要約

  • RFC 9807 の OPAQUE では、クライアントは登録時にも認証時にもパスワードをサーバーへ開示しない。ただし単一サーバーから該当する登録情報と秘密が漏れれば、その利用者に対するオフライン総当たり辞書攻撃は避けられない。
  • 利用者ごとの OPRF 鍵が別でも、根となる oprf_seed が共通なら侵害領域は共通になり得る。独立シード、偽応答、しきい値 OPRF、再登録はいずれも別の費用を伴う選択肢だ。

セキュリティ上もっとも危うい説明は、誤りではなく、正しいまま短すぎる説明である。

「サーバーはパスワードを一度も見ない」は OPAQUE について正しい。だが、その文だけでは、誰が OPRF の根を持つのか、一つの根が何人を束ねるのか、登録レコードと AKE 鍵が同じ復旧経路に置かれるのか、緊急時に休眠利用者まで再登録できるのかが分からない。見えなくなった秘密の代わりに、どの能力がどこへ移ったのかを問う必要がある。

2025 年 7 月の RFC 9807 は、拡張型パスワード認証鍵交換 OPAQUE を規定する。クライアントは Oblivious Pseudorandom Function、認証情報を回復するエンベロープ、認証付き鍵交換を組み合わせる。パスワードを渡さずに知識を証明し、サーバーと同じセッション鍵を得る。登録時にもパスワードは開示されない。

文書の位置づけも曖昧にしてはならない。RFC Editor の情報ページと Datatracker が示すとおり、これは IRTF ストリームの Informational RFC で、Crypto Forum Research Group の合意を表す。本文は IETF の成果物でも標準でもないと明記する。IETF のディレクトリへのリンクは資料発見のためであり、Standards Track の権威を付与するものではない。

パスワードを渡さないことの正確な意味

従来の方式では、TLS 1.3 が配送中のパスワードを保護し、その終端でアプリケーションへ平文の秘密を渡す。TLS は受信後の誤記録、メモリ漏えい、境界外の終端まで統制できない。安全な輸送と、安全な受信者は別の主張である。

OPAQUE は境界を越える対象を変える。RFC 9497 の OPRF では、サーバーが関数の鍵を持ち、クライアントはブラインド化した入力を提示する。クライアントだけが出力を得て、サーバーは入力も出力も知り得ない。RFC 9807 では、その結果をクライアント側でストレッチし、自らの認証材料を守るエンベロープもクライアントが作る。

オンライン交換は KE1、KE2、KE3 の三段階である。明示的なクライアント認証は三通目で成立する。したがって KE2 を送った時点を成功として記録してはいけない。有効な KE3 を受け取り ServerFinish が完了して初めて認証の証跡になる。プロトコルが正しくても、監視上の成功定義が早ければ不正対策の現実は誤る。

クライアントは共有 session_key と、サーバーが持たない export_key を受け取る。後者は付加データの保護に使えるが、相手を認証する前に利用してはならない。どちらも業務上の許可ではない。認証、セッション保護、データ復号、取引承認は別々の証拠である。

侵害後の推測は残る

OPAQUE の原論文 は、単一サーバー aPAKE の限界を明確にする。サーバーが侵害され、ある利用者の関連ファイルと秘密が漏れれば、そのパスワードをオフラインで総当たりする機会は避けられない。OPAQUE が防ぐのは、予測可能な写像に対する事前計算である。攻撃者は侵害後に得た材料を用い、候補ごとの費用を払わなければならない。

KSF はその費用を引き上げる。RFC 9807 は Argon2id や scrypt の構成を示し、RFC 9106 が Argon2 の指針を提供する。ただし計算するのはクライアントだ。メモリと時間を増やせば攻撃を重くできる一方、低価格端末、組み込み機器、復旧画面にも負荷がかかる。平均的なデスクトップの測定値ではなく、最も弱い対応機器における遅延、失敗、電池消費を見なければならない。

OPAQUE はオンライン推測や弱いパスワードを消さず、ブラインド化前に秘密を漏らす端末も救わない。サーバー侵害を無害にもできない。それでも、サーバーが再利用可能な秘密を持たないこと、事前計算への耐性、相互認証、前方秘匿性は大きな改善である。境界を広げて万能と語るより、狭く正確に語る方が強い。

個別鍵を束ねる一つのシード

サーバーは AKE 鍵ペアと oprf_seed を用意し、固有の credential identifier と組み合わせて利用者ごとの OPRF 鍵を導出する。各鍵は異なっても、その祖先は共有され得る。

RFC 9807 は、記載された利用者列挙対策を使う場合に共通シードを勧める一方、10.9 節で共通 oprf_seed が漏れれば依存する全クライアントの安全が損なわれると述べる。「利用者ごとに別鍵」という図だけでは、この横断的な根を表せない。

