WireGuard の暗号設計（Noise プロトコルフレームワーク）

WireGuard が解く問題：選択肢を消して安全にする

IPsec や OpenVPN が抱える複雑さの多くは「ネゴシエーション」に由来します。鍵交換方式、暗号アルゴリズム、ハッシュ、認証方式を相互に合意するための膨大な状態機械があり、その組み合わせの中に弱い設定やダウングレード攻撃の余地が残る。WireGuard の設計思想は正反対で、暗号スイートを1つに固定し、設定項目を極限まで削ることで安全性を構造的に保証します。

具体的な固定スイートはこうです。

ネゴシエーションが無いということは、攻撃者が「弱い方式を選ばせる」介入点が存在しないということです。アルゴリズムを更新したいときはプロトコルのバージョン自体を上げる――この潔さが WireGuard の安全性の土台になっています。

Noise プロトコルフレームワークと Noise_IK

WireGuard のハンドシェイクは、自前の設計ではなく Noise プロトコルフレームワークに基づきます。Noise は「DH 鍵共有とハッシュチェーンの組み合わせ方」をパターン化した枠組みで、各パターンが満たす認証・秘匿の性質が形式的に定義されています。WireGuard が使うのは Noise_IK パターンです。

名前の IK は2文字それぞれが意味を持ちます。

• 1文字目 I（Immediate）：イニシエーター（接続を開始する側）の静的公開鍵を、最初のメッセージの中で相手に送る。ただし平文ではなく暗号化して送る。
• 2文字目 K（Known）：レスポンダー（受け側）の静的公開鍵を、イニシエーターが事前に知っている。

つまり WireGuard は「相手のサーバーの公開鍵はあらかじめ設定ファイルに書いてある」前提で動きます。これは TLS のように「接続してから相手の証明書を検証する」モデルとは異なり、PKI も証明書チェーンも要りません。鍵の真正性は設定の時点で人間が担保する、SSH の authorized_keys に近いモデルです。

ハンドシェイクの中身：ハッシュチェーンと複数 DH

Noise_IK のハンドシェイクは2メッセージ（イニシエーター→レスポンダー、レスポンダー→イニシエーター）で完結します。鍵は楕円曲線 Curve25519 上の ECDH で複数回計算され、その結果を順に HKDF でハッシュチェーンに混ぜ込んでいきます。各当事者は静的鍵ペア（長期）とエフェメラル鍵ペア（毎回新規）を持ちます。

記号: s=静的鍵, e=エフェメラル鍵, DH(a,b)=a の秘密鍵と b の公開鍵の ECDH
i=イニシエーター, r=レスポンダー

メッセージ1（i → r）:
  ei を生成して公開鍵を送る
  DH(ei, sr)  ← 即座にレスポンダーと共有秘密を作れる（K の効果）
  この鍵で si（イニシエーターの静的公開鍵）を暗号化して同梱（I の効果）
  DH(si, sr)  ← 双方の静的鍵を結びつけ相互認証に寄与

メッセージ2（r → i）:
  er を生成して公開鍵を送る
  DH(er, ei)  ← 双方エフェメラルで前方秘匿性の核
  DH(er, si)  ← イニシエーターの静的鍵を認証に結ぶ

ポイントは、エフェメラル鍵同士の DH（DH(er, ei)）が前方秘匿性を供給することです。静的鍵が将来漏れても、毎回捨てられるエフェメラル鍵は復元できないため、過去のセッションは守られます。一方、静的鍵を絡めた DH が「相手が正しい秘密鍵の持ち主か」という認証を担います。これらをすべて1本のハッシュチェーンに HKDF で畳み込むので、どれか1つでも食い違えば最終的なセッション鍵が一致せず、ハンドシェイクは静かに失敗します。

cryptokey routing：鍵がそのままルーティングになる

WireGuard 最大の発明が cryptokey routing です。各ピアに対して「公開鍵」と「そのピアが名乗ってよい IP アドレス範囲（AllowedIPs）」を1対1で対応させた表を持つ、というだけの仕組みです。

[Peer]
PublicKey  = <相手の Curve25519 公開鍵>
AllowedIPs = 10.0.0.2/32, 192.168.5.0/24

この表が2方向で働きます。

• 送信時（ルーティング）：宛先 IP が AllowedIPs のどれに一致するかで、どのピアの鍵で暗号化すべきかが決まる。ルーティングテーブルと暗号鍵選択が一体化している。
• 受信時（認証）：あるピアの鍵で正しく復号できたパケットでも、その内側の送信元 IP が当該ピアの AllowedIPs に入っていなければ破棄する。鍵で本人確認し、IP 範囲で「名乗ってよい住所」を縛る。

この設計の効果は大きい。アクセス制御リストや IP ベースの認証を別に持つ必要がなく、「正しい鍵を持つ」ことと「その IP を名乗る資格がある」ことが表の1行に集約されます。

ステルス性とローミング：状態と無言を設計に織り込む

WireGuard は「攻撃者に存在を気取られない」ことと「クライアントの IP が変わっても切れない」ことを、明確な設計判断として組み込んでいます。

ステルス性（無言の原則）。WireGuard は、正規のピアから来た正しく認証できるパケット以外には一切応答しません。鍵が一致しないパケットや形式不正なパケットは、エラーも RST も返さず黙って捨てる。ポートスキャンしても応答が無いため、サーバーがそこで動いているかどうかすら外部からは判別しにくい。さらにハンドシェイク開始時には DoS 緩和のための cookie 機構があり、サーバーが負荷下にあるとき MAC 付き cookie を要求することで、送信元 IP を詐称した接続氾濫を退けます。

ローミング。これは cryptokey routing の自然な帰結です。パケットの正当性は送信元 IP/ポートではなく鍵で判定されるため、クライアントの外側アドレスが変わっても問題ありません。サーバーはあるピアの鍵で復号成功したパケットの送信元アドレスを見て、そのピアの宛先エンドポイントを最新の値に更新します。Wi-Fi からモバイル回線へ切り替えても、再ハンドシェイクすら不要でセッションが継続する。

まとめ

WireGuard は Noise_IK により、相手の公開鍵を既知とする前提で前方秘匿な認証付き鍵共有を 1-RTT で確立し、Curve25519・ChaCha20-Poly1305・BLAKE2s・HKDF の固定スイートでネゴシエーションとダウングレード攻撃を構造的に排除します。ハンドシェイクは複数の ECDH をハッシュチェーンに畳み込んで秘匿と認証を同時に達成し、cryptokey routing がルーティングと認証を「公開鍵と AllowedIPs の表」1つに統合する。無言の応答方針がステルス性を、鍵ベースの判定がローミングを、それぞれ自然に成立させています。

土台となる楕円曲線鍵共有は 楕円曲線暗号の内部 と Diffie-Hellman、データ本体を守る暗号は AEAD の設計原理、エフェメラル鍵が支える 前方秘匿性 と併せて読むと、WireGuard が「少ない部品で堅い」理由が原理から腑に落ちます。