On 7/6/2021 8:57 AM, Jan Kiszka wrote:
On 04.07.21 11:03, Cedric Hombourger wrote:
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
They use SecureBoot to make sure you only boot something they have signed
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)
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
In their case, they seem to suspend BitLocker when they apply firmware
updates
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.
Once we have our LUKS volumes mounted, we also poisoned PCRs that were
used to seal our secret
Does that help?
We can certainly have a discussion if more clarifications are needed or
if you feel we could achieve something somewhat similar by some other means
Cedric
Jan
--
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/5e00f908-b57d-3fbb-3ffd-3fe3222cc641%40mentor.com.
