早期计算机安全主要依赖于杀毒软件，然而，这种纯软件防御存在明显缺陷。一旦恶意软件获得与杀毒软件相同的权限，它可以轻易关闭防护程序并悄悄隐藏自身。更甚的是，一旦恶意软件针对固件和引导程序发起攻击，杀毒软件的查杀难度进一步增加。针对这些挑战，可信平台模块（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算法弱点为契机，重新设计了更加集成和统一的架构，使得对算法的支持更加灵活。
二. TPM介绍
2.1
组成
一个标准的可信平台模块如图1所示，通常由以下部分组成：
输入输出（I/O）：管理TPM内不同组件间的数据流传递，同时作为TPM与外部总线交互的接口。
非易失性存储：用于存储关键数据，主要包括密钥（背书密钥EK和存储根密钥SRK）以及所有者授权数据。
平台身份认证密钥（AIK）：作为TPM中特殊用途的RSA密钥，与EK有数学上的关联，用于平台签名认证。
平台配置寄存器（PCR）：提供一种密码学的方式记录软件的状态，用于存储系统启动过程中系统状态测量值。
程序代码：用于初始化设备的固件。
执行引擎：负责运行程序代码。
密码学加速器引擎：用于进行高速的密码学运算，包括对称、非对称和哈希算法等。
随机数生成器：生成密钥所需的高质量随机数，符合TPM标准的要求。
密钥生成器：借助密码学加速引擎和随机数生成器，生成根密钥。
图1.TPM组成结构
2.2
功能
2.2.1
身份认证
TPM芯片的一个重要能力是安全密钥存储。通过在芯片中植入设备私钥，可以给设备分配唯一标识，方便组织对设备资产进行管理，当然也可以存放用户私钥，标识用户的身份。一些典型的例子包括：
（1）VPN认证身份：设备用TPM中的私钥签名消息，后台用公钥验证签名，从而确保内部网络资源只有特定的设备和用户可以访问；
（2）信息交互中的身份确认：使用TPM中存储的私钥对数据做签名，确保消息来源的可靠性。
2.2.2
加解密
TPM可以用于加密密钥，被加密的密钥则用于加密文件或者解密收到的文件。基于此能力，可以实现：
（1）加密文件、文件夹；
（2）磁盘加密；
（3）加密远程存储的文件。
2.2.3
密钥存储
TPM可以使用自己内部生成的非对称密钥，将需要保护的密钥用公钥加密后存储在外部，需要使用时再用私钥解密，理论上可以实现任意数量密钥的安全存储，让TPM本身可以使用不限量的密钥。由此带来的一些优势包括：
（1）更多的密钥意味着针对不同的数据可以使用不同的密钥来加密。在隐私保护的场景下，针对不同的信息使用不同的密钥加密，细化隐私保护的粒度，增强安全性；
（2）针对不同安全级别的数据，使用不同的密钥；
（3）可以将加密后的密钥存放在服务器上，需要时再从服务器获取，使用更灵活。
2.2.4
随机数生成
随机数是密码学应用中很重要的一部分。高质量的随机数生成器可以降低安全协议被被破解的几率。TPM要求配备高质量的随机数生成器，可以认为是比软件更可信的随机数生成源，随机数生成器常用于：
（1）为操作系统提供随机数种子
（2）为安全协议提供nonce（随机数）
（3）生成密钥
2.2.5
可信度量
TPM在系统启动时，会根据系统状态，由软件算出一系列哈希值，并存储在平台配置寄存器（PCR）中，后续可以使用特定私钥签名这一系列测量值，然后向外部报告。PCR基于其单项存储特性，保证内容不被纂改，因此如果PCR中的值与预期值相同，这些值就被认为是可信的。这一测量过程可用于验证系统的完整性和安全性，防止系统被恶意软件感染。
三. TPM2软件栈
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规范，提高了开发效率，降低了实现安全解决方案的门槛。
图2.TPM2软件栈
四. 总结
TPM作为独立硬件，能够提高计算机系统的安全性，有效防止恶意软件入侵和数据泄露。同时也是可信计算的核心技术之一，为可信计算平台提供基本的验证机制和安全防护。随着可信计算的蓬勃发展，TPM的功能和性能也在进一步得到提升和完善。
参考文献
https://en.wikipedia.org/wiki/Trusted_Platform_Module
Will, Arthur and Challener, David and Goldman, Kenneth (1015). A Practical Guide to TPM 2.0. Apress Open, Springer New York, 2015
Tomlinson, Allan. "Introduction to the TPM." Smart Cards, Tokens, Security and Applications (2017): 173-191.
https://tpm2-software.github.io/
内容编辑：创新研究院 杨博杰 责任编辑：创新研究院 陈佛忠
本公众号原创文章仅代表作者观点，不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。
