基本上，每个带有硬件随机数生成器(RNG)的物联网设备都存在一个严重的漏洞，该漏洞无法使设备正确生成随机数，这会破坏任何上游使用者的安全性。
为了进行安全操作，计算机需要通过RNG生成机密信息。然后，这些秘密构成了密码学、访问控制、身份验证等的基础。生成这些秘密的确切方式和原因的详细信息因每次使用而异，但规范示例是生成加密密钥：
Alice和Bob尝试使用RNG进行私人对话
为了让Alice和Bob秘密通信，他们需要使用RNG生成共享秘密。Eve起初并不知道这个号码是阻止她泄露通讯机密的唯一原因。所以，无论是用于身份验证的SSH密钥还是用于授权的会话令牌，随机数都是计算机安全的基石之一。
但在物联网设备中，这些“随机”选择的数字并不总是像你希望的那样随机。事实上，在许多情况下，设备选择的加密密钥为0或更糟。
截至年，大多数新的物联网系统(soc)都有专门的硬件RNG外设，旨在解决这个问题。但不幸的是，事情并没有那么简单。所以，如何使用外围设备就显得至关重要。
调用硬件RNG时产生的漏洞
当开发人员未能检查错误代码响应时，会发生一个更明显的漏洞，这通常会导致与安全相关的使用所需要的数字不是那么随机。
当物联网设备需要随机数时，它会通过设备的SDK或越来越多地通过物联网操作系统调用专用硬件RNG。当然，函数调用的名称各不相同，但它发生在硬件抽象层(HAL)中。这是由设备制造商创建的API，旨在让你可以更轻松地通过C代码与硬件交互，而无需设置和检查设备独有的特定寄存器。HAL函数看起来像这样：
我们关心的有两个部分：
一个名为out_number的输出参数，这是函数放置随机数的地方；它是一个指向无符号32位整数的指针。
指定任何漏洞情况的返回值，根据设备的不同，它可以是布尔值或任意数量的枚举漏洞条件。
所以，你可能会问的第一个问题是，“有多少人在野外实际检查这个漏洞代码?”不幸的是，答案是几乎没有人。
例如，只需查看使用MediaTekSoCHAL功能的GitHub结果：
甚至是FreeRTOS（一种流行的物联网操作系统）的抽象层（参见此处的GitHub）：
请注意，返回代码普遍没有被检查。尽管这不是这两个示例所独有的。这正是物联网行业的做法，你会在每个SDK和物联网操作系统中发现这种行为。
发生最糟糕的情况
所以设备不会检查RNGHAL函数的漏洞代码。但它到底有多糟糕呢？这取决于特定的设备。
RNG外设的HAL功能可能会由于多种原因而失败，但迄今为止最常见和可利用的是设备的熵已用完。硬件RNG外围设备通过各种方式，例如模拟传感器或EMF读数，将熵从设备中提取出来，但不能无限供应。它们每秒只能产生这么多的随机位。如果你在RNGHAL函数没有提供任何随机数时尝试调用它，它将失败并返回漏洞代码。因此，如果设备试图过快地获取过多的随机数，则调用将开始失败。
但这就是随机数的问题，只有一个是不够的。当设备需要生成新的位私钥时，作为一个保守的例子，它会循环调用RNGHAL函数。这开始严重影响硬件的计算能力，而在实践中，他们往往做不到。最初的几个调用可能成功，但它们通常很快就会开始导致漏洞。
那么，当HAL函数失效时，它会给你一个随机数字带来什么呢?根据硬件的不同，有以下几种：
部分熵
数字0
未初始化的内存
那不应该存在
这些都不是很好，但未初始化的内存?这是怎么发生的?记住随机数是一个输出指针。然后考虑下面的伪代码：
random_number变量被声明并存在于堆栈中，但从未被初始化。如果HAL函数的行为使得它在发生漏洞时从不覆盖输出变量(这是常见行为)，则变量中的值将包含未初始化的RAM，然后通过网络将其发送给其他人。不要以为这些都是理论上的分析，现在市面上的设备都在使用0或更糟的加密密钥。
Keyfactor在年对公开可用的RSA证书进行的一项分析发现，所有个证书中有1个容易受到已知攻击。研究人员发现，物联网设备中的随机数生成是罪魁祸首之一，但这也只是猜测。
如果你是正在为安全通信生成加密密钥的网络堆栈，你应该如何“处理”漏洞？实际上只有两种选择：
中止，杀死整个进程；
在HAL函数上旋转循环无限长的时间，直到调用完成，阻止所有其他进程并在进程中使用%的CPU。
这两种解决方案都是不可接受的。这就是开发人员忽略漏洞条件的原因，替代方案很糟糕，围绕RNG硬件的生态系统对他们没有好处。
即使开发人员有充足的时间，情况也没有好到哪里去。有些设备，如STM32，有大量的文档，甚至供应商提供的随机性证明白皮书，但这些都是例外。很少有设备甚至对硬件RNG应该如何工作有基本的描述，也很少有设备拥有关于预期操作速度、安全的操作温度范围，和随机的统计证据等基本内容的任何类型的文档。
有趣的是，试图仔细按照STM32文档的操作说明，仍然设法创建漏洞处理漏洞响应的代码。当出现漏洞响应时，需要多次尝试和大量代码才能正确阻止对RNG和自旋循环的额外调用。即使这样，我们也观察到有问题的结果，这让我们怀疑我们的代码。难怪开发人员在做物联网RNG。
CSPRNG子系统
伪随机数产生器（CryptographicallySecurePseudo-RandomNumberGenerator，简称CSPRNG）是一个工具，常用的算法有MD5或者SHA1等标准，它们可以将不定长的信息变成定长的二进位或者二进位随机数。
CSPRNG子系统组件
当应用程序在Linux服务器上需要加密安全的随机数时，它不会直接从硬件RNG读取或调用某些HAL函数并阻止漏洞代码。它只是通过/dev/urandom读取。这是一个加密安全的伪随机数生成器(CSPRNG)子系统，可作为API提供给应用程序。每个主要操作系统上也有类似的子系统：Windows、iOS、MacOS、Android、BSD，等等。
重要的是，对/dev/urandom的调用永远不会失败并且永远不会阻止程序执行。CSPRNG子系统可以立即产生无穷无尽的强随机数序列。这直接解决了HAL函数要么阻止程序执行要么失败的问题。
CSPRNG子系统的另一个关键设计特征是熵池。这是为了从各种来源获取熵，包括硬件RNG(HWRNG)。由于异或运算的魔力，所有这些单独的弱熵源都可以组合成一个强熵源。这是生成加密安全随机数的正确方法，并且已经成为所有地方的行业标准，除了物联网。
为什么你真的需要一个CSPRNG子系统
设计一个完整的CSPRNG子系统听起来真的很难，尤其是当你的小工具没有使用这些新的物联网操作系统之时。也许只需要咬紧牙关，在RNGHAL功能上进行循环就足够了。这样就能得到很好的随机数，对吧？
本节将否定你认为硬件RNG完全安全的想法。
易受攻击的参考代码
没有人会完全从零开始编写源代码，尤其是在物联网设备领域。总有一些参考代码或示例文档可供开发人员参考。与硬件的接口对于任何设备来说都是棘手的，更不用说像硬件RNG外围设备这样挑剔的设备了。
当设备的参考代码包含漏洞时，它会向下传播到使用它的每个设备。毕竟，开发人员应该如何知道易受攻击的参考实现和古怪的参考实现之间的区别？下面是一些例子：
使用HWRNG传播不安全的PRNG
像libcrand()这样的prng是非常不安全的，因为它们产生的数字揭示了RNG的内部状态信息。它们适用于与安全性无关的上下文，因为它们快速且易于实现。但使用它们来加密密钥等内容会导致设备安全性的灾难性崩溃，因为所有的数字都是可预测的。
不幸的是，许多支持硬件RNG的SDK和操作系统在幕后使用不安全的PRNG。NordicSemiconductor的nrfSoC的Contiki-ng物联网操作系统通过使用硬件RNG传播不安全的libcrand()函数来实现这一点：
转载请注明：http://www.0431gb208.com/sjszlff/505.html
