Random-Number-Generator

RDRAND(英特爾)會妥協熵嗎?

  • May 20, 2020

我最近在討論英特爾晶片中的 RDRAND 問題,以及關於 NSA 可能如何影響英特爾削弱或在其設計中製造後門的整個問題。

請願書已張貼,要求 Linus Torvalds 忽略 RDRAND 並且不將其作為熵的來源包含在/dev/random/. 你可以在這裡看到 Linus 的回應。

我的主要問題是,使用 RDRAND 作為熵的一種來源(在許多其他來源中)是否會/dev/random通過增加一些可預測性來損害“隨機性”?或者他是否正確地說,只要它不是唯一產生熵的東西,它真的沒有任何區別嗎?

首先,寫入/dev/random和/或/dev/urandom增加核心中維護的熵計數之間存在差異。

這就是為什麼預設情況下是全域/dev/random可寫的——任何輸入只會增加,但永遠不會替換 RNG 的內部狀態;如果您編寫完全可預測的數據,那麼您沒有做任何好事,但也沒有壞處。

另一方面,如果您使用特殊的 ioctl寫入 /dev/random (這確實需要超級使用者權限),您實際上可以增加熵估計。

如果你能夠做到這一點(如果你是,你可以很容易地替換/dev/random/dev/notsorandom完成它),/dev/random退化為/dev/urandom: 通常,讀取random應該阻塞,直到至少有盡可能多的熵位寫入內部池而不是請求,同時urandom返回請求的“隨機性”。)

如果您設法將可預測的位寫入池中,但告訴核心將它們視為不可預測的數據,則 /dev/random 的下一個讀取器將收到僅確定性地取決於熵池的目前內部狀態的隨機數,而不是像磁碟尋軌時間和鍵盤輸入這樣的“真正隨機”事件。

但是,除非您能夠從作業系統的安裝開始執行該攻擊,否則您實際上並不知道內部狀態!從輸出中預測它/dev/random至少與反轉 SHA-1 一樣困難(這被認為非常困難)。這也是為什麼可以推斷,除了直接在新的作業系統安裝之後,urandom 對於所有目的,無論是否加密,都可以被認為是“足夠隨機的”。

現在讓我們看看drivers/char/random.c中RdRand的實際實現:

唯一可能使用惡意 RdRand 指令的地方是隨機設備的輸出函式。在輸出返回給呼叫者之前,它與“經典”Linux RNG的“實際”輸出進行異或。

由於資訊論告訴我們,當我們將一個選定的字元串與一個未知字元串進行異或運算時,我們無法預測轉換後結果字元串的外觀,因此顛覆 RdRand 指令並沒有什麼好處,至少是這樣它目前在Linux中使用。

更新: 一些人認為,一個非常聰明的 CPU 可能會將對 RdRand 的呼叫解釋為後門的觸發器,例如,用 MOV 替換後續的 XOR。

我想說這在理論上是可能的,但比直接扭曲 RdRand 的輸出要困難得多,例如通過在只有對手知道的“隨機數”密鑰下返回 AES-CTR 的密鑰流。

必須檢查核心中使用的特定程式碼序列;如果這種情況發生了變化(例如,通過使用一些虛擬 XOR 操作來包圍 RdRand 呼叫),則必須廣泛部署適應啟發式的微程式碼更新,否則人們很快就會產生懷疑。

將 RdRand 指令(或不同架構上的等效指令)視為只是另一個熵輸入(為了安全起見,不增加估計的熵),可能會使 RNG 更難被顛覆。

第二次更新: 這個問題已經在核心郵件列表中討論過兩次:一次是在 2011 年,由一位 Intel 工程師送出的更新檔開始,然後是關於安全性的大量討論,第二次是在 2012 年,最終導致了更新檔實施目前的方法。甚至有人提到了關於觸發改變某些指令(例如 XOR 或 MOV)行為的後門的擔憂。就 XOR 構造而言:Linux 人員聲稱 XOR 方法據說比將 RdRand 輸出散列到熵池中更安全,儘管我們這裡的一些人並不真正相信這一點。

引用自:https://crypto.stackexchange.com/questions/10283