Skip to main content

Introducing new learning courses and educational videos from Apress. Start watching

Trust Computing, Backed by the Intel Platform Trust Technology

  • 19k Accesses




  • Management Engine
  • Trusted Platform Module1
  • Platform State
  • Trust Computing Group
  • Cryptography Algorithm

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Love all, trust a few, do wrong to none.

—William Shakespeare

In recent years, computing devices such as laptops, smartphones, tablets, and so forth, have become very functionally powerful. These devices have deeply penetrated into people’s daily lives in many ways. To take advantage of all the convenience that the advanced technologies have to offer, it is almost impossible for a regular user to avoid giving personal data and confidential information to these intelligent machines. A computer probably knows more secrets of its owner than the owner’s best friend. A user, implicitly, trusts his computers just like he trusts his family and friends.

For financial applications, shoppers input their credit or debit card numbers to purchase from online retailers; bank customers deposit checks using mobile devices by taking pictures of the checks and uploading to the bank’s server; financial institutions often require a social security number for the purpose of authentication; investors buy and sell stocks through electronic brokers. For personal applications, most people store all their photos, videos, and documents in local storage or upload to the cloud; in addition, users’ private information exposed in e-mails and social networking sites is handled completely by computers.

As you enjoy the convenience, a trust relationship is established. You are willing to give out the secrets because you trust the computers, not only your personal devices, but also the remote web sites and servers they interact with. You believe they are reliable and accountable and they will protect your sensitive information and use it legitimately.

Consumers need to trust the devices, and so do the service providers. The owner of a platform is not always the one to protect. For example, one of the biggest concerns of any content provider is its for-profit contents being transmitted to a rogue device that has been hacked by the owner. If the provider was not able to identify compromised devices, hackers could happily consume the received contents for free or even share with more people, resulting in direct profit loss for the provider.

The reliance on computers in the sectors of governments and large businesses is even more vital. Computer security for those highly sensitive domains is not merely about preventing loss of revenue or privacy, but also safeguarding national secrets and security. When the specification for the Trusted Platform Module1 (TPM) was introduced more than a decade ago, it was found especially useful for defense and intelligence agencies and other organizations where critical data must be stored and safeguarded from compromise.

For any new technology to be valuable, the benefit of applying the technology must exceed the expenses of initial deployment and continuous management. Ten years ago, the cost of TPM deployment was relatively high; consumer usages were not depending on computer security as heavily as today. In other words, the expenses incurred to users outweighed the benefit of utilizing hardware-based security, making TPM not a popular consumer feature. In contrast, TPM was financially meaningful for governments and large enterprises and organizations.

But the situation has gradually changed over time. On one hand, today’s personal computing devices are managing and processing critical assets for individuals, and compromise of security and the loss of such assets can result in a tremendous impact. Considering the ever-increasing threats from advanced attacks, protecting personal devices with a more robust technology is now inevitable. On the other hand, the cost of deployment and administration for TPM has reduced significantly and become more affordable, thanks to the improved manufacturing processes and cutting-edge embedded designs for TPM. Given these considerations, it makes sense, economically, to install TPM in consumer devices. For example, select tablets and desktops built with Intel’s Bay Trail SoC (System-on-Chip) are shipped with integrated TPM capability; Google’s Chromebook that sells for $250 also has TPM built in. These are lower-cost consumer-grade products.

TPM Overview

What does “trusted” mean in the context of computing? A trusted or trustworthy platform is a platform that behaves in a manner that is expected for its designated purposes. A platform is trusted if and only if the integrity of its hardware, firmware, and software components is proven to be intact. That is, the platform is operating in a state that is identical to what is configured by its manufacturer and other authorized entities.

