【TEE】Intel SGX的不足和解决方案

Xinyao Zheng

已于 2024-01-22 23:56:04 修改

阅读量790

点赞数 13

分类专栏：可信执行环境TEE 文章标签：可信计算技术安全架构安全

于 2024-01-22 11:09:39 首次发布

本文链接：https://blog.csdn.net/qq_43543209/article/details/135742443

版权

可信执行环境TEE 专栏收录该内容

23 篇文章

订阅专栏

本文探讨了在计算能力受限且面临侧信道威胁的环境下，如何利用硬件可信执行环境（如Graviton、SGX、FPGA）增强隐私计算的安全性。文章介绍了FunctionPrivacy的远程认证需求、内存安全策略以及提升编程易用性的技术，如LibOS和编程语言支持。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

[基于硬件可信执行环境的隐私计算（2021）阅读记录
https://heartever.github.io/files/ConfidentialComputing-tianjin.pdf
https://heartever.github.io/files/ConfidentialComputing-Guilin.pdf
https://heartever.github.io/files/HETEE_slides.pdf

1 计算能力弱

计算能力弱：CPU至多8核，128/256MB加密内存
在这里插入图片描述

解决方法：可以扩展到GPU（Graviton，HIX）、 FPGA（SGX-FPGA，shEF）、 AI加速器（TNPU，TACC）等架构，提高计算能力

缺点：

需要更改GPU（Graviton）或者CPU（HIX）
GPU runtime等heavy software stack需要在可信环境内（Graviton）
频繁通信的加解密开销
GPU runtime和GPU的通信可能泄露侧信道信息（Telekine）

相关解决方案：HETEE，极简TCB，物理强隔离

2 侧信道攻击

在这里插入图片描述

解决方案
在这里插入图片描述

系统角度
- 检测异常中断(T-SGX、De javu)
- 检测cache eviction (TSX, Usenix 18)
- 检测SMT（hyper-threading）（HyperRace, SP 2018 https://heartever.github.io/files/SideChannelRisks.pdf）
软件开发者的角度
- ORAM
- Oblivious program execution
- Code/data randdomization

3 Function Privacy（远程认证需要证明代码）

为证明自身，service provider需要向remote user展示自己的代码
在这里插入图片描述

保证代码安全的认证：

在SGX内实现一个binary loader + checker
在SGX外提供编译器
Checker检查代码，并向remote user提供证据
思路来源于proof carrying code（PCC）
硬成S 1

4 Memory Safety

在这里插入图片描述
若代码存在漏洞，则用户数据可能被泄露
思路：代码具备某些属性，即使 control flow被任意redirect，仍能保证数据不被泄露

5 运行时状态

如何保证运行时状态的正确性？
在这里插入图片描述

6 编程和易用性

LibOS：Haven(Windows[BPH,OSDI’14])、Graphene-SGX(linux[TPV,ATC’17])、
SCONE[ATG+,OSDI’16]、Occlum(蚂蚁金服)
程序自动分割：Glamdring(c/c++[LPM+,ATC’17])，Civet(Java[TSJ+,Security’20])
编程语言支持：python(MesaPy，百度), Javascript[GWM+,Eurosec’17],GO
微容器：Panoply[STT+,NDSS’17]
中间件：Open Enclave(微软)、Asylo(Google)、SOFAEnclave(蚂蚁金服)