硬件化方案坚不可摧？揭秘可信硬件TEE的是非功过

可信硬件何以可信？相比纯软件隐私保护解决方案，结合可信硬件的解决方案有何优势？可信硬件是否真的坚不可摧？可信硬件的使用又会引入哪些技术风险和商业顾虑？

可信硬件执行环境（TEE，Trusted Execution Environment）通过硬件隔离手段对涉及隐私数据的运算和操作进行保护。在不破解硬件的前提下，攻击者无法直接读取其中的隐私数据和系统密钥，由此保障了数据的机密性。同时，攻击者无法通过固化的硬件逻辑和硬件层面篡改检测，以此确保相关系统运行过程不被恶意篡改。

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

值得注意的是，比较成熟的TEE已经面世近5年，然而在多方协作的实际应用中，TEE并未“一统江湖”，其背后是否还蕴含着不广为人知的重大风险？且随本文一探究竟。

TEE安全模型

为了深入了解TEE的能力边界，第一个需要回答的问题就是，TEE如何实现安全可信，即TEE的安全模型是什么？

尽管不同的硬件供应商提供的TEE硬件功能不尽相同，但其安全特性主要依赖以下几类硬件功能：

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

物理隔离的代码运行环境，也常称之为飞地（Enclave）。飞地具有独立的内部数据通路和计算所需存储空间，确保代码在飞地中运行产生的内部数据不会被飞地之外的程序轻易读取。

硬件设备绑定的设备密钥，配合外部软件验证服务验证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创建的飞地中对参数解密、执行程序逻辑、返回结果。

如果平台服务商能够提供前两个阶段的标准化服务，应用开发者只需关注自身业务的开发即可。因此，TEE的应用开发和业务适配过程，相当直白高效。

但是，作为构建隐私保护解决方案中的一类核心技术，如果TEE只能满足功能性需求是远远不够的，关键还要看是否能够同时满足安全性和其他非功能性业务需求。TEE在这些方面表现如何？我们在下一节风险披露中，对此一一展开。

TEE风险披露

TEE将保障数据运算过程中的机密性和抗篡改性问题归约到保障TEE硬件设备自身的安全性问题上。这一设计是把双刃剑，在提供优异方案通用性的同时，不可避免地对安全性和可用性造成巨大影响。

安全性风险

用户使用TEE的过程，看似直白高效，但其安全性和隐私保障，与前两个阶段——TEE硬件设备注册和可信执行程序部署的有效性密不可分。

设想一下，如果一个攻击者基于被破解的TEE硬件设备提供了一个服务接口，而用户完全不知情，使用了被攻击者控制的公钥来加密隐私数据，那么对于用户而言，是没有任何隐私可言的。

这就带来了一个很有挑战的问题，用户如何才能知情？

解答这一问题的关键，在于理解认证过程为什么有效：

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

部署阶段认证了可信执行程序确实在通过远程硬件认证服务认证的TEE硬件设备中完成了部署，且代码和部署的参数与约定的一致。

除开TEE硬件设备的设计和生产缺陷，这两个阶段的有效性很大程度上依赖远程硬件认证服务是否诚实、是否被破解、是否有最新的黑名单信息。由于这一服务通常由硬件厂商或者平台服务商提供，因此形成一个中心化的信任问题。

这就是第一方面的风险，用户必须相信硬件厂商和平台服务商的信誉。

即便硬件厂商和平台服务商未能履行约定，甚至可信执行程序根本没有在TEE硬件设备中执行，用户都是无法感知。

到底由哪一方来提供这一中心化的信任服务？对于需要多方平等协作的场景，就引入了一个非常现实的信任问题。

多个同时提供TEE可信硬件解决方案的平台服务商，如果他们之间需要基于TEE进行多方数据合作，可能出现的情况是：

远程硬件认证服务不会由这些参与数据交换的平台服务商中的任意一个来提供，而是需要另寻一个没有商业利益冲突的可信第三方，如果找不到，业务就可能无法开展。

第二方面，TEE硬件设备的设计和生产过程中也难免有安全缺陷。

由于这一技术相对较新，所以前期攻击者对其关注度也不高。但随着隐私保护的业务需求日渐人心，诸多业务方案问世，自2017开始，相关安全缺陷陆续报出。在国际漏洞数据库CVE（Common Vulnerabilities and Exposures）中，绝大部分TEE相关的硬件漏洞都与本地物理访问相关，可能造成密钥泄露、数据泄露、权限提升等问题。

最近值得关注的有CacheOut和SGAxe攻击（漏洞识别号CVE-2020-0549）。

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

第三方面，TEE一旦曝光新的安全风险，可能难以及时修复。

其原因主要可能有以下三个因素：

无法升级的硬件模块：虽然可以通过升级固件的形式对绝大部分密码学算法进行升级，但对于其中的一些性能攸关的关键模块却可能无法通过软件升级，只能替换硬件。

比较典型的例子有内存加密（MEE，Memory Encryption Engine） 硬件模块，目前主流的硬件实现是128位安全长度的密码学算法，相比目前软件算法实现中普遍的256位安全长度，其抗暴力破解的安全性弱了不少。

如果此类模块出现安全风险，短时间内没有新的硬件产品替换或者好的软件过渡修复方案，那原有的方案就只能暴露在对应的安全风险之下。面对可能面世的量子计算机，现有TEE硬件设备中固化的非抗量子硬件算法模块，可能会面临比较显著的安全风险。

硬件进出口限制：目前主要的TEE厂商都是海外芯片制造商，如果国际贸易关系发生恶化，即便最新的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的重要前提。

至此，密钥学原语和相关基础技术介绍已经过半，自下一论起，我们将对数字化业务系统中无处不在的数字签名进行分期解析，欲知详情，敬请关注下文分解。