Intel® vPro™ Technology

Configuring Intel® Active Management Technology

Asymmetric Key Method (Remote Configuration) Detailed Flow

Preparation
In this flow, Intel® Active Management Technology (Intel® AMT) acts as a TLS server, and the configuration server acts as the TLS client. Since we depend on a mutually-authenticated TLS, both parties require private and public RSA key certificates. Intel AMT generates a 2048-bit modulus-based RSA key pair early in its lifetime, creates a self-signed X.509v3 [13] certificate for this key pair, and stores the certificate and private key in the non-volatile flash memory associated with Intel AMT. The enterprise IT administrator obtains a TLS certificate from an Intel AMT partner Certification Authority (CA). Intel has partnered with some of the leading CAs to streamline the process for obtaining certificates for Intel AMT configuration. The Intel AMT firmware image comes pre-configured with cryptographic hashes of the root certificates of these partner CAs (VeriSign*, Comodo*, GoDaddy*, and Starfield*). Since these certificate hashes are part of the firmware image, they provide a pre-configured root of trust for verifying configuration server certificates. The only reason why we chose to store a hash of the root certificate and not the entire root certificate itself is to save storage space on the nonvolatile flash memory. A full certificate could run into a few kilobytes of space, whereas a Secure Hash Algorithm (SHA-1) [14] of the certificate requires just 20 bytes of storage.

Having done the preparation, we now delve into the actual mechanics of the configuration protocol. In the scenario we present, initial Intel AMT configuration takes place at any given time, assuming the host OS is already operational. We define this scenario as the delayed configuration scenario. Delayed configuration caters to both the direct shipment and the IT staging area deployment strategies, mentioned earlier in the “Client System Deployment Strategies for IT” section of this article.

Remote Configuration Flow: Phase I

Figure 3: Intel® AMT remote configuration–Phase 1
Source: Intel Corporation, 2008
click image for larger view

Figure 3 outlines the initial phase of the flow. To start with, Intel AMT is at the un-provisioned state: its network interface is disabled, effectively disabling any remote configuration attempts; the local host to the A communication channel, known as the Intel® Management Engine Interface (Intel® MEI), is enabled. A local host software agent can detect the state of Intel AMT, by using the Intel MEI, and then can upload device information to the configuration server. The information includes the firmware version, the installed root certificate hashes, and whether the device is configured to operate in PSK or Asymmetric Key provisioning mode. In this scenario we assume it is the latter.

Next, the configuration server instructs the agent to enable remote configuration of Intel AMT, and it provides the agent with a One-Time-Password (OTP). The role of the OTP will become clearer when we explore Phase 2 of the protocol. The agent then sends the “enable remote configuration” and the “store One-Time-Password” commands to Intel AMT. Once Intel AMT enables remote configuration, it enters Phase 2 of the protocol, in which the configuration server communicates directly with Intel AMT via the Out-Of-Band (OOB) channel. Phase 2 is described next.

Remote Configuration Flow: Phase 2

Figure 4: Intel® AMT Remote Configuration–Phase 2
Source: Intel Corporation, 2008
click image for larger view

In Phase 2 of the configuration flow, the configuration server and Intel AMT establish a TLS session between them (see Figure 4). This phase commences when the configuration server opens a TLS session with the Intel AMT device. As part of the TLS handshake, Intel AMT sends its self-signed certificate. In Step 1 in Figure 4, the configuration server skips the verification of the self-signed certificate. However, the server requires the public key embedded in it to successfully complete the TLS handshake with Intel AMT. Next, the configuration server sends the entire TLS certificate chain (including the root certificate) to Intel AMT. In Step 2 Intel AMT validates the configuration server, based on the information provided in the certificate chain. This process entails validating three main areas:

• Certificate chain validation. Intel AMT verifies the entire certificate chain, first by verifying that the root certificate is a trusted one. This is done by calculating its hash and comparing the hash with the ones stored in the firmware image. Subsequently, Intel AMT verifies the rest of the certificates in the certificate chain, following the validation procedures described in Section 6.1 of RFC 5280 [15].
• Configuration server identity. The identity of the configuration server is provided in the Certificate Subject’s Common-Name (CN) field. To verify the authenticity of the Fully-Qualified-Domain Name (FQDN) presented in the configuration server certificate, Intel AMT obtains the name, assigned by the Domain Name System (DNS) of the network it is in, by querying the Dynamic Host Configuration Protocol (DHCP) server for DHCP Option 15. Per the DHCP options RFC [16], Option 15 specifies the domain name the client should use when resolving hostnames, via the DNS.
• Certificate usages. Intel AMT first confirms that the certificate includes both “TLS Client” and “TLS Server” roles. This guarantees that the CA issuing the certificate has verified the certificate applicant is associated with the name appearing in the CN field, as is the case for standard TLS certificates used on the Internet. Next, Intel AMT checks a particular qualifier in the certificate, specifically indicating this certificate is meant for Intel AMT configuration. When submitting a request to a partner CA, the IT administrator must explicitly require this qualifier, as Intel AMT will not accept any certificate that does not have this qualifier. The qualifier can be one of two types:
• A well-defined usage Object Identifier (OID). This OID is defined and registered as an OID to denote it as an Intel AMT configuration certificate. The OID value is 2.16.840.1.113741.1.2.3.
• A well-known string in the Subject’s Organization Unit (OU) field. The string is “Intel AMT configuration server certificate.”

