為了防止有目的地嘗試修改數據的對手,我們需要比錯誤檢測/糾正CRC等代碼更強大的解決方案。 理想情況下,任何(計算限制的)對手都不應該能夠說服我們非法數據來自我們的設備或在我們沒有注意到的情況下修改我們的數據。在介紹兩種可能的解決方案之前,我們將回顧一些所需的構建塊。首先,我們需要了解對稱和非對稱密碼學之間的高級差異。
可以根據私鑰的使用方式將不同的加密解決方案分組到類中。當所有用戶共享單個私鑰時,他們對密鑰材料都有相同的知識。由于每個用戶在密鑰材料上的信息是對稱的,因此此類稱為對稱加密。在另一個類中,每個用戶都有一組兩個數學上相關的密鑰:一個只有他們知道的私鑰,以及一個他們與所有人共享的公鑰。由于私鑰只有用戶知道,因此用戶之間的信息現在是不對稱的。
需要注意的重要區別是,在對稱加密中,每個用戶都有同一私鑰的副本,并且相同的密鑰用于兩種類型的操作:加密和解密,以及生成和驗證簽名。在非對稱加密中,只有用戶知道其私鑰,并且只有該私鑰可用于解密或簽名數據。
需要的另一個工具是一種創建任意大量數據的簡短摘要或“指紋”的方法。由于加密操作的計算成本很高,因此在表示(可能更大)數據量的簡短摘要上運行它們會更方便。
加密哈希函數采用任意長度的輸入并生成固定長度的摘要或“哈希”,該摘要將用作數據的摘要。由于該函數將任意大的輸入映射到固定的輸出范圍,因此肯定會發生沖突。但是,通過使哈希輸出的大小足夠大,沖突概率可以忽略不計。
哈希函數的另一個重要屬性是,即使輸入數據中非常小的變化,例如一位翻轉,也會導致輸出哈希的實質性變化。平均而言,輸入數據中的單個位翻轉(即使數TB)將導致大約50%的哈希輸出位發生變化。這意味著對原始數據的微小更改將導致生成截然不同的摘要或摘要作為哈希函數的輸出。再加上碰撞的可能性可以忽略不計,這將作為我們要保護的數據的指紋。
我們可以只加密數據嗎?
在嘗試保護數據時,我們通常會想到加密。使用密鑰加密數據可以使沒有密鑰的任何人都無法讀取加密的密文。那么,我們為什么不對數據進行加密以保護它呢?
加密本身僅提供機密性,不提供真實性或完整性。讓我們研究一種常用的加密方法:計數器模式下的 AES。AES 是一種對稱分組密碼,它使用共享密鑰一次加密 16 字節的數據塊。分組密碼可以在幾種不同的模式下運行(組合每個數據塊的方法),一種常用的模式是計數器模式。在這種模式下,有一個單調遞增的計數器,該計數器被加密以產生偽隨機密鑰流。為了加密數據,此密鑰流與明文輸入進行異或運算以生成密文。
密文可以與使用的初始計數器值(初始化向量)一起存儲或發送,以便以后使用相同的密鑰解密。解密時,將加載初始計數器值,并使用相同的密鑰再次加密以生成相同的密鑰流。此密鑰流與密文進行 XOR 運算,以取消加密操作并恢復明文。
如果對密文的修改也以可預測的方式修改基礎明文,則密文稱為可延展性。計數器模式下的分組密碼(以及其他流密碼)具有微不足道的延展性。翻轉密文中的單個位將在解密時翻轉明文中的相同位,而不會更改任何其他位。這意味著攻擊者可以輕松修改加密數據并預測此更改對解密數據的影響,即使他們不知道密鑰或基礎明文消息也是如此。
考慮有兩個系統通過無線發送和接收在計數器模式下使用 AES 加密的消息進行通信的情況。攻擊者可能能夠攔截通信,即使他們可能無法解密消息,他們也知道他們可以翻轉密文中的位以翻轉明文中的相同位。在某些情況下,可能很容易猜到明文可能是什么。這些類型的機器對機器通信通常具有結構化和可預測的格式。攻擊者可能已經獲得了與之相關的文檔,或者可能只是能夠猜測它或對其進行逆向工程。
在我們的示例中,攻擊者想要中斷運營中心的訂單。攻擊者知道交換消息的格式(通過閱讀用戶手冊),處理訂單的命令是“fill”,刪除訂單的命令是“kill”。在上圖中,我們可以看到執行訂單的命令已正確加密和解密。讓我們看看攻擊者如何在不被發現的情況下更改此命令,即使消息將被加密!
攻擊者知道明文消息中“fill”命令的位置,并希望惡意將命令更改為“kill”,以導致訂單被取消,而不是履行。
首先,攻擊者計算消息 M = “填充” 和 M' = “kill” 之間的差?。通過?包含明文消息“fill”的密文塊進行異或運算,解密消息中的字符“f”將更改為“k”!
由于僅加密并不能阻止這些數據被修改,我們可以通過加密消息及其CRC來保護其完整性嗎?攻擊者不會知道CRC的值,如果他們修改密文,CRC應該檢測到修改,對吧?正如我們在上一節中看到的,加密可以是可延展的,不幸的是,加密的CRC也可以。
假設我們有一個加密的消息M,它也包含該消息上的加密CRC,并且我們知道密文中與加密CRC相對應的位置。如果我們想將消息 M 修改為新消息 M',我們還需要修改 CRC。
設 ? = M ? M' 是原始消息 M 和新消息 M' 之間的差值。這是兩個異或一起,或者已經改變的位(如果?的每個位是我們翻轉的消息中的位,則為 1)。原始 CRC 與新計算的 M' 上的 CRC 不匹配。我們需要修改 CRC,使其在新消息 M' 上有效。
由于CRC是一個線性函數,CRC(M') = CRC(M) ? CRC(?)。換句話說,為了獲得一個新的有效CRC,我們計算?上的CRC函數(我們已經更改的位的CRC),并使用CRC對這個值進行XOR。正如我們之前看到的,我們甚至可以在密文上完成所有這些操作,甚至不知道消息的真實值或 CRC 的值,我們可以使用有效的 CRC 將消息更改為我們想要的任何內容!
這種弱點不僅僅是理論上的。它存在于有線等效保密 (WEP) 算法中,該算法允許以類似的方式修改 WEP 流量。
因此,僅僅加密數據本身并不能保護它不被修改,加密的CRC也不能。如果明文CRC,加密數據或加密數據及其CRC不能保護我們的數據免受故意修改,那又有什么作用呢?
審核編輯:郭婷
-
crc
+關注
關注
0文章
199瀏覽量
29467 -
計數器
+關注
關注
32文章
2256瀏覽量
94603 -
AES
+關注
關注
0文章
104瀏覽量
33236
發布評論請先 登錄
相關推薦
評論