memory - 密码学:内存中 key 的最佳实践？

Question

背景:我在数据库中使用 AES(即对称加密)加密了一些数据。在(假定的)安全且隔离的 Linux 机器上运行的服务器端应用程序使用此数据。它从数据库中读取加密数据，并写回加密数据，只处理内存中未加密的数据。因此，为了做到这一点，应用程序需要将 key 存储在内存中。

问题是，有什么好的最佳实践吗？保护内存中的 key 。

一些想法:

1. 将其保存在不可交换的内存中(对于 linux:使用 shmctl(2) 设置 SHM_LOCK ？)
2. 将 key 拆分到多个内存位置。
3. 加密 key 。用什么以及如何保证...key key..的安全？
4. 每次需要时从文件中加载 key (速度慢，如果作恶者可以读取我们的内存，他可能也可以读取我们的文件)

key 可能泄露的一些场景:evildoer 获取了 mem dump/core dump；错误的代码边界检查导致信息泄露；

第一个看起来不错，而且很简单，但是剩下的呢？其他想法？任何标准规范/最佳实践？

感谢您的任何意见!

Answer 1

一切都取决于您的偏执程度和关键/数据的敏感性。在极端情况下，只要您在内存中有未加密的 key ，就可以使用 coldboot 检索它。技巧。 frozencache 上有一个有趣的发展。试图打败它。我只是随便读了一遍，没有在实践中尝试过，但这似乎是一种有趣的尝试方式。

尽管摘下锡箔帽，但 - (1)、(2)、(3) 似乎是合理的。 (4)不会因为你提到的原因而精确切割它。 (不仅速度很慢，而且假设您读入堆栈，不同的堆栈深度，键可能不止一次可见)。

假设解密的数据是值得的，并且它会在可交换的内存中，你当然也应该加密交换本身。此外，根、/tmp 分区也应该加密。这是一个相当标准的设置，在大多数操作系统指南中都很容易找到。

然后，当然，您希望确保机器本身的高水平物理安全并尽量减少它执行的功能 - 运行的代码越少，暴露的越少。您可能还想看看如何绝对最小化远程访问这台机器的可能性 - 即使用基于 RSA key 的 ssh，这将被另一个主机控制的另一个 ACL 阻止。 portknocking在能够登录到第二台主机之前，可以将其用作额外的身份验证向量之一。为确保如果主机受到威胁，则更难以将数据取出，请确保该主机没有与互联网的直接可路由连接。一般来说，获取敏感数据的过程越痛苦，有人去那里的机会就越小，但这也会让普通用户的生活变得痛苦 - 所以需要有一个平衡。

如果应用程序很严重并且风险很高，最好构建更明确的整体威胁模型，看看您可以预见哪些可能的攻击向量，并验证您的设置是否有效处理他们。 (不要忘记包含 human factor :-)

更新:确实，您可以使用专用硬件来处理加密/解密。然后您不必处理 key 的存储 - 请参阅 Hamish 的答案。