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

by sylph01

Slide 1

Slide 1 text

Email, Messaging, and Self-Sovereign Identity Ryo Kajiwara @ WIDE Meeting, 2021/05/28

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

TL;DR

Slide 6

Slide 6 text

SMTP をやめろ

Slide 7

Slide 7 text

どうやってやめる？

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

もうちょっと真面目にやせいのプログラマ 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 をやっています

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

E メールには identity layer がない

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

じゃあ暗号化諦める？

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

グループチャットの鍵共有は難しい 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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Messaging Layer Security

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

第3 部: Self-Sovereign Identity

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

知ってる。

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

まとめ

Slide 78

Slide 78 text

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