要約

  • MLS の各グループメンバーは、そのエポックにおける送信チェーンの共通フレーミング用 AEAD 鍵を計算できる。復号成功が示すのはグループ能力の保有であり、一つのクライアントではない。
  • クライアント署名はより強い送信元証拠になる。しかし本人との結び付け、業務権限、配送、現実の結果には、それぞれ独立した記録が要る。
  • 新しいエポックは重要な暗号状態だが、復旧完了証明ではない。侵害された秘密の種類と、排除・失効・同期・結果の確認を明記すべきだ。

ある端末が侵害された疑いを受け、調査チームがログを開く。問題のメッセージは AEAD 検証を通過している。ここで「暗号的に正しい」から「この端末が送信した」へ飛ぶと、調査は最初の画面で誤った容疑者を作る。さらに「その利用者が承認した」「全員に届いた」まで進めば、一つの検査が組織の判断全体を代行してしまう。

RFC 9750 は Messaging Layer Security のアーキテクチャを説明し、この飛躍を明確に止める。MLS のメンバーはグループ秘密を持ち、そのエポックの各送信チェーンに用いる AEAD 鍵を計算できる。したがって共通フレーミングの認証は、限定された意味で弱い。暗号文を正しく開けても、分かるのは「いずれかのメンバー、または侵害された AEAD 鍵を持つ攻撃者が作成した」という範囲までである。

これは AEAD の失敗ではない。共有された能力から得られる証拠が、能力の共有範囲と同じ大きさになるだけだ。特定のクライアント名を表示するには、別の観測が必要になる。

署名は別の能力を検査する

RFC 9420 では、各メッセージに送信者のデジタル署名が付く。メンバー送信者の場合、指定されたリーフインデックスの LeafNode にある署名鍵で検証する。署名対象には内容、ワイヤ形式、現在の GroupContext が含まれ、特定エポックの特定署名能力へメッセージを結び付ける。

侵害時には二つの検査の差が決定的になる。AEAD 用のグループ材料だけを得た攻撃者は、受理可能な暗号文を作れる場合がある。それでも有効なクライアントの署名能力がなければ、そのクライアントから来たようには見せられない。反対に、署名秘密鍵を取得したり、鍵を取り出さずに署名を依頼できるオラクルへ到達したりすれば、送信元証拠そのものが損なわれる。

ログは「AEAD オープン」「エポックと世代の受理」「リプレイ検査」「リーフインデックス」「署名検証」を分離して残すべきである。すべてを一つの「認証済み」へ潰すと、どの能力が悪用されたかを後から判定できない。

RFC 9750 が署名秘密鍵の保護を優先し、HSM やセキュアエンクレーブに言及する理由もここにある。頻繁に変化するグループ秘密は、必ずしも同じ方法で保護できない。両方を「鍵」という一語で統一管理するより、寿命、呼び出し方法、侵害時の影響を区別した方が現実的である。

クライアントの署名は人の意思ではない

MLS の基本単位は人ではなくクライアントである。一人が複数端末を持てば、それぞれに署名鍵がある。Authentication Service はクレデンシャルを発行し、参照識別子と署名鍵の結び付きを検証し、二つのクレデンシャルが同じクライアントを示すか判断する。この判断は署名処理の外側にある。

有効な署名と有効なクレデンシャルを組み合わせれば、そのサービスの規則上はクライアントを識別できる。しかし、人が自ら操作したこと、現在も特定の職務にあること、業務上その操作を許されたことまでは証明しない。自動化、委任、共有端末、失効同期の遅延があっても、署名は技術的に正しい場合がある。

操作権限を決めるのはアプリケーションである。RFC 9750 は、MLS 自体がグループ操作のアクセス制御を強制しないと明記する。誰がメンバーを追加・削除できるか、誰が重要な内容を承認できるかは、アプリのポリシーが定義する。Proposal は変更案を示し、Commit は状態を変える。どちらも、適切な職責者の承認記録を自動的には作らない。

画面上の言葉も制御の一部だ。「クライアント署名を検証」「参照識別子との対応を確認」「ポリシーが操作を許可」は三つの出来事である。一個の信頼バッジにまとめると、暗号検査が本人性と組織権限まで借りてしまう。

配送サービスは復号の外にある

Delivery Service は MLS メッセージを転送し、初期鍵材料を配る。強い順序性を提供する構成もあれば、結果整合性に依存する構成もある。障害や侵害によって、メッセージが抑止されたり、異なるクライアントへ異なる履歴が示されたり、現在のエポックについて分岐が生じたりし得る。MLS は配送サービスが内容を読み、正当なクライアント署名を偽造することを防ごうとするが、可用性や同期まで自動的に保証しない。

一台が暗号文を受理しても、全対象端末が取得した、同じエポックで処理した、画面に表示した、利用者が行動した、とは言えない。配送を主張するなら、サービス受理、配信、端末別取得、暗号処理、状態収束、表示、そして必要なら現実の結果について個別の記録が要る。

新規クライアントへの Welcome 送信も同じだ。送った事実だけでは、受信や復号を示さない。新しいクライアントが参加し、他メンバーが検証できる形でグループ秘密へ寄与するまで、運用上の参加完了を仮定できない。招待、受信、参加、収束は別の状態である。

復旧では秘密の種類を名指しする

「鍵をローテーションした」という報告では足りない。ラチェット秘密の侵害は、適切に削除された過去鍵を守りながら、当該エポックの送信チェーンにおける現在・将来の AEAD 鍵を露出させることがある。より広いグループ秘密の侵害は、複数の侵害エポックで暗号化と復号に影響する。署名能力の侵害は帰属を変え、別のクレデンシャル対応を必要とする。

受動的な侵害なら、修復後の誠実な Commit が、規定されたポストコンプロマイズ条件の下で新しいエポック秘密へ進める。攻撃者が能動的にプロトコルへ残る場合は厳しい。残りのメンバーが誠実であるとき、侵害された当事者を除去することが後続エポックの秘密性を回復させる操作になる。

それでもエポック遷移はインシデント完了票ではない。問題のクライアントを除去または更新したこと、必要なクレデンシャルを失効したこと、代替端末を正しく登録したこと、権限を復元したこと、受信側が収束したことを別途確認する必要がある。「対象クライアント除去後に新エポックへ進み、列挙した端末が収束した」という狭い記述の方が、「安全になった」より検証可能である。

証拠を八段に分ける

実務では次の問いを独立に残す。暗号文を解析して AEAD を開けたか。エポック、世代、リプレイ状態を受理したか。指定メンバーまたは許可された外部送信者の署名を検証したか。クレデンシャルは期待する参照識別子に一致したか。そのクライアントは現在のメンバーか。アプリの規則は当該操作を許したか。配送サービスと各端末は必要な配送・処理記録を出したか。人または事業の結果を独立に観測したか。

ある段の成立は次の段の前提になり得るが、次の段の代わりにはならない。段を飛ばすことは暗号上の近道ではなく、分析者が追加した主張である。その主張で処分や承認や復旧完了を決めるなら、専用の根拠が必要だ。

RFC 9750 は Informational、RFC 9420 は Standards Track の文書である。特定製品への採用や、実際の侵害・性能を示す資料ではない。価値は、主張を生成した仕組みの範囲に戻す点にある。この原則を守れば、フォレンジックは容疑を作らずに絞り込み、運用は正しい復旧操作を選び、経営は検証可能な言葉だけで判断できる。

出典