硬件解决方案是否坚不可摧？揭示可信硬件tee的优缺点

如何信任可信的硬件？与纯软件隐私保护解决方案相比，可信硬件解决方案有哪些优势？可信硬件真的是坚不可摧的吗？使用可信硬件的相关技术风险和业务问题是什么？

可信执行环境（TEE）通过硬件隔离来保护隐私数据的计算和操作。在不破解硬件的前提下，攻击者不能直接读取隐私数据和系统密钥，保证了数据的机密性。同时，攻击者无法通过固化的硬件逻辑和硬件级别检测到篡改，从而确保相关系统操作过程不被恶意篡改。

基于以上特点，与纯软件隐私保护方案相比，结合tee的方案通常表现出更好的性能和可扩展性，因此受到了广大平台服务提供商的青睐。从众多解决方案的效果来看，结合TEE的解决方案似乎可以满足数据内容保护中隐私保护的任何业务需求。

值得注意的是，这款较为成熟的T恤已经面世近5年。然而，在多方合作的实际应用中，tee并没有“一统江湖”它是否仍然包含着不为人们所知的重大风险？并用这篇文章来探究真相。

Tee安全模

为了进一步了解tee的能力边界，首先要回答的问题是如何实现tee的安全性和可信性，即tee的安全模是什么？

虽然不同硬件供应商提供的tee硬件功能不同，但其安全特性主要取决于以下硬件功能类：

物理隔离的密钥存储空间。

物理隔离的代码运行环境，也称为enclae。飞盘具有独立的内部数据路径和计算存储空间，保证飞盘外程序不易读取飞盘内运行的代码生成的内部数据。

绑定到硬件设备的设备密钥与外部软件验证服务一起，验证tee硬件设备的真实性，从而恶意识别软件模拟的假设备。

物理篡改检测自毁机制，当tee数据存储模块的传感器检测到外部硬件攻击时，会清除数据进行保护。

基于上述功能，在实际的商业应用中，开发人员通常将可信硬件视为一个安全的黑匣子，假设它满足以下特征：

存储在可信硬件中的数据，其明文形式仅存在于硬件中，不能被外界读取或截获。

可信硬件中的操作过程可以通过相关的远程代码认证协议进行验证，以确保如果操作过程的功能逻辑与约定不一致，将被检测到，恶意篡改后的操作过程无法通过检测。

在功能层面上，tee对所支持的计算过程没有限制，可以方便地适应各种应用场景。这是一种非常通用的技术。

理论上，基于tee的隐私保护方案的核心优点是将方案的安全性降低到硬件设备本身的安全性。只要TEE承诺的硬件功能和支持软件功能不存在任何安全问题，隐私保护方案也将是安全的。

看似完美的假设涉及三个关键问题：

TEE承诺的硬件功能是否完美？

tee的配套软件功能，如tee硬件设备的真伪验证服务是否完善？

TEE承诺的硬件功能和支持软件功能一旦出现问题，如何从用户的角度进行有效的验证？

对这三个问题的回答将导致tee的一系列技术风险。为了更深入地了解它对实际业务的影响，让我们在下一节首先了解TEE的常见应用程序模式。

三通应用模式

tee的应用模式非常多样化，但在常用方案的构建过程中，一般都离不开经典的飞地计算模式，即将所有与隐私数据相关的计算放在物理隔离的飞地中执行，整个过程大致可以抽象为以下三个阶段：

T形硬件设备注册

Tee硬件设备向远程硬件认证服务请求设备注册，该服务通常由硬件Maker或平台服务提供商提供。

远程硬件认证服务根据tee硬件设备的内置绑定密钥等系统参数，判断该设备是否是真实的物理设备，而不是软件模拟的虚拟设备。

根据黑名单机制，远程硬件认证服务判断tee硬件设备不是已知的破解或丢失设备。

如果以上所有验证均通过，则注册完成。远程硬件认证服务和tee硬件设备协商密钥，分别生成未来远程设备认证所需的密钥，并将相应的数据保存在各自的存储介质中。

可信执行器部署

应用程序提供程序将受信任的执行器作为输入，调用系统接口来创建飞地，并部署受信任的执行器。

在可信执行器的部署过程中，通常在未来的调用过程中，至少会生成一对公钥和私钥，用于通信数据的加密和解密。私钥的明文只存在于飞地中，公钥将作为返回值返回给应用程序提供程序。

部署完成后，应用提供方通过tee硬件设备提供的enclae测量接口对部署的可信执行程序进行全面测量，生成的测量报告包含一系列部署的软硬件属性和内存中代码的哈希值。

应用程序提供程序将上一步生成的度量报告发送到远程硬件身份验证服务，并请求对部署的受信任执行器进行身份验证。经过身份验证的可信执行器的二进制数据确实已成功部署到未加密的tee物理硬件设备上。检定合格后，签署测量报告。

