暗号化グループから誰かを削除すると、その人は将来の保護されたメッセージに必要な秘密情報を受け取れなくなるべきです。残った送信者が元メンバーの知る鍵素材を使い続けるなら、メンバー一覧を変えるだけでは実現しません。
また、不安定なネットワーク全体で移行が瞬時に完了するわけでもありません。安全なグループ設計では、メッセージがどのメンバー状態に属するか、削除をまだ処理していない送信者がどう動作するかを定義する必要があります。
過去と将来のメッセージは別の問題
元メンバーは、権限を持っていた間に受信したメッセージ、ファイル、鍵を保持しているかもしれません。削除しても、その人に履歴を忘れさせたり、スクリーンショットを消したりはできません。
実現可能な目標は、削除が有効になった後の新しい暗号状態からその人を除外することです。同様に、メンバー追加には過去の履歴へのアクセスを与えるかという別の問題があります。製品やプロトコルは前方秘匿性などの用語を異なる文脈で使うため、曖昧なラベルより意図するアクセス規則を平易に説明する方が明確なことがよくあります。
送信者鍵グループに新しい状態が必要な理由
送信者鍵の設計では、各参加者は許可された受信者と共有するチェーンで通常のグループメッセージを暗号化できます。これにより、送信のたびに受信者ごとに内容全体を別々に暗号化することを避けられます。
削除後も元メンバーは古いチェーンを持っている可能性があります。そのため、残った送信者には除外されたメンバーへ配布されない代替状態が必要で、クライアントにはその使用に関して合意されたメンバー構成の文脈が必要です。更新は関連する送信者と端末をすべて対象にしなければならず、サーバー側のフラグを1つ変えるだけでは不十分です。
具体的なプロトコルが重要です。RFC 9420で規定されたMLSは、残ったメンバーへ新たなエントロピーを与える、コミットされたエポック変更で削除を処理します。これは明確に定義された状態遷移の例であり、LivaraがMLSを実装しているという主張ではありません。
LivaraがLGS1について文書化していること
Livaraのセキュリティページは、送信者ごとに署名付き送信者チェーンが1本あり、送信者鍵をペアごとのLVR1セッションで配布すると説明しています。メンバー構成が変わると新しい送信者鍵を作成し配布するとしています。
これは公開された鍵更新設計についての主張を裏付けます。しかし、測定済みの「即時失効」時間を確立するものでも、あらゆる競合、オフライン端末の状況、再試行が正しく処理されることの証明でもありません。それには実装の分析とテストが必要です。
サーバー側のメンバー制御と暗号学的な除外にも異なる役割があります。サービスは配信やアクセスを拒否できますが、暗号化は、除外された相手が後続の暗号文のコピーを持っていても、新しい秘密情報なしでは開けないようにすべきです。
役立つ削除テスト計画
許可されたテスト用グループで、機密性のないメッセージを使い、次の場面を確認します。
| 場面 | 解明すべき問い |
|---|---|
| 全員オンラインの状態でメンバーを削除 | 新しいメンバー状態に属する最初のメッセージはどれか？ |
| 残った送信者がオフライン | 再び送信する前にメンバー情報と鍵を更新する必要があるか？ |
| 削除されたメンバーが後で再接続 | 新しい送信者鍵の配布を取得できるのか、過去に許可された内容だけか？ |
| 複数のメンバーが同時に変わる | 残ったすべての端末が同じ状態に収束するか？ |
| 古いメッセージを再試行 | 新しい内容と誤表示せず、元のエポックを保持するか？ |
UIだけのテストは見える動作を確認できますが、それだけで暗号学的な除外を証明することはできません。厳密な評価では、除外されたテスト端末がどの鍵と暗号文を取得できるかを調べる必要があります。
管理者が覚えておくこと
不要な参加者を削除し、残ったメンバーを確認し、アプリが変更を処理するまで新しい機密資料を送らないようにします。現在の参加者が意図的に内容を転送すれば、グループの鍵更新ではその開示を防げません。
機密性の高い用途では、削除の正確な意味、端末の失効動作、テスト証拠を事業者に求めてください。重要なのは将来のメッセージに対する明確な境界であり、削除ボタンが過去のすべてのコピーを破壊するという根拠のない主張ではありません。
