第3章
机密计算模型

在第2章中，我们介绍了机密计算的基础概念。在本章中，将详细介绍机密计算的通用模型。

3.1 机密计算安全模型

简单地说，机密计算用于保护使用中的数据。机密计算联盟在“机密计算技术分析”（A Technical Analysis of Confidential Computing）白皮书中给出了更严格的目标定义：机密计算的目的是“ 最大限度地减少系统平台的所有者/管理者/攻击者访问TEE中数据和代码的能力，使得攻击运行程序这条路径在经济上或逻辑上不可行 ”。这句话有点拗口，也有点复杂。前半句的重点是，除了TEE的使用者， 其他系统平台人员都不应该拥有运行时访问TEE中数据和代码的能力 。这和我们以往的经验不同，在机密计算出现之前，系统平台管理员（例如root用户）往往拥有至高无上的权利，可以修改用户权限、访问用户数据等。后半句则阐明了局限性，强调攻击在 经济上或逻辑上不可行 。我们知道，没有绝对的安全。在密码学中，根据香农（Shannon）的观点，只有一次一密（One Time Pad）在理论上是绝对安全的，现有的密码体系都是建立在计算性安全（Computational Security）上的。这意味着：1）如果攻击者拥有无限的资源（时间或计算能力），那么就有可能打破机密计算的保护；但是如果破坏方案需要的资源要比打破保护获得的收益更大，那么现有的方案还是安全的。2）攻击者虽然可能有非常小的概率获得成功，但是这个概率小到可以忽略，那么就不必担心了。

就可用性（Usability）和代价（Cost）而言，相比其他方案，TEE方案显著提高了保护使用中的数据的能力，这就可以让涉及敏感数据的软件设计者/实现者/操作者能够专注于系统的其他方面。

尽管机密计算本身只关注运行中的数据安全，但对于一个系统方案来说，存储中和传输中的数据安全同样重要。例如，我们需要考虑以下几点：

TEE的本地或远程证明：使用者需要确保TEE是被管理者正确地启动的。

TEE中工作负载和数据的传输：使用者需要确保工作负载和数据是被安全地传输到TEE的，机密性和完整性没有受到破坏。

与TEE相关的数据在非TEE的非易失存储介质（Non-Volatile Storage，NVS）中的存储：使用者需要确保这些TEE相关数据的机密性和完整性，还要避免数据的重放攻击（Replay Attack）。

在TEE之间工作负载和数据的迁移：使用者需要制定安全策略来表明什么样的TEE可以迁移，什么样的TEE无法迁移。

3.1.1 机密计算的通用架构模型

图3-1展示了一个基于TEE的机密计算通用架构模型。我们用白色框表示TEE可信计算基（Trusted Computing Base，TCB），浅灰色框表示TEE自身，深灰色框表示不可信的模块。

首先，系统的CPU和内存控制器必须是可信的，因为它们是进行计算的基础，必须是TEE TCB的一部分。DRAM可以是不可信的，因为MC可以自带内存加密引擎（MEE）并把加密的内容存储到DRAM中。Gueron在2016年的论文“A memory encryption engine suitable for general purpose processors”中介绍了通用MEE的设计以及安全模型，MEE的安全目标有：

DRAM数据的机密性。

DRAM数据的完整性，并能抵御重放攻击，保证从DRAM上读取的数据就是最近一次写入的数据。

MEE需要满足以下安全特性：

MEE密钥需要在启动阶段均匀随机地生成，并且不离开芯片内部。

MEE加密密钥和认证密钥需要分开，分别对应机密性和完整性。

MEE完整性验证需要遵循“放弃和锁定”（Drop-and-Lock）策略。MEE需要在读操作时计算MAC值，然后和完整性树中的期待值进行比较，如果一致则继续。但是，MEE一旦发现有不一致之处，就需要立刻发出失败信号，放弃当前事务（Transaction），并且锁定内存控制器，使得之后的事务也一同失败。这时的MC处于死机状态，只能由重启恢复。

其次，TEE可有一个或多个，这取决于系统架构的实现。如果存在多个TEE，那么这些TEE之间必须是隔离的。一个TEE的安全不应该依赖于其他TEE，因为当存在多个TEE的时候，攻击者可能会启动一个恶意TEE作为同谋。

再次，为了方便管理多个TEE，系统可以有一个TEE安全管理器（TEE Security Manager，TSM）。TSM可以是CPU SoC扩展硬件的一部分，也可以是一个或多个独立运行的软件。TSM要负责管理所有TEE和TEE的元数据（Metadata），例如TEE上下文（Context）。TSM也是TEE-TCB的一部分。TSM和包括TEE的其他任何模块都必须是隔离的。

最后，系统中的其他模块都是不可信的，包括资源管理器（Resource Manager）和被资源管理器管理的其他非TEE部分。这里，如果TEE是个用户态的安全飞地，那么资源管理器就是操作系统，非TEE则是其他应用程序。如果TEE是机密虚拟机，那么资源管理器就是VMM，非TEE则是普通虚拟机。

这种架构中的软硬件模块分为三类： TEE-TCB、TEE 和 不信任模块， 它们之间的关系如图3-2所示。

信任关系 ：系统各个TEE-TCB之间的信任关系由系统架构决定；TEE可以信任所有TEE-TCB，但是多个TEE之间不能互相信任。

保护关系 ：TEE-TCB必须保护自己不被任何TEE和不信任模块攻击；TEE-TCB必须保护每个TEE及其TEE元数据不被其他TEE和不信任模块攻击；TEE必须保护自己不被其他TEE和不信任模块攻击；如果TEE有认证的启动能力，TEE-TCB负责进行启动时的认证。

证明关系 ：TEE-TCB作为度量可信根（Root-of-Trust for Measurement，RTM），必须支持为TEE建立度量可信链，为了方便细粒度的度量，TEE-TCB可以支持TEE运行时度量；TEE-TCB作为存储可信根（Root-of-Trust for Storage，RTS），必须为TEE提供受保护的度量存储空间，TEE的度量可以作为TEE的元数据的一部分；TEE-TCB作为报告可信根（Root-of-Trust for Report，RTR），必须支持报告所有TEE-TCB模块和每个独立TEE的度量作为证据。为了协助远程证明，TEE-TCB可以包括一个或多个证明TCB（Attestation-TCB）模块，作为RTR的一部分。

下面再讨论一下这种架构中的一些重要模块的角色和责任。

