亚马逊AWS官方博客
OpenSource | 更好地随机生成OpenSSL
作者：Colm MacCarthaigh
2015 年，AWS 推出了 s2n，它以全新的开源方式来实施 TLS/SSL 协议，保证数据在网络上传输时的私密性和完整性。s2n 的特点是：安全、简单、小巧、快速。
该项目发展势头良好，而且应用广泛。2 月份，我们的 CISO Stephen Schmidt 说：“我们已将 Amazon Simple Storage Service (Amazon S3) 商业区域中所有内部和外部 SSL 流量的 OpenSSL 替换为 s2n。”在接下来的几个月，我们还将公布其他使用 s2n 的应用程序。
能够生成安全的随机数字是所有加密协议的重要基础。TLS/SSL 协议使用随机数字生成加密密钥，为所传输的数据提供安全保护。如果随机数字可以预测，那么不管加密本身有多强都没有用，因为密钥本身会泄漏。多年来，尽管创建了许多随机数字生成器，但不幸的是，其中几种并不安全，要么是因为算法遭到入侵并且本身就是可预测或有偏差的，要么是因为随机数字生成器只是勉强基于种子值 (又称“熵”) 进行初始化，而种子值可通过某种方式猜测或泄漏出来。
我们在构建 s2n 时必须选择使用一种安全的随机数字生成器。在对众多生成器的安全性和性能进行评估后，我们选择了采用防预测模式的 AES_CTR_DRBG (即“Advanced Encryption Standard Counter Mode Deterministic Random Bit Generator”[高级加密标准计数器模式确定性随机位生成器] 的缩写)。此生成器的特点是：提供了书面规范、简单、易于理解、以 AES 的安全性为基础、具有参考测试矢量，并且我们可对其进行正式验证。
今年年初，我们使用 Galois 完成了对 AES_CTR_DRBG 实施的检验，并且经过正式验证后确认我们 s2n 中的代码堪比书面规范。
最近，OpenSSL 和 glibc 项目都希望替换他们的随机数字生成器。连同 AES_CTR_DRBG 一起，它们在某种程度上也依赖于 s2n 中的工作，以及可应用于代码的正式验证的可用性。这听起来相当令人兴奋。
但真正让我们感到兴奋的是，在使用 libc 的过程中，我们还能够从 Linux 的另一项重大变革中受益。去年，我们为 Linux 内核推荐了新的 madvise() 选项。该选项基于 OpenBSD 的 MINHERIT_ZERO，可将内存区域标记为 WIPEONFORK，这意味着，在调用 fork() 后可以直接通过一个子进程将这些区域清零。
fork() 调用会复制进程：这是服务器等扩展自身的方式。例如，Web 服务器软件通常会调用 fork() 来为自己创建多个副本，每个副本处理一个或多个不同的连接，并且每个副本都可以在自己的 CPU 核心上运行。通常，在软件调用 fork() 时，会发生间接核分裂：一个进程变成两个，而这两个进程实际上是相同的，而且占用的内存也是相同的。
因此，这会加速扩展并提高其可靠性，但这对于随机数字生成器来说却很危险。原因在于，调用 fork 后，两个进程都会运行相同的生成器，使用相同的种子进行初始化，并且可以生成相同的数字序列。一个进程可能会在公开环境中使用这些随机数字 (例如，启动每条 TLS“hello”消息的随机字节序列)，而另一个进程可能会在私有环境中使用它们 (例如，生成密钥)。就安全性而言，这非常危险，因为密钥现在实际上已经公开了。
很长时间以来，s2n 都采用三种“深度防御”缓解措施来应对这个问题。首先，如前所述，s2n 使用所谓的“防预测”模式，这意味着，只要有适当的硬件，s2n 在每次调用时都会为随机数字生成器提供更多的熵 (来自硬件)。其次，s2n 的随机数字生成器按类型归类：每个线程都有一个“公共”生成器和一个“私有”生成器，二者分别进行初始化。最后，s2n 使用“pthread_atfork”调用来检测 fork() 调用并重置随机数字生成器。
设计新的 WIPEONFORK 选项是为了提供比最后一个缓解措施更稳定可靠的缓解方法，因为在某些情况下，可以绕过 pthread_atfork 调用。如果您运行的应用程序绕过 pthread_atfork，对于同时还缺乏硬件熵的平台来说，将只有一层防御可用来应对遭到破坏的随机数字生成器。以下情况十分罕见：极少应用程序会绕过 pthread_atfork，硬件熵现在也很常见，但即使在不常见的情况下，我们也偏向于至少提供两层防御。
WIPEONFORK 无法绕过，因为在进行 fork() 调用时，内核本身也会擦除随机数字生成器内存。新进程将会重新初始化随机数字生成器，确保没有复制风险。
这确实是社区共同努力的结晶。Red Hat 的 Florian Weimer 得到了 Rik Van Riel 的帮助，在连接补丁并指导其完成贡献流程方面，Rik Van Riel 承担了大部分工作。OpenSSL 的 Rich Salz 也做出了重要贡献。在他们的帮助下，该补丁自 9 月初便已纳入 Linus 树和内核操作说明。如今，所有人都可以在 Linux 4.14 版本中使用该补丁。
也就是说，我们可以在自己及客户使用的平台上生成更可靠的随机数字，这是加密安全的基础。
以上只是两个示例，展示了我们加入开源社区的方式。今后，我们还会就此话题展开更多讨论。
Colm 是 AWS 的首席高级工程师，也是 Apache 软件基金会的老会员。Colm 致力于研究 EC2、加密和 Apache httpd。在业余时间，他喜欢演奏爱尔兰音乐。