Hi Cedric, > > > Our concept is twofold: (1) use SecureBoot to make sure we are booted > > > from a trusted boot-loader + trusted Linux kernel (both are signed with > > > keys loaded into the trust store) (2) extend the root of trust by > > > mounting a LUKS encrypted volume with the key in the TPM and sealed with > > > selected PCRs. In an A/B scheme, we may have the same encryption key > > > placed both in slot[A] and slot[B] but sealed as follows: > > I do get the point of using measurements to keep the platform open for > > non-secure boots but protect the secretes to define boot chains. But I > > do not get the use case of booting only well-defined secure images and > > then additionally measuring them on top to unlock secrets. What's the > > added value? The downside is the need to maintain the measuring values > > in addition, right? > > Our concept is kind of similar to Microsoft's BitLocker
Note that this is however primarily targeted to machines having an HMI where a human operator can jump in and interactively click on buttons to recover the machine in case of failure. This is probably not what one can expect from (deeply) embedded systems having more qualified robustness requirements... Either way, the concept needs to match the intended use case. > They use SecureBoot to make sure you only boot something they have signed ... which is the same purpose we're using Secure Boot for, so far so aligned :) > They use MeasuredBoot and place all measurements of their boot components into > PCR[7] where the BitLocker key is sealed against PCR[7] > (they don't seem to bother tracking which boot component was tampered since a > single PCR is used while they most likely have multiple boot components) They are then apparently anchoring it all to Secure Boot and Secure Boot's PCR #7: If Secure Boot (or related measurements) gets compromised / changed (even by intention), then no disk unlock will happen and hence no Windows OS would be booted ― until the re-seal disk unlock secret operation, that is. > See > https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/trusted-execution-environment-efi-protocol > and > https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-bitlocker Quote: "Suspend BitLocker (required for devices bound to PCR[07] only if the firmware update changes the Secure Boot policy)." > In their case, they seem to suspend BitLocker when they apply firmware updates They consequently have to since any change related to Secure Boot or its related measurements such as, e.g., a Windows Bootloader or Kernel update requires a re-sealing ― either prior to rebooting or after the fact by human consent. Otherwise, the machine naturally doesn't boot. > In our case, we have an A/B scheme and use different non-volatile slots in the > TPM for each system (A/B) to store our encryption key. We have them sealed > against PCR measurements of their respective boot components. Which means you have to update them while any firmware update transaction prior to the due reboot into the new firmware plus handling any rollback logics in the initramfs, right? It's a direct port of Microsoft's BitLocker to an A/B deployment, isn't it? > Does that help? Yes, but I'm with Jan here, in particular regarding maintaining the measuring values, quoting: > > But I do not get the use case of booting only well-defined secure > > images and then additionally measuring them on top to unlock > > secrets. What's the added value? The downside is the need to > > maintain the measuring values in addition, right? Kind regards, Christian -- Dr. Christian Storm Siemens AG, Technology, T RDA IOT SES-DE Otto-Hahn-Ring 6, 81739 München, Germany -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/20210719140227.3rwrca35lilshoh5%40MD1ZFJVC.ad001.siemens.net.
