要約

  • 現行のKey Transparencyアーキテクチャ草案は、一人の利用者に届く要求と証明がすべて正しくても、他の利用者には別のビューが提示され得ると説明する。整合性は各端末を一つの分岐に固定するが、別の分岐の存在までは知らせない。
  • 検出には、非共謀の監査者や管理者、匿名経路での照合、またはピア間のゴシップという独立した比較が要る。選択ごとに、信頼、プライバシー、保存状態、運用負担の置き場所が変わる。

ローカルに正しいことと全体で同じこと

冒頭は実際の侵害報告ではなく、境界を確かめるための運用想定である。「この応答は自分が以前見た状態を正しく延長している」と、「全利用者が同じ状態を見ている」は別の命題だ。前者は一台で計算できる。後者には外側の観測点が必要になる。

draft-ietf-keytrans-architecture-09 はこの差を明記する。IETF DatatrackerではActive Internet-Draftであり、09版は2026年6月29日、記録の最終更新は7月9日である。ワーキンググループの状態はSubmitted to IESG for Publication、IESGはPublication Requested、想定区分はInformational、telechatの日付はない。承認済みRFCでも確定文章でもない。

エンドツーエンド暗号化には、鍵配送という別の支配面が残る。本文が暗号化されていても、表示される利用者名と公開鍵を結ぶディレクトリをサービス運営者が単独で操作できれば、運営者が持つ鍵へ差し替える余地がある。暗号化通信という外形を保ったまま、相手の認証だけを変えられる。

Key Transparencyは、その対応関係を暗号学的に保護された追記型ログへ置く。Searchはラベルの値と証明を返し、Updateは新しい版を加え、Monitorは過去の値が残っていることや所有ラベルに未知の変更がないことを継続確認する。共通層が担うのは観測可能な履歴であり、アプリケーション全体の権限判断ではない。

不正なログは利用者ごとに別の履歴を見せられる。端末は次の応答が保存済みのツリーヘッドと整合することを求めるため、一度与えられた線形な分岐に残り、それと矛盾する将来の応答を拒む。分岐が後から自然に消されにくい点は強みである。しかし、相手側のツリーヘッドと照合しない限り、どちらの端末にも異常は現れない。

証明の検算とビューの比較は別工程である

草案は比較経路を三つに整理する。信頼する第三者、ログへの匿名通信、ピアツーピア通信である。いずれも、隔離された認証経路の外から別の見え方を持ち込む。

第三者監査では、外部監査者がログの追記成長を確認し、新しいツリーヘッドに署名する。その署名が照会応答とともに利用者へ届く。ただし、監査者とログが共謀しないことが前提だ。監査は通常非同期なので、署名は最新状態から遅れ得る。許容遅延は暗号方式が自動決定するものではなく、設定責任者が引き受ける時間的リスクである。

第三者管理では、管理者がログの保管と運用の多くを担い、サービス運営者はアクセス制御と新しいラベル版の認証を続ける。非共謀に加えて、運営者自身が管理者の分岐を見つける仕組みを持たなければならない。複数第三者による閾値署名は一者への依存を減らすが、参加者の選定、鍵更新、離脱時の扱いは依然として制度上の判断だ。

Contact Monitoringでは常設第三者を置かず、ラベル所有者と閲覧者で監視を分ける。所有者は最新値を定期確認し、作成直後の値を見た相手は後日、それが所有者の確認前に消されていないかを確かめる。分岐検出のため、匿名照合またはピア間比較も定期的に行う必要がある。負担は消えず、端末の稼働と人同士の接続へ移る。

匿名照合では、要求者を識別できない経路からツリーヘッドを得て、認証済み経路のものと比べる。複数の分岐を維持するログは、誰の分岐を返すべきか判断しにくい。繰り返せば露見の確率は上がるが、匿名性が実効的で、経路が選択的に妨害されないことが必要だ。

ピア間ゴシップは小さなデータ交換で足り、帯域の狭い帯域外経路やQRコードでも成立する。難所は利用者グラフの連結性である。交わらない共同体には異なる分岐を出し続けられる。相互運用可能な形式を定めても、証人同士が実際に会うとは限らない。

状態喪失は過去との比較点を失わせる

端末が将来の応答へ連続性を要求できるのは、以前のチェックポイントを持つからだ。その記憶を失うと、新しい履歴が古い履歴と衝突することを示せない場合がある。草案が状態喪失を独立した安全上の論点として扱う理由である。

