🔥

ワクチンパスポートのトラスト基盤：欧州、米国、日本

2021/12/26に公開

Security

JWT

コロナ

tech

ワクチンパスポートのトラスト基盤についてのサーベイ記事です。

2021年12月20日、デジタル庁が新型コロナワクチン接種証明書アプリをリリースしました。ついに日本もワクチン接種のデジタル証明書の運用を開始したということですね。本記事では、このデジタル証明書を支えるトラスト基盤に焦点を当て、欧州、米国、日本でどのような設計・運用がなされているのか、規格（EUDCC, SMART Health Cards）の内容も含め、ざっと調べたところを紹介します。

以下、ワクチンパスポートという言葉を、ワクチン接種証明だけでなく回復証明や陰性証明を含む広い用途のデジタルヘルスカードを指すものとして使っています。

はじめに

まず、この記事でのトラスト基盤とは「ワクチンパスポートの関係者（発行者、被発行者、検証者）間で信頼を構築するための技術仕様と対応する実装、ガバナンスメカニズム」を指すものとします。WHOの開発ガイダンスや後述する EU Digital COVID Certificate（以降、EUDCC）や、FHIR SMART Health Cards（以降、FHIR）の中での "Trust Framework" に相当し、ワクチンパスポートの正しさを担保する枠組みです。

以下、欧州・米国・日本それぞれで、このトラスト基盤がどう規定・整備されているか、実際の実装・運用はどうなっているのかを順にながめていきますが、とりあえず要約してしまうと ――

欧州が規格（EUDCC）レベルでトラスト基盤を比較的しっかり定め、実装を整備しているのに対して、日米が採用している規格（FHIR）は、これをout of scope としています。誰でもワクチンパスポートを発行でき、検証者は各々どの発行者を信頼すべきか判断すればよい、というスタンスです。このスタンスのまま、国としてのトラスト基盤を整備していない（正確に言うと、現状はThe Commons Projectに任せている）のが米国、欧州寄りのちゃんとしたトラスト基盤を整備しようとしているように見えるのが日本、という感じです。

もう少し具体的に説明すると、FHIRには、後述するEUDCCのCSCA（国単位で整備されるワクチンパスポートのルートCA証明書）や、これに連なるDSC（発行者の証明書）の規定がありません。米国では、実運用上も存在しないように見えますが、日本にはあります。ただ、日本の場合、現時点では「とりあえずCSCAとDSCを作っておいた」程度で、欧州のような運用ルールが定まっているようには（少なくとも外野からは）見えません。DSCの有効期限が1年を切っているにもかかわらず、「アプリで発行した接種証明書の表示期限はありません（一度発行すると、ずっと使えます）」と言っている現状は変（穏便な言い方をすると過渡的）で、おそらく今後、DSCの有効期限に合わせたワクチンパスポートの有効期限設定、CSCAやDSCの運用方針（x509証明書のローテーション方針など）が追って定められていくのだろうとみています。

図示するとこんな感じでしょうか。

Overview

それでは、欧州、米国、日本の順に、規格と実装の両面をみていきます。

>>> 以下、詳しく知りたい人向け

欧州

詳しくは、前記事「EUのワクチン接種証明書はCWTを使っている」を参照いただければと思いますが、欧州は、EUDCC（EU Digital COVID Certificate）という規格を定め、EU加盟各国では、このEUDCCに則ったワクチンパスポートの実装・運用が行われています。EU脱退したイギリスも、ワクチンパスポートはEUDCCベースです。

規格 - EU Digital COVID Certificate

EUDCCのトラスト基盤の肝であるCSCA、DSCという2種類の証明書と、これを各国間で共有するDGCGについて概説します。詳細は以下の3つのEUDCCの仕様書の中で規定されています。

