The conference goes through end of the week - yet the excitement around Intel vPro will continue for days\months to come. Below is a quick summary of items shown. Have questions or want more information? Add a comment or post a question.

• Keynote demonstration

  - showing how the Intel vPro client can be remediated (or isolated) to only the management console on specific ports. Using the Altiris TaskServer - a 1:many job was defined to place a system in remediation, restart a process on the client, and remove the system from remediation. This did require a customization to the network filter settings (e.g. System Defense). The value of isolating a system on the computers NIC was very compelling and led to many conversations.

• At the demo booth

  - some of the most frequent questions (and associated answers) include:

1. When will Intel vPro and Centrino Pro be available? (Product available today from all major OEMs - including Dell's recent product announcement for Latitude 630c)

2. How long has Intel vPro been available? (Product has been available for a year now)

3. Are customers adopting Intel vPro? (Yes)

4. How do channel partners and service providers get training or more information to assist their customers? (Utilize sites such Intel vPro Expert, Altiris Juice, and so forth today. Formalized training material and events are being created. Stay tuned)

5. Does Intel vPro utilize Wake-on-LAN? (The remote power features are communicated via TCP\IP for reliability\consistency. WoL utilizes UDP and a "magic packet" to contact systems - yet may not act as reliably. In addition, Intel vPro remote power features allow for power off. With integration into Altiris - the ability to record present power state, perform list of defined tasks, and to return the system to the previously recorded power state.)

6. Will Intel vPro appear in other platforms beyond PC-based laptops and desktops? (No publicly stated plans. Raise the question\interest with your preferred OEM)

7. What break-out sessions and materials were available at the event? ("Realizing the value of Intel vPro" - focus on how to integrate Intel vPro into a production environment. A hands-on lab also occurred to step through common operational usage models.)

There were likely other questions - yet these questions occurred frequently.

With the event closing this Thursday - some early discussions already starting to build on the momentum.... "What should we show next time?". I'm thinking more real-world scenarios, enterprise reference architecture for implementation, and remote configuration - what do you think?

Ok, this question has been out there for sometime now. Can playing video games at work be good for you? Could having your brain always on the "go" position be bad for productivity.

I think many social psychologists (full disclosure, none were interviewed for this blog) would agree that taking short breaks to recharge your brain is much better then charging full steam through the day. But can we even take that idea a step further and say that not only could it be good for your mental health but possibly good for the company as well? More then what a typical break to the soda machine can offer, playing games may also encourage certain activities (such as teamwork, if you can convince your company to let you play a team-based game like Halo 3 for instance...).

Well as is always the case, someone did a study on this -

It's amusing to note that the researchers had a lot of trouble finding companies willing to let their employees play games. However, the results show that workers who got to play up to an hour of games a day were more productive and more satisfied in their jobs. Of course, someone will come along and point out (like your boss) that if people are just playing games, no work will get done - agreed. But I'm not saying that people should play games all day long, just as a break here and there. Hey, they did a study right and the data doesn't lie. Anyway, with that said, I'm off to go spend the rest of my day conquering virtual worlds and dominating invading aliens...

Note this blog was written with the help of Mike Masnick as I wanted to write more but i'm on level 6 of

and couldn't pull myself away...

Well, it probably won’t work if you stick it there, but the

truth is that there are a lot of certificates used in AMT, and knowing where to

put those certificates and their private keys can save a lot of hair pulling

down the line.

<!--<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtevml+1">if gte vml 1>
id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t"

path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f">





































]]>

<v:imagedata src="file:///C:\DOCUME_{1\gjbevan\LOCALS}1\Temp\msohtmlclip1\01\clip_image001.emz"

o:title=""/>

endif><!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if%21vml">if !vml</a>>!AMT Certs.jpg!<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>><!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtemso9">if gte mso 9>


DrawAspect="Content" ObjectID="_1253102892">



endif-->]]>

AMT Certificates

Let’s start with the AMT system itself.

TLS Certificate

If the SCS profile calls for TLS to be enabled then a

private key and certificate are generated at the SCS and then installed on the

Amt device as part of the provisioning process. This certificate and key are

then used in future communications between the SCS and the AMT device and the

