E2E Encryption + Identity
主に自分向けの資料まとめです
Cisco の Webex におけるゼロトラストセキュリティのホワイトペーパーが公開されました。
このホワイトペーパーがかなり面白かったので自分の理解できる範囲で書いていきます。
まとめ
ゼロトラストセキュリティにおいて ACME プロトコルの SSO 拡張を利用することで信頼できる認証局による署名付きの X.509 証明書をメールアドレスと結びつけ、
その証明書を利用し MLS (Message Layer Security) でグループ鍵を共有し、SFrame (Secure Frame) で音声や映像を暗号化する E2E Encryption を Webex が提供するしていくそうです。
ゼロトラストセキュリティ
なんか難しい話で書いてあることが多いのですが 決して信頼せず、常に確認する という認識で良さそうです。
ACME + SSO
E2E で利用される MLS で利用する信頼された認証局に署名されたメールアドレスと結びついている証明書をどう用意するのかという課題を ACME と SSO の組み合わせで解決しています。
ACME は Let's Encrypt が採用している証明書発行の仕組みです。詳細は RFC になってるのでそちらをどうぞ。
ACME に SSO の仕組みを組み合わせることでメールアドレスを信頼させるという仕組みです。
ACME の証明書発行のフローに SSO を差し込んでしまうというなんとも斬新な仕組みです。
この仕組みを使うことで例えば Google などの ID プロバイダーで利用しているメールアドレスと E2EE で利用する証明書を結びつける事が可能になります。
ID プロバイダーの選択は CA 側ができるというのもよい仕組みだと思います。
MLS
現時点で世の中のほとんどの E2EE の仕組みは Signal プロトコルを採用しています。
ただ Signal プロトコルはセキュリティ的にはガッチガチでよいのですが、
参加者すべてのクライアントがフルメッシュでセッションを張り、それぞれが全員異なる鍵を利用する必要があり効率はよくありません。
その問題を解決するために Facebook によって考えられたのが On Ends-to-Ends Encryption: Asynchronous Group Messaging with Strong Security Guarantees です。この仕組みを使うことでグループで共有の鍵を利用することができます。
MLS はその Asynchronous Ratcheting Tree を利用した仕組みです。
SFrame
SFrame は鍵交換の仕組みに依存しない汎用的な E2EE 向けのメディア暗号化の仕組みです。
MLS を使う場合 AES-GCM で利用する鍵が全員同じになり、
誰がその音声や映像を送ったかどうかを確認できないため、
SFrame に署名をつけるという仕組みが必要になります。
draft-omara-sframe-01 - Secure Frame (SFrame)
MLS + SFrame
今回の Webex の E2EE は MLS と SFrame を組み合わせている仕組みを採用しており、オープンな規格で動作しています。
Using Messaging Layer Security (MLS) to Provide Keys for SFrame
- cisco/sframe: Implementation of draft-omara-sframe
- cisco/mlspp: Implementation of Messaging Layer Security
今後の方向性
Webex はオープンな標準ベースのアプローチ、分散型アイデンティティエコシステム、すべてのエンドポイントに対する E2E セキュリティの有効化を今後の方向性として考えているようです。
正直ここまでオープンな方針をとってくると思っていなかったので衝撃でした。
Discussion