AWS Private CA と AWS KMS を使用した ISO/IEC 18013-5 準拠のモバイル運転免許証ソリューションの構築

本ブログは 2024 年 9 月 4 日に公開されたBlog ”Build a mobile driver’s license solution based on ISO/IEC 18013-5 using AWS Private CA and AWS KMS” を翻訳したものです。

モバイル運転免許証 (mDL) は、モバイルデバイスに保存される物理的な運転免許証のデジタル版です。物理的な身分証明書には、紛失、盗難、偽造、破損、または古い情報が含まれる可能性があり、同意なしに個人を特定できる情報 (PII) を露出させる可能性があります。mDL は、身分証明書に比べて大幅な改善がされます。さまざまな組織が連携して、飛行機搭乗時の本人確認から年齢確認が必要な活動での情報提供まで、さまざまな状況で mDL を使用できるように取り組んでいます。

mDL システムにおける信頼は、公開鍵暗号方式に基づいています。mDL は発行機関によって秘密鍵で署名され、発行機関 (issuing authority) の公開鍵を使用して検証されます。

このブログでは、mDL 仕様 ISO/IEC 18013-5:2021 に従って、AWS Private Certificate Authority (AWS Private CA) と AWS Key Management Service (AWS KMS) を使用して、Amazon Web Services (AWS) で mDL 発行機関を構築する方法を紹介します。これらの AWS サービスは、ISO/IEC 18013-5 が発行機関に課す暗号化要件に適合しています。本ブログは mDL のユースケースに合わせて調整されていますが、AWS Private CA と AWS KMS を使用した署名と検証のメカニズムは、多様なデジタルアイデンティティ検証にも参考にできます。

ソリューションの概要

AWS Private CA は、独自のプライベート認証局（CA）を運用するための初期投資や継続的なメンテナンスコストなしに、高可用性のプライベート CA サービスを提供します。CA 管理者は、AWS Private CA を使用して、外部の CA に依存せずに、オンラインのルート CA や下位 CA を含む完全な CA 階層構造を作成できます。AWS Private CA を使用することで、組織内で信頼される証明書の発行、更新、失効を行うことができます。

AWS Private CA は、ISO/IEC 18013-5 で規定されたフォーマットの証明書を発行できます。ISO/IEC 18013-5 で発行機関認証局 (IACA: issuing authority certificate authority) と呼ばれる認証局 (CA) をAWS Private CA で構築できます。本ブログでは、AWS Private CA を使用して IACA の自己署名ルート証明書と mDL 文書署名用証明書を作成します。

AWS KMS は、データを保護するために使用される暗号化キーを作成および管理するためのマネージドサービスです。AWS KMS は、FIPS 140-2 レベル 3 認証済みのハードウェアセキュリティモジュール (HSM) を使用して AWS KMS キーを保護します。これは、ISO/IEC 18013-5 で説明されている発行機関を構築する際の要件です。mDL 文書の署名と検証のために、AWS KMS で非対称キーペアを作成します。AWS KMS に保存された非対称キーペアによって署名された証明書署名要求 (CSR) をプログラムで作成します。CSR は AWS Private CA サービスに送信され、ISO/IEC 18013-5 で指定された証明書の証明書プロファイル要件に適合する mDL 文書署名用証明書を発行します。

AWS KMS で作成された KeyUsage 値が SIGN_VERIFY の非対称キーペアの秘密鍵を使用して、mDL 文書に署名します。署名された mDL 文書はモバイルデバイスに送信され、デジタルウォレットに保存され、mDL リーダーによる検証のために提示で使用されます。mDL リーダーには、さまざまな発行機関からの IACA 証明書が設定されており、それぞれの発行機関によって署名された mDL 文書を検証できます。発行機関の一例としては、運転免許証を発行する米国州政府機関などが挙げられます。

最小権限

本ブログのソリューションでは、AWS KMS と AWS Private CA サービスを使用します。ブログで説明する手順を実行する前に、選択した AWS Identity and Access Management (IAM) プリンシパルが最小特権の原則に従っており、必要最小限の権限のみが付与されていることを確認してください。詳細については、IAM のセキュリティベストプラクティスをご覧ください。