2024 年の (Strong) aPAKE Revisited は草案系統の多利用者性を分析した。共通シードだけで全パスワードが直ちに分かるという話ではない。一人のファイル侵害で全体シードを取得し、別利用者の OPRF 鍵を導出し、誠実なサーバーとの一度の通常対話を足場に、その別利用者への推測をオフラインへ移すという攻撃である。最終 RFC はこの研究を引用し、影響を明示した。

列挙対策が不要な用途では、クライアントごとの独立シードを選べる。ただし登録とログインを通じて同じ対応関係を保たなければならない。バックアップの不一致、探索の代替経路、復旧の誤りは、存在情報の漏えいやログイン不能につながる。根を分散するなら、その対応表も運用資産として統制する必要がある。

動くコードを第一とする考えで見れば、「利用者別鍵」は名称にすぎない。誰がシードを復元でき、誰が導出を実行でき、どのバックアップが何人分を再構成できるかが現実の権限である。

利用者列挙を隠すための別契約

未登録の識別子に対し、サーバーは偽の CredentialResponse を返せる。登録時にクライアントが作る masking_key によって、実在と偽装の応答を見分けにくくする。処理時間やエラー分岐が異なれば、それ自体が識別手段になる。

登録フローは対象外である。既存識別子と新規識別子を異なる扱いにせざるを得ないため、登録は列挙のオラクルとして残り、レート制限や利用制約が必要になる。偽応答は、サーバーの生成費用がクライアントの要求費用より低い場合、資源悪用の面も持つ。

masking_key は登録時にサーバーへ送るため、登録チャネルには認証、機密性、完全性が必要だ。RFC 9807 は TLS を挙げ、認証済みだが秘匿されていない経路で機密性を足す例として HPKE を示す。パスワードを隠したという理由で、その他の秘密を設置する入口を軽視してはならない。

共通シードと独立シードの選択は、存在秘匿、横断侵害、状態整合性、運用負荷の取引である。最小仕様、局所的な将来判断、自発的採用という考え方に従えば、共通規格は相互運用を定め、どの列挙脅威にどの管理構造を当てるかは現場が証拠とともに決める。

三つの保管領域を混同しない

OPRF シード、サーバー AKE 秘密鍵、RegistrationRecord 保管庫は別の能力を与える。RFC 9807 によれば、AKE 秘密鍵は HSM から取り出す必要がなく、共有秘密の計算だけを許せる。シードとエンベロープが漏れた場合でも、AKE 能力の分離はサーバー偽装を防ぎ得る。だが OPRF 材料とレコードによる辞書攻撃までは止めない。

管理図は、誰が何人分の OPRF を評価できるか、誰が AKE 演算を呼べるか、誰がレコードと実在識別子を結び付けられるかを別々に答えるべきだ。同じ管理者、同じ復旧担当、同じバックアップに収まる三サービスは一つの障害領域である。

しきい値 OPRF は最初の境界を変える。十分なシェアを奪うかオンラインで攻撃を続けることを強制でき、OPRF サーバーと認証サーバーを分離すれば、全シェアだけではレコードなしにオフライン攻撃できない。原論文はクライアント透過のしきい値構成を認める。ただし RFC 9807 の範囲外であり、独立した保管者、クォーラム障害、復旧時の再集中は別に実証しなければならない。

HKDF、RFC 9380 の hash-to-curve、RFC 8125 の PAKE 要件は必要な部品だが、実装全体の乱数、定時間性、秘密保管、事故対応を保証する証明書ではない。

再登録されて初めて移行が終わる

暗号方式の更新は、サーバーだけ見れば通常のリリースに見える。RFC 9807 は、KSF やアルゴリズム、サーバー公開鍵など RegistrationRecord に結び付いた材料を変えると、利用者が再登録して新しいレコードを作る必要があるとする。パスワード変更も新しい乱数を使う新規登録である。

つまり移行は利用者状態の更新であり、バイナリ配布ではない。休眠アカウント、古いクライアント、復旧不能者、旧 export_key に依存するデータは自動では移らない。規模が大きくなるほど、既存構成は利用者の再参加なしに離脱できない拘束になる。

現実の層を分けて記録する必要がある。新ソフトが稼働したこと、全レコードが更新されたこと、旧秘密が無効になったことは三つの事実だ。最後の旧レコードと互換経路が消えるまで、旧侵害領域は残る。

必要なのはコホート台帳である。対象数、新レコード数、なお受理される旧レコード、休眠利用者、復旧失敗、新 KSF を処理できない端末、旧 export key 依存、フォールバック利用、旧 OPRF・AKE・レコード資産が本当に使えなくなった日を記録する。

OPAQUE は「パスワードをサーバーに渡さず、再利用可能な事前計算を防げるか」という明確な問いに強い答えを出した。経営判断の失敗は、その答えをシステム全体の安全証明へ膨らませることにある。

パスワードはサーバーの視界から消えた。権限は導出根、保存レコード、秘密演算、偽応答、端末予算、移行状態へ移った。それらを可視化し、分離し、退役まで検証して初めて、暗号上の改善が運用上の縮小になる。

Sources