Trusted Platform Module (TPM) Essay Example

its purpose.

The TPM background section discusses in some detail an overarching summary of TPM. This will include what the motivations and advantages are to using TPM as well as how the different types of keys function. Also discussed is the evolution of TPM over time in how it functions in both its hardware encryption but also its capabilities.

2.1 TPM Summary

A Trusted Platform Module (TPM) is a cryptographic coprocessor that replaced smart cards in the 1990’s and then became present on most commercial personal computer (PC’s) and servers. TPM’s are almost ubiquitous in computer hardware and typically not seen by users because of the lack of compelling applications that use them. However, this situation has changed effective with TPM version 1.16 by adding the Federal Information Processing Standards (FIPS) bit which is a static flag that verifies if the device or firmware the TPM is attached to is FIPS 140-2 cryptographic module compliant. This compliance is then registered by the consolidated validation certificates granted when FIPS 140-2 is validated and are then registered and published at NIST as public record listed alphabetically by vendor located at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401vend.htm. (TCG FIPS 140-2 Guidance for TPM 2.0, ver 1, rev.8, 2016) Therefore, the line of thinking of TPM has increasingly become one of importance and an essential ingredient to cryptographic defense community whom are required to prove their FIPS 140-2 compliance. However, this was not always the case since security was not a mainstream issue in the early years of the Internet.

2.2 Motivation to use TPM

The motivation for TPM began decades after the advent of what is known as the Internet. From the creation of Advanced

Research Projects Agency (ARPA) in 1969 it took almost nineteen (19) years for us to become aware of the first known exploit called the Internet Worm in 1988. (Pearson Education, Inc., 2014) Until this time the focus had always been on the development of the computer with no security hardware and software that was easy to use. There was a real concept of information security threats. However, in the 1990s there was the concept of the potential of commerce the Internet would have and the need to secure the PCs that would exchange with that commerce. This prompted many computer engineers to convene and form and develop the first TPMs which became known to be as the Trusted Computing Group (TPM: A Brief Introduction, 2015). A main objective of this group was a cost effective approach to create a hardware anchor for PC system security on which secure systems could be built. This first resulted in a TPM chip that was required to be attached to a motherboard and the TPM command set was architected to provide all functions necessary for its security use cases.

2.2.1.Evolution

TPM has evolved considerably over the years to become the trusted platform it is today. The earlier TPM 1.2 standard was incorporated into billions of PCs, servers, embedded systems, network gear and other devices, the evolving Internet of Things and increasing demand for security beyond traditional PC environment led TCG to develop a new TPM specification, which recently was adopted as an international standard ISO/IEC 11889:2015. For more flexibility of application and to enable more widespread use of the specification, TCG created TPM 2.0 with a “library” approach. This allows

users to choose applicable aspects of TPM functionality for different implementation levels and levels of security. Also, new features and functions were added, such as algorithm agility, the ability to implement new cryptographic algorithms as needed (“Trusted Platform Module (TPM): A Brief Introduction,” 2015).

ISO/IEC 11889-1:2015

ISO/IEC 11889-1:2015 defines the architectural elements of the Trusted Platform Module (TPM), a device which enables trust in computing platforms in general. Some TPM concepts are explained adequately in the context of the TPM itself. Other TPM concepts are explained in the context of how a TPM helps establish trust in a computing platform. When describing how a TPM helps establish trust in a computing platform, ISO/IEC 11889-1:2015 provides some guidance for platform requirements. However, the scope of ISO/IEC 11889 is limited to TPM requirements (“Trusted Platform Module (TPM) Summary,” 2008).

2.3 TPM Working Functionality

The TPM (Trusted Platform Module) is a computer chip (microcontroller) that can securely store artifacts used to authenticate the platform on a PC or laptop. These artifacts can include passwords, certificates, or encryption keys. A TPM can also be used to store platform measurements that help ensure that the platform remains trustworthy. This is critical because Authentication and attestation are necessary to ensure safer computing in all environments. Trusted modules can be used in computing devices other than PCs, such as mobile phones or network equipment (“Trusted Platform Module (TPM) Summary,” 2008).

.

Figure 1: Components of a TPM

2.3.1 Hardware-based cryptography

This cryptography makes certain that the data stored in hardware is guarded against malicious threats such as external software attacks. Also, many types of applications storing secrets on a TPM can be developed

