先日、WebRTC SFU Sora の JavaScript SDK で利用可能な E2EE ライブラリを公開しました。
このライブラリは Chrome M83 から Origin Trial で利用可能な Insertable Streams API を利用し、クライアントだけが知っている MasterSecret を利用してエンコード済みペイロードを AES-GCM で暗号化/復号するというものです。
ただ、残念ながら E2EE と名乗るにはまだまだ足りていません。現時点で実現できているのは 1 割程度というのが正直なところです。
今後は完全な E2EE 対応にむけて、どのような課題にどう対応していくのかを書いていきます。
ただ、WebRTC SFU + E2EE はまだまだこれからの世界なので、今書いていることが確定している世界ではありません。そこには注意してください。
グループでの MasterSecret の安全な共有
今は事前に何かしらの方法で MasterSecret を共有してもらうという方法をとっていますが、本来はこの MasterSecret を安全に共有する仕組みも含める必要があります。
この部分は Message Layer Security (以降 MLS)を採用したいと考えています。
グループへの参加/離脱時での鍵更新
E2EE ではグループにクライアントが参加したタイミング、離脱したタイミングで鍵を更新する仕組みが必要になります。
この部分でも Message Layer Security を採用したいと考えています。
独自ペイロード暗号化の廃止
現在 Sora の E2EE のペイロード暗号部分は独自の仕組みです。独自と言ってもシーケンス番号と SSRC をペイロードに追加して送るというものです。
この部分は独自をやめて Secure Frame (以降 SFrame) を採用したいと考えています。
SFrame は Google と CoSMo からの提案で、かなり良さげな実装になっています。実際 Google Duo が採用しているとのことです。
CoSMo の中の人からお誘いを受けて SFrame への取り組みを一緒にやっていく予定です。
WebRTC SFU Sora へ MLS 組み込み
現時点ではメッセージングサーバを別途立てるという仕組みをどうするべきか悩んでいます。
MLS 自体を WebRTC SFU Sora に組み込んでしまうというのが一番キレイなパターンなのではないだろうか？とも考えています。
理由としては MLS はクライアント側で状態管理と通知が必要になります。これらを Push で受け取るには WebSocket などのプロトコルを利用するというのが一般的だと思いますが、WebRTC は UDP ベースのプロトコルを採用しているということもあり、TCP ベースではりっぱなしのプロトコルとは相性が悪いです。
そのため、Sora に DataChannel ベースの MLS を実装するというのが良いのではないか？と考えています。
まだわかりませんが、具体的に動くものができたらまたこちらについては共有していきます。
なぜ E2EE なのか
WebRTC SFU はサーバがすべてを管理してうまくいく仕組みです。さらに合成などを一切しないため、MCU と比べて負荷が低いです。
ただ、サーバ側ですべてのパケットを復号するため「中身が全部見れます」、そして「復号しているが、中身を見ていない」ことを証明することはとても難しいです。
完全な E2EE を実装することで、これを証明可能です。さらにクライアント側を OSS にしている事により、信頼性を担保しやすいです。
今後 E2EE への対応というのが「WebRTC SFU 採用する要件」に上がってくるとも考えています。
何より、利用側には地味で効果はまったくわからないが、実際の効果は絶大というのがとても良いです。
時雨堂としてはプライバシーを考慮することが可能な WebRTC SFU を提供したいと強く思っています。
