/dev/random 是一种加密安全伪随机数生成器 (CSPRNG)，已知有一个恼人的问题：阻塞。 本文介绍了如何解决该问题。
在过去的几个月中，内核中的随机数生成工具已被稍微修改，但该子系统中的问题已在更广泛的过程中得到解决。 。 最多 这样做是为了防止 getrandom() 系统调用在系统启动时长时间阻塞，但其根本原因是随机池的阻塞行为。 最近的补丁将删除该池，并且预计它将前往主核心。
Andy Lutomirski 在 XNUMX 月底发布了该补丁的第三个版本。 他贡献 “随机 Linux API 的两个主要语义变化”。 该补丁向 getrandom() 系统调用添加了一个新的 GRND_INSECURE 标志（尽管 Lutomirsky 将其称为 getentropy()，它是在 glibc 中使用带有固定标志的 getrandom() 实现的）； 此标志导致调用始终返回请求的数据量，但不保证数据是随机的。 内核将尽最大努力生成给定时间的最佳随机数据。 “也许最好的办法就是称之为‘不安全’ （不安全）以防止此 API 被用于需要安全的事情。”
这些补丁还删除了阻塞池。 内核当前维护了两个随机数据池，一个对应于/dev/random，另一个对应于/dev/urandom，如下所述 2015年。 阻塞池是/dev/random的池； 该设备的读取将被阻塞（意思是它的名字），直到从系统收集到“足够”的熵来满足请求。 如果池中没有足够的熵，从此文件的进一步读取也会被阻止。
删除锁池意味着从 /dev/random 读取的行为类似于 getrandom() ，其中标志设置为零（并将 GRND_RANDOM 标志转变为 noop）。 一旦加密随机数生成器 (CRNG) 初始化，从 /dev/random 读取和调用 getrandom(...,0) 将不会阻塞，并将返回请求的随机数据量。
卢托米尔斯基 说： “我认为 Linux 阻塞池已经过时了。 CRNG Linux 生成的输出甚至足以用于密钥生成。 区块链在任何物质意义上并不强大，需要大量价值可疑的基础设施来支持它。”
进行这些更改的目的是确保现有程序不会真正受到影响，事实上，长时间等待 GnuPG 密钥生成等问题会减少。
“这些事件不得扰乱任何现有计划。 /dev/urandom 保持不变。 /dev/random 仍然在启动时立即阻塞，但阻塞程度比以前少。 具有现有标志的 getentropy() 将返回与以前一样适合实际目的的结果。”
Lutomirsky 指出，内核是否应该提供所谓的“真正的随机数”仍然是一个悬而未决的问题，而这正是阻塞内核在某种程度上应该做的事情。 他认为这样做的原因只有一个：“遵守政府标准”。 Lutomirsky 建议，如果内核要提供此功能，则应通过完全不同的接口来完成，或者应将其移至用户空间，从而允许用户检索可用于创建此类锁池的原始事件样本。
斯蒂芬·穆勒 (Stephan Müller) 建议他的套装 Linux 随机数生成器 (LRNG)（目前已发布版本 26）可以为需要它的应用程序提供真正的随机数。 LRNG“完全符合用于生成随机位的熵源的 SP800-90B 指南”，使其成为政府标准问题的解决方案。
马修·加勒特（Matthew Garrett）反对“真正的随机数据”一词，指出原则上可以对采样的设备进行足够精确的建模，以使其可预测：“我们不是在这里采样量子事件。”
Müller 回应称，该术语来自德国标准 AIS 31，用于描述随机数生成器，该生成器仅“以与底层噪声源产生熵相同的速率”产生结果。
抛开术语差异不谈，拥有 LRNG 补丁建议的锁池只会导致各种问题，至少在没有特权的情况下访问它是这样。
正如卢托米尔斯基所说： “这并不能解决问题。 如果两个不同的用户运行像 gnupg 这样的愚蠢程序，他们只会互相耗尽对方的资源。 我发现 /dev/random 目前存在两个主要问题：它容易受到 DoS（即资源耗尽、恶意影响或类似的情况），并且由于使用它不需要任何权限，因此它也容易被滥用。 Gnupg错了，彻底崩溃了。 如果我们添加一个新的非特权接口供 gnupg 和类似程序使用，我们将再次失败。”
Mueller 指出，添加 getrandom() 现在将允许 GnuPG 使用此接口，因为它将提供池已初始化的必要保证。 根据与 GnuPG 开发人员 Werner Koch 的讨论，Mueller 认为保证是 GnuPG 目前直接从 /dev/random 读取的唯一原因。 但是，如果存在容易受到拒绝服务攻击的非特权接口（如今天的 /dev/random），Lutomirsky 认为它将被某些应用程序滥用。
Linux 随机数子系统的开发人员 Theodore Yue Tak Ts'o 似乎改变了他对阻塞池需求的看法。 他说，删除这个池将有效地消除 Linux 具有真正的随机数生成器（TRNG）的想法： “这不是废话，因为这正是 *BSD 一直在做的事情。”
他还担心提供TRNG机制只会成为应用程序开发人员的诱饵，并认为事实上，考虑到Linux支持的硬件类型不同，内核中无法保证TRNG。 即使仅使用 root 权限操作设备也无法解决问题： “出于安全目的，应用程序开发人员指定将他们的应用程序安装为 root，因此这是访问‘真正好的’随机数的唯一方法。”
穆勒询问曹是否放弃了他本人长期以来提出的阻塞池实施方案。 曹回应说，他计划采用 Lutomirsky 的补丁，并积极反对向内核添加阻塞接口。
“内核无法保证噪声源是否已被正确表征。 GPG 或 OpenSSL 开发人员唯一能得到的就是一种模糊的感觉，即 TRUERANDOM“更好”，并且由于他们想要更高的安全性，因此他们无疑会尝试使用它。 在某些时候它会被阻止，当其他一些聪明的用户（可能是分发专家）将它插入到 init 脚本中并且系统停止工作时，用户只能向 Linus Torvalds 本人抱怨。”
Cao 还主张为密码学家和那些真正需要 TRNG 的人提供一种在用户空间中收获自己的熵的方法，以便在他们认为合适的时候使用。 他表示，收集熵并不是内核可以在其支持的所有不同硬件上执行的过程，内核本身也无法估计不同来源提供的熵量。
“内核不应该将不同的噪声源混合在一起，并且当它尝试在极其简单的 CPU 上玩某种“抽搐熵游戏”时，它当然不应该试图声称知道它获得了多少位熵。 “面向消费者用户的架构。物联网/嵌入式情况下，一切都与单个主振荡器不同步，没有 CPU 指令来重新排序或重命名寄存器等。”
“你可以谈论提供尝试进行这些计算的工具，但这些事情必须在每个用户的硬件上完成，这对于大多数发行版用户来说根本不切实际。 如果这仅适用于密码学家，那么就让它在他们的用户空间中完成。 我们不要简化 GPG、OpenSSL 等，以免每个人都说“我们想要“真正的随机性”，并且不会满足于更少。” 我们可以讨论如何为密码学家提供接口，以便他们可以通过访问主要噪声源（分离和命名）来获取所需的信息，并且也许噪声源可以以某种方式向库或用户空间应用程序验证自身身份。”
对于这样的接口可能是什么样子进行了一些讨论，因为例如某些事件可能存在安全隐患。 曹指出，键盘扫描代码（即击键）作为熵收集的一部分被混合到一个池中：“将其带入用户空间，即使是通过特权系统调用，至少可以说是不明智的。” 其他事件计时很可能会通过侧通道造成某种信息泄漏。
因此，Linux 随机数子系统的一个长期存在的问题似乎正在得到解决。 随机数子系统最近发生的变化实际上仅导致使用它时出现 DoS 问题。 现在有一些有效的方法可以获得内核可以提供的最佳随机数。 如果 TRNG 在 Linux 上仍然需要，那么将来需要解决这个缺陷，但很可能这不会在内核本身内完成。
一些广告🙂
感谢您与我们在一起。 你喜欢我们的文章吗？ 想看更多有趣的内容？ 通过下订单或推荐给朋友来支持我们， , 我们为您发明的入门级服务器的独特模拟： （适用于 RAID1 和 RAID10，最多 24 个内核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 数据中心便宜 2 倍？ 只有这里 在荷兰！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 阅读
来源： habr.com