Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Email, Messaging, and Self-Sovereign Identity (...

Email, Messaging, and Self-Sovereign Identity (2021/05/28 edition)

2021/05/08 @ WIDE research meeting 2021
https://github.com/sylph01/20210528-wide-email-talk

Speaker Deckにないのが不便になったので表示用コピーを作ることにした。

sylph01

May 28, 2021
Tweet

More Decks by sylph01

Other Decks in Technology

Transcript

  1. もうちょっと真面目に やせいのプログラマ 2019/3 までの所属はACCESS 、2020/10 までの 所属はレピダム 大学時代はユーザーインターフェースとかやっ てたらしい "Dark

    Depths of SMTP"(2017) という薄い本を書きま した W3C, IETF などでセキュリティ周りの標準化の調 査・お手伝いをしていました HTTPS in Local Network CG @ W3C Messaging Layer Security @ IETF Internet Society 日本支部のOfficer をやっています
  2. E メールはどこまでできる? End-to-End 暗号化 -> S/MIME を使えば1 対1 なら可能 暗号化されたグループメッセージング

    -> 不可能 マルチデバイスのアクセス -> POP3 なら不可能、IMAP なら可能 ただし、IMAP の場合データがサーバーに残ることが前提 アイデンティティ表現の制御 メールアドレスを複数所持すれば可能 受信アドレスを出し分けるのはローカルパート + suffix を使えば可能だが関 連付けは容易
  3. Q: なんでLINE/Facebook Messenger/WhatsApp etc. があるのにメールなんか使ってるの? SMTP は十分な暗号化や認証を持っていない → insecure E

    メールは通常End-to-End 暗号化を持っていない そもそもSMTP の認証は拡張仕様 POP before SMTP, SMTP-AUTH, ... PGP やS/MIME を使ったところでグループに対する暗号化コミュニケーション はできない E メールにはspam がある
  4. もともとE メールの暗号化は不十分 S/MIME でも使わない限りend-to-end encrypted でない TLS を使っているのはあくまでSMTP リレーのホップ間 SMTP

    サーバに悪意があったら平文に戻すことができます ヘッダに伝送のための情報が書いてあったり、途中経路でヘッダに書き 加える必要があるから仕方ないのだけど…
  5. E メールがdigital identity の核となることの問題 E メールは暗号化が不十分 パスワードを忘れたときのリセットはだいたいE メールを通して行われますね? → E

    メールが乗っ取られるとあなたのインターネット上のidentity は全て乗っ取れ ます。 secure messaging で代替できるかはさておき、十分にセキュアでないプロトコル/ エコ システムをdigital identity の核とするのは危険であり、代替を考える必要がある。
  6. SMS を二要素認証で使ってるし、そっちなら悪用は困 難なのでは? NIST SP 800-63B ではSMS (を含む公衆電話網)による二要素認証は条件付きで推奨 となっている。 条件付き、というのは、これ以外の方式を提供せよ、リスクアセスメントをせよ、将

    来的に禁止するかもしれないので移行準備せよ、というもの。 非推奨ってよく言われていたのはPreview 版の時点での話。 暗号化されていないので(ただ公衆電話網のピンポイントの盗聴がインターネットの 盗聴に比べて難しいというだけ)どのみち大差ない。
  7. グループチャットの鍵共有は難しい メッセージングで実現したい性質である Forward Secrecy: 長期鍵が流出しても過去のセッション鍵の安全性が失われない TLS で用いられるFS(PFS) と同じ用法 Post-Compromise Security:

    グループメンバーの状態が暴露されたとしても、新た に安全な鍵が導出されて以後のグループの会話の秘密性が保たれること を同時に満たすグループチャットは難しい。
  8. グループチャットの鍵共有は難しい 2 者間であればわかりやすい Signal Protocol で用いられるDouble Ratchet 方式。 暗号におけるRatchet とは、ハッシュ関数を用いて「新しい値から過去の値を計算でき

    ないように鍵を導出する」仕組みである。 CK ​ = i+1 HMAC-SHA256(CK ​ , 0x02) i MK ​ = i HMAC-SHA256(CK ​ , 0x01) i のように からメッセージごとに異なる を作り出す。 から が計算できないことに注意。 CK ​ i MK ​ i CK ​ + i 1 CK ​ i
  9. グループチャットの鍵共有は難しい 3 者以上では自明ではない sender key をブロードキャストする方法がよく取られるがこれはFS でない hash ratchet でFS

    は実現できるが一度破られると鍵の更新に同じ方法を使わ なくてはならない また、マルチデバイス対応が必要な場合デバイス間で鍵を安全に共有することが 困難 グループチャットのメンバーの一員かのように別の鍵を配ってしまうことが できればよいが…
  10. Multi-Source Identity, Verifiable Credentials 中央集権的なID 管理ではアイデンティティ情報は単一の情報源からのみ提供され る 現実には「免許証」「学位」「マイナンバー」… それぞれ発行主体が異なる →

    Multi-Source Identity また、「プロフェッショナルとしての私」「趣味のコミュニティでの私」「家族 の中での私」は役割が違い、混同してほしくない → アイデンティティ情報に対す るコントロールが欲しい これを支える仕組みとしてVerifiable Credentials Data Model がある
  11. E メールの中央集権化の加速 中央集権的E メールプロバイダ(Gmail, Microsoft Live, ...) のspam フィルタの動作は十分 な透明性がなく、悪意のないメールですらspam

    フィルタに飲まれてしまう。 中央集権的E メールプロバイダを利用していないメールはspam フィルタを信用させる ことが難しくなり、より中央集権化が進む (メール認証が十分に行き渡っていないこと、まただいぶhacky な方法しかないことも 挙げられるが… )
  12. Principles of User Sovereignty / Fundamental Problems of Distributed Systems

    @ IIW30 「分散システムの抱える根本的な問題を解決できないとき、それは企業による中央集 権化(corporate capture) を自ら許してしまう」 E メールはまさにこの最たる例ではないか?
  13. Fundamental Problems of Distributed Systems 例: ノードのディスカバリー ノードがネットワークに参加する際のセッションの確立 (introduction) プライバシー

    ( 識別子による長期的な関連付けの防止) トラスト これらの問題を十分に解決できなかったので企業がマネタイズの機会を見出し中央集 権化してしまった。
  14. 1 対多のユースケース メーリングリスト、通知の購読 An Abuse-Resistant Messaging Protocol by Jim Fenton

    通知に特化した、オプトイン限定かつ送信先が認証されているメッセージン グプロトコルのサブセットの提案(Notif) グループでのメッセージのやりとり 1 対多でやりとりする形よりも、ルームを作ってそこにjoin するグループチャ ットのアプローチを採用すればよいのでは? mass marketing これは仕方ないので暗号化されてない世界でやってもらうしかないし、たい ていspam なのでブロックされても仕方ないのでは?
  15. DIDComm Aries RFC 0005: DID Communication で説明されている、Distributed Identifiers をもっ て識別されるDID

    Agent 同士のコミュニケーションメカニズム。 DIDComm はtransport-agnostic なコミュニケーションのアーキテクチャを示しているも のと考えるのがよく、各トランスポートにおける通信方法はAries RFC 0025: DIDComm Transports で書かれている。 相手をどのように発見するか、相手とどのように関係を持つかはDID Core の仕様に基 づいている。 既にいくつかの実装例がある。
  16. DIDComm … とはいえ、DID が"purely self-sovereign" であるかというと必ずしもそうではない。 自分自身でID を名乗ることができる、という意味ではself-sovereign だが 相手に見つけてもらう必要がある

    globally discoverable であるためには名前が必要 DNS 、DNS に紐づくlookup service public blockchain にID を名乗るとしてもどのchain を信用するか問題 見つけてもらってもオフラインだったらメッセージを保管する場所が必要 self-sovereign( ただしマッチョに限る) であれば中央集権化への道が開かれて しまう
  17. Verifiable Credential を用いたE メール 各トランザクション(E メールのやりとり)で異なるアイデンティティ表現を使うに は? → 特定のアイデンティティ表現に対応するVerifiable Credential

    を使えばよいので は? spam フィルタはE メールに関連づいたVC の正当性・信頼度を判定する。より accountable なID にたどり着けるVC のほうが高い信頼性とする。 よく考えたらただのbetter digital signature かもしれないが…
  18. Data at Rest の暗号化 JSON Web Message (JWM) が有望なのでは… と思ったらExpire

    してしまっていた。 暗号化して保存でき、相互運用可能なフォーマットがあるといいですね…
  19. まとめ E メールには暗号化がない E メールをデジタルアイデンティティの核とし続けるのは怖い E メールにはまともなidentity layer がない identity

    layer の構築をE メールプロバイダに任せるとself-sovereign でなくなる どうやって解決する? セキュアメッセージングのinteroperability DID を使ったidentity layer を作る