A Systematic Look at Ciphertext Side Channels on AMD SEV-SNP

Author: Mengyuan Li∗,Luca Wilke∗,Jan Wichelmann,Thomas Eisenbarth,Radu Teodorescu,Yinqian Zhang Conference: S&P 2022 Paper Link: https://ieeexplore.ieee.org/document/9833768 Note Link: https://jbox.sjtu.edu.cn/l/D1EiAo Contributor: pdh Overview 基于硬件的内存加密方案例如Intel SGX和AMD SEV为程序提供了可信的执行环境,然而21年Security的一篇文章揭露了CipherLeaks攻击,它能够监控特殊VMSA页中密文的变化,通过在泄露虚拟机进行上下文切换时泄露寄存器中的数据,攻破了最新的 时间下的密码学方法的实现,包括OpenSSL中的RSA和ECDSA。 本文对TEE中(具体来说时SEV中)密文的旁路进行了一个系统性的研究,结果显示,虽然密文泄漏攻击只针对VMSA页面,但一般的密文侧通道攻击可能利用任何内存页面的密文泄漏,包括内核数据结构、堆栈和堆的页面。因此,AMD现有的应对方案,即一个固件上的补丁,对VMSA上的密文嵌入随机化,是无效的。AMD SEV内存加密的泄露的根本原因,即使用未经过身份验证的加密模式和对加密内存密文的无限制读取访问依然是一个未解决的问题。针对这一源于硬件设计上的漏洞,本文提出了一套基于软件的对策,包括对系统内核以及密码库的补丁。

[2022.06.15] [S&P 2022] vSGX: Virtualizing SGX Enclaves on AMD SEV

Author: Shixuan Zhao, Mengyuan Li, Yinqian Zhang, Zhiqiang Lin Conference: S&P 2022 Paper Link: https://www.computer.org/csdl/proceedings-article/sp/2022/131600a687/1A4Q3q3W28E Note Link: https://jbox.sjtu.edu.cn/l/01EAPB Contributor: pdh Overview 现如今对可信执行环境的需求加速了可信硬件的发展,然而在不同架构下有着不同的可信硬件的实现方式,导致开发者在开发时还要针对架构进行不同程度的开发,兼容性很差。本文提供了vSGX,用于在AMD SEV的环境下虚拟一个SGX enclave,使得AMD架构能够兼容SGX的代码。其问题的关键在于SGX代码有一些额外的指令集(ENCLS和ENCLU),需要在AMD平台下对这些指令进行模拟,并且利用SEV虚拟机创建一个类似于SGX的地址空间和内存执行环境。具体来说,vSGX可以被视作一个被插入到SEV虚拟机中的SGX硬件模块,其核心思路就是利用SEV提供的虚拟机保护机制创建一个可信执行环境,用来移植SGX。这样,SGX enclave的代码和数据的机密性由AMD的内存加密引擎(Memory Encryption Engine, MEE)来保证,完整性由基于AMD SEV的远程认证设计出的认证服务来保证。移植了SGX enclave的虚拟机被称为enclave VM (EVM),而运行不可信app的虚拟机则被称为app VM (AVM)。因此,通过本文的设计,vSGX在AMD平台下达到了和Intel SGX相似的安全性,并且有着合理的额外开销。 虽然这个在AMD架构上虚拟化SGX的想法非常直观,但是完成这个想法需要面对几个不平凡的挑战: 如何在AMD SEV中插入SGX的指令; 如何处理那些需要跨越EVM和AVM的操作(例如EENTER和EEXIT); 如何处理跨EVM和AVM的内存访问; 如何处理AVM的OS中存在的不可信的代码,甚至是恶意的hypervisor; 如何去实现远程认证。 本文分析了vSGX的安全性,并且讨论了本文的设计是如何达到和原生SGX可比较的安全级别。同时,本文对vSGX的运行性能进行了评估,运行了一个benchmark集合以及现实世界中真实的SGX应用。结果显示一些SGX的指令确实会显著降低vSGX的运行性能(例如EENTER和EEXIT),但是这些只有那些拥有很多ECall和I/O操作的程序中才会显示出来。本文通过对真实世界SGX应用进行评估的结果显示,vSGX的额外性能开销是可以接受的。