带有加密 RAM 的操作系统?

信息安全 密码学 加密 操作系统 记忆
2021-08-13 03:32:47

是否有任何专注于加密虚拟内存的应用程序、JIT 框架或操作系统,或者可能有类似功能的虚拟机?我知道有一些处理器(尽管旧的、慢的和弱的)允许完全加密的系统,但我还没有看到任何操作系统或应用程序为 x86 或其后代之一提供了一个体面的解决方案。

我知道 L1/L2/L3 缓存、DMA 缓冲区等在没有硬件支持的情况下无法加密,但肯定至少某些内核结构和大部分用户模式内存(即进程分配的内容)可以在支持的情况下加密编译时?

我还想知道在理论上是否可以(虽然显然很困难)翻译现有的 JIT 编译器(例如 .NET CLR),该编译器生成自动加密其用户模式内存的代码。

沿着这些思路的任何现有解决方案都会很有趣。

4个回答

我还想知道在理论上是否可以(虽然显然很困难)翻译现有的 JIT 编译器(例如 .NET CLR),该编译器生成自动加密其用户模式内存的代码。

操作系统代表程序执行此操作可能非常困难。原因是操作系统分配的虚拟页面实际上是由 CPU 控制的——操作系统会根据存储区域向 CPU 指示它想要什么,然后 CPU 在此基础上为每个程序计算偏移量并直接应用结果。阅读MMUx86上的分页

简而言之,当您的程序进行计算时mov eax, [edi+something],MMU/paging 会处理地址转换并在找不到页面时发出页面错误。如果需要,这允许您将页面从存储空间中加载出来。

因此内存访问本身并不通过内核,因此不能像文件读取或写入那样被挂钩和处理(您的读取和写入通过适当的系统调用转换为适当的文件系统结构。作为这样,操作系统会在数据通过时看到它。您不需要系统调用即可写入 RAM。您可以制作一个,但它仅适用于调用它的程序,因此不适用于大多数程序)。

但是,这并不意味着 JIT 进程不能代表应用程序执行此操作,或者应用程序本身无法保持数据加密,直到需要将其加载到寄存器中,并在传递数据时对其进行解密.

在这种情况下,你就陷入了SteveS很好地解决的问题——你有一个密钥存储问题。密钥本身也必须在 RAM 中的某个地方。这是一个从根本上解决问题的乌龟 - 从根本上说,要保持该密钥“安全”是不可能的。

最后,由于能够读取另一个应用程序的 RAM 需要超级用户模式访问 CPU(即内核空间),如果您担心软件拦截,您可能会遇到更大的问题。如果您关心的是硬件,我认为物理安全可能是降低风险的更好方法。

编辑我看了看论文。这是一个叫做CryptKeeper的。他们的技术是有一个大的加密“RAM磁盘”作为交换文件,并在不使用时将所有页面交换到那个位置:

我们使用软件加密的虚拟内存管理器 Cryptkeeper (CK) 来缓解此漏洞。传统处理器无法对加密数据进行操作,因此 CK 将 RAM 分段为一个称为 Clear 的较小工作集和一个称为 Crypt 的较大加密 RAM 设备。随着工作空间的填满,页面会自动交换到内存的加密部分,并按需解密。

显然性能还不错,但我认为还没有任何实现。

编辑 2所以事实证明 CryptKeeper 和OpenBSD 交换加密机制在非常相似的级别上工作;它实际上并不加密物理内存,而是使用物理内存作为交换结构,强制页面错误并在解析中加密/解密数据。

来自问题作者的编辑,2018 年 12 月: AMD 现在支持SME 指令集扩展,它允许对 RAM 页面进行硬件加密,加上 TSME 用于全内存加密,以及 SEV 用于虚拟化中的加密内存。这似乎可以在现代 AMD64 平台上启用全系统内存加密。

OpenBSD操作系统包括虚拟内存的自动加密自 3.9 版起默认启用。

如果没有带有嵌入式加密硬件的 CPU,缓存和物理 RAM 中的数据无法真正加密,因为 CPU 无法使用它;但是“虚拟内存”如“复制到磁盘和从磁盘复制的 RAM 块”是完全由操作系统控制的,因此操作系统可以随意加密它,这就是 OpenBSD 所做的。在某种程度上,大部分RAM 也可以保持加密,就像使用磁盘一样(即基于 RAM 的虚拟磁盘上的交换文件——它会工作!)。

RAM 内容应该在断电时自动消失(实际上需要大约一分钟左右,具体取决于温度)。

我很好奇是否也存在某些东西,但我不完全确定没有硬件干预就可以存在。

我的逻辑是,为了加密内存,任何直接访问它的进程都必须知道密钥,为了争论,这只是在内核级别。在某些时候,需要将密钥移动到未加密的内存中,以便对事物进行加密或解密,因为处理器无法直接操作加密数据。一旦此密钥在未加密的内存中,您可以通过几种方式访问​​它:内存转储、内核驱动程序、物理探测等。

从理论上讲,您可以阻止将内存转储写入磁盘并阻止安装驱动程序,并且您可以将设备锁定在保险箱中并将其放入海中(最好是防水保险箱),使其物理上无法访问,但这会改变系统的使用显着。

那么,让我重新表述我的第一个陈述——一个可以在没有硬件干预的情况下存在,但我不确定它有多安全。

至于你的另一个问题,这是可能的,但你仍然遇到同样的基本问题。您将不得不修改编译器并修改 JIT 解释器,而 exe 会将密钥存储在自己的内存空间中。exe 必须将密钥交给解释器来处理加密。这样做的问题是您仍然必须将密钥存储在未加密内存中的某个位置。事实上,如果密钥是硬编码在 exe 中的,那么你可以打开文件并去寻找它。

不过,这将是一件很酷的事情。

cryptkeeper 方法的问题在于它仍然使关键数据保持清晰(尽管比正常系统少得多)。在过去的一年里,我一直在研究这个问题,但我不相信有什么能满足你的要求(我正在努力在某种程度上进行补救)。我确实相信 INTEL 将在未来几年内发布一款能够自动加密 RAM 中所有内容的芯片。