Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bypassing disk encryption on systems with automatic TPM2 unlock

oddlama.org

Post reply on HN
Print view View original

91–100 of 136 posts

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#91

Post by kevincox »

AzzyHN wrote: post #88
_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

I believe with software-based encryption (LUKS and the like), the decryption key ends up being stored in RAM, which will always present a risk. And TPM-based solutions don't have this problem. Could be wrong though.

I think most TPM based solutions still use software encryption. Most TPMs don't have the bandwidth to actually decrypt all disk data as it is read. (I think Apple devices do actually do something like this, but I don't think it is common.)

I believe when using TPM with LUKS the TPM just decrypts the master key and that is handed back to the OS and used in software. So the primary key does end up in RAM.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#92

Post by sedatk »

prmoustache wrote: post #44
sedatk wrote: post #8

Earlier quoted context omitted.

Because I don't expect a random thief to go to the lengths of identifying OS level vulnerabilities to bypass the login prompt in order to decrypt the disk contents. The potential gains for them are marginal compared to the time and effort spent there, not to mention technical expertise needed. I expect them to steal it, and if it's encrypted, just sell it for parts, or wipe it and sell it anew. Entering a password ca…

> Entering a password can be a lot of work if you use a strong password (and if you don't, why bother with a password?). So does-it means you do not setup a password/passphrase for your user account?

No, I use biometrics login for the same reasons. I have a strong password, but 99% of the time, I don’t need it.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#93

Post by sedatk »

_blk wrote: post #25
sedatk wrote: post #8

Earlier quoted context omitted.

Because I don't expect a random thief to go to the lengths of identifying OS level vulnerabilities to bypass the login prompt in order to decrypt the disk contents. The potential gains for them are marginal compared to the time and effort spent there, not to mention technical expertise needed. I expect them to steal it, and if it's encrypted, just sell it for parts, or wipe it and sell it anew. Entering a password ca…

A weak password is always better than no password. It's like using a cheap lock on your door or not locking it. Practically, if a thief wants to get through he'll get through but your insurance and sentencing will look different.

As I said before, if someone’s determined enough to spend a lot of time find OS level vulnerabilities and exploit them to decrypt my disk, they will certainly have enough time and determination to break a weak password.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#94

Post by snailmailstare »

rollcat wrote: post #80

When I first read about TPM-based FDE on Linux[0], I was excited that the systemd guys were finally taking a step in the right direction - BitLocker/FileVault were standard on Windows/macOS for a long time by that point. FDE should be secure by default, dead-simple to set up (e.g. a checkbox in the installer that defaults to "enabled"), and painless for everyday use. [0]: https://0pointer.de/blog/brave-new-trusted-bo…

>> we can confuse the initrd into executing a malicious init executable.

This hash the next link method is always as flawed as the weakest link..

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#95

Post by toast0 »

_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

I would consider it for my hosted server.

Entering a password on boot is a lot of work, because I need to vpn in, and run a java webstart kvm application (serial over ipmi would work better, but it doesn't work well on the hardware I have).

Encrypted disks is a requirement because I don't trust the facility to wipe disks properly. But I assume I would be able to clear the TPM (if present) when I return the machine. And I could store a recovery key somewhere I think is safe in case of hardware issues (although, last time I had hardware issues, I simply restored from backup to new to me disks)

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#96

Post by cuu508 »

toast0 wrote: post #95
_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

I would consider it for my hosted server. Entering a password on boot is a lot of work, because I need to vpn in, and run a java webstart kvm application (serial over ipmi would work better, but it doesn't work well on the hardware I have). Encrypted disks is a requirement because I don't trust the facility to wipe disks properly. But I assume I would be able to clear the TPM (if present) when I return the machine. A…

> Encrypted disks is a requirement because I don't trust the facility to wipe disks properly.

Couldn't you wipe the disks yourself?

Or are you thinking of cases where the disk breaks, gets replaced, and the removed disk does not get properly destroyed?

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#97

Post by blastrock »

Very clever!

I am the author of one of the older guides https://blastrock.github.io/fde-tpm-sb.html .

I was wondering about the solution you propose which seems a bit complicated to me. Here's my idea, please tell me if I'm completely wrong here.

What if I put a file on the root filesystem with some random content (say 32 bytes), let's name it /prehash. I hash this file (sha256, blake2, whatever). Then, in the signed initrd, just after mounting the filesystem, I assert that hash(/prehash) == expected_hash or crash the system otherwise. Do you think it would be enough to fix the issue?

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#98

Post by _verandaguy »

foepys wrote: post #90
_verandaguy wrote: post #87

Earlier quoted context omitted.

This was actually a problem for me on my current gaming PC build! I had switched to a new AM4 mobo a few years back and decided to spring for a pluggable TPM chip (since the CPU I have doesn't come with TPM onboard). Plugged it in, set everything up pretty seamlessly in windows, no fuss, no muss, boot drive's encrypted transparently. The lack of a password was a bit jarring at first, but it's a gaming PC, so if thing…

Don't all AM4 CPUs feature fTPM which is a firmware-based TPM? Bitlocker at least accepts this as secure enough to boot Windows 11.

Frankly, it's possible; I don't remember at this point. At the time, I just decided to go for a separate chip since I hadn't heard of fTPM being available at the time. The chip in question's a 3900X and it's still running smoothly.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#99

Post by [deleted] »

oddlama wrote: post #63
staff3203 wrote: post #12

On my system, I used `tpm2-measure-pcr=yes` in `/etc/crypttab.initramfs`, then used `--tpm2-pcrs=0+2+7+15:sha256=0000000000000000000000000000000000000000000000000000000000000000` with `systemd-cryptenroll`. As soon as a volume is decrypted, initrd will write `volume-key` to PCR 15, so any further executables can no longer access the data stored in the TPM.

This is great if you only have a single disk, but if you have multiple encrypted disks that are unlocked in the initrd this way, then if you can gain control flow by faking data on the last decrypted disk you can still gain access to all the previously unlocked partitions. Of course you cannot unseal the secret from the TPM anymore.

[deleted]

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#100

Post by cesarb »

Avamander wrote: post #73
HPsquared wrote: post #68

Earlier quoted context omitted.

Most of this concern is around certain public key cryptography algorithms which depend on math problems being extremely hard to solve but could in theory be mathematically solved (decrypted without the key) with a good enough quantum computer. Disk encryption (AES etc) is symmetric and still only brute-force would work which can be made infeasible with a long enough key.

Brute-forcing symmetric encryption is a somewhat silly concept anyways, because each decryption is equally valid.

> Brute-forcing symmetric encryption is a somewhat silly concept anyways, because each decryption is equally valid.

Each decryption is equally valid as long as the key has the same size as the data. What happens, in practice, is that the key is much smaller than the data. Take a look at your filesystem, it should have hundreds or thousands of bytes of fixed information (known plaintext), or an equivalent amount of verifiable information (the filesystem structure has to make sense, and the checksums must match). That is: for a large enough filesystem (where "large enough" is probably on the order of a small floppy disk), decrypting with the wrong key will result in unrecoverable garbage which does not make sense as a filesystem.

To give an illustration: suppose all filesystems have to start with the four bytes "ABCD", and the key has 256 bits (a very common key size). If you choose a key randomly to decrypt a given cyphertext, there's only one chance in 2^32 that the decryption starts with ABCD, and if it doesn't, you know it's the wrong key. Now suppose the next four bytes have to be "EFGH", that means only one in 2^64 keys can decrypt to something which appears to be valid. It's easy to see that, once you add enough fixed bytes (or even bits), only one key, the correct one, will decrypt to something which appears to be valid.

Post reply on HN