For a consumer device, there are three angles of trust, depending on the identities of the trusting entity and the adversary, respectively:

  • The owner of the platform needs to trust the platform in order to let it perform sensitive operations. In this case, the adversary is a remote or local attacker, for example, an evil maid2 (see Chapter 6 of this book for a description of the Evil Maid attack).

  • A remote server needs to trust the platform in order to grant it access to premium services. In this case, the adversary is the owner of the platform. For example, wireless carriers may refuse to deliver feature updates or honor a warranty for rooted phones; many companies do not permit employees’ rooted devices to be used for Bring Your Own Device (BYOD) purposes; content providers may ban transmissions of paid contents to devices for which integrity cannot be verified.

  • In a distributed system, a node computer needs to be trusted by its peers. Sensitive operations should not be assigned to a node for which integrity cannot be verified.

The TPM covers these scenarios by employing a dedicated security processor that is isolated from the host firmware and operating system. The TPM device acts as the root of trust for the platform. A trust that is rooted in separate and shielded hardware is generally believed to provide more robust protection and expose a minimal attack surface compared to a software-based root of trust. Notice that the TPM itself is just a library and does not provide security per se; the host firmware and software must invoke the TPM to benefit from its functionalities and establish the trust.

The TPM specification is created and maintained by the Trusted Computing Group (TCG), a not-for-profit organization formed to develop, define, and promote open, vendor-neutral, global industry standards, supportive of a hardware-based root of trust, for interoperable trusted computing platforms. Its members include major hardware and software vendors, such as Intel, IBM, Microsoft, HP, Lenovo, and so on. The first version of the TPM specification was released in 2003. The latest published version is 1.2. The TPM version 1.2 is also published as ISO/IEC standard 11889. The next version is 2.0, which is under public review as of April 2014. The TPM specification is intended to define a standardized interface for hardware-based root of trust for all form factors of computing systems, so that users and remote servers can trust the integrity of the systems with a high level of confidence. In addition to attestation, a TPM also provides fundamental cryptography functionalities, such as random number generation, hashing, key management, and so forth. Since its release, over two billion end-point devices have been shipped with TPM.

It is worth pointing out that there is no such thing as 100% trustworthy computing. Given sufficient time and resources, even hardware such as TPM may be broken by skilled hackers with special tools and applying, for example, side channel attacks and cold boot attacks. However, it is commonly accepted that hardware-based security mechanisms are much harder to defeat than software solutions. The difficulty is due to equipment and skills required for finding and exploiting hardware vulnerabilities. One other important consideration is that it almost always requires a physical presence to compromise hardware. This means that it is rarely possible for remote attackers to infect a large number of devices through widespread viruses. This also means that it is unlikely that an average user can hack his own device by simply following step-by-step instructions or installing malware that is published on the Internet. This limits the scope of impact, even if vulnerability in hardware is found and exploited.

After all, the robustness of the trust protection only has to be such that the expense associated with the effort exceeds the benefit that the attacker may gain from successful exploitations. For most cases, especially consumer applications, a well-designed TPM implementation would satisfy this requirement.

Cryptography Subsystem

The TPM 1.2 specification involves a limited set of cryptography algorithms:

  • Hash and HMAC family: SHA-1 and HMAC-SHA-1.

  • Symmetric encryption family: Vernam one-time-pad3 or AES.

  • Asymmetric encryption and digital signature family: RSA.

  • Random number generator.

The draft of the TPM 2.0 specification published in March 2014 defines a much larger set of cryptography capabilities for its cryptography subsystem:

  • Hash and HMAC family: SHA-1, SHA-256, SHA-384, SHA-512, SM3,4 and their HMAC. The SM3 is the cryptographic hash standard published by the State Encryption Management Bureau of China.

  • Symmetric encryption family: AES and SM4.5 The SM4 is the block encryption standard of China. The Cipher Feedback (CFB) mode is required by the TPM specification, whereas other modes are optional. Note that the CFB mode does not require the size of the plaintext or ciphertext be a multiple of the block size.

  • Asymmetric encryption family: RSA and ECC.

  • Digital signature family: RSA, ECC, and SM2.6 The SM2 is the elliptic curve cryptography standard of China.

  • Key derivation family: NIST (National Institute of Standard and Technology) SP800-56A7 and the counter mode of SP800-108.8

  • Random number generator.

