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
   

   View Slide

2. 注意事項
   これはどちらかというと意見表明のような性質の発表です
   一時期のQiita
   でいうところの「ポエム」
   よって、プロダクトや開発成果のデモではありません
   また、議論や前提に抜けや穴は余裕で存在するハズです
   

   View Slide

3. スライド(
   のソース)
   は以下の
   URL
   から見れます
   https://github.com/sylph01/2021
   0528-wide-email-talk
   

   View Slide

4. English version (from 2020,
   so not up to date):
   https://speakerdeck.com/sylph01
   /did
   

   View Slide

5. TL;DR
   

   View Slide

6. SMTP
   をやめろ
   

   View Slide

7. どうやってやめる？
   

   View Slide

8. 遅れましたが自己紹介
   梶原 龍 といいます
   Twitter: @s01
   暗号とかできます
   ネットワークまるでわからん
   

   View Slide

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
   をやっています
   

   View Slide

10. View Slide

11. 第1
    部:
    なんでSMTP
    をやめる？
    

    View Slide

12. メッセージングに求める性質
    End-to-End
    暗号化
    派生して、暗号化されたグループメッセージング
    マルチデバイスのアクセス
    アイデンティティ表現の制御
    場面によって使うID
    を変えたい
    

    View Slide

13. E
    メールはどこまでできる？
    End-to-End
    暗号化 -> S/MIME
    を使えば1
    対1
    なら可能
    暗号化されたグループメッセージング ->
    不可能
    マルチデバイスのアクセス -> POP3
    なら不可能、IMAP
    なら可能
    ただし、IMAP
    の場合データがサーバーに残ることが前提
    アイデンティティ表現の制御
    メールアドレスを複数所持すれば可能
    受信アドレスを出し分けるのはローカルパート + suffix
    を使えば可能だが関
    連付けは容易
    

    View Slide

14. Q:
    なんで LINE/Facebook Messenger/WhatsApp
    etc.
    があるのにメールなんか使ってるの？
    

    View Slide

15. Q:
    なんでLINE/Facebook Messenger/WhatsApp
    etc.
    があるのにメールなんか使ってるの？
    SMTP
    は十分な暗号化や認証を持っていない → insecure
    E
    メールは通常End-to-End
    暗号化を持っていない
    そもそもSMTP
    の認証は拡張仕様
    POP before SMTP, SMTP-AUTH, ...
    PGP
    やS/MIME
    を使ったところでグループに対する暗号化コミュニケーション
    はできない
    E
    メールにはspam
    がある
    

    View Slide

16. A: E
    メールでは 事前の信頼関係のない人からも メッ
    セージを受け取ることができる
    

    View Slide

17. でもE
    メールには spam
    がある じゃん！
    

    View Slide

18. E
    メールにspam
    があるのはプロトコルに埋め込まれた
    匿名性 が原因
    

    View Slide

19. E
    メールの匿名性
    「事前の信頼関係のない人からもメッセージを受け取れる」という性質は電話にもあ
    てはまるが、E
    メールには電話網にあるようなanti-abuse mechanism
    を持っていない。
    これはE
    メールのプロトコルに埋め込まれた匿名性が原因である。
    電話網をabuse
    した場合逆探知が可能
    E
    メールにおいてはidentity
    のspoofing
    が容易で、捕まえることが困難
    

    View Slide

20. E
    メールには identity layer
    がない
    

    View Slide

21. まともなidentity layer
    がないので
    まともなtrust
    が構築できない
    

    View Slide

22. なのでspammer
    はこの trust
    の不在を悪用する
    

    View Slide

23. そもそも匿名のE
    メール、欲しい？
    匿名のE
    メールは高確率でspam
    。
    新たに信頼関係を結びたい場合匿名であることにいいことはそんなにない。
    

    View Slide

24. じゃあ全面的にS/MIME
    、使う？
    

    View Slide

25. S/MIME
    の問題
    高い
    発行された用途に縛られる
    ある証明書は特定のorganization
    の所属を証明してくれるかもしれないが
    インターネットで常にその特定の帽子をかぶっていたいかというとそうでは
    ない
    複数の証明書を使えばいいじゃん？1
    行目に戻る
    

    View Slide

26. もっとドラスティックな解法:
    マイナンバーカード の証明書でsign
    されたメールなら
    自動で受け入れる
    

    View Slide

27. 誰も マイナンバーに紐付いたアカウント でspam
    なん
    かしないでしょ？
    

    View Slide

28. まあこんなの 怖いに決まってる じゃないですか
    

    View Slide

29. じゃあ暗号化諦める？
    

    View Slide