ソリューションアーキテクチャ

AWS で mDL 発行機関を構築するためのサンプルソリューションアーキテクチャを図 1 に示します。この図は、プライベート CA のセットアップから mDL 文書署名用証明書の発行、mDL の発行と検証までの段階的なプロセスを示しています。このアーキテクチャを使用して構築されるインフラストラクチャには、文書署名用証明書を発行するルート証明機関が含まれます。証明書の要件は、ISO/IEC 18013-5 のセクション B.1 証明書プロファイルで確認できます。

図 1 : AWS における mDL 発行機関のアーキテクチャとプロセスフロー

このブログでは、AWS Command Line Interface (AWS CLI) コマンドを使用しますが、必要に応じて AWS SDK API 呼び出しに置き換えることができます。AWS CLI の手順と併せて、AWS KMS を使用して mDL 文書署名用の CSR をプログラムで作成し署名するための GitHub サンプルも提供されています。

このソリューションで使用されているコマンドの詳細については、AWS Private CA と AWS KMS の AWS CLI コマンドドキュメントをご覧ください。

ソリューションの詳細

mDL の署名と検証に必要なインフラストラクチャを作成する手順です。

ステップ 1: AWS Private CA での IACA CA の作成

このステップでは、信頼の起点となる IACA (発行機関 CA) を作成します。IACA ルート CA は、mDL の検証に使用される信頼の基点です。

以下の内容で、ローカルに ca_config.txt ファイルを作成します。このファイルの内容は、ISO/IEC 18013-5 の証明書プロファイルのセクション（付録 B ）から派生しています。必要に応じて、ファイル内の Country と CommonName の値を変更できます。
```
{
  "KeyAlgorithm": "EC_prime256v1",
  "SigningAlgorithm": "SHA256WITHECDSA",
  "Subject": {
    "Country": "US",
    "CommonName": "mDL IACA Root"
  }
}
```
IACA ルート証明書は、証明書失効リスト（ CRL ）とペアになります。CRL の設定に関する情報は、証明書失効リスト（ CRL ）の設計を参照してください。CRL を設定するために、以下の情報を含む revocation_config.txt というローカルファイルを作成します。CustomCname と S3BucketName の値は例示です。AWS アカウント内で作成した値に更新してください。ExpirationInDays は要件に合わせて更新してください。CRL を含む Amazon Simple Storage Service （ Amazon S3 ）バケットに暗号化を設定することをお勧めします。
```
{
  "CrlConfiguration": {
    "CustomCname": "example.com",
    "Enabled": true,
    "S3BucketName": "crlmdlbucket",
    "ExpirationInDays": 5000
  }
}
```
AWS CLI コマンドを呼び出して、プライベート認証局（ CA ）を作成します。必要に応じて region パラメータを置き換えてください。以下のコマンドの file:// パスを、ca_config.txt と revocation_config.txt ファイルを保存した場所に更新してください。
```
aws acm-pca create-certificate-authority \
    --region us-west-1 \
    --certificate-authority-configuration file://ca_config.txt \
    --revocation-configuration file://revocation_config.txt \
    --certificate-authority-type "ROOT"
```
コマンドは以下の出力を生成するはずです。出力には作成された CA の Amazon リソースネーム (ARN) が含まれています。この ARN は後続のステップで必要になります。
```
{
    "CertificateAuthorityArn": "arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113"
}
```

ステップ 2: IACA ルート証明書の CSR の取得

IACA ルート証明書を作成します。この作成プロセスは CSR の取得から始まります。この手順で IACA ルート証明書の CSR を取得します。certificate-authority-arn パラメータには、ステップ 1 で生成された CA ARN が含まれています。

次のコマンドは、Privacy-Enhanced Mail （ PEM ）形式の CSR を出力します。

aws acm-pca get-certificate-authority-csr \ 
    --region us-west-1 \
    --output text \
    --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113

