Sun, 05 Mar 2023 05:16:25 +0000

ABSTRACT

本ガイドライン群は, Digital Identity サービスを実装する連邦機関に対する技術的要件を提供するものであり, それ以外の条件下での標準仕様の開発・利用に対する制約を意図したものではない. 本ガイドラインは, 政府機関がネットワークを介して提供する情報システムを利用する Subject の Authentication にフォーカスしている. この Authentication により, 特定の Claimant が以前 Authenticate された Subscriber であるということが立証可能となる. Authentication プロセスの結果は Authentication を実行したシステムローカルで利用されることもあるが, Federated Identity System 内の別の場所で利用されることもある. 本ドキュメントは3つの Authenticator Assurance Level 毎に技術要件を定義する. 本ドキュメントの発行をもって, 本ドキュメントは既存の NIST Special Publication 800-63B を置き換えるものとする.

Keywords

authentication; authentication assurance; credential service provider; digital authentication; digital credentials; electronic authentication; electronic credentials; passwords.

翻訳者

Hitomi Kimura
- Trend Micro Inc. (United States)
Nov Matake
- OpenID Foundation Japan エバンジェリスト兼翻訳WGリーダー
- MoneyForward inc.
- YAuth.jp LLC

Note to Reviewers

The rapid proliferation of online services over the past few years has heightened the need for reliable, equitable, secure, and privacy-protective digital identity solutions.

Revision 4 of NIST Special Publication 800-63 Digital Identity Guidelines intends to respond to the changing digital landscape that has emerged since the last major revision of this suite was published in 2017 — including the real-world implications of online risks. The guidelines present the process and technical requirements for meeting digital identity management assurance levels for identity proofing, authentication, and federation, including requirements for security and privacy as well as considerations for fostering equity and the usability of digital identity solutions and technology.

Taking into account feedback provided in response to our June 2020 Pre-Draft Call for Comments, as well as research conducted into real-world implementations of the guidelines, market innovation, and the current threat environment, this draft seeks to:

Advance Equity: This draft seeks to expand upon the risk management content of previous revisions and specifically mandates that agencies account for impacts to individuals and communities in addition to impacts to the organization. It also elevates risks to mission delivery – including challenges to providing services to all people who are eligible for and entitled to them – within the risk management process and when implementing digital identity systems. Additionally, the guidance now mandates continuous evaluation of potential impacts across demographics, provides biometric performance requirements, and additional parameters for the responsible use of biometric-based technologies, such as those that utilize face recognition.
Emphasize Optionality and Choice for Consumers: In the interest of promoting and investigating additional scalable, equitable, and convenient identify verification options, including those that do and do not leverage face recognition technologies, this draft expands the list of acceptable identity proofing alternatives to provide new mechanisms to securely deliver services to individuals with differing means, motivations, and backgrounds. The revision also emphasizes the need for digital identity services to support multiple authenticator options to address diverse consumer needs and secure account recovery.
Deter Fraud and Advanced Threats: This draft enhances fraud prevention measures from the third revision by updating risk and threat models to account for new attacks, providing new options for phishing resistant authentication, and introducing requirements to prevent automated attacks against enrollment processes. It also opens the door to new technology such as mobile driver’s licenses and verifiable credentials.
Address Implementation Lessons Learned: This draft addresses areas where implementation experience has indicated that additional clarity or detail was required to effectively operationalize the guidelines. This includes re-working the federation assurance levels, providing greater detail on trusted referees, clarifying guidelines on identity attribute validation sources, and improving address confirmation requirements.

NIST is specifically interested in comments on and recommendations for the following topics:

Authentication and Lifecycle Management

Are emerging authentication models and techniques – such as FIDO passkey, verifiable credentials, and mobile driver’s licenses – sufficiently addressed and accommodated, as appropriate, by the guidelines? What are the potential associated security, privacy, and usability benefits and risks?
Are the controls for phishing resistance as defined in the guidelines for AAL2 and AAL3 authentication clear and sufficient?
How are session management thresholds and reauthentication requirements implemented by agencies and organizations? Should NIST provide thresholds or leave session lengths to agencies based on applications, users, and mission needs?
What impacts would the proposed biometric performance requirements for this volume have on real-world implementations of biometric technologies?

General

Is there an element of this guidance that you think is missing or could be expanded?
Is any language in the guidance confusing or hard to understand? Should we add definitions or additional context to any language?
Does the guidance sufficiently address privacy?
Does the guidance sufficiently address equity?
- What equity assessment methods, impact evaluation models, or metrics could we reference to better support organizations in preventing or detecting disparate impacts that could arise as a result of identity verification technologies or processes?
What specific implementation guidance, reference architectures, metrics, or other supporting resources may enable more rapid adoption and implementation of this and future iterations of the Digital Identity Guidelines?
What applied research and measurement efforts would provide the greatest impact on the identity market and advancement of these guidelines?

Reviewers are encouraged to comment and suggest changes to the text of all four draft volumes of of the NIST SP 800-63-4 suite. NIST requests that all comments be submitted by 11:59pm Eastern Time on March 24, 2023. Please submit your comments to dig-comments@nist.gov. NIST will review all comments and make them available at the NIST Identity and Access Management website. Commenters are encouraged to use the comment template provided on the NIST Computer Security Resource Center website.

Purpose

This section is informative.

本ドキュメントとそれと対をなす各ドキュメント [SP800-63], [SP800-63A], そして [SP800-63C] は, Digital Identity Service を実装する組織に向けた技術的ガイドラインを提供するものである.

このドキュメント, SP 800-63Bは, 3つの Authentication Assurance Levels (AALs) のそれぞれでのRemote User Authenticationのための Credential Service Providers (CSPs) に対する要件を提供するものである.

Introduction

This section is informative.

Digital Authentication は, Digital Identity を主張するために使用される1つかそれ以上の Authenticator の有効性を判断するプロセスである. Authentication は, デジタルサービスにアクセスしようとしている Subject が,Authentication に使用される技術を制御していることを立証する. 再訪問の対象となるサービスの場合, Authentication に成功することは今日サービスにアクセスする Subject が以前サービスにアクセスした Subject と同じであるという合理的なリスクベースの保証を提供する.

Subscriber の進行中の Authentication は, Subscriber をそれらのオンラインアクティビティ (つまり, Subscriber Account) に関連付けるプロセスの中心である. Subscriber Authentication は, 特定のSubscriber Account に関連付けられた1つかそれ以上の Authenticator (SP 800-63 の一部の以前のバージョンでは Token と呼ばれる) を Claimant が制御していることを検証することによって実行される. Authentication の成功は, Pseudonymous または Non-Pseudonymous Identifierと, 選択に応じてその他の identity 情報が Relying Party (RP) に Assertion される.

このドキュメントでは, さまざまな Authentication Assurance Level (AAL) で使用される可能性がある, Authenticator の選択を含む Authentication プロセスのタイプに関する推奨事項を提供する. また紛失や盗難が発生した場合の失効を含む Authenticator のライフサイクルに関する推奨事項も提供する.

この技術ガイドラインは, Subject のネットワーク越しのシステムに対する Digital Authentication に適用される. デジタルアクセスに使用されるいくつかの Credential は物理アクセスの Authentication にも使用される場合があるが, 本ガイドラインは (例: 建物などへの) 物理アクセスに対する個人の Authentication には対応しない. この技術ガイドラインでは, Authentication プロトコルに参加する Federal システムとサービスプロバイダーが Subscriber に対して Authenticate されることも要求する.

AAL は, Authentication Transaction の強度を, 順序のあるカテゴリとして特徴づけることができる. より強力な Authentication (より高い AAL) は, 悪意のあるアクターが Authentication プロセスの転覆を成功させるために, より優れた能力を持ち, より大きなリソースを消費することを必要とする. より高い AAL での Authentication は, Attack のリスクを効果的に減らすことができる. 各 AAL の技術要件の概要を以下に示す. 特定の Normative Requirement についてはこのドキュメントの Sec. 4 と Sec. 5 を参照のこと.

Authentication Assurance Level 1: AAL1 は, Claimant が Subscriber Account に Bind された Authenticator を制御するというある程度の保証を提供する. AAL1 は, 利用可能な幅広い Authentication 技術を使用した Single-Factor または Multi-Factor の Authentication を必要とする. Authentication の成功には, Claimant がセキュアな Authentication プロトコルを介して Authenticator の所有と制御を証明する必要がある.

Authentication Assurance Level 2: AAL2 は, Claimant が Subscriber Account に Bind された1つかそれ以上の Authenticator を制御するという高い確信を提供する. セキュアな Authentication プロトコルを介して, 2つの異なる Authentication Factor の所有と制御の証明が必要である. AAL2 以上では, Approved な暗号技術が必要である.

Authentication Assurance Level 3: AAL3 は, Claimant が Subscriber Account に Bind された1つかそれ以上の Authenticator を制御するという非常に高い確信を提供する. AAL3 での Authentication は, 暗号プロトコルを介した Key の所有の証明に基づく. AAL3 Authentication は, ハードウェアベースの Authenticator と Phishing 耐性のある Authenticator を必要とし(Sec. 5.2.5 を参照), 同じデバイスがこれらの両方の要件を満たす場合がある. AAL3 で Authentication を行うには, Claimant は, セキュアな Authentication プロトコルを介して, 2つのはっきりと異なる Authentication Factor の所有と制御を証明する必要がある. Approved な暗号技術が必要である.

次のリストは, ドキュメントのどのセクションが Normative で, どのセクションが Informative であるかを示す.

1 Purpose Informative
2 Introduction Informative
3 Definitions and Abbreviations Informative
4 Authentication Assurance Levels Normative
5 Authenticator and Verifier Requirements Normative
6 Authenticator Lifecycle Management Normative
7 Session Management Normative
8 Threat and Security Considerations Informative
9 Privacy Considerations Informative
10 Usability Considerations Informative
11 Equity Considerations Informative
References Informative
Appendix A Strength of Memorized Secrets Informative
Appendix B Change Log Informative

Definitions and Abbreviations

定義と略語の完全な組み合わせについては [SP800-63] Appendix A を参照.

Authentication Assurance Levels

This section is normative.

与えられた AAL の要件を満たし, Subscriber として認識されるためには, Claimant は, そのレベルの要件と同等, またはそれ以上の強度のプロセスで Authenticate されることとする(SHALL). Authentication プロセスの結果は, Subscriber がその RP に対して Authentication する, それぞれの回で使用されることになる(SHALL) Identifier である. Identifier は Pseudonymous であってもよい(MAY). Subscriber Identifier は別の Subject に再利用されないほうがよい(SHOULD NOT)が, 以前に登録された Subject が CSP によって再登録された場合に再利用する必要がある(SHOULD). Subscriber を一意の Subject として識別するその他の属性も提供されることがある(MAY).

各 AAL での Authenticator と Verifier の詳細な Normative Requirement は Sec. 5 で提供される.

最も適切な AAL を選択する方法の詳細については [SP800-63] Sec. 5 を参照.

[FIPS140] 要件は, FIPS 140-3 か, それ以降のリビジョンで満たされる.

Identity Proofing の最中およびその後に収集された Personal Information は, Digital Identity サービスを介して Subscriber が利用できるようにしてもよい(MAY). 連邦政府機関によって任意の PII またはその他の Personal Information が開示されたりオンラインで利用可能になる場合, その情報が Self-asserted か Validated かにかかわらず, [EO13681] に従って Multi-Factor Authentication が要求される. したがって連邦政府機関は, PII またはその他の Personal Information をオンラインで利用可能にする場合には, 最低限 AAL2 を選択することになる(SHALL).

Authentication Assurance Level 1

AAL1 は, Claimant が Subscriber Account に Bind された Authenticator を制御するというある程度の保証を提供する. AAL1 は, 利用可能な幅広い Authentication 技術を使用した Single-Factor または Multi-Factor の Authentication を必要とする. Authentication の成功には, Claimant がセキュアな Authentication プロトコルを介して Authenticator の所有と制御を証明する必要がある.

Permitted Authenticator Types

AAL1 Authentication は, Sec. 5で定義されているいずれかの Authenticator タイプを使用することで発生することになる(SHALL).

Memorized secret (Sec. 5.1.1)
Look-Up secret (Sec. 5.1.2)
Out-of-band device (Sec. 5.1.3)
Single-factor one-time password (OTP) device (Sec. 5.1.4)
Multi-factor OTP device (Sec. 5.1.5)
Single-factor cryptographic software (Sec. 5.1.6)
Single-factor cryptographic device (Sec. 5.1.7)
Multi-factor cryptographic software (Sec. 5.1.8)
Multi-factor cryptographic device (Sec. 5.1.9)

Authenticator and Verifier Requirements

AAL1 で使用される Cryptographic Authenticator は Approved な暗号を使用することになる(SHALL). オペレーティングシステムのコンテキスト内で動作する Software-Based Authenticator は, 可能な場合, それらが実行中のユーザーエンドポイントで(例: マルウェアによる)侵害の検出を試みてもよい(MAY). また, そのような侵害が検出された場合は操作を完了しないほうがよい(SHOULD NOT).

Claimant と Verifier の間の通信は, Authenticator Output の Confidentiality (機密性) と Adversary-in-the-Middle (AitM) Attack への耐性の提供のため, Authenticated Protected Channel を介して行われることになる(SHALL).

連邦政府機関によって, または連邦政府機関に代わって AAL1 で運用されている Verifier は, [FIPS140] Level 1 の要件に適合しているか検証されることになる(SHALL).

Reauthentication

Subscriber Session の定期的な Reauthentication は, Sec. 7.2 で説明される通りに実行されることになる(SHALL). AAL1 では, Subscriber の Reauthentication は, ユーザーのアクティビティに関係なく, 延長使用 Session の間は少なくとも30日に1回繰り返される必要がある(SHOULD).

Security Controls

CSP は, [SP800-53] または同等の連邦 (例: [FEDRAMP]) ないし業界標準で定義されたベースラインセキュリティコントロールから適切に調整されたセキュリティコントロールを採用することになる(SHALL). 参考とするガイドラインは, 保護する対象となる情報システム, アプリケーション, オンラインサービスのために組織が決定すること. CSP は, 適切なシステムまたは同等のシステムに対する最低限の assurance-related controls が満たされていることを保証することになる(SHALL).

Records Retention Policy

CSP は, 適用される可能性のある National Archives and Records Administration (NARA) の記録保持スケジュールを含む, 適用される法律, 規制, およびポリシーに従って, それぞれの記録保持ポリシーを遵守することになる(SHALL). CSP が必須要件がない場合に記録を保持することを選択した場合, CSP は, 記録を保持する期間を決定するためにプライバシーおよびセキュリティリスクのアセスメントを含むリスク管理プロセスを実施することになる(SHALL). また, そのリテンションポリシーを Subscriber へ通知することになる(SHALL).

Authentication Assurance Level 2

AAL2 は, Claimant が Subscriber Account に Bind された Authenticator を制御するという高い確信を提供する. セキュアな Authentication プロトコルを介して, 2つの明確に異なる Authentication Factor の所有と制御の証明が必要である. AAL2 以上では, Approved な暗号技術が必要である.

Permitted Authenticator Types

AAL2 Authentication は, Multi-Factor Authenticator か, 2つの Single-Factor Authenticator の組み合わせのいずれかを使用することで発生することになる (SHALL). Multi-Factor Authenticator は, 単一の Authentication イベントを実行するために2つの要素を必要とする. 例として, デバイスを Activate するために必要となる Biometric センサーが統合された暗号的にセキュアなデバイスなどが挙げられる. Authenticator の要件は Sec. 5 に指定されている.

Multi-Factor Authenticator が使用されるとき, 以下のいずれかが使用されてもよい(MAY).

Multi-Factor Out-of-Band Authenticator (Sec. 5.1.3.4)
Multi-Factor OTP Device (Sec. 5.1.5)
Multi-Factor Cryptographic Software (Sec. 5.1.8)
Multi-Factor Cryptographic Device (Sec. 5.1.9)

2つの Single-Factor Authenticator の組み合わせが使用されるとき, その組み合わせは, 以下のリストから1つの Memorized Secret Authenticator (Sec. 5.1.1) と 1つの物理 Authenticator (すなわち, “something you have”) を含むことになる(SHALL).

Look-Up Secret (Sec. 5.1.2)
Out-of-Band Device (Sec. 5.1.3)
Single-Factor OTP Device (Sec. 5.1.4)
Single-Factor Cryptographic Software (Sec. 5.1.6)
Single-Factor Cryptographic Device (Sec. 5.1.7)

Note: Biometric Authentication が Sec. 5.2.3 の要件を満たすとき, Biometric の一致に加えて, デバイスが Authenticate されなければならない. Biometric の特徴は1つの要素として認識されるが, それ自体は Authenticator とは認識されない. したがって, Biometric の特徴による Authentication を行う場合, 関連付けられたデバイスは “something you have” として働き, 同時に Biometric の一致は “something you are” として働くため, 2つの Authenticator を使用することは不要である.

Authenticator and Verifier Requirements

AAL2 で使用される Cryptographic Authenticator は Approved Cryptography を使用することになる(SHALL). 連邦政府機関によって調達された Authenticator は [FIPS140] Level 1 の要件に適合していることを検証されることになる(SHALL). オペレーティングシステムのコンテキスト内で動作する Software-Based Authenticator は, 可能な場合, それらが実行中のプラットフォームで(例: マルウェアによる)侵害の検出を試みてもよい(MAY). また, そのような侵害が検出された場合は操作を完了しないべきである (SHOULD NOT). AAL2 で使用される少なくとも1つの Authenticator は, Sec. 5.2.8 で説明されているように, リプレイ耐性を持つことになる(SHALL). AAL2 での Authentication は, Sec. 5.2.9 で説明されているように, 少なくとも1つの Authenticator から Authentication Intent を実施する必要がある(SHOULD).

Claimant と Verifier の間の通信は, Authenticator Output の Confidentiality (機密性) と AitM Attack への耐性の提供のため, Authenticated Protected Channel を介して行われることになる(SHALL).

連邦政府機関によって, または連邦政府機関に代わって AAL2 で運用されている Verifier は, [FIPS140] Level 1 の要件に適合しているか検証されることになる(SHALL).

AAL2 での Authentication に Bimetric Factorが使用される場合, Sec. 5.2.3 で述べられるパフォーマンス要件を満たすことになり(SHALL), Verifier は Bometric センサーとその後の Processing がこれらの要件を満たしていることを判断するべきである(SHOULD).

OMB Memorandum [M-22-09] は, 連邦政府機関に対して AAL2 のパブリックユーザーに少なくとも1つの Phishing 耐性のある Authenticator のオプションを提供することを要求している. Sec. 5.2.5 で説明されている Phishing 耐性は通常 AAL2 での Authentication には必要とされないが, Phishing は重大な脅威ベクトルであるため, Verifier は可能な限り AAL2 での Phishing 耐性のある Authenticator の使用を奨励するべきである(SHOULD).

Reauthentication

Subscriber Session の定期的な Reauthentication は, Sec. 7.2 で説明される通りに実行されることになる(SHALL). AAL2 では, Subscriber の Authentication は, ユーザーのアクティビティに関係なく, 延長使用 Session の間は少なくとも12時間に1回繰り返されることになる(SHALL). Subscriber の Reauthentication は, 30分以上続く非アクティブ期間の後に繰り返されることになる(SHALL). これらのタイムリミットのいずれかに到達した場合, Session は終了(つまり, ログアウト)されることになる(SHALL).

タイムリミットにまだ到達していない Session の Reauthentication には, Memorized Secret またはまだ有効な Session Secret と組み合わせた Biometric のみが必要とされるとしてもよい(MAY). Verifier は, 非アクティブタイムアウトの直前に, アクティビティを行うようにユーザーを促してもよい(MAY).

Security Controls

Records Retention Policy

CSP は, 適用される可能性のある NARA の記録保持スケジュールを含む, 適用される法律, 規制, およびポリシーに従って, それぞれの記録保持ポリシーを遵守することになる(SHALL). CSP が必須要件がない場合に記録を保持することを選択した場合, CSP は, 記録を保持する期間を決定するためにプライバシーおよびセキュリティリスクのアセスメントを含むリスク管理プロセスを実施することになる(SHALL). また, そのリテンションポリシーを Subscriber へ通知することになる(SHALL).

Authentication Assurance Level 3

AAL3 は, Claimant が Subscriber Account に Bind された Authenticator を制御するという非常に高い確信を提供する. AAL3 での Authentication は, 暗号プロトコルを介した Key の所有の証明に基づく. ハードウェアベースの Authenticator とPhishing 耐性のある Authenticator を使用することになり(SHALL), 同じデバイスがこれらの両方の要件を満たしてもよい(MAY). AAL3 で Authentication を行うには, Claimant は, セキュアな Authentication プロトコルを介して, 2つのはっきりと異なる Authentication Factor の所有と制御を証明することになる(SHALL). Approved な暗号技術が必要である.

Permitted Authenticator Types

AAL3 Authentication は, Sec. 4.3 の要件を満たす Authenticator の組み合わせのうちのひとつを使用することで発生することになる(SHALL). 可能性のある組み合わせは:

Multi-Factor Cryptographic Device (Sec. 5.1.9)
Single-Factor Cryptographic Device (Sec. 5.1.7) used in conjunction with a Memorized Secret (Sec. 5.1.1)
Multi-Factor OTP device (software or hardware) (Sec. 5.1.5) used in conjunction with a Single-Factor Cryptographic Device (Sec. 5.1.7)
Multi-Factor OTP device (hardware only) (Sec. 5.1.5) used in conjunction with a Single-Factor Cryptographic Software (Sec. 5.1.6)
Single-Factor OTP device (hardware only) (Sec. 5.1.4) used in conjunction with a Multi-Factor Cryptographic Software Authenticator (Sec. 5.1.8)

Authenticator and Verifier Requirements

Claimant と Verifier の間の通信は, Authenticator Output の Confidentiality (機密性) と AitM Attack への耐性の提供のため, Authenticated Protected Channel を介して行われることになる(SHALL). AAL3で使用される少なくとも1つの Authenticator は, Sec. 5.2.5 で説明されているようにPhishing 耐性があり(SHALL), Sec. 5.2.8 で説明されているようにリプレイ耐性があることになる(SHALL). AAL3 でのすべての Authentication と Reauthentication は, Sec. 5.2.9 で説明されているように, 少なくとも1つの Authenticator から Authentication Intent を示す必要がある(SHOULD).

AAL3 で使用される Multi-factor Authenticator は, [FIPS140] レベル 2 以上で検証されたハードウェア暗号モジュールか, 少なくとも [FIPS140] レベル 3 を全体的に上回る物理セキュリティとなる(SHALL). AAL3 で使用される Single-factor Cryptographic Device は, [FIPS140] レベル 1 で検証されるか, 少なくとも [FIPS140] レベル 3 を全体的に上回る物理セキュリティとなる(SHALL).

AAL3 の Verifier は, [FIPS140] レベル 1 かそれ以上で検証されることになる(SHALL).

AAL3 の Verifier は, Sec. 5.2.7 で説明されているように, 少なくとも1つの Authentication Factor に関して, Verifier の危殆化耐性があることになる(SHALL).

AAL3 のハードウェアベースの Authenticator と Verifier は, 関連する Side-Channel Attack (例: タイミングや消費電力の分析) に resist する必要がある(SHOULD).

