PRODUCT DESCRIPTION

The product is an integrated circuit chip designed to be included in personal computers and other embedded systems. The AT97SC3201 implements a Trusted Computing Module (TPM) in accordance with version 1.1b of the TCG Main Specification issued by the Trusted Computing Group. The TPM provides security primitives in a secure environment. The primitives include digital signatures, random number generation, and protected storage and binding information to the TPM. The TPM is described in detail in the TCG Main Specification.

The Target of Evaluation (TOE) comprises the Atmel AT97SC3201 and its embedded firmware. The TOE performs RSA key generation and digital signature, data decryption, user identification and authentication, secure hash, and software random number generation. The TSF boundary is the same as the TOE boundary. The TPM supports the following protocols and algorithms:

• Algorithms: RSA, SHA-1, HMAC
• Random number generation
• Key generation
• Self-testing

The TPM may be used to provide secure storage for a minimum of 10 private keys or other data by using RSA key technology to encrypt data and keys. The resulting encrypted file, which contains header information in addition to the data or key, is called a blob and is output by the TPM and can be loaded in the TPM when needed. The functionality of the TPM can also be used so that private keys generated on the TPM can be stored outside the TPM (encrypted) in a way that allows the TPM to use them later without ever exposing such keys in the clear outside the TPM.

The functionality used to provide secure storage is:

• Seal and Unseal, which perform RSA encrypt and decrypt, respectively, on data that is externally generated. The sealing operation encrypts not only the data, but also the platform configuration values that are stored in platform configuration registers (PCRs) in the TPM and TPMProof, a unique identifier for that TPM. To unseal the data, three conditions must exist: 1) the appropriate key must be available for unseal, 2) the TPM PCRs must contain the same values that existed at the time of the seal operation, and 3) the value of TPMProof must be the same as that encrypted during the seal operation. By requiring the PCR values to be duplicated at unseal and the TPMProof value to be checked, the seal operation allows software to explicitly state the future "trusted" configuration that the platform must be in for the decrypted key to be used and for decrypt to only occur on the specified TPM.
• Unbind, which decrypts a blob created outside the TPM that has been RSA encrypted using a public key where the associated private key is stored in the TPM.

A number of key types are defined within the TPM. Keys may be migratable or non-migratable. A migratable key is a key that may be transported outside the specific TPM. A non-migratable key is a key that cannot be transported outside a specific TPM. Key types include:

• The Storage Root key (SRK), the root key of a hierarchy of keys associated with a TPM; it is generated within a TPM and is a non-migratable key. Each TPM contains a SRK, generated by the TPM at the request of the Owner. Under that SRK are two trees: one dealing with migratable data and the other dealing with non-migratable data
• Signing Keys, which must be a leaf of the Storage Root Key hierarchy. The private key of the key pair is used for signing operations only.
• Storage keys, which are used only to RSA encrypt and RSA decrypt other keys in the Protected Storage hierarchy,.
• Identity Keys, which are only used for operations that require a TPM identity.
• Binding Keys, which are used for TPM_Unbind operations only. A bind operation (performed outside the TPM) associates identification and authentication data with a particular data set and the entire data blob is encrypted outside the TPM using a binding key, which is an RSA key. The TPM_Unbind operation uses a private key stored in the TPM to decrypt the blob so that the data (often a key pair) stored in the blob may be used.
• The Endorsement key pair, which is an asymmetric key pair generated by a TPM that is used as proof that a TPM is a genuine TPM.

Each TPM is identified and validated by its Endorsement Key. A TPM has only one endorsement key pair. The Endorsement Key is transitively bound to the Platform via the TPM as follows:

• An Endorsement Key is bound to one and only one TPM (i.e., that is a one to one correspondence between an Endorsement Key and a TPM.)
• A TPM is bound to one and only one Platform, (i.e., there is a one to one correspondence between a TPM and a Platform.)
• Therefore, an Endorsement Key is bound to a Platform, (i.e., there is a one to one correspondence between an Endorsement Key and a Platform.

SECURITY EVALUATION SUMMARY

The evaluation was carried out in accordance to the Common Criteria Evaluation and Validation Scheme (CCEVS) processes and procedures. The Trusted Platform Module Atmel AT97SC3201 was evaluated against the criteria contained in the Common Criteria for Information Technology Security Evaluation, Version 2.1. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 1.0. CygnaCom Solutions has determined that the product meets the security criteria in the Security Target, which specifies an assurance level of EAL 3 augmented by ADV_SPM.1 and ALC_FLR.1. A validator, on behalf of the CCEVS Validation Body, monitored the evaluation. The evaluation was completed on April 6, 2005.

ENVIRONMENTAL STRENGTHS

The TOE is an integrated circuit chip designed to be installed in personal computers and other embedded systems. The Atmel AT97SC3201 implements a Trusted Computing Module (TPM) in accordance with version 1.1b of the TCG Main Specification. The TPM provides security primitives in a secure environment. The primitives include digital signatures, random number generation, and protected storage and binding information to the TPM.

The product provides an authentication failure mechanism to protect against password guessing attacks by locking out access to the product for a period of time. Failed password attempts up to the value of a failure modulus (an internal counter that is initially set to 1 in the evaluated configuration) do not cause any lockout. The next failure, however, causes a lockout delay. After the delay times out, additional attempts are permitted before the next delay is imposed. The length of the delay increases geometrically each time with the first delay lasting 1.1 minutes, the second lasting 2.2 minutes, and so on.

Vendor Information

Atmel Corporation
Randy Mummet
719.540.1759
rmummert@cso.atmel.com

http://www.atmel.com