Looking for a good tool for PRO? - check out the new PRO TOOL WIKI
Posted by Josh Hilliker Oct 9, 2007
In the short history of the Intel AMT Developer Tool Kit (DTK), this is probably the single release with the most changes and improvements in it. One look at the change log and you notice that there are lots of improvements in many areas of the DTK. In this blog, I want to touch on a few of the major new features.
Intel AMT Guardport, a C/C++ version of the Intel AMT Outpost serial agent. Many have noticed that Intel AMT Outpost is a quite powerful Intel AMT agent. The main problem with Outpost is that it is rather fat software and makes use of .NET. It's not practical if you are going to run it on 1000's of computers or most importantly, add it to a recovery OS image. Intel AMT Guardpost is a light weight port of the most important feature of Outpost, the serial agent. Guardpost is a statically linked .exe file (no other .DLL's required) that finds the SOL COM port automatically and binds to it. It offers a command prompt and the same binary-over-SOL support that Outpost supports. In this version, Guardpost is still very limited but supports remote process monitoring and the most impressive of the Outpost features: TCP-over-SOL.
Intel AMT Interceptor, a trace and debug tool that connects to Intel AMT Switchbox. This new tool takes advantage of a new debug port in Switchbox to show in real-time all of the traffic going thru Switchbox. It shows in real time HTTP, SOL and IDE-R traffic flowing thru and for each data chunk, its source and destination. It even works with TLS since a console with authenticate with Switchbox and Switchbox will perform its own TLS connection to Intel AMT. At a minimum, this new tool is very educational for people curious to see in-depth, what Intel AMT network traffic looks like.
Intel AMT DTK Internationalization effort. A lot of effort is going into internalization of the Intel AMT DTK. This started months ago with Simplified Chinese and Japanese support. In order to make it easier to internationalize the DTK (or any .NET application) we started work on a Resource Translator tools. It's only part of the source code package and it's just an early tool right now. I have used it to start translation into French of the Intel AMT Terminal. Some will also notice that some of the Terminal is translated into Hebrew to test to right-to-left support and NetStatus is translated to Russian.
Lots more improvements are coming up for the DTK. Mostly, I have to code all the time and I sometimes have to put aside answering mails for a while. I will try to answer more mails next week.
Audio File: Ylian's audio blog on the Intel AMT DTK v0.38 (.mp3)
Ylian
Remote Configuration - What is it? How does it work? When will it be available?
Posted by Terry Cutler Aug 29, 2007This article provides an overview. If you have questions, comments, and so forth - please respond.
Overview of Remote Configuration
With the launch AMT 3.0 on the Weybridge platform (e.g. Intel® vPro™ platform launched Aug 27, 2007), Intel is introducing an additional mechanism for enterprise provisioning and configuration: Remote Configuration (RCFG) formerly known as Zero-Touch Configuration (ZTC). This process provides an alternative approach to the existing pre-shared key (e.g. TLS-PSK) configuration or provisioning - commonly referred to as USB one-touch.
Enterprise configuration of Intel® vProTM of provides a central configuration control of the management engine. For environments using small-medium business (SMB) configuration, RCFG is not applicable. RCFG applies only to enterprise mode of provisioning of configuration the management engine.
In the diagram below - Remote Configuration accomplishes the transition from Factory Default to Setup Mode.
RCFG allows an IT administrator using an RCFG-enabled setup and configuration application (SCA), such as Intel Setup and Configuration Service (SCS), to remotely initiate a secure and authenticated communication channel with the Intel® AMT device in order to perform setup and configuration of the device. RCFG is based on a Mutual Transport Layer Security (MTLS) handshake with an Intel® Client Setup Certificate on the provisioning server and a self-signed certificate on the Intel® vPro™ client system. The Intel® vPro™ client system has a series of certificate hashes which identify approved certificate authorities.
During the MTLS handshake, the SCA sends a certificate to the Intel AMT system - this certificate is used to authenticate the SCA to the Intel AMT system. An enterprise customer or environment must obtain this SSL Server certificate from a commercial Certificate Authority (CA), with certificate properties as defined below. The chain of trust of this certificate must include as its root one of the root certificates which are on the list of root certificate hashes in the firmware image of the Intel AMT system - i.e., it is a trusted CA. The default firmware image supplied by Intel contains a default of list certificate hashes which can be edited by the OEM. In essence, this is the same as noting trusted certificate authorities for internet browsers.
The certificate which the customer purchases must be marked as capable of Intel AMT configuration in one of the following two ways:
OID value in EKU field = 2.16.840.1.113741.1.2.3
OU value in Subject field = "Intel(R) Client Setup Certificate"
These requirements, along with additional processes mention below, will prevent an attacker from attaining a certificate from one a less secure server of the end customer and using it to configure Intel AMT systems.
RCFG will be first available on AMT 3.0, released Aug 2007. Backwards support on AMT 2.x platforms will include AMT 2.2 (Intel vPro platform released in 2006) and AMT 2.6 (Intel Centrino Pro platform release in 2007). It is best to confirm with your preferred OEM on their plans to support the respective Intel AMT releases.
What is TLS-PSK?
Before diving deeper into Remote Configuration, a base understanding or awareness of the current provisioning process might be helpful. TLS-PSK refers to Transport Layer Security Preshared Key. Essentially - a pre-shared secret (actually, a triplet pair) is shared between the Intel AMT client and the Setup and Configuration Application (SCA).
Since this article focuses on Remote Configuration - only an overview of the predecessor is provided
Keys are generated and stored in the database
Keys are transferred to a USB key
The USB key is inserted into the Intel vPro Clients, which load a pre-shared secret record at boot
The client boots, negotiates an IP address and requests the IP of "ProvisionServer"
The client sends a "hello" packet to the ProvisionServer. The packet includes the public portion of the pre-shared key along with client specific\unique information.
The ProvisionServer matches the public portion of the pre-shared key (e.g. Provisioning Identifier), and performs a handshake based on the private key (provisioning passphrase). Once the handshake and TLS session obtained - the configuration data is transferred as part of the Intel AMT profile.
What is Required for Remote Configuration?
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 ISV client agent must be obtained, which will support the Remote Configuration process to allow agent initiation.
Version 3.1 or higher of Intel® Setup and Configuration Service (SCS) is required within the ProvisionServer. For ISVs implementing their own Setup and Configuration Application (SCA) - recommend checking with them directly (Hint: A quick check of the AMTconfig service will reveal the version number of SCS.)
The base certificate hashes loaded on AMT client are listed below. Again - it may be best to confirm with your preferred OEM on what certificate hashes they have chosen to support, make active, and so forth. There is space for 20 certificate hashes, thus allowing custom hashes to be created - especially for environments which manage their own enterprise PKI. However, a full UnProvision of the client will restore the base certificate hashes along with setting all base certificate hashes to active.
AMT Version | VeriSign G1 | VeriSign G3 | GoDaddy | Comodo | Starfield |
AMT 2.2 | Yes | Yes | Yes | Yes | Yes |
AMT 2.6 | Yes | Yes | Yes | Yes | Yes |
AMT 3.0 | Yes | Yes | Yes | Yes | No |
The exact fingerprints of the certificates can be provided if needed. Post a comment at the end of the article.
How does Remote Configuration Work?
Two approaches are included in the design: Agent Initiated and Bare-metal (aka agent-less).
AMT 3.0 and beyond 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 an 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 TLS-PSK section above). The MTLS session established for Remote Configuration is separate from TLS and MTLS sessions defined in the Intel® AMT profile and used for management traffic security.
Agent Initiated Preparation Phase
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 ISV client management agent to support Remote Configuration. The steps below assume that existing Intel® AMT version is 2.0 or 2.1 for Intel® vProTM 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:
The ISV client management suite sends an updated BIOS, Intel® AMT firmware, and Intel® AMT drivers (e.g. MEI, LMS), and the latest ISV client agent. All of these updates are in support of the Remote Configuration process. 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.
The ISV client 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.
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.
The ISV 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 ISV client agent if needed.
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 (e.g. Agent-Less) Initiated Preparation Phase
Targeted for Intel® AMT 3.0 and higher systems, this preparation phase allows the provisioning process to start before a host operating system has been loaded or if the client management agent is not used (i.e. agent-less).
!http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/38-10209-1032/BarePrep.png!
Per the numbering in the diagram above, the bare-metal preparation process is as follows:
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.)
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).
The hello packet is sent to the ProvisionServer with the Intel® AMT client's UUID and self-signed certificate included.
*_Authentication Phase_*
After completing one of the two paths for preparation, the 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).
!http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/38-10209-1034/RCFGstep2.gif!
Per the numbering in the animated image above, the mutual authentication process of Remote Configuration is as follows:
The ProvisonServer requests the self-signed certificate of the Intel® AMT client.
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. (An enterprise security architect will also be familiar with how to create a PEM file.)
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 (AMT version 2.6 and beyond)
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.
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.
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® vProTM and Centrino® Pro systems. These firmware upgrades are Intel® AMT versions 2.2 and 2.6 respectively, and it is best to confirm with you preferred OEM whether they plan to support.
In addition the firmware upgrades, the ISV client 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. Certificate hashes outside the base 5 can be added to the OEM system, with space for up to 20 total. However, a full UnProvision of the client will restore the base certificate hashes along with active\inactive indicators.
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.