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

41–50 of 136 posts

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#41

Post by megous »

Hakkin wrote: post #5
_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

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.

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.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#42

Post by michaelt »

tommiegannert wrote: post #31

Very nice exploit. So if you use this PCR state machine, the problem is that the step before initrd doesn't require the correct password to move the PCR forward? It accepts any password that decrypts the next stage, which didn't have its integrity verified here. Seems there are multiple ways of solving this, and adding integrity checks is only one. It could also let the TPM verify the disk decryption password (when i…

> It could also let the TPM verify the disk decryption password (when it's needed.)

The design intent is basically:

1. The TPM is very sensitive, and errs on the side of not unlocking your disk.

Booting into recovery mode to fix a driver? Reinstalled your distro? Added a MOK so you can install the nvidia drivers? Toggled certain options in your BIOS? The expected-computer-state checksums are wrong, better not unlock the disk as it could be an attack.

2. When this happens, you key in the password instead.

You can't rely on the TPM to verify the manually entered password, as the intent of the manually entered password is to recover when the TPM is in a broken state.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#43

Post by bigfatkitten »

ARob109 wrote: post #18
yx827ha wrote: post #17

Earlier quoted context omitted.

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

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…

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.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#44

Post by prmoustache »

sedatk wrote: post #8
_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

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?

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#45

Post by prmoustache »

dangero wrote: post #7
_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

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.

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.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#46

Post by fguerraz »

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 certificates (PK, KEK, db, dbx, …) with my own and sign every kernel/initrd update, I also unlock my disks with a passphrase anyways, but I'm on the fence WRT if it's more secure than TPM.

Yes in theory TPM key extraction is feasible (and even easy if it's performed by a chip other than your CPU https://pulsesecurity.co.nz/articles/TPM-sniffing ) but it is harder than filming/watching you type the passphrase or installing a discrete key-logger ?

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#47

Post by tucnak »

dangero wrote: post #7
_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

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.

Google: IPMI, BMC

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#48

Post by prmoustache »

mcny wrote: post #4
_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

> Entering a password on boot isn't even that much work It is on fedora. I wabt the latest packages and I want to install them with dnf offline upgrade but now I need to put in password twice once for the updates d again for next boot. If it is a server, I don't want to keep a monitor attached to it just to enter the password. I want the computer to just boot. There has to be a better way.

I also use a fedora.

Typically I use offline upgrade if I mean to poweroff but otherwise I just run `sudo dnf update -y && sudo systemctl reboot` in a terminal if I want a quick update&reboot.

On another laptop I am using silverblue (well bluefin) and the atomic upgrades solve the issue completely.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#49

Post by kopirgan »

Any idea how this works in the Windows world with bitlocker? I hope it's not same vulnerability

I recently changed motherboard on my laptop, had the bitlocker key if not I was told I'll have to reinstall Windows all over again.

Even with the key, one must decrypt and re-encrypt.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#50

Post by dist-epoch »

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.

Post reply on HN