可信执行器调用

用户从应用程序提供程序获取带有远程硬件身份验证服务签名的可信执行器度量报告，以验证签名的有效性。

身份验证通过后，用户使用受信任的执行器在部署阶段生成的公钥来加密调用所需的参数，并可以选择附加一个返回值加密密钥来调用结果的密文返回。

用户将加密的调用参数发送到tee硬件设备。在飞地的隔离操作环境中，可信执行器使用部署阶段生成的私钥将密文参数解密为明文，完成约定的计算并返回结果。

除了直接返回结果明文外，可信执行器还可以使用call参数中附加的返回值加密密钥对结果进行加密，然后以密文的形式返回结果，以确保只有用户才能解密结果。

用户可以在实际调用前后请求tee硬件设备对部署的飞地中的可信执行程序进行新一轮的测量，并联系远程硬件认证服务获取**的认证结果。

从用户的角度来看，上述使用TEE的过程可以进一步简化为以下三个步骤：

获取受信任执行器的公钥并加密调用参数。

将加密的密文参数发送到受信任的执行器。

等待受信任的执行器解密参数，执行程序逻辑并在TEE创建的飞盘中返回结果。

如果平台服务提供商能够在前两个阶段提供标准化的服务，那么应用程序开发人员只需要关注自己的业务开发。因此，tee的应用程序开发和业务适应过程是非常直接和高效的。

但是，作为构建隐私保护解决方案的核心技术，tee如果仅仅能够满足功能性需求还远远不够，关键是看它能否同时满足安全性等非功能性业务需求。tee在这些区域的表现如何？在下一节风险披露中，我们将逐一展开。

Tee风险披露

Tee降低了数据操作过程中的保密性和抗篡改性，从而保证了硬件设备本身的安全。这个设计是把双刃剑。在提供**的方案多功能性的同时，不可避免地会对安全性和可用性产生巨大影响。

安全风险

用户使用TEE的过程看似简单高效，但其安全性和隐私保护与前两个阶段的有效性密切相关AMPLmdash；TEE硬件设备注册和可信执行程序部署。

想象一下，如果攻击者提供了基于破解的tee硬件设备的服务接口，而用户不知道该接口，并使用攻击者控制的公钥加密隐私数据，那么用户就没有隐私。

这带来了一个非常具有挑战性的问题，用户如何知道？

回答这个问题的关键是理解为什么身份验证过程是有效的：

在注册阶段，证明tee硬件设备是真实的物理硬件（在远程硬件认证服务的白名单中），并且没有被破解（不在远程硬件认证服务的黑名单中）。

在部署阶段，验证可信执行器确实部署在经远程硬件认证服务认证的tee硬件设备中，并且代码和部署参数与协议一致。

除了tee硬件设备的设计和生产缺陷外，这两个阶段的有效性在很大程度上取决于远程硬件认证服务是否诚实、破解，以及是否有**的黑名单信息。由于此服务通常由硬件Maker或平台服务提供商提供，因此形成了一个中心化信任问题。

这是第一个风险。用户必须信任硬件Maker和平台服务提供商的声誉。

即使硬件厂商和平台服务商未能履行协议，甚至可信的执行程序根本没有在tee硬件设备中执行，用户也无法感知。

哪一方将提供此中心化信任服务？对于需要多方平等合作的场景，引入了一个非常现实的信任问题。

如果同时有多个平台服务商提供tee的可信硬件解决方案，如果需要基于tee的多方数据进行合作，可能的情况如下：

参与数据交换的任何平台服务提供商都不会提供远程硬件身份验证服务，但需要找到另一个不存在商业利益冲突的可信第三方。否则，该业务可能无法开展。

另一方面，三通五金设备的设计和生产过程中也不可避免地存在安全缺陷。

由于这项技术相对较新，早期的攻击者对此并没有太多的关注。然而，随着人们对隐私保护业务需求的不断增长，许多商业解决方案应运而生。自2017年以来，相关安全缺陷已上报。在CVE中，与tee相关的硬件漏洞大多与本地物理访问有关，可能导致密钥泄露、数据泄露、权限增强等问题。

最近，出现了缓存和sgaxe攻击（漏洞ID ce-2020-0549）。

这些已知的硬件漏洞对基于tee平台的服务提供商的自我约束提出了更高的要求。

第三，一旦tee暴露出新的安全风险，可能很难及时修复。

主要原因如下：

无法升级的硬件模块：虽然大多数密码算法都可以通过升级固件来升级，但一些与性能相关的关键模块可能无法通过软件升级，只能更换硬件。

