第4步，即T使用自己的SharedAuthData来验证A的输入信息inAuth是否合法。具体过程如下：T加载与受保护资源相关的共享信息SharedAuthData。同时计算

HM = HMAC (SharedAuthData||SHA(inputparam)||inAuthSetupParam)，   

    其中，outputParam代表TPM_COMMAND及其返回值和输出参数，然后比较HM和inAuth是否相等，如果相等则执行A所请求的TPM_COMMAND命令。   

    访问TPM的另外一条协议OSAP，与OIAP的主要差别在于，通信时双方使用共享授权信息SharedAuthData共同协商一个临时共享信息，并使用该临时共享信息实现相互认证。OSAP可在只建立一条会话的情况下，实现多条命令多次使用同一受保护资源的功能，本文对OSAP不作详细介绍。通过上述分析可以看出，无论A使用哪种协议访问T，都必需拥有两者共享的授权信息SharedAuthData。    

    2.  安全性分析    

    抛开OIAP和OSAP本身易受重放和替代攻击的固有弱点不提，TCG给出的“可信平台模块规范”中将TPM之外的环境定义为不可靠环境，并指出，用于获取TPM授权的共享信息必须被保存于安全的环境中。但规范中并没有给出保护授权信息的具体措施和方法。因此如果操作系统在启动后不再提供度量机制（如Vista），那么用于访问TPM的授权信息仍然存在受到攻击的可能性。因此，建立在OIAP和OSAP协议之上的TPM访问机制仍然存在着不安全因素。    

    由于在Vista一类的操作系统之中，TSS作为操作系统的一部分，在被加载到系统核心态之前，已接受完整性检查。所以，如果能够较为合理地解决OIAP/OSAP自身的安全性问题，那么A将成为攻击者Eva的重点攻击目标。针对A的攻击主要可分为以下两种情况：

■ Eva试图非法获取A所持有的，用于访问T的共享认证信息SharedAuthData。

■ Eva试图以篡改A，甚至替换A的手段来破坏A的完整性，冒充A发动劫持或伪造攻击。

    显然，A自身持有用于访问T的共享认证信息是Eva能够发动第一类攻击的主要原因。因此，抵抗此类攻击的方法非常明确，即将SharedAuthData保存到安全的存储环境中。引入硬件安全设备USBToken是抵抗此类攻击的有效方法之一。 

3   引入USBToken后的TPM访问机制     

    引入硬件安全设备USBToken后，可将用于访问TPM的共享认证信息SharedAuthData保存于USBToken中，访问TPM时所用的inAuth也由USBToken生成。由于此时攻击者Eva无法从USBToken中获取共享认证信息，因此实施第一类攻击的难度将大大增加。    

但是采用USBToken，并不能有效地阻止Eva发动第二类攻击。由于位于不安全的环境中，A同样无法向USBToken证明自己的身份。因此，Eva依然可以采用第二类攻击手段冒充A访问USBToken，并从USBToken中获取用于访问T的认证信息inAuth。实际上，在引入USBToken之后，应用程序A向TPM证明自身身份的问题被转换成向USBToken证明自身身份的问题，其实质是一样的。    

既然位于不安全环境中的A没有能力保存任何可以证明自身身份的秘密信息，那么完全建立在TPM访问协议（OIAP/OSAP）之上的TPM访问机制也肯定无法彻底保证A与T之间的通信安全。

(责任编辑：adminadmin2008)