5 ms·

What I don’t understand is, how did that not completely nullify the security promises of SecureBoot, rendering the whole exercise pointless in the end ?

wmf 6y ago
Insecure shims can be revoked. https://blogs.gnome.org/hughsie/2020/08/17/updating-secure-boot-dbx-with-fwupd-and-the-lvfs/ https://blogs.gnome.org/hughsie/2020/08/17/updating-secure-b...
- deleted 6y ago
  [deleted]
voxic11 6y ago
Because the shim is still secure. > Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.
monoideism 6y ago
Because each stage of the boot sequence is still verified: - the root of trust is in the TPM - by default, the initial shim stage is verified using a Microsoft cert in the native trust database, and after the shim (which has an embedded Canonical cert) loads grub, then it verifies and loads the kennel Grub also has its own trust store it can use, if I recall.
- mjg59 6y ago
  The root of trust is not in the TPM, it's in the system firmware. On Intel, the firmware itself is verified by the Management Engine. Measurements of these roots of trust may be passed to the TPM, but the TPM isn't in a position to do much with that information other than report it back at a later point in time - otherwise firmware updates would invalidate your root of trust.
  - monoideism 6y ago
    OK, I probably should have just left this as a "cryptographic co-processor" rather than TPM (or else used "a TPM"). But I believe there is some blurring here: - My understanding is that the secure boot cryptographic root of trust for Intel is in the PTT, which is essentially a software-implemented TPM with some extra features (so right, "system firmware"). It's true that PTT is part of the ME. But it's still a firmware-based TPM. - With AMD, they use a cryptographic coprocessor whose name I forget but which is similar to PTT and which contains either a hardware or firmware-based TPM. - With ARM, I'm pretty sure they use TrustZone, which is analogous to a TPM. But yes, I should have been clearer.
    - mjg59 6y ago
      > My understanding is that the secure boot cryptographic root of trust for Intel is in the PTT No. The public keys used for verifying secure boot payloads are in the system firmware and are validated on the CPU. If you have a feature like Boot Guard enabled then the Management Engine will verify the firmware bootblock with a key that's flashed into the chipset, but that's not required by the UEFI spec and has nothing to do with PTT. Under no circumstances is the TPM used. On ARM the initial firmware validation will be carried out by the SoC, but there's no TrustZone involved.
      - monoideism 6y ago
        Well, that's how Intel describes for 4th gen, and I had assumed more recent gens: "Intel Platform Protection Technology with Bootguard works with Intel PTT..." on page 8. They mention both Windows and boot protection. How does it work with Bootguard? Does that mean bootguard bootstraps PTT trust? Have a look: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/security-technologies-4th-gen-core-retail-paper.pdf https://www.intel.com/content/dam/www/public/us/en/documents... If you have more recent documentation, I'd be interested. It's hard to learn about this semi-internal Intel and AMD stuff. Edit: Also, you write "with a key that's flashed into the chipset". Do you mean chipset (which could be on the motherboard) or on the CPU itself? Where do you find this information?

wmf 6y ago

Insecure shims can be revoked. https://blogs.gnome.org/hughsie/2020/08/17/updating-secure-boot-dbx-with-fwupd-and-the-lvfs/ https://blogs.gnome.org/hughsie/2020/08/17/updating-secure-b...

deleted 6y ago
[deleted]

voxic11 6y ago

Because the shim is still secure. > Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.

monoideism 6y ago

Because each stage of the boot sequence is still verified: - the root of trust is in the TPM - by default, the initial shim stage is verified using a Microsoft cert in the native trust database, and after the shim (which has an embedded Canonical cert) loads grub, then it verifies and loads the kennel Grub also has its own trust store it can use, if I recall.

mjg59 6y ago
The root of trust is not in the TPM, it's in the system firmware. On Intel, the firmware itself is verified by the Management Engine. Measurements of these roots of trust may be passed to the TPM, but the TPM isn't in a position to do much with that information other than report it back at a later point in time - otherwise firmware updates would invalidate your root of trust.
- monoideism 6y ago
  OK, I probably should have just left this as a "cryptographic co-processor" rather than TPM (or else used "a TPM"). But I believe there is some blurring here: - My understanding is that the secure boot cryptographic root of trust for Intel is in the PTT, which is essentially a software-implemented TPM with some extra features (so right, "system firmware"). It's true that PTT is part of the ME. But it's still a firmware-based TPM. - With AMD, they use a cryptographic coprocessor whose name I forget but which is similar to PTT and which contains either a hardware or firmware-based TPM. - With ARM, I'm pretty sure they use TrustZone, which is analogous to a TPM. But yes, I should have been clearer.
  - mjg59 6y ago
    > My understanding is that the secure boot cryptographic root of trust for Intel is in the PTT No. The public keys used for verifying secure boot payloads are in the system firmware and are validated on the CPU. If you have a feature like Boot Guard enabled then the Management Engine will verify the firmware bootblock with a key that's flashed into the chipset, but that's not required by the UEFI spec and has nothing to do with PTT. Under no circumstances is the TPM used. On ARM the initial firmware validation will be carried out by the SoC, but there's no TrustZone involved.
    - monoideism 6y ago
      Well, that's how Intel describes for 4th gen, and I had assumed more recent gens: "Intel Platform Protection Technology with Bootguard works with Intel PTT..." on page 8. They mention both Windows and boot protection. How does it work with Bootguard? Does that mean bootguard bootstraps PTT trust? Have a look: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/security-technologies-4th-gen-core-retail-paper.pdf https://www.intel.com/content/dam/www/public/us/en/documents... If you have more recent documentation, I'd be interested. It's hard to learn about this semi-internal Intel and AMD stuff. Edit: Also, you write "with a key that's flashed into the chipset". Do you mean chipset (which could be on the motherboard) or on the CPU itself? Where do you find this information?