數十億物聯網設備使用的硬件隨機數生成器存在嚴重漏洞，無法正常生成隨機數，導致設備安全性下降，面臨攻擊風險。

　　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實現可以作為一個很好的參考。