2

The man page for tpm2_load has the following example:

To load an object you first must create an object under a primary object. So the first step is to create the primary object.

tpm2_createprimary -c primary.ctx

Step 2 is to create an object under the primary object.

tpm2_create -C primary.ctx -u key.pub -r key.priv

What exactly is the primary.ctx file that is created by tpm2_createprimary and used by tpm2_create? The man page for tpm2_createprimary calls it the "object context":

-c, --key-context=FILE:

The file path to save the object context of the generated primary object.

And I can get some information about the file's contents with tpm2_print -t TPMS_CONTEXT primary.ctx:

version: 1
hierarchy: owner
handle: 0x80000000 (2147483648)
sequence: 128
contextBlob:
        size: 1506

But I still don't understand what I'm looking at. What is this "object context" file and why is it necessary?

Alex Henrie
  • 715
  • 1
  • 8
  • 13

1 Answers1

1

I am looking into this at the moment too and my understanding so far is that a 'context' is essentially some encrypted form of the object, or information that the TPM (and only the TPM) can use to re-derive that object back in the protected hardware space of the TPM.

The need for them seems to stem from the fact that the TPM has an extremely minimal amount of working RAM/memory on it, and so any operation you want to do with the TPM that involves certain objects will probably require those objects to be re-loaded back into the TPM at the point in time you want to do the operation. For example, it does not seem uncommon for TPMs to only support having three or so objects actually loaded at any one point in time.

Storing whole unencrypted keys in files outside the TPM would defeat some of the purpose of the TPM because then cryptographic operations with those keys could be performed outside the TPM, beyond its ability to enforce any authentication policies on the operations such that they can only be performed with e.g. the right password. So this seems to be why these object context files themselves contain encrypted data that only the TPM can decrypt.

I'm still not 100% sure if I've got this all right - will update this answer if I am able to get to any clearer of a conclusion here.

Some references:

Part 1 of the TPM 2.0 Library Specification defines a context as follows:

4.17 context

collection of data that provides qualifying information about a data object to differentiate it from others of the same type or to differentiate one version of a data object from another

The 'A Practical Guide to TPM 2.0' Book (free download, CC BY-NC license) says the following:

chapter 18, pg 294

Because the TPM has limited internal memory, objects, sessions, and sequences need to be dynamically swapped in and out of memory. As an example, the reference implementation of a TPM 2.0 implemented by the Microsoft simulator only allows room for three object slots. An object slot is internal TPM memory for an object or sequence. There are also three session slots.

pg 295:

TPM2_ContextSave saves the context of a transient entity and returns the entity’s context. The returned context is encrypted and integrity protected. This is done in a manner that only allows the context to be loaded on the exact same TPM that saved it; a saved context can’t be loaded into a different TPM.

nuclearpidgeon
  • 121
  • 3