I've been getting quite a few questions recenly regarding provisioning. Many folks are confused when it comes to what type of provisioning works with which versions of AMT and I'm hoping that this post will help to clear up some of that confusion.


Currently, there are two types of provisioning, PKI (Protected Key Infrastructure) and PSK (Pre Shared Key). For those who are not familiar with what is involved with these two types of provisioning, PKI involves using a formatted provisioning certificate in order to establish a trust relationship between the AMT client and provisioning server where PSK uses a PID/PPS key pair to establish the trust for provisioning. There is quite a bit of documentation regarding how to setup PKI and PSK provisioning in the deployment documents for AMT, so I won't go into that detail here. What I'd like to cover here is what are the differences between these types of provisioning and which versions of AMT use which types of provisioning.






First, lets cover the different types of provisioning and a brief overview how each of them work.



PSK provisioning uses a Pre Shared Key to encrypt the provisioning process. In order for an AMT client to use a Pre Shared Key, however, the MEBx must first be programed with the correct key. This can be done in either one of two ways, manual entry or via a setup.bin file located on a USB thumb drive.



Manual entry is just that, a user must access the MEBx and manually type in the characters for the PID and PPS and any other settings that are required in order to get provisioning to work (system name, password change, etc). Once the user saves the changes to the MEBx, AMT starts sending out 'hello' packets to the provisioning server to start the provisioning process. This method is the most straight forward but is also the most time consuming, especially when attempting to deploy many systems at the same time.



USB thumb drive provisioning shortens the PSK entry process by using a formatted setup.bin file located on a USB thumb drive that can hold many PID/PPS pairs as well as password change information for MEBx. This key is then used on each system as it boots up to load the PSK information into MEBx. When the system boots, ME detects that a setup.bin file is located on the USB key and, if AMT isn't provisioned already, will prompt the user if they would like to load the provisioning information from the USB key. If the user confirms the request, then ME loads the first available PID/PPS entry into the PSK settings as well as changes the password for MEBx to the password set in the file. ME then marks that entry in the setup.bin file as used and reboots the system. Once rebooted, AMT starts sending out 'hello' packets using the PID/PPS pair. This method is better than manual entry, but only barely. This still requires a user to be at the system and to interact with the process.



PKI provisioning is split into two different types of provisioning as well, Bare Metal and Agent Based/Delayed provisioning.



Bare metal provisioning is where the factory settings in AMT are set at the OEM/System Integrator so that as soon as power and a network connection are applied to the system, then AMT will send out 'hello' packets and provisioning starts. If provisioning doesn't happen right away the provisioning period will continue for 24 hours, sending out 'hello' packets at a decreasing rate, after which AMT goes into delayed provisioning mode. This method of provisioning greatly improves the time savings from a deployment aspect by enabling many systems to be provisioned with minimal interaction from deployment personnel. This method works well when using a 3rd party trusted certificate that is natively supported in AMT (Verisign, GoDaddy, etc).



Agent based/delayed provisoining is where either the 24 hour provisioning period has expired without a successful provisioning transaction or, due to the AMT version, AMT requires an in-band agent or tool to start the PKI provisioning process. In order to start agent based/delayed provisioning the agent or tool sends a command down through the HECI driver in the host OS and tells AMT to start sending out 'hello' packets to the provisioning server. In addition, some basic configuration settings can also be sent to AMT in order to get it ready for provisioning (enable AMT, set PKI provisoining, etc). This method of provisioning tends to be the most reliable. Again this works best when using a 3rd party trusted certificate that is natively supported in AMT but in addition you gain the benefits of having an in-band agent that is able to assist the provisioning process by providing the provision server in-band information that helps keep the out of band aspects of AMT synced with the in-band host OS. Configured correctly, provisioning AMT with the assistance of an in-band agent can make the entire provisioning process hands free for deployment personnel.



Lastly, I want to touch on how each of these provisioning processes relates to the different AMT versions. Different versions of AMT support different types of provisioning. AMT 2.0, 2.1, 2.5 only support PSK provisioning. AMT 2.2 and 2.6 support PKI provisioning (as well as PSK) but only agent based PKI provisioning.  AMT 3.0 and higher versions of AMT support bare metal PKI provisioning (as well as agent based/delayed PKI and PSK provisioning).  A common utility used to accomplish agent based provisioning is the RCT (Remote Configuration Tool).



Provisioning is a very complex topic and what I've touched on here is really just the tip of the iceburg when it comes to understanding the intricacies involved. I hope I've provided more answers than questions, but if there is something you still don't understand, feel free to comment and I'll try to clear it up!




Matt Primrose