一个合理安全且具有可移植性的为私钥分配内存的方法是什么？

Question

一个合理安全且具有可移植性的为私钥分配内存的方法是什么？

clinuxunix

7

我正在寻找为256位私钥分配存储空间的“最佳实践”。我认为至少，密钥不应该被分页到磁盘上，并且可能存在其他攻击向量（如Heartbleed）。解决方案必须可移植到Linux和BSD。

一些我已经看过的东西：

- TRESOR（不支持BSD） - Akamai的“安全堆” - David Shaw的secmalloc - 使用mlock禁止分页 - 只需使用malloc并不必担心。粗略阅读表明这可能是LibreSSL所做的。

有什么建议吗？

- Drew

顺便问一下，你在使用什么加密方式，以至于256位密钥才能提供任何安全性？ - R.. GitHub STOP HELPING ICE

现代对称密码（如AES）？像4096位这样的大尺寸是用于非对称算法，如RSA。 - nobody

OP说“私钥”，所以我认为是公钥加密，但也许意图只是“需要保密的密钥”。 - R.. GitHub STOP HELPING ICE

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- R.. GitHub STOP HELPING ICE · Accepted Answer

除非您有特殊需求，否则只使用malloc是明智的选择。它的优点是valgrind等工具可以检测到使用错误，这是您可能担心的漏洞类型产生的主要方式之一。正如OpenSSL事件所显示的那样，尝试做一些花哨的事情并搞砸它是一个重大风险。

如果您有更高要求，那么很大程度上取决于您的使用情况。我假设您的密钥是短暂的，否则避免将其存储在磁盘上就没有什么意义了。以下是我推荐的特定风险缓解措施：

- 交换到磁盘：如果您的系统需要防范物理攻击，则根本不应该有交换。试图通过mlock来保护特定数据实际上是一种玩笑。只需关闭交换并安装足够的内存即可轻松解决。 mlock应被视为实时调度功能，而不是安全功能。 - 类似Heartbleed的问题，中等防御：通过mmap分配内存并在两侧设置守卫页面：首先mmap比您需要的多2个页面，全部使用PROT_NONE，然后使用mprotect使除第一个和最后一个页面外的所有页面都是PROT_READ|PROT_WRITE。完成后使用munmap释放它。 - 类似Heartbleed的问题，强大防御：派生一个子进程来执行所有的加密操作。