Closed5
リアルタイムコミュニケーションにおける End to End Encryption (E2EE) について
voluntasライセンス
Creative Commons — 表示 - 非営利 - 改変禁止 4.0 国際 — CC BY-NC-ND 4.0
前提
- 雑に書いている
- ここで扱う E2EE の対象はメッセージングと音声と映像のみ
- 特にグループでの扱いを書いていく
- ストレージでの用途については書かない
- 歴史とかはググれば出てくるので、今どうなのか
著者
- 商用 WebRTC SFU 開発者
- E2EE 対応
- WebRTC プロトコルスタック実装者
- End to End Encryption プロトコルスタック実装者
- Signal + SFrame (WebAssembly)
voluntasE2EE の目的
- E2EE とはサービスの管理者が悪用できないようにするのが最大の目的とする仕組み
- その中にはパケットを中継するであろうキャリアやサービスプロバイダも含まれる
voluntasE2EE で守れないもの
- 悪意ある参加者
- 認証を握っているであろうサービスの管理者が悪意がある場合は拒否できない
- 悪意ある参加者を拒否するには本人確認がサービスとは別の仕組みでできる必要があり、それは E2EE とは関係ない
- ローカルへの保存
- 受信したデータをローカルで復号する以上は防げない、これはもうどうしようもない
voluntasE2EE で求められるもの
パケットへの署名
- 公開鍵ペアを生成し秘密鍵を利用してパケットに署名を行う事で途中でパケットが改ざんされていないことを確認する
- 公開鍵がサービス外の第三者によって共有されていることも重要となる
- これで悪意ある管理者がパケットを改ざんしていないことを確認できる
- 例えば接続完了時に公開鍵のフィンガープリントを口頭などで共有することで確認することができる
- Zoom や Cisco はフィンガープリントを数値のみにしたりして、共有しやすくしている
メンバー参加/離脱時の鍵ローテーション
- これがない限りは E2EE とはいえないと思って良い
- 誰かが参加したり、誰かが離脱したら参加者全員が現在利用している鍵をローテーションする
- 鍵の更新後の古い鍵の破棄までのインターバルが重要になる
- Google Duo は 5 秒以内または全員に鍵が配り終わったらとしている
- Zoom は 15 秒
- もっと知りたい人は Foward Security / Post-Compromise Security でググると良い
E2EE の課題
- 基本的には SIgnal プロトコルを採用しているため大規模な人数に対応できない
- 数万人規模のメッセージングのやりとりなどには相性が悪い
- Google / Cisco / Apple などは Message Layer Security を検討中
- E2EE の仕組みがあまりにも安全で強力すぎるため 解析できない問題 が出ている
- オープンな場でバックドアの要望が出ている
voluntasリアルタイムコミュニケーションにおける E2EE
- メッセージングは様々なアプリが対応しておりそこそこ歴史がある
- グループメッセージも大規模でなければ対応してきている
- ビデオチャットについては今までは 1:1 が主流だった
- グループビデオチャットでの E2EE はここ最近の話
グループビデオチャットにおける E2EE は今まさにホットな分野。歴史はない。
なぜグループビデオチャットは難しいのか
- オフラインという概念がないため、全てリアルタイムでの取り扱いになる
- メッセージと違い「遅延がそもそも許されない」ため、扱いが難しい
- 鍵のローテーションするたびに鍵配布のインターバルが存在する
- インターバルを減らすため鍵の配布をしなくていい MLS が仕様策定中
- グループ共通鍵を採用するとパケットへの署名が必要になる
リアルタイムかつ、サーバ経由かつ、鍵交換、鍵ローテーション、暗号化、復号などの複雑な仕組みをクライアントだけで実装する必要があり、さらに本人確認の仕組みも E2EE とは別に用意する必要がある。
参考
- Signal
- LINE
- https://linecorp.com/ja/security/encryption/2020h1
- グループ通話は E2EE に対応していない
- Telegram
- https://telegram.org/blog/video-calls
- 2020 年にアルファ版がでて、グループビデオチャットはこれから
このスクラップは2022/08/22にクローズされました