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層です。暗号化されているから安全、ではありません。どこが暗号化されていないかを見てください。
参考文献
🔒 AIセキュリティ・コードレビューの実践に興味がある方は、Zenn Book「Claude Code 実践ガイド」もご覧ください。