Volume 1 (Electronic Health Certificate Specification)：基本仕様書。Appendix Aがトラスト基盤に割かれています。
Volume 2: European Digital Green Certificate Gateway：EU加盟各国をまたがったEUDCCの相互検証のためのトラスト基盤を支える Digital Green Certificate Gateway（DGCG）のアーキテクチャ、技術仕様を規定しています。
Volume 5: Public Key Certificate Governance：DGCGとこれを利用するEU加盟各国のバックエンドサービスの間では、幾つかのタイプの証明書が利用されますが、それぞれのPKIのガバナンスについて規定しています。

[1] CSCA証明書とDSC

上記 Volume 1, 5 で定義されている以下の2つの証明書がトラスト基盤の重要な構成要素です。

CSCA (Country Signing Certificate Authority) 証明書: EU加盟各国毎に設置されるワクチンパスポートのルートCA証明書。CSCA証明書は、後述するDSCの発行に利用します。CSCAは、基本的には国ごとに1つですが、複数あってもよいとされています。また、ICAOのMaster Listに登録された（デジタルパスポート用の）CSCAを流用することも可能です（WHOはヘルスケアドメインで独立したCSCAを立ち上げることを推奨していますが）。
DSC (Document Signer Certificate): ワクチンパスポートを発行できる発行者の証明書。このDSC(の秘密鍵)でワクチンパスポートに署名します。DSCは CSCAによって発行されます。

Volume 5 の中では、これらの証明書のライフサイクルについても規定されており、例えば、「ワクチンパスポートの期限を1年とする場合、DSCは2年、CSCAは4年とすることが推奨される」といった記述があります。以下は、ワクチンパスポートの有効期限を1年半とした場合のCSCA証明書やDSCのライフサイクル管理の例です（Volume 5から引用）。DSCの有効期限を2年としても、半年で切り替え、同時に最大4つのDSCを運用する必要があります。

EUDCC Lifecycle Management

また、CRLを用いたDSCの失効チェックについても規定されいます。プライバシーの観点から検証アプリでのOCSPの利用を禁じているのも興味深いところです。

[2] DGCG

Digital Green Certificate Gateway（DGCG）は、EU内で上記のCSCA証明書とDSCを流通させ、EU加盟国をまたがった検証を行えるようにするゲートウェイです（下図参照）。実体はCSCA証明書とDSCのレジストリであり、これらを登録・取得できるREST APIサーバで、API仕様は Open API SpecでDigital Green Certificate Gateway として公開されています。

DGCG Overview

上図のとおり、DGCGを使ってCSCA証明書やDSC（青や緑の鍵）を取得するのは各国のバックエンドサービスであり、そこから検証アプリへの公開方法は各国の実装にゆだねられています。

[3] CSCA証明書・DSCの公開

EUDCCの仕様書の中では、以下の2種類の公開方法が例示されています。

JWTでおなじみの JWK set format（RFC7517 section 5）で公開する方法（Volume 1）
Verifier API (Digital Green Certificate Verifier Service)で公開する方法（Volume 4）

方式2.については、DSC限定で、CSCA証明書を取得できる方法ではありません。方式1.であれば、JWKのx5c属性にDSCだけでなく、CSCA証明書も含めてしまうのが自然でしょう。

実装

欧州のトラスト基盤の実装がどうなっているのか、CSCA/DSCのライフサイクル管理、流通・公開の視点で記します。

[1] CSCA/DSC及びライフサイクル管理

ワクチンパスポート本体はもちろんのこと、CSCA証明書、DSCについても、フォーマット、記載内容については規格に則った実装の統制がとれているようです。眺めた範囲では、全ての国が ICAO とは独立したCSCAを設置していました。

有効期限の設定は国に依りますが、CSCA証明書は4年～15年、DSCは1年～3年という範囲に大体収まっているようです。DSCは2年が多いですね。特殊なケースとして、オランダは、DSCの有効期限を10年以上に設定しているのですが、X.509のPrivate Key Usage Period拡張を使って署名（つまりワクチンパスポートの作成）に使える期間を7か月に制限していました。証明書の有効期間とは別に、Private Key Usage Periodを使って署名期間を厳密に設定する例は他の国にも見られました。

