Summary

  • draft-ietf-cose-hpke-27は9月12日に公開され、現在も担当エリアディレクターのフォローアップ中にある。Standards Trackを目指すInternet-Draftであり、RFCでも承認済み実装プロファイルでもない。
  • 保護されたpsk_idがあればPSKモード、なければBaseモードになる。Baseモードは指定受信者への暗号化を提供するが、HPKEのKEMでは送信者を認証しない。
  • kidは受信者鍵を選ぶための値で、送信者の身元ではない。Daniel KadeはPSKや平文を残さず、実際に使われた認証・認可経路を記録する受領票を提案する。これはIETF要件ではなく編集上の提案である。

正常終了という一語では足りない

第27版は9月12日に公開された。Datatrackerの履歴によれば、文書はIESGへの出版申請後、AD Evaluation::AD Followupにある。今回の改訂は乱数に関する文言を強め、HPKE自体に暗号学的に安全な乱数源を求めるとともに、Key Encryptionで用いるコンテンツ暗号鍵にも同じ要件を課した。

もっとも、これはRFC成立の知らせではない。現在の記録は今後も変わり得る。IANAの値はまだ仮置きで、最終テキストも確定していない。現時点で読み取るべきなのは、暗号処理の成功と送信者の権限を一つの状態にまとめてはいけないという境界だ。

Baseモードでは、受信者の公開鍵を知る者なら、その秘密鍵の保持者が開けるオブジェクトを作れる。AEADは、導出鍵の下で暗号文と関連データが改変されていないことを検査する。しかし、そのオブジェクトを作った主体を組織上の人物やサービスに結び付けるわけではない。

暗号化の形と認証の選択は別々である

COSE HPKE草案は二つの配置を定める。Integrated EncryptionはCOSE_Encrypt0の中で平文をHPKEに直接渡し、受信者は一人である。Key Encryptionはコンテンツ暗号鍵で本文を保護し、その鍵を受信者レイヤーのHPKEで包む。こちらは複数受信者に対応できる。

COSEのアルゴリズム識別子は、KEM、KDF、AEADの完全な組み合わせと、どちらの配置で使うかを固定する。実装が勝手に部品を交換したり、Integrated用の識別子をKey Encryptionに流用したりする余地を狭める設計である。

一方、送信者認証モードはその識別子に含まれない。保護ヘッダーにpsk_idがあればmode_psk、なければmode_baseになる。同じアルゴリズム番号でも、認証についての意味が異なるオブジェクトが成立する。

PSKモードの成功は、送信側が外部の共有秘密を持っていたことを示す。Baseモードはその主張をしない。監査ログがアルゴリズム番号だけを残せば、どちらの信頼経路が選ばれたかを後から復元できない。

kidが示すのは宛先である

草案は、送信者が選んだ受信者の静的公開鍵を明示するためにkidを推奨する。受信側はこれを手掛かりに対応する秘密鍵を選べる。鍵ローテーション中には特に有用だが、これは送信者IDではない。

公開鍵の配布は仕様の範囲外とされる。従ってアプリケーションは、鍵をどのディレクトリーから取得したか、どのテナントに属するか、いつ失効したかを管理しなければならない。誤った組織境界から取得した正しい公開鍵でも、HPKEの計算自体は正常に終わる。

psk_idも秘密鍵そのものではない。識別子は保護されるが、PSKは外部入力でありCOSEオブジェクトに格納してはならない。PSKの保持を確認できても、それが特定個人を表すか、担当者の退任後も有効か、どの操作を許すかは別の問題である。現行HPKE草案は十分なエントロピーを要求し、低エントロピーのパスワードをPSKとして扱うことも戒めている。

結び付けた文脈にも運用上の意味付けが要る

COSEでは保護ヘッダーと外部追加認証データを暗号処理に組み込める。Key EncryptionのRecipient_structureは、直下レイヤーのアルゴリズム、受信者の保護ヘッダー、追加情報を決定的に符号化し、レイヤー間のアルゴリズム置換を防ぐ。

ただし、仕組みが守るのは入力された文脈だけだ。テナント、処理目的、期限、ポリシー版、要求番号のどれを必須とするかは利用プロファイルが決める。外部AADが空でも構文上は扱える場合があり、そのことは認可に十分な文脈があることを意味しない。

HPKEは低水準の部品として設計されている。コンテキスト内の順序以外のリプレイ対策、ダウングレード防止、メッセージ損失、鮮度判定は埋め込み側の責任になる。単発オブジェクトを二度受け取ったとき、二度目も暗号検査に通り得る。同じ指示を再実行しないためにはアプリケーション状態が必要だ。

分離暗号文にも注意が要る。後段でCOSE署名やMACを付けても、分離された暗号文バイト列が自動的に覆われるわけではない。草案は別途整合性を確保するよう求める。「署名検証成功」という記録だけでは、署名対象を示さない限り証拠にならない。

Baseモードを避けることが結論ではない

匿名の送信者から機密情報を受け付けたい場面はある。公開提出窓口や通報受け付け、別レイヤーで認証するシステムではBaseモードが合理的だ。草案も追加認証の手段としてCOSE_Sign、COSE_Sign1、COSE_Mac、COSE_Mac0を挙げる。

問題はBaseを使うことではなく、Baseの成功を送信者認証と呼ぶことだ。PSKに切り替えても認可は自動化されない。一つの共有鍵が端末群や複数担当者を表すなら、保持の証明から個々の権限を導くことはできない。

暗号結果が操作に変わる場所で統治が始まる。ゲートウェイが設定を適用し、端末が指示を実行し、サービスが報告を受理する。その都度、「何を保護したか」「誰のどの資格を検証したか」「どの規則が行為を許したか」を別々に確認する必要がある。

受理の根拠を小さな受領票に残す

Daniel Kadeは、受理したCOSE HPKEオブジェクトごとに送信者認証受領票を作ることを提案する。草案または運用プロファイルの版、IntegratedかKey Encryptionか、暗号スイート、実効HPKEモード、受信者鍵のフィンガープリントと配布元を記録する。PSKモードならpsk_idの一方向指紋、秘密ではない鍵版、ライフサイクル状態を加える。Baseモードなら、別途検証した署名、MAC、認証済みチャネル、アプリケーションIDを示すか、匿名提出を許すことを明記する。

さらに、保護文脈のプロファイル、鮮度・リプレイ判定、分離暗号文の整合性、認可ポリシー版、最終判断を結び付ける。PSKや平文、不要な個人情報は保存しない。不透明なイベントIDとダイジェストで、秘密を増やさず検証可能性を残せる。

この受領票は草案、RFC 9052、RFC 8937、IANA COSE登録簿の要求ではない。Heng LuのPolicy Mirrorが示すように、機構の成功と権威の成立を分けるための運用証拠である。最小初期仕様に沿って共有部分は小さく保ち、BTWの現実重視の原則に従って、改訂を事故や実装不良の証拠には仕立てない。

Sources

  1. COSE HPKE第27版
  2. COSE HPKE第26版
  3. Datatracker現行記録
  4. Datatracker文書履歴
  5. HPKE第04版
  6. RFC 9052 — COSEの構造と処理
  7. RFC 8937 — セキュリティプロトコルの乱数改善
  8. IANA COSE登録簿
  9. Heng Lu — The Policy Mirror
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — Why BTW Media Exists