可信计算论文学习集

CARE

Abstract

该方法是一种云平台可信性验证的新方法。提出了基于多个验证者远程认证的方法。

CARE旨在提高远程认证的实用性和效率，并解决涉及多个利益相关者的环境中的安全和信任问题。

• 采用群体验证的概念，采用多个验证者的循环协作模型来收集和验证证据，从而解决信任问题，提高验证效率。
• 引入了精心设计的过滤机制，以非侵入式方式解决验证结果中的误报问题。
• 采用多向树形结构来构建基线值库，从而增强了系统的灵活性和细粒化管理能力。

CARE 可解决因应用层激活完整性测量架构 (IMA) 而导致远程验证结果不准确的首个实用解决方案。

知识补充

什么是基线值库（Baseline Value Library）？

基线值是系统中某些关键对象（如文件、配置项、内核模块等）在可信状态下的参考值。这些值可以是文件的哈希值或签名（如 SHA-256 哈希）、系统配置项的参数值（如安全策略、网络规则）、应用程序的版本信息、运行环境的状态描述等

什么是完整性测量架构（IMA）？

• IMA 的作用是测量系统中关键组件（如内核模块、文件、应用程序等）的完整性，并生成对应的哈希值。这些哈希值会被记录在日志中或存储到 TPM（可信平台模块）的 PCR（平台配置寄存器）中。

• 远程验证通常通过获取这些测量值并比对预期的值，来检查系统是否被篡改。

什么是应用层激活 IMA？

• 激活 IMA 是指触发 IMA 来对某些对象（如文件、程序）进行完整性测量。
• 应用层激活 IMA 是指这种触发是由应用层的操作导致的，例如某个应用程序读取文件或加载模块时触发了 IMA的测量。

为什么会导致远程验证不准确？

1. 测量结果的不一致性：

   如果测量是在应用层动态触发的，不同时间、不同条件下激活IMA，测量的结果可能会受运行时的上下文影响。例如，某些动态生成的文件或临时文件在测量时的哈希值可能会变化，导致测量值与预期不一致。

2. 不可预测的测量值：

   应用层的操作有时会访问文件或模块，这些访问可能并不总是按照固定顺序进行。这种不确定性会导致测量值的顺序和内容与预期值不符，影响远程验证。

3. 测量与预期范围不一致：

   远程验证通常依赖于预定义的策略来验证特定对象（如内核或关键配置文件）。应用层触发IMA后，可能测量了额外的、非关键的对象，或者没有测量到策略要求的对象，从而导致远程验证失败。

4. 动态数据的测量问题：

   应用层可能涉及动态生成的数据（如日志、缓存文件）。这些数据的完整性测量在远程验证时可能没有意义，因为其哈希值会随时间或操作而变化。

Introduction

深度学习即服务(DLaaS)

DLaaS（Deep Learning as a Service）是一种基于云计算平台的服务模型，它允许用户通过云端提供的深度学习基础设施、算法和工具来进行模型训练、推理和开发，而无需自行配置和管理硬件资源。

在DLaaS的生态系统中，有多个服务提供者，每个都有不同的角色，如模型提供者、计算提供者和应用程序提供者，协作提供专门的服务。

缺点：多方的参与和公共云环境中的操作导致数据和模型提供商在将他们的知识产权上传到云时犹豫不决，担心他们的知识产权被泄露或滥用。

• 解决1：

  如同态加密(HE)和安全多方计算(MPC)等隐私计算技术提供了一些安全措施。局限性：内存计算期间的攻击风险，并且这两种方法都要求模型和数据集提供者完全信任执行计算任务的云平台。

• 解决2：

  远程证明机制可解决云平台的可信度问题

远程证明(RA)

RA（Remote Attestation） 是一种用于验证和评估远程系统（如服务器、物联网设备、虚拟机等）可信状态的技术。它通过向验证方（通常是管理系统或信任中心）提供系统的可信状态证明，确保远程设备没有被篡改或受到攻击，从而建立信任关系。

1. 单个验证器

   缺点：集中式验证模式，容易造成瓶颈，尤其是延迟。

2. 蜂群验证机制

   优点：缩短了总验证时间，规避了单个验证器可能存在的拥堵。

   缺点：主要应用于物联网（IoT）场景，很难迁移到云环境。

缺点：IMA 测量所有二进制文件加载、模块加载和动态链接库加载，并将指标记录在日志中。因此，即使是生命周期极短的文件也会被测量和记录。记录生命周期极短的文件可能会对验证结果的精确性产生不利影响。

Related Work

深度学习系统安全和虚拟机可信状态证明的相关工作

Deep Learning System Security

• 基于隐私计算技术

  优点：隐私保护方法可以防止模型窃取和篡改。

  缺点：可能存在计算速度和准确性降低等问题。

• 利用安全的执行环境进行系统保护

  优点：提供了可信的执行环境，有效地防止了代码和数据泄漏

  缺点：受有限的可信内存的限制，因此很难确保在数据的存储、传输和计算生命周期中提供全面保护。

Hardware-based Remote Attestation

基于硬件的证明依赖于物理芯片和模块，如TPM和Intel SGX，以提供高级别的安全性。

TPM支持安全存储和计算。SGX 通过硬件确保应用程序的机密性和完整性，然而，SGX依赖于物理CPU，由于硬件环境的变化，在VM迁移期间会带来挑战。

在云环境中，验证虚拟机的可信性需要同时验证虚拟机、主机和管理程序，这叫做虚拟机深度验证。TCG提出的分段测量框架将虚拟机与主机验证分开，但这种方法存在冗余问题。

当多台虚拟机运行在同一台主机上时，对每台虚拟机进行远程验证需要重复收集主机证据，效率较低。

TVP-PCA

• 优点：使用信任链和MAC地址算法解决了身份问题。通过验证测量日志和PCR值提供更高的准确性，从而能够识别受损设备并精确定位受影响的组件
• 不足：无法解决主机证据收集过多的问题。

CloudTA

该框架将同一主机上所有vm的测量扩展到同一寄存器，从而实现组验证。

• 优点：提高了验证效率，解决了冗余问题。通过验证测量日志和PCR值提供更高的准确性，从而能够识别受损设备并精确定位受影响的组件
• 不足：无法对虚拟机内部状态进行针对性的验证，无法判断应用的可信启动状态。

