スマートフォン上のデジタル運転免許証（mDL）の統合が難しいのは、ID検証用のAPIを呼び出すことではなく、そのAPIの背後で何が起きているかを理解することにある。認証情報はどこに保存されるのか、デバイスの鍵を誰が保護するのか、信頼証明書はどのように管理されるのか、ネットワークの切断時やサービスプロバイダーの障害時にも何が動作し続けるのか。本記事はInfoQに掲載されたもので、ISO/IEC 18013-5規格に基づくmDLシステムのアーキテクチャ像を示し、プロバイダー、SDK、ウォレットプラットフォーム、検証サービスを選定する組織を対象としている。
本人確認と認証情報の発行を分離する
提案されるフレームワークは、IDライフサイクルにおける異なる2段階の分離から始まる。本人確認の段階では、ユーザーが物理的な運転免許証の写真と、生体認証確認用の動画を撮影し、その証拠と抽出データを検証システムへ送信する。陸運局などの所管機関は、これらの証拠を自動または手動で審査し、承認または拒否を決定する。
承認後、プロビジョニングの段階が始まる。デバイスはSecure Enclaveまたはセキュアエレメント内で非対称鍵を生成し、公開鍵、証明書、本人確認プロセスへの参照を発行機関へ送信する。発行機関は、署名付きのMobile Security Object内で免許証データを鍵に関連付け、その認証情報パッケージを暗号化して、ハードウェアで保護された領域に保存するためウォレットへ送信する。
組織がこれらの手順を自ら実行する必要はないが、各手順に責任を負う当事者と、それによって生じる信頼の判断を担う当事者を特定しなければならない。
プロバイダーのインターフェースの背後で何を検査すべきか
本記事は、verifyCredential()やrequestPresentation()のような機能を呼び出すパイロットが成功しても、プロバイダーの評価には不十分だと指摘する。検査には、相互に関連する次の6つの領域を含めるべきである。
- 暗号アーキテクチャ：鍵の生成と保護、デバイス認証、アルゴリズム、鍵のライフサイクル。
- 信頼と公開鍵基盤：トラストアンカー、Document Signer証明書、信頼リスト、失効リスト。
- プライバシーとデータ最小化：選択的開示、テレメトリー、提示データの保持、取引間のリンク付けリスク。
- オフライン動作：キャッシュされた資料、古い失効状態、ネットワーク切断時のシステム動作。
- 相互運用性：ISO/IEC 18013-5への準拠、独立したウォレットや検証者との連携可能性。
- 運用上のレジリエンス：プロバイダー障害の影響、認証情報の継続性、復旧メカニズム、障害対応。
暗号化と証明書は実装上の細部ではない
本記事は、インターネット経由の通信およびAPIのやり取りを保護するため、RFC 9180に基づくHybrid Public Key Encryptionの使用を提案している。指定されるパラメーターには、DHKEM(P-256, HKDF-SHA256)、HKDF-SHA256、AES-128-GCMが含まれる。しかし、提示されたフレームワークによれば、暗号化を信頼モデルから切り離された機能として扱うべきではない。暗号化がどこで始まりどこで終了するのか、誰が鍵を生成し保護するのか、鍵をどのようにローテーションするのか、プロバイダーの信頼境界内にどのコンポーネントが存在するのかを把握する必要がある。
ウォレットサーバー、発行プラットフォーム、検証システム間の通信にも、明確な証明書基盤による相互TLS認証が必要である。本記事は、オフラインのハードウェアセキュリティモジュールに保存されるトラストルートから、短期間有効なDocument Signer証明書、mTLS証明書、デバイス鍵認証証明書まで、証明書のさまざまな役割を示している。決定的な問題は、責任の分配である。どの基盤をプロバイダーが管理し、どの基盤を組織が管理し、どの信頼関係を発行機関が保持するのかを明確にしなければならない。
サービス停止時に実際に何が変わるのか
設計では、NFC経由のデータ交換やAPIによる直接検証など、検証中に発生する同期処理と、本人確認の審査、認証情報のプロビジョニング、鍵のローテーション、信頼リストの同期など、バックグラウンドで実行できる非同期処理を区別する。
この分離により、ポリシーが許す場合には、既存の認証情報の提示とオフラインでの検証を継続できる一方、信頼リストの同期や失効情報の更新を延期できる。本記事は、ネットワークなしでの提示と検証、期限切れの認証情報、古い失効リスト、デバイス時計のずれ、接続の復旧、プロバイダー障害時のシステム動作をテストすることを提案している。高可用性のプロバイダーに依存していても、すべての検証にバックエンドサービスへの接続が必要なら、単一障害点になり得る。
選択的開示とプロバイダーへのロックイン防止
必要なデータは状況によって異なる。空港の検問所では氏名、写真、生年月日、文書番号、発行機関が必要になる場合がある一方、店舗では、氏名、住所、文書番号を示すことなく、ユーザーが21歳を超えていることを証明する論理値と写真だけで済む場合がある。したがって、1つのシナリオだけでプロバイダーをテストするのでは不十分であり、組織のポリシーと実際の取引カテゴリーに照らして評価しなければならない。
本資料は、ビジネスロジックをプロバイダーの構造から独立させることを提案している。これにより、アプリケーションは、システム全体にプロバイダー固有のデータ構造を展開するのではなく、「21歳を超えていることの証明を要求する」といったポリシーを表現できる。CBORのシリアライズ、APDUメッセージの構築、暗号ライブラリの呼び出しなどの詳細は隠蔽できるが、トラストアンカー、発行機関の身元、開示される属性、証明書および失効の状態、プロバイダーへの依存、オフライン動作の能力は組織から見える状態にしておく必要がある。
certi.newsの見解
本記事が重視する真の変化は、mDLの評価をSDKの機能テストから、完全な信頼システムのレビューへ移行することである。このアプローチは、セキュリティ、ID、調達の各チームにとって有用である。何を購入でき、何を組織のガバナンス下に残すべきかを明確にできるからだ。ウォレットの実装、NFCプロトコル、暗号ライブラリは購入できる一方、開示、認可、監査のポリシー、鍵と証明書の管理、プライバシー、可用性、相互運用性のガバナンスは構築すべきである。
ただし、このフレームワークだけでは、地域のコンプライアンス要件や、発行機関と検証者の間のガバナンスモデルといった問題は解決しない。また、署名の正当性が保証されても、システムが過剰な記録を保持したり、提示操作をユーザーに関連付けたりすれば、プライバシーが保証されるわけではない。そのため、追跡可能性、プライバシーを維持する失効、プロバイダー障害時の責任といった問題は、本番環境へ移行する前に、組織および規制上の判断を必要とする。
ニュースの出典
InfoQ - Architecture Articles
原文を開く ↗