認証付き鍵交換(AKE)の原理（PAKE・OPAQUE）

鍵を作るだけでは足りない：認証と鍵共有の一体化

Diffie-Hellman（DH） は盗聴されている回線でも二者が同じ共有鍵に到達できる仕組みでした。しかし DH 単体は「誰と鍵を共有したか」を一切保証しません。回線を流れる公開値には身元が付いておらず、値を差し替える攻撃者を防げないからです。

Alice ──A──▶ [攻撃者 M] ──A'──▶ Bob
Alice ◀─B'── [攻撃者 M] ◀──B─── Bob

M は Alice とは鍵 K1、Bob とは鍵 K2 を別々に DH 確立し、
両者になりすまして全通信を中継・復号する（中間者攻撃 / MITM）。

この穴をふさぐには、鍵共有と相手認証を結びつける必要があります。これを一つのプロトコルで達成するのが**認証付き鍵交換（AKE: Authenticated Key Exchange）**です。AKE は「同じ鍵に到達する」だけでなく「正しい相手とだけ到達する」ことを保証します。

認証の根拠には何を使うか。証明書や長期公開鍵を使うのが TLS の方式ですが、人間が相手の場合、信頼できる根拠はパスワードという短い秘密しかないことが多い。そこで生まれたのが、パスワードだけで AKE を成立させる PAKE です。

PAKE：パスワードを送らずにパスワードで認証する

PAKE（Password-Authenticated Key Exchange）は、二者が同じパスワードを知っていることを前提に、相互認証つきの共有鍵を確立するプロトコルです。鍵となる性質は次の二点です。

• パスワードそのものも、その検証に使える値も回線に流さない。
• 攻撃者が観測・改ざんしても、1回の試行につき1個のパスワード推測しか検証できない。

二点目が決定的に重要です。素朴な設計、たとえば「パスワードのハッシュを送って一致を確認する」方式だと、攻撃者は流れたハッシュを記録し、オフラインで辞書全体を総当たりできてしまいます。PAKE はこのオフライン辞書攻撃を構造的に封じます。

PAKE では、攻撃者にできるのはオンライン推測だけです。1回の接続試行で1個の候補しか試せず、しかも当たったかどうかは相手に問い合わせないと分からない。これならレート制限やアカウントロックで実害を抑えられます。原理的には、DH の公開値をパスワード由来の値で「ねじる（マスクする）」ことで、正しいパスワードを知る相手とだけ最終鍵が一致する、という構造で実現します。

SRP：先駆的な aPAKE とその限界

初期に広く実装された PAKE が **SRP（Secure Remote Password）**です。SRP は単なる PAKE ではなく **aPAKE（asymmetric / augmented PAKE）**でした。両者の違いは重要です。

aPAKE の狙いは、サーバーが侵害されてもパスワードを直接奪われないことです。サーバーは平文パスワードの代わりに、パスワードから一方向に導いた**検証子（verifier）**を保管します。クライアントだけがパスワードを知り、サーバーは検証子で相手を確かめます。

しかし SRP には弱点がありました。第一に、SRP の検証子は漏れるとオフライン辞書攻撃の入力に使える点です。サーバーが侵害され検証子が流出すると、攻撃者は手元で候補パスワードから検証子を再計算し、一致を探せてしまいます。これは aPAKE が本来防ぎたかった事態です。第二に、SRP は標準的な DH 群の上に独自の代数構造を載せており、厳密な安全性証明が難しく、楕円曲線への移行も素直ではありませんでした。

OPAQUE：事前計算辞書攻撃まで防ぐ現代的 aPAKE

OPAQUE は、SRP の弱点を解消するために設計された現代的な aPAKE で、IRTF/CFRG の RFC 9807 として仕様化されています。中核には **OPRF（Oblivious Pseudo-Random Function、忘却擬似ランダム関数）**という部品を使います。

OPRF は、二者が協力して擬似ランダム関数 PRF(key, input) の値を計算する仕組みですが、決定的な性質を持ちます。

• サーバーは鍵 key を持つが、クライアントの入力 input（＝パスワード）を知ることができない。
• クライアントは出力を得るが、サーバーの鍵 key を知ることができない。

