第5章 信息系统可信性

第５章信息系统可信性5.1可信性概述5.2可信度测度和评估5.3可信计算平台5.4

TCG软件栈5.5

TSS服务

5.1可 信 性 概 述

当前以防火墙、入侵监测和病毒防范为主要构成的传统网络安全系统，是以保护服务器不受外来入侵为重点，在防外上有一定的效果，但在保护整个系统上却并非固若金汤。这是因为它不适应目前信息安全主要“威胁”源自内部的状况。而要解决内部安全威胁，就需要建立一个信息的信任传递模式。必须做到终端的可信，才能从源头解决人与程序、人与机器以及人与人之间的信息安全传递。可信计算技术源自于容错计算，是以1971年召开第一届国际容错计算会议(Fault-TolerantComputingSymposium)为起点。从1975年开始，商业化的容错机推向市场。到20世纪90年代，软件容错的问题被提了出来，进而发展到网络容错。与此同时，安德逊(J.P.Anderson)首次提出可信系统(TrustedSystem)的概念。早期学者对可信系统研究主要集中在硬件设备和运行于其上的软件的安全和可靠性。此时的可信计算实际上是一种可靠计算(DependableComputing)的概念，与容错计算(Fault-TolerantComputing)领域的研究密切相关。

1999年10月由国际几大IT厂商Compaq、HP、IBM、Intel和Microsoft牵头组织了可信计算平台联盟(TrustedComputingPlatformAlliance，TCPA)。2000年12月，美国卡内基梅隆大学与美国国家宇航总署的艾姆斯研究中心牵头，由十几家大公司和著名大学成立了高可信计算联盟，该组织致力于发展新一代安全、可信的硬件运算平台。2002年1月微软的比尔·盖茨提出可信计算(TrustworthyComputing)概念，并在邮件中称微软公司未来的工作重点将从致力于产品的功能与特性转移到侧重于解决安全问题。2003年4月，TCPA被重组为可信计算组织(TrustedComputingGroup，TCG)。TCG在TCPA强调安全硬件平台的基础上，进一步增加了对软件安全性的关注，旨在从跨平台和操作环境硬件组件和软件接口两方面，促进不依赖特定厂商的可信计算平台工作标准的制定。

目前可信计算研究有三个技术分支，分别是TCG的可信计算(TrustedComputing)，侧重于容错计算的可靠计算(DependableComputing)，以及微软的高信度计算(TrustworthyComputing)，三者之间的比较见表5-1。表5-1三种可信计算研究路线的比较

TCG的可信计算重点在于推出基于硬件安全防护的可信平台模块(TrustedPlatformModule，TPM)，以加强异构计算机平台的计算环境为目标。TPM作为一个系统级的安全芯片被集成到平台的主板上，为平台提供了可信根的功能，用可信根保证系统加电时的初始状态是可信的，之后利用TPM中的平台配置寄存器的功能，对系统的各个部件进行完整性度量、存储和报告，通过引入信任链的概念，保证整个系统的安全启动。TPM还通过软件协议栈(TCGSoftwareStack，TSS)为应用程序提供各种安全应用接口。可靠计算主要关注操作系统自身安全机制和支撑它的硬件环境，并与容错计算领域研究密切相关。人们关注元件随机故障、生产过程缺陷、定时或数据不一致、随机外界干扰、环境压力等物理故障，同时，关注设计错误、交互错误、恶意推理、暗藏入侵等人为故障造成系统失效的情况，设计出了许多集成故障检测技术、冗余备份系统的高可用性容错计算机等。可靠计算属于早期的可信计算研究，在可靠计算中，一个数字系统的可信性是指该系统提供确实可信服务的综合能力，其衡量标准有6个：可靠性(Reliability)、可用性(Availability)、可测试性(Testability)、可维护性(Maintainability)、安全性(Safety)以及保密性(Privacy)。高信度计算是一种可以随时获取的可靠安全计算，它从目标、手段、实施三个角度来考虑。目标考虑最终用户的需要，提供安全性、私密性、可靠性和商务完整性的保护。手段是实现目标所要进行的商务和工程方面的考虑，包括的策略有安全开发策略、信息平等原则、可用性策略、可管理策略、准确性策略、实用性策略、可审计策略和透明性策略。在高信度计算的实施方面，微软的高信度计算涵盖了整个计算机联机系统，包含从单个计算机芯片到全球Internet服务的各个方面。2007年微软基于下一代安全计算基(NGSCB)推出安全操作系统解决方案，并联合Intel推出LaGrande可信芯片技术。5.1.1

TCG的可信定义

TCG对“可信”的定义是：“一个实体在实现给定目标时，若其行为总是如同预期，则该实体是可信的”(Anentitycanbetrustedifitalwaysbehavesintheexpectedmannerfortheintendedpurpose)。这个定义将可信计算和当前的安全技术分开：可信强调行为结果可预期，但并不等于行为是安全的，这是两个不同的概念。根据英特尔的密码与信息安全专家大卫·格劳洛克(DavidGrawrock)的说法，如果你知道你的电脑中有病毒，这些病毒会在什么时候发作，了解会产生如何的后果，同时病毒也确实是这么运行的，那么这台电脑就是可信的。从TCG的定义来看，可信实际上还包含了容错计算里可靠性的概念。可靠性能保证硬件或者软件系统性能可预测。

可信计算的主要手段是进行身份确认，使用加密进行存储保护及使用完整性度量进行完整性保护。但是由于引入了TPM这样的一个嵌入到计算机平台中的嵌入式微型计算机系统，TCG解决了许多以前不能解决的问题。TPM实际上就是在计算机系统里面加入了一个可信第三方，通过可信第三方对系统的度量和约束来保证一个系统可信。5.1.2

TCG体系结构规范框架

TCG具有明确的目标和组织架构，并且为基于TPM的平台使用定义了预期的场景、执行程序和预期的生产实施。这些文档并不包含标准化的内容。TCG的文档结构如图5-1所示。

(1) TCG目标。TCG是一个非营利的工业标准组织，以加强异构计算机平台的计算环境安全为目标。TCG的任务是通过平台、软件和技术的协作，定义、开发、推广一套开放的、系统的可信计算规范，提供一整套可信计算安全技术，规范硬件构建模块和通用的软件接口，设计多平台、多外设的可信计算环境。图5-1

TCG的文档结构

(2) TCG应用场景。①风险与资产管理，在突发事件发生时，使个人和企业财产的损失最小；②数字版权管理，保护数字媒体不被非授权地拷贝和扩散；③电子商务中有利于交易双方互相了解和建立信任关系；④系统监测与应急响应中可以监测计算机的安全状态，发生事件时作出响应。

(3)完整性验证。其涉及可信根、完整性度量、完整性存储、完整性报告可信启动(安全边界)。其中可信根有度量可信根(RTM)、存储可信根(RTS)、报告可信根(RTR)、度量可信根核心(CRTM)。完整性度量是一个过程，获得一个平台的影响可信度的特征值(Metrics)，存储这些值，然后将这些值的摘要放入PCRs中。通过计算某个模块的摘要同期望值的比较，就可以维护这个模块的完整性。完整性存储是将存储度量值存储在度量存储日志(StoredMeasurementLog，SML)中，并将其摘要存入PCRs。此外还需要存储期望值。

