要約

  • RFC 3078 の整合性カウンターは、MPPE パケットの欠落や順序の断絶を検出できた。失われた暗号文を再生したり、次の平文がアプリケーションへ届いたと証明したりするものではない。
  • ステートレス・モードは差分だけ鍵を進められた。ステートフル・モードは受信パケットを捨て、CCP Reset-Request を返し、送信側の FLUSHED パケットを受けるまで復号状態を信用できなかった。

欠落を知らせたパケットを利用できない

受信側が予想した値と、実際に届いたカウンターが違う。その差は、途中の履歴が欠けたことを明確にする。しかしステートフル・モードでは、送信側が既に鍵を更新し、受信側が古い RC4 状態に残っている可能性がある。新しい番号を見つけることと、その中身を読めることは同じではない。

RFC 3078 は受信側に、そのパケットを破棄し、データを含まない CCP Reset-Request を送るよう求めた。さらに FLUSHED が付いたパケットが届くまで、後続を黙って捨てる。送信側は要求を受けると RC4 テーブルを初期化し、次のパケットに FLUSHED を立てる。別の Reset-Ack は不要で、送信側の次の動作そのものが応答となった。

カウンターは断絶の証拠を作った。FLUSHED は継続可能な共通状態を作った。だが失われたパケットの内容も、アプリケーション上の結果も、そのどちらからも復元されない。

暗号化より前に複数の条件があった

RFC 3078 は2001年3月に Informational RFC として公開され、PPP パケットに Microsoft Point-to-Point Encryption を適用する方法を記述した。RFC 2118 の MPPC と共有するオプションを更新したが、Internet Standard ではない。

MPPE は Compression Control Protocol のオプション18で交渉された。開始側は対応する選択肢を提示し、応答側は通常、128、56、40ビットのうち一つを選ぶ。ステートレスを希望するビットは別に存在した。交渉しなければ既定は暗号化なしであり、交渉を試みて失敗したならリンクを終了すべきとされた。

MPPE データを送るには、PPP が Network-Layer Protocol フェーズへ進み、CCP が Opened になっていなければならない。認証成功は Opened ではない。鍵を受け取ったことはモード選択ではない。128ビットを提案したことは、その強度が採用された証拠ではない。

周辺文書の役割も分かれている。RFC 2548 は RADIUS で方向別の MPPE 鍵を運ぶ。RFC 3079 は認証材料からの鍵導出を扱う。RFC 1962 は CCP の交渉とリセット、RFC 1661 は PPP のフェーズを定める。RFC 3078 は、実際に暗号パケットが流れ始めた後の状態遷移を担った。

12ビットが保存したのは位置であって内容ではない

整合性カウンターはパケットごとに一つ増え、4095の次にゼロへ戻る。受信側は保持していた期待値と比べ、欠落や順序の異常、鍵を何段進めるべきかを判断した。

数値の中に欠落パケットの複製はない。異常の原因も認証しない。キューの破棄、物理的損失、フィルター、順序入れ替え、攻撃者による変更が同じような観測を生み得る。連続した値であっても、各平文がアプリケーションに受理されたとは限らない。

RFC 3078 は MPPE が信頼性のあるリンクを必要としないとし、同期のためだけに RFC 1663 の Reliable Transmission を使うのは通常余分な負荷だと述べた。これはデータ損失を無効にする宣言ではない。暗号状態が損失後に進めるという意味であり、消えた内容は上位層の問題として残る。

また MPPE が暗号化するのは所定範囲の PPP プロトコルだけである。暗号化データを示すビットも完全性保護された証明ではない。「MPPE パケットを見た」というログだけでは、保護対象、交渉結果、復号成功を説明できない。

ステートレスは差分だけ鍵を進めた

ステートレス・モードではカウンターが変わるたび、つまり通常は各パケットごとに鍵が変わる。送信側は暗号化前に進め、受信側は新しいカウンターを読んだ後、復号前に進める。全暗号パケットに FLUSHED が付く。

前回が2で次が5なら、受信側は鍵変更を3回実行してから5番のパケットを復号する。Reset-Request を往復させずに現在位置へ追いつけるが、3番と4番のデータが戻るわけではない。

したがって「ステートレス」は共有状態の不在を意味しない。開始鍵、鍵変更関数、カウンターの意味、選択したモードは双方で一致していなければならない。各パケットが再構成の境界を持つため、回復判断を局所化できるだけである。

ステートフルは逆方向を復号条件にした

ステートフル・モードは、カウンター下位オクテットが 0xFF になるフラグ・パケットで鍵を変更した。その一包が失われると、送信側だけが新しい鍵へ進み得る。後のカウンターは食い違いを発見しても、正しい復号状態を直ちに与えない。

そこで Reset-Request の逆方向経路が、順方向データの回復に組み込まれる。一方向だけを観測する装置は欠落と後の FLUSHED を見ても、どの受信側がどの要求を出したか証明できない。要求だけ見ても有効な応答を証明できない。両方向の時刻と、リセット後に初めて成功した平文までが必要である。

RFC は、ステートフル再初期化によって二つのパケットが同じ鍵を使う可能性も警告し、Internet 上のレイヤー2トンネルなど損失のある環境でこのモードを避けるよう勧めた。これは特定の状態機構への警告であり、全実装の障害率を示すものではない。

交渉は保護されていなかった

MPPE の交渉には完全性保護がなかった。能動的な攻撃者が Supported Bits を変え、見かけの強度を弱められる。ローカル設定が許容しない選択を拒否すれば影響を抑えられるが、交換そのものが認証されるわけではない。

整合性カウンターを変更して同期を崩すことや、暗号化データ・ビットを反転してサービス拒否を起こすことも指摘された。ヘッダーは状態機械への入力であって、監査のための信頼済み証明書ではない。

RC4 を含む歴史を現在の推奨と混同してもいけない。RFC 4345 は後に SSH 向けの改良 Arcfour モードを記述したが、別の構成である。鍵長だけでは安全性を語れないという補助線にはなるものの、MPPE の移行や現在の普及を示さない。

保存すべきものは遷移の鎖である

PPP セッションとピア、認証結果、秘密を露出しない初期鍵の由来と世代、CCP の提案・NAK・確認、選択強度とモード、Opened の時刻を保存する。方向ごとに、期待値と観測値、4095の周回、欠落幅、FLUSHED、暗号化データ・ビット、0xFF 境界、破棄数、Reset-Request の送受信、待機中の破棄、再初期化と最初の復号成功を結びつける。

さらに上位プロトコルの系列、再送、確認、業務結果へ進む。RC4 テーブルが揃っただけでは、失われたメッセージもその効果も戻らない。

Lu Heng の現実層という見方では、認証、鍵導出、鍵配送、交渉、受信、損失検出、同期回復、平文化、アプリケーション配送は別々の事実である。実装がそれらを接続したときだけ、運用上の主張が成立する。

出典