Readers who are not familiar with these algorithms may refer to Chapter 3 of this book for detailed information. A TPM can choose to implement only necessary cryptography algorithms that are applicable to the platform’s use cases. Most cryptography algorithms used by the TPM specification follow existing government and industry standards, such as AES, HMAC, RSA PKCS, and so forth. However, besides leveraging existing cryptography standards, the TPM specification also defines additional cryptography schemes, for example, the modified Schnorr digital signature based on ECC.

For certain standardized cryptography algorithms, the TPM specification may specify additional restrictions and requirements. This deserves special attention from implementers who intend to deliver compliant TPM products. Here are two examples:

  • TPM’s ECC key pair generation should follow NIST’s FIPS (Federal Information Processing Standard) 186-3: Digital Signature Standard, with a small modification. Per FIPS 186-3, the value of resulting private key d should be between 1 and n inclusively, where n is the order of the base point of the selected curve. However, the TPM specification mandates that the lower bound of d be 2nLen/2 instead of 1, where nLen denotes the order of n. This is equivalent to saying that the most significant nLen/2 bits of d cannot be all zeroes.

  • When generating a k-bit RSA key pair, the TPM is required to set the most significant two bits of the two k/2-bit prime candidates p and q to 1, respectively. This is to assure that the bit length of the resulting modulo n = p × q is not shorter than k. Although this is in fact common practice exercised by many implementations, it is not explicitly required by the RSA PKCS standard.


For cryptography algorithms, pay attention to specific requirements mandated by the TPM specification on top of the corresponding cryptography standards.


In addition to the cryptography subsystem, the TPM is also equipped with volatile and nonvolatile memory. The most critical volatile data on the TPM is the PCR (platform configuration register), which stores the platform measurements and is read only to the host. The PCR should not be persistent. Furthermore, secure internal memory is used for runtime operation and must not be visible to the host.

The nonvolatile memory is used for storing TPM secrets, such as primary seeds, endorsement key pairs, and persistent objects created by TPM callers. It must be protected against external access.

Endorsement Key

Unique to the TPM device, an endorsement key is an identity for the Root of Trust for Reporting. The private portion of the endorsement key is stored securely in the TPM’s nonvolatile memory and is never exposed externally. The TPM 1.2 specification requires the endorsement key be used only in two operations—namely, establishing the TPM Owner and establishing Attestation Identity Key (AIK) values and credentials, and it prohibits using the endorsement key for other purposes. Per the TPM 2.0 draft, it is the privacy administrator’s responsibility to control the uses of the endorsement key. The specification still recommends restricting the use of the endorsement key, due to potential privacy concerns. Generally, if a public key is not vouched for by a certification authority, then the privacy concerns are not material. A TPM implementation may create multiple asymmetric key pairs descended from the endorsement key.

The TPM 1.2 specification requires a preinstalled 2048-bit RSA key pair as the endorsement key. The 2.0 version allows multiple endorsement keys to be derived from the endorsement primary seed. For TPM 2.0, the endorsement key can be either RSA or ECC.


The TCG defines attestation as “the process of vouching for the accuracy of information. External entities can attest to shielded locations, protected capabilities, and Roots of Trust. A platform can attest to its description of platform characteristics that affect the integrity (trustworthiness) of a platform. Both forms of attestation require reliable evidence of the attesting entity.” The TPM provides a way to establish the “reliable evidence.”

As briefly discussed in Chapter 6, the PCR carries a critical role in platform integrity measurements, especially during the boot process. A PCR stores the accumulative cryptographic hash of platform components, using the “extend” operation defined as follows, where || means concatenation:

Starting from the Core Root of Trust for Measurement (CRTM), the boot process traverses a series of platform firmware and software. Each component measures the successive component and extends the results to the designated PCR. The control is transferred to the next component after the measurement.

