How much do we want to include on what type encryption is. This could be a 1 paragraph to 20 pages of stuff.
The TPM uses RSA for encryption and digital signatures. The standard key size for most keys is 2,048 bits. When used for internal encryption the TPM must use 2,048-bit keys.
When performing RSA encryption the TPM enforces the rules established by PKCS #1 V2.1. These rules require randomness (provided by the RNG) and masking (provided by SHA-1). The rules set forth by PKCS #1 provide mitigation against all sorts of esoteric attacks. By
follow-132 The Intel Safer Computing Initiative
ing these rules, the TMP uses a well-known algorithm and protocol and avoids the necessity of performing additional cryptographic evaluations.
When performing RSA digital signatures, the TPM provides for a cou-ple of standard digital signature schemes. These schemes allow for the digital signature on a wide variety of internal TPM and external data. The schemes also provide for mitigation against attacks.
Key Generation
Applications using the TPM are not going to all want to use the same key.
In fact good security practice demands that the applications use different keys. Some key will provide data protection and other keys will provide digital signatures. It would be nice to predetermine how many keys the TPM requires but one is now in the child’s game of “pick a number, 21, ok I pick 22 I win” where whatever number is picked will be wrong for someone. The end result is the requirement that the TPM have the ability to generate RSA keys on demand. All information necessary to generate the key must come from internal TPM resources8. The process for gener-ating the key is:
■ Obtain two random numbers. While the TPM could go looking for a source of randomness, one of the major reasons that the TPM has a requirement for an internal RNG is to provide the ran-domness for key generation.
■ Determine whether both the numbers are prime numbers. This is the fun part of creating an RSA key. For the typical key sizes, the numbers are around 1000-bits. While knowledge of prime num-bers has been around for thousands of years, and tests for deter-mining if a number is prime area available, to perform an exhaustive test on the two numbers could take days. Obviously then the TPM does not do an exhaustive test but performs some sort of statistical test to gain an assurance of that the number was prime.
− The normal method is to first make the number to test odd, as the only even prime number is 2, and 2 has only 2-bits not the 1000 bits we are looking for. The TPM then uses the statistical tests to determine whether the number is prime. If the num-ber is not prime, the TPM could add 2 to get to the next odd
8 The entity requesting the new key certainly provides the key type, protection or signing, key size, and other pieces of information, but the randomness must come from the internal TPM RNG.
Chapter 8: Attestation 133
number, and try the tests again. If, after a certain number of tries, the TPM does not find a prime number, the TPM could discard the original try and get some more randomness from the RNG.
− The testing for a prime number is not deterministic. That is, no one can tell you how long the TPM will take to find a prime number. While it would be great if we had some way to put a bound on the process, with today’s processors and mathematical knowledge, prime number testing is going to take some indeterminate amount of time. Because of the inde-terminate time necessary some TPM vendors “cheat”9, when-ever the TPM is idle, the TPM is creating a list of prime numbers. Now, when the TPM gets a request to create a new RSA key, the TPM merely picks the next two prime numbers from the list and performs the rest of the math. If too many requests for new keys arrive in a short amount of time, the prime number list could be exhausted and the TPM would need to find a prime number in real time.
■ With two prime numbers, the TPM would perform the other mathematical operations necessary to create a RSA key pair.
Opt-in
The TPM contains a unique value, called the endorsement key. The plat-form owner must have an assurance that the EK is only in use for those operations that the platform owner authorizes. The authorization pro-vides protection against the improper use of the uniqueness. Improper use of the uniqueness could create the ability for outside entities to cor-relate two different uses of the uniqueness, resulting in a loss of privacy.
The TPM is an opt-in device. Opt-in means that the platform owner must take specific steps to turn the TPM on. When shipped, the TPM is not operational. The TPM must have a mechanism that stores and keeps secure the platform owner’s selection of the state of the TPM.
The opt-in mechanism must include some physical mechanism that an operator at the platform must manipulate to indicate that a human is operating the platform. This physical presence mechanism, when
9 Actually, I don’t think of this proactive number generation as cheating. It is rather an excellent way to use the limited TPM resources.
134 The Intel Safer Computing Initiative
serted, allows the TPM to validate that requests to manipulate the per-manent state of the TPM have authorization from a human.
Attestation Identity Key
The Attestation Identity Key (AIK) provides a mechanism for establishing that an entity is communicating with a TPM but not for determining which TPM. This distinction is very important when discussing privacy issues. If the requesting entity can determine from the key in use which TPM is in use, the entity could correlate uses and cause a loss of privacy.
The EK is the Root of Trust for Reporting, but if every single report used the EK, then the correlation would be very easy.
The AIK provides a mechanism to report on TPM internal information like the status/content of a PCR, but not to use the EK directly.
Authorization
The advantage that the TPM provides to entities wishing to rely on the TPM is that many operations require authorization to execute. From the standpoint of the TPM mechanisms, there needs to be a mechanism that can prove to the TPM that the entity requesting the operation has the au-thority to do so. While it would be nice for the TPM to put up a dialog box or use a voice request, those options really are not possible. The HMAC mechanism provides a way to authenticate TPM requests.
The authorization of a command wants to use a shared secret, which is both sides of the communication know the shared secret, one side wants to prove to the other side knowledge of the shared secret, and nei-ther side wants to transmit the shared secret over the communication medium. HMAC provides the mechanism to do that.
When an entity creates a new key, or other resource requiring subse-quent authorization, the creation process includes the authorization value. When the entity wishes to use the resource, the request to use the resource includes the HMAC of the request and the authorization value, or shared secret. The TPM must associate with the resource, and perma-nently keep track of the authorization value.
A security concern, not just a theoretical one but a practical concern, is that some attacker could capture a request to use the resource and re-play the HMAC calculation. With the request being the same and the au-thorization being the same the HMAC calculation would result in the exact same value. To mitigate this vulnerability the calling entity places into the request some randomness and includes the randomness into the
Chapter 8: Attestation 135
HMAC calculation. Now the caller knows that the command sent to the TPM and the response from the TPM, which also uses the randomness, is fresh and not a replay.