【要点抽出】NIST SP800-63A-4

ニキヌス

今回は身元確認（Identity Proofing）についての情報が詰まった63Aを読みます。

https://openid-foundation-japan.github.io/800-63-4/sp800-63a.ja.html

はじめに

本noteでは、OpenIDファウンデーションジャパンによる翻訳版を読んでいます。ただ、翻訳版ではあえて正確に伝えるために単語を英語のまま表記しているのに対し、本noteでは読みやすさのために私なりの便宜的な日本語をあてはめています。
そうした箇所は、「身元確認（Identity Proofing）」といった形で、便宜的な日本語+括弧書きで元の英語　という形で記しています。

何の本？

NIST SP800-63の兄弟的な文書で、63Aはアカウント登録時などの身元確認（Identity Proofing）の要件を取り扱います。

構成は？

全10セクションです。このうち1～3の前置き部分と、7～10のSecurity、Privacy、Usability、Equity(SP800-63で掲げられた4つの観点）をそれぞれ掘り下げる構成は63B、63Cと共通です。
真ん中の4～6が本書が扱うIdentity Proofingならではのセクションであり、Normativeな内容です。
このnoteでは、１～6セクションをまとめます。

  1. Purpose（Informative）

  2. Introduction（Informative）

  3. Definitions and Abbreviations（Informative）

  4. Identity Assurance Level Requirements（Normative）

  5. Identity Resolution, Validation, and Verification（Normative）

  6. Subscriber Accounts（Normative）

  7. Threats and Security Considerations（Informative）

  8. Privacy Considerations（Informative）

  9. Usability Considerations（Informative）

  10. Equity Considerations（Informative）

前提知識

１～２セクションから前提知識をまとめます。

  • 本書では、ネットワーク上または対面での Identity Proofingを対象とし、カスタマーサポートやコールセンターに電話してきた人の身元確認は対象外です。

  • Identity Proofing の定義は「オンラインサービスにアクセスする Subject と実存する人物との関係性を、ある程度の確実性または保証（Assurance ）をもって確立するプロセスのこと」としています。

  • ValidationとVerificationという、日本語ではどちらも「確認」になってしまう言葉が登場しますが、違いは以下です。

    1. Validation：有効性や妥当性の確認（例えば提示された身分証明が公式な機関から発行されたものか、有効期限内かを確認するイメージ）

    2. Verification：主張が正しいこと、事実であることの確認

３．Definitions and Abbreviations

用語一覧なので割愛します

４．Identity Assurance Level Requirements

このセクションでは身元確認からアカウント登録（Identity ProofingとEnrollment）の流れを、Resolution、Validation、Verificationという3つのステップに分けて、それぞれの要件を説明します。

（１）身元確認（Identity Proofing）全体の流れ

まず、身元確認（Identity Proofing）全体の流れは以下です。

図１．「図 1. Identity Proofing プロセス」より

1つ目のステップであるResolutionは以下を行います。

  • 最初にどこの馬の骨とも分からない登録希望者（Applicant）が、アカウント登録がしたいとやってきます。

  • CSPは、登録希望者（Applicant）から名前や住所などのプロフィール情報（Attribute）を教えてもらいます。

  • あわせて、そのプロフィール情報（Attribute）の裏付けとして、運転免許証などの身分証明書（Identity Evidence）も提出してもらいます。

2つ目のステップであるValidationは以下を行います。

  • CSPは、先ほど得たプロフィール情報（Attribute）を、信頼できるソースと照合します。

  • また、登録希望者（Applicant）が出してきた身分証明書（Identity Evidence）について、真正性、正確性、最新性の観点でチェックします。

  • ここまでで「どうもさっきの登録希望者が言ってるプロフィール情報は嘘じゃないっぽい」ということが分かります。しかし、まだこの時点では、誰かが赤の他人のプロフィール情報と身分証明書を出してきただけかもしれません。

3つ目のステップであるVerificationは以下を行います。

  • CSPは、登録希望者（Applicant）と先ほどプロフィール情報をValidationした人が同一であることを確認します。

  • そのために、登録希望者（Applicant）に自身の写真を撮影させて、Validation済の身分証明書（Identity Evidence）と照合する等のチェックを行います。

全て終わったら、登録希望者（Applicant）は晴れて「どこの馬の骨とも分からない」身分から「身元確認済のXXさん」にレベルアップし、登録済利用者（Subscriber）アカウントに登録（Enroll）してもらえます。

身元確認（Identity Proofing）は、免許証やパスポート、対面や非対面など様々な手法が考えられます。
求められるIALの要件を満たしつつも、様々な事情を持つ人たちが利用できるように、単一的な手法ではなく複数の手法をオプションとして提供するべき（SHOULD）と本書では述べています。

（２）各ステップの要件

この後、Resolution、Validation、Verificationや身分証明書（Identity Evidence）の要件の話に入りますが、先にIAL１～３に求められる要件の概観を見てからそれぞれの内容に触れたいと思います。

表１．「表1 IAL 要件サマリ」より

Resolutionについては、本書ではこれといった要件は述べられていません。
強いて言えば、登録希望者（Applicant）から集めるプロフィール情報（Attribute）は必要最小限にしておこうね。くらいです。
IAL１～３によって求められる要件に違いはありません。

身分証明書（Identity Evidence）については、以下の「許容できるエビデンスの性質」が定められており、それを元に自分のシステムでどんな身分証明書を受理するかを決めます（SHALL）。運転免許証やパスポートを思い浮かべながら読むと分かりやすいと思います。
なお、本書では物理的なエビデンスとデジタルエビデンスを分けて触れられていますが、性質的には大きな違いはなさそうです。

  • 登録希望者（Applicant）の氏名が含まれて（印刷されて）いる

  • 少なくとも1つのリファレンス番号が含まれて（印刷されて）いる

  • エビデンスの発行者の名称が含まれて（印刷されて）いる

  • エビデンスの発行者が、事前に登録希望者（Applicant）の身元確認（Identity Proofing）を実施している。

  • エビデンスがが、意図された人物に届けられた、あるいはアクセス可能なものであるという、合理的な保証がある。

加えて、エビデンスの強度について考える必要があります。
強度は「発行の厳密さ」「登録希望者(Applicant)のVerificationにおける信頼性を提供する能力」「プロフィール情報（Attribute）のValidationにおける信頼性を提供する能力」の3つの観点で構成され、Superior＞Strong＞Fairの3段階が定められています。各観点と要件を表にまとめました。

表２．エビデンスの強度要件

Validationについては、CSPが受け取った身分証明書（Identity Evidence）に対して以下の確認を行います（SHALL）。
確認の仕方について「どの観点を」「どうやって」チェックすべきか定められています。

「どの観点を」は以下です。

  • 正しい形式であり、必要な情報が全て揃っていること

  • 偽造、改ざんされていないこと

  • セキュリティ機能が備わっていること

  • 有効期限を過ぎていないなど最新であること

  • デジタル署名が正しく検証可能であること

「どうやって」は複数の方法があり、例えば対面/非対面、自動化、公開鍵を用いたデジタル署名の検証などが挙げられています。

また、本書ではプロフィール情報（Attribute）の確認先などの文脈で「権威あるソース（Autoritative source)」「信頼できるソース」という用語がたびたび登場します。本書の4.3.4.4にその定義が示されていますが、ここでは割愛します。
IAL１～３によって求められる要件に違いはありません。