AAL3 での Authentication に Biometric Factor が使用される場合, Verifier は Bometric Sensor とその後の Processing が Sec. 5.2.3 で述べられるパフォーマンス要件を満たしていることを判断することになる(SHALL).

Reauthentication

Subscriber Session の定期的な Reauthentication は, Sec. 7.2 で説明される通りに実行されることになる(SHALL). AAL3 では, Sec. 7.2で説明される通り, Subscriber の Authentication は, ユーザーのアクティビティに関係なく, 延長使用 Session の間は少なくとも12時間に1回繰り返されることになる(SHALL). Subscriber の Reauthentication は, 15分以上続く非アクティブ期間の後に繰り返されることになる(SHALL). Reauthentication は両方の Authentication Factor を使用することになる(SHALL). これらのタイムリミットのいずれかに到達した場合, Session は終了(つまり, ログアウト)されることになる(SHALL). Verifier は, 非アクティブタイムアウトの直前に, アクティビティを行うようにユーザーを促してもよい(MAY).

Security Controls

Records Retention Policy

Privacy Requirements

CSP は, [SP800-53] または同等の業界標準で定義された, 適切に誂えられたプライバシーコントロールを採用することになる(SHALL).

CSP が Identity Proofing, Authentication, Attribute Assertion (総称して “Identity Service”), 関連する不正行為の軽減, または法律や法的手続きの遵守以外の目的で Attribute を処理する場合, CSP は追加の処理から生じるプライバシーのリスクに見合った Predictability と Manageability を維持するための手段を実装することになる(SHALL). 手段には, 明確な通知の提供, Subscriber の同意の取得, Attribute の選択的な使用・開示の有効化を含んでもよい(MAY). CSP が同意を手段として使用する場合, CSP は追加の処理の同意を Identity Service の条件にしてはならない(SHALL NOT).

CSP が政府機関であるか民間セクターの Provider であるかに関わらず, Authentication Service を提供または使用する連邦政府機関には, 以下の要件が適用される:

政府機関は, Senior Agency Official for Privacy (SAOP) と相談し, Authenticator を発行または維持するための PII の収集が [PrivacyAct] (Sec. 9.4 を参照) の要件をトリガーするかどうか判断するために分析を実施することになる(SHALL).
政府機関は, 該当する場合, そのような収集を対象とする System of Records Notice (SORN) を公開することになる(SHALL).
政府機関は, SAOP と相談し, Authenticator を発行または維持するための PII の収集が E-Government Act of 2002 [E-Gov].の要件をトリガーするかどうか判断するために分析を実施することになる(SHALL).
政府機関は, 該当する場合, そのような収集を対象とする Privacy Impact Assessment (PIA) を公開することになる(SHALL).

Summary of Requirements

Table 1 は, 各 AAL の要件の non-normative な要約を提供する.

Table 1 AAL Summary of Requirements

Requirement	AAL1	AAL2	AAL3
Permitted authenticator types	Memorized Secret; Look-up Secret; Out-of-Band; SF OTP Device; MF OTP Device; SF Crypto Software; SF Crypto Device; MF Crypto Software; MF Crypto Device	MF Out-of-Band; MF OTP Device; MF Crypto Software; MF Crypto Device; or Memorized Secret plus: Look-up Secret, Out-of-Band, SF OTP Device, SF Crypto Software, SF Crypto Device	MF Crypto Device; SF Crypto Device plus Memorized Secret; SF OTP Device plus MF Crypto Device or Software; SF OTP Device plus SF Crypto Software plus Memorized Secret
FIPS 140 validation	Level 1 (Government agency verifiers)	Level 1 (Government agency authenticators and verifiers)	Level 2 overall (MF authenticators) Level 1 overall (verifiers and SF Crypto Devices) Level 3 physical security (all authenticators)
Reauthentication	30 days	12 hours or 30 minutes inactivity; one authentication factor	12 hours or 15 minutes inactivity; both authentication factors
Security controls	[SP800-53] Low Baseline (or equivalent)	[SP800-53] Moderate Baseline (or equivalent)	[SP800-53] High Baseline (or equivalent)
AitM resistance	Required	Required	Required
Phishing resistance	Not required	Recommended	Required
Verifier-compromise resistance	Not required	Not required	Required
Replay resistance	Not required	Required	Required
Authentication intent	Not required	Recommended	Required

Authenticator and Verifier Requirements

This section is normative.

このセクションでは, 各 Authenticator タイプ固有の詳細な要件を提供する. Sec. 4で指定された Reauthentication の要件および Sec. 5.2.5 で説明された AAL3 での Phishing 耐性のための要件を除いて, Authenticator が使用される AAL に関係なく, 各 Authenticator タイプの技術要件は同じである.

Requirements by Authenticator Type

Memorized Secrets

Memorized Secret Authenticator — 一般に Password または数値の場合は PIN と言われる — は, ユーザーによって選択され記憶されることを意図した秘密の値である. Memorized Secret は, Attacker が正しい Secret Value を推測または発見することが現実的でないように, 十分に複雑で秘匿されている必要がある. Memorized Secret は something you know である.

このセクションの要件は, Authenticated Protected Channel を介して CSP の Verifier に送信される, 独立した Authentication Factor として使用される中央で検証された Memorized Secret に適用される. Multi-Factor Authenticator によってローカルで使用される Memorized Secret は, Activation Secret と呼ばれ, Sec. 5.2.11 で議論される.

Memorized Secret Authenticators

Memorized Secret は, 長さが少なくとも8文字となる(SHALL). Memorized Secret は, Subscriber によって選択されるか, CSP によってランダムに割り当てられることとなる(SHALL).

CSP が, 頻繁に使用される, 予期される, または侵害されている値の Blocklist にあるために, 選択された Memorized Secret を許可しない場合 (Sec. 5.1.1.2 を参照), Subscriber は別の Memorized Secret を選択することになる(SHALL). Memorized Secret に他の複雑さの要件が課されることはない(SHALL). この根拠は, Appendix A Strength of Memorized Secrets に示される.

Memorized Secret Verifiers

Verifier は, 長さが少なくとも8文字の Memorized Secret を要求することとする(SHALL). Verifier は, Memorized Secret の長さが少なくとも64文字であることを許可する必要がある(SHOULD). すべての Printing ASCII 文字 [RFC20] と空白文字は Memorized Secret に受け入れられる必要がある(SHOULD). Unicode 文字 [ISO/ISC 10646] も同様に受け入れられる必要がある(SHOULD). Verifier は, Verification の前に先頭と末尾の空白文字を削除したり, 先頭の文字の大文字と小文字が異なる Memorized Secret の Verification を許可したり, 残りの文字数が8文字以上ある場合に先頭の文字の大文字・小文字が異なっていることを許したりなど, タイプミスの可能性を許容してもよい(MAY).

Verifier は, 提出された Memorized Secret 全体を検証することになる(SHALL)(つまり, Secret を切り詰めない). 前述の長さの要件に関して, 各 Unicode コードポイントは1文字としてカウントされることになる(SHALL).

Memorized Secret でUnicode文字が受け入れられる場合, Verifier は Sec. 12.1 of Unicode Normalization Forms [UAX15] で定義された NFKC または NFKD 正規化を使用して, スタビライズされた文字列の正規化プロセスを適用する必要がある(SHOULD). このプロセスは, Memorized Secret を表すバイト文字列をHash する前に適用される. Unicode 文字を含む Memorized Secret を選択する Subscriber は, 一部の文字が一部のエンドポイントによって異なる方法で表現される可能性があることを通知される必要がある(SHOULD). これは, 正常に Authenticate する能力に影響を与える可能性がある.

Memorized Secret の Verifier は, Subscriber に対して, Authenticate されていない Claimant がアクセスできるヒントを保存することを許可することはない(SHALL NOT). Verifier は, Memorized Secret を選択する際に, Subscriber に特定の種類の情報 (例えば, 「あなたの最初のペットの名前は何ですか?」といった Knowledge-Based Authentication (KBA) または秘密の質問として知られる手法) を使用するように促すことはない(SHALL NOT).

Memorized Secret を確立および変更するリクエストを処理するとき, Verifier は, 頻繁に使用される, 予期される, または侵害されていることが知られている値を含む Blocklist と, リクエストされた Secret を比較することになる(SHALL). 例えば, リストには以下を含んでもよい(MAY) が, これらに限定されない:

以前の侵害事例から得られた Password.
辞書の単語.
反復または連続した文字 (例: ‘aaaaaa’, ‘1234abcd’).
サービスの名前, ユーザー名, およびその派生語など, コンテキスト特有の単語.

選択された Secret が Blocklist の中にある場合, CSP または Verifier は Subscriber に別の Secret を選択する必要があることを通知することとなり(SHALL), 拒否の理由を提供することになり(SHALL), Subscriber に別の値を選択することを要求することになる(SHALL). Blocklist はブルートフォース Attack を防御するために使用され, 試行の失敗は以下で説明するようにレート制限されるため, Blocklist は Subscriber が Attacker が試行リミットに到達する前に推測する可能性のある Memorized Secret を選択することを防ぐのに十分なサイズにする必要がある(SHOULD). 過度に大きな Blocklist は使用しないほうがよい(SHOULD NOT). これは, Subscriber が許容される Memorized Secret を確立しようとする試みを妨げ, 大幅に改善されたセキュリティを提供しないためである.

Verifierは, 強力な Memorized Secret を選択する際にユーザーを支援するために, Subscriber にガイダンスを提供することとなる(SHALL). これは, リストされた (そしておそらく非常に弱い) Memorized Secret への浅はかな変更を思いとどまらせるため, 上記のリストにある Memorized Secret の拒否に続いて特に重要である. [Blocklists]

Verifier は, Sec. 5.2.2 で説明されている通り, Subscriber Account で試行できる Authentication の失敗回数を効果的に制限するレート制限メカニズムを実装することとなる(SHALL).

Verifier は, Memorized Secret に他の構成ルールを課すことはない(SHALL NOT) (例: 異なる文字タイプの混合の要求, 連続して繰り返される文字の禁止). Verifier は, Memorized Secret を定期的に変更することをユーザーに要求することはない(SHALL NOT). ただし, Authenticator の侵害の証拠がある場合, Verifier は変更を強制することとなる(SHALL).

Verifier は, Passwordマネージャーの使用を許可することになる(SHALL). それらを使用しやすくするために, Verifier は, Memorized Secret を入力するときに, Claimant が「貼り付け」機能の使用を許可ことになる(SHALL). Passwordマネージャーは, ユーザーがより強力な Memorized Secret を選択する可能性を高める場合がある.

Claimant が Memorized Secret を正常に入力することを支援するために, Verifier は, 入力されている間および Verifier に送信されるまで, 一連のドットやアスタリスクではなく, Secret を表示するオプションを提供する必要がある(SHOULD). これにより Claimant は, 自分の画面が観察される可能性が低い場所にいる場合, 自分の入力を確認できる. Verifier は, 各文字が入力された後, 正しく入力したかを確認するために入力された個々の文字を短時間表示することを Claimant のデバイスに許可してもよい(MAY). これは, モバイルデバイスでは一般的である.

Verifier は, Memorized Secret を要求するときには, 盗聴や Adversary-in-the-Middle Attack に対する耐性を提供するために, Approved な暗号による暗号化と Authenticated Protected Channel を使用することになる(SHALL).

Verifier は, Memorized Secret を Offline Attack に耐性のある形式で保存することになる(SHALL). Memorized Secret は, 適切な Password Hash スキームを使用して Salt および Hash されることになる(SHALL). Password Hash スキームは, Password, Salt, およびコストファクターを入力として受け取り, Password Hash を生成する. それらの目的は, Hash された Password ファイルを取得した Attacker に対して, 各 Password の推測をより高価なものにし, それによって推測攻撃のコストを高くしたり法外なものにしたりすることである. Attack のコストを増加させるため, Memory-Hard と Compute-Hard の両方の性質を持つ関数を使用する必要がある(SHOULD). NIST は特定の Password Hash スキームに関するガイドラインを公開していないが, そのような関数の例には Argon2 [Argon2] や scrypt [Scrypt] などがある. Approved な一方向関数の例には, Keyed Hash Message Authentication Code (HMAC) [FIPS198-1], [SP800-107] で Approved ないずれかの Hash 関数, Secure Hash Algorithm 3 (SHA-3) [FIPS202], CMAC [SP800-38B], Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), および ParallelHash [SP800-185] が含まれる. Password Hash スキームが処理した出力の長さは, 基になる一方向関数の出力の長さと同じである必要がある(SHOULD).

Salt は長さが少なくとも 32 ビットとなり, 保存された Hash 間の Salt 値の衝突を最小限に抑えるためにばらついて選択されることとなる(SHALL). Salt 値と結果の Hash の両方が, Memorized Secret Authenticator ごとに保存されることとなる(SHALL).

Password-based Key Derivation Function 2 (PBKDF2) [SP800-132] の場合, コストファクターは反復回数である. PBKDF2 関数が反復される回数が多いほど, Password Hash の計算に時間がかかる. したがって, 反復回数は, Verification サーバのパフォーマンスが許す限り大きくする必要がある(通常, 少なくとも10,000回の反復)(SHOULD).

