On Thu, May 30, 2024 at 10:43:48PM +0200, Lennart Poettering wrote: > On Mi, 29.05.24 14:48, Demi Marie Obenour (demi@xxxxxxxxxxxxxxxxxxxxxx) wrote: > > > > > > (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. > > Hmm, this is an interesting idea, I kinda like it. But I am not sure > how far this will get us, because I think even for FDE we eventually > want to store asymmetric keys, not symmetric ones (i.e. I think we > should start supporting things like TPM2+FIDO or TPM2+PKCS11 or > TPM2+ssh-agent where both devices operate in tandem, in a challenge > response model, not sure how far you get with that if we can only > protect symmetric keys) How would TPM2+FIDO work? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