资源管理器 是TEE的 管理者 ，负责管理和协调所有的TEE，包括TEE的启动和关闭、CPU和内存配置、调度运行等。资源管理器需要通知TSM对TSM的配置。

TSM 是TEE 安全策略实施者 ，负责保护TEE的资源不被其他模块攻击，并且锁定资源管理器对TEE的配置。

TEE 内部有一个 决策者 ，它根据策略做出决策。例如，决策者需要决定是否接受资源管理器对TEE的配置。

3.1.2 关于TEE的权限问题

可用性通常不是机密计算需要考虑的问题，原因是系统的资源管理器负责管理整个系统资源，TEE只是其中的一部分。虽然不能访问TEE，但是资源管理器有权启动或关闭TEE。因此， TEE的可用性是不必考虑的 。

但是，从整个平台来说，我们需要考虑 系统的可用性 ，即资源管理器的可用性。和非机密计算的传统威胁模型类似，这时的攻击者是TEE，而系统资源管理器需要保护自己。这时有以下几种关系：

信任关系 ：我们认为资源管理器可以信任TEE-TCB，理由是TEE-TCB通常拥有很高的权限，也是平台的TCB，例如CPU SoC。但是，资源管理器不能信任任何TEE。

保护关系 ：资源管理器需要保护自己不被TEE攻击。资源管理器不需要保护TEE-TCB或者其他TEE，因为在机密计算模型下，资源管理器是不可信的。

证明关系 ：资源管理器不需要证明能力，因为它是不可信的。

这里我们单独讨论 可用性 ，目的是说明机密计算TEE的权限问题。广义上说，只要是一个独立可信的执行环境，都可以称为TEE。TEE可以有最高的系统权限，会影响系统可用性；也可以有最小的系统权限，只保护一小部分用户态应用程序。例如，Intel早在386SL处理器中就提出了系统管理模式（System Management Mode，SMM），如图3-3所示。但是，SMM具有最高的系统优先级，甚至可以超过VMM，那么把SMM作为通用TEE就不是一个合适的选择。同样，ARM在ARMv6KZ引入的TrustZone就是一个创建安全世界（Secure World）TEE的安全技术，如图3-4所示。其中，监视器模式（Monitor-mode）的TrustZone监视器软件具有最高的权限，这就意味着，如果把这类TEE作为机密计算TEE，就赋予了这个执行环境所不需要的权限，违反了Saltzer和Schroeder早在1975年发表的“The protection of information in computer systems”中提出的计算机安全保护的最小权限（Least Privilege）原则。Smith在2012年的文章“A contemporary look at Saltzer and Schroeder's 1975 design principles”中重新审视了这些设计原则，最小权限原则依然重要。因此，这不是机密计算TEE最佳的选择。

3.1.3 关于TEE-TCB的范围问题

可信计算基（TCB）不是一个全新的概念。Lampson、Abadi、Burrows和Wobber在1992年的论文“Authentication in distributed systems:theory and practice”中把TCB定义为“ 我们区分出来的安全所依赖的一小部分计算机软件和硬件，使得其他大部分模块就算失灵也不会影响安全 ”。美国国防部（Department of Defense，DoD）在1983年发布的DOD 5200.28“可信计算机系统评估标准”（Trusted Computer System Evaluation Criteria）橘皮书中定义了各种安全级别下TCB的角色和责任。美国国家标准与技术研究院（National Institute of Standards and Technology，NIST）对TCB的定义是“ 一个计算机系统里的所有保护机制的总体集合，包括硬件、固件和软件。它们负责强制执行安全策略 ”。TCB对系统安全的重要性显而易见，TCB保护系统安全的前提是保护TCB自身的安全。因此，系统设计者往往会将大量精力花费在设计和实现TCB上。为了降低开销和潜在风险，业内公认TCB应该越小越好。MINIX的设计者Tanenbaum在和Linus Torvalds的辩论中把操作系统的可靠性放在第一位，认为可以“ 把操作系统的大部分功能移到一系列用户进程当中，由每个功能驱动一个用户进程，再提供一系列的系统服务。这么做不会减少代码中bug的数量，但是会大大减少每个潜在的bug带来的危害， 减少了可信基的大小 ” 。

在系统设计的初期，操作系统在某种程度上扮演了TCB的角色，它负责隔离和保护每个用户进程，是每个用户进程的TCB。随着虚拟化技术的诞生，用户进程安全的依赖更加复杂，自底向上涉及以下模块：

系统级芯片 （SoC）：CPU、内存管理器，包括系统硬件补丁，如CPU微码（Microcode）。由芯片厂商提供。

平台外设 （Platform Peripheral）：内存条，由内存设备厂商提供。

系统固件 （System Firmware）：基本输入/输出系统（Basic Input/Output System，BIOS）或统一可扩展固件接口（Unified Extensible Firmware Interface，UEFI）固件。由原始设备制造商（Original Equipment Manufacturer，OEM）提供。

虚拟机管理器 ：如Linux Kernel-based Virtual Machine（KVM）、Windows Hyper-V等，由VMM厂商提供。

操作系统 ：如Linux系统、Windows系统，由操作系统厂商提供。

为了解决可信问题，TCG提出了TPM和可信启动规范，例如，平台固件配置规范（Platform Firmware Profile，PFP）描述的基于静态度量可信根（Static Root-of-Trust for Measurement，SRTM）的可信启动，如图3-5a所示。我国也发布了和TPM类似的可信密码模块（Trusted Cryptography Module，TCM），支持SRTM形式的启动。SRTM是成熟的技术，市场上现有的系统（例如Linux和Windows）都支持基于SRTM的可信启动。但为了确保一个用户态的应用程序是可信的，验证者需要检查所有系统组件的度量值，包括硬件补丁、系统固件、虚拟机管理器、操作系统等。由于不同的组件来自不同的厂商，信任链的建立非常复杂。而且，由这些组件构成的TCB非常庞大，这些组件中只要有一个出现问题，安全性就无法保证。其中，威胁最大的要数系统固件，由于系统固件的SMM代码具有最高权限，因此一旦系统固件存在安全漏洞，就需要重新刷机，重装系统。