出力される CSR の形式は以下の通りです：

-----BEGIN CERTIFICATE REQUEST-----
..
-----END CERTIFICATE REQUEST-----

出力されたテキストを IACA.csr というファイル名で保存してください。

ステップ 3: ルート証明書の生成

このステップでは、IACA ルート証明書を発行します。ISO/IEC 18013-5 の証明書プロファイルセクションから参照された以下の内容を使用して、extensions.txt という名前のファイルを作成します。KeyUsage 拡張機能の KeyCertSign と CRLSign を true に設定する必要があります。CRL 配布ポイントのカスタム拡張機能が設定され、証明書の有効期間は 9 年または 3285 日（次のステップで設定）に設定する必要があります。IACA ルート証明書は mDL の発行にのみ使用されるため、ISO/IEC 18013-5 の表 B.1 に示されているように、最大有効期間を 9 年とすれば十分です。さらに、CRL ディストリビューションポイント拡張機能が存在する必要があります。以下の例では、CDP 拡張機能でエンコードされた CRL URL は http://example.com/crl/0116z123-dv7a-59b1-x7be-1231v72571136.crl で、CA 作成時に適用された CA CRL 設定および CA ID の両方に合致しています。CDP 拡張機能の Base 64 エンコーディングについては、この Java サンプルを参照してください。
```
{
  "Extensions": {
    "KeyUsage": {
      "KeyCertSign": true,
      "CRLSign": true 
    },
    "CustomExtensions": [ 
      {
        "ObjectIdentifier": "2.5.29.31",
        "Value": "MEgwRqBEoEKGQGh0dHA6Ly9leGFtcGxlLmNvbS9jcmwvMDExNnoxMjMtZHY3YS01OWIxLXg3YmUtMTIzMXY3MjU3MTEzNi5jcmw="
       }
    ] 
  }
}
```

以下のコマンドを AWS Private CA に対して実行して、証明書を作成します。

aws acm-pca issue-certificate \
    --region us-west-1 \
    --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \
    --template-arn "arn:aws:acm-pca:::template/BlankRootCACertificate_PathLen0_APIPassthrough/V1" \
    --signing-algorithm "SHA256WITHECDSA" \
    --csr fileb://IACA.csr \
    --validity Value=3285,Type="DAYS" \
    --api-passthrough file://extensions.txt

このコマンドは、以下の出力を生成します：

{
  "CertificateArn": "arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113/certificate/34a1dab03117f0e89c54b1234fe13318"
}

AWS Private CA で作成された IACA ルート CA には、デフォルトで CRL 配布ポイント (CDP) 拡張が含まれていないことに注意してください。しかし、これは ISO/IEC 18013-5 の IACA ルート証明書プロファイルによると必須の拡張機能です。これを実装するために、CDP 拡張を埋め込むカスタム拡張を API パススルーを使用して渡します。この拡張機能で指定される配布ポイントは、ステップ 1 で作成された CA ARN に含まれる CA ID である 0116z123-dv7a-59b1-x7be-1231v7257113 を使用して指定する必要があります。

ステップ 4: ルート証明書の取得

このステップでは、PEM 形式の IACA ルート証明書を取得します。

以下のコードを使用して IACA ルート証明書を取得します：

aws acm-pca get-certificate \
    --region us-west-1 \
    --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \
    --certificate-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113/certificate/34a1dab03117f0e89c54b1234fe13318 \
    --output text

コマンドの出力は、以下のような PEM 形式の証明書となります：
```
-----BEGIN CERTIFICATE-----
..
-----END CERTIFICATE-----
```
この出力されたテキストを IACA-Root-CA-Cert.pem という名前のファイルに保存します。

ステップ 5: ルート証明書のインポート

以下のコードを使用して、ルート証明書を AWS Private CA にインポートし、認証局をアクティブにして証明書を発行できる状態にします。

aws acm-pca import-certificate-authority-certificate \
    --region us-west-1 \
    --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \
    --certificate fileb://IACA-Root-CA-Cert.pem

