暗号の系統的失敗：歴史的に破られたプロトコル分析

破綻は「解読」ではなく「定型的な失敗」

歴史的に破られた暗号プロトコルを並べると、共通点が見えてきます。AES や RSA そのものを数学的に解いた例はほとんどなく、プリミティブを束ねる設計・実装・運用のどこかにある定型的な欠陥が突かれています。攻撃者は困難な数学問題を解くのではなく、設計者が無防備に開けた抜け道を通っただけです。

破綻は次の三類型に整理できます。本稿はこの軸で WEP・SSLv3/POODLE・RC4・MD5 を分析し、再発を防ぐ判断基準を抽出します。

• 設計の失敗：プリミティブは健全でも、組み合わせ方や鍵・nonce・IV の与え方が壊れている。
• プリミティブの弱体化：アルゴリズム自体が時間とともに解析され、安全余裕が消える。
• 運用の硬直：弱い方式を互換性のために残し、攻撃者が安全な方式から弱い方式へ引きずり下ろせる。

WEP：IV 再利用という設計の失敗

WEP（Wi-Fi の旧暗号）はストリーム暗号 RC4 を使い、フレームごとに RC4(IV || 共有鍵) で鍵ストリームを生成して平文と XOR しました。問題は IV がわずか 24 ビットだった点です。

WEP の鍵ストリーム:  keystream = RC4(IV || K)     # K は全端末で共有、IV は 24 ビット
暗号化:              C = P XOR keystream
2 フレームで同じ IV が出ると:
  C1 XOR C2 = P1 XOR P2       # 鍵ストリームが相殺し、平文同士の XOR が露出

24 ビットの IV 空間は約 1670 万通りしかなく、混雑した AP では数時間で必ず IV が衝突します。ストリーム暗号で同じ鍵ストリームを二度使うと、二つの暗号文の XOR から鍵ストリームが消え、平文の相関が漏れます。これは nonce/IV の一意性が崩れたときの典型的な破綻で、乱数生成器の障害と nonce 再利用 と同根です。

さらに WEP は完全性保護に線形な CRC-32 を使いました。CRC は XOR に対して準同型的に振る舞うため、攻撃者は暗号文の特定ビットを反転させ、それに対応する CRC の補正ビットも反転させることで、復号後に正しいチェックサムを保ったまま平文を改ざんできました。決定打は FMS 攻撃（2001）で、RC4 の鍵スケジュールの偏りと既知の IV を組み合わせ、集めたフレーム数に比例して共有鍵そのものを回復できることが示されました。

SSLv3 / POODLE：CBC パディング検証の構造欠陥

SSLv3 の CBC モードは MAC-then-Encrypt（平文に MAC を付けてから暗号化）を採り、復号側はまず復号し、パディングを剥がし、最後に MAC を照合しました。SSLv3 のパディングは末尾 1 バイトだけがパディング長を示し、それ以外のパディングバイトの中身を検証しない仕様でした。この緩さが POODLE（2014）の入口です。

攻撃者は中間者として、ターゲットブロックの暗号文を末尾ブロックにコピーします。CBC 復号では P[末尾] = D(C[ターゲット]) XOR C[末尾の手前] となり、復号後の末尾バイトがちょうどパディング長と一致すれば検証を通過します。1/256 の確率で通過し、通過した瞬間に末尾バイトの値が方程式から確定します。位置をずらして繰り返せば、1 バイトあたり平均 256 リクエストで HTTPS Cookie を 1 バイトずつ復号できます。詳細な 1 バイト復号の機序は パディングオラクル攻撃 と共通の構造です。

POODLE の核心（CBC + パディング中身を検証しない）:
  攻撃者が C[末尾] := C[ターゲット] に差し替える
  検証通過なら  D(C[ターゲット])[15] XOR C[末尾の手前][15] = 15（=末尾の期待値）
  → D(C[ターゲット])[15] が判明 → 本物の平文バイトが XOR 一発で求まる

POODLE の致命性はダウングレードと組み合わさった点にあります。当時のクライアントは接続失敗時に古いプロトコルへ自動的に落ちる挙動があり、攻撃者がハンドシェイクを妨害するだけで TLS 1.2 対応の両端を SSLv3 へ引きずり下ろせました。これは運用の硬直（弱い方式の温存）が設計欠陥を実害に変えた例です。対策は SSLv3 の全面廃止と、ダウングレードを暗号学的に封じる TLS_FALLBACK_SCSV の導入でした。プロトコル選択を安全に行う原理は 暗号アジリティとネゴシエーション、TLS のレコード構造は TLS / SSL を参照してください。