之后，TCG又提出了基于动态可信度量根（Dynamic Root-of-Trust for Measurement，DRTM）的可信启动，如图3-5b所示。在系统硬件厂商的DRTM配置环境（DRTM Configuration Environment，DCE）的帮助下，一个动态启动度量环境（Dynamic Launched Measured Environment，DLME）可以不需要信任系统固件而随时创建一个动态的可信度量根。这个设计把OEM系统固件排除在TCB之外，消除了系统固件带来的安全风险。目前，Intel的可信执行技术（Trusted Execution Technology，TXT）和AMD的安全虚拟机（Secure Virtual Machine，SVM）都是支持DRTM技术的硬件实现。Microsoft推出的Windows 11 Secure Core PC中的系统保护安全启动和SMM保护（System Guard Secure Launch and SMM protection）就是利用基于DRTM的可信启动完成的。相比SRTM，DRTM是一个进步，但DRTM的实现还是把整个VMM加入TCB作为可信链的一部分。对于机密计算TEE来说，TCB还是不够精简。另外，在云环境下，VMM通常是由云服务提供商（Cloud Service Provider，CSP）提供的。而VM的租户（Tenant）可能只希望使用CSP提供的CPU算力，但不希望信任CSP或把自己的数据暴露给CSP。这些需求是DRTM无法满足的。

因此，在机密计算TEE的安全模型中，我们直接把VMM的系统资源管理器排除在TCB之外，最大程度地减少了TCB的大小。最理想的情况是，只有芯片厂商提供的硬件、固件和软件模块构成TEE的TCB，那么TEE的使用者只需要信任芯片厂商就可以了，从而大大减少了TCB内组件出现问题的风险。通常认为，通用机密计算信任模型中的SoC和TSM是属于TEE-TCB的，而且TEE-TCB可能包含更多的模块，具体的设计和TEE硬件设计相关。

图3-6总结了可信计算和各种机密计算TEE架构。左边是之前介绍的可信计算架构，包括基于静态可信根和动态可信根两种。中间部分是基于x86架构的机密计算方案，包括安全飞地和机密虚拟机。这类方案的特点是把复杂的系统固件和VMM排除在TCB之外。注意，这里包括了一个子类—嵌套的机密虚拟机，指的是在一个机密虚拟机内部再启动一个轻量级的L1 VMM来支持未修改的OS。例如，Intel TDX的TD分区（TD Partitioning）和AMD SEV的VM特权级别（VM Privilege Level，VMPL）都可以认为是嵌套方案。一个有趣的现象是，x86机密计算的TCB一开始在SGX方案中将所有特权级组件（例如操作系统）排除在外，但是人们发现，这样做的话必须要修改现有的系统应用，所以又逐渐添加新的TCB模块支持已有系统，保持兼容性。可以看出，系统设计的难点不仅仅在于安全性，还包括整个生态系统的支持。为了使产品可用，有时候架构师不得不在安全性和可用性之间进行权衡。右边的部分是基于ARM和RISC-V架构的机密计算方案，包括早期提出的隔离TEE环境和目前的机密虚拟机。和x86架构的方案不同，ARM和RISC-V系统存在一个最高权限的监视器，用来切换包括VMM之内的各个不同世界，并提供服务，这个监视器一直是系统的TEE-TCB。

3.1.4 关于RoT的问题

我们在讨论TCB的时候提到了可信根（RoT），这里详细讨论一下它的概念，因为之后我们会用到这个概念。根据NIST的定义，可信根是“ 一些高可靠的硬件、固件和软件模块，它们负责执行特定的，重要的安全功能。因为可信根是天然可信的，它们必须通过设计保证安全 （Secure by Design）。 可信根为构建安全和信任提供坚实的基础 ”。可信根位于TCB之内，但在TCB内部，不一定所有模块都是可信根，因为可信根可以通过建立信任链（Chain of Trust，CoT）来一步步扩展可信的范围。

一般来说，可以从两个维度来看可信根：

可信根的位置 ：例如，平台可信根（Platform RoT，P-RoT）负责平台启动，芯片可信根（Silicon RoT）负责CPU SoC内部启动，主动设备可信根（Active Component RoT，AC-RoT）负责设备启动等。

可信根的功能 ：例如，可信启动中的度量可信根（RTM）、存储可信根（RTS）和报告可信根（RTR）；安全启动和平台固件弹性恢复中的检测可信根（RTD）、升级可信根（RTU）和恢复可信根（RTRec）。

机密计算TEE-TCB通常由芯片可信根负责可信启动，并且引入RTM、RTS和RTR来辅助TEE的远程证明。如果TEE-TCB的固件和软件提供升级和恢复功能，那么TEE-TCB会引入RTD，RTU和RTRec。我们会在之后的内容中详细介绍这些可信根的设计。

如果系统需要支持机密设备加速器，那么系统还需要主动设备组件可信根来负责机密设备的启动并提供设备的远程证明。我们会在第三部分介绍。

3.2 机密计算的威胁模型

本节的介绍依然参考机密计算联盟在“机密计算技术分析”白皮书中给出的通用威胁模型。需要注意的是，具体到一个特定的机密计算实现，不同厂商、不同代的产品会有不同的威胁模型。

3.2.1 需要考虑的威胁

机密计算的主要目标是保障TEE的机密性和完整性。机密计算需要考虑的威胁主要有以下类型：

软件攻击 ：这里的软件可以是系统平台上的任意软件或是固件。例如，虚拟机管理器、操作系统、任何非TEE程序、其他TEE程序、系统固件（也称为BIOS）、不可信的设备固件（如网卡固件、硬盘固件、显卡固件、键盘固件等）。TEE需要抵御对这些软件的直接访问攻击。

协议攻击 ：这里的协议指的是TEE和其他非TEE交换数据时使用的安全协议，通常需要引入密码学方案来保护它们。例如，TEE和第三方验证者交互进行远程证明，TEE利用认证的密钥交换协议（Authenticated Key Exchange Protocol）安全地导入工作负载和数据。

密码学攻击 ：TEE通常需要引入密码学方案来保护数据。需要注意的是，密码学在不停地演进。一方面是密码算法的进步，随着量子计算时代的到来，现在的RSA、DH、椭圆曲线（ECC）等算法将会被新的抗量子密码算法（Post-Quantum Cryptography，PQC）取代。NIST公布了一系列抗量子密码算法，例如基于模格的密钥封装机制（Module Lattice based Key-Encapsulation Mechanism，ML-KEM）、基于模格的数字签名算法（Module Lattice-based Digital Signature Algorithm，ML-DSA）、基于无状态哈希的数字签名算法（Stateless Hash-based Digital Signature Algorithm，SLH-DSA）以及两种基于有状态哈希的数字签名算法（Stateful Hash-base Signature）。另一方面是密钥长度的变化，在量子计算时代，128位AES加密算法必须升级为256位AES，256位SHA算法必须升级为384位SHA。NSA的商用国家安全算法套件（Commercial National Security Algorithm Suite，CNSA）2.0规定了传统密码向PQC密码迁移的时间线：大约2025年之后开始迁移工作，2030～2033年完成PQC的部署。TEE固件的设计需要考虑密码的灵活性来为以后的升级做好准备。

