When taking ownership of a TPM in Windows 7, how is the SRK derived from the password?

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.

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.