Tls

為什麼 Vaudenay 的原始 padding oracle 攻擊無法在 TLS 1.0 上利用?

  • July 20, 2017

在 2003 年發布的 SSL/TLS 通道中讀取密碼攔截:

在 Eurocrypt'02 上,Vaudenay 提出了 CBC 模式下用於塊密碼的填充方案中的漏洞。他使用了一個side channel,即padding驗證中的錯誤資訊。由於側通道不可用(錯誤被加密)和在錯誤的情況下會話過早中止,這種攻擊不可能針對 SSL/TLS

Vaudenay 2002 年的論文中

TLS v1.0(也)提供了一個可選的 MAC,它未能阻止攻擊:當伺服器發現 MAC 錯誤時,它會產生bad_record_mac錯誤。但是,消息填充是在 MAC 算法之後執行的,因此 MAC 不排除我們的攻擊,因為在解密中的填充之前無法檢查它。

它繼續:

攻擊不太實用的原因是填充格式錯誤(decryption_failed 錯誤)是致命警報,會話必須中止。

現在,這有多糟糕?錯誤的填充會導致該部分中斷 OK,但 256 次中的 1 次填充將是正確的,並且將恢復一個字節的明文。這應該足夠了,並且以與 BEAST 式攻擊相同的方式,可以通過移動有效負載來恢復更多字節,以便我們想要恢復的 cookie 的字節始終是 LSB。我不明白為什麼這些人認為這是不可利用的。

除此之外,看起來 Canvel、Vaudenay 和其他人實際上知道這一點,但不知道這是完全可利用的:

正如在

$$ 17 $$,為了只解密最右邊的字節,攻擊仍然有效,成功機率為 2−8。它也可以被調整以測試 x 是否以給定的模式結束。

雖然他們後來補充說:

由於另一個原因,這對 TLS 也不起作用:因為攻擊者無法獲得錯誤消息(它們確實是加密的且無法區分)。

一個錯誤,即使是加密的,如何無法區分?我猜與較長的正常響應相比,這將是一條短消息。

這是攻擊模型的問題。Vaudenay 將自己置於攻擊者在“外部”的模型中,並試圖計算出人類使用者在網站中輸入的密碼(或其他類似的密碼保護協議)。客戶端和伺服器系統都是誠實的,如實執行 TLS 協議;攻擊者可以檢查和更改數據包,僅此而已。選擇的明文攻擊超出範圍。

在該模型中,如果出現重複錯誤,人類使用者會認為事情太可疑,並且不會堅持下去。此外,大多數旨在檢查塊最後一個字節的假設的更改也會破壞記錄中包含 MAC 的先前字節,因此從攻擊者的角度來看,最終可觀察到的行為沒有改變:(加密的)警報記錄由伺服器發送,連接被中止(所以我們不是在談論短錯誤消息和長非錯誤消息之間的區別,而是關於兩個具有完全相同長度的錯誤消息)。

2003 年的論文“修復”了這兩個問題:

  • 它針對電子郵件客戶端的情況,該客戶端每分鐘自動連接到 IMAPS 伺服器,並且即使連接中止也會一次又一次地嘗試;這些錯誤也會被默默地忽略。
  • 攻擊者可以通過測量伺服器的響應時間來計算故障模式(“bad padding”與“good padding but bad MAC”)之間的差異。

回想起來,我們可能會注意到,當填充具有完整塊的大小並且接收方不檢查填充字節內容時,可以避免關於不知道警報消息的問題,就像 SSL 3.0 名義上的情況一樣。還有一些 TLS 1.0 實現沒有檢查填充字節內容。

大約在 2010 年,研究人員做出了某種“心理突破”,他們意識到 CPA 在 Web 環境中是一種有效的模型。這始於對 ASP.NET 的填充 oracle 攻擊,其中攻擊者位於發送端,並希望解開“視圖狀態”,即伺服器添加到 Web 頁面的加密 blob,以便解除安裝狀態資訊儲存在客戶。這不是TLS攻擊,但它仍然展示了授予攻擊者的“額外權力”:攻擊者控制連接並可以決定重試,反复嘗試,無需人類受害者的監督;他可以訪問錯誤消息。

然後,在 2011 年,BEAST 攻擊展示了一種與填充無關的攻擊(儘管它仍然與 TLS 中的 CBC 有關),在 Web 瀏覽器中使用 CPA 模型,並針對客戶端自動發送的秘密值(cookie) . 從那時起,研究人員開始真正相信每次連接成功率低的 CPA 在 Web 環境中非常實用。

Vaudenay 風格的 padding oracle 攻擊與使用惡意 Javascript 的類似 BEAST 的攻擊者相結合,形成了幸運十三攻擊。與此同時(感謝 Vaudenay 2003 年的文章),TLS 庫已經修改了他們的程式碼:

  • 發送了相同的警報消息,無論故障是在填充還是 MAC 上(此外,該錯誤消息不一定對攻擊者可用)。
  • 即使在填充錯誤的情況下仍會計算 MAC,以便具有恆定的處理時間。

然而,有一個小的定時洩漏殘餘,因為 MAC 計算時間取決於明文的大小,由於填充,明文的大小並不完全等於密文的大小。如果解密時發現的填充不正確,那麼庫必須選擇一些偽填充長度,這會洩漏一些資訊。幸運十三攻擊在帶有惡意 Javascript 的 CPA 模型中使用了這個小漏洞。

現代 TLS 庫實現了真正的恆定時間處理,消除了最後的時間洩漏,從而使 TLS 1.0 CBC 密碼套件再次安全(但 TLS 1.2 與 AEAD 套件仍然在很大程度上是可取的)。


**總結:**研究人員花了十年時間才明白 Web 提供了實用的 CPA 設置。這需要認識到 Javascript 不僅是為了讓網頁上的魷魚跳舞,而且功能強大到足以觸發許多無聲連接嘗試;而且,至關重要的是,每個這樣的連接都可以包含一個秘密值,雖然不是人類輸入的實際密碼,但仍然足夠多汁,足以保證一些攻擊努力。

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