On Thu, May 30, 2024 at 11:22:56PM +0200, Lennart Poettering wrote: > On Do, 30.05.24 22:43, Lennart Poettering (lennart@xxxxxxxxxxxxxx) wrote: > > > > 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) > > Eh, I might have figured out a way how I can do this, somewhat > inspired by this: > > TPMs implement hierarchies of keys after all where each key is wrapped > by its parent, and you can apparently nest things pretty liberally, to > as many levels as one likes. > > So here's what systemd's TPM2-based FDE does right now: > > When enrolling: it ensures that a "storage root key" (SRK) exists on > the TPM. It then loads the plaintext FDE encryption key as a symmetric > key into the TPM, so that it is "wrapped" by the SRK. It then reads > back the wrapped (i.e. encrypted) key (this is called "sealing") and > writes that to the LUKS superblock. When unlocking we take that > wrapped key, load it back into the TPM and then read back the > plaintext key (this is called "unsealing"). Since the SRK is specific > to the TPM only the TPM can give us access to our FDE key. This model > is then enriched with TPM2 "extended policies" which we set while > sealing and which tell the TPM to insist that during unsealing the > PCRs are in a specific state. > > So much so good. This allows us to define *one* extended policy for the > FDE key. And as mentioned that's a problem for us, because we'd like > to define *two* extended policies (i.e. the pcrlock one, and the > signed PCR one). But if we take benefit of the fact we can wrap keys > arbitrarily we can do it like this: > > when enrolling: as before, take care of the SRK. But now generate > another key, wrapped by the SRK and with our first policy built into > it. And then seal the FDE key against that "intermediate" key, and > build our 2nd policy into that sealing. > > To unlock we then first have to load the intermediate key (which will > just work) and then load the FDE key below it (which will require us > to fulfill policy 1) and then the unseal the FDE key (which will > require us to fulfill policy 2). > > Unless I am missing something this should work and do exactly what I > want: I can combine policies arbitrarily. Does this require policies 1 and 2 to be fulfilled _at the same time_? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
