其实可信平台模块（Trusted Platform Module，简称TPM）是一项比较古老的安全技术了，只不过之前的操作系统都没有强制要求，其103版本在2009年就已经被接受为ISO标准（ISO/IEC11889），全球有上亿的各类终端都配备了TPM安全芯片，不过到目前为止占据主要市场的还是TPM1.2。

TPM2.0与TPM1.2芯片不兼容，在上层软件链成熟前，TPM1.2还会持续一段时间。但由于TPM2.0的灵活性，解决了TPM1.2的很多安全问题，且满足更多场景的应用，其代替TPM1.2芯片是一个必然趋势。自2016年7月28日起，所有新设备和产品线都必须默认实现并启用TPM2.0。

TPM旨在提供基于硬件的安全相关功能，它是一种安全的加密处理器，可帮助我们执行生成、存储和限制使用加密密钥等操作，许多TPM包含多种物理安全机制以使其具有防篡改功能，并且恶意软件无法篡改TPM的安全功能。TPM是被动的，它只接收命令并返回响应，TPM为系统硬件、平台所有者和用户提供安全和隐私优势。从Windows10操作系统开始就会自动初始化并取得TPM的所有权，这就不需要IT专业人员来配置或监控系统了，同样在苹果的电脑手机上也都有同样的芯片。为了更好的保障信息安全，大家以后在购买电脑时就要留意是否是secured-core或带有“Windows11 Ready”标识的机型了。

密码算法的改进

TPM1.2密码算法：RSA加密、RSA签名、RSA-DAA、SHA1、HMAC，并没有要求支持对称算法。

TPM2.0密码算法：RSA加密和签名、ECC加密和签名、ECC-DAA、ECDH、SHA1、SHA256、HMAC、AES，而且厂商可以随意使用TCG IDs来增加新的算法，如在国内实现必须增加SM2、SM3和SM4算法，拥有一定的灵活性。

在平台上的发展

TPM1.2主要面向PC平台设计，而类似的安全思维其实可以扩展到网络、服务器、云环境、移动设备和嵌入式产品等。TPM安全芯片本身是以安全芯片的形式在主机上隔离出一个拥有独立处理能力和存储能力的区域，在这个程度上，虚拟技术、TrustZone、智能卡等本质上是一致的，不过安全性可能并不在一个层次。TPM1.2的owner只有一个就是用户，而计算平台本身可能也需要使用TPM。TPM1.2中，所有安全和隐私都在该owner的控制下。

TPM2.0将这种控制功能进行了隔离，给出了三个控制域：安全域或者存储域（owner为用户，用户正常的安全功能）；隐私域（owner为平台或者用户，平台身份认证）；平台域（owner为平台，保护平台固件的完整性）。另外TPM2.0规范主要是提供一个参考，以及可能实现的方式，但是并没有限制必须以安全芯片的形式存在，如可以基于虚拟技术或者ARM TrustZone、Intel TXT等进行构建，只要能提供一个可信执行环境（TEE），就可以进行构建。一个安全芯片嵌入到服务器上，体现不了多少成本；但是如果在空间有限的移动设备或者嵌入式设备上配备一个安全芯片，就需要慎重考虑了。

在密钥上的改进

TPM1.2的背书密钥只有EK，出厂时厂商就预置在芯片内，更换都很困难。takeowner后可以生成属主和唯一的存储根密钥SRK，从而可以构建密钥的存储体系。

在TPM2.0中，EK属于隐私域，可以有多个，而且可以支持不同的非对称算法；SRK属于安全域，也可以有多个和支持不同的算法。实际上TPM2.0的三个控制域中，都支持多密钥和多算法。TPM2.0的主密钥都是通过主种子，使用密钥派生算法KDF来生成。存储种子的空间比存储密钥的空间要小很多。TPM2.0中密钥的存储通常是通过对称加密，父密钥的强度不能低于子密钥吧，要不子密钥的安全强度也无法达到其声称的size。

平台配置寄存器

微软早在win8中就使用PCR来恢复unsealing Bitlocker的密钥。如果系统启动过程中有任何微小的变化，都需要用户干预才能恢复，因此这个过程比较脆弱。PCRs主要用来存储系统启动和运行过程中的度量值，防止度量日志被篡改。PCRs值不只保证每次系统启动时执行相同的代码，其保证以相同的顺序执行相同的代码。

TPM2.0规范运行其有多个PCRsbanks，一个bank内所有PCR使用相同的算法进行扩展操作。而且不同的banks可以分配不同的PCRs。对于不同的bank，扩展操作是相互独立的，互不干扰。

授权机制的改进