简单物理攻击 ：虽然针对CPU的攻击在考虑范围之外，但是机密计算需要考虑针对其他物理外设的攻击，包括冷DRAM读取（Cold DRAM Extraction）、总线监听（Bus Monitoring）、缓存监听（Cache Monitoring）和设备（例如PCI Express设备、USB设备等）拔插。

简单上游供应链攻击 （Basic Upstream Supply-Chain Attack）：虽然对于TEE组件供应链的攻击在范围外，但是也需要考虑简单的全局的攻击，例如给系统添加调试端口等。

这里，由于简单物理攻击包括DRAM线下读取，那么运行时内存加密就变成必要的条件。仅仅依靠TEE隔离无法抵御DRAM线下读取。

另外，机密计算联盟的威胁模型还特意指出了一些灰色地带，例如 完整性检查、 回滚攻击以及各类基于软件硬件的重放攻击等。完全防范这些威胁需要进行大量的硬件设计改动。因此，CCC让厂商根据用例自行考虑。

3.2.2 不需要考虑的威胁

机密计算通常不考虑以下类型的威胁：

复杂物理攻击 ：例如，进行芯片剖片（Chip Scraping）或者电镜探测（Electron Microscope Probe）。

上游硬件供应链攻击 ：例如，在芯片制成时注入木马。

可用性攻击 / 拒绝服务攻击 ：通常情况下，TEE不是整个系统的管理者。安全飞地的管理者是操作系统，机密虚拟机的管理者是虚拟机管理器。TEE与外界联系时必须要通过不安全的操作系统或VMM，而操作系统或VMM可以忽略TEE发出的联系请求。因此，通用TEE不可能防止可用性攻击/拒绝服务攻击。

3.2.3 侧信道攻击与防范

虽然TEE硬件为机密计算提供了数据机密性方面的保护，但是TEE软件设计的漏洞可能会暴露机密数据。除了常见的缓冲区溢出外，近年来最引人注目的要属于侧信道（Side Channel）攻击，例如Spectre和Meltdown。机密计算TEE设计的初衷就是解决运行时的数据安全问题，例如，用户可以把密钥部署在TEE中，而不用担心密钥在使用过程中被泄露；用户可以把具有知识产权的代码部署在TEE中运行，而不用担心这个私有模块代码被其他进程窃取。对于这两种情况，侧信道攻击可以有两个方向：

恢复TEE中任意内存信息 ：这是和密码学无关的通用侧信道攻击，完全破解了TEE的机密性。

恢复TEE中的密码学密钥 ：这是针对密钥运算的侧信道攻击，包括对称密钥的恢复和非对称密钥系统中私钥的恢复，它和各类密码学算法紧密相关。常用的攻击方法有缓存侧信道（Cache Side Channel）、时长侧信道（Timing Side Channel）、功耗侧信道（Power Side Channel）等，还有故障注入（如电压或电磁攻击）。

我们将在第8章详细介绍各种通用侧信道攻击。

3.3 机密计算TEE实例的威胁模型

下面我们来看一看各类典型的机密计算TEE实例的威胁模型。

3.3.1 Intel SGX的威胁模型

Intel的SGX是Intel提出的最早的机密计算方案。用户可以把一个应用程序拆分成可信和不可信两部分，可信的部分在一个SGX用户态Ring-3的Enclave中执行，使用SGX保护它的机密性和完整性，如图3-7所示。一个Enclave相当于一个机密计算TEE。每个Enclave和非Enclave以及其他Enclave都是隔离的。Intel SGX没有软件TSM，TSM的功能由CPU Microcode完成。SGX实现了Enclave中代码和数据的隔离，并且使用内存加密引擎来保障内存数据的机密性、完整性，以及时新性（Freshness）。但是，Intel SGX硬件本身并不能抵御侧信道攻击。

Intel从2013年开始介绍SGX的相关信息，例如发表了论文“Innovative instructions and software model for isolated execution”和“Innovative technology for CPU based attestation and sealing”。Costan等研究了SGX，并且在2016年发表论文“Intel SGX Explained”，2017年发表论文“Secure processors part I: background，taxonomy for secure enclaves and intel SGX architecture”和“Secure processors part Ⅱ: Intel SGX security analysis and MIT Sanctum architecture”，详细描述了Intel SGX的设计、实现，以及安全特性。下面总结一些Intel SGX考虑的威胁。

物理攻击 ：SGX假设DRAM和DRAM总线是不可信的。因此，SGX使用内存加密引擎来保护内存数据。但是， SGX不考虑侧信道功耗分析攻击 。

特权软件攻击 ：SGX认为所有系统软件都是不可信的，包括VMM、操作系统、BIOS等。第一，SGX实现使用特殊的Enclave Page Cache（EPC）存储Enclave的控制结构（SGX Enclave Control Structure，SECS）、代码和数据，以及线程控制结构（Thread Control Structure，TCS）。而EPC位于受保护的内存中，其他软件无法直接访问。第二，Enclave需要和其他软件（非Enclave或其他Enclave）进行交互，SGX的CPU微码会在Enclave退出时保存当时的执行状态，在Enclave进入时重新加载执行状态。当产生硬件中断触发异步Enclave退出（Asynchronous Enclave Exit，AEX）时，Enclave内的寄存器状态会被保存到Enclave特有的状态存储区（State Save Area，SSA），其他系统软件无法访问Enclave的保存状态，如图3-8所示。

内存映射攻击 ：SGX使用独立的Enclave页缓冲映射（Enclave Page Cache Map，EPCM）在Enclave的虚拟地址空间中存储EPC页表信息及其类型。在CPU地址翻译过程中，Enclave不允许访问的地址在到达页表TLB之前就被EPCM直接禁止。SGX允许系统软件把EPC页驱逐（Evict）到DRAM，同时SGX通过密码学方案来保护这个EPC页的数据及其相关的EPCM元数据。