コマンドを実行すると、success が表示されるはずです。

ステップ 6: AWS KMS での非対称キーの作成

この手順では、AWS KMS で非対称署名キーを作成します。このキーは、モバイル運転免許証（ mDL ）の文書に対する証明書署名要求（ CSR ）の署名に使用されます。

以下のコマンドを使用して非対称キーを作成します：

aws kms create-key \
    --region us-west-1 \
    --key-spec ECC_NIST_P256 \
    --key-usage SIGN_VERIFY

コマンドを実行すると、以下のような出力が得られます：

{
  "KeyMetadata": {
    "AWSAccountId": "123412345678",
    "KeyId": "3ab87971-1fe2-45d9-955a-5dc7f65558zf",
    "Arn": "arn:aws:kms:us-west-1:123412345678:key/3ab87971-1fe2-45d8-955c-5dc7f65558ef",
    "CreationDate": "2024-05-18T19:53:27.318000 + 00:00",
    "Enabled": true,
    "Description": "",
    "KeyUsage": "SIGN_VERIFY",
    "KeyState": "Enabled",
    "Origin": "AWS_KMS",
    "KeyManager": "CUSTOMER",
    "CustomerMasterKeySpec": "ECC_NIST_P256",
    "KeySpec": "ECC_NIST_P256",
    "SigningAlgorithms": [ 
      "ECDSA_SHA_256"
    ],
    "MultiRegion": false 
  }
}

出力から Arn の値をメモしてください。ステップ 7 で、mDL 文書署名用証明書の CSR 作成ユーティリティを構成する際に使用します。

ステップ 7: CSR 作成ユーティリティを使用した文書署名用証明書の CSR の生成

AWS の非対称キーで署名された CSR を作成するサンプルユーティリティを GitHub で公開しました。

GitHub リポジトリをクローンし、リポジトリの README ファイルの指示に従って設定し、実行します。
このプログラムは、以下のような PEM 形式の CSR を出力します。
```
-----BEGIN CERTIFICATE REQUEST-----
..
-----END CERTIFICATE REQUEST-----
```
出力をコピーし、document-signing-kms.csr という名前のファイルに保存します。手順 8 で、この CSR に基づいて mDL 文書用の署名証明書を作成する際にこのファイルを使用します。

ステップ 8: mDL 文書署名用証明書の生成

このステップでは、AWS KMS の非対称キーを使用して署名された CSR から、文書署名用証明書を発行します。

以下の内容で extensionSigner.txt というファイルを作成します。このファイルの内容は、ISO/IEC 18013-5 の証明書プロファイルの節から派生しています。以下の JSON スニペットは、DigitalSignatureフィールドがtrueに設定されたKeyUsage拡張を含む拡張機能の構造を示しています。
```
{
     "Extensions": {
         "KeyUsage": {
             "DigitalSignature": true 
         },
         "ExtendedKeyUsage": [ 
             {
                 "ExtendedKeyUsageObjectIdentifier": "1.0.18013.5.1.2"
             }
         ] 
     }
}
```

以下の AWS CLI コマンドを使用して証明書を作成します。

aws acm-pca issue-certificate \
    --region us-west-1 \
    --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \
    --template-arn "arn:aws:acm-pca:::template/BlankEndEntityCertificate_APIPassthrough/V1" \
    --signing-algorithm "SHA256WITHECDSA" \
    --csr fileb://document-signing-kms.csr \
    --validity Value=1825,Type="DAYS" \
    --api-passthrough file://extensionSigner.txt

出力：

{
    "CertificateArn": "arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113/certificate/d462fcd3b9h3beb45c7c312241d42fba"
}

出力から CertificateArn を使用して、モバイル運転免許証（ mDL ）文書署名用証明書を取得します。

ステップ 9: mDL 文書署名用証明書の取得

このステップでは、AWS Private CA から PEM 形式の文書署名用証明書を取得します。

次のコマンドで文書署名用証明書を取得します：

