On Mon, May 13, 2024 at 11:33 PM James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 2024-05-13 at 18:09 +0100, Ignat Korchagin wrote: > [...] > > TPM derived keys attempt to address the above use cases by allowing > > applications to deterministically derive unique cryptographic keys > > for their own purposes directly from the TPM seed in the owner > > hierarchy. The idea is that when an application requests a new key, > > instead of generating a random key and wrapping it with the TPM, the > > implementation generates a key via KDF(hierarchy seed, application > > specific info). Therefore, the resulting keys will always be > > cryptographically bound to the application itself and the device they > > were generated on. > > So I think what confuses me is what the expected cryptographic secrecy > properties of the derived keys are. I get they're a KDF of seed and > deterministic properties, but if those mixing values are well known (as > the path or binary checksum cases) then anyone with access to the TPM > can derive the key from user space because they can easily obtain the > mixing parameters and there's no protection to the TPM keyed hash > operation. > > Consider the use case where two users are using derived keys on the > same system (so same TPM). Assuming they use them to protect sensitive > information, what prevents user1 from simply deriving user2's key and > getting the information, or am I missing the point of this? You are correct: it is possible, but in practice it would be limited only to privileged users/applications. I remember there was a push to set a 666 mask for the TPM device file, but it is not how it is done today by default. Also I think the same applies to trusted keys as well, at least without any additional authorizations or PCR restrictions on the blob (I remember I could manually unwrap a trusted key blob in userspace as root). It would be fixed if we could limit access to some TPM ops only from the kernel, but I remember from one of your presentations that it is generally a hard problem and that some solution was in the works (was it based on limiting access to a resettable PCR?). I'm happy to consider adopting it here as well somehow. > James >
