Traditionally speaking - if security is improved, manageability suffers. The reverse of this is true also - traditionally.

Intel vPro presents a different approach and perspective to this common understanding - consider some of the usage models and scenarios described at the follow link. http://www.intel.com/business/vpro/index.htm (see the "improve security" and "extend manageability" links on this page under Resources - lower right side)

The above links demonstrates and introduces the usage models and capabilities. But - what about ensuring the security of the platform. As commonly inquired - "Could vPro be used maliciously?". Considering that any tool of value - even the screwdriver sitting in a garage or a desk drawer - could be used maliciously, the question might be better phrased - "What are the built-in security features of Intel vPro?" The following is only a summary and overview - yet should provide some comfort in the platform. (BTW: Are you aware of all the security features in current environments, or would introducing vPro perhaps expose a long term policy or technological oversight? Just a thought.)

• Internal security - Use of Intel digitally signed firmware. In some cases, the OEM will also require their digital signature for firmware updates. The non-volatile RAM (NVRAM) has strict security and access control. There is a small section referred to as "3rd party datastore" or 3PDS. Access to this area requires registration with Intel and granting of a token. Communications into the management engine occur through secure channels - whether from the operating system or from the network interface. Generally speaking - compromising the internal security would indicate there are bigger problems in the environment.

• Enterprise setup and configurationsecurity - Enterprise mode setup and configuration is handled via either a pre-shared secret or certificate based authentication. (see related blog on the latter). The configuration uses secure handshakes, authentication, and so forth. Replay attacks are prevented. With the latest configuration service, option to require authentication or approval of systems to be provisioned\configured. Pre-shared keys are changed after configuration, and subsequently based on definable schedules. Minimal setup rights can be used to limit exposure of accounts to perform setup\configuration. Security audit logs and event logs monitor activities. The process also has dependencies on the enterprise DHCP, DNS, PKI\CA, and so forth. Generally speaking - if the enterprise setup and configuration service is compromised, there are bigger problems wtihin the environment (whether technological, social networking, policy\procedure, etc)

• Operator Security - Roles, permissions, and AMT security realm access control come into play here. This effectively defines who is allowed to configure the "configuration services", who is allowed to authorize or change vPro configurations, and who is allowed to utilize functions on configured vPro systems. The "who" could be defined by a user, group, service, etc.In addition - use of Kerberos for user rights mgmt and so forth provides an integration into the Microsoft Active Directory. Thus a group of users can be defined withe various levels of access control and capability. Plus - all security related actions and configuration changes can be logged. Generally speaking - if an operator compromising vPro security, there are likely bigger problems in the environment (eg. policies, procedures, etc)

• Communication Security - Once a system configured, transport layer security (TLS) or Mutual TLS can used to secure management traffic. User sessions can authenticated using a digest protocol or Kerberos.

• Infrastructure Security - Since vPro effectively hasa separate management computer inside, this management engine can be configured for environments supporting wireless profiles (WPA or WPA2), VLAN, Network Access Control, 802.1x, etc.

• Operational Client Security - On top of all the configuration security items is the end-user usage and capabilities. Items such as System Defense, Agent Presence, remote power management, and so forth.

This returns to the first question - Can manageability and security be raised together for client management?

Open to hear from the community on your thoughts - whether in agreement or disagreement.

This 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® vPro^TM 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

1. Keys are generated and stored in the database

2. Keys are transferred to a USB key

3. The USB key is inserted into the Intel vPro Clients, which load a pre-shared secret record at boot

4. The client boots, negotiates an IP address and requests the IP of "ProvisionServer"

5. 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.

6. 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.

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® vPro^TM 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 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.

