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

51–60 of 136 posts

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#51

Post by michaelt »

_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

Imagine a big corporate workplace, where the infosec team wasn't comprised of freewheeling anarchic hacker types who've dedicated their career to mastering the intricacies of the Linux boot process, but instead by compliance folks who've dedicated their career to mastering the intricacies of global privacy laws and passing SOC2 compliance audits.

From their perspective, "Secure Boot" has the word "Secure" right in the name. And they've looked up details about the TPM - Microsoft says the TPM avoids systems being tampered with, and addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned devices.

If you don't know the intricacies involved, that stuff all sounds great! So they put a line into the corporate IT policy that TPM use is mandatory.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#52

Post by dist-epoch »

usr1106 wrote: post #40
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.

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

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

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#53

Post by dist-epoch »

saljam wrote: post #34
keeperofdakeys wrote: post #10

You can mitigate this by including PCRs that sign the kernel and initrd, however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros. Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decry…

> You can mitigate this by including PCRs that sign the kernel and initrd nope! the trick the article is describing works even if the kernel and initrd is measured. it uses the same kernel, initrd, and command line. the reason this trick works is that initrds usually fall back to password unlock if the key from the tpm doesn't work. so the hack replaces the encrypted volume, not the kernel, with a compromised one. th…

> 3. the automated tpm unlock fails, prompting for a password.

> 4. type in our password.

In a serious security conscious setup this should be a big red flag to investigate. Any unexpected boot password prompt.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#54

Post by dist-epoch »

kopirgan wrote: post #49

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.

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

That's not true, the unlock key will be regenerated, but the disk contents will not be re-encrypted, because it's encrypted with another immutable key.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#55

Post by kopirgan »

dist-epoch wrote: post #54
kopirgan wrote: post #49

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.

> Even with the key, one must decrypt and re-encrypt. That's not true, the unlock key will be regenerated, but the disk contents will not be re-encrypted, because it's encrypted with another immutable key.

Thanks may be I didn't know the exact steps. It kept prompting key at every startup until I disabled and re-enabled bitlocker.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#57

Post by highwaylights »

mateusz834 wrote: post #56

Personally i would like a way to use TMP2 (with PIN) + password. (i.e. mode where PIN is derived from the password, but is also used to encrypt), so that i do not have to trust the TPM manufacturer.

This can be done. Not sure how on Windows/bitlocker but certainly with cryptenroll. Essentially you’d wrap this in your bootscript, though.

So password (or pin) encrypts passphrase, passphrase encrypts LUKS and goes to TPM, then you need to reverse the process for your init script (request password, decrypt passphrase, exchange with TPM to decrypt LUKS), but it depends on your appetite for planning that out.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#58

Post by highwaylights »

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…

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.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#59

Post by saljam »

dist-epoch wrote: post #53
saljam wrote: post #34

Earlier quoted context omitted.

> You can mitigate this by including PCRs that sign the kernel and initrd nope! the trick the article is describing works even if the kernel and initrd is measured. it uses the same kernel, initrd, and command line. the reason this trick works is that initrds usually fall back to password unlock if the key from the tpm doesn't work. so the hack replaces the encrypted volume, not the kernel, with a compromised one. th…

> 3. the automated tpm unlock fails, prompting for a password. > 4. type in our password. In a serious security conscious setup this should be a big red flag to investigate. Any unexpected boot password prompt.

yes of course - but in this case the "unexpected" prompt is presented to the attacker, not the user.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#60

Post by mateusz834 »

highwaylights wrote: post #57
mateusz834 wrote: post #56

Personally i would like a way to use TMP2 (with PIN) + password. (i.e. mode where PIN is derived from the password, but is also used to encrypt), so that i do not have to trust the TPM manufacturer.

This can be done. Not sure how on Windows/bitlocker but certainly with cryptenroll. Essentially you’d wrap this in your bootscript, though. So password (or pin) encrypts passphrase, passphrase encrypts LUKS and goes to TPM, then you need to reverse the process for your init script (request password, decrypt passphrase, exchange with TPM to decrypt LUKS), but it depends on your appetite for planning that out.

Wouldn't this work with some kind of PKDF instead?

Like: Password ---> PKDF ---> PIN

And then Password XOR (Key from TPM) -> LUKS

But i guess this kind of logic is not for a bootscript, but for tools like systemcd-cryptenroll.

Post reply on HN