【InForSec2023 年会论坛回顾】陈国兴：无需可信第三方的可信执行环境互认证框架

陈老师首先抛出了一个问题，在云计算时代下，我们能否完全信任这些云，如阿里云，谷歌云等？这些云能否保证我们数据的机密性，是否按照预期对我们的数据进行处理。

然后陈老师总结了针对该问题的现有解决方案。目前的解决方案可以分为两类，第一类是基于密码学的解决方案，如全同态加密和安全多方计算。第二类是基于硬件的解决方案，即可信执行环境。

接着陈老师介绍了什么是TEE与远程认证。TEE是CPU内部的安全区域，也称为Enclave(可以存在多个Enclave)，利用硬件特性来保证其中代码和数据的机密性与完整性，来抵御不可信的特权软件的攻击。因为对于Enclave自身外的软件都被认为是不可信的，在交互之前需要利用远程认证机制对Enclave的身份进行验证。在远程认证场景中，待认证的一方被称为Attester，对Attester进行认证的一方被称为Verifier。

为了帮助大家理解远程认证机制，陈老师进一步介绍了远程认证过程主要是在解决三个问题：

（1）第一个问题是Attester是否是一个Enclave。这个主要利用的是TEE厂商在CPU中内置的Root Secret，它会对一个用于远程认证的私钥Attestation Key进行背书，通过签名信息，Verifier可以验证对方是否为Enclave，这个过程通常还会利用到厂商提供的Attestation Service。

（2）第二个问题是Attester的身份是什么？目前身份识别主要依赖于Enclave Measurement，即Enclave中初始的代码和数据的哈希值作为Enclave的身份标识。

（3）第三个问题是这个身份是否是可信的。这里主要是通过与Verifier提前预设的可信身份信息进行比较来确定对方是否是可信的。

接着陈老师分享了他对远程验证这三个问题目前解决方案的一些研究与思考。在第一个问题中，会使用到厂商提供的Attestation Service，如果这个Service “好奇心”比较重，那么它可能会在这个过程中搜集信息，存在隐私泄露风险。陈老师发表在CCS 2019的一篇论文就是围绕该问题展开的研究。

第二个问题目前的解决方案仅考虑enclave初始状态，没有考虑运行时状态，无法应对运行时enclave被劫持的情况。

第三个问题目前的解决方案存在的一个不足之处是当两个Enclave都要认证对方的身份时，需要依赖于一个可信第三方的存在。陈老师团队针对这一问题研究提出了一种无需可信第三方的可行执行环境互认证框架，发表在USENIX Security 2022上。接下来，陈老师对这篇研究工作的内容进行了展开介绍。

陈老师先介绍了安全软件开发的模块化和特权分离趋势。以一个基于TEE的智能家具应用为例，将语音收集处理逻辑和代码执行逻辑放在不同的Enclave中，从而降低当一个模块被恶意攻击者攻陷后所能造成的安全影响。但是这也带来了一个互相认证的需求，即两个模块在通信前需要验证对方的身份。

针对互认证问题，陈老师介绍到目前的解决方案主要是引入一个可信第三方，但是引入可信第三方会带来额外的开销。

那么能否在不引入可信第三方的前提下解决这个问题呢，陈老师又介绍了一篇在Asia CCS 2016年的一篇论文中提出的观点，两个Enclave要互相认证，那么需要在Enclave A完成开发后根据其初始状态生成Measurement并将其硬编码到Enclave B中，然后再同样的将Enclave B的Measurement硬编码到A中，但这个时候Enclave A的初始状态发生了变化，导致其Measurement也发生了变化，这个依赖关系陷入了一个死循环，当时的作者认为这是一个不可解的问题。

针对这个“不可解”的问题，陈老师提出了他们的解决方案——MAGE。其核心想法是将Enclave划分为两部分，Specific Part负责具体的功能，Common Part用于生成Enclave的身份标识。

紧接着陈老师介绍到这个方案需要设计三个关键的函数，分别是共同部分生成函数、内容构建函数、以及身份推导函数。

为此，陈老师介绍了这三个函数设计思路来源于传统的Measurement计算过程，即当了解了任意一点的Intermediate hash和后续的enclave content时，可以推导出最终的计算结果。

基于该观察，陈老师随后介绍了他们对于上述三个关键函数的设计思路。

在介绍了算法的设计思路后，陈老师介绍了他们基于SGX对算法进行的实现，以及从内存和时间两个角度的测试结果，实际证明该了方法在实际应用中所引入的内存和计算开销都是可接受的，与enclave的数量线性相关。

最后，陈老师讨论了该研究的未来可能的扩展方向，如支持不同类型TEE之间的认证和私有代码支持等。