為什麼新版本的 TLS 對 CBC 套件使用顯式 IV？
SSL 3.0 和 TLS 1.0 在 CBC 模式下加密記錄時使用了一種不安全的方案來生成隱式 IV：它們使用了先前記錄的最後一部分，該值可以被攻擊者預測。這種攻擊在BEAST 攻擊中得到了展示。
為避免這些問題，TLS 1.1 及更高版本使用顯式 IV，它們作為記錄的一部分發送。這避免了攻擊，但也為每條記錄增加了 16 字節的成本。
$$ CBCATT $$描述了對 TLS 的選擇明文攻擊，該攻擊依賴於知道記錄的 IV。以前版本的 TLS$$ TLS1.0 $$使用先前記錄的 CBC 殘差作為 IV，因此啟用了此攻擊。此版本使用顯式 IV 來防止這種攻擊。
我解決這個問題的第一個想法不是顯式 IV，而是隱式 IV，它從共享秘密安全地派生。TLS 已經定義了從主密鑰生成任意長度的偽隨機數據的方案（參見5. HMAC 和偽隨機函式）。
為什麼 TLS 1.1 的設計者決定使用顯式 IV，而不是簡單地用強隱式 IV 方案替換弱隱式 IV 方案？顯式 IV 是否比生成良好的隱式 IV 有任何優勢？
TLS 1.0 使用初始化向量 (IV) 來指代兩個不同的程序。TLS 1.1 引入了一種新類型的 IV，它會導致整個塊被丟棄，並且不能與基於 CBC 殘差的舊系列 IV 直接比較。通過在記錄開始時簡單地更改操作，顯然希望使實現易於修補並防止某些系統受到壓力。
概述
IV 試圖防止任何（密鑰、消息）對在重傳時產生相同的密文。它們通常需要是唯一的，最好是隨機的，但不需要保密。（共享秘密 IV 確實更關鍵。）
有很多方法可以嘗試使用 IV。讓我們從 ECB（無 IV）開始，然後首先檢查 TLS 1.0，然後檢查 TLS 1.1/1.2 如何使用其新的 IV。
一、歐洲央行
如果您只是將明文分成塊並加密每個塊，那麼如果明文重複，您將面臨重新傳輸相同塊的風險。因此，CBC 對 ECB 的改進方式是在加密之前將前一個塊的密文異或到目前塊的明文中。這足以降低除第一個塊之外的每個塊重傳的可能性，這些塊還沒有與任何東西進行異或。因此，您將明確的 IV 扔到第一輪以獲得 CBC。
二、帶有 CBC 的 TLS 1.0
在 TLS 1.0 中，各方可能希望能夠確保第一個 IV 是隨機的。所以每一方都提出了一個IV。然後通過偽隨機函式將兩個 IV 混合在一起。
初始化向量 (IV) 當分組密碼用於 CBC 模式時，初始化向量在加密之前與第一個明文塊進行異或。–RFC 2246
然後，發送者獲取 IV 並將其與第一個明文塊進行異或。這將通過區塊鏈傳播，確保沒有重複的密文塊（至少不對應重複的明文塊）就足夠了。
雖然 IV 本身不需要保密，但 BEAST 表明讓攻擊者預測您的下一個 IV 並能夠塑造您的下一個明文塊是不明智的。
三、獸
因此，在 BEAST 攻擊中，攻擊者獲取下一條消息的 IV，然後欺騙發送者發送某種形式的消息（不是 IV xor CPT）。
一旦 IV（又名“遮罩”）在加密之前被異或，它就會取消（不是 IV）。CPT 現在是一些選擇的明文，將被加密（沒有任何遮罩）。那很糟。
在 TLS 1.1 版中，最大的變化是在每條記錄的開頭（每 16k 字節）提供一個新的 IV。
每個塊的 TLS 1.0 “IV”在 1.1 中只是稱為遮罩。甚至可以選擇保留第一個塊的 TLS 1.0 IV。因此，新的 IV 實際上並沒有直接替換舊的 IV，它們的用途略有不同，實現方式也略有不同。
根據 RFC 4346，應該使用以下兩種算法之一來生成每條記錄 IV：
- 為 IV 生成一個加密的強隨機字元串 R。用 R 屏蔽數據。第一個密碼塊將被加密為：
E（R XOR 數據）。 2. 在加密之前生成一個加密強的隨機 R 並添加到明文中。在這種情況下，可以固定遮罩，或者可以將來自先前記錄的 CBC 殘差用作遮罩。使用殘基可以最大限度地保持與 TLS 1.0 和 SSL 3 的程式碼兼容性。它還**具有不需要快速重置 IV 的能力，**這在某些系統上是已知的問題。
所有備選方案的解密操作都是相同的：接收方解密整個結構，但丟棄對應於 IV 分量的第一個密碼塊。
優先事項是盡可能多地保留現有規範，使實施更容易。
在 TLS 1.1 和 1.2 中，他們在第一個塊中加密 IV，這將被發送者丟棄。TLS 1.0 IV 現在稱為“遮罩”。通過保留舊的 IV 作為遮罩，但引入一個新的 IV 來製作一次性塊，他們讓算法盡可能少地改變。
各方不再在這個新的、更頻繁生成的 IV 上進行合作，這意味著程式碼更改更少，對某些系統的壓力也更小。
進一步閱讀
- Tor 對 BEAST 攻擊
- 殺死野獸
- 美女和野獸
- Rizzo/Duong 的安全影響
- RFC 2246 (TLS 1.0)、RFC 4346 (TLS 1.1)
- 分組密碼操作模式
除了上面提到的 Brownbat 之外，還有一個原因是，在設計 TLS 1.1 時，DTLS 已經存在。DTLS 是 TLS 的變體，使用 UDP 而不是 TCP 進行傳輸。在 UDP 通信中，您不能依賴實際傳送到目的地的任何記錄，因此任何記錄都必須自行解密，而無需了解以前的記錄。所以如果你想在 DTLS 中使用 CBC 模式，你必須有一個顯式的 IV。
首次發布 DTLS 時，他們必須定義自己的密碼套件，因為當時的 TLS 1.0 沒有指定任何可用的密碼套件。但是從 TLS 1.1 和 DTLS 1.1 開始，可以共享（大多數）密碼套件。