Verificationについては、以下の5つの手法が定められており、1つ以上を採用することを求めています。
IAL１～３によって求められる要件に差があります。

  • Enrollment code verification（※）

  • 対面で身分証明書(Identity Evidence）の顔写真と登録希望者(Applicant)の顔を比較

  • 上記のリモート版。CSPの担当者が画面ごしに対話する方法と、動画や顔写真をその場で撮影させて機械的に比較する方法がある。

  • 自動化された生体情報の比較
    #「生体」よりも「自動化」がポイントです。この生体情報には顔写真も、その他の生体情報も含まれます。これを自動化された比較システムを用いてチェックするイメージです。

  • デジタルアカウントのコントロール
    例えばオンラインバンキングに認証させることで本人であることを確認するイメージかと思います

※Enrollment code verificationとは、アカウント登録の最後あたりにメールアドレスにURLリンクが通知され、それをクリックできるか確認するようなイメージです。他にも電話番号に通知するケース、URLリンクではなく数字コードが通知されるケースなど様々な手法があります。
本書では5.1.6にEnrollmentコードの要件が定められており、例えば数字コードの場合は6桁であるとか、有効期限はSMS通知なら10分、メールアドレスなら24時間といった定めがあります（いずれもSHALL）。
また、Enrollmentコードは認証要素として使ってはならない（SHALL NOT）とも定められています。

５．Identity Assurance Level 要件

このセクションでは「一般的な要件」としてIdentityサービスの文書化、プライバシー要件、Equity要件、セキュリティ要件、身元確認（Identity Proofing）の通知要件、生体情報（Biometrics）の利用要件などが書かれた上で、IAL1～３のそれぞれの要件が定められています。
全てを書くと非常に長くなるので、めぼしいところを抜粋します。

（１）Equity要件

公平性（Equity）は第4版から初登場した観点です。
公平性が損なわれるケースとして考えられる例が10.Equity Considerations セクションに挙げられています。例を以下に挙げます。

  • Resolutionの段階では、名前や性別が変わったことで身分証明書（Identity Evidence）と一致せず、身元確認ができない

  • Validationの段階では、身分証明書（Identity Evidence）と信頼できるソースを照合する作業がありますが、信頼できるソース側保持している情報の中に、なりすまし被害者である人物に関する不正確または誤った情報が含まれている可能性がある

  • Verificationの段階では、顔写真を撮影する際に特定の肌色の場合に比較精度が落ちてしまう、あるいは宗教上の理由から顔を出せないために顔写真を撮影できない場合がある

こうした事情による、Identityサービス上の不公平を招かないためにも、CSPは以下の要件を求めています（SHALLのみ抜粋）。

  • リスク評価の結果に基づいて、不公平を軽減するための措置を文書化する

  • Identityサービスの変更を行う場合、あるいは定期的に、公平性の観点で再評価する

  • 公平性の観点のリスク評価や軽減策について、一般公開するとともに、全てのサービス利用者が利用できるようにする

（２）Identity Proofingの通知要件

身元確認（Identity Proofing）が終わりましたよ。という通知をどうやって本人に届けるかという論点です（SHALLのみ抜粋）。

  • 通知は、確認（Validate）済の電話番号やメアドに送信します。

  • Identityサービスの名前や身元確認（Identity Proofing）の完了日付などの詳細情報を通知内容に含みます

  • 通知を受けとった受取人が「いや私アカウント登録した覚えないけど」的に否認する場合の連絡先や手続きの情報を提供します

（３）Biometricsの利用要件

まず、生体情報（Biometrics）とは、登録希望者（Applicant）が撮影した顔写真やその場で採取した指紋だけでなく、提出された身分証明書（Identity Evidence）上にある顔画像や指紋特徴点テンプレートなども含みます。
生体情報を扱うCSPには以下が求められます。

  • どんな生体情報を集め、どう保存し、どう削除するか、といった情報を公開する

  • 生体情報を収集する前に、登録希望者（Applicant）から同意を得るとともに、その同意内容を登録済利用者（Subscriber）アカウントに保管する

  • 生体情報の削除プロセスとデフォルトの保存期間を文書化し、公開する

  • 法令などによる制限を除き、個人がいつでも自分の生体情報の削除を要求できるようにする

  • Biometricアルゴリズムについて、独立した研究機関等による性能テストを行い、結果を公開する

  • 他人受入率(False match rate)、本人拒否率(False non-match rate)ともに 0.0001%未満を満たす

  • 人種、性別、民族などのグループが異なった場合でも、性能差がない技術を用いる。もし性能差がある場合は、その影響を受ける希望登録者（Applicant）に対する救済オプションを提供する

  • 正しい（他人ではない）利用登録者（Applicant）から生体情報を取得することを保証する

  • リモートで生体情報を集める場合、画面の向こうの利用登録者（Applicant）が「本当に生きていること」を確認する

  • 対面で生体情報を集める場合、生体情報に用いる顔や指に「non-naturalな物質が存在するかどうか」を確認する
    #変装や偽造の指を見破るみたいなイメージ？

（４）Trusted Referees と Applicant References

何らかのサービスを利用したくても、身元確認（Identity Proofing）ができない事情を持つ人がいます。例えば、障がい者、高齢者、ホームレス、未成年者などです。
そうした人の身元確認を促進するために「リスクに基づく判断を行う訓練を受けて認可された、CSPまたはそのパートナーの代理人」がTrusted Refereeと定義しています。
第３版では「Applicantの身元を保証したり代理人となれる信頼できる身元引き受け人」と訳されており、あくまで登録希望者（Applicant）の代理人であってCSPの代理人とは異なるように思います。

一方、入院中などで身元確認（Identity Proofing）ができない状況の人に対して「Identity Proofing要件を満たすことを支援するために、ApplicantのIdentity Proofingに参加する個人」をApplicant Referenceと定義しています。この言葉は第３版には登場しません。
本書の説明を読む限り、
登録希望者（Applicant）の代理人がApplicant Referenceであり、
Applicant Referenceが提出した登録希望者（Applicant）についてのエビデンス等をチェックする人がTruted Refereeであるように読み取れました。
この2つの役割に対する要件も定められていますが、ここでは割愛します。

（５）IAL１～３の要件

やっと本題のIAL1～３の要件です。
といっても、IALごとの要件の違いは表１．や、前回の記事で既にほとんど説明済です。
ここでは、IAL3で認められている対面と同等レベルに保護されたオンラインセッション（Supervised Remote Identity Proofing Session）の要件だけ触れます。

  • 登録希望者（Applicant）が身元確認のセッション全体にわたって継続的に存在していることを確認する。例えば、高解像度のビデオ伝送など。

  • 生身のオペレータをリモートから参加させる

  • オペレータにとって、登録希望者（Applicant）が身元確認中に取ったすべての行動がはっきりと見えるようにする

  • 身分証明書（Evidence）のすべてのデジタルVerification（例：チップまたは無線技術を介したもの）が、統合されたスキャナおよびセンサ（例：組み込み指紋リーダ）によって実行させる

  • 潜在的な不正行為を検出する等のトレーニングを受けたオペレータが担当する

  • オンラインセッションの設備が配置される環境に適した物理的な改ざん検出および耐タンパ機能を採用する

  • すべての通信を、Mutually Authenticated Protected Channel（mTLS等かと思われる）で保護する

要は通信を保護した環境下で、訓練されたオペレータが登録希望者（Applicant）の動きの一部始終をビデオ等で見れる状況で。みたいなイメージです。最近のセキュリティ系の試験は自宅でも受験できますが、その際も似たようなものを求められますね。

6.Subscriber Accounts

身元確認（Identity Proofing）が終わると、登録希望者（Applicant）の情報は認証サービスに登録（Enroll）され、以降このユーザは登録済利用者（Subscriber）と呼ばれます。
この登録済利用者のアカウントをSubscriber Accountと呼び、アカウントには以下の情報を含めます（いずれもSHALL）。

  • 一意の識別子

  • それまでに完了した Identity Proofing ステップの記録

  • 達成された最大IAL

  • 個人情報または機微情報の取り扱い関する登録済利用者（Subscriber）の同意

  • アカウントに紐づけられているすべての認証情報（Authenticator）

  • 確認（Validate）済のプロフィール情報（Attribute）や身元証明書（Evidence）

また、アカウントに登録された個人情報は、登録済利用者（Subscriber）が変更できる必要があります（SHALL）。
この際、個人情報への不正アクセスを防ぐために、AAL2以上の認証を行った上で（つまりMFAで）アクセスさせます（SHALL）。

登録済利用者（Subscriber）がアカウントの利用終了を選んだ場合、あるいは利用規約に反した場合、第三者によって侵害された場合等に、アカウントを終了します（SHALL）。
この際、アカウントに紐づいていた個人情報等を、記録保持要件を踏まえつつ削除します（SHALL）。

ここまでで今回のまとめは終わりです。
残りの7～10のセクションは、Digital Identityの世界で考慮すべき4つの要素（Security, Privacy, Equity, Usability）の検討事項が書かれています。
特に7.のセキュリティは、身元確認（Identity Proofing）における脅威と対策の組み合わせが書かれているので頭の整理に役立ちます。
10．のEquityは、本noteでは５．Identity Assurance Level 要件のEquity要件にまとめています。

SP800-63-4：こちら
SP800-63A-4：こちら（この記事）
SP800-63B-4（前編）：こちら
SP800-63B-4（後編）：こちら
SP800-63C-4（前編）：こちら
SP800-63C-4（後編）：こちら

＊＊＊はじめての方へ＊＊＊
これは何のnoteだ？と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら

この記事が気に入ったらサポートをしてみませんか？