There are two types of measurements using PCR: static and dynamic, as defined by individual platform specifications. PCRs that are configured to hold static measurements are cleared upon only platform power-up and hard reset, whereas PCRs for dynamic measurements may be cleared by the TPM2_PCR_Reset command.

For example, in the server environment, Intel Trusted Execution Technology (TXT) securely measures the following components during boot in seven static PCRs.9 The operating system may use the remaining PCRs of the TPM to perform software measurements specific to the operating system.

  • PCR0: BIOS (basic input/output system) code

  • PCR1: BIOS settings

  • PCR2: Option ROM (read-only memory) code

  • PCR3: Option ROM settings

  • PCR4: Boot sector—master boot record (MBR)

  • PCR5: Boot configuration

  • PCR6: Platform state changes

The entity that requests the attestation may choose to examine any of the defined PCRs according to its usage model and trust policies, but PCR0, which proves the BIOS integrity, is usually examined.

The TPM reports the platform state by quoting PCR values. The platform state report is available to local and remote entities. To assure that the PCR values in a report actually reflect the state of the platform, it is necessary to bind the report to the platform. A common approach is to have the TPM digitally sign the report with one of its asymmetric keys, for example the AIK, for which the associated public key is present in its corresponding certificate signed by a trusted attestation authority. The requesting entity can then use the subject public key in the certificate to verify the TPM’s signature on the state report. The TPM specification encourages the use of domain-specific signing keys for the purpose of signing reports.

Binding and Sealing

Binding refers to the operation of encrypting a caller’s data using a TPM trusted key, which is descended from the endorsement key. Because the TPM that encrypts the data is the only entity that possesses the trusted key, only the same TPM is able to decrypt and retrieve the data, and the data is essentially bound to the platform.

Sealing is similar to binding but poses an additional condition for decryption. The “unseal” (decrypt) operation is allowed only if the platform is in a specified state identified by values in PCRs. The specific state is usually the state when the “sealing” of the data was performed.

A famous example of sealing is full disk encryption. The symmetric key for encrypting the disks can be sealed in the TPM, and unsealed during the boot process only if the integrity of the boot path is verified by measurements in the PCRs. If malware such as a boot kit is detected, then the platform state will be incorrect and the TPM will refuse to decrypt the disk encryption key. The encrypted data on the disk is safe from, for example, the Evil Maid attack.

Intel Platform Trust Technology

The security and management engine shipped with recent Intel platforms, such as Haswell ULT multichip packaging and Bay Trail SoC, features the Intel Platform Trust Technology (PTT). The PTT implements a firmware-based TPM that is compliant to version 1.2.

From an architecture perspective, the TPM is an application running on the embedded engine’s core and communicates with the external world, for example the Windows 8 operating system, through an I/O driver in the embedded kernel. As part of the security and management engine, the firmware-based TPM is inherently isolated from the host. The TPM also benefits from all the security hardening countermeasures implemented on the security and management engine. These hardening features are discussed in Chapter 4. The engine serves as the Shielded Location, as defined in the TPM specification, for the firmware-based TPM.

As described in earlier chapters of this book, the security and management engine runs a collection of firmware applications. Although the actual set of applications installed on the engine varies from product to product, so far, there is no product that hosts only TPM. As a result, to minimize the trusted computing base of the TPM, it is necessary to protect the TPM from being attacked by other internal firmware applications, such as AMT (Advanced Management Technology), in case they are compromised. To achieve this goal, the TPM is placed in an isolated process or task, and covered by the task isolation mechanism. Figure 7-1 illustrates the high-level architecture. Note that the TPM uses internal memory and does not rely on the embedded engine’s capabilities of using the system DRAM (dynamic random-access memory).

Figure 7-1.
figure 1

Block diagram of the firmware-based TPM architecture and its communication with the host