Management Console and the AMT device. I’m going to use the SMS Add-on as an

example of the management console because it uses gSOAP libraries which have

addition certificate storage requirements.

802.1x Certificate

If the SCS profile calls for and 802.1x certificate then a

private key and certificate are generated at the SCS and installed on the AMT

device as part of the provisioning process. This certificate and key are used

to allow the AMT device to connect to an 802.1x protected network without the

host operating system being available.

Mutual Authentication Root Certificate (MTLS Root)

The MTLS root certificate is used by the AMT device to

validate the mutual authentication certificate provided by the SCS or

management console after provisioning has completed. (Assuming of course that

the SCS profile used for provisioning configures MTLS). This certificate is

installed during the provisioning process. Note only the certificate is

installed – there is no private key installed for this certificate.

h1. Remote Configuration

The remaining two certificates on the AMT device are used

for Remote Configuration. This feature is available in AMT 2.2, 2.6 and 3.0.

(Note that does not include 2.5).

Remote Configuration Root Certificate (RCFG Root)

Actually this is not a whole certificate. It’s just the

certificate thumbnail, referred to as a hash. The certificate hashes can come

from a couple of places:

<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if+%21supportLists">if !supportLists</a>>·

hashes from VeriSign, GoDaddy and Comodo.

<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if+%21supportLists">if !supportLists</a>>·

<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>>Your OEM can place a certificate hash of your

choosing on to the AMT devices you buy as part of their manufacturing process.

E.g. if you have your own PKI and wish to use your own root certificate.

<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if+%21supportLists">if !supportLists</a>>·

manually enter the certificate hash into the MEBx screen.

The advantages and disadvantages of each of these methods

are best left for another discussion.

This certificate is used to validate the remote

configuration certificate provided to the AMT device by the SCS service that is

trying to provision the AMT device. The details of this validation are somewhat

complicated and also best left to another discussion.

Remote Configuration Self Signed Certificate

Finally the remote

configuration processes requires the AMT device to generated its own self

signed (i.e. there is no certificate authority involved – and hence no trust

established) certificate to serve as a TLS/SSL certificate in place of the Pre

Shared Key (PSK) that was used to protect provision in earlier version of AMT.

Both the certificate and the key are generated locally on the AMT system.

SCS Certificates

Once we get to the server side, certificates become more

interesting as we have to know which Windows certificate store to put the

certificate and private key.

The SCS requires four certificates.

SSL Certificate

The SCS service runs as a web service within IIS.

Connections to the service can be carried out by the SCS console or by an ISV

supplied UI. To secure this traffic the SCS service requires that these web

services be protected by TLS/SSL. The SSL certificate is the same type used to

secure other web servers like amazon.com or eBay.

This certificate is installed in the Windows certificate

store of the service account used to run IIS. If you use the IIS “Server

Certificate” this is a two step process. First the IIS server generates the

private key and a certificate request. The private key is stored in the IIS

service account key store, and the request is stored in a text file. The

certificate request is then sent to the CA who issues the certificate. The

wizard then installs the certificate and matches it up with the private key.

<!--<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtevml+1">if gte vml 1>
type="#_x0000_t75" style='width:555pt;height:444pt' o:ole="">

]]>

<v:imagedata src="file:///C:\DOCUME_{1\gjbevan\LOCALS}1\Temp\msohtmlclip1\01\clip_image003.emz"

o:title=""/>

endif><!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if%21vml">if !vml</a>>!SCS Certs.jpg!<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>><!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtemso9">if gte mso 9>


DrawAspect="Content" ObjectID="_1253102893">



endif-->]]>

TLS Root

The TLS root certificate is the root certificate from the

certificate chain that issued the TLS certificates to the AMT devices. This may

or may not be the same as your MTLS Root, depending on how you issue your

certs. This certificate is used to validate the TLS certificate provided by the

AMT device when the SCS connects to the device to perform some function after

initial provisioning. This could be re-provisioning or one of the maintenance

tasks that the SCS performs – like setting the AMT system time.

There is no private key associated with this certificate.

The certificate should be stored in the “Trusted Root Certification

Authorities” folder of the SCS service accounts certificate store.

Mutual TLS Authentication Certificate