30. もともとE
    メールの暗号化は不十分
    S/MIME
    でも使わない限りend-to-end encrypted
    でない
    TLS
    を使っているのはあくまでSMTP
    リレーのホップ間
    SMTP
    サーバに悪意があったら平文に戻すことができます
    ヘッダに伝送のための情報が書いてあったり、途中経路でヘッダに書き
    加える必要があるから仕方ないのだけど…
    

    View Slide

31. E
    メールがdigital identity
    の核となることの問題
    E
    メールは暗号化が不十分
    パスワードを忘れたときのリセットはだいたいE
    メールを通して行われますね？
    → E
    メールが乗っ取られるとあなたのインターネット上のidentity
    は全て乗っ取れ
    ます。
    secure messaging
    で代替できるかはさておき、十分にセキュアでないプロトコル/
    エコ
    システムをdigital identity
    の核とするのは危険であり、代替を考える必要がある。
    

    View Slide

32. SMS
    を二要素認証で使ってるし、そっちなら悪用は困
    難なのでは？
    NIST SP 800-63B
    ではSMS
    （を含む公衆電話網）による二要素認証は条件付きで推奨
    となっている。
    条件付き、というのは、これ以外の方式を提供せよ、リスクアセスメントをせよ、将
    来的に禁止するかもしれないので移行準備せよ、というもの。
    非推奨ってよく言われていたのはPreview
    版の時点での話。
    暗号化されていないので（ただ公衆電話網のピンポイントの盗聴がインターネットの
    盗聴に比べて難しいというだけ）どのみち大差ない。
    

    View Slide

33. View Slide

34. 第2
    部:
    セキュアメッセージング
    

    View Slide

35. セキュアメッセージングとは？
    厳密な術語として存在するかどうかは不明だが、
    ここではEnd-to-End
    暗号化を実現して、デフォルトで提供しているメッセージングサ
    ービスを称してセキュアメッセージングと呼ぶ。
    

    View Slide

36. 現在までにうまくセキュアメッセージングを実装して
    いるところ
    LINE
    Letter Sealing
    Telegram
    MTProto
    WhatsApp, Signal
    Signal Protocol
    Keybase
    Keybase Key Exchange (KEX)
    

    View Slide

37. 補足:
    以前の発表ではFacebook Messenger
    もE2EE
    を提供しているとしていなかったっけ？
    確かにEnd-to-End
    暗号化を実現するオプションはある
    しかしデフォルトで有効ではなく
    グループチャットができない、特定デバイスからしか有効にならないという制限
    がつくので除外した。
    

    View Slide

38. プロトコル間にも差がある
    The Hacks Between Us
    による、香港の国家安全法の成立に伴って出されたメッセージ
    ングの比較記事がわかりやすい。
    Letter Sealing:
    グループチャットの人数制限がある（パフォーマンス上の制限と思
    われる）
    安全性検証についてはProVerif
    でのモデル化と検証が行われている
    MTProto:
    グループチャットをサポートしていない
    

    View Slide

39. グループチャットの鍵共有は難しい
    メッセージングで実現したい性質である
    Forward Secrecy:
    長期鍵が流出しても過去のセッション鍵の安全性が失われない
    TLS
    で用いられるFS(PFS)
    と同じ用法
    Post-Compromise Security:
    グループメンバーの状態が暴露されたとしても、新た
    に安全な鍵が導出されて以後のグループの会話の秘密性が保たれること
    を同時に満たすグループチャットは難しい。
    

    View Slide

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
    

    View Slide

41. グループチャットの鍵共有は難しい
    3
    者以上では自明ではない
    sender key
    をブロードキャストする方法がよく取られるがこれはFS
    でない
    hash ratchet
    でFS
    は実現できるが一度破られると鍵の更新に同じ方法を使わ
    なくてはならない
    また、マルチデバイス対応が必要な場合デバイス間で鍵を安全に共有することが
    困難
    グループチャットのメンバーの一員かのように別の鍵を配ってしまうことが
    できればよいが…
    

    View Slide

42. セキュアメッセージングで全てが解決？
    →No.
    

    View Slide

43. サービス事業者の「悪堕ち」
    LINE
    のデータ管理問題
    本体のガバナンスの問題であることに加えて…
    通常の通信そのものは暗号化されているが、スタンプのアクセスログは残っ
    ていてそこからどのようなスタンプが用いられたかは類推可能 →
    必ずしもす
    べての通信が運営から保護されていたわけではない
    

    View Slide

44. Interoperable
    なプロトコルが欲しい！
    

    View Slide

45. Messaging Layer Security
    

    View Slide