一个典的例子是内存加密引擎（MEE）硬件模块。目前，主流的硬件实现方法是128位安全长度加密算法。与目前软件算法实现中常用的256位安全长度相比，其抗暴力破解的安全性要弱得多。

如果这类模块存在安全风险，且短时间内没有新的硬件产品更换或良好的软件过渡修复方案，则原方案只能暴露在相应的安全风险中。面对可能出现的量子计算机，现有tee硬件设备中固定的非反量子硬件算法模块可能面临重大的安全风险。

硬件进出口限制：目前，主要的三通厂商是海外芯片厂商。如果国际贸易关系恶化，即使**的tee硬件设备已经修复了安全问题，也可能由于进出口限制而无法得到及时修复。

硬件更换的运行成本高：如果物理硬件设备需要大规模更换，其综合成本将远远高于大规模更换软件。

除了上述硬件漏洞外，来自官方支持的SDK软件tee也存在很多安全漏洞。因此，即使硬件上没有缺陷，如果配套软件组件上存在安全漏洞，或者配置数据没有及时更新（如已知被破解的tee硬件设备黑名单），tee的安全性也会受到严重影响。

所以我们不能简单地认为只要程序在tee硬件设备中执行，数据就必须是安全的。

可用性风险

除了安全风险外，基于TEE的隐私保护方案还可能遇到可用性风险。

主要原因是tee方案的黑盒设计通常限制了与隐私数据相关的密钥只能在tee硬件设备中使用，并且这些密钥不能离开设备。这在一定程度上保证了密钥的安全性，但同时也带来了可用性问题。

在这种情况下，如果此tee硬件设备损坏或断电，是否所有相应的数据都不可用？

答案肯定是不可用的，这对于需要高可用性的数据平台业务来说通常是不可接受的。

对于这个可用性问题，我们可以使用门限密码方案（见前面的讨论）在一定程度上缓解它，但它不能从根本上解决问题。因此，在实际的方案设计中，往往需要引入外部密钥管理服务进行密钥备份和重新分配，这与TEE所倡导的密钥永不离开硬件设备的思想相冲突。

因此，为了保持系统的高可用性，可以进一步降低三通的安全性。

虽然在一定程度上，tee仍然可以保证程序执行过程不被篡改，但对数据保密性的保护却要弱得多。理论上，使用外部密钥管理服务的tee方案与纯软件隐私保护方案相同，没有任何比较优势。

结合上述情况，tee的有效性必须依赖于中心化式的远程硬件认证服务。如果认证服务不能履行其职责，那么基于tee的隐私保护方案就不能保证程序执行过程中的抗篡改性。

在这些不利条件下，即使使用tee硬件设备，其隐私保护效果也与纯软件方案没有太大区别，而且作为最终用户，很难验证tee是否真的发挥了应有的作用。

如果考虑到最坏的情况，外部平台服务提供商提供了基于tee的隐私保护方案。信任的实际基础往往是平台服务商的声誉，而不是tee的硬件设备和相关技术。

只是：安全硬件的黑匣子很难证明自己，隐私风险也很容易被打破！

与几十年来发展起来的现代密码学相比，tee的成熟还比较年轻。本文对基于tee的隐私保护方案的技术细节进行了详细的阐述，并对相关风险进行了全面的披露，并没有说明该技术的不足。相反，作为一项全方位的系统工程，构建一个安全有效的隐私保护技术方案需要结合多种不同的技术。作为重要的安全增强工具之一，tee可以用来增强数据保护的效果。

需要注意的是，TEE的安全特性在固化的同时，各种隐私风险也在固化。作为设计上的折衷，tee通过引入中心化式可信硬件执行环境认证系统，优化了这种技术方案对各种业务需求的适应性，但同时与纯软件加密方案相比，也引入了更强的安全性假设，削弱安全性和可用性。

如果隐私保护方案的安全性仅仅取决于tee的硬件特性，那么用户不仅要相信硬件厂商，还要相信平台服务商提供的一系列中心化的软硬件支持服务，因此必然会面临重大的安全性和可用性风险。而且，一旦发生风险，很可能在短时间内难以修复，用户也很难感知。

这些风险将给商业数字化趋势下倡导的公平对等的商业合作模式带来巨大挑战。如果tee解决方案提供的“可见数据可用”效果仅限于用户，而平台服务商仍有能力看到这些隐私数据，将极大地打击用户作为数据贡献者积极参与合作的动机，而相应的商业模式创新和产业应用落地也将面临阻力。

作为隐私保护方案的开发者，充分了解上述技术风险和业务关注点是充分利用tee的重要前提。

到目前为止，已有一半以上的关键原语和相关基础技术被引入。在接下来的讨论中，我们将分阶段分析数字商务系统中普遍存在的数字签名。有关详细信息，请注意下面的分解。

—结束—