随着RA的应用增多，传统集中式验证模式难以适应。蜂群认证成为解决方案，通过广播或分层结构，高效服务多个节点。

广播适用于网络拓扑变化频繁但通信开销高且容易发生广播风暴的场景。

分层认证更适合具有不同资源能力的设备集群。

ESDRA

• 优点：分布式设计减少了时间开销。
• 缺点：多个邻居同时对单个证明者进行认证会增加计算和内存成本。只包含设备的最终哈希值，无法精确定位到组件。

SARA

• 优点：保证物联网设备上运行的软件的安全性。
• 缺点：集中认证机制需要将整个设备组的证据报告给验证方，导致证据数据量随着服务数量的增加呈线性增长。只包含设备的最终哈希值，无法精确定位到组件。

FeSA

第一个将机器学习应用于群体认证方案

• 优点：验证者根据其行为识别可疑设备并执行证明，从而减少了证明者的开销。
• 缺点：由于机器学习算法固有的假阳性和假阴性率，设备状态评估的准确性有待进一步研究。

DeepTrust

也是使用机器学习来评估物联网设备的可信度。

为了缓解依赖于单个验证者的远程认证方案可能面临单点故障的风险，基于第三方服务的远程认证解决方案利用SGX来确保验证过程的安全性。

DVRA

• 优点：
• 缺点：SGX封装的内存限制和频繁的分页操作严重影响了大规模认证任务的效率。

ZKSA

一个基于零知识证明（ZKP）的去中心化远程认证协议

• 优点：支持证明者和多个验证者之间的非交互式验证过程，增强了认证过程的安全性。
• 缺点：计算开销大，设备要求高。

总的来说，上述方案不考虑设备退出，只部分考虑新设备加入。群体认证模式可以有效地评估集群的可信度，但由于结果聚集，无法推断单个节点的内部状态。ZKSA、DVRA、ESDRA和SARA在脱机阶段部署软件，但在程序启动时缺乏完整性检查。分段认证方法可以验证虚拟机的可信性，但存在主机信息收集过多的问题。基于管理程序的并发认证确保虚拟机的可信引导，但在验证虚拟机内应用程序的可信度方面受到限制。

零知识证明复习：

零知识证明（Zero-Knowledge Proof, ZKP） 是一种密码学方法，允许证明者向验证者证明某件事是真实的，而无需透露证明过程中的任何额外信息。它的核心特点是确保隐私和安全，同时完成可信验证。

零知识证明的三个关键特性：

1. 完整性（Completeness）
   如果声明是真实的，诚实的证明者可以让验证者相信它是真实的。

2. 可靠性（Soundness）
   如果声明是假的，证明者无法欺骗验证者，使其相信声明是真实的。

3. 零知识性（Zero-Knowledge）
   验证者只能确认声明的真实性，但无法获取任何额外信息。

零知识证明的工作流程（简单例子）

1. 声明：证明者宣布“某个命题为真”。
2. 挑战：验证者随机生成一个问题，要求证明者回答。
3. 响应：证明者基于其秘密知识回答问题。
4. 验证：验证者根据声明和规则验证证明者的答案是否符合条件。

这个过程通常重复多次，以降低欺骗成功的概率。

Overview

介绍循环远程认证体系结构、安全假设、设计目标和攻击模型。

Infrastructure requirement

基础设施要求（Infrastructure requirement）：

要求服务器配备tpm，而vm配备vtpm。

Architecture

模型构建

Cloud Server (CS)

过程步骤：

1. 每个云服务器和虚拟机必须主动注册CS的注册模块。

2. 云服务器及其托管的虚拟机作为证明者，生成远程认证所需的证据信息。同时，云服务器还充当验证者。当需要提供远程认证服务时，云管理中心将验证者的基线值并发分发给指定的验证者。

3. 验证者在指定的相邻云服务器及其上运行的所有虚拟机上执行远程认证操作。

4. 验证方将认证结果上报给云平台管理中心。

Cloud Management Center (CMC)

由两个模块构成

1. 注册模块RM (Register Module)：

   负责存储云服务器、虚拟机的id、AIK公钥和鉴权。

2. 基线值库：

   负责存储所有证明者的基线值。

Assumptions

假设所有的云服务器都配备了硬件tpm，虚拟机拥有vtpm，云平台的管理中心是完全安全的。此外，CARE需要四个基本先决条件。

首先，尽管容易受到硬件攻击，如TPM回滚攻击、系统重启攻击和恶意SMM处理程序攻击，但假设云节点的TPM是安全的。这意味着安全密钥、非易失性内存RAM （NVRAM）和平台配置寄存器（pcr）不会受到破坏。

其次，攻击者不能模拟TPM软件、伪造认证结果或伪造数据签名，因为加密密钥的私钥是不可迁移的，并且由物理TPM保护。

第三，假设芯片生成的密钥、哈希值和伪随机数可以抵抗冲突或暴力攻击，因此重写或回滚物理TPM的PCR值在密码学上是不可行的。

第四，考虑了攻击者入侵虚拟机和云服务器的场景，目的是通过篡改核心操作系统组件来提升特权，同时排除了所有云服务器都被入侵的场景。

Design Goals

CARE的安全目标

1. 安全——重新设计的方案没有引入新的攻击面。例如，引入的过滤机制不会降低远程认证服务的安全性。
2. 可信度——该方法应该验证多方参与的运行时环境的可信度，为深度学习服务提供受控的运行时环境。
3. 完整性——该方法在启动时保护虚拟机内应用程序的完整性，防止文件修改攻击。

CARE的部署目标

1. 兼容性和稳定性——该方法应尽量减少对操作系统内核的修改，以防止中断用户业务运营和云服务可用性。
2. 实用性——所提出的方法应该确保加载应用层程序时完整性验证的准确性。
3. 可扩展性——随着虚拟机数量的增加，证明方法应该保持有效。

Attack Model

确定了两种主要的攻击类型:

1. 重放攻击，在这种攻击中，攻击者秘密地截取并向服务器重新发送用户数据包，而不为特定目的进行修改。
2. 中间人(MITM)攻击，攻击者窃听网络通信，可能发送错误消息，导致拒绝服务或损坏。

确定了两种攻击对象：

