7

I am interested in 'adding' preexisting keys to a TPM's storage hierarchy.

An example of a desired key hierarchy can be shown as:

(SRK)----->(User Storage Key)-------> User Working Key 1
                             |
                             |------> User Working Key 2
                             |
                             |------> User Working Key 3

Where:

  • SRK is the storage root key created and managed by TPM administrator
  • User Storage Key is created as a (public, private) key pair outside TPM. For example by using the OpenSSL command line tools.
  • User Working Keys are also created outside TPM using OpenSSL.

How can I insert "User Storage Key" and "User Working Keys" in the above hierarchy?

The TPM allows me to create (public, private) key pairs internally inside TPM (and to export public key along with a (wrapped form of) private key thereof). But it is not clear to me if TPM commands like TPM_CreateWrapKey and TPM_LoadKey2 allow this option.

This is warranted by situations where user's signing/encryption keys are already created elsewhere and we are interested in using the TPM as a secure repository of keys on the operating platform. (Binding/sealing to create opaque data inside TPM is not useful here, since bound/sealed data is incapable of extending the key hierarchy).

4
  • The TPM is not a key repository. The key hierarchy is stored entirely on the hard-disk or other main media, and managed entirely by the TPM software stack (TSS) you have installed. So, you are really just using the TSS, i.e. TrouSerS. In this case, you might as well leverage other key management software. May 2, 2016 at 23:43
  • Just for interest, I tried to force keys to remain in the TPM by creating "owner evict" keys. I found that the TPM had room for <5 keys before it complained, thus demonstrating that it really isn't a very good repository. May 2, 2016 at 23:45
  • 1
    True that the secure NVRAM in TPM hardware has very limited storage for storing persistent secrets. The original question was about bring keys originally not created in the TPM to the TPM's storage hierarchy. Understandably, they will be stored in encrypted format on the hard drive when the TPM is not in active state & the relevant subtree of the key hierarchy is not loaded.
    – user13311
    Jan 25, 2018 at 19:51
  • This should be possible since you can migrate some keys from one TPM to another. Encode the keys in the same way a TPM would export them for migration, then make the TPM import them. Nov 24, 2022 at 22:09

2 Answers 2

1

I wouldn't have thought this was a good idea. The TPM can only provide "trust" for keys that were created within the TPM. Otherwise, who knows what happened to the keys before they were added to the TPM? If the private key ever exists outside the TPM, all bets are off.

2
  • 1
    Assume that the external key to be imported to TPM is previously administered in a secure key server or an HSM.
    – user13311
    Jan 25, 2018 at 19:52
  • 4
    @user13311 Can you guarantee that they were never intercepted during transmission? That while being held in RAM before being copied over they weren't stolen? etc. -- The point is that the TPM can only guarantee security within itself. So long as you realize it can't reach into the past and retroactively secure keys, then no, it's not a problem, but that's such an incredibly rare case with such a massive possibility for misuse that I'd be surprised if it was available.
    – anon
    Jul 12, 2019 at 18:59
0

In the TPM specifications, an SRS key is a public-private key pair, the private key is kept inside the TPM and the public segment is available to wrap working keys. SRS keys are used as the proxy for the EK key in all transactions outside of the TPM, with only the public segment being used outside of it.

Thats whats in the docs. Now, how vendor's implement it is another thing, TPM implementations are so convoluted I leave it for the vendor to consolidate and automate. However, it does assist in overall security, by obscurity.

https://lwn.net/Articles/768419/

I do not know if the TPM owner can alter Storage Keys directly which wrap working keys or its done automatically. Suffice to say, creating 'working keys' wrap the key in a storage key that is under TPM control.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .