[Vogtinator]

Measured boot > trust chain through signature verification:

With measured boot, components in the boot chain tell some trusted component (e.g. a TPM, possibly in FW) about all of their input and only if the hashes at the end match, $something is accessible (in most cases a secret key for data decryption).

1. More flexibility (with TPM e.g. you can "seal" a secret against different parts independently)

2. No need for PKI, which gets very complex once revocations are involved (have fun looking at the "Secure Boot" DBX lists and the shim SBAT mechanism)

3. More freedom: The system still boots if the measurements don't match, you just don't get access to secrets. You're free to seal your own secrets against your new measurements and whoever did the last sealing has no access anymore. (Unlike on PCs where the Microsoft trust is in most cases not removable).

[quohort]

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.

[thewanderer1983]

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

[Vogtinator]

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

[Arnavion]

That said, it does require more care when you do OS updates or UEFI updates to remember to update the TPM sealed secret with the new measurements. Windows and Linux both have the former automated so it should generally be fine.

UEFI updates can also be a problem if they wipe the TPM as part of the update and thus destroy the sealed secret entirely (as my PC mobo does).

[Vogtinator]

> That said, it does require more care when you do OS updates or UEFI updates to remember to update the TPM sealed secret with the new measurements. Windows and Linux both have the former automated so it should generally be fine.

Yep, this can be a pain also in regards to firmware bugs (broken TCG event log anyone?). In the worst case you need to enter the recovery key or if you know in advance, exclude some component from measurement temporarily while supervising the next boot. If something goes wrong with the trust chain like a key got revoked but the bootloader didn't update correctly, you end up with an unbootable device and can't even go back easily.

> UEFI updates can also be a problem if they wipe the TPM as part of the update and thus destroy the sealed secret entirely (as my PC mobo does).

Ouch, that's bad design. The firmware is measured into the TPM on boot so there's no reason to do that..

[Arnavion]

Yeah, every time I update the UEFI it pops up a warning that the TPM will be cleared and I better have disabled Windows Bootlocker before I did this. The warning also goes away within a fraction of a second because the PC reboots which is not nearly enough time to read it, and I only know what it says because I've updated the UEFI enough times to be able to piece it together. Weird.

It might just be a warning to cover their asses; ie it doesn't actually clear the TPM but they don't want to be responsible for your un-unlockable drive in case it does. I don't actually use the TPM for measured boot or anything else so I haven't checked.

In any case, UEFI updates are relatively common right now (once every couple of months or so) because it's a relatively new mobo (AM5), and because AMD is about to release new CPUs that requires corresponding AGESA etc updates. It'll probably become less frequent in a few years.

[evanjrowley]

It appears Apple Silicon uses a combination of measured boot and trusted boot concepts: https://support.apple.com/guide/security/boot-process-secac7...

[dathinab]

Without a trust chain measured boot is security wise meaningless and doesn't work.

But you don't need any fancy PKI or vendor certificates for a trust chain, local trust is good enough.

I.e. the problem of secure boot isn't that it has a secured boot chain but how it has one.

Either way measured boot is still a nice think to complement a secure boot chain.