Trusted Platform Module Components and Keys - Research Paper Example

? Trusted Platform Module Components and Keys (Insert Trusted Platform Module Components and Keys TPM can be defined as “a computer chip that can securely store artifacts used to authenticate the” computer. The artifacts may include passwords, encryption keys or certificates. Platform measurements which ensure that help ensure that the computer remains trustworthy can also be stored using a TPM. The necessary steps for ensuring that computing in all environments is safe are authentication and attestation. Authentication is simply ensuring that what the computer claims to be can be proven. Attestation on the other hand is a verification process of the computer’s trustworthiness and determining if it has been breached or not. Other devices such as network equipment and mobile phones can be computed using TPMs (Trusted Computing Group, 2012). In summary, the TPM has four main functions which include platform monitoring, secure storage, encryption operations and authentication services (Hewitt, 2006). Operations on sensitive data can only take place in special locations, called shielded locations, which must be incorporated in the TPM. It should be impossible for user programs to access these locations. Protected capabilities are the set of commands which one can use to access the shielded locations. This set of commands protect the shielded locations and report integrity measurements at the same time. The TPM has several major components which are illustrated in the following diagram. TPM COMPONENTS The SecureI/O component It is a control component that manages the TPM’s information flow to the outside and also controls and routes internal signals (Hewitt, p.3). The I/O encodes and decodes the information passing over the internal and external buses (Gunupudi, p.11). The Cryptographic Co-Processor This is a major subdivision of the TPM containing various cryptographic engines. The RSA key generator, RSA encryption/decryption and SHA-1 engine must be included in its functionality (Microsoft 2012). Other asymmetric algorithms such as DSA or elliptic curve, are allowed by the specification. The strength of 2048 bit RSA key should be the threshold of all storage and identity keys as this is enough to offer sufficient protection from malicious access. Digital signatures and encryptions are made using the RSA algorithm. If RSA encryption is not used when a signing is done within the TPM, it stands the risk of being rejected by other TPM devices. The engine must support key sizes ranging from 512,768, 1024 and 2048 bits. The minimum recommended size is 2048 bits. The specified public exponent of RSA is (2raised to 16 +1). The SHA-1 engine requires 160-bit keys and provides the primary hash algorithm used by the TPM. The implementations of the HMAC engine are dictated in RFC 2104. It involves turning a keyless hash function in to a keyed hash by incorporating a cryptographic key. This will allow the chip to detect proof of knowledge of Auth Data and also ensure that authorized incoming requests have not been tampered with (Hewitt, p.4). The TPM also uses the symmetric encryption algorithm internally because they cannot have user-accessible interfaces. They are used in encrypting internal data that was fed in to the TPM from an outside source and encrypting authentication exchanges. Other algorithms such as AES are allowed by the specification depending on the sufficiency preference of the implementer (Hewitt, p.5). The Key Generator It’s a protected capability function that manages the generation of keys and nonce (Gunupudi, p.12). The keys generated are used for encryption.The specification of the key generator is not strict. It however emphasizes that data that has existed in a non-protected location as a key should not be used. The specification also requires that all nonces be from the TPM’s Random Number Generator (Hewitt, p.5). The Random Number Generator It’s the source of entropy in the TPM (Gunupudi, p.12). It consists of a post-processor with a hashing function, a state register and an entropy or unpredictable data collector. Inside the TPM’s non-volatile memory, where the current state of the machine is stored, is where the state register is located. It’s a protected location. Hewitt states that “It can also be implemented as a combination of one volatile register and one non-volatile register, which is a bit of clever design allowing developers to use flash RAM (which wears out after a certain number of writes) as the non-volatile storage.” (p.5). Input data is filtered and corrected by the entropy collector. This means that a dedicated source of hardware entropy is not needed for the TPM to produce good random numbers. The Opt-in Component This component allows the disabling of the TPM when necessary. It’s disabled by default and must be enabled via the opt-in component. The Execution Engine The program code is run by this component for execution of commands from the I/O bus. It also segregates operations and ensures that the shielded locations are protected (Gunupudi, p.12). The Platform Configuration Registers This is where integrity measurements are stored at 160-bits. The TPM has at least 16 PCRs. The reason why the PCRs have the same number of bits as the SHA-1 engine is because they hold a hash of all previous measurement updates. When storing a new measurement, the PCR’s just hash it next to the previous measurement (Hewitt, p.6). The Attestation Identity Key This is a 2048-bit RSA key which aliases the EK (used during validity testing for the TPM). It signs data which can be available outside the TPM but is generated internally. Privacy concerns and security are the reasons why the EK cannot be used for this purpose (Hewitt, p.7). The Non-Volatile Storage This component holds information regarding the persistent state and identity of the machine (Gunupudi, p.12). TPM Keys Keys are labeled with attributes indicating allowed uses for keys and characteristics regarding the level of protection afforded the key in the TPM. The TPM attributes designation of migratable or non-migratable to all the keys that it manages (cmlab). Migratable Keys With the authorization of both the TPM owner and the key owner, the migratable keys can be migrated off a TPM. The origin of such a key cannot, unfortunately, be guaranteed. This is because it can be migrated to the control of a non-TPM environment just as easily as to another TPM-protected environment. A new protection level for keys protected by a TPM was introduced in the version 1.2 of the Trusted Computing Group specification; Certifiable migratable keys (CMKs). This is a migratable key whose migration is restricted (Microsoft 2012). The TCG specification’s intended use is that a migration practice statement would be published by a public, trusted migration authority to ensure that CMKs are only migrated to TPM protected environments. Non-migratable keys These keys are generated within a TPM. The private key can only leave the TPM in cipher-text form having been encrypted by another non-migratable key in the storage hierarchy. This protection only allows the use of the private part of the non-migratable key in the TPM that generated it (Gunupudi, p.14). There are various types of TPM keys which include: The Endorsement Key (EK) The EK is a public/private key pair. It’s generated as part of the manufacturing process by the manufacturer or vendor of the TPM. The authenticity values produced by the TPM can be attested to the EK. A credential or certificate must be provided by the entity that has created it to certify that the key pair was generated in the specified manner and is valid. The EK can only be used in carefully controlled ways such as creating identity keys since it is non-migratable (Gunupudi, p.15). The Attestation Identity Key (AIK) AIKs are aliases to the EK and are non-migratable key pairs. Information originating from a TPM cannot be signed by an EK due to privacy concerns. Since the private portion of an AIK never leaves the TPM in plain-text, it is used for signing data originated by the TPM. For example, certifications of other non-migratable keys. Unlike the EK, activation and generation of AIKs is controlled by the owner (Gunupudi, p.15). Storage Root Key Generated internally by the TPM, the storage root key (SRK), is a key pair that has a private key which never leaves the TPM. It’s a non-migratable key which is at the root of the secure storage hierarchy in the TPM (Gunupudi, p.16). Bind Keys These keys are used for encrypting small amounts of data on one platform and then decrypt it on another (cmlab). Legacy Keys These are migratable keys which are created outside the TPM. They are then imported to the TPM where they can be used to sign and encrypt operations (cmlab). Authentication Keys These keys are used to protect transport sessions involving the TPM. They are symmetric keys (cmlab). Signing Keys These keys are used to sign application data and messages. The keys can either be migratable or non-migratable. Signing keys are asymmetric general purpose keys (cmlab). References Cmlab.Trusted Platform Module (TPM). Retrieved from http://www.cmlab.csie.ntu.edu.tw/~ipr/ipr2006/data/lecture/Lecture13%20- %20Trusted%20Platform%20Module%20(TPM).pdf Gunupudi, V. (May, 2008). EXPLORING TRUSTED PLATFORM MODULE CAPABILITIES: A THEORETICAL AND EXPERIMENTAL STUDY. Retrieved from http://nsl.cse.unt.edu/~dantu/cae/attachments/vandana%20Dissertation.pdf Hewitt, B. ( April 13, 2006). Trusted Computing and the Trusted Platform Module: What All the Fuss Is About.Retrieved from http://www.cs.hmc.edu/~mike/public_html/courses/security/s06/projects/bill.pdf Microsoft. (March 9, 2012).Trusted Platform Module Administration Technical Overview. Retrieved fromhttp://technet.microsoft.com/en-us/library/cc766159(v=ws.10).aspx Trusted Computing Group (2012). Trusted Platform Module (TPM) Summary. Retrieved from http://www.trustedcomputinggroup.org/resources/trusted_platform_module_tpm_summar y Read More