为私钥分配内存的合理安全、合理便携的方法是什么？ [关闭]答案

【问题标题】：What's a reasonably-secure, reasonably-portable way to allocate memory for private keys? [closed]为私钥分配内存的合理安全、合理便携的方法是什么？ [关闭]
【发布时间】：2014-06-06 02:29:27
【问题描述】：

我正在寻找为 256 位私钥分配存储空间的“最佳实践”。我至少在想，不应该将密钥分页到磁盘，并且可能还有其他一些攻击媒介需要担心（a la Hearbleed）。该解决方案必须可移植到 Linux 和 BSD。

我看过的一些东西：

TRESOR（非 BSD 便携式）
Akamai 的“安全堆”
David Shaw 的 secmalloc
使用 mlock 禁止分页
只需使用 malloc 即可，不用担心。粗略阅读表明这可能是 LibreSSL 所做的。

有什么建议吗？

【问题讨论】：

顺便问一下，您使用什么密码，256 位密钥提供任何安全性？
@R.. 现代对称密码（如 AES）？ 4096 位等大尺寸适用于 RSA 等非对称算法。
OP 说“私钥”，所以我假设公钥加密，但也许意图只是“需要保密的密钥”。

标签： c linux unix

【解决方案1】：

除非您有特殊要求，否则仅使用malloc 是明智的方法。它的优点是 valgrind 和类似的可以捕获使用错误，这是您可能担心的漏洞类型出现的主要方式之一。正如 OpenSSL 惨败向我们展示的那样，试图做一些花哨的事情并搞砸它是一个重大风险。

如果您有更苛刻的要求，这在很大程度上取决于您的使用案例。我将假设您的密钥是临时的，否则避免将它们存储在磁盘上没有多大意义。以下是针对特定风险的建议缓解措施：

交换到磁盘：如果您的系统需要针对物理攻击的安全性，则根本不应该进行交换。单独尝试使用mlock 保护特定数据是个笑话。只需关闭交换并安装足够的内存，这不是问题。 mlock 应被视为实时调度功能，而不是安全功能。
类似 Heartbleed 的问题，适度防御：通过 mmap 分配内存，两边都有保护页：首先 mmap 比您需要的多 2 页，全部使用 PROT_NONE，然后使用 mprotect制作除第一页和最后一页以外的所有页面PROT_READ|PROT_WRITE。完成后立即使用munmap 释放它。
类似心脏出血的问题，强大的防御：派生一个子进程来执行所有加密。

【讨论】：