As depicted in the figure, the TPM application consumes and relies on other elements of the security and management engine:

  • Kernel: For nonvolatile secure storage, cryptography algorithms, I/O driver, and security fuse access for endorsement key derivation. The kernel also handles intertask calls from the TPM to the field programmable fuses task.

  • Field programmable fuses task: For programming and sensing a fuse allocated for recording whether the endorsement key in the fuse has been revoked or not. This programmable fuse is a single-bit one-time programming fuse. See Chapter 6 for details.

The TPM is not consumed by other processes or tasks, although this may be supported in the future.

To establish the communication channel between the host and the firmware-based TPM, the BIOS reserves a dedicated I/O buffer during boot. Command calls to the TPM are signaled through system interrupts. The I/O buffer is not protected for confidentiality or integrity.

The design of BIOS setting up the I/O buffer for TPM input and output does not sacrifice security. This is because the I/O buffer is not considered part of the shielded location, and information handled by the TPM is not disclosed to the I/O buffer unless the disclosure is the intent of a Protected Capability. The worst damage that a rogue BIOS can achieve is denial of service, rendering the TPM unusable. However, this does not benefit the host in any way.

Cryptography Algorithms

All algorithms of the TPM’s cryptography subsystem are implemented by the embedded kernel’s cryptography driver. For algorithms on which the TPM specification has special requirements, the TPM module is responsible for satisfying the requirements. For example, when invoking the cryptography driver for generating an ECC key pair, the TPM must test the significant half of the resulting private key d. If the most significant nLen/2 bits of d are all zeroes, a new key pair will be generated and tested.

The RSA key pair generation is a time-consuming operation on the embedded engine. For a 2048-bit RSA, a generation takes an average of 30 seconds. To avoid timing out key generation commands, the TPM implements a cache in volatile memory that holds up to five pregenerated key pairs. When a key pair is consumed, a new key generation will be kicked off in a low-priority thread and the resulting key will fill the empty slot.

Endorsement Key Storage

The TPM on the security and management engine features a preinstalled endorsement key (2048-bit RSA). The endorsement key is required to be unique per hardware part. Because of its uniqueness, the endorsement key cannot simply be hard-coded in the firmware, which is the same on all parts. Instead, hundreds of millions of endorsement keys are pregenerated. During Intel’s manufacturing process, different key materials are burned to the platform’s security fuses for all parts, respectively. Note that key materials are not the key value.

The security fuses are the highest-valued assets of the engine and they can be accessed only from the kernel of the engine. Consequently, the TPM task has to call the kernel’s cryptography driver to retrieve fuse values for the endorsement key materials. The kernel, upon receiving the call, verifies the caller is indeed the TPM task, before fulfilling the request.

Without applying lossless data compression, it takes at least 2080 bits of space to express a 2048-bit RSA key pair—32 bits for public exponent e, 1024 bits for private component p, and 1024 bits for private component q. The value of e can be a constant, say 65537, for all keys and hence hard-coded in the firmware, reducing the number of bits to 2048. Other key components, including the 2048-bit modulus n and the 2048-bit private exponent d, can be calculated from e, p, and q. 2048 is a really large number for the fuse array, which is a constrained resource. Unfortunately, lossless compression can hardly yield satisfying results due to the semi-randomn nature of cryptographic keys. Is there a more efficient approach to store the unique endorsement key in fuses? Intel’s firmware-based TPM uses a patented technique10 to lower the required fuse space.

As described in Chapter 3, the RSA key generation works by generating two large pseudo-random numbers and testing their primality, until two probably primes, p and q, are found. A pseudo-random number generator (PRNG) works by taking a seed and running deterministic heuristics in a loop, until the requested number of bits has been output. The seed is usually much smaller in size than p or q. Therefore, p or q can be represented by the seed and the number of iterations (an integer) that has been run to yield p or q.

Algorithm 7-1 shows the pseudo code for generating a probable prime of 1024 bits using the PRNG proposed in ANSI X9.31 Appendix A.2.4.11 This PRNG is recommended by NIST. This algorithm is implemented by the key generation facility and not the TPM firmware.