46. Messaging Layer Security
    日本語の資料としては過去にしゃべったスライドがありますが、最新で2
    年前なのでち
    ょっと古いことに注意が必要です
    https://speakerdeck.com/sylph01/messaging-layer-security
    https://speakerdeck.com/sylph01/messaging-layer-security-and-stuff-at-ietf105
    

    View Slide

47. Messaging Layer Security
    メッセージの秘密性・完全性・認証
    メンバーの認証
    非同期性（メンバーの常時オンライン性を要求しない）
    Forward Secrecy, Post-Compromise Secrecy
    スケーラビリティ
    を実現するグループ鍵共有のinteroperable
    な方法の確立を目指すIETF
    のworking group
    

    View Slide

48. Messaging Layer Security
    アーキテクチャを定める draft-ietf-mls-architecture-06
    プロトコルを定める draft-ietf-mls-protocol-11
    がWG document
    として存在する。まだどちらもstatus
    は"I-D Exists"
    （進行中）。
    WG
    のWeb
    サイト messaginglayersecurity.rocks
    がある。
    

    View Slide

49. View Slide

50. 第3
    部: Self-Sovereign Identity
    

    View Slide

51. Self-Sovereign Identity
    とは
    日本語だと「自己主権型アイデンティティ」と呼ばれる。
    外部のIdentity Provider
    に頼る中央集権化されたアイデンティティモデルに対して、自
    らの手にアイデンティティのコントロールを取り戻すことを目指す動き・その思想の
    こと。
    前職のテックブログに記事を書いた。 https://lepidum.co.jp/blog/2020-01-31/self-
    sovereign-identity/
    

    View Slide

52. Self-Sovereign Identity
    とは
    中央集権化されたID
    のリスク
    情報漏洩
    情報の目的外利用、必要以上の情報収集
    自らのデジタルアイデンティティへのアクセスを失う
    2020
    年以降Terms of Service
    違反でのアカウントBAN
    が急に現実化した
    

    View Slide

53. Self-Sovereign Identity
    で実現したい主な機能
    アイデンティティ情報の提供範囲の制御
    文脈によってアイデンティティを使い分ける
    アイデンティティの有効期限の制御
    現実世界では既に行われている！
    

    View Slide

54. Multi-Source Identity, Verifiable Credentials
    中央集権的なID
    管理ではアイデンティティ情報は単一の情報源からのみ提供され
    る
    現実には「免許証」「学位」「マイナンバー」…
    それぞれ発行主体が異なる →
    Multi-Source Identity
    また、「プロフェッショナルとしての私」「趣味のコミュニティでの私」「家族
    の中での私」は役割が違い、混同してほしくない →
    アイデンティティ情報に対す
    るコントロールが欲しい
    これを支える仕組みとしてVerifiable Credentials Data Model
    がある
    

    View Slide

55. View Slide

56. E
    メールはもともとself-sovereign
    だった
    

    View Slide

57. E
    メールはもともとself-sovereign
    だった
    (
    ただしマッチョに限る)
    

    View Slide

58. E
    メールはもともとself-sovereign
    だった
    SMTP/POP3/IMAP
    はもともとself-sovereign
    なプロトコルだった。自分でサーバーを立
    てる限りは。
    自分でID
    を発行できる
    用途によってID
    を使い分けることができる
    自分のデータは自分で持つことができる
    

    View Slide

59. E
    メールはもともとself-sovereign
    だった
    最近は誰もそんなことはしない。
    SMTP:
    適切に認証をするのが難しい。設定を1
    個でも間違えるとspam
    の踏み台
    IMAP:
    マルチデバイスアクセスなら必須だがストレージ管理が地獄
    結果、本来self-sovereign
    であるはずのプロトコルなのだが、中央集権化を許してしま
    った
    

    View Slide

60. E
    メールの中央集権化の加速
    中央集権的E
    メールプロバイダ(Gmail, Microsoft Live, ...)
    のspam
    フィルタの動作は十分
    な透明性がなく、悪意のないメールですらspam
    フィルタに飲まれてしまう。
    中央集権的E
    メールプロバイダを利用していないメールはspam
    フィルタを信用させる
    ことが難しくなり、より中央集権化が進む
    （メール認証が十分に行き渡っていないこと、まただいぶhacky
    な方法しかないことも
    挙げられるが…
    ）
    

    View Slide

61. Principles of User Sovereignty / Fundamental
    Problems of Distributed Systems @ IIW30
    「分散システムの抱える根本的な問題を解決できないとき、それは企業による中央集
    権化(corporate capture)
    を自ら許してしまう」
    E
    メールはまさにこの最たる例ではないか？
    

    View Slide

