弱熵源值得吗？

Question

我维护一个可以部署到具有高度多样化功能的嵌入式设备上的操作系统。将操作系统移植到设备的一个方面是声明可用的熵源(包括但不限于专用TRNG外围设备)，这些源将用于为CSPRNG播撒种子。软件这一部分的安全目标是确保CSPRNG在每次实例化后都具有足够的熵。(也可能有一种方法可以在重新启动过程中保存随机种子，但在这里，我担心没有保存的随机种子，因此RNG只带有熵源。)

配置机制允许被认为“弱”的源。弱源被混合到熵池中，但是它们的贡献毫无意义:它们不会增加测量可用熵的计数器。文件建议将当前时间以微秒或纳米秒的分辨率宣布为弱熵源。

我正在考虑删除弱熵源的概念，只推荐强熵源。我可以看到两个方向的定性论点，但我不知道如何权衡这些论点。

• 支持:即使是薄弱的来源也是有用的。如果对手无法访问设备的初始化时间，一个细粒度的时钟值可能会增加大约30位的熵，这本身是不够的，但可以帮助补偿一个合适的TRNG源，但没有达到应有的强度(例如，由于不太理想的温度或电压)。
• 支持:由于系统期望来自强源的同样数量的熵，无论弱源是否存在，包含弱源不会直接造成安全性损失，所以我们也可以将它们包括在内。
• Con:任何特性都会增加复杂性，因此为了安全起见，默认的选择应该是不具有特性。但就系统设计而言，成本实际上是零:弱源只是系统地返回估计0位熵的源，而强源通常每次返回一个或多个比特。
• 弱来源降低了可测试性。通过两次实例化系统并检查get_random()是否返回不同的值，很容易检测系统是否没有熵。如果系统同时具有弱熵源和强源，且强源行为不正常，则很难通过测试来检测。例如，如果只从OpenSSL臭名昭著的种子错误种子，而不是进程ID，那么发现/dev/urandom的速度要快得多。

还有其他我错过的重要论点吗？总的来说，弱熵源值得吗，还是适得其反？

Answer 1

您还没有澄清设备对熵的要求，所以我假设它是通过其他公开的通道参与某种安全的交换。

我认为你实际上已经暗示了一种量化问题中事物的方法，你提到了高分辨率的时钟可以贡献多达30位的CS熵，但这还不够。

如果您知道您参与的是什么协议(假设TLS1.3)，那么您将知道至少存在32+32 (对于短暂的客户端密钥和客户端随机性贡献)以及另外12字节的高质量熵(对于ChaCha20Poly1305对称密码中的当前)。

(请访问Michael关于TLS 1.3 https://tls13.ulfheim.net/的非常有用的详细信息。)

..。因此，为了支持包含弱源的观点:在没有高质量的随机性源的情况下，设备客户端不能在像TLS这样的具有某种随机IV或前向保密的协议中贡献共享熵。