Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?
share|improve this question

1 Answer 1

up vote 5 down vote accepted

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.

share|improve this answer
    
Thanks for the great answer. I'm not grokking your last paragraph, though. What do you mean by "internal encryption"? –  alx9r Mar 17 '13 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 Mar 17 '13 at 21:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.