要約

  • RFC 5269 は、送信元 CGA の主張に使う CGA/SEND 鍵、共有秘密を運ぶだけの独立した公開鍵ペア、FBU の MAC を生成する共有ハンドオーバー鍵を分離している。
  • 有効な MAC が示すのは、previous access router における特定の previous care-of CGA の転送変更権限だけである。端末の所在、attachment、NCoA、到達、利用者、アプリケーション、後続の Mobile IPv6 binding は含まれない。

守るべき対象は「移動」ではなく危険な一命令だった

Fast Binding Update は、移動前のアドレスに届くトラフィックを別の経路へ送るよう previous access router に求める。正当な端末より先に攻撃者がこの命令を出せるなら、データプレーンの暗号を破らなくても被害者のパケットを奪える。

RFC 5269 は移動前に共有鍵を用意し、FBU に authorization MAC を付ける。PAR は FBU の Home Address Option にある旧 care-of CGA から鍵を探し、認証子を検証して初めて forwarding を変更する。一致する鍵がなければ変更してはならない。

ここで得られるのは価値ある制御だが、結果名を「ハンドオーバー認証済み」とすると事実が拡張される。MAC は無線接続を観測していない。NCoA に対する DAD も、新ルーターからのバッファ解放も、アプリケーションでの受信も確認していない。検証したのは旧アドレスに関する一つの制御操作である。

三種類の鍵は三種類の責任を表す

第一は CGA/SEND の鍵ペアである。移動ノードは care-of CGA を送信元として RtSolPr を送り、CGA Parameters Option と SEND Signature Option を付ける。SEND の検証により、要求者がこの交換で当該送信元 CGA を主張できることが分かる。

第二はハンドオーバー鍵を暗号化して運ぶためだけの鍵ペアである。公開鍵アルゴリズムとパラメーターは SEND と同じだが、鍵そのものは独立していなければならない。RFC 5269 は、別の暗号化や署名に使うことを禁じる。公開鍵は Handover Key Request Option に入り、秘密鍵は端末内で応答の共有秘密を復号する。

第三はアクセスルーターが生成または再利用する共有ハンドオーバー鍵である。専用公開鍵で暗号化され、Handover Key Reply Option で返される。後で FBU の認証子を作るのはこの共有秘密である。

三つを mobilityKey のような一項目に畳むと、署名、秘密の運搬、メッセージ認可という異なる作用が見えなくなる。生成主体、利用可能な操作、更新条件、漏えい時の影響範囲も異なる。鍵素材が同じ種類の暗号に見えても、権限は同じではない。

SEND の成功前に状態を作らない

RtSolPr には専用の暗号化公開鍵、希望する FBU Algorithm Type、CGA と Signature の SEND オプション、nonce が含まれる。アクセスルーターはまず SEND を検証する。失敗した要求には Handover Key Reply Option を付けず、新しい鍵を作らず、そのアドレスに既にある正当なレコードも変更してはならない。

この順序は DoS 対策でもある。強い乱数を生成し、暗号化し、キャッシュ領域を確保するには資源が要る。要求者を検証する前に状態を割り当てれば、攻撃者は未解決レコードを増やせる。認証済みの要求にもレート制御とキャッシュ上限は必要であり、「署名あり」は無限の処理能力を意味しない。

運用記録には SEND の判定と admission の判定を分けて残す必要がある。署名が正しくても容量規則で拒否され得る。鍵が返ったという事実だけでは、検証より後に割り当てたことを説明できない。

復号できても、応答元が正しいとは限らない

要求が有効なら、ルーターは CGA に既に関連付けた共有鍵を返すか、新しく生成する。PrRtAdv には暗号化された鍵、HK-LIFETIME、選択した Algorithm Type、要求から引き継いだ nonce が含まれる。

ルーター側も SEND の信頼モデルで認証される。アクセスルーターは適切な証明書を持ち、認証済み公開鍵に対応する秘密鍵で応答へ署名する。証明書経路がキャッシュされていない場合、CPS/CPA による発見が使われる。移動ノードは trust anchor までの経路と署名を検証し、認証されたルーター鍵でない応答を捨てる。

nonce は応答を特定の要求へ結び付ける。同時に複数の運搬鍵ペアを持つ場合には、どの秘密鍵で復号すべきかを示す。対応する nonce がなければ、ローカルの秘密鍵を総当たりするのではなく応答を破棄する。

したがって受領証は「復号成功」一行ではない。要求世代、CGA 主張、SEND 署名、ルーター検証、証明書経路、PrRtAdv 署名、nonce、アルゴリズム選択、対応秘密鍵、寿命が一続きになって初めて意味を持つ。