to strengthen security by increasing the difficulty of access without proper authorization. If the configuration of the platform has been altered as a result of unauthorized activities, access to data and secrets can be denied and sealed off using these applications. TPM is not responsible for control of other proprietary or vendor software running on a computer. However, TPM can store pre-run time configuration parameters, but it is other applications that determine and implement policies associated with this information. Also, processes can be made secure and applications such as email or secure document management. For example, if at boot time it is determined that a PC is not trustworthy because of unexpected changes in configuration, access to highly secure applications can be blocked until the issue is remedied. With a TPM, one can be more certain that artifacts necessary to sign secure email messages have not been affected by software attacks. And, with the use of remote attestation, other platforms in the trusted network can make a determination, to which extent they can trust information from another PC. Attestation or any other TPM functions do not transmit personal information of the user of the platform.

2.3.2 Capabilities

TPM can improve security in many areas of computing, including e-commerce, citizen-to-government applications, online banking, confidential government communications and many other fields where greater security is required. Hardware-based security can improve protection for VPN, wireless networks, file encryption (as in Microsoft’s BitLocker) and password/PIN/credentials’ management. TPM specification is OS-agnostic, and software stacks exist for several Operating Systems.

2.4TPM Components

Trusted Platform Module (TPM) is the core component of trusted computing. TPM is implemented as a secure hardware chip and provides

the hardware “Root of Trust”. TPM has been designed to provide trusted computing based on Trusted Computing Group (TCG) specifications. TPM functions can be implemented either in hardware or software. A secure cryptographic chip (Figure 2) can be integrated on the motherboard of a computing device according to TPM 1.2 specifications (Angela, Renu Mary, & Vinodh Ewards, 2013).

