When you take ownership of a TPM in Windows 7 you encounter a screen like this:

enter image description here

Based on this document, it is my understanding that completing this dialog box somehow results in the generation of the Storage Root Key (SRK) based on the password:

Storage Root Key: The Storage Root Key (SRK) is used to wrap TPM protected keys which can be stored outside the TPM. This builds a hierarchy of keys represented in figure 4 on an external storage device like a hard disk drive. The SRK is embedded into the TPM and is generated during the process of taking logical ownership of the platform. It can be re-generated by creating a new platform owner which destroys the previous key hierarchy and all the data and keys it contains.

This raises the following questions:

  1. How is the SRK derived from the password?
  2. How is the SRK stored?
  3. If the SRK is somehow compromised, how easily can the password be derived from the SRK?

2 Answers 2


Disclaimer: I'm not a TPM expert - most of this has come from a half hour's worth of research. I've managed to cobble together a reasonable understanding of the process and details from the TCG TPM spec, the TPM API documentation on MSDN, and various papers on the subject.

The SRK is an RSA key pair (of at least 2048-bit size) that is used as the root for a chain of trust within the TPM. It acts as the ultimate authority of trust. If a secondary RSA key is loaded into the TPM and signed with the SRK, that key is classed as trusted, and other materials signed with that key may be loaded in via that chain of trust. The SRK is not derived from a password - it is an RSA key generated in hardware.

When ownership is taken of the TPM, the process involves two things: one is generating the SRK, the other is storing the owner authentication secret. Once set, this secret is used to authenticate owner users in future sessions, usually via a HMAC-based exchange.

The Trusted Computing Group (TCG) spec for TPMs does not specify how this secret is to be created, but Windows uses a SHA1 hash of the UTF-16LE encoded password, with the null terminator of the string excluded (source). If you were able to retrieve the owner authentication secret from the TPM, you would be able to crack it just as quickly as you could any other SHA1 hashed password, e.g. via oclHashcat. Simply capturing an authentication exchange (HMAC of a challenge value using the secret as a key) is not enough to crack the authentication secret, since the challenge value is generated by the TPM.

The SRK is stored in the TPM in an encrypted format, using one of two different encryption methods. If the Authorisation Data Insertion Protocol (ADIP) is used, the SRK may be encrypted with AES-128-CTR or simple XOR. If ADIP is not used, XOR is the only method defined by the spec. Therefore, the system is expected to compute its own key, and store secondary information such as the IV inside non-protected areas of the TPM. The creation of the key for the encryption is, again, entirely reliant on the OS.

It stands to reason that different keys can be used for ownership and internal encryption, i.e. an SRK key and an owner key. However, it appears that Windows simplifies the situation by using the same key for both.

  • Thanks for the great answer. I'm not grokking your last paragraph, though. What do you mean by "internal encryption"?
    – alx9r
    Commented Mar 17, 2013 at 20:53
  • Sorry, I meant encryption of stored keys, i.e. encryption of keys added to the TPM rather than "special" keys like the SRK.
    – Polynomial
    Commented Mar 17, 2013 at 21:09

I realise this is an old thread, but still...

This raises the following questions:

  1. How is the SRK derived from the password?
  2. How is the SRK stored?
  3. If the SRK is somehow compromised, how easily can the password be derived from the SRK?
  1. It isn't. The SRK is generated by the TPM using an onboard random number generator. The password is used to authorise SRK actions.
  2. Both the password and the SRK are stored in TPM NVRAM. The SRK's private half never leaves the TPM.
  3. This has two half-answers, depending on what you mean.
    1. The SRK's private half is hard to compromise: unless the NSA is your adversary (and even then), you can basically assume that isn't going to happen. To do so would require either an electron microscope or breaking RSA.
    2. If the password is compromised, it allows remote parties to authorise SRK operations on this TPM. They don't get the SRK itself, since the SRK isn't derived from it.

Note: there is a rumour that the NSA is capable of breaking TPM-held private keys via a power attack. Such an attack still requires physical access to the machine; it can't be mounted remotely.

You must log in to answer this question.

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