Algorithm 7-1. Generation of 1024-bit Probable Prime

Input: None

Output: Key (128 bits), Seed (128 bits), DT (DT < 65536)


Key := rand(128);

Seed := rand(128);

DT := 0


Block_0 := ANSI_PRNG(DT++)

Block_1 := ANSI_PRNG(DT++)

Block_2 := ANSI_PRNG(DT++)

Block_3 := ANSI_PRNG(DT++)

Block_4 := ANSI_PRNG(DT++)

Block_5 := ANSI_PRNG(DT++)

Block_6 := ANSI_PRNG(DT++)

Block_7 := ANSI_PRNG(DT++)

Block_0_fixup := Block_0 | C0000000000000000000000000000000h

Block_7_fixup := Block_7 | 00000000000000000000000000000001h

While DT < 65536

  If (isPrime(Block_0_fixup || Block_1 || Block_2 || ... || Block_6 || Block_7_fixup))



    Block_0 := Block_1

    Block_1 := Block_2

    Block_2 := Block_3

    Block_3 := Block_4

    Block_4 := Block_5

    Block_5 := Block_6

    Block_6 := Block_7

    Block_7 := ANSI_PRNG(DT++)

    Block_0_fixup := Block_0 | C0000000000000000000000000000000h

    Block_7_fixup := Block_7 | 00000000000000000000000000000001h

If (DT == 65536)

  Goto Begin


  Output Seed, Key, and DT

The purpose of Block_0_fixup is to set the most significant two bits of the candidate. The purpose of Block_7_fixup is to make sure the candidate is odd. isPrime(candidate) denotes the Miller-Rabin primality test. isPrime() returns true if candidate is a prime number with high probability, and false otherwise. Function rand(size) returns a random number of size bits. Function ANSI_PRNG_INIT(Seed, Key) initializes an instance of the ANSI X9.31 PRNG in the AES mode with 128-bit Key as *K and Seed as V. Function ANSI_PRNG(DT) runs the PRNG for one iteration and returns a 128-bit random value. After iterating the PRNG once, the value of DT is incremented by one. Essentially, the algorithm attempts to find consecutive 1024-bit number output by the PRNG that is a probable prime after fix-ups.

Note that the preliminary primality test introduced in Chapter 3 for expediting the prime search is not applied to Algorithm 7-1. To take advantage of the preliminary primality test, an extra value, delta, must also be output from the algorithm and stored in fuses for the firmware to recover the generated prime. Because the endorsement key generation is not an online operation, its velocity is not a concern.

The size of integer DT is limited to 16 bits in order to conserve fuse space. Experiments for a large amount of prime generation show that the value of DT output by Algorithm 7-1 rarely exceeds 2000h. The Seed, Key, and DT together can be used to derive the probable prime. The three values are burned to security fuses during manufacturing. The total storage is only 128+128+16 = 272 bits, realizing a saving of as many as 752 bits compared to storing the 1024-bit prime itself. To generate an RSA key pair, the algorithm is executed twice to generate p and q, respectively.

Algorithm 7-2 gives the pseudo code for recovering the probable prime from Seed, Key, and DT. The algorithm is implemented by the TPM firmware. The values of Seed, Key, and DT are read from security fuses by the kernel and provided to the TPM.

Algorithm 7-2. Retrieval of 1024-bit Probable Prime

Input: Key (128 bits), Seed (128 bits), DT

Output: Prime (1024 bits)

i := 0


Block_0 := ANSI_PRNG(i++)

Block_1 := ANSI_PRNG(i++)

Block_2 := ANSI_PRNG(i++)

Block_3 := ANSI_PRNG(i++)

Block_4 := ANSI_PRNG(i++)

Block_5 := ANSI_PRNG(i++)

Block_6 := ANSI_PRNG(i++)

Block_7 := ANSI_PRNG(i++)

While i < DT

  Block_0 := Block_1

  Block_1 := Block_2

  Block_2 := Block_3

  Block_3 := Block_4

  Block_4 := Block_5

  Block_5 := Block_6

  Block_6 := Block_7

  Block_7 := ANSI_PRNG(i++)

