Intel® vPro™ Technology

Advanced Security Features of Intel® vPro™ Technology

Advanced Security Features of Intel® Active Management Technology (Intel® AMT)

We now cover some of the more advanced hardware and firmware security features, built into Intel® AMT, that were not in its first version: these features were added to the later version to make Intel AMT more secure and resilient to attacks. The new hardware includes new features, such as a true random number generator (RNG), secure storage of sensitive data, a measured launch of Intel AMT firmware, and secure audit logging.

True Random Number Generator
Many cryptographic algorithms and mechanisms make use of random numbers, including several of the Intel AMT mechanisms described previously. The important feature of RNG is its entropy, that is, the measurement of the inability of an external viewer to predict the next number that will be generated by the RNG, even if the viewer knows all the previously-generated random numbers by that generator. Many implementations use a pseudo-RNG (PRNG), a deterministic algorithm that produces the next random number based on the current generator’s state. These algorithms maintain a high level of entropy, as long as the initial state (also called “the seed state”) of the PRNG is not known [6]. For example, some PRNG implementations seed themselves according to the value of one of the platform clocks. This value is considered to be fairly unpredictable (due to the high resolution of the clock), and therefore makes a good seed for the PRNG. However, given that a large number of platforms power up at the same time, a time that may be known to within a few minutes or seconds, this could help a potential attacker to narrow down the possibilities and therefore crack the PRNG seed state, thereby predicting the next numbers generated by the PRNG. Conversely, an attacker could learn from the numbers generated by one hacked platform to break other platforms in the enterprise (known as a BORE attack: “Break Once, Run Everywhere”).

Intel® vPro™ technology contains a true random number generator (TRNG) hardware device (see Figure 2). The TRNG is based on two resistors that produce a thermal noise. The noise is amplified and provided as input to a frequency-modulated, low-frequency oscillator. Combined with a high-frequency oscillator, a nearly-random bit stream is produced. A voltage regulator controls the above hardware components to avoid any bias based on voltage. In addition, a logic block attempts to correct the bit stream of any bias that may have been inserted (for example, due to the non-perfect duty cycle of the oscillator), by using a standard anti-bias correction algorithm.

Figure 2: True Random Number Generator hardware
Source: Intel Corporation, 2008
click image for larger view

One reason not to use a TRNG for Intel AMT usages (such as in TLS) is that a TRNG takes relatively longer than a PRNG to generate random bits. In reality, Intel AMT uses a PRNG whose state is occasionally reset to a state generated by the TRNG. This creates a powerful high-quality RNG that is able to keep up with the high usage of random numbers in the Intel AMT subsystem.

Secure Storage of Sensitive Data–Blob Service
As mentioned earlier, the flash part contains the configuration data for Intel AMT, which stores some of the Intel AMT secrets. The flash controller prevents software applications and drivers running on the host processor from accessing the flash part. However, an attacker may be able to steal a platform, pull out the flash, and read its contents by using a flash reader. In this way, an attacker could secure a backdoor to the enterprise network by reading the secrets, or even modifying them before returning the flash to the compromised system.

The Blob Service is a firmware mechanism that allows for protection of sensitive data on the flash part. The pieces of information protected by the Blob Service are called blobs. In this context, protection of a blob may take the following forms:

• Encryption to prevent the attacker from reading the content of the blob.
• Integrity to prevent the attacker from modifying the content of the blob.
• Anti-replay to prevent the attacker from reading an encrypted/integrity-protected blob (with a value known to the attacker), and later reusing it as-is while overriding a value unknown to the attacker.

Chipset Key
Encryption of secrets is achieved by using standard encryption techniques, but the interesting feature is the key that is used for the encryption. The encryption key needs to be stored in some non-volatile form, but the flash itself is obviously not a good place to store it (otherwise the attacker would first read this key from the flash and then use it to decrypt the rest of the protected data on the flash). Rather, the Intel AMT hardware contains a key that is unique to each system, and it is known to the Intel AMT firmware only. This key is called the chipset key.

The chipset key is actually a set of 128 fuses. Each fuse can be blown or un-blown, corresponding to a 0 or 1 value. The 128-fuse-set thus creates a 128-bit encryption key.

The status of each of the fuses (0 or 1) is determined at manufacturing. A random subset of the fuses is blown on the chipset manufacturing line, while the rest remain un-blown. Thus, a random unique value is created for each chipset.

A similar technique is used to generate the integrity key for the integrity part of the Blob Service.

Monotonic Counters
The Intel AMT hardware contains a few registers that implement simple counters. The counters are incremented by the firmware. Those registers are unique in the sense that they are powered by the platform coin battery (also known as the RTC battery, as it powers the platform Real Time Clock). Therefore, the counters retain their value as long as the battery is functional, which typically is for a few years.

To implement anti-replay, the value of the counter is incremented, then appended to the blob before applying the integrity algorithm. When the blob is read by the firmware, the value of the counter in the blob is compared to the value in the register. If they match, only then is the value considered valid. As long as the counter register is not reset (either by wraparound of the counter or by the replacement of the coin battery), the value of the counter is unique and therefore the anti-replay is achieved.