(4) TSS。TSS(TPMSupportSoftware)即可信软件协议栈，它允许应用程序和可信移动设备TMD(TrustedMobileDevice)中的可信平台模块(TPM)进行通信。它为TPM功能的使用提供了接口，如鉴权(Authentication)、授权、保护存储和认证(Attestation)。它还为利用TPM基于硬件的密码服务提供了接口，允许应用程序使用TPM来生成密钥、加密/解密、签名等。TSS为应用程序利用TPM服务提供了同步访问机制。除此之外，TSS还管理TPM资源。TSS结构如图5-2所示。图5-2

TSS结构

TSS的需求体现在以下几方面：

①提供给应用程序独立于TPM硬件实施的通用标准接口；

②提供给应用程序一接口使用TPM的密码操作、保护内存(SealedStorage)和认证；

③如果TSS被旁路，则不能使用TPM可信服务；

④以对应用程序透明的方式管理TPM硬件资源；

⑤为TPM事件提供日志/审计服务；

⑥除了支持基于TPM的密码运算之外，TSS还应提供集成工业标准密码服务提供的方法。整个体系主要可以分为三层：TPM、TSS(TPMSoftwareStack)和应用软件。TSS处在TPM之上，应用软件之下，称做可信软件栈，它提供了应用程序访问TPM的接口，同时进行对TPM的管理。TSS分为四层：工作在用户态的TSP(TrustedServiceProvider)、TCS(TSSCoreServices)、TDDL(TPMDeviceDriverLibrary)和内核态的TDD(TPMDeviceDriver)。

TPM是由TCG定义的安全硬件子系统。TPM持久地依附在平台之上，并为基于硬件的可信根提供服务。TPM软硬件提供的密码功能有RNG、哈希、HMAC、非对称密钥生成、非对称加解密等。TPM由160位的平台配置寄存器组成，PCR用来保存SHA-1操作的结果。TPM至少拥有8个PCR，用来在可信启动过程中记录软件完整性度量的结果。

TSS由TPM设备驱动器、TSS核心服务(TCS)和TSS服务提供者(TSP)组成。TPM设备驱动器是由TPM厂商提供的硬件驱动。TSS核心服务提供了管理密钥和证书、内容和审计管理等所用到的基础设施。应用程序通过使用TSS服务提供者这一层，与TSS核心服务通信。TSP是栈中的最顶层部件，为应用程序提供TPM服务。

TCG软件栈定义了两种模式—用户模式和内核模式，三个接口—TCG服务提供者接口(TSPI)、TSS核心服务接口(TCSI)和TPM设备驱动接口(TDDLI)。内核模式包括TPM和TPM的设备驱动。用户模式又分为用户进程和系统进程。用户进程指的是TCG服务提供者提供给外部应用程序的服务操作；系统进程指的是TCG设备驱动库提供的TSS核心服务操作。三个接口与不同层次的计算平台服务通信，其中，TDDL接口提供了用户模式和内核模式之间的过渡，它工作在TPM设备和设备驱动层之上；TCS为一组普通的平台服务提供接口，它保证了即使在一个平台上可能存在多个TCG服务提供者，它们都只展示相同的行为；TSP为TPM提供了一个接口，它作为应用程序驻扎在公共的进程地址空间。TSP提供两种服务：上下文管理和密码使用。上下文管理考虑到应用程序和TSP资源的使用效率，并为此提供动态的操作；密码功能的使用则是为了充分地利用TPM受保护的功能。

1．TCG服务提供层(TSP)

TSP提供应用程序访问TPM的C++ 界面，基于一个面向对象的底层结构，驻留在与应用程序一样的进程地址空间(都是用户进程)。授权协议在这一层通过一个在这层编码的用户接口，或TCS层的回调机制(如果调用者是远程)来实现。

TSP提供两种服务：上下文(Context)管理和密码操作。上下文管理器产生动态句柄，以便高效地使用应用程序和TSP资源。每个句柄提供一组相关TCG操作的上下文。应用程序中不同的线程可能共享一个上下文，每个线程也可能获得单独的上下文。为了充分利用TPM的安全功能，TSP层也提供了密码功能。但是内部数据加密对接口是保密的，例如报文摘要和比特流的产生功能等。

2．TCG核心服务层(TCS)

TCS提供一组标准平台服务的API(ApplicationProgrammingInterfaces)。一个TCS可以给多个TSP提供服务。如果多个TCG服务提供者都基于同一个平台，则TCS保证它们都将得到相同的服务。TCS提供了4个核心服务：①上下文管理—实现到TPM的线程访问；②证书和密钥的管理—存储与平台相关的证书和密钥；③度量事件管理—管理事件日志的写入和相应PCR(PlatformConfigurationRegisters)的访问；④参数块的产生—负责对TPM命令序列化、同步和处理。

3．TCG设备驱动库(TDDL)

TDDL是用户态和内核态的过渡。它仅仅是一个接口，不对线程与TPM的交互(Interaction)进行管理，也不对TPM命令进行序列化(Serialization)，而这些是在高层的软件堆完成的。由于TPM不是多线程的，一个平台只有一个TDDL实例(Instance)，从而只允许单线程访问TPM。TDDL提供开放接口，使不同厂商可以各自自由实现TDD和TPM。

5.2可信度测度和评估

1983年美国国防部(DoD)首次公布了《可信计算基系统评估准则》(TCSEC)以用于对操作系统的评估。这是IT历史上的第一个安全评估标准，1985年公布了第二版。TCSEC有一个为业界所熟知的名字“橘皮书”(因其封面的颜色而来)。为了针对网络、安全系统和数据库具体情况来应用橘皮书准则，美国国防部国家计算机安全中心又制定并出版了三个解释性文件：《可信网络解释》、《计算机安全子系统解释》、《可信数据库解释》，这三个解释性文件和橘皮书被合称为美国计算机系统安全评估标准彩虹系列。

TCSEC所列举的安全评估准则主要是针对美国政府的，涉及商用可信自动数据处理系统，着重点是基于大型计算机系统的机密文档处理方面的安全要求。准则中描绘了不同安全等级的要求特点和可信措施，其目的是：

(1)为生产厂商提供一种安全标准，作为检查和评价产品的依据；

(2)为国防部和用户评估处理保密信息的计算机系统安全可信度提供一种安全度量；

(3)为产品规格中规定的安全要求提供基准。

TCSEC的安全等级分为A、B、C、D四级，A级最高，D级最低。每级的具体划分确定按照以下四个方面进行：安全策略、可计算性、可信赖性、文件编制。下面对每个安全等级的内容和要求做简要说明。

1．非保护级

D等是最低保护等级，即非保护级。它是那些经过评估，但不满足较高评估等级要求的系统设计。因此，这种系统不能在多用户环境下处理敏感数据。

2．自主保护级

C等为自主保护级，具有一定的保护功能，采用的措施则是自主访问控制和审计跟踪，它一般只适用于具有一定等级的多用户环境，并具有对主体责任和他们的初始动作审计的能力。它对各级提供无条件的安全保护，并通过审计追踪提供主体及其产生动作的责任。这一等级分为C1和C2两个级别。

1)自主安全保护级(C1级)

C1级通过提供用户和数据隔离，就能够满足市场可信计算基TCB(TrustedComputingBase)的自动安全要求。所谓可信计算基，就是一个安全计算机系统的参考校验机制，它包括所有负责实施安全策略以及对保护系统所依赖的客体实施隔离操作的系统单元。简单地说，即所有与系统安全有关的功能均包含在TCB中。在这一级，TCB应在命名用户和命名的客体之间定义和进行访问控制。它用的机理(如个人/组/公共控制，访问控制表)应允许客体拥有者指定和控制客体是由自己使用，还是由用户组或公共使用。该级需要在进行任何活动之前，由TCB去确认用户身份(如采用口令)，并保护确认数据，以免未经授权对确认数据的访问和控制。通过用户拥有者的自主定义和控制，可以防止自己的数据被别的用户有意或无意地读出、篡改、干涉和破坏。C2级系统同时提供软件和硬件特性，并定期地检查其运行正确性。系统的完整性要求硬件和软件能提供保证TCB连续有效的操作特性。评价为C1级多依据系统某些特点，目前生产的大多数计算机系统都能达到这一等级，但这级系统不一定要经过严格的评价。

2)可控安全保护级(C2级)

在C2级，计算机系统比C1级有更细致的自主访问控制。它通过注册过程，与安全有关事件的审计和资源隔离，使得用户的操作有可查性。在安全策略方面，C2级系统除具备C1级所有功能外，还提供授权服务，还可提供控制，以防止存取权力的扩散。应确定用户的动作或缺省客体提供保护，避免非授权存取。它可指定哪些用户可以访问哪些客体，未经授权用户不得访问已指定访问权的客体。同时还提供了客体再用功能，即对于一个未使用的存储客体，TCB应该能够保证该客体不包含未授权主体的数据。C2级系统还提供唯一的识别自动数据处理系统各个用户的能力；提供将这种身份与该客体用户发生的所有审计动作相联系的能力。C2级系统能与该识别相符，可审计所有主体进行的各种活动。要求能对可信计算基(TCB)进行建立、维持和保护，对客体存取的审计跟踪，同时应保护审计信息，并能防止修改、未经授权访问或毁坏审计信息。TCB也能记录下列类型的事件：①确认和识别安全机理的使用；②将客体引入用户地址空间；③客体的删除；④操作人员、系统管理人员和安全管理人员进行的各种活动，特别是与安全相关的活动。对于每个审计事件，审计记录应包括用户名、事件发生时间、事件类型、事件的成功或失败等。对于确认事件，请求源(如终端ID)也应包括在审计记录中；对于客体进行访问的事件，审计记录也应包括客体名。通过识别符，自动数据处理系统管理人员应能有选择地审计任一或多个用户的活动。保障要求TCB除C1级的要求外，还必须保留在一特定区域，以防止外部人员的篡改。由于TCB控制的资源中是以主体和客体定义的子集，TCB应与被保护的资源隔离，以使存取控制更容易，并达到审计目的。DEC公司的VAX/VMS操作系统被确认为C2级。

3．强制安全保护级

B级为强制安全保护级，这一等级比C等级的安全功能有很大增强。它要求对客体实施强制访问控制，并要求客体必须带有敏感标志，可信计算基利用它去施加访问控制。B级分为B1、B2、B3三级。

1)标记安全保护级(B1)

该级具有C2级的全部功能，并增加了标记、强制访问控制、责任、审计和保证功能。

(1)标记。与每个主体和存储客体有关的标记都要由TCB维护。这些标记在实施强制访问控制时使用。为了引导非标记信息，TCB授权用户申请请求并接受数据安全级。主体的各种活动能通过TCB审计。在这一级标记有如下要求：

①标记的完整性：安全标记应能准确地体现主体和客体的安全级别。当那个敏感标记由TCB输出时，应该能够准确地体现出其在TCB的内部标记，并标志着与其输出信息相关联。②标记信息的输出：TCB应该能够指明每个通信信道和I/O设备，是作为单级还是多级使用。其指定都应由人工来做，并由TCB来对这种活动进行审计。

③多级设备输出：当TCB输出一客体到多级I/O设备时，敏感标记应于客体仪器输出，并以同样的形式与输出信息一起驻留在同一物理介质上。当TCB通过多级通信信道输出和输入一个客体时，使用的协议应在敏感标记和发送(或接收)的信息间提供明确的对应关系。④单级设备的输出：不要求对单级I/O设备和单级通信信道所处理信息保留敏感标记。然而，TCB应该包括一种机制，通过该机制授权用户可经由单级通信信道或I/O设备来安全地传输来自单级安全级的信息。

⑤硬拷贝标记输出：ADP系统管理员应该能够指定与输出敏感标记相关联的可打印标记名。TCB标识出硬拷贝敏感标记(人们可以读的)输出的开始和结束。独特敏感标记可以是秘密、机密和绝密字样等。

(2)强制访问控制。TCB应对它控制下的所有主体和客体，施加一种强制访问控制策略。主体和客体要指定敏感标记，这些标记是分层保密等级和非分层保密等级的结合，并作为强制访问控制判断的依据。TCB应支持两个以上的安全级。在由TCB控制的主体和客体之间的访问必须满足下列要求：只有在主体的安全级中分层保密等级小于或等于客体安全级中分层保密等级时，才允许对客体进行写操作，并且在客体的安全级中，非分层等级包括主体安全级中所有的非分层等级。

(3)责任。在用户开始完成任何由TCB干预的活动时，TCB将要求对他们进行识别，并且TCB要保存确定数据，以防止未经授权的用户访问。用于识别和确认的这些数据包括验证用户身份信息(如口令)、检查用户签证信息和用户授权信息。

(4)审计。审计包括除C2级的全部功能，还可以对任何滥用职权的人可读输出标志，对安全级记录的事件进行审计，也能对基于安全级的用户活动进行有选择的审计。

2)结构保护级(B2)

该级着重强调实际中的评价手段。为此，B2级增加了以下功能：

(1)安全策略。加强了强制访问功能，它将强制访问控制对象，从主体和客体扩张到I/O设备等所有资源，并要求每种系统资源必须与安全标记相联系。

(2)责任。在责任方面，提高了连续保护和防渗透能力。它保证了和用户之间开始注册和确认是的通路是可信的，提高了系统连续保护和防渗入的能力，且审计功能得到加强，能审计使用隐蔽信道的标记事件。隐蔽信道是指一个进程可用违反系统安全策略的方法去传输信息。隐蔽信道包括所有允许一个进程直接或间接地对一个存储单元写，而另一个进程直接或间接读的载体。

(3)结构。应支持操作人员和管理人员的分离，能执行最小特权原则。即每个主体进行授权任务时，应被授予完成任务所必需的最小存储权。应划分与保护有关和与保护无关部分，并把它的执行维持在一个固定的区域，以防止外部干预和篡改，其设计和实现要利用检测和评估，应支持操作人员和管理人员的分离。Honeywell公司的操作系统Multics被确认为B2级。

3)强制安全区域级(B3)

B3级监督所有主体对客体的访问，防篡改，并提供分析和测试。它将审计机理扩展到能报知与安全有关的事件。B3级系统要有恢复能力，为此，它增加了以下功能：

(1)安全策略。采用访问控制表进行控制，允许用户指定和控制对客体的共享，也可以指定命名用户对客体访问的方式。

(2)责任。它能监视安全审计事件的发生和积累，当超出阈值时，能立即报知安全管理人员进行处理。

(3)保证。只完成与安全有关的管理功能，对其他完成非安全功能的操作要严加限制。在系统出现故障和灾难性事件后，要提供过程和机理，以保证在不损害保护的条件下，使系统得到恢复。

4．验证安全保护级

A级为验证保护级。它的显著特征是从形式设计规范说明和验证技术导出分析，并高度地保证正确实现TCB。其特点是使用形式化验证方法，以保证系统的自主访问和强制访问控制机理能有效地使该系统存储和处理秘密信息和其他敏感信息。该等级分为A1和超A1两个级。

1)验证设计级(A1级)

A1级的主要特点是要求用形式化设计说明和验证方法来对系统进行分析，确保TCB按设计需要实现。Honeywell公司的Scomp系统被确定为A1级。

2)超A1级

超A1级超出目前的技术发展，有些具体要求很难提出，仅提出了一些设想。它为以后的研究提供了指导。

5.3可信计算平台

除了支持隐私保护外，可信计算组织(TCG)技术委员会在可信计算平台模块(TPM)的设计中提出了很多目标。其中，在设计中拥有以下能力是非常重要的：

(1)安全地报告当前所引导的环境；

(2)安全地存储数据；

(3)安全地标识用户和系统(在不影响隐私保护的前提下)；

(4)支持标准的安全系统和协议集；

(5)支持在同一系统为多个用户提供各自的安全保障；

(6)生产成本低廉。当然，“安全”只是一个相对的术语。如果给定足够的资源，任何信息安全产品都能被攻破。在TCG出现之前，个人电脑(PC)的安全是相对较低的，因此对于PC而言，任何安全上的改进都是非常有价值的。尽管在TCG的规范中，并没有TPM与PC主板的连接方式上的安全要求，但还是期望TPM与附有安全BIOS的PC主板之间在设计上采用安全的连接方式，以改善PC的安全状况。同时，TPM模块在设计上如果能满足FIPS140-2以及《通用评价准则》(CC)EAL3级别认证，将会对PC的安全情况有更好的改善。(在TSS1.2规范中，EAL等级被升到EAL4+)。由于TPM在设计上要求成本相对低廉，因此对规范而言，大量非常好的特性都被忽略了，其中包括实时时钟、SSL加速器、对称加密引擎、对椭圆曲线的支持和对扩展的安全散列算法的支持等。所有这些功能尽管都是很好的，但不是必需的，其中一些可能出现在最近的新规范中。

TPM的设计是灵活的，因此大量在设计中没有定义的功能可以通过设计中的其他一些功能来模拟或通过芯片中的软件来实现。5.3.1安全地报告当前环境：平台状态

TCG的首要设计目标之一是提供一种可信的方法去度量和报告平台的环境。但是，看似简单的目标实现起来确实是非常困难的。如果使用者想要问软件：“这些软件是我能够信任的吗？”那么，仅当这个软件在回答这个问题时没有被破坏，你才能信任软件对这一问题的回答。这就陷入了一个典型的“鸡生蛋，蛋生鸡”的循环问题。只有软件是可信的，软件对问题的回答才能被信任。而软件只有正确回答了问题，软件才能被信任。尽管智能卡、USB密钥、iButton这些硬件令牌相对而言是比较难于被破坏的，但也难于和平台集成在一起，因此试图利用这些硬件对平台上的运行状况进行度量是比较困难的。在PC中嵌入安全芯片的解决方案虽是安全令牌的解决方案(如智能卡、USBFob)，但它们之间存在很大的差异。这种差异不仅仅体现在封装方式上，在本质上更是存在着很大的差异。采用引导安全设备的设计不能依赖这些安全令牌与PC建立一种持久的关联关系。从本质上而言，安全令牌意味着该令牌可以在各种系统之间移动。同时，通过这些安全令牌也无法建立一个令牌与系统组件之间的可信连接。这是因为这些设备与PC的连接是通过读卡器或者该写口来实现的，而它们没有一个先验的方法来决定安全令牌以怎样的方式连接到系统中。TCG委员会希望利用类似平台配置寄存器(PCR)这类新功能，能够在安全芯片和PC平台之间建立一种持久的和已定义的连接。TPM的设计目标之一就是提供一种远程判断平台可信状态的能力。

1.存储系统启动序列的记录

TCG使用系统启动序列来判断平台的可信状态。这包括了BIOS、启动过程中要求控制权的板卡、引导加载程序、操作系统内核以及其他用户选择的部件(例如，操作系统启动的第一个程序)。短语“bootacomputer”来源于“Pullingoneselfupbyone’sownbootstraps”(拎着鞋带把自己提起来，即凭自己的力量重新振作起来或自力更生的意思)。当一个系统正在启动时，首先是BIOS取得控制权，BIOS系统将建立一个基本的输入/输出子系统来初始化一些板卡。然后BIOS将控制权传递给系统安装的各种板卡的BIOS，当这些板卡完成了相应工作后，BIOS将回收控制权。这一系列工作完成以后，控制权将传递给引导加载程序，引导加载程序把控制权传递给操作系统内核。操作系统将装载各种各样的设备驱动和服务，然后可能启动程序或者由终端用户来启动某个程序。当终端用户可以控制操作系统去做某些工作，将机器的控制权在不同实体之间传递时，用户如何才能知道系统并没有受到攻击，且没有允许黑客访问当前用户的任何操作呢？

TCG采用了一种链式的设计来解决这一问题。系统从一个很小的信任根开始启动，信任根是整个系统中第一个获得控制权的模块。这个信任根是BIOS的一部分。这个模块记录了在将控制权传递给整个BIOS之前哪一个BIOS将被用来启动系统。接下来，BIOS将记录哪一个板卡的BIOS将获得控制权。哪一个引导加载程序将获得控制权也将被记录下来，然后引导加载程序将记录哪一个内核将获得系统控制权，最终内核将记录操作系统引导后将有哪些程序会获得控制权。TPM正是用来存储这些记录值并安全地报告这些情况的重要部件。由于TPM以一种预先定义的方式直接与平台相连接，因此链式结构的设计可以利用硬盘存储空间较大的优势来存储密钥。另外，由于TPM能确保在系统启动序列中处于主导地位，因此BIOS可以依赖TPM而存在，并在操作系统引导之前的早期系统启动序列中将度量值存储于TPM的平台配置寄存器(PCR)中。在这个阶段是不能依赖那些可移植安全令牌的，因此来自于这些设备的报告是不可信的。

这里存在一个显而易见的问题：TPM不可能存储前面所描述的所有信息。如果要求TPM拥有足够大的内存去存储操作系统内核，那么对于TPM生产商而言，这种高昂成本将是不可负担的。因此，TPM采用了一种存储信息摘要而不是信息本身的方法来解决这一问题。这些信息摘要要被存储到平台配置寄存器中。对于PC而言，平台配置寄存器(PCR)是一种新事物。通过PCR，各种各样的摘要值存储到TPM内部的存储空间中，并通过一个所谓扩展的操作来进行修改。这一操作的具体方法是，给定一个当前PCR值，并将一个新的输入值连接到后面，接着对该值采用安全散列算法(SHA-1)进行计算，最后用产生的新值替换当前PCR值。SHA-1操作是一种输入为任何大小的文件、输出为20B数据的算法，这个算法可以在美国国家标准与技术研究所(NIST)的网站()上找到。对于SHA-1算法来说，若输入中任何一位发生变化，则输出平均有一半会发生变化。在系统启动过程中，序列中的每一个执行程序在执行之前的度量摘要值都将存储于PCR中。这样，在BIOS将控制权交给引导加载程序之前，它就会计算引导加载程序的散列值，并将值“扩展”到PCR中。在引导加载程序将系统控制权交给操作系统内核之前，它会计算操作系统内核的散列值，并将值“扩展”到另一个PCR中。

这样，信任根记录了BIOS的状态，BIOS记录了各类板卡固件和引导加载程序的信任状态。引导加载程序记录了操作系统内核的信任状态。通过检查保存在PCR中的值，就可以判断这些值是否对应着可信的程序。如果BIOS所对应的PCR记录值是可信的，那么BIOS对于PCR的“扩展”就是可信的。如果引导加载程序是可信的，那么引导加载程序所做的PCR“扩展”就是可信的。通过这种方式，信任的边界就从信任根扩展到操作系统内核(或更远)。对于某个PCR值“扩展”操作的具体计算历史被记录在TPM之外。这一历史序列应该由TPM之外的软件来完成，并与当前TPM中的PCR值进行比较。由于PCR的值能够验证历史文件的准确性，因此历史文件并不需要保护。

当黑客试图改变引导加载程序时，平台将进行相同的系统启动序列，被篡改的引导加载程序可能会做出欺骗性的解释，将系统引向一个错误的操作系统。然而，在被篡改的引导加载程序获取系统控制权之前，BIOS会记录这个被篡改的引导加载程序的摘要值，然后当TPM被问及系统启动序列时,将出现以下两种情况之一：①系统启动的历史文件匹配成功，但发现引导加载程序并不符合预期，被认为是不可信的启动；②系统启动的历史文件匹配不成功，这样该历史文件及启动被视为不可信。安全启动和可信启动之间存在着明显的差异：安全启动是仅仅允许机器启动到一个可信状态，而可信启动则是安全地报告系统的启动状态。TPM并不禁止引导一个不安全操作系统或使用一个不安全的引导加载程序，而是仅仅记录系统的启动序列，这些序列将用于判断系统启动序列是否由可信的一组部件来执行。如果一个具体的实现者希望建立一个安全启动，那么就需要通过修改一些固件来使用这些TPM的信息。不过，没有TPM也能实现安全启动。可信启动能够证明系统是以一种安全的模式启动，并不要求用户究竟以何种方式启动，只要能证明是一种合适且安全的方式即可。

2.报告启动序列记录

当一个使用者通过因特网连接一个远程计算机时，如何才能确信其所得到的TPM的PCR值(这里PCR值指的是系统启动序列)就是当前远程计算机的系统启动序列值呢？对于这个问题有两个回答。其中一个回答是身份标识，在现有规范中提供了一种让TPM对来自于自身的PCR值进行签名的方法。然而，测试者需要知道他所获得的正是当前系统启动序列的值，而不是一个历史系统启动序列记录。上面这个问题实际上很容易解决：在系统中采用一个nouce询问机制后，就能获得当前PCR值的签名集。nouce是作为质询发给对方的一串毫无意义的字符串或随机数。通过在签名的返回值中加入nouce，对方就能知道得到的签名是新的。通过这种技术可以对一个系统具备的启动序列进行安全的远程检查。这种询问机制的一种应用是当一个客户端连接远程服务器时，客户端希望远程服务器没有被破坏，并安全地了解服务器的系统启动状况。同样，远程服务器的系统管理员也希望采用这种技术来检查服务器没有被破坏。另外，从保护隐私角度来说，只有被系统所授权的用户才能进行这一远程验证技术。

TPM芯片中存在很多其他的平台配置寄存器。这些寄存器除了完成安全启动的记录外，还用于其他一些方面。例如，验证一个特殊的程序被首先运行或者验证一个杀毒软件正在使用当前的杀毒特征码。当系统启动过程验证通过后，其他PCR值也可以在被授权的情况下接受远程询问。

这一方案非常适合远程用户的需求，但如何能够在本地系统上实现该机制呢？使用者坐在屏幕前时，当然希望验证系统已经进入了一个可信的状态。尽管可以采用与远程方案相同的方法来实现，但是此时所面临的问题是不同的。当使用者处于远程访问状态时，假设本地主机是安全的，关注的是远程的计算机是否处于一种安全状态。而当使用者坐在屏幕前时，需要验证的是本地主机是否安全。如果该计算机被攻击，所得到的回答可能是不真实的。同时，本地验证签名并不容易，让使用者在电脑前手工验证是不现实的。为了解决这一问题，TPM设计中采用了将密钥与系统状态进行锁定的技术。此外，签名密钥除了能够运用于简单的报告机制外，还能被“锁定”到某个或几个PCR寄存器中。具体方法是：在密钥或数据创建时就为用户指定相关联的PCR寄存器和相应的值。这个过程被称为将数据“密封”到某个系统状态中去。因为PCR寄存器可以在任何时候进行“扩展”操作，所以通过这种方法操作系统或者终端用户就能够实现在某个进程的早期有权限访问数据，并在使用后锁定数据的操作。并且，这一方法是非常有价值的，这是因为在进程的早期正确的PCR值能够确保系统行为是按照预期的方式运行的。另外，安全启动过程能够把体现安全启动的某些秘密信息加密到PCR中。如果想验证系统是安全启动的，则可以要求计算机解密这个信息。如果这个秘密信息能够正确地解开，那么就说明PCR处于一种正确的状态。这样，就避免了手工验证签名的过程。

PCR需要提及的另一种功能是，当数据被锁定到一组PCR时，PCR的值同样会被记录。此后，可以查询数据被锁定到PCR的机器状态。这一技术类似于签名技术，当需要在同一系统的两个安全启动序列之间进行数据传递时，通过允许“解封”出机器状态来判断数据被“密封”时的机器状态是否为所预期的值，从而验证“密封”时的机器状态。

“密封”也可以用于存储一个文件系统的文件加密/解密密钥。5.3.2安全存储

TCG的第二个安全设计目标是提供一种对数据和签名密钥的安全存储。存储数据对象包括两种不同的技术。其一是使用独立的存储介质来存储数据。这种设计有些类似于银行地下保险库，在存储介质的输入/输出管道上实施访问控制；其二是使用加密来存储数据，通过加密和解密来实现对数据的访问控制。

第一种技术对于拒绝服务攻击有很好的控制能力，因为数据在不被访问时是无法删除的。而第二种技术提供的是一种虚拟的无限制的安全存储方式，相对于第一种技术更为廉价。尽管从某种意义上而言，TPM有点类似于安全智能卡芯片，但差异在于，TPM与大容量永久存储器之间是通过PC直接连接的。因此，可以安全地存储大量与TPM相关的加密数据。安全存储的一个设计目标就是TPM能将大量私钥、对称密钥和数据永久存储到一个透明、虚拟、无限制的存储空间。如果PC和企业内部网或者因特网存在一个持久的连接，那么可以利用远程存储进行设计。

但是，该方案可能存在的主要问题是，一旦锁定的大量数据的某一点出现了单点错误，那么就需要从设计上考虑灾难恢复和设计升级。TPM的体系结构恰恰为这些问题提供了良好的解决方案，这就是“可迁移和不可迁移密钥”。

1．存储数据和对称密钥

尽管TPM本身能够在内部存储少量的加密数据，但是对称密钥存储可以将存储空间无限扩展，这样就能够任意地存储被加密的对称和非对称密钥。非对称密钥可以是1024位或者2048位RSA密钥。TPM中最多可以存储256位被加密的对称密钥。这些密钥能用于加密任意大小的文件。使用密钥的对称算法由开发者选择，256位的对称密钥长度的选取主要是确保能够使用AES的密钥也可以存储在TPM中。这些密钥可以用于DES、3xDES、RC4、Blowfish以及其他AES候选算法。

2．存储非对称密钥

TPM内部可以用来存储多种非对称密钥。包括512位、1024位和2048位在内的多种RSA密钥可以在TPM外部或者内部产生，密钥可以在适当授权下被复制或者迁移到其他TPM上，而不是迁移到其他系统上。如果密钥由TPM内部产生，并且具有不可迁移特性，那么密钥的安全性可以得到进一步保障。可迁移的密钥也可以在TPM内部产生，但其安全性相对较弱。不可迁移密钥除了TPM是不可能被其他设备解密的外，只有在TPM内部才能使用内部密钥进行签名。长度至少为2048位的RSA公钥可以用于存储密钥和“密封”数据，其存储密钥的格式通常为PKCS#1v2.0。

3．授权

TPM对于不同功能有不同的授权，但是TPM规范的基本定义是一种固定的设计。通过将不同授权方式进行不同的组合，就可以得到多需要的授权方式。即使创建“no-auth”密钥(这类密钥在使用时不需要提供授权)时，也需要一种授权协议(对象相关授权协议，简称OSAP)。为了解决这个问题，在程序代码的头文件中需要定义一种称为“well-knownsecret”的默认口令。在创建一个每次启动时都需要单独授权信息的密钥时(这在规范中由密钥定义)，可以采用将一个口令扩展写到某个未用的PCR中的方法，然后在这个PCR与密钥之间建立一种锁定关系。

4．安全签名

非对称密钥的分类是多种多样的。其中一种区分方法是通过用途来区分，即一部分密钥用于存储其他密钥，另一部分则用于存储数据，分别称之为存储密钥或绑定密钥，但这些密钥是不可以用于签名操作的。这类密钥之所以不可能同时用作存储和签名，是因为在某些情况下，存储密钥需要使用密钥的公钥部分，而签名密钥需要使用密钥的私钥部分，这两种操作是互逆的。如果使用单独密钥进行这样两个操作，在设计上需要特别注意，不能让数据通过对加密的数据签名来解密。尽管TPM设计允许一个密钥同时作为存储和签名(被称为“遗留密钥”)密钥，但设计上考虑了组织这类攻击问题，所以遗留密钥是不推荐使用的，除非是更新原有软件中的密钥时使用。

5．安全身份标识

在TPM规范的制定中，设计者希望最大地扩展TPM的使用范围。为此，证明一个给定的密钥为TPM的不可迁移密钥是非常有必要的。在TPM规范中有一种方法可以实现这一目标，它能够验证一个TPM签名密钥的赋值是否是TPM中产生的。这一技术还要考虑以下问题：TPM中的签名密钥必须是终端用户产生的；在隐私方面，需要避免签名密钥与给定的系统相关联。

最终的方法是，每一个TPM都产生一个唯一的背书密钥，这个密钥是由生产厂商依次认证的。背书密钥会带来隐私的问题，即会造成这些密钥既无法签名也无法加密。为了解决这个问题，背书密钥只用于对其他产生密钥的TPM证书的解密，并且这个工作只能由TPM所有者和证书权威中心(CA)来协同完成。

6．多用户环境中用户的隔离

当讨论TPM设计时(特别是不可迁移密钥)，经常提到一个问题：为什么终端用户不能访问TPM基本加密密钥，即存储根密钥(SRK)呢？该问题涉及TPM基本设计原则的两

面性。

(1)攻击者进入系统的过程是一个“社会性的攻击”，即黑客会欺骗终端用户而提供某些威胁自身安全的有用的信息。如果终端用户并不知道基本的秘密，那么就不会泄露秘密。这与智能卡中确保私钥在卡中而不外泄的原因是类似的。

(2)要为终端用户提供抵抗恶意管理员的保护。当多个用户访问系统时，用户不允许访问他人数据(特别是密钥)。如果某人能够访问SRK，就可以任意访问系统中的所有密钥。这就涉及到一个更复杂的安全问题：如果一个用户了解另一个用户的一个或多个口令，就能推断出该用户创建口令的模式，甚至包括用户的私人银行账号口令。

7．内部随机数产生器

为了在内部产生密钥，TPM需要一个内部的随机数产生器(RNG)。由于真随机数产生器是比较难实现的，因此许多TPM实际上采用的是伪随机数产生器(PRNG)。伪随机数产生器能够等间隔地从计时器或者其他TPM熵源中获取一些信息，然后将熵转换为种子，通常这些熵都是递增的。伪随机数产生器或者随机数产生器的输出用于产生密钥、随机数和种子，它们都遵从PKCS#1v2.0创建格式。然而，随机数不仅仅用于简单地产生密钥，它还有更广泛的用途。特别是，随机数在蒙特卡罗规则中有很好的应用。该方法能利用可能的随机特性快速寻找解决困难问题的好方案。其中一个很有用的问题就是著名的旅行商问题。这个问题经常采用模拟退火的方法来解决，模拟退火法模拟金属中原子的移动，这些原子在退火时会寻找金属中的最强点。所以，原子的随机行为与利用随机数来求解问题是类似的。

当使用TPM随机数产生器时，需要注意2个问题：①需要确保熵的输入足够好；②产生器的速度并不快，因此不可以将其作为蒙特卡罗方法的直接输入。

8．没有包含的特性

在设计中，TPM中有大量的特性由于这样或那样的原因被舍弃了。其中之一就是安全时钟。尽管安全时钟是非常有用的，但由于成本的考虑而取消了安全计时特性。在TPM1.2的设计中，这一思想又被部分采用，但是每次掉电处理后，时间都会被重置。同时，TPM内部并没有供电的要求。对称密钥引擎也是作为可选的特性。对于TPM而言，不需要芯片支持PC的对称密钥解密，这主要是芯片进出口方面的考虑。但是安全的算法本身并不是保密的，同时，解密的输出是攻击者最感兴趣的东西，但在这里并不考虑这些问题。对称密钥引擎的一个优势在于速度，但是AES的一些候选算法都是为软件执行设计的，更多的需求在于对称加速器。对于通用的硬件块加密的考虑主要在于进出口的规则。由于这一原因，TPM内部的对称密码操作并不能够很容易地被用户采用进行基础性的块加密，而只定义了一些相关的函数描述。

另一个忽略的功能是用于执行特权代码的安全分区问题。尽管安全分区是很好的特征(如Java卡中就采用了类似的技术)，但这一技术非常昂贵，并且会导致DRM的广泛应用(对于某些人而言，DRM是希望避免的)。芯片中没有固定的签名密钥。在TSS1.1规范中，终端用户无法在重启系统后访问一个启动前加载的签名密钥。密钥必须先加载再使用。在TSS1.2规范中，密钥所有者可以在TPM中固定某个密钥，从而使得将来也能用到。

另外，在现阶段，TPM中采用椭圆曲线算法是不可能的，并且TPM规范已经规定了散列算法使用SHA-1。这两个问题可能会在将来发生改变。

5.4

TCG软件栈

程序员编写可信计算应用程序的切入点是TSS(TCG软件栈)。TSS规范以厂商无关的方式为上层提供TPM的所有功能，并定义了一种能够让访问TPM变简单和直接的体系结构。TSS基于TPM提供了API，比如：