1. 恶意用户:恶意用户可能会通过修改某些文件来中断服务或运行环境，从而提升对系统的控制并实现他们的攻击目标。这些用户可能会通过修改现有记录或添加无效记录来破坏证据信息。
2. 恶意服务提供商:作为平台所有者，他们有能力通过某些方式添加、修改或删除软件的信任链证据。恶意服务提供商可能为了商业利益或其他动机伪造或修改软件证据，甚至删除可能对他们不利的证据。

Remote Attestation Design

主要分为系统设置和远程认证两个阶段

System setup

云节点注册（Cloud Node Registration）

为保证信息的准确性，在云节点内部署信息收集代理（information Collection Agent，ICA）进行信息收集。

• 步骤1：云节点进行身份密钥注册，ICA向RM发送基本信息(节点$ID$、认证身份公钥($AIK_{pub}$)和签名密钥公钥($EK_{pub}$))。
• 步骤2a：RM将$AIK_{pub}$与$EK_{pub}$绑定，并存储$ID$和$AIK_{pub}$。
• 步骤2b：RM生成随机数$nonce$(防止重放攻击)和会话密钥($ke$)，然后按照等式(1)计算$\beta$。

$$\beta=Hash(AIK_{pub}) \tag1$$

• 步骤2c：RM根据等式(2)计算密文$M_1$并发送至云节点

$$M_1=E_{EK_{pub}}(\beta,ke,nonce)\tag2$$

• 步骤3a：云节点使用背书密钥私钥($EK_{pri}$)解密$M_1$，如等式(3)中所描述的，以获得$\beta$、$ke$和$nonce$。

$$\beta,ke,nonce=Dec_{EK_{pri}}(M_1)\tag3$$

• 云节点随后基于等式(4)验证密文是否损坏。

$$Hash(AIK_{pub})=\beta\tag4$$

• 步骤3b：ICA通过设计的过滤机制收集和过滤测量日志( core log，ML)，以导出核心测量日志(core measurement log，CML)，在后部分Core measurement log（核心测量日志）中详细描述。然后，ICA使用等式(5)和等式(6)计算$M_2$，并将其传输到RM。

$$CML'=HMAC(CML)\tag5$$

