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にないのが不便になったので表示用コピーを作ることにした。

Transcript

1. Email, Messaging, and Self-Sovereign Identity Ryo Kajiwara @ WIDE Meeting, 2021/05/28
2. 注意事項 これはどちらかというと意見表明のような性質の発表です 一時期のQiita でいうところの「ポエム」 よって、プロダクトや開発成果のデモではありません また、議論や前提に抜けや穴は余裕で存在するハズです
3. スライド( のソース) は以下の URL から見れます https://github.com/sylph01/2021 0528-wide-email-talk
4. English version (from 2020, so not up to date): https://speakerdeck.com/sylph01 /did
5. TL;DR
6. SMTP をやめろ
7. どうやってやめる？
8. 遅れましたが自己紹介 梶原 龍 といいます Twitter: @s01 暗号とかできます ネットワークまるでわからん
9. もうちょっと真面目に やせいのプログラマ 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 をやっています
11. 第1 部: なんでSMTP をやめる？
12. メッセージングに求める性質 End-to-End 暗号化 派生して、暗号化されたグループメッセージング マルチデバイスのアクセス アイデンティティ表現の制御 場面によって使うID を変えたい
13. E メールはどこまでできる？ End-to-End 暗号化 -> S/MIME を使えば1 対1 なら可能 暗号化されたグループメッセージング -> 不可能 マルチデバイスのアクセス -> POP3 なら不可能、IMAP なら可能 ただし、IMAP の場合データがサーバーに残ることが前提 アイデンティティ表現の制御 メールアドレスを複数所持すれば可能 受信アドレスを出し分けるのはローカルパート + suffix を使えば可能だが関 連付けは容易
14. Q: なんで LINE/Facebook Messenger/WhatsApp etc. があるのにメールなんか使ってるの？
15. Q: なんでLINE/Facebook Messenger/WhatsApp etc. があるのにメールなんか使ってるの？ SMTP は十分な暗号化や認証を持っていない → insecure E メールは通常End-to-End 暗号化を持っていない そもそもSMTP の認証は拡張仕様 POP before SMTP, SMTP-AUTH, ... PGP やS/MIME を使ったところでグループに対する暗号化コミュニケーション はできない E メールにはspam がある
16. A: E メールでは 事前の信頼関係のない人からも メッ セージを受け取ることができる
17. でもE メールには spam がある じゃん！
18. E メールにspam があるのはプロトコルに埋め込まれた 匿名性 が原因
19. E メールの匿名性 「事前の信頼関係のない人からもメッセージを受け取れる」という性質は電話にもあ てはまるが、E メールには電話網にあるようなanti-abuse mechanism を持っていない。 これはE メールのプロトコルに埋め込まれた匿名性が原因である。 電話網をabuse した場合逆探知が可能 E メールにおいてはidentity のspoofing が容易で、捕まえることが困難
20. E メールには identity layer がない
21. まともなidentity layer がないので まともなtrust が構築できない
22. なのでspammer はこの trust の不在を悪用する
23. そもそも匿名のE メール、欲しい？ 匿名のE メールは高確率でspam 。 新たに信頼関係を結びたい場合匿名であることにいいことはそんなにない。
24. じゃあ全面的にS/MIME 、使う？
25. S/MIME の問題 高い 発行された用途に縛られる ある証明書は特定のorganization の所属を証明してくれるかもしれないが インターネットで常にその特定の帽子をかぶっていたいかというとそうでは ない 複数の証明書を使えばいいじゃん？1 行目に戻る
26. もっとドラスティックな解法: マイナンバーカード の証明書でsign されたメールなら 自動で受け入れる
27. 誰も マイナンバーに紐付いたアカウント でspam なん かしないでしょ？
28. まあこんなの 怖いに決まってる じゃないですか
29. じゃあ暗号化諦める？
30. もともとE メールの暗号化は不十分 S/MIME でも使わない限りend-to-end encrypted でない TLS を使っているのはあくまでSMTP リレーのホップ間 SMTP サーバに悪意があったら平文に戻すことができます ヘッダに伝送のための情報が書いてあったり、途中経路でヘッダに書き 加える必要があるから仕方ないのだけど…
31. E メールがdigital identity の核となることの問題 E メールは暗号化が不十分 パスワードを忘れたときのリセットはだいたいE メールを通して行われますね？ → E メールが乗っ取られるとあなたのインターネット上のidentity は全て乗っ取れ ます。 secure messaging で代替できるかはさておき、十分にセキュアでないプロトコル/ エコ システムをdigital identity の核とするのは危険であり、代替を考える必要がある。
32. SMS を二要素認証で使ってるし、そっちなら悪用は困 難なのでは？ NIST SP 800-63B ではSMS （を含む公衆電話網）による二要素認証は条件付きで推奨 となっている。 条件付き、というのは、これ以外の方式を提供せよ、リスクアセスメントをせよ、将 来的に禁止するかもしれないので移行準備せよ、というもの。 非推奨ってよく言われていたのはPreview 版の時点での話。 暗号化されていないので（ただ公衆電話網のピンポイントの盗聴がインターネットの 盗聴に比べて難しいというだけ）どのみち大差ない。
34. 第2 部: セキュアメッセージング
35. セキュアメッセージングとは？ 厳密な術語として存在するかどうかは不明だが、 ここではEnd-to-End 暗号化を実現して、デフォルトで提供しているメッセージングサ ービスを称してセキュアメッセージングと呼ぶ。
36. 現在までにうまくセキュアメッセージングを実装して いるところ LINE Letter Sealing Telegram MTProto WhatsApp, Signal Signal Protocol Keybase Keybase Key Exchange (KEX)
37. 補足: 以前の発表ではFacebook Messenger もE2EE を提供しているとしていなかったっけ？ 確かにEnd-to-End 暗号化を実現するオプションはある しかしデフォルトで有効ではなく グループチャットができない、特定デバイスからしか有効にならないという制限 がつくので除外した。
38. プロトコル間にも差がある The Hacks Between Us による、香港の国家安全法の成立に伴って出されたメッセージ ングの比較記事がわかりやすい。 Letter Sealing: グループチャットの人数制限がある（パフォーマンス上の制限と思 われる） 安全性検証についてはProVerif でのモデル化と検証が行われている MTProto: グループチャットをサポートしていない
39. グループチャットの鍵共有は難しい メッセージングで実現したい性質である Forward Secrecy: 長期鍵が流出しても過去のセッション鍵の安全性が失われない TLS で用いられるFS(PFS) と同じ用法 Post-Compromise Security: グループメンバーの状態が暴露されたとしても、新た に安全な鍵が導出されて以後のグループの会話の秘密性が保たれること を同時に満たすグループチャットは難しい。
40. グループチャットの鍵共有は難しい 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
41. グループチャットの鍵共有は難しい 3 者以上では自明ではない sender key をブロードキャストする方法がよく取られるがこれはFS でない hash ratchet でFS は実現できるが一度破られると鍵の更新に同じ方法を使わ なくてはならない また、マルチデバイス対応が必要な場合デバイス間で鍵を安全に共有することが 困難 グループチャットのメンバーの一員かのように別の鍵を配ってしまうことが できればよいが…
42. セキュアメッセージングで全てが解決？ →No.
43. サービス事業者の「悪堕ち」 LINE のデータ管理問題 本体のガバナンスの問題であることに加えて… 通常の通信そのものは暗号化されているが、スタンプのアクセスログは残っ ていてそこからどのようなスタンプが用いられたかは類推可能 → 必ずしもす べての通信が運営から保護されていたわけではない
44. Interoperable なプロトコルが欲しい！
45. Messaging Layer Security
46. Messaging Layer Security 日本語の資料としては過去にしゃべったスライドがありますが、最新で2 年前なのでち ょっと古いことに注意が必要です https://speakerdeck.com/sylph01/messaging-layer-security https://speakerdeck.com/sylph01/messaging-layer-security-and-stuff-at-ietf105
47. Messaging Layer Security メッセージの秘密性・完全性・認証 メンバーの認証 非同期性（メンバーの常時オンライン性を要求しない） Forward Secrecy, Post-Compromise Secrecy スケーラビリティ を実現するグループ鍵共有のinteroperable な方法の確立を目指すIETF のworking group
48. Messaging Layer Security アーキテクチャを定める draft-ietf-mls-architecture-06 プロトコルを定める draft-ietf-mls-protocol-11 がWG document として存在する。まだどちらもstatus は"I-D Exists" （進行中）。 WG のWeb サイト messaginglayersecurity.rocks がある。
50. 第3 部: Self-Sovereign Identity
51. Self-Sovereign Identity とは 日本語だと「自己主権型アイデンティティ」と呼ばれる。 外部のIdentity Provider に頼る中央集権化されたアイデンティティモデルに対して、自 らの手にアイデンティティのコントロールを取り戻すことを目指す動き・その思想の こと。 前職のテックブログに記事を書いた。 https://lepidum.co.jp/blog/2020-01-31/self- sovereign-identity/
52. Self-Sovereign Identity とは 中央集権化されたID のリスク 情報漏洩 情報の目的外利用、必要以上の情報収集 自らのデジタルアイデンティティへのアクセスを失う 2020 年以降Terms of Service 違反でのアカウントBAN が急に現実化した
53. Self-Sovereign Identity で実現したい主な機能 アイデンティティ情報の提供範囲の制御 文脈によってアイデンティティを使い分ける アイデンティティの有効期限の制御 現実世界では既に行われている！
54. Multi-Source Identity, Verifiable Credentials 中央集権的なID 管理ではアイデンティティ情報は単一の情報源からのみ提供され る 現実には「免許証」「学位」「マイナンバー」… それぞれ発行主体が異なる → Multi-Source Identity また、「プロフェッショナルとしての私」「趣味のコミュニティでの私」「家族 の中での私」は役割が違い、混同してほしくない → アイデンティティ情報に対す るコントロールが欲しい これを支える仕組みとしてVerifiable Credentials Data Model がある
56. E メールはもともとself-sovereign だった
57. E メールはもともとself-sovereign だった ( ただしマッチョに限る)
58. E メールはもともとself-sovereign だった SMTP/POP3/IMAP はもともとself-sovereign なプロトコルだった。自分でサーバーを立 てる限りは。 自分でID を発行できる 用途によってID を使い分けることができる 自分のデータは自分で持つことができる
59. E メールはもともとself-sovereign だった 最近は誰もそんなことはしない。 SMTP: 適切に認証をするのが難しい。設定を1 個でも間違えるとspam の踏み台 IMAP: マルチデバイスアクセスなら必須だがストレージ管理が地獄 結果、本来self-sovereign であるはずのプロトコルなのだが、中央集権化を許してしま った
60. E メールの中央集権化の加速 中央集権的E メールプロバイダ(Gmail, Microsoft Live, ...) のspam フィルタの動作は十分 な透明性がなく、悪意のないメールですらspam フィルタに飲まれてしまう。 中央集権的E メールプロバイダを利用していないメールはspam フィルタを信用させる ことが難しくなり、より中央集権化が進む （メール認証が十分に行き渡っていないこと、まただいぶhacky な方法しかないことも 挙げられるが… ）
61. Principles of User Sovereignty / Fundamental Problems of Distributed Systems @ IIW30 「分散システムの抱える根本的な問題を解決できないとき、それは企業による中央集 権化(corporate capture) を自ら許してしまう」 E メールはまさにこの最たる例ではないか？
62. Fundamental Problems of Distributed Systems 例: ノードのディスカバリー ノードがネットワークに参加する際のセッションの確立 (introduction) プライバシー ( 識別子による長期的な関連付けの防止) トラスト これらの問題を十分に解決できなかったので企業がマネタイズの機会を見出し中央集 権化してしまった。
63. The Internet の強みは 自律分散性 ではなかったのか？
65. 第4 部: どうやってSMTP をやめる？
66. 「SMTP をやめろ」というとよく言われる話： 「要するにそれ、Better PGP でしょ？」 「PGP が失敗したのって知ってる？」
67. 知ってる。
68. 我々は既にBetter PGP を持っている ... LINE, WhatsApp, Telegram, Signal, Keybase (, Facebook Messenger) っていうんですけど
69. 我々は既にBetter PGP を持っている セキュアメッセージングアプリはPGP のユーザビリティの問題を解決している 暗号化は透過的に行われる なんなら暗号鍵のライフサイクルすら面倒を見てくれる 暗号鍵の選択 = 複数アカウントの使い分け 一部のものはグループメッセージングすら可能 それが単にSMTP という形をとっていないだけ
70. SMTP でも1 対1 の暗号化は割と解決している SMTP では1 対多の暗号化が難しい
71. 1 対多のユースケース メーリングリスト、通知の購読 An Abuse-Resistant Messaging Protocol by Jim Fenton 通知に特化した、オプトイン限定かつ送信先が認証されているメッセージン グプロトコルのサブセットの提案(Notif) グループでのメッセージのやりとり 1 対多でやりとりする形よりも、ルームを作ってそこにjoin するグループチャ ットのアプローチを採用すればよいのでは？ mass marketing これは仕方ないので暗号化されてない世界でやってもらうしかないし、たい ていspam なのでブロックされても仕方ないのでは？
72. DIDComm Aries RFC 0005: DID Communication で説明されている、Distributed Identifiers をもっ て識別されるDID Agent 同士のコミュニケーションメカニズム。 DIDComm はtransport-agnostic なコミュニケーションのアーキテクチャを示しているも のと考えるのがよく、各トランスポートにおける通信方法はAries RFC 0025: DIDComm Transports で書かれている。 相手をどのように発見するか、相手とどのように関係を持つかはDID Core の仕様に基 づいている。 既にいくつかの実装例がある。
73. DIDComm … とはいえ、DID が"purely self-sovereign" であるかというと必ずしもそうではない。 自分自身でID を名乗ることができる、という意味ではself-sovereign だが 相手に見つけてもらう必要がある globally discoverable であるためには名前が必要 DNS 、DNS に紐づくlookup service public blockchain にID を名乗るとしてもどのchain を信用するか問題 見つけてもらってもオフラインだったらメッセージを保管する場所が必要 self-sovereign( ただしマッチョに限る) であれば中央集権化への道が開かれて しまう
74. Verifiable Credential を用いたE メール 各トランザクション（E メールのやりとり）で異なるアイデンティティ表現を使うに は？ → 特定のアイデンティティ表現に対応するVerifiable Credential を使えばよいので は？ spam フィルタはE メールに関連づいたVC の正当性・信頼度を判定する。より accountable なID にたどり着けるVC のほうが高い信頼性とする。 よく考えたらただのbetter digital signature かもしれないが…
75. Data at Rest の暗号化 JSON Web Message (JWM) が有望なのでは… と思ったらExpire してしまっていた。 暗号化して保存でき、相互運用可能なフォーマットがあるといいですね…
77. まとめ
78. まとめ E メールには暗号化がない E メールをデジタルアイデンティティの核とし続けるのは怖い E メールにはまともなidentity layer がない identity layer の構築をE メールプロバイダに任せるとself-sovereign でなくなる どうやって解決する？ セキュアメッセージングのinteroperability DID を使ったidentity layer を作る
79. やめよう、SMTP
80. Questions/Comments?