キャッシュのキーは主体間の関係である

ルーター側では、共有鍵を移動ノードの CGA とアルゴリズム、寿命に関連付ける。端末側で後の FBU に使う鍵を選ぶ際には、previous access router の識別と、そのリンクで使っていた previous care-of CGA の双方が要る。

同じ端末が複数ルーターの鍵を持つことも、同じルーターへ戻ることもある。ある関係で有効な鍵が別の関係にも有効とは限らない。「device ID」だけで引くキャッシュは粗すぎる。「現在のルーター」も誤りで、FBU が作用する相手は旧ルーターだからである。

正しい結合条件にはルーター、CGA、世代、アルゴリズム、有効期間、用途が含まれる。間違ったデータベース結合の後でも MAC の計算自体は成功し得る。暗号学は、どのレコードを選んだかの論理を保証しない。

アルゴリズムの交渉も証拠である

移動ノードは希望する FBU 認証 Algorithm Type を提示する。ルーターが対応していればそれを返し、対応しない場合は同等以上の強度を持つ方式を選ばなければならない。端末は返信で指定された方式を使う。

複数ルーターから応答があれば複数の鍵を保持できる。対応方式が一つもなければ再要求もできる。しかし侵害されたルーターの圧力を受け、最初の希望より弱い方式へ次の要求を下げるべきではない。

監査で MAC valid だけを残すと、その「valid」を定義した政策が消える。要求方式、返却方式、当時のポリシー世代、実行された暗号実装を一緒に保存する。将来のアルゴリズム廃止が過去の判断を無言で書き換えてはならない。

期限内のローカルコピーは再認可ではない

専用の運搬鍵ペアは、十二時間または十回のハンドオーバーの早い方までという上限が推奨される。共有ハンドオーバー鍵の既定寿命は十二時間、すなわち 43,200 秒である。

ルーターは選択した認証アルゴリズムに十分な強さの乱数鍵を生成し、CGA 公開鍵ごとに固有の値を割り当てる。異なるハンドオーバー鍵同士、そして CGA 鍵との間に相関を作ってはならない。

通常の Mobile IPv6 binding が完了する前に次の移動が起きるため、PAR はまだ有効な鍵を保持できる。端末が同じ care-of CGA で戻れば、ルーターは同じ鍵を再送してもよい。ただし端末は、手元のコピーが期限内という理由だけで再利用を仮定できない。ルーターから改めて受け取る必要がある。

ローカルにあること、時間切れでないこと、相手が保持していること、再配布されたことは四つの別状態である。通常の binding 完了後には端末が鍵を捨て、PAR は forwarding timeout または HK-LIFETIME のどちらかで関係を閉じる。

専用鍵を汎用の身分証へ変えてはならない

共有鍵はユーザートラフィックを暗号化しない。アプリケーションのセッション鍵でも、加入者や従業員を識別する証明でもない。提案された NCoA を検証せず、通常の Mobile IPv6 Binding Update や Return Routability を置き換えず、home agent や correspondent node の受理も証明しない。

現在の FMIPv6 基本文書は RFC 5268 を置き換えた RFC 5568 である。RFC 5568 は FBU authenticator に使う共有鍵の確立方法として RFC 5269 を引き続き参照する。拡張を読むときは現行の基本形式と組み合わせる必要があり、旧 RFC の廃止されたパケット形式を取り込んではならない。

後の SEND 仕様が証明書や trust anchor の配布を改善しても、MAC が表す範囲は広がらない。署名者についての保証が強くなれば、同じ狭い主張が強くなるだけである。

実行されたコードを追うと一つの鎖が見える

Lu Heng の Running-Code Primacy に従えば、「安全なモビリティ」という製品名ではなく、実際の処理を列挙する。CGA の主張、SEND 検証、専用公開鍵、認証済みルーターの署名、nonce の対応、共有鍵キャッシュ、選択アルゴリズム、FBU の MAC、forwarding 変更である。

reality layers の考え方は、鍵の所持、命令の認可、移動結果を分離する。秘密鍵を操作できることは暗号操作の支配を示す。SEND は限定されたアドレス主張を示す。認証子は経路変更の権限を示す。どれも新リンクへの接続やサービス継続の測定ではない。

緑の表示から、鍵用途、主体関係、世代、方式、寿命、メッセージへ戻れるときだけ抽象は可逆である。「認証済み」で履歴が終わる設計は、暗号が守った境界を管理画面で捨てている。

出典