2. 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.

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 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.

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 (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:

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.

*_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:

1. The ProvisonServer requests the self-signed certificate of the Intel® AMT client.

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. (An enterprise security architect will also be familiar with 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 (AMT version 2.6 and beyond)

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.

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^TM 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.

When IT experts get together to talk about PRO you never know what we'll talk about it. Here's our first PODcast of getting Big Dave McCray, Randy Nystrom, Bob Bogowitz, Todd Christ & myself (Josh Hilliker) to talk about PRO. This PODcast tells you why we care so much about PRO & how we use on a daily basis.

I am sure you are all aware of the benefits of adopting the embedded manageability features in vPro. What has SCS got to do with that and why do we need SCS?

Can you buy a home theater, plug in the power and expect it to work with all your other media devices? Can you buy a wireless router, switch it on and expect a home network to work without configuring? No.

Similarly, in order to reap the benefits of the embedded manageability features in vPro, we need to set it up and configure it appropriately. Setup and Configuration services (SCS) provide the means to setup and configure vPro systems. Some of the abilities that SCS provides include

• - Ability to integrate with identity management systems such as Active Directory

• - Ability to request the CA for a certificate on behalf of the vPro system

• - Ability to push wireless profiles on to the vPro system for wireless manageability

• - Method to push configuration settings to a bulk of vPro systems

• - Maintenance operations such as renewal of certificates, re-provisioning systems if hostname changes

Currently SCS is integrated as part of an ISV's management console. With vPro spanning across domains such as Asset management, Remote Support, Security, Patching and Compliance, are we looking at a single management console? If we have different management consoles for different domains, how do we ensure that the vPro systems are setup and configured once and all management consoles can operate with vPro? Who provisions, who maintains, who talks to who in order to make efficient use of vPro in a multi-management console eco system? In order to allow effective inter-operability between the management consoles, are we looking at a "unified provisioning application" for all the technologies that Intel supports on a vPro system?

Let me know your thoughts...

Welcome and Future Topics

This blog posting is being created to discuss/highlight the key areas you should be aware of when implementing and activating vPro and Centrino Pro Technology within your environment. To start we will focus on Infrastructure, Requirements and Dependencies, and The Setup and Configuration Server.

If you have any additional topics you would like to see that fall under implementation and activation, please let me know.

Infrastructure:

In general an enterprise looking to deploy Intel® Active Management Technology will require at a minimum three servers in addition to your existing management framework to take full advantage of these capabilities. It is also recommended that for a fully functional enterprise that these servers be redundant as appropriate for their service to provide for high availability. Most, if not all enterprises require the robustness of service that can only be attained via high availability configurations. The three additional servers are as follows:

1. One to host the Microsoft Certificate Authority

2. One to host the Intel® AMT Setup & Configuration Server (depending on your ISV of choice)

3. One to host the Microsoft SQL® Server Database

If an enterprise already has a SQL Server database or database farm in place, it could possibly be utilized eliminating the need to standup a separate service. Similarly, if an enterprise has an existing PKI in place, it could possibly be utilized for the Intel® AMT deployment. However, in this case it is likely that a successful startup of a pilot within an enterprise would be bolstered by implementing the PKI in standalone mode and then migrating to the existing PKI.

Another option for the enterprise that has a fully supported virtualization environment is to place the Microsoft Certificate Authority and the Intel® AMT Setup & Configuration Server in within that environment. The caveat is that the environment must be supported just like standard physical server environment. Process and procedures should account for standard server support in the virtual environment. Note: Virtualization of the SQL Server database cluster is not recommended.

It is assumed that a fully functional Windows networking infrastructure is in place prior to the deployment of Intel® AMT management capabilities. These assumptions include the highly available configurations most common to enterprise deployments of Windows Active Directory, Domain Name Servers, DHCP servers, and your Manageability Software that was support for Intel® vPro Technology.

Windows Server 2003 Active Directory (AD)

Microsoft Active Directory is assumed to be part of the overall network infrastructure supporting the existing Windows network environment. This architecture requires AD as the authentication mechanism allowing the Intel® Setup & Configuration Server, vPro ISV enabled Software, and potential web clients to logon to Intel® AMT hosts. AD should inherently be designed in a high availability configuration as prescribed by the existing environment and geographic requirements as well as best practices for AD in general.

Domain Name Server (DNS)

A domain name server is used to supply the name to IP resolution for the Intel® AMT hosts as well as resolving the Setup & Configuration server IP address for provisioning purposes. The name and IP address of each Intel® AMT host will be automatically registered in the DNS by the DHCP server.

Each Intel® AMT host will try to resolve the static name "ProvisionServer" during the initial activation process. ProvisionServer will be manually registered in the DNS and assigned to the Setup & Configuration Server IP address.

DNS is expected to be integral to the existing Windows network infrastructure. DNS should inherently be designed in a high availability configuration as prescribed by the existing environment and geographic requirements as well as best practices for DNS in general.

Dynamic Host Configuration Protocol (DHCP) Server

DHCP services must be in place to properly register Intel® AMT hosts within the enterprise. The hosts require that the DHCP server register their fully qualified domain name (FQDN) with the DNS. If the Microsoft DHCP server is employed it should be configured to automatically register the hosts in the DNS. Standard DHCP option 81 should be used to accomplish the task of registering the Intel® AMT hosts in the DNS as the FQDN is required as part of the PKI certificate generated for the device. The DNS is queried by the configuration server or add-on to compare against the certificate received in order to properly accept the TLS encryption with the Intel® AMT host.

Microsoft Certificate Authority (CA)

At a minimum a stand-alone PKI certificate authority would need to be in place to enable encrypted and secure communication with the Intel® AMT hosts. The Microsoft certificate authority (CA) is required to properly interoperate with the Intel® Setup & Configuration Server. The CA is required to issue certificates to the Intel® AMT hosts, the Setup & Configuration Server, and in the case of Mutual Transport Layer Security (MTLS) the vPro enabled ISV software (that using the Intel SCS). These certificates allow for SSL encryption and Transport Layer Security (TLS) and MTLS.

A certificate can be purchased from an outside vendor such as Verisign®. This enables easier provisioning (Remote Configuration) of the Intel® AMT 3.0 hosts as the Verisign root certificate hash is already defined in the host. This will be covered in later when we focus on Intel® AMT 3.0 devices.

These servers may be considered for virtual hosting environments. It is a requirement that the virtual hosting environment be fully supported within the environment through standard operating procedures. It is expected that if these servers are virtually hosted they will receive equivalent operational support as if they were hosted in a physical environment.