Checkout the latest embedded or linked YouTube videos on vPro Expert. If you go out on YouTube - check the "vproexpert" and "IntelNick" users. Good short videos.

ProExpert Embedded early examples- http://communities.intel.com/docs/DOC-1128 and http://communities.intel.com/docs/DOC-1129

Direct links on YouTube to these accounts - http://youtube.com/user/vproexpert and http://youtube.com/user/IntelNick

More training and demo based videos are coming. Have an idea or request? Reply to this blog or to the existing discussion at http://communities.intel.com/message/1280

Before the opening bell on the IDF showroom floor, Matt Wallington explains what the vPro challenge is all about. The question is who's the proest of pro's & ready to take on the challenge..

IDF - PRO Classes

If your headed to IDF, here are the specific PRO classes & speakers

Session ID Title Speakers

• SCIC001 Security Technologies - Chalk Talk Doughty/Smith/Grawrock

• SCIS001 Security Kickoff: Providing World-Class Security
  and Data Protection for the PC Platform Rob Crooke

• SCIS002 The Intel Safer Computing Initiative and Trusted
  Computing Grawrock/Brickell

• SCIS003 Making Security Practical in the Enterprise with
  Client Technologies Grobman/Smith

• SCIS004 The Front Door of Trusted Computing: Controlling
  the Software Stack with Intel® TXT Grawrock

• SCIS005 Delivering Security Requires More Than Features David Doughty

• SCIS006 Research on Platform Security Technologies David Durham

Session ID Title Speakers

• BDOL001 Intel® Active Management Technology Lab Ylian Saint-Hilaire

• BDOP001 Panel: "Software as a Service" (SaaS) Chuck Brown

• BDOS001 Directions on the Business Desktop and Mobile PC Marek/Tucker

• BDOS002 Intel® vPro^TM Processor Technology Value Proposition
  to Managed Service Providers Supporting SMBs Kevin Havre

• BDOS003 "Software as a Service" (SaaS)/Streaming Compute
  Initiative Technical Session Khosravi/Fraser

• BDOS004 Intel® Active Management Technology Hedrick/Maresky

• BDOS005 Intel® Virtualization Technology on Next-Generation
  Client Platforms Klotz/Bailey

• BDOS006 Pro Platform Interoperability and Integration -
  Are You Pro Ready? Chan/Hilliker

• BDOS008 Small Business: Jump-start your eCommerce
  Development with Overviews from eBay, PayPal
  and Skype* Kumar Kandaswamy

If your headed to IDF let me know.. if you can't make it, we're going to get whatever we can on PRO material & post here.

Extending the value of Altiris Client Management Suite via Intel vPro Technology will be a focus at the upcoming Altiris ManageFusion event in Orlando. The dates are Oct 9-11. Registration and event information is available at http://www.managefusion.com/agenda/Orlando.aspx

For details on the technical sessions, please refer to the following article - http://juice.altiris.com/headsup/2479/managefusion-07-intel-vpro-sessions-and-events

I thought I'd provide a short introduction to the vPro Expert Training Program. I'll have more details to share as we get into the 4th Quarter of this year. As this program is still in development, some of the information below is subject to change, fair warning :D.

What is the vPro Expert Training Program?

The vPro Expert Training Program is a series of public, technical training courses currently in development. These courses will be offered to the general public starting in the 4th quarter of 2007. Specific dates/times/logistics are not available at present.

What material will be covered?

Various courses are being developed, with different target audiences.

A pilot of the vPro Operations class is scheduled to take place before the end of this month. Assuming everything goes according to plan we'll be able to start offering that class sometime after October. I'll continue to provide updates as information becomes available. Stay tuned.

-Jeff

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.