在通过大企业(Enterprise)模式来配置Intel® AMT时，为了保证配置过程中的数据传输的安全性，配置服务器到AMT的连接必须采用TLS的加密传输方式。Intel® AMT一开始就支持TLS-PSK（预共享密钥）的方式来加密配置服务器到AMT的通信数据，在AMT相关文档中经常提到的PID/PPS就是应用这种模式。
那到底PID（Provisioning ID）和PPS（Provisioning Pre-Shared Key）有什么不同呢？ 分别又是做什么用途的呢？
在TLS－PSK加密通信过程中，使用的对称密钥加密算法，也就是通信的双方（这里时AMT和配置服务器）需要在通信前知道本地通信所使用的密钥。由于需要双方事先知道，所以我们称之为与共享密钥，也就是我们这里的PPS。为了安全起见，预共享密钥是不能在通信开始之前通过明文的方式来协商的，因为随时可能被窃听。为了能让通信的双方知道要用那个密钥，AMT引入了PID。PID是可以在网络上明文传输，即使被第三方非法获得也是没有关系的，因为PID和PPS之间并没有算法上的任何关系，也就是不可能由PID推算出PPS来。
在AMT的TLS-PSK配置方式中，我们首先需要给AMT预设一对PID/PPS，这种预设可以是通过AMT的MEBX菜单，也可以是通过USB盘的方式。在配置服务器段，一般是预先配置了多对PID/PPS，存储在配置文件中。当AMT的PID/PPS被设置好后，并且AMT的网络连接正常的情况下，AMT会自动开始朝配置服务器发送hello包，其中hello包里面就包含了给AMT配置的PID的值。Hello包的发送规则是，AMT启动后开始是每分钟发送一次，共发送5次；然后在接下来的时间内每十分钟发送一次，也是发送5次；接下来是间隔每1个小时发送一次，也是发送5次；也就是每次AMT启动最多会发送15次hello包，如果中间配置完成，就停止发送hello包。这里需要注意的是，hello包是在AMT重新启动才会重新开始发送，而不是系统重启；AMT的重启取决于AMT的电源设置，如果设置成常开，那么需要断电后再次接上电源才会是AMT重新启动；如果设置的是只在S0有效，那么系统关机再开机就能使AMT重启。
配置服务器在接受到AMT发送过来的hello包后，从包里面解析出PID，然后通过读取配置文件的信息，找到与此PID相匹配的PPS，接着就用此PPS作为加密的密钥，将发往AMT的信息加密再发给AMT；AMT接收到后，自动用已配置的PPS来解密通信信息；这样就实现了AMT和配置服务器的加密通信。我们可以看到，在整个过程中PPS是不会在网络上传输的，传输的只是加密的数据，因此传输的配置信息在安全方面的保证是可靠的。
PID/PPS是不是随便使用一串字符就可以呢？也不是，需要有一定的规则。首先组成PID/PPS的字符只能是大写的A-Z和数字0-9，按每四个字符一组组成，中间用‘－’隔开；其中PID由两组四字符组成，PPS由8组四字符组成。另外，PID和PPS都有校验和检查规则，这里校验和检查是按每个字符对应的ASCII码来校验的；校验和的计算规则是：需要校验的字符的ASCII码的和摸0x24，结果如果是0x0 – 0x09，则结果加上0x30，结果如果是0x0A – 0x23，则结果再加上0x37，得到的结果就是最后一个字符的ASCII码。
对于PID，其最后一个字符是前面7个字符的校验和，比如0000-007M，最后一个字符的计算是： 0x30+0x30+0x30+0x30+0x30+0x30+0x37 = 0x15A；然后模0x24为0x16，大于0x09，则加上0x37得到0x4D，即是ASCII M。
对于PPS，其每组字符最后一个字符是前三个字符的校验和，比如 NKLD-G5DC-RRNQ-E9YZ-ZIJL-7LFL-VJED-69XJ，第一组字符是NKLD，前三个字符相加 0x4E+0x4B+0x4C = 0xE5，模0x24得0xD，加0x37得0x44，即是ASCII D。
为了保证每个AMT客户机使用的PID/PPS都不一样，并且不能由一台机器的PPS猜测出另外一台机器的PPS，因为PID/PPS的生成应该使用比较强的随机算法。Intel® AMT SDK有提供程序来生成PID/PPS，名字应该是USBFile.exe，有源程序可供参考，并且可以自动的将生成的PID/PPS写到U盘上，然后用U盘自动将PID/PPS设置到AMT中。另外，Intel SCS也提供了随即生成PID/PPS的功能，也支持将生成的PID/PPS导出到U盘。
TLS-PSK的加密通信方式为了保证PPS不在网络传输，因此需要管理员至少一次到客户桌面去配置PID/PPS，不管是手动配置还是通过U盘配置，因此我们称之为One-Touch-Configuration。在Intel AMT大规模部署的时候，这样的方法会感觉有些不方便，需要一台一台去设置，确实是一种体力活，因此在Intel AMT 3.0版本开始就引入了Zero-Touch-Configuration，引入了TLS-PKI配置方式，减轻了配置负担的同时，带来了配置过程的复杂性。笔者将会在下一篇博文中继续讲解ZTC的配置过程。
评论
铎锋老师写的很仔细，很有耐心，赞。学习...努力成为你这样的人喔，定下心来学东西做东西。
你好，duofeng
我在用DTk工具做完psk privison之后，通过DTK工具可以访问我的AMT machine，但是通过WEB UI的方式访问不了，总是提示用户名和密码不正确。验证了几台机器之后，都是这样的现象。采用这样的加密算法进行通信，好像在整个过程当中没跟WEB service发生什么联系，是不是因为这样的原因，web ui在使用psk或者是pki方法加密的machine当中，没有办法进行访问，还是在操作过程当中出现了什么问题？
WebUI功能是否打开？ 一般来说，只要webui接口打开了，都可以通过浏览器访问webui的。 另外，是否是配置成了mutual authentication的TLS方式？ 如果是，则访问webui需要本地证书。
webUI 在进行配置的时候已经打开，没有配置成mutual authentication的TLS方式，使用webUI进行访问的时候，IE的版本是否会有影响，在ie的Internet选项当中是否要将TLS1.0进行勾选？
Thanks
如果没有使用TLS，勾不勾选都没有关系的。 看样子可能是你的AMT机器有问题， 你试试看SMB模式下webui是不是可以访问。
是机器的问题，现在能够正常访问了，谢谢
前几天，实验了一下用DTK工具当中的PKI方式进行了相关的配置，有几个问题一直困扰着我。
PKI方式进行加密的时候，我生成了two certificate，其中一个是根证书，另一个是All permissions的证书，然后查看了一下，这两个证书都有自己相对应的私钥，也就是说解密肯定是在我console端进行的。在PKI的过程当中如果说ME将信息用公钥加密，然后Console端用私钥进行解密，进行通信的话，那么从console端发出的信息要经过什么操作呢？要是console端发出的信息用公钥加密的话，那ME当中肯定要有相关的私钥，进行相关的解密动作，但是私钥是怎样给传过去的呢，上网查了一下资料，一般情况下，私钥都是在本地存在的啊，一般是不通过网络进行相关的传输的，除非是通过已经建立安全通道的网络连接。还是说相关的公钥私钥已经存在ME当中？
AMT支持两种TLS模式：Server Authentication和Mutual Authentication；对于前一种模式，只需要为AMT生成一个包括公私钥的证书，然后存到ME中，Console安装相应的根证书的公钥证书即可通信；对于后一种模式，除了前一种模式的证书外，console还需要有自己的包含公私钥的证书，然后AMT的可信根证书列表要有console证书对应的根证书的公钥证书。 希望我有时间专门写篇文章来详细介绍，呵呵。
我通过将hash的值添加到ME当中来进行provision的，个人感觉这个hash值只是用来让根证书来验证是否合法的，那么这个证书的公钥是通过什么方式装到ＭＥ当中的，还是说两者在进行Handshake 的过程当中，给装到ＭＥ当中的。现在的疑问主要是证书的公钥时怎样给装到ＭＥ当中的。
那对于第一种方式，只要有根证书，来进行验证ＡＭＴ当中的的证书的合法性，就可以通信，那么如果第三方拥有根证书，并且通过别的方法，截取了Ｃｏｎｓｏｌｅ端和ＡＭＴ的通信（因为第一种方式当中,好像通信是没有加密的），是否就可以控制ＳＵＴ进行相应的操作。
现在用的ＴＬＳ，一般是用证书的方式来进行身份的验证，和建立一个安全的通道，而真正对数据进行加密和解密工作一般是用同步加密算法，不知道ＡＭＴ当中是否也是采用这样相关的方法？
根证书的公钥是预先安装进去的，不会出现在通信过程中，可以是OEM预设进去，或者是通过ME的配置菜单手工输入。
TLS的通信都是加密的，重放攻击基本无效。TLS通信中有用于会话识别的随机值和时间戳，要重放真不是那么容易。
AMT里面的证书主要是加密通信，辅助用于认证，amt主要还是用用户名和密码认证。 TLS的通信协商最后是根据双方的非对称密钥协商出同步加密算法的密钥，这个是TLS的标准，AMT也是遵循的。
页面