失効については、証明書内へ CRL Distribution Pointsを設定している例は少なからずありました。全てでは無いですが。

[2] CSCA/DSCの流通・公開

まずDGCGについては、各国のバックエンドの裏側にいるため、どの程度実際に活用されているのかはわかりません。一方で、EU加盟各国におけるCSCA証明書とDSCの公開方法は様々で、前述（規格[1]CSCA証明書・DSCの公開）した2つの方式を採用する例もありますが（方式1.はスウェーデン、方式2.はイタリア）、各国それぞれの検証アプリ用に独自形式で配布している例が多そうです。

ちなみに方式1.のスウェーデンは、Document Signer Certificate (DSC) Trust List - Format Specification として仕様を公開しています（公開エンドポイントのURLを含めてここに情報がまとまっています）。ここから各国のDSCが取得できますのでご参考まで。

米国

米国は、医療情報関連の国際標準規格HL7 FHIRが定める SMART Health Cards を新型コロナワクチン接種証明書に採用しています。ただし、欧州のように国レベルでトラスト基盤を運用しておらず、州や医療機関単位でIssuer（ワクチンパスポート発行者）になり、独自運用を行っている状況です。

規格 - SMART Health Cards (FHIR)

FHIRにおいて、トラスト基盤をどう位置づけているかについて概説します。詳しくは、以下の規格文書に記載されています。

SMART Health Cards Framework: Protocol: SMART Health Cardsの実装ガイドの位置づけ。短期的なゴールを「COVID-19のワクチン接種証明や検査結果を検証可能な方法で別パーティに示せること」に置いています。要は、タイトルは"スマートヘルスカード"と広いが、現状は新型コロナワクチン接種証明書にスコープを絞ったものになっています。

[1] トラスト基盤の位置づけ

FHIRはトラスト基盤をout-of-scopeとしています。ベースラインとしては、誰でもワクチンパスポートを発行でき、検証者（Verifier）は各々どの発行者（Issuer）を信頼すべきか判断すればよい、というスタンスです。このため規格自体はトラスト基盤から独立して動作するよう設計されていますが、トラスト基盤は Verifier の判断に根拠を与え一貫したものにするために必要なものなので、連携するための口は用意されています。

[2] トラスト基盤との連携方法

FHIRが提供しているワクチンパスポートをVerifierが検証する仕組みは、いたってシンプルです。

Issuerは自身の公開鍵を、JWKSエンドポイント(RFC7517)で公開する（公開ディレクトリは、<Issuer URL>/.well-known/jwks.json）
Verifierは、信頼するIssuerの公開鍵を上記JWKSエンドポイントから取得し、ワクチンパスポートの署名検証に利用する。

トラスト基盤との連携は、このJWKSエンドポイントが返すJWKのメタデータのx5c属性（X.509証明書チェーン）を使うだけです。EUDCCの例なら、Issuerが、x5c属性にDSCとCSCA証明書を入れておき、Verifierが、CSCA証明書を自身のトラストリストに加えておけばよいわけです。

実装

米国のトラスト基盤の実装がどうなっているのかと言えば、前述のとおり特に無しです。国レベルでの（CSCAの）は見当たりません。以下、カリフォルニア州のIssuerのJWKSエンドポイント（ https://myvaccinerecord.cdph.ca.gov/creds/.well-known/jwks.json ）の応答です。

{
  keys: [
    {
      kty: "EC",
      kid: "7JvktUpf1_9NPwdM-70FJT3YdyTiSe2IvmVxxgDSRb0",
      use: "sig",
      alg: "ES256",
      crv: "P-256",
      x: "3dQz5ZlbazChP3U7bdqShfF0fvSXLXD9WMa1kqqH6i4",
      y: "FV4AsWjc7ZmfhSiHsw2gjnDMKNLwNqi2jMLmJpiKWtE"
    }
  ]
}

