VPNのnonceとは何か、再利用がトンネルを壊す理由

ほとんどの人はVPNプロファイルでnonceという語に出会い、ピア間でコピーするもう一つの共有秘密だと思い込みます。そうではありません。nonceは同じ鍵の下で決して繰り返してはならない値であり、nonceベースの暗号化のほとんどでは平文で流れます。混乱は誰かが手作業で編集するまで無害なままで、そこから本当の破損が始まります。

nonceは実際どこから来るのか

認証付き暗号化では、鍵の下で暗号化されるメッセージごとに異なるnonceが必要です。プロトコルはこの要件を、単調に増加するカウンタ、パケット識別子と組み合わせたソルト、十分に長いランダム値といったさまざまな方法で満たします。IKEv2は初期交換でnonceを交換し、それらは秘密ではなく鍵導出への公開入力です。

一意性は構造的にも確率的にもなり得ます。カウンタは折り返すまで繰り返せないため、プロトコルはそのずっと前に鍵更新の点を定めます。ランダム値は、メッセージ上限内で衝突が起こり得ないと言えるだけのビット数に依存し、これは異なる失敗モードを持つ別の論拠です。プロトコルの文書はどちらの方式が当てはまるかを示しており、どちらも定められた上限が守られている間だけ安全です。

再利用が実際に何を犠牲にするか

一つの鍵の下でnonceを再利用することは、小さな効率の問題ではありません。GCMでは、IVを共有する二つのメッセージによって、観察者は認証鍵を復元し、二つの平文の排他的論理和を計算できます。ストリームベースの構成も同じように鍵ストリームを再利用し、暗号文を秘密ではなくパズルに変えてしまいます。

だからこそ実装はカウンタが折り返す前に鍵を更新し、状態が不確かなときには続行せず停止します。ピアがまだ古い鍵を保持している間にカウンタをリセットする再起動や、セッションの途中で取得したスナップショットから復元された仮想マシンは、まさに上限が防ぐために存在する状況です。攻撃者は不要で、通常の運用だけで十分です。

手作業の編集が間違った修正である理由

カウンタ、ソルト、パケット識別子は両端が共有する状態機械です。片側を変えるともう片側の同期が崩れ、トンネルはルーティング問題のように見える形で失敗します。サポートされた手段は新しい鍵交換であり、両端の状態を同時にリセットします。

パスワードとnonceも異なる役割を果たします。パスワードは鍵導出への秘密の入力であり、nonceはメッセージごとの公開入力です。長い秘密を求めるnonceというラベルのプロファイル項目は、通常は別名の静的鍵か事前共有秘密なので、推測せずにその項目の文書を読んでください。

助言がnonceの扱いに関するものである場合、修正はメンテナーの修正版であり、別の暗号や短い鍵ではありません。nonceという語を避けるために暗号を変えることは、問題を解決するのではなく移動させます。

推測せずに警告を読む

カウンタやnonceに関するログ行は通常、攻撃ではなく失われた状態を表します。一方のピアが再起動したか、複製された仮想マシンが同じ識別情報を再利用したか、両端が鍵更新の設定で一致しているかを確認してください。その後、新しいセッションを確立し、メッセージが戻るかどうかを観察します。

診断は無関係な障害と切り離してください。読み込めないページや、ループする資格情報の要求は、nonceの再利用の証拠ではなく、そう扱うと問題がその上にあるのに暗号層へ入り込むことになります。

通常の利用では、安全な規則は短く、nonceは実装に管理させ、両端をサポートされたバージョンに保ち、状態のリセットは値を編集するのではなく鍵を更新する理由として扱います。プロファイル項目がベンダーの文書にない場合は、その値をでっち上げないでください。トンネルの修正は、どの層を見ているかを知ることから始まります。