对于外设的软件攻击 ：SGX只信任CPU片上系统内部组件，包括内存控制器。SGX不信任任何外设，例如外部PCI Express总线、DRAM等。SGX通过内存加密引擎来保证EPC内容的安全，包括抵御内存的行锤（Row-Hammer）攻击。

缓存时长攻击 ： SGX硬件并不能考虑缓存时长侧信道攻击。 不安全的操作系统软件控制把Enclave的内存映射到缓存的特定区域，从而辅助侧信道攻击。

对私有微架构状态的软件攻击 ：研究指出， SGX硬件不保护微架构的信息 ，例如，Enclave的分支执行历史。

其他软件侧信道攻击 ：一个用户的Enclave通常需要有个引用飞地（Quoting Enclave，QE）提供用于远程证明的SGX Quote（引用）。SGX Quote要求QE用私钥进行数字签名。由于 SGX硬件不提供侧信道攻击保护 ，根据密码学侧信道的最佳实践，这意味着Enclave的开发者需要写出没有数据相关的内存访问（Data-Dependent Memory Access）的代码来访问密钥。

另外，佐治亚理工学院也在SGX 101网站上发布了一些学习资料。目前，业界已经出现一系列针对SGX Enclave的侧信道攻击。例如，Weichbrodt等在2016年的论文“Exploiting synchronisation bugs in Intel SGX Enclaves”中提出了AsyncShock工具可以利用Enclave内的多线程同步漏洞。Gotzfried等在2017年的论文“Cache attacks on Intel SGX”中解释了SGX的缓存攻击。Lee等在2017年的论文“Inferring fine-grained control flow inside SGX Enclaves with branch shadowing”中提出了Intel SGX Enclave的分支追踪（Branch Shadowing）攻击。Bulck等在2018年的论文“Foreshadow:extracting the keys to the Intel SGX kingdom with transient out-of-order execution”中提出了Foreshadow攻击，利用瞬态乱序执行（Transient Out-of-order Execution）从SGX Enclave提取出密钥。Chen等在2019年的论文“SgxPectre: stealing Intel secrets from SGX Enclaves via speculative execution”中展示了SgxPectre，它是Spectre在SGX的变体。Murdock等在2020年的论文“Pludervolt: software-based fault injection attacks against Intel SGX”中提出，Pludervolt攻击会利用电压故障注入攻击Intel SGX。Puddu等在2021年的论文“Frontal attack: leaking control-flow in SGX via the CPU frontend”中提出了Intel SGX的Frontal Attack攻击。王鹃等在2018年的论文“SGX技术的分析和研究”，Fei等在2021年的论文“Security vulnerabilities of SGX and countermeasures:a survey”中分别对SGX的安全弱点和防范进行了总结。这是SGX Enclave的软件设计者需要考虑的问题，读者可以参考Intel提供的一系列侧信道攻击防范的最佳实践来抵御侧信道攻击，例如，“Managed runtime speculative execution side channel mitigations”“Security best practices for side channel resistance”以及“Guidelines for mitigating timing side channels against cryptographic implementations”。

3.3.2 Intel TDX的威胁模型

安全飞地支持把用户态的应用程序加载到飞地中，但这也带来了局限性：为了使用飞地，用户必须把代码重写、整合成符合飞地的形式。而机密虚拟机可以方便地执行未修改的代码。在机密虚拟机方案中，需要更改的只有虚拟机中的操作系统（Windows或Linux），这样就可以方便地执行已有的应用程序。

Intel的TDX是Intel提出的基于虚拟机的机密计算方案。Intel的机密虚拟机称为可信域（Trust Domain，TD），也就是机密计算的TEE VM（TVM）。每个TD和VMM、非TD（也就是普通VM）以及其他TD都是相互隔离的。TDX依赖多密钥全内存加密（Multi-Key Total Memory Encryption，MK-TME）引擎进行内存加密，并添加额外的模式来保证完整性。每一个TD都有属于自己的密钥。

安全地管理一个虚拟机比管理一个飞地更加复杂，特别是管理TD的运行状态以及管理TD和VMM的上下文切换。因此，Intel引入了一个称为Intel TDX-Module的软件模块来辅助管理VMM。这就是机密计算的软件TSM。简单来说，VMM负责非安全的部分，Intel TDX-Module负责安全相关的部分。对于每一个TD来说，Intel TDX-Module是TCB的一部分，相当于硬件CPU的扩展。Intel TDX-Module的主要功能是负责每一个TD的状态管理，以及管理TD和VMM之间的切换。Intel TDX的架构如图3-9所示。

在TDX白皮书中，详细介绍了TDX的安全功能（如图3-10所示）。

内存机密性和完整性 ：TDX依赖TME-MK引擎提供基于TD的密钥，从而提供加密和完整性检查功能。TDX使用主机密钥ID（Host Key Identifier，HKID）告诉内存加密引擎使用哪个加密密钥，每个TD都会在启动时分配到一个私有HKID用于加密私有内存，而共享内存由共享HKID负责加密。TDX的内存完整性有两种模式：第一种是密码完整性（Ci），即内存完整性由消息认证码和TD所有者位（TD Owner Bit）保证，可以抵御软件篡改攻击和某些硬件破坏攻击，例如行锤攻击；第二种是逻辑完整性（Li），即内存完整性仅由TD所有者位保证，只能抵御软件访问TD密文而无法抵御硬件攻击。

地址翻译完整性 ：一个TD可以访问两种形式的内存，一种是私有内存（Private Memory），这是指只有TD自己可以访问的内存，由分配给TD特定的临时（Ephemeral）内存加密密钥加密以保证其机密性和完整性；另一种是共享内存（Shared Memory），它不额外受TDX可信模块保护，VMM也可以访问。通常，在VMM存在的情况下，VM的物理页表由VMM通过扩展页表（Extended Page Table，EPT）管理，扩展页表也称为共享EPT（Shared EPT）。在启用TDX时，TD私有内存的物理页表由另一个安全EPT（Secure-EPT，S-EPT）管理。安全EPT的存放位置由Intel TDX-Module管理，而其他未授权的软件（VMM、VM、TD）都没有直接访问的权限。

CPU状态机密性和完整性 ：类似于普通VM，当一个TD被创建时，它需要把状态保存到TD特有的虚拟机控制结构（Virtual Machine Control Structure，VMCS）中。当TD和VMM进行上下文切换时，TD的CPU寄存器由Intel TDX-Module保存到TD特有的状态存储区（SSA）中。Intel TDX-Module负责管理所有TD的VMCS和SSA，把这些元数据保存在加密内存中，使其他模块无法访问。