This certificate is used by the SCS to authenticate itself

to the AMT devices. Both the certificate and the private key should be stored

in the SCS service accounts “Personal” certificate store. The root certificate

of the chain must be installed on the AMT device during provisioning to allow

this authentication mechanism to work correctly.

Remote Configuration Certificate

This is the most interesting of the three SCS service

certificates. This is because the certificate needs to be in two certificate

stores – but the private key only needs to be in one. The SCS service presents

this certificate to the AMT device to start remote provisioning. As this is a

mutually authenticated TLS session, the SCS service must have access to the

private key. So the certificate and private key should be installed in the SCS

service accounts certificate store.

To configure SCS for remote configuration, a utility called

“loadcert.exe” is run. This utility lists the certificates in the local

computer store and you select the one you want the SCS service to use for

remote configuration. The utility then make a registry entry containing the

thumbnail of the certificate. The SCS service looks at this registry entry and

then looks up the selected certificate in the SCS service account certificate

store. Because the loadcert.exe utility reads from the local computer store,

the remote configuration certificate needs to be installed in there. But,

because it is only read by the utility to extract the thumbnail, the private

key does not have to be installed in the local computer store.

SMS (Management Console) Certificates

Certificates for the SMS Add-on are complicated by the use

of the gSOAP libraries. GSOAP is a cross platform, open source web services

development toolkit. Because it is cross platform it does not (obviously) use

the windows certificate store. Instead it uses a file format called PEM (from

the Privacy Enhanced Mail system). PEM files store certificates and keys as

base-64 encoded strings. This makes them easy to manipulate (with things like

notepad) and portable between systems. The following discussion assumes a 3

level PKI hierarchy, with a root CA, policy CA and an issuing CA. If there is

sufficient interest I can talk about PKI hierarchies on a separate thread.

As the SMS is also a windows program, it also needs its

certificates in the windows store.

<!--<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtevml+1">if gte vml 1>
type="#_x0000_t75" style='width:566.25pt;height:407.25pt' o:ole="">

]]>

<v:imagedata src="file:///C:\DOCUME_{1\gjbevan\LOCALS}1\Temp\msohtmlclip1\01\clip_image005.emz"

o:title=""/>

endif><!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if%21vml">if !vml</a>>!SMS Certs.jpg!<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>><!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtemso9">if gte mso 9>


DrawAspect="Content" ObjectID="_1253102894">



endif-->]]>

h2. Mutual Authentication Certificate (MTLS)

If the AMT profile the SCS calls for mutual TLS, then the

management console needs to supply an MTLSS certificate. This certificate, and

its private key, needs to be installed in SMS Add-on Service account

certificate store. This allows the SMS Add-on service to access the key for

operations such as power management. Because

the windows certificate store can “walk certificate chains”, only the MTLS cert

needs to be installed. Windows will work out where to get the rest of the chain

from on its own.

This is not true for the PEM file. In order for the gSOAP

library to have access to the certificate chain, all the chain entries must be

placed in the file (in the right order).

TLS Root Certificate

When a connection to the AMT device is made, it presents its

TLS certificate. In order for the Management console to trust the certificate,

the root certificate the issued the AMT certificate must be installed in the

“Trusted Root Certification Authorities” folder in the SMS Add-on’s certificate

store. . Because the windows certificate

store can “walk certificate chains”, only the TLS root cert needs to be installed.

Again, this is not true for the PEM file. In order for the

gSOAP library to have access to the certificate chain, all the chain entries

must be placed in the file (in the right order).

Christopher Guest directed two music videos about Intel's vPro and Centrino Pro processor technology. Check it out, what do you think?

When dealing with Initial trust it is important to figure out who is trusting what.

First we will define a few terms to use.

