要約

  • RFC 5275では、閉鎖型または管理型リストからメンバーを削除した後も、再鍵化しなければ元メンバーは共有鍵を保持し、入手できるメッセージを復号できる。
  • 終了を証明するには、削除受付ではなく、新しい名簿世代、鍵の影響範囲、継続メンバーへの配布、切替、旧鍵の停止、残存データの露出を分けて確認しなければならない。

引き継ぎの都合で、来月使う鍵まで今月配っておく。運用としては合理的だ。ところが今日、一人のメンバーを外す必要が生じた。名簿を更新しても、その人物の端末には今月の鍵だけでなく来月の鍵も残っている。この瞬間、継続性のための在庫は、撤回できない将来権限へと性格を変える。

RFC 5275はCMSを使う対称鍵管理・配布の標準である。文書が想定するメールリストやメッセージ配布の実装は2008年のものだが、権限の分解は現在にも通用する。閉鎖型または管理型のグループリストからメンバーを外したなら、リストを再鍵化しなければならない。そうしない限り、元メンバーはグループ鍵を持ち続け、手に入れた暗号文を復号できる。

名簿の所有者と鍵の代理人

グループリスト所有者（GLO）はリストを作り、非管理型・管理型・閉鎖型のどれにするかを定める。メンバー変更や再鍵化方針にも関与する。グループリスト代理人（GLA）は、グループ管理と鍵管理の機能を担い、共有KEKを運ぶ glKey に署名する。

この役割分担は、代理人を真実の源にするものではない。RFCは、GLAが破られれば常に混乱を起こし得ると認めている。権限は「誰が実行してよいか」を定める。実行証拠は「何が実際に変わったか」を別に示さなければならない。

glDeleteMember は署名付きの削除要求である。リストの運用形態に応じて、所有者から送られることも、本人の退会要求として送られることもある。しかし、要求の正当性と削除後の能力停止は同一ではない。管理型・閉鎖型では、同じ主体が別名義で二重登録されていないかも確認する必要がある。一方だけ消して他方が残れば、鍵の配布は続く。

完了は一つの時刻ではない

削除の後には、新しいメンバー集合に対する glRekey が続く。glKey にはグループ名、鍵識別子、ラップされたKEK、アルゴリズム、利用開始・終了時刻が入る。相互にメンバーを知らせない設定では、GLAは受信者ごとに別々の鍵メッセージを送る。

ここから、少なくとも次の状態が分かれる。

  1. 正当な削除要求を受理した。
  2. 対象者の重複IDを含まない新しい名簿世代が有効になった。
  3. その世代向けの新鍵を生成した。
  4. 残る各メンバーへ正しい鍵を届け、失敗を記録した。
  5. 送信側が旧鍵の使用を止め、受信側が新鍵を使い始めた。
  6. 現在鍵と先行配布鍵を、管理可能な範囲で停止した。

配布通知は受領確認ではない。受領は利用開始でもない。GLAの署名付き成功応答も、代理人の処理結果を示すのであって、全端末の切替や全コピーの消去を証明しない。RFC 5275は遠隔の安全消去を保証する規格ではない。

世代数と有効期間が作る長い影

generationCounter は配布または未消化のまま維持する鍵の数を、duration は各鍵の有効期間を表す。停止時間を避けるため、最初は最低二つのKEKを同時に渡す。次の鍵を事前に持つことで、現行鍵が期限を迎えても通信を続けられる。

だがRFCは、十四個の鍵を一年ずつ有効にする例を挙げ、最後の鍵には少なくとも十三年の攻撃期間が生じると警告する。世代数と期間を掛け合わせた遠い未来まで、秘密が現在の端末に置かれるからだ。

退会処理で問うべき範囲は、現行鍵だけではない。対象者が取得済みの将来鍵をすべて洗い出し、必要なら glRekeyAllGLKeys によって未失効鍵を再発行する。継続性の在庫は、そのまま撤回対象の在庫でもある。

さらにKEKが別のKEKをラップし、その鍵が次をラップする連鎖もある。RFC 5275は、連鎖中の一つが漏えいしたなら、それ以後のすべてを漏えい扱いにするよう求める。事故調査は最初の鍵番号で止められない。依存関係の先まで閉じる必要がある。

新鮮さは記憶から生まれる

KEKを保管するメンバーは、それを配ったGLAの名前も結び付けて保存し、後の再鍵化が同一の主体から来たか確かめなければならない。署名が正しいだけでは、正しいグループの正しい履歴につながるメッセージかは分からない。

nonceと signingTime によるリプレイ対策も、過去の交換状態を保管して比較できる場合にだけ効く。時計にはずれがあり、許容範囲はローカル方針で決まる。未来を示す署名時刻も処理対象である。状態を持たないタイムスタンプは、鮮度の根拠ではなく、ただの記載項目にすぎない。

新しい鍵は古い暗号文を回収しない

切替後に旧鍵を使わなければ、将来の通信は元メンバーから隔離できる。しかし、すでにメールボックス、リポジトリ、バックアップへ複製された暗号文は消えない。持ち出された鍵や平文も自動では戻らない。

残存露出は、元メンバーが手にできる暗号文と、まだ使える鍵の交差で決まる。前向きの封じ込めと過去の回復を分けることで、実現できる保護を過小評価せず、実現できない消去を約束せずに済む。

退会の証拠を一本の鎖にする

RFC 5275自体は、現代的な透明性ログ、端末アテステーション、普遍的な消去証明を定めていない。だが、同規格が分けた状態から、必要な受領証の形は導ける。

署名付き要求を対象リストと本人へ結び付ける。発効した名簿世代を記録する。現在・将来・ラップ連鎖上の対象鍵を列挙する。継続メンバーごとの配布結果を残す。送受信双方の切替境界を示す。計測できる旧鍵停止を記録し、端末外のコピーや取得済み暗号文を未解決として開示する。

これは管理を厚くするためではない。動いているシステムが必要とする最小限の真実、すなわち「この境界以後、新しいメンバー集合だけが新しい能力を使える」を証明するためである。