Key management is handled on the drive itself, making the SED encryption process essentially a black box. This requires placing a lot of trust in the drive's firmware. In contrast, LUKS is more transparent and has been thoroughly audited. Personally, I would only use SED to supplement LUKS, as the performance impact would be minimal. On the plus side, using both together will automatically encrypt boot as well.
Our valued sponsor
What tool can encrypt a laptop's data instantly when it's closed, and how do you set it up?
- Thread starter sebastian
- Start date
-
- Tags
- data encryption laptop security
I think a post or reply to this topic by the professionals on how to do all the above would be appreciated by everyone in the forum. Plenty of information has already been posted but it is difficult to keep up with it and even more difficult to implement it.
The OP's request is to have secure offline data - data at rest - after laptop is closed.
That is achievable on Microsoft Windows with Bitlocker (somehow I originaly wrote Bitdefender
) and VeraCrypt, macOS FileVault and Linux with LUKS. Also, SED and RAID encryption is agnostic towards O/S, so it can be used for similar purpose.I may write the short instruction for all applicable O/S and scenarios, but not before next weekend. @0xDEADBEEF can also write it perfectly and I read that @void has knowledge as well.
SED idea is analog to HW RAID. It offloads the CPU. But, while RAID firmware is actually a Linux O/S, SED firmware is proprietary and should be used with extreme caution.
Whilst it's possible to have rootfs encrypted by ZFS, it's primary purpose is to encrypt data sets not an O/S related volumes on BSD derivatives and Linux distribution. Also, if rootfs isn't encrypted, (only) non system volumes are encrypted which negates the aim to have secure machine that locks out users and encrypted volumes and performs power cycle once condition is triggered.
To be fair and transparent, system encryption may be achived on Linux as well with VeraCrypt, but that is highly specific case and set-up.
Last edited:
I agree, that would definitely benefit the community. I'll find some time in the near future to compile the key points and information mentioned around the forum into a comprehensive overview. Mraleph also has a wealth of knowledge regarding OPSEC, so I'll look to involve him as well. The idea is to create a thread where everyone can contribute and share their expertise. As @Sols has mentioned before, security is much broader than just picking the right OS and using the right configurations. Security is a complex problem without an easy solution and also requires you to change your way of thinking.
Whatever you all do, I want you to realize that movies are NOT equal to real-life altercations with delusional gang members with a monopoly on violence.
With this, I'll leave you to read the following:
(1) 2016 - Former police officer locked in solitary confinement for 7 months after not handing over his passwords.
(2) 2016 - Suspect who won’t decrypt hard drives jailed indefinitely. He's got the keys to his own prison, the court says.
(3) Man Who Refused To Decrypt Hard Drives Is Free After Four Years In Jail
(4) The U.S. Court of Appeals for the 3rd Circuit has a case pending on the Fifth Amendment limits of forcing a suspect to enter his password to decrypt a computer. The case provides an opportunity for the 3rd Circuit to correct an error in the 11th Circuit’s treatment of the same question, specifically on how to apply the “foregone conclusion” doctrine to an order requiring decryption of a storage device.
(5) 2017 - Man jailed indefinitely for refusing to decrypt hard drives loses appeal. “Our client has now been in custody for almost 18 months,” defense attorney says.
(6) 2009 - - UK - Two convicted for refusal to decrypt data. Up to five years in jail after landmark prosecutions.
(7) Ad infinitum... Some of these are the same guy who wasn't supposed to do more than 18 months (imagine that) but ended up doing four (4) years. The other is in the UK.
Before the dawn of the WWW, I witnessed myriads of these cases when it was just a password to get into the BIOS or Lotus 123, etc,. The "law" would lock up ANY person and not release them even after the password was "decrypted" by someone else.
Don't build Pies in the Skies! (Unless you have a flying kitchen and a Jetman/Jetwing)
There are NO mutes in prison!
Caveat Emptor.
PS. There is a solution to this, and Huawei has a good one...in case anyone is interested, *BUT* always remember: There are NO mutes in prison!
With this, I'll leave you to read the following:
(1) 2016 - Former police officer locked in solitary confinement for 7 months after not handing over his passwords.
(2) 2016 - Suspect who won’t decrypt hard drives jailed indefinitely. He's got the keys to his own prison, the court says.
(3) Man Who Refused To Decrypt Hard Drives Is Free After Four Years In Jail
(4) The U.S. Court of Appeals for the 3rd Circuit has a case pending on the Fifth Amendment limits of forcing a suspect to enter his password to decrypt a computer. The case provides an opportunity for the 3rd Circuit to correct an error in the 11th Circuit’s treatment of the same question, specifically on how to apply the “foregone conclusion” doctrine to an order requiring decryption of a storage device.
(5) 2017 - Man jailed indefinitely for refusing to decrypt hard drives loses appeal. “Our client has now been in custody for almost 18 months,” defense attorney says.
(6) 2009 - - UK - Two convicted for refusal to decrypt data. Up to five years in jail after landmark prosecutions.
(7) Ad infinitum... Some of these are the same guy who wasn't supposed to do more than 18 months (imagine that) but ended up doing four (4) years. The other is in the UK.
Before the dawn of the WWW, I witnessed myriads of these cases when it was just a password to get into the BIOS or Lotus 123, etc,. The "law" would lock up ANY person and not release them even after the password was "decrypted" by someone else.
Don't build Pies in the Skies! (Unless you have a flying kitchen and a Jetman/Jetwing)
There are NO mutes in prison!
Caveat Emptor.
PS. There is a solution to this, and Huawei has a good one...in case anyone is interested, *BUT* always remember: There are NO mutes in prison!
This is not enough. I would recommend at least 256 bit (AES for example).
Lets take Bitlocker for example. Bitlocker relies on the decryption keys being passed from the TPM chip to the motherboard. This process is vulnerable to sniffing attacks on many types of computers. (Mac stores their secure chip inside a 'secure enclave' which negates these types of sniffing attacks ).
These attacks are fairly easy with only $15 worth of gear.
To negate these attacks on windows we need to use Bitlocker + TPM + PIN setting. This prevents the decryption keys from being passed to the motherboard without the PIN being entered. The TPM has anti hammering capabilities which prevents brute-forcing the PIN.
TPM sniffing – Sec Team Blog
blog.scrt.ch
When talking about mobile phones, its important to remember your device is the most secure when it is off. If your device is powered on, the vast majority of devices can be hacked into using tools such as Cellebrite. If this is a problem for you, look into Graphene OS.
GrapheneOS: the private and secure mobile OS
GrapheneOS is a security and privacy focused mobile OS with Android app compatibility.
This is highly dependent on jurisdictions. In other jurisdictions I've seen there are no requirement to hand over decryption keys. Some jurisdictions have a time limit to attempt to decrypt the device before they have to return it. Some places have mixed case law.
Other ways around this are beyond just 'encryption'. I would recommend looking into encryption and also stenography (hiding the encrypted folders inside other files). The forensic tools available for recovering data hidden via stenography is limited at best.
Example cases:
In a 2019 Ontario court case (R v. Shergill), the defendant was initially ordered to provide the password to unlock his phone. However, the judge concluded that providing a password would be tantamount to self-incrimination by testifying against oneself.
United States v. Doe, the United States Court of Appeals for the Eleventh Circuit ruled on 24 February 2012 that forcing the decryption of one's laptop violates the Fifth Amendment
They probably meant 32 bytes key length which equals 256 bit.This is not enough. I would recommend at least 256 bit (AES for example).
Lets take Bitlocker for example. Bitlocker relies on the decryption keys being passed from the TPM chip to the motherboard. This process is vulnerable to sniffing attacks on many types of computers. (Mac stores their secure chip inside a 'secure enclave' which negates these types of sniffing attacks ).
These attacks are fairly easy with only $15 worth of gear.
To negate these attacks on windows we need to use Bitlocker + TPM + PIN setting. This prevents the decryption keys from being passed to the motherboard without the PIN being entered. The TPM has anti hammering capabilities which prevents brute-forcing the PIN.
TPM sniffing – Sec Team Blog
When talking about mobile phones, its important to remember your device is the most secure when it is off. If your device is powered on, the vast majority of devices can be hacked into using tools such as Cellebrite. If this is a problem for you, look into Graphene OS.
GrapheneOS: the private and secure mobile OS
GrapheneOS is a security and privacy focused mobile OS with Android app compatibility.grapheneos.org
This is highly dependent on jurisdictions. In other jurisdictions I've seen there are no requirement to hand over decryption keys. Some jurisdictions have a time limit to attempt to decrypt the device before they have to return it. Some places have mixed case law.
Other ways around this are beyond just 'encryption'. I would recommend looking into encryption and also stenography (hiding the encrypted folders inside other files). The forensic tools available for recovering data hidden via stenography is limited at best.
Example cases:
In a 2019 Ontario court case (R v. Shergill), the defendant was initially ordered to provide the password to unlock his phone. However, the judge concluded that providing a password would be tantamount to self-incrimination by testifying against oneself.
United States v. Doe, the United States Court of Appeals for the Eleventh Circuit ruled on 24 February 2012 that forcing the decryption of one's laptop violates the Fifth Amendment
I can’t comment on this chap specifically but will comment on one aspect this feed has brought to light - as someone that was once “interrogated” by the secret police of Dubai - as a AI visiting speaker - I will say the best and only approach is the following.
Burner devices -> you travel and buy new (price in) so traveling with a simple phone and then buy onsite in new location (work related).
If ever stopped and device leaves hands - bin it buy new.
If ever have device left unintended and strangers around or even cleaners - buy new.
As for storage find the best encrypted client side access service point for remote storage ideally on ZK.
For personal - use it strictly for personal - and have two - one for travel and one for main
——
Governments increasingly are being intrusive under the guise of anti terrorism but naturally that’s just a facade for other interests - tech know how, trade secrets, etc another final piece of advice have a handy bucket of water nearby
I should add whilst I was being interrogated our rooms were being turned upside down - and they also went though our devices without passcodes/passwords in our room - and our mobiles had Pegasus.
Hence always just dump it use it as an access point but not for its local storage etc and buy new.
Naturally the best way to buy new is in store in an emergency or ideally via secondary cash purchase market and then clean / clear fresh install and use a completely unrelated account fresh to set up and then restrict all data outgoing or cloud services so basically your prior grid referenced device against yourself/company ceases and you don’t popup as a new device etc.
Burner devices -> you travel and buy new (price in) so traveling with a simple phone and then buy onsite in new location (work related).
If ever stopped and device leaves hands - bin it buy new.
If ever have device left unintended and strangers around or even cleaners - buy new.
As for storage find the best encrypted client side access service point for remote storage ideally on ZK.
For personal - use it strictly for personal - and have two - one for travel and one for main
——
Governments increasingly are being intrusive under the guise of anti terrorism but naturally that’s just a facade for other interests - tech know how, trade secrets, etc another final piece of advice have a handy bucket of water nearby
I should add whilst I was being interrogated our rooms were being turned upside down - and they also went though our devices without passcodes/passwords in our room - and our mobiles had Pegasus.
Hence always just dump it use it as an access point but not for its local storage etc and buy new.
Naturally the best way to buy new is in store in an emergency or ideally via secondary cash purchase market and then clean / clear fresh install and use a completely unrelated account fresh to set up and then restrict all data outgoing or cloud services so basically your prior grid referenced device against yourself/company ceases and you don’t popup as a new device etc.
Last edited:
It was probably a typo error, but it's steganography - not stenography as
The current standard is AES; previous was DES and it had 56 bit key length. There aren't encryption algorithm with 32 bit key length considered safe
as @aniglo22 commented
and I wrote it before
Encrypting entire machine with 32 bit encryption sounds like a TV presenter's understanding of the topic stemming from watching Impossible mission sequels
More plaussible is that they refered to 32 byte key lenght which is equal to 256 bits - an industrial standard for AES for instance, as stated
For the sake of completeness, what TV presenter and its source may refered to
can be 32 bit block length but ciphers with that block size aren't considered safe nor are implemented on a scale - RC5 for example.
All currently used encryption alghorithms - AES (RijnDael), Serpent, Twofish, Camelia - have at least 128 bit block size. DES and Blowfish have 64 bit block size.
As Blowfish has minimum 32 bit key length, TV presenter may refered to it but it's highly unlikely it did
When talking about mobile phones, its important to remember your device is the most secure when it is off. If your device is powered on, the vast majority of devices can be hacked into using tools such as Cellebrite. If this is a problem for you, look into Graphene OS.
GrapheneOS: the private and secure mobile OS
GrapheneOS is a security and privacy focused mobile OS with Android app compatibility.
Perhaps, a device with GrapheneOS was examined with Cellebrite UFED and conclusion was that it's not possible
It's not the topic of the thread and it shouldn't be public - as we may interfere with ongoing investigations - but this school of thought may/will end for person thinking about mutes in prison whilst spewing its own stupidity and enviousness.A person may break its prior grid references only if it cease to operate within the same social framework. What's the point of using a burner phones or other equipment when you retain same social context - your address book is the same - even if another contact uses different address (IP, phone number etc.) the fact is that persons haven't changed.
Well LUKS comes as an option with most distro installers at this point so thats figured out for you already, and from what I remember veracrypt on windows was also a basic installer walking you through it. Theres always youtube videos if you prefer that over reading documentation, but its pretty simple and only reason you think you cannot figure it out is because of people making it sound harder than it is.
Maybe you all should get back to the topic. What's going on here is childish !!
I quote the above not to quote OP but to remind you what the topic is about.
Next step will be a BAN from the thread! So please stop insulting each other, it's boring after all.
yeah an you can setup 2 separate sessions with 2 different passwords. For instant you have session one with just trash and session two with the super secret stuff. Should one ak you for the password and put a gun to your head you can just give him the password for the session with trash and he will never find out there is another secret session with a different password!
I thought I answered this, but here we go:
(1) Shergill is doing a lengthy prison sentence for child porn. The courts called it that way because they do NOT care. What's the point? They got the guy, who got just as much as if he had given the password. Look deeply into the case. It's obvious! I hope you understand the Machiavellian word salad by the courts.
(2) This "John Doe" was incarcerated! The defendant doesn't give the password. They tell you you don't have to, but they STILL hold you in contempt of court. They got you! If you provide the password, you'll serve four years. If you refuse, they hold you in contempt of court, and you serve four years! How can this be lost on so many people?
(3) In these cases, they'll offer you immunity if you provide the password. That means the DOJ will NOT prosecute you. ***BUT*** here is where they will f*(& you without vaseline by the state, another district, or another country! I've seen this happen so many times. It's so tiring.
(4) As far as #3 is concerned, you all need to read about Sergey Aleynikov. You can ask me questions about this case if you don't understand it. I know this case inside and out.
i see some members mentioned TPM sniffing
let me explain what i know about it
this problem is more often happening on high end laptops/motherboards than on the low end
let me explain why
high end laptops/mbs have tpm as a separate chip, and that chip has physical path on PCB that is used to communicate with CPU, meaning these would be the sniffing pins for an attacker since this communication is not encrypted(other member mentioned it's cheap equipment, in fact in white papre i've read they use raspberry pi)
low end laptops/mbs have tpm bult in the CPU, so it is a black box that can't be use
all this brings us to a conclusion that TPM is weaker than a password (ofcrs locked bios to prevent booting using a different bootloader, to cover evil maid attack), that is why most out of the box solutions (bitlocker for example) are prone to some vulnerabilities
if you are using bitlocker there is a way to make it ask for password (to input manually like vera crypt does) , instead of doing automatic dec using TPM, this would be more secure option
bitlocker, vera crypt, apple enc....they all relay on the same math (AES), so encryption wise they are all equally good/bad
let me explain what i know about it
this problem is more often happening on high end laptops/motherboards than on the low end
let me explain why
high end laptops/mbs have tpm as a separate chip, and that chip has physical path on PCB that is used to communicate with CPU, meaning these would be the sniffing pins for an attacker since this communication is not encrypted(other member mentioned it's cheap equipment, in fact in white papre i've read they use raspberry pi)
low end laptops/mbs have tpm bult in the CPU, so it is a black box that can't be use
all this brings us to a conclusion that TPM is weaker than a password (ofcrs locked bios to prevent booting using a different bootloader, to cover evil maid attack), that is why most out of the box solutions (bitlocker for example) are prone to some vulnerabilities
if you are using bitlocker there is a way to make it ask for password (to input manually like vera crypt does) , instead of doing automatic dec using TPM, this would be more secure option
bitlocker, vera crypt, apple enc....they all relay on the same math (AES), so encryption wise they are all equally good/bad
There is no universal solution as its always about details. As for BIOS/UEFI and TPM I agree completelly. Essentially, bootstrap from other bootloader - via disabled external boot and locked UEFI - should be disabled and PIN/password should be always used when TPM is active where Microsoft Windows Bitlocker or Linux LUKS is used. But, TPM should be disabled and not be used in the first place.
VeraCrypt can't utilize TPM which in the end does not make it inferior to other solutions. FileVault uses Apple's secure enclave which is an analogue to TPM's implementation. I would not use Apple products for anything that is above sensitive.
I partially agree with this for AES - though which mode of operation - whether CBC or XTS beside other - is used can be of significant security difference but also backward compatibility.
Both VeraCrypt and LUKS are superior to Bitlocker and FileVault as they offer other cipher algorithms - Serpent, Twofish etc.
VeraCrypt cipher's cascade can be used which makes it superior to other solutions.
We internally deprecated AES and are using that cipher in quite specific set-ups.
In order to protect system volume (the one where O/S reside) beside other data volumes this selection may be of help - depending on what hardware and O/S is used
Microsoft Windows - VeraCrypt (optimum is cascade)
macOS - FileVault
LINUX - LUKS
There are special cases when boot volume requires encryption on LINUX and also VeraCrypt used for system volume encryption on LINUX but those require significant non user friendly set-up.
yes, bios needs to be locked in any case (tpm or password) to prevent various attack (i mentioned evil maid one that will basically act as a keylogger)
i do agree that preboot password/pin is more secure than tpm due to the fact that with tpm if attacker has access to the entire device (not just disk drive) it can either:
- sniff communication between tpm and cpu and get dec keys
- just boot laptop and have decryption key(not the password) stored in ram (various tech including freezing ram modules can be used to extract it, or just plain bypass of win login screen)
due to various ram extraction tech, OP question is hard to answer
some rams hold memory longer than others, so immediate power off might still leave the keys in there (again this is just a theory)
as far as chiper algos goes, my knowledge is very limited
i think modern versions of AES block chipers are secure, i agree that there are some versions such as ECB block chiper that are less secure but even with them it depends on block size and key size
we are talking about potential theoretical attacks here
most of these will be very very hard to achieve, close to impossible
most people will have their security breached by some drive by virus/malware, or running software that is not trusted(i know that's not the topic)
not sure why you are against apple, i am sure you know more than i do, but i honestly find them the most secure option (nothing is bulletproof).
fun fact: some keys can be extracted using electronic microscope. chip is "stripped down", and all the boxes are read (to see which one contains, and which one doesn't contain an electron) - no actually help with this
@0xDEADBEEF said it well, most problematic part is key management
with all this limited knowledge i have, and spending a lot of mind power, some of my projects still got hacked (ex. server running on newest version of ubuntu, with newest version of apache as web server), how i don't know (login was SSH, i was not logging in with root(but even if I did doesn't change the fact), server was hosted on very reputable hosting, directory listing was disabled, cgi scripts were running by loading another script/module from outside web directory....
Nothing is bulletproof, and we shouldn't exaggerate
i do agree that preboot password/pin is more secure than tpm due to the fact that with tpm if attacker has access to the entire device (not just disk drive) it can either:
- sniff communication between tpm and cpu and get dec keys
- just boot laptop and have decryption key(not the password) stored in ram (various tech including freezing ram modules can be used to extract it, or just plain bypass of win login screen)
due to various ram extraction tech, OP question is hard to answer
some rams hold memory longer than others, so immediate power off might still leave the keys in there (again this is just a theory)
as far as chiper algos goes, my knowledge is very limited
i think modern versions of AES block chipers are secure, i agree that there are some versions such as ECB block chiper that are less secure but even with them it depends on block size and key size
we are talking about potential theoretical attacks here
most of these will be very very hard to achieve, close to impossible
most people will have their security breached by some drive by virus/malware, or running software that is not trusted(i know that's not the topic)
not sure why you are against apple, i am sure you know more than i do, but i honestly find them the most secure option (nothing is bulletproof).
fun fact: some keys can be extracted using electronic microscope. chip is "stripped down", and all the boxes are read (to see which one contains, and which one doesn't contain an electron) - no actually help with this
@0xDEADBEEF said it well, most problematic part is key management
with all this limited knowledge i have, and spending a lot of mind power, some of my projects still got hacked (ex. server running on newest version of ubuntu, with newest version of apache as web server), how i don't know (login was SSH, i was not logging in with root(but even if I did doesn't change the fact), server was hosted on very reputable hosting, directory listing was disabled, cgi scripts were running by loading another script/module from outside web directory....
Nothing is bulletproof, and we shouldn't exaggerate
Did it had active network policy - nftables or iptables - active? What was default policy? What ports under what states were opened?
What services were active beside system ones and apache2?
What were sshd params?
What web management software it had?
Was it machine, VPS or container or shared hosting?
IBM solutions - both hardware and software - provides you, as professional user, a control.
With Apple solutions, control is restricted to the level its not a control but your adaptation to their solution
IBM is robust and not quite appealing to eye; Apple is like Italian women hence dangerous
only ports for SFTP and HTTPS were opened.
firewall was activated and was restricting everything
it was a VPS(virtual machine on famous hosting provider's server)
it was managed through browser interfaces like many otherd VPS/droplets
SSH was done on a standard way, i made random keys with putty, uploaded private key through browser intreface...
bad thing i didn't have any logging except the standard one enabled, since i was very confident that issues can't occur
what i did not do, is changing default ssh port to some other, but still by not doing this, it could be a cause for server being down due to ddos, and not for someone to gain access to files
all scripts had input sanitized, and it was not able to deliver a hack that way
I am pretty much clueless when it comes to networks, but I think i covered most of the bases
firewall was activated and was restricting everything
it was a VPS(virtual machine on famous hosting provider's server)
it was managed through browser interfaces like many otherd VPS/droplets
SSH was done on a standard way, i made random keys with putty, uploaded private key through browser intreface...
bad thing i didn't have any logging except the standard one enabled, since i was very confident that issues can't occur
what i did not do, is changing default ssh port to some other, but still by not doing this, it could be a cause for server being down due to ddos, and not for someone to gain access to files
all scripts had input sanitized, and it was not able to deliver a hack that way
I am pretty much clueless when it comes to networks, but I think i covered most of the bases
It sounds like your web application might have been vulnerable in multiple ways, not just to injection attacks [1]. Exposed HTTP(S) services often provide attackers with a foothold to infiltrate a server and escalate privileges to cause more damage. For the SSH part, I recommend setting up a jump server that is the only machine allowed to access your servers over port 22. You can then tunnel into this jump server and from there ‘jump’ to the rest of your infrastructure. Ensure that access to your jump server is tightly controlled with strict access policies. This approach significantly mitigates the risk of unauthorized access, brute forcing or password spraying.
A solution you can use is Teleport: Easiest, Most Secure Infrastructure Access (GitHub - gravitational/teleport: The easiest, and most secure way to access and protect all of your infrastructure.), which your IaaS provider can likely auto-deploy for you.
Also a WAF like Cloudflare is the easiest to setup and will block threats on the application side. I don't want to go off topic too much, so if you want to go more in-depth about this, feel free to send me a message.
[1] OWASP Top Ten | OWASP Foundation
Forum Announcement
-
!NEWS! Take Control of Your Destiny with OffshoreCorpTalk- Latest: bountymounty
Latest Threads
-
Panama v Belize or ? for US eCommerce biz, residing in Latam- Started by jv88
- Replies: 0
-
-
-
-
Payment gateway for EVC (Expedia Virtual Card)- Started by diskoteka
- Replies: 0
-
-
-
-
Best place to register offshore company with nominees, privacy question?- Started by justnew
- Replies: 7
