要約

  • RFC 2405が論じた攻撃モデルでは、鍵の有効期間を短くするだけでは足りなかった。IPデータグラムは既知または推測可能なヘッダーから始まることが多い。
  • DES-CBCが担うのは機密性であり、認証ではない。IV、鍵探索、完全性、Security Associationの管理は別々の論点である。

万能のタイマーはなかった

1998年11月のRFC 2405は、DES-CBCをESPの機密性変換として規定した。一方、鍵を何時間または何バイトで交換すべきかという一律の基準は設けていない。保護対象の価値と、攻撃者が投入すると見積もる資源に判断を委ねた。これはリスク判断であって、予定どおりに鍵を替えればアルゴリズムが強化されるという保証ではない。

同文書は当時の根拠を挙げる。1993年の見積もりでは、100万ドルのDES解読機が一つの鍵を3.5時間で破れる設計だったという。またIPデータグラムは既知、または推測しやすいヘッダーから始まることが多い。したがって、RFCの結論は特定の既知平文攻撃に限定される。頻繁な鍵交換ではそれを防げない。数値は1998年のRFCが伝えた歴史的見積もりで、現在の価格、性能比較、実測値ではない。RFCは当時の但し書きとして、DES-CBCにも平文送信よりは高いプライバシーがあると述べていた。

三つの保護は別の仕事をする

ESPデータグラムごとに、8オクテットの明示的な初期化ベクトルを付ける。RFCは値をランダムにすること、連続値のハミング距離が小さくなるカウンターなどを使わないことを要求した。別のデータグラムが失われたり順序を入れ替えられたりしても、そのパケットに入ったIVから復号を始められる。しかし、パケット単位のIVは暗号文を認証せず、DES鍵の探索を難しくもしない。

RFC 2405はDES-CBCを認証機構ではないと明記し、対応する認証なしでの使用を強く勧めていない。CBCの切り貼り攻撃も説明している。認証は完全性の問題に対処できるが、鍵交換では代用できない。信頼性は暗号だけでなく、実装、Security Associationの管理、鍵の強さ、参加するすべてのノードに左右される。

実装必須から「MUST NOT」へ

後のESPアルゴリズム要件では表記が段階的に変わった。RFC 4305は、それ以前の実装必須からDES-CBCを「SHOULD NOT」へ移した。RFC 4835も同じ要件を維持し、RFC 7321は「MUST NOT」に変更、RFC 8221もそれを引き継いだ。これは相互運用要件の変遷であり、すべての装置がDESを停止した日付ではない。

仕様は将来の互換圧力を減らせても、稼働中のシステムを自動で消去しない。規範文、ローカル設定、ネゴシエーション結果、認証されたパケット処理、利用実態の測定は別の証拠である。鍵寿命の記述だけから一つにまとめてはならない。

出典