安全的中断/异常分发 ：在TDX中，中断和异常是通过VMX-APIC虚拟化和虚拟中断分发到一个TD的。VMX-APIC虚拟化的目的是减少软件模拟APIC，以方便管理，同时减少开销。在TDX中，虚拟APIC页也是由Intel TDX-Module进行管理的，其他未授权模块不可访问。

在一个非TDX的虚拟化环境里，VMM可以通过设置EPT来管理客户机物理地址（Guest Physical Address，GPA）到宿主机物理地址（Host Physical Address，HPA）的映射。在TDX的环境里，也需要有类似的TD的GPA到HPA的映射。不过，VMM不能够随意地修改这个映射，所以TDX引入了共享EPT和安全EPT这两个页表组件，如图3-11所示。

在TD环境里，所有客户机虚拟地址（Guest Virtual Address，GVA）到GPA映射是通过普通页表CR3寄存器完成的。但是，TD环境中的页表会有一个共享位（SHARED-bit）来表示这个页是TD的私有内存还是共享内存。随后，CPU在将GPA翻译为HPA时会根据共享位来决定使用共享EPT还是使用安全EPT来查找地址映射信息。如果一个TD页面是共享的，那么共享位为1，CPU使用共享EPT。如果一个TD页面是私有的，那么共享位为0，CPU使用安全EPT。共享EPT在VMM的内存中仍然由VMM直接管理。但是，安全EPT需要在TDX Module管理的私有内存中由TD的临时密钥加密，VMM不能直接修改安全EPT，只能够向TDX Module发送命令来构建管理安全EPT。

在地址翻译的最后，CPU会在HPA设置主机密钥ID（HKID），告诉内存加密引擎使用哪个加密密钥。TDX架构把HKID的空间分为共享HKID（Shared HKID）和私有HKID（Private HKID）。TD的共享内存会使用共享HKID加密，而TD的私有内存使用TD特定的私有HKID加密。

对于普通设备的MMIO地址空间，TD必须显式设置SHARED位来标识，这样可以支持设备的透传（Passthru）模式。这时的设备是不可信设备，TD在使用前必须要验证设备的数据。

Intel TDX硬件主要考虑两类威胁：

系统软件攻击 ：这里的系统软件包括具有系统管理员权限的内部攻击者以及VMM、普通VM、其他TD、BIOS（包括系统管理模式）等具有系统权限的软件，它们可以启动其他可能有恶意软件的模块。例如，攻击者可以尝试直接访问TD的私有内存、注入私有内存、执行私有内存、修改CPU状态、使用直接内存访问（Direct Memory Access，DMA）引擎、利用EPT页表、内存重映射、触发内存别名（Alias）访问、注入虚拟中断等方法来获取TD中的机密信息。TDX可以防止以上所列的系统软件攻击，包括不同TD之间和同一个TD的对于私有内存的软件抓取-重放（Capture and Replay）攻击。

硬件攻击 ：云服务提供商（CSP）内部的攻击者可以通过硬件攻击来访问目标TD中的数据。例如，攻击者可以使用DRAM冻结攻击（DRAM Freeze Attack）读取DRAM中的加密数据，然后通过线下分析（Offline Analysis）来破解明文；或者覆写DRAM中的加密数据内容进行相同或不同DRAM物理地址的重放攻击。TDX可以防止大部分的简单硬件攻击。需要注意的是，TDX可以防止不同TD之间的抓取-重放攻击，但是 不能抵御同一个TD的硬件抓取-重放攻击 。

除此之外，Google的Aktas等在2023年发布了关于Intel TDX的审计报告“Intel Trust Domain Extensions（TDX）security review”。IBM的Cheng等也在2023年发表了Intel TDX的研究报告“Intel TDX demystified:a top-down approach”。

同SGX一样，TDX也不能完全防止侧信道攻击。TD的使用者需要采用软件安全最佳实践来保证TD的安全，为此Intel发表了关于TDX安全实践的报告“Trust domain security guidance for developers”和“Intel trust domain extension guest kernel hardening documentation”，以及关于TME-MK的侧信道攻击防范的报告“MKTME side channel impact on Intel TDX”。

Intel TDX系列还包含Intel TDX Connect，它用于支持可信机密设备。我们将在第三部分详细描述。

3.3.3 AMD SEV的威胁模型

AMDSEV是AMD推出的基于虚拟机的机密计算方案。内存由内存控制器的加密引擎进行加密，然后存储到DRAM。根据AMD在“TLB poisoning attacks on AMD Secure Encrypted Virtualization（SEV）”中的描述，第一代SEV会泄露CPU寄存器的信息，SEV-Encrypted State（SEV-ES）已做出了改进，但还是有可能受到TLB Poisoning攻击的威胁。SEV-Secure Nested Paging（SEV-SNP）解决了前两代的问题，并且加入了内存完整性保护功能。AMD SEV-SNP的架构如图3-12所示。

在SEV-SNP机密虚拟机系统中，每个SNP VM就是一个机密计算TEE。管理SNP VM的工作由AMD安全处理器（AMD Secure Processor，AMD-SP）的硬件模块完成，也就是说，AMD-SP充当了硬件TSM的角色。AMD-SP和AMD CPU SoC都是SEV-SNP方案的TCB模块，如图3-12所示。

SEV-SNP的私有内存管理策略和TDX不同，它没有使用隔离的安全嵌套页表（Nested Page Table，NPT）的概念，而是在NPT之后加上一个反向映射表（Reverse Map Table，RMP），如图3-13所示。

在SNP-VM环境里，所有GVA到GPA的映射是通过普通页表CR3寄存器实现的。页表会有一个C（enCryption）位来表示这个页面是加密私有内存还是非加密共享内存。在GPA通过嵌套CR3（Nested CR3，nCR3）转换为系统物理地址（System Physical Address，SPA）之后，CPU会查找RMP。RMP表记录了所有使用的4KiB页面的所有者（Owner）是VMM、AMD-SP还是特定的SMP-VM。只有通过RMP权限访问检查，内存的访问才被允许。同样，RMP自身是需要保护的，VMM不能直接修改RMP表，只能通过特殊命令来创建。

同TDX一样，对于普通设备的MMIO地址空间，SNP-VM必须清除C位标识，以支持不可信设备的透传模式。

