こんにちは。CTO室長の浅野@masakz5です。
インターネットの世界で「電子証明書」という場合、一般的にはx.509規格の電子証明書(Digital Certificate)のことを指すと思われているのではないでしょうか。
しかし、何度かこのブログの記事の中で取り上げているSSI – Self Sovereign Identityの世界でのVerifiable Credential(以下VC)も、日本語では「証明書」と表現されることがあります。
今回の記事では、両者にどのような違いがあるのかを説明していきたいと思います。
x.509証明書の信頼性
x.509証明書（電子証明書）の主な目的は、「公開鍵（と対になっている秘密鍵）の持ち主を証明する」ことです。ネットの向こう側にいる相手が、その公開鍵と対になる秘密鍵を持っていることを暗号的に検証することで、その相手が証明書の持ち主(Subject)であることが確認でき、証明書に記載された情報によって自分の意図した相手かどうかが判断できる、という形です。 *1
では、その証明書が「信頼できる」ものであるかどうかはどのように判断すれば良いのでしょうか。
証明書の発行者である認証局は、証明書の中に公開鍵の情報とその持ち主の情報をセットした上で電子署名を施して証明書を発行します。
証明書を受け取った側は、その電子署名を検証することで、証明書の内容が改竄されていないことと、その認証局によって確かに発行されたことを確認できる – つまりその認証局が「信頼できる」のであれば、証明書に書かれている公開鍵とその持ち主の情報は信頼できる、ということになります。
通常、認証局は図のような階層構造をとっており、認証局に対してその上位の認証局が電子証明書を発行するような形をとっています。上位の認証局を信頼することで下位の認証局が信用できる、というモデルになっているわけです（これをTrust Chain=信頼チェインと呼んだりします）。
認証局の階層構造
この最上位に位置する認証局を一般的に「ルート認証局」と呼びます。この認証局はさらに上位に認証局を持たないため、自己の公開鍵情報に対して自分自身で証明書を発行します（これを「自己署名証明書」と言います）。
さて、このような形で自分が手に入れた証明書が信頼できるものであるか否かは認証局が信頼できるか否かにより、その認証局の証明書が信頼できるかどうかはさらに上位の認証局が信頼できるか否かにより・・・結局は最上位のルート認証局が信頼できるかどうかにかかるわけですが、その信頼性はどうやって担保されるのでしょうか。
PrivateルートとPublicルート
一般的にパブリックなWebサイトにおけるTLSやコードサイン、PDF署名、S/MIME等で使用される証明書は”Publicな”証明書と呼ばれています。これはWebサーバやブラウザ、メーラなどの一般的なアプリケーションが「信頼できるルート認証局」のリスト（トラストリスト）を持つことで、ユーザが明示的に信頼するかどうかの判断を行わなくて良いというものです。この、一般的なアプリケーションのトラストリストに掲載されているルート認証局を「Publicルート」と呼びます。当然「信頼できるルート認証局」としてリストに掲載されるためには、厳密な基準（CAB ForumのBaseline RequirementsやWebTrust監査基準）を満たす必要があるのですが、１つのルート認証局がさまざまなアプリケーションのトラストリストに載ることで、配下の証明書の相互運用性が高まり、よりオープンな環境での利用が可能になります。
実はもう１つ、Privateルートと呼ばれるものも存在します。これはクローズドな環境（例えば社内のみ）で信頼関係が構築できれば良い、という際に利用されるもので、ルート認証局の証明書を「信頼できる手段」（たとえば信頼できる社内ネットワーク等）で利用者に配布し、アプリケーションに「信頼できるルート認証局」として明示的（暗黙的な場合もありますが）に設定するものです。クローズドなコミュニティでの信頼関係であればとくに”Public”である必要はない、という考え方ですね。
長くなりましたのでここ今までのでポイントを整理しましょう。
- x.509証明書は公開鍵とその持ち主（Subject)を証明するもの
- 公開鍵その他の証明書に記載されている情報の非改竄性は、発行者である認証局の電子署名によって担保される。
- 証明書の信頼性は認証局の信頼性に依存し、最終的にはルート認証局の信頼性に依存する
- ルート認証局の信頼性を担保する方式としてオープンな信頼関係のための「Publicルート」とクローズドな信頼関係のための「Privateルート」が存在する。
VCの信頼性
W3CのDID/VCのデータモデルの定義では、特に相手を認証する手段をPKI(公開鍵暗号方式)に限定しているわけではありませんが、事実上この形がスタンダードになると思いますし、そもそもx.509との比較という意味でこのモデルを例にお話しするのが適切かと思いますので、その前提で説明をしたいと思います。
まず、SSI/DID/VCの世界では、Subject(主体)は全てDIDで表されます。そして、Subjectと公開鍵の紐付けはDIDドキュメントによって行われます。(DIDやDIDドキュメントについては【記事】 Self Sovereign Identity (SSI)の現在地をご参照ください。)
x.509証明書の場合、証明書に記載されたSubjectと公開鍵の情報の紐付けは認証局の電子署名によって担保されていますが、DIDドキュメントの場合はその情報が保管されるブロックチェインなどの分散台帳の技術に依存します。「登録された情報が改竄されることがない」という分散台帳の技術によってその非改竄性を担保しているわけですね。
そしてVCそのものについては、”Proof”として発行者の電子署名が施され、 DIDドキュメントによって発行者と紐づけられた公開鍵を使用することによって、x.509証明書と同様に非改竄性やその発行者を検証することができます。
ポイントは公開鍵とその所有者の情報の紐付け（DIDドキュメント）を分散台帳技術によって保証することで、ルート認証局のような「中央集権的な」機関を不要にしているところです。
「証明書の位置づけ」が違う
もう１つの大きな相違点は証明書としての位置づけではないでしょうか。
一般的にはPublicなx.509証明書は、それ自体がPublicなもの、つまり秘密情報ではない、と考えられています。これはTLSやS/MIMEの仕組みの中で証明書が暗黙的にやりとりされることが多く、持ち主がその流通をコントロールできないことに依存します。ですので、原則的にはPublicな証明書に個人情報などの流通しては困る情報は記載しません。証明書にそのような機微な情報を紐づける必要がある場合は、証明書を使用した認証・認可のプロセスを経て、データベースに格納している情報を取り出す、等のプロセスが必要になります。
一方のVCは、その流通を持ち主がコントロールすることを前提にしています。ゼロ知識証明を使用することで、例えばVCに記載された生年月日の情報を元にして、検証者には持ち主が20歳以上かどうかだけを情報として提示する、ということも可能です。
基本的にはVCがあれば検証者が必要な情報を取得することができる、というモデルが構築できるため、中央集権的なデータベースを持つ必要が（少なくとも理論上は）ありません。
これによってシングルポイントに対する攻撃への耐性が高くなることが「分散」のメリットである、とSSIを支持する人々は主張しています。
信頼の「委任」
x.509のPublicな証明書のモデルは、証明書を信用できるかどうかは認証局の信頼性に依拠し、認証局の信頼性がブラウザやメーラなどのアプリケーションに依拠している、というモデルだと言えると思います。証明書の検証者は自分でその証明書の発行者が信頼できるかどうかを判断する必要はなく、より上位の認証局やそれを信頼しているアプリケーションにその判断を「委任している」ということができるでしょう。
信頼の委任モデル
このモデルはWEBサーバの運用者とそこに接続する人々のような、多対多のオープンなコミュニケーションの場合非常に有効に機能します。一方で、信頼の委託先であるアプリケーションや認証局に問題があれば、非常に多くの利用者が影響を受けることになります。CABForumでのアプリケーションベンダーと認証局事業者の信頼性確保のための取り組みは、まさにここを担保するものと言えるでしょう。
SSIを支持する人の中には、これこそが中央集権的な信頼構造の脆弱なポイントであるという人々もいます。
上記で述べたように、SSIの世界はx.509のPrivateな証明書の考え方に近く、証明書(VC)の検証者は、発行者が信頼できるかどうかを明示的に判断します。これも自己主権=Self Sovereignの一端であるという考え方だと思います。
直接的な信頼モデル
ただ、現実の実装を考えたときにはある程度の「委任」は発生するのだろうと私は考えています。
たとえば以前の記事でも取り上げたIATAによるトラベルパスのようなワクチン証明書のケースを考えてみましょう。VCの発行者として想定されるのは保健所や医療機関、地方自治体のようなワクチン接種についての記録を持つ機関になるでしょう。
IATAの場合検証者になるのは航空会社のカウンターや入国管理局だと思われます。
そうすると、現実的に検証者がそれぞれの発行者（と発行者のDID）を明示的に信頼する、ということは難しいでしょう。検証者用のアプリケーションがあらかじめ信頼できる発行者のDIDのリストを持つ（＝アプリケーションに発行者への信頼を委任する）か、IATAがそれらの機関の代わりにVCを発行する（=IATAに発行者への信頼を委任する）かのどちらかになるはずです。x.509証明書のPublic証明書よりは規模が小さいものの、こういった「委任」の形というのは少なからず実装されるのではないでしょうか。
ではここまでのポイントを整理してみましょう。
- SSI/DID/VCの世界では公開鍵とその持ち主の紐付けはDIDドキュメントで行われる
- VCの非改竄性は発行者の電子署名(等)によって担保される
- VCは持ち主(主体者)がその流通をコントロールする
- Publicなx.509証明書に対する信頼は、それを認証局やアプリケーションに「委任」することで成り立つが、VCについてはより直接的な信頼関係の構築が必要。しかしながら実装上は多少の「委任」関係が発生すると思われる
最後に
その他にも、証明書のステータスの開示方法など、いろいろな違いがあります。
そもそも用途が異なる上に歴史も全く違うものなので単純に比較するべきものでもないと思いますが、両者を比較することでより一層それぞれの特徴が浮き彫りになるのではないかと思い、この記事を描いてみました。
皆さんの理解の一助になれば幸いです。
*1 実際にはTLSであればブラウザが、アクセスしているサイトのFQDNと証明書中のFQDNの一致をチェックし、S/MIMEであればメーラが相手のメールアドレスと証明書中のメールアドレスをチェックする、といったようにシステム的に確認が行われるケースが多いです。
