The other option is to have an intrusion prevention switch or two in the case so the TPM locks itself in some way and the machine refuses to boot at all without some PKI attestation.
Bypassing disk encryption on systems with automatic TPM2 unlock
11–20 of 136 posts
Re: Bypassing disk encryption on systems with automatic TPM2 unlock
#12On 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.
Re: Bypassing disk encryption on systems with automatic TPM2 unlock
#13Seems 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.
Re: Bypassing disk encryption on systems with automatic TPM2 unlock
#14I 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
Between consciously encrypting with a user-supplied password, and not encrypting at all, automatic encryption seems more like a nuisance/hazard for recovery than anything else.
Consciously encrypting with a password implies an understanding of the risk of permanent loss. Leaving it unencrypted implies an understanding of the risk of disclosure. Having your drive silently encrypted feels like the worst of both worlds. "I never encrypted or locked it, what do you mean my data is encrypted and gone forever!?"
Re: Bypassing disk encryption on systems with automatic TPM2 unlock
#15I 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
[dead]
Re: Bypassing disk encryption on systems with automatic TPM2 unlock
#16I 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 don't understand why anyone would use passwordless disk encryption.
I'm using it on my home server that I'm using for self-hosting. This way, if it's stolen, the thief won't be able to easily get to my data. At the same time, I don't have to physically enter the password if my server reboots.
Re: Bypassing disk encryption on systems with automatic TPM2 unlock
#17Seems 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 how ChromeOS does it. https://m.youtube.com/watch?v=iO6cb90WiQ4
Re: Bypassing disk encryption on systems with automatic TPM2 unlock
#18Seems 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 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 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.
Re: Bypassing disk encryption on systems with automatic TPM2 unlock
#19I 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 just not practical. How are you going to manually enter the password for let's say 10 servers?
Re: Bypassing disk encryption on systems with automatic TPM2 unlock
#20The other option is to have an intrusion prevention switch or two in the case so the TPM locks itself in some way and the machine refuses to boot at all without some PKI attestation.
depends on the threat model. a rot saw will hack it :P