数十亿物联网设备使用的硬件随机数生成器存在严重漏洞，无法正常生成随机数，导致设备安全性下降，面临攻击风险。

　　Bishop Fox研究人员称，这个漏洞影响了整个物联网行业。关键是漏洞并不存在于单个设备的SDK或任何特定的SoC实现。物联网需要一个伪随机数生成器（CSPRNG）子系统。这个问题不能仅仅通过更改文档和责备用户来解决。对于这样一个CSPRNG子系统来说，最优雅的地方是在一个日益流行的物联网操作系统中。如果您正在从头开始设计一个新设备，建议在操作系统中实现一个CSPRNG。自己编写RNG代码应该被认为是危险的，就像加密代码一样。不管你有多聪明，永远不要自己编写与RNG硬件接口的代码。你几乎肯定会弄错。相反，您应该使用由较低抽象层提供的CSPRNG子系统。不要直接从RNG硬件中使用熵。总的来说，硬件RNG不适合（立即）加密使用。弱熵可以也应该通过软件，通过cspring来修复。

　　“事实证明，当涉及物联网设备时，这些‘随机’选择的数字CSPRNG并不总是像你希望的那样随机，”Bishop Fox研究人员丹·彼得罗和艾伦·塞西尔在上周发表的一份分析报告中说。“事实上，在很多情况下，设备选择的加密密钥是0或更糟。这可能会导致任何上游应用的安全性崩溃。”

　　随机数生成（RNG）是一个至关重要的过程，它支持多个加密应用程序，包括密钥生成、nonces和salt。在传统的操作系统上，它来自一个加密安全的伪随机数生成器（CSPRNG），该生成器使用从高质量种子源获得的熵。

　　当涉及到物联网设备时，这是由一个片上系统（SoC）提供的，它包含一个专用的硬件RNG的外围设备，称为真正的随机数生成器（TRNG），用于从物理进程或专辑音乐（phenomenа）中捕获随机性。

　　研究人员指出当前调用外围设备的方式是不正确的，缺乏对错误代码响应的全面检查，导致产生的随机数不是简单的随机，更糟糕的是可预测的，导致部分熵，未初始化的内存，甚至包含纯零的加密密钥。

　　研究人员指出：“RNG外围设备的HAL功能可能会因各种原因失效，但到目前为止最常见的（也是可利用的）是设备的熵耗尽。”硬件RNG外设通过各种方式（如模拟传感器或EMF读数）将熵从宇宙中提取出来，但并不是无限供应的。

　　“它们每秒只能产生这么多随机比特。如果你尝试调用RNG HAL函数时，它没有任何随机数给你，它将失败并返回一个错误代码。因此，如果设备试图快速获取太多随机号码，呼叫就会开始失败。”

　　这个问题是物联网领域特有的，因为它们缺乏通常带有随机API的操作系统（例如，在类unix操作系统中是“/dev/random”，在Windows中是BCryptGenRandom），研究人员强调了与CSPRNG子系统相关联的更大熵池的好处，这样就消除了“熵源中的任何单点故障”。

　　虽然可以矫正软件更新的问题，理想的解决方案是物联网设备制造商和开发商包括CSPRNG API的种子从一组不同的熵源并确保代码没有忽略错误条件，或未能阻止调用RNG当没有更多的熵是可用时。

　　研究人员说：“这个漏洞的难点之一是，它不是一个简单的‘你在应该曲折的地方曲折了’的情况，可以很容易地修补。”他们强调了在物联网操作系统中实现CSPRNG的必要性。“为了解决这个问题，必须在物联网设备中设计一个实质性和复杂的功能。”

　　最后，研究人员建议：

　　对设备所有者而言：

　　留意更新，并确保在它们可用时应用它们。这是一个可以用软件解决的问题，但可能需要一些时间。与此同时，要小心不要太相信你的物联网设备。对于需要连接互联网的家用设备，把它们放在一个只能连接到外部的专用网络段。这将有助于防止任何漏洞蔓延到你的网络。

　　对物联网设备开发人员而言：

　　如果可能，请选择包含从包括硬件 RNG 在内的各种熵源中播种的 CSPRNG API 的物联网设备。如果没有可用的 CSPRNG 并且您别无选择，请仔细检查您所依赖的库以及您自己的代码，以确保您没有使用从未初始化的内存读取、忽略硬件 RNG 外设寄存器或错误的代码条件，或者在没有更多可用熵时无法阻塞。仔细考虑阻塞不是可行选项的实时情况的影响。

　　对设备制造商/物联网操作系统而言：

　　在SDK中弃用和/或禁用任何直接使用RNG HAL函数。相反，要包含一个CSPRNG API，该API使用健壮的、不同的熵源和适当的硬件RNG处理。Linux内核的/dev/urandom实现可以作为一个很好的参考。