aws acm-pca get-certificate \
    --region us-west-1 \
    --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \
    --certificate-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113/certificate/d462fcd3b9h3beb45c7c312241d42fba \
    --output text

コマンドの出力を document_signing_cert.pem に保存します。

ISO/IEC 18013-5 で要求される Concise Binary Object Representation (CBOR) を用いて後ほどパッケージ化するために利用する mDL 文書署名用証明書を得ることができました。

ステップ 10: mDL リーダーによる発行機関の mDL 署名証明書チェーンの取り込み

mDL リーダーは、ユーザーが提示した mDL を暗号学的に検証した後、その mDL を信頼することができます。この検証には、リーダーがユーザーに mDL を発行した発行機関の mDL 署名証明書チェーンを保持している必要があります。ISO/IEC 18013-5 で規定されている分散型公開鍵基盤 (PKI) 信頼モデルで要求されているように、mDL リーダーは発行機関の mDL 署名証明書チェーンを取得する必要があります。

ステップ 11: ユーザーによる発行機関への mDL 署名リクエスト

ユーザーは発行機関に mDL への署名を要求します。

ステップ 12: 発行機関によるユーザーへの署名済み mDL の発行

発行機関はユーザーの身元を認証し、署名された mDL を発行します。発行機関は、モバイルセキュリティオブジェクト (MSO) として知られる CBOR エンコードされたオブジェクトとともに、mDL データをユーザーのデバイスに提供します。MSO には、ダイジェストアルゴリズム、個々の mDL データ要素のダイジェスト、および有効期間が含まれています。この MSO が ISO/IEC 18013-5:2021 のセクション 9.1.2.4 で要求されるように生成およびエンコードされた後、発行機関によって MSO に署名することができます。この署名は、以下のコマンドに示すように AWS KMS で生成できます。エンコードされた MSO の生成については、このブログでは扱いません。

sha256sum ユーティリティを使用して、エンコードされた MSO オブジェクトの SHA-256 ダイジェストを生成するには、次のコマンドを使用します。
```
sha256sum < EncodedMSO > EncodedMSODigest
```

ステップ 6 で作成した AWS KMS の非対称キーを使用してダイジェストに署名します。

aws kms sign \
 --region us-west-1 \
 --key-id 3ab87971-1fe2-45d8-955c-5dc7f65558ef \
 --message fileb://EncodedMSODigest \
 --message-type DIGEST \
 --signing-algorithm ECDSA_SHA_256 \
 --output text \
 --query Signature | base64 --decode

この署名は、発行機関の証明書と MSO と組み合わされて、CBOR Object Signing and Encryption (COSE) の署名付きメッセージを形成し、mDL データ要素とともにリーダーに提示されます。リーダーはこの署名を検証して、MSO の完全性を確認できます。

ステップ 13: ユーザーによる mDL リーダーへの mDL の提示

ユーザーは、空港などで本人確認のために mDL を mDL リーダーに提示します。このプロセスは、ISO/IEC 18013-5:2021 の 6.3.2.2 項で mDL 初期化と呼ばれています。mDL は、この初期化ステップでアクティブ化されます。

ステップ 14: mDL リーダーによるユーザーのモバイルデバイスからの mDL データのリクエスト

mDL リーダーは、ユーザーのモバイルデバイスに mDL 取得リクエストを発行します。mDL の重要な特徴は、mDL 所有者が個人識別情報（ PII ）の一部を提示できることです。mDL リーダーは、氏名や生年月日などの特定の属性を要求し、mDL 所有者はこの情報の開示に同意する必要があります。mDL リーダーのリクエストには、mDL 所有者に共有を求める個人識別情報の項目リストが含まれています。

ステップ 15: ユーザーによる mDL データ共有の同意

ユーザーは、mDL 共有リクエストを通知するメッセージを受け取ります。このメッセージには、リクエストされている個人識別情報（ PII ）の項目リストが表示されます。ユーザーがリクエストに同意すると、MSO を含む mDL データがリーダーと共有されます。

ステップ 16: リーダーによる mDL の整合性の検証

