Intel,Altiris Group

If you are new to configuring Intel AMT or have a working solution for your environment - this article is not intended for you.

If you're a service provider, consultant, or customer with unique environmental constraints which have prevented the configuration of Intel AMT - keep reading.

If you have environmental security requirements for the Intel AMT configuration - such as Kerberos, TLS, 802.1x, etc - some information in this article may not be suitable for your environment. This article focuses on customers using a "Basic" or "Standard" configuration.

The Challenge of Out-of-Band Configuration: Establishing Trust

Much has been posted regarding the configuration of Intel vPro technology. Configuration of the technology occurs "out-of-band" from the operating system, and requires a trust to be established between two untrusted entities. The two entities looking to establish a trust relation are the Intel AMT firmware and the provisionserver configuration service.

Some has asked "Why". Since Intel AMT provides management control at the hardware layer, it would be best that only trusted and authorized solution environments configured that technology.

The following diagram provides a summary of the situation

Getting the initiate trust or authentication to occur requires a third party to be involved. The classic scenario: A trusts B, and C trusts B, than A trusts C.

Understanding this overview of out-of-band configuration and establishing the initial trust is important. It will help to better understand the purpose of the security keys or remote configuration certificate used to establish the initial trust. Both the security keys and remote configuration certificate involve a third party element to help establish the initial trust. In the Intel AMT firmware is a set of public certificate hashes - this is the default nature. Generated security keys can be added, or additional certificate hashes - again, keys or rather public\private "secrets" that only the Intel AMT firmware, provisionserver, and possibly a trusted third party should be aware of.

Security Keys or Certificates to Establish the Initial Trust

If security keys are generated via the Symantec Management Console (i.e. Altiris), the following interface may look familiar. The generated keys are exported in a setup.bin file format, and using a USB flash drive that setup.bin file is read by the various Intel AMT systems to obtain a public\private key pair. Thus - the keys were generated and distributed. The public key is used to initiate the handshake with the management server, which was the source of the security key pair. The third party involvement was the USB key and technician that physically touched each system. What results is a type of TLS public\private key handshake to provide a secure tunnel for sending the configuration data over the network.

Some enterprise environments may have used an OEM pre-provisioning service. In this scenario, the OEM is the trusted third party which distributes the security keys to the firmware. The end customer receives a setup.bin file which is imported via the interface shown above, thus accomplishing the same goal of the Intel AMT firmware and ProvisionServer having a matching set of public\private keys. (Lenovo and HP support the pre-provisioning with setup.bin file to customer. Dell CFI process currently sends a .CSV file - for more information see Dell CFI Process and Intel vPro Provisioning )

Alternative Approaches Compliant to Out-of-Band Configuration

Based on the information stated above, a common question is raised: Is there a command line utility or end-user utility for alternative configuration approaches?

Yes - there are tools and different approaches to accomplishing the configuration out-of-band. But the rules of out-of-band configuration still have to be followed.

An article on Intel vPro Expert Center provides some great insights for small environments, managed service providers (MSP), and so forth. See http://communities.intel.com/docs/DOC-3811.

If one of these approaches is taken, keep in mind that the Symantec Management Platform (i.e. Altiris 7) will not own the configuration of Intel AMT. BUT - it will still be able to utilize the technology. The OOB Discovery process will find Intel AMT systems, and the Pluggable Protocol Architecture with Default Connection Profile will specify what credentials the Symantec Management Platform should use to connect to Intel AMT systems.

What about creating a setup.bin file outside of the installed Symantec Management Platform environment? The article noted above makes references to this capability.

In the Intel AMT SDK is a utility called USBfile.exe. Once the SDK is downloaded and extracted, look in extracted directory .\Windows\Intel_Manageability_Configuration\Bin\ConfigScripts

The USBFile is a reference tool, and the source code is contained in the SDK. A few examples of this tool's capability include:

• Generating a setup.bin file with security keys and initial password (similar to the OEM pre-provisioning). Each key pair is consumed on a per system basis
• Generating a setup.bin file with reusable security key pairs. Thus a single key pair is desired for the initial configuration. Don't worry - at each configuration event, the key pairs are randomized on a per system basis. This single reuse key pair applies only to the initial set.
• Generating a setup.bin file which can insert a root certificate hash beyond the default remote configuration certificate hashes in the firmware. This can be used for testing and validation purposes before acquiring an external certificate. For information on how to generate an internal remote configuration certificate, see http://technet.microsoft.com/en-us/library/cc161804.aspx#BKMK_AMTprovisioning2
• Generating a setup.bin file that sets the initial security keys along with desired management engine settings (i.e. provisionserver FQDN or address, allowed redirection options, SMB mode configuration with client hostname, etc)

There are a host of additional possibility and options. The attached text files provide a readme file and option output for USBfile.exe.

There are also different versions of setup.bin files. As a general guideline:

• Version 1 - usable on Intel AMT version 2 and above. Used primarily to set the pre-shared security keys.
• Version 2 - usable on Intel AMT version 3 and above. In addition to version 1, able to insert root certificate hashes and set some management engine features.
• Version 2.1 - usable on Intel AMT version 4 and above. Adds in the ability for SMB provisioning with hostname (Take a look at the article previously referenced - especially Improved Manual Configuration with SCS 6 Lightweigth and vPro Activator GUI http://communities.intel.com/docs/DOC-3772)
• Version 3 - usable on Intel AMT version 6, which will be released in 2010. Note the references to KVM. More on this feature will be explained after January 2010.

Concluding Thoughts and Ideas for the Future

Once the base requirements of Intel AMT out-of-band configuration are understood, along with utilities available to try alternative approaches, a new paradigm opens up on how to handle configuration events. To the reader - please understand that the present Intel AMT configuration approach in the Symantec Management Platform works great - several thousands of systems in single customer environments have been configured. Multiple that by hundreds of customer environments and hopefully you'll agree - the current process\approach works. The challenge is unique environment situations where alternatives need to be considered.

An item I personally would like to see - and have been researching for several months - is a "provisioning appliance". The information in the vPro Expert Center article provides a number of ideas and hints, the information in this and supporting articles provides more hints, yet a few items are still missing or need to be improved (at least in my view). The desired outcome is to get Intel AMT configured prior to or after deployment without having the installed client management solution owning the configuration, yet utilizing the Symantec\Altiris and Intel tool sets.

Why is a provisioning appliance of interest? Did you know that there are several millions of Intel AMT capable systems which are simply not configured? The technology is effectively dormant, and one of the key challenges is discovering the technology exists and getting the initial trust established to enable the technology. The core objective has been on my mind for more than a year. Intel AMT configuration events are moving forward at many customers, but more is wanted. (Side comment - it's always nice to have demand for more.)

The challenge is complying to the firmware security, software licensing, and other rules that are unchangeable (or very difficult to change). The SMB and MSP configuration approaches are inspiring, collaboration with NetX (http://www.youtube.com/watch?v=iX880v9DZuI) provided some insights... much has been learned and will hopefully influence future firmware security models for configuration... but for now, if you'd like to dig into this in more detail, post a comment or send me a note.