Contact Monitoringでは監視期間内の新しい値や、まだ十分にゴシップされていない範囲が特に影響を受ける。第三者監査では監査者の許容遅延内が弱点になり得る。短命なウェブ状態、機種変更、不完全なバックアップ、攻撃者が誘導した初期化は、証明アルゴリズムを変えずに保証を弱める。

アカウント回復で何を復元するかを決める必要がある。最後のツリーヘッド、未完了のMonitor義務、外部署名、比較時刻、ログ設定の識別情報である。連続性を証明できないなら、その不確実性を隠さず、回復時のローカル方針へ渡すべきだ。

検出までの時間も複数の設定に依存する。応答の最大鮮度、Reasonable Monitoring Window、実際のバックグラウンド監視頻度、匿名照合またはゴシップの間隔、監査遅延、管理者分岐を探す運用の有効性である。利用者が一定時間オンラインでなければ見つからないケースもある。「有限時間で検出」は、各時間に測定と責任者がある場合だけ運用上の意味を持つ。

監視指標は証明成功率だけでは足りない。端末ごとのチェックポイント年齢、外部証言の年齢、比較失敗、Monitorの滞留、状態回復、古い応答の拒否、矛盾発見からローカル対応までの時間を分けて見るべきだ。全証明が成功する画面こそ、隔離された分岐の表情になり得る。

アプリケーションのアクセス判断は残る

この仕組みは既存の通信方式や大部分のアクセス制御を置き換えない。ログインを求める、検索可能な相手を制限する、頻度を抑える、他人のラベル更新を拒む、といった規則はアプリケーションが持つ。透明性は許可済み操作の証拠を出すが、許可そのものは決めない。

Contact Monitoringには時間をまたぐ例外がある。昨日はラベルを検索でき、今日は権限を失った利用者でも、昨日見た値の監視を完了するため後からMonitorを実行する必要がある。草案はこの要求を許すよう求める。権限取消しを一律に全経路へ適用すると、隠蔽を発見する経路まで閉じてしまう。

プライバシー負担も方式ごとに異なる。監査者は変更の件数、順番、おおよその時刻を知るが、平文のラベルや値は見ない。管理者は一般に、運営者が知る平文、履歴、照会パターンを知る。匿名経路はメタデータ保護が必要で、ピア交換は接触関係を示すことがある。情報を全く受け取らない証人はいない。

したがって、第三者を導入するだけでは設計は終わらない。観測範囲、保存期間、相関可能性、署名対象、公開鍵の配布、遅延時の扱い、交代手順まで記録する必要がある。

移行時に古い証拠を捨てない

ログ障害からの回復では新ログへの移行が重要になるため、クライアントは複数ログに対応することが望ましい。段階移行では、長くオフラインだった利用者も監視を完了できるまで旧ログを稼働させる。早期停止すると、旧ログの不正を後から見つけられない利用者が生まれる。

即時移行では、旧ログの最終サイズとルートハッシュを信頼できる方法で全員へ渡す。連合型サービスでは、どの主体のログがある利用者を担当するかを一貫して決めなければならない。入口で権威が分かれれば、ログ証明以前にビューが分かれる。

剪定も二種類のデータを分けて考える。期限切れまたは恒久的に参照不能な利用者データを削除できても、残る状態の証明に必要な暗号学的データは保持が必要な場合がある。削除要求と証拠連続性は協調させるが、同一視しない。

分岐の証拠は処置そのものではない

相反する二つのビューを比較できれば、ログの不正を否認しにくい形で保存できる。その後、警告、鍵変更の凍結、送信停止、帯域外本人確認、端末隔離、調査中の限定運用のどれを選ぶかはアプリケーション側の判断である。

誤検出、なりすまし見逃し、サービス停止の損失は環境ごとに違う。共通機構は矛盾を観測・移送可能にするところまでを担い、最終処置は状況を知り結果を負う当事者に残す。決定は記録され、後から検証・撤回できる必要がある。

よい導入試験は、デモで証明が通るかだけを見ない。独立比較が日常的に動くか、回復後も状態が続くか、移行時に旧証拠へ到達できるか、誰が通信を止める権限を持つかを確かめる。証人が出会えるとき、初めてログは透明になる。

情報源