TPM as secure key store

[Anonymous Sender]

Thought I'd say something about how the TPM chip is used for secure
storage.  It works a little differently than many people think.

Unlike a smart card, the TPM chip does not generally store user keys.
Although it can generate and hold keys, it normally unloads them after
use.  Most of the time it only holds two keys.  One is the Endorsement
Key, which is used for the controversial remote attestation feature and
is not discussed here.  The other is the Storage Root Key or SRK and is
the basis for its secure storage.

The SRK is a 2048 bit RSA key generated on-chip and normally stored
there unchanged for the lifetime of use.  It can however be cleared and
re-generated by the chip owner at any time.  The SRK private part never
leaves the chip.

New storage keys for the TPM can be created in two ways.  One is to
generate them outside the chip in software, and then to load them into
the chip for use.  The other is to generate them on-chip and then to
unload them until they need to be used.

When unloaded and stored off-chip, keys are encrypted to parent keys.
All these storage keys form a tree rooted at the SRK.  How the tree is
organized, its depth and breadth, is up to the software.

Keys are encrypted to their parents in an interesting and clever manner.
Since all keys are 2048 bit RSA keys it may seem impossible to encrypt
one to another, especially since OAEP mode is used, but the TPM gets
around this.

Public keys are freely exported from the chip and are assumed to be
available.  The private part of an RSA key consists of the primes p and q
such that p*q = n, the RSA modulus.  What the TPM does is to encrypt p,
one of the primes, to the parent RSA key.  It also encrypts a hash of
the public part.  This is what is exported from the chip and stored for
later use.

As a specific example, imagine generating a user RSA key on-chip and
making it a child of the SRK.  The RSA key is generated and then when it
is exported, its prime p is encrypted to the SRK, along with the hash
of the public part of the new user key.  This encrypted data, plus the
public part, is stored as an off-chip representation of the user key.

When it is time to later use such a key, it is loaded into the chip.
The SRK is used to decrypt the encrypted portion, which lets it recover
the prime p.  It also receives the public part, which it hashes and
compares with the corresponding encrypted hash.  With p and n it can
derive q, and then from the public exponent e it can derive the decryption
exponent d.  In this way it recovers the whole private key in the format
that was generated on-chip.

Keys can be set to require authentication or be no-auth.  Authentication
keys require a 20-byte value, generally a hash of a passphrase, to
accompany the key when it is used.  When a key is loaded into the TPM,
the parent key's authentication data must be supplied since it is used
to decrypt the child key as it is loaded.

Keys generated on-chip can also be set to be non-migratable.  Such keys
can only have parents that are also non-migratable.  With these keys, the
user never learns their private part.  They are only ever exported while
encrypted to a parent key which is itself non-migratable.  Even though
these keys are loaded on and off the chip, they are protected at all
times.

The result of this system is that the TPM can manage as many keys as
the software desires.  Each one is stored in computer memory off-chip,
locked to a parent key.  This key hierarchy is ultimately rooted at
the SRK, whose private part never leaves the chip.  The effect is as if
the TPM had an infinitely expandable key store.

One flaw in this design is that TPMs tend to be slow, hence it takes a few
hundred milliseconds to load a key into a TPM.  If your key hierarchy is
deep and you want to use a key that is down many levels from the SRK, it
may take several seconds just to load it into the chip, as each parent in
turn has to be loaded before the next child can come in.  Hopefully future
TPMs will run more quickly so this will not be such a problem.  As it is,
for now it is best to make user keys be direct descendants of the SRK.