$$M_2=Enc_{ke}(CML',CML,nonce)\tag6$$

• 步骤4a：RM在接收到$M_2$时，使用$ke$来提取$CML’$、$CML$和$nonce$。步骤4需要RM通过将随机数与步骤2b中的随机数进行匹配来确保$M_2$是最新发送的，并检查等式(7)是否成立。如果等式成立，则表明CML完好无损，RM将CML存储在基线值库中。否则，RM会丢弃CML并触发警报。

$$HMAC(CML)=CML'\tag7$$

基值库构建（ Base Value Library Construction）

定义1——临时文件

通常用于数据存储或计算任务。它的生命周期很短，只存在于相关的任务或会话中，并在完成后自动删除或清除。

定义2——核心文件

如果一个文件可以通过它的文件名在任何时候被访问，那么这个文件就被归类为核心文件。因此，核心测量日志和基线库中的所有文件都是核心文件。

1. 核心测量日志（Core measurement log）

   核心测量日志（CML）的获取算法：

   //Input : Measurement Log(ML)
   //Output: Core Measurement Log(CML)
   Core_Measurement_Log = []
   for each Measurement_log_entry in ML do
       file_name = extract(Measurement_log_entry)
       file_is_exist = file_exsits_in_system(file_name)
       // If the file exists, put it to the CML; otherwise, skip it
       if file_is_exist then
       	Core_Measurement_Log.append(file_name)
       end
   end
   return Core_Measurement_Log(CML)

   ICA顺序读取ML中的每个条目，并提取相应的文件路径(即文件名字段)(第2-3行)。然后，它根据提取的文件路径检查Linux系统中是否存在这个文件(第4行)。如果文件存在，它被认为是核心文件，并且ML中的相应条目被添加到CML。如果该文件不存在，它将被视为临时文件，被跳过，并且不会添加到CML中(第5-7行)。在用该算法遍历整个ML之后，生成CML。

2. 基线值的存储（Storage of baseline values）

   基线值库由存储在CMC中的多个基线值文件组成。基线值是云节点完成注册后发送给RM的CML。基线值库使用深度为3的多叉树构建，以~~“T”~~为根。在这个结构中，每个子节点代表一个CS，相应的CS的基线值存储在其对应的子节点上。

   每个叶节点代表一个虚拟机(VM)，虚拟机的基准值存储在相应的叶节点上。叶节点的父节点是托管对应于该叶节点的虚拟机的云服务。

   如图

   

   使用树结构存储基线值参与计算任务的虚拟机和云服务器可以动态地加入或离开。

疑问

临时文件是只存在于相关的任务或会话中，并在完成后自动删除或清除的文件，但是如果在检查的时候临时文件还未完成任务从而未被删除，是不是会误判该文件为核心文件？

是否是因为临时文件在产生时不会将文件路径（file_name）记录在文件格式中?

基线值存储时，构建多叉树的根"T"表示的是什么？

Circular Remote attestation

Task Issued

在云环境中，服务器和虚拟机的位置相对稳定，虚拟机的可信度由虚拟机本身及其主服务器共同决定。根据这一特点，该文提出了一种循环邻居协作认证方法。

在这种方法中，云服务器既是验证者，又是证明者。如图。

定义3——远程验证顺序：

对于给定的云服务器序列$(CS_1,CS_2,...,CS_i,...,CS_{n-1},CS_n)$云服务器的远程验证顺序为

$$CS_1\xrightarrow{\text{validate}}CS_2\xrightarrow{\text{validate}}...\xrightarrow{\text{validate}}CS_i\xrightarrow{\text{validate}}...\xrightarrow{\text{validate}}CS_{n-1}\xrightarrow{\text{validate}}CS_n\tag8$$

其中，$1\leq i\leq n - 1$，最后 $CS_{n}\xrightarrow{\text{validate}}CS_1$。

Attestation Process

远程认证过程可分为三个步骤：收集、传输和验证证据信息，如图。

• 信息收集

  图中红色虚线为信息收集部分，以$CS_2$为例，$CS_1$作为验证者，$CS2$作为证明者。

  1. 验证器主机层的验证代理（Attestation Agent,AA）向$CS_2$虚拟机监控器（Virtual Machine Monitor,VMM）层的传输代理（Transit Agent,TA）发送远程验证请求。TA向主机及其托管的所有虚拟机中的ICA并行发起信息收集请求。
  2. ICA使用TPM_TOOLS收集证据信息，包括来自TPM和vTPM的PCR值以及云服务器和虚拟机中IMA的测量日志（ML、vML）。

• Transmitting the information

  信息收集完成后TA就会汇总从所有运行的虚拟机收集到的证据并加密，然后将数据传输给验证器中的AA，如步骤3所示。

  如下图描述了从 TA 向 AA 传输证据信息的详细过程。

  

  首先，TA向$CS_2$上的所有ICA并行发送信息收集请求，每个请求都包含不可预测的随机数（$nonce$）。

  然后，虚拟机中的ICA根据公式(9)生成$vPCR_{2j}$的哈希的消息验证码($HMAC$)。

  $$vPCR'_{2j}=HMAC(vPCR_{2j},nonce)\tag9$$

  随后，ICA使用vTPM根据式(10)进行签名，并将生成的$Quote_{V M_{2j}}$和$vML_{2j}$一起发送给TA。

  $$Quote_{VM_{2i}}=sig(vPCR_{2j},vPCR'_{2j},nonce)_{AIK}\tag{10}$$

  同样，主机中的ICA根据式（11）计算$PCR_2$的$HMAC$，并利用TPM执行签名操作（公式(12)）。

  $$PCR'_2=HMAC(PCR_2,nonce)\tag{11}$$

  $$Quote_{Host_2}=sig(PCR_2,PCR_2',nonce)\tag{12}$$

疑问

如果在循环验证的过程中，只有一个云服务器的情况下，应该让谁来验证它。也就是n=1的时候，如何做验证。

A Bad Dream: Subverting Trusted Platform Module While You Are Sleeping

Abstract

两种针对电源管理的可信平台模块（TPM）攻击。一种攻击是利用TPM 2.0规范中用于度量的静态信任根（SRTM）的设计缺陷。另一种攻击是利用tboot中的一个实现缺陷，tboot是英特尔可信执行技术（Trusted Execution Technology）中最流行的测量启动环境。

Introduction

介绍了可信平台模块（Trusted Platform Module， TPM）的基本概念，以及度量过程和PCR。

指出TPM芯片需要与其他固件共同工作，合作机制无法明确规定将导致安全漏洞。而电源管理的工作方式就非常复杂，因为每个外围设备都有自己的电源状态，独立于系统范围的电源状态。

电源接口（Advanced Configuration and Power Interface， ACPI）是一种开放的行业规范，它使以操作系统为中心的智能和动态管理能够与电源管理感知设备（如cpu、网络、存储和图形处理单元）进行协调。

当电源状态发生变化时，TPM不能安全地保持状态。在两种类型的RTM（静态和动态）中都发现了漏洞，静态RTM （SRTM）的漏洞是由TPM2.0规范的设计漏洞造成的。动态RTM （DRTM）的漏洞是由于开源项目tboot中的一个错误造成的。

这些漏洞使攻击者可以在系统唤醒时重置和伪造pcr。

Background

TPM Technology

介绍了可信链以及信任度量时PCR的作用、TPM的作用，并且提到了核心RTM（CRTM）的作用。介绍了SRTM和DRTM的启动过程。

ACPI Sleeping States

介绍了ACPI以及四种全局电源状态：工作状态（G0 或 S0）、睡眠状态（G1）、软关机状态（G2）和机械关机状态（G3）。睡眠状态分为四种：

• S1
• S2
• S3
• S4

概述保存和恢复TPM状态的步骤

TPM在系统进入睡眠模式（如S3、S4）时保存状态，唤醒后恢复。

描述了睡眠和恢复过程中涉及的操作系统与BIOS/UEFI合作。

Assumptions and Threat Model

Assumptions

首先，假设系统使用TCG的SRTM来测量固件和引导程序,并将测量结果存储在TPM芯片中。

第二，假设系统采用TCG的DRTM架构。

最后，假设TPM中存储的测量值由远程证明者验证。

Threat Model

攻击者被设定为拥有Ring-0权限，能修改启动加载器和内核，但不能物理接触硬件。

Vulnerability Analysis

Finding the Security Vulnerabilities

利用TPM和SRTM/DRTM 技术启动系统涉及许多实体，如图显示了它们之间的关系。

发现漏洞的步骤如下：

1. 审查规范：发现在电源管理方面，TPM 2.0规范相较于TPM 1.2更容易引发状态重置问题。
2. 测试实现：在多种硬件和固件实现中，发现SRTM和DRTM均存在不符合规范或实现缺陷的问题。
3. 漏洞确认：实验验证了这些问题普遍存在于多个厂商的设备中。

SRTM Vulnerability: CVE-2018-6622

Problem: The Grey Area

介绍了当平台进入S3或S4休眠状态时，切断设备电源，此时TPM应该将其状态保存到非易失性随机存取存储器（NVRAM）中，稍后再恢复状态。因此，一些平台允许软件重置PCR并任意扩展测量。

TPM有两种主要电源状态：工作状态（D0）和低功耗状态（D3）。在进入D3状态前，TPM需要保存当前状态，在恢复到D0状态时它可以恢复保存的状态。

根据TPM 1.2规范，在进入S3睡眠状态时，操作系统会通知TPM保存状态（通过TPM_SaveState()命令）。在从S3恢复时，静态信任根（S-CRTM）决定是恢复先前的状态还是重新初始化TPM。如果没有保存的状态，TPM进入故障模式，直到系统重启。

而在TPM 2.0规范中，即使没有保存状态，TPM也会返回TPM_RC_VALUE，仍允许重新启动。此时，S-CRTM需要重置TPM并执行TPM2_Startup(CLEAR)命令，然后再交给操作系统控制。

当TPM没有保存状态时，它的状态如果被重置的话会导致TPM恢复到清除状态，此时攻击者可以向PCR扩展任意值。

Exploit Scenario

如果攻击者控制了系统软件，包括引导加载程序和内核，首先从正常启动过程中提取有效的哈希值，并将其存储在RAM中。然后，在系统进入休眠状态后，攻击者使用这些哈希值伪造PCR值，使得TPM显示系统仍在使用原始软件启动和运行，尽管实际上系统已经被篡改。如图：

Implementation in Detail

1. 提取正常的哈希值：攻击者首先需要获取正常的哈希值，这些哈希值可以从TCG事件日志中提取。事件日志中记录了每个扩展到PCR的值，以及事件类型和相关的哈希值。
2. 获取事件日志：通过修改现有的启动加载器和内核，攻击者可以通过UEFI接口调用GetEventLog()来提取事件日志，并将日志传递给内核。日志数据存储在特定的内存区域（64KB内存块），并在启动后仍然保留。
3. 重置TPM并重放哈希：攻击者通过让系统进入S3睡眠状态来重置TPM，并利用提取的正常哈希值依次扩展到PCR，伪造一个正常的启动序列。该过程通过内核中的tpm_pcr_extend()函数实现。
4. 修改启动加载器和内核：攻击者定制了启动加载器和内核，使其能够提取事件日志并伪造PCR值。特别是，启动加载器的哈希值和内核（包括内核文件和初始化RAM磁盘文件）的哈希值通过特定的事件类型（如EV_EFI BOOT_SERVICES_APPLICATION和EV_IPL）来识别。
5. TPM重置过程：要重置TPM，攻击者需要修改内核，使其跳过保存TPM状态的步骤，并调用TPM_Startup(CLEAR)命令。此外，攻击者还需要通过系统的休眠命令使系统进入睡眠状态，然后再唤醒系统以重放正常的哈希值。

DRTM Vulnerability: CVE-2017-16837

Problem: Lost Pointer

DRTM依赖动态平台配置寄存器（PCRs17-22）存储测量值，通过硬件受信保护的动态启动事件（Dynamic Launch Event, DLE）初始化，正常情况下只有硬件可访问。

但在从S3/S4睡眠状态恢复时，DRTM也会重新初始化，存在篡改的机会。更严重的是，tboot（Intel TXT 的开源实现）中的部分可变的函数指针未被测量，这使得攻击者可以通过修改这些指针来控制测量流程。

Exploit Scenario

为了破坏动态信任根（DRTM）的安全性，攻击者需要伪造扩展到动态PCR的测量值。虽然DCE（动态配置环境）在启动DLME（动态加载测量环境）之前会先测量并扩展DLME的值，这使得伪造测量值变得困难，但如果DLME本身存在漏洞，攻击者仍然可以破坏动态信任链。

攻击流程与SRTM的攻击类似，包括以下步骤：

1. 攻击者从正常启动过程中生成的事件日志中提取合法的哈希值。
2. 通过触发系统进入睡眠状态，重置动态PCR的状态。
3. 恢复时，攻击者通过钩住 DCE和 DLME中的函数，将提取的合法哈希值重新扩展到动态 PCR。

攻击的最终效果与SRTM攻击一致：伪造动态PCR的测量值，使其显示系统处于可信状态，同时隐藏系统已经被篡改的事实。

Implementation in Detail

1. 提取正常启动测量值
   攻击的第一步是获取正常启动时的动态PCR值。tboot在启动过程中记录事件日志，这些日志包含PCR的扩展顺序和测量值（如启动加载器、内核文件及initrd的哈希）。攻击者通过tboot的工具（如txt-stat）提取这些日志，或直接访问BIOS/UEFI暴露的内存区域，将这些值存储备用。
2. 挂钩tboot的函数指针
   在tboot实现中，某些全局变量（如g_tpm、tpm_12_if和tpm_20_if）存储在数据段和未初始化数据段（.bss），这些区域未被SINIT ACM测量。攻击者通过篡改这些变量，将其指向自定义的挂钩函数。挂钩后的函数接管测量逻辑，负责伪造动态PCR的扩展值。
3. 重置动态PCR并注入伪造值
   当系统进入S3或S4睡眠状态时，TPM会被置于低功耗模式，动态PCR清空。唤醒后，SINIT ACM重新启动测量流程并扩展新的PCR值。此时，攻击者的挂钩函数拦截测量操作，将日志中的正常测量值按顺序扩展到PCR，伪造系统为可信状态。

整个攻击完成后，动态PCR显示的测量值与正常启动时完全一致，隐藏了系统被篡改的事实。攻击利用了tboot在数据段的测量漏洞，以及TPM睡眠模式下动态PCR的重置机制，展示了DRTM中关键实现的安全隐患。

Evaluation

• 作者测试了多个基于Intel处理器的设备，包括支持TPM1.2和TPM2.0的设备，采用了不同的硬件厂商和BIOS版本。

• 测试系统使用Ubuntu16.04.03操作系统，内核版本为4.13.0-21-generic，并对GRUB（用于SRTM攻击）和tboot（用于DRTM攻击）进行了定制修改。

SRTM Attack: Grey Area Vulnerability

• 在SRTM攻击中，攻击者通过重置TPM并重放事件日志中的正常测量值，成功伪造了TPM的PCR值。测试中所有支持TPM 2.0的设备都能成功实施攻击，而TPM 1.2设备在特定条件下会进入故障模式，防止攻击成功。
• 测试结果表明，TPM2.0设备普遍未能妥善处理状态保存和恢复，导致攻击能够重置并伪造PCR。

DRTM Attack: Lost Pointer Vulnerability

• 所有支持Intel TXT和tboot的设备都暴露在此漏洞下，包括使用TPM2.0和1.2的设备。
• 通过对tboot源码的修改，攻击者能够挂钩函数指针，进而伪造动态PCR值，成功实现重放攻击。

Discussion and Solutions

Discussion

1. 攻击后果的严重性
   • SRTM攻击允许攻击者绕过静态测量链，将恶意修改隐藏在可信状态中，从而欺骗远程验证。
   • DRTM攻击利用tboot漏洞伪造动态PCR值，威胁范围更广，因为它能够影响运行时的动态可信链，使整个系统对软件篡改不敏感。
2. 现有安全假设的不足
   • SRTM假设TPM状态不可在不重启的情况下重置，但实际漏洞表明这种假设存在问题。
   • DRTM假设减少受信计算基（TCB）的规模可以提升安全性，但tboot的漏洞表明，DRTM实现仍可能受限于软件的脆弱性。

Solutions

1. SRTM

   改进BIOS/UEFI固件：

   • 确保在没有保存状态的情况下，禁止调用TPM2_Startup(CLEAR)或限制其执行范围。
   • 当TPM无法恢复到正常状态时，固件应该触发系统重启或进入“安全模式”（failure mode），而非允许PCR重新初始化。

   强化规范细节：

   • TPM2.0规范需要明确规定当状态恢复失败时应采取的具体措施，而不仅仅依赖CRTM的“纠正措施”。
   • 增强对异常情况下状态处理的规范化要求，从而减少厂商实现中潜在的不一致性。

2. 针对DRTM漏洞的解决方案

   修复tboot实现：

   • 对tboot中的动态测量逻辑进行全面审核，确保所有涉及的关键数据结构（如函数指针）都受到测量保护。
   • 将动态测量逻辑中使用的全局变量移出未初始化数据段或可写数据段，放入只读内存区域或测量范围内。

   使用安全的编程实践：

   • 引入不可变函数指针或通过硬件方式锁定关键数据结构，防止其被挂钩。
   • 增加对敏感内存区域的保护措施，防止攻击者注入恶意代码。

3. 针对事件日志重放的对策

   保护事件日志：

   • BIOS/UEFI在启动过程中生成的事件日志可以被攻击者利用重放正常测量值，因此应在操作系统接管之前对事件日志进行加密或擦除。
   • TPM规范应加入针对事件日志重放的防御机制，例如禁止日志中敏感数据的重复使用。

   增强远程验证机制：

   • 在远程验证中增加对系统唤醒事件的监控，通过审计睡眠和唤醒的历史记录，检测是否存在重置和伪造的行为。

4. 长期方向：改进可信计算基础架构

   作者指出，虽然DRTM通过减少TCB规模提升了安全性，但当前的实现表明，软件漏洞仍然可能破坏信任链。未来的可信计算架构应更加注重硬件与软件的协同防御：

   • 开发更强的硬件信任根（如更安全的动态测量触发机制）。
   • 在软件层面加入多重冗余校验和完整性保护。

Design and implementation of trusted boot based on a new trusted computing dual-architecture

Abstract

论文提出了一种新型的可信计算双体系架构，用以解决现有可信平台模块（TPM）技术的缺陷，如易被物理攻击、启动依赖CPU等问题。通过设计可信计算子系统和传统计算子系统的协作机制，以及新的可信启动流程，该架构能够提供更高的系统安全性和主动防御能力。

Introduction

可信平台模块（TPM）是当前计算机系统中普遍使用的一种可信计算技术，其通过加密技术和硬件模块实现数据保护和平台完整性验证。然而，现有的TPM架构在实际应用中存在以下两大问题：

1. 启动顺序问题
   在传统架构中，TPM作为从设备，其启动依赖于主CPU的初始化。主CPU会优先加载BIOS代码，并负责初始化TPM。这种流程带来一个安全隐患：如果BIOS代码遭到篡改，例如注入病毒（如MoonBounce病毒），整个系统的信任链条将被破坏。当前TPM架构无法保障在主CPU加载前就建立可信环境。
2. 物理安全问题
   TPM芯片通常外置安装在主板上，这让其暴露于物理攻击。例如，攻击者可以使用探测设备截取TPM总线上的传输数据，甚至物理移除芯片以禁用其功能。此外，TPM作为从设备，其权限受限，无法主动控制整个计算系统。

针对上述问题，本文提出了一种全新架构，核心目标包括：

• 确保可信模块启动优先：让系统的硬件根信任优先于其他组件启动，以建立可信的系统基础。
• 增强物理安全性：通过将硬件根信任模块集成到CPU内部，避免外部暴露所带来的安全隐患。
• 构建完整的可信链条：从硬件到软件逐层验证和保护，确保每一环节的安全性。

Related work

可信计算技术自1971年首次提出以来，经历了持续的发展，并被广泛应用于保障计算机系统的安全性。其中，Trusted Computing Group (TCG) 的可信平台模块（TPM）是目前最广泛使用的可信计算技术，其最新规范TPM 2.0于2014年发布，能够通过测量和验证来确保系统运行的可信性。然而，TPM技术仍然存在一些不足，例如启动次序滞后和易受物理攻击。

为应对这些问题，各大厂商和研究机构提出了多种改进方案。例如，IBM开发了基于PCIe卡的硬件协处理器，通过硬件测量实现系统启动的可信性；Intel提出的Trusted Execute Technology (TXT) 则利用CPU硬件和固件，实现可信执行环境（TEE）并强化启动过程。此外，ARM 的TrustZone技术通过硬件隔离的方式划分安全世界和普通世界，为敏感数据提供独立的运行环境。这些技术虽然各具优势，但仍存在架构复杂性高或易被攻击等问题。

总体来看，当前的研究为可信计算技术提供了诸多启发，但系统性地解决可信启动中的缺陷仍需要新的架构支持，这正是本文提出可信计算双体系架构的意义所在。

Trusted computing dual-architecture scheme

Design of trusted computing dual-architecture

该文提出的可信计算双体系架构创新性地将系统划分为传统计算子系统和可信计算子系统，通过硬件可信根的优先启动、资源隔离和高效通信机制，构建起从硬件到软件的完整可信链条。在架构设计、运行机制和整体优势方面，体现出对传统TPM架构的全面优化。

可信计算子系统的设计与运行机制

可信计算子系统是系统安全的核心，其主要功能由可信CPU（Trusted CPU）以及独立的硬件资源（如ROM、SRAM和加密模块）实现，具备以下特点：

• 硬件根信任的优先启动
  系统上电后，可信CPU率先加载嵌入式ROM中的启动代码（on-chip boot loader），完成自身初始化并启动加密模块。可信CPU通过片内总线读取并验证外部SPI闪存中的扩展启动代码（off-chip boot loader）和BIOS。验证完成后，传统计算子系统才会被允许启动，确保整个启动过程自硬件层面即受到信任。
• 独立的硬件资源与权限隔离
  可信CPU通过专属的ROM存储不可篡改的启动代码和密钥，利用SRAM执行可信计算任务，并使用加密模块（如AES、SHA和ECDSA）对外部数据进行验证。可信计算子系统的所有资源对传统计算子系统完全隔离，但可信CPU可通过总线访问传统子系统的资源，实现主动的安全监控。
• 分离的电源域设计
  可信计算子系统和传统子系统分别位于两个独立的电源域中。可信计算子系统优先上电并完成初始化，然后控制传统计算子系统的上电流程，避免传统架构中由于启动顺序错误导致的潜在安全漏洞。

通过可信计算子系统的独立设计和优先启动机制，架构有效解决了传统TPM架构在启动可信性和权限控制上的问题。

架构内通信与协作机制

可信计算子系统与传统计算子系统通过高性能片内总线（如AXI总线）实现通信和协作，优化了系统的效率和安全性：

• 片内总线的高性能设计
  采用先进可扩展接口（AXI）总线作为片内通信核心。AXI总线支持多主多从模式，其中可信CPU作为主设备拥有更高权限，可以访问传统计算子系统的所有资源（如内存、BIOS和外部存储）。而传统子系统则无法访问可信子系统的资源，从而实现资源隔离与权限控制。
• 更高的传输效率
  相较于传统主板上的SPI总线，片内AXI总线具有更宽的数据通道（支持8至1024位）和更高的时钟频率（最高可达200 MHz）。这种设计显著提升了数据传输速率和运行效率，并降低了延迟。
• 动态监控与主动验证
  在系统运行过程中，可信CPU通过AXI总线实时访问传统子系统的资源，并执行安全策略，例如定期测量内存的完整性或动态验证BIOS的安全性，从而确保整个系统始终处于可信状态。

这种片内高速总线的设计不仅提升了架构的整体性能，还通过严格的访问控制强化了资源保护。

硬件可信根的集成与设计优势

硬件可信根的集成设计是本文架构的重要创新，突破了传统TPM芯片外置的限制，为系统带来了更高的安全性和性能：

1. 硬件根信任的芯片内集成
   硬件根信任模块（Trusted CPU）直接设计为CPU芯片上的一个IP模块，与传统计算CPU共用同一块硅片。其设计方法包括：
   • 硬件资源共享与隔离：可信CPU通过共享的片内总线与其他IP模块（如内存控制器）交互，但可信CPU独占ROM和SRAM等关键资源，保障安全性。
   • 制造过程中的固化：可信CPU的启动代码和密钥在芯片制造过程中固化到ROM中，这种设计确保了可信根的不可篡改性。
2. 片内高速总线的实现
   可信CPU和传统CPU通过片内AXI总线连接，该总线在设计上具有以下特点：
   • 多主多从架构：AXI总线允许多个主设备（如可信CPU和传统CPU）同时访问多个从设备（如内存和SPI控制器）。
   • 权限管理机制：通过分配设备ID和访问权限，确保传统子系统无法访问可信子系统的专属资源，而可信CPU可主动控制传统子系统的资源访问权限。
   • 数据加密与保护：总线通信的数据可通过硬件加速的加密模块（如AES）加密传输，进一步增强安全性。
3. 设计优势的综合体现
   • 启动可信性：可信CPU优先启动并对BIOS等外部数据进行验证，从硬件层面构建起完整的可信链条。
   • 物理安全性增强：可信CPU与计算CPU共用一块芯片，消除了TPM外置芯片易被拆卸或监控的物理安全隐患。
   • 运行效率优化：片内高速总线极大提升了数据传输速率，减少了传统架构中的启动时间延迟。

通过硬件可信根的集成和片内总线的优化设计，本文架构不仅在启动可信性和物理安全性上取得了突破，还显著提升了系统性能，为可信计算提供了全新的解决方案。

Advantages of trusted computing dual-architecture

本文提出的可信计算双体系架构通过硬件可信根的集成、优先启动和系统级优化，显著提升了计算机系统的安全性和性能。

启动可信性

可信计算双体系架构通过硬件可信根（Trusted CPU）的优先启动，确保系统从最底层硬件开始构建可信链条：

• 硬件优先启动：系统通电后，可信CPU首先初始化自身并加载内嵌ROM中的启动代码（on-chip boot loader）。可信CPU完成自身初始化后，通过片内高速总线读取并验证扩展启动代码和BIOS的完整性，确保启动流程的每一步都可信。
• 逐层验证的可信链：从可信CPU到BIOS，再到操作系统和应用程序，可信CPU通过加密技术（如SHA和ECDSA）逐层测量和验证每一环节的完整性。若检测到任何篡改，系统会中止启动并发出警报。
• 避免BIOS篡改风险：传统TPM架构中BIOS优先启动的设计易导致安全漏洞，而双体系架构通过可信CPU控制BIOS加载的先决条件，完全规避了此类风险。

这种逐步递进的验证方式使系统启动过程在硬件级别和逻辑级别都达到高度可信。

物理安全性

通过将硬件可信根集成到CPU内部，架构在物理安全性上取得了显著提升：

• 内嵌设计的不可篡改性：可信CPU被集成为CPU芯片上的IP模块，与传统计算CPU共享同一硅片。可信CPU内的启动代码和根密钥在芯片制造过程中固化到ROM中，确保其无法被篡改或替换。
• 防止物理攻击：传统TPM芯片由于外置设计易受硬件攻击（如探测传输总线、物理拆卸等），而双体系架构通过内嵌设计完全消除了外部攻击面。可信计算子系统的独立资源和片内通信机制进一步强化了对关键数据的保护。
• 安全的数据传输：片内高速总线通过访问权限管理机制和硬件加密功能（如AES）保护通信过程中的数据，避免了外部总线传输中常见的窃听和篡改风险。

这一设计从根本上解决了传统TPM架构在物理层面暴露的安全隐患，为系统提供了更坚固的硬件防护。

系统性能优化

可信计算双体系架构通过高效的片内通信和硬件加速技术，显著提高了系统运行效率：

• 片内高速总线：架构采用高性能的AXI总线，支持多主多从模式，实现了可信CPU和传统CPU之间的高速数据传输。相比传统的SPI总线，AXI总线提供了更高的带宽（支持8至1024位数据通道）和更低的延迟，显著缩短了系统的启动时间。
• 硬件加速模块：可信CPU集成了硬件加速的加密引擎（如AES、SHA和ECDSA），在执行数据加密和完整性验证任务时比软件实现快数倍。例如，实验中硬件加速的AES加密在大数据块上达到了633.8 MB/s的速率，而软件实现仅为52.2 MB/s。
• 启动流程优化：硬件可信根的优先启动和片内高效通信使启动流程更加紧凑，避免了传统TPM架构中因启动次序问题导致的时间延迟。对于启动时间敏感的用户（如个人电脑和移动设备），这种优化尤为重要。

架构的性能提升不仅体现在启动阶段，还为可信计算的动态运行提供了更强大的计算能力和更快的响应速度。

Scheme of trusted boot system

可信计算可以对硬件、固件、GRand Unified Bootloader（GRUB）、操作系统和应用软件进行度量和验证，从而建立整个平台的信任链。信任链的来源决定了整条信任链的可靠性。下面重点介绍从硬件信任根启动到固件加载完成的可信启动流程设计，本文不涉及从固件到GRUB、到OS、到应用软件的阶段。

Design of a Secret Key System

1. 根秘钥（Endorsement Key, EK）

   根秘钥（EK）是系统的硬件信任基础，由制造商在设备生产阶段生成。EK 是一对非对称密钥（公钥和私钥），其私钥被直接固化在可信 CPU 内部的 ROM 中，这一过程在 CPU 晶圆生产阶段完成，确保了 EK 的不可读取性和不可篡改性。EK的存在使每台设备拥有独一无二的身份，从硬件层面为系统建立了初始的信任。

   在系统运行时，EK私钥的主要功能是加密其他秘钥（如制造商秘钥MK），从而为秘钥系统提供强大的加密保护。EK的公钥则可以被外部使用，用于设备认证或信任建立，例如向外部验证设备是否为可信硬件。

   EK的私钥和公钥被设计为无法直接暴露，确保根秘钥的安全性和独立性。通过这种硬件层面的隔离，EK在整个秘钥系统中扮演了不可替代的基础角色，直接决定了系统最底层的安全性。

2. 制造商秘钥（Manufacturer Key, MK）与公私钥对（ECDSA）

   制造商秘钥（MK）是系统中用于保护设备加载程序的对称加密密钥，由制造商生成并通过EK加密后存储。MK不直接存储原始密钥，而是以加密版本（ENC_MK）的形式存放于设备的SPI Flash中。在设备启动时，可信 CPU 使用ROM中的EK私钥，通过硬件加密引擎解密ENC_MK，从而恢复出 MK。恢复后的MK被用于解密加载程序或其他敏感数据，并确保这些数据在启动前未被篡改。

   与MK一起工作的还有制造商的ECDSA公私钥对（PubK_ECDSA和PriK_ECDSA）。私钥（PriK_ECDSA）由制造商保存在安全服务器中，仅用于对加载程序或关键数据进行数字签名，而公钥（PubK_ECDSA）则被存储在设备的SPI Flash中，供可信CPU验证加载程序的数字签名。

   为了防止公钥被篡改，制造商在生产阶段会计算公钥的哈希值（HASH_PubK_ECDSA）并将其固化到硬件信任根的ROM中。这一固化过程与EK的写入类似，在晶圆生产阶段完成，确保哈希值的不可更改性。在设备启动时，可信CPU从SPI Flash读取公钥（PubK_ECDSA），通过硬件加密引擎重新计算哈希值，与ROM中的HASH_PubK_ECDSA比对。如果匹配，则说明公钥未被篡改，可信CPU随后会使用公钥验证加载程序的数字签名，确保加载程序的来源和完整性可信。

3. 用户秘钥（User Key, UK）

   用户秘钥是用户在系统中的身份凭据，由用户生成一对非对称的公私钥（UK_Pub和UK_Pri）。用户公钥（UK_Pub）由用户提供给制造商，制造商将其使用MK加密后存储于设备的SPI Flash中，生成加密版本ENC_UK_Pub；用户私钥（UK_Pri）由用户自行保管，用于签名 BIOS 配置文件或其他用户自定义代码。

   在BIOS签名验证过程中，可信CPU首先使用MK解密ENC_UK_Pub，恢复用户提供的公钥UK_Pub，然后使用该公钥验证BIOS的数字签名，确保用户提供的代码未被篡改。用户秘钥的引入使系统在保持制造商安全管理的同时，赋予用户一定的安全控制权，进一步增强了系统的灵活性和可信性。

4. 硬件支持与启动过程

   硬件在整个秘钥系统中起着核心支撑作用，其安全性直接决定了系统可信计算能力的高低。硬件信任根中的关键模块包括 ROM、硬件加密引擎和随机数生成器（TRNG）。ROM 存储了系统最核心的数据，包括EK私钥和 HASH_PubK_ECDSA，其不可修改性为系统提供了最基础的信任保障。硬件加密引擎负责执行AES加密解密、ECDSA签名验证和SHA哈希计算等操作，这些操作由硬件完成，比纯软件实现更加高效且安全。TRNG用于生成高质量的随机数，为秘钥生成提供支持，确保加密的强度。

   启动过程中，可信 CPU 首先从ROM中读取EK和HASH_PubK_ECDSA，验证SPI Flash中存储的PubK_ECDSA和加载程序的数字签名。在这一过程中，硬件加密引擎会负责计算公钥的哈希值，并与ROM中的HASH_PubK_ECDSA进行比对。如果公钥可信，可信CPU会继续解密ENC_MK，恢复MK，并解密加载程序。随后，使用PubK_ECDSA验证加载程序的数字签名，确认程序完整性，最终启动系统。

5. 设计的安全性与优势

   这套秘钥系统结合硬件和加密算法，从根秘钥（EK）到用户秘钥（UK）层层加密保护，构建了一个严密的信任链。

   • 硬件不可篡改性：EK和HASH_PubK_ECDSA固化于ROM中，确保了系统最底层的安全性；SPI Flash中的秘钥和加载程序经过加密保护，即使外部存储器被攻击，攻击者也无法直接提取关键数据。
   • 逐级验证机制：系统从硬件到软件逐层验证，所有关键组件（如公钥、加载程序、BIOS配置文件）都需通过数字签名和哈希比对，确保每一级运行环境的可信性。
   • 高效性能与抗攻击能力：硬件加密引擎支持高性能的加密与验证操作，同时抵御物理攻击，例如防止外部探测或拆卸。
   • 灵活性与可管理性：用户秘钥与制造商秘钥的结合，确保用户能够参与系统配置的安全管理，同时支持设备的批次化管理，适用于大规模生产。

   通过这些设计，秘钥系统为可信计算双架构提供了可靠的安全保障，不仅提高了设备的安全性，还增强了其在实际应用中的灵活性。

云环境中XXXXXX