その他¶
クライアントの見える化¶
E2EE の仕組みはクライアントとサーバの実装が悪意がないことが前提に組まれています。
どれだけ E2EE を実装したとしても、クライアントがクローズドソースな場合、 クライアントからこっそりとマテリアルキーをサーバに送っていたらそれはもうどうしようもありません。
そのため、すべての通信が目に見えるブラウザでの実装がとても重要になると考えています。
実際 Signal は提供している Android クライアントが、 オープンソースで公開されているものと同一かどうかを確認する方法などを紹介しています。
Signal >> Blog >> Reproducible Signal builds for Android
クライアントのソースコードが公開されていない場合は、 E2EE が行われているかどうかを確認するのが困難です。
E2EE と匿名性¶
E2EE 自体には実は匿名性というものは含まれていないと考えるのが一般的です。 ただ E2EE を利用したメッセージングサービスの多くが匿名性を強みにしていることから E2EE は匿名性ありきと考えがちです。
E2EE はむしろ「参加者が信頼できるかどうか」の方が重要だったりします。 このあたりは Zoom のホワイトペーパが詳しく書いていますので興味がある人は読んでみてください。
今後の WebRTC SFU を利用した場合の E2EE 実装¶
X3DH と Double Ratchet と SFrame を利用した仕組みがまず広まっていくと思います。 現時点で実現できているのは Google Duo だけですが、Wire や Signal がデスクトップ版を提供し始めています。
その後 MLS を利用した仕組みに置き換わっていくと考えています。 ただ MLS 自体はそんなに一気に広まっていくとは考えていません。ゆっくり時間をかけて検証する必要があるためです。
ただ Google Duo はブラウザでの E2EE を WebAssembly を利用して実現してきており、本気を感じさせます。
Certificate Transparency¶
そのうち書きます