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

71–80 of 136 posts

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#71

Post by oneplane »

ARob109 wrote: post #13

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 mal…

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.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#73

Post by Avamander »

HPsquared wrote: post #68
megous wrote: post #41

Earlier quoted context omitted.

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.

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.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#74

Post by tibordp »

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.

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.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#75

Post by blucaz »

ChocolateGod wrote: post #66
ARob109 wrote: post #13

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 mal…

> 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 t…

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

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#76

Post by teddyh »

prennert wrote: post #69
teddyh wrote: post #65

Earlier quoted context omitted.

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.

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?

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

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#77

Post by jrockway »

_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

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.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#78

Post by jakogut »

dist-epoch wrote: post #50
fguerraz wrote: post #46

The "mitigation" itself is still not very safe if you're paranoid about governments or very motivated organisations. The extra step of checking PCR12 is performed by the initrd that you trust because it's signed by a private key that has probably leaked to every serious hacking corp / government. They can just boot their own signed initrd and kindly ask the TPM that will oblige. I personally replace the firmware cert…

> sign every kernel/initrd update If you believe that the those SecureBoot private keys were leaked, why not also believe that the linux kernel signing keys were also leaked and that you are downloading a backdoored one.

It's quite easy to generate your own signing keys which you use to sign a kernel you've built yourself.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#79

Post by [deleted] »

teddyh wrote: post #76
prennert wrote: post #69

Earlier quoted context omitted.

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?

> 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,…

[deleted]

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#80

Post by rollcat »

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.

Post reply on HN