RC4：プリミティブの弱体化

RC4 は実装が軽く広く使われましたが、鍵ストリームに統計的なバイアスがあることが累積的に判明しました。理想的なストリーム暗号は各バイトが一様分布すべきですが、RC4 は出力の先頭付近に偏りを持ち、特に第 2 バイトが値 0 になる確率が理論値 1/256 の約 2 倍といった偏りが知られます。

理想:  P(出力[i] = v) = 1/256  （全位置・全値で一様）
RC4:   P(出力[2] = 0x00) ≈ 2/256  ほか多数の位置で系統的な偏り
帰結:  同一平文を膨大な異なる鍵で暗号化させ、各位置の出現頻度を集計すると
       偏りが平文バイトの推定に直結する（broadcast 攻撃）

単発では無害に見える偏りが、TLS の文脈で実害化しました。Web 認証 Cookie のように同じ秘密が多数のセッションで同じ位置に繰り返し現れると、攻撃者は被害者のブラウザに何度も再接続させ、各位置のバイト頻度を統計的に積み上げて Cookie を復元できます。アルゴリズムは何も変わっていないのに、解析の進展と利用文脈が重なって安全余裕が消えた——これがプリミティブ弱体化の本質です。2015 年に RFC 7465 が TLS での RC4 を全面禁止しました。

MD5 衝突の悪用：完全性の前提が崩れる

MD5 は衝突耐性——異なる二つの入力が同じハッシュになる組を見つけられない性質——を前提に署名・証明書で使われました。2004 年に Wang らが現実的な衝突（共通接頭辞をもつペア）を提示し、2007 年には選択接頭辞衝突（攻撃者が任意に選んだ二つの接頭辞それぞれに、同じ MD5 値へ収束する後続ブロックを付加できる）まで構成可能になって、前提が崩れました。

最も衝撃的な悪用が、不正な中間 CA 証明書の偽造（2008、後に Flame マルウェアが実戦投入）です。攻撃者は CA に署名させる正規の証明書要求と、同じ MD5 値を持つ別内容の証明書（CA 権限フラグ付き）を衝突ペアとして用意します。CA は正規要求のハッシュに署名しますが、その署名はハッシュ値が同一なので偽造証明書にもそのまま有効です。署名は中身ではなくハッシュにかかる、という原理が逆手に取られました。衝突攻撃の構成原理は ハッシュ衝突攻撃 を参照してください。

署名の検証式:  verify(署名, ハッシュ(証明書内容)) が真かを見る
攻撃:  ハッシュ(正規CSR) == ハッシュ(偽造CA証明書)   # MD5 衝突で成立
  → CA が正規CSRに付けた署名が、そのまま偽造CA証明書でも検証を通る
  → 任意ドメインに有効な証明書を発行できる中間CAが手に入る

ここで重要なのは、衝突耐性が要る用途と原像耐性だけで足りる用途を混同してはならない点です。攻撃者が両方の入力を選べる署名・証明書・コミットメントでは衝突耐性が必須で、MD5（および SHA-1）は失格です。一方、HMAC のように攻撃者が片方しか制御できない用途では、衝突がただちに破綻には直結しません。用途ごとに必要な性質を見極めるのが、ハッシュ選定の核心です。

四つの破綻を類型で並べる

系統と教訓：同じ轍を踏まないために

時系列で見ると、破綻には連鎖があります。RC4 という一つの弱いプリミティブは、まず WEP（2001、IV 設計と結合して鍵回復）で、次に TLS（2015、バイアスで Cookie 復元）で、それぞれ別の文脈で爆発しました。CBC + 復号後検証という一つの設計欠陥は、古典パディングオラクル（2002）→ Lucky13（2013）→ POODLE（2014）と顔を変えて再来しました。衝突可能なハッシュは MD5（2008）から SHA-1（2017、SHAttered）へと同じ轍をたどりました。一つの欠陥が複数のプロトコルに伏在し、文脈ごとに発火するのが系統的失敗の特徴です。

破られた暗号の歴史は、アルゴリズムの敗北史ではなく前提の管理の失敗史です。プリミティブの強度を語る前に、それを束ねる設計が完全性と一意性を保証しているか、運用が弱い方式とダウングレードを許していないかを問う。証明書まわりで同じ轍を避ける実務は X.509 証明書チェーン検証 も合わせて確認してください。