Block_0_fixup = Block_0 | C0000000000000000000000000000000h

Block_7_fixup = Block_7 | 00000000000000000000000000000001h

Output Prime = Block_0_fixup || Block_1 || Block_2 || ... || Block_6 || Block_7_fixup

Endorsement Key Revocation

The endorsement key initially placed in security fuses may be revoked by the TPM2_ChangeEPS command introduced in TPM 2.0. In this case, the TPM must generate a new endorsement key pair, store it in nonvolatile memory, and remember not to use the one in the security fuses in the future. The TPM task uses a field programmable fuse for the purpose of saving the revocation status of the endorsement key in fuses.

Endorsement Certificate

The public portion of an endorsement key can be published in an endorsement certificate that is vouched for by a trusted certification authority. The certificate may be shipped together with the endorsement key. Size-wise, a typical X.509 certificate with a 2048-bit RSA subject key and a 2048-bit signature can be as big as approximately 1KB. An ECC certificate is smaller but its size is still in the scale of a few hundred bytes. Some TPM implementations do not have the luxury of storing the endorsement certificate on the device.

Fortunately, the TPM specification does not mandate the endorsement certificate be installed on the device. An alternative design is to have the external requesting entity (for example, operating system, service provider, and so forth) obtain the endorsement certificate from an online server. The server is linked to a database where all TPM endorsement certificates are stored. When an endorsement key is revoked, its certificate will no longer be available from the server. Notice that this flow is between the requesting entity and a server, and does not involve the TPM device at all.


For a pregenerated and preinstalled endorsement key, the corresponding endorsement certificate does not have to be stored on the TPM device.

Supporting Security Firmware Applications

For TPM, locality is defined to be the privilege level of a command. When a TPM session is established, the locality associated with the session is specified. Future access to the object must be made at the specified locality. The TPM version 1.2 defines five localities 0–4. The TPM 2.0 draft introduces extended localities 32–255. The TPM interface is responsible for determining the locality each time the TPM is accessed.

For the security and management engine, the extended localities are useful for identifying communications between the TPM task and other firmware applications that may benefit from the TPM capability. The communication is through the kernel’s intertask manager and the call can be placed at locality 32 from the TPM’s perspective, for example.

Figure 7-2 illustrates the conceptual idea of using extended localities to support internal firmware applications. Let us see a hypothesis example. A secure server encrypts a secret with one of the firmware-based TPM’s asymmetric public keys and sends the encrypted secret (a data object) to the TPM at a basic locality. The data object will be accessed from locality 32. The TPM imports the object, performs decryption, and now possesses the clear secret. The firmware task designed to process the secret can then retrieve the secret from the TPM task at locality 32. The TPM interface for extended localities is guarded by the kernel’s intertask call manager. Intertask calls are internal to the security and management engine, and the host has no way to peek. Also, only TPM, the consuming task, and the kernel are involved in the process. Other firmware tasks are not able to steal the key, thanks to the task isolation mechanism.

Figure 7-2.
figure 2

Using extended localities for internal security applications

Integrated vs. Discrete TPM

Traditionally, the TPM is implemented as a physically discrete hardware component and connected to the platform via a hardware bus; for example, the LPC (low pin count) bus or SPI (serial peripheral interface). Many personal computers and laptops feature discrete TPMs. The following are two benefits of using a discrete TPM:

  • Easy integration and maintenance: A discrete TPM can be physically disconnected from the platform for debugging and testing. A malfunctioning TPM device can be replaced without impacting the rest of the platform.

  • Better security: The isolation between the TPM and the host is physical, and the TPM device is not co-located with any other devices or functionalities. Compared to an integrated TPM, a well-designed discrete TPM can be certified at a higher FIPS 140-212 level and the Common Criteria’s evaluation assurance level13 (EAL).

