Zoom が DataChannel を利用している理由について考えてみた
最近 E2EE や DataChanel を実装してることもあり、様々なホワイトペーパやらオープンソースの実装を見たりしています。
Zoom の E2EE ホワイトペーパーを読んで、Zoom がなぜ MediaChannel を利用せず DataChannel を利用したのかがわかった気がしたので、まとめてみます。
注意
Zoom 側の理解が間違っているかもしれませんので、間違いを見つけた方は Twitter の voluntas までご連絡ください。
Zoom の E2EE ホワイトペーパー
現在の実装から今後どうしていくかをかなり詳細に書いていますので、まずはこちらを読んでみることをおすすめします。
Zoom の暗号化/復号
Zoom の暗号化/復号はすべてクライアントで行われ、Zoom のメディアルーターは基本的に干渉しないという設計のようです。WebRTC SFU とは異なり、基本的にはリレーサーバのような役割を果たしているようです。
ただしここからがポイントでクライアントが暗号化/復号に利用する鍵は参加者全員が同じものを利用します。さらにこの鍵はZoom サーバが配布します。
鍵自体の変更は一切行われず、1 鍵 1 会議という仕組みのようです。
WebRTC MediaChannel
WebRTC MediaChannel は DTLS-SRTP という RFC に規定されている仕組みを利用しているため、融通が全く効きません。
この仕組を利用する以上、SFU 経由で配信する場合は必ず一度サーバで暗号化/復号を行う必要があります。これはどんな WebRTC SFU でも同様です。Google でも、Jitsi でも、Janus でも、mediasoup でも、Sora でもです。
つまり全員が同じ暗号鍵を使うという仕組みを使う以上 MediaChannel は利用できません。なぜならもし行ってしまったらサーバ側で暗号化/復号を行う必要があるためです。
ちなみに WebRTC SFU の一番の負荷は暗号化/復号です。これはどう頑張っても回避できません。
WebRTC DataChannel
Zoom は MediaDataChannel が使えなかったため以前は WebSocket 経由で映像を送受信していました。だた WebSocket は不安定な回線にとても弱く、すぐに詰まってしまうため、 DataChannel への切り替えを行ったのでしょう。
DataChannel は簡単に言うと SCTP over DTLS over UDP という仕組みです。そのためブラウザで内部で使うプロトコルを強制されることなく UDP の仕組みを利用できる唯一の方法です。
おそらく Zoom のブラウザのクライアントは音声や映像を AES-GCM (まだ ECB かもしれませんが) をブラウザで WASM かWebCrypto を暗号化した状態で DataChannel を利用して Zoom のメディアルーターに送っているのだと思います。エンコード/デコードが WASM を利用した独自なのも MediaChannel が利用したくても利用できないからです。
おまけ
Zoom の E2EE をざっくりと
Zoom の E2EE ではブラウザが外されました。この理由は色々あると思いますが、暗号が 3 重になってしまうというのもありそうです。
ちなみにZoom の E2EE は X3DH っぽい仕組みを採用しています。ホストと呼ばれる会議主催者がすべてのクライアントと DH (x25519) を行い、ホストが生成した暗号鍵をすべてのクライアントに配布します。
参加/離脱で暗号鍵が変更され、その間のインターバルは 15 秒です。プッシュ方式ではなく掲示板方式で誰もが見れる掲示板にそれぞれと DH することで得た暗号鍵を利用してグループ用の暗号鍵を全員分、共有します。
手間はかかりますが確かにこれであれば E2EE 自体は実現可能です。
そのうち Zoom の E2EE については、ちゃんとまとめていこうと思います。
Google Duo の E2EE
別にまとめてあるのでどうぞ。
