I've been fielding an increasing number of requests to help others understand Intel® AMT Remote Configuration, formerly known as Zero Touch Configuration (ZTC). This article will provide a preview of what Remote Configuration is, key items needed, how it works, and address some key questions.

With Remote Configuration (not yet available for production environments) some details may be light for now, yet will be further explained and validated once this configuration option is released. Before proceeding further, a base understanding of the current TLS-PSK, or pre-shared key, configuration approach is recommended. Please review http://www.symantec.com/connect/node/1673.

The Remote Configuration process is done remotely without physically touching the client before or after deployment, hence the name. The process involves certificates, certificate hashes, updates to drivers, software, and firmware, and more. Similar to the existing TLS-PSK configuration approach, Remote Configuration performs the task of preparing the Intel® AMT management engine to send and receive webservice calls within a production environment. Both approaches will be supported in Intel® AMT platforms going forward.

Before addressing a common question of "Why provision now when remote configuration will allow us to deploy the Intel® AMT system now and configure them later?" - let us first understand more about Remote Configuration.

Remote Configuration Availability

The target Intel® AMT platform for Remote Configuration is codenamed Weybridge. This is the second generation of the Intel® vPro™ technology platform, which will use the AMT 3.0 firmware. These desktop systems are expected to be released in the late August timeframe by the OEMs. After the Weybridge release, Remote Configuration will be added to the current Intel® vPro™ technology platform along with the current Intel® Centrino® Pro platform. These were codenamed Averill and Santa Rosa, and will require AMT 2.2 and AMT 2.6 updates respectively. Understand that Intel provides the firmware and driver update package to OEMs who decide whether they will integrate into their associated driver and BIOS\firmware update packages. Since AMT 2.2 and 2.6 releases after AMT 3.0, it may be best to validate with the OEMs on what packages they plan to support. (Hint: The list is growing - yet can't be stated publicly at the moment.)

Key Items Needed

Remote Configuration addresses an interesting challenge - how to establish a trusted connection between the ProvisionServer and the Intel® AMT management engine without touching the client system. The TLS-PSK approach requires a pre-shared secret to be entered, which requires someone to physically touch each system.

The following list provides an overview of components and environment configurations required for Remote Configuration, with the following section addressing the process including how each item is utilized.

• DHCP is required, with option 15 enabled and configured. This will return the DNS suffix with the IP lease. The DNS suffix will be used in validating the configuration certificate.
• An Intel® Client Setup Certificate must be obtained, and associated with the ProvisionServer. In multiple ProvisionServers due to different DNS domains, one certificate per each is needed. More on this certificate will be shared later in this article.
• An OEM update package must be obtained for the Intel® AMT firmware, the Management Engine Interface (MEI) drive and Local Management Service (LMS) driver.
• An OEM platform with certificate hashes embedded in the non-volatile RAM of the Intel® AMT management engine, or the ability to update per the previous item.
• An updated Altiris client agent must be obtained, which will support the Remote Configuration process to allow agent initiation.
• An updated Intel® Setup and Configuration Service (SCS) is required within the ProvisionServer. Intel® SCS is embedded inside the Altiris OOBM. A version greater than 3.0 of Intel® SCS is required. (Hint: A quick check of the AMTconfig service will reveal the version number of SCS.)

As mentioned previously, the list of OEMs is growing for support of Remote Configuration on current Intel® vPro™ and Centrino® Pro platforms. This applies to the AMT 2.2 and 2.6 releases. The next generation of Intel® vPro™ (codenamed Weybridge) will be released in late August and will be the first to include Remote Configuration natively. Please consult with your preferred OEM to confirm their respective plans.

How Remote Configuration Works

Two approaches are included in the design: Agent Initiated and Bare-metal. AMT 3.0 will support both. AMT 2.2 and 2.6 will support only Agent Initiated.

The initial actions and communications occur during a preparation stage which is unique between the agent initiated and bare-metal approaches. The preparation phase ends with a hello packet sent to the ProvisionServer announcing the Intel® AMT client request for a remote configuration session. Next is a two-way authentication stage between the ProvisionServer and the Intel® AMT client for the setup of a mutual transport layer security (MTLS) session. Once the MTLS session is established, a valid FQDN and UUID map is obtained, the configuration process commences and the assigned Intel® AMT profile is sent to the client. The following subsections provide some additional detail on the preparations phases and the mutual authentication for Remote Configuration. The final phase of Intel® AMT profile assignment, although not shown in this article, is similar to the existing pre-shared key approach once the session is encrypted (see linked article above). The MTLS session established for Remote Configuration is separate from TLS and MTLS sessions defined in the Intel® AMT profile.

Agent Initiated Preparation

Targeted for all Intel® AMT platforms supporting Remote Configuration, this process is best used after the host operating system has been installed along with the Altiris management agent to support Remote Configuration. The steps below assume that existing Intel® AMT version is 2.0 or 2.1 for Intel® vPro™ systems, or Intel® AMT version 2.5 for Intel® Centrino® Pro systems. This implies that no certificate hashes have been stored on the Intel® AMT client, and an upgrade is needed for the BIOS, firmware, drivers, and so forth.

Per the numbering in the diagram above, the agent initiated preparation process is as follows:

1. The Altirs Client Management Suite sends an updated BIOS, Intel® AMT firmware, and Intel® AMT drivers (e.g. MEI, LMS), and the latest Altiris agent. All of these updates are in support of the Remote Configuration process, and could be deployed via Altiris Deployment Server. In addition, the Intel® AMT firmware could be updated out-of-band (supported with AMT 2.1 and higher). The Intel® AMT firmware update package places a set of certificate hashes into the non-volatile RAM (NVRAM). More on the certificate hashes is mentioned in the next section.
2. The Altiris agent will then query the BIOS and firmware to check the configuration mode, configuration state, and Intel® AMT version. It will obtain the system's UUID and AMT version, passing this information to the ProvisionServer via the management console.
3. The management console creates a One Time Password (OTP), which is sent to the client agent and subsequently to the NVRAM. The management console also send the OTP to the ProvisionServer (running Intel® SCS). Note: Only the agent initiated process creates an OTP.
4. The Altiris client agent sends a command to the Intel® AMT management engine, via the Management Engine Interface (MEI), to open the network interface. Once the network interface is open, the management engine obtains an IP address and queries for the ProvisionServer. The interface is open for 6 hours and will close if provisioning does not complete. The process can be restarted by the Altiris client agent if needed.
5. Once the ProvisionServer IP address is obtained from DNS, a hello packet is sent containing the UUID and a self signed certificate created via the local certificate hash.

Bare Metal Preparation

Targeted for Intel® AMT 3.0 and higher systems, this preparation process allows the provisioning process to start before a host operating system has been loaded. Since a successful provisioning process, whether TLS-PSK or Remote Configuration, requires the FQDN (Fully Qualified Domain Name) of the client host system along with the UUID to be mapped - this process presents an interesting challenge. The FQDN of a bare-metal system does not exist, the system has not been added to the Windows domain, and so forth. More on this will be shared in a future article.

Per the numbering in the diagram above, the bare-metal preparation process is as follows:

1. When the system first boots, a self-signed certificate is created based on the existing certificate hashes loaded by the OEM at the time of manufacturing. Only one of the hashes will be set to active, in accordance to the matching Intel® Client Setup certificate within the ProvisionServer's local certificate store. (There is an assumption here that the OEM activates or the IT administrator activates the appropriate certificate hash.)
2. Intel® AMT obtains a DHCP IP lease which includes option 15 (DNS domain suffix), and queries DNS for ProvisionServer within that DNS domain (e.g. ProvisionServer.Loc1.com).
3. The hello packet is sent to the ProvisionServer with the Intel® AMT client's UUID and self-signed certificate included.

Mutual Authentication

After completing one of the two paths for preparation, the mutual authentication between ProvisionServer and the Intel® AMT client commences. For this process to complete, the ProvisionServer has a valid Intel® Client Setup Certificate local to the system and associated for the Remote Configuration process. The Intel® AMT client has received a DHCP IP lease with option 15 included (the DNS domain suffix). The Intel® AMT client has generated a self-signed certificate based on the active certificate hash within the local NVRAM store. The active certificate hash matches the fingerprint of the Intel® Client Setup Certificate - which will be validated during the process. If agent initiated, the Intel® AMT client, ProvisionServer, and management console all have a matching One Time Password (OTP).

Per the numbering in the animated image above, the mutual authentication process of Remote Configuration is as follows:

1. The ProvisonServer requests the self-signed certificate of the Intel® AMT client.
   • NOTE: SCA refers to Setup and Configuration Application. Intel® SCS is one implementation of an SCA framework. The SCA, Intel® SCS, and ProvisionServer are one in the same. If more detail and explanation needed, please comment at the end of the article.
2. The Intel® AMT management engine requests the Intel® Client Setup Certificate from the ProvisionServer.
   • Based on the self-signed certificate form the client, the ProvisionServer generates TLS key 1 and encrypts this using the public key obtained from client's self-signed certificate.
   • The encrypted TLS key 1, Intel® Client Setup Certificate, and PEM file are then sent to the management engine. The PEM file defines the chain of trust. (See article at http://www.symantec.com/connect/node/1866. An enterprise security architect will also be familiar one how to create a PEM file.)
3. At this point, the Intel® AMT client does some validation.
   • Extracts and stores Key 1
   • Using the PEM file and Intel® Client Setup certificate, the management engine extracts the root certificate, generates a certificate hash and validates to the local active certificate hash. NOTE: If the two hashes do not match, the process stops.
   • Validates the OU assignment of the Intel® Client Setup certificate to the DNS suffix received via DHCP IP lease with option 15. For this reason, each ProvisionServer MUST have a unique Intel® Client Setup certificate (see next section). A wildcard certification (e.g. *.company.com) is supported.
4. If the previous validation steps complete successfully, the Intel® AMT management engine creates TLS key 2, encrypts with the public key of the Intel® Client Setup Certificate obtained from the ProvisionServer, and transmits.
5. With TLS key 1 and key 2 obtained by both the ProvisionServer and the Intel® AMT management engine, mutual authentication has occurred and an MTLS session is established.

At this point, the configuration process occurs where the FQDN and UUID are matched, the assigned Intel® AMT profile is sent to the management engine, and the changes are committed.

Intel® Client Setup Certificate and Certificate Hashes

The Intel® Client Setup Certificate will be supported by multiple Certificate Authorities. The final list will not be stated at this time, since some negotiations and other processes are in the works. (Hint: This is a placeholder until the time Certificate Authority names can be made public, along with links on where to obtain.)

The Intel® Client Setup certificate is an SSL Server authentication certificate, which is placed is associated to and configured for each ProvisionServer. It must include the DNS suffix of the target environment (e.g. Company.com). Multiple ProvisionServers can exist within a production environment, with at least one for each DNS subdomain (e.g. geo1.company.com and geo2.company.com). SSL Server authentication certificates support a wildcard feature (e.g. *.company.com), which typically increases the price of the certificate. Since the certificate authority is validating the identity of environment, increased liability coverage leads to increased cost.

SSL Server authentication certificates can cost up to $1000, often with a renewal contract per year. The price details of the Intel® Client Setup Certificate are not yet available and will likely be vendor specific. Based on the type of certificate this provides a rough cost estimate. Remember - one certificate per ProvisionServer and\or DNS subdomain in the target environment. (See the previous section to understand the role of this certificate.)

When submitting a request - whether online or directly to a certificate authority customer service representative - the following points will be needed for enrollment:

• SSL Server authentication certificate
• OID value in EKU field = 2.16.840.1.113741.1.2.3
• OU value in Subject Field = "Intel(R) Client Setup Certificate"
• Common Name = host + domain name (e.g. ProvisionServer.Loc1.com)

The certificate hash on the client systems will contain a fingerprint of an approved certificate. Due to space limitations in the non-volatile RAM (NVRAM), only a defined number of certificate hashes can be supported. The current number of hashes is 3, with only one of the certificate hashes set to active. It may be best to consult with your preferred OEM on what certificate hashes are preloaded and ensure the preferred certificate hash is set to active (see preparation process in previous section). Future versions of Intel® AMT may allow for additional certificate hashes depending on the available space in the NVRAM.

The question has been raised - "What if we already have a production enterprise PKI with a validated root certificate provided by an external certificate authority?" These environments have made a significant investment in their public key infrastructure (PKI) and are thus able to create subsequent certificates for internal and external usage. Their root certificate originates from a third party provider such as VeriSign, GoDaddy, Starfield, and so forth. Establishing such an enterprise PKI is not a simple or inexpensive task. The process to create the Intel® Client Setup certificate and associate certificate hash will be known by the security experts of such environments. The process for embedding the certificate hash within the OEM system at the time of manufacturing has been provided to the OEMs. Whether or not an OEM will support this process... best to have that conversation with the OEMs.

Common Questions

Since this is one of the first public articles on Remote Configuration, there will likely be a number of questions beyond what is stated below. The official answers will be provided upon release of the AMT 2.2, 2.6, and 3.0 platforms. These answers will likely be provided to OEMs and ISVs (e.g. Altiris) before to the public community

Q:
With Remote Configuration coming, will the current USB one-touch and manual configuration options still be supported?

A:
Yes. Both the TLS-PSK (e.g. one-touch or manual provisioning) and Remote Configuration will be supported.

Q:
Why provision, or configure, Intel® AMT systems now when Remote Configuration appears to remove a physical touch to each system?

A:
While remote configuration does provide a "hands-off" approach, it comes with an associated cost of the Intel® Client Setup Certificate. This places dependencies on the production infrastructure, coordination with preferred OEMs, and so forth. This cost might be minimal in comparison to touching each system in a pre-shared key approach (e.g. TLS-PSK), or having an OEM pre-provision the systems during manufacturing. Whether using Remote Configuration or the TLS-PSK (e.g. pre-shared key method), the outcome is preparing and configuring (e.g. provisioning) the Intel® AMT management engine to send and receive calls. Once provisioned, these systems provide enhanced manageability and security for the environment. The timing and cost considerations will vary per production environment, and should be assessed to help make the right decision.

Q:
Why is an Intel® Client Setup Certificate required per ProvisionServer?

A:
When the initial hello packet is sent and directed to the ProvisionServer (due to DNS resolution), that server will send the Intel® Client Setup Certificate to the Intel® AMT system. The OID, OU and DNS domain suffix will be validated by the Intel® AMT system as part of the authentication process. Therefore, each ProvisionServer which will support Remote Configuration needs to have an associated Intel® Client Setup Certificate with the correct DNS domain suffix, OID, and so forth.

Conclusion

Remote Configuration adds to the existing Pre-shared key configuration, providing two main approaches to preparing and configuring the Intel® AMT management engine. Remote Configuration will be supported first on Intel® AMT 3.0 (codenamed Weybridge) systems, followed by firmware upgrades to support current Intel® vPro™ and Centrino® Pro systems. These firmware upgrades are Intel® AMT versions 2.2 and 2.6 respectively.

In addition the firmware upgrades, the Altiris management agent will require an update to support the agent initiated process. Updates to the Intel® AMT drives will also be required - specifically the MEI and LMS drivers.

For systems already deployed, an update package from the OEM will be required to load the appropriate certificate hashes and\or to set one of the hashes to active. The active hash on the Intel® AMT client will be used to create a self-signed certificate used in the authentication process.

Using SSL Server authentication certificates, certificate hashes, Mutual TLS authentication and encryption, updated firmware and drivers, and other key components - Remote Configuration establishes a trusted relationship to securely transmit the provisioning data without physically touching the Intel® AMT client system. This secure session is separate from the TLS configuration and sessions of an enterprise provisioned Intel® AMT client, which is defined in the Intel® AMT profile.

The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries.