摘要
基于硬件的TPM为各种任务关键型应用程序提供了硬件支持的安全解决方案和信任基础。但是，基于硬件的TPM具有一些固有的问题，例如极低的性能，片外安全漏洞以及事件响应敏捷性不足。在即将到来的量子计算时代，至关重要的是要提供抗量子（QR）加密功能而不损害性能。不幸的是，基于硬件的TPM严格的硬件和软件体系结构模型使基于硬件的TPM过渡以适应未来的QR密码系统极为困难。另一方面，基于软件的TPM（例如，基于固件的TPM）提供了基于CPU的片上安全解决方案。他们利用ARMTrustZone或IntelSoftwareGuardExtensions（SGX）等芯片组提供的低级片上基元来构建具有高级别信任计算环境的系统。基于软件的TPM解决方案可提供更高的性能，片上安全性和事件响应敏捷性。但是，它缺少硬件支持的保护和一些重要功能，例如安全密钥存储，针对边信道攻击的鲁棒性，真正的随机数生成等。另外，它的实现高度依赖于每个硬件供应商提供的低级原语，这使得很难将其作为通用解决方案提供。在本文中，我们提出了混合TPM（hTPM），它充分利用了基于硬件的TPM的优势，并通过安全容器内部的基于软件的TPM解决方案来消除了基于硬件的TPM的弱点，例如基于虚拟化的安全性（VBS）。
我们将hTPM实施为完全双模式TPM，即让最终用户根据他们的需求在硬件TPM模式和软件TPM模式之间进行完全控制。我们进行了并将对提议的hTPM进行全面的风险分析，以显示如何在实现hTPM时最好地克服安全挑战。最后，我们对提议进行了性能分析，以显示加密操作的显著改进。
简介
可信平台模块（TPM）是一种物理或虚拟密码协处理器，可为各种关键任务应用程序提供广泛的安全功能和信任根。TPM的基本安全功能可以总结如下：
- 安全密钥存储：TPM设计带给设备的一大优势是确保良好的密钥（尤其是免受软件攻击）的安全性。
- 设备身份验证：TPM可以使用其唯一的每设备RSA或ECC密钥进行安全的设备身份验证。
- 设备证明：TPM可以通过获取和存储软件状态的安全性度量来确保平台完整性。TPM中的平台配置寄存器（PCR）与身份密钥一起可用于证明系统的运行状况。
- 秘密绑定：通过使用TPM绑定密钥加密数据，可以使用从设备唯一存储密钥派生的唯一RSA或ECC密钥，因此可以将其安全地绑定到设备。
- 秘密密封：秘密可以使用特定的设备状态进行密封，并且只有当设备满足密封状态条件时，TPM才能进行数据解密。
TPM提供关键功能的应用程序很多种。例如，Bitlocker可以选择在驱动器解密中使用TPM。通过使用TPM，Bitlocker可以为需要基线数据保护级别以满足安全策略的组织提供最透明的用户体验。Bitlocker中TPM的使用可总结如下。BIOS启动并初始化TPM。可信/已测量的组件与TPM交互以将组件的测量结果存储在TPM的PCR中。如果PCR值符合预期值，TPM使用存储根密钥（SRK）来解密卷主密钥（VMK）。从卷中读取已加密的全卷加密密钥（FVEK），并使用解密的VMK对其进行解密。磁盘扇区在访问时用FVEK解密。然后，将明文数据提供给应用程序和进程。TPM提供了关键功能，有助于安全地将VMK密封并绑定到特定设备。TPM还用于系统完整性测量和设备认证。在系统引导过程中，可以测量已加载的引导代码（包括固件和操作系统组件）并将其记录在TPM中。完整性测量与设备专用证明密钥相结合可用于设备证明。远程服务器可以配置访问控制，以根据提供的TPM的设备运行状况来限制对关键资源的访问。
从历史上看，TPM是焊接到计算机母板上的分立芯片，称为分立TPM（dTPM）。这种实施方式使计算机的原始设备制造商（OEM）可以与系统的其余部分分开评估和认证TPM。尽管离散TPM实施仍然很常见，但是它们存在一些严重的弱点，这些弱点危及了系统的安全性。首先，dTPM最初并不是设计为加密加速器，而是有意将其设计为低成本设备，以便OEM可以轻松采用它们。因此，自然不可能为应用程序提供及时的密码服务。不幸的是，加密操作是TPM功能的核心部分，不能免除大多数现代安全应用程序的性能要求。TPM应用程序需要在其软件生命周期的某个时刻依赖加密操作，包括密钥生成，加密/解密和签名/验证。因此，dTPM的性能低下会严重损害其应用质量。在将来的TPM中，性能问题可能会变得更加严重，因为QR密码操作将成为强制性措施以抵御基于量子计算的攻击，这不可避免地会导致更加复杂和昂贵的密码算法和操作。其次，由于基于硬件的TPM是一种隔离的硬件解决方案，因此遭受片外攻击。dTPM通过串行总线与CPU的连接打开了攻击面，使攻击者可以通过物理方式访问主板。Jeremy指出了TPM和主机之间嵌入的中介程序可能造成的各种攻击，例如伪造的PCR扩展攻击，低熵随机数生成攻击以及触发主机端TPM驱动程序中的解析错误。第三，它不会在安全事件期间提供响应敏捷性。如今，针对安全漏洞的敏捷反应非常重要，因为在当前的安全形势下，完美的预防已不再是可行的策略。由于dTPM是基于硬件的解决方案，因此很难及时应用安全补丁。
一些更新的TPM实现将TPM功能与其他平台组件集成到同一芯片组中，同时仍提供类似于dTPM芯片的逻辑分离。一个典型的例子是基于固件的TPM（fTPM）。fTPM是基于TPM的软件，利用商用CPU的内置安全功能进行信任计算。例如，fTPM在ARM上使用了TrustZone。TrustZone提供了与平台其他软件（包括OS，应用程序和固件）高度隔离的运行时环境。通过这些功能，fTPM为平台提供了一组TPM安全功能，类似于专用安全硬件提供的功能。它试图通过引入诸如新硬件组件之类的低级原语来克服诸如安全存储，安全计数器，时钟和熵之类的挑战。但是，基于纯软件的TPM不能提供基于硬件的信任根，这在现代安全领域中非常重要。缺乏硬件安全支持意味着在基于软件的攻击和旁道攻击中存在固有的漏洞。此外，基于纯软件的解决方案在预引导阶段限制了其适用性，并可能导致合规性问题。
在本文中，我们提出了混合TPM（hTPM），它有效地结合了硬件TPM和软件TPM的优点，并提供了一种复杂的设计来克服将基于硬件的TPM和基于软件的TPM结合在一起时遇到的安全挑战。与dTPM相比，我们的hTPM实施显示出显着的性能改进，并且比纯硬件或纯软件的TPM解决方案保证了更强的安全性。
现有的信任平台模块架构
在本章中，我们将更深入地研究基于硬件的TPM和软件TPM解决方案，并分析它们的弱点。
2.1基于硬件的TPM
基于硬件的TPM是提供可信平台功能的主要方式。它是一种专用的低成本芯片，在自己的防篡改半导体封装中实现TPM功能。从理论上讲，硬件TPM是最安全的，因为它没有与软件相关的漏洞，并且硬件本质上提供了一种强大的方式来提供避免侧通道攻击的安全功能。但是，硬件TPM具有许多固有的问题，这些问题在交付高质量应用程序时引起了巨大挑战。
- 低性能由于硬件TPM最初不是为加密加速而设计的，因此会遭受严重的性能下降。图1显示了从各种TPM命令收集的性能数据。它是在商用HP设备（英特尔至强CPUE3-1505Mv63GHz，300Mhz，4核，8个逻辑处理器和具有TPM规范版本2.0的英飞凌（IFX）TPM版本7.61.2785.0）中进行测量的。时间是使用C++11中的chrono库以纳秒粒度测量的。如图1所示，在RSA签名，解密，引用和密钥生成中观察到明显的性能问题。延迟数百毫秒（例如RSA2048解密时间超过500毫秒）对于大多数应用程序来说是完全不可接受的，因为它会严重破坏用户的体验。
- 片外漏洞基于硬件的TPM通过南桥通过串行总线连接到CPU。该总线代表了新的攻击面，因为它从外部暴露于攻击者并可以物理访问主板。请注意，基于CPU的TPM解决方案回避了这一攻击面，因为它没有通往CPU的单独总线。
- 安全事件响应敏捷性基于硬件的TPM功能被实现为硬件。因此，由于需要固件更新或重新设计硬件，因此难以及时对安全事件做出反应。例如，在2017年，发现了ROCA漏洞，该漏洞利用一种加密漏洞，可以从公钥中恢复密钥对的私钥。如果在硬件中发现了这种基本错误，则从根本上修复该漏洞的唯一方法是更换硬件或将变通办法放入固件中。更新固件或修复硬件是一个昂贵的过程，会导致更长的零日漏洞。
- 缺乏端到端的保护意识一些关键数据（例如身份验证数据）驻留在内存中，并传输到TPM以进行启封操作。另外，在未绑定或未密封所需的密钥之后，NVRAM外部会发生许多实际的加密操作。攻击者可以发起各种软件攻击或内存攻击，例如冷启动攻击或DMA攻击。基于硬件的TPM缺少对机密信息（例如，身份验证数据（例如，PIN，生物识别等）或释放到RAM的密钥）的端到端保护。这不是TPM的固有弱点，因为它不在TPM设计范围内。但是，我们仍然需要一个整体的安全解决方案来最终保护关键任务应用程序。
图1 硬件TPM的加密性能
2.2基于软件的TPM
在基于软件的TPM中，所有TPM功能都在软件中实现。该软件实现可以包含在受信任的执行环境（例如TrustZone），单独的虚拟机或仅在单独的进程中。基于纯软件的解决方案容易受到软件错误的影响，并且缺乏硬件支持的强化。进一步来说：
- 缺乏硬件级别的保护由于这些秘密完全由软件处理，因此容易受到各种侧通道攻击，故障攻击，微体系结构攻击（例如Meltdown，Spectre攻击）和基于软件漏洞的攻击。它也容易受到试图从DRAM读取机密的内存攻击。
- 基于硬件的熵TPM规范需要一个真正的随机数生成器（RNG）。真正的RNG通过具有一个熵池来构造，该熵池的熵由诸如电压和温度之类的硬件熵源提供。它需要特殊的硬件来收集经统计证明的真实随机种子。纯软件解决方案缺乏真正的随机数生成功能，因为它不符合TPM规范，因此成为一个问题。
- 安全证书保障某些应用程序需要严格的安全认证合规性，例如PCIDSS（支付卡行业数据安全标准），HIPPA（健康保险可移植性和责任法案），FIPS（联邦信息处理标准）等。通常，它需要硬件的信任和保护。因此，纯软件解决方案无法满足行业要求。
- 预引导环境TPM在预启动环境中使用，例如Bitlocker加密操作和设备证明。由于在系统的预引导阶段需要TPM，因此纯软件TPM在尝试提供所有必需的功能方面将存在固有的困难，因为基于软件的TPM的全部功能只有在配置了所有必需的软件堆栈之后才可用。请注意，根据引导流程和低级CPU原语，在预引导环境中可能会使用完整的软件TPM。例如，在fTPM中，TrustZone在正常启动世界引导加载程序之前已完全启动。在这种情况下，不会有任何问题。但是，此问题在其他预引导环境中仍然存在。
提出的混合TPM架构
我们提出了一种新颖的设计来实现hTPM并实现上一节中描述的设计目标。总体架构如图2所示。
图2 TPM结构
首先，我们的S模式TPM与正常的世界操作系统安全隔离。我们利用基于Windows10的虚拟化来提供关键的隔离属性。请注意，我们的建议可以应用于其中集成了虚拟化技术的其他商品操作系统。窗口10引入了一种新的安全功能，称为虚拟安全模式（VSM）。VSM利用Hyper-V虚拟机管理程序和第二级地址转换（SLAT）来创建一组称为虚拟信任级（VTL）的模式。这种新的软件体系结构创建了一个安全边界，以防止在一个VTL中运行的进程访问另一个VTL的内存。这种隔离的好处包括在保护资产（例如密码散列和Kerberos密钥）的同时，可以进一步缓解内核漏洞。内核模式和用户模式代码的传统模型分别在CPU环0和环3中运行。在VSM模型中，在传统模型中运行的代码在VTL0中执行，并且无法访问特权更高的用户VTL1。VTL是分层的，这意味着在VTL1中运行的任何代码都比在VTL0中运行的代码更具特权。VTL隔离由Hyper-V管理程序创建，该管理程序在引导时使用二级地址转换（SLAT）分配内存空间。它会在系统运行时动态地继续执行此操作，从而保护安全内核指定需要从VTL0保护的内存，因为该内存将用于包含机密信息。当为两个VTL分配了单独的内存块时，通过为具有适当访问权限的VTL1和VTL0分配独占内存块，为VTL1创建了安全的运行时环境。Trustlet是可信任进程的缩写，是在VSM安全模式下作为IUM进程运行的程序。它们通过将它们编组到在VTL0环0中运行的Windows内核来完成系统调用。VSM创建一个小型执行环境，包括在VTL1中执行的小型安全内核，该内核与在VTL0中运行的内核和驱动程序隔离。明显的安全性好处是将VTL1中的trustlet用户模式页面与VTL0内核中运行的驱动程序隔离。即使VTL0的内核模式受到恶意软件的破坏，它也无权访问委托人。
我们的软件TPM在VTL1内部实现，并且所有关键任务操作都在VTL1容器内完全隔离并受到保护。例如，使用用户凭证进行的密钥启封是在VTL1S-ModeTPM内部处理的，并且永远不会暴露给普通的操作系统。此外，从dTPM派生的主密钥仅保留在VTL1的安全内存中，在引导阶段，信任将从H模式TPM传输到该安全内存中。
其次，TPM状态安全地存储在非易失性存储器中，以便可以在重新启动或睡眠后恢复该状态。我们使用从VTL1存储密钥派生的密钥来加密状态信息并将其存储在文件系统中。由于使用仅VTL1知道的密钥对其进行加密，因此无法对其进行篡改。另外，我们不存储派生密钥，而是即时从VTL1主密钥派生的，以减少攻击面。
第三，我们通过利用基于虚拟化的隔离和硬件TPM来实现深度防御。根密钥（例如SRK，EK，AIK）通过硬件保护安全地存储在H模式TPM中，并且用作基于硬件的信任根。VSM通过使用隔离的环境来提供额外的防御深度。普通操作系统无法直接访问dTPM内部的根密钥。它应该通过VSM，并且VSM充当密钥管理中的附加防火墙。
第四，我们通过信任转移和H模式与S模式之间的安全通信通道建立，在H模式与S模式之间建立了无缝的信任信任关系。为此，我们生成了多个VTL1主密钥。一个密钥是从dTPM的SRK派生的存储主密钥。另一个密钥是通信主密钥，用于保护VTL1和dTPM之间的通信。分别来自通信主密钥的机密性和完整性保护密钥。VTL1存储密钥和通信主密钥都是在引导过程中派生的。为避免密钥被盗用，将密钥密封到VTL1映像和设备配置的状态。另外，关键是当且仅当它在启动过程中通过dTPM的设备认证时，才被密封。密钥是针对TPM的状态密封的，TPM的状态通过PCR的子集表示。密封的信息使用公钥加密，并且仅在所选PCR处于密封时的确切状态下才能解密。一旦从dTPM根密钥派生VTL1主密钥并将其放置在VTL1的受保护安全存储器中，就只能从VTL1进行访问，并且信任建立完成。
第五，我们为基于硬件的TPM和基于软件的TPM提供了完全双重模式，这意味着VTL1可以完全控制以根据应用程序的需求使用其中一种。为了提高可用性，我们的参考实现的构造如图3所示。所有应用程序需要做的是调用相同的包装器API，并设置一个标志以指示它打算使用H模式TPM还是S模式TPM。然后，包装程序根据该标志将应用程序的请求路由到硬件TPM或软件TPM。标志的完整性受到保护，因为它是应用程序可执行映像的一部分。
图3 整体软件架构
性能评估
dTPM由于其低成本的设计原理而存在严重的性能问题，如图1所示。它对要求高操作质量的应用提出了可用性挑战。由于其操作的数学特性（例如大质数搜索，模幂运算），RSA密钥生成，解密和签名的速度特别慢。我们展示了如何通过我们提出的hTPM方案显着提高性能。我们已经使用TPM参考实现版本1.16实现了hTPM。用户只需设置标志以映射相应的功能指针，即可在H模式和S模式之间切换。我们从DELL和HP中选择了商用OEM设备，并使用英飞凌和NuvotondTPM进行了性能评估。戴尔计算机使用英特尔至强CPUE5-1650v43.60GHz，3601Mhz6核，12个逻辑处理器。戴尔计算机的TPM是NuvotonTechnology（NTC），具有1.3.2.8和TPM规范版本2.0。HP使用IntelXeonCPUE3-1505Mv63GHz，300Mhz，4个内核，8个逻辑处理器。HP机器的TPM使用Infineon（IFX）版本7.61.2785.0和TPM规范版本2.0。
结论
对于要求高操作性能，可用性和端到端系统安全性保证的应用，纯硬件和纯软件TPM解决方案都构成了重大挑战。在本文中，我们提出了混合TPM方案，其中我们有效地结合了基于硬件的TPM和基于软件的TPM的优点。我们提出了一种复杂的设计，以克服实施hTPM的技术和安全挑战。我们的风险分析表明，hTPM设计可提供最高级别的安全保证，并可以有效地减轻实施hTPM的可能风险。此外，我们对参考hTPM实施方案的性能分析表明，通过安全利用现代CPU的高性能，与dTPM相比，性能有了显着提高。