要約

  • RFC 7146 は、ブロックストレージを保護する IPsec の相互運用基準を更新し、RFC 3723 の 3DES-CBC 実装必須を AES-CBC 実装必須へ置き換えた。
  • 3 GiB は、64 ビットブロック暗号の 32 GiB birthday bound より一桁小さい量を例示した値であり、一律の鍵更新規則でも、攻撃発生の報告でもない。

ストレージセッションより先にデータ量が限界へ

IPsec のセキュリティアソシエーションが稼働中のストレージを運んでいても、セッションの終了前に暗号上の制約へ近づくことがある。2014 年 4 月の RFC 7146 が扱ったのは、まさにそのずれだった。ブロックストレージのプロトコルは毎秒数ギガビットでの動作を想定される一方、3DES が一度に処理するブロックは 64 ビットである。見るべきなのは鍵の経過時間だけでなく、同じ鍵で処理した総データ量だった。

RFC 7146 は RFC 3723 の IPsec 要件を改めた。以前の基準では、実装は CBC モードの 3DES をサポートしなければならず、カウンターモード AES（AES-CTR）の実装が推奨されていた。改定後は両者が任意となり、AES-CBC の実装が必須になった。NULL 暗号をサポートする要件は維持された。この方式は、機密性は提供せず認証と完全性を提供するアソシエーションで使える。ここで定めているのは実装能力であって、各運用環境でどの方式を使うかではない。

上限はタイマーではない

64 ビットブロック暗号について、RFC 7146 は birthday bound を 32 GiB と説明する。単一鍵の下でこの量に近づくと弱点が現れ始めるため、十分手前で鍵を更新するのが望ましい。多ギガビット毎秒のリンクで 3 GiB ごとに更新すれば一桁分の安全余裕が得られる、というのが文書の例だ。全システムに課す閾値ではなく、運用負荷を見える形にする例示である。

数 GiB はストレージ転送では短時間に到達しうる。セッションの長さだけで鍵寿命を決めると、データ量の増加を見逃す可能性がある。頻繁な更新には、通信を止めずに両端が新しいアソシエーションを交渉・導入できることも必要だ。RFC 7146 はこの圧力を示すが、すべての 3DES セッションが上限に達したとも、攻撃が成功したとも述べていない。

AES のブロック長は 128 ビットで、同 RFC が示す birthday bound は 2^68 バイトと大きい。AES-CBC は相互運用性のための新たな実装必須方式になった。ただし AES の各モードを同一視してはならない。IKEv2 を実装する場合、AES-GCM も実装することが推奨される。AES-CTR の位置づけが変わった理由は別で、ハードウェア実装上の事情が GCM に有利になったためと説明される。CTR の安全性が破られたという説明ではない。

要件更新が示した範囲

RFC 7146 は要件の更新であり、導入済み機器の調査でも、ストレージ網の実測でも、現在の暗号方式を一律に推奨する文書でもない。低速で鍵更新の頻度が許容できる場合、3DES-CBC の実装は引き続き任意で認められる。変わったのは、対象とするブロックストレージ用途での最低限の相互運用保証であり、すべての既存利用が消えたわけではない。

この歴史が示すのは、実装要件には運用の前提が埋め込まれているということだ。方式が実装可能なままでも、通信速度が上がれば想定範囲内に保つコストは変わる。アルゴリズム対応、交渉されたアソシエーション寿命、転送バイト数、シーケンス番号、停止せずに鍵を更新する能力を一体で見る必要がある。RFC 7146 はその連関を明示したが、実際のポリシーと導入状況の証拠は運用者に委ねた。

出典：RFC 7146、RFC 7146 情報、RFC 7146 正誤表、RFC 3723、RFC 4106、RFC 3602、RFC 4303、RFC 4301、RFC 8221、RFC 6071、RFC 6176。