在SEV-SNP的白皮书“AMD SEV-SNP: strengthening VM isolation with integrity protection and more”中，介绍了威胁模型。

机密性 ：顾名思义，SNP VM中的内存是加密的。VM的寄存器状态是受保护的，并且通过DMA保护SNP VM阻止来自不信任的设备的访问。启动时，每个SNP VM会有一个地址空间标识（Address Space Identifier，ASID），用来告诉内存控制器使用哪个VM加密密钥（VM Encryption Key，VEK）来加密VM内存。

完整性 ：SEV-SNP引入反向映射表（RMP）来支持内存完整性检查，可以抵御内存破坏攻击（写入任意垃圾数据）、内存重放攻击（会写入之前旧的数据）、重映射攻击（会交换映射到VM的页面）、别名访问攻击（会有两个VM映射到同一个DRAM页面）等。

可用性 ：SEV-SNP可以保证VMM的可用性，但不能保证SNP VM的可用性。

物理访问攻击 ：SEV-SNP可以抵御DRAM线下攻击，但是SEV-SNP 不考虑在线 （ on-line）DRAM完整性攻击 。例如，在VM运行时直接操纵内存DDR总线。

其他 ：SEV-SNP可以 部分抵御 中断/异常注入攻击， 部分抵御 间接分支预测器（Indirect Branch Predictor）的Poisoning攻击， 部分抵御 调试攻击（即在调试时修改断点）。SEV-SNP不能完全防止侧信道攻击。

业界也对AMD SEV安全性做出了研究。例如，Du等在2017年发表的论文“Secure encrypted virtualization is unsecure”中就提出可能利用SEV缺少完整性检查的缺陷进行攻击。Morbitzer等在2018年的论文“SEVered: subverting AMD's virtual machine encryption”中提出了SEVered，这种攻击可以用恶意VMM获取TEE内容。Buhren等在2019年的论文“Insecure until proven updated: analyzing AMD SEV's remote attestation”中讨论了由于CPU密钥泄露导致的SEV远程证明问题，在2021年的论文“One glitch to rule them all: fault injection attacks against AMD's secure encrypted virtualization”中提出使用glitch进行故障注入，使得ASP执行恶意代码，解密VM内存。Li等在2019年的发表的论文“Exploiting unprotected I/O operations in AMD's secure encrypted virtualization”中提出可能用未保护的I/O攻击了SEV，在2021年的论文“TLB poisoning attacks on AMD secure encrypted virtualization”中说明了TLB Poisoning攻击，在论文“CrossLine: breaking “security-by-crash”based memory isolation in AMD SEV”中说明了CrossLine攻击，并在论文“CIPHERLEAKS:breaking constant-time cryptography on AMD SEV via the ciphertext side channel”和“A systematic look at ciphertext side channels on AMD SEV-SNP”中说明了SEV-SNP的侧信道攻击CipherLeaks。

Google的Cohen等在2022年发布了关于AMD SEV-SNP的审计报告“AMD secure processor for confidential computing security review”。

对于侧信道攻击，AMD也发表了防范指南“Technical guidance for mitigating effects of ciphertext visibility under AMD SEV”。

AMD SEV系列中包含SEV-TIO，可支持可信机密设备。我们将在第三部分详细描述。

3.3.4 ARM RME

ARMv8及之前支持ARM TrustZone的系统可以创建一个与正常世界（Normal World）隔离的安全世界（Secure World）来作为TEE。这个安全世界只能静态创建，所以影响了TEE的扩展性。颇有争议的是，安全世界的权限过大，超过了TEE的需要，因此不能算是机密计算的通用解决方案。

ARMv9引入了基于虚拟机的CCA，这是ARMv9增加的最大的功能。ARM CCA增加了Realm World（Realm世界）这个概念。系统利用机密领域管理扩展（RME）可以在Realm世界中创建Realm VM。每个Realm VM就是一个机密计算的TEE，TSM则是由机密领域管理监视器（Realm Management Monitor，RMM）负责管理Realm VM。异常级别3（Exception Level 3，EL3）的监视器负责切换三个不同的世界。ARM CCA的架构如图3-14所示。

ARM DEN-0129“Arm Realm Management Extension（RME）system architecture”中介绍了RME的安全特性，ARM DEN-0096“ARM CCA security model”描述了ARM CCA的安全模型。由于ARM系统的EL3还运行着负责切换不同世界的监视器，因此CCA的组成和安全设计更加复杂一些。

CCA系统安全域 （CCA System Security Domain，CCA SSD）：可信硬件和固件，属于系统TCB的一部分，被其他模块MSD和RMSD所信任。

监视器安全域 （Monitor Security Domain，MSD）：包括在根世界（Root World）运行的所有固件，负责不同世界之间的安全切换，使得其他安全世界和正常世界不会影响Realm世界。MSD是Realm世界的TCB的一部分，被RMSD所信任。

机密领域管理安全域 （Realm Management Security Domain，RMSD）：包括在Realm世界运行的所有固件，负责隔离保护每个Realm VM。RMSD是Realm VM的TCB的一部分，充当TSM的角色，被Realm VM所信任。

由于ARM机密计算架构保留了“安全世界”这一概念，因此安全世界的安全性没有改变，即Realm世界不能影响安全世界。这是由CCA系统安全域和MSD保证的。

ARM CCA考虑以下内存相关的威胁模型，同时，CCA还列出了最小安全需求作为实现机密计算的基线（Baseline）。

直接内存访问 ：未授权的软件实体直接访问Realm的数据，ARM CCA隔离机制可以对此进行防护。

探测 （Probing）：攻击者用物理方法直接访问内存中Realm的数据。ARM CCA内存加密机制可以对此进行防护。

重放 ：攻击者使用物理方法重放之前抓取的旧的内存内容。ARM CCA的基线 不提供重放攻击保护 。如果系统采用具有临时时新性的内存完整性保护，则可以防范重放攻击，但是这会影响系统性能，增加内存开销。

泄露 ：攻击者通过CCA平台的错误配置来获取Realm的内容。ARM CCA的基线主要防止跨越World边界的泄露，但 不防止跨越Realm边界的泄露 。如果系统采用基于Realm的独立密钥加密，则可以防止跨越Realm边界的泄露，但是这会影响缓存性能。

基于软件的侧信道攻击 ：例如，时间侧信道攻击、行锤攻击等。ARM CCA的基线 不包括软件侧信道保护 。

