摘要 可信平台模块（Trusted Platform Module,简称TPM）在当前得以广泛地应用。但是，仅仅建立于OIAP协议和OSAP协议之上的TPM访问机制存在着弱点和安全隐患。本文在引入可信计算的核心思想——可信度量的基础之上，对原有TPM访问机制进行了改进，提高了原有TPM访问机制的安全性。
一、引言
具有安全存储和加密功能的TPM（可信平台模块）概念提出至今已近八年。可信计算渐渐成为全球计算机安全技术发展的主要趋势。TPM的核心思想是在个人计算机系统中嵌入一个可以抵抗篡改的，即非法用户无法对其内部数据进行更改的独立计算引擎，从而提高个人计算机中身份认证和数据加密应用服务的安全性。
按照TPM所处的操作系统环境，当前的TPM应用服务大致可以被分为两种：第一种是计算机主板提供了TPM芯片，但操作系统没有提供对TPM芯片的支持，因此TPM应用服务提供商需要为TPM芯片开发相应的驱动程序，并在此基础上为用户提供各种应用服务。 第二种是操作系统提供了对TPM芯片的支持，支持TPM的驱动程序成为操作系统的组件之一。
在第一种情况下，由于操作系统本身不支持TPM，无法建立操作系统度量机制，所以操作系统无法保障自身的完整性，从而也无法保障TPM支撑软件（TCG Software Stack，简称TSS，如TPM驱动程序）的完整性。因此，建立在这种环境中的TPM应用程序在访问TPM时存在着不安全因素。
第二种情况下，TSS被集成到操作系统中，成为操作系统的一部分。在操作系统的支持下，TMP可在计算机加电与启动系统之间对计算机的硬件系统和操作系统的重要组成部分进行静态度量。微软最新发布的操作系统Vista就属于第二种情况，由于操作系统被加载之前，要接受完整性度量，因此很大程度上保障了TSS的完整性。但是，由于Vista操作系统启动后，并没有继续为其他应用服务提供度量机制，因此，建立在这种操作系统中的TPM应用程序访问TPM时仍然存在不安全因素。
二、TPM访问机制的安全性分析
1. TPM访问协议
目前，TPM访问机制大多简单地建立在TPM访问协议的基础之上。TCG在“可信平台模块规范”中定义了两种用于访问TPM的基本协议，即独立对象授权协议（Object-Independent Authorization Protocol，简称OIAP）和特定对象授权协议（Object-Specific Authorization Protocol，简称OSAP）。OIAP是访问受TPM保护的密钥、数据或执行TPM授权命令时经常使用的访问协议之一。按照“可信平台模块规范”的定义，只有在基于TPM的应用程序（简称A）与TPM（简称T）之间共享指定的秘密授权信息（记作SharedAuthData）时，A才能访问受T保护的资源。OIAP协议的具体过程如图1所示。
其中关键步骤包括第3步，即A使用自己的SharedAuthData计算用于访问TPM的输入认证信息inAuth。
inAuth =HMAC(SharedAuthData ||SHA(inputParam)||inAuthSetupParam) inputParam代表请求T执行的命令TPM_COMMAND及其相关输入参数。而inAuthSetupParam=（rand1||rand2||SessionHandle）。
第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之间的通信安全。
三、 基于度量的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访问机制的安全性。
