ここ数ヶ月は自社製品向けの End to End (Media) Encryption の設計と実装をしています。年内での提供を目標として開発を進めてい見ていますが、色々感じることがあったので雑に書いていこうと思います。
前提
- 自分は暗号やセキュリティの専門家ではない
- 自社製品向けの E2EE は Signal や Google Duo が利用している実績のある仕組みを採用している
- E2EE や暗号の専門家を招聘し、相談しながら開発している
自分の E2EE に対する考え
悪意あるサービス管理者からユーザを守るために存在する機能と考えています。
Signal プロトコルはよく考えられすぎている
Signal が考えた Curve25519 (x25519/ed25519) を利用した X3DH / Double Ratchet の仕組みは安全すぎると感じるくらいです。
- 相手からメッセージを受信するたび DH (Diffie–Hellman key exchange) に利用する公開鍵を変える
- 参加と離脱で利用するマテリアル鍵を変える
実装して、テストを書いて感じるのが仕組みとしてよく考えられているということです。仕組み自体はよくできているのですが、いかんせん複雑というのは正直思いました。ただ Foward Security / Post-Compromise Security の両方を実現できているのは考えられているなと実感しています。
End to End Media Encryption はこれから
E2EE は今までメッセージがほとんどで、通話は 1 対 1 が前提でグループ通話は今までほとんど考えられていませんでした。
実際、ほとんどの E2EE サービスはグループ通話の E2EE には対応していません。対応が活発になったのは今年になってからです。
グループ通話での E2EE が難しいのは P2P が利用できないのが理由でしょう。ほぼすべての E2EE サービスの 1:1 の通話は WebRTC の P2P が利用されています。ただグループ通話となると P2P は厳しくなるため WebRTC SFU が必要になります。Zoom でも Media Router と呼ばれる WebRTC SFU と同じような仕組みを実現しています。
メッセージは参加者それぞれの鍵で暗号化してそれぞれに送信していたとしてもそんなに重いものではありませんでしたが、音声や映像のようなストリームは「常に送信し続ける」必要があり、それぞれに送信するわけにもいきません。
そこで出てきたのが Sender Keys と呼ばれる仕組みで、Signal プロトコル上でストリーム向けの鍵を事前に配布するというものです。
この仕組を利用した場合、誰かが参加した場合にはそれぞれが配られた鍵を更新する必要があります。また、誰かが離脱した場合には鍵を全員が配布し直す必要があり、新しい鍵を利用開始するまでのインターバルは限りなく小さくする必要があります。ちなみに Google Duo では 5 秒、Zoom では 15 秒以内と決められています。
グループ通話における E2EE はいろいろなサービスが試行錯誤している段階と言って間違いないでしょう。まずは Signal プロトコルをうまく利用して進んでいく事になりそうです。
WebRTC における E2EE
WebRTC (メディアチャネル) の P2P は E2EE といって問題ない仕組みを実現していますが、WebRTC SFU となると話は別です。
WebRTC (メディアチャネル) を WebRTC SFU でそのまま利用する場合は必ず、SFU 側で一度復号し、その後暗号化して送るという手順が必要になります。そのため WebRTC を利用してブラウザで E2EE を実現するのは今まで困難でした。
そこで出てきたのが Insertable Streams API です。これはブラウザ側でエンコード後またはデコード前のフレームに対して処理を挟み込める仕組みです。コレを利用することで独自の暗号化や復号ができるようになりました。
Google Duo のウェブ版もこの仕組を利用しています。おそらく Signal や Wire のデスクトップ版もこの機能を利用するでしょう。もちろん自社製品でもこの機能を利用しています。
ブラウザにおける E2EE
ブラウザで E2EE を実現する際に課題になるのが暗号関連です。Signal プロトコルで利用する Curve25519 が Web Crypto が非対応という問題です。これの問題を Google Duo では WebAssembly を利用して解決しており、Signal は Emscripten を利用して JS 化することで解決しているようです。自社製品では Go を利用した WebAssembly で解決することにしました。
また複雑な仕組みということもあり、JS で書くのはあまり現実的ではないようにも思います。
E2EE の情報は嘘が多い
「E2EE をよくわかっていない人」が書いている情報が多いです。そしてそれらを信じた「E2EE よくわかっていない人の記事を参考に書いたさらに E2EE をよくわかっていない人の記事」もあります。
また、よくわかっていない中で「E2EE 未対応を批判をしている」記事も多いです。
わかりにくい技術を利用している世界なのでどうしようもないのかもしれませんが、E2EE の記事は一次情報以外は参考にしないほうがいいです。サービスが出しているホワイトペーパーか、オープンソースの実装か、サービスの中の人が書いた記事あたりがおすすめです。
E2EE は安全すぎることが脅威とされている
どうやら E2EE は「安全すぎる」ということがいろいろな場面で脅威とされているようです。これは実際に実装していても「安全すぎる」と思います。
自分はあくまでサービス側ではなく「サービスに利用するためのパーツ」を作っている側なので、なんとも言えませんが今後 E2EE は安全すぎるために解析できないと困る部分で脅威とされていくんだろうなとは思います。
どう転ぶかは今後も見守り続けたいと思います。
追記: 2020–10–12 12:00
E2EE を採用したメッセージングアプリに対して暗号技術の見直しを求めたとの記事がでました。
ＩＴ企業に対し、捜査機関がメッセージの内容を閲覧できるよう対策を取るべきだとしたE2EE は現時点でメッセージングの解読は難しいため、補完した復号済みのメッセージに対してのバックドアがほしいというのが本音ではないでしょうか。
もちろん EncroChat のように「すべてのメッセージを読めるサーバを設置したい」というのが本音だと思いますが。
何万人ものユーザーのメッセージが警察の監視にさらされてフィナーレを迎えた日本も声明に参加しているという事から、今後どうなっていくのかわかりませんが、このあたりは積極的に追いかけて行こうと思います。
追記: 2020–10–12 15:00
（1）システム設計に公共の安全を取り入れることにより、企業が違法なコンテンツや活動に対し、安全性を損なうことなく効果的に行動できるようにしつつ、違法行為の捜査や訴追を円滑化し、脆弱な人々を保護することができるようにすること。E2EE では両方は難しいので誰もが利用できる E2EE サービス自体を廃止しろと言う流れのような文章にも見えます。
（2）令状等が合法的に発行され、必要かつ衡平であり、厳格な手続と審査に服している場合に、法執行機関が読取可能かつ利用可能な形式のコンテンツにアクセスできるようにすること。誰もが利用できる E2EE サービスにバックドアを用意しろという文章に見えます。E2EE はバックドアがある時点で E2EE ではなくなります。
（3）合法的なアクセスを促進するための政府や他の利害関係者との協議に、実質的かつ設計の決定に実際に影響を及ぼす形で取り組むこと。E2EE においてバックドアをどう実現するかの設計に横槍を入れられるようにしたいという文章に見えます。
追記: 2021–03–18
https://blog.nic.ad.jp/2020/5545/
2020年秋の動きとして、E2E暗号化に関する7ヶ国共同の声明が公開され、かつEUでの決議案のリークがありました。本稿ではその内容をご紹介したいと思います。日本語で丁寧にまとめられた記事で、リークに関して言及しています。
どうやら誰もが利用できる E2EE サービス自体を殺しにかかっているように見えます。まずは E2EE を実装している Signal / Wire / Telegram / WhatsApp / FB Messenger / LINE がどう出るかを見守りたいです。
