Intel® vPro™ Technology

Advanced Security Features of Intel® vPro™ Technology

Security Overview

This section describes the protections available in Intel® Active Management Technology (Intel® AMT) from its very first generation. These constitute protections such as isolated execution, code integrity, storage protection, network security, authentication, and access control.

Isolated Execution Environment
Intel AMT runs on an internal processor integrated into the platform chipset. The firmware code for Intel AMT is stored on internal Read Only Memory (ROM) in the chipset, and on a portion of the platform’s nonvolatile flash memory device (simply referred to as flash). The flash also contains the nonvolatile configuration data for the Intel AMT firmware.

The Intel AMT processor uses some Random Access Memory (RAM), internal to the chipset, for runtime storage; however, most of the runtime storage comes from an area in the platform Dynamic RAM (DRAM), called the Unified Memory Architecture (UMA). The integrated DRAM controller, once it is configured properly by the system Basic Input/Output System (BIOS), ensures that the host does not have read and write access to the UMA region of system memory. (The host in this case refers to the main platform processor and OS software that are visible to the end user, for example, the Intel® Core™2 Duo processor, and Windows Vista*, respectively.)

All of the above ensure that the Intel AMT processor has an isolated execution environment: when using platform resources, the processor maintains a closed system that does not interfere with the operation of the main platform, and cannot be intruded upon by the OS and software applications running on the main processor.

Firmware Signing
The Intel AMT processor begins its execution from the internal ROM. The content of the ROM is determined before the Intel® chipset is manufactured and is created as part of the chipset. Since the ROM code cannot be modified after the chipset is manufactured, the ROM code makes an appropriate root of trust for the Intel AMT subsystem.

The bigger portion of the Intel AMT code is located on the platform flash. The ROM code is responsible for loading the code from the flash, only after verifying its authenticity. This process ensures that only authentic code produced by Intel is loaded onto the Intel AMT processor.

The signing method for the flash code is based on public/private key cryptography. The private part is kept safely in Intel’s data centers. When Intel produces a firmware version for Intel AMT, a digital signature for the code image is produced in the signing facility (within one of Intel’s data centers) by using the private key. This digital signature is then stored on the production platform flash, along with the firmware code. The corresponding public key is embedded in the ROM code. When the ROM loads, it uses the public key to verify that the signature on the flash matches the code it is about to load. Only if the signatures match, will the ROM load the code onto the flash.

A similar process occurs during the firmware update process (a process to update the firmware from an older version to a newer version). Each updated firmware image, which may be publicly available and also placed on the website of the original equipment manufacturer (OEM), is also signed by using the Intel private firmware signing key, as explained earlier. The Intel AMT processor will update the code on flash, only if the image is properly signed.

Flash Security
The platform flash part is shared among various platform consumers. It contains the Intel AMT code and data (including secret/sensitive data such as keys and access control lists), and also the BIOS code and other platform configuration parameters. It is important to make sure that the Intel AMT portion (code and data) is accessible only to the Intel AMT processor.

At the beginning of the flash (that is, at address 0) there is an area called the flash descriptor. This area describes the partitioning of the flash into regions, and defines the owner of that region (see Figure 1). The flash controller is responsible for enforcing the partitioning of the flash according to the contents of the flash descriptor. This ensures that the Intel AMT region of the flash is accessible by the Intel AMT processor only.

Figure 1: SPI flash partitioning and region owner
Source: Intel Corporation, 2008

The flash descriptor also contains the access capabilities to the flash descriptor itself. If the flash descriptor remains open to write operations, the protection on the other regions is of course useless. Therefore, at the end of the manufacturing process, the OEM must lock the flash descriptor region. From that point on, it cannot be rewritten. This precludes any possibility of access to the flash from regular host-based software.

However, certain situations require the flash to be rewritten: for example, if an error was made during manufacturing, or if the platform was returned to the manufacturer. In these situations, a physical jumper may exist on the platform motherboard to override the flash descriptor. When this jumper is set, the flash controller ignores the contents of the flash descriptor and allows writing to all regions of the flash.

Network Security
The Intel AMT firmware implements standards-based network security. This approach increases the ability of the enterprise IT administrator to use Intel AMT in a secure manner by using standards-based software, thereby avoiding any compatibility issues.

Access to Intel AMT through the network is based on the Hypertext Transfer Protocol (HTTP). The HTTP enables the HTTP server (the Intel AMT subsystem in this case) to require the client (the management console) to identify itself in some way, before providing the service. Intel AMT supports two forms of identification. The first is called “HTTP digest”: it requires the HTTP console to supply a username and a password as forms of identification [1]. As the name implies, the password is passed in a “digested” form, that is, hashed, such that it is not visible to a network eavesdropper [2]. The second form of identification is called “HTTP Negotiate” [3]. HTTP Negotiate can be based on various authentication protocols, such as NTLM, and Kerberos. Intel AMT supports Kerberos-based HTTP Negotiate. This form of identification is specifically suited to (but not limited to) Microsoft Active Directory* domains. HTTP Negotiate requires the management console to retrieve a Kerberos ticket from the Active Directory server; the ticket encapsulates the details of the administrator (his or her username and the Active Directory groups he or she belongs to), and it signs them with a key known only to the HTTP server.

The Intel AMT firmware holds an Access Control List (ACL). Each entry in the ACL contains a HTTP Digest username/password pair, or a HTTP Negotiate Active Directory user. The ACL entry also contains the list of resources and features in the Intel AMT subsystem that this specific user has access to. In both forms, the Intel AMT platform first checks that the user is authenticated; it then checks that the user is authorized to access the specific resource/feature; and only then does it act on the specific user request.

The Intel AMT subsystem also allows the use of secure HTTP (HTTPS) to ensure the confidentiality of the contents of the message. In this mechanism, HTTP is implemented on top of the Transport Layer Security (TLS) protocol, rather than on top of the plain Transmission Control Protocol (TCP) [4]. TLS allows encryption and integrity-protection of all messages from the client to the server and back, PKI-certificate-based authentication of the server to the client, and optional certificate-based authentication of the client to the server.

In addition, Intel AMT supports some advanced methods of network security, such as link-layer authentication, by using 802.1x (especially useful in WiFi* networks), and client compliance, by using Network Access Control (NAC) mechanisms.

All of these methods are optional; it is up to the IT administrators to determine the required network security level for their manageability/security requirements. Many of the options mentioned require some backend infrastructure and maintenance mechanisms to be supported by the IT: for example, a periodic replacement of all secrets provisioned onto the Intel AMT platform.

It should also be noted that the initial configuration of the secrets provisioned onto the platform with Intel AMT is itself performed in a secure manner. A detailed explanation of the provisioning process can be found in “Intel AMT Configuration” [5], which also appears in this issue of the Intel Technology Journal.

Back to Top