基本上，每個(gè)帶有硬件隨機(jī)數(shù)生成器 (RNG) 的物聯(lián)網(wǎng)設(shè)備都存在一個(gè)嚴(yán)重的漏洞，該漏洞無法使設(shè)備正確生成隨機(jī)數(shù)，這會(huì)破壞任何上游使用者的安全性。
為了進(jìn)行安全操作，計(jì)算機(jī)需要通過 RNG 生成機(jī)密信息。然后，這些秘密構(gòu)成了密碼學(xué)、訪問控制、身份驗(yàn)證等的基礎(chǔ)。生成這些秘密的確切方式和原因的詳細(xì)信息因每次使用而異，但規(guī)范示例是生成加密密鑰：
Alice 和 Bob 嘗試使用 RNG 進(jìn)行私人對(duì)話
為了讓Alice和Bob秘密通信，他們需要使用 RNG 生成共享秘密。Eve 起初并不知道這個(gè)號(hào)碼是阻止她泄露通訊機(jī)密的唯一原因。所以，無論是用于身份驗(yàn)證的 SSH 密鑰還是用于授權(quán)的會(huì)話令牌，隨機(jī)數(shù)都是計(jì)算機(jī)安全的基石之一。
但在物聯(lián)網(wǎng)設(shè)備中，這些“隨機(jī)”選擇的數(shù)字并不總是像你希望的那樣隨機(jī)。事實(shí)上，在許多情況下，設(shè)備選擇的加密密鑰為0或更糟。
截至2021年，大多數(shù)新的物聯(lián)網(wǎng)系統(tǒng)(soc)都有專門的硬件RNG外設(shè)，旨在解決這個(gè)問題。但不幸的是，事情并沒有那么簡(jiǎn)單。所以，如何使用外圍設(shè)備就顯得至關(guān)重要。
調(diào)用硬件 RNG時(shí)產(chǎn)生的漏洞
當(dāng)開發(fā)人員未能檢查錯(cuò)誤代碼響應(yīng)時(shí)，會(huì)發(fā)生一個(gè)更明顯的漏洞，這通常會(huì)導(dǎo)致與安全相關(guān)的使用所需要的數(shù)字不是那么隨機(jī)。
當(dāng)物聯(lián)網(wǎng)設(shè)備需要隨機(jī)數(shù)時(shí)，它會(huì)通過設(shè)備的 SDK 或越來越多地通過物聯(lián)網(wǎng)操作系統(tǒng)調(diào)用專用硬件 RNG。當(dāng)然，函數(shù)調(diào)用的名稱各不相同，但它發(fā)生在硬件抽象層 (HAL) 中。這是由設(shè)備制造商創(chuàng)建的 API，旨在讓你可以更輕松地通過 C 代碼與硬件交互，而無需設(shè)置和檢查設(shè)備獨(dú)有的特定寄存器。HAL函數(shù)看起來像這樣：
我們關(guān)心的有兩個(gè)部分：
● 一個(gè)名為 out_number 的輸出參數(shù)，這是函數(shù)放置隨機(jī)數(shù)的地方；它是一個(gè)指向無符號(hào) 32 位整數(shù)的指針。
● 指定任何漏洞情況的返回值，根據(jù)設(shè)備的不同，它可以是布爾值或任意數(shù)量的枚舉漏洞條件。
所以，你可能會(huì)問的第一個(gè)問題是，“有多少人在野外實(shí)際檢查這個(gè)漏洞代碼?”不幸的是，答案是幾乎沒有人。
例如，只需查看使用 MediaTek 7697 SoC HAL 功能的 GitHub結(jié)果：
甚至是 FreeRTOS(一種流行的物聯(lián)網(wǎng)操作系統(tǒng))的抽象層(參見此處的 GitHub)：
請(qǐng)注意，返回代碼普遍沒有被檢查。盡管這不是這兩個(gè)示例所獨(dú)有的。這正是物聯(lián)網(wǎng)行業(yè)的做法，你會(huì)在每個(gè)SDK和物聯(lián)網(wǎng)操作系統(tǒng)中發(fā)現(xiàn)這種行為。
發(fā)生最糟糕的情況
所以設(shè)備不會(huì)檢查 RNG HAL函數(shù)的漏洞代碼。但它到底有多糟糕呢?這取決于特定的設(shè)備。
RNG 外設(shè)的 HAL 功能可能會(huì)由于多種原因而失敗，但迄今為止最常見和可利用的是設(shè)備的熵已用完。硬件 RNG 外圍設(shè)備通過各種方式，例如模擬傳感器或 EMF 讀數(shù)，將熵從設(shè)備中提取出來，但不能無限供應(yīng)。它們每秒只能產(chǎn)生這么多的隨機(jī)位。如果你在 RNG HAL函數(shù)沒有提供任何隨機(jī)數(shù)時(shí)嘗試調(diào)用它，它將失敗并返回漏洞代碼。因此，如果設(shè)備試圖過快地獲取過多的隨機(jī)數(shù)，則調(diào)用將開始失敗。
但這就是隨機(jī)數(shù)的問題，只有一個(gè)是不夠的。當(dāng)設(shè)備需要生成新的 2048 位私鑰時(shí)，作為一個(gè)保守的例子，它會(huì)循環(huán)調(diào)用RNG HAL函數(shù)。這開始嚴(yán)重影響硬件的計(jì)算能力，而在實(shí)踐中，他們往往做不到。最初的幾個(gè)調(diào)用可能成功，但它們通常很快就會(huì)開始導(dǎo)致漏洞。
那么，當(dāng)HAL函數(shù)失效時(shí)，它會(huì)給你一個(gè)隨機(jī)數(shù)字帶來什么呢?根據(jù)硬件的不同，有以下幾種：
● 部分熵
● 數(shù)字 0
● 未初始化的內(nèi)存
那不應(yīng)該存在
這些都不是很好，但未初始化的內(nèi)存?這是怎么發(fā)生的?記住隨機(jī)數(shù)是一個(gè)輸出指針。然后考慮下面的偽代碼：
random_number 變量被聲明并存在于堆棧中，但從未被初始化。如果 HAL函數(shù)的行為使得它在發(fā)生漏洞時(shí)從不覆蓋輸出變量(這是常見行為)，則變量中的值將包含未初始化的 RAM，然后通過網(wǎng)絡(luò)將其發(fā)送給其他人。不要以為這些都是理論上的分析，現(xiàn)在市面上的設(shè)備都在使用0或更糟的加密密鑰。
Keyfactor在2019年對(duì)公開可用的RSA證書進(jìn)行的一項(xiàng)分析發(fā)現(xiàn)，所有172個(gè)證書中有1個(gè)容易受到已知攻擊。研究人員發(fā)現(xiàn)，物聯(lián)網(wǎng)設(shè)備中的隨機(jī)數(shù)生成是罪魁禍?zhǔn)字唬@也只是猜測(cè)。
如果你是正在為安全通信生成加密密鑰的網(wǎng)絡(luò)堆棧，你應(yīng)該如何“處理”漏洞?實(shí)際上只有兩種選擇：
● 中止，殺死整個(gè)進(jìn)程；
● 在 HAL函數(shù)上旋轉(zhuǎn)循環(huán)無限長(zhǎng)的時(shí)間，直到調(diào)用完成，阻止所有其他進(jìn)程并在進(jìn)程中使用 100% 的 CPU。
這兩種解決方案都是不可接受的。這就是開發(fā)人員忽略漏洞條件的原因，替代方案很糟糕，圍繞 RNG 硬件的生態(tài)系統(tǒng)對(duì)他們沒有好處。
即使開發(fā)人員有充足的時(shí)間，情況也沒有好到哪里去。有些設(shè)備，如STM32，有大量的文檔，甚至供應(yīng)商提供的隨機(jī)性證明白皮書，但這些都是例外。很少有設(shè)備甚至對(duì)硬件 RNG 應(yīng)該如何工作有基本的描述，也很少有設(shè)備擁有關(guān)于預(yù)期操作速度、安全的操作溫度范圍，和隨機(jī)的統(tǒng)計(jì)證據(jù)等基本內(nèi)容的任何類型的文檔。
有趣的是，試圖仔細(xì)按照 STM32 文檔的操作說明，仍然設(shè)法創(chuàng)建漏洞處理漏洞響應(yīng)的代碼。當(dāng)出現(xiàn)漏洞響應(yīng)時(shí)，需要多次嘗試和大量代碼才能正確阻止對(duì) RNG和自旋循環(huán)的額外調(diào)用。即使這樣，我們也觀察到有問題的結(jié)果，這讓我們懷疑我們的代碼。難怪開發(fā)人員在做物聯(lián)網(wǎng) RNG。
CSPRNG子系統(tǒng)
phically Secure Pseudo-Random Number Generator，簡(jiǎn)稱CSPRNG)是一個(gè)工具，常用的算法有 MD5 或者 SHA1 等標(biāo)準(zhǔn)，它們可以將不定長(zhǎng)的信息變成定長(zhǎng)的 128 二進(jìn)位或者 160 二進(jìn)位隨機(jī)數(shù)。
當(dāng)應(yīng)用程序在 Linux 服務(wù)器上需要加密安全的隨機(jī)數(shù)時(shí)，它不會(huì)直接從硬件 RNG 讀取或調(diào)用某些 HAL函數(shù)并阻止漏洞代碼。它只是通過 /dev/urandom 讀取。這是一個(gè)加密安全的偽隨機(jī)數(shù)生成器 (CSPRNG) 子系統(tǒng)，可作為 API 提供給應(yīng)用程序。每個(gè)主要操作系統(tǒng)上也有類似的子系統(tǒng)：Windows、iOS、MacOS、Android、BSD，等等。
重要的是，對(duì) /dev/urandom 的調(diào)用永遠(yuǎn)不會(huì)失敗并且永遠(yuǎn)不會(huì)阻止程序執(zhí)行。CSPRNG 子系統(tǒng)可以立即產(chǎn)生無窮無盡的強(qiáng)隨機(jī)數(shù)序列。這直接解決了HAL函要么阻止程序執(zhí)行要么失敗的問題。
CSPRNG 子系統(tǒng)的另一個(gè)關(guān)鍵設(shè)計(jì)特征是熵池。這是為了從各種來源獲取熵，包括硬件 RNG (HWRNG)。由于異或運(yùn)算的魔力，所有這些單獨(dú)的弱熵源都可以合成一個(gè)強(qiáng)熵源。這是生成加密安全隨機(jī)數(shù)的正確方法，并且已經(jīng)成為所有地方的行業(yè)標(biāo)準(zhǔn)，除了物聯(lián)網(wǎng)。
為什么你真的需要一個(gè) CSPRNG 子系統(tǒng)
設(shè)計(jì)一個(gè)完整的 CSPRNG子系統(tǒng)聽起來真的很難，尤其是當(dāng)你的小工具沒有使用這些新的物聯(lián)網(wǎng)操作系統(tǒng)之時(shí)。也許只需要咬緊牙關(guān)，在RNG HAL功能上進(jìn)循環(huán)就足夠了。這樣就能得到很好的隨機(jī)數(shù)，對(duì)吧?
本節(jié)將否定你認(rèn)為硬件 RNG 完全安全的想法。
易受攻擊的參考代
沒有人會(huì)完全從零開始編寫源代碼，尤其是在物聯(lián)網(wǎng)設(shè)備領(lǐng)域?？傆幸恍﹨⒖即a或示例文檔可供開發(fā)人員參考。與硬件的接口對(duì)于任何設(shè)備來說都是棘手的，不用說像硬件RNG外圍設(shè)備這樣挑剔的設(shè)備了。
當(dāng)設(shè)備的參考代碼包含漏洞時(shí)，它會(huì)向下傳播到使用它的每個(gè)設(shè)備。畢竟，開發(fā)人員應(yīng)該如何知道易受攻擊的參考實(shí)現(xiàn)和古怪的參考實(shí)現(xiàn)之間的區(qū)別?下面是一些子：
使用 HWRNG 傳播不安全的 PRNG
像libc rand()這樣的prng是非常不安全的，因?yàn)樗鼈儺a(chǎn)生的數(shù)字揭示了RNG的內(nèi)部狀態(tài)信息。它們適用于與安全性無關(guān)的上下文，因?yàn)樗鼈兛焖偾乙子趯?shí)現(xiàn)。但使用它們來加密密鑰等內(nèi)容會(huì)導(dǎo)致設(shè)備安全性的災(zāi)難性崩潰，因?yàn)樗械臄?shù)字都是可預(yù)測(cè)的。
不幸的是，許多支持硬件 NG 的 SDK 和操作系統(tǒng)在幕后使用不安全的 PRNG。Nordic Semiconductor 的 nrf52840 SoC 的 Contiki-ng 物聯(lián)網(wǎng)操作系統(tǒng)通過使用硬件 RNG 傳播不安全的 libc rand() 函數(shù)來實(shí)現(xiàn)這一點(diǎn)：
https://contiki-ng.readthedocs.io/en/release-v4.6/_api/arch_2cpu_2nrf52840_2dev_2random_8c_source.html
使用硬件 RNG 熵播種 libc rand()
將來調(diào)用random_rand()調(diào)不安全的libc rand()
需要明確的是，沒有一種安全的方法可以使用libc rand()生成安全的值。使用硬件創(chuàng)建種子的事實(shí)是無關(guān)緊要的，因?yàn)楣粽呖梢允褂胾ntwister派生或枚舉它。重要的是，當(dāng)用戶調(diào)用random_rand()時(shí)，輸出將來自不安全的libc rand()調(diào)用。
你還可以在 MediaTek Arduno 代碼中看到相同的易受攻擊行為(在此處的 GitHub上)：
MediaTek SDK 中不安全的 libc rand() 使用
所以，即使你的設(shè)備有一個(gè)硬件RNG外設(shè)，即使你認(rèn)為你在使用它，也可能不安全。
使用怪癖
有時(shí)，設(shè)備的工作方式非常古怪，如果不能正確地解釋這些怪癖，可能會(huì)導(dǎo)致設(shè)備安全性的災(zāi)難性崩潰，下面就以LPC 54628為例進(jìn)行說明。
在測(cè)試 LPC 54628 時(shí)，們注意到我們從硬件 RNG 中獲得了質(zhì)量極差的隨機(jī)數(shù)，結(jié)果如此糟糕以至于我們懷疑我們的工具可能有問題。事實(shí)證明我們是對(duì)的。如果你仔細(xì)閱讀用戶手冊(cè)，你會(huì)注意到以下說明：
“隨機(jī)數(shù)生成器產(chǎn)生的隨機(jī)數(shù)的質(zhì)量(熵)依賴于內(nèi)部邏輯的初始狀態(tài)。如果需要使用128位或256位的隨機(jī)數(shù)，建議不要將幾個(gè)32位的字串接成一個(gè)隨機(jī)數(shù)。例如，如果兩個(gè)128位的字串接在一起，硬件RNG將不會(huì)提供2倍128位的熵。”
為了構(gòu)成一個(gè)128位的數(shù)先讀取一個(gè)32位的隨機(jī)數(shù)，然后讀取接下來的32個(gè)數(shù)，但不使用。讀取和使用下一個(gè) 32 位數(shù)字，依此類推。因此，32位的隨機(jī)數(shù)會(huì)在使用的兩個(gè)32位數(shù)字之間跳過。
為了正確使用RNG外設(shè)，應(yīng)該得到一個(gè)隨機(jī)數(shù)，然后拋出后面的32。然后繼續(xù)循環(huán)!在我們的測(cè)試代碼中，我們只是調(diào)用 RNG HAL函數(shù)并使用結(jié)果，這是一種相當(dāng)合理的編寫代碼的方式。有多少人仔細(xì)去閱讀那個(gè)用戶手冊(cè)?
顯然，安全依賴于這種行是不可接受的。
統(tǒng)計(jì)分析
事實(shí)證明，物聯(lián)網(wǎng)硬件 RG 外圍設(shè)備的原始熵質(zhì)量差異很大。大多數(shù)設(shè)備未能通過統(tǒng)計(jì)分析測(cè)試，這些結(jié)果通常取決于單個(gè)設(shè)備本身，因?yàn)楫a(chǎn)品質(zhì)量，即使是相同品牌和型號(hào)的設(shè)備也會(huì)產(chǎn)生不同的結(jié)果。
MediaTek 769
在分析熵時(shí)，我們測(cè)試的內(nèi)容之一是RNG產(chǎn)生的字節(jié)的相對(duì)分布。在理想情況下，我們應(yīng)該期望每個(gè)字節(jié)的可能性相等，因此字節(jié)的分布應(yīng)該是一條平坦的線但我們看到的MT7697并非如此：
MediaTek 7697 SoC上從0到255的每個(gè)字節(jié)頻率的直方圖
上圖是一個(gè)直方圖，顯示了從 MediaTek 7697 SoC 的硬件 RNG 憑經(jīng)驗(yàn)測(cè)量的每個(gè)可能字節(jié) (0 -> 255) 的相對(duì)頻率。請(qǐng)注意鋸齒圖案：這絕對(duì)不是隨機(jī)的。不應(yīng)該有任何類型的模式。直接使用它作為你的加密密鑰，你感覺安全嗎?
Nordic Semiconductor nrf5840
Nordic Semiconductor nrf52840 SoC 的硬件 RNG 表現(xiàn)出 0x000 的重復(fù) 12 位模式，每 0x50 個(gè)字節(jié)出現(xiàn)一次：
在 nrf52840 SoC 中重復(fù) 0000
事實(shí)上，這是12個(gè)字節(jié)，而不是8或16個(gè)字節(jié)，這很奇怪。對(duì)此我們沒有一個(gè)很好的解釋，但這可能取決于黑盒RNG硬件的內(nèi)部工作方式。
STM32-L432KC
不幸的是，我們沒有一個(gè)很好的圖表來展示這一點(diǎn)，但以下是來自 Dieharder測(cè)試套件的結(jié)果：
STM32-L432KC SoC 的計(jì)分析結(jié)果示例
如你所見，這未能通過頑固的“RGB 最小距離”測(cè)試。該測(cè)試的作用是使用 RNG 在大網(wǎng)格中隨機(jī)繪制數(shù)字，然后計(jì)算任意兩點(diǎn)之間的最小距離。這個(gè)測(cè)試特別擅長(zhǎng)識(shí)別數(shù)字之間的細(xì)微關(guān)聯(lián)，比如重復(fù)。如果測(cè)試失敗，可能表明RNG產(chǎn)生的數(shù)字不是相互獨(dú)立的，或者它們以某種方式重復(fù)。
雖然我們測(cè)試的許多硬件 RNG 看起來都不錯(cuò)，例如 LPC54628和 ESP32，但在這里得出的唯一合理結(jié)論是，不應(yīng)孤立地信任從硬件 RNG 中獲取的原始熵。CSPRNG 子系統(tǒng)提供的密鑰拉伸和熵池從根本上是避免執(zhí)行 IoT RNG 所必需的。
總結(jié)
物聯(lián)網(wǎng)需要一個(gè) CSPRNG 子系統(tǒng)，這個(gè)問題不能僅僅通過修改文檔和責(zé)備用戶來解決。如果你要從頭開始設(shè)計(jì)新設(shè)備，我們建議你在操作系統(tǒng)中實(shí)現(xiàn) CSPRNG。
RNG代碼應(yīng)該被認(rèn)為是危險(xiǎn)的，就像加密代碼一樣。不管你有多聰明，永遠(yuǎn)不要自己編寫與RNG硬件接口的代碼。你幾乎肯定會(huì)出錯(cuò)。不要直接從RNG硬件中使用熵?？偟膩碚f，硬件 RNG 不適合加密使用。
設(shè)備所有者
留意更新并確保在可用時(shí)應(yīng)用它們。這是一個(gè)可以通過軟件解決的問題，但可能需要一些時(shí)間。與此同時(shí)，請(qǐng)注意不要過度信任你的 IoT 小工具。對(duì)于需要互聯(lián)網(wǎng)連接的家庭設(shè)備，請(qǐng)將它們放置在只能從外部訪問的專用網(wǎng)段中，這將有助于遏制傳播到網(wǎng)絡(luò)其他部分的任何違規(guī)行為。
物聯(lián)網(wǎng)設(shè)備開發(fā)商
如果可能，請(qǐng)選擇包含從包括硬件 RNG 在內(nèi)的各種熵源中傳播的 CSPRNG API 的物聯(lián)網(wǎng)設(shè)備。如果沒有可用的 CSPRNG 并且你別無選擇，請(qǐng)仔細(xì)檢查你所依賴的庫(kù)以及你自己的代碼，以確保你沒有使用從未初始化的內(nèi)存讀取、忽略硬件 RNG 外設(shè)寄存器或漏洞的代碼條件，或者在沒有更多可用熵時(shí)無法阻止。
設(shè)備制造商/物聯(lián)網(wǎng)操作系統(tǒng)
在你的 SDK 中棄用和或禁用 RNG HAL函數(shù)的任何直接使用。相反，應(yīng)該包含一個(gè) CSPRNG API，該 API 使用具有適當(dāng)硬件 RNG 處理的穩(wěn)健且多樣化的熵源進(jìn)行傳播。Linux內(nèi)核對(duì)dev/urandom的實(shí)現(xiàn)可以作為一個(gè)很好的參考。
參考及來源：https://labs.bishopfox.com/tech-blog/youre-doing-iot-rng
文章來源：嘶吼專業(yè)版
在線咨詢
在線咨詢
0371-63319761