要約

  • RFC 9180 の Base モードは、指定された受信者 KEM 秘密鍵の保持者に向けた暗号化を可能にする。Open() の成功は、その文脈での検証結果であって、送信主体の身元や委任の証明ではない。
  • PSK、Auth、AuthPSK は設定済みの秘密または送信者 KEM 秘密鍵の保持について限定的な保証を追加する。組織上の本人性、メッセージの意味、失効、再送防止、業務承認までを完成させるものではない。
  • 運用の記録は、鍵の選定からモード、文脈、外側の形式、解析、鮮度、方針、実行結果までを分離する必要がある。復号成功を最後の承認にしてはならない。

障害対応で最も危険なログ行は、しばしば短い。「HPKE decrypt: success」。それは暗号ライブラリにとって有用な事実である。だが、それを受けて経営者や運用者が「正規の送信者からの指示だった」と読むなら、ログは途中の事実を最終結論に見せている。

RFC 9180 は Hybrid Public Key Encryption を、KEM、KDF、AEAD を組み合わせる方式として定める。送信者と受信者が共有する暗号文脈を作り、その文脈で内容を封印・復号するための共通部品である。これは強い最小仕様だが、完全なメッセージ・プロトコルではない。送信者の名称、受信者公開鍵の配布、外側のレコード形式、要求の意味、承認の規則、実行後の回復を RFC は中央で決めない。

この節度を弱点と読んではならない。暗号の共通層が、実装ごとに異なる人事、契約、役割、期限、商取引上の不可逆性まで決め始めれば、相互運用の根拠も責任の所在地も曖昧になる。危険なのは、ローカルで決めるべきことを決めないまま、暗号化の成功に預けることだ。

Base モードが確認する範囲

HPKE の ciphersuite は、一つの KEM、一つの KDF、一つの AEAD の組である。KEM は受信者公開鍵に対するカプセル化と受信者秘密鍵による復元を扱う。KDF は共有秘密と文脈を鍵素材へ導く。AEAD は平文と追加認証データを保護する。それぞれが限定された仕事を担う。

Base の送信側は pkR とアプリケーション指定の info でセットアップする。受信側は enc、対応する skR、同じ info で文脈を復元する。ここで得られるのは、選ばれた受信者鍵に向けて暗号化された内容を、その秘密鍵の保持者が処理できるという性質である。

そこには送信者の秘密鍵も PSK も入らない。受信者の公開鍵を知る者は、Base 用の暗号文を作れる。RFC 9180 の性質表が Base に送信者認証を与えないのはこのためである。公開鍵が公開されていることは異常ではない。むしろそれが、公開鍵に向けて暗号化する仕組みの出発点である。

たとえば一つの受信鍵を複数の内部サービスに知らせる場合を考える。診断を送ってよいサービスと、本番変更を要求してよいサービスが同じ鍵を見ているかもしれない。Base の復号は、その差を判別しない。どの送信元が、どの種類のメッセージを、どの範囲で送れるかは、鍵の外側で管理しなければならない。

AAD にも同じ限界がある。テナント、バージョン、要求番号を AAD として結び、改変すれば失敗するようにできる。しかし HPKE はそのテナント名が真実か、送信側が名乗る資格を持つかを判定しない。完全性が保護された主張と、主張する権限は別の資産である。

Auth は組織名を自動で生まない

PSK モードでは、受信者は設定された pre-shared key の保持を確認できる。Auth モードでは、送信者 KEM 秘密鍵の保持に結び付いた保証が得られる。AuthPSK は両方を使う。これらは Base より強い出発点になり得る。

ただしプロトコルが示すのは、秘密材料を持っていたということに限られる。企業がその鍵を個人、サービス、ハードウェア、共有職務、委託先などのどれに結び付けるかは別の台帳の仕事である。発行、保管、交替、失効、職務変更、例外承認がそこで初めて意味を持つ。

RFC 9180 は Auth/AuthPSK が認証するのは送信者の鍵対であり、ドメイン名やメールアドレスなど別の識別子を束縛したいなら info に含めるべきだとする。これは小さな API の注意書きではない。名前と鍵を結ぶ操作には、誰が値を選び、誰が検証し、どの期間有効とするかという所有者が必要だという設計原則である。

さらに、RFC が定める DHKEM の Auth/AuthPSK には、受信者鍵が侵害された場合に関する key-compromise impersonation の制約がある。したがって Auth の成功を、永久の本人証明や万能の非否認性として保存してはならない。時点、鍵状態、脅威モデルの下での限定的な鍵保持保証として記録する。

監査用語がこの線を消しやすい。sender_authenticated はプロトコル上の状態として正しいかもしれない。しかし「取引先が承認した」という結論には、鍵と取引先の有効な対応、メッセージ範囲の委任、当該内容を許可するアプリケーション方針が要る。三つを一つの boolean に畳むと、事故時に誰も承認者を示せなくなる。

HPKE の外に残る封筒と時間

info はセットアップ時の補助認証情報であり、AAD は個々の Seal() と Open() のための情報である。複数操作に共通の文脈と、メッセージごとに変わる文脈を分けられる点は有用である。

しかし RFC 9180 は HPKE メッセージの wire format を定めない。アプリケーションは enc、暗号文、複数ならその順序、暗黙でない info を含む曖昧でない形式を自分で定義しなければならない。受信者が複数の公開鍵を持つなら、どの鍵を選んだかも外側の形式で必要になる場合がある。

ここで、パーサと復号器の責任を混ぜてはならない。外側の形式が曖昧なら、復号が成功しても、どの構成要素が一つの要求を構成するか不明なままである。形式が正しくても、明文が設定変更なのか診断なのか、誰のロールに属するか、今も有効かは暗号文から決まらない。schema、型、発行元、失効、鮮度、方針、制限実行器が別々に拒否できる必要がある。

時間も外側にある。RFC 9180 は同一文脈内で送信順に Open() されるときだけ、限定的な replay protection を与える。それ以外の再送防止は提供しない。複数メッセージを扱うアプリケーションは順序を強制し、喪失を検出し、しばしば sequence や不変の識別子を AAD に結び付ける必要がある。

昨日正しかった同意が、今日の業務状態で正しいとは限らない。暗号文が正確に復号できても、失効済みの鍵、期限切れの要求、すでに使われた nonce、異なるテナントなら拒否されるべきである。暗号化されたバイト列に鮮度や業務上の正当性を継承させないことが重要だ。

受信者鍵の妥協には遡及的な側面もある。RFC 9180 は、受信者の長期秘密が後で侵害されれば、過去にその鍵へ暗号化された暗号文を解けるため、受信者妥協に対する forward secrecy はないと述べる。これは特定の侵害を意味しない。鍵更新、アーカイブ、保持期間、影響調査を別に所有すべきという設計事実である。

実行可能な証拠をつなぐ

鍵の入口では、受信鍵の識別子、所有者、許容用途、配布元、発行日、交替日、失効日を記録する。公開鍵の存在は暗号化先の存在であって、すべての送信者にすべての要求を許す証明ではない。

送信準備では、モード、suite、PSK または送信者鍵の由来、info、AAD、封筒、アルゴリズム選択の証拠を残す。受信時には enc と暗号文の安全な参照、選択鍵、文脈構築、Open() の結果を残す。ここで成功を成功として保存し、認可の成功へ書き換えない。

解釈時には、schema version、メッセージ型、認識した身元、鍵失効状態、順序・再送判定、鮮度、方針決定、拒否理由を残す。最後に、要求された操作、許可された操作、実行された操作、独立に観測された結果、rollback を分ける。一つの暗号学的イベントが全行を代理してはならない。