分散型アイデンティファイアー (DIDs: Decentralized Identifiers)（中編）
【概要】分散型アイデンティファイアー（前編）ではW3C勧告のDecentralized Identifiers (DIDs) Core Specification v1.0が定める分散型アイデンティファイアー(DIDs: Decentralized Identifiers)の4つの要件、およびそのようなアイデンティファイアーを利用することのメリットと自己主権型アイデンティティ実現のためのToIPスタックの４レイヤーにおけるDIDの役割について説明しました。(中編)ではそのような特徴を持つDIDを実現するための技術的課題と解決方法について詳しく見ていきたいと思います。
************** 目次 ****************
【6】DIDと公開鍵暗号方式
【7】バインディング問題はPKIの潜在的難問
【8】バインディング問題の従来の解決方法
【9】分散型PKI (DPKI: Decentralized Public Key Infrastructure)
*************************************
【6】DIDと公開鍵暗号方式
DIDを使ってセキュアにコミュニケーションするためには公開鍵暗号方式を利用します。下の図では、アリスが自分のDID did:example:123 と対応する公開鍵Xを公開しています。did:example:123 からのメッセージは秘密鍵Xで署名されており、これを受け取ったボブは公開鍵Xで検証します。署名を認証できれば、それを送ったのは秘密鍵Xの持ち主(コントローラ)であることが確認できます。またボブからアリスへのメッセージを公開鍵Xで暗号化すれば複合できるのは秘密鍵を持つアリスだけになります。
一見問題なさそうですが、このシナリオが成り立つためには、次の３つの結び付き(バインディング)を確認できることが前提となります。
① 秘密鍵Xの持ち主アリスとDID did:example:123
② DID did:example:123と公開鍵X
③ 公開鍵Xと秘密鍵X
バインディング③は公開鍵暗号方式そもそもの性質により署名を公開鍵で認証することで確認できますが、①、②は簡単でありません。これが確認できないと攻撃者は did:example:123 のコントローラになりすまし、偽の秘密鍵Y、公開鍵Yで署名することで、メッセージの受信者を欺くことが出来てしまいます。下の図では、攻撃者はボブに対して「私はアリスです。前回と同じ私のDID did:example:123からメッセージを送ります。署名をしますので別送した公開鍵Yで認証して下さい」と言ってアリスになりすましています。鍵はセキュリティ上変更されることがあるため、前回と違ってもボブは疑わずアリスからのメッセージと信じてしまいます。ここでメッセージの送信元が did:example:123 だからと言ってアリスが送り主である保証はありません。有名なECサイトの送信アドレスから送られてきたEメールも実は攻撃者からのフィッシング詐欺メールかも知れませんので注意が必要です。
【7】バインディング問題はPKIの潜在的難問
バインディング問題はそもそも公開鍵基盤(PKI: Public Key Infrastructure)の潜在的難問として認識されていました。公開鍵・秘密鍵の持ち主であるコントローラが公開鍵を公開し、秘密鍵を使った電子署名によりセキュアにメッセージを送る場合、メッセージの受信者はその公開鍵が本当にコントローラの公開鍵なのか確認できる必要があり、それが非常に難しいのです。つまり①’コントローラと公開鍵、②’公開鍵と秘密鍵、のバインディングを受信者が確認できなければPKIは成立せず、②’は暗号学的に証明できても①’の証明が困難なのです。
①’コントローラと公開鍵
②’公開鍵と秘密鍵
更にコントローラは現実世界の人や組織なのでインターネット上で直接確認できないため、コントローラを指す識別子、つまりアイデンティファイアーを介在させる必要があり、そうするとこの問題は以下の３つのバインディングをメッセージの受信者が確認できなければならないことになります。難しいのは①、②のバインディングの確認になります。
① コントローラとアイデンティファイアー
② アイデンティファイアーと公開鍵
③ 公開鍵と秘密鍵
【8】バインディング問題の従来の解決方法
バインディング問題はこれまでは認証局などの信頼出来る第三者(TTP: Trusted Third Party)が発行する証明書によって解決されてきました。
まず①コントローラとアイデンティファイアーのバインディングについては、コントローラの既存のアイデンティファイアーからグローバルにユニークな（唯一無二）ものを選びます。URL(Uniform Resource Locator)がおなじみですが、X.500 DN (Distinguished Name)などもよく使われます。URLはインターネット上のリソースの場所を識別するのでブラウザーでアクセスして成功すれば真正性が確認できるのでは？と思われるかも知れませんが、例えばDNSポイズニングによってネームサーバーのキャッシュが改竄され、偽のサーバーのIPアドレスに誘導されることもあります。やはり公開鍵暗号方式により本物のサーバーであることの証明が別途必要です。
②アイデンティファイアーと公開鍵のバインディングは、認証局が発行する公開鍵証明書によって確認できます。これはアイデンティファイアーと公開鍵を含んだファイルを認証局の秘密鍵で署名したものです。認証局は、コントローラ、アイデンティファイアー、公開鍵の結び付きを決められた人的手続きに従って審査し、証明書を発行します。信用できる第三者である認証局とその審査手続きに頼ることで、アイデンティファイアーと公開鍵のバインディングが証明されます。
TTPによるバインディング問題の解決はHTTPSやTLS/SSLなどに応用され、現在のインターネット社会を支えるセキュリティ基盤となっています。しかしTTPの介在は人的サービスへの依存を意味し、高コスト、非効率、人的ミスの原因になります。またコントローラーのアイデンティティ情報がTTPに集中するのも問題視されています。アイデンティファイアーの対象が企業やそのWebサイトなど比較的大きなものであればコストや運用負担はある程度吸収できますが、個人や大量のIoTデバイスがアイデンティファイアーを持ってセキュアなコミュニケーションを行いたい場合、TTPを必要としない、もっと軽量で低コストのバインディングが必要になります。
【9】分散型PKI (DPKI: Decentralized Public Key Infrastructure)
バインディング問題の①、②を中央集権的な機関や信頼出来る第三者に依存せずにどうしたら解決できるのか、これから詳しく見ていきたいと思います。これは1970年代に公開鍵暗号方式によるPKIが考案されて以来多くの研究者、開発者を悩ましてきた難問なので答を見る前に自分ならどう解決するか、パズルに挑戦してみると良いです。
① コントローラとアイデンティファイアー
② アイデンティファイアーと公開鍵
③ 公開鍵と秘密鍵
まず①ですが、唯一無二で未来永劫他者に再割当てがされないURN (Uniform Resource Name)を中央集権的な管理機関なしにコントローラに割当てる問題です。前述の従来型PKIで例として挙げたURLやDNは識別子の重複が起こらないように管理している中央集権的機関が存在しました。しかもURLはドメイン名の再割当てがあるためURI(Uniform Resource Identifier)ではありますが、URNではありません。私たちが良く知る電話番号、住所、パスポート番号などのURIは全て中央集権的な管理機関が存在します。管理機関の存在しないアイデンティファイアーの代表例は氏名ですが、同姓同名の鈴木一郎さんが何人もいらっしゃるように重複が発生してしまいます。
URNは生成のアルゴリズムを標準化することで管理機関が不要になります。一つ例を挙げて説明します。次のようなアルゴリズムでURNを作ってみてください。
1. 自分の居る場所の緯度経度を(LNG, LAT)とする。
例：LNG=35.5871703、LAT=139.5907809
2. 今の世界標準時をGMTとする。例：GMT=20221008023015
3. 文字列LNG:LAT:GMTを作成する。
例：35.5871703:139.5907809:20221008023015
この結果生成された35.5871703:139.5907809:20221008023015はURNになります。なぜなら同時に２つのコントローラが同じ場所に存在することは不可能だからです。しかもこのアイデンティファイアーは将来に渡って他者に再割当てされることもありません。この記事の読者の皆さんが世界のどこにおられようと上記の方法で作成した文字列は世界で唯一無二なURNになります。
この方法は、全員が同じアルゴリズムでURNを生成するところが大切です。DIDも、アルゴリズムの内容は上記の方法と異なりますが、アルゴリズムを標準化することで管理機関なしでURNを生成できるようになっています。DIDではこのアルゴリズムはDIDメソッドで仕様が決められます。そしてどのアルゴリズムでDIDを生成したかを明確にするため、DIDの始まりはdid:{DID Method}:となっています。
次に②アイデンティファイアーと公開鍵のバインディングですが、DIDはコロンブスの卵的な発想の転換でTTPなしでこの問題を解決しています。DID以前のPKI研究者たちは既存のアイデンティファイアーに公開鍵をバインディングする方法を模索してきました。しかしDIDでは逆の発想で、公開鍵からアイデンティファイアーを生成することでこの難問を解決したのです。
下の図でアリスは先ず公開鍵・秘密鍵を生成し、その公開鍵からDIDを生成しています。その生成方法は、did:example が定めたDIDメソッドによります。この例ではDIDメソッドの演算結果は123（実際のDIDではもっと長くなります）で、それをdid:example:の後に続けてdid:example:123としています。つまりDID固有のアイデンティファイアーが123、そのネームスペースがdid:example:になっています。
この方法によれば、DIDと公開鍵が結び付いていることはdid:exampleのDIDメソッドが定めるアルゴリズムを使って誰でも検証できます。もはやTTPに頼る必要はありません。更にDIDとアリスの結び付きも公開鍵に対応する秘密鍵の持ち主はアリスしかいませんので自動的に証明されます。つまり中央集権的な管理機関無しにURNが割り振られ、信用出来る第三者(TTP)に依存せずにURNと公開鍵のバインディングが証明できたことになります。
以上、分散型アイデンティファイアー(DIDs)を実現するための技術的課題と解決方法について説明しました。次回はHyperledger Indyを例にDID生成の具体例を見ることで更に理解を深め、併せてDID普及の課題についても考えたいと思います。
最後までお読み頂きありがとうございます。記事へのご意見やご質問などがございましたらお気軽に下記までご連絡ください。
info@kaula-lab.com
カウラ株式会社HP: kaula.jp
（カウラ株式会社はEnterprise Ethereum Allianceの会員企業です。）
関連記事
· Web3.0におけるアイデンティティレイヤー（前編）https://medium.com/kaula-lab/web3-0-identity-layer-89494f479c14
· Web3.0におけるアイデンティティレイヤー（後編）https://medium.com/kaula-lab/web3-0-identity-layer-2-4632344ec069
· 分散型アイデンティファイヤー (DIDs: Decentralized Identifiers)（前編）
https://medium.com/kaula-lab/%E8%A8%98%E4%BA%8B%EF%BC%93-%E5%88%86%E6%95%A3%E5%9E%8B%E3%82%A2%E3%82%A4%E3%83%87%E3%83%B3%E3%83%86%E3%82%A3%E3%83%95%E3%82%A1%E3%82%A4%E3%83%A4%E3%83%BC-dids-decentralized-identifiers-%E5%89%8D%E7%B7%A8-9f4f6421bd01