授权即是否允许软件进程访问TPM内部的资源（密钥、计数器、NV存储空间等）。TPM1.2拥有不同的机制来授权客体（objects）的使用、委托使用和迁移等。TPM1.2的授权比较受限制，唯一的授权访问方式是基于passwords和PCR值。例如，为了使用TPM内部的一个密钥，软件需要证明其拥有某个password的知识（通过hash的方式嵌入在可信命令中）；而且可以将该密钥与特定的PCR状态seal在一起。这使得TPM1.2的授权机制缺乏灵活性。通常一个计算机平台拥有多个用户，如何共享TPM密钥和数据是比较困难的。不同用户由于password不一样，他们知道的密钥集合也是相互独立的。系统管理员如何授权这些密钥的使用是一个难点。

TPM1.2中，软件通过授权会话证明其拥有password（消息验证码），在命令需要授权前通常通过一个独立的命令来开启会话。TPM2.0提出了增强的授权机制（Enhanced Authorization，EA）。

而TPM2.0提供了一个统一的框架来使用授权功能，授权功能可以通过各种独特的方式进行组合来增加灵活性。TPM2.0允许使用明文密码和HMAC的授权，也允许使用多个授权限定符来构造任意复杂的授权策略。增强的授权机制是TPM2.0的一个特色。

TPM2.0对密钥和数据的授权使用方式进行了扩展，授权会话变成了策略会话，多个授权方式可以通过布尔逻辑的形式进行组合。例如，在一个场景中，Alice和Bob两个用户拥有不同的passwords，现在想要让他们可以访问同一个密钥，可以创建一个策略“当且仅当Password(Alice) or Password(Bob),允许访问密钥”。软件进程可以先创建策略，在生成TPM密钥或者数据时指定该策略的哈希值即可，TPM不需要知道策略的详情，hash值足够。

TPM芯片启用状态

影响TPM1.2使用的最大一个障碍是PC厂商将TPM默认置为关闭状态。为了激活TPM的使用，用户必须进入固件（BIOS），找到管理TPM安全芯片的目录，将其激活。这是因为TCG早期受到了质疑的影响，质疑者认为使用TPM可能导致PC平台绑定特定的软件，而影响其他软件的使用，特别是厂商可以借此推广自己的软件，因此推荐默认情况下关闭TPM。这是非常浪费的行为，但国内TCM在这方面做得还好，只是一些特定型号的安全主机才会配备TCM芯片，并不是每个PC主板上都装。

既然要在BIOS中对TPM的使用进行激活，而实际上大部分用户都没有用过BIOS，这样导致大部分TPM永远沉睡在主板上。即便激活了TPM1.2，其状态是没有属主的（unowned），需要通过一个特定的命令来建立属主，往往第一个建立属主的人才是TPM的实际拥有者。在非属主状态，能使用的TPM很有限，没有SRK，密钥也无法创建或者加载，PCR状态也无法进行验证。在TPM1.2中，固件（BIOS）无法验证启动状态（boot state），固件可以哈希代码并扩展PCRs，但是检查具体的度量值只能靠更上层的操作系统或者应用程序。

在TPM2.0中默认状态应该是开启的，并增加了平台域，保证平台固件也可以操作完整的TPM资源，即固件可以创建密钥、加密数据、验证PCR值等。这意味着，平台固件和平台用户可以同时成为TPM的属主（owner）。固件开发者可以使用这种能力来保证一个安全的预引导环境，类似操作系统使用TPM的能力来保护其操作以及上层应用。

TPM2.0规范介绍

TPM1.2规范对功能的描述采用伪代码的形式，虽然更加正式，但是厂商实现时在细节上还是会存在一定的误解。TPM2.0规范采用C语言的形式进行了描述，为不同厂商实现时提供了标准的指导。但TPM2.0的标准看起来也很费劲，对于一个不懂可信计算的开发人来说，让其根据规范实现芯片，绝对是一种煎熬。但对于搞可信计算的人来说，认真研读TPM2.0规范，还是很有收获的。

TPM2.0规范主要有四部分，Part1是比较系统的介绍，要了解可信平台模块的基本思想和原理，主要参考Part1。Part2给出TPM接口的变量、数据类型、数据结构和常量。Part3总结TPM能执行的所有命令，对于每个命令给出命令请求和响应的格式，并且通过C代码形式分析了每个命令的执行流程。最后的Part4是给出了Part3中命令代码用到的算法和方法。实际使用可信计算是很多命令的组合，但具体使用时必须从整体上思考，才能组合出实际的应用。

更多参考：

https://docs.microsoft.com/en-us/windows/security/information-protection/tpm/trusted-platform-module-overview

声明：本文来自山石网科安全技术研究院，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。