リーダーは mDL データを受信し、その完全性を検証します。mDL データ要素に MSO を含めることで、mDL リーダーは受信したデータの完全性を検証するメカニズムを得られます。mDL リーダーは、デバイスから提示された個々の mDL データ要素をハッシュ化して検証できます。すべてのデータ要素が MSO の対応するエントリと一致する場合、mDL リーダーはデータが改ざんされていないことを確認できます。

例として、mDL に以下のデータ要素が含まれていると仮定します：

24(<<
  {
    "digestID": 0,
    "random": h'BBA394B98088CAE238D35979F7210E18DFAF70354524D86149CA20046E4321B1',
    "elementIdentifer": "given_name",
    "elementValue": "John"
  }
>>),
24(<<
  {
    "digestID": 1,
    "random": h'901F63FD880A15B30EDCEEFA857201C52FB9EAD1D39C15BB592829D16CB8A368',
    "elementIdentifer": "family_name",
    "elementValue": "Doe"
  }
>>)

さらに、データ要素のダイジェストを格納するモバイルセキュリティオブジェクトはこちらです。

24(<<
  {
    "version": "1.0",
    "digestAlgorithm": "SHA-256",
    "valueDigests":
    {
      "org.iso.18013.5.1":
      {
        0: h'D6AA81E454036313A9A681809151DDDBDF702289094F18286DDC591C41C6434E',
        1: h'4C3D83940CA8C5DE8060A23EB649C175E79B745B6A7D9939B4D16B3E46BB14D5'
      }
    }
  }
>>)

MSO の整合性チェックでは、まず MSO の有効期間 (図示されていません) が期限切れでないことを確認します。次に、発行機関の公開鍵を使用して署名 (図示されていません) を検証します。これらの確認が完了した後、各データ要素を検証する必要があります。各要素 (digestID、random、elementIdentifier、elementValue) の CBOR 表現はバイト列としてエンコードされ、SHA-256 を使用してハッシュ化されます。例えば、以下は D6AA81E454036313A9A681809151DDDBDF702289094F18286DDC591C41C6434E と等しくなるはずです。

SHA256(CBOR byte representation of 24(<<
    {
      "digestID": 0,
      "random": h'BBA394B98088CAE238D35979F7210E18DFAF70354524D86149CA20046E4321B1',
      "elementIdentifer": "given_name",
      "elementValue": "John"
    }
  >>))
)

同様に、次の例は
4C3D83940CA8C5DE8060A23EB649C175E79B745B6A7D9939B4D16B3E46BB14D5 と等しくなるはずです。

SHA256(CBOR byte representation of 24(<<
    {
      "digestID": 1,
      "random": h'901F63FD880A15B30EDCEEFA857201C52FB9EAD1D39C15BB592829D16CB8A368',
      "elementIdentifer": "family_name",
      "elementValue": "Doe"
    }
  >>))
)

すべてのデータ要素がこのハッシュ検証チェックに合格すれば、mDL リーダーは提示された mDL の内容を信頼できるものとして扱うことができます。

まとめ

このソリューションでご覧いただいたように、モバイル運転免許証 (mDL) は、個人のプライバシーを保護するために、セキュリティの向上と柔軟な同意管理を提供します。暗号化による署名と検証の原理は新しいものではなく、AWS KMS と AWS Private CA はどちらも、運転免許証やその他の種類の身分証明書など、デジタル ID アプリケーションのサポートに適しています。AWS KMS の非対称鍵と AWS Private CA の詳細については、AWS KMS の非対称鍵機能を使用したデジタル署名とAWS で完全なプライベート証明書インフラストラクチャをホストおよび管理する方法をご覧ください。

本ブログに関するフィードバックがある場合は、以下のコメント欄にコメントを投稿してください。このブログに関する質問がある場合は、AWS re:Post (AWS Certificate Manager) および AWS re:Post (AWS KMS) で新しいスレッドを立てるか、AWS サポートにお問い合わせください。

本ブログは Security Solutions Architect の中島章博が翻訳しました

Amazon Web Services ブログ