E2EE（エンドツーエンド暗号化）

エンドツーエンド暗号化とは？

エンドツーエンド暗号化（E2EE）は、通信当事者のみがメッセージを読むことができるセキュリティシステムです。サービスプロバイダー、サーバーインフラストラクチャ、プラットフォーム運営者でさえ通信を復号できません。受信者だけが鍵を持つ施錠された箱で手紙を送り、郵便局はそれを開けられないようなものです。

ビデオ通話では、E2EEは音声とビデオストリームがデバイス上で暗号化され、受信者のデバイスに届くまで暗号化されたままであることを意味します。転送中にデータが傍受されたり、通話をルーティングするサーバーが侵害されたりしても、暗号化されたデータしか見えません。

WebRTCの組み込み暗号化（DTLS-SRTP）

WebRTCは暗号化を義務付けています。すべてのWebRTC接続はデフォルトでDTLS-SRTPを使用して暗号化されます。ただし、DTLS-SRTPだけではエンドツーエンド暗号化にはなりません。

SFUの問題：標準WebRTCがE2EEではない理由

P2P WebRTC（2人が直接接続）では、DTLS-SRTPが真のE2EEを提供します。しかし、ほとんどのビデオ通話はグループ通話にSFUサーバーを使用します。SFUはメディアを検査しルーティングするために復号する必要があり、これによりエンドツーエンド暗号化が破られます。

Insertable Streamsによる真のE2EE

解決策は、SFUが決して復号しない暗号化の第2層を追加することです。エンドポイント（参加者）のみがこの層の鍵を持ちます。ブラウザのRTCRtpScriptTransform APIにより、JavaScriptコードがエンコードされたメディアフレームを送信前に傍受し、追加の暗号化を適用できます。

SFrame：新たな標準

SFrame（Secure Frame）は、WebRTCグループ通話でメディアフレームを暗号化するために特別に設計されたIETF標準プロトコルです。メディアペイロードのみを暗号化し、RTPヘッダーを非暗号化のまま残すことで、SFUがパケットをルーティングできるようにします。

なぜ常にE2EEを使用しないのか？

• 機能の制限：クラウド録画、ライブ文字起こし、AIなどのサーバー側機能はメディアへのアクセスが必要で、E2EEと互換性がない
• コンプライアンス：一部の業界では通信の監査が必要で、E2EEはこれを妨げる
• パフォーマンス：追加の暗号化オーバーヘッドにより低スペックデバイスでの品質が低下
• ブラウザサポート：2025年時点でクロスブラウザE2EEにはまだ互換性の課題がある

まとめ

エンドツーエンド暗号化は通信プライバシーのゴールドスタンダードです。WebRTCは常に転送中の暗号化（DTLS-SRTP）を行っていますが、サーバーでさえ通話を復号できない真のE2EEには、SFrameのような追加のアプリケーション層暗号化とMLSのような鍵管理プロトコルが必要です。