Verifier - The entity that wants to trust the platform.
Platform - the vPro platform everyone is buying (you are buying one aren't you?)
Platform Configuration - the set of software measured by the platform (vPro measures BIOS and if executing the VMM)
Platform credentials - evidence of the platform properties which on vPro includes presence of TPM and the ability to execute TXT.

Now with these definitions let us work through a few trust decisions.

IT wants to trust new platform in the enterprise

Here we are assuming that the platform is brand new. The IT department uses the platform credentials to ensure that the platform delivered matches the platform credentials. If the platform does not come with credentials IT can create credentials for internal IT use.
Trust here is on either supplied credentials or direct creation of new credentials.

IT wants to trust a platform as it attaches to the network

here the platform contacts an access point (wired or wireless) and before assigning an IP address the access point asks for the current platform configuration. The trust necessary here is that the access point has to have sufficient evidence of the platform properties (credentials from our first use model) and then the access point obtains the platform configuration and validates the TPM report. (note that this is just the network access control protocol)
The access point must be able to determine what is a valid platform configuration and it does not matter if it is the first time the platform connects or the 20th time. The only issue is does the access point understand the platform configuration, if it does then the access point grants access, if it does not the access point blocks access. Determination of a valid platform configuration includes knowing what BIOS is supposed to be present and which VMM is supposed to be running.
Trust in this model requires the platform evidence (credentials) and the ability to understand the platform configuration.

Timing for the first two models does not matter. Whenever IT creates the evidence it is sufficient for IT, does not matter if it is the first day of use for the platform or in the second year of use. If one is using NAC, then the credentials provide the root of trust to believe the measurements and then the measurements provide information on the platform configuration. What else is executing on the platform does not change what measurements were taken. Measurements are not a one time operation but occur each time the associated root of trust executes (static RTM that is on each boot, dynamic RTM occurs on each invocation of GETSEC[SENTER]). It does not matter what else is executing or has executed, the measurement represents what occurred during the execution of the RTM.

Understand that platform configuration would not normally include the entire application stack. Rather the measured environment would provide additional measurements for applications. The entries in the PCR represent those components measured by the RTM and do not normally include applications. For instance when launching TXT the DRTM measures the SINIT authenticated code module, the measured launched environment (MLE), and a few registers. That is it. No applications, additional measurements would be provided by the MLE for applications or environments the MLE launches.

Applications can not just register with the TPM, there must be some process that measures the application and stores the measurement into some repository (which may or may not be the TPM).

Hopefully this little explanation helps in who is trusting what.

David

Intel got Christopher Guest (Spinal Tap) to direct music videos about Intel

and Intel

processor technology. Check them out, see what you think.

Hi the vPro team has asked me to blog here regarding the Trusted Platform Module (TPM) and general security issues. For some strange reason I said yes. I have never blogged before, though i do read some blogs regularly, so hopefully I get this right

To give a little bit of my bona fides, I have been the chair of the TPM workgroup for many years and have been the editor of the TPM spec since the begining of the TCG. For extra credit I am also the security architect of Intel Trusted Execution Technology (TXT). Those two jobs may be part of why it seems like I have no real life outside of Intel. But then I really do as this is my 27th year as a soccer coach, this year it is a U14 girls team, Go Shark Bait (ooh ha ha).

Anyway after that little digression some information on the TPM. A vPro platform requires the inclusion of a Version 1.2 TPM. The features of a TPM include storage of measurements, reporting the measurements, protection of information, and basic cryptographic services. I have classes that take hours to give and my first blog post will not cover all of the features and uses of the TPM.

What I will focus on today is that the TPM is an integral part of the platform. Adding a TPM to the platform requires laying out the real estate for the device, adding busses to the device, changing the BIOS to initialize and configure the device, and then OS and applications that take advantage of the TPM. Without all of these changes the TPM does not provide benefits to the platform or the users of the platform. One change that is very important to the platform is the ability to accept and store measurements. The platform is designed to perform a measurement for two critical processes. The first is the boot of the platform. The measurement of the boot process is known as the "static root of trust for measurement" or S-RTM. The other process is the TXT launch and measurement known as the "dynamic root of trust for measurement" or D-RTM. For those just learning about the TPM measurement in this context means take a cryptographic hash of the target (BIOS or VMM). The hash in use is SHA-1.

The result of either RTM is the knowledge, stored in the TPM as a measurement value, of the status of which BIOS just booted the platform or which VMM is executing. Knowledge of the status of the platform then enables both local processes and remote processes to make trust decisions regarding the platform.

Well most likely this is too long for a first post. Please be kind to a first time blogger and let me know what details you would like to dive into.