62. Fundamental Problems of Distributed Systems
    例:
    ノードのディスカバリー
    ノードがネットワークに参加する際のセッションの確立 (introduction)
    プライバシー (
    識別子による長期的な関連付けの防止)
    トラスト
    これらの問題を十分に解決できなかったので企業がマネタイズの機会を見出し中央集
    権化してしまった。
    

    View Slide

63. The Internet
    の強みは 自律分散性 ではなかったのか？
    

    View Slide

64. View Slide

65. 第4
    部:
    どうやってSMTP
    をやめる？
    

    View Slide

66. 「SMTP
    をやめろ」というとよく言われる話：
    「要するにそれ、Better PGP
    でしょ？」
    「PGP
    が失敗したのって知ってる？」
    

    View Slide

67. 知ってる。
    

    View Slide

68. 我々は既にBetter PGP
    を持っている
    ... LINE, WhatsApp, Telegram, Signal, Keybase (,
    Facebook Messenger)
    っていうんですけど
    

    View Slide

69. 我々は既にBetter PGP
    を持っている
    セキュアメッセージングアプリはPGP
    のユーザビリティの問題を解決している
    暗号化は透過的に行われる
    なんなら暗号鍵のライフサイクルすら面倒を見てくれる
    暗号鍵の選択 =
    複数アカウントの使い分け
    一部のものはグループメッセージングすら可能
    それが単にSMTP
    という形をとっていないだけ
    

    View Slide

70. SMTP
    でも1
    対1
    の暗号化は割と解決している
    SMTP
    では1
    対多の暗号化が難しい
    

    View Slide

71. 1
    対多のユースケース
    メーリングリスト、通知の購読
    An Abuse-Resistant Messaging Protocol by Jim Fenton
    通知に特化した、オプトイン限定かつ送信先が認証されているメッセージン
    グプロトコルのサブセットの提案(Notif)
    グループでのメッセージのやりとり
    1
    対多でやりとりする形よりも、ルームを作ってそこにjoin
    するグループチャ
    ットのアプローチを採用すればよいのでは？
    mass marketing
    これは仕方ないので暗号化されてない世界でやってもらうしかないし、たい
    ていspam
    なのでブロックされても仕方ないのでは？
    

    View Slide

72. DIDComm
    Aries RFC 0005: DID Communication
    で説明されている、Distributed Identifiers
    をもっ
    て識別されるDID Agent
    同士のコミュニケーションメカニズム。
    DIDComm
    はtransport-agnostic
    なコミュニケーションのアーキテクチャを示しているも
    のと考えるのがよく、各トランスポートにおける通信方法はAries RFC 0025:
    DIDComm Transports
    で書かれている。
    相手をどのように発見するか、相手とどのように関係を持つかはDID Core
    の仕様に基
    づいている。
    既にいくつかの実装例がある。
    

    View Slide

73. DIDComm
    …
    とはいえ、DID
    が"purely self-sovereign"
    であるかというと必ずしもそうではない。
    自分自身でID
    を名乗ることができる、という意味ではself-sovereign
    だが
    相手に見つけてもらう必要がある
    globally discoverable
    であるためには名前が必要
    DNS
    、DNS
    に紐づくlookup service
    public blockchain
    にID
    を名乗るとしてもどのchain
    を信用するか問題
    見つけてもらってもオフラインだったらメッセージを保管する場所が必要
    self-sovereign(
    ただしマッチョに限る)
    であれば中央集権化への道が開かれて
    しまう
    

    View Slide

74. Verifiable Credential
    を用いたE
    メール
    各トランザクション（E
    メールのやりとり）で異なるアイデンティティ表現を使うに
    は？ →
    特定のアイデンティティ表現に対応するVerifiable Credential
    を使えばよいので
    は？
    spam
    フィルタはE
    メールに関連づいたVC
    の正当性・信頼度を判定する。より
    accountable
    なID
    にたどり着けるVC
    のほうが高い信頼性とする。
    よく考えたらただのbetter digital signature
    かもしれないが…
    

    View Slide

75. Data at Rest
    の暗号化
    JSON Web Message (JWM)
    が有望なのでは…
    と思ったらExpire
    してしまっていた。
    暗号化して保存でき、相互運用可能なフォーマットがあるといいですね…
    

    View Slide

76. View Slide

77. まとめ
    

    View Slide

78. まとめ
    E
    メールには暗号化がない
    E
    メールをデジタルアイデンティティの核とし続けるのは怖い
    E
    メールにはまともなidentity layer
    がない
    identity layer
    の構築をE
    メールプロバイダに任せるとself-sovereign
    でなくなる
    どうやって解決する？
    セキュアメッセージングのinteroperability
    DID
    を使ったidentity layer
    を作る
    

    View Slide

79. やめよう、SMTP
    

    View Slide

80. Questions/Comments?
    

    View Slide