Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.

On the other hand, someone who can steal your laptop may be able to dump the TPM keys by simply attaching probes and turning on your machine: https://astralvx.com/stealing-the-bitlocker-key-from-a-tpm/

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.


>On the other hand, someone who can steal your laptop may be able to dump the TPM keys by simply attaching probes and turning on your machine: https://astralvx.com/stealing-the-bitlocker-key-from-a-tpm/

That only works for dTPMs. fTPMs (ie. ones built into the cpu) is safe from that attack, although they might have other weaknesses.


It's not quite clear to me whether fTPMs really protect against hardware attacks.

According to

https://security.stackexchange.com/questions/189950/how-does...

most CPUs can be controlled via JTAG, and apparently that includes many of their deep internals.


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.


By design, does the TPM prevent me from making a backup of own keys? What if I want to move my own drive somewhere else?


   > 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]

[0]: https://www.tomshardware.com/news/crucial-samsung-ssd-encryp...

[1]: https://twitter.com/matthew_d_green/status/10594413723175813...


>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.


I think the concern is that Microsoft does this automatically and keeps a copy. A backup under my control is a completely different matter.


The rest of their post makes it clear that they consider any keys that are not backed by their TPM to be undesirable.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: