可信计算之可信平台模块介绍

早期计算机安全主要依赖于杀毒软件，然而，这种纯软件防御存在明显缺陷。一旦恶意软件获得与杀毒软件相同的权限，它可以轻易关闭防护程序并悄悄隐藏自身。更甚的是，一旦恶意软件针对固件和引导程序发起攻击，杀毒软件的查杀难度进一步增加。针对这些挑战，可信平台模块（Trusted Platform Module，TPM）应运而生。

TPM是安全密码处理器的国际标准，旨在通过设备内置的专用微控制器（即安全硬件）来处理设备中的加密密钥。该标准已于2009年被国际标准化组织（ISO）和国际电工委员会（IEC）规范为ISO/IEC 11889。

TPM的发展经历了几个阶段，从最初的TPM1.1b的大规模部署开始，经历了TPM1.2和TPM2.0版本。TPM1.2在TPM1.1b的基础上增加和整合了功能，一方面弥补了之前版本的不足，但也导致规范变得相当复杂。后来，TPM2.0以解决SHA-1算法弱点为契机，重新设计了更加集成和统一的架构，使得对算法的支持更加灵活。

一个标准的可信平台模块如图1所示，通常由以下部分组成：

输入输出（I/O）：管理TPM内不同组件间的数据流传递，同时作为TPM与外部总线交互的接口。

非易失性存储：用于存储关键数据，主要包括密钥（背书密钥EK和存储根密钥SRK）以及所有者授权数据。

平台身份认证密钥（AIK）：作为TPM中特殊用途的RSA密钥，与EK有数学上的关联，用于平台签名认证。

平台配置寄存器（PCR）：提供一种密码学的方式记录软件的状态，用于存储系统启动过程中系统状态测量值。

程序代码：用于初始化设备的固件。

执行引擎：负责运行程序代码。

密码学加速器引擎：用于进行高速的密码学运算，包括对称、非对称和哈希算法等。

随机数生成器：生成密钥所需的高质量随机数，符合TPM标准的要求。

密钥生成器：借助密码学加速引擎和随机数生成器，生成根密钥。

TPM芯片的一个重要能力是安全密钥存储。通过在芯片中植入设备私钥，可以给设备分配唯一标识，方便组织对设备资产进行管理，当然也可以存放用户私钥，标识用户的身份。一些典型的例子包括：

（1）VPN认证身份：设备用TPM中的私钥签名消息，后台用公钥验证签名，从而确保内部网络资源只有特定的设备和用户可以访问；

（2）信息交互中的身份确认：使用TPM中存储的私钥对数据做签名，确保消息来源的可靠性。

TPM可以用于加密密钥，被加密的密钥则用于加密文件或者解密收到的文件。基于此能力，可以实现：

（1）加密文件、文件夹；

（2）磁盘加密；

（3）加密远程存储的文件。

TPM可以使用自己内部生成的非对称密钥，将需要保护的密钥用公钥加密后存储在外部，需要使用时再用私钥解密，理论上可以实现任意数量密钥的安全存储，让TPM本身可以使用不限量的密钥。由此带来的一些优势包括：

（1）更多的密钥意味着针对不同的数据可以使用不同的密钥来加密。在隐私保护的场景下，针对不同的信息使用不同的密钥加密，细化隐私保护的粒度，增强安全性；

（2）针对不同安全级别的数据，使用不同的密钥；

（3）可以将加密后的密钥存放在服务器上，需要时再从服务器获取，使用更灵活。

随机数是密码学应用中很重要的一部分。高质量的随机数生成器可以降低安全协议被被破解的几率。TPM要求配备高质量的随机数生成器，可以认为是比软件更可信的随机数生成源，随机数生成器常用于：

（1）为操作系统提供随机数种子

（2）为安全协议提供nonce（随机数）

（3）生成密钥

TPM在系统启动时，会根据系统状态，由软件算出一系列哈希值，并存储在平台配置寄存器（PCR）中，后续可以使用特定私钥签名这一系列测量值，然后向外部报告。PCR基于其单项存储特性，保证内容不被纂改，因此如果PCR中的值与预期值相同，这些值就被认为是可信的。这一测量过程可用于验证系统的完整性和安全性，防止系统被恶意软件感染。

TPM2软件栈（Trusted Platform Module 2.0 Software Stack，TPM2-TSS）是为了方便应用程序与TPM2.0设备交互而设计的一系列软件。这个软件栈实现了TPM2.0规范，提供了一系列工具和库，方便开发者接入。

核心特点：

（1）跨平台。整体设计不依赖操作系统，可以在不同的操作系统和环境下使用，可移植性好。

（2）完全开源。作为开源项目，依托开源社区，在开发者的帮助下不断优化。此外，由于它是开源项目，开发者和企业可以根据自己的需求对其进行定制和扩展，以适应特定的应用场景和安全需求。

（3）标准化。项目遵循TPM 2.0规范，提供一套标准的API，允许软件开发者和系统集成者以标准化的方式与TPM 2.0设备进行交互。

TPM2-TSS提供如下几个不同层次的框架：

（1）TPM Command Transmission Interface 

(TCTI)：传输/接收TPM命令和结果的标准API，定义了如何与TPM硬件通信，是TPM2-TSS中最底层的接口。

（2）Marshaling/Unmarshaling (MU)：用于编码和解码TPM数据结构的函数库。

（3）System API (SAPI, sometimes SYS)：TPM2命令的一比一映射，是较低层次的接口。使用SAPI需要开发者对TPM命令有较深的理解，包括命令的参数、状态、错误处理等。

（4）Enhanced System API (ESAPI, sometimes ESYS)：在System API的基础上做了封装，意在降低编程复杂性，简化了利用安全上下文实现的HMAC计算、参数加解密、TPM命令审核等。即使相较于SAPI更加简单，但使用时仍需要对TPM2.0接口定义有深入了解，因此官方仅推荐专业人士在专业应用中使用。对于常规应用，则推荐使用更高级接口(FAPI)。

（5）Feature API(FPAI)：更高级别的抽象，比SAPI和ESAPI更加简洁易用。旨在让不了解TPM的开发者也能使用TPM的安全能力。在保证安全性的基础上，减少了必须编写和维护的代码量。开发者不必关心复杂的TPM2.0规范，提高了开发效率，降低了实现安全解决方案的门槛。

TPM作为独立硬件，能够提高计算机系统的安全性，有效防止恶意软件入侵和数据泄露。同时也是可信计算的核心技术之一，为可信计算平台提供基本的验证机制和安全防护。随着可信计算的蓬勃发展，TPM的功能和性能也在进一步得到提升和完善。