Hacker Remix

Bypassing disk encryption on systems with automatic TPM2 unlock

189 points by arjvik 1 day ago | 107 comments

staff3203 24 hours ago

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.

usr1106 20 hours ago

Yes, that seems a good extra level of defense. Allow unsealing only once. We extend a PCR with random data.

dist-epoch 19 hours ago

This is what Bitlocker does. There was a recent article about it.

oddlama 17 hours ago

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.

bean-weevil 15 hours ago

If you have tpm encryption on your boot disk, then you can simply store decryption keys for your otyer disks on it.

staff3203 10 hours ago

What to do for a single root fs spanned over 2 encrypted partitions on 2 separate disks?

rollcat 13 hours ago

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-boot-world.html

Then I read about the implementation details[0], and it's a complex bloody mess with an unending chain of brittle steps and edge cases, that are begging for a mistake and get exploited. So here we are.

I'm convinced that "measure the kernel" into "measure the initrd" into "show login screen" is all it should take.

snailmailstare 11 hours ago

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

acheong08 1 day ago

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

Hakkin 1 day ago

If a disk is encrypted, you don't have to worry about the contents if you eventually have to RMA or dispose of the disk. For this use case, it makes no difference how the encryption key is input.

tommiegannert 22 hours ago

I'd guess the most common scenario is for someone giving away the entire computer, not fiddle with components. Or theft of the full machine.

This feels like one of those half-security measures that makes it feel like you're safe, but it's mostly marketing, making you believe *this* device can be both safe and easy to use.

lukeschlather 2 hours ago

It's pretty fast to destroy all the keys in a TPM. Should take a minute if you know the right place to go. Meanwhile securely deleting a normal drive requires overwriting every sector with random data, which could take hours. So it also helps if you're giving away the whole machine.

megous 20 hours ago

Encrypted data are noise now, maybe, but may be decryptable in the future with advances in computing.

So all this depends on what you worry about.

HPsquared 16 hours ago

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.

Avamander 14 hours ago

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

cesarb 10 hours ago

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

tibordp 14 hours ago

That's only true for information theoretically secure algorithms like one-time pad. It's not true for algorithms that are more practical to use like AES.

toast0 11 hours ago

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)

cuu508 11 hours ago

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

toast0 9 hours ago

Sometimes yes, but if there's a hardware issue, I may not be able to.

Ex: the first server I had failed and they ended up replacing it with a different server with similar specs, but the drives werem't moved. In this case, the failure was gradual (resetting by itself) and as part of debugging it, I wiped the drives and installed a new OS, but towards the end, the amount of time between resets was very short, and I wouldn't have had a chance to wipe it if I had started later.

Yes, this isn't great service, but it's personal hosting and it's cheap and I get a whole (very old) machine.

gizmo 9 hours ago

Dropbear is the solution for this.

toast0 7 hours ago

Well, if the FreeBSD installer would set that up for me, I probably would have done it that way, but lazy, and I don't reboot that often.

jrockway 13 hours ago

It's always felt like the best way to lock myself out of my own machine. While I don't really keep any important data on it that's not backed up, I also don't build my workstation image from a config file or anything, so some time will be lost. The thing that's always bugged me is that before AMD had a TPM built into the CPU, the TPM was just a poorly-secured dongle hanging off the motherboard (at least with Asus motherboards) and it just seems like something that's going to break randomly. That breaks, then what. Meanwhile, the CPU owning the keys also doesn't feel great. Sometimes you swap your CPU and now there is an 800 step process to disable decryption before you do that, which is certain to be forgotten as you excitedly unpack your new CPU purchase. (Even if you're completely rebuilding the computer, the number of times I've put a new disk into a new build is approximately zero.)

Just typing a passphrase at boot seems like a pretty decent compromise. I've done it for years and it's never caused a problem.

_verandaguy 12 hours ago

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 things go pear-shaped it's not the end of the world.

Fast forward six months and my PC suddently refuses to boot; turns out the pluggable TPM thing was defective and stopped working (without any warning that got surfaced to me).

It was just my boot drive, and reinstalling windows isn't a huge hassle, but it definitely cemented my mixed feelings about passwordless FDE. Had that been the drive I use for my photo library, or my software projects, or work-related documents (tax slips, employment contracts, whatever), that would've been devastating.

It's actually made me rethink the strategy I use for my laptop's backups, and I think I'm in a better place about that now.

foepys 12 hours ago

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.

_verandaguy 10 hours ago

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.

sedatk 10 hours ago

You can add alternative Bitlocker decryption mechanisms including a strong password using manage-bde CLI tool. Also, Bitlocker gives you the opportunity to save your recovery data externally in case you lose all your authentication mechanisms. I'm surprised that you lost your data.

vladvasiliu 13 hours ago

I sympathize with your points, especially rebuilding the box from scratch.

