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

一. 背景

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

内容编辑:创新研究院 杨博杰 责任编辑:创新研究院 陈佛忠

本公众号原创文章仅代表作者观点,不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权,严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用,转载须注明来自绿盟科技研究通讯并附上本文链接。