検証可能な証明書(VC)を使ってみた - fltech - 富士通研究所の技術ブログ

はじめに

こんにちはデータ&セキュリティ研の加嶋です。エンジニアから研究所に転職して 1 年ちょっと経ちました。転職とは言っても、社内の転属です。前職は長く製品やサービスの開発職をやっていたのですが、もっと最先端の技術に触れていたいと思って異動しました。

そして今は希望した通り、まだまだ普及しないような、でも普及したら便利だろうなぁという技術を触って、どうやったら面白く普及させられるだろうかな、と頭を悩ませています。

さて今回は、そうした経緯で仕事として触れるようになった技術のひとつ、検証可能な資格情報 (Verifiable Credentials 略して VC) について、実際に触りながら、どのように役立てればよいかを考えてみたいと思います。

1. VC とは

検証可能な資格情報 (VC) とは、身分証明書や卒業証明書などの紙やプラスチックの証明書と同じように、個人が持っている属性を証明するものです。ただし既存の証明書そのものではなく、属性をデジタル化して、オンラインで検証できるようにしたものです。さまざまなサービスで身分証明などが必要な時に、すぐ使えるようにと標準化されています。

現在さまざまなサービスで個人情報を利用するときに、大手のサービス事業者に登録しておいた個人情報を利用して、かんたん入力で済ませるサービスが普及してきています。どこかのサイトにログインするとき、Facebook ID でログインしたり Google ID でログインしたり、というのは、よくやりますね。もちろん、これらの企業では安全にサービスを維持できるよう努力を重ねており、ユーザーは気軽に個人情報を預けて利用できるようになっています。しかし個人情報は取り扱いが非常にデリケートな情報であり、管理するサービスを維持するには多くの努力とコストが必要であるため、体力のある企業でないとサービスが維持できず、結果として数社による寡占が進んでいます。また、ユーザーの意図しない用途で第三者が個人情報を利用しているんじゃないか、あるいは法や企業のポリシーによって突然アクセスできなくなったりするんじゃないか、などの懸念が生じています。

近年、これらの問題を克服するために、自己主権型アイデンティティ - Self-Sovereign Identity (SSI) という概念が提唱されています。これは、ユーザーの個人情報やアイデンティティなどを管理するにあたって、他人や企業に管理を依存することなく、ユーザーが自分で管理して利用をコントロールできることを目指す考えかたです。検証可能な資格情報 (VC) は SSI を実現するための標準化のひとつであり、資格情報を提示したり検証したりするための枠組みを提唱しています。この枠組みが普及することによって、多くのサービスが共通的な基盤のうえで多種多様な資格を提示してもらい、検証できるようになります。

検証可能な資格情報 (VC) を取り扱うとき、以下の役割のヒトやモノが登場します。