Figure 2: A TPM 1.2 Chip (Source http://www.infineon.com)

A logical layout of the TPM is represented below (Figure 3) along with the TPM components.

Figure 3: TPM Component Diagram (Zimmer, Dasari, & Brogam, 2009)

Information flow is managed by the I/O component through the communication bus. The I/O component handles routing of messages to various components within the TPM and establishes access control for TPM functions and the Opt-in component.
The non-volatile memory in the TPM is a repository for storing the Endorsement Key (EK) and the Storage Root Key (SRK). These long-term keys are the basis of key hierarchy. Owner’s authorization data such as password and persistent flags are also stored in the non-volatile memory (Trusted Computing Group, 2007).
Platform Configuration Registers (PCR) are reset during power-offs and system restarts and can be stored in volatile or non-volatile region. In TPM v 1.1, minimum number of registers that can be implemented is 16. Registers 0-7 are allocated for TPM usage leaving the remaining registers (8-15) to be used by operating system and applications (Angela, Renu Mary, & Vinodh Ewards, 2013). In TPM v 1.2, number of registers can be 24 or more and categorized as static PCRs (0-16) and dynamic PCRs (17-22).
The Program Code, also known as Core Root of Trust for Measurement

(CRTM) is the authoritative source for integrity measurements. Execution engine is responsible for initializing TPM and taking measurements. The execution engine is the driver behind the program code.
RNG (Random Number Generator) is used for generating keys, nonce creation and to fortify passphrase entropy. The SHA-1 engine plays a key role in creating key Blobs and hashing large blocks of data. TPM modules can be shipped with various states ranging from disabled, and deactivated to fully enabled. The Opt-in component ensures the state of TPM modules during shipping.
The RSA engine can be used for a variety purposes including key signing, encryption/decryption using storage keys and decryption using EK. The AIK (Attestation Identity Key) is an asymmetric key pair typically linked to the platform module that can be used to vouch for the validity of the platform’s identity and configuration. The RSA key generation engine are used for creating symmetric keys of up to 2048 bits.
2.5 TPM Keys

TCG keys can be categorized as signing or storage keys. Other key types defined by TCG are Platform, Identity, Binding, General and Legacy keys (Trusted Computing Group, 2007).

Signing keys can be classified as general purpose keys and are asymmetric in nature. Application data and messages can be signed by the TPM using signing keys. Signing keys can be moved between TPM devices based on restrictions in place. Storage keys are asymmetric keys and primarily used for encrypting data and other keys as well as for wrapping keys. Attestation Identity Keys (AIK) are used for signing data pertaining to the TPM such as PCR register values. AIK are signing keys that cannot be exported. Endorsement Key (EK)

is used for decrypting the owner authorization credentials as well as cryptic messages created by AIK. EK is not used for encryption or signing and cannot be exported. Bind keys (symmetric keys) come in handy to encrypt data on one platform and decrypt it on a different platform. Legacy keys can be imported from outside the TPM and used for signing and encrypting data. Authentication keys are responsible for securing the transport sessions related to TPM and are symmetric in nature.

Endorsement Key (EK) in the TPM plays a critical role to maintain system security. TPM uses a private key EK to generate other keys which are bound to a specific EK. EK should be secured and protected from being compromised. A 160-bit AIK authentication value is necessary to use the AIK by TPM (Sparks, 2007). The parent key used for generating other keys should be loaded first and authenticated by users before TPM can load all other keys. The EK is unique to the TPM and embedded within the tamper resistant non-volatile memory (Angela, Renu Mary, & Vinodh Ewards, 2013). Public EK is used for creating AIK certificates and during the process of encrypting data within the TPM. The private key pair of EK is not touched when generating signatures. Multiple AIKs can be stored within a TPM to ensure anonymity between various service providers requiring proof of identity. AIK keys should be stored in secure external storage (outside the TPM) to make them persistent. AIKs can be loaded on to the volatile memory in the TPM when in use.

TPM has a Storage Root Key which stays persistent. Keys are not stored permanently

in TPM due to limited storage space. A brief description of the process involved in key generation, encryption, and decryption in TPM is outlined below (Osborn & Challener, 2013). A new RSA key is generated by the TPM when a key creation request is initiated by a software. TPM concatenates a value to the RSA key, appends authorization data and then the data is encrypted using the public section of the Storage Root Key and sends an encrypted “blob” to the requested software. A request is sent for the key to be retrieved from the blob storage when requested by the software program. TPM uses the Storage Root Key for decryption and validates the proof value and password before loading the key into TPM memory. This loaded key is referred to as the “parent” key and can be used for subsequent key creation forming key hierarchies.

The TMP security section discusses in some detail the various ways in which security is implemented and vulnerable. TPM authorization protocols in both version 1.2 and version 2.0 are addressed. Several examples of different types of TPM vulnerabilities are outlined as well as ways to verify the integrity of the system to protect against this vulnerabilities and what the future holds for TPM.

3.1 TPM Authorization Protocols
TPM 1.2 Authorization

The basic definition of TPM authorization is the process of verifying that software is allowed to use a TPM key. For TPM 1.2 this process is accomplished by utilizing a couple basic commands in an authorization session; typically using passwords or values stored in the Platform Configuration Registers (PCRs) which are referred to as authorization data. The three types of

authorization sessions for TPM 1.2 are: Object Independent Authorization Protocol (OIAP), which creates a session that allows access to multiple objects, but works only for certain commands; Object Specific Authorization Protocol (OSAP), which creates a session that can manipulate only a single object, but allows for new authorization transfer; and Delegate-Specific Authorization Protocol (DSAP), which delegates access to an object without disclosing the authorization data (Nyman, Ekberg, & Asokan, 2014).

Commands are then used to manipulate the keys within an authorization session. Software can prove that it is trusted by sending a command which includes the password hash to verify it has knowledge of the password. Also the “locking” of non-volatile random-access memory (NVRAM) to PCRs and particular localities is utilized for two different authorizations; one for reading and one for writing. While effective, these authorization mechanisms created a relatively rigid authorization system which make it difficult to administrate the sharing of TPM keys and data (Osborn & Chaneller, 2013).

3.1.2 TPM 2.0 Authorization

The implementation of TPM 2.0 on the other hand, takes a couple different approaches by introducing enhanced authorization (EA). EA takes methods from the TPM 1.2 authorization methods and improves upon them by incorporating features mentioned in Table 1 below.

Table 1.

TPM 2.0

Authorization Feature

Description

Passwords in the clear

Reduces overhead in environments where the security of hash message authentication (HMAC) may not be feasible due to its extra cost and complexity

HMAC key

In some cases when the software talking to the TPM is trusted but the OS is untrusted (like in a remote system), it could

be useful to use HMAC for authorization the same way as used in TPM 1.2

Signature methods

Allows IT employees to perform maintenance on a TPM by authenticating using a smart card or additional data such as a biometric fingerprint or GPS location. This ensures that passwords can’t be shared or compromised by unauthorized users and that an additional verification check is conducted

PCR values as a proxy for system boot state

If the system management module software has been compromised, this prevents the release of the full-disk encryption key

Locality as a proxy for command origins

Can be used to indicate whether a command originated from the CPU in response to a special request.

Time

Can limit the use of a key to certain times of the day

Internal counter values

Limits the use of an object so that a key can only be used a certain number of times indicated by an internal counter

Value in a non-volatile (NV) index

Use of a key is restricted to when certain bits are set to 1 or 0

NV index

Authorization is based on whether the NV index has been written

Physical presence

Requires proof that the user is physically in possession of the platform

(Table created with information from (Arthur, Challener, & Goldman, 2015))

These features can be combined to create more complex policies by using the logical operators AND or OR which allows for the creation of policies

to include multifactor/multiuser authentication of resources, limited time constraints for resources, and/or revocation of resources. (Arthur, Challener, & Goldman, 2015).

3.2TPM Vulnerabilities

When ranked against other standards, TPM comes in as highly secure but that isn’t to say that it is immune to all attacks. There are several vulnerabilities that can allow an attacker to circumvent TPM’s level of security. The sections below explain a few vulnerabilities that attackers can use to exploit TPM, and the mitigation techniques one could deploy to manage the risk.

Dictionary Attack

TPM authorization relies on a 20-byte authorization code that is sent by the requestor which if not properly locked down can result in an attacker guessing their way past the authorization. TPM issues guidance on how best to mitigate and prevent these attacks; however, the guidance is not very detailed and rather leaves the specifics up to the implementer. For example, one could implement a design that has TPM disable further input whenever it encounters more than 3 failed attempts. This would effectively prevent online dictionary attacks and has the added benefit of also preventing Denial-of-Service attacks.

We’ve spoken about preventing online dictionary attacks but where the threat truly comes into play is with an offline-based attack. This vulnerability comes into play when the authorization code is easily guessable, or in other words, poorly implemented. An attacker could observe a given command, the associated Key-Hash Message Authentication Code (HMAC) sent by the requestor and finally, the TPM response back. Since the HMAC is created from the authorization code, session handle and nonces; an attacker can utilize a dictionary attack to try different nonces and authorization codes with the given

HMAC algorithm. A match would then provide the attacker with the correct authorization code. This offline attack bypasses TPM’s lockout policy and though the attacker but sift through the random nonces and authorization codes, the method is a viable means of attack because it can be reasonably executed given the availability of time and computing resources. The mitigation for this comes down to proper configuration and ensuring that the authorization code is not easily guessable.

DRAM Attack

Though this attack is not directly against TPM, it is worth mentioning as it is a viable way to circumvent TPMs security authorization protocols. TPM maintains its keys within non-volatile memory within the TPM component; however, when these keys are pulled by a requestor or requesting application, they are stored within Dynamic Random Access Memory (DRAM). It is well known that one can easily exploit DRAM to extract valuable information (keys, passcodes, etc) with this even being demonstrated against Microsoft’s BitLocker encryption utility. During reboot, Windows would load the encryption keys stored within TPM into DRAM, prior to even prompting the user. Given this, an attacker could go in and dump the raw memory to an external device, obtain the keys, then utilize those keys to decrypt the disk. This flaw enabled attackers to gain access to data on stolen laptops, even with full disk encryption. This hits on how a system is designed and ensuring that every detail is accounted for. Even if your system has a TPM, it is only going to be as secure as the weakest component within the overall system.

OIAP Replay Attack

Replay attacks are a method used by many attackers across

a multitude of systems. TPM is no exception and is vulnerable to replay attacks based on several characteristics. First, a TPM Object-Independent Authorization Protocol (OIAP) session can be left open for an indefinite period. The authorized session is only closed by the requestor whenever an abnormal message is received and finally, the HMAC that wraps the message can detect alterations to the message but cannot distinguish between a deliberate alteration and a simple network error.

For example, an attacker would first capture a requestor’s authorized command for later use. The attacker then sends an abnormal message to the requestor which then fools it into resetting the session. The requestor is unable to distinguish between the abnormal message and a network error so no concern is raised. Since there is no concern, the TPM keeps the authorized session open, allowing the attacker the ability to replay the previously captured command through the open session. This could lead to the attacker being able to corrupt or even overwrite a subsequent command issued by the requestor. The TPM would not be able to notice this type of attack which is truly concerning based upon the foundational principles of TPM and its assurance of being able to detect unauthorized modifications to data.

3.3TPM Attestations

Attestation is the method a platform uses to prove to another platform that it is in a particular configuration by using a digitally signed set of cryptographic hash values which creates a trust between platforms (Fisher, McCune, & Andrews, 2011). The network server first creates a cryptographic random value (used to prevent replay attacks) called a “nonce”, which is then sent to the client. Software on

the client then sends the nonce to the TPM and specifies an identity key. The TPM hashes the PCR values along with the nonce and then signs the hash with a private key. The client software sends this back to the server which then verifies the platform configuration by comparing the public portion of the identity key. This process provides hardware-based assurance that software on these platforms has not been modified. (Osborn & Chaneller, 2013). Figure 5 provides a visual representation of attestation as provided by (Osborn & Chaneller, 2013)

Figure 5: Attestation

In order for the attestation process to be valid however, it must be able to be proven that the TPM values from the client are not being spoofed. This can be accomplished using a couple of key components: attestation identity keys (AIK), which are created by the TPM and securely stored on disk before being reloaded into volatile TPM memory; endorsement keys (EK), which are hardcoded by the manufacturer into the TPM chip; and a privacy certificate authority (CA), which is a third-party validation entity.

The first step of this process occurs when the public half of the AIK and EK is sent to the CA. The CA then uses the public EK certificate to verify that the request comes from a valid TPM by comparing it to a list of all valid TPM manufacturers’ public keys. The CA then puts the public AIK in a certificate and encrypts it with the public EK. This ensures that the only party that can decrypt it is the computer with the AIK of the corresponding TPM, thus confirming that the TPM from the

requesting platform is trusted, and therefore, the attestation method is trusted as well. (Uppal & Brandon, 2011).

3.4Application of TPM

With the ever-evolving landscape of technology, there is an increased need for faster, more reliable and more secure methods of protecting private and personal data. TPM is a product of those evolving requirements and has thus been incorporated into many different sets of applications. This section will expand upon those sets of applications and delve into how TPM is utilized within the industry today.

Encryption

One of the most popular uses of TPM is to ensure the confidentiality of user data by providing full encryption capabilities for disks and file systems. The full disk encryption utilizes symmetric encryption with a key created from the user’s supplied passcode and used during the initial configuration and system boot. This protects against the loss of the disk drive and serves to facilitate disposal or repurposing of the drive since deleting the keys will result in the drive being wiped. The same method is utilized for the encryption of file systems and can be done so to protect specific nodes.

Policy Enforcement

With Bring-Your-Own-Device (BYOD) policies becoming more and more prevalent within the commercial businesses, TPM has found a use as a policy enforcement mechanism for remote access. TPM can be used to establish trust and verify a device’s integrity before allowing remote connection to an organizations intranet. This utilization of TPM is comprised of a series of hashes that measure the predefined sequence of code loads, starting with the boot of the BIOS through the loading of the applications. The chain of hash measures are then compared to the

stored value in order to validate the system’s integrity. This is very useful for establishing the base operating environment and developing a baseline with which access control policies can be developed.

Password Protection

TPM protected storage provides a method of storing encryption/decryption keys as well as providing utility management of user passwords. Typically, the password manager retrieves the then encrypted password from TPM, decrypts it, and then sends it to the client application for validation. Since the passwords are usually sent to the client applications over plain-text, this is a serious vulnerability in which TPM can provide a solution for. Using the 20-byte authorization code, a TPM object is created for each user password with this then being saved in the objects authorization field. To verify a password, an application would need to send an OIAP request to access the TPM object. TPMs response to this request would indicated whether the password was correct or not. As a plus, this serves as both password storage and verification with the password never being sent to the application thus eliminating the vulnerability associated with plain-text.

3.5TPM Future

TPM is compatible with many hardware and software platforms in use in today’s commercial markets and is already in use by several major business functions, to include: Banking, E-Commerce, Biometrics and even Antivirus applications. Looking forward, TPM will play an even bigger role in the evolving mobile market, providing more enhanced security for cell phones, GPS tracking systems, tablets and more. TPM can be used to secure the Mobile Operating System (OS) from being modified by attackers and can be used to further secure authorized access by implementing a hard-coded digital

signature solution. For GPS devices, TPM can be used to protect against the modification of system defined location parameters, thus preventing an attacker from adjusting those parameters to satisfy their ends.

The biggest constraint facing TPM’s implementation within the mobile realm is the space and power constraints on mobile devices. Research is being done on whether a mobile instantiation of TPM should be based on firmware, software or even hardware. A hardware implementation would be the most secure; however, the firmware-based option will likely prove to be the best approach as it will balance the security of the device with the size limitations.

TPM is also being looked at with regards to providing security enhancements for cloud-based services. Cloud computing has migrated most of the standard desktop to a virtual and remotely shared environment which negates the TPM services that were deployed on the local PC. Cloud environments focus a lot more on trusted computing and the assurances of application integrity meaning TPM will be even more important in a cloud-based environment for preventing data leakage for both in transit and stored data.

4.0Conclusion (1.5 p)

We have presented