In the last few weeks, I have been posting many updates to the OpenDTK, in fact version numbers are up at a swift pace and you many have noticed that the auto-update system has kicked in many times. One area that I have been updating is the Manageability Director tool, the light weight Intel AMT provisioning tool. Nice, simple and it just works.
In the course of updating the OpenDTK I did come across a pretty big omission to the Intel AMT SDK’s documentation that will be of high interest to anyone trying to build their own Intel AMT activation software. Basically, with both TLS-PSK and TLS-PKI, the first time you connect to Intel AMT to perform activation; you need to use a non-standard TLS stack. That is right, you can't use the .NET TLS stack and hope to activate an Intel AMT machine. It’s NOT going to work. Why?
The first time you connect to Intel AMT, you have to use a PSK (pre-shared key) or a certificate (PKI) within the TLS connection. In the case of the TLS-PSK, you need a TLS stack that is modified with a Nokia proposed RFC to use a pre-shared key instead of client certificates. Most (almost all) TLS stacks don’t have this extension.
As for TLS-PKI, most people would assume that you are authenticating to Intel AMT using a client side certificate chain, should work on most TLS stacks? Nop. See, as a convention, when using TLS on the internet, one or both sides send certificate chains but always omit to send the root certificate. It’s assumed that if you trust the root certificate, it’s already in your certificate store and so, no need to send it. Both sides sent the entire certificate chain except the root. Problem is, during activation Intel AMT does not have a copy of the root certificates it trusts, only the hash of that certificate. So, you need to send everything including the root, something you can’t do with the .NET TLS stack and probably others.
The net result is that, you can’t activate Intel AMT in TLS-PSK or TLS-PKI unless you have a modified TLS stack. The Intel AMT SDK documents the activation flow, but does not mention this. Also, in the latest version of the Intel AMT SDK 8.0, the ConfigurationServer.exe sample was removed. This sample was the only correctly modified stack easily available to developers. In the case of the OpenDTK, I use this sample to perform initial activation, change admin password and push Intel AMT TLS certificated. I then switch to a C# WSMAN/SOAP stack to perform the rest of the configuration. With the only sample to do this gone, it leaves developers building their own activation solution pretty much out of luck.
If you have a copy of an older Intel AMT SDK, like a 7.0 version. You may have to keep a backup of it just in case. If you intend to write your own activation server, the ConfigurationServer.exe sample may be a lifesaver.