さらに, Verifier は, Verifier のみが知っている Secret Key を使用して, 鍵付き Hash または暗号化オペレーションの追加の反復を実行する必要がある(SHOULD). この Key 値を使用する場合, Approved Random Bit Generator [SP800-90Ar1] によって生成され, 少なくとも NIST SP 800-131A Transitioning the Use of Cryptographic Algorithms and Key Lengths [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度を提供することとなる(この発行日時点で112ビット)(SHALL). Secret Key の値は, Hash された Memorized Secret とは別に保存されることとなる(例えば, Hardware Security Moduleのような特別なデバイスに)(SHALL). この追加の反復により, Secret Key の値が秘密のままである限り, Hash された Memorized Secret に対するブルートフォース Attack は非現実的である.

Look-Up Secrets

Look-up Secret Authenticator は, Claimant と CSP の間で共有される一連の Secret を格納する物理的または電子的な記録である. Claimant は, Verifier からのプロンプトに応答するために必要な, 適切な Secret を見つけるために Authenticator を使用する. 例えば, Verifier は, 表形式でカードに印刷された数値または文字列の特定のサブセットを提供するように Claimant に尋ねることができる. Look-up Secret の一般的な用途は, 別の Authenticator が紛失されたり故障した場合に使用するために, Subscriber によって保管された1回限りの”回復キー”としての使用である. Look-up Secret は something you have である.

Look-Up Secret Authenticators

Look-up Secret Authenticator を作成する CSP は, Approved Random Bit Generator [SP800-90Ar1] を使用して Secret のリストを生成することとなり(SHALL), Authenticator を Subscriber に安全に配布することとなる(SHALL). Look-up Secret は, 少なくとも20ビットの Entropy を持つこととなる(SHALL).

Look-up Secret Authenticator は, CSP が対面で, Subscriber の Address of Record へ郵便で, またはオンラインで配布してもよい(MAY). オンラインで配布される場合, Look-up Secret は Sec. 6.1.2 にある Post-Enrollment Binding の要件に従って, セキュアなチャネルを介して配布されることとなる(SHALL).

Authenticator がリストからシーケンシャルに Look-up Secret を使用する場合, Authentication が成功した後に限り, Subscriber は使用済みの Secret を破棄してもよい(MAY).

Look-Up Secret Verifiers

Look-up Secret の Verifier は, Claimant に, 彼らの Authenticator からの次の Secret, または特定の (例えば, 番号が振られた) Secret を要求することとなる(SHALL). Authenticator から与えられた Secret は, 一度だけ成功として使用されることとなる(SHALL). Look-up Secret がグリッドカードから得られたものである場合, グリッドの各セルは一度だけ使用されることとなる(SHALL).

Verifier は, Offline Attack に耐性のある形式で Look-up Secret を保存することとなる(SHALL). 少なくとも 112 ビットの Entropy を持つ Look-up Secret は, Sec. 5.1.1.2 で述べられた通り, Approved な一方向関数で Hash されることとなる(SHALL). Entropy が 112 ビット未満の Look-up Secret は, 同様にSec. 5.1.1.2で述べられた通り, Salt 化され適切な Password Hash スキームを使用して Hash されることとなる(SHALL). Salt 値は長さが少なくとも 32 ビットとなり, 保存された Hash 間の Salt 値の衝突を最小限に抑えるためにばらついて選択されることとなる(SHALL). Salt 値と結果の Hash の両方が, Look-up Secret ごとに保存されることとなる(SHALL).

Entropy が 64 ビット未満の Look-up Secret の場合, Verifier は, Sec. 5.2.2 で説明されている通り, Subscriber Account で試行できる Authentication の失敗回数を効果的に制限するレート制限メカニズムを実装することとなる(SHALL).

Verifier は, Look-up Secret を要求するときには, 盗聴や AitM Attack に対する耐性を提供するために, Approved な暗号による暗号化と Authenticated Protected Channel を使用することになる(SHALL).

Out-of-Band Devices

Out-of-band Authenticator は, 一意にアドレス指定が可能で, セカンダリチャネルと呼ばれる個別の通信チャネルを介して Verifier と安全に通信できる物理デバイスである. デバイスは Claimant によって所有および制御され, Authentication のためのプライマリチャネルとは別に, このセカンダリチャネルを介したプライベート通信をサポートする. Out-of-band Authenticator は something you have である.

Out-of-band Athentiction は, Verifier によって生成された短期的な Secret を使用する. Secret の目的は, プライマリとセカンダリチャネルでの Athentiction 操作を安全にバインドし, Claimant による Out-of-band デバイスの制御を確立することである.

Out-of-band Authenticator は以下のいずれかの方法で動作できる:

Claimant は, Out-of-band デバイスによってセカンダリチャネルを介して受信した Secret を, プライマリチャネルを使用して Verifier に転送する. 例えば, Claimant はモバイルデバイスで Secret (通常は6桁のコード) を受信し, それを Authentication Session に入力してもよい. この方法は Figure 1 に示される.

Figure 1. Transfer of Secret to Primary Device

Diagram showing authentication secret being transferred from out-of-band device to session being authenticated

Claimant は, セカンダリチャネルを介して Verifier に送信するために, プライマリチャネルを介して受信した Secret を Out-of-band デバイスに転送する. 例えば, Claimant は Authentication Session 上で Secret を表示し, モバイルデバイスのアプリにそれを入力するか, バーコードやQRコードなどのテクノロジーを使用して転送を行ってもよい. この方法は Figure 2 に示される.

Figure 2. Transfer of Secret to Out-of-band Device

Diagram showing authentication secret being transferred from session being authenticated to out-of-band device

注: 三番目の方法であった, プライマリとセカンダリチャネルから受信した Secret の比較とセカンダリチャネルでの承認による Out-of-band Authentication は, 説明された通りに実装されることは稀であったため, もはや受け入れられないと見なされる. これは Claimant が Secret を実際に比較せず単に承認する可能性を高くしていた. 例えば, Verifier からプッシュ通知を受け取り, 単に Claimant に Transaction の承認を求めるだけの Authenticator は (たとえ Authentication に関する追加情報を提供したとしても), このセクションの要件を満たさない.

Out-of-Band Authenticators

Out-of-band Authenticator は, Out-of-band Secret または Authentication 要求を取得するために, Verifier と別のチャネルを確立することとなる(SHALL). このチャネルは, デバイスが Claimant の許可なしにひとつのチャネルから別のチャネルに情報を漏らさないという条件であれば, (たとえ同じデバイス上で完了する場合でも) プライマリ通信チャネルに関して Out-of-band であると見なされる.

Out-of-band デバイスは, Verifier によって一意にアドレス指定が可能である必要がある(SHOULD). セカンダリチャネルを介した通信は, 公衆交換電話網 (Public Switched Telephone Network, PSTN) 経由で送信されない限り, 暗号化されることとなる(SHALL). Out-of-band Authentication のために PSTN を使用する場合の追加の Authenticator 要件については, Sec. 5.1.3.3 を参照のこと. Voice-Over-IP (VOIP) 電話番号など, 特定のデバイスの所有を証明しないチャネルまたはアドレスは, Out-of-band Authentication に使用されることはない(SHALL NOT).

電子メールは特定のデバイスの所有を証明するものではなく, 通常は Memorized Secret のみを使用してアクセスされるため, Out-of-band Authentication に使用されることはない(SHALL NOT).

Out-of-band Authenticator は, Verifier と通信するときに, 以下のいずれかの方法で自身を一意に Authentication することとなる(SHALL).

Approved Cryptography を使用して, Verifier への Authenticated Protected Channel を確立する. 使用されるキーは, Authenticator アプリケーションが利用可能な, 適切に安全なストレージ (例: キーチェーンストレージ, TPM, TEE, セキュアエレメントなど) に格納することとなる(SHALL).

デバイスを一意に識別する SIM カードまたは同等のものを使用して, 公衆携帯電話ネットワークに対して Authentication する. このメソッドは, Secret が Verifier から PSTN (SMS または音声) 経由で Out-of-band デバイスに送信される場合にのみ使用されることとなる(SHALL).

Verifier によって Out-of-band デバイスに Secret が送信される場合, デバイスは, 所有者によってロックされている間, Authentication Secret を表示しないほうがよい(SHOULD NOT)(つまり, 表示のために PIN, パスコード, または Biometric Characteristic の提示と Verification を要求する必要がある(SHOULD). ただし, Authenticator は, ロックされたデバイス上で Authentication Secret の受信を示す必要がある(SHOULD).

Out-of-band Authenticator が, (Claimant がプライマリ通信チャネルに転送する Secret を提示するのではなく) セカンダリ通信チャネルで承認を要求する場合, プライマリチャネルからの Secret の転送を受け入れることとなり(SHALL), 承認を Authentication Transaction に関連付けるために, それをセカンダリチャネルを介して Verifier に送信することとなる. Claimant は, 転送を手動で行うか, バーコードやQRコードなどのテクノロジーを使用して転送を行ってもよい(MAY).

Out-of-Band Verifiers

PSTN に固有の追加の Verification 要件については, Sec. 5.1.3.3 を参照のこと.

Out-of-band Authenticator がスマートフォン上などの安全なアプリケーションである場合, Verifier はそのデバイスにプッシュ通知を送信してもよい(MAY). Verifier は, Out-of-band Authenticator との Authenticated Protected Channel の確立を待ち, その識別キーを Verifiy する. Verifier は識別キー自体を保管することはない(SHALL NOT)が, Verification 方法 (例えば, Approved なハッシュ関数または識別キーの所有の証明) を使用して, Authenticator を一意に識別することとなる(SHALL). ひとたび Authenticate されると, Verifier は Authentication Secret を Authenticator に送信する.

Out-of-band Authenticator のタイプに応じて, 以下のいずれかが行われることとなる(SHALL):

セカンダリからプライマリチャネルへの Secret の転送: Verifier は, Authentication の準備ができていることを示すために, Subscriber の Authenticator を含むデバイスにシグナルを送ってもよい(MAY). そして, Random Secret を Out-of-band Authenticator に送信することとなる(SHALL). 続いて, Verifier は, プライマリ通信チャネル上で Secret が返却されるのを待つこととなる(SHALL).

プライマリからセカンダリチャネルへの Secret の転送: Verifier は, プライマリチャネルを介して Claimant に Random Authentication Secret を表示することとなる(SHALL). そして, Claimant の Out-of-band Authenticator からセカンダリチャネル上で Secret が返却されるのを待つこととなる(SHALL).

すべてのケースで, 10分以内に完了しない場合, Authentication は無効と見なされることとなる(SHALL). Sec. 5.2.8で述べられた通りに Replay Resistance を提供するため, Verifier は, 与えられた Authentication Secret の受け入れを有効期間中に一度のみとすることとなる(SHALL).

Verifier は, Approved Random Bit Generator [SP800-90Ar1] を使用して, 少なくとも 20 ビットの Entropy を持つ Random Authentication Secret を生成することとなる(SHALL). Authentication Secret の Entropy が 64 ビット未満の場合, Verifier は, Sec. 5.2.2 で説明されている通り, Subscriber Account で試行できる Authentication の失敗回数を効果的に制限するレート制限メカニズムを実装することとなる(SHALL).

CSP が, Out-of-band Authentication が Sec. 5.1.3.4 の要件を満たしていることを確認しない限り, Out-of-band Verifier はすべての Authentication 操作を Single-Factor と見なすこととなる(SHALL). この要件は CSP または信頼されたサードパーティによる Authenticator の発行, またはこれらの要件を満たすことが CSP によって認識されている Authentication アプリケーションの使用によって満たされてもよい(MAY).

Subscriber のデバイスにプッシュ通知を送信する Out-of-band Verifier は, 成功した最後の Authentication 以降に送信されるプッシュ通知のレートまたは総数に合理的な制限を実装する必要がある(SHOULD).

Authentication using the Public Switched Telephone Network

Out-of-band Verification のための PSTN の使用は, このセクションと Sec. 5.2.10 で説明されているように制限されている. PSTN を使用して Out-of-band Verification を行う場合, Verifier は, 使用されている事前登録済みの電話番号が特定の物理デバイスに関連付けられていることを Verification することとなる(SHALL). 事前登録された電話番号の変更は, 新しい Authenticator のバインドであると見なされ, Sec. 6.1.2 で説明されている場合にのみ発生することとなる(SHALL).

PSTN を使用して Out-of-band Authentication Secret を配信することは, 限定された電話のカバレッジを持つ地域 (特に携帯電話サービスがない地域) では, 一部の Subscriber が利用できない可能性がある. したがって, Verifier は, すべての Subscriber が代替の Authenticator タイプを利用できるようにすることとなり(SHALL), バインドする前に, PSTN を使用した Out-of-band Authenticator のこの制限を Subscriber に通知する必要がある(SHOULD).

Verifier は, PSTN を使用して Out-of-band Authentication Secret を配信する前に, デバイスの交換, SIM の変更, 番号の移植, またはその他の異常な動作などのリスク指標を考慮する必要がある(SHOULD).

注意: Sec. 5.2.10 の Authenticator の制限と整合性を取り, NIST は, 脅威をとりまく状況の進化と PSTN の技術的なオペレーションに基づいて, 時間の経過とともに, PSTN の制限付きステータスを調整してもよい.

Multi-Factor Out-of-Band Authenticators

Multi-Factor Out-of-band Authenticator は, Claimant が Authentication Transaction を完了できるようにする前(つまり, Authentication Secret にアクセスする前, Authentication Secret を入力する前, または使用されている Authentication フローに適した Transaction を確認する前)に Memorized Secret または Biometric Characteristic のいずれかの追加要素の提示と Verification を必要とすることを除いて, Single-Factor Out-of-band Authenticator (Sec. 5.1.3.1を参照) と同様の方法で動作する. Authenticator の使用ごとに, Activation Factor の提示を要求することとなる(SHALL).

Authenticator による Activation Secret の使用は, Sec. 5.2.11 の要件を満たすこととなる(SHALL). Biometric Activation Factor は, Authentication の連続失敗回数の制限を含め, Sec. 5.2.3 の要件を満たすこととなる(SHALL). Activation Factor の提出は, ホストデバイス (スマートフォンなど) のロック解除とは別の操作となる(SHALL)が, ホストデバイスのロック解除に使用されたものと同じ Activation Factor が Authentication 操作で使用されてもよい(MAY). Activation に使用される Memorized Secret または Biometric Sample -および信号処理によって生成された Probe などの Biometric Sample から得られたすべての Biometric データ- は, Authentication 操作の直後に Zeroize されることとなる(SHALL).

Single-Factor OTP Device

Single-Factor OTP デバイスは, ワンタイムパスワード(OTP)を生成する. このカテゴリには, ハードウェアデバイスと携帯電話などのデバイス上にインストールされた Software-Based OTP Generator が含まれる. これらのデバイスは, OTP 生成のシードとして使用される組み込みの Secret を持ち, 二番目の要素による Activation を必要としない. OTP はデバイス上に表示され Verifier に送信するために手動で入力される, これによりデバイスの所有と制御が証明される. OTP デバイスは, 例えば, 一度に6文字を表示してもよい. Single-Factor OTP デバイスは something you have である.

Single-Factor OTP デバイスは, Secret が Authenticator と Verifier によって暗号論的にかつ独立して生成され, Verifier によって比較されることを除いて, Look-up Secret Authenticator と同様である. Secret は, 時間ベースの Nonce に基づいて, または Authenticator と Verifier の数値カウンターから計算されてもよい.

Single-Factor OTP Authenticators

Single-Factor OTP Authenticator は, 2つの永続的な値を含む. 1つ目は, デバイスのライフタイムの間保持される Symmetric Key である. 2つ目は, Authenticator が使用されるたびに変更されるか, リアルタイムクロックに基づく Nonce である.

Secret Key とそのアルゴリズムは, 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度を提供することとなる(SHALL)(発行日現在で 112 ビット). Nonce は, デバイスのライフタイム全体にわたってデバイスの各操作ごとに一意であることを確保するのに十分な長さとなる(SHALL). Subscriber が Software-Based OTP Authenticator に使用されるデバイスを変更する必要がある場合, 彼らは Sec. 6.1.2.1 で説明されている通りに新しいデバイス上の Authenticator を Subscriber Account へバインドする必要があり(SHOULD), 使用されなくなった Authenticator アプリケーションを無効にする必要がある.

Authenticator Output は, Key と Nonce を安全な方法で結合するために Approved なブロック暗号または Hash 関数を使用すること取得される. Authenticator Output は, わずか6桁の10進数 (約20ビットのEntropy) に切り詰められられてもよい(MAY).

Authenticator Output を生成するために使用される Nonce がリアルタイムクロックに基づいている場合, Nonce は少なくとも2分ごとに変更されることとなる(SHALL).

Single-Factor OTP Verifiers

Single-Factor OTP Verifier は, Authenticator に使用される OTP 生成プロセスを効果的に複製する. そのため, Authenticator に使用される Symmetric Key は Verifier にもまた存在し, アクセスを必要とするデバイス上のそれらのソフトウェアコンポーネントのみに Key へのアクセスを制限するアクセスコントロールを使用して, 無許可の開示から強力に保護されることとなる(SHALL).

Single-Factor OTP Authenticator が Subscriber Account に関連付けられている場合, Verifier または関連付けられた CSP は, Authenticator Output を複製するために必要な Secret を生成および交換, または取得するために, Approved Cryptography を使用することとなる(SHALL).

Verifier は, OTP を収集するときに, 盗聴や AitM Attack への耐性を提供するために, Approved Encryption と Authenticated Protected Channel を使用することとなる(SHALL). Sec. 5.2.8 で説明されている通りに Replay Resistance を提供するために, Verifier は, 有効な OTP の受け入れを一度のみとすることとなる(SHALL). OTP の重複使用が原因で Claimant の Authentication が拒否された場合, Verifier は, Attacker が事前に Authenticate できた場合に備えて Claimant に警告してもよい(MAY). また, Verifier は, OTP の重複使用の試行について, 既存セッションの中にいる Subscriber に警告してもよい(MAY).

時間ベースの OTP [TOTP] は, ネットワーク遅延と OTP のユーザー入力のための許容値, それに加え Authenticator が寿命の間に持つはずの両方向のクロックのずれを考慮した上で決定される, 定義されたライフタイムを持つこととなる(SHALL).

Authenticator Output の Entropy が 64 ビット未満の場合, Verifier は, Sec. 5.2.2 で説明されている通り, Subscriber Account で試行できる Authentication の失敗回数を効果的に制限するレート制限メカニズムを実装することとなる(SHALL).

Multi-Factor OTP Devices

Multi-Factor OTP デバイスは, Activation Factor の入力による Activation 後に Authentication に使用する OTP を生成する. これには, ハードウェアデバイスと携帯電話などのデバイス上にインストールされた Software-Based OTP Generator が含まれる. Authentication の二番目の要素は, 一体型入力パッドのようなもの, 一体型Biometric (例: 指紋) リーダー, または直接的なコンピュータインターフェース (例: USB ポート) によって実現されてもよい. OTP はデバイス上に表示され Verifier に送信するために手動で入力される. 例えば, OTP デバイスは一度に6文字を表示することができ, それによってデバイスの所有と制御を証明する. Multi-Factor OTP デバイスは something you have であり, かつ, something you know または something you are のいずれかによって Activation されることとなる(SHALL).

Multi-Factor OTP Authenticators

Multi-Factor OTP Authenticator は, Authenticator から OTP を取得するために Memorized Secret または Biometric Characteristic のいずれかの提示と Verification を必要とすることを除いて, Single-Factor OTP Authenticator (Sec. 5.1.4.1を参照) と同様の方法で動作する. Authenticator の使用ごとに, Activation Factor の入力を要求することとなる(SHALL).

Activation 情報に加えて, Multi-Factor OTP Authenticator は, 2つの永続的な値を含む. 1つ目は, デバイスのライフタイムの間保持される Symmetric Key である. 2つ目は, Authenticator が使用されるたびに変更されるか, リアルタイムクロックに基づく Nonce である.

Authenticator による Activation Secret の使用は, Sec. 5.2.11 の要件を満たすこととなる(SHALL). Biometric Activation Factor は, Authentication の連続失敗回数の制限を含め, Sec. 5.2.3 の要件を満たすこととなる(SHALL). Activation Factor の提出は, ホストデバイス (スマートフォンなど) のロック解除とは別の操作となる(SHALL)が, ホストデバイスのロック解除に使用されたものと同じ Activation Factor が Authentication 操作で使用されてもよい(MAY). Unencrypted Key と Activation Secret, または Biometric Sample -および信号処理によって生成された Probe などの Biometric Sample から得られたすべての Biometric データ- は, Authentication 操作の直後に Zeroize されることとなる(SHALL).

Multi-Factor OTP Verifiers

Multi-Factor OTP Verifier は, 二番目の要素を提供を受ける要件なしに Authenticator に使用される OTP 生成プロセスを効果的に複製する. そして, Authenticator に使用される Symmetric Key はアクセスを必要とするデバイス上のそれらのソフトウェアコンポーネントのみに Key へのアクセスを制限するアクセスコントロールを使用して, 無許可の開示から強力に保護されることとなる(SHALL).

Multi-Factor OTP Authenticator が Subscriber Account に関連付けられている場合, Verifier または関連付けられた CSP は, Authenticator Output を複製するために必要な Secret を生成および交換, または取得するために, Approved Cryptography を使用することとなる(SHALL). Verifier または CSP は, Authenticator の発行によって, Authenticator が Multi-Factor デバイスであることを確立することとなる(SHALL). それ以外の場合, Verifier は, Sec. 5.1.4 に従って, Authenticator を Single-Factor として扱うこととなる(SHALL).

Authenticator Output または Activation Secret の Entropy が 64 ビット未満の場合, Verifier は, Sec. 5.2.2 で説明されている通り, Subscriber Account で試行できる Authentication の失敗回数を効果的に制限するレート制限メカニズムを実装することとなる(SHALL).

Single-Factor Cryptographic Software

Single-Factor Cryptographic Software Authenticator は, ディスク上またはその他の “ソフト” メディアに格納された Cryptographic Key である. Authentication は, Key の所有と制御を証明することによって成し遂げられる. Authenticator Output は, 特定の暗号プロトコルに大きく依存するが, 通常は何らかのタイプの署名付きメッセージである. Single-Factor Cryptographic Software Authenticator は something you have である.

Single-Factor Cryptographic Software Authenticators

Single-Factor Cryptographic Software Authenticator は, 1つかそれ以上の一意の Secret Key を Authenticator にカプセル化する. Key は, Authenticator アプリケーションが利用可能な, 適切に安全なストレージ (例: キーチェーンストレージ, TPM, または可能であれば TEE) に格納することとなる(SHALL). Key は, アクセスを必要とするデバイス上のそれらのソフトウェアコンポーネントのみに Key へのアクセスを制限するアクセスコントロールを使用して, 無許可の開示から強力に保護されることとなる(SHALL).

Cryptographic Hardware Authenticator の要件を満たさない, 外付けの Cryptographic Authenticator (例: Private Key のエクスポートを許可するメカニズムを持つもの) も, Cryptographic Software Authenticator と見なされる. それらは Sec. 5.2.12 の Connected Authenticator の要件を満たすこととなる(SHALL).

Single-Factor Cryptographic Software Verifiers

Single-Factor Cryptographic Software Verifier の要件は, Sec. 5.1.7.2 で述べられる Single-Factor Cryptographic Device Verifier と同様である.

Single-Factor Cryptographic Devices

Single-Factor Cryptographic デバイスは, 保護された Cryptographic Key を使用して暗号的操作を実行し, ユーザーエンドポイントへの直接接続を介して Authenticator Output を提供するハードウェアデバイスである. デバイスは, 組み込みの Symmetric または Asymmetric Cryptographic Key を使用し, 二番目の要素による Activation を必要としない. Authentication は, Authentication Protocol を介してデバイスの所有を証明することによって成し遂げられる. Authenticator Output は, ユーザーエンドポイントへの直接接続によって提供され, また特定の暗号デバイスとプロトコルに大きく依存するが, 通常は何らかのタイプの署名付きメッセージである. Single-Factor Cryptographic デバイスは something you have である.

Single-Factor Cryptographic Device Authenticators

Single-Factor Cryptographic Device Authenticator は, 1つかそれ以上の一意の Secret Key を, エクスポート機能を持つことはない(SHALL NOT)(つまり,デバイスから削除できない) Authenticator にカプセル化するために耐タンパー性ハードウェアを使用する. この Authenticator は, Sec. 5.2.12 に指定された通り, Authenticator とエンドポイントの間の直接的なインターフェース(例: USB ポートや保護されたワイヤレス接続)を通じて提示された Challenge Nonce に署名するために Secret Key を使用することで動作する. あるいは, Authenticator は, ユーザーエンドポイントそれ自体に統合された適切に安全なプロセッサであってもよい.

Secret Key とそのアルゴリズムは, 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティの長さを提供することとなる(SHALL)(発行日現在で 112 ビット). Challenge Nonce は, 少なくとも 64 ビットの長さとなる(SHALL). Approved Cryptography を使用することとなる(SHALL).

Cryptographic Device Authenticator は, 暗号デバイスによる組み込みの Authentication Secret によって, より大きな保護がもたらされるため, Cryptographic Software Authenticator とは異なる. 暗号デバイスと見なされるために, Authenticator は, ハードウェアの別の部分または組み込みプロセッサ, または実行環境 (例: セキュアエレメント, Trusted Execution Environment (TEE), Trusted Platform Module (TPM))のいずれかとなる(SHALL). これらのハードウェア Authenticator または組み込みプロセッサは, ラップトップやモバイルデバイス上の CPU などのホストプロセッサからは分離される. Cryptographic Device Authenticator は, ホストプロセッサへの Authentication Secret のエクスポートを禁止するように設計されることとなり(SHALL), Secret の抽出が許されるようにホストプロセッサによって再プログラムを行えるようになることはない(SHALL NOT). Authenticator は, Authenticator が使用されている AAL に適合する [FIPS140] の要件の対象となる.

Single-Factor Cryptographic Device Authenticator は, 動作するために物理的な入力 (例: ボタンを押す) を要求する必要がある(SHOULD). これは, デバイスが接続されているエンドポイントが侵害された場合に発生する可能性がある, デバイスの意図しない動作に対する防御を提供する.

Single-Factor Cryptographic Device Verifiers

Single-Factor Cryptographic Device Verifier は, Challenge Nonce を生成し, それを対象の Authenticator に送信し, デバイスの所有を検証するために Authenticator Output を使用する. Authenticator Output は, 特定の暗号デバイスとプロトコルに大きく依存するが, 通常は何らかのタイプの署名付きメッセージである.

Verifier は, それぞれの Authenticator に対応する Symmetric または Asymmetric Cryptographic Key のいずれかを持つ. 両タイプの鍵は変更から保護されることとなる(SHALL)が, Symmetric Key はさらに, アクセスを必要とするデバイス上のそれらのソフトウェアコンポーネントのみに Key へのアクセスを制限するアクセスコントロールを使用して, 無許可の開示から強力に保護されることとなる(SHALL).

Challenge Nonce は, 長さが少なくとも 64 ビットとなり(SHALL), Authenticator のライフタイムにわたって, または統計的に一意となる(SHALL)(つまり, Approved Random Bit Generator [SP800-90Ar1] を使用して生成される). Verification 操作は, Approved Cryptography を使用することとなる(SHALL).

Multi-Factor Cryptographic Software

Multi-Factor Cryptographic Software Authenticator は, Authentication の二番目の要素での Activation を必要とする, ディスク上またはその他の “ソフト” メディアに格納された Cryptographic Key である. Authentication は, Key の所有と制御を証明することによって成し遂げられる. Authenticator Output は, 特定の暗号プロトコルに大きく依存するが, 通常は何らかのタイプの署名付きメッセージである. Multi-Factor Cryptographic Software Authenticator は something you have であり, something you know または something you are のいずれかによって Activation されることとなる(SHALL).

Multi-Factor Cryptographic Software Authenticators

Multi-Factor Cryptographic Software Authenticator は, 1つかそれ以上の一意の Secret Key を Authenticator にカプセル化し, Memorized Secret または Biometric Characteristic のいずれかの Activation Factor の提示と Verification によってのみアクセス可能となる. Key は, Authenticator アプリケーションが利用可能な, 適切に安全なストレージ (例: キーチェーンストレージ, TPM, TEE) に格納する必要がある(SHOULD). Key は, アクセスを必要とするデバイス上のそれらのソフトウェアコンポーネントのみに Key へのアクセスを制限するアクセスコントロールを使用して, 無許可の開示から強力に保護されることとなる(SHALL).

Authenticator を使用する各 Authentication 操作は, Activation Factor の入力を必要とすることとなる(SHALL).

Authenticator による Activation Secret の使用は, Sec. 5.2.11 の要件を満たすこととなる(SHALL). Biometric Activation Factor は, Authentication の連続失敗回数の制限を含め, Sec. 5.2.3 の要件を満たすこととなる(SHALL). Activation Factor の提出は, ホストデバイス (スマートフォンなど) のロック解除とは別の操作となる(SHALL)が, ホストデバイスのロック解除に使用されたものと同じ Activation Factor が Authentication 操作で使用されてもよい(MAY). Activation Secret または Biometric Sample -および信号処理によって生成された Probe などの Biometric Sample から得られたすべての Biometric データ- は, Authentication 操作の直後に Zeroize されることとなる(SHALL).

Multi-Factor Cryptographic Software Verifiers

Multi-Factor Cryptographic Software Verifier の要件は, Sec. 5.1.7.2 で述べられる Single-Factor Cryptographic Device Verifier と同様である. Multi-Factor Cryptographic Software Authenticator Output の Verification は, Activation Factor の使用を証明する.

Multi-Factor Cryptographic Devices

Multi-Factor Cryptographic デバイスは, 1つかそれ以上の保護された Cryptographic Key を使用して暗号的操作を実行し, 二番目の Authentication Factor による Activation を必要とするハードウェアデバイスである. Authentication は, デバイスの所有および Key の制御を証明することによって成し遂げられる. Authenticator Output は, ユーザーエンドポイントへの直接接続によって提供され, また特定の暗号デバイスとプロトコルに大きく依存するが, 通常は何らかのタイプの署名付きメッセージである. Multi-Factor Cryptographic デバイスは, something you have であり, かつ, something you know または something you are のいずれかによって Activation されることとなる(SHALL).

Multi-Factor Cryptographic Device Authenticators

Multi-Factor Cryptographic Device Authenticator は, 1つかそれ以上の一意の Secret Key を, エクスポート機能を持つことはない(SHALL NOT)(つまり,デバイスから削除できない) Authenticator にカプセル化するために耐タンパー性ハードウェアを使用する. Secret Key は, Sec. 5.2.11 で述べられている通り, Biometric Characteristic または Activation Secret のいずれかの Activation Factor の提示と Verification によってのみアクセス可能となる(SHALL). この Authenticator は, Sec. 5.2.12 に指定された通り, Authenticator とエンドポイントの間の直接的なインターフェース(例: USB ポートや保護されたワイヤレス接続)を通じて提示された Challenge Nonce に署名するために Activation Factor によってアンロックされた Secret Key を使用することで動作する. あるいは, Authenticator は, ユーザーエンドポイントそれ自体に統合された適切に安全なプロセッサであってもよい(例: ハードウェア TPM).

Cryptographic Device Authenticator は, 暗号デバイスによる組み込みの Authentication Secret によって, より大きな保護がもたらされるため, Cryptographic Software Authenticator とは異なる. 暗号デバイスと見なされるために, Authenticator は, ハードウェアの別の部分または組み込みプロセッサ, または実行環境 (例: セキュアエレメント, Trusted Execution Environment (TEE), Trusted Platform Module (TPM))のいずれかとなる(SHALL). Cryptographic Device Authenticator は, ホストプロセッサへの Authentication Secret のエクスポートを禁止するように設計されることとなり(SHALL), Secret の抽出が許されるようにホストプロセッサによって再プログラムを行えるようになることはない(SHALL NOT). Authenticator は, Authenticator が使用されている AAL に適合する [FIPS140] の要件の対象となる.

Authenticator を使用する各 Authentication 操作は, Activation Factor の入力が必要である(SHOULD). Activation Factor の入力は, デバイス上の直接入力か, ハードウェア接続(例: USB, スマートカード)を介してのいずれかで行われてもよい(MAY).

Authenticator による Activation Secret の使用は, Sec. 5.2.11 の要件を満たすこととなる(SHALL). Biometric Activation Factor は, Authentication の連続失敗回数の制限を含め, Sec. 5.2.3 の要件を満たすこととなる(SHALL). Activation Factor の提出は, ホストデバイス (スマートフォンなど) のロック解除とは別の操作となる(SHALL)が, ホストデバイスのロック解除に使用されたものと同じ Activation Factor が Authentication 操作で使用されてもよい(MAY). Activation Secret または Biometric Sample -および信号処理によって生成された Probe などの Biometric Sample から得られたすべての Biometric データ- は, Authentication 操作の直後に Zeroize されることとなる(SHALL).

Multi-Factor Cryptographic Device Verifiers

Multi-Factor Cryptographic Device Verifier の要件は, Sec. 5.1.7.2 で述べられる Single-Factor Cryptographic Device Verifier と同様である. Multi-Factor Cryptographic Device からの Authenticator Output の Verification は, Activation Factor の使用を証明する.

General Authenticator Requirements

Physical Authenticators

CSP は, Authenticator を盗難や紛失から適切に保護する方法について, Subscriber にインストラクションを提供することとなる(SHALL). CSP は, Subscriber からの Authenticator の紛失または盗難が疑われる通知に対して, 即時に Authenticator を無効にするメカニズムを提供することとなる(SHALL).

Rate Limiting (Throttling)

Sec. 5.1 の Authenticator Type の説明で必要とされる場合, Verifier は, Online Guessing Attack から保護するための制御を実装することとなる(SHALL). その Authenticator の説明で特に指定されていない限り, Verifier は, 単一の Subscriber Account での Authentication の連続失敗の試行を 100回以下に制限することとなる(SHALL).

レート制限の結果として Attacker が正当な Claimant をロックアウトする可能性を減らすために, 以下を含む追加のテクニックが使用されてもよい(MAY)：

Authentication を試みる前に, Claimant にボットの検出と緩和のための課題を完了するように要求する.

失敗した試行の後に, Subscriber Account がその連続失敗試行回数の最大許容値に近づくにつれて増加する時間(例: 30秒から1時間まで)の間, Claimant に待つことを要求する.

Subscriber が以前, Authentication に成功した IP アドレスの Allowlist からの Authentication 要求のみを受け入れる.

他のリスクベースまたは適応できる Authentication テクニックを活用して, 一般的な基準の範囲内または範囲外となるユーザーの行動を識別する. これらには, 例えば, IP アドレス, 位置情報, リクエストのタイミングのパターン, またはブラウザのメタデータの使用が含まれることがある.

Subscriber が Authentication に成功すると, Verifierは, 同じ IP アドレスからのそのユーザーのそれ以前の失敗試行をすべて考慮しないようにする必要がある(SHOULD).

Use of Biometrics

Authentication における Biometrics (something you are) の使用には, 身体的特徴 (例: 指紋, 虹彩, 顔の特徴) と行動的特徴 (例: タイピングのリズム) の両方の測定が含まれる. どちらのクラスも Biometric Modalitiy と見なされるが, Sec. 5.2.9 で説明されているように, Modalitiy が異なると Authentication Intent の確立度合いが異なる場合がある.

さまざまな理由から, このドキュメントでは, Authentication のための Biometrics の限定的な使用のみをサポートしている. 理由は以下を含む:

Biometric False Match Rate (FMR) は, Subscriber の Authentication が Subscriber 自身によってなされたものであるという信頼を提供しない. さらに, FMR はスプーフィング Attack を考慮して計算されない.
Biometric の比較は確率的だが, 他の Authentication Factor は決定的である.
Biometric Template Protection スキームは, 他の Authentication Factor (例: PKIの証明書および Password) と同等の Biometric Credential を失効する方法を提供する. しかし, そのようなソリューションの有効性は限られており, これらの方法をテストするための標準は開発中である.
Biometric Characteristics は Secret の構成要素とはならない. それらはオンラインでたびたび入手でき, また人々の顔写真は相手の認識の有無を問わず写真を撮ることで入手できる. 隠れた指紋は人々が触れた物から取得することができ, 虹彩パターンは高解像度の画像で捉えられる. Presentation Attack Detection (PAD) テクノロジーはこれらのタイプの Attack のリスクを軽減できるが, PAD が CSP と Subscriber のニーズに従って動作していることを確実にするには, センサーまたは Biometric Processing への追加の信頼が必要とされる.

このため, Authentication のための Biometrics の限定的な使用は, 次の要件とガイドラインでサポートされる:

Biometrics は, 物理的な Authenticator (something you have) を使用した Multi-Factor Authentication の一部としてのみ使用されることとなる(SHALL).

Biometric システムは, 1/10000 またはそれよりも望ましい False-Match Rate (FMR) [ISO/IEC2382-37] で動作することとなる(SHALL). この FMR は, [ISO/IEC30107-1] で定義されている Conformant Attack (つまり, Zero-Effort Impostor Attempt) の条件のもとで達成されることとなる(SHALL).

Biometric システムは, Presentation Attack Detection (PAD) を実装する必要がある(SHOULD). 展開される Biometric システムのテストでは, 関連する Attack タイプ (つまり, Species) ごとに, Presentation Attack に対して少なくとも 90% の耐性があることを示す必要がある(SHOULD). 耐性は, 阻止された Presentation Attack の数を試行したPresentation Attack の数で割った値として定義される. Presentation Attack 耐性のテストは, [ISO/IEC30107-3] の第12条に従うこととなる(SHALL). PAD の決定は, Claimant のデバイス上でローカルに行われるか, 中央の Verifier によって行われてもよい(MAY).

Biometric システムは, Authentication の試行の連続失敗を5回まで, または, 上記の要件を満たす PAD が実装されている場合においては試行の連続失敗を 10 回まで許容することとなる(SHALL). ひとたびその制限に達すると, Biometric Authenticator は, 全体的な制限として Authentication の試行の連続失敗が 50 回 (PAD が実装されている場合は 100 回) を超えないとともに, その後の各試行の前に少なくとも 30 秒の遅延を課すこととなる(SHALL). ひとたび全体的な制限に達すると, Biometric システムは, Biometric User Authentication を無効にすることとなり(SHALL), 利用可能な代替方法がすでにある場合は, 他の要素 (例: 別の Biometric Modality, または, まだ要求された要素でない場合は Activation Secret) を提案することとなる.

Verifier は, センサーとエンドポイントのパフォーマンス, Integrity (完全性), および Authenticity (真正性) を判断することとなる(SHALL). この決定を行うための許容される方法は, 以下を含むがこれらに限定されない:

センサーまたはエンドポイントの Authentication
Approvedな公認機関による Certification
Sec. 5.2.4 で説明されている通りの, 署名されたメタデータ (例: Attestation) の実行時の問い合わせ.

Biometric の比較は, Claimant のデバイス上でローカルでも, 中央の Verifier でも実行可能である. しかし, 大規模な Attack の可能性は中央の Verifier の方が大きいため, 比較はローカルで実行される必要がある(SHOULD).

比較が中央で実行される場合:

Authentication Factor としての Biometric の使用は, Approved Cryptography を使用して識別される1つかそれ以上の特定のデバイスに限定されることとなる(SHALL). Biometric はメインの Authentication Key をまだアンロックしていないため, デバイスの識別には別の Key が使用されることとなる(SHALL).
[ISO/IEC24745] で Biometric Template Protection と呼ばれるBiometric Revocation が実装されることとなる(SHALL).
Authenticated Protected Channel は, センサー (またはセンサー交換耐性があるセンサーを含むエンドポイント) と Verifier の間に確立されることとなり(SHALL), また, センサーまたはエンドポイントは, Claimant から Biometric Sample を取得する前に Authenticate されることとなる(SHALL).
Biometrics のすべての送信は, Authenticated Protected Channel を介することとなる(SHALL).

Authentication プロセスの中で収集された Biometric Sampleは, 比較アルゴリズムのトレーニングに使用するか, または -ユーザーの同意のもとで- 他の研究目的に使用されてもよい(MAY). Biometric Sample, および信号処理によって生成された Probe などの Biometric Sample から得られたすべての Biometric データは, すべてのトレーニングまたは研究データが得られた直後に Zeroize されることとなる(SHALL).

Biometric Authentication 技術は, さまざまな人口統計的タイプ (人種的背景, 性別, 民族など) の Subscriber に対して同様のパフォーマンスを提供することとなる(SHALL).

Attestation

Attestation は, 接続された Authenticator, または Authentication 操作に関わるエンドポイントに関して Verifier に伝達される情報である. Attestation によって伝達される情報には以下を含んでもよい(MAY) が, これらに限定されない:

Authenticator とエンドポイントの起源 (例: メーカーまたはサプライヤーの認定), 健全性, および Integrity (完全性)
Authenticator のセキュリティ機能
Biometric センサーのセキュリティとパフォーマンスの特性
センサーモダリティ

この Attestation が署名されている場合は, 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度(発行日現在で 112 ビット)を提供する Digital Signature を使用して署名されることとなる(SHALL).

Attestation 情報は, Verifier のリスクベース Authentication の決断の一部として使用されてもよい(MAY).

Phishing (Verifier Impersonation) Resistance

以前 SP 800-63B で “Verifier Impersonation” と呼ばれていた Phishing Attack は, 悪意のある偽物の Verifier と RP が, 不注意な Claimant をだまして Authenticator を Impostor に提示させようとする試みである. いくつかの SP 800-63 の以前のバージョンでは, Phishing Attack に耐性のあるプロトコルは, “Strongly MitM Resistant” とも呼ばれていた.

Phishing という用語は, さまざまな同様の Attack を説明するために広く使用されている. このドキュメントの目的上, Phishing 耐性とは, Subscriber の警戒に頼ることなく, Authentication Secret と有効な Authenticator Output を Impostor が偽装する Relying Party へ開示することを検出し防止する Authentication Protocol の機能である. Subscriber が Impostor が偽装する Relying Party に向けられた手段は関係しない. 例えば, Subscriber が検索エンジンの最適化によってそこに案内されたのか, 電子メールで促されたのかに関係なく, Phishing Attack であると見なされる.

Approved な暗号アルゴリズムは, 必要とされる場所で Phishing 耐性を確立するために使用されることとなる(SHALL). この目的のための Key は, 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度(発行日現在で 112 ビット)を提供することとなる(SHALL).

Out-of-band や OTP Authenticator のような, Authenticator Output の手動入力を伴う Authenticator は, Phishing 耐性があると見なされることはない(SHALL NOT), なぜならば, 手動入力は Authenticator Output を特定の Authenticated session に Bind しないためである. AitM Attack では, Impostor が偽装する Verifier が OTP Authenticator の Output を Verifier に Replay し, Authentication に成功する可能性がある.

個々の Authenticator には Phishing 耐性があるとしても, 特定の Subscriber Account の Phishing 耐性はすべての Authentication の方法に Phishing 耐性がある場合にのみ達成される.

Phishing 耐性の2つの方法が知られている: Channel Binding と Verifier Name Binding である. Channel Binding は Relying Party 証明書の誤発行や不正使用に対して脆弱ではないため, Verifier Name Binding よりも安全であるとみなされるが, どちらの方法も Phishing 耐性の要件を満たす.

Channel Binding

Channel Binding を伴う Authentication Protocol は, Authenticated Protected Channel を Verifier と確立することとなる(SHALL). 次に, Authenticated Protected Channel を確立する際にネゴシエートされた Channel Identifier を, Authenticator Output に強力かつ不可逆的に Bind することとなる(SHALL)(例: Public Key が Verifier に知られている Claimant によって制御される Private Key を使用して, 2つの値を一緒に署名することによって). Verifier は, Phishing 耐性を証明するために, 使用される署名またはその他の情報を検証することとなる(SHALL). これにより, Impostor が偽装する Verifier が実際の Verifier を表す証明書を取得したとしても, 異なる Authenticated Protected Channel でその Authentication の中継に成功することを防ぐ.

Channel Binding を使用する Phishing 耐性のある Authentication Protocol の例は, Client-authenticated TLS である. なぜならば, ネゴシエートされた特定の TLS 接続に一意の, Protocol からの以前のメッセージと共に Authenticator Output にクライアントが署名するためである.

Verifier Name Binding

Authenticator Name Binding を伴う Authentication Protocol は, Authenticated Protected Channel をVerifier と確立することとなる(SHALL). 次に, Protocol の一部として Authenticate された Verifier Identifier に対して暗号的に Bind された Authenticator Output を生成することとなる(SHALL). Domain Name System (DNS) Identifier の場合, Verifier Identifier は, Verifier の Authenticate されたホスト名, またはホスト名に関連付けられた Public Suffix [PSL] の少なくとも 1 レベル遡った親ドメインのいずれかとなる(SHALL). Binding は, 関連付けられた Authenticator Secret を選択するか, Verifier Identifier を使用して Authenticator Secret を導出するか, Verifier Identifier と供に Authenticator Output に暗号的に署名するか, または同様の暗号的に安全な手段によって確立されてもよい(MAY).

Verifier-CSP Communications

Verifier と CSP が別々のエンティティである状況では ([SP800-63] の点線で示されているように, Verifier と CSP 間の通信は, Approved Cryptography を使用して, (Client-authenticated TLS 接続のような) 相互に Authenticate された安全なチャネルを介して行われることとなる(SHALL).

Verifier Compromise Resistance

いくつかのタイプの Authenticator を使用するには, Verifier が Authenticator Secret のコピーを保管する必要がある. 例えば, OTP Authenticator (Sec. 5.1.4 で説明) では, Claimant によって送信された値と比較するための Authenticator Output を, Verifier が独立して生成することが求められる. Verifier が侵害され, 保管された Secret が盗まれる可能性のため, Verifier が Authentication に使用できる Secret を永続的に保管する必要のない Authentication Protocol はより強力であると見なされ, Verifier Compromise Resistant(Verifierが侵害耐性を持つ状態) である旨がここで説明されている. このような Verifier もすべての Attack に耐性があるわけではないことに注意が必要である. Verifier は, 特定の Authenticator Output を常に受け入れるようにのっとられるなど, 別の方法で侵害されるかもしれない.

Verifier Compromise Resistant は様々な方法で達成できる, 例えば:

Verifier は, Authenticator 保持する Private Key に対応する Public key を保管することを要求する Cryptographic Authenticator を使用する.

予想される Authenticator Output を Hash 形式で保管する. このメソッドは, 例えば一部の Look-Up Secret Authenticator (Sec. 5.1.2 で説明) で使用できる.

Verifier Compromise Resistant であると見なされるために, Verifier によって保管される Public key は, Approved な暗号アルゴリズムの使用によるものとなり(SHALL), 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度(発行日現在で 112 ビット)を提供することとなる(SHALL).

その他の Verifier Compromise Resistant Secret は, Approved な Hash アルゴリズムを使用することとなり(SHALL), 基となる Secret は, 少なくとも [SP800-131A] の最新リビジョンで指定されている最小のセキュリティ強度(発行日現在で 112 ビット)を持つすることとなる(SHALL). 低い複雑度を持つ Secret (例: Memorized Secret) は, 辞書検索または網羅的探索によって Hash プロセスを破る可能性があるため, Hash された場合でも Verifier Compromise Resistant と見なされることはない(SHALL NOT).

Replay Resistance

Authentication Process は, 過去の Authentication のメッセージを記録して Replay することによって Authentication を成功させることが現実的でない場合, Replay Attack に耐性がある. Protected Channel に入る前に Output が盗まれる可能性があるため, Replay Resistance は Authenticated Protected Channel Protocol の Replay-Resistant 特性には含まれていない. Nonce または Challenge を使用して Transaction の “真新しさ” を証明するプロトコルは, Replay Attack に耐性がある. Verifier は, 古いプロトコルメッセージが適切な Nonce または適時性のあるデータを含んでいないため, 古いプロトコルメッセージが Replay されることを簡単に検出できるからである.

Replay 耐性のある Authenticator の例は, OTP デバイス, Cryptographic Authenticator, および Look-Up Secret である.

反対に, Memorized Secret は Replay 耐性があるとは見なされない. Authenticator Output —つまり, Secret そのもの— が Authentication ごとに提供されるためである.

Authentication Intent

Subject がそれぞれの Authentication または Reauthentication の要求に明示的に応答する必要がある場合, Authentication Process は Intent (意図)を実証する. Authentication Intent のゴールは, エンドポイント上のマルウェアなどによって, Subject の知らないうちに Authenticator (例: Multi-Factor Cryptographic Device) が使用されるのをより困難にすることである. Authentication Intent は, Authenticator 自体によって確立されることとなる(SHALL)が, Multi-Factor Cryptographic Device は, Authenticator の Activation Factor の再入力によって Intent を確立してもよい(MAY).

Authentication Intent は, いろいろな方法で確立されてもよい(MAY). Subject の介入を必要とする Authentication Process は, Intent を確立する (例: OTP デバイスからの Authenticator Output を入力するClaimant). それぞれの Authentication または Reauthentication 操作ごとにユーザーアクションを必要とする暗号デバイスも, Intent を確立する (例: ボタンを押す, 再挿入する).

Modality に応じて, Biometric Characteristic の提示は Authentication Intent を確立する場合と確立しない場合がある. Behavioral Biometrics も, Claimant 側での特定のアクションを必ずしも必要としないため, 同様に Authentication Intent を確立する場合と確立しない場合がある,

Restricted Authenticators

脅威の進化により, Authenticator の Attack 耐性の性能は通常は低下する. 反対に, 一部の Authenticator のパフォーマンスは, 例えば基となる標準の変更によって特定の Attack 耐性の能力が向上した場合に改善することがある.

Authenticator のパフォーマンスのこれらの変化に責任を持つために, NIST は, Authenticator Type, または Authenticator Type の特定のクラスやインスタンス化に追加の制約を課す:

Restricted Authenticator の使用は, 実装組織がその Authenticator に関連するリスクを評価, 理解, および受け入れ, リスクが時間の経過とともに増加する可能性があることを認識することを求める. システムと関連データについて許容可能なリスクのレベルを決定し, それを超えるリスクを軽減する方法を定義することは組織の責任である. いずれかの関係者へのリスクが許容できないと組織が判断した場合はいつでも, それ以降その Authenticator が使用されることはない(SHALL NOT).

さらに, Authentication エラーのリスクは通常, 実装組織, Authentication の決定に依存する組織, および Subscriber を含む複数の関係者によって負担される. 組織が Restricted Authenticator を受け入れると, Subscriber は追加のリスクにさらされる可能性があり, また Subscriber が持つ理解と制御能力が限られている可能性があるため, CSP は以下を行うこととなる(SHALL):

必要とされる AAL で使用できる少なくとも1つの Restricted でない代替の Authenticator を Subscriber に提供する.
Restricted Authenticator のセキュリティリスクと Restricted でない代替について, Subscriber に意味のある通知を提供する.
Risk Assessment で Subscriber への追加のリスクに取り組む.\
Restricted Authenticator が未来のある時点で受け入れられなくなる可能性について移行計画を作成し, この移行計画をその digital identity acceptance statement に含む.

Activation Secrets

Multi-Factor Authenticator の Activation Factor として使用される Memorized Secret は, Activation Secret と呼ばれる. Activation Secret は, Authentication に使用される Stored Secret Key を復号するために使用されるか, Authentication Key へのアクセスを提供するためにローカルに保持されている Stored Verifier と比較される. これらのいずれの場合でも, Activation Secret は Authenticator とそれに関連付けられたユーザーエンドポイント内にとどまることとなる(SHALL).

Activation Secret を利用する Authenticator は, Secret の長さに少なくとも 6 文字を要求することとなる(SHALL). Activation Secret は, すべて数字 (つまり PIN) であってもよい(MAY). (数字だけではなく)英数字の値が許可されている場合は, すべての Printing ASCII [RFC20] 文字と空白文字が受け入れられる必要がある(SHOULD). Unicode [ISO/ISC 10646] 文字もまた, 英数字の Secret に受け入れられる必要がある(SHOULD). Authenticator は, (特定の値またはアルゴリズムによって指定された) 少なくとも 10 個のよく使用される Activation 値の Blocklist を含むこととなり(SHALL), それらの Activation Secret としての使用を防ぐこととなる(SHALL).

Authenticator または Verifier は, Authenticator を使用した Activation の連続失敗の試行を効果的に 10回に制限する再試行制限メカニズムを実装することとなる(SHALL). 正しくない Activation Secret の入力によって Authenticator が中央の Verifier に送信される無効な Output を生成する場合, Verifier によってレート制限が実装されてもよい(MAY). すべての他のケースでは, レート制限は Authenticator に実装されることとなる(SHALL). ひとたび 10回の試行の制限に達すると, Authenticator を無効化されることとなり(SHALL), Authentication には別の Authenticator が要求されることとなる(SHALL).

Authenticator が Activation Secret を (Key の復号に使用するのではなく) ローカルで Verifiy する場合, Verification は, ハードウェアベースの Authenticator 内, または正しい Activation Secret の提示時にのみ Authentication Secret を解放するセキュアエレメント内 (例: TEE, TPM) で実行されることとなる(SHALL). 他の状況 (つまり, Software-Based Multi-Factor Authenticators) では, Authenticator は, 保管された Authentication Secret の復号のために Memorized Secret を Key として使用することとなる(SHALL). Approved Cryptography が使用されることとなる(SHALL).

Connected Authenticators

Cryptographic Authenticator は, Authenticator と Authenticate されるエンドポイントとの間の直接接続を必要とする. この接続は, 有線 (例: USB またはスマートカードとの直接接続) またはワイヤレス (例: NFC, Bluetooth) でもよい(MAY). ほとんどの場合, 有線接続は盗聴や Adversary-in-the-Middle Attack から安全であると推定できるが, ワイヤレス技術を介して接続されている Authenticator には追加の予防措置が必要とされる.

有線の Authenticator 接続は, エンドポイントに組み込まれている Authenticator (例: TPMの中) と, USB などの外部インターフェースを介して接続される Authenticator の両方を含む. Claimant は, 彼らが侵害されていないことのさらなる保証のため, 外部接続に信頼されたハードウェア (ケーブルなど) を使用することについてアドバイスを受ける必要がある(SHOULD).

ワイヤレスの Authenticator 接続は, 盗聴, インジェクション, リレー Attack などの脅威に対して潜在的に脆弱である. このような Attack の可能性は, 使用されているワイヤレス技術の有効範囲に依存する.

1 メートル以上の有効範囲を持つワイヤレス技術 (例: Bluetooth LE) は, Authenticator とエンドポイントの間で Authenticate された暗号化接続を使用することとなる(SHALL). ペアリングプロセスは, Authenticator とエンドポイント間の暗号化通信用の Key を確立するために使用される. ペアリングプロセスの代わりに, デバイス間の一時的な有線接続が Key を確立するために使用されてもよい(MAY). ペアリングプロセスは, ペアリングコードを使用することで Authenticate されることとなる(SHALL). ペアリングコードは, Authenticator またはエンドポイントのいずれかに関連付けられることとなり(SHALL), 少なくとも 20 ビットまたは 10 進数 6 桁の Entropy を持つこととなる(SHALL). ペアリングコードは, 関連付けられたデバイスに印刷してもよく(MAY), 手動入力, または光学的に伝達される QR コードか同様の提示方法を使用して, デバイス間で伝達することとなる(SHALL). この例は, [SP800-73] で指定された仮想コンタクトインターフェースで使用されるペアリングコードである. Authentication Transaction 全体は, ペアリングプロセスによって確立された Key を使用して暗号化されることとなる(SHALL).

1 メートル未満の有効範囲を持つワイヤレス技術 (例: NFC) が使用されている場合, エンドポイントから Authenticator に送信される Activation Secret がもしあれば, デバイス間のペアリングプロセスまたは一時的な有線接続を介して確立された Key を使用して暗号化されることとなる(SHALL). 上記の要件を満たすペアリングコードを使用した Authenticate された接続を使用する必要がある(SHOULD). Authenticator が Authenticate されたペアリングを要求するように構成されている場合, ペアリングコードが使用されることとなる(SHALL).

注: Authentication Transaction 全体ではなく Activation Secret のみの暗号化は, Relying Party の Identity などのセンシティブ情報を晒してしまう可能性があるが, これには Attacker が Subscriber の非常に近くにいる必要がある. “スキミング” や Eavesdropping Attack から情報を保護するために, Authenticate されたペアリングを必要としない, 個人を特定できる情報を含む Authenticator には, 特別な注意を払う必要がある.

ペアリングプロセスの結果として確立された Key は, 一時的 (限られた数のトランザクションまたは時間に対して有効) または永続的のどちらであってもよい(MAY). 永続 Key を削除するエンドポイントのメカニズムが提供されることとなる(SHALL).

暗号操作が必要なところでは, Approved Cryptography を使用することとなる(SHALL). Authenticator とエンドポイント間の Authentication データのすべての通信は, これらのデバイス間で直接行われるか, Authenticator とエンドポイント間の Authenticated Protected Channel を介して行われることとなる(SHALL).

Authenticator Lifecycle Management

This section is normative.

Subscriber の Authenticator のライフサイクル全体にわたって, Authenticator の使用に影響を与えるような多くのイベントが発生しうる. これらのイベントには, Binding, 紛失, 盗難, 無許可な複製, 有効期限切れ, および失効などが含まれる. 本セクションでは, これらのイベントに対応して実行すべきアクションについて記述する.

Authenticator Binding

Authenticator Binding とは, 特定の Authenticator と Subscriber Account の関連付けを確立することを指し, Authenticator を - 場合によっては他の Authenticator と組み合わせて - Subscriber Account の Authenticate に使用可能にすることを意味する.

Authenticator は Subscriber Account に以下のいずれかにより紐づけられるものとする (SHALL).

Enrollment の一環としての CSP による Authenticator の発行
Subscriber から提供された Authenticator を CSP が受け入れることによる Authenticator の登録

本ガイドライン群は上記の両オプションを考慮して Authenticator の発行ではなく Binding という用語を用いる.

Digital Identity のライフサイクルを通して, CSP は各 Subscriber Account に関連づけられている, ないしは関連づけられていた, すべての Authenticator レコードを管理することとする (SHALL). CSP ないし Verifier は, Sec. 5.2.2 にあるように, 必要に応じて Authentication 試行の Throttling に必要な情報も管理すること (SHALL). さらに, CSP はユーザーが提供する Authenticator のタイプ (e.g., Single-factor Cryptographic Device vs. Multi-factor Cryptographic Device) を検証し, Verifier が各 AAL 要件に準拠しているか判断できるようにすること (SHALL).

CSP が生成するレコードには, Authenticator が Subscriber Account に紐づけられた日時を含めること (SHALL). このレコードには, Enrollment に関与したすべてのデバイスとの Binding の発生源 (e.g., IP アドレス, Device 識別子) に関する情報も含めるべきである (SHOULD). 可能であれば, このレコードには当該 Authenticator による Authentication 試行失敗の発生源に関する情報も含めるべきである (SHOULD).

新しい Authenticator を Subscriber Account に紐づける際, CSP は Binding Protocol と関連する鍵の提示プロトコルが当該 Authenticator が用いられる AAL に見合ったセキュリティレベルであることを保証すること (SHALL). 例えば, 関連する鍵の提示プロトコルは Authenticated Protected Channel を使うか対面で行い, Adversary-in-the-Middle Attack から保護しなければならない (SHALL). Multi-factor Authenticator の Binding には, Multi-factor Authentication ないしそれ相当 (e.g., Identity Proofing が完了した直後の Session との関連付け) の利用を必要としなければならない (SHALL). 同じ条件は, Authenticator により Key Pair が生成され Public Key が CSP に送信される際にも適用される.

Binding プロセスの一環として, CSP は, 要求されている AAL に適合しているか, およびエンドポイントと Authenticator がマルウェアに感染していないかどうか判断するために, 新しい Authenticator やそれに関連するエンドポイントに関する追加情報を要求してもよい (MAY).

Binding at Enrollment

Enrollment プロセスの一環として Authenticator を Subscriber Account に紐づける際には, 以下の要件が適用される.

CSP は, Memorized Secret や1つ以上の Biometric Characteristics (生体特徴) に加え, 最低限1つ - そしてできれば最低限2つ (SHOULD) - の物理 Authenticator (something you have) を Subscriber Account に紐づけなければならない (SHALL). 複数の Authenticator の Binding により, Subscriber のプライマリー Authenticator の紛失や盗難時のリカバリー手段が確保される. オンラインマテリアルやオンラインレピュテーションが長期間維持されていくほど, Authenticator を紛失し Subscriber Account のコントロールを失うことはますます望ましくないものとなる. 2つめの Authenticator は Authenticator 紛失時のセキュアなリカバリーを可能とする.

Enrollment と Binding が一度の物理的やりとりや電子的 Transaction (i.e., 単一の Protected Session 内) で完了できない場合は, 以下の方法によりプロセス全体を通じて同じ当事者が Applicant として行動していることを保証すること (SHALL).

Remote Transaction の場合:

Applicant は, 各新規 Binding Transaction において, 事前の Transaction 内で確立された, ないしは Applicant の電話番号, メールアドレスまたは Address of Record に配送された Temporary Secret を提示して, 自らを同定しなければならない (SHALL).

長期間有効な Authenticator Secret は, Protected Session 内で Applicant に発行せねばならない (SHALL).

対面の Transaction の場合:

Applicant は, 上記 Remote Transaction (1) で述べたシークレットか事前の対面処理中に記録された Biometric を利用して, 自らを同定せねばならない (SHALL).

Temporary Secret を再利用してはならない (SHALL NOT).

CSP が物理 Transaction 中に長期間有効な Authenticator Secret を発行する場合, その Authenticator Secret は Applicant に対面で発行される物理デバイスにその場でロードするか, Address of Record を確認できる方法で配送されなければならない (SHALL).

Post-Enrollment Binding

Binding of an Additional Authenticator at Existing AAL

Memorized Secret を除き, CSP と Verifier は, Subscriber が使用することになる, ファクターの異なる最低限2つ以上の有効な Authenticator を維持するよう推奨すべきである (SHOULD). 例えば, 普段 OTP Device を物理 Authenticator として使用する Subscriber には, 物理 Authenticator が紛失, 盗難, 損傷した場合にそなえ, いくつかの Look-up Secret Authenticator を発行したり, Out-of-band Authentication のためのデバイスを登録させることができる (MAY). Memorized Secret Authenticator の置換に関する詳細情報は Sec. 6.1.2.3 を参照のこと.

以上のことから, CSP は追加の Authenticator を Subscriber Account に紐づけることを許容するべきである (SHOULD). 新しい Authenticator を追加する前に, CSP は Subscriber に当該 Authenticator が利用されることになる AAL (ないしより高い AAL) で Authenticate することを要求しなければならない (SHALL). 新 Authenticator の紐付け要求に続いて, 既存の Authenticator を用いた独立した Authentication を実行し (SHALL), 当該 Authentication を20分間有効とすること (SHALL). Authenticator が追加された際, CSP は Subscriber に新しい Authenticator を紐づけた Transaction とは独立したメカニズムを用いて通知を送るべきである (SHOUD) (e.g., 事前に Subscriber に関連づけられていたアドレスへの Email). CSP はこの方法で紐づけられる Authenticator の数を制限してもよい (MAY).

Adding an Additional Factor to a Single-Factor Subscriber Account

Subscriber Account が1つしか Authentication Factor を持たず, 異なる Authentication Factor の Authenticator が追加されようとしている時, Subscriber は Subscriber Account を AAL2 に昇格するよう要求することができる (MAY).

新たな Authenticator を紐づける前に, CSP は Subscriber に AAL1 で Authenticate するよう要求しなければならない (SHALL). CSP は, 新しい Authenticator を紐づけた Transaction とは独立したメカニズムを用いて, Subscriber に当該イベントに関する通知を送るべきである (SHOULD) (e.g., 事前に Subscriber に関連づけられていたアドレスへの Email).

Account Recovery

Subscriber が Authenticator の制御を失った状況から Authenticate を成功させることができるようにするシチュエーションを, 一般的に Account Recovery と呼ぶ.

Identity Proofing を終えた Subscriber が Authentication を完了するために必要なすべての Authenticator を失った場合, [SP800-63A] にあるように Subscriber は Identity Proofing プロセスをやり直さねばならない (SHALL). CSP が ([SP800-63A] Sec. 5.2.2 にあるプライバシーリスク評価に従って) 元の Identity Proofing プロセスで用いられた Evidence の情報を保持しており, 元の Identity Proofing プロセスが当該 Evidence の有効性を検証した上で Subscriber に対して Verification を実行するだけで事足りるものであれば, 2度目のやり直しプロセスは [SP800-63A] にあるように Identity Proofing プロセスの Verification のみを再実行するだけでよい (MAY).

CSP は, Claimant がもしまだ残されたファクターの Authenticator を保持していれば, 既存 Subscriber Account との Binding を確認するため, それを用いて Authenticate するよう要求しなければならない (SHALL). IAL3 における Autentication Factor の再確立は, [SP800-63A] Sec. 5.6.8 にあるように対面ないし Supervised Remote プロセスを介して行わねばならず (SHALL), 元の Identity Proofing プロセス中に収集された Biometric 特性に対する Biometrics 比較を行わねばならない (SHALL).

CSP は Subscriber にこのイベントの通知を送るべきである (SHALL). これは Identity Proofing プロセスの一環として要求されたものと同じ通知でもよい (MAY).

Identity Proofing を終えていない Subscriber Account (i.e., IAL がない) は, Subscriber を当該アカウントに再び関連づける信頼できる方法が存在しないため, リカバリーもできない. そういったアカウントは放棄されたものとして扱い (SHALL), 新たな Subscriber Account を確立すること (SHALL).

紛失した (i.e., 忘れ去られた) Memorized Secret の置換は, それが非常に一般的であるがゆえに問題が多い. 追加の “バックアップ用” Memorized Secret は, 大抵の場合それもまた忘れ去られるため, 対策にならない. Biometric が Subscriber Account に紐づいていれば, 新たな Memorized Secret の確立にこの Biometrics 特徴と関連する物理 Authenticator を用いるべきである (SHALL).

Subscriber Account に Biometric が紐づけられていない場合における上記の再 Proofing プロセスの代替として, CSP は, Subscriber の Address of Record の1つに送られた確認コードとともに, 2つの物理 Authenticator を用いて, 新たな Memorized Secret を Authentication に紐づけることもできる (MAY). この確認コードは, Approved な乱数ビット生成器 [SP800-90Ar1] で生成された最低限6文字のランダムな英数字で構成すること (SHALL). 確認コードは最大限以下の期間のみ有効なものとする (SHALL).

米国本土の Address of Record に郵送される場合は21日.
米国本土以外の Address of Record に郵送される場合は30日.
記録済電話番号に (SMS ないし音声で) 送信される場合は10分.
記録済 Email アドレスに送信される場合は24時間.

External Authenticator Binding

External Authenticator Binding とは, Authenticated エンドポイントに接続されていない (または埋め込まれていない) Authenticator を Subscriber Account に Binding するプロセスである. 通常このプロセスは, 新たなエンドポイントに埋め込まれた Authenticator を追加する, ないしは接続の制限により新しく紐づけられた Authenticator が Authenticated エンドポイントに接続できない際に用いられる.

Binding プロセスは, CSP に Authenticate されたエンドポイントからの要求により開始できる (MAY). CSP への Authenticate は, CSP から受け取った Binding Code を, 新たな Authenticator に関連づけられたエンドポイントに入力して CSP に送信することで行う. さらに, 新たな Authenticator に関連づけられたエンドポイントが, CSP から Binding Code を取得して, それを Authenticated エンドポイントに入力して CSP に送信することもできる (MAY).

上記 Sec. 6.1.2.1, Sec. 6.1.2.2, および Sec. 6.1.2.3 に挙げた要件に加え, External Authenticator Binding には以下の要件も適用される.

新たな Auehtnicator に関連づけられるエンドポイントと CSP が Authenticated Protected Session を確立すること (SHALL).

新たな Authenticator に関連づけられるエンドポイントにおいて, CSP が Subscriber を識別できるような識別子を Subscriber に入力するよう促しても良い (MAY).

CSP は Approved な乱数生成器を用いて Binding Code を生成し, それを新たな Authenticator エンドポイントないし Binding を許可しようとしている Authenticated エンドポイントに送らなければならない (SHALL). 前ステップで入力された識別子と組み合わせて使用する場合, Binding Code は最低限40bitのEntropyを持つものとする (SHALL). それ以外の場合は少なくとも112bitの Entropy が必要となる (SHALL).

Subscriber は Binding Code を他方のエンドポイントに送信しなければならない (SHALL). この送信は手動ないし QR コード等のローカルの Out-of-band な手法で行うべきである (SHOULD). Binding Code は Email や PSTN (SMS / 音声) のようなセキュアでない経路で送信してはならない (SHALL NOT).

Binding Code の利用は一度きりとし (SHALL), 有効期限は最大10分までとする (SHALL).

新たな Authenticator の Binding (PKI ベースの Authenticator の場合は証明書の発行) の後, CSP は当該プロセスが成功裏に完了したことを確認するため, Subscriber に新たな Authenticator を用いて Authenticate するよう促すべきである (SHOULD).

CSP は, Authenticator Binding の事故が発生した場合に何をすべきか, Subscriber に明確な手順書を提供すること (SHALL). これには誤って紐づけられた Authenticator を即座に適切に無効化できるようなボタンや連絡先などが挙げられる. これは Authenticated Session や Binding 通知ないで提供することもできる (MAY). Binding 通知に関しては Sec. 6.1.2.1, Sec. 6.1.2.2, Sec. 6.1.2.3 を参照のこと.

Subscriber が騙されて Attacker に Binding Code を使用させられたり, Attacker に Binding Code を提供してしまったりする可能性があるため, External Authenticator の Binding は潜在的にリスクのある操作である. 場合によっては, 信頼できる情報源 (Authenticated Session から取得したものなど, 特に Authenticated Session が Phishing 耐性を持つものであればことさら) から取得した QR コードはそのような攻撃に対してより堅牢であると考えられる. これは通常そのような QR コードが Binding Code とともに CSP の URL を含むからである. そのような条件下では, Subscriber が騙されて Phishing サイトで Binding Code を入力する可能性が低くなる.

Binding to a Subscriber-provided Authenticator

Subscriber は特定の AAL での Authentication に適した Authenticator をすでに所有している可能性もある. 例えば, AAL2 および IAL1 とみなされるソーシャルネットワークプロバイダーから提供された2-factor Authenticator を持っており, その Credential を IAL2 を要求する RP に対して使用したいかもしれない.

CSP は, 差し支えなければ, Subscriber が提供した Authenticator を使用できるようにし, 多数の Authenticator を管理するという Subscriber の負担を軽減すべきである (SHOULD). そういった Authenticator の Binding に関しては Sec. 6.1.2 に従うこと (SHALL). Authenticator の強度が自明でない場合 (e.g., 特定のタイプの Single-factor Authenticator と Multi-factor Authenticator の間), より強力な Authenticator が実際に使われていることを立証 (e.g., Authenticator 発行者ないし製造者に対する Verification) できない限り, CSP はより弱い Authenticator が使われているものと想定すること (SHALL).

Renewal

Subscriber は, 既存の Authenticator の有効期限が切れる前に, 適切な時間的余裕を持って, 新規または更新すべき Authenticator を紐づけるべきである (SHOULD). このプロセスは, Sec. 6.1.2.1 で述べた追加の Authenticator の Binding プロセスにしっかりと従うべきである (SHOULD). CSP は, 更新プロセスの一環ないしそれとは別に, Address of Record の再確認などの他のアクションを定期的に実行してもよい (MAY). Authenticator の交換に成功した後, CSP は有効期限が切れそうな Authenticator を無効化してもよい (MAY).

Loss, Theft, Damage, and Unauthorized Duplication

侵害された Authenticator には, 紛失, 盗難, 無許可の複製の対象となったものなどが含まれる. 一般に, 紛失した Authenticator は, 正規の Subscriber ではない誰かに盗まれたか侵害されたと想定する必要がある. 損傷ないし誤動作している Authenticator もまた, Authenticator Secret が抽出される可能性を防止するため, 侵害されたとみなされる. ただし, Attacker に取得されたなどの侵害の兆候もなく忘れ去られた Memorized Secret は例外とする.

侵害された Authenticator の一時停止, 失効, ないし破棄は, それを検出した時点で出来る限り迅速に行うべきである (SHOULD). 組織はこのプロセスにタイムリミットを設定すべきである (SHOULD).

Authenticator の紛失, 盗難, ないし損傷をセキュアに報告しやすくするため, CSP は Subscriber にバックアップまたは代替の Authenticator を使って CSP に対する Authenticate を行う手段を提供すべきである (SHOULD). このバックアップ Authenticator は Memorized Secret ないし物理 Authenticator とすること (SHALL). どちらを使用して良いが, この報告には必要な Authentication Factor はどちらか一方のみである. また代わりに, Subscriber が CSP と Authenticated Protected Channel を確立し, Proofing プロセス中に収集された情報を検証することもできる (MAY). CSP は Address of Record の検証 (i.e., Email, 電話, 郵便) を選択し, 侵害報告のあった Authenticator を一時停止にしてもよい (MAY). Subscriber が有効な (i.e., 一時停止されていない) Authenticator を使用して CSP への Authentication に成功し, 同じ方法で一時停止にされた Authentication の Reactivation を要求した場合, 一時停止は元に戻すものとする (SHALL). CSP は, 一時停止された Authenticator が Reactivate できなくなるまでのタイムリミットを設定してもよい (MAY).

Expiration

CSP は有効期限付きの Authenticator を発行しても良い (MAY). Authenticator が有効期限切れになった場合, それを Authentication に使用可能にしてはならない (SHALL NOT). 有効期限切れの Authenticator を用いた Authentication 試行があった場合, CSP は Authentication の失敗が他の要因ではなく期限切れによるものであることを Subscriber に通知すべきである (SHOULD).

CSP は Subscriber に対して, 有効期限切れ後または更新された Authenticator の受領後出来るだけ早く, CSP が署名した Attribute Certificate を含む物理 Authenticator を返却するよう, または破棄したことを証明するよう要求すること (SHALL).

Invalidation

Authenticator の無効化 (Invalidation) とは, Authenticator と Subscriber Account の間の Binding を削除することをいう (Revocation や Termination と呼ばれることもある).

CSP は, Subscriber Account が存在しなくなった場合 (e.g., Subscriber の死亡, 不正な Subscriber の発見), Subscriber から要求を受けた場合, ないしは Subscriber がもう適格要件を満たさないと CSP が判断した場合, 即座に Authenticator を無効化しなければならない (SHALL).

CSP は, 無効化を実施した後できるだけ早く, CSP が署名した証明書などの Subscriber Attribute を含む物理 Authenticator の返却または破棄証明を Subscriber に要求すること (SHALL). これは, Subscriber のプライバシーを保護し, 証明書が無効化されてから期限切れになるまでの間にオフラインの状況で利用されることを防止するために必要である.

PIV Authenticator の無効化に関するさらなる要件については [FIPS201] を参照のこと.

Session Management

This section is normative.

一度 Authentication イベントが発生すると, Subscriber が Authentication イベントを繰り返さなくとも, 後続の複数のインタラクションに渡ってアプリケーションを使い続けられるようにすることが望ましいことが多い. この要件は [SP800-63C] で述べる Federation シナリオで特に当てはまる. Federation シナリオでは, Authentication イベントに複数のコンポーネントおよび当事者が関与し, Network 全体で協調する必要がある.

上記の挙動を円滑にするため, Authentication イベントに呼応して Session を開始して, 終了されるまでそれを継続させることもできる (MAY). Session は, 非アクティブタイムアウト, 明示的ログアウトイベント, またはその他の手段を含む, 様々な理由で終了させてよい (MAY). Session は Sec. 7.2 で述べる Reauthentication イベントを通じて継続してもよい (MAY). Reauthentication イベントでは, Subscriber は最初の Authentication イベントの一部または全てを繰り返し, それにより Session を再確立する.

Session Management は頻発する Credential の提示より好ましい. Credential の提示が頻発すると Usability が悪化し, Activation Factor のキャッシング, Authentication Intent の無効化, Authentication イベントの鮮度の不明瞭化などを引き起こすような回避策へのインセンティブを引き起こすことが多い.

Session Bindings

Session は, Subscriber が実行しているソフトウェア - ブラウザ, アプリケーションないしオペレーティングシステム (i.e., Session Subject) - と, Subscriber が Access している RP ないし CSP (i.e., Session Host) の間で発生する. Session Secret は Subscriber のソフトウェアと Access されるサービスの間で共有しなければならない (SHALL). このシークレットは Session の両端を Bind し, Subscriber が長時間サービスを使い続けられるようにする. このシークレットは Subscriber ソフトウェアから直接提示されるか (SHALL), 暗号論的メカニズムによりその保有が証明されなければならない (SHALL).

Authenticated Session の継続性は, Authentication 時に Verifier に発行され, オプションで Session 中に更新される Session Secret を保持しているかどうかに基づいている必要がある (SHALL). Session の性質は次のようなアプリケーションによって異なる.

“Session” Cookie による Web ブラウザ Session
Session Secret を保持するモバイルアプリケーション

Session Secret は永続的 (紐づくアプリケーションのリスタートやホストデバイスのリブートを挟んでも保持される) であってはならない (SHALL NOT).

Session Binding に用いられるシークレットは, Authentication イベントに直接レスポンスする Session Host によって生成されなければならない (SHALL). Session は, それを生成するトリガーとなった Authentication イベントの AAL プロパティを継承すべきである (SHOULD). Session は Authentication イベントより低い AAL であるとみなすこともできるが (MAY), Authentication イベントより高い AAL であるとみなしてはならない (SHALL NOT).

Session Binding に用いられるシークレットは以下の全要件を満たさねばならない (SHALL).

シークレットは Session Host によってインタラクション中に生成されること. 通常は Authentication 直後に.
シークレットは Approved なランダムビット生成器 [SP800-90Ar1] で生成し, 少なくとも64bitの Entropy を持つこと.
シークレットは Subscriber がログアウトした際は Session Subject により消去ないし無効化されること.
シークレットは Authenticated Protected Channel を利用したデバイスによって送信, 受信されること.
シークレットは, AAL に応じて, Sections 4.1.3, 4.2.3, ないし 4.3.3 に指定された時間を超えたのちはタイムアウトし, 受け入れられないこと.
シークレットは Host と Subscriber エンドポイント間のセキュアでないコミュニケーションにさらさないこと.

さらに, Session Binding に用いられるシークレットは, Subscriber がログアウトしたりシークレット自身が有効期限切れになったと見なされた時に, Subscriber エンドポイントから削除されるべきである (SHOULD). シークレットは HTML5 Local Storage などのセキュアでない場所に置くべきではない (SHOULD NOT). ローカルストレージは Cross-site Scripting (XSS) Attack に晒される可能性がある.

Authenticated Session は Authentication 後に, HTTPS から HTTP など, セキュアでない通信路にフォールバックしてはならない (SHALL NOT).

URL や POST コンテンツには, Cross-site Request Forgery 対策のために, RP が検証する (SHALL) Session 識別子を含めることとする (SHALL).

長時間 Session を管理するためのメカニズムはいくつか存在する. 後続のセクションでは, さまざまな例を, 各テクノロジー例固有の追加要件および考慮事項とともに示す. OWASP Session Management Cheat Sheet [OWASP-session] にも追加の有益なガイダンスが存在する.

Browser Cookies

ブラウザ Cookie は, Session を生成するための有力なメカニズムであり, サービスに Access する Subscriber を追跡するものである. Cookie は Authenticator ではないが, 短期間のシークレット (セッション中) に適している.

Session の維持に用いられる Cookie は以下の全要件を満たすこと (SHALL).

Cookie はセキュア (HTTPS) Session でのみアクセス可能なようタグ付けすること.
Cookie は必要最小限のホスト名およびパスのセットでのみアクセス可能であること.

さらに, Session 維持用 Cookie は, JavaScript からアクセスできないようにタグ付け (HttpOnly) されるべきである (SHOULD). 当該 Cookie は, Opaque 文字列 (Session 識別子など) のみで構成されるべきであり (SHOULD), 平文の PII を含むべきではない (SHOULD NOT). また当該 Cookie は, Session 有効期間終了時または終了後すぐに有効期限切れになるようタグ付けされるべきである (SHOULD). 最後の要件は Cookie の蓄積を制限することを目的としたものであり, Session タイムアウトの強制のためにそれに依存してはならない (SHALL NOT).

Access Tokens

Access Token - OAuth などで見られる - は, アプリケーションが Authentication イベント後に Subscriber の代理としてあるサービス群に Access することを許可するために用いられる. RP は, 他のシグナルがない限り, OAuth Access Token が存在することをもって Subscriber がそこに存在すると解釈してはならない (SHALL NOT). OAuth Access Token および関連する Refresh Token は, Authentication Session が終了し Subscriber がアプリケーションを去った後でも長期間有効でありうる (MAY).

Device Identification

Secure Device Identification のその他の手法 - mutual TLS, Token Binding, またはその他のメカニズム - も, Subscriber とサービスの間で Session を実現するために使用できる (MAY).

Reauthentication

Session の定期的な Reauthentication を実行し, Authenticated Session に Subscriber が引き続き存在することを確認すること (SHALL). (i.e., Subscriber がログアウトせずに立ち去っていないか)

Session は, Session Secret の提示のみをもって, (AAL に応じて) セクション 4.1.3, 4.2.3, および 4.3.3 のガイドラインを超えて延長してはならない (SHALL NOT). Session の有効期限が切れる前に, Table 2 で指定された Authentication Factor を Subscriber に求めることで, Reauthentication タイムリミットを延長すること (SHALL).

タイムアウトか他のアクションにより Session が終了した場合は, Subscriber に再度 Authentication を行い新たな Session を確立するよう要求すること (SHALL).

Table 2 AAL Reauthentication Requirements

AAL	Requirement
1	任意の1ファクターの提示
2	Memorized Secret ないし Biometric の提示
3	全ファクターの提示

Note: AAL2 では, 物理 Authenticator ではなく Memorized Secret や Biometric が求められる. Session Secret は something you have であるため, Session の継続には追加の Authentication Factor が求められるのである.

Reauthentication from a Federation or Assertion

[SP800-63C] で述べたように, RP に Authenticate するために Federation Protocol と Identity Provider (IdP) を使用する場合は, Session Management と Reauthentication に特別な考慮事項が適用される. Federation Protocol は Assertion を用いて IdP での Authentication イベントを RP に伝達し, RP はこの Assertion の検証の成功をもって Authenticated Session を開始する. IdP と RP は Session を個別に管理し, Federation Protocol は IdP と RP の Session Management を接続しないため, IdP と RP での Session の終了は互いに独立して行われる. 同様に, Subscriber が複数の RP で持つ Session は, 互いに独立して確立および終了される.

したがって, RP Session が期限切れになり RP が Reauthentication を要求する時, IdP の Session が期限切れになっておらず, Subscriber を明示的に Reauthenticate することなく, IdP のこの Session にもとづいて新たな Assertion が生成される可能性は十分にある. IdP が Authentication イベントの発生時間および詳細を RP に伝えることもできるが, Reauthentication 要件が満たされているかを判断する責任は RP にある. [SP800-63C] Section 5.3 には Federation コンテキストにおける Session Management に関するさらなる詳細および要件が記載されている.

Threats and Security Considerations

This section is informative.

Authenticator Threats

Authenticator のコントロールを取得できる Attacker は, 多くの場合 Authenticator 所有者になりすますことができる. Authenticator に対する脅威は, Authenticator を構成する Authentication Factor タイプに対する Attack に基づいて分類できる.

Something you know には, Attacker に対する露呈のリスクがある. Attacker は Memorized Secret を推測できるかもしれない. Authenticator が Shared Secret の場合, Attacker は CSP または Verifier への Access を得てシークレット値を取得したり, シークレットのハッシュ値に対する辞書攻撃を実行するかもしれない. Attacker は PIN やパスコードの入力を監視したり, PIN やパスコードのメモ書き等を見つけたり, 悪意あるソフトウェア (e.g., キーロガー) をインストールしてシークレットを取得する可能性もある. さらに Attacker は Verifier が管理する Password データベースへのオフライン攻撃を通じてシークレットを特定するかもしれない.

Something you have には, 紛失, 損傷, 所有者からの盗難, Attacker による複製などのリスクがある. 例えば所有者のコンピューターへの Access を得た Attacker は, Software Authenticator を複製するかもしれない. Hardware Authenticator は盗難, 改ざん, 複製されるかもしれない. Out-of-band Secret は Attacker に傍受され, Attacker 自身の Session の Authenticate に使用される可能性がある.

Something you are には, 複製のリスクがある. 例えば, Attacker は Subscriber の指紋のコピーを取得し, レプリカを作成する可能性がある.

本ドキュメントは, Subscriber が Verifier に対して偽って Authenticate しようとしている Attacker と共謀していないことを前提とする. この前提の元, Digital Authentication に用いられる Authenticator に対する脅威を, いくつかの例とともに Table 3 に示す.

Table 3 Authenticator Threats

Authenticator Threat/Attack	Description	Examples
Assertion Manufacture or Modification	Attacker が偽の Assertion を生成する.	侵害された CSP が正しく Authenticate されていない Claimant の Identity を主張する.
	Attacker が既存 Assertion を改ざんする.	侵害された Proxy が Authentication Assertion の AAL を書き換える.
Theft	物理 Authenticator が Attacker に盗まれる.	Hardware Cryptographic Device が盗まれる.
		OTP Device が盗まれる.
		Look-up Secret Authenticator が盗まれる.
		携帯電話が盗まれる.
Duplication	Subscriber の Authenticator が, 知覚の有無を問わずコピーされる.	紙に書かれた Password が露呈する.
		電子ファイルに保存された Password がコピーされる.
		Software PKI Authenticator (Private Keye) がコピーされる.
		Look-up Secret Authenticator がコピーされる.
		Biometric Authenticator が偽造される.
Eavesdropping	Subscriber が Authenticate している間に, Authenticator Secret や Authenticator Output が Attacker に露呈する.	キーボード入力の監視により Memorized Secret が取得される.
		Memorized Secret や Authenticator Output がキーロガーソフトウェアに傍受される.
		PIN が PIN パッドデバイスから捕捉される.
		ハッシュ化された Password が取得され, Attacker によって別の Authentication に利用される. (pass-the-hash attack).
	Out-of-band Secret がコミュニケーションチャネルの侵害により Attacker に傍受される.	Out-of-band Secret が暗号化されていない Wi-Fi を介して送信され, Attacker に受信される.
Offline Cracking	Authenticator が Authentication メカニズム外部の分析手段により露呈する.	Software PKI Authenticator が辞書攻撃を受け, Private Key 復号用の正しい Password が特定される.
Side Channel Attack	Authenticator の物理特性を利用して Authenticator Secret が露呈する.	Hardware Cryptographic Authenticator に対する差分電力分析により, 鍵が抽出される.
		Cryptographic Authenticator Secret が, 大量の試行にわたる Authenticator レスポンスタイムの分析により抽出される.
Phishing or Pharming	Subscriber を騙して Attacker を Verifier ないし RP だと思い込ませることで, Authenticator Output が捕捉される.	Subscriber が Verifier を装う Web サイトに Password を開示してしまう.
		銀行の Subscriber が, 銀行を装う詐欺師からの電子メールでの問い合わせに応じて, Memorized Secret を開示してしまう.
		Subscriber が, DNS スプーフィングによって偽の Verifier Web サイトに到達し, Memorized Secret を開示してしまう.
Social Engineering	Attacker が Subscriber と一定レベルの信頼を確立し, Subscriber に自身の Authenticator Secret や Authenticator Output を開示するよう言い聞かせる.	Subscriber が, Subscriber の上司の代理として Password を要求する同僚に, Memorized Secret を開示してしまう.
		Subscriber が, システム管理者になりすました Attacker からの電話問い合わせにより, Memorized Secret を開示してしまう.
		SMS で送られた Out-of-band Secret が, 被害者の携帯電話を Attacker にリダイレクトするよう言い聞かされた携帯電話会社により, Attacker に送られる.
Online Guessing	Attacker がオンラインで Verifier に接続し, Verifier のコンテキストで有効な Authenticator Output を推測する.	Memorized Secret の推測のためオンライン辞書攻撃が行われる.
		正規の Claimant に登録された OTP Device の Authenticator Output 推測のため, オンライン推測が行われる.
Endpoint Compromise	エンドポイント上の悪意あるコードが Subscriber の同意なしに接続された Authenticator への Remote Access を Proxy する.	エンドポイントに接続した Cryptographic Authenticator が Remote Attacker の Authenticate に使用される.
	エンドポイント上の悪意あるコードが原因となり, 意図した Verifier 以外に Authentication が行われる.	Authentication が Subscriber ではなく Attacker を代理して行われる.
		エンドポイント上の悪意あるアプリが SMS で送られた Out-of-band Secret を読み取り, Attacker がそのシークレットを Authenticate に利用する.
	エンドポイント上の悪意あるコードが Multi-factor Software Cryptographic Authenticator を侵害する.	悪意あるコードが Authentication やエンドポイントからの Authenticator 鍵のエクスポートを Proxy する.
Unauthorized Binding	Attacker が自身のコントロール下にある Authenticator を Subscriber Account に紐づけることができる.	Attacker が Subscriber に届く途中の Authenticator や Provisioning 鍵を横取りする.

Threat Mitigation Strategies

上記で特定された脅威を軽減するための手助けとなる関連メカニズムを Table 4 に示す.

Table 4 Mitigating Authenticator Threats

Authenticator Threat/Attack	Threat Mitigation Mechanisms	Normative References
Theft	Memorized Secret や Biometric により Activate する必要のある Multi-factor Authenticator を使用する.	4.2.1, 4.3.1
	Memorized Secret や Biometrics を含む Autheticator の組み合わせを使用する.	4.2.1, 4.3.1
Duplication	Long-term Authentication Secret の抽出や複製が困難な Authenticator を使用する.	4.2.2, 4.3.2, 5.1.7.1
Eavesdropping	エンドポイントのセキュリティを保証する. 特に使用前にキーロガーなどのマルウェアに侵されていないか確認すること.	4.2.2
	Out-of-band Authenticator Secret の送信時, Authenticate されておらず暗号化もされていないコミュニケーションチャネルを避ける.	5.1.3.1
	Authenticated Protected Channel を介して Authenticate する. (e.g., ブラウザウィンドウの鍵アイコンを視認する)	4.1.2, 4.2.2, 4.3.2
	pass-the-hash などの Replay Attack 耐性のある Authentication Protocol を使用する.	5.2.8
	信頼できる入力機能と信頼できる表示機能を備えた Authentication エンドポイントを使用する.	5.1.6.1, 5.1.8.1
Offline Cracking	高 Entropy な Authenticator Secret を持つ Authenticator を使用する.	5.1.2.1, 5.1.4.1, 5.1.5.1, 5.1.7.1, 5.1.9.1
	中央で検証された Memorized Secret を, 鍵付きハッシュを含む Salt 付きハッシュ形式で保存する.	5.1.1.1.2, 5.2.7
Side Channel Attack	シークレット値に関係なく一定の電力消費およびタイミングを維持するよう設計された Authenticator アルゴリズムを使用する.	4.3.2
Phishing or Pharming	Phishing 耐性のある Authenticator を使用する.	5.2.5
Social Engineering	カスタマーサービス代行業者等の 3rd-party の Social Engineering リスクをもたらす Authenticator の使用を避ける.	6.1.2.1, 6.1.2.3
Online Guessing	高 Entropy な Output を生成する Authenticator を使用する.	5.1.2.1, 5.1.7.1, 5.1.9.1
	Activation が一定回数以上連続して失敗した際にロックされるような Authenticator を使用する.	5.2.2
Endpoint Compromise	Subscriber の物理アクションを要求するようなハードウェア Authenticator を使用する.	5.2.9
	Access が制限されたストレージ内でソフトウェアベースの鍵を管理する.	5.1.3.1, 5.1.6.1, 5.1.8.1
Unauthorized Binding	Authenticator および関連する鍵の Provisioning には AitM 耐性のあるプロトコルを使用する.	6.1

Table 3 に挙げた脅威の軽減には, 他にもいくつかの戦略が適用可能である.

多要素 (Multiple factors) により, Attack の成功はさらに困難になる. Attacker が Cryptographic Authenticator を盗んだ上で Memorized Secret を推測しなければならない場合, 両方のファクターを見つけ出すための仕事量は多すぎる可能性がある.

物理セキュリティメカニズム (Physical security mechanism) を採用し, 盗まれた Autheticator を複製から保護することも可能である. 物理セキュリティメカニズムは改ざんの証拠, 検出, 応対も可能にしうる.

長い Memorized Secret の使用を要求 (Requiring the use of long memorized secrets) する. そのようなシークレットは一般的な辞書には載っておらず, Attacker は全ての取りうる値を総当たりしなければならなくなる可能性がある.

システムおよび Network セキュリティコントロール (System and network security controls) を採用し, Attacker がシステムへの Access を得たり不正なソフトウェアをインストールすることを防ぐことも可能である.

定期的なトレーニング (Periodic training) を実施し, Subscriber がいつどのように侵害 - または侵害の疑い - を報告すべきか, いつどのように Attacker が Authentication プロセスを侵害しようとしていることを示しているかもしれない行動パターンを認識しうるかを理解できるようにすることもできる.

Out-of-band なテクニック (Out of band techniques) を採用し, 登録デバイス (e.g., 携帯電話) の保持証明を検証することもできる.

Authenticator Recovery

多くの Authentication メカニズムの弱点は, Subscriber が1つ以上の Authenticator のコントロールを失いそれらをリプレイスする必要がある際のプロセスにある. 多くの場合, Subscriber を Authenticate するために残された利用可能な手段は限られており, 経済的な懸念 (e.g., コールセンターの維持費) が安価でしばしば安全性の低いバックアップ Authentication 手法を利用するモチベーションにつながっている. また, Authenticator リカバリーが人間の支援によるものである限り, Social Engineering Attack のリスクもつきものである.

Authentication Factor の Integrity (完全性) を維持するには, あるファクターを含む Authentication を利用して別のファクターの Authenticator を取得できないようにすることが不可欠である. 例えば, Memorized Secret は Look-up Secret の新しいリストを取得するために利用可能であってはならない.

Session Attacks

上記は Authentication イベント自体に対する脅威にフォーカスしているが, Authentication イベントに後続する Session に対する Hijacking Attack も同様のセキュリティインパクトを及ぼしうる. Sec. 7 の Session Management ガイドラインは, XSS などの Attack に対する Session Integrity (完全性) 維持に不可欠である. さらに表示される情報を全てサニタイズして [OWASP-XSS-prevention], 実行可能なコンテンツが含まれないようにすることも重要である. これらのガイドラインは, Session Secret の流出に対するさらなる保護策として, Mobile Code が Session Secret にアクセスできないようにすることも推奨している.

もう一つの Authentication 後の脅威である Cross-site Request Forgery (CSRF) は, 複数の Session を同時にアクティブにするユーザーの傾向を利用する. Session 識別子を Web リクエストに埋め込んで検証し, 有効な URL ないしリクエストが意図せずにまたは悪意を持ってアクティベートされるのを防ぐことが重要である.

Privacy Considerations

これらのプライバシー考慮事項は Sec. 4 のガイダンスを補足する. This section is informative.

Privacy Risk Assessment

Sections 4.1.5, 4.2.5, 4.3.5 は, CSP が記録保持のためのプライバシーリスク評価を実施することを要求する. このようなプライバシーリスク評価には, 以下を含む:

記録の保持によって, Subscriber に情報への侵入や未承認のアクセスなどの問題が起こる可能性.
そのような問題が発生した場合の影響.

CSP は, リスクの受け入れ, リスクの軽減, リスクの共有を含む識別されたプライバシーリスクに対して行うあらゆる対応を合理的に正当化できる必要がある. Subscriber の同意の使用は, リスクを共有する形式であるため, Subscriber が共有されたリスクを評価して受け入れる能力を持っていると合理的に期待できる場合にのみ使用するのが適切である.

Privacy Controls

Section 4.4 は, CSP が適切に調整されたプライバシーコントロールを採用することを要求する. [SP800-53] は, CSP が Authentication メカニズムを展開する際に考慮すべき一連のプライバシーコントロールを提供する. これらのコントロールは, 効果的で信頼に値する展開のための通知, 是正, およびその他の重要な考慮事項をカバーする.

Use Limitation

Section 4.4 は, CSP に対して, Identity Proofing, Authentication, Authorization, または Attribute Assertion, 関連する不正の軽減, または法律と法的手続きの遵守以外の目的でのAttribute の処理から生じる可能性のあるプライバシーリスクに見合った Predictability (個人, 所有者, オペレーターによる, PII と情報システムによる Processing について信頼できるという仮定を可能にする) および Manageability (情報システムによる変更, 削除, 選択的開示を含む PII の詳細な管理の提供) の目的を維持するための手段を使用することを要求する [NISTIR8062].

CSP は, Subscriber に Non-Identity Services を提供することを含む, Attribute を処理するためのさまざまなビジネス目的を持つ場合がある. しかし, 収集時に指定された以外の目的で Attribute を処理することは, 個人が追加の処理を期待していない, または快適でない場合, プライバシーリスクを作り出す可能性がある. CSP は, 追加の処理から生じるプライバシーリスクに見合った適切な手段を決定できる. たとえば, 適用される法律, 規制, ポリシーがなければ, Subscriber からリクエストされた Non-Identity Services を提供するために Attribute を処理する際に同意を得る必要はないかもしれないが, 通知は Subscriber が処理に関する信頼できる仮定を維持するのに役立つ場合がある(Predictability). Attribute のその他の処理には, 同意を取得する必要がある, または Subscriber が特定の Attribute の使用や開示をより詳細に制御できるようにする必要がある, さまざまなプライバシーリスクを運び込む可能性がある(Manageability). Subscriber の同意は意味のあるものである必要がある. したがって, Sec. 4.4 で述べられた通り, CSP が同意を手段として使用する場合, Subscriber が追加の使用を受け入れることが Authentication Service を提供する条件になることはない.

目的とする処理が許可された処理または適切なプライバシーリスク軽減手段の範囲外となるかどうかについて質問がある場合は, 政府機関の SAOP と相談する.

Agency-Specific Privacy Compliance

Section 4.4 は, 連邦の CSP の特定のコンプライアンス義務をカバーする. プライバシーリスクを評価して軽減し, Authenticator を発行・維持するための PII の収集が PIA を実施する Privacy Act of 1974 [PrivacyAct] または the E-Government Act of 2002 [E-Gov] の要件をトリガーするかどうかといったコンプライアンス要件を政府機関にアドバイスするために, Digital Authentication System 開発の一番早いステージで政府機関の SAOP を巻き込むことが非常に重要である. 例えば, Biometrics の集中管理に関しては, ほとんどの場合で Privacy Act requirements がトリガーされ, PII および Authentication に必要なその他の Attribute の収集と管理のために, 新規または既存の Privacy Act システムの記録によるカバーが要求される. 同様に, SAOP は政府機関が PIA が必要かどうかを判断することを支援できる.

これらの考慮事項は, Authentication だけのために Privacy Act SORN や PIA を開発するための要件として読まれないほうがよい. 多くの場合, Digital Identity Process 全体を網羅する PIA や SORN の草案を作成するか, 政府機関が確立しようとしているオンラインサービスやベネフィットについて議論する, より大きなプログラムによる PIA の一部として, Digital Identity Process を含めることが最も理にかなっている.

Digital Authentication には多くのコンポーネントがあるため, SAOP が個々のコンポーネントを認識し理解することが重要である. 例えば, 他の Privacy Artifact は, 連携された CSP や RP サービス (例: データ使用契約, コンピュータマッチング契約) を提供または使用する政府機関に適用される場合がある. SAOP は, 何の追加要件が適用されるかを政府機関が判断することを支援できる. さらに, Digital Authentication の個々のコンポーネントを十分に理解することは, SAOP が, コンプライアンスプロセスやその他の方法を通じて, プライバシーリスクを十分に評価, 軽減することを可能にする.

Usability Considerations

This section is informative.

本セクションでは, ユーザー という用語は Claimant ないし Subscriber を意味する.

[ISO/IEC9241-11] は Usability を “特定の利用コンテキストにおいて, 特定のユーザーが, あるシステム, プロダクトないしはサービスを利用して, 特定の目標を, どの程度有効的, 効率的かつ満足のいくレベルで達成できるかの度合い” と定義している. この定義はユーザー, 目標および利用コンテキストを, 有効性, 効率性および満足度の達成に必要な重要要素として捉えている. Usability を実現するには, これらの重要要素を考慮した総合的なアプローチが必要となる.

ユーザーが情報システムに Access する際の目標とは, 彼らが意図した何らかのタスクの実行にある. Authentication とは, その目的を可能とする機能である. しかしながらユーザー視点で見ると, Authentication は彼らと彼らの意図したタスクの間に存在するものである. Authentication の効果的な設計および実装は, 正しいことの実行を容易にし, 誤ったことの実行を困難にし, 間違いが起こった場合のリカバリーを容易にする.

組織は, ステークホルダーの Digital Authentication エコシステムへの全体的な影響を認識する必要がある. ユーザーはしばしば複数の Authenticator をそれぞれ異なる RP に対して利用しており, パスワードを覚えるために苦闘し, どの Authenticator がどの RP 向けであったか思い出すために苦闘し, 複数の物理的な Authentication デバイスを持ち運ぶために苦闘している. Authentication の Usability を評価することは不可欠であり, Usability が低いと最終的にセキュリティコントロールの有効性を損ねかねない対処策や意図しない回避策が生じることもしばしばである.

Usability を開発プロセスに組み込むことで, ユーザーの Authentication へのニーズと組織のビジネス目標に対応しながら, 安全で使いやすい Authentication ソリューションを実現できる.

適切な AAL の決定の際は, リスク評価の一環として Digital システム全体の Usability を考慮する必要がある. より高い AAL の Authenticator のほうが Usability が良い場合もあり, より低い AAL の Authentication においてもそういった Authenticator の利用を許可すべき場合がある.

[SP800-63C] で述べるように, そのアプローチ自体にもトレードオプが存在するものの, Authentication のために Federation を活用すると多くの Usability の問題を軽減できる可能性もある.

本セクションでは一般的な Usability 上の考慮事項と取りうる実装について述べるが, 特定のソリューションを推奨するものではない. ここで言及する実装は, 特定の Usability ニーズに対応するための革新的技術アプローチを促すための例に過ぎない. さらに, Usability 上の考慮事項とこれらの実装は, 1つで全てを解決する万能なソリューションを妨げるような, 多くの要因を含みがちである. 例えば, デスクトップコンピューター環境においては適切なフォントサイズでも, 小さな OTP デバイスのスクリーンで見た際は文字がはみ出してしまうかもしれない. 選択された Authenticator に対する Usability 評価の実施は, 実装上の不可欠な要素である. 評価を行う際は, 代表的なユーザー, 現実的な目標とタスク, 適切な利用コンテキストのもとで行うことが重要である.

ガイドラインと考慮事項はユーザー目線で記述されている.

Usability とは異なり, アクセシビリティに関しては本ドキュメントのスコープ外とする. [Section508] は情報技術の障壁を取り除くために制定され, 連邦政府機関に対して電子および情報技術の公開コンテンツを障害を持つ人にもアクセスできるように要求している. アクセシビリティガイドラインに関しては Section 508 の法律および標準を参照のこと.

Usability Considerations Common to Authenticators

Authentication システムの選択および実装の際は, 選択した Authenticator のライフサイクル全体 (e.g., 通常の使用や断続的イベント) における Usability を考慮すること. またその際は, ユーザー, ユーザーの目標および利用コンテキストの組み合わせに注意すること.

通常, 単一の Authenticator Type ではユーザー母集団全体の要求を満たすには不十分である. 従って可能であれば - AAL 要件に基づき - CSP は代替の Authenticator Type をサポートすべきであり, それらをユーザーのニーズに合わせて選択させるべきである. タスクの緊急度, 認識される費用対効果のトレードオフ, 特定の Authenticator への習熟度などが, しばしば選択に影響を及ぼすことになる. ユーザーは, その時点で最も負担やコストの低い選択肢を選ぶ傾向がある. 例えば, タスクが情報システムへの即時 Access を必要とする場合, ユーザーはより多くのステップを必要とする Authenticator を選択するよりも, 新しい Subscriber Account と Password を作成することを選好する可能性もある. 代わりに, Identity Provider に Subscriber Account を持っている場合, ユーザーは - 適切な AAL で Approve された - Federated Identity という選択肢を選ぶ可能性もある. ユーザーはある Authenticator を他の Authenticator よりもよく理解しており, 理解と経験に基づいて異なるレベルの信頼感を持っている可能性もある.

ユーザーによるポジティブな Authentication エクスペリエンスは, 望ましいビジネス上の成果を達成する組織の成功に不可欠である. 従って, 組織はユーザーの視点に立って Autheenticator を検討するよう努力すべきである. Authentication Usability における非常に重要な目標として, ユーザーの負担と Authentication により生じる摩擦 (e.g., ユーザーが Authenticate しなければならない回数, それにかかるステップ数, 確認しなければならない情報量) の最小化が挙げられる. Single Sign-on はそのような最小化戦略の一例である.

以下に, 大抵の Authenticator に適用可能な Usability 上の考慮事項を示す. また, 後続のセクションは, 特定の Authenticator に特化した Usability 上の考慮時を鵜を説明するものである.

すべての Authenticator の通常利用 (Typical Usage) における Usability 上の考慮事項として, 以下のようなものが挙げられる.

Authenticator の利用および保守に関する情報を提供する. e.g., Authenticator を紛失したり盗難にあった場合の対処方法, および使用手順 - 特に初回利用時または初期化時に異なる要件がある場合

ユーザーは自身の Authenticator をすぐ利用できるようにしておく必要があるため, Authenticator の Availability (可用性) も考慮すべきである. 紛失, 損傷, その他のオリジナルの Authenticator への悪影響から保護するため, 代替となる Authentication の選択肢の必要性も検討すること.

可能な限り, AAL 要件に基づき, ユーザーに代替の Authentication の選択肢を提供するべきである. これによりユーザーは自身のコンテキスト, 目標, タスク (e.g., タスクの頻度や緊急度) に基づき Authenticator を選択することができるようになる. 代替の Authentication の選択肢は, 特定の Authenticator で発生する可能性のある Availablility (可用性) の問題に対処する際にも役に立つ.

ユーザーに表示するテキストの特徴
- ユーザーに表示するテキスト (e.g., 手順書, プロンプト, 通知, エラーメッセージ) は, 対象読者向けに平易な言葉で記述すること. 専門用語を避け, 読者に想定されるリテラシーレベルに合わせた記述にすること.
- ユーザーに表示するテキストとユーザーが入力するテキストの読みやすさを考慮すること. これにはフォントスタイル, サイズ, 色, 周囲の背景とのコントラストなどを含む. 読みにくいテキストは, ユーザーの入力エラーの元となる. 読みやすさを向上させるため, 以下の採用を検討すること.
  - ハイコントラスト. 最大のハイコントラストは白地に黒である.
  - 電子的表示用には Sans Serif フォント. 印刷物用には Serif フォント.
  - 混同しやすい文字 (e.g., 大文字の “O” と数字の “0”) を明確に区別できるフォント.
  - テキストがデバイスのディスプレイでの表示に治る限り, 最小フォントサイズは12ポイント.

Authenticator 入力中のユーザーエクスペリエンス
- マスクされたテキスト入力はエラーを引き起こしやすいため, 入力中にテキストを表示するオプションを提供すること. 入力文字をユーザーが視認するのに十分長い間表示した後は, 非表示にしてもよい. 従来のデスクトップコンピューターよりモバイルデバイス (e.g., タブレットやスマートフォン) のほうが Memorized Secret の入力に時間がかかるので, マスキング遅延時間を決定する際はデバイスを考慮すること. マスキング遅延時間がユーザーのニーズに合致していることを保証すること.
- テキスト入力に十分な時間が与えられている (i.e., 入力画面が途中でタイムアウトにならない) ことを保証すること. 許可されたテキスト入力時間がユーザーのニーズに合致していることを保証すること.
- ユーザーの混乱とフラストレーションを軽減するため, 入力エラーについての明確で意味のある対応可能なフィードバックを提供すること. ユーザーがテキスト誤入力に気づかないと, Usability に重大な影響を及ぼす.
- ユーザーに Authenticator Output を入力させるような Authenticator に関しては, 少なくとも10回の入力試行を許可すること. 入力テキストが長く複雑になればなるほど, ユーザーの入力エラー率も高くなる.
- 許可された残りの試行回数について, 明確で意味のあるフィードバックを提供すること. レート制限 (i.g., スロットリング) については, 混乱とフラストレーションを軽減するため, 次に試行までどれくらい待つ必要があるのかをユーザーに知らせること.

モバイルデバイスのタッチおよびディスプレイ領域の制限など, フォームファクターの制約による影響を最小化すること.
- 小さなデバイス上でのタイピングはフルサイズキーボードでのタイピングと比べてはるかにエラー率が高く時間もかかるため, より大きなタッチ領域はテキスト入力の Usability を向上させる. スクリーン上のキーボードが小さいほど, 入力メカニズム (e.g., 指) のサイズとスクリーン上の対象物のサイズとの兼ね合いで, より入力が困難になる.
- 小さなディスプレイ向けの優れたユーザーインタフェースおよび情報デザインに従うこと.

断続的イベント (Intermittent Events) には, Reauthentication, Subscriber Account のロックアウト, 期限切れ, 失効, 損傷, 紛失, 盗難, 機能しないソフトウェアといったイベントが含まれる.

すべての Authenticator Type における断続的イベントに関する Usability 上の考慮事項には以下のようなものが挙げられる.

ユーザーが非アクティブであることが原因でユーザーが Reauthentication する必要がないように, 非アクティブタイムアウトが発生する直前 (e.g., 2分前) にアクティビティをトリガーするようユーザーに促すこと.

ユーザーのアクティビティに関係なく固定の定期的な Reauthentication イベントが必要な場合, その前に十分な時間 (e.g., 1時間) を設けてユーザーに作業を保存するよう促すこと.

技術支援を受ける方法と場所を明確に伝えること. 例えば, オンラインのセルフサービス機能へのリンク, チャット Session, ヘルプデスクサポート用の電話番号などの情報をユーザーに提供すること. 理想的には, ユーザーが外部の介入なしに自身で断続的イベントからリカバリーできるよう十分な情報を提供されることが望ましい.

Usability Considerations by Authenticator Type

前述の大抵の Authenticator に適用可能な一般的な Usability 上の考慮事項 ((Sec. 10.1)) に加え, 以下のセクションでは特定の Authenticator Type 固有の Usability 上の考慮事項について述べる.

Memorized Secrets

Typical Usage (通常利用)

ユーザーは手動で Memorized Secret (一般的には Password や PIN と呼ばれる) を入力する.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

Memorized Secret の記憶可能性
- ユーザーが覚える項目が多いほど, 思い出せずに失敗する可能性が高くなる. Memorized Secret が少なければ少ないほど, ユーザーは特定の RP のために必要な特定の Memorized Secret をより簡単に思い出すことができる.

Memorized Secret 入力中のユーザーエクスペリエンス
- Passphrase を含む Memorized Secret 入力フィールドにおいてコピーアンドペースト機能をサポートすること.

Intermittent Events (断続的イベント)

断続的イベントにおける Usability 上の考慮事項としては以下のようなものが挙げられる.

ユーザーが Memorized Secret を生成・変更する際
- Memorized Secret の生成・変更方法に関する情報を明確に伝えること.
- Memorized Secret の要件 (Sec. 5.1.1 参照) を明確に伝えること.
- Passphrase には最低でも64文字を許容すること. 記憶しやすいようユーザーが選好する文字 (スペースを含む) を使用して, 好きなだけ長い Memorized Secret を作成することを推奨すること.
- Memorized Secret に他の構成ルール (e.g., 異なる文字種の混合) を課さないこと.
- ユーザーの要求や Authenticator 侵害の証拠がない限り, Memorized Secret の変更を恣意的 (e.g., 定期的) に要求しないこと. (追加情報に関しては Sec. 5.1.1 参照)

選択した Password を拒否する場合 (e.g., 受け入れられない Password の “Blocklist” に含まれる場合や, 以前に使用されているものと同じである場合) は, 明確で意味のある対応可能なフィードバックを提供すること.

Look-Up Secrets

Typical Usage (通常利用)

ユーザーは - 印刷物または電子的な - Authenticator を使用して, Verifier のプロンプトに応答するために必要とされる適切なシークレットを見つけ出す. 例えば, ユーザーはカードに表形式で印刷された数値または文字列の特定のサブセットを提供するよう求められる場合がある.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

Look-up Secret 入力中のユーザーエクスペリエンス
- プロンプトの複雑さとサイズを考慮すること. ユーザーが検索するよう求められるシークレットのサブセットが大きいほど, Usability への影響も大きくなる. Authentication のための Look-up Secret の量と複雑さを決定する際には, 認知作業負荷と入力の物理的な困難さの両方を考慮するべきである.

Out-of-Band

Typical Usage (通常利用)

Out-of-band Authentication では, ユーザーはプライマリおよびセカンダリなコミュニケーションチャネルへの Access を必要とする.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

ロックされているデバイスにシークレットを送信したことをユーザーに伝えること. ただし, Out-of-band Device がロックされている場合, シークレットに Access するためにデバイスへの Authenttication が要求されるべきである.

実装によっては, ユーザーがモバイルデバイス上でテキスト入力を行う必要がある場合に特に問題となるため, フォームファクターの制約を考慮すること. より大きなタッチ領域を提供することで, モバイルデバイス上でのシークレット入力の Usability を向上することができる.

さらに良い Usability のオプションは, モバイルデバイス上でテキスト入力を必要としない機能 (e.g., スクリーンを一回タップするだけだったり, Out-of-band シークレットをコピーアンドペーストできるようにコピー可能にするなど) を提供することである. このような機能を提供すると, プライマリチャネルとセカンダリチャネルが同一デバイス上にある場合, 特に役に立つ. 例えば, スマートフォン上で - 場合によっては複数回 - Out-of-band アプリケーションとプライマリチャネルの間を行ったり来たりして Authentication Secret を移動させるのは困難である.

Single-Factor OTP Device

Typical Usage (通常利用)

ユーザーは Single-factor OTP Device で生成された OTP に Access する. Authenticator Output は通常デバイス上に表示され, ユーザーがそれを Verifier に入力する.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

Authenticator Output は切り替わるまでに少なくとも1分間の猶予があるが, 理想的には Sec. 5.1.4.1 にあるようにユーザーにフルで2分間の猶予を与えることが望ましい. ユーザーは Authenticator Output の入力 (Single-factor OTP Device と入力画面の間の行き来を含む) に十分な時間を必要とする.

実装によっては, 実装者向けの以下のような追加の Usability 上の考慮事項が挙げられる.
- Single-factor OTP Device が電子的インタフェース (e.g., USB) を介して出力を提供できると, ユーザーは Authenticator Output を手動で入力する必要がないため, そのような実装が望ましい. しかしながら, 操作に物理的な入力 (e.g., ボタンを押す) が必要な場合, USB ポートの位置によっては Usability 上の問題をひきおこす可能性がある. 例えば, 一部のコンピューターの USB ポートはコンピューターの背面にあり, ユーザーがアクセスしにくい場合がある.
- USB ポートなどの直接的コンピューターインタフェースの Availability (可用性) に関する制約が Usability 上の問題を引き起こす可能性もある. 例えば, ラップトップコンピューターの USB ポート数はしばしば非常に限られている. これによりユーザーは Single-factor OTP Device を使用するために他の USB 周辺機器を取り外す必要があるかもしれない.

Multi-Factor OTP Device

Typical Usage (通常利用)

ユーザーは Multi-factor OTP Device で生成された OTP に Access する. OTP は通常デバイス上に表示され, ユーザーがそれを Verifier に入力する. 2nd Authentication Factor は, Memorized Secret を入力するためのある種の一体型入力パッド, 一体型 Biometric (e.g., 指紋) リーダー, または直接的なコンピューターインタフェース (e.g., USB ポート) を介してもたらされる可能性がある. ここでは追加の Authentication Factor に対する Usability 上の考慮事項も適用される - Multi-factor Authenticator 内で用いられる Memorized Secret に対しては Sec. 10.2.1, Biometrics に対しては Sec. 10.4 を参照.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

Authenticator Output の手入力中のユーザーエクスペリエンス
- Time-based OTP の場合, OTP が表示されている時間にプラスして猶予時間を設けること. Multi-factor OTP Device と入力画面の間を行き来することを含め, ユーザーは Authenticator Output の入力に十分な時間を要する.
- ユーザーが, 一体型入力パッドを介して Multi-factor OTP Device のロックを解除したり, Authenticator Output をモバイルデバイスに入力する必要がある場合, フォームファクターの制約を考慮すること. 小型デバイスでの入力は, 従来のキーボードでの入力よりも大幅にエラーが発生しやすく, 時間がかかるものである. 一体型入力パッドとオンスクリーンキーボードが小さければ小さいほど入力は難しくなる. より大きなタッチ領域を提供することで, Multi-factor OTP Device のロックを解除したり, モバイルデバイスに Authenticator Output を入力する際の Usability が向上する.
- USB ポートなどの直接的コンピューターインタフェースの Availability (可用性) に関する制約が Usability 上の問題を引き起こす可能性もある. 例えば, ラップトップコンピューターの USB ポート数はしばしば非常に限られている. これによりユーザーは Multi-factor OTP Device を使用するために他の USB 周辺機器を取り外す必要があるかもしれない.

Single-Factor Cryptographic Software

Typical Usage (通常利用)

ユーザーは Cryptographic Software Key を保持および管理していることを証明することにより Authenticate を行う.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

ユーザーはどの Authentication タスクにどの Cryptographic Key を使用するかを認識し思い出す必要があるため, Cryptographic Key には適切でわかりやすい名前をつけること. これによりユーザーは似たような曖昧な名前の複数の Cryptographic Key を扱う必要がなくなる. 小型のモバイルデバイスで複数の Cryptographic Key から選択する場合, 画面サイズが小さくなったために Cryptographic Key の名前が短縮されていると, 特に問題になる可能性がある.

Single-Factor Cryptographic Device

Typical Usage (通常利用)

ユーザーは Single-Factor Cryptographic Device を保持していることを証明することにより Authenticate を行う.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

Single-Factor Cryptographic Device を操作するために物理的な入力 (e.g., ボタンを押す) を必要とすると, Usability 上の問題を引き起こす可能性がある. 例えば, 一部の USB ポートはコンピューターの背面に配置されているため, ユーザーの手に届きにくい場所にある.

USB ポートなどの直接的コンピューターインタフェースの Availability (可用性) に関する制約が Usability 上の問題を引き起こす可能性もある. 例えば, ラップトップコンピューターの USB ポート数はしばしば非常に限られている. これによりユーザーは Single-Factor Cryptographic Device を使用するために他の USB 周辺機器を取り外す必要があるかもしれない.

Multi-Factor Cryptographic Software

Typical Usage (通常利用)

Authenticate するため, ユーザーは Activation が必要なディスクまたはその他の “ソフト” メディアに保存されている Cryptographic Key の保持および管理を証明する. Activation は 2nd Authenticator Factor, Memorized Secret または Biometrics の特徴のいずれか, の入力により行われる. ここでは追加の Authentication Factor に対する Usability 上の考慮事項も適用される - Multi-factor Authenticator 内で用いられる Memorized Secret に対しては Sec. 10.2.1, Biometrics に対しては Sec. 10.4 を参照.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

ユーザーはどの Authentication タスクにどの Cryptographic Key を使用するかを認識し思い出す必要があるため, Cryptographic Key には適切でわかりやすい名前をつけること. これによりユーザーは似たような曖昧な名前の複数の Cryptographic Key を扱う必要がなくなる. 小型のモバイルデバイスで複数の Cryptographic Key から選択する場合, 画面サイズが小さくなったために Cryptographic Key の名前が短縮されていると, 特に問題になる可能性がある.

Multi-Factor Cryptographic Device

Typical Usage (通常利用)

ユーザーは Multi-Factor Cryptographic Device を保持していること, および保護されている Cryptographic Key を管理していることを証明することにより Authenticate を行う. Activation は 2nd Authenticator Factor, Memorized Secret または Biometrics の特徴のいずれか, の入力により行われる. ここでは追加の Authentication Factor に対する Usability 上の考慮事項も適用される - Multi-factor Authenticator 内で用いられる Memorized Secret に対しては Sec. 10.2.1, Biometrics に対しては Sec. 10.4 を参照.

通常利用における Usability 上の考慮事項としては以下のようなものが挙げられる.

Authentication 後に Multi-factor Cryptographic Key を接続したままにしておくことを要求しないこと. ユーザーは Multi-factor Cryptographic Key を使い終わった後も取り外すのを忘れる (e.g., スマートカードリーダーにスマートカードを入れ忘れたままコンピューターから離れてしまう) 可能性がある.
- 接続を維持するために Multi-factor Cryptographic Device が必要かどうか, ユーザーに通知する必要がある.

ユーザーはどの Authentication タスクにどの Cryptographic Key を使用するかを認識し思い出す必要があるため, Cryptographic Key には適切でわかりやすい名前をつけること. これによりユーザーは似たような曖昧な名前の複数の Cryptographic Key を扱う必要がなくなる. 小型のモバイルデバイス (スマートフォンなど) で複数の Cryptographic Key から選択する場合, 画面サイズが小さくなったために Cryptographic Key の名前が短縮されていると, 特に問題になる可能性がある.

USB ポートなどの直接的コンピューターインタフェースの Availability (可用性) に関する制約が Usability 上の問題を引き起こす可能性もある. 例えば, ラップトップコンピューターの USB ポート数はしばしば非常に限られている. これによりユーザーは Multi-Factor Cryptographic Device を使用するために他の USB 周辺機器を取り外す必要があるかもしれない.

Summary of Usability Considerations

Figure 3 は各 Authenticator Type 毎に通常利用 (Typical Usage) および断続的イベント (Intermittent Events) における Usability 上の考慮事項をまとめたものである. 表を見ても分かる通り, 通常利用における Usability 上の考慮事項の多くが, ほとんどの Authenticator Type に当てはまる. この表は Authenticator Type 全体にわたって共通するさまざまな Usability の特徴を示している. 各カラムにより, 読者は各 Authenticator に対応するための Usability Attribute を簡単に識別することができる. ユーザーの目標と利用コンテキストに応じて, 特定の Attribute が他の Attribute より高く評価される場合もある. 可能な限り代替の Authenticator Type を提供し, ユーザーがそれらの中から選択できるようにすることが望ましい.

Multi-factor Authenticator (e.g., Multi-factor OTP Device, Multi-factor Cryptographic Software, Multi-factor Cryptographic Device) は, さらにセカンダリーファクターに関する Usability 上の考慮事項も受け継いでいる. Biometrics は Multi-factor Authentication ソリューションの Activation Factor としてのみ許容されているため, Biometirics に関する Usability 上の考慮事項は Figure 3 には含まれず, Sec. 10.4 で述べられている.

Figure 3 Usability Considerations Summary by Authenticator Type

Table showing which usability considerations apply to each authenticator type

\clearpage

Biometrics Usability Considerations

本セクションでは, Biometrics の一般的な Usability 上の考慮点について概説する. Biometrics の Usability に関するより詳細な議論は Usability & Biometrics, Ensuring Successful Biometric Systems [UsabilityBiometrics] を参照のこと.

Biometrics の様式は多様であるが, 以下で述べる3つの Biometrics 様式, 指紋, 顔, 虹彩は, その中でもより一般的に Authentication に用いられる.

Typical Usage (通常利用)

全ての様式について, ユーザーがデバイスに慣れて実践することで, そのパフォーマンスは向上する.

デバイスのアフォーダンス (i.e., ユーザーがアクションを実行できるようにするデバイスのプロパティ), フィードバックおよび明確な手順書は, ユーザーが Biometrics デバイスを使用して成功体験を得るのに不可欠である. 例えば, Liveness Detection に必要なアクションに関する明確な手順書を提供すること.

理想的には, ユーザーが 2nd Authentication Factor として最も使いやすい様式を選択できることが望ましい. ユーザー母集団はある Biometrics 様式に他より慣れ親しんで - かつ受け入れて - いる可能性がある.

Activation Factor としての Biometrics のユーザーエクスペリエンス
- 許可された残りの試行回数について, 明確で意味のあるフィードバックを提供すること. レート制限 (i.g., スロットリング) については, 混乱とフラストレーションを軽減するため, 次に試行までどれくらい待つ必要があるのかをユーザーに知らせること.

指紋認証に関する Usability 上の考慮事項
- ユーザーは Enrollment 時にどの指を登録したか覚えておく必要がある.
- 指の湿気がセンサーの読取精度に影響する.
- 指紋読取精度に影響を与えるその他の要因として, 年齢, 性別, 職業 (e.g., 化学薬品を扱ったり手を酷使する仕事についているユーザーは, 指紋が劣化している可能性がある) などが挙げられる.

顔認証に関する Usability 上の考慮事項
- 顔認識精度に影響するため, ユーザーは Enrollment 時に人工物 (e.g., メガネ) を着用していたかどうか覚えておく必要がある.
- 環境光条件の違いが顔認識精度に影響を及ぼす可能性がある.
- 表情 (e.g., 笑顔と無表情) は顔認識精度に影響を与える.
- 顔のポーズ (e.g., 下を向いている, カメラから離れている) は顔認識精度に影響を与える.

虹彩認証に関する Usability 上の考慮事項
- カラーコンタクトを着用すると, 虹彩認識精度に影響を与える可能性がある.
- 目の手術を受けたユーザーは, 手術後に再度 Enrollment を行う必要があるかもしれない.
- 環境光条件の違いが, 特に特定の虹彩の色について, 虹彩認識精度に影響を与える可能性がある.

Intermittent Events (断続的イベント)

Biometrics は Multi-factor Authentication における 2nd ファクターとしてのみ許容されている一方, 1つめの Authentication Factor における断続的イベントに関する Usability 上の考慮事項も適用される. Biometrics の利用に関する断続的イベントとしては, 認識精度に影響を与える以下のようなものが挙げられる. ここに挙げるものは例であり全てとは限らない.

ユーザーが登録した指を傷つけた場合, 指紋認識が不能になる可能性がある. 指紋認証 (Fingerprint Authentication) は指紋を損傷したユーザーにとっては困難であろう.
ユーザーの顔は時間の経過とともに自然に変化するため, 最初の Enrollment 時点から Authentication のための顔認識時点までに時間が経過していると, 認識精度に影響を与える可能性がある. ユーザーの体重変化もその要因となり得る.
目の手術を受けたユーザーは, 手術後に再度 Enrollment を行うまで虹彩認識が不能になるかもしれない.

全ての Biometrics 様式において, 断続的イベントにおける Usability 上の考慮事項として以下が挙げられる.

代替の Authentication 手段が利用可能かつ機能している必要がある. Biometrics が機能しない場合, ユーザーが Memorized Secret を代替の 2nd ファクターとして利用できるようにすること.
技術支援を提供すること.
- 技術支援を受ける方法と場所を明確に伝えること. 例えば, オンラインのセルフサービス機能へのリンク, ヘルプデスクサポート用の電話番号などの情報をユーザーに提供すること. 理想的には, ユーザーが外部の介入なしに自身で断続的イベントからリカバリーできるよう十分な情報を提供されることが望ましい.
- Biometric センサーの感度に影響を与える可能性のある要因 (e.g., センサーの清潔さ) をユーザーに知らせること.

Equity Considerations

This section is informative.

正確で公平な Authentication Service は, Digital Identity System の不可欠な要素である. Authentication の正確さの aspect は, 大部分がこのドキュメント以外の場所で見つかるセキュリティ要件の対象だが, Executive Order 13985, “Advancing Racial Equity and Support for Underserved Communities Through the Federal Government” [EO13985] で指定されているように, 政府サービスへの公平なアクセスを提供するために, すべての Subscriber を確実に Authenticate できることが必要である. 連邦政府を通じて十分なサービスを受けていないコミュニティのために」[EO13985]. 公平性リスクを評価するにあたり, CSP はその Authentication Service によって取り扱われる全体的なユーザーの Population を考慮する必要がある. 加えて, CSP はその Service を使用する際に, 共通する特性によって不公平なアクセス, 扱い, または結果にさらされる可能性がある Population 内のユーザーのグループをさらに識別する. Sec. 10 で提供される使いさすさの考慮事項もまた Authentication Service を使用するすべての人のための全体的な使いやすさと公平性の確保のために考慮される必要がある.

Equity の主要な aspect は, CSP がその Subscriber Population のニーズの予測と, その Population に適した Authenticator の選択肢の提供を必要とすることである. Authenticator の適合性の問題の例を以下に示す:

SMS-based Out-of-band Authentication は, 携帯電話のサービスが利用できない地域では使いづらい可能性がある.
OTP デバイスは, 視覚に難しさがある Subscriber にとって読みにくい場合がある.
音声電話で送信される Out-of-band Authentication Secret は, 聞き取りに難しさがある Subscriber にとってはわかりにくい場合がある.
Facial matching algorithm は, 一部の ethnicity の Subscriber の顔の特徴と効果的に一致しない場合がある.
ハードウェアベースの Authenticator のコストは, 一部の Subscriber にとっては自身の許容範囲を超えている場合がある.
Memorized Secret を正確に手動で入力することは, 動作や器用さに disabilitiy がある Subscriber にとっては難しい場合がある.
特定の Authenticator Type の使用は, 知能, 発達, 学習, 神経認知などに disabilitiy がある Subscriber にとっては難しい場合がある.

この分野の最も一般的な問題を軽減するために, CSP に要求する Normative Requirement が確立されている. しかし, すべての潜在的な公平性の問題を予測することは実現不可能である. 潜在的な公平性の問題はまたアプリケーションによって異なる. したがって, CSP は, Subscriber が不公平な Authentication Requirement を報告し, 代替となりえる Authentication 方法について助言するためのメカニズムを提供する必要がある.

このガイドラインでは, アカウント回復の必要性を最小限に抑えるために, 追加の Authenticator を Bind することを推奨している(Sec. 6.1.2.3 を参照). しかし, Subscriber は2つ目のハードウェアベースの Authenticator をバックアップとして購入することが難しい場合がある. この不公平性には, Look-up secret (Sec. 5.1.2 を参照) などの安価な Authenticator を, Primary Authenticator の障害や紛失の場合に使用できるようにすることで取り組める.

CSP は, 現在サポートしている Authenticator を使用して解決できない Authentication の課題に遭遇した Subscriber に対応する必要がある. これには, 新しい Authenticator Type のサポートや, Subscriber のニーズを満たす信頼できるサービスを介した Federated Authentication の許可が含まれる場合がある.

References

This section is informative.

General References

[Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, “Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications“, RFC 9106, DOI 10.17487/RFC9106, September 2021, https://www.rfc-editor.org/info/rfc9106.

[Blocklists] Habib, Hana, Jessica Colnago, William Melicher, Blase Ur, Sean Segreti, Lujo Bauer, Nicolas Christin, and Lorrie Cranor. “Password Creation in the Presence of Blacklists,” 2017. Available at: https://www.ndss-symposium.org/wp-content/uploads/2017/09/usec2017_01_3_Habib_paper.pdf

[Composition] Komanduri, Saranga, Richard Shay, Patrick Gage Kelley, Michelle L Mazurek, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor, and Serge Egelman. “Of Passwords and People: Measuring the Effect of Password-Composition Policies.” In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 2595–2604. ACM, 2011. Available at: https://www.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwords.pdf.

[E-Gov] E-Government Act (includes FISMA) (P.L. 107-347), December 2002, available at: https://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf.

[EO13681] Executive Order 13681, Improving the Security of Consumer Financial Transactions, October 17, 2014, available at: https://www.federalregister.gov/d/2014-25439.

[EO13985] Executive Order 13985, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government, January 25, 2021, available at: https://www.federalregister.gov/d/2021-01753.

[FEDRAMP] General Services Administration, Federal Risk and Authorization Management Program, available at: https://www.fedramp.gov/.

[M-22-09] OMB Memorandum M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022, available at: https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf.

[NISTIR8062] NIST Internal Report 8062, An Introduction to Privacy Engineering and Risk Management in Federal Systems, January 2017, available at: https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf.

[UsabilityBiometrics] National Institute and Standards and Technology, Usability & Biometrics, Ensuring Successful Biometric Systems, June 11, 2008, available at: https://www.nist.gov/customcf/get_pdf.cfm?pub_id=152184.

[OWASP-session] Open Web Application Security Project, Session Management Cheat Sheet, available at: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet.

[OWASP-XSS-prevention] Open Web Application Security Project, XSS (Cross Site Scripting) Prevention Cheat Sheet, available at: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet.

[Persistence] herley, cormac, and Paul van Oorschot. “A Research Agenda Acknowledging the Persistence of Passwords,” IEEE Security&Privacy Magazine, 2012. Available at: https://research.microsoft.com/apps/pubs/default.aspx?id=154077.

[Policies] Weir, Matt, Sudhir Aggarwal, Michael Collins, and Henry Stern. “Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords.” In Proceedings of the 17th ACM Conference on Computer and Communications Security, 162–175. CCS ‘10. New York, NY, USA: ACM, 2010. doi:10.1145/1866307.1866327.

[PrivacyAct] Privacy Act of 1974 (P.L. 93-579), December 1974, available at: https://www.justice.gov/opcl/privacy-act-1974.

[PSL] Public Suffix List https://publicsuffix.org/list/

[Scrypt] Percival, C. and S. Josefsson, The scrypt Password-Based Key Derivation Function, RFC 7914, DOI 10.17487/RFC7914, August 2016, https://www.rfc-editor.org/info/rfc7914.

[Section508] Section 508 Law and Related Laws and Policies (January 30, 2017), available at: https://www.section508.gov/manage/laws-and-policies/.

[Shannon] Shannon, Claude E. “A Mathematical Theory of Communication,” Bell System Technical Journal, v. 27, pp. 379-423, 623-656, July, October, 1948.

[Strength] Kelley, Patrick Gage, Saranga Komanduri, Michelle L Mazurek, Richard Shay, Timothy Vidas, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor, and Julio Lopez. “Guess Again (and Again and Again): Measuring Password Strength by Simulating Password-Cracking Algorithms.” In Security and Privacy (SP), 2012 IEEE Symposium On, 523–537. IEEE, 2012. Available at: https://ieeexplore.ieee.org/iel5/6233637/6234400/06234434.pdf.

[TOTP] M’Raihi, D., Machani, S., Pei, M., and J. Rydell, TOTP: Time-Based One-Time Password Algorithm, RFC 6238, DOI 10.17487/RFC6238, May 2011, https://www.rfc-editor.org/info/rfc6238.

Standards

[ISO/IEC9241-11] International Standards Organization, ISO/IEC 9241-11 Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11: Guidance on usability, March 1998, available at: https://www.iso.org/standard/16883.html.

[ISO/IEC2382-37] International Standards Organization, Information technology — Vocabulary — Part 37: Biometrics, 2017, available at: https://standards.iso.org/ittf/PubliclyAvailableStandards/c066693_ISO_IEC_2382-37_2017.zip.

[ISO/IEC10646] International Standards Organization, Information technology — Universal coded character set (UCS), 2020, available at: https://www.iso.org/standard/76835.html.

[ISO/IEC24745] International Standards Organization, Information technology — Security techniques — Biometric information protection, 2011, available at: https://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52946.

[ISO/IEC30107-1] International Standards Organization, Information technology — Biometric presentation attack detection — Part 1: Framework, 2016, available at: https://standards.iso.org/ittf/PubliclyAvailableStandards/c053227_ISO_IEC_30107-1_2016.zip.

[ISO/IEC30107-3] International Standards Organization, Information technology — Biometric presentation attack detection — Part 3: Testing and reporting, 2017.

[RFC20] Cerf, V., “ASCII format for network interchange“, STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, https://www.rfc-editor.org/info/rfc20.

[UAX15] Unicode Consortium, Unicode Normalization Forms, Unicode Standard Annex 15, Version 9.0.0, February 2016, available at: https://www.unicode.org/reports/tr15/.

NIST Special Publications

NIST 800 Series Special Publications are available at https://csrc.nist.gov/publications/sp800. The following publications may be of particular interest to those implementing systems of applications requiring digital authentication.

[SP800-38B] NIST Special Publication 800-38B, Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication, October, 2016, https://dx.doi.org/10.6028/NIST.SP.800-38B.

[SP800-53] NIST Special Publication 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations, September 2020 (updated December 10, 2020), https://dx.doi.org/10.6028/NIST.SP.800-53r5.

[SP800-63] NIST Special Publication 800-63-4, Digital Identity Guidelines, December 2022, https://doi.org/10.6028/NIST.SP.800-63-4.ipd.

[SP800-63A] NIST Special Publication 800-63B-4, Digital Identity Guidelines: Enrollment and Identity Proofing, December 2022, https://doi.org/10.6028/NIST.SP.800-63a-4.ipd.

[SP800-63C] NIST Special Publication 800-63C-4, Digital Identity Guidelines: Assertions and Federation, December 2022, https://doi.org/10.6028/NIST.SP.800-63c-4.ipd.

[SP800-73] NIST Special Publication 800-73-4, Interfaces for Personal Identity Verification, February 2016, https://doi.org/10.6028/NIST.SP.800-73-4.

[SP800-90A] NIST Special Publication 800-90A Revision 1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, June 2015, https://dx.doi.org/10.6028/NIST.SP.800-90Ar1.

[SP800-107] NIST Special Publication 800-107 Revision 1, Recommendation for Applications Using Approved Hash Algorithms, August 2012, https://dx.doi.org/10.6028/NIST.SP.800-107r1.

[SP800-131A] NIST Special Publication 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths, March 2019, https://dx.doi.org/10.6028/NIST.SP.800-131Ar2

[SP800-132] NIST Special Publication 800-132, Recommendation for Password-Based Key Derivation, December 2010, https://dx.doi.org/10.6028/NIST.SP.800-132.

[SP800-185] NIST Special Publication 800-185, SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash, December 2016, https://doi.org/10.6028/NIST.SP.800-185.

Federal Information Processing Standards

[FIPS140] Federal Information Processing Standard Publication 140-3, Security Requirements for Cryptographic Modules, March 22, 2019, https://doi.org/10.6028/NIST.FIPS.140-3.

[FIPS198] Federal Information Processing Standard Publication 198-1, The Keyed-Hash Message Authentication Code (HMAC), July 2008, https://doi.org/10.6028/NIST.FIPS.198-1.

[FIPS201] Federal Information Processing Standard Publication 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, https://dx.doi.org/10.6028/NIST.FIPS.201-3.

[FIPS202] Federal Information Processing Standard Publication 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, August 2015, https://dx.doi.org/10.6028/NIST.FIPS.202.

Strength of Memorized Secrets

This appendix is informative.

本 Appendix を通じて, 議論を容易にするため “Password” という用語を用いる. 本用語が用いられる箇所では, Password に加え Passphrase や PIN も含むと解釈すべきである.

Introduction

Usability とセキュリティ双方の観点で Password の使用に関するフラストレーションが広がっているが, Password は依然として広く Authentication に使われている方式である [Persistence]. しかしながら, 人間は複雑で勝手に決められたシークレットを記憶する能力が限られており, しばしば簡単に推測可能な Password を選択することになる. この結果生じるセキュリティ上の懸念に対応するため, オンラインサービスは Memorized Secret の複雑度を上げるようなルールを導入してきた. 最も顕著なルール形式はその構成ルールであり, 1つ以上の数字, 大文字および記号など, 複数の文字種を用いることをユーザーに要求するようなものである. しかしながら, 侵害された Password データベースの分析からは, そのようなルールがもたらす Usability への影響や記憶しづらさのわりに, それによる恩恵は当初考えられていたほど大したものではないことが明らかになっている [Policies].

ユーザー選択により生成された Password の複雑度は, しばしば Entropy という情報理論のコンセプトを使って特徴づけられることがある [Shannon]. 決定論的分布関数を持つデータの Entropy は容易に計算可能だが, ユーザー選択の Password の Entropy を推定するのは困難であり, そのための過去の努力はあまり正確ではなかった. そのため, それとは異なりよりシンプルなアプローチとして, 主に Password の長さに基づくものをここに示す.

Password の使用に関連する Attack の多くは, Password の複雑性と長さには影響されない. キーストロークロギング, Phishing および Social Engineering Attack は, シンプルな Password に対して有効であるのと同様に, 長く複雑な Password に対しても有効である. こういった Attack は本 Appendix のスコープ外とする.

Length

Password の長さは Password 強度を特徴づける第一のファクターであることがわかっている [Strength] [Composition]. 短すぎる Password は, 単語や一般的に使用される Password を用いた辞書攻撃や Brute Force Attack の対象となる.

最低限必要な Password の長さは, 対応する脅威モデルに大きく依存する. Attacker が Password を推測してログインを試みる Online Attack は, 許容するログイン試行回数を制限することで軽減可能である. Attacker (またはタイピングスキルの低い執拗な Claimant) が大量の誤推測により Subscriber に対して Denial-of-Service Attack を引き起こすのを防ぐため, Password は十分複雑で, 適度な入力回数ではレートリミットに到達しないが, 推測が成功する可能性がかなり高くなる前にはレートリミットに到達するようなものとする必要がある.

Attacker がデータベース侵害を通じて1つ以上のハッシュ化された Password を取得すると, Offline Attack が可能になることもある. Attacker が1人以上のユーザーの Password を特定できるかは, Password の保存方法に依存する. 通常 Password は乱数値の Salt を用いてハッシュ化されており, さらに計算コストの高いアルゴリズムが使用されていればなお良い. そのような対策を講じても, 現在の Attacker はレートリミットなしで毎秒数十億のハッシュ計算が可能であり, そのような攻撃に対抗できる Password は Online Attack に抵抗できると予想される Password より桁違いに複雑でなければならない.

ユーザーには, 合理的な範囲内で Password を好きなだけ長くすることを推奨するべきである. ハッシュ化された Password のサイズは元の Password の長さとは無関係であるため, ユーザーが希望しているのに長い Password (ないし Passphrase) の利用を許可しない理由はない. 非常に長いパスワード (おそらくメガバイト級) はハッシュ化に過度の処理時間を要する可能性があるため, そういった制限を設けるのは合理的である.

Complexity

上述のように, 構成ルールは, ユーザー選択による Password の推測を困難にするために一般的に利用されている. しかし, 調査によると, ユーザーは構成ルールで課される要件に対して非常に推測容易な方法で応答することが示されている [Policies]. 例えば, Password として “password” を選択しようとするユーザーは, 大文字と数字を含める必要がある場合には “Password1” を, 記号も必要な場合は “Password1!” を選択する可能性が比較的高い.

また, 複雑な Password を生成しようとしてオンラインサービスに拒否されると, ユーザーはフラストレーションを感じる. 多くのサービスは, スペースやさまざまな特殊文字を含む Password を拒否する. 場合によっては, 受け入れられない特殊文字は, そういった文字に依存する SQL インジェクションなどの Attack を回避するためな可能性もある. しかしながら, 適切にハッシュ化された Password はどのような場合でもデータベースにそのまま送られるわけではないため, そのような予防策は不要である. さらに, ユーザーがフレーズを使用できるよう, スペースを含められるようにもすべきである. ただし, スペース自体は Password の複雑さをほとんど増やすこともなく, Usability の問題 (e.g., 気づかずに1つではなく2つのスペースを入力してしまう) を引き起こす可能性もあるため, 入力 Passsword 中の連続するスペースを Verification 前に取り除くことが有益な場合もある.

ユーザーの Password 選択は非常に予測しやすいため, Attacker は過去に利用に成功したものをもとに Password を推測する可能性がある. これには, 上記例の “Password1!” のような, 過去に侵害された辞書単語や Password を含む. そのため, ユーザー選択の Password を受け入れ不可な Password の Blocklist と比較することを推奨する. このリストには, 過去に侵害された事例で用いられた Password, 辞書単語やユーザーが選択しがちな特定単語 (サービス自体の名前など) から生成された Password を含めるべきである. ユーザー選択の Password も最小長要件に従うため, この辞書にはそのような要件にあったエントリーのみを含める必要がある. Sec. 5.1.1.2 で述べたように, Blocklist があまりに大きく包括的であることは有益ではない. Blocklist の主な目的は, Online Attack で Throttling 制限に到達するまでに推測されてしまう可能性のある非常に一般的な Password の利用を防ぐことである. Blocklist が大きすぎると, 覚えやすい Password を選択しようとするユーザーにフラストレーションを与えかねない.

非常に複雑な Memorized Secret は新たな潜在的脆弱性をもたらす. そういった Memorized Secret は記憶に残る可能性が低く, 安全でない方法で書き留められたり電子的に保存される可能性が高い. そういった慣行が必ずしも脆弱であるわけではないが, 統計的にはそういったシークレットの記録方法はのいくらかは脆弱になりがちである. これは過度に長く複雑な Memorized Secret を要求しないという追加のモチベーションとなる.

Central vs. Local Verification

単体の Authentication Factor として利用される Password は, 通常 CSP の Verifier によって中央で一元的に検証されるが, Multi-factor Authenticator の Activation Factor として利用される Password は, ローカルで検証されたり Authenticator Output の導出 (Activation Factor が正しくなければ Authenticator Output も正しくならない) のために用いられる. こういったシチュエーションは “Local Verification” と呼ばれる.

Central Verification と Local Verification の Attack 対象領域と脆弱性は互いに大きく異なる. したがって, 中央で検証される Memorized Secret に対する要件とローカルで検証されるそれは異なる. 中央で検証されるシークレットには, オンラインリソースである Verifier が, 全ての Subscriber の Password に対して Salt 付きで繰り返しハッシュ化した Verification シークレットを保存する必要がある. Salt およびハッシュ化プロセスはハッシュ値から Password を特定するための計算量を増大させるが, Verifier は Attacker にとっての格好の標的となる. 特定の Subscriber ではなく任意の Subscriber を侵害することに関心を持つ Attacker であればなおさらである.

ローカルの Verifier には, 中央のオンラインな Verifier に対する大規模攻撃のような心配はないが, Authenticator の物理セキュリティと関連するエンドポイントの Integrity (完全性) により大きく依存する. Authenticator が Activation Factor を保存する範囲で, その Activation Factor は物理攻撃および Side-Channel Attack (e.g., 電力およびタイミング解析) から保護しなければならない. 関連するエンドポイントから Activation Factor が入力される際は, そのエンドポイントがマルウェアに感染していてはならない. 例えば Password を保護する場合は, キーロガーソフトウェアなどが防ぐべきマルウェアになる. これらの脅威は Password の長さと複雑さにあまり依存しないため, こういった要件は Local Verification では緩和される.

Online Password-guessing Attack は, 中央およびローカルで検証される Password ともに共通した脅威である. Online Attack に対する主要な防御策である Throttling は, ローカルの Verifier にとっては特に困難となる可能性がある. そういった Authenticator の中には, 失敗試行に関する情報をセキュアに保存する能力が限られているものもある. Throttling は, Authenticator 内に無効な試行の回数を保持するか, Throttling を行う CSP Verifier に拒否されるような Authenticator Output を生成することで実現できる. この場合, Authenticator Output が無効であることが Attacker に明らかにならないことが重要である. さもないと Attacker は有効に見える Authenticator Output が出力されるまでオフライン試行を繰り返すことができる.

Summary

ここで推奨されている以上の長さと複雑さの要件は, Memorized Secret の難易度を大幅に高め, ユーザーのフラストレーションを増加させる. その結果, ユーザーはしばしばそういった制約の回避策として逆効果な方法を選ぶこともある. さらに, Blocklist, セキュアでハッシュ化されたストレージ, レートリミットなどのその他の軽減策は, モダンな Brute-force Attack を防ぐのにより効果的である. したがって, 追加の複雑さの要件は課さない.

Change Log

This appendix is informative. It provides an overview of the changes to SP 800-63B since its initial release.

Section 5.2.3 — Updated biometric performance requirements and metrics and included discussion of equity impacts.
Section 5.2.5 — Added definition and updated requirements for phishing resistant authenticators.
Section 5.2.11 — Established separate requirements for locally verified memorized secrets known as activation secrets.
Section 5.2.12 — Added requirements for authenticators that are connected via wireless technologies such as NFC and Bluetooth.