更好地随机生成 OpenSSL

阅读数:53 2019 年 10 月 29 日 08:00

更好地随机生成OpenSSL

2015 年, AWS 推出了 s2n ,它以全新的开源方式来实施 TLS/SSL 协议,保证数据在网络上传输时的私密性和完整性。s2n 的特点是:安全、简单、小巧、快速

该项目发展势头良好,而且应用广泛。2 月份,我们的 CISO Stephen Schmidt 说:“我们已将 Amazon Simple Storage Service (Amazon S3) 商业区域中所有内部和外部 SSL 流量的 OpenSSL 替换为 s2n。”在接下来的几个月,我们还将公布其他使用 s2n 的应用程序。

更好地随机生成OpenSSL

能够生成安全的随机数字是所有加密协议的重要基础。TLS/SSL 协议使用随机数字生成加密密钥,为所传输的数据提供安全保护。如果随机数字可以预测,那么不管加密本身有多强都没有用,因为密钥本身会泄漏。多年来,尽管创建了许多随机数字生成器,但不幸的是,其中几种并不安全,要么是因为算法遭到入侵并且本身就是可预测或有偏差的,要么是因为随机数字生成器只是勉强基于种子值 (又称“熵”) 进行初始化,而种子值可通过某种方式猜测或泄漏出来。

我们在构建 s2n 时必须选择使用一种安全的随机数字生成器。在对众多生成器的安全性和性能进行评估后,我们选择了采用防预测模式的 AES_CTR_DRBG (即“Advanced Encryption Standard Counter Mode Deterministic Random Bit Generator”[高级加密标准计数器模式确定性随机位生成器] 的缩写)。此生成器的特点是:提供了书面规范、简单、易于理解、以 AES 的安全性为基础、具有参考测试矢量,并且我们可对其进行正式验证。

更好地随机生成OpenSSL

今年年初,我们使用 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 版本中使用该补丁。

也就是说,我们可以在自己及客户使用的平台上生成更可靠的随机数字,这是加密安全的基础。

以上只是两个示例,展示了我们加入开源社区的方式。今后,我们还会就此话题展开更多讨论。

了解更多关于 s2n、使用方法以及如何为其做出贡献的信息。

Colm 是 AWS 的首席高级工程师,也是 Apache 软件基金会的老会员。Colm 致力于研究 EC2、加密和 Apache httpd。在业余时间,他喜欢演奏爱尔兰音乐。

作者介绍:
Deirdré Straughan

复制代码
Deirdré Straughan 是 AWS 开源团队的内容负责人,致力于推广技术和帮助他人开展这方面的工作已有 30 年的时间。截至目前,她撰写了一本书并参与了两本以上书籍的编辑;她还开展和进行技术培训、制作了数百个视频并进行技术讲座直播;此外,她还负责多个技术博客的编写、编辑和管理以及负责技术活动的管理。自 2010 年起,她便利用自己的一技之长,通过各种方式投身云计算,投身开源的时间还要长一些。她于 20176 月加入 AWS。她的 Twitter 账号是 @deirdres。

本文转载自 AWS 技术博客。

原文链接:
https://amazonaws-china.com/cn/blogs/china/better-random-number-generation-for-openssl/

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布