鍵透明性（Key Transparency）

鍵透明性が解く問題：公開鍵配布の信頼

エンドツーエンド暗号化（E2EE）の安全性は「相手の公開鍵が本当に相手のものか」に完全に依存します。Signal や WhatsApp、iMessage では、メッセージを暗号化する前に相手の公開鍵をサーバー（鍵ディレクトリ）から取得します。ところがこのサーバーが悪意を持つ、あるいは侵害された場合、特定のユーザーにだけ攻撃者の公開鍵を返すことができます。すると攻撃者は中間者としてメッセージを復号でき、E2EE は名ばかりになります。従来の防御は QR コードによる「安全番号（safety number）」の対面照合ですが、実際にこれを行うユーザーはごく一部で、鍵が変わるたびに再照合する運用は現実的ではありません。

鍵透明性（Key Transparency, KT） は、この鍵配布を 検証可能（verifiable） にします。核心は、サーバーが誰にどの公開鍵を配ったかを 追記専用ログ（append-only log）に記録し、その内容を暗号学的に検証可能にすることです。サーバーは嘘をつけますが、嘘は必ずログに刻まれるため、後から誰でも検出できる。この「サーバーを無条件には信じず、その主張を証明で裏取りする」構図は、TLS 証明書に対する X.509 チェーン検証と Certificate Transparency と同じ設計思想の、ユーザー公開鍵版です。

土台：追記専用ログと signed tree head

KT の基盤は、鍵の割り当てを葉に持つ マークル木（Merkle 木） です。木の構造・包含証明・一貫性証明の数理は Merkle 木と認証データ構造 が詳しいので、ここでは KT に必要な三つの証明を整理します。

サーバーは一定間隔（エポック）ごとに木全体の根（root hash）に署名し、これを signed tree head（STH） として公開します。STH はエポック番号・根ハッシュ・タイムスタンプを含み、サーバーの署名鍵で署名されます（署名方式は デジタル署名スキーム を参照）。STH さえ正しければ、木の中身は包含・不在・一貫性の各証明で O(log N) サイズで検証できます。KT が Certificate Transparency と決定的に違うのは、不在証明を必須とする点です。CT は「載っていること」を監視すれば足りますが、KT では「載っているべきでない鍵が載っていないこと」まで示さないと、隠れた第2の鍵を検出できません。

索引の秘匿と一意化：VRF

不在証明を作るには、鍵をユーザー名で索引できる木、すなわちキーでソートまたはトライ構造にした木が要ります。しかしユーザー名をそのまま葉のキーにすると、ログを見た第三者に 全ユーザーの一覧が漏れます。かといってユーザー名を普通のハッシュにすると、サーバーが同じユーザー名に対しエポックごとに異なるハッシュを主張し、証明を出し分ける余地が残ります。

CONIKS が導入した解法が VRF（検証可能疑似ランダム関数, Verifiable Random Function） です。VRF はサーバーの秘密鍵で「ユーザー名 → 木の中の位置（index）」を決定的に写像しつつ、その写像が正しいことの証明を出せます。

index, proof = VRF_Prove(sk_server, username)
# 検証者は公開鍵で確認できる：
VRF_Verify(pk_server, username, index, proof) == true

VRF の二つの性質が効きます。第一に 一意性（uniqueness）：あるユーザー名に対する index はサーバー鍵のもとで一意に定まり、サーバーは「別の位置」を主張できません。これがなければ、サーバーは同一ユーザーに対し複数の位置を使い分けて不在証明を偽装できます。第二に 疑似ランダム性：VRF 出力は秘密鍵を持たない者には予測不能なため、ログの位置からユーザー名を逆算・列挙できません。こうしてプライバシー（列挙耐性）と検証可能性（位置の一意固定）を同時に満たします。VRF の詳細は 検証可能疑似ランダム関数 を参照してください。

split-view 攻撃と gossip

STH に署名があっても、それだけでは足りません。サーバーは 人によって異なる木を見せる ことができるからです。攻撃対象の被害者には「偽の鍵を含む木」の STH を、他の全員には「正規の木」の STH を配れば、一貫性証明は各系列の中では整合してしまい、被害者は自分だけ別の履歴を見せられていることに気づけません。これを split-view 攻撃（分岐ビュー／fork 攻撃）と呼びます。

対策は gossip（うわさ話） です。ユーザーや監視者が観測した STH を互いに、あるいは第三者の監査者に共有し、同じエポックに対し異なる根が存在しないことを突き合わせます。矛盾する二つの STH が見つかれば、それがサーバーの二枚舌の動かぬ証拠（cryptographic proof of misbehavior）になります。実装では、独立した auditor（一貫性だけを検証し STH 系列の単一性を保証）と、後述の monitor が役割分担します。この「単一の根に全員を合意させる」問題は、Certificate Transparency における SCT の gossip や、中間者攻撃と証明書ピンニング が扱う信頼の固定と同根の課題です。

monitor：なりすまし鍵を検知する主体

KT で最も重要かつ見落とされがちなのが monitor（監視者） の役割です。包含・不在・一貫性の各証明は「その瞬間のログの正しさ」を検証するだけで、自分のアカウントに勝手に鍵が追加されたこと自体は、誰かが継続的に見張らなければ気づけません。

monitor は、エポックごとに更新される STH を追跡し、特定のユーザー名（典型的には自分自身）に紐づく鍵集合の変化を監視します。ある版で「鍵は A のみ」だったのが次の版で「A と B」に増えていれば、B は本人が登録した覚えのない なりすまし鍵かもしれない、と警告できます。この監視は本人のデバイスがバックグラウンドで行うのが理想ですが、常時オンラインとは限らないため、信頼できる第三者 monitor に委任する設計もあります。

CONIKS から Key Transparency 実装へ

系譜を押さえると全体像が締まります。

• CONIKS（2015）：KT の学術的原型。VRF による名前の秘匿と一意化、ユーザー自身が自分のキー履歴を監視する monitor モデル、split-view 検出のための STH gossip という主要部品を提示しました。
• Google Key Transparency：CONIKS を実装・一般化したオープンソース基盤で、Trillian（CT と共通の追記専用ログ実装）の上に鍵ディレクトリを構築します。
• WhatsApp Key Transparency（2023）：数十億ユーザー規模で稼働する初の大規模実装の一つ。安全番号照合を KT による自動検証で裏打ちします。
• Apple iMessage Contact Key Verification（2023）：連絡先の鍵を KT ログで検証し、鍵が食い違えばユーザーに警告します。iMessage の E2EE 鍵配布（FIDO2/WebAuthn と同じく公開鍵ベースの本人性）に監査可能性を足す位置づけです。
• IETF KEYTRANS ワーキンググループ：これらの相互運用可能な標準化を進めており、ログ構造・証明形式・gossip の共通仕様を定義しつつあります。

まとめ

鍵透明性は、E2EE の最後の急所である「公開鍵配布時のサーバー信頼」を、暗号学的な検証で置き換える仕組みです。鍵の割り当てを追記専用のマークル木ログに載せ、署名付きの根で固定し、包含・不在・一貫性の証明で中身を裏取りします。ユーザー名は VRF で秘匿しつつ位置を一意化し、gossip で全員が同一の根を見ていること（split-view の不在）を担保し、monitor が自分の鍵に混入したなりすまし鍵を継続監視します。CONIKS の原理を WhatsApp や iMessage が実運用に落とし込み、IETF KEYTRANS が標準化を進める今、鍵透明性は「サーバーが正直でなくても E2EE が安全である」ことを、ユーザーに追加の手間を課さずに近づける中核技術になりつつあります。