「E2E暗号化対応」を信じてはいけない — ZoomがFTCに嘘と認定された理由と、WebRTC SFUの同じ落とし穴

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は暗号化を「解く」のか

技術的な理由は明確です。

Simulcast（サイマルキャスト） という仕組みがあります。送信者は同じ映像を複数の解像度（高画質・中画質・低画質）で同時に送信します。SFUは受信者のネットワーク状況に応じて、最適な解像度のストリームを選んで転送します。

この選択と切り替えのために、SFUは暗号化を解除してメディアストリームにアクセスする必要があります。

つまり、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 — セキュリティのトレードオフ

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

第3の選択肢 — Insertable Streams

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

Alice ──[独自暗号化]──→ [ SFU ] ──[独自暗号化のまま]──→ Bob
                         ↑
                    SFUはメタデータだけ見る
                    中身は復号できない

アプリケーション層で独自の暗号化をかけてからSFUに渡します。SFUはルーティングに必要なメタデータだけを読み、メディアの中身には触れません。

理論上はP2PのE2E暗号化とSFUのスケーラビリティを両立できます。ただし、まだ実験的な機能であり、Simulcastとの併用に制約があります。本番投入は慎重に検討してください。

どっちを選ぶべきか

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

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

両方必要？
  → Insertable Streams（ただし実験的）

重要なのは、「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)