Attestation 仅保证 TEE 是可信的，执行正确的代码以及安全地处理数据。除了这种保证之外，用户还需要创建一个安全通道，以便与远程 TEE 进行可信通信。

理解 attestation，需要明白 sign, encrypt, certificate 的区别（之前有相关笔记）：

  • sign: 签名，使用私钥，不加密，表示数据是真实可信的（私钥背后的实体背书）；
  • certificate：签名，使用私钥，不加密，表示数据是真实可信的，数据是包含一把公钥的；
  • encrypt：加密，不解释。

所有 Intel PCS 相关的比如设备注册过程中用到的底层数据结构可以在这里找到：Intel® Provisioning Certification Service - Intel® SGX and Intel® TDX services - Production environment

QVL (Intel® TDX Quote Verification Library)

PCE (Provisioning Certification Enclave)

是一种特殊的 Enclave。

和 QE 一样，都是软件代码，可以直接下载的。You can download Intel’s architectural enclaves (the QE and the PCE) from Intel’s website.

DCAP_VERSION="1.6" # Replace with the most up-to-date version available.

INTEL_ENCLAVES_PATH="/opt/intel_enclaves/${DCAP_VERSION}"
mkdir -p "${INTEL_ENCLAVES_PATH}"

curl -SL "https://download.01.org/intel-sgx/sgx-dcap/${DCAP_VERSION}/linux/prebuilt_dcap_${DCAP_VERSION}.tar.gz" \
| tar -xvz --strip=5 -C "${INTEL_ENCLAVES_PATH}"

执行完上面代码后，在目录 /opt/intel_enclaves/1.6 下能看到有三个 so 文件：libsgx_pce.signed.so, libsgx_qe3.signed.so 和 libsgx_qve.signed.so。（qve 应该是为了 quoting verification 这部分的/）

Collateral Caching Service (CCS) / Collateral / Provisioning Certificate Caching Service (PCCS)

Collateral（附属担保品），PCCS 其实就是 CCS 的一种，用来 cache PCS，只不过是 Intel 提供的一个开源实现。

PCCS is a cache for PCS hold locally（云厂商自建的）. It retrieves PCK Certificates and other collaterals on-demand using the internet at runtime, and then caches them in local database.

The PCCS exposes similar HTTPS interfaces as PCS.

Infrastructure Setup - Intel® TDX Enabling Guide

Quoting Enclave

在 Intel SGX 中，"Quoting Enclave" 是一个特殊类型的 enclave，用于处理 SGX 的 remote attestation 过程。

Quoting Enclave 是由 SGX 平台的提供者（例如，Intel）部署的标准化且高度受信任的代码，因此不对外界暴露私钥，并提供安全的签名功能。Quoting Enclave 作为 Intel 提供的 SGX 软件堆栈的一部分进行部署，应用开发者无需自行部署。

SGX 和 TDX 可以各有一个 QE，互不干扰，并且 QE 不一定非要跑在 TD 中（只在 enclave 中就行）：