登場する役割の相関図
(https://www.w3.org/TR/vc-data-model/#ecosystem-overview より引用)

Issuer: VC を作成して署名する、VC 発行者という役割です。たとえば行政府や業界団体、企業、個人などがこの役割になります。 Issuer が信頼できることが、VC を使ったシステムの前提になります。
Subject: VC の対象の、ヒトあるいはモノです。 VC には、Subject が持っている属性について記載があります。その記載内容について Issuer が署名を加えて内容を保証しています。
Holder: VC を管理する役割です。多くの場合には VC を発行してもらったヒト (Subject) そのものですが、場合によっては子供 (Subject) の保護者であったり、モノ (Subject) の所有者の場合もあります。 VC を Verifier に提示するときには、Subject が安心して提示できるように、 VC の一部に目隠しなどの加工を施したり、いくつかの VC をまとめたりして、提示に適した Verifiable Presentation (VP) を仕立てる、という役割もあります。
Verifier: Holder から VP を提示してもらい、その内容を検証する役割です。 VP 内の各 VC の Issuer が信用できるのであれば、そして各 VC の署名が有効であれば、その内容はきちんと確認されているものと判断します。たとえば入館などのセキュリティ担当者や、アクセス制御する Web サイトなどがこの役割になります。

就職活動を例にとって説明しましょう。学生 (Holder) は大学 (Issuer) から成績証明書 (VC) を発行してもらい、就職したい企業 (Verifier) むけに成績証明書 (VC を加工した VP) を提示します。 VP を提示された企業はこの VP を見て、学生 (Subject) の成績と出身校 (Issuer) を確認することができます。 VP の内容は、大学 (Issuer) が発行した内容であると数学的に証明されており、詐称されていない情報として信用できるので、雇用するかどうかの判断材料になります。本当に正しい情報かどうか、大学に問い合わせて確認する必要はありません。

2. Azure Active Directory の検証可能な資格情報を使ってみた

いま世の中にある検証可能な資格情報 (VC) の実装には、以下のものがあります。

Hyperledger [Indy](https://www.hyperledger.org/use/hyperledger-indy), [Aries](https://www.hyperledger.org/use/aries), [Ursa](https://www.hyperledger.org/use/ursa): Linux Foundation が運営する Hyperledger プロジェクトの中の機能群です。 Hyperledger Indy が提供するブロックチェーンは分散 ID (DID) や、その ID に対する公開鍵を管理しています。 Hyperledger Aries は、VC の作成、送信や保存などを行なうためのツールキットです。そして VC の発行や検証などで行なわれる暗号処理には、 Hypergedger Ursa パッケージが提供する暗号処理機能が使われています。
[Azure Active Directory の検証可能な資格情報 (プレビュー)](https://docs.microsoft.com/ja-jp/azure/active-directory/verifiable-credentials/decentralized-identifier-overview): Microsoft が運営する Azure Active Directory (AD) の中で提供されているサービスです。2022年2月時点では、プレビューという状態になっており、 Azure AD の開発者アカウントを使って試用できます。
[mattr](https://mattr.global/): mattr 社は、W3C の DID Working Group や Decentralized Identity Foundation (DIF) といった標準化団体で活躍している、ニュージーランドの会社であり、主にデジタルトラストに関する製品やサービスを提供しています。 VC に関しては、 VC作成、取得、削除、検証を行なうためのサービスプラットフォームやツール群を提供しています。

私達はまず、Azure の検証可能な資格情報（プレビュー）を利用して、 VC に触れてみることにしました。なお、ちょっと名前が長いので、以降の章ではこのサービスのことを Azure VC と呼ぶことにします。

2.1. Azure VC でどんなことができるようになるのか

下記の画面は、スマートフォンアプリ Microsoft Authenticator にインストールした氏名を証明する VC の画面です。 Azure のチュートリアルから、「検証可能な資格情報サービスを設定する」および「検証可能な資格情報を発行する」に沿って作成しました。 VC は Microsoft Authenticator で管理できるようになっており、適切な Issuer に発行してもらった VC を取得して保管したり、 VP に変換して適切な Verifier に提示することができるようになっています。

Azure のチュートリアルに沿った手続きにより得られた VC の表示画面
(Android スマートフォンからキャプチャ)

下記の画面は、チュートリアルの後続の章「検証可能な資格情報を検証する」に沿って作成した、Verifier の Web サイトの一例です。 VP の提示を求める Verifier は、Web サイトにこのような QR コードを表示しておきます。 VC を持った Holder が Microsoft Authenticator でこの QR コードをスキャンすると、 Microsoft Authenticator は自分の VC を Verifier に見せてよいか、スマートフォンの持ち主に確認を取ったうえで、VC から VP を作成して Verifier に渡します。

Azure のチュートリアルに沿った手続きで作成された Verifier の Web 画面
(ブラウザからキャプチャ)

Azure VC ではこの例のように氏名を証明するだけでなく、通常の証明書のように氏名、生年月日、免許の条件や種類などどいったさまざまな属性の集合をまとめて証明することができます。あらかじめ Azure ポータルに設定ファイルを登録しておくことで、免許証や卒業証明書など、用途に合った証明書を発行・検証できるようになっています。

この機能を試すには、Microsoft Authenticator を動かせる Android あるいは iOS のモバイルデバイスと、Azure Active Directory の開発者テナントが必要です。開発者テナントは、ドキュメントに記載された「開発者アカウントを作成する方法」に沿って作成できますので、この機会にぜひ作ってしまいましょう。

2.2. 使ってみよう

前章の方法で Azure Active Directory 開発者テナントを作成したら、チュートリアルに沿ってテナントに設定を加えていきます。

Azure Active Directory の中では、以下のクラウドサービスを利用します。

Azure VC (プレビュー): この記事で紹介する Azure のサービス
[Azure Key Vault](https://docs.microsoft.com/ja-jp/azure/key-vault/general/overview): シークレットとキーを安全に保管しアクセスできるようにするサービス
[Azure Blob Storage](https://docs.microsoft.com/ja-jp/azure/storage/blobs/storage-blobs-introduction): 検証可能な資格情報サービスの構成ファイルを格納するサービス

具体的にはチュートリアルから、「検証可能な資格情報サービスを設定する」と「検証可能な資格情報を発行する」の2つの章を実行することで、 VC を発行させて Microsoft Authenticator に取得できるようになります。そしてその次の「検証可能な資格情報を検証する」の章によって、取得した VC を Microsoft Authenticator から Verifier に提示できるようになります。

これらのチュートリアルでは .NET 版のチュートリアルアプリを使って説明されていますが、私達は Node.js 版のチュートリアルアプリを利用しました。起動のためのコマンド群は、アプリの中に書いてある説明の通りにすれば問題なく Microsoft Authenticator に VC を登録できるようになっていました。

しかしここで、ひとつおかしな点を見つけてしまいました。発行された VC には firstName が "FIRSTNAME"、lastName が "LASTNAME" という氏名が載っていたのですが、私は "LASTNAME FIRSTNAME" 氏ではありません。この FIRSTNAME、LASTNAME って、何者なのでしょう。

どこで設定された値なのか調べてみると、チュートリアルアプリの中のファイル 1-node-api-idtokenhint/issuance_request_config.json に書かれた値がそのまま使われたらしいことが分かりました。つまりここを書き換えてアプリを再起動すれば、 VC に適切な属性値を載せることができるようになります。

アプリの設定ファイルを毎回書き換えなきゃいけないなんて、プレビュー機能だから仕方ないのかな、と一度は思ったのですが、チュートリアルを読み進めたところ、そこはちゃんと運用設計できるように考えてあるようです。「資格情報をカスタマイズする方法」の章によれば、固定値以外にも OpenID Connect の id token, 他の VC, Microsoft Authenticator でユーザー自身が書く、という 3 種類の方法で、ちゃんとしたデータを記載できるようになっているそうです。私達はまだ試せていませんが、時間を見つけて試してみたいものです。

2.3. 問題発生！自宅じゃ通知を受けられない

さて、ひととおりチュートリアルに沿って進めていけば体験できるのですが、ひとつ困った問題がありました。

Azure VC のサービスは、ユーザーが VC を取得したことを Issuer に通知したり、ユーザーが提示した VP を Verifier に伝達したりするために、 Issuer や Verifier に対して HTTP POST を送信します。

Issuer や Verifier となるアプリは、Azure からのこの HTTP POST を受信するために、 Web サービスをインターネット公開する必要があるのです。 Web サービスをインターネット公開するには、しっかりとしたセキュリティー対策が必要です。公開せずに済むならそれに越したことはありません。

チュートリアルの中では、チュートリアルアプリを一時的にインターネット公開するために ngrok を使用しました。 ngrok は一時的に利用するには、とても便利なサービスです。チュートリアルを試しているほんの一瞬だけ一時的な URL で公開するぶんには、それほど危険はないかもしれません。

しかし、一時的な公開と常時公開では、リスクの大きさがまったく違います。自分用の証明書サービスを作成したときを想像すると、これを自宅やオフィスで常時稼動させて、必要なときすぐに使えるようにしておきたくなるものですが、そのために自宅サーバやオフィスのサーバをインターネット公開するのは、とてもリスクが高くて望ましくありません。

そこで、代わりに HTTP POST を受けてくれるサービスはないものか、と探してみたところ、 Azure AD のなかに "Azure Web PubSub" というサービスがありました。読んでみたところ、REST API と WebSocket を使ったメッセージキューのようです。これが良さそうなので、使ってみることにしました。

3. Azure Web PubSub を併用してみた

Azure Web PubSub のドキュメントによると、このサービスは WebSocket とパブリッシュ-サブスクライブパターンを使用して、リアルタイムメッセージング Web アプリケーションを作成するためのサービスとして提供されているようです。

Publish/Subscribe サービスの有名どころとしては、 Apache Kafka や Redis がありますね。この Azure Web PubSub も同じようなものと考えることができます。チュートリアルなどを見る限り、一般的な publish/subscribe サービスのようで、チャットで相手から来るメッセージをリアルタイムで受信したり、サービスからときどき出てくる通知などを受信するのに良さそうです。

メッセージや通知の受信と同じ手法で Azure VC サービスから VP を受信できるなら、自宅サーバをインターネット公開する必要がなくなります。自宅で常時稼動するには、とても良さげなサービスですね。

3.1. Azure Web PubSub の特徴

Azure Web PubSub のドキュメントを読み進めていくと、メッセージを Publish するには、 REST API の Send to All に POST すれば良いようです。前述の VC サービスの通知や VP 送信に使われているのも POST なので、これは相性が良さそうです。また、ちゃんと認証もあって、無作為な POST 攻撃はしっかりと避けることができるので、その点も良いですね。

ローカル PC 上の Issuer や Verifier (サーバーアプリ) は、今までは通知や VP を ngrok 経由で HTTP POST を受信していましたが、これからはその代わりに、Azure Web PubSub に受信しに行くことにします。ざっと眺めてみた感じでは、それほど難しいことでもなさそうで、チュートリアル内の「メッセージの発行とサブスクライブ」の章に記載された JavaScript のサンプルを見る限りとてもシンプルに利用できそうですし、 VC のチュートリアルアプリに取り込むのも難しくなさそうです。

3.2. Azure VC に Azure Web PubSub を組み合わせてみよう

まずはクイックスタートに沿って、Azure Web PubSub のインスタンスをひとつ作ります。そうすると、このインスタンスにホスト名が割り当てられます。割り当てられたホスト名は、Azure Web PubSub ポータル画面で確認することができます。

次に、Azure VC に POST してもらうための URL を作ります。 REST API 解説ページの Send to All を見ると、URL の作りかたが分かります。 URL は POST {Endpoint}/api/hubs/{hub}/:send と説明されており、その中の {Endpoint} は "https://ホスト名" になります。さきほどクイックスタートで作成したホスト名が、ここで使われます。そしてもうひとつ、他のパラメーターとして {hub} があります。これは例えて言えば住所のようなもので、送り手と受け手が同じ {hub} 文字列を使えば、送り手から受け手にデータが届きますし、複数の送り手～受け手ペアがそれぞれ別の {hub} 文字列を使うようにすれば、ひとつの Azure Web PubSub サービスを共有していても混信を防げます。 Azure VC からひとまず使ってみようという今の時点では、なにか共通の文字列を決めておけばよいので、文字列 pubsub を使うことにしましょう。

さてこれで、Azure Web PubSub が受信するための URL が決まりました。次に、Azure VC から Azure Web PubSub への POST に欠かせない認証トークンを作ります。認証トークンを作成するには、上記の URL と、 Azure Web PubSub にアクセスするためのキーという 2 つのデータが必要になります。このキーはホスト名と同様に、Azure Web PubSub のポータルサイトから確認できます。あとはライブラリ @azure/web-pubsub の中の webPubSubKeyCredentialPolicy() 関数を参考に、トークンを作成します。

ここまでで作った 2 つのデータを、Azure VC チュートリアルアプリ内で「発行要求のペイロード」や「提示要求ペイロード」で作成する JSON に適用します。 Azure Web PubSub が受信するための URL は、両ペイロード内の callback.url に記載します。そして認証ヘッダは、callback.headers の Authorization 項に記載すれば、 Azure VC チュートリアルアプリからの通知や VP 送信は Azure Web PubSub に送信 (パブリッシュ) されるようになります。

あとは「メッセージの発行とサブスクライブ」の実装を参考に、Azure VC からの通知や送信された VP を Azure Web PubSub から受信する (サブスクライブ) ようにすれば OK です。受け取ったメッセージの扱いかたは、Azure VC チュートリアルアプリの /api/issuer/issuance-request-callback や /api/verifier/presentation-request-callback を受信している処理を踏襲すればよいでしょう。

これで完成です。自宅の PC をインターネット公開することなく Azure VC アプリを動かして、 Microsoft Authenticator で VC を扱うことができるようになりました。

4. まとめ

Azure Active Directory で提供されているふたつの機能「検証可能な資格情報」と「Azure Web PubSubサービス」を利用することで、検証可能な資格情報 (VC) でできた証明書を発行したり提示を受けたりするサービスを、ローカル PC で常時稼動できるようになりました。

ローカル PC で実験できるようになると、運用の幅が広がりますね。個人が私的な証明書を発行することも簡単にできるようになるし、知人が作った私的な証明書を個人的に確認することも簡単になります。多くのひとから山のような数の証明書を発行してもらっても、お財布が膨れ上がって困るようなこともありません。プライベートな用途の証明書なんて作れるとしたら、あなただったら誰にどんな証明をしますか？

…

さて、エンジニアだった前職から研究所に移籍して1年とちょっと経って、このような新しい標準規格を触るようになりました。前職では、そもそも用途が定まっている組み込み機器であったり、ビジネス要件の定まったソフト・サービスなどをいかに良くしていくか、というものでした。しかしここ研究所での開発は、もっと手前のところでいかに新しい「嬉しさ」を作っていくか、という観点でもがくようになりました。努力の方向性を見つけづらいのは、移籍前に覚悟していた以上の難しさがありますが、楽しんで楽しんで頭が柔らかくなった先にこそ新しい嬉しさが隠れていると信じて、新しいものを楽しんでいきたいと思います。