But all the “passwordless” schemes I’ve seen support at least an additional “master key” which you can type in.

So if you’re ok with the security tradeoffs of passwordless tpm, it’s only an added convenience on top of your approach.

dangero 1 day ago

Depends on the use case. If boot requires a password, the computer can never lose power or be rebooted without human presence. That’s not always practical.

teddyh 16 hours ago

You can reboot your full-disk-encryption server while you sleep. Obligatory plug: <https://www.recompile.se/mandos>

Disclosure: I am a co-author of Mandos.

prennert 16 hours ago

Has this solution been audited? In particular, is it safe to replay attacks by actors listening in to the network traffic?

Also from the diagram it looks like the secret key is stored unencrypted on the server, or do I read it wrong?

teddyh 14 hours ago

> Has this solution been audited?

Only insofar as everybody that I’ve asked over the years has failed to find anything wrong with it. But no formal verification has been done.

> In particular, is it safe to replay attacks by actors listening in to the network traffic?

Yes, it is safe, since we make sure to only use TLS with PFS.

> Also from the diagram it looks like the secret key is stored unencrypted on the server, or do I read it wrong?

No, the secret is stored encrypted on the server, encrypted with a key which only the client ever has.

For more information, see the introduction and FAQ: <https://www.recompile.se/mandos/man/intro.8mandos>

gerdesj 13 hours ago

Thank you for this. I will almost certainly be deploying that.

prmoustache 20 hours ago

That is what remote kvm are for and if you do that on commodity hardware you can start a tiny ssh server starting up from an initrd. Having said that an attacker with local access could change the initrd without your knowledge so that it logs the password you enter so it is not necessarily the most secure solution.

deno 18 hours ago

You’ve answered it yourself. Without TPM you have no idea if you can provide the secret to the system or if it’s compromised. Whether that secret comes from TPM or network is secondary.

tucnak 20 hours ago

Google: IPMI, BMC

ARob109 24 hours ago

Seems like this could be easily mitigated with a read only root filesystem using dm verity

Store the root hash of the dm verity formatted rootfs in the PCR. If a malicious partition is presented to initrd, its root hash will not match the trusted one stored in the TPM.

Or if you need a writeable rootfs, use fs verity and store the signature of init into the PCR. The trusted init signature won’t match signature of malicious init.

LUKS for encryption and verity for integrity/verification.

ChocolateGod 16 hours ago

> If a malicious partition is presented to initrd

The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.

I know Fedora has been musing with shipping prebuilt initrds, but it raises problems with things like Nvidia where you need the driver to be in the initramfs to have a proper boot screen. There's also UKIs that have the kernel + initramfs in the same EFI binary (and thus signed) for booting by secure boot, but they can become too big for the small EFI partition computers ship with.

blucaz 14 hours ago

> The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.

It is not. There are other, very real and very important problems with that fact and reasons why it should be fixed, but this is not it. The point of SecureBoot is to protect the firmware from userspace. It works very well for that purpose, as evidenced by the facts that exploits to bypass it have to continuosly be found.

oneplane 15 hours ago

That's similar to how Apple does it. The base system is signed (and has a tree of signatures so you don't need to strictly re-calculate the entire RO volume your base OS sits on), and the signature is recorded in the boot configuration.

Granted, you could disable that, but they have thought of that too, you can only disable it from a recovery OS that is signed the same way. But disabling that doesn't disable it for the recovery OS, so you can't evil maid the recovery OS later to make it appear as if it is still enabled.

yx827ha 24 hours ago

That's how ChromeOS does it. https://m.youtube.com/watch?v=iO6cb90WiQ4

ARob109 23 hours ago

Android too in a way via Android Verified Boot. I think ChromeOS uses AVB as well.

Android Verified Boot extends the System on chip Hardware based secure boot to the kernel and rootfs. Root of trust is fused into the SoC, and second stage bootloaders are signed. Second stage boot loader eg uboot,UEFI/edk2 contains a public key that is used to verify a signed AVB partition. This signed partition contains signed rootfs dm verity metadata and signed hash of the kernel(+initrd). AVB validates kernel hash with expected hash and loads kernel if good. It provides the trusted rootfs verity hash to kernel via cmdline. Then when kernel reads rootfs, the dmverity system will calculate hash and check if matches the expected one. If not, the system reboots and the AVB metadata is flagged to indicate tampering/failure of the rootfs.

edit to add: If the SoC supports hardware based full disk encryption, the filesystem can be encrypted as well, with the key being stored in Androids secure key store. Android though has moved away from FDE in favor of file based encryption.

bigfatkitten 20 hours ago

The ingredients are there as Chrome OS and Android have shown, but robust hardware-bound disk encryption has just never been a priority for the general purpose distros.

highwaylights 18 hours ago

I’m not sure if this is the exact process for openSUSE Aeon, but it’s very close philosophically so I image the rest is a question of hardening this over time.