Zoomは「E2E暗号化」で嘘をついていた

2020年、Zoomは「256bit E2E暗号化対応」と謳いながら、実際にはサーバー側で通話内容を復号できる状態でした。FTC（米国連邦取引委員会）はこれを**「欺瞞的かつ不公正な慣行」**と認定し、Zoomは和解に追い込まれています。

録画データもサーバーに最大2ヶ月間、暗号化なしで保存されていたことまで発覚しました。

なぜこんなことが起きたのか。答えは SFU（Selective Forwarding Unit） というアーキテクチャにあります。Zoom自体はWebRTCではなく独自プロトコルを使っていますが、SFUの仕組みはWebRTCでも広く使われており、同じ問題を抱えています。

「E2E暗号化対応」と書いてあれば安心する。でもその暗号化は、本当にE2Eですか？

P2P vs SFU — まず仕組みを整理する

WebRTCのビデオ通話には、大きく2つのアーキテクチャがあります。

P2P（Peer-to-Peer）

Alice ←──── 暗号化されたまま ────→ Bob
         （サーバーを経由しない）

端末同士が直接つながります。映像データは暗号化されたまま相手に届きます。途中で誰にも見られません。これが本物のE2E暗号化です。

SFU（Selective Forwarding Unit）

Alice ──→ [ SFU サーバー ] ──→ Bob
              ↑ ここで復号 ↑
              ↓ して再暗号化 ↓
                           ──→ Carol
                           ──→ Dave

全員がサーバーを経由します。SFUは受け取った映像を復号し、各参加者に合わせて再暗号化して転送することが可能です。映像の品質調整（解像度の切り替え等）のために、中身を見る必要があります。
※通常は復号せず転送しているものがおおいため、仕様技術のドキュメントをご確認ください。

手紙に例えるなら、郵便局員が毎回封筒を開けて読んでから、新しい封筒に入れて届けてくれる。丁寧ですが、それは「E2E」とは呼べません。

なぜSFUは暗号化を「解く」のか

技術的な理由はDTLS/SRTPの鍵管理にあります。

WebRTCでは、各ピア間でDTLSハンドシェイクを行い、SRTPの暗号鍵を交換します。P2Pの場合はAliceとBobが直接鍵を交換するため、2者間だけの秘密が成立します。

一方SFUの場合、AliceはSFUとDTLSハンドシェイクを行い、SFUはBobと別のDTLSハンドシェイクを行います。そのため、SFUは両方の鍵を持っていることになります。SFUがメディアを転送するには、Aliceからの暗号を解き、Bobへの暗号をかけ直す必要があります。

これはSimulcast（解像度の選択・切り替え）のためではありません。Simulcastの切り替え自体はRTPヘッダー拡張だけで可能です。復号が必要な理由は、純粋に鍵が異なるためです。

つまり、SFUの運営者は技術的に全参加者の映像と音声にアクセス可能です。

信頼できる運営者であれば問題ないかもしれません。でも「E2E暗号化対応」と書いてあったら、普通は「運営者にも見えない」と思いますよね？

じゃあP2Pが安全？ — IP漏洩という代償

P2Pは本物のE2E暗号化を実現できます。ただし、別の問題があります。

IPアドレスが漏れます。

WebRTCのP2P接続では、ICE（Interactive Connectivity Establishment）という仕組みで最適な通信経路を探します。このとき、ICE候補としてローカルIPとパブリックIPが相手に通知されます。

ICE候補の例:
candidate: 0 1 UDP 2122252543 192.168.1.105 52847 typ host
candidate: 1 1 UDP 1686052863 203.0.113.42 52847 typ srflx
                                ^^^^^^^^^^^^
                                パブリックIP（これが漏れる）

VPNを使っていても漏れます。WebRTCのICE収集はVPNトンネルの外で行われるケースがあるためです。あなたの本当のIPアドレスが、通話相手に筒抜けになります。

鉄壁の金庫を持っているのに、自宅の住所を全世界に公開しているようなものです。

P2P vs SFU — セキュリティのトレードオフ

	P2P	SFU
E2E暗号化	✅ 本物	❌ サーバーが復号
IP漏洩	❌ 相手にIPが見える	✅ サーバー経由で隠れる
信頼の対象	通話相手のみ	通話相手 + サーバー運営者
スケーラビリティ	❌ 4人程度が限界	✅ 数百人対応可能

完璧な選択肢はありません。 E2E暗号化を取ればIPが漏れ、IPを隠せばE2Eが崩れる。どちらかを選ぶしかありません。

第3の選択肢 — Insertable Streams

P2PのE2E暗号化は欲しい。でもSFUのスケーラビリティも捨てられない。この矛盾を解決する技術があり、私も実際に検証を進めています。Insertable StreamsとSFrameです。

Alice ──[SFrame暗号化]──→ [ SFU ] ──[SFrame暗号化のまま]──→ Bob
                           ↑
                      SFUはRTPヘッダーだけ見る
                      メディアの中身は復号できない

アプリケーション層でSFrameによる暗号化をかけてからSFUに渡します。SFUはルーティングに必要なRTPヘッダー拡張だけを読み、メディアの中身には触れません。SFUは暗号化されたペイロードをそのまま転送するため、Simulcastとの併用も可能です。

これにより、P2PのE2E暗号化とSFUのスケーラビリティを両立できます。Insertable StreamsはChromeで実装済みであり、すでに実用段階に入りつつあります。

どっちを選ぶべきか

1:1 の機密性の高い通話？
  → P2P（IP漏洩はTURN強制で緩和）

5人以上の会議？
  → SFU（E2Eは妥協、サーバー運営者を信頼）

両方必要？
  → Insertable Streams + SFrame（SFU経由でもE2E暗号化可能）

重要なのは、「E2E暗号化対応」の一言で安心しないことです。それがP2PなのかSFUなのかで、セキュリティの意味がまったく違います。

まとめ

SFUの「E2E暗号化」は技術的にはE2Eではない（サーバーが復号する）
P2Pは本物のE2Eだが、IPアドレスが漏洩する
どちらも完璧ではない。トレードオフを理解して選ぶことがセキュリティの第一歩
使っているビデオ会議ツールがP2PかSFUかを確認してみてください。「E2E暗号化」の意味が変わるはずです

プロトコルの選定は、セキュリティ設計の第1層です。暗号化されているから安全、ではありません。どこが暗号化されていないかを見てください。

参考文献

FTC: Zooming in on Zoom's unfair and deceptive security practices (2020)

🔒 AIセキュリティ・コードレビューの実践に興味がある方は、Zenn Book「Claude Code 実践ガイド」もご覧ください。