Comment by quohort | Hacker News Reader

Comment by quohort | Hacker News Reader

Parent Full thread

1. This is interesting. So in a measured boot scenario, you wouldn't be able to boot the main OS, but it would give you access to sort of a minimal initramfs environment for debugging? It's a good idea for personal computers, like a tamper-proofing approach.

I assume the TPM in this case would only have a partial decryption key? I think something similar could be accomplished with SSS, no?

2. As for this, I can say i've never used DBX with UEFI Secure boot. Instead of revoking keys, I just remake the entire PKI from the top. The PKI is only there to support independent use by OS Vendor/OEM hence the separation of PK/KEK/db.

3. Counterpoint: over-reliance on TPMs and such. Whereas the ordinary trust chain only requires signature verification at the start of boot (presumably on-chip), measured boot requires more complex trusted computing hardware (presumably off-chip).

Personally, I find that systems that are overly-reliant on complex trusted computing hardware tend to lack in other areas. For example, iphones or google-pixel devices encourage the user to use a low-entropy password like a 4-digit PIN. These systems try often to reconcile "analog" passkeys like Biometrics (FaceID, fingerprints) by using trusted computing. Of course, if the trusted computing systems are breached (https://www.404media.co/leaked-docs-show-what-phones-cellebr...), then security is very weak.

I suppose the advantage of the measured-boot method is that it is optional. So you can still boot whatever OS you want, just without some TC features.

>1. This is interesting. So in a measured boot scenario, you wouldn't be able to boot the main OS, but it would give you access to sort of a minimal initramfs environment for debugging? It's a good idea for personal computers, like a tamper-proofing approach.

If you would like to play around with measured boot and similar functionality of TCG DICE. Thats on a USB stick that open, and have a good team behind it.

https://tillitis.se/

> 1. This is interesting. So in a measured boot scenario, you wouldn't be able to boot the main OS, but it would give you access to sort of a minimal initramfs environment for debugging? It's a good idea for personal computers, like a tamper-proofing approach.

Depends on how it's set up. Currently most setups that use measured boot (systemd-pcrlock, partially BitLocker) ask for a recovery key if unsealing fails due to measurement mismatches and offer other options.

> I assume the TPM in this case would only have a partial decryption key?

That's also possible, but so far I haven't seen that. The sealed secret is sent to the TPM which then uses its hidden internal seed to derive the master key for volume decryption and sends it back. (In the case of bitlocker with TPM < 2 that could trivially be sniffed on the LPC bus...)

> I think something similar could be accomplished with SSS, no?

If you mean Shamir's secret sharing, possibly. Question is what to do with the shares.

2. Yeah, for your local machine this is a working approach, if you make sure that really only your own key works. Another reason against PKI is also that the trusted authority can't retroactively sign a backdoored executable to gain access to devices, as the measurements are independent from authority and ideally device specific.

3. Signature verification isn't just needed at the start of boot, it's ideally from start of booting until user authentication, which is the part that can be tampered with. I'd argue that the software side for measured boot is simpler, while the hardware side may be more complex.

> For example, iphones or google-pixel devices encourage the user to use a low-entropy password like a 4-digit PIN.

Using TPM+PIN is actually not that bad: Only if measurements match it's possible to unlock with a PIN and the TPM uses a counter in nonvolatile memory to prevent brute force attacks. It's not unfathomable that some manufacturer screws that up, but it's IMO stronger than relying on multiple parties (CPU, BIOS, OEMs, OS) developing an actually secure trust chain.

Reply on news.ycombinator.com