I kind of want to ask a question here since I'm likely to run into my betters on this topic. How does macOS / Windows 11 / Linux stack up to each other in terms of full-disk encryption?
What's the simplest approach to ensuring that my data isn't as easily decrypted, and to protect myself? (I'm aware of other vectors like via Internet/browsing, etc, but I'm concerned also about the physical security of my data).
Is macOS disk encryption pretty good all things considering? I see Windows 11 requires a compatible configuration to enable it for Home edition, or a Pro license. (Why?)
I've setup LUKS, created my keyphrases and all of that before on Fedora. But I'll be honest, I don't know how effective the defaults are and whether I'm doing the correct thing. I also worried about losing access to my data if the disk or LUKS volume became corrupted.
IIUC the main benifit of Windows and macOS full disk encryption over Linux is that they will use a TPM to protect the key by default. This effectively prevents brute forcing of even very weak passwords at the expense of being unable to recover your data on a different computer.
You can set up Linux to use the TPM which will be a good improvement. Other than that I believe that LUKS has good defaults.
The TPM is a blessing and a curse. On the one hand, it protects you from having to remember any passwords and makes encryption available to almost anyone.
I'm not sure about the situation on macOS, I think Apple's TPM is a bit more advanced than most PC alternatives. I don't think modern macs are vulnerable to the attack I linked above. Microsoft's Pluton chip may also be different, I can't find much about its physical security properties.
That assumes the TPM is willing to unseal the drive, so you can use a probe to capture the key as it sends it. Microsoft recommend using TPM+PIN which prevents this as the TPM won't release the key unless you provide the PIN. The PIN can be fairly weak as the TPM prevents brute force.
I'm sure there are still vulnerabilities, but this is the method that governments themselves use for their devices, at least in UK.
Yes, TPM without a password is a step up from no encryption but TPM with even a weak password is a huge benefit.
Of course I am assuming that the TPM works correctly. Vulnerabilities in that may be more likely than with software crypto. But that is a difficult tradeoff to evaluate.
Use the TPM as an additional layer of protection. In combination with other things as well, heck even the encryption built into an SSD. So if any one fails, it's still better than nothing. All with separate, uncorrelated passphrases.
> What if I want to move my own drive somewhere else?
That's the fun part: you don't. Move the contents somewhere else, format the drive, and move them back. Also another cool feature: if the TPM stops working for some reason you lose all your data! (unless you have offsite backups, which you should anyways). I'm saying this kinda jokingly but this really is a feature of keeping the keys in your TPM, in a lot of situations this is a desired behavior.
Be aware that in the case of Bitlocker specifically Microsoft "conveniently" saves your encryption key on their "cloud", so you don't really need the TPM to decrypt stuff, which of course goes completely against the purpose of storing the key there in the first place. Oh yeah, also: DON'T trust Bitlocker, it's absolutely compromised if you are using an SSD which provides firmware "encryption". [0][1]
>Be aware that in the case of Bitlocker specifically Microsoft "conveniently" saves your encryption key on their "cloud", so you don't really need the TPM to decrypt stuff, which of course goes completely against the purpose of storing the key there in the first place.
What MS stores in the cloud is not the encryption key but a recovery key. Obviously a recovery key can also be used to perform the decryption, but it has the benefit that it's generated by the system to be of high entropy, as opposed to a human-chosen password.
If you're against FDE recovery keys I assume you're also against 2FA recovery codes.
You generally can't backup the TPM key as most TPMs are designed to prevent key material extraction.
However, with LUKS there are two keys. The key slot key that is stored in the TPM is not able to be retrieved (by design) however the disk encryption key is not stored in the TPM, it is stored encrypted in each key slot. As long as you have access to the disk encryption key via an existing key slot you can create additional key slots without TPM protection. Once you have a non-TPM key slot you can transfer the drive anywhere and unlock it using that slot instead of the TPM. Of course this slot will not be protected from brute-forcing by the TPM but if using a sufficiently long passphrase for backup or transfer it should be fine.
TL;DR if you have access to the TPM you can migrate away from it. But if the TPM is your only form of access and you lose access (stolen, wiped, forget password...) then your data is irretrievable.
They're fine for most use cases. Probably wouldn't trust windows or MacOS against state actors.
Fedora defaults are adequate but depend on the strength of your password.
Simplest setup is actually to just enable SSD password in bios. All SSDs these days are encrypted by default - they just store the password in bios and don't tell you they're doing it. If you set a password there is zero perf overhead.
A basic linux setup is unencrypted boot and encrypted root partitions.
You can encrypt boot using a small grub partition to chain load boot/root but all it's preventing is someone swapping your kernel/bootloader configs out without your knowledge. If that's not a concern you can skip it.
While using bios level encryption is simple it limits my options as far as controlling decryption with keyfiles on USB or yubikey which I like in some situations.
The bigger problem I have with encryption these days is ensuring my automated backups are encrypted despite being always on.
They are not sanke oil but "compliance tricks" ;=)
Basically:
- full disk encryption is required for whatever reason
- BIOS SSD passwords fulfill that requirement
and it is good enough to prevent accidentally leaking data when losing the laptop and it goes in the hand of someone slightly technical versatile but not a specialist/hacker nor a targeted attack interested in handing the laptop to a specialist.
Hence why compliance rules in cases involving actual sensitive data often require full disk encryption using more strict requirements not fulfilled with BIOS encryption.
> Nobody verifies that the encryption scheme is sound.
for some Latop brands/variants you most likely have a sound encryption schema, but there is still the problem that it's unlocked by the TPM and the en-/de-cryption is likely run on the CPU or similar instead of an specialized IO description chip tightly coupled with the TPM (modern Apple devices, at least phones, are a notable exception here AFIK). So even if the encryption schema is sound it's normally not too hard to extract the key in one of many ways for a specialist. And even if that doesn't work there is still the attack to inject your OS which then sees the unencrypted SSD... so normally not secure.
It all depends on your threat model, of course. If you trust Apple and Microsoft and just don't want thieves to read your data, then you can probably rely on OS encryption tools: as far as I know, not even governments have managed to unlock any of these methods without access to a (backup) key. If you're an activist in a totalitarian country, you should take different precautions.
On Windows 11, Bitlocker should just work. Windows 10 still requires a Pro license for encryption, but 11 should've fixed that, making it available (in most part) to all versions.
If you use Bitlocker, pay attention to where the recovery codes are stored. By default, Windows will offer to add the recovery key to your Microsoft account, theoretically giving Microsoft and various governments access to a method of decrypting your drive. You can opt out of that and store the recovery key somewhere safe instead. You should keep this key available, because you may need it even if you know your password (for example when the secure boot state gets toggled, or the boot configuration changes).
Also consider using a password in addition to the TPM key storage if you're okay with your drive not being decryptable without the recovery key outside of your computer (https://www.howtogeek.com/262720/how-to-enable-a-pre-boot-bi...). Windows likes to store the key inside your TPM (which is then exchanged without encryption in a way that someone with physical access can probably intercept), which makes it possible for Windows to boot without prompting for a key, meaning an exploit against the Windows login prompt can bypass the security Bitlocker PROVIDES. An additional password means you need to type in a password on boot,
If you distrust closed source encryption methods, Veracrypt is available for PC as an open source full disk encryption system. My understanding is that the code is reasonably safe, though you may want to Google around to make sure it's as secure as you'd like it to be.
With LUKS, your data is gone when the LUKS headers are gone; your password only serves to decrypt the real key that protects your data. You can back up the headers somewhere safe (this article shows you the commands to do so) and restore them later in case something goes terribly wrong. You'll still lose data if the data written to disk is corrupted of course, but with the headers backed up you should be reasonably safe against specifically encryption related disk corruption.
Once you have loaded the encryption keys, LUKS presents itself as just another drive, completely transparent to the underlying file system, so fixing partition corruption is similar to fixing an unencrypted drive. As far as I know, the same is true for most other operating systems as well. Many traditional file recovery tools work after simply unlocking an encrypted volume.
If you're paranoid, you can also use the fact that LUKS headers are all you need to your advantage. It's possible to configure LUKS to store the headers on a separate device (i.e. one you always carry with you and another in a secure location) so a drive can be completely unreadable without a second physical storage device, even if your adversaries know your password.
I think the simplest method of securing yourself would be to just enable drive encryption built into your OS with a sufficiently long and random password. It's probably best to use a password generator to create one. In theory attacks on bad key derivation functions are feasible, but most people's data isn't worth all the time and compute it takes to crack such a password. If you use modern tools and modern configurations (backwards compatibility can be an issue), the tools built into your OS are probably Good Enough™ for most people.
I kind of want to ask a question here since I'm likely to run into my betters on this topic. How does macOS / Windows 11 / Linux stack up to each other in terms of full-disk encryption?
What's the simplest approach to ensuring that my data isn't as easily decrypted, and to protect myself? (I'm aware of other vectors like via Internet/browsing, etc, but I'm concerned also about the physical security of my data).
Is macOS disk encryption pretty good all things considering? I see Windows 11 requires a compatible configuration to enable it for Home edition, or a Pro license. (Why?)
I've setup LUKS, created my keyphrases and all of that before on Fedora. But I'll be honest, I don't know how effective the defaults are and whether I'm doing the correct thing. I also worried about losing access to my data if the disk or LUKS volume became corrupted.
Any advice or tips for me?