三、 基于度量的TPM访问机制    

    1. 引入度量的意义    

    由上述分析可知，TPM访问机制的安全性问题实质上就是如何在不安全环境中认证通信实体是否合法的问题，而解决这一问题的最佳方案之一是引入度量机制。TCG在“可信平台模块规范”中给出了与度量机制相关的描述，即在启动某一部件（包括软件）之前，必须先对其进行度量，如果符合度量要求，才能将控制权交予该部件，并允许其运行。由此可见，引入度量功能有助于解决TPM访问机制中的身份认证问题。    

    2. 基于度量的TPM访问机制    

    引入度量机制后，应用程序A仍然通过OIAP/OSAP来访问硬件安全设备（USBToken或TPM）。此时，需要A首先创建一个OIAP/OSAP初始协议包（简称initProtoPocket）。由于A自身不能保存SharedAuthData，因此初始协议包中应包含除inAuth之外的其他信息。度量模块（M）除需具备度量A的功能外，还需要为A计算身份认证信息inAuth，并将inAuth填入OIAP/OSAP初始协议数据包中。引入度量后的TPM访问机制如下所示： 

图4  基于度量的TPM安全访问机制     

    如果操作系统不支持度量机制（目前的操作系统，包括VISTA），可在保存SharedAuthData的硬件安全设备（如USBToken）中实现度量模块。但是，在USBToken中实现度量模块时面临两个难题：一是，USBToken属于从属设备，无法主动地获得访问自己的进程信息；二是，鉴于度量模块本身的重要性，度量模块不应建立在不安全的操作系统之上，但设计独立于操作系统的度量模块在技术上存在一定难度。因此设计支持度量功能的操作系统才是解决此类问题的最佳方案。    

     度量模块M一旦由操作系统实现（例如，由成操作系统一部分的TSS实现），向TPM访问机制中引入度量功能的工作就会变得相对容易。作为操作系统一部分的M可以无缝地从其他操作系统专用模块中获得所有企图访问T的进程信息。因此，M可准确无误地度量这些进程位于内存中的二进制执行代码，同时通过度量值为A计算，并填入访问T所需的共享认证信息inAuth。    基于度量机制的TPM访问流程如下所示：

    (1) A（应用程序）向TSS发出访问T（TPM）的请求，并生成OIAP/OSAP初始协议数据包initProtoPocket；

    (2)TSS启动T完成二项工作：对A发送的initProtoPocket签名；加载与该应用程序相关的共享授权信息和度量方案，不同的度量方案对应不同的共享授权信息。

    (3) TSS将由TPM签名后的{initProtoPocket}signed by tpm发送给A。由A判断其真实性。

    (4) TSS从操作系统的其他模块中获取访问TPM的进程（即A）信息。

    (5) TSS按照指定的度量方案对A在内存中的执行代码进行度量。

    (6) TSS使用度量值来计算A访问TPM时所需的inAuth，并填入initProtoPocket中形成完整的OIAP/OSAP协议数据包fullProtoPocket。

    (7) A按照TPM访问协议（OIAP或OSAP）向T请求需要访问的命令或信息。    基于系统度量的TPM访问机制无需A，或其他安全设备保存共享授权信息，减少了Eva截获共享授权信息的机会。由于度量是由操作系统发起的，因而安全的操作系统在改造后的TPM访问机制中占有主导地位，再加上操作系统能够清楚地掌握访问TPM的所有进程信息，因此Eva无法冒充合法的应用进程，从而能够有效地防止Eva的伪造和劫持攻击。 　　 　　　　

图5   引入度量后，访问TPM的主要流程 　　                       

四、结束语    

    本文首先通过分析指出了现有操作系统下，TPM访问机制存在的安全性隐患及其原因，然后引入可信度量功能对现有TPM访问机制进行改造，从而提高了现有TPM访问机制的安全性。

(责任编辑：adminadmin2008)