/dev/random 是一種加密安全偽隨機數產生器 (CSPRNG)，已知有一個惱人的問題：阻塞。 本文介紹如何解決該問題。
在過去的幾個月中，核心中的隨機數產生工具已被稍微修改，但該子系統中的問題已在更廣泛的過程中解決。 。 最多 這樣做是為了防止 getrandom() 系統呼叫在系統啟動時長時間阻塞，但根本原因是隨機池的阻塞行為。 最近的補丁將刪除該池，並且預計它將前往主核心。
Andy Lutomirski 在 XNUMX 月底發布了該補丁的第三個版本。 他貢獻 “隨機 Linux API 的兩個主要語義變化”。 該補丁為 getrandom() 系統呼叫添加了一個新的 GRND_INSECURE 標誌（儘管 Lutomirsky 將其稱為 getentropy()，它是在 glibc 中使用帶有固定標誌的 getrandom() 實現的）； 此標誌導致呼叫始終傳回請求的資料量，但不保證資料是隨機的。 內核將盡最大努力生成給定時間的最佳隨機數據。 “也許最好的辦法就是稱之為‘不安全’ （不安全）以防止此 API 被用於需要安全的事情。”
這些補丁也刪除了阻塞池。 核心目前維護了兩個隨機資料池，一個對應於/dev/random，另一個對應於/dev/urandom，如下所述 2015年。 阻塞池是/dev/random的池； 該設備的讀取將被阻塞（意思是它的名字），直到從系統收集到“足夠”的熵來滿足請求。 如果池中沒有足夠的熵，從此檔案的進一步讀取也會被阻止。
刪除鎖定池意味著從 /dev/random 讀取的行為類似於 getrandom() ，其中標誌設為零（並將 GRND_RANDOM 標誌轉變為 noop）。 一旦加密隨機數產生器 (CRNG) 初始化，從 /dev/random 讀取和呼叫 getrandom(...,0) 將不會阻塞，並將傳回請求的隨機資料量。
盧托米爾斯基 說： 「我認為 Linux 阻塞池已經過時了。 CRNG Linux 產生的輸出甚至足以用於金鑰產生。 區塊鏈在任何物質意義上並不強大，需要大量價值可疑的基礎設施來支持它。”
進行這些變更的目的是確保現有程式不會真正受到影響，事實上，長時間等待 GnuPG 金鑰產生等問題會減少。
「這些事件不得擾亂任何現有計劃。 /dev/urandom 維持不變。 /dev/random 仍然在啟動時立即阻塞，但阻塞程度比以前少。 具有現有標誌的 getentropy() 將返回與以前一樣適合實際目的的結果。”
Lutomirsky 指出，核心是否應該提供所謂的「真正的隨機數」仍然是一個懸而未決的問題，而這正是阻塞核心在某種程度上應該做的事情。 他認為這樣做的原因只有一個：「遵守政府標準」。 Lutomirsky 建議，如果核心要提供此功能，則應透過完全不同的介面來完成，或者應將其移至使用者空間，從而允許使用者檢索可用於建立此類鎖定池的原始事件樣本。
史蒂芬穆勒 (Stephan Müller) 建議他的套裝 Linux 隨機數產生器 (LRNG)（目前已發布版本 26）可以為需要它的應用程式提供真正的隨機數。 LRNG“完全符合用於產生隨機位元的熵源的 SP800-90B 指南”，使其成為政府標準問題的解決方案。
馬修·加勒特（Matthew Garrett）反對“真正的隨機數據”一詞，指出原則上可以對採樣的設備進行足夠精確的建模，以使其可預測：“我們不是在這裡採樣量子事件。 」
Müller 回應稱，該術語來自德國標準 AIS 31，用於描述隨機數產生器，該生成器僅「以與底層噪音源產生熵相同的速率」產生結果。
撇開術語差異不談，擁有 LRNG 補丁建議的鎖池只會導致各種問題，至少在沒有特權的情況下訪問它是這樣。
正如盧托米爾斯基所說： “這並不能解決問題。 如果兩個不同的用戶運行像 gnupg 這樣的愚蠢程序，他們只會互相耗盡對方的資源。 我發現 /dev/random 目前有兩個主要問題：它容易受到 DoS（即資源耗盡、惡意影響或類似的情況），而且由於使用它不需要任何權限，因此它也容易被濫用。 Gnupg錯了，徹底崩潰了。 如果我們添加一個新的非特權介面供 gnupg 和類似程式使用，我們將再次失敗。”
Mueller 指出，新增 getrandom() 現在將允許 GnuPG 使用此接口，因為它將提供池已初始化的必要保證。 根據與 GnuPG 開發人員 Werner Koch 的討論，Mueller 認為保證是 GnuPG 目前直接從 /dev/random 讀取的唯一原因。 但是，如果存在容易受到拒絕服務攻擊的非特權介面（如今天的 /dev/random），Lutomirsky 認為它將被某些應用程式濫用。
Linux 隨機數子系統的開發人員 Theodore Yue Tak Ts'o 似乎改變了他對阻塞池需求的看法。 他說，刪除這個池將有效地消除 Linux 具有真正的隨機數產生器（TRNG）的想法： “這不是廢話，因為這正是 *BSD 一直在做的事情。”
他也擔心提供TRNG機制只會成為應用程式開發人員的誘餌，並認為事實上，考慮到Linux支援的硬體類型不同，核心中無法保證TRNG。 即使僅使用 root 權限操作設備也無法解決問題： “出於安全目的，應用程式開發人員指定將他們的應用程式安裝為 root，因此這是您訪問‘真正好的’隨機數的唯一方法。”
穆勒詢問曹是否放棄了他自己長期以來提出的阻塞池實施方案。 曹回應說，他計劃採用 Lutomirsky 的補丁，並積極反對向核心添加阻塞介面。
「核心無法保證雜訊源是否已被正確表徵。 GPG 或 OpenSSL 開發人員唯一能得到的就是一種模糊的感覺，即 TRUERANDOM“更好”，並且由於他們想要更高的安全性，因此他們無疑會嘗試使用它。 在某些時候它會被阻止，當其他一些聰明的用戶（可能是分發專家）將它插入到 init 腳本中並且系統停止工作時，用戶只能向 Linus Torvalds 本人抱怨。”
Cao 也主張為密碼學家和真正需要 TRNG 的人提供一種在使用者空間中收穫自己的熵的方法，以便在他們認為合適的時候使用。 他表示，收集熵並不是內核可以在其支援的所有不同硬體上執行的過程，內核本身也無法估計不同來源提供的熵量。
「核心不應該將不同的噪音源混合在一起，當它嘗試在極其簡單的 CPU 上玩某種『抽搐熵遊戲』時，它當然不應該試圖聲稱知道它獲得了多少位熵。「面向消費者用戶的架構。物聯網/嵌入式情況下，一切都與單一主振盪器不同步，沒有CPU 指令來重新排序或重命名暫存器等。”
「你可以談論提供嘗試進行這些計算的工具，但這些事情必須在每個用戶的硬體上完成，這對大多數發行版用戶來說根本不切實際。 如果這僅適用於密碼學家，那麼就讓它在他們的用戶空間中完成。 我們不要簡化 GPG、OpenSSL 等，以免每個人都說“我們想要“真正的隨機性”，並且不會滿足於更少。” 我們可以討論如何為密碼學家提供接口，以便他們可以通過訪問主要噪聲源（分離和命名）來獲取所需的信息，並且也許噪聲源可以以某種方式向庫或用戶空間應用程序驗證自身身份。”
對於這樣的介面可能會是什麼樣子進行了一些討論，因為例如某些事件可能存在安全隱患。 曹指出，鍵盤掃描代碼（即擊鍵）作為熵收集的一部分被混合到一個池中：“將其帶入用戶空間，即使是通過特權系統調用，至少可以說是不明智的。” 其他事件計時很可能會透過側通道造成某種資訊外洩。
因此，Linux 隨機數子系統的一個長期存在的問題似乎正在解決。 隨機數子系統最近發生的變化實際上只導致使用它時出現 DoS 問題。 現在有一些有效的方法可以獲得內核可以提供的最佳隨機數。 如果 TRNG 在 Linux 上仍然需要，那麼將來需要解決這個缺陷，但很可能這不會在核心本身內完成。
一些廣告🙂
感謝您與我們在一起。 你喜歡我們的文章嗎？ 想看更多有趣的內容？ 通過下訂單或推薦給朋友來支持我們， , 我們為您發明的入門級服務器的獨特模擬： （適用於 RAID1 和 RAID10，最多 24 個內核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 數據中心便宜 2 倍？ 只有這裡 在荷蘭！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 閱讀
來源： www.habr.com