(1)在磁盘上永久保存密钥对象的能力；

(2)连接本地和远程的TPM；

(3)数据块在可移植格式之间的转换(TSS1.2规范)。5.4.1

TSS设计概况

TSS由三个逻辑组件构成：TCG设备驱动程序库(TDDL)、TCG核心服务(TCS)、TCG服务提供者(TSP)。TSS的体系结构概况如图5-3所示。

TDDL是一个提供与TPM设备驱动程序进行交互的API的库。一般来说，TPM生产厂商会随TPM设备驱动程序一起附带TDDL库，以方便TSS实现者和TPM进行交互。TDDL提供一个小的API集合来打开和关闭设备驱动程序，发送和接收数据块，查询设备驱动程序的属性，以及取消已经提交的TPM命令。对于嵌入式应用程序来说，并不存在完整的TSS，仅有一小部分的TPM命令会被用到，TDDL也许就是与TPM交互的最好方式。然而，在大多数情况下，TCS是TDDL的唯一使用者。图5-3

TSS的体系结构

TCS层有以下几个任务：①管理TPM的资源，比如，授权会话和密钥上下文的交换；②提供一个TPM命令数据块产生器，这个命令数据块产生器能够把TCSAPI请求转换为TPM能够识别的字节流；③提供一个全局的密钥存储设备，并同步来自TSP层的应用程序访问。如果操作系统支持，TCS层必须以系统服务方式实现，也应该是TDDL的唯一使用者。关于TCS层的更详细资料请参考下一节。

TSP层以共享对象或动态链接库的方式直接被应用程序调用。TSP接口(即TSPi)对外提供了TPM的所有功能和它自身的一些功能，比如密钥存储和弹出关于授权数据的对话框。在本节中，我们关注的是TSPi的编程实践及其运行原理。5.4.2

TCG服务提供者接口(TSPi)

TSPi被设计为每条API都和一种对象类型关联。TSS1.1规范里定义了七种对象类型：上下文对象、数据对象、TPM对象、策略对象、PCR合成对象、散列对象和密钥对象。TSS1.2规范增加了关于认证可迁移密钥数据、非易失性数据、直接匿名证明和代理簇的对象类型。每一个TSPiAPI按此命名，以便程序员知道正在操作的是哪种对象类型。比如，最简单的TSS应用程序如表5-2所示，此表中都是对TSP的上下文对象进行操作的API。Tspi_Context_Create告知TSP产生一个新的上下文句柄供应应用程序使用并返回给应用程序。TSP中其他所有的API需要一个与某个TSP上下文相联系的对象，因此，每个TSS应用程序必须首先调用Tspi_Context_Create。Tspi_Context_Close释放与上下文相关联的所有资源。表5-2中最简单的TSS应用程序使用TSP库打开一个上下文句柄，然后再关闭。

对数据对象操作的API将以Tspi_Data_开头，操作密钥对象的API会以Tspi_Key_开头，以此类推。用来获取和设置对象属性的辅助函数仅以Tspi_作为前缀，比如Tspi_SetAttribData和Tspi_GetAttribUint32。表5-2简单TSS应用程序

5.4.3

TSP(或TSPi)对象类型

每一种TSP对象类型在TSP库的函数中都有自己的作用。下面先浏览每种类型对象的作用以及使用方法。表5-3列出了TSPi对象类型和用于表示它们的C语言数据类型。

在本节中，用于示范每种对象类型适用方法的代码片段会包含一些密钥定义的对象的引用。这些例子仅仅用于举例，读者需要阅读最新的TSS规范信息来了解每个API的使用。表5-3

TSPi对象类型

1．上下文对象

上下文对象用来保存当前TSP库的句柄，连接本地和远程TCS提供者，装载密钥，保存和从磁盘恢复密钥对象，创建新的工作对象。每个新创建的对象与创建它的上下文相关联。使用Tspi_Context_Create创建一个新的上下文对象，使用Tspi_Context_Close来关闭上下文。以表5-2为例，当Tspi_Context_Create被调用时，做了两件事情：TSP生成了一个新的上下文对象，创建了一个策略对象并与上下文相关联。对于在这个上下文中创建的所有授权对象来说，这个策略对象是默认的策略。当使用Tspi_Context_CreateObjict创建新的授权对象时，新创建的授权对象在默认情况下与上下文的默认策略相关联。如果对象的使用需要授权，则TSP通过查询上下文的默认策略来获得授权数据。为了传送命令给TPM，TSP的上下文必须连接到一个TCS提供者。这一操作用Tspi_Context_ConnectAPI来完成。Tspi_Context_Connect获取上下文句柄、UTF-16编码的主机名或目的系统的IP地址。要连接本机的TCS，使用空指针作为目的地址。如果连接TCS提供者成功，则TSP会隐式地创建一个TPM对象，并将其与上下文相关联。

应用程序可以创建任意熟练的上下文，这些上下文能连接任意熟练的TCS提供者。在TSS1.2中，有一个上下文连接版本的概念，它用来控制使用上下文创建的对象的类型。在默认情况下，上下文的连接版本是1.1，这意味着无论Tspi_Context_Connect连接的TPM版本是多少，上下文创建的对象都会与TPM1.1相兼容。当连接版本改变时，创建的对象的类型见表5-4。为了让TSP上下文一直创建与TPM1.2兼容的对象，可按下列方法设置：

Tspi_SetAttribUint32(hContext,

TSS_TSPATTRIB_CONTEXT_VERSION_MODE,0,

TSS_TSPATTRIB_CONTEXT_VERSION_V1_2)；

或者让TSP自动检测和创建基于所连接的TPM版本的对象，方法如下：

Tspi_SetAttribUint32(hContext,

TSS_TSPATTRIB_CONTEXT_VERSION_MODE,0,

TSS_TSPATTRIB_CONTEXT_VERSION_AUTO)；表5-4为基于TSP的上下文连接版本，由Tspi_Context_CreateObject创建的对象的类型。

可以根据密钥在不同版本的TPM之间迁移时是否需要兼容来决定上下文创建何种类型的对象。举例来说，由于新的机器在大量生产，为了保证密钥在两者之间迁移，需要在TPM1.2上创建TPM1.1的密钥。表5-4基于TSP的上下文连接版本及创建的对象的类型

2．TPM对象

当TSP上下文连接到TCS提供者时会隐式创建一个TPM对象。用Tspi_Context_GetTPMObjice可以在TCS连接创建以后获取TPM对象的句柄。当TPM对象创建时，TPM对象会获取它自己的策略对象，这个策略对象通常是用来保存TPM所有者授权数据的。表5-5列出了当建立一个经所有者授权的命令时，所有必要的TSPi调用集合。表5-5建立一个经所有者授权的命令的所有必要的TSPi

3．策略对象

策略对象保存命令需要用到的授权数据。装载密钥、迁移密钥、加密和解密数据、取得TPM的所有权、获得和设置TPM的敏感属性时，需要授权数据。策略有三种类型：使用策略、迁移策略和操作策略。迁移策略仅在创建可迁移的密钥时使用。在为TSS1.2中的“Tspi_TPM_SetTempDeactivatedAPI：”保存授权数据时使用操作策略。所有其他的策略都归为使用策略。策略获取授权数据的方法称为秘密模式。默认情况下，所有的策略都用秘密模式TSS_SECRET_MODE_POPUP，这意味着当使用这种秘密模式时，TSP会提供一个图形化的弹出对话框，以便从用户获取授权数据。在第一次从弹出对话框获取授权数据后，授权数据被保存下来，无论什么时候访问该策略，都会用到授权数据。除非调用Tspi_Policy_FlushSecret来清空秘密数据，否则弹出式对话框不会再出现。