If the aforementioned validation steps are successful, the parties complete the TLS handshake. Finally, the configuration server requests the OTP value, mediated through the host agent in Phase 1, and compares this value with the locally-stored OTP value. If the two values are identical, the configuration server has successfully authenticated the Intel AMT device.

At this point in the protocol, both the configuration server and Intel AMT have established a mutually-authenticated and confidential channel through which subsequent configuration commands can flow.

Note that the protocol does not require any manual configuration of the Intel AMT system (no one has to touch the machine), which is a key requirement for many enterprises. Still mal-configuration is quite difficult as it would require an attacker to gain access to the Intel AMT device in two ways: (1) intrude into the local OS, and (2) control the enterprise DHCP infrastructure.

Configuration Hardening Through a One-Touch Operation
Intel AMT offers additional means to harden the protocol, as some enterprises have IT policies that they need to comply with, and the remote configuration protocol does not fit fully within the constraints of those policies. For such customers, the security of the configuration process can be further strengthened so long as these customers are willing to touch the Intel AMT machines and configure some parameters into the Intel AMT subsystem. The mechanisms to configure these parameters via a one-touch operation are these:

• Manual. IT technicians can type in configuration parameters through the Intel® Management Engine BIOS Extension (Intel® MEBX) user interface.
• Semi-automated. IT technicians can use an ISV application to create a configuration information file and store it on a USB thumb-drive. A technician can then repetitively plug the USB thumb-drive into a machine with Intel AMT. Once the machine is powered-up and the Intel MEBX logic executes, Intel MEBX detects the presence of the thumb-drive with configuration information. Intel MEBX then applies the settings to the Intel AMT system. The USB configuration file specification is provided in the Intel AMT SDK. The USB thumb-drive method offers increased convenience and scalability relative to the manual method. Typically, this method can be used for small to medium businesses, or in an IT environment in which PC client deployment is performed in an IT staging area. However, this automated method is not cost-effective if direct shipment to the end-user is involved.
• Negotiating with a system manufacturer to configure the parameters at the time of manufacturing. This method is more likely to be used when dealing with a large enterprise customer that orders a fairly substantial number of machines and negotiates with the manufacturer to configure the settings on the computers on the manufacturing line. This saves the customer from having to configure the settings into the machines. We do not go into the economics of this method in this article.

Once the IT has chosen one of the above mechanisms, the following parameters related to the Asymmetric Key configuration are available:

• Use of an enterprise root CA. Suppose an enterprise policy disallows trusting a commercial CA for root of trust; company policy only allows for the enterprise’s own root of trust. In this case, the enterprise IT administrator can configure Intel AMT with the designated enterprise root certificate hash and disable all existing pre-configured partner CA roots. The configuration server will then have to use a certificate issued by this enterprise CA, instead of any other CA. This mechanism completely cuts off an attacker from being able to attack the configuration process of Intel AMT, because the attacker needs to have access to the CA infrastructure of the enterprise, which is usually a very heavily guarded asset.
• Specify a trusted pre-configured DNS suffix. A domain suffix can be configured into the non-volatile flash memory of the Intel AMT subsystem (by using one of the aforementioned one-touch operations). If this domain suffix is configured into the nonvolatile flash memory, then Intel AMT does not use DHCP Option 15 to learn the network’s domain suffix. Instead it uses the configured domain suffix validating the FQDN presented in the configuration server certificate. This eliminates vulnerabilities that are due to a compromised DHCP infrastructure. It also allows configuration in environments where the DHCP infrastructure does not support Option 15.

Configuration Audit Record
Once the device with Intel AMT establishes trust with the configuration server, it creates a configuration audit record, recording the configuration TLS certificate details and additional parameters. This record is subsequently locked down to prevent any further modifications, but it is still available for being read via the local Intel® Management Engine (Intel® ME) Interface as well as through the Intel AMT WS-MAN interface. Since the record is read-only it allows policy enforcement applications to detect occurrences of unauthorized configuration and use of Intel AMT systems.

Back to Top