🤩

WebRTC における E2EE について

2 min read

概要

WebRTC での E2EE (End to End Encryption) についてまとめてなかったのでまとめておいた。

誰?

  • 商用 WebRTC SFU の設計/開発者
  • 商用 WebRTC SFU 向け E2EE ライブラリ設計/開発者
  • E2EE 専門家ではない

要約

  • WebRTC P2P は E2EE を実現している
  • WebRTC SFU はサーバ側で DTLS や SRTP を復号し、暗号化するため E2EE ではない
  • WebRTC SFU で E2EE を実現するため Insertable Streams API (現在は WebRTC Encoded Transform API) が出てきた

WebRTC P2P における E2EE

  • WebRTC P2P の場合は P2P で直接 DTLS のやりとりをするため E2EE が実現できている
    • Fingerprint をシグナリングサーバ経由で送る事で証明書のチェックもしている

WebRTC SFU における E2EE

  • WebRTC SFU では SFU が一度クライアントからのデータを全て復号し、再度暗号化してから転送するため、E2EE は実現されない
  • そのため SFU ではクライアント側でエンコード済みの音声や映像に触れるようにする Insertable Streams API (現在は WebRTC Encoded Transform API) がでてきた。
    • この API を使うことでエンコード済みのパケットを書き換えることができる
      • この機能自体は E2EE と直接は関係ない
    • この API を利用してエンコード済みの音声や映像を暗号化/復号する事で E2EE を実現する
  • E2EE のための鍵の交換や鍵の署名は規定されていないが、基本的には Signal Protocol を利用する
  • E2EE のためのメッセージの暗号化のやりとりは規定されていないが、基本的には Signal Protocol を利用する
  • E2EE のための音声や映像のメディアストリームの暗号化のやりとりは規定されていないが、基本的には SFrame を利用する

これらを組み合わせて WebRTC SFU では E2EE を実現している事が多い。
Signal、Wire、Google Duo や Apple FaceTime、Facebook Messenger、WhatsApp などが採用している。

最近の流れ

よくある誤解

  • E2EE を採用していれば安全
    • クライアント側のソースコードが完全に公開されており、そのコードをビルドしたアプリである事を証明されなければ安全とはいえない
  • グループビデオチャットでも E2EE は昔から実現されている
    • グループでのメディアストリームは E2EE を実現されていない事が多い
    • メディアストリームの E2EE はここ数年でやっと使い物になってきた技術
    • SFrame もまだドラフト段階で、今後は SPacket という話も出てきている

Discussion

ログインするとコメントできます