Sweet32:對TLS及openVPN的64位元的密碼攻擊

Sweet32:對TLS及openVPN的64位元的密碼攻擊

CVE-2016-2183，CVE-EDT329

加密協議（如TLS，SSH，IPsec和OpenVPN）通常使用區塊密碼演算法（如AES，3DES和Blowfish）來加密客戶端和服務器之間的數據。為了使用這樣的算法，將數據分解成固定長度的區塊，稱為區塊，並且每個區塊根據操作模式被單獨加密。較舊的區塊密碼，例如3DES和Blowfish使用64位的區塊大小，而AES使用128位的區塊大小。

在加密社區中眾所周知的是，即使沒有針對區塊密碼本身的加密攻擊，短區塊大小也使得區塊密碼容易受到攻擊。我們觀察到這種攻擊現在變得適用於在諸如TLS和OpenVPN之類的流行協議中普遍使用64位元的區塊密碼。然而，這種密碼在互聯網上得到廣泛的使用。Blowfish目前是OpenVPN中的默認密碼，3DES幾乎全部支持HTTPS Web服務器，目前在主流瀏覽器和Web服務器之間大約有1-2％的HTTPS連接。

研究顯示，一個網路攻擊者可以監控網頁瀏覽器和網站之間長久的3DES HTTPS連接，可以透過擷取大約785 GB的流量來恢復安全的HTTP Cookie。在我們的概念驗證中，此次攻擊目前需要不到兩天的時間，使用惡意Javascript來生成流量。保持網路連接活動兩天可能看起來不實用，但在實驗室中很容易實現。在計算複雜性方面，這種攻擊是堪比最近攻擊 的RC4。我們還展示了使用64位密碼的VPN的類似攻擊，例如OpenVPN。

瀏覽器供應商，OpenSSL和OpenVPN團隊目前正在實施對策，我們建議用戶更新最新的可用版本。

區塊密碼的安全性通常減少到密鑰大小k：最佳攻擊應該是密鑰的窮舉搜索，複雜度為2 k。然而，區塊大小n也是重要的安全參數，定義了可以在相同密鑰下加密的數據量。這在使用常用操作模式時尤其重要：我們要求區塊加密可以達到2 n個 查詢的安全性，但大多數操作模式（例如CBC，CTR，GCM，OCB等）不安全，超過2 n / 2區塊消息。

使用具有128位元區塊（如AES）的現代區塊密碼，綁定對應於256 EB。然而，對於具有64位元區塊的區塊密碼，限制對應於僅32 GB，這在實踐中容易實現。當固定密鑰加密的數據量接近該限制時，操作模式的安全保證開始崩潰。這個問題是密碼學家所熟知的，密碼學家總是要求在 2 n / 2塊之前更改密鑰。然而，由於攻擊需要已知的明文，並且僅顯示少量信息，往往被實踐者最小化。實際上，標準機構只建議在2 n / 2塊之前更改密鑰，許多實現不會對使用密鑰執行任何限制。

特別地，存在具有64位元區塊的區塊密碼的許多用途，其中大量數據在相同的密鑰下可能被加密，例如：

3G電話（UMTS），用KASUMI加密;

OpenVPN使用Blowfish作為默認密碼;

許多Internet協議（如TLS，IPSec和SSH）都支持3DES作為傳統密碼。

在許多情況下，32 GB的數據可以透過不到一個小時內傳輸連接。

實際上，區塊密碼與操作模式一起使用以處理任意長度的訊息。CBC模式是最早的加密模式之一，仍然被廣泛使用。訊息M被分成區塊m ₁，並且被加密為：c _i = E _k（m _i， c _i-1），其中c _-1是通常表示為IV的初始化值。我們現在解釋衝突對CBC模式的影響。

CBC已被證明是高達$2^{n/2}$個訊息區塊的安全。另一方面，對CBC有一個簡單的生日攻擊：在使用相同密鑰（相同消息或不同消息）加密的2個n / 2訊息區塊之後，預期兩個密文區塊c _i = c _j之間的衝突。由於 E_k 是置換，在輸出一個碰撞意味著該輸入是相同的(m_i ⊕ c_i-1 = m_j ⊕ c_j-1)，其揭示了兩個明文塊的XOR：

m_i ⊕ m_j = c_i-1 ⊕ c_j-1.

使用2 ^d數據區塊，預期的碰撞數量大約為2 ^2 d-n- 1。

在許多情況下，僅在兩個明文區塊之間恢復xor不足以對具有實際影響的攻擊。但是，當滿足以下條件時，可以執行攻擊：

一個固定的密文被重複發送;

一些部分的明文是已知的。