登録時:
  クライアント: パスワード pw を盲検化して送る（blind(pw)）
  サーバー    : 自分の OPRF 鍵で評価して返す
  クライアント: 盲検を外し rwd = OPRF(key, pw) を得る
              → rwd で自分の秘密鍵を含む封筒(envelope)を暗号化しサーバーへ保存
  サーバー    : envelope と OPRF 鍵だけ保管（pw も rwd も平文では持たない）

このため OPAQUE では、サーバーはパスワードを検証できる値を一切平文で保持しません。サーバーが保管するのは「OPRF 鍵」と「rwd で暗号化された封筒」だけ。rwd を得るにはパスワード pw とサーバーの OPRF 鍵の両方が必要なので、攻撃者は次の二重の壁にぶつかります。

1. サーバーが侵害され封筒と OPRF 鍵が漏れても、rwd を計算するには各パスワード候補ごとに OPRF 評価をやり直す必要があり、事前計算した辞書を使い回せない。
2. OPRF 鍵を知らない外部の盗聴者は、封筒を見ても辞書攻撃の足がかりすら得られない。

封筒の暗号化には、rwd をそのまま鍵にするのではなく パスワードハッシュ（Argon2 など） を併用するのが定石です。これにより、万一辞書攻撃に持ち込まれても1候補あたりのコストを意図的に重くできます。

相互認証はどう達成されるか

PAKE / aPAKE が「相互」認証を達成する仕組みを整理します。鍵は、正しいパスワード（または検証子）を持つ者だけが同じ最終鍵に到達するという構造です。

1. 双方がエフェメラルな DH 公開値を交換する（鍵共有の素材）
2. パスワード由来の値で公開値や導出鍵を変形・束縛する
3. 各自が共有鍵から「確認タグ（key confirmation）」を計算して送り合う
4. タグが一致 ⇒ 相手も同じパスワード/検証子を知っていたと確定
   タグが不一致 ⇒ 接続を破棄。攻撃者は1推測ぶんしか情報を得ない

ここで攻撃者が偽の公開値を注入しても（中間者攻撃を試みても）、パスワードを知らない限り相手と同じ鍵には到達できず、確認タグの照合で必ず弾かれます。しかも失敗から漏れる情報は「その1つの推測が違った」ことだけで、辞書全体を試す手がかりにはなりません。これが、生 DH には欠けていた「鍵共有と相手認証の一体化」の正体です。

OPAQUE はこの最終段に、確立した rwd で復号した封筒からクライアントの長期鍵を取り出し、標準的な AKE（HMQV など）を走らせる構成を採ります。結果として、パスワードという低エントロピーの秘密から出発しながら、署名鍵ベースの AKE と同等の相互認証つきセッション鍵が得られます。導出した鍵をそのまま使わず HKDF などの KDF に通して用途別に展開するのも、通常の鍵共有と同じ作法です。

まとめ

生の Diffie-Hellman は鍵を作れても相手を認証せず、中間者攻撃に無力でした。これを解くのが鍵共有と相手認証を一体化した AKE で、認証の根拠にパスワードを使うのが PAKE です。PAKE はパスワードも検証可能な値も回線に流さず、攻撃者に1試行1推測のオンライン攻撃しか許さないことでオフライン辞書攻撃を封じます。

非対称版の aPAKE はサーバーにパスワード平文を置かず侵害被害を限定しますが、先駆けの SRP は検証子流出時にオフライン辞書攻撃が成立する弱点を残しました。OPAQUE は OPRF を核に、サーバー鍵なしには検証値 rwd を計算できない構造で事前計算辞書攻撃まで防ぎ、標準的な楕円曲線上で安全性証明も伴う現代的 aPAKE として RFC 9807 に仕様化されています。鍵共有・相手認証・辞書攻撃耐性は別々の課題であり、PAKE/OPAQUE はこれらを一つのプロトコルで満たします。背景となる鍵共有の数理は Diffie-Hellman、なりすまし防止の全体像は 認証と認可 と併せて押さえると理解が深まります。