The algorithm described here requires a separate hardware register for each blob that needs to be anti-replay protected. In fact we can take this method one step further. Only one blob (let us call it the counter blob) in the system will be protected by one hardware counter only. But the counter blob can contain counter values for other blobs. Whenever an anti-replay protected blob is modified, its private counter is incremented; this means that the counter blob is modified, which requires incrementing the hardware counter. Therefore, the counter blob helps us reduce several counters to a single counter, maintained by the hardware and protected by the coin battery.

When the battery is replaced, the anti-replay protected blobs are invalidated. In some cases, this will require the user to reinsert some of the secrets protected by the anti-replay blob service.

Note that we assume that every anti-replay protected blob is also integrity-protected. This assumption makes perfect sense: an anti-replay blob contains a unique value that prevents it from being replayed. If the blob is not integrity-protected, the unique value can be modified, and therefore the anti-replay quality is also lost.

A sample list of data blobs protected by Intel AMT, by using the Blob Service, is given in Table 1.

Table 1: Sample list of data blobs

Intel® AMT Data Structure	Encrypted	Integrity Protected	Anti-Replay Protected
Usernames and hashed passwords	No	Yes	No
Permissions and Access Control Lists	No	Yes	No
Certificates	No	Yes	No
Kerberos keys and attributes	Yes	Yes	No
Private portions of Asymmetric Key Pairs	Yes	Yes	No
Integrated TPM secrets	Yes	Yes	Yes

Measured Firmware
Someone not familiar with the concept of measured launch may ask what it means, and why it is necessary. We begin by trying to answer these questions. We would love to be able to say that the Intel AMT firmware is free of design and implementation bugs. The reality is that there is no such thing as bug-free code. Even some of the most critical systems, such as airplane cockpit software or air-traffic control software, have been known to have flaws. Therefore, the entire computer industry depends on a perpetual cycle of bug-fixing and software updates (also known as patches) to fix the known flaws. By doing this, we eliminate the known flaws at least. However, finding new vulnerabilities is not an easy task. Attackers (and researchers, who are good guys) spend a lot of time reverse engineering software to discover new flaws. The most common way of compromising software is to attack it by using malware: malware makes use of known vulnerabilities in a system, usually a system that has not been kept up to date with patches. It is, therefore, very important to keep any software updated with the latest updates, especially the security updates.

What’s even worse is the inability to be able to know which version of the software is running. Bugs in the design or code make the software vulnerable to being exploited by malware. The first thing the smartest malware tries to do is to hide itself.

Software running on the host processor, such as the BIOS or virtual machine monitor (VMM) loader, needs to be able to measure any code running on the platform. This measurement can be used to find out if every piece of code running on the platform can be found on a “whitelist” (a list of accepted versions) of software that was previously verified by the platform owner [7].

The existing features in the chipset that come closest to providing this functionality are the firmware signing and flash protection mechanisms discussed earlier.

As stated, the Intel AMT processor verifies the firmware signature at initialization time, by using the verification logic in the ROM code, and the measurement done during the signature verification process is not recorded anywhere in the platform for subsequent evaluation. Therefore, the host processor has no role to play in this verification, thereby leaving the host-based VMM loader or the BIOS with no capability to assess the validity of the firmware at any later point in time, after the platform powers on. Consequently, the host software cannot enforce any policy that depends on the evaluation of the Intel AMT firmware measurement to enforce certain system behavior.

The other problem with signed firmware images is that all images (belonging to a particular chipset generation) are valid on that chipset, because they are signed by the Intel code-signing private key (the corresponding public key being embedded in the ROM). Therefore, the existing firmware signature verification mechanism makes no distinction between the various versions of the firmware images that may have been produced by Intel for that product generation/family.

The Intel AMT firmware measurement mechanism solves these issues by providing a direct mechanism for reading the firmware measurement, by using host-based software (such as BIOS, VMM Loader, OS, or OS agent), without imposing the burden of the knowledge of firmware address location or offsets in the flash, on the host software. The design of the architecture ensures that the measurement is always completed, recorded, and locked inside the Intel AMT processor, before Intel AMT firmware execution begins. This measurement is also available while the Intel ME is powered on. Therefore, it is not possible to overwrite this measurement value after Intel AMT firmware execution begins. This aspect of the firmware is guaranteed by the hardware of the Intel AMT processor. So, even if there is a vulnerability (known or unknown) that somehow exists in the Intel AMT firmware, it is impossible for malware to exploit this vulnerability and thereby modify the previously-recorded measurement value. By definition, the measurement will be different for each firmware version, thereby giving the host a mechanism to cryptographically assert the measurement of the firmware image. The Intel AMT firmware measurement value is readable by the host software (such as BIOS, or VMM Loader) via the PCI configuration space of the Host Embedded Controller Interface (HECI) device (the Intel AMT processor is visible to the host OS as a HECI device).

Back to Top