Contrary to popular belief that discrete TPM provides better security, older versions of discrete TPM are vulnerable due to dependencies on the physical bus. For example, the LPC bus reset attack14 against TPM version 1.1 demonstrated by researchers of Dartmouth College works by resetting the LPC bus and clearing the PCRs of the TPM on the LPC bus, without resetting the platform. This flaw that allows a simple hardware attack was addressed in TPM 1.2, for which a similar attack would require expertise and special hardware.

In addition, discrete TPMs also have drawbacks with regard to deployment—for example, development effort, BOM (bill of materials) cost, and onboard space required for installation, just to name a few. For small form factors such as a smartphone, these shortcomings are critical considerations.

In recent years, the integrated TPM has come into play. In contrast to the discrete TPM, an integrated TPM is implemented inside an existing platform component. For example, Intel’s firmware-based TPM is a module of the security and management engine, and logically isolated from the other modules of the engine. ARM’s TrustZone may also realize TPM functionalities in its secure mode. The obvious advantage of an integrated TPM is the virtually zero BOM cost. Security-wise, it is generally believed that the robustness of an integrated TPM is not as good as a discrete one. That said, for price-sensitive markets, such as consumer electronics, an integrated TPM provides a balanced solution between affordability and security.


  1. 1.

    Trusted Computing Group, “Trusted Platform Module Library,” , accessed on March 20, 2014.

  2. 2.

    Joanna Rutkowska, “Evil Maid goes after TrueCrypt,” , accessed on March 20, 2014.

  3. 3.

    Gilbert S. Vernam, “Cipher Printing Telegraph Systems for Secret Wire and Radio Telegraphic Communications,” Journal of the IEEE 55, pp. 109–115, 1926.

  4. 4.

    State Encryption Management Bureau of China, “SM3 Cryptographic Hash Algorithm,” standard publication GM/T 0004-2012, , accessed on April 15, 2014.

  5. 5.

    State Encryption Management Bureau of China, “SM4 Block Cipher Algorithm,” standard publication GM/T 0002-2012, , accessed on April 15, 2014.

  6. 6.

    State Encryption Management Bureau of China, “Public Key Cryptographic Algorithm SM2 Based on Elliptic Curves,” standard publication GM/T 0003-2012, , accessed on April 15, 2014.

  7. 7.

    National Institute of Standards and Technology, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography,” , accessed on April 15, 2014.

  8. 8.

    National Institute of Standards and Technology, “Recommendation for Key Derivation Using Pseudorandom Functions,” , accessed on April 15, 2014.

  9. 9.

    William Futral and James Greene, Intel Trusted Execution Technology for Server Platforms: A Guide to More Secure Datacenters, Apress, 2013.

  10. 10.

    Daniel Nemiroff, “Cryptographic Key Generation Using a Stored Input Value and a Stored Count Value,” US patent 20100329455 A1.

  11. 11.

    American National Standards Institute, “Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA),” ANSI X9.31-1988, September 1998.

  12. 12.

    National Institute of Standards and Technology, “Security Requirements for Cryptographic Modules,” , accessed on April 15, 2014.

  13. 13.

    Common Criteria, , accessed on April 15, 2014.

  14. 14.

    Dartmouth College, PKI/Trust Lab, “TPM Reset Attack,”∼pkilab/sparks/ , accessed on April 15, 2014.

Author information

Authors and Affiliations


Rights and permissions

Open Access This chapter is licensed under the terms of the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License (, which permits any noncommercial use, sharing, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence and indicate if you modified the licensed material. You do not have permission under this licence to share adapted material derived from this chapter or parts of it.

The images or other third party material in this chapter are included in the chapter’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the chapter’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

Reprints and Permissions

Copyright information

© 2014 Xiaoyu Ruan

About this chapter

Cite this chapter

Ruan, X. (2014). Trust Computing, Backed by the Intel Platform Trust Technology. In: Platform Embedded Security Technology Revealed. Apress, Berkeley, CA.

Download citation