TSS_SECRET_MODE_CALLBACK用回调函数从应用程序中请求获取秘密。在策略对象上使用Tspi_SetAttribUint32(TSS1.1)或Tspi_SetAttribData(TSS1.2)来设置回调函数的地址。传递给Tspi_Policy_SetSecret的参数ulSecretLength和rgbSecert将会被忽略。每个上下文对象和TPM对象都有它们自己的策略，这些策略被TSP隐式创建。所有新创建的使用策略的TSP对象(密钥对象和数据对象)将会获得上下文对象的策略的一个引用。这意味着，对于每个需要唯一口令的对象，必须创建一个新的策略，然后分配给它。密钥对象秘密也可以基于使用次数或使用时间来设置为过期。比如，调用以下代码创建一个策略，10秒后过期：

Tspi_SetAttribUint32(hPloicy，

TSS_TSPATTRIB_POLICY_SECRET_LIFETIME,

TSS_TSPATTRIB_POLSECRET_LIFETIME_TIMER,10);调用以下代码创建一个策略，在使用一次后过期：

Tspi_SetAttribUint32(hPolicy，

TSS_TSPATTRIB_POLICY_SECRET_LIFETIME,

TSS_TSPATTRIB_POLSECRET_LIFETIME_COUNTER,1);

根据秘密类型的不同，秘密的处理方法也不同，但是在TSP库内部，都会以SHA-1散列值作为结束。SHA-1散列算法用在HMAC的计算中，以建立与TPM的授权对话。不幸的是，每种秘密类型处理方式的差异会产生不正确的散列值，进而导致授权会话失效。如果TSS应用程序需要在多用户交互环境中运行(有时使用弹出策略，有时不用)，则在设置策略之前，将以明文表示的秘密转化为UTF-16LE编码格式是一种谨慎的做法。同时，在TSS1.1和TSS1.2的混合环境中，要注意是否有空的终结字符包含在秘密中。在TSS1.2中，上下文对象的一个属性TSS_TSPATTRIB_SECRET_HASH_MODE可以用来控制从弹出式对话框获得的秘密中是否包含空终结字符。为了与TSS1.1保持兼容性，调用以下函数可以强制TSS1.2包含空的终结字符：

Tspi_SetAttribUint32(hContext,TSS_TSPATTRIB_SECRET_HASH_MODE,TSS_TSPATTRIB_SECRET_HASH_MODE_POPUP,TSS_TSPATTRIB_HASH_MODE_NULL);

4．密钥对象

密钥对象用来表示TPM密钥，实际上就是RSP密钥对。

密钥对象能像其他对象一样通过调用Tspi_Context_CreateObject或者TSS的永久存储函数(比如Tspi_Context_GetRegisteredKeyByUUID)来创建。至少要调用2个API才能的到TPM创建的1024位绑定密钥对。

TSS_HKEYhKey；

Tspi_Context_CreateObject(hContext，TSS_OBJECT_TYPE_RSAKEY,

TSS_KEY_SIZE_1024|TSS_KEY_TYPE_BIND|TSS_KEY_NO_AUTHORIZATION,

&hKey)；

/*创建hKey，hParentKey是它的父密钥(父密钥必须装载到TPM中)，*0表示的是PCR合成

对象句柄，表示该密钥与任何PCR进行绑定*/

Tspi_Key_CreateKey(hKey,hParentKey,0);

调用Tspi_Context_CreateObject,根据请求的相关属性，在TSP库中创建了一个软件密钥对象结构。对Tspi_Key_CreateKey的调用会把刚才生成的密钥结构发送给TPM。TPM会根据软件密钥的参数生成密钥对，再把生成好的密钥对返回给TSP。然后，TSP会把生成的密钥对数据添加到软件对象结构中。需要注意的是，hParentKey必须先于Tspi_Key_CreateKey调用装载到TPM中。密钥对象从TSS中以数据块形式导出，数据块形式也就是TPM所用的字节流格式，用Tspi_GetAttribData可以以数据块形式取回密钥。

BYTE*keyBlob；

UINT32keyBlobLen；

Tspi_GetAttribData(hKey，TSS_TSPATTRIB_KEY_BLOB,

TSS_TSPATTRIB_KEYBLOB_BLOB,

&keyBlobLen，&keyBlob)；调用成功返回以后，keyBlob会指向保存着序列化的TCPA_KEY结构体、大小为key_BlobLen的内存。可以通过设置Tspi_GetAttribData的其他标志位来获得密钥对(一个TCPA_PUBKEY数据块)的公钥部分。

BYTE*pubkeyBlob；

UNIT32pubkeyBlobLen；

Tspi_GetAttribData(hKey，TSS_TSPATTRIB_KEY_BLOB,

TSS_TSPATTRIB_KEYBLOB_PUBLIC_KEY,

&pubkeyBlobLen，&pubkeyBlob)；只获取密钥的RSA模块：

BYTE*modulus；

UINT32modulusLen；

Tspi_GetAttribData(hKey，TSS_TSPATTRIB_RSAKEY_INFO,

TSS_TSPATTRIB_KEYINFO_RSA_MODULUS,

&modulusLen,&modulus)；

TCPA_PUBKEY结构体和RSA模块之间的差异在于，TCPA_PUBKEY结构体包含一个TCPA_KEY_PARMS结构体，这个结构体为密钥和密钥的其他属性保存了加密和签名的配置信息。

5．加密数据对象

数据对象用于在密封和绑定操作中保存密封好的和已经绑定的数据块。可以分别使用Tspi_SetAttribData和Tspi_GetAttribData函数来插入和提取数据。在一个绑定或密封操作中，加密过的数据会被TSS自动插入到加密数据对象中。

TSS_HENCDATAhEncData；

BYTE*blob，*data=“data”；

UINT32blobLen；

Tspi_Context_CreateObject(hContext,TSS_OBJECT_TYPE_ENCDATA,

TSS_ENCDATA_BIND,&hEncData)；

/*调用TSS来绑定数据，并把加密后的数据块存到hEncData中*/

Tspi_Data_Bind(hEncData,hKey,strlen(data),data)；

/*得到已经加密过的数据块，存到别处*/

Tspi_GetAttribData(hEncData,TSS_TSPATTRIB_ENCDATA_BLOB,

TSS_TSPATTRIB_ENCDATABLOB_BLOB,

&blobLen,&blob)；

前面的例子是简化过的，并没有标明密钥或者上下文的创建过程。创建和使用加密数据对象是非常直接的，但是记住每次都要用Tspi_Context_FreeMemory释放由Tspi_GetAttribData返回的数据。

6．散列对象

HASH对象用来保存散列值，计算数据的散列值，用密钥签名和认证散列值。TSS本来就仅支持用SHA-1算法散列数据，尽管TSS能够签名和认证任意类型的散列值。使用Tspi_Hash_UpdataHashValue创建数据的SHA-1散列值：

TSS_HHASHhHash；

BYTE*digest，*data="d