在這種情況下，有可能碰撞洩漏固定密文和已知明文之間的xor; 這將立即揭示密文。

許多最有影響力的互聯網安全協議（如TLS，SSH和IPsec）在64位元區塊密碼（如3DES和Blowfish）仍被認為是強大的時候被標準化了。例如，在TLS 1.0和1.1中，3DES是強制加密算法，所以所有TLS庫都實現它，絕大多數Web服務器支持它。此外，直到我們披露了本文中的攻擊，OpenSSL在其高安全性列表中包含了3DES密碼套件（現已將其移動到MEDIUM）。

IPSec大多數基於IPSec的VPN客戶端都支持3DES進行互操作。特別是，一些版本的Microsoft L2TP VPN客戶端默認使用3DES。

OpenVPN 是由James Yonan最初編寫的受歡迎的開源VPN解決方案。

OpenVPN的傳輸協議的默認加密是Blowfish - 一種64位元密碼，具有CBC模式。OpenVPN支持兩種不同的模式來生成會話密鑰來加密消息：

在預共享密鑰模式下，靜態密鑰用於所有流量。特別地，這些靜態密鑰的壽命沒有限制。

在TLS模式下，使用TLS握手生成會話密鑰，使用證書來驗證對等體。會話密鑰週期性更新，對數據包數量，字節數或會話時間有限制。默認配置每小時重新啟用隧道一次。

3DES是HTTPS服務器中第二大受歡迎的密碼（AES之後），大約87％的服務器支持它。此外，所有主流的網路瀏覽器都支持3DES。實際上為TLS連接協商的密碼由服務器根據其本地優先級順序和客戶端通告其密碼方式的順序來選擇。由於大多數現代瀏覽器和服務器都喜歡使用AES 或 3DES，所以可以預期只有可以忽略的連接數量可以協商3DES。然而，我們發現證據表明，所有TLS連接中的1-2％可能在CBC模式下使用3DES，如下所述。

來自Mozilla Firefox的Firefox數據 顯示，3DES用於Firefox瀏覽器中接近1％的HTTPS連接（0.76％，具有beta 49）。使用3DES與Firefox正在慢慢減少，並從版本36中支持的密碼列表中刪除RC4達到頂峰。實際上，許多服務器配置為首先使用RC4，然後使用3DES，現在使用3DES與Firefox。由於所有現代瀏覽器在2013年至2015年之間已經不再使用RC4（遵循RFC 7465），因此在這種情況下，它們還將使用3DES密碼。

我們使用cipherscan 工具執行前1萬台服務器的掃描。我們發現支持TLS的服務器的86％包括3DES作為支持的密碼之一。此外，這些服務器中的1.2％配置為使用現代瀏覽器實際選擇基於3DES的密碼套件，儘管有更好的選擇。（特別是這些服務器中的許多服務器支持基於AES的密碼管理，但優先使用3DES或RC4）

Windows XP客戶端和Windows 2003伺服器Windows Server 2003操作系統在其默認配置中不支持基於AES的密碼連接，儘管可以使用可選的修補程序添加對AES的支持。具有安全更新MS10-049的Windows XP操作系統支持基於AES的密碼檢測。如果尚未添加基於AES的密碼套件，則這些操作系統僅支持RC4，3DES，DES和RC2-40。雖然Microsoft不再支持它們，但它們仍然有一些用戶，並且這創建了最佳可用密碼為3DES的情況。

攻擊的一個重要要求是在相同的TLS連接中發送大量請求。因此，我們需要找到不僅協商使用3DES的客戶端和伺服器，而且還可以在相同的TLS連接中交換大量的HTTP請求（無需重新密鑰）。這可以使用HTTP / 1.1（Keep-Alive）中定義的持久HTTP連接。在客戶端，我們測試的所有瀏覽器（Firefox，Chrome，Opera）將重新使用TLS連接，只要伺服器保持打開狀態。

在伺服器端，我們發現許多HTTP伺服器將關閉TLS連接，即使它仍然處於活動狀態。特別地，Apache和Nginx限制在同一連接中發送的請求數，默認配置最多為100。另一方面，IIS似乎沒有這樣的限制。實際上，許多伺服器在單個TLS連接中接受了大量的請求。

易受攻擊的網站為了更好地估計易受攻擊的服務器數量，我們測試了Alexa前10名的伺服器，與客戶端協商3DES。我們確定了11483個不同的HTTPS服務器，發現其中226個（1.9％）與客戶端協商3DES。此外，其中72個（佔總數的0.6％）也接受連接開放至少800k的請求。因此，攻擊的持續時間至少從瀏覽器和伺服器的角度來看是不切實際的，我們估計至少有0.6％的HTTPS連接容易受到攻擊。

原文摘譯