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.