On Wed, May 29, 2024 at 04:54:13PM +0200, Lennart Poettering wrote: > On Mi, 29.05.24 17:00, Andrei Borzenkov (arvidjaar@xxxxxxxxx) wrote: > > > If you use pcrlock for more flexibility it will change into > > > > PolicyPCR(PCR1, PCR2, ...) > > PolicyAuthorize > > PolicyPCR(PCR3, PCR4, ...) > > PolicyOR(digest1, digest2, ...) > > PolicyAuthorizeNV > > Unseal > > When you do this then the policy made up of the three expressions in > the middle would have to be stored in the nvindex. Which you > definitely can do, and this is exactly what I discussed below, see > below: > > > > (you can of course include PolicyAuthorizeNV in the policy you sign > > > for PolicyAuthorize, but that doesn#t work, since we want to pin the > > > local nvindex really, and allocate it localy, and the signer (i.e. the > > > OS vendor) cannot possibly do that. Or you could include the > > > PolicyAuthorize in the policy you store in the nvindex for > > > PolicyAuthorizeNV use, but that feels much less interesting since it > > > means the enforcement of the combination is subject to local, > > > delegated policy choices instead of mandated by the policy of the > > > actual object we want to protect) > > this here is where i discuss what you are saying ^^^ > > so technically this works, but this means objects are effectively > protected by local policy only. And whether to also protect by OS vendor > policy is then a choice of the local policy, but not a choice of the > original object's policy anymore. Or in other words: that shifts > around who owns which part of the policy. Ideally we want that when I > create a protected object in the TPM I can say: "to unlock this you > *must* validate OS vendor policy *and* local pcrlock policy". But you > cannot do that. You can only say "to unlick this you *must* validate > local pcrlock policy", and then hope that that local policy also > enforces validation via OS vendor policy. What about combining two different secrets, such that _both_ must be accessible? At a minimum, something like HASH(SECRET1||SECRET2) is guaranteed to be available if and only if both SECRET1 and SECRET2 are available. This won't work with TPM-bound keys that are not accessible outside the TPM, but my understanding is that the most common cases (LUKS and fscrypt keys and systemd credentials) must be accessible in cleartext on the host _anyway_. If the secret to be sealed is provided externally, then one can use symmetric encryption with a randomly generated key to have the same effect. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