[!PDF|annotate] [[TDX Base.pdf#page=131&selection=46,0,93,14&color=annotate|TDX Base, p.131]] The Intel SGX attestation architecture is designed to provide facilities for multiple Quoting Enclaves from multiple providers. This is intended to allow the host to instantiate a Quoting Enclave for Intel SGX attestations and another Quoting Enclave for TD attestation without interference — i.e., each provider can supply its own quoting enclave, and the quoting enclave for Intel SGX and for Intel TDX may be separate; the design does not require the quoting enclave to5 run inside the TD.

为什么硬件不直接签名，而是使用一个 Quoting Enclave 在里面签名呢？这是因为基于证书链的签名方式能有效降低根密钥（Hardware Key）的使用次数，降低泄漏的风险。

![[TDX Base.pdf#page=25&rect=42,421,555,535&color=annotate TDX Base, p.25]]

关于 TD 的 Quoting Enclave：

A quote generation service (qgs) is a service that aids in the TD Quote Generation flow. The qgs has to run on the same host as the TD and it can run directly in the host or a dedicated VM. In particular, the qgs hosts the TD Quoting Enclave, which receives the TD Report from the TD, verifies that the TD Report was generated on the same host, and then signs the TD Report with a private key for which the trust is rooted in Intel. The signed TD Report is called a TD Quote. Note that the TD Quoting Enclave is an Intel SGX enclave and therefore, requires Intel SGX to be enabled on the platform.

Infrastructure Setup - Intel® TDX Enabling Guide

用户如何保证 QGS 所部署的 Quoting Enclave 不是恶意的？

  • 如何保证 QGS 里的代码不是恶意的？代码是开源的，用户可以检阅，Intel 提供一个参考实现，用户可以部署自己的代码；
  • 如何保证 QGS 是运行在 Enclave 里面，不会被外界攻击，没有泄漏风险的？TDVM 和 TDQE 之间可以做 local attestation，通过之后，TDQE 就自证了其真实性。

DCAP (Data Center Attestation Primitives)

可以理解为 Intel 发布的一套支持 remote attestation 的软件栈。

Measurement, Report, Claim, Evidence, Quote and Attestation

Measurement 一般叫做度量。通常指的是对系统状态或组件进行哈希计算，生成一个唯一的哈希值，用来表示该状态的完整性。可以对静态数据，也可以对动态数据进行度量，也就是所谓的动态度量和静态度量。

Report 一般叫做报告，将度量结果（Measurement）与其他上下文信息（如日志、时间戳）组合成一个结构化数据集合。仅汇总信息，未进行密码学验证。提供系统状态的完整快照，供本地或外部实体分析。对应到 TDX，就是 TDX 模块生成的原始数据，包含当前信任域的度量值（Measurement）和附加信息（如 TD 属性、CPU 安全版本号等）。通过 TDX 指令（如 TDG.MR.REPORT）生成本地报告（Local Report）。

Quote 是用 Attestation key 私钥签名过的 Report。这就加上了证书链作为背书，能够远程进行证明。

Attestation 通过密码学手段证明报告（Report）的真实性和完整性，向外部验证者确认系统状态可信。建立信任链，防止伪造或篡改。

Evidence 就是 TD attest 出来的内容，需要进一步被验证，通俗来讲，就是 TD Quote。

每一个 claim 都是从 evidence 里解析出来的字段，表示环境的状态。The evidence comprises a set of claims, later asserted or denied by the verifier. 所以能够看出来应该 evidence 是包含了一个 claim 的列表。

Local attestation 和 remote attestation 的区别

当两个 TEE 在同一台物理机上运行时使用 local attestation，当用户希望证明在远程物理机上运行的 TEE 时使用 remote attestation。

不管哪种 attestation，两者都不是对等的，一个是 claimer 一个是 verifier。

IRS (Intel® SGX and Intel® TDX Registration Service for Scalable Platforms) / Platform key / Platform registration

Infrastructure Setup - Intel® TDX Enabling Guide

要想 RA，要先提前将设备注册到 IRS。

A key piece of information required for this registration is the Platform Manifest (PM). The PM is a blob of data containing information about all CPUs in the system, including the shared platform keys which are negotiated between the available CPU packages in the platform. CPU 硬件密钥（私钥？）会加密这个密钥。然后 The contained shared platform keys are encrypted with the Registration Server's Encryption Key (RSEK), which is a public key.

Platform key 是平台上所有 CPU 一起协商出来的。

IRS 收到 Platform key 后，首先验证这是一个真的 Intel 平台（通过自己的私钥解开，收到 Platform key），然后基于这个 platform key 生成一个 Provisioning Certification Key Certificate (PCK Certificate).

Intel 相当于根 CA，会使用自己私钥给 PCK 证书签名， PCK 相当于二级代理， 给 QE 的 attestation public key 签名。

SGX Local attestation

作用是为了能让本地的两个应用之间进行通信，在此之前需要先互证。

本质上是利用了单台机器上共享一个编码在硬件层的密钥实现的，这样两端都可以利用这个相同的密钥进行加密和解密。在加上一些额外的机制，就能够实现两个 enclave 之间进行互证。但是由于远端没有写在 platform 上的密钥，因此只能将 report 发送到一个信任实体比如 Intel 来辅助进行验证（引入第三方）。

有以下指令（所有指令 Overview of Intel SGX - Part 1, SGX Internals - Quarkslab's blog）：

EREPORT: Create a cryptographic report, used by the enclave to generate a REPORT structure containing multiple informations about it and authenticated using the Report Key of the destination enclave. 只能在一个 enclave 当中被调用。

  • 第一个参数里包含 MRENCLAVE 的地址，这个 MRENCLAVE 是一个 measurement，但是不是这个 enclave 的，而是想要使用 EGETKEY 生成的 report key 来做验证的那个 enclave；
  • 第二个参数是用户自定义数据地址。比如可以加 DH 算法来在不安全信道协商密钥；
  • 第三个参数就是 report 数据要输出到的地址。
  • 注意 report 数据里包含了执行这个指令的 Enclave 的自己的 MRENCLAVE 数据，这是为了能让对端知道是谁发的，没有中间人劫持。
  • 这个函数还是会根据传过来的 MRENCLAVE 数据计算一个 report key，并用这个 key 为 report 计算一个 mac 并附上去。这个 key 的值 EREPORT 调用方不知道（因为这个指令根据 MRENCLAVE 直接计算出了 key，然后直接根据 key 计算出了 MAC 并附加在了 report 后面，并没有把 key 暴露出来），B 可以通过 EGETKEY 知道，B 能拿到自己的 key 的值是理所当然的，只要 B 不乱泄漏自己的 key。

EGETKEY: Create a cryptographic key. This instruction is used by an enclave to access the different keys provided by the platform. Each key enables a different operation (sealing, attesting). 两个 enclave 同时使用 EGETKEY 指令时。所有的实例将会返回相同的密钥值

有以下数据结构：

MRENCLAVE: Each enclave is represented by a hash of both its attributes and the position, content and protection of its pages. Two enclaves with the same hash are identical. This measure is called MRENCLAVE and is used to check the integrity of the enclave. 这应该是一个动态的度量值，不同时候的 MRENCLAVE 是不一样的。

Key Request: KEYREQUEST: used as an input to the EGETKEY instruction. It allows to choose which key to get.

Report Target Info: TARGETINFO: used as an input for the EREPORT instruction. It is used to identify which enclave (hash and attributes) will be able to verify the REPORT generated by the CPU.

Report: The REPORT structure is the output of the EREPORT instruction. It contains the enclave's attributes, measure, signer identity and some user data to share between the source and destination enclaves. The processor performs a MAC over this structure using the Report Key.

local attestation 流程：

  • There are two enclaves on the same platform, referred to as A and B. We assume they have established a communication path between each other, and the path doesn’t need to be trusted. we assume B is asking A to prove it’s running on the same platform as B as an enclave.
  • First, B retrieves its MRENCLAVE value and sends it to A. 这应该是明文。
  • A uses EREPORT instruction to produce a report for B using B’s MRENCLAVE. 同时 EREPORT 也会为 B 生成一个 report key（只有在 B enclave 内才能获得），并用这个 report key 生成一个 hash 值加到 report 里。Then A sends this report back to B. A can also include Diffie-Hellman Key Exchange（在不安全网络建立共享对称密钥的方法）data in the REPORT as user data for trusted channel creation in the future. 这一步还是明文，因为 MAC^ 仅仅保证完整性和自证性。
  • After B receives the REPORT from A, B calls EGETKEY instruction to get REPORT KEY to verify the REPORT. If the REPORT can be verified with the REPORT KEY, then B assures that A is on the same platform as B because the REPORT KEY is specific to the platform.
  • Then B use the MRENCLAVE received from A’s REPORT to create another REPORT for A and sends the REPORT to A.
  • A then also can do the same as step 4 to verity B is on the same platform as A（A 和 B 能够互相验证在相同的平台上）.
  • By utilizing the user data field of the REPORT, A and B can create a secure channel using Diffie-Hellman Key Exchange. Information exchange can be encrypted by the shared symmetric key.

攻击场景一：如果中间人 Enclave C 劫持了 B 的请求，使用 EREPORT 给 B 生成了 report key。并把 report 发回给了 B。B 拿到自己的 report key hash 之后发现值一样，那么 B 这里就证明了 C 是一个 enclave，但是其实 B 想要证明的是 A。

不会有问题，因为 A 发来的 report 包含了 A 自己的 MRENCLAVE 信息。B 根据这个信息就知道发来的是 C 而不是 A。

TDX Attestation

Quote 或 Report 里的信息有哪些？

软件信息，大体上分为两部分，即静态度量部分和动态度量部分。

  • 寄存器（说是寄存器，其实在 TDCS 里面，是内存空间） TDCS.MRTD，含有静态度量信息，SHA384 Digest。
    • TDH.MEM.PAGE.ADD（注意在 build time 才能调，runtime 只能调 AUG）inserts its properties (GPA) into the MRTD digest calculation.
    • Control structure pages (TDR, TDCX and TDVPR) and Secure EPT pages are NOT measured.
    • TDH.MR.EXTEND 可以用来手动加入那些对 TD 有贡献的页的信息进去（比如 TD-Shim 这种 Virtual Firmware 的页信息，这样是不是有助于增加对于 TD Shim attestation 的验证）。
    • TDH.MR.FINALIZE 表示静态度量完成。
  • 寄存器（同上） RTMR，含有动态度量信息，通过 TDCALL TDG.MR.RTMR.EXTEND 来进行 extend。
    • build 阶段初始化为 0；
    • Guest 可以调用 TDCALL (TDG.MR.RTMR.EXTEND) 来动态往里面加页。也是以 RTMR[i] = SHA384(RTMR[i] || x) 这种方式进行滚动更新的；
    • 有四个 RTMR 寄存器。

TDX Local Attestation

整体流程请看这一章节：

[!PDF|annotate] [[TDX Base.pdf#page=130&selection=88,0,90,25&color=annotate|TDX Base, p.130]] 12.4. Local Report Verification

![[TDX Base.pdf#page=130&rect=51,382,543,712&color=annotate TDX Base, p.130]]

第一步：TD attestation is initiated from inside the TD by calling TDG.MR.REPORT and specifying a REPORTDATA value.

第二步：TDG.MR.REPORT creates a TDREPORT_STRUCT structure:

![[TDX Base.pdf#page=129&rect=51,388,543,560&color=annotate TDX Base, p.129]]

TDREPORT_STRUCT is HMAC’ed using an HMAC（一种 MAC，只保护完整性、签名性）key that is designed to be accessible only to the CPU. by design, it can only be verified on the local platform via the TDG.MR.VERIFYREPORT interface function or the SGX ENCLU(EVERIFYREPORT2) instruction. By design, TDREPORT_STRUCT cannot be verified off platform，这是因为这个用来 HMAC 的对称密钥只有这个 platform 有，所以其他方无法验证。

Local attestation 直接用 Report 就可以了，不需要转换成为 Quote。

Local verification 就是通过相同的加密 HMAC key 来验证，通过上面提到指令。

TDX Remote Attestation

Intel TDX remote attestation flow is based on a remote attestation flow originally designed for Intel SGX and was enhanced to also support Intel TDX.

作为一个用户，在某个 CSP 厂商开了一台 TDVM 虚拟机，首先我们应该验证我们买的环境确实是基于 TDX 硬件，而不是 CSP 厂商模拟给我们的。

Intel 在芯片出厂时，会为每一个 CPU 内部电路嵌入一个私钥，同时 Intel 维护一个数据库 PCS（Provisioning Certification Service），存储着每个私钥对应的公钥。这个数据库服务以公开的方式允许用户查询。远程证明时，位于 TD 内的 userspace 程序可以调用 guest kernel 提供的接口，获取一个叫做远程证明 Quote 的数据结构。该数据结构包含了当前 Guest 的软硬件信息，且整体会被位于 CPU 内的私钥签名。然后，程序可以把这个 Quote 发送给远端的验证者。验证者通过访问 PCS 找到该签名对应的公钥（若存在），然后进行解密拿到，就可以确认该硬件是不是 Intel 生产的，进而确定它具有 TDX 声称的机密性。

但是这些足够吗？即使知道了当前 Guest 执行环境确实是 TDVM 虚拟机，仍然不能保证用户的数据不被窃取，原因是当前 VM 内还运行着一些非常容易被忽视的软件栈，即用以支持虚拟机运行的 Guest 固件、Guest Kernel 等底层软件。如果这些软件存在 CSP 植入的后门，就依然能够窃取用户的数据。

Keys for TD Remote Attestation / Attestation Key

所有的 Key 可以参考：Platform Registration | Confidential Computing 101

原理基于证书链（注意 sign 的目的是为了保证所关联信息的真实性）：

  • Intel（Intel 自己所持有的，注意和硬件 key 不一样） sign 保证了 PCK 公钥的真实性；
  • PCK（PCE 所持有的） sign 保证了 Attestation key 公钥的真实性；
  • Attestation key（QE 所持有的） sign 保证了 Quote 内容的真实性。

那么我们就要关注 Attestation key, PCK 的私钥是怎么得出的了。

![[Intel TDX Demystified- A Top-Down Approach.pdf#page=26&rect=99,563,389,647&color=annotate Intel TDX Demystified- A Top-Down Approach, p.26]]

这其实是一个数字签名链，也是一个信任链，Intel 保证了 PCE 的真实性，PCE 保证了 Enclave 的真实性。因为 Intel 是被信任根，需要用户无条件信任 Intel，也就意味着如果 Intel 存心想攻击，也无法防范。

TDX Remote Attestation 流程

到生成 TDREPORT_STRUCT 这里，和 TDX Local Attestation^ 流程类似。

Remote Attestation 需要把 TDREPORT_STRUCT 转化成为一个 Quote，通过 TD Quoting Enclave 使用 Attestation key（一个非对称密钥）签名的方式（并不是加密）。Remote Attestation 分成两步，中间的分界线是 Quote 文件。TD Quote Generation and TD Quote Verification are two completely independent steps. TD Quote Generation is always done by the platform a TD is running on, but TD Quote Verification can be done by any party at an arbitrary location. 除了这两步，还需要做一些准备工作，也就是 platform registration 过程，因此，整个 remote attestation 流程可以分为三步：

  • Platform registration（一般在请求 attestation 之前就已经做好了）
  • Quote generation
  • Quote verification

我们一步一步来看。 先来看第一步，设备注册流程：

![[platform_registration.excalidraw]]

注意在设备注册时，platform key 可以发送给 Intel registration service，也可以自己生成 PCK 而不发送，这取决于是 direct 还是 indirect 的注册方式。设备注册的关键成果在于得到 PCK Certificate，能够验证 PCK 的真实性。

来看第二步，TD Quote Generation 流程：

先看 quote setup 阶段，这一步主要是为了生成 attestation key pair 并 certify it。可以看到 Attestation key certificate 其实是放在 QE 里面的。Attestation key certification 这一步可以在 platform registration 这一步发生，也可以在 quote generation 这一步发生，这里以后者为例进行流程阐述。

![[Intel_TDX_DCAP_Quoting_Library_API.pdf#page=8&rect=70,198,541,424&color=annotate Intel_TDX_DCAP_Quoting_Library_API, p.8]]
![[TDX Base.pdf#page=131&rect=44,217,550,698&color=annotate TDX Base, p.131]]

注意下图里的 EVERIFYREPORT 指令，这个表示了 remote attestation 之前需要先在 QE 和 TD 之间做 local attestation，所以 remote 是依赖于 local 的。

在 TDQE 生成 TD Quote 的时候，它自己的 TDQE Report 的内容也会被放在里面 [[Intel_TDX_DCAP_Quoting_Library_API.pdf#page=57&selection=63,0,65,28&color=annotate Intel_TDX_DCAP_Quoting_Library_API, p.57]]，因为 TDQE 会把自己的 Attestation Key Certificate (PCK signed) 放到 TDQE Report 里面，因此可以说 TD Quote 里面其实已经包含了 Attestation Key Certificate。

Quote generation 阶段，PCE 不是必须运行的，只要 Attestation Key Certificate 已经生成并返回 TDQE 之后，就可以了（因为 PCK Certificate 已经被 Intel PCS 公开了，所以不需要 PCE 也运行了）。

![[attestation.png]]

第三步，TD Quote Verification 流程：

直接根据根证书一步步验下去就可以了。Quote 里应该包含整个证书链的信息。可以看下整个 Quote 的格式： [[Intel_TDX_DCAP_Quoting_Library_API.pdf#page=48&selection=26,0,38,5&color=annotate Intel_TDX_DCAP_Quoting_Library_API, p.48]]
  • Quote 里包含的 Attestation key certificate 信息：[[Intel_TDX_DCAP_Quoting_Library_API.pdf#page=57&selection=63,0,65,28&color=annotate Intel_TDX_DCAP_Quoting_Library_API, p.57]]

大致验证步骤：

  • Verifier 拿到了一个 TD Quote；
  • Verifier 从 Intel 这里拿到 PCK Certificate，用 Intel 自己的公钥验证签名内容真实性，得到真实的 PCK 公钥；
  • 使用 PCK 公钥验证拿到的 TD Quote 里 Attestation Key Certificate 字段的真实性，从而得到 attestation public key；
  • 使用 attestation public key 验证 quote 内容的真实性；
  • 检查 quote 内容是否满足我们的要求。

Quote 生成后最好马上发给 challenger 做验证，时间长了说服力就下降了。因为 [[#Remote attestation 过程中 Challenger 如果收到的 Quote 是中间人发送的另一个 TD 的 Quote，怎么解决？/ Nouce]]，如果 offline 也就是等了很久才验证，那么只能证明这个 Quote 所声称的内容是对的，但是不能把它和正在通信的这个会话的通信方联系到一起。

Remote attestation 过程中 Challenger 如果收到的 Quote 是中间人发送的另一个 TD 的 Quote，怎么解决？/ Nonce

如果一个中间人劫持了原来的 attestation request，然后发送了一个另外一个 CVM 的 quote 过来，challenger 拿来验证了一下通过了，就相信了和它通信的实例运行在 TD 中，其实已经被 TD 劫持了，后面的请求都转发给了一个非 TD 的服务，这种攻击怎么进行防御？

握手时 challenger 会随机产生一个 nonce 作为挑战值发给 TD，然后 TD 在请求生成 Quote 的时候，会把 nonce 也发给生成 Quote 的逻辑，在最底层，生成 Quote 的硬件逻辑会把挑战值也放到 Quote 里，最后对 Quote 做个硬件签名，把挑战值也一起保护起来。所以 Quote 即便泄露了，但如果攻击者不能劫持当时那个会话，那重放这个泄露的 Quote，也无法发起二次攻击，因为 challenger 不会认同一个和他随机生成的 nonce 挑战值不同的 Quote 的。

TD Quote 里能够对外声明哪些内容是可信的？

TDX Remote Attestation Use Cases

两个不同平台上的 TD 做热迁移的时候，两方的 MigTD 需要做 mutual remote attestation 以验证对端 MigTD 的真实性。

TDX Remote Attestation 实践

Intel 官方给的如何做 Remote Attestation 的指南：Introduction - Intel® TDX Enabling Guide