ARM CCA Realm的安全内存管理由多个模块负责，如图3-15所示。首先，在一个Realm内部可以设立Stage-1页表负责虚拟地址（Virtual Address，VA）到中间物理地址（Intermediate Physical Address，IPA）的映射。其次，VMM向RMM申请IPA到物理地址（Physical Address，PA）的映射，由RMM建立Stage-2页表，也称为 Realm转换表 （Realm Translation Table，RTT），用于描述Realm的地址空间信息。一个Realm的IPA可以分为保护（Protected）和不保护（Unprotected）两部分，分别对应机密内存和共享内存。最后，Root世界的监视器会根据物理地址空间（Physical Address Space，PAS）设立 粒度保护表 （Granule Protection Table，GPT），PA只有通过GPT的检查才能最终访问到系统物理内存。每个世界都有自己的PAS，例如Root PAS、Realm PAS、安全PAS（Secure PAS）和非安全PAS（Non-Secure PAS）。GPT描述了不同世界对不同PAS的访问控制策略，例如Realm世界和Root世界可以访问Realm PAS，但其他世界不能访问Realm PAS。

ARM CCA RME的架构中引入了内存加密上下文（Memory Encryption Context，MEC）扩展。在没有MEC的时候，每个世界中只有一个根据PAS衍生出的加密密钥，虽然Realm世界和安全世界以及Root世界使用不同的加密密钥，但是每个Realm都使用相同的加密密钥，Realm之间的隔离由RMM完成。MEC存在的时候，一个Realm世界中可以有多个根据 MEC标识符 （MEC Identifier，MECID）衍生出的加密密钥，这样RMM和每一个Realm都有自己的加密密钥，满足纵深防御的要求。如图3-16所示，左图表示没有MEC的情况，右图表示有MEC的情况，虚线框表示同一密钥的加密边界。

ARM安全中心发布了一系列白皮书—“Speculative processor vulnerability latest updates”，用于帮助ARM开发者理解、抵御侧信道攻击，如Spectre/Meltdown以及它们的变种。

ARM CCA RME的架构中包含RME设备分配（RME Device Assignment，RME-DA）来支持可信机密设备。我们将在第三部分详细描述。

3.3.5 RISC-V CoVE

RISC-V标准化组织AP-TEE工作组在2023年起草了支持RISC-V架构的机密虚拟机方案，称为CoVE。RISC-V的CoVE方案类似于ARM CCA RME，不同之处在于RISC-V没有安全世界这一概念。CoVE将机密计算TEE称为TEE VM（TVM）或 域 （Domain），而且直接把保护和隔离TVM的模块称为TSM或 域安全管理器 （Domain Security Manager，DoSM）。机器模式或M模式（M-mode）的监视器或 根安全管理器 （Root Security Manager，RSM）负责切换TEE世界（TEE World）和非TEE世界（Non-TEE World）。RISC-V CoVE的架构如图3-17所示。

CoVE规范和安全模型“RISC-V Platform Security Model”非常详细地定义了威胁模型和安全需求。安全需求分为必要的需求和实现相关的需求。下面简单总结一下必要的需求。

CPU状态保护 ：防止不可信代码访问或修改CPU状态。

内存机密性 ：内存访问需要隔离，内存需要加密。但是，CoVE 不要求基于TVM的独立密钥加密 。

内存完整性 ：需要抵御基于软件的攻击，包括内存执行。但是，CoVE 不要求抵御基于硬件的攻击，包括行锤攻击 。

I/O保护 ：不可信的设备不能访问TEE。

安全中断请求 （Interrupt Request，IRQ）：防止违反中断优先级或中断屏蔽的IRQ注入。

安全时间戳 ：需要保证TEE有一致的时间戳。

性能分析 ：既要保证TEE获得正确的性能监视单元（Performance Monitoring Unit，PMU）信息，又要防止由PMU导致的机密信息泄露。

调试 ：产品中的调试端口必须禁止。

可用性 ：防止TVM对系统进行拒绝服务攻击。但是VMM对TVM的拒绝服务不在考虑中。

侧信道 ：CoVE规定需要提供受保护的地址映射以及微架构侧信道保护，如分支预测（Branch Prediction），来防止类似Spectre/Meltdown的攻击；需要提供机制防止单步攻击（Single-Step Attack）/零步攻击（Zero-Step），以及防止中断/异常注入。但是，CoVE 不要求抵御CPU架构的缓存侧信道和时长侧信道。

CoVE机密计算的内存安全管理由SmMPT规范“Memory tracking table for supervisor domain access protection specification”定义，如图3-18所示。首先，在一个Domain内部可以设立VS-Stage页表完成GVA到GPA的映射。其次，TSM建立G-Stage页表负责GPA到系统物理地址（System Physical Address，SPA）的映射。最后，CoVE的一个重要功能模块是 内存保护表 （Memory Protection Table，MPT）。每一个RISC-V的硬件线程（Hardware Thread，HART）会有MPT检查者（MPT Checker，MPTCHK）扩展，它和已有的基于页表的内存管理单元（Memory Management Unit，MMU）以及物理内存保护（Physical Memory Protection，PMP）机制一起工作。机器模式的软件使用MTT来创建一个隔离的环境，包括CPU状态和内存的隔离。MPT的另一个作用是指定物理内存属性（Physical Memory Attribute，PMA），TSM可以指定哪些是机密内存（Confidential，C）、哪些是非机密内存（Non-Confidential，NC）。

CoVE的一个重要功能模块是 特权域物理地址元数据选择子 （Supervisor Domain Physical Address Metadata Selector，Svpams）。当MTT允许访问时，特权模式的软件使用Svpams来更精确地控制内存访问策略。除此之外，Svpams指定的元数据可以与其他特权域标识符（Supervisor Domain Identifier，SDID）、虚拟机标识符（Virtual Machine Identifier，VMID）、地址空间标识符（Address Space Identifier，ASID）等一起指定一个密码上下文，从而提供内存保护功能。

RISC-V微架构侧信道（uarch-side-channels）工作组起草了“实现者安全指南”（Transient Execution：Implementer's Security Guide），用于帮助RISC-V开发者理解软件侧信道攻击和防护。

RISC-V CoVE系列还包含CoVE-IO来支持可信机密设备。我们将在第三部分详细描述。 bGztSsSwVmzUeVGTByxzNKElcy+eb5Bn11tjROod7zaxC2LoCZqTIAylSDQw6alm