x5c属性の利用は無く、カリフォルニア州が独自でES256の鍵ペアを管理しているだけ、という状況です。JWKには有効期限の定義は無いので、対応するX.509証明書が無い以上、特に鍵の失効を含むライフサイクル管理も考慮していない状況だと思います。

検証アプリはこうした独立したIssuerを自前のトラストリストで管理しなければなりませんが、FHIRの初期方針として、The Commons Projectに管理をゆだねています。具体的には、Github上で The Commons Project - VCI Directory としてトラストリストが公開されています。国（プエルトリコ）、米国・カナダの州、医療機関など、さまざまな粒度でIssuerが登録されています。2021年12月25日時点でその数約500。これほどの数のIssuerがそれぞれ独立してちゃんと鍵管理できていることを前提としていて、カオスというか危うい感じがしますね。このトラストリストは、同じくThe Commons Projectが提供する SMART Health Card Verifier App で使われています。

ちなみに、2021年12月18日に、日本政府のIssuerを追加するPull Request が作られていますが、おそらく日本のJWKSエンドポイントがSMART Health Cards Framework: Protocol の仕様を満たしていない（CORSヘッダが設定されていない）ために、CIがfailしていてマージされていません（8日間放置されているが大丈夫なんだろうか・・）。

日本

最後は日本です。米国と同様、FHIR（SMART Health Cards）を採用しています。米国との違いは、国レベルでトラスト基盤を運用しようとしているところです。日本のJWKSエンドポイントを見てみましょう。

{
  keys: [
    {
      kty: "EC",
      kid: "f1vhQP9oOZkityrguynQqB4aVh8u9xcf3wm4AFF4aVw",
      use: "sig",
      alg: "ES256",
      x5c: [
        # DSC (Document Signer Certificate)
        "MIIByjCCAXGgAwIBAgIJAPZFN9WW4voaMAoGCCqGSM49BAMDMCIxIDAeBgNVBAMMF3ZjLnZycy5kaWdpdGFsLmdvLmpwIENBMB4XDTIxMTEyNTEyNTUxNloXDTIyMTEyNTEyNTUxNlowJjEkMCIGA1UEAwwbdmMudnJzLmRpZ2l0YWwuZ28uanAgSXNzdWVyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEViKBgZ0f3pQKv+tSz653HUtIzCS8TVSNu1Hwi0tKpSnTXXvtqkpcfYeAZ+SfvVk8SWNaTRDZ9wTNjb9c58v9l6OBizCBiDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUiIXKUyT93YdyqsIjE8i5I1z8w0IwHwYDVR0jBBgwFoAU0cYt0sPpuIDBt7a9PD3qs9mOu7EwLgYDVR0RBCcwJYYjaHR0cHM6Ly92Yy52cnMuZGlnaXRhbC5nby5qcC9pc3N1ZXIwCgYIKoZIzj0EAwMDRwAwRAIgEwVdLdbPqMYqEsVltnsm3bI/Z6eibgMwYaNVZiu0r2sCIFebHk1i6ghWOQn+Q0+t5F77fasgJ3Oc6NWx9I8AWjRM",
	# 中間CA
        "MIIBkDCCATagAwIBAgIJAOECTZDa4MA7MAoGCCqGSM49BAMEMCcxJTAjBgNVBAMMHHZjLnZycy5kaWdpdGFsLmdvLmpwIFJvb3QgQ0EwHhcNMjExMTI1MTI1NTEzWhcNMjYxMTI0MTI1NTEzWjAiMSAwHgYDVQQDDBd2Yy52cnMuZGlnaXRhbC5nby5qcCBDQTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEL3S0yNIJ8EuxgiaHEvsjGWd60P0BBKUfVUVSxpVyGsnXwuzkS7OPGG/DT60m5XTvKT125MRuZoS/sajPBcg2KjUDBOMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFNHGLdLD6biAwbe2vTw96rPZjruxMB8GA1UdIwQYMBaAFPKN8VogQyX0IuxEi7jBB5gUnFinMAoGCCqGSM49BAMEA0gAMEUCIQCcq3H/pRMRkUmpWUDsggQXJAjLB/AutlHQigEBsVx0sgIgfVyc0L1cbRaDmdCQ3CGd994rRuwlQI0/cJCIv5LeI3g=",
	# CSCA (Country Signing CA) Certificate
        "MIIBlTCCATugAwIBAgIJANt2MZrWChe2MAoGCCqGSM49BAMEMCcxJTAjBgNVBAMMHHZjLnZycy5kaWdpdGFsLmdvLmpwIFJvb3QgQ0EwHhcNMjExMTI1MTI1NDUzWhcNMzExMTIzMTI1NDUzWjAnMSUwIwYDVQQDDBx2Yy52cnMuZGlnaXRhbC5nby5qcCBSb290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEilfgw+JIG8TOliOLe7jufm2m0+HqL4t5nvBdQj3UMgh8jjl6VoVKKwcj3T1DWFinm6sCTWYUrPSXWcvOq64GbKNQME4wDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQU8o3xWiBDJfQi7ESLuMEHmBScWKcwHwYDVR0jBBgwFoAU8o3xWiBDJfQi7ESLuMEHmBScWKcwCgYIKoZIzj0EAwQDSAAwRQIgQWnKyVhaKpu1WcXP49s9inaa5mnWgV/pCW31h/NIJnwCIQDSIHvGUuPwK+ofYqLJGo99hhwhfkIBWhvSo0vr5IGesg=="
      ],
      crv: "P-256",
      x: "ViKBgZ0f3pQKv-tSz653HUtIzCS8TVSNu1Hwi0tKpSk",
      y: "01177apKXH2HgGfkn71ZPEljWk0Q2fcEzY2_XOfL_Zc"
    }
  ]
}

カリフォルニア州のものとは違いますね。x5c属性が設定されています。3つのX.509証明書がリストされていますね。DSC、中間CA証明書、最後がCSCA証明書です。それぞれ有効期間は、1年、5年、10年となっていました。欧州平均と比べるとDSCの寿命が短めですね。また中間CAが設定されているのも特徴的です。例えば、（現実的とは思えませんが）都道府県を中間CA、市区町村・医療機関がDSCを発行するような運用を将来的に想定しているのでしょうか？ ―― それとも、AWSの ACM Private CA が簡単すぎて勢い余ってポチポチ作ってしまっただけなのでしょうか？

気になるのは、DSCの有効期間が1年にもかかわらず、「アプリで発行した接種証明書の表示期限はありません（一度発行すると、ずっと使えます）」と言っている点です。JWTライブラリがどれぐらい真面目に作られているかに依りますが、DSCが期限切れになったら CSCAに連なるx5cの証明書チェーンの検証に失敗する（つまりワクチンパスポートの検証に失敗する）はずです。まあ再発行も容易なようですし、このあたりは織り込み済みで、今後、DSCの有効期限に合わせたワクチンパスポートの有効期限設定、CSCAやDSCの運用方針（x509証明書のローテーション方針など）が追って定められていくのかもしれません。

いずれにしても日本は、FHIRを採用しながら米国ほどアバウトでなく、欧州寄りのしっかりしたトラスト基盤運用に舵を切っているように見えます。今後の整備状況も引き続きウォッチしていきたいと思います。

おわりに

日本、もう少し仕様をオープンにしてもらえると嬉しいんですけどね。この記事、「ソースはJWKSエンドポイントだけ」な感じなので。ちなみに私のスマホ、NFC非対応でして「新型コロナワクチン接種証明書アプリ」まだ使えていません・・。