NIST SP 800-63B-4

ABSTRACT

本ガイドラインは、ネットワーク経由で政府の情報システムとやり取りする主体（subject）の認証に焦点を当て、ある申告者（claimant）が、過去に認証済みの購読者（subscriber）であることを確立します。認証プロセスの結果は、認証を実行するシステム内でローカルに利用される場合もあれば、フェデレーションされたアイデンティティシステム内の別の場所で表明（assert）される場合もあります。本書は、3つの認証保証レベルそれぞれについて技術要件を定義します。これらのガイドラインは、この目的の範囲外で標準の開発や利用を制約する意図はありません。本書は NIST Special Publication (SP) 800-63B を置き換えるものです。

Keywords

認証；認証保証；credential service provider；デジタル認証；パスワード。

Table of Contents

• NIST SP 800-63B-4
  • ABSTRACT
  • Keywords
  • Table of Contents
  • Preface
  • 1. Introduction
    • 1.1. Notations
    • 1.2. Document Structure
  • 2. Authentication Assurance Levels
    • 2.1. Authentication Assurance Level 1
      • 2.1.1. Permitted Authenticator Types
      • 2.1.2. Authenticator and Verifier Requirements
      • 2.1.3. Reauthentication
    • 2.2. Authentication Assurance Level 2
      • 2.2.1. Permitted Authenticator Types
      • 2.2.2. Authenticator and Verifier Requirements
      • 2.2.3. Reauthentication
    • 2.3. Authentication Assurance Level 3
      • 2.3.1. Permitted Authenticator Types
      • 2.3.2. Authenticator and Verifier Requirements
      • 2.3.3. Reauthentication
    • 2.4. General Requirements
      • 2.4.1. Security Controls
      • 2.4.2. Records Retention Policy
      • 2.4.3. Privacy Requirements
      • 2.4.4. Redress Requirements
    • 2.5. Summary of Requirements
  • 3. Authenticator and Verifier Requirements
    • 3.1. Requirements by Authenticator Type
      • 3.1.1. Passwords
        • Password Authenticators
        • Password Verifiers
      • 3.1.2. Look-Up Secrets
        • Look-Up Secret Authenticators
        • Look-Up Secret Verifiers
      • 3.1.3. Out-of-Band Devices
        • Out-of-Band Authenticators
        • Out-of-Band Verifiers
        • Authentication Using the Public Switched Telephone Network
        • Multi-Factor Out-of-Band Authenticators
      • 3.1.4. Single-Factor OTP
        • Single-Factor OTP Authenticators
        • Single-Factor OTP Verifiers
  • 4. Session Management
    • 4.1. Session Bindings
      • 4.1.1. Browser Cookies
      • 4.1.2. Access Tokens
    • 4.2. Reauthentication
    • 4.3. Session Monitoring
  • 5. Threats and Security Considerations
    • 5.1. Authenticator Threats
    • 5.2. Threat Mitigation Strategies
    • 5.3. Authenticator Recovery
    • 5.4. Session Attacks
  • 6. Privacy Considerations
    • 6.1. Privacy Risk Assessment
    • 6.2. Privacy Controls
    • 6.3. Use Limitation
    • 6.4. Agency-Specific Privacy Compliance
  • 7. Customer Experience Considerations
    • 7.1. Usability
      • 7.1.1. Common Usability Considerations for Authenticators
      • 7.1.2. Usability Considerations by Authenticator Type
        • Passwords
        • Look-Up Secrets
        • Out-of-Band
        • Single-Factor OTP
        • Multi-Factor OTP
        • Single-Factor Cryptographic Authenticator
        • Multi-Factor Cryptographic Authenticator
      • 7.1.3. Summary of Usability Considerations
      • 7.1.4. Usability Considerations for Biometrics
    • 7.2. Customer Success Considerations
  • References
  • Strength of Passwords
    • Introduction
    • Length
    • Complexity
    • Central vs. Local Verification
    • Summary
  • Syncable Authenticators
    • Introduction
    • Cloning Authentication Keys
    • Implementation Requirements
    • Sharing
    • Example
    • Security Considerations
  • List of Symbols, Abbreviations, and Acronyms
  • Glossary
  • Change Log

Preface

本書およびその関連巻である [SP800-63]、[SP800-63A]、[SP800-63C] は、組織がデジタルアイデンティティサービスを実装するための技術ガイドラインを提供します。

本書 SP 800-63B は、3つの認証保証レベル（AAL）それぞれにおけるリモートのユーザー認証について、credential service providers（CSP）に対する要件を提供します。

1. Introduction

この節は参考情報（informative）です。

認証（Authentication）とは、デジタルアイデンティティを主張するために用いられる1つ以上の認証器（authenticator）の妥当性を判定するプロセスであり、デジタルサービスへアクセスしようとする主体が、認証に用いる秘密（secret）を管理していることを確立することによって行われます。サービスが再訪（return visits）を想定する場合、認証が成功することにより、今日サービスへアクセスしている主体が、以前にそのサービスへアクセスした主体と同一であるという、リスクに基づく合理的な保証が得られます。単回限りのサービス（すなわち、subscriber がそのサービスへアクセスするのが一度きりである場合）では、永続的なデジタル認証や認証器の発行が必ずしも必要とは限りません。

claimants の認証は、credential service provider（CSP）によって維持される subscriber account に記録されたオンライン活動と subscriber を結び付けるプロセスの中心となります。認証は、特定の subscriber account に関連付けられた1つ以上の authenticators（SP 800-63 の旧版では tokens と呼ばれていたもの）の管理を claimant が行っていることを検証することで実施されます。認証プロセスは verifier によって実行され、verifier は CSP の役割である場合もあれば、フェデレーション認証では Identity Provider (IdP) の役割である場合もあります。認証に成功すると、verifier は subscriber の identifier を Relying Party (RP) に対して表明します。必要に応じて、verifier は追加の attributes を RP に表明することもあります。

本ガイドラインは、さまざまな認証保証レベル（AAL）で利用できる認証プロセスの種類（認証器の選択を含む）について推奨事項を示します。また、認証器の初回発行、維持、そして認証器の紛失や盗難時の無効化など、認証器のライフタイム中に発生し得る出来事についても推奨事項を示します。

本ガイドラインは、ネットワーク経由でシステムに対して主体をデジタル認証する場合に適用されます。また、認証プロトコルに参加する verifiers と RPs が、認証相手となる claimant に対しても認証され、認証しているサービスのアイデンティティを保証することを求めます。本書は、物理的アクセス（例：建物への入館）のための個人認証は扱いません。

本ガイドラインは、subscriber が自身の認証用秘密を保護し、他者に開示しない（例：クレデンシャルの共有）責任を負うことを前提とします。各 AAL における防御は、クレデンシャル窃取に対する保護を目的としており、subscriber が意図的にクレデンシャルの秘密を開示する行為を防ぐことは目的としていません。多くの場合、そのような意図的な共謀や共有を検知し防止できる技術的対策はほとんどありません。

AAL は、認証トランザクションの強度を分類します。より強い認証（すなわち、より高い AAL）では、悪意ある行為者が認証プロセスを破るために、より高度な能力とより多くのリソースを必要とします。高い AAL での認証は、攻撃リスクを効果的に低減できます。各 AAL に関する技術要件の概要を以下に示します。具体的な規定要件については、本書の Sec. 2 および Sec. 3 を参照してください。

Authentication Assurance Level 1: AAL1 は、認証対象の subscriber account に結び付けられた authenticator を claimant が管理しているという基本的な確信を提供します。AAL1 は、幅広い利用可能な認証技術を用いた単要素認証のみを要求します。ただし、AAL1 と評価されるアプリケーションであっても、多要素認証の選択肢を提供することが推奨されます。認証が成功するためには、claimant が authenticator の所持および管理 を証明する必要があります。

Authentication Assurance Level 2: AAL2 は、認証対象の subscriber account に結び付けられた1つ以上の authenticator を claimant が管理しているという高い確信を提供します。2つの別個の authentication factors の所持および管理の証明が必要です。AAL2 と評価されるアプリケーションは、phishing-resistant な認証（Sec. 3.2.5 参照）の選択肢を提供しなければなりません。

Authentication Assurance Level 3: AAL3 は、認証対象の subscriber account に結び付けられた1つ以上の authenticator を claimant が管理しているという非常に高い確信を提供します。AAL3 の認証は、公開鍵暗号プロトコルを用いた鍵の所持証明に基づきます。AAL3 の認証では、フィッシング耐性を備えた authenticator（Sec. 3.2.5 参照）と、エクスポートできない認証鍵（Sec. 3.2.13 参照）が必要です。AAL3 で認証するには、claimant は2つの別個の authentication factors の所持および管理を証明する必要があります。

ある session が特定の AAL で認証されており、より高い AAL が必要になった場合、認証プロセスは session の AAL を引き上げるステップアップ認証を提供することもあります。

1.1. Notations

本ガイドラインは本文中で次の表記上の約束を用います。

• 大文字（CAPITALS） で示される特定の用語は、規定（normative）の要件を表します。同じ用語が 大文字ではない 場合、その用語は規定要件を表しません。
  • “SHALL” および “SHALL NOT” は、本書に適合するために厳格に従うべき要件を示し、逸脱は認められません。
  • “SHOULD” および “SHOULD NOT” は、複数の可能性の中で特に適切として推奨されるもの（他を言及・排除しない）、ある行動方針が望ましいが必須ではないこと、または（否定形では）ある可能性や方針を推奨しないが禁止ではないことを示します。
  • “MAY” および “NEED NOT” は、本書の範囲内で許容される行動方針を示します。
  • “CAN” および “CANNOT” は、可能性および能力（物質的・物理的・因果的）を示し、否定形ではその可能性または能力が存在しないことを示します。

1.2. Document Structure

本書は次のとおり構成されています。各節は、規定（normative：適合のために必須）または参考情報（informative：必須ではない）のいずれかとしてラベル付けされています。

• Section 1 は本書を紹介します。この節は informative です。
• Section 2 は AAL に関する要件を記述します。この節は normative です。
• Section 3 は authenticator および verifier の要件を記述します。この節は normative です。
• Section 4 は authenticator のイベント管理に関する要件を記述します。この節は normative です。
• Section 5 は session 管理に関する要件を記述します。この節は normative です。
• Section 6 はセキュリティ上の考慮事項を示します。この節は informative です。
• Section 7 はプライバシー上の考慮事項を示します。この節は informative です。
• Section 8 は顧客体験上の考慮事項を示します。この節は informative です。
• References 節は、本書で引用した刊行物を列挙します。この節は informative です。
• Appendix A はパスワードの強度を議論します。この付録は informative です。
• Appendix B は同期可能な authenticator を議論します。この付録は normative です。
• Appendix C は本書で使用される略語の抜粋リストを含みます。この付録は informative です。
• Appendix D は本書で使用される用語の抜粋用語集を含みます。この付録は informative です。
• Appendix E は本書の変更履歴の要約リストを含みます。この付録は informative です。

2. Authentication Assurance Levels

この節は規定（normative）です。

所定の AAL の要件を満たし subscriber として認められるために、claimant は、そのレベルの要件と同等以上の強度を持つプロセスで RP（または [SP800-63C] に記載のとおり IdP）に対して認証を SHALL 行わなければなりません。認証プロセスは、claimant がその RP に認証するたびに subscriber を一意に識別する identifier を生成します。identifier は匿名化されたもの（pseudonymous）であっても MAY かまいません。subscriber を一意の主体として識別する他の attributes も提供されても MAY かまいません。各 AAL における authenticator および verifier の詳細な規定要件は Sec. 3 に示します。最も適切な AAL の選び方については [SP800-63] Sec. 3 を参照してください。

アイデンティティ証明（identity proofing）中およびその後に収集された個人情報（[SP800-63A] 参照）は、デジタルアイデンティティサービスにより subscriber account を通じて subscriber に提供されても MAY かまいません。連邦機関が個人情報を公開またはオンラインで利用可能にする場合は、[EO13681] に従い多要素認証が必要です。したがって、連邦機関は個人情報をオンラインで利用可能にする場合、最低でも AAL2 を SHALL 選択しなければなりません。

すべての AAL において、Sec. 5.3 に記載された適用可能な指標を含む潜在的な不正の兆候は、誤認証（misauthentication）のリスクを低減するために MAY 用いられます。たとえば、予期しない地理的位置や IP アドレスブロック（例：クラウドサービス）からの認証は、追加のリスクベース制御の適用を促す場合があります。CSP または verifier は、潜在的不正指標の利用について、有効性を評価し、ユーザー集団への負の影響を特定して緩和するために SHALL 評価しなければなりません。CSP または verifier は、認証のプライバシーリスク評価に不正指標を SHALL 含めなければなりません。認証前または認証中に潜在的不正指標を使用しても、トランザクションの AAL に影響や変更を与えることはなく、また認証要素の代替にもなりません。

本書全体を通じて、[FIPS140] の要件は、Cryptography Module Validation Program（[CMVP]）により検証された暗号実装を利用するセキュリティ技術、製品、サービスによって満たされます。所定の AAL における FIPS 140 の要件は、authenticator と verifier で異なることが多く、一般に verifier に対してより厳格な要件が適用されます。これは、authenticator の認証取得に関する実務上の制約、および verifier における侵害が通常より広範な影響を持つことを踏まえたものです。

2.1. Authentication Assurance Level 1

AAL1 は、claimant が subscriber account に結び付けられた authenticator を管理しているという基本的な確信を提供します。AAL1 は、利用可能な幅広い認証技術を用いた単要素認証または多要素認証のいずれかを要求します。verifier は、AAL1 で多要素認証の選択肢を利用可能にし、その利用を促すことを SHOULD とします。認証が成功するためには、claimant が安全な認証プロトコルを通じて authenticator の所持および管理を証明する必要があります。

2.1.1. Permitted Authenticator Types

AAL1 の認証は、次のいずれかの認証タイプを SHALL 使用しなければなりません（詳細定義は Sec. 3）。

• Password（Sec. 3.1.1）：通常、subscriber が選択する記憶可能な秘密
• Look-up secret（Sec. 3.1.2）：subscriber が保持するリストから、提示された値を参照して claimant が決定する秘密
• Out-of-band device（Sec. 3.1.3）：subscriber と別の通信チャネルを介して送受信される秘密
• Single-factor one-time password (OTP)（Sec. 3.1.4）：subscriber が保持するデバイスまたはアプリケーションから得られる一回限りの秘密
• Multi-factor OTP（Sec. 3.1.5）：subscriber が保持するデバイスまたはアプリケーションから得られる一回限りの秘密で、第二の認証要素による起動が必要なもの
• Single-factor cryptographic authentication（Sec. 3.1.6）：subscriber が保持する暗号鍵の、認証プロトコルによる所持および管理の証明
• Multi-factor cryptographic authentication（Sec. 3.1.7）：subscriber が保持する暗号鍵の、第二の認証要素による起動を伴う認証プロトコルによる所持および管理の証明

2.1.2. Authenticator and Verifier Requirements

AAL1 で使用される authenticators は approved cryptography を SHALL 使用しなければなりません。すなわち、承認されたアルゴリズムを使用しなければなりませんが、実装が [FIPS140] に基づき検証されている必要はありません。

claimant と verifier の間の通信は、1つ以上の authenticated protected channels を介して SHALL 行われなければなりません。

連邦機関により、または連邦機関の代理として運用される AAL1 の verifiers が使用する暗号は、[FIPS140] Level 1 の要件を満たすよう検証されていることを SHALL 求められます。

2.1.3. Reauthentication

本ガイドラインは、Sec. 5.2 でさらに説明する2種類のタイムアウトを規定します。

1. 全体タイムアウト（overall timeout）は、認証または直前の再認証の後、認証済み session の持続時間を一定期間に制限します。
2. 非活動タイムアウト（inactivity timeout）は、subscriber からの活動が一定期間ない session を終了させます。

subscriber の session の定期的な再認証は、Sec. 5.2 に記載のとおり SHALL 実施されなければなりません。再認証の全体タイムアウト（definite reauthentication overall timeout）を SHALL 設定しなければならず、AAL1 では 30 日を超えないことを SHOULD とします。非活動タイムアウトは適用しても MAY かまいませんが、AAL1 では必須ではありません。

2.2. Authentication Assurance Level 2

AAL2 は、claimant が subscriber account に結び付けられた1つ以上の authenticator を管理しているという高い確信を提供します。安全な認証プロトコルを通じて、2つの別個の認証要素の所持および管理を証明することが必要です。approved cryptographic techniques が必要です。

2.2.1. Permitted Authenticator Types

AAL2 では、認証は、多要素 authenticator か、2つの別個の認証要素の組み合わせのいずれかを SHALL 使用しなければなりません。多要素 authenticator は、暗号学的に安全なデバイスに統合された生体センサーを用いてデバイスを起動する場合など、単一の認証イベントの実行に2要素を必要とします。authenticator の要件は Sec. 3 に規定されます。

多要素 authenticator を使用する場合、次のいずれかを MAY 使用できます。

• Multi-factor out-of-band authenticator（Sec. 3.1.3.4）
• Multi-factor OTP（Sec. 3.1.5）
• Multi-factor cryptographic authentication（Sec. 3.1.7）

2つの単要素 authenticator の組み合わせを使用する場合、その組み合わせは、次の一覧から physical authenticator（すなわち「持っているもの」）を1つ含み、かつ Password（Sec. 3.1.1）または生体比較のいずれかと組み合わせることを SHALL とします。

• Look-up secret（Sec. 3.1.2）
• Out-of-band device（Sec. 3.1.3）
• Single-factor OTP（Sec. 3.1.4）
• Single-factor cryptographic authentication（Sec. 3.1.6）

生体特性は、それ単体では authenticator として認められません。Section 3.2.3 は、物理 authenticator を生体比較と合わせて認証することを求めます。物理 authenticator が「持っているもの」として機能し、生体一致が「本人であること」を示す要素として機能します。多要素 authenticator の起動要素として生体比較を用いる場合、authenticator 自体が物理 authenticator として機能します。その節で述べたとおり、生体要素のローカル検証（すなわち、生体比較を起動要素として用いる多要素 authenticator の利用）が、中央での生体要素比較より望ましいとされます。

2.2.2. Authenticator and Verifier Requirements

AAL2 で使用される authenticators は approved cryptography を SHALL 使用しなければなりません。連邦機関が調達する暗号 authenticator は、[FIPS140] Level 1 の要件を満たすよう検証されていることを SHALL とします。AAL2 で使用される少なくとも1つの authenticator は、Sec. 3.2.7 に記載のとおりリプレイ耐性（replay-resistant）を SHALL 備えなければなりません。AAL2 の認証は、Sec. 3.2.8 で議論されるとおり、少なくとも1つの authenticator による認証意思（authentication intent）の提示を SHOULD 求めます。

claimant と verifier の間の通信は、1つ以上の authenticated protected channels を介して SHALL 行われなければなりません。

連邦機関により、または連邦機関の代理として運用される AAL2 の verifiers が使用する暗号は、別段の指定がない限り、[FIPS140] Level 1 の要件を満たすよう検証されていることを SHALL とします。

verifier は、Sec. 3.2.5 に記載のとおり、AAL2 で少なくとも1つの phishing-resistant な認証オプションを SHALL 提供しなければなりません。連邦機関は、連邦情報システムへアクセスするために、職員、請負業者、パートナーに phishing-resistant な認証の使用を SHALL 求めなければなりません。すべての場合において、フィッシングは重要な脅威ベクトルであるため、実用的である限り AAL2 で phishing-resistant な認証の利用を奨励することを verifier は SHOULD とします（[IC3] 参照）。

2.2.3. Reauthentication

subscriber の session の定期的な再認証は、Sec. 5.2 に記載のとおり SHALL 実施されなければなりません。再認証の全体タイムアウトを SHALL 設定しなければならず、AAL2 では 24 時間を超えないことを SHOULD とします。非活動タイムアウトは 1 時間を超えないことを SHOULD とします。非活動タイムアウトが発生したが全体タイムアウトはまだ発生していない場合、verifier は、Sec. 5.1 に記載の session secret と組み合わせた Password または生体比較のみで subscriber が再認証できるようにしても MAY かまいません。

2.3. Authentication Assurance Level 3

AAL3 は、claimant が subscriber account に結び付けられた authenticators を管理しているという非常に高い確信を提供します。AAL3 の認証は、起動要素または Password と併用した暗号プロトコルによる鍵の所持証明に基づきます。AAL3 の認証には、フィッシング耐性を提供する、エクスポートできない private key を備えた暗号 authenticator の使用が必要です。approved cryptographic techniques が必要です。

2.3.1. Permitted Authenticator Types

AAL3 の認証は、次のいずれかの authenticator の組み合わせを SHALL 要求します。

• Multi-factor cryptographic authentication（Sec. 3.1.7）
• Single-factor cryptographic authentication（Sec. 3.1.6）を、Password（Sec. 3.1.1）または生体比較のいずれかと併用する

生体特性は、それ単体では authenticator として認められません。Section 3.2.3 は、物理 authenticator を生体比較と合わせて認証することを求めます。物理 authenticator が「持っているもの」として機能し、生体一致が「本人であること」を示す要素として機能します。多要素 authenticator の起動要素として生体比較を用いる場合、authenticator 自体が物理 authenticator として機能します。その節で述べたとおり、生体要素のローカル検証が中央での生体要素比較より望ましいとされます。

2.3.2. Authenticator and Verifier Requirements

AAL3 で使用される authenticators は approved cryptography を SHALL 使用しなければなりません。claimant と verifier の間の通信は、1つ以上の authenticated protected channels を介して SHALL 行われなければなりません。AAL3 で使用される暗号 authenticator は、エクスポートできない private key を SHALL 持ち、Sec. 3.2.5 に記載のとおりフィッシング耐性を SHALL 提供しなければなりません。暗号認証プロトコルは、Sec. 3.2.7 に記載のとおりリプレイ耐性を SHALL 備えなければなりません。AAL3 におけるすべての認証および再認証プロセスは、Sec. 3.2.8 に記載のとおり、少なくとも1つの authenticator からの認証意思を SHALL 示さなければなりません。AAL3 で使用される暗号 authenticator は、verifier の侵害から認証用秘密を保護するために公開鍵暗号を SHALL 使用しなければなりません。

AAL3 で使用される単要素および多要素 authenticators は、全体として [FIPS140] Level 1 以上の要件を満たすよう検証されていることを SHALL とします。Sec. 3.2.12 に記載のとおり、AAL3 の暗号 authenticator は、認証鍵の漏えい・抽出を防ぐために、ハードウェアで保護された隔離環境を提供することが求められます。syncable authenticators（Appendix B 参照）では private key がエクスポート可能である必要があるため、syncable authenticators は AAL3 で SHALL NOT 使用されます。

AAL3 の verifiers が使用する暗号は、[FIPS140] Level 1 以上で検証されていることを SHALL とします。

AAL3 のハードウェアベースの authenticators および verifiers は、関連するサイドチャネル攻撃（例：タイミング分析や消費電力分析）に耐性を持つことを SHOULD とします。

2.3.3. Reauthentication

subscriber の session の定期的な再認証は、Sec. 5.2 に記載のとおり SHALL 実施されなければなりません。AAL3 では、再認証の全体タイムアウトは 12 時間を超えないことを SHALL とします。非活動タイムアウトは 15 分を超えないことを SHOULD とします。AAL2 と異なり、AAL3 の再認証要件は、AAL3 の初回認証と同一です。

2.4. General Requirements

以下の要件は、すべての AAL における認証に適用されます。

2.4.1. Security Controls

verifier は、[SP800-53] で定義された中程度（moderate）ベースラインのセキュリティコントロール、または同等の連邦基準（例：[FEDRAMP]）あるいは組織が選択した業界標準から、これらのガイドラインで保護する情報システム、アプリケーション、オンラインサービスに適したセキュリティコントロールを SHALL 適用しなければなりません。

2.4.2. Records Retention Policy

verifier は、適用される法律、規則、方針、ならびに適用され得る National Archives and Records Administration（NARA）の記録保存スケジュールを含む、各自の記録保存方針に SHALL 従わなければなりません。必須要件がない状況で記録を保持することを verifier が選択する場合、verifier または、それが属する CSP または Identity Provider (IdP) は、プライバシーおよびセキュリティリスクの評価を含む risk management プロセス（[NISTRMF] 参照）を SHALL 実施し、記録を保持すべき期間を決定し、かつ subscriber にその保持方針を SHALL 通知しなければなりません。

2.4.3. Privacy Requirements

verifier は、[SP800-53] で定義された適切なプライバシーコントロール、または同等の業界標準を SHALL 適用しなければなりません。

CSP または Identity Provider (IdP) が、アイデンティティサービス（すなわち identity proofing、認証、または属性の assertions）、関連する不正対策、または法律・法的手続の遵守以外の目的で attributes を処理する場合、それらは、追加の処理から生じるプライバシーリスクに見合う形で予測可能性と管理可能性を維持するための措置を SHALL 実装しなければなりません。例として、明確な通知、subscriber の同意取得、属性の選択的な利用や開示を可能にすることが挙げられます。CSP または Identity Provider (IdP) が同意措置を用いる場合、追加処理への同意をアイデンティティサービス提供の条件として SHALL NOT 取り扱ってはなりません。

CSP または Identity Provider (IdP) が機関であるか民間事業者であるかにかかわらず、認証サービスを提供または利用する連邦機関には次の要件が適用されます。

1. 機関は Senior Agency Official for Privacy（SAOP）に SHALL 相談し、authenticators の発行または維持のために個人情報を収集することが Privacy Act of 1974（[PrivacyAct]）の要件を発動させるかを判断する分析を SHALL 実施しなければなりません（Sec. 7.4 参照）。
2. 機関は、該当する場合、その収集を対象とする System of Records Notice（SORN）を SHALL 公表しなければなりません。
3. 機関は SAOP に SHALL 相談し、authenticators の発行または維持のための個人情報収集が E-Government Act of 2002（[E-Gov]）の要件を発動させるかを判断する分析を SHALL 実施しなければなりません。
4. 機関は、該当する場合、その収集を対象とする Privacy Impact Assessment（PIA）を SHALL 公表しなければなりません。

2.4.4. Redress Requirements

verifier および関連する CSP または Identity Provider (IdP) は、[SP800-63] の Sec. 5.6 に記載のとおり、subscriber の苦情や、subscriber 認証プロセスから生じる問題を救済する仕組みを SHALL 提供しなければなりません。これらの仕組みは subscriber が容易に見つけて利用できることを SHALL とします。CSP または Identity Provider (IdP) は、苦情や問題の解決における有効性について、この仕組みを SHALL 評価しなければなりません。

2.5. Summary of Requirements

Table 1 は、各 AAL における要件の非規定（non-normative）な要約を示します。

Table 1. Summary of requirements by AAL

Requirement	AAL1	AAL2	AAL3
Permitted Authenticator Types	\ 任意の AAL2 または AAL3 の authenticator 種別 \ Password \ Look-up secret \ Out-of-band \ 単要素 OTP（SF OTP） \ 単要素 cryptographic	\ 多要素 cryptographic（MF cryptographic） \ 多要素 out-of-band（MF out-of-band） \ 多要素 OTP（MF OTP） \ Password または生体比較、加えて：–単要素 cryptographic –Look-up secret –Out-of-band –単要素 OTP	\ 多要素 cryptographic（MF cryptographic） \ 単要素 cryptographic、加えて：–Password –生体比較
FIPS 140 Validation（政府の verifiers および authenticators）	Verifiers –Level 1	Verifiers –Level 1 Authenticators –全体として Level 1	Verifiers –Level 1 Authenticators –全体として Level 1
Reauthentication（推奨）	全体で 30 日	全体で 24 時間／非活動 1 時間／単要素が必要	全体で 12 時間／非活動 15 分
Phishing Resistance	必須ではない	推奨；利用可能でなければならない	必須
Replay Resistance	必須ではない	必須	必須
Authentication Intent	必須ではない	推奨	必須
Key Exportability	許可	許可	禁止

3. Authenticator and Verifier Requirements

この節は規定（normative）です。

本節は、各種 authenticator タイプに固有の詳細要件を提供します。Sec. 2 に規定された再認証要件と、Sec. 3.2.5 に記載された AAL3 のフィッシング耐性要件を除き、各 authenticator タイプの技術要件は、authenticator がどの AAL で使用されるかに依存せず同一です。

[SP800-63C] に記載されたフェデレーション・アプリケーションでは、IdP の認証機能は CSP または verifier の機能と密接に対応します。以下の議論では、CSP に関する要件は IdP にも適用されます。

多くの場合、subscriber は認証プロセスで使用されるデバイス（例：OTP を受け取る家族共用の電話）を共有する必要があります。公開向けアプリケーションでは、CSP はデバイスが複数の subscriber により authenticator として登録されることを SHOULD NOT 妨げるべきです。ただし、大規模な不正や悪用を防ぐため（例：単一デバイスが登録できる subscriber account の総数を制限する等）、制限を設けても MAY かまいません。

認証、authenticator binding（Sec. 4.1）、および session 管理（Sec. 5）は、Table 2 に示すとおり、1つ以上の種類の秘密の所持証明に基づきます。

Table 2. Summary of secrets (non-normative)

Type of Secret	Purpose	Reference Section
Password	認証要素として使用される subscriber が選ぶ秘密	3.1.1
Look-up secret	verifier が発行し、一度だけ秘密の所持を証明するために使用される秘密	3.1.2
Out-of-band secret	verifier が生成し、subscriber のデバイスに独立して送信して所持を検証する短命な秘密	3.1.3
One-time passcodes (OTP)	authenticator が生成し、authenticator の所持を証明するために一度だけ使用される秘密	3.1.4、3.1.5
Activation secret	多要素 authenticator の起動要素としてローカルで使用される Password	3.2.10
Long-term authenticator secret	物理 authenticator に埋め込まれ、認証のために機能させる秘密	4.1
Recovery code	subscriber が認証できなくなった account を回復するために発行される秘密	4.2
Session secret	認証時に verifier が発行し、認証済み session の継続性を確立するために使用される秘密	5.1

3.1. Requirements by Authenticator Type

以下の要件は特定の authenticator タイプに適用されます。

3.1.1. Passwords

Password（passphrase と呼ばれることもあり、数値のみの場合は personal identification number [PIN] と呼ばれることもあります）は、subscriber が選択し、記憶するか記録することを意図した秘密値です。Password は、攻撃者が正しい秘密値を推測または発見することが現実的でない程度に、有効な強度と秘匿性を備えていなければなりません。Password は「知っているもの」です。

本節の要件は、独立した認証要素として使用され、authenticated protected channel を介して verifier に送信される、中央検証型（centrally verified）の Password に適用されます。多要素 authenticator の起動要素としてローカルで使用される Password（例：ロック解除用の PIN）は activation secrets と呼ばれ、Sec. 3.2.10 で議論します。中央検証型 Password と対照的に、activation secrets（多くのデバイスにあるロック解除用 Password や PIN と同様）は verifier に送られず、認証用秘密へのアクセスを得るためにローカルで使用されます。

Passwords はフィッシング耐性を持ちません。

Password Authenticators

Passwords は、subscriber が選択するか、CSP がランダムに割り当てるかのいずれかで SHALL あります。

CSP が、よく使われる・推測されやすい・漏えいした値のブロックリスト（Sec. 3.1.1.2 参照）に含まれることを理由に選択 Password を許可しない場合、subscriber は別の Password を選ぶことを SHALL 求められます。Password に対して、他の構成要件（SHALL NOT：異なる文字種の混在を要求する等）を課してはなりません。その根拠は Appendix A「Strength of Passwords」に示します。

Password Verifiers

以下の要件は Password に適用されます。

1. verifier と CSP は、単要素認証の仕組みとして使用される Password の最小長を 15 文字として SHALL 要求しなければなりません。verifier と CSP は、多要素認証プロセスの一部としてのみ使用される Password をより短くしても MAY かまいませんが、その場合でも最小長を 8 文字として SHALL 要求しなければなりません。
2. verifier と CSP は、最大 Password 長として少なくとも 64 文字を SHOULD 許容すべきです。
3. verifier と CSP は、印字可能な ASCII 文字（[RFC20]）およびスペース文字を Password に SHOULD 受け入れるべきです。
4. verifier と CSP は、Unicode 文字（[ISO/ISC 10646]）を Password に SHOULD 受け入れるべきです。Password 長を評価する際、各 Unicode code point は 1 文字として SHALL カウントされなければなりません。
5. verifier と CSP は、Password に対して他の構成規則（例：文字種の混在要求）を SHALL NOT 課してはなりません。
6. verifier と CSP は、subscriber に定期的な Password 変更を SHALL NOT 要求してはなりません。ただし verifier は、authenticator が侵害された証拠がある場合、変更を SHALL 強制しなければなりません。
7. verifier と CSP は、未認証の claimant がアクセスできるヒント（例：Password の作り方のメモ）を subscriber が保存することを SHALL NOT 許可してはなりません。
8. verifier と CSP は、subscriber が Password を選ぶ際に、知識ベース認証（KBA）（例：「最初のペットの名前は？」）や秘密の質問を用いるよう促すことを SHALL NOT 行ってはなりません。
9. verifier は、Password を全体として入力するよう SHALL 求めなければならず（部分入力ではない）、提出された Password 全体を SHALL 検証しなければなりません（例：切り詰めてはならない）。

Unicode 文字を Password で受け入れる場合、verifier は、Unicode Normalization Forms の Sec. 12.1 で定義された NFC（Normalization Form Canonical Composition）による安定化文字列の正規化プロセスを SHOULD 適用すべきです（[UAX15] 参照）。このプロセスは、Password を表すバイト列をハッシュ化する前に適用されます。Unicode 文字を含む Password を選ぶ subscriber には、エンドポイントによっては一部の文字が異なる表現になる可能性があり、それにより認証に成功できない場合があることを SHOULD 伝えるべきです。

Password の設定または変更要求を処理する際、verifier は、候補の秘密を、よく使われる・推測されやすい・漏えいした Password を含むブロックリストと SHALL 照合しなければなりません。Password 全体を照合対象とし、部分文字列や含まれる単語のみを対象としてはなりません。たとえば、ブロックリストには次が含まれ得ます。

• 過去の漏えいデータ集合から得られた Password
• 辞書語
• サービス名、ユーザー名、およびそれらの派生語などの文脈依存語

選択された Password がブロックリスト上に見つかった場合、CSP は subscriber に別の秘密を選ぶことを SHALL 求め、拒否理由を SHALL 提供しなければなりません。ブロックリストは総当たり攻撃への防御として利用され、失敗試行はレート制限されるため、ブロックリストは、攻撃者が試行上限に達する前に推測しやすい Password を subscriber が選ぶことを防ぐのに十分なサイズであることを SHOULD とします。

ブロックリストを過度に大きくしても、オンライン攻撃に対する追加的なセキュリティ効果は小さい傾向があります。オンライン攻撃は、Sec. 3.2.2 に記載のスロットリング要件により既に制限されるためです。

verifier は、subscriber が強い Password を選べるようにガイダンスを SHALL 提供しなければなりません。これは、ブロックリスト上の Password が拒否された後に特に重要です。なぜなら、弱い Password の些細な変更を抑止するためです（[Blocklists] 参照）。

verifier は、Sec. 3.2.2 に記載のとおり、subscriber account に対して実行できる失敗した認証試行の回数を効果的に制限するレート制限機構を SHALL 実装しなければなりません。

verifier は、Password マネージャーおよび自動入力機能の利用を SHALL 許可しなければなりません。Password 自動入力 API が利用できない場合でも Password マネージャーを利用しやすくするため、Password 入力時に「貼り付け」機能を利用することを claimant に SHOULD 許可すべきです。Password マネージャーは、特に Password 生成器を備える場合、subscriber がより強い Password を選ぶ可能性を高めることが示されています（[Managers] 参照）。

claimant が Password を正しく入力できるよう、verifier は、入力中および提出までの間、点やアスタリスクの列ではなく Password を表示できる選択肢を SHOULD 提供すべきです。これにより、画面を覗き見されにくい場所で claimant が入力内容を確認できます。verifier は、各文字入力後に短時間だけ入力文字を表示することを claimant のデバイスに許可しても MAY かまいません。これはモバイルデバイスで一般的です。

verifier は、Password が必要最小長を満たし続け、かつ結果の Password の複雑さが著しく低下しない範囲で、タイプミスに対する限定的な許容（例：検証前に前後の空白を除去する、先頭文字のみ大文字小文字の差異を許容する等）を MAY 認めてもかまいません。

verifier と CSP は、Password を要求する際に approved encryption および authenticated protected channel を SHALL 使用しなければなりません。

verifier は、Password をオフライン攻撃に耐性のある形式で SHALL 保存しなければなりません。Passwords は、適切な Password ハッシュ方式を用いて salted し、ハッシュ化されることを SHALL とします。Password ハッシュ方式は、Password、salt、cost factor を入力として Password ハッシュを生成します。その目的は、ハッシュ化された Password ファイルを入手した攻撃者にとって各推測をより高コストにし、推測攻撃のコストを高く（または実質的に不可能に）することです。選択された cost factor は、verifier の性能に悪影響を与えない範囲で可能な限り高いことを SHOULD とします。また、計算性能の向上を考慮して時間とともに引き上げることを SHOULD とします。最新改訂の [SP800-132] に掲載された承認済み Password ハッシュ方式、または Password ハッシュ方式に関する最新の NIST ガイドラインを SHOULD 使用すべきです。salt とバージョニング情報を除いた Password verifier の出力長は、基礎となる Password ハッシュ方式の出力長と同じであることを SHOULD とします。

salt は少なくとも 32 ビット長で SHALL あり、保存されるハッシュ間で salt 値の衝突を最小化するよう選ばれなければなりません（すなわち、複数の subscriber account が同一のハッシュ化 Password を持つことを防ぐ）。salt 値と生成されたハッシュは、各 Password について SHALL 保存されなければなりません。新しいアルゴリズムや work factor への移行を可能にするため、使用した Password ハッシュ方式（cost factor を含む）への参照を各 Password について保存することを SHOULD とします。

さらに、verifier のみが知る秘密鍵を用いた鍵付きハッシュまたは暗号化操作を追加で1回実行することを verifiers は SHOULD とします。これを使用する場合、その鍵値は Sec. 3.2.12 に記載のとおり、承認済み乱数ビット生成器で生成されることを SHALL とします。秘密鍵値はハッシュ化 Password とは別に SHALL 保存されなければなりません。この鍵値は、hardware security module や trusted execution environment (TEE)、trusted platform module (TPM) などのハードウェア保護領域内で保存・使用されることを SHOULD とします。この追加反復により、秘密鍵値が秘匿されている限り、ハッシュ化 Password に対する総当たり攻撃は現実的ではなくなります。

3.1.2. Look-Up Secrets

Look-up secret authenticator は、claimant と CSP の間で共有される秘密の集合を格納する物理または電子的な記録です。claimant は authenticator を用いて、verifier からのプロンプトに応答するために必要な適切な秘密を参照します。たとえば、verifier は claimant に対して、表形式カードに印刷された数値または文字列の特定の部分集合を提示するよう求めることができます。Look-up secret の典型的な用途は、別の authenticator を紛失または故障した場合に備えて subscriber が保存する、一回限りの保存済み回復コード（Sec. 4.2.1.1 参照）です。Look-up secret は「持っているもの」です。

Look-up secrets はフィッシング耐性を持ちません。

Look-Up Secret Authenticators

Look-up secret authenticator を作成する CSP は、Sec. 3.2.12 に記載のとおり、承認済み乱数ビット生成器を SHALL 使用して秘密リストを生成し、authenticator リストを subscriber に安全に SHALL 配送しなければなりません（例：対面セッション、オンラインセッション、郵送で連絡先住所へ）。オンラインセッションで配送する場合、その session は AAL2 以上で subscriber により認証されていることを SHALL とし、authenticated protected channel を通じて秘密を配送し、かつ Sec. 4.1.2 の post-enrollment binding 要件に従うことを SHALL とします。Look-up secrets は、少なくとも 6 桁の10進数（または同等）で SHALL あります。長さによっては Sec. 3.1.2.2 に記載の追加要件が適用される場合もあります。

Look-Up Secret Verifiers

Look-up secrets の verifier は、claimant に authenticator から秘密を提示するよう SHALL 促さなければなりません。Look-up secret authenticator からの秘密は、成功して使用できるのは一度だけで SHALL あります。Look-up secret がグリッドカードから導出される場合、各グリッドセルは一度だけ使用されることを SHOULD とし、これにより Look-up secrets で実行できる認証回数が制限されます。非常に長い秘密リストが必要になる可能性があります。

verifier は、Look-up secrets をオフライン攻撃に耐性のある形式で SHALL 保存しなければなりません。すべての Look-up secrets は、承認済みハッシュ関数を用いてハッシュ化された形式で SHALL 保存されなければなりません。

Look-up secrets は、Sec. 3.1.2.1 に規定のとおり、少なくとも 6 桁の10進数（または同等）で SHALL あります。規定長より短い Look-up secrets には、次の追加の検証要件が適用されます。

• 最新改訂の [SP800-131A] に規定の最小セキュリティ強度（本書発行日時点では 112 ビット）を下回る短さの Look-up secrets は、Sec. 3.1.1.2 に記載のとおり、適切な Password ハッシュ方式を用いて salted し、ハッシュ化された形式で SHALL 保存されなければなりません。salt 値は少なくとも 32 ビットで SHALL あり、保存されるハッシュ間で salt 値の衝突を最小化するよう任意に選ばれなければなりません。salt 値と生成されたハッシュは、各 Look-up secret について SHALL 保存されなければなりません。

• verifier は、Sec. 3.2.2 に記載のとおり、subscriber account に対して失敗した認証試行の回数を効果的に制限するレート制限機構を SHALL 実装しなければなりません。

verifier は、Look-up secrets を要求する際に approved encryption および authenticated protected channel を SHALL 使用しなければなりません。

3.1.3. Out-of-Band Devices

Out-of-band authenticator は、個別にアドレス指定可能であり、独立した通信チャネル（secondary channel）を介して verifier と安全に通信できる物理デバイスです。デバイスは claimant により所持・管理され、この別の secondary channel による私的通信をサポートします。secondary channel は、認証の primary channel とは別です。Out-of-band authenticator は「持っているもの」です。Out-of-band device の例には、verifier が subscriber と独立に通信できるアプリケーションを備えたスマートフォン、またはテキストメッセージや音声通話を用いた subscriber との通信が含まれます。

Out-of-band 認証は、verifier が生成する短期の秘密を使用します。この秘密は、primary と secondary の両チャネル上の認証操作を安全に結び付け、out-of-band device を claimant が管理していることを確立します。

Out-of-band 認証はフィッシング耐性を持ちません。

Out-of-band authenticator は、次のいずれかの方法で動作します。

• claimant が、secondary channel を介して out-of-band device で受け取った秘密を、primary channel を用いて verifier に転送します。たとえば、claimant はモバイルデバイスで（通常 6 桁のコードなどの）秘密を受け取り、認証 session に入力します。この方法を Fig. 1 に示します。

Fig. 1. Transfer of secret to primary device

（図：out-of-band device から、認証対象の session へ認証用秘密が転送されることを示す図）

• claimant が、primary channel で受け取った秘密を out-of-band device に転送し、それを secondary channel で verifier に送信します。たとえば、claimant は認証 session 上の秘密を見て、モバイルデバイスのアプリケーションに入力するか、バーコードや QR code などの技術を用いて転送します。この方法を Fig. 2 に示します。

Fig. 2. Transfer of secret to out-of-band device

（図：認証対象の session から out-of-band device へ認証用秘密が転送されることを示す図）

Note: out-of-band 認証の第3の方法として、primary と secondary の両チャネルから受け取った秘密を比較し、secondary channel 上で承認を求める方法があります。しかしこの方法は、subscriber が要求されている比較を実際には行わずに認証要求を承認してしまう可能性を高めるため、もはや許容される方法とは見なされません。これは、攻撃者が多数の out-of-band 認証要求を subscriber に生成し、subscriber が煩わしさを解消するために1つを承認してしまう可能性がある「認証疲れ（authentication fatigue）」攻撃として観測されています。このため、本ガイドラインは、subject が verifier とともに session に能動的に参加しているという保証を高めるため、out-of-band device と primary channel の間で秘密を転送することを求めます。claimant に比較用の秘密リストを提示するだけでは、提示できるリストのサイズが限られているため、claimant が合理的に秘密を推測できてしまい、この要件を満たすのに十分ではありません。

Out-of-Band Authenticators

Out-of-band authenticator は、out-of-band secret または認証要求を取得するために、verifier との別チャネルを SHALL 確立しなければなりません。このチャネルは、デバイスが claimant の関与なしに一方のチャネルから他方へ情報を漏えいしない限り（たとえ同じデバイス上で終端していても）、primary communication channel に対して out-of-band と見なされます。

out-of-band device は、verifier が一意にアドレス指定できることを SHOULD とします。secondary channel 上の通信は、public switched telephone network (PSTN) 経由で送信される場合を除き、approved encryption を SHALL 使用しなければなりません。PSTN を out-of-band 認証に使用する場合に固有の追加要件については Sec. 3.1.3.3 を参照してください。

Email は out-of-band 認証に SHALL NOT 使用されます。なぜなら、次の脆弱性があり得るためです。

• Password のみでのアクセス
• 転送中または中継メールサーバにおける傍受
• Domain Name System (DNS) のなりすましに起因するようなリルート攻撃

Email アドレスを検証するために送られる確認コード、または回復コードとして発行されるコード（Sec. 4.2.1.2 参照）は認証プロセスではなく、上記の禁止の影響を受けません。

out-of-band authenticator は、verifier と通信する際に、次のいずれかの方法で自身を一意に SHALL 認証しなければなりません。

• approved cryptography を用いて、verifier との相互認証された protected channel（例：クライアント認証付き transport layer security (TLS)（[RFC8446]））を確立します。out-of-band authenticator と verifier の通信は、各者が認証する信頼できる中継サービスを MAY 使用してもかまいません。チャネル確立に使用される鍵は、Sec. 4.1 に記載のとおり、authenticator binding 中の相互認証 session で SHALL プロビジョニングされなければなりません。

• SIM カードまたは subscriber を一意に識別する同等の秘密を用いて、公衆移動体通信網に対して認証します。この方法は、verifier から out-of-band device へ PSTN（SMS または音声）または暗号化されたインスタントメッセージングサービスにより秘密が送信される場合にのみ SHALL 使用されます。

• verifier が out-of-band secret を電話で伝えられる PSTN への有線接続を使用します。本定義における「有線接続」には、他の有線メディアやアナログ電話アダプタ経由のファイバーを通じて PSTN サービスを提供するケーブル事業者などのサービスも含まれます。

単要素 out-of-band authenticator の場合、verifier が out-of-band device に秘密を送信するなら、デバイスは所有者によりロックされている間、その認証用秘密を表示しないことを SHOULD NOT とします。代わりに、秘密を表示するには PIN、パスコード、または生体特性の提示と検証を SHOULD 要求すべきです。ただし、authenticators は、ロック状態のデバイス上で認証用秘密の受信を示すことを SHOULD とします。

out-of-band authenticator が、primary communication channel に秘密を提示して claimant が転送する代わりに、secondary communication channel 上で承認を求める場合でも、primary channel からの秘密の転送を SHALL 受け入れ、それを secondary channel で verifier に送信して、承認を認証トランザクションと関連付けなければなりません。claimant は、この転送を手動で行っても MAY かまいませんし、バーコードや quick response (QR) code などの表現の助けを借りても MAY かまいません。

Out-of-Band Verifiers

verifier は、out-of-band authenticator との authenticated protected channel が確立されるのを待ち、その識別鍵を検証します。verifier は識別鍵自体を SHALL NOT 保存してはならず、承認済みハッシュ関数や識別鍵の所持証明などの検証方法を SHALL 使用して authenticator を一意に識別しなければなりません。認証が完了すると、verifier は認証用秘密を authenticator に送信します。out-of-band authenticator との接続は、手動で開始されても MAY かまいませんし、プッシュ通知などの仕組みにより促されても MAY かまいません。

out-of-band authenticator の種類に応じて、次のいずれかが SHALL 行われます。

• secondary から primary への秘密の転送。Fig. 1 に示すとおり、verifier は subscriber の authenticator を含むデバイスに、認証の準備ができたことを示す信号を MAY 送ってもかまいません。その後、out-of-band authenticator にランダムな秘密を SHALL 送信し、primary communication channel 経由で秘密が返されるのを待ちます。

• primary から secondary への秘密の転送。Fig. 2 に示すとおり、verifier は primary channel を介して claimant にランダムな認証用秘密を SHALL 送信しなければなりません。その後、claimant の out-of-band authenticator から secondary channel 経由で秘密が返されるのを SHALL 待たなければなりません。verifier は、claimant が応答先として使用する電話番号や VoIP アドレスなどのアドレスを追加で表示しても MAY かまいません。

いずれの場合も、認証は 10 分以内に完了しない限り SHALL 無効と見なされます。verifier は、Sec. 3.2.7 に記載の replay resistance を提供するため、所定の認証用秘密を有効期間中に一度だけ有効として SHALL 受け入れなければなりません。

verifier は、Sec. 3.2.12 に記載の承認済み乱数ビット生成器を用いて、少なくとも 6 桁の10進数（または同等）であるランダムな認証用秘密を SHALL 生成しなければなりません。認証用秘密が 64 ビット未満である場合、verifier は Sec. 3.2.2 に記載のとおり、subscriber account に対して連続する失敗した認証試行の総数を効果的に制限するレート制限機構を SHALL 実装しなければなりません。新しい認証用秘密を生成しても、失敗した認証回数は SHALL NOT リセットされません。

プッシュ通知を subscriber デバイスに送信する out-of-band verifiers は、最後に認証が成功して以降に送信されるプッシュ通知のレートまたは総数について、合理的な上限を SHOULD 実装すべきです。

PSTN に固有の追加検証要件については Sec. 3.1.3.3 を参照してください。

Authentication Using the Public Switched Telephone Network

PSTN を out-of-band 検証に使用することは、本節に記載のとおり restricted であり、Sec. 3.2.9 の要件を SHALL 満たさなければなりません。事前登録された電話番号の設定または変更は、新しい authenticator の binding と見なされ、Sec. 4.1.2 に記載のとおりにのみ SHALL 行われます。

一部の subscriber は、特に携帯電話サービスがない場合、電話のカバレッジが限られる地域で PSTN による out-of-band 認証用秘密の配信を利用できないことがあります。そのため、verifier は代替の authenticator タイプをすべての subscriber に利用可能にすることを SHALL 確保し、PSTN out-of-band authenticators を1つ以上のデバイスに binding する前に、この制約を subscriber に SHOULD 注意喚起すべきです。

verifier は、PSTN を用いて out-of-band 認証用秘密を配信する前に、リスク指標（例：デバイス入替、SIM 変更、番号ポーティング、その他の異常行動）を SHOULD 考慮すべきです。

Sec. 3.2.9 における restricted authenticators の議論と整合して、NIST は、脅威状況の変化や PSTN の技術運用の変化に基づいて、PSTN を用いた out-of-band 認証の restricted ステータスを調整する可能性があります。

Multi-Factor Out-of-Band Authenticators

Multi-factor out-of-band authenticators は、単要素 out-of-band authenticators（Sec. 3.1.3.1 参照）と同様に動作します。ただし、claimant が認証トランザクションを完了できるようにする前（すなわち、認証フローに応じて認証用秘密へアクセスまたは入力する前）に、起動要素（Password または生体特性）の提示と検証を必要とします。authenticator の各使用は、起動要素の提示を SHALL 必要とします。

authenticator の activation secrets は Sec. 3.2.10 の要件を SHALL 満たさなければなりません。生体の起動要素は、連続する認証失敗回数の制限を含む Sec. 3.2.3 の要件を SHALL 満たさなければなりません。起動に使用された Password または生体サンプル、および生体サンプルから派生した生体データ（例：指紋画像や、指紋特徴抽出器が生成した特徴点位置）は、認証操作の直後に SHALL 消去されなければなりません。

3.1.4. Single-Factor OTP

単要素 OTP は、一回限りの Password（OTP）を生成します。このカテゴリには、ハードウェアデバイスおよび、携帯電話などのデバイスにインストールされるソフトウェアベースの OTP 生成器が含まれます。これらの authenticators は、OTP 生成のシードとして使用される埋め込み秘密を持ち、第二の要素による起動を必要としません。OTP は authenticator に表示され、手動で入力して verifier に送信されることで authenticator の所持および管理を証明します。単要素 OTP authenticator は「持っているもの」です。

単要素 OTP は、Look-up secret authenticator と似ていますが、秘密が authenticator と verifier により暗号学的に独立して生成され、verifier により比較される点が異なります。秘密は、authenticator と verifier の nonce に基づいて計算され、nonce は時間ベースまたはカウンタベースである場合があります。

OTP 認証はフィッシング耐性を持ちません。OTP authenticators および verifiers の [FIPS140] 検証は必須ではありません。

Single-Factor OTP Authenticators

単要素 OTP authenticators と verifiers は、永続値を2つ保持します。1) authenticator の寿命の間持続する対称鍵、2) authenticator の各使用時に変更されるか、実時間クロックに基づく nonce です。

秘密鍵およびそのアルゴリズムは、最新改訂の [SP800-131A] に規定される最小セキュリティ強度（本書発行日時点では 112 ビット）を少なくとも SHALL 提供しなければなりません。nonce は、authenticator の寿命を通じて各操作で一意になることを確保できる十分な長さで SHALL なければなりません。subscriber がソフトウェアベース OTP authenticator を配置したデバイスを変更する必要がある場合、subscriber は Sec. 4.1.2 に記載のとおり新しいデバイス上の authenticator アプリケーションを subscriber account に SHOULD binding し、今後使用しない authenticator アプリケーションを無効化することを SHOULD とします。あるいは、subscriber は秘密鍵をエクスポートし、Appendix B.2 の要件を満たす sync fabric に格納し、新しいデバイスでその鍵を取得しても MAY かまいません。

authenticator の出力は、承認済みブロック暗号またはハッシュ関数を用いて鍵と nonce を安全に結合して得られます。verifier と協調して、authenticator はその出力を 6 桁の10進数（または同等表現）まで切り詰めても MAY かまいません。

nonce が実時間クロックに基づく場合、nonce は少なくとも 2 分に 1 回は SHALL 変更されなければなりません。

Single-Factor OTP Verifiers

単要素 OTP verifiers は、authenticator が使用した OTP を生成するプロセスを実質的に複製します。そのため、authenticator で使用される対称鍵は verifier にも存在し、鍵へのアクセスを、アクセスを必要とするソフトウェアコンポーネントのみに限定するアクセス制御により、無断開示から強固に保護されることを SHALL とします。

単要素 OTP authenticator を subscriber account に binding する際、verifier または関連する CSP は、鍵確立のために approved cryptography を SHALL 使用して鍵を生成・交換するか、authenticator 出力を複製するために必要な秘密を取得しなければなりません。

verifier は、OTP を収集する際に approved encryption および authenticated protected channel を SHALL 使用しなければなりません。verifier は、Sec. 3.2.7 に記載のとおりリプレイ耐性を提供するため、所定の OTP を有効期間中に一度だけ受け入れることを SHALL とします。OTP の重複使用により claimant の認証が拒否された場合、攻撃者が先に認証した可能性があることを claimant に警告しても MAY かまいません。verifier は、既存 session の subscriber に対して OTP の重複使用の試みを警告しても MAY かまいません。

時間ベース OTP（[TOTP]）は、authenticator の寿命を通じた時計の正負方向のドリフトの想定量に、ネットワーク遅延および claimant の OTP 入力時間の余裕を加味して決定される、定義された有効期間を SHALL 持たなければなりません。

verifier は、（authenticator 出力が 64 ビット未満の場合は）Sec. 3.2.2 に記載のとおり、subscriber account に対して失敗した認証試行の回数を効果的に制限するレート制限機構を SHALL 実装しなければならず、そうでない場合でもその実装を SHOULD とします。

4. Session Management

この節は規定（normative）です。

認証イベントが発生した後、subscriber が認証イベントを繰り返さずに、複数の後続のやり取りにわたってアプリケーションを継続利用できるようにすることが望ましい場合がよくあります。これは、認証イベントがネットワーク越しに複数のコンポーネントや当事者の連携を必然的に伴うフェデレーションのシナリオ（[SP800-63C] 参照）で特に当てはまります。

この挙動を実現するため、認証イベントに応じて session を開始しても MAY かまわず、終了されるまで継続しても MAY かまいません。session は、非活動タイムアウトや明示的なログアウトイベントなど、さまざまな理由で終了されても MAY かまいません。session は、subscriber が初回認証プロセスの一部を繰り返すか、完全な認証を行う再認証イベント（Sec. 5.2 参照）によって延長されても MAY かまいません。これにより、認証済み session が再確立されます。

session 管理は、クレデンシャルを継続的に提示し続けるより望ましいとされます。継続的提示は使い勝手が悪く、回避策（例：起動要素のキャッシュ）を誘発しやすく、その結果、認証意思が損なわれたり、認証イベントの新しさ（freshness）が不明瞭になったりするためです。

4.1. Session Bindings

session は、subscriber が実行しているソフトウェア（すなわち session subject：例：ブラウザ、アプリケーション、オペレーティングシステム）と、subscriber がアクセスしている RP または CSP（すなわち session host）の間で成立します。session secret は、subscriber のソフトウェアとアクセス先サービスの間で共有されることを SHALL とします。この秘密は session の両端を結び付け、subscriber が時間をまたいでサービスを利用し続けることを可能にします。この秘密は subscriber のソフトウェアにより直接提示されるか、または暗号メカニズムにより秘密の所持が SHALL 証明されなければなりません。

認証済み session の継続性は、認証時に session host が発行し、必要に応じて session 中に更新される session secret の所持に基づくことを SHALL とします。session の形態はアプリケーションによって異なり、例として次が挙げられます。

• “session” cookie を用いた Web ブラウザの session
• session secret を保持するモバイルアプリケーションのインスタンス

session 管理のために bearer tokens として使用される session secrets は、関連するアプリケーションの再起動や host デバイスの再起動をまたいで保持される（persistent）ものであるべきではないため、SHOULD NOT 永続的であるべきです。なぜなら、再起動はその session を終了させるためです。cookies や類似の「ブラウザを記憶する」機能は、Sec. 2.2.3 に規定される、非活動上限を超過したが時間上限は超過していない場合の AAL2 における再認証で認められる場合を除き、認証の代替として SHALL NOT 使用されてはなりません。

一部の技術（例：新興の device bound session credentials 仕様 [DBSC]）は、session secrets を bearer tokens として扱うのではなく、session secret の所持を証明する暗号プロトコルを用いることで、session secret の窃取リスクを低減します。これらの技術は、マルウェアによる持ち出しリスクを低減するため、保護されたキーストアに session secrets を保存・使用する場合もあります。こうした所持証明技法で使用される session secrets は永続化されても MAY かまいません。ただし、RP と CSP は、session secret の知識が示される場合でも、Sec. 2.2.3 に記載の session の有効期間上限が確実に適用されることを SHALL 確保しなければなりません。

session binding に使用される secret は、認証イベントに直接応答して session host により生成されることを SHALL とします。session は、その作成を引き起こした認証イベントの AAL の性質を継承することを SHOULD とします。session は、認証イベントより低い AAL と見なされても MAY かまいませんが、認証イベントより高い AAL と見なされては SHALL NOT なりません。

session binding に使用される secrets は、次のすべての要件を SHALL 満たさなければなりません。

1. secrets は、認証中または認証直後に確立される。
2. secrets は、Sec. 3.2.12 に記載の承認済み乱数ビット生成器の入力を用いて確立され、少なくとも 64 ビット長である。
3. secrets は、subscriber がログアウトしたときに session subject により消去または無効化される。
4. secrets は、authenticated protected channel を介して session host から RP または CSP に転送されるか、または有効な相互認証された protected channel の確立の一部として確立された鍵から導出される。
5. secrets は、AAL に応じて Sec. 2.1.3、Sec. 2.2.3、Sec. 2.3.3 に規定された時間でタイムアウトし、その後は受け付けられない。
6. secrets は、host と subscriber のエンドポイントの間に存在する中継者から利用できない。

加えて、session binding に使用される secrets は、subscriber がログアウトしたとき、または secret の期限切れと判断されたときに、subscriber のエンドポイント上で消去されることを SHOULD とします。これらは、クロスサイトスクリプティング（XSS）攻撃による露出の可能性があるため、（HTML5 Local Storage などの）安全でない場所に置かれるべきではなく、SHOULD NOT とします。

認証後、認証済み session は、安全でないトランスポート（例：https から http）へフォールバックしては SHALL NOT なりません。

POST/PUT の内容は、セッション識別子を含み、RP はそれを検証してクロスサイトリクエストフォージェリ（CSRF）から保護することを SHALL とします。

session を時間をまたいで管理するための仕組みはいくつか存在します。以下の節では、各種の例となる技術ごとに、異なる例・追加要件・考慮事項を示します。追加の参考情報として、Open Worldwide Application Security Project (OWASP) の Session Management Cheat Sheet（[OWASP-session]）が利用できます。

sessions は、subscriber がやり取りを完了したときに session を終了（すなわちログオフ）できる、容易にアクセス可能な仕組みを提供することを SHOULD とします。session のログオフは、特にエンドポイントが他者からアクセス可能な場合に、subscriber に追加の確信と session のセキュリティに対する制御を与えます。

4.1.1. Browser Cookies

購読者がサービスにアクセスする際、セッションを作成して追跡するための主要な仕組みはブラウザのCookieである。Cookieは認証器ではないが、セッションの継続期間における短期的な秘密情報として適している。

セッション維持に用いるCookieは、次を満たすこと：

1. セキュア（すなわちHTTPS）なセッションでのみアクセス可能となるようにタグ付けしなければならない。
2. 実務上可能な限り最小のホスト名およびパスに対してのみアクセス可能しなければならない。
3. JavaScript（すなわちHttpOnly）からアクセスできないようにタグ付けすべきである。
4. セッションの有効期間の終了時または直後に失効するようにタグ付けすべきである。この要件はCookieの蓄積を抑えることを意図しているが、セッションのタイムアウトを強制するためにこれに依拠してはならない。
5. 「__Host-」接頭辞を付け、「Path=/」を設定すべきである。
6. 「SameSite=Lax」または「SameSite=Strict」を設定すべきである。
7. 不透明な文字列（例：セッション識別子）のみを含むべきであり、平文の個人情報を含めてはならない。

4.1.2. Access Tokens

Access Token（例：OAuth [RFC6749]）は、認証イベントの後に、購読者に代わってアプリケーションが一連のサービスへアクセスできるようにするために用いられる。RPは、他のシグナルがない場合に、Access Tokenの存在を購読者の在席を示す指標として解釈してはならない。Access Tokenおよび関連するRefresh Tokenは、認証セッションが終了し、購読者がアプリケーションを離れた後も、長期間有効であり得る。

4.2. Reauthentication

セッションに対する定期的な再認証は、認証済みセッションにおける購読者の継続的な在席を確認するために実施しなければならない（例：ログアウトせずにその場を離れていないことの確認）。

セッション管理では2種類のタイムアウトを用いる。全体タイムアウト は、認証または前回の再認証から一定期間後までに、認証済みセッションの継続時間を制限する。非活動タイムアウト は、購読者からの活動が一定期間ない場合にセッションを終了させる。いずれの種類のタイムアウトについても、RPは、タイムアウトによりセッションが終了する前に、セッションがまもなく終了することを購読者に通知し、セッションをアクティブにする、または状況に応じて再認証を行う機会を購読者に与えてもよい。いずれかのタイムアウトが満了した場合、セッションは終了しなければならない。セッション上の活動は非活動タイムアウトをリセットしなければならず、セッション中に再認証が成功した場合は両方のタイムアウトをリセットしなければならない。

全体タイムアウトと非活動タイムアウトの満了上限は、セッションのAAL、セッションが行われる環境（例：購読者が制限区域内にいるかどうか）、使用されるエンドポイントの種類（例：モバイルアプリケーション、Webベース）、エンドポイントが管理対象デバイスであるかどうか、そしてアプリケーション自体の性質など、複数の要因に依存する。より高いセキュリティのセッション維持技術（例：デバイスに紐づく仕組み）を用いる場合、これらの上限を延長してもよい。各機関は、適用している非活動および全体の時間上限を、[SP800-39]で述べられているようなシステムセキュリティ計画書において定め、文書化しなければならない。各AALの詳細要件は、Sec. 2.1.3、Sec. 2.2.3、Sec. 2.3.3に示されている。

フェデレーションプロトコルとIdPを用いてRPで認証を行う場合、[SP800-63C]で述べられているとおり、セッション管理と再認証には特別な考慮が適用される。フェデレーションプロトコルは、アサーションを用いてIdPにおける認証イベントをRPへ伝達し、RPはこのアサーションの検証に成功したことに基づいて認証済みセッションを開始する。IdPとRPは互いに独立してセッションを管理し、またフェデレーションプロトコルはIdPとRP間のセッション管理を連結しないため、IdPとRPにおける購読者のセッション終了は互いに独立である。同様に、複数の異なるRPにおける購読者のセッションも、それぞれ独立に確立され、独立に終了する。

したがって、RPのセッションが満了し、RPが再認証を要求する場合でも、IdPのセッションがまだ満了しておらず、購読者を明示的に再認証することなく、IdPの当該セッションから新たなアサーションを生成できる可能性がある。IdPは認証イベントの時刻と詳細をRPに伝達できるが、再認証要件が満たされたかどうかについての最終判断はRPが担わなければならない。[SP800-63C]のSection 4.7は、フェデレーションの文脈におけるセッション管理の追加の詳細および要件を示している。

4.3. Session Monitoring

セッションモニタリング（継続的認証 と呼ばれることもある）とは、セッション中に起こり得る不正を検出するために、セッションの特性を継続的に評価することである。リスク低減策として、RPはCSPまたはIdPおよび関連する検証者と連携してセッションモニタリングを実施してもよい。セッション中に潜在的な不正が検出された場合、RPはCSP、IdP、または検証者と協調して、再認証、セッション終了、または適切な支援担当者への通知を行うべきである。評価の対象となり得るセッション特性には、次が含まれる：

• 利用パターン、速度、およびタイミング
• 行動的生体特徴（例：タイピングのリズム）
• デバイスおよびブラウザの特性（例：受理される言語）
• 位置情報
• IPアドレスの特性（例：不正利用で知られるブロック内のIPアドレスかどうか）

これらの特性の多くはプライバシー上の含意を持つ。収集、想定される購読者特性の保管、ならびにセッション特性の処理は、Sec. 7で述べられているプライバシーリスク評価に含めなければならない。

[SP800-63C]で述べられているように、RPとCSPまたはIdPの間で共有シグナリングを用いることにより、セッションモニタリングを容易にできる場合がある。

1. 管理対象デバイスには、IT担当者がそれらを発見し、維持し、制御できる管理エージェントを備えた、パーソナルコンピュータ、ノートPC、モバイルデバイス、仮想マシン、またはインフラ構成要素が含まれる。↩

5. Threats and Security Considerations

この節は参考情報である。

5.1. Authenticator Threats

攻撃者が認証器の制御を獲得できる場合、多くの場合、認証器の所有者になりすますことができる。認証器に対する脅威は、認証器を構成する認証要素の種類に対する攻撃に基づいて分類できる：

• 「知識要素（知っているもの）」は攻撃者に漏えいし得る。例えば、攻撃者がパスワードを推測することがある。認証器が共有秘密である場合、攻撃者はCSPまたは検証者にアクセスして秘密値を取得したり、その値のハッシュに対する辞書攻撃を行ったりできる。攻撃者はPINやパスコードの入力を観察したり、PINやパスコードの書き留めや日記の記録を見つけたり、悪意あるソフトウェア（例：キーボードロガー）をインストールして秘密を収集したりする可能性がある。加えて、攻撃者は、検証者が保持するパスワードデータベースに対するオフライン攻撃によって秘密を特定することもある。

• 「所持要素（持っているもの）」は、所有者によって紛失、損傷、盗難に遭う、または攻撃者によって複製され得る。例えば、攻撃者が所有者のコンピュータにアクセスできる場合、ソフトウェア認証器をコピーできることがある。ハードウェア認証器は盗難、改ざん、または複製され得る。帯域外の秘密は攻撃者により傍受され、攻撃者自身のセッションを認証するために使用され得る。購読者は、意図的な共謀がなくても、ソーシャルエンジニアリング により秘密へのアクセスを提供してしまうことがある。

• 「生体要素（本人であるもの）」は複製され得る、または偽一致が起こり得る。例えば、攻撃者が購読者の指紋の複製を入手し、レプリカを作成することがある。

購読者が攻撃者と意図的に共謀することもあり、そのような攻撃を認証の観点から防ぐためにできることはほとんどない。この注意点を踏まえ、デジタル認証に用いられる認証器に対する脅威は、いくつかの例とともにTable 3に示されている。

Table 3. Authenticator threats

Authenticator Threat/Attack	Description	Examples
Theft	攻撃者が物理的な認証器を盗む。	ハードウェア暗号認証器が盗まれる。
		OTP認証器が盗まれる。
		Look-up secret認証器が盗まれる。
		携帯電話が盗まれる。
Duplication	購読者の認証器が、本人の認識の有無にかかわらずコピーされる。	紙に書かれたパスワードが漏えいする。
		電子的ファイルに保存されたパスワードがコピーされる。
		十分に安全でないパスワードマネージャの脆弱性が悪用される。
		ソフトウェアPKI認証器（すなわち秘密鍵）がコピーされる。
		Look-up secret認証器がコピーされる。
		偽造の生体認証器が製造される。
		デバイスまたはクラウドベースの同期基盤から、輸出可能な暗号鍵が取得される。
Eavesdropping	攻撃者が、購読者が認証中に認証器の秘密または認証器の出力を観察する。	キーボード入力を覗き見してパスワードが取得される。
		キーストローク記録ソフトウェアによって、パスワードまたは認証器の出力が傍受される。
		PINパッド装置からPINが収集される。
		ハッシュ化されたパスワードが取得され、攻撃者により別の認証で使用される。
	攻撃者が通信チャネルを侵害して帯域外の秘密を傍受する。	帯域外の秘密が暗号化されていないWi-Fiで送信され、攻撃者に受信される。
Offline Cracking	認証器が、認証機構の外で分析的手法により露出する。	ソフトウェアPKI認証器に対し、秘密鍵を復号するための正しいパスワードを特定する目的で辞書攻撃が行われる。
Side-Channel Attack	認証器の物理的特性を用いて認証器の秘密が露出する。	ハードウェア暗号認証器に対する差分電力解析により鍵が抽出される。
		複数回の試行にわたる応答時間の解析により暗号認証器の秘密が抽出される。
Phishing or Pharming	攻撃者が検証者またはRPであると申請者を欺くことで、認証器の出力が取得される。	申請者が、検証者を装ったWebサイトにパスワードを開示する。
		フィッシャーが銀行を代表するふりをしたメール問い合わせに応じ、銀行の購読者がパスワードを開示する。
		DNSスプーフィングにより到達した偽の検証者Webサイトで、申請者がパスワードを開示する。
Social Engineering	攻撃者が購読者との信頼関係を構築し、認証器の秘密または認証器の出力を開示させる。	同僚が、購読者の上司の代理としてパスワードを求め、購読者がそれを開示する。
		攻撃者がシステム管理者を装った電話問い合わせにより、購読者がパスワードを開示する。
		攻撃者がモバイル事業者を説得して被害者の携帯電話を攻撃者へ転送させ、SMSで送られた帯域外の秘密を受け取る。
Authentication Fatigue	攻撃者が繰り返し認証要求を購読者へ送信し、承認させようとする。	繰り返される要求を止めるため、購読者が不正なプッシュ型認証要求を承認してしまう。
Online Guessing	攻撃者が検証者へオンラインで接続し、その検証者の文脈で有効な認証器出力を推測しようとする。	オンライン辞書攻撃によりパスワードが推測される。
		正当な購読者に登録されたOTP認証器について、オンラインで認証器出力が推測される。
Endpoint Compromise	エンドポイント上の悪意あるコードがプロキシとして機能し、購読者の同意なく接続された認証器への遠隔アクセスを可能にする。	エンドポイントに接続された暗号認証器が用いられ、遠隔の攻撃者が認証する。
	エンドポイント上の悪意あるコードが、意図された検証者以外への認証を引き起こす。	攻撃者の代理として認証が実行される。
		エンドポイント上の悪意あるアプリがSMSで送信された帯域外の秘密を読み取り、攻撃者がその秘密で認証する。
	エンドポイント上の悪意あるコードが多要素ソフトウェア暗号認証器を侵害する。	悪意あるコードが、認証器鍵のプロキシ認証またはエクスポートを行う。
Unauthorized Binding	攻撃者が、自身の制御下にある認証器を購読者アカウントへ紐づけさせる。	認証器またはプロビジョニング鍵が購読者へ届く途中で攻撃者に傍受される。
Latent Keys	廃止されたデバイスが認証鍵を保持したままである。	デバイス（例：ノートPC）が、デバイスベースの認証鍵が存在し得ることを認識しないまま売却され、新しい所有者により使用され得る。
Proliferation of Keys	デバイスベースの認証鍵をデバイス間で移転すると攻撃対象領域が拡大する。	購読者が認証鍵を多数のデバイスにコピーし、その一部は本人の直接管理下にない可能性があり、鍵の保存場所を把握できなくなる。
Key Transfer Security	認証鍵が十分に安全でないクラウドサービスを通じてデバイス間で移転される。	認証鍵を保存するクラウドサービスへのアクセスに、単一要素認証しか要求されない。
		鍵が、メールで送られたURLを通じて他者に提供される。
Untrusted Devices	認証鍵が、十分な保護を提供しないデバイス上に常駐する。	同期基盤を通じて、鍵が安全でないデバイスへ移転される。
Insider Threats	信頼された内部者が信頼に値しないことが判明する。	CSP（例：カスタマーサポート担当者）にアクセスできる内部者が攻撃者と共謀し、購読者アカウントへのアクセスを与える。

5.2. Threat Mitigation Strategies

Table 4は、Table 3に記載された脅威の軽減に役立つ関連メカニズムを要約している。

Table 4. Mitigating authenticator threats

Authenticator Threat/Attack	Threat Mitigation Mechanisms	Normative Reference Sections
Theft	パスワードまたは生体特徴を通じて有効化しなければならない多要素認証器を使用する。	2.2.1, 2.3.1
	パスワードまたは生体特徴を含む認証器の組み合わせを使用する。	2.2.1, 2.3.1
Duplication	長期の認証秘密を抽出・複製することが困難な認証器を使用する。	2.2.2, 2.3.2, 3.1.6.1
	輸出された認証鍵を含む同期基盤へのアクセスにAAL2要件を適用し、それらを信頼できるデバイスにのみ取り込むことを許可する。	3.1.7.1
Eavesdropping	特にマルウェア（例：キーロガー）が存在しないことという観点で、利用前にエンドポイントの安全性を確保する。	2.2.2
	帯域外の認証器秘密を、認証されておらず暗号化もされていない通信チャネルで送信することを避ける。	3.1.3.1
	認証済みで保護されたチャネル上で認証する（例：ブラウザウィンドウのロックアイコンを確認する）。	2.1.2, 2.2.2, 2.3.2
	リプレイ攻撃への耐性を持つ認証プロトコルを使用する（例：pass-the-hash）。	3.2.7
	信頼できる入力および表示機能を備えた認証エンドポイントを使用する。	3.1.6.1, 3.1.7.1
Offline Cracking	高いエントロピーを持つ認証器秘密を備えた認証器を使用する。	3.1.2.1, 3.1.4.1, 3.1.5.1, 3.1.6.1, 3.1.7.1
	一元的に検証されるパスワードを、キー付きハッシュを含むソルト付きハッシュ形式で保存する。	3.1.1.1.2
Side-Channel Attack	秘密値に関係なく、一定の消費電力およびタイミングを維持する認証器アルゴリズムを使用する。	2.3.2
Phishing or Pharming	フィッシング耐性を提供する認証器を使用する。	3.2.5
Social Engineering	第三者（例：カスタマーサービス担当者）に対してソーシャルエンジニアリングのリスクを生じさせる認証器の使用を避ける。	4.1.2.1, 4.2
Authentication Fatigue	承認ではなく、OOB認証のために認証秘密の転送を要求する。	3.1.3
Online Guessing	高エントロピーの出力を生成する認証器を使用する。	3.1.2.1, 3.1.6.1, 3.1.7.1
	繰り返しの有効化失敗の後にロックする認証器を使用する。	3.2.2
Endpoint Compromise	申請者による物理的な動作を要求するハードウェア認証器を使用する。	3.2.8
	制限されたアクセス制御を伴う保管領域にソフトウェアベースの鍵を保持する。	3.1.3.1, 3.1.6.1, 3.1.7.1, 3.2.13
Unauthorized Binding	認証された保護チャネルを用いるか対面で、認証器と関連鍵をプロビジョニングする。	4.1
Latent Keys	デバイスベースの認証鍵を含む機器を安全に廃棄することを確実にする。	4.4, 4.5
	連邦エンタープライズ向けアプリケーションでは、組織が管理する、または信頼できるデバイスへの鍵の移転を制限する。	B.2
Key Transfer Security	鍵の保管と移転のために承認されたクラウドサービスの利用を、購読者に推奨または要求する。	B.2

Table 4に示された脅威を軽減するために、他にもいくつかの戦略を適用できる：

• 複数の要素 により攻撃成功がより困難になる。攻撃者が暗号認証器を盗み、さらにパスワードを推測しなければならない場合、両要素を見つけ出すための労力が大き過ぎる可能性がある。
• 物理的セキュリティ機構 により、盗まれた認証器の複製を防ぐことができる。物理的セキュリティ機構は、改ざんの痕跡、検知、対応を提供し得る。
• 長いパスワードの要求 により、一般的な辞書に載っていない値を求め、攻撃者にあらゆる候補値を試させることになる可能性がある。
• システムおよびネットワークのセキュリティ制御 により、攻撃者がシステムへアクセスしたり、悪意あるソフトウェアをインストールしたりすることを防止できる。
• 定期的な訓練 により、購読者が侵害または侵害の疑いをいつどのように報告すべきかを理解し、攻撃者が認証プロセスを侵害しようとしていることを示す行動パターンを認識できるようにする。
• 帯域外手法 により、登録済みデバイス（例：携帯電話）の所持証明を検証できる場合がある。

5.3. Authenticator Recovery

多くの認証機構における弱点は、購読者が1つ以上の認証器の制御を失い、それらを置き換える必要がある場合に従うプロセスである。多くの場合、購読者を認証するための選択肢は限られており、経済的な懸念（例：コールセンター維持コスト）が、安価でしばしば安全性の低いバックアップ認証方式の利用を促す。認証器の回復が人手を伴うほど、ソーシャルエンジニアリング攻撃もリスクをもたらす。

認証要素の完全性を維持するためには、ある認証要素が、別の要素の認証器を取得するために利用されないことが不可欠である。例えば、パスワードが、新しいLook-up secretの一覧を取得するために使用されてはならない。

5.4. Session Attacks

認証イベントに続くセッションに対するハイジャック攻撃は、同様のセキュリティ影響を持ち得る。Sec. 5のセッション管理ガイドラインは、（例：XSSのような）攻撃に対するセッションの完全性維持に不可欠である。また、表示されるすべての情報をサニタイズし、実行可能な内容が含まれないことを確実にすることも重要である [OWASP-XSS-prevention]。これらのガイドラインは、セッション秘密をモバイルコードからアクセス不能にし、セッション秘密の持ち出しに対して追加の保護を提供することを推奨している。

認証後の別の脅威はCSRFであり、ユーザが同時に複数のセッションをアクティブにしている傾向を悪用する。意図せず、または悪意をもって有効化される有効なURLやリクエストを防ぐため、Webリクエストにセッション識別子を埋め込み、検証することが不可欠である。

6. Privacy Considerations

この節は参考情報である。

6.1. Privacy Risk Assessment

Sec. 2の認証要件と、Sec. 5.3の任意のセッションモニタリング指針は、記録保持に関するプライバシーリスク評価をCSPが実施することを求める。そのようなプライバシーリスク評価には、次の評価が含まれ得る：

• 信頼の喪失など、記録保持が購読者のプライバシー問題を生じさせ得る可能性
• そのような問題が発生した場合の影響

CSPは、特定されたプライバシーリスクに対するいかなる対応（受容、軽減、リスク共有を含む）についても、合理的に正当化できるべきである。購読者の同意はリスク共有の一形態であり、したがって購読者が共有されるリスクを評価し、受け入れる能力を持つと合理的に期待できる場合にのみ適切である。

6.2. Privacy Controls

Section 2.4.3は、CSPに対して、適切に調整されたプライバシー制御を適用することを要求する。[SP800-53]は、CSPが認証機構を導入する際に検討すべき、通知、救済、その他の重要な考慮事項を含むプライバシー制御の一式を提供している。これらは、信頼に値する導入を成功させるために重要である。

6.3. Use Limitation

Section 2.4.3は、CSPに対して、予測可能性（すなわち、個人・所有者・運用者が、情報システムによる個人情報の処理について信頼できる想定を行えるようにすること）と、管理可能性（個人情報の変更、削除、選択的開示を含む、個人情報のきめ細かな管理を行う能力を提供すること）の目的を維持することを要求する。これは、本人確認、認証、認可、属性アサーション、または関連する不正抑止、あるいは法令または法的手続の遵守以外の目的で属性を処理することから生じ得るプライバシーリスクに見合うものでなければならない [NISTIR8062]。

CSPは、購読者に非アイデンティティサービスを提供することを含め、属性を処理するさまざまな事業目的を持ち得る。しかし、収集時に特定された目的以外で属性を処理すると、プライバシーリスクを生じ得る。CSPは、追加の処理から生じるプライバシーリスクに見合う適切な対策を特定できる。例えば、適用される法令、規制、またはポリシーがない場合、購読者が要求した非アイデンティティサービスを提供するために属性を処理する際、同意の取得が必須でないこともあり得る。しかし、通知は、購読者が処理について信頼できる想定（すなわち予測可能性）を維持する助けとなり得る。属性の他の処理は、同意の取得や、特定の属性の利用または開示に関する購読者のより大きなコントロールを可能にする（すなわち管理可能性）ことを求める別のプライバシーリスクを伴い得る。購読者の同意は実質的でなければならない。したがって、Sec. 2.4.3に述べられているとおり、CSPが同意の手段を用いる場合、追加利用の受諾を認証サービス提供の条件としてはならない。

提案された処理が許容される処理の範囲外に当たるかどうか、または適切なプライバシーリスク軽減策について疑問がある場合は、SAOPに相談すること。

6.4. Agency-Specific Privacy Compliance

Section 2.4.3は、連邦CSPに対する特定の遵守義務を説明している。デジタル認証システム開発の最も早い段階からSAOPを関与させることが重要である。これは、プライバシーリスクを評価し軽減し、また、認証器の発行や維持のための個人情報収集が、Privacy Act of 1974 [PrivacyAct]または E-Government Act of 2002 [E-Gov]のPIA実施要件を発動させるかどうか等、機関の遵守要件について助言を得るためである。例えば、生体情報の集中管理に関しては、個人情報および認証に必要な他の属性の収集・維持により、Privacy Act要件が発動し、新規または既存のPrivacy Act SORNの対象となる可能性が高い。SAOPは同様に、PIAが必要かどうかの判断を機関に支援できる。これらの考慮事項は、認証のためだけにPrivacy Act SORNやPIAを策定する要件として読まれるべきではない。多くの場合、PIAおよびSORNはデジタルIDプロセス全体を包含でき、また、オンラインサービスまたは給付を確立する機関について議論する、より大きなプログラム上のPIAの一部としてデジタル認証プロセスを含めることもできる。

デジタル認証は多数の構成要素から成るため、SAOPは各構成要素を把握し理解している必要がある。例えば、フェデレーテッドなCSPまたはRPサービスを提供または利用する機関には、他のプライバシー成果物（例：Data Use Agreements、Computer Matching Agreements）が適用される場合がある。SAOPは、どの追加要件が適用されるかの判断を機関に支援できる。さらに、デジタル認証の各構成要素を十分に理解することで、SAOPは遵守プロセスやその他の手段を通じてプライバシーリスクを評価し軽減できる。

7. Customer Experience Considerations

この節は参考情報である。

ユーザ中心設計、顧客体験、ユーザビリティに関する標準用語に合わせるため、本節では「user」という用語を人間の当事者を指すために用いる。多くの場合、ここで言うuserは、申請者、申告者、または購読者の役割における主体となる。顧客体験は、ユーザビリティ、アクセシビリティ、選択可能性の接点に位置する。ユーザのニーズを考慮することで、組織は不要な摩擦や不満を最小化しつつ、応答性と安全性を備えたIDソリューションを提供できる。

7.1. Usability

[ISO/IEC9241-11]は、ユーザビリティを「指定されたユーザが、指定された利用状況の文脈において、指定された目標を有効性、効率性、満足度をもって達成するために、システム、製品、またはサービスを使用できる程度」と定義している。この定義は、有効性、効率性、満足度、およびユーザビリティを達成するために必要な主要要素として、ユーザ、その目標、利用状況の文脈に焦点を当てている。

ユーザが情報システムへアクセスする際の目標は、意図したタスクを実行することである。認証は、この目標を可能にする機能である。しかしユーザの観点では、認証はユーザと意図したタスクの間に存在する。認証プロセスを効果的に設計・実装することで、正しいことは容易に、誤ったことは困難に、そして誤ったことが起きても回復しやすくなる。

組織は、ステークホルダ全体のデジタル認証エコシステムが持つ全体的な影響を認識する必要がある。ユーザはしばしば、異なるRPごとに複数の認証器を利用する。その結果、パスワードを覚え、どの認証器がどのRPに対応するかを思い出し、複数の物理的認証デバイスを持ち歩くことに苦労する。認証のユーザビリティを評価することは重要である。というのも、ユーザビリティが低いと、対処行動や意図しない回避策が生まれ、最終的にセキュリティ制御の有効性を損なうことが多いからである。

開発プロセスにユーザビリティを組み込むことで、ユーザの認証ニーズと組織の事業目標の双方に対応しながら、安全で使いやすい認証ソリューションにつながり得る。適切なAALを決定する際のリスク評価の一部として、デジタルシステム全体にわたるユーザビリティの影響を考慮する必要がある。より高いAALの認証器は、場合によってはより良いユーザビリティを提供するため、より低いAALのアプリケーションでも利用を許可すべきである。

認証にフェデレーションを活用すると、多くのユーザビリティ問題を軽減できるが、[SP800-63C]で述べられているとおり、そのアプローチにはトレードオフがある。

本節は一般的なユーザビリティの考慮事項と実装例を示すが、特定のソリューションを推奨するものではない。言及された実装は、特定のユーザビリティニーズに対処する革新的な技術的アプローチを促す例である。さらに、ユーザビリティの考慮事項と実装は多くの要因に左右され、万能の解決策を妨げる。例えば、デスクトップ環境で適切なフォントサイズでも、小型のOTP認証器画面ではテキストがはみ出してスクロールが必要になるかもしれない。選定した認証器のユーザビリティ評価を実施することは、実装における重要な要素である。代表的なユーザで評価を行い、現実的な目標とタスクを設定し、適切な利用状況の文脈を特定することが重要である。

ガイドラインと考慮事項はユーザの観点から述べる。

1973年のRehabilitation ActのSection 508 [Section508]は、情報技術における障壁を取り除き、連邦機関に対して、障害のある人々に電子的・情報技術へのアクセス可能性を確保することを求めるために制定された。これらのガイドラインはSection 508の要件を直接主張するものではないが、IDサービス提供者はSection 508の規定に準拠することが期待される。Section 508への準拠に加えて、連邦機関とそのサービス提供者は、IDシステムのライフサイクル全体を通じてアクセシビリティが優先されるよう、障害のある人々の体験を念頭に置いてサービスとシステムを設計することが一般に期待される。

7.1.1. Common Usability Considerations for Authenticators

認証システムを選定し実装する際は、ユーザ、その目標、利用状況の文脈に留意しつつ、選定した認証器の全ライフタイム（例：通常の利用および断続的な事象）にわたるユーザビリティを考慮すること。

単一の認証器タイプが、通常は全ユーザ集団に十分であることはない。したがって、可能な限り、かつAAL要件に基づき、CSPは代替となる認証器タイプを支援し、ユーザが自身のニーズに最も合うタイプを選べるようにすべきである。タスクの即時性、費用対効果に関する認識、特定の認証器への不慣れさは、選択に影響することが多い。ユーザは、その時点で負担やコストが最小となる選択肢を選びがちである。例えば、情報システムへの即時アクセスが必要なタスクでは、より多くの手順を要する認証器を選ぶよりも、新しい購読者アカウントとパスワードを作成することを好むかもしれない。別の例として、ユーザが既にIdentity Providerの購読者アカウントを持っている場合、適切なIAL、AAL、および federation assurance level（FAL）で承認されたフェデレーテッドなID選択肢を選ぶこともある。ユーザは認証器の理解度がそれぞれ異なり、その理解と経験に基づく信頼の程度も異なり得る。

望ましい事業成果を得るには、良好なユーザ認証体験が不可欠である。したがって、組織はユーザの観点から認証器を考慮するよう努めるべきである。包括的な認証ユーザビリティ目標は、ユーザ負担と認証摩擦（例：ユーザが認証しなければならない回数、関与する手順、追跡しなければならない情報量）を最小化することである。Single sign-on（SSO）は、そのような最小化戦略の一例である。

大半の認証器に適用できるユーザビリティ上の考慮事項には、次が含まれる：

• 認証器の利用と保守（例：認証器を紛失・盗難された場合にどうするか）および利用手順に関する情報を提供する。特に、初回利用や初期化に異なる要件がある場合は手順を示す。

• ユーザは認証器をすぐに利用できる状態にしておく必要があることを忘れないようにしなければならない。元の認証器の紛失、損傷、その他の悪影響や、（該当する場合）電池切れの可能性に備えるため、代替の認証選択肢の必要性を考慮する。

• AAL要件に基づく代替の認証選択肢により、ユーザは文脈、目標、タスク（例：頻度や即時性）に応じて認証器を選べる。代替の認証選択肢は、特定の認証器で生じ得る可用性の問題にも対処する助けとなる。

• ユーザ向けテキストの特性を考慮する：
  • ユーザ向けテキスト（例：手順、プロンプト、通知、エラーメッセージ）は、想定読者に向けて平易な言葉で書く。専門用語を避け、読者の期待されるリテラシー水準に合わせて書く。
  • ユーザ向け表示テキストおよびユーザ入力テキストの可読性（フォントの種類、サイズ、色、周囲の背景とのコントラストを含む）を考慮する。読めないテキストは入力誤りの原因となる。可読性を高めるため、次の利用を検討する：
    • 高コントラスト（すなわち白地に黒）
    • 電子表示にはサンセリフ体、印刷物にはセリフ体
    • 混同されやすい文字（例：大文字の「O」と数字のゼロ「0」）を明確に区別できるフォント
    • デバイスの表示領域に収まる限り、最小12ポイントのフォントサイズ
  • ブラウザのセキュリティ指標と混同され得るアイコン（例：南京錠や盾）を使用しない。
• 認証器入力時のユーザ体験を考慮する：
  • 入力中にテキストを表示する選択肢を提供する。マスクされたテキスト入力は誤りが起きやすい。ある文字がユーザに見えるのに十分な時間表示されたら、その後は隠してよい。モバイルデバイス（例：タブレットやスマートフォン）では従来のデスクトップコンピュータよりパスワード入力に時間がかかるため、マスク解除の遅延時間を決める際はデバイスを考慮する。マスク解除の時間はユーザのニーズに整合するよう一貫させる。
  • テキスト入力に許される時間が十分であることを確保する（すなわち入力画面が早過ぎるタイムアウトにならない）。入力に許される時間はユーザのニーズに整合するよう一貫させる。
  • 入力誤りに対して明確で意味があり行動可能なフィードバックを提供し、ユーザの混乱や不満を減らす。ユーザがテキストを誤って入力したことを知る手段がない場合、重大なユーザビリティ上の問題が生じる。
  • ユーザによる認証器出力の入力が必要な認証器では、少なくとも10回の入力試行を許可する。入力テキストが長く複雑であるほど、入力誤りが起きる可能性が高い。
  • 残りの許可試行回数を、明確で意味のある形で通知する。レート制限（すなわちスロットリング）では、次の試行までに待つ必要がある時間をユーザに知らせる。
• モバイルデバイスにおけるタッチ領域や表示領域の制約など、フォームファクタ制約の影響を最小化する：
  • 大きいタッチ領域は、テキスト入力のユーザビリティを改善する。小型デバイスでのタイピングは、入力機構（例：指）のサイズが画面上ターゲットのサイズに対して相対的に大きいため、フルサイズキーボードよりも誤りが多く、時間もかかる。
  • 小型表示に適した良いユーザインタフェースおよび情報設計に従う。

認証器タイプをまたいで断続的な事象（例：再認証、購読者アカウントのロックアウト、失効、取り消し、損傷、紛失、盗難、ソフトウェアの不具合）に関するユーザビリティ上の考慮事項には、次が含まれる：

• 非活動タイムアウトが発生しなければならない時刻の直前（例：2分前）に、何らかの活動を行うようユーザに促す。

• ユーザの活動にかかわらず、固定の再認証タイムアウトが発生する前に、作業を保存するようユーザに促す。

• 技術支援を得る方法と場所を明確に伝える（例：オンラインのセルフサービス機能へのリンク、チャットセッション、またはヘルプデスク支援の電話番号を提供する）。理想的には、外部介入なしに断続的な事象から回復できるよう、十分な情報を提供する。

• 購読者がセッションを終了できる（すなわちログオフできる）アクセス可能な手段を提供する。

以降の節では、特定の認証器に固有のユーザビリティ考慮事項を述べる。

7.1.2. Usability Considerations by Authenticator Type

以下の節では、特定の認証器タイプに固有のその他のユーザビリティ考慮事項を述べる。

Passwords

Typical Usage

ユーザはしばしばパスワード（パスフレーズまたはPINとも呼ばれる）を手動で入力する。別の方法として、パスワードマネージャを利用して安全なパスワードを選び、認証対象サービスごとに異なるパスワードを維持することもある。異なるパスワードを用いることは、「password stuffing」攻撃（攻撃者があるサイトで漏えいしたパスワードを別サイトで用いてユーザアカウントへアクセスする攻撃）を避けるために重要である。機関は、推奨または義務付けを行う前にパスワードマネージャを慎重に評価し、安全な実装に対する期待を満たしていることを確認すべきである。

パスワードマネージャなしの通常利用に関するユーザビリティ考慮事項：

• パスワードの覚えやすさ
  • 覚えておく項目が多いほど、思い出せない可能性は高まる。パスワード数が少ないほど、特定のRPに必要なパスワードを思い出しやすくなる。
  • 利用頻度が低いパスワードほど、記憶の負担は大きい。

パスワードマネージャありの通常利用に関するユーザビリティ考慮事項：

• 入力の容易さ
  • パスワードマネージャから秘密を安全に取り出せるよう、オートフィル機能を支援する。
  • パスフレーズを含むパスワード入力欄で、コピー＆ペースト機能を支援する。

Intermittent Events

断続的な事象に関するユーザビリティ考慮事項：

• ユーザがパスワードを作成・変更する場合
  • パスワードの作成・変更方法に関する情報を明確に伝える。
  • Sec. 3.1.1で規定されるパスワード要件を明確に伝える。
  • パスフレーズの利用を支援するため、長さを少なくとも64文字まで許可する。ユーザが望むだけ長いパスワードを作り、（空白を含む）任意の文字を用いて記憶を助けられるよう促す。ユーザインタフェースが十分な長さのパスワードを支援していることを確保する。
  • パスワードに対して他の構成規則（例：異なる文字種の混在）を課さない。
  • ユーザの要求または認証器侵害の証拠がない限り、パスワードの恣意的（例：定期的）な変更を要求しない（Sec. 3.1.1参照）。
• 選択したパスワードが拒否された場合（例：受け入れられないパスワードの「blocklist」に含まれる場合や、以前使用された場合）に、明確で意味があり行動可能なフィードバックを提供する。

Look-Up Secrets

Typical Usage

購読者は、印刷された、または電子的な認証器を用いて、検証者のプロンプトに応答するために必要な適切な秘密を参照する。例えば、ユーザは、表形式のカードに印刷された数値または文字列の特定の部分集合を提供するよう求められることがある。

通常利用に関するユーザビリティ考慮事項は次のとおり：

• Look-up secret入力時のユーザ体験
  • プロンプトの複雑さとサイズを考慮する。より大きな部分集合の秘密を参照するよう促される場合、ユーザビリティ上の影響は大きくなる。認知負荷と、入力に伴う物理的な難しさの双方を考慮すべきである。

Out-of-Band

Typical Usage

Out-of-band認証は、ユーザが一次および二次の通信チャネルにアクセスできることを要求する。

通常利用に関するユーザビリティ考慮事項は次のとおり：

• ロック可能なデバイス上で秘密を受領したことをユーザに通知する。Out-of-bandデバイスがロックされている場合、秘密にアクセスするには当該デバイスへの認証を要求すべきである。

• 実装によっては、フォームファクタ制約を考慮する。これは、ユーザがモバイルデバイス上でテキストを入力しなければならない場合に特に問題となる。より大きいタッチ領域を提供すると、モバイルデバイスで秘密を入力するユーザビリティが改善する。

• モバイルデバイスでのテキスト入力を要しない機能（例：コピー＆ペースト機能）の提供を検討する。一次・二次チャネルが同一デバイス上にある場合に特に有用である。例えば、スマートフォンで認証秘密を手動で移すのは困難である。なぜならユーザは、Out-of-bandアプリケーションと一次チャネルの間を（場合によっては複数回）行き来して切り替える必要があるからである。

• Out-of-bandデバイスへのメッセージや通知には、アクセスしているサービス名など、ユーザにとっての文脈情報を含めるべきである。

• Out-of-bandメッセージは、一貫した方法とスタイルで配信し、購読者が潜在的に不審な認証要求を識別できるようにすべきである。

Single-Factor OTP

Typical Usage

ユーザはSingle-Factor OTP認証器が生成するOTPにアクセスする。認証器の出力は通常、認証器上に表示され、ユーザは認証対象のセッション中にそれを入力する。

通常利用に関するユーザビリティ考慮事項は次のとおり：

• 認証器の出力は、変化の間隔を少なくとも1分とし、Sec. 3.1.4.1で規定されるとおり、理想的には丸2分をユーザに与える。ユーザは、Single-Factor OTP認証器と入力画面を見比べながら、認証器出力を入力するための十分な時間を必要とする。

Multi-Factor OTP

Typical Usage

ユーザはMulti-Factor OTP認証器が生成するOTPに、第二の認証要素を通じてアクセスする。OTPは通常デバイス上に表示され、ユーザは認証対象のセッション中にそれを手動で入力する。第二の認証要素は、パスワード入力のための一体型入力パッド、または一体型の生体要素（例：指紋）リーダによって実現され得る。追加要素に関するユーザビリティ考慮事項も適用される（パスワードについてはSec. 8.1.2.1、Multi-Factor認証器で用いられる生体情報についてはSec. 8.1.4参照）。

通常利用に関するユーザビリティ考慮事項：

• 認証器出力の手動入力時のユーザ体験
  • 時刻ベースOTPでは、OTPが表示される期間に加えて猶予期間を設ける。ユーザは、Multi-Factor OTP認証器と入力画面を見比べながら、認証器出力を入力するための十分な時間を必要とする。
  • ユーザが、一体型入力パッドでMulti-Factor OTP認証器をアンロックする必要がある場合、またはモバイルデバイス上で認証器出力を入力しなければならない場合には、フォームファクタ制約を考慮する。小型デバイスでのタイピングは、従来のキーボードよりも誤りが多く時間もかかる。より大きいタッチ領域を提供すると、Multi-Factor OTP認証器のアンロックやモバイルデバイス上での認証器出力入力のユーザビリティが改善する。

Single-Factor Cryptographic Authenticator

Typical Usage

ユーザは暗号鍵の所持と制御を証明することで認証する。

通常利用に関するユーザビリティ考慮事項は次のとおり：

• ユーザにとって意味があり、どの暗号鍵をどの認証タスクに使うべきかを認識し想起できるよう、暗号鍵に適切で説明的な名前を付ける。これにより、似通って曖昧な名前の暗号鍵が複数あることによる負担を避けられる。小型のモバイルデバイス上で複数の暗号鍵から選択することをユーザに求める場合、画面サイズの制約で暗号鍵名が短縮されると、特に問題となり得る。

• 物理的な入力（例：ボタン押下）を求めるSingle-Factor暗号認証器は、ユーザビリティ上の困難をもたらし得る。例えば、USBポートがコンピュータの背面にある場合、ユーザがポートに手を伸ばすのが難しいことがある。

• 接続型認証器では、直接のコンピュータ接続（例：USBポート）の利用可能性が限られていることが、ユーザビリティ上の困難をもたらし得る。例えば、ノートPCはUSBポートの数が限られていることが多く、認証器を利用するために他のUSB周辺機器を抜かざるを得ない場合がある。

Multi-Factor Cryptographic Authenticator

Typical Usage

認証するために、ユーザは暗号鍵の所持と制御、ならびに有効化要素の制御を証明する。追加要素に関するユーザビリティ考慮事項も適用される（パスワードについてはSec. 8.1.2.1、活性化要素として用いられる生体情報についてはSec. 8.1.4参照）。

通常利用に関するユーザビリティ考慮事項は次のとおり：

• ユーザにとって意味があり、どの暗号鍵をどの認証タスクに使うべきかを認識し想起できるよう、暗号鍵に適切で説明的な名前を付ける。これにより、似通って曖昧な名前の暗号鍵が複数あることによる負担を避けられる。小型のモバイルデバイス上で複数の暗号鍵から選択することは、画面サイズの制約で暗号鍵名が短縮される場合、特に問題となり得る。

• 認証後に外付けのMulti-Factor暗号認証器を接続したままにすることをユーザに要求しない。ユーザは、作業を終えた後に認証器を外すのを忘れることがある（例：スマートカードをカードリーダに挿したまま席を離れる）。
  • 認証器を接続したままである必要があるかどうかをユーザに知らせる必要がある。
• 接続型認証器では、直接のコンピュータ接続（例：USBポート）の利用可能性が限られていることが、ユーザビリティ上の困難をもたらし得る。例えば、ノートPCはUSBポートの数が限られていることが多く、認証器を利用するために他のUSB周辺機器を抜かざるを得ない場合がある。

7.1.3. Summary of Usability Considerations

Figure 3は、各認証器タイプについて、通常利用および断続的な事象に関するユーザビリティ考慮事項を要約している。通常利用に関するユーザビリティ考慮事項の多くは、行に示されているとおり、ほとんどの認証器タイプに適用される。表は、認証器タイプ間の共通および相違するユーザビリティ特性を強調している。各列により、読者は各認証器に対して対処すべきユーザビリティ属性を容易に識別できる。ユーザの目標と利用状況の文脈によっては、特定の属性が他よりも重視される場合がある。可能な限り、代替の認証器タイプを提供し、ユーザがそれらの間で選べるようにすること。

Multi-factor認証器（例：Multi-factor OTP）は、その活性化要素のユーザビリティ考慮事項も引き継ぐ。生体情報はMulti-factor認証ソリューションにおける活性化要素としてのみ許可されるため、生体情報のユーザビリティ考慮事項はFig. 3には含まれておらず、Sec. 8.1.4で議論される。

Fig. 3 Usability considerations by authenticator type

（認証器タイプごとに、どのユーザビリティ考慮事項が適用されるかを示す表）

7.1.4. Usability Considerations for Biometrics

本節は、生体情報の一般的なユーザビリティ考慮事項を高いレベルで概観する。生体情報のユーザビリティに関するより詳細な議論は、Usability & Biometrics, Ensuring Successful Biometric Systems [UsabilityBiometrics]に記載されている。

ユーザがデバイスに慣れ、練習することで、すべてのモダリティの性能が向上する。デバイスのアフォーダンス（すなわち、ユーザが行動を実行できるようにするデバイスの特性）、フィードバック、明確な手順は、生体デバイスを用いたユーザの成功にとって重要である。例えば、ライブネス検知に必要な行動について明確な手順を提供する。理想的には、ユーザは第二の認証要素として最も快適に感じるモダリティを選べる。ユーザ集団によっては、ある生体モダリティの方が他よりも快適で、馴染みがあり、受容しやすい場合がある。残りの許可試行回数に関する意味のあるフィードバックを提供する。例えば、レート制限（すなわちスロットリング）については、次の試行までに待つ必要がある時間をユーザに知らせる。

Typical Usage

認証で最も一般的に用いられる生体モダリティは、指紋、顔の比較、虹彩の比較の3つである。

• 指紋に関するユーザビリティ考慮事項：
  • ユーザは、初回登録でどの指を用いたかを覚えておく必要がある。
  • 指の湿り気の量は、センサが成功裏に取得できるかに影響する。
  • 指紋取得品質に影響する追加要因には、年齢、性別、職業（例：化学薬品を扱う、または手を多用する仕事のユーザは摩擦隆線が劣化している可能性がある）が含まれる。
• 顔の比較に関するユーザビリティ考慮事項：
  • 登録時に（例：眼鏡などの）付属物を着用していたかどうかをユーザが覚えておく必要がある。これは顔認識精度に影響する。
  • 環境の照明条件の違いは、顔認識精度に影響し得る。
  • 表情は顔認識精度に影響する（例：笑顔と無表情）。
  • 顔の向きは顔認識精度に影響する（例：カメラに対して下を向く、または視線を外す）。
• 虹彩の比較に関するユーザビリティ考慮事項：
  • カラーコンタクトの着用は、虹彩認識精度に影響し得る。
  • 眼の手術を受けたユーザは、手術後に再登録が必要になる場合がある。
  • 環境の照明条件の違いは、特定の虹彩色では特に、虹彩認識精度に影響し得る。

Intermittent Events

生体情報はMulti-factor認証の第二要素としてのみ許可されるため、一次要素に関する断続的な事象のユーザビリティ考慮事項は引き続き適用される。生体情報を用いた認識精度に影響し得る断続的な事象には、次が含まれる：

• 指紋の劣化または指のけが
• 汚れた手、乾いた手、濡れた手
• 手袋やマスクの着用
• 時間経過に伴う自然な顔貌変化や体重変化
• 眼の手術

すべての生体モダリティに共通する断続的な事象のユーザビリティ考慮事項は次のとおり：

• 代替の認証方法がすぐに利用でき、かつ明確に伝達されていなければならない。ユーザに生体認証を試みることを決して強制してはならず、代替の第二要素としてパスワードの利用を許可すべきである。
• 技術支援のための備えが必要である：
  • 技術支援を得る方法と場所を明確に伝える。例えば、オンラインのセルフサービス機能へのリンクや、ヘルプデスク支援の電話番号をユーザに提供する。理想的には、外部介入なしに断続的な事象から回復できるよう、十分な情報を提供する。
  • 生体センサの感度に影響し得る要因（例：センサの清潔さ）をユーザに知らせる。

7.2. Customer Success Considerations

顧客体験の主要な側面は、ユーザ集団のニーズを予測し、その集団に適した認証器の選択肢を提供することである。認証器の適合性に関する問題の例をいくつか示す：

• SMSベースのOut-of-band認証は、携帯電話サービスのない地方の購読者にとって利用できない場合がある。
• OTP認証器は、視覚に問題のある購読者には読み取りが困難な場合がある。
• 音声通話で送られるOut-of-band認証秘密は、聴覚に問題のある購読者には聞き取りが困難な場合がある。
• 一部の顔照合アルゴリズムは、すべてのユーザ集団に対して同等に良好な性能を示さない場合がある。
• 一部の購読者は、指の欠損、指紋の劣化（例：化学薬品を扱う、または手を多用することによる）、または巧緻性の問題など、指紋収集を妨げる状態を持つ場合がある。
• ハードウェアベースの認証器の費用が、一部の購読者にとって負担しきれない場合がある。
• 移動や巧緻性に関する身体障害を持つ購読者にとって、パスワードの正確な手動入力が困難な場合がある。
• 特定の認証器タイプは、知的、発達、学習、または神経認知上の困難を持つ購読者にとって難しい場合がある。
• 低所得の購読者は、特定の認証方式で必要となる最新のデバイスを持っていない可能性が高い。
• 技術スキルが低い購読者は、あるデバイスから別のデバイスへOTPコードを入力する際に支援が必要になる場合がある。
• 一部の認証器の小さなフォームファクタは、高齢者や巧緻性に課題のある人々など、特定のユーザにとって困難となり得る。

CSPはこの分野で一般的かつ想定される問題を軽減することが求められているが、アプリケーションによって異なり得るすべての潜在的な顧客体験問題を予測することは現実的ではない。したがって、CSPは、購読者が認証要件に関する課題を報告できる仕組みを提供し、潜在的な代替認証戦略について助言する必要がある。

References

この節は参考情報である。

[Blocklists] Habib H, Colnago J, Melicher W, Ur B, Segreti S, Bauer L, Christin N, Cranor L (2017) Password Creation in the Presence of Blacklists. Proceedings 2017 Workshop on Usable Security (Internet Society, San Diego, CA). https://doi.org/10.14722/usec.2017.23043

[CMVP] National Institute of Standards and Technology (2025), Cryptographic Module Validation Program. Available at https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program

[Composition] Komanduri S, Shay R, Kelley PG, Mazurek ML, Bauer L, Christin N, Cranor LF, Egelman S (2011) Of Passwords and People: Measuring the Effect of Password-Composition Policies. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (ACM, New York, NY), pp 2595–2604. Available at https://www.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwords.pdf

[DBSC] W3C (2025) Device Bound Session Credentials. Available at https://github.com/w3c/webappsec-dbsc

[E-Gov] E-Government Act of 2002, P.L. 107-347, 116 Stat. 2899, 44 U.S.C. § 101 (2002). Available at https://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.pdf

[EO13681] Obama B (2014) Improving the Security of Consumer Financial Transactions. (The White House, Washington, DC), Executive Order 13681, October 17, 2014. Available at https://www.federalregister.gov/d/2014-25439

[FEDRAMP] General Services Administration (2022), How to Become FedRAMP Authorized. Available at https://www.fedramp.gov/

[FIDO2] Bradley J, Jones MB, Kumar A, Lindemann R, Verrept J, Waite D (2025) Client to Authenticator Protocol (CTAP). (FIDO Alliance, Beaverton, OR). Available at https://fidoalliance.org/specs/fido-v2.2-ps-20250228/fido-client-to-authenticator-protocol-v2.2-ps-20250228.html

[FIPS140] National Institute of Standards and Technology (2019) Security Requirements for Cryptographic Modules. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 140-3. https://doi.org/10.6028/NIST.FIPS.140-3

[FIPS201] National Institute of Standards and Technology (2022) Personal Identity Verification (PIV) of Federal Employees and Contractors. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 201-3. https://doi.org/10.6028/NIST.FIPS.201-3

[FISMA] Federal Information Security Modernization Act of 2014, Pub. L. 113-283, 128 Stat. 3073. Available at https://www.govinfo.gov/app/details/PLAW-113publ283

[IC3] Federal Bureau of Investigation (2024) Annual Reports - Internet Crime Complaint Center (IC3). Available at https://www.ic3.gov/AnnualReport/Reports/

[ISO/IEC2382-37] International Standards Organization (2022) Information technology — Vocabulary — Part 37: Biometrics (ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/73514.html

[ISO/IEC9241-11] International Standards Organization (2018) ISO/IEC 9241-11 Ergonomics of human-system interaction – Part 11: Usability: Definitions and concepts (ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/63500.html

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

[ISO/IEC19792] International Standards Organization (2009) Information technology — Security techniques — Security evaluation of biometrics (ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/51521.html

[ISO/IEC19795-1] International Standards Organization (2021) Information technology - Biometric performance testing and reporting Part 1: Principles and framework (ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/73515.html

[ISO/IEC19989-1] International Standards Organization (2020) Information security — Criteria and methodology for security evaluation of biometric systems — Part 1: Framework (ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/72402.html

[ISO/IEC19989-3] International Standards Organization (2020) Information security — Criteria and methodology for security evaluation of biometric systems — Part 3: Presentation attack detection (ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/73721.html

[ISO/IEC30107-1] International Standards Organization (2023) Information technology — Biometric presentation attack detection — Part 1: Framework (ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/83828.html

[ISO/IEC30107-3] International Standards Organization (2023) Information technology — Biometric presentation attack detection — Part 3: Testing and reporting (ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/79520.html

[Managers] Lyastani SG, Schilling M, Fahl S, Backes M, Bugiel S (2018) Better managed than memorized? Studying the Impact of Managers on Password Strength and Reuse. 27th USENIX Security Symposium (USENIX Security 18) (USENIX Association, Baltimore, MD), pp 203–220. Available at https://www.usenix.org/conference/usenixsecurity18/presentation/lyastani

[NISTIR8062] Brooks S, Garcia M, Lefkovitz N, Lightman S, Nadeau E (2017) An Introduction to Privacy Engineering and Risk Management in Federal Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) NIST IR 8062, January 2017. https://doi.org/10.6028/NIST.IR.8062

[NISTRMF] Joint Task Force (2018) Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-37r2. https://doi.org/10.6028/NIST.SP.800-37r2

[OWASP-session] Open Web Application Security Project (2021) Session Management Cheat Sheet. Available at https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

[OWASP-XSS-prevention] Open Web Application Security Project (2021) XSS (Cross Site Scripting) Prevention Cheat Sheet. Available at https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

[Persistence] Herley C, Van Oorschot P (2012) A Research Agenda Acknowledging the Persistence of Passwords. IEEE Security & Privacy Magazine, (IEEE, Garden Grove, CA) 10(1):28–36. https://doi.org/10.1109/MSP.2011.150

[Policies] Weir M, Aggarwal S, Collins M, Stern H (2010) Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords. Proceedings of the 17th ACM Conference on Computer and Communications Security, CCS ‘10, (ACM, New York, NY, USA), pp 162–175. https://doi.org/10.1145/1866307.1866327

[PrivacyAct] Privacy Act of 1974, Pub. L. 93-579, 5 U.S.C. § 552a, 88 Stat. 1896 (1974). Available at https://www.govinfo.gov/content/pkg/USCODE-2020-title5/pdf/USCODE-2020-title5-partI-chap5-subchapII-sec552a.pdf

[PSL] Mozilla Foundation (2022) Public Suffix List. Available at https://publicsuffix.org/list/

[RBG] National Institute of Standards and Technology (2023) Random Bit Generation. Available at https://csrc.nist.gov/projects/random-bit-generation

[RFC20] Cerf V (1969) ASCII format for network interchange. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 20. https://doi.org/10.17487/RFC0020

[RFC5280] Cooper D, Santesson S, Farrell S, Boeyen S, Housley R, Polk W (2008) Internet X.509 Public Key Infrastructure Certification and Certificate Revocation List (CRL) Profile. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 5280. https://doi.org/10.17487/RFC5280

[RFC6749] Hardt D (2012) The OAuth 2.0 Authorization Framework. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 6749. https://doi.org/10.17487/RFC6749

[RFC8446] Rescorla E (2018) The Transport Layer Security (TLS) Protocol Version 1.3. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 8446. https://doi.org/10.17487/RFC8446

[RFC9325] Sheffer Y, Saint-Andre P, Fossati T (2022) Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 9325. https://doi.org/10.17487/RFC9325

[Section508] General Services Administration (2022) IT Accessibility Laws and Policies. Available at https://www.section508.gov/manage/laws-and-policies/

[Shannon] Shannon CE (1948) A Mathematical Theory of Communication. Bell System Technical Journal 27(3):379–423. https://doi.org/10.1002/j.1538-7305.1948.tb01338.x

[SP800-39] Joint Task Force (2011) Managing Information Security Risk. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-39. https://doi.org/10.6028/NIST.SP.800-39

[SP800-52] McKay K, Cooper D (2019) Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. (National Institute of Standards and Technology), NIST Special Publication (SP) NIST SP 800-52r2. https://doi.org/10.6028/NIST.SP.800-52r2

[SP800-53] Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-53r5, Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53r5

[SP800-57Part1] Barker EB (2020) Recommendation for Key Management: Part 1 – General. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-57pt1r5. https://doi.org/10.6028/NIST.SP.800-57pt1r5

[SP800-63] Temoshok D, Galluzzo R, LaSalle C, Lefkovitz N, Regenscheid A, Choong YY, Proud-Madruga D, Gupta S (2025) Digital Identity Guidelines. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63-4. https://doi.org/10.6028/NIST.SP.800-63-4

[SP800-63A] Temoshok D, Abruzzi C, Choong YY, Fenton JL, Galluzzo R, LaSalle C, Lefkovitz N, Regenscheid A, Vachino M (2025) Digital Identity Guidelines: Identity Proofing and Enrollment. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63A-4. https://doi.org/10.6028/NIST.SP.800-63A-4

[SP800-63C] Temoshok D, Richer JP, Choong YY, Fenton JL, Lefkovitz N, Regenscheid A, Galluzzo R (2025) Digital Identity Guidelines: Federation and Assertions. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-63C-4. https://doi.org/10.6028/NIST.SP.800-63C-4

[SP800-73pt2] Ferraiolo H, Mehta K, Francomacaro S, Chandramouli R, Gupta S (2024) Interfaces for Personal Identity Verification: Part 2 – PIV Card Application Card Command Interface. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-73pt2-5. https://doi.org/10.6028/NIST.SP.800-73pt2-5

[SP800-90A] Barker E, Kelsey J (2015) Recommendation for Random Number Generation Using Deterministic Random Bit Generators. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-90Ar1. https://doi.org/10.6028/NIST.SP.800-90Ar1

[SP800-90B] Turan MS, Barker E, Kelsey J, McKay K, Baish M, Boyle M (2018) Recommendation for the Entropy Sources Used for Random Bit Generation. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-90B. https://doi.org/10.6028/NIST.SP.800-90B

[SP800-90C] Barker E, Kelsey J, McKay K, Roginsky A, Turan MS (2024) Recommendation for Random Bit Generator (RBG) Constructions. (National Institute of Standards and Technology, Gaithersburg, MD), Draft NIST Special Publication (SP) NIST SP 800-90C. https://doi.org/10.6028/NIST.SP.800-90C.4pd

[SP800-131A] Barker E, Roginsky A (2019) Transitioning the Use of Cryptographic Algorithms and Key Lengths. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-131Ar2. https://doi.org/10.6028/NIST.SP.800-131Ar2

[SP800-132] Turan M, Barker E, Burr W, Chen L (2010) Recommendation for Password-Based Key Derivation. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-132. https://doi.org/10.6028/NIST.SP.800-132

[SP800-157] Ferraiolo H, Regenscheid AR, Fenton J (2023) Guidelines for Derived Personal Identity Verification (PIV) Credentials. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-157r1 ipd (initial public draft). https://doi.org/10.6028/NIST.SP.800-157r1.ipd

[Strength] Kelley PG, Komanduri S, Mazurek ML, Shay R, Vidas T, Bauer L, Christin N, Cranor LF, Lopez J (2012) Guess again (and again and again): Measuring password strength by simulating password-cracking algorithms. 2012 IEEE Symposium On Security and Privacy (SP), pp 523–537. Available at http://ieeexplore.ieee.org/iel5/6233637/6234400/06234434.pdf

[TOTP] M’Raihi D, Machani S, Pei M, Rydell J (2011) TOTP: Time-Based One-Time Password Algorithm. (Internet Engineering Task Force, Reston, VA), RFC 6238. https://doi.org/10.17487/RFC6238

[UsabilityBiometrics] National Institute of Standards and Technology (2008) Usability & Biometrics: Ensuring Successful Biometric Systems. (National Institute of Standards and Technology, Gaithersburg, MD). Available at https://www.nist.gov/system/files/usability_and_biometrics_final2.pdf

[UAX15] Whistler K (2022) Unicode Normalization Forms. (The Unicode Consortium, South San Francisco, CA), Unicode Standard Annex 15, Version 15.0.0, Rev. 53. Available at https://www.unicode.org/reports/tr15/

[WebAuthn] Hodges J, Jones JC, Jones MB, Kumar A, Lundberg E (2021) Web Authentication: An API for accessing Public Key Credentials - Level 2. (World Wide Web Consortium, Cambridge, MA). Available at https://www.w3.org/TR/2021/REC-webauthn-2-20210408/

Strength of Passwords

この付録は参考情報である。

この付録では、議論を容易にするために「password」という語を用いる。使用される場合、それはパスフレーズおよびPINを含むものとして解釈されるべきである。

Introduction

Passwordsは、ユーザビリティおよびセキュリティの観点からの懸念があるにもかかわらず、広く用いられている認証形態である [Persistence]。人間は複雑で任意の秘密を記憶する能力が限られているため、推測しやすいパスワードを選びがちである。この結果として生じるセキュリティ上の懸念に対処するため、オンラインサービスはこれらのパスワードの実効強度を高める規則を導入してきた。最も顕著な形態は構成規則であり、ユーザに対して、複数の文字種（例：少なくとも1つの数字、大文字、記号）を組み合わせてパスワードを構成することを要求する。しかし、侵害されたパスワードデータベースの分析により、そのような規則の効果は当初考えられていたほど大きくないことが示されており [Policies]、ユーザビリティと記憶容易性への影響は深刻である。

ユーザが選ぶパスワードの実効強度は、情報理論の概念であるエントロピー [Shannon]を用いて特徴付けられることが多かった。エントロピーは、決定的な分布関数を持つデータについては容易に計算できるが、ユーザが選ぶパスワードのエントロピー推定は難しい。このため、ここでは主にパスワード長に基づく、別の、やや単純で分かりやすいアプローチを提示する。パスフレーズ（すなわち複数単語からなるパスワード）の利用は、より長いパスワードを作成する有効な方法であることが多い。

パスワードに関連する多くの攻撃は、パスワードの複雑さや長さの影響を受けない。キーストローク記録、フィッシング、ソーシャルエンジニアリング攻撃は、単純なパスワードと同様に、長く複雑なパスワードに対しても同等に有効である。これらの攻撃は本付録の範囲外である。

Length

パスワードの長さは、パスワード強度を特徴付ける主要因である [Strength] [Composition]。短すぎるパスワードは、総当たり攻撃および辞書攻撃に屈する。必要な最小パスワード長は、対処すべきThreat modelに依存する。攻撃者がパスワードを推測してログインを試みるオンライン攻撃は、許可されるログイン試行率を制限することで軽減できる。多くの誤推測を行うことで購読者に対して素早くサービス妨害を引き起こすこと（またはタイピングが不得手な継続的申告者が誤りを繰り返すこと）を防ぐため、パスワードは、成功確率が低い状態で妥当な回数の試行を許容できる程度に十分複雑である必要があり、Sec. 3.2.2で述べられているように、成功の可能性が有意になる前にレート制限を適用できる。

攻撃者がデータベース侵害により1つ以上のハッシュ化されたパスワードを取得した場合、オフライン攻撃が可能となる。攻撃者が1人以上のユーザのパスワードを特定できるかは、パスワードの保存方法に依存する。一般に、パスワードはランダム値でソルトされ、可能であれば計算コストの高いアルゴリズムでハッシュ化される。そうした措置があっても、レート制限のないオフライン環境で毎秒何十億ものハッシュを計算できるという現在の攻撃能力を踏まえると、パスワードはオンライン攻撃のみを想定して耐性を持たせる場合に期待されるよりも、桁違いに複雑である必要がある。

ユーザには、妥当な範囲で望むだけ長いパスワードを作るよう促すべきである。ハッシュ化されたパスワードのサイズは長さに依存しないため、ユーザが望むのであれば、長いパスワード（またはパスフレーズ）の利用を禁じる理由はない。しかし、極端に長いパスワード（おそらくメガバイト級）はハッシュ化に過度な処理時間を要し得るため、何らかの上限を設けることは合理的である。

Complexity

構成規則は、ユーザが選ぶパスワードの推測を困難にする目的で一般に用いられる。しかし、研究は、構成規則によって課される要件に対してユーザが非常に予測可能な形で反応することを示している [Policies]。例えば、パスワードとして「password」を選んだかもしれないユーザは、大文字と数字を含めることを要求された場合には「Password1」を、さらに記号も要求された場合には「Password1!」を選ぶ可能性が比較的高い。

オンラインサービスが複雑なパスワードの作成を拒否する場合、ユーザは不満を表明する。多くのサービスは、空白やさまざまな特殊文字を含むパスワードを拒否する。受け入れられない文字は、そうした文字に依存する攻撃（例：SQL injection）を避けようとする努力の結果である場合がある。しかし、ハッシュ化されていないパスワードがそのままデータベースに送られることはないため、そのような予防策は不要である。ユーザは、フレーズを使用できるよう空白文字を含められるべきでもある。繰り返しの空白文字は実効強度への寄与が小さく、ユーザビリティ上の問題（例：1つではなく2つの空白を用いたことに気づかない）を導入し得るため、初回の検証が失敗した場合に、入力されたパスワードから連続する空白を取り除くことが有益となり得る。

ユーザのパスワード選択が予測可能であるため、攻撃者は、過去に成功が証明されたパスワードを推測する可能性が高い。これには、辞書語や、過去の侵害で漏えいしたパスワード（上の「Password1!」の例など）が含まれる。このため、ユーザが選んだパスワードは、受け入れられないパスワードのblocklistと照合すべきである。このリストには、過去の侵害コーパス由来のパスワード、パスワードとして用いられる辞書語、ならびにユーザが選びがちな特定語（例：サービス名自体）が含まれるべきである。最小長要件もユーザの選択を支配するため、この辞書には、その要件を満たすエントリだけを含めればよい。Sec. 3.1.1.2で述べられているとおり、blocklistを過度に大きくしたり包括的にしたりしても有益ではない。主目的は、スロットリング制限が効く前にオンライン攻撃で推測され得る非常に一般的なパスワードの使用を防ぐことだからである。過度に大きいblocklistは、覚えやすいパスワードを選ぼうとするユーザを苛立たせる可能性が高い。

非常に複雑なパスワードは、新たな潜在的脆弱性を導入する。すなわち、記憶しにくく、書き留められたり電子的に安全でない形で保管されたりしやすくなる。これらの慣行が必ずしも脆弱であるとは限らないが、そのような秘密の記録方法の一部は脆弱となる。これは、過度に長く複雑なパスワードを要求しない追加の動機となる。

Central vs. Local Verification

別個の認証要素として用いられるパスワードは、しばしばCSPの検証者によって中央で検証される。一方、Multi-factor認証器の活性化要素として用いられるパスワードは、認証器によってローカルに検証されるか、認証器出力を導出するために用いられ、誤った活性化要素が用いられた場合には誤った認証器出力となる。これらの状況はいずれも「ローカル検証」と呼ばれる。

中央検証とローカル検証では、攻撃対象領域と脆弱性が大きく異なる。したがって、中央で検証されるパスワードの要件は、ローカルで検証されるものとは異なる。中央で検証されるパスワードでは、検証者（すなわちオンライン資源）が、すべての購読者のパスワードの検証秘密を、ソルト付きで反復的にハッシュ化した形で保存する必要がある。ソルト付与とハッシュ化は、ハッシュからパスワードを特定する計算労力を増大させるが、検証者は攻撃者にとって魅力的な標的であり、特に特定の購読者ではなく任意の購読者の侵害に関心がある攻撃者にとってそうである。

ローカル検証者は、中央のオンライン検証者に対する大規模攻撃について同様の懸念はないが、認証器の物理的安全性と、その関連エンドポイントの完全性に依存する。認証器が活性化要素を保存する範囲において、その要素は、認証器に対する物理的攻撃および side-channel（例：電力・タイミング解析）攻撃から保護されなければならない。活性化要素が関連エンドポイントを通じて入力される場合、そのエンドポイントはマルウェア（例：キーロギングソフトウェア）が存在しない状態である必要がある。これらの脅威はパスワードの長さや複雑さへの依存が小さいため、ローカル検証の要件は緩和される。

オンラインでのパスワード推測攻撃は、中央検証とローカル検証の双方に共通する脅威である。スロットリングがオンライン攻撃に対する主要な防御であり、ローカル検証者では、失敗試行に関する情報を安全に保存する能力が限られる認証器があるため、特に難しくなり得る。ローカルの活性化要素のスロットリングは2通りで実施できる。認証器自体が無効な活性化試行数を数えてスロットリングを処理するか、または誤って有効化された場合に、認証器が無効な認証器出力を生成し、検証者側で拒否およびスロットリングされるようにする。

Summary

ここで推奨する以上の長さおよび複雑さ要件は、ユーザの不満とパスワード利用の困難さを大きく増加させる。その結果、ユーザはしばしば、逆効果な回避策を取る。他の軽減策（例：blocklist、安全なハッシュ化保存、機械生成のランダムパスワード、レート制限）は、現代の総当たり攻撃を防ぐうえでより効果的であるため、追加のパスワード要件は課さない。

Syncable Authenticators

この付録は規定である。

Introduction

認証器を「sync」する能力、具体的にはその認証秘密をクラウドへコピー（すなわち複製）し、さらに追加の認証器へコピーする能力は、認証における比較的新しい進展である。本付録は、sync可能な認証器の利用に関する追加のガイドラインを提供する。

Cloning Authentication Keys

場合によっては、認証鍵が同期基盤（例：クラウドストレージ）に保存され得る。これにより、鍵のバックアップと他デバイスへの移転が可能となる。この方法で管理される鍵には、次の要件が適用される：

• すべての鍵は、承認された暗号技術を用いて生成しなければならない。
• デバイスから同期基盤へ複製またはエクスポートされる認証鍵は、この発行時点での最新改訂版である[SP800-131A]に指定された最小セキュリティ強度（すなわち112ビット）を持つ鍵を用いて、暗号化された形でのみ保存しなければならない。これらの鍵は、ユーザが制御する秘密を用いる方式で暗号化すべきである。
• すべての認証トランザクションは、デバイス上で生成された暗号鍵、または同期基盤から回復された暗号鍵を用いて、ローカルデバイス上で秘密鍵演算を実行しなければならない。
• 同期基盤に保存される認証鍵は、認証済みユーザのみが同期基盤内の自身の認証鍵へアクセスできるよう、アクセス制御機構により保護しなければならない。
• 同期基盤内の認証鍵へのユーザアクセスは、同期済み鍵を用いる認証プロトコルの完全性を保つため、AAL2相当のMFAにより保護しなければならない。
• sync可能な認証器を使用するためのこれらの一般要件およびその他の機関固有要件は、該当する場合、公的なWebサイトやデジタルサービスのポリシー等を含め、文書化して周知しなければならない。
• sync可能な認証鍵の利用を可能にする認証器は、購読者が、sync可能な認証鍵を作成したサービス、当該鍵が同期されたかどうか、そしてどこに同期されたかを確認できるユーザインタフェース（UI）を提供すべきである。UIは認証鍵そのものを露出してはならない。

連邦エンタープライズにおけるsync可能な認証器の利用には、次の追加要件が適用される：

• 連邦エンタープライズの認証鍵は、Federal Information Security Modernization Act (FISMA) [FISMA]のmoderate保護、または同等の保護を達成した同期基盤に保存しなければならない。
• 連邦エンタープライズの認証鍵を含む認証器を生成・保存・同期するデバイス（例：携帯電話、ノートPC、タブレット）は、モバイルデバイス管理ソフトウェア、または、未承認のデバイスや同期基盤への鍵の同期や共有を防ぐ他のデバイス構成制御によって保護しなければならない。
• 同期基盤へのアクセスは、機関が管理するアカウント（例：中央のIDおよびアクセス管理ソリューション、プラットフォームベースの管理アカウント）により制御しなければならない。これは認証鍵のライフサイクルに対する連邦エンタープライズの管理を維持するためである。
• 認証鍵を生成する認証器は、認証器の能力と供給元（例：エンタープライズattestation）を検証するために利用できるattestation機能を支援すべきである。

これらの制御は同期を特に支援するものであり、既存のMulti-factor暗号認証器要件およびAAL2要件（[FIPS140]の検証を含む）に追加されるものとして考えるべきである。

認証鍵を同期するということは、本質的にその鍵がエクスポート可能であることを意味する。AAL2での認証は、上記要件に従うことを条件として支援され得る。しかし、同期はAAL3の非エクスポート性要件に反する。エクスポート可能な形で保存されない鍵を用い、他のAAL3要件も満たす類似プロトコルを使用してよい場合がある。

Implementation Requirements

多くのsync可能な認証器は、W3Cの[WebAuthn]仕様に基づいている。WebAuthnは、共通のデータ構造、チャレンジレスポンスの暗号プロトコル、および公開鍵資格情報を活用するAPIを提供する。この仕様は柔軟で適応的であり、したがってWebAuthn資格情報のすべての導入が、連邦機関の実装要件を満たすとは限らない。

この仕様には、RPアプリケーションが認証器に要求できる一連のフラグがあり、認証イベントに関する追加の文脈を提供し、それがRPのアクセス方針を満たすかどうかを判断する。本節は、AAL2ガイドラインに整合させてsync可能な認証器実装を構築する際、RPsとして行動する連邦機関が理解し確認すべき、WebAuthn仕様の特定のフラグを説明する。

WebAuthn Level 3フラグに適用される要件は次のとおり：

User Present (UP)

User Presentフラグは、「在席」テストによりユーザが認証器と対話したこと（例：USBポートに挿入されたハードウェアトークンをタップすること）が確認されたことを示す。これは、Sec. 3.2.8で述べられている認証の意図を支援する。検証者はUser Presentフラグが設定されていることを確認すべきである。

User Verified (UV)

User Verifiedフラグは、認証器が利用可能な「ユーザ検証」方式のいずれかを用いて、ローカルでユーザを認証したことを示す。検証者は、UVが望ましいことを示し、UVフラグの値を確認するために応答を検査しなければならない。これは、認証器をMulti-factor暗号認証器として扱えるかどうかを示す。ユーザが検証されていない場合、機関は認証器をSingle-factor暗号認証器として扱わなければならない。WebAuthn Level 3仕様へのさらなる拡張（[WebAuthn]のSec. 10.3参照）は、機関がローカル認証イベントの文脈を得たい場合に、検証方法に関する追加データを提供する。

Backup Eligible

Backup Eligibleフラグは、認証器が別デバイスへ同期可能かどうか（すなわち鍵が別の場所に保存され得るか）を示す。重要なのは、認証器が同期「できる」からといって、同期「された」とは限らないという点である。検証者はこのフラグを用いて、sync可能な認証器の利用を制限する方針を定めてもよい。このフラグは、デバイスに紐づく認証器と、複数デバイスへ複製され得る認証器を区別するために必要である。

Backup State

Backup Stateフラグは、認証器が別デバイスへ同期「された」かどうかを示す。検証者はこのフラグを用いて、他デバイスへ同期された認証器に対する制限を定めてもよい。機関は、ユーザ体験上の懸念から、公的なアプリケーションにおいて、このフラグに基づいて受け入れ条件を定めるべきではない。

上で指定したフラグに加えて、機関は、実装・受入れを選ぶsync可能な認証器の起源と能力について追加情報を得たい場合がある。WebAuthnの文脈では、一部の認証器がattestation機能を支援しており、特定の認証器の能力や製造元を判断するために利用できる。連邦エンタープライズのユースケースでは、機関は、プラットフォーム提供者が提供する機能に基づいてattestation機能を実装すべきである。これは、RPが認証器に関する識別情報を要求する製造元attestationの形を取る。

attestationが利用できないことは、広範な公的アプリケーションにおけるsync可能な認証器の利用を妨げるべきではない。消費者向け製品ではattestationの利用可能性が限られるため、attestationを必須にすると、ユーザがフィッシングに脆弱な、より安全性の低い認証選択肢（例：PSTNベースのOut-of-band認証）へ誘導される可能性が高い。WebAuthn応答では、User Verifiedフラグ値がローカル活性化要素の利用を示すなどの認証トランザクションメタデータが利用可能である一方、attestationは、トランザクションで使用された認証器の特性についてより強い保証を提供できる。RPsは、attestationが利用できる場合、sync可能な認証器に対してattestationを用い、当該認証器にどの程度の信頼を置くかを判断すべきである。

RPがフラグおよびattestationデータを受け取ると、認証器は、資源へのアクセスという観点では不完全、または一貫しない情報を提供する場合がある。機関は、sync可能な認証器のユースケースを評価し、返された情報に基づいて行うつもりのアクセス方針決定について、適切なものを定めなければならない。

Sharing

サイバーセキュリティのガイドラインは歴史的に、ユーザ間での認証器の共有を避けるよう注意喚起してきた。むしろ、ユーザはそれぞれ自分固有の認証器を維持することが期待されている。それにもかかわらず、一部のユーザ集団やアプリケーションでは、個人がデジタルアカウントへのアクセスを共有できるよう、認証器やパスワードの共有が発生している。

Table 5に示されるとおり、一部のsync可能な認証器実装はこのユーザ行動を取り込み、異なるユーザ間で認証鍵を共有する手段を確立してきた。さらに、一部の実装は、一般的なサービスに対してパスワードを共有する代替として、より便利で安全な選択肢としてsync可能な認証器の共有を積極的に促している。

エンタープライズのユースケースでは、共有鍵に関する懸念は、承認済みデバイスや同期基盤から鍵が移動される能力を制限するデバイス管理技術により、効果的に軽減できる。しかし、公的ユースケースでは同様の軽減策が現在利用できず、RPはsync可能な認証器提供者が採用する共有モデルに依存せざるを得ない。公的アプリケーションの所有者は、共有認証器に伴うリスクを認識しておくべきである。公衆とやり取りする際、機関はユーザが用いている特定の認証器に関する可視性が限られており、すべてのsync可能な認証器が共有の対象となり得ると想定すべきである。多くの共有モデルは、リスクを最小化する実質的な制御（例：共有に際してデバイス間の近接を要求する）を備えているが、他の実装は制限が少ない。

この新しいクラスの認証器がもたらす共有リスクは固有のものではない。sync可能な認証器より弱いものも含め、すべての認証器タイプに当てはまる。どの認証器も、共有する意思のあるユーザによって共有され得る。ユーザはパスワード、OTP、Out-of-band認証器、さらには、指名された者（正式か否かを問わない）がEnd-Userの代わりに認証できるようにするプッシュ型認証イベントさえ、積極的に共有できる。

機関は、直面する具体的なリスク、脅威、ユーザビリティの考慮事項に基づいて、アプリケーションで受け入れる認証器を決定する。sync可能な認証器は、AAL2までの実装を目指すアプリケーションに対して新たな選択肢として提供され得る。この技術のトレードオフは、セキュリティ、プライバシー、およびユーザ体験に関して期待される成果とバランスを取るべきである。

Example

sync可能な認証器の一般的な利用は、AAL2の認証トランザクションにおいてである。以下は、WebAuthn sync可能な認証器がAAL2要件の側面をどのように満たすかを要約する：

Phishing resistance（推奨、連邦エンタープライズでは必須）

達成：適切に構成されたsync可能な認証器は、一意の公開鍵・秘密鍵ペアを作成し、その利用を作成されたドメインに制約する（すなわち、その鍵は特定のWebサイトまたはRPでのみ使用できる）。これにより、偽のWebページが認証器出力を取得して再利用することを防ぐ。

Replay resistance（必須）

達成：sync可能な認証器は、各認証トランザクションに組み込まれるランダムなnonceにより、リプレイ耐性（すなわち将来のトランザクションでの再利用防止）を提供する。

Authentication intent（必須）

達成：sync可能な認証器は、暗号認証プロトコルを開始するために、ユーザが活性化要素（すなわち活性化の秘密、生体特徴）を提示することを要求する。イベントはユーザの能動的な参加なしには進行できないため、これは認証の意図を満たす。

Multi-factor（必須）

達成：User Verifiedフラグ値は、ローカル認証機構（すなわち活性化要素）がトランザクション完了のために使用されたかどうかを示す。ユーザ検証がない場合、検証者はトランザクションの一部として追加の認証要素を求める。

購読者が自分の認証器を提供する場合、検証者は、同期基盤の機能や能力、およびユーザが認証鍵を同期し得るデバイスについて、可視性が限られる可能性がある。このシナリオでは、検証者は、認証イベントへの信頼を高めるために、トランザクション、デバイス、または同期基盤から得られる追加のリスク指標や信頼シグナルを活用すべきである。

sync可能な認証器がこの点で特別というわけではない。購読者提供の認証器は、OTP認証器やほとんどすべてのOut-of-band認証器を含め、sync可能な認証器と同様のリスクにさらされる。CSPとIdPにとって重要なのは、各保証レベルにおいて提供する認証器タイプそれぞれを評価し、ユーザやトランザクションタイプに基づいて許容可能なものを決定することである。

Security Considerations

sync可能な認証器は、Table 5に示されるとおり、実装または展開の前に機関が評価すべき独特の脅威と課題を提示する。

Table 5. Syncable authenticator threats, challenges, and mitigations

Threat or Challenge	Description	Mitigations
Unauthorized key use or loss of control	一部のsync可能な認証器導入は、認証鍵を他ユーザに属するデバイスへ共有することを支援しており、そのユーザが鍵を悪用できてしまう。	エンタープライズのデバイス管理機能や管理プロファイルを適用し、同期済み鍵が共有されないように強制する。
		ユーザが鍵、鍵の状態、および鍵が共有されたか／どこに共有されたかを確認できる仕組みを提供する。
		既存の意識向上および訓練の仕組みを通じて、Unauthorized key useのリスクについてユーザを教育する。
Sync fabric compromise	鍵の同期を支援するため、多くの実装は鍵を同期基盤（すなわち、アカウントに関連付けられた複数デバイスに接続するクラウドベースのサービス）へ複製する。	暗号化された鍵素材のみを保存する。
		認証済みユーザ以外が認証鍵へアクセスできないようにする同期基盤のアクセス制御を実装する。
		クラウドサービスのベースラインのセキュリティ機能（例：FISMA moderate保護または同等）を評価する。
		暗号化鍵を保護するためにハードウェアセキュリティモジュールを活用する。
Unauthorized access to sync fabric and recovery	同期済み鍵は、クラウドベースのアカウント回復プロセスを通じてアクセス可能であり、これは認証器に対する潜在的な弱点を表す。	SP 800-63Bに整合する認証回復プロセスを実装する。
		デバイス管理または管理アカウント機能により、連邦エンタープライズ鍵の回復能力を制限する。
		回復を支援するため、AAL2以上で複数の認証器を紐づける。
		同期基盤へのユーザアクセスのために新しい認証器を追加する際は、AAL2認証を要求する。
		連邦エンタープライズのシナリオでは、同期済み鍵をderived authenticatorとしてのみ用いる [SP800-157]。
		回復活動があればユーザに通知する。
		鍵を暗号化し回復するために、ユーザが制御する秘密（すなわち同期基盤提供者が知らないもの）を活用する。
Revocation	sync可能な認証器はRP固有の鍵を用いるため、それらの鍵に基づいてアクセスを中央で失効させることは困難である。例えば、従来のPKIではCRLを用いて中央でアクセスを失効できる。同様のプロセスは、sync可能な認証器や、FIDO WebAuthnベースの資格情報には利用できない。	ユーザが認証器を管理し、侵害または期限切れの場合に「ホーム機関」アカウントから削除できるように、中央のID管理（IDM）アカウントを実装する。
		SSOとフェデレーションを活用し、インシデントで失効が必要となるRP固有鍵の数を制限する。
		ユーザに対し、鍵の有効性と最新性を定期的に見直すことを求める方針とツールを整備する。

1. 連邦エンタープライズシステムには、政府請負業者、政府職員、およびミッションパートナーなど、PIVガイダンスの対象範囲内とみなされるものが含まれる。政府対消費者または公的ユースケースは含まれない。↩

List of Symbols, Abbreviations, and Acronyms

AAL

Authentication Assurance Level

ASCII

American Standard Code for Information Interchange

CAC

Common Access Card

CSP

Credential Service Provider

CSRF

Cross-Site Request Forgery

DNS

Domain Name System

FEDRAMP

Federal Risk and Authorization Management Program

FIPS

Federal Information Processing Standards

FMR

False Match Rate

FNMR

False Non-Match Rate

IAL

Identity Assurance Level

IdP

Identity Provider

KBA

Knowledge-Based Authentication

MAC

Message Authentication Code

MF

Multi-Factor

MFA

Multi-Factor Authentication

NARA

National Archives and Records Administration

NFC (communications protocol)

Near-Field Communication

OTP

One-Time Password

OWASP

Open Worldwide Application Security Project

PAD

Presentation Attack Detection

PIA

Privacy Impact Assessment

PIN

Personal Identification Number

PIV

Personal Identity Verification

PKI

Public-Key Infrastructure

PSTN

Public Switched Telephone Network

QR

Quick Response

RP

Relying Party

SAOP

Senior Agency Official for Privacy

SF

Single-Factor

SMS

Short Message Service

SORN

System of Records Notice

SSO

Single Sign-On

TEE

Trusted Execution Environment

TLS

Transport Layer Security

TPM

Trusted Platform Module

USB

Universal Serial Bus

VOIP

Voice-Over-IP

XSS

Cross-Site Scripting

Glossary

This section is informative.

デジタル・アイデンティティの領域では、非常に多様な用語が使用される。多くの定義は SP 800-63 の以前の版と整合しているが、この改訂版で変更されたものもある。これらの用語の多くは、単一で一貫した定義を持たないため、ここでどのように定義されているかに注意深く目を向ける必要がある。

account recovery

subscriber account と、それに関連する情報および権限の所有権を取り戻す能力。

activation

authentication を可能にするために、multi-factor authenticator に activation factor を入力するプロセス。

activation factor

multi-factor authenticator による成功した authentication を可能にするために用いられる、追加の authentication factor。

activation secret

multi-factor authenticator の activation factor としてローカルで用いられる password。

applicant

identity proofing と enrollment のプロセスを受けている subject。

approved cryptography

Federal Information Processing Standards (FIPS) により承認されている、または NIST が推奨する暗号化アルゴリズム、hash function、乱数生成器、または同種の技法。承認されたアルゴリズムおよび技法は、FIPS または NIST の推奨事項において指定されるか、採用される。

assertion

subscriber の認証イベントに関する情報を含む、IdP から RP への表明。Assertion には、属性値、派生属性値、属性バンドルの形で、subscriber の ID attributes を含めることもできる。

asymmetric keys

暗号化と復号、または署名検証と署名生成のような、相補的な操作を実行するために使用される、public key と private key から成る 2 つの関連した cryptographic keys。

attestation

一般に authenticator がバインドされる時点で CSP に伝達される情報であり、接続された authenticator の特性、または認証操作に関与する endpoint の特性を記述するもの。

attribute

誰かまたは何かに帰属する性質または特性。アイデンティティ属性は、subscriber のアイデンティティに関する属性（例：氏名、生年月日、住所）である。

attribute validation

一連の attributes が正確であり、現実世界のアイデンティティに関連付いていることを確認するプロセスまたは行為。validation を参照。

authenticate

authentication を参照。

authenticated protected channel

接続の開始者（client）が受信者（server）を authenticated 済みである、approved cryptography を用いた暗号化通信チャネル。Authenticated protected channels は、機密性と能動的な中間者に対する保護を提供するために暗号化されており、ユーザーの authentication プロセスで頻繁に使用される。Transport Layer Security (TLS) および Datagram Transport Layer Security (DTLS) [RFC9325] は、受信者が提示する証明書を開始者が検証する、authenticated protected channel の例である。別段の指定がない限り、authenticated protected channels は server が client を認証することを要求しない。Server の認証は、各 server を個別に扱うのではなく、信頼された root へ至る証明書チェーンによって実現されることが多い。

authenticated session

protected session を参照。

authentication

claimant が subscriber account にバインドされた 1 つ以上の authenticators の所持と制御を証明することにより、そのアカウントに関連付けられた subscriber であることを示すプロセス。

authentication assurance level (AAL)

authentication プロセスの強度を記述するカテゴリ。

authentication factor

認証要素の 3 つの種類は、something you know、something you have、something you are である。すべての authenticator は、1 つ以上の認証要素を持つ。

authentication intent

認証フローにおいてユーザーの介入を要求することで、claimant が authenticate または再認証を行う意思を確認するプロセス。一部の authenticators（例：OTP）は、その動作の一部として authentication intent を確立する。他のものは、ボタンを押すといった、意思を確立するための特定の手順を必要とする。Authentication intent は、subscriber に知られないまま、endpoint 上のマルウェアが攻撃者を認証する代理となることへの対抗策である。

authentication key

authenticator 出力を生成するために authenticator が使用する private または対称鍵。

authentication protocol

claimant と verifier の間で定義された一連のメッセージであり、claimant が 1 つ以上の有効な authenticators を所持し制御していることを示してアイデンティティを確立し、（任意で）claimant が意図した verifier と通信していることを示す。

authentication secret

authentication protocol において subscriber を検証するために使用される、あらゆる秘密値の総称。これらはさらに、攻撃者にとって有用な期間が限られる short-term authentication secrets と、手動でリセットされるまで攻撃者が subscriber になりすまし可能な long-term authentication secrets に分けられる。authenticator secret は long-term authentication secret の代表例であり、authenticator output（それが authenticator secret と異なる場合）は、通常 short-term authentication secret である。

authenticator

subscriber が所持し制御するもの（例：cryptographic module または password）で、claimant のアイデンティティを authenticate するために使用されるもの。authenticator type および multi-factor authenticator を参照。

authenticator binding

特定の authenticator と subscriber account の間に関連付けを確立し、（他の authenticators と併用する場合も含めて）その authenticator が当該アカウントに関連付けられた subscriber を認証できるようにすること。

authenticator output

authenticator によって生成される出力値。必要に応じて有効な authenticator outputs を生成できる能力は、claimant が authenticator を所持し制御していることを証明する。verifier に送信されるプロトコルメッセージは authenticator output に依存するが、それを明示的に含む場合と含まない場合がある。

authenticator type

提供する authentication factors の種類や動作メカニズムなど、共通の特性を持つ authenticators のカテゴリ。

authenticity

データが、その主張される発生源から生じたという性質。

authorize

通常は subject の attributes を評価することにより自動化される、アクセスを許可するという判断。

biometric sample

生体特徴の特徴量抽出より前の、生体特徴のアナログまたはデジタル表現（例：指紋画像を含む記録）。

biometrics

生物学的または行動的特徴に基づく個人の自動認識。生物学的特徴には、指紋、手のひらの紋様、顔の特徴、虹彩および網膜パターン、声紋、静脈パターンなど（これらに限られない）が含まれる。行動的特徴には、キーストロークのリズム、スマートフォンの保持角度、画面への圧力、入力速度、マウスや携帯電話の動き、ジャイロスコープの位置など（これらに限られない）が含まれる。

blocklist

ポリシー判断によりブロックされる特定要素の、文書化されたリスト。この概念は歴史的に “blacklist” と呼ばれてきた。

challenge-response protocol

verifier が claimant にチャレンジ（例：乱数値または nonce）を送信し、claimant がそのチャレンジを秘密値と組み合わせ（例：チャレンジと shared secret を一緒にハッシュする、またはチャレンジに private-key 操作を適用する）て response を生成し、それを verifier に送信する authentication protocol。Verifier は、claimant が生成した response を独立に検証（例：チャレンジと shared secret のハッシュを再計算して response と比較する、または response に public-key 操作を実行する）し、claimant が秘密値を所持し制御していることを確認できる。

claimant

1 つ以上の authentication protocols を用いてアイデンティティが確認されるべき subject。

claimed identity

未検証かつ未確認の個人 attributes に関する applicant の申告。

credential

_ identifier_ を介してアイデンティティを権威的にバインドし、（任意で）追加の attributes を、subscriber が所持し制御する少なくとも 1 つの authenticator にバインドする、オブジェクトまたはデータ構造。Credential は CSP が発行し、保管し、維持する。Credential からの情報の写しは subscriber が保持でき、通常は 1 つ以上のデジタル証明書の形をとり、それらはしばしば authenticator 内に、その関連する private keys とともに格納される。

credential service provider (CSP)

信頼される主体であり、その機能には、アイデンティティサービスに対する applicants の identity proofing と、subscriber accounts への authenticators の登録が含まれる。CSP は独立した第三者である場合がある。

cross-site request forgery (CSRF)

現在 authenticated 状態で RP に接続しており、かつ安全なセッションを通じて接続している subscriber が攻撃者のウェブサイトを閲覧することで、subscriber が意図せず RP に対して望ましくない操作を呼び出してしまう攻撃。たとえば、銀行サイトが CSRF 攻撃に脆弱である場合、別のブラウザウィンドウで銀行への接続が開いたままの状態で、subscriber がメール内の悪意あるリンクをクリックすることで、意図せず大口の送金を authorize してしまう可能性がある。

cross-site scripting (XSS)

本来は無害なウェブサイトに攻撃者が悪意あるコードを注入できる脆弱性。これらのスクリプトは、標的サイトが生成するスクリプトと同等の権限を取得し、ウェブサイトと clients 間のデータ転送の機密性と完全性を侵害する。ウェブサイトが、リクエストやフォームから提供されたユーザー入力データを、実行可能ではないように無害化（sanitize）せずに表示する場合、脆弱となる。

cryptographic authenticator

暗号学的な authentication protocol を通じて verifier と直接通信することで、authentication secret の所持を証明する authenticator。

cryptographic key

復号、暗号化、署名生成、署名検証などの暗号操作を制御するために用いられる値。本ガイドラインの目的において、鍵要件は [SP800-57Part1] の Table 2 に記載された最小要件を満たさなければならない。asymmetric keys または symmetric keys を参照。

cryptographic module

暗号アルゴリズムおよび鍵生成を含む、承認されたセキュリティ機能を実装するハードウェア、ソフトウェア、またはファームウェアの集合。

digital authentication

システムにデジタルに提示されたユーザーアイデンティティに対する信頼を確立するプロセス。SP 800-63 の以前の版では “electronic authentication” と呼ばれていた。

digital identity

与えられた文脈において subject を一意に記述する attribute、または属性の集合。

digital signature

private key を用いてデータにデジタル署名を行い、public key を用いて署名を検証する asymmetric key 操作。Digital signatures は authenticity 保護、完全性保護、non-repudiation の支援を提供するが、機密性や replay attack からの保護は提供しない。

digital transaction

ビジネスまたはプログラム上の目的を支援する、ユーザーとシステム間の個別のデジタルイベント。

endpoint

laptops、desktops、mobile phones、tablets、servers、Internet of Things デバイス、仮想環境など、network 上の digital identity にアクセスするために使用されるあらゆるデバイス。

enrollment

CSP/IdP が、正常に identity proofing を完了した applicant に対して subscriber account を提供し、永続的アクセスを付与するために authenticators をバインドするプロセス。

entropy

攻撃者が秘密値を特定する際に直面する不確実性の量。Entropy は通常ビットで表される。n ビットの entropy を持つ値は、一様分布する n-bit の乱数値と同程度の不確実性を持つ。

factor

authentication factor を参照。

Federal Information Processing Standards (FIPS)

NIST（米国商務省の一部）が策定する、連邦省庁および機関が採用・使用するための標準。FIPS は、共通の品質、セキュリティ、相互運用性の水準を達成するために、情報技術に関するトピックを扱う。FIPS 文書は、FIPS ホームページでオンライン入手できる: https://www.nist.gov/itl/fips.cfm

federation

networked なシステム群をまたいで、アイデンティティおよび authentication 情報を伝達できるようにするプロセス。

federation assurance level (FAL)

federation transaction において、authentication イベントおよび subscriber attributes を RP に伝達するために使用されるプロセスを記述するカテゴリ。

hash function

任意長のビット列を固定長のビット列へ写像する関数。承認された hash functions は、以下の性質を満たす。

1. 一方向性 — 事前に指定された任意の出力に写像される入力を見つけることが、計算上実行不可能である。
2. 衝突耐性 — 同一の出力に写像される 2 つの異なる入力を見つけることが、計算上実行不可能である。

identifier

与えられた文脈において、単一の一意な主体（例：個人、デバイス、または session）に関連付けられるデータオブジェクトであり、その文脈内の他の主体に決して割り当てられないもの。

identity

digital identity を参照。

identity assurance level (IAL)

subject の claimed identity が実在のアイデンティティであることに対する信頼度を伝えるカテゴリ。

identity evidence

claimed identity の現実世界での実在を裏付ける情報または文書。Identity evidence は、物理的（例：運転免許証）である場合も、デジタル（例：モバイル運転免許証やデジタル assertion）である場合もある。Evidence は、validation（すなわち authenticity と正確性の確認）と verification（すなわち applicant が evidence の真の所有者であることの確認）の両方を支援しなければならない。

identity proofing

subject に関する情報を収集し、検証し、確認することで、subject の claimed identity に対する保証を確立するためのプロセス群。

identity provider (IdP)

federation transaction において subscriber の assertion を作成し、その assertion を RP に送信する当事者。

injection attack

攻撃者が、信頼されない biometric 情報または媒体をプログラムやプロセスに入力する攻撃。たとえば、偽造した identity evidence 画像、ユーザーの偽造動画、または変形（morph）画像を注入して、evidence validation 技術やユーザー確認のための生体・視覚比較を回避することが含まれ得る。

manageability

alteration、deletion、selective disclosure を含む、personal information のきめ細かな管理を行う能力を提供すること。[NISTIR8062]

memorized secret

password を参照。

message authentication code (MAC)

symmetric key を用いてデータに付与する暗号学的チェックサムであり、偶発的および意図的なデータ改変の双方を検出する。MAC は authenticity と完全性の保護を提供するが、non-repudiation の保護は提供しない。

mobile code

通常、別のコンピュータシステムで実行するために、ソースから転送される実行可能コード。この転送はしばしば network を介して行われる（例：ウェブページに埋め込まれた JavaScript）が、物理媒体を介して転送される場合もある。

multi-factor authentication (MFA)

成功した認証のために、複数の異なる種類の authentication factor を要求する認証システム。MFA は multi-factor authenticator を使用して実行することも、異なる種類の要素を提供する single-factor authenticators を組み合わせて実行することもできる。

multi-factor authenticator

統合された生体センサーを備え、デバイスを有効化するためにそれが必要となる暗号認証デバイスのように、複数の異なる authentication factor を提供する authenticator。

network

open communications medium（通常はインターネット）であり、claimant と他の当事者の間でメッセージを転送するために使用される。別段の記載がない限り、ネットワークは open であり、当事者間（例：claimant、verifier、CSP、RP）のいかなる地点でも、能動的（例：なりすまし、session hijacking）および受動的（例：盗聴）攻撃の対象となり得ると想定される。

nonce

同じ鍵で繰り返し使用されない、セキュリティプロトコル内で使用される値。たとえば、challenge-response authentication protocols におけるチャレンジとして使用される nonce は、authentication keys が変更されるまで繰り返してはならない。そうでない場合、replay attack の可能性がある。Nonce をチャレンジとして用いることは、ランダムチャレンジであることとは異なる要件である。なぜなら nonce は必ずしも予測不能である必要がないためである。

non-repudiation

個人が特定の取引を実行したことを虚偽に否認することから保護する能力。

offline attack

攻撃者が何らかのデータ（例：認証トランザクションの盗聴、またはシステム侵入とセキュリティファイルの窃取）を入手し、攻撃者が選択した自前のシステムでそのデータを分析できる攻撃。

online attack

authentication protocol に対する攻撃であり、攻撃者が genuine な verifier に対して claimant の役割を引き受けるか、または認証チャネルを能動的に改変する。

online guessing attack

攻撃者が繰り返しログオン試行を行い、authenticator output の可能な値を推測する攻撃。

passphrase

claimant が自らのアイデンティティを authenticate するために使用する、単語列またはその他のテキストから成る password。Passphrase は使用上 password と似ているが、一般に安全性を高めるために長い。

password

認証プロセスの一部として something they know を示すために、subscriber が記憶できる（または記憶に残りやすい）ことを意図した文字列から成る authenticator の一種。SP 800-63B の初版では、password は memorized secrets と呼ばれていた。

personal identification number (PIN)

通常は 10 進数字のみから成る password。

personal information

個人のアイデンティティを、単独で、または特定の個人にリンクされる（またはリンク可能な）他の情報と組み合わせることで、識別または追跡できる情報。

pharming

攻撃者が subscriber を詐欺的なウェブサイトへリダイレクトさせる攻撃であり、通常は認証の文脈における詐欺的な verifier/RP である。これにより subscriber が、機微情報（例：password）を攻撃者に開示したり、有害なソフトウェアをダウンロードしたり、不正行為に加担したりする可能性がある。これは、インフラサービス（例：DNS）を破壊するか、subscriber の endpoint を汚染することで実現され得る。

phishing

攻撃者が、subscriber を（通常はメールを通じて）偽造された verifier/RP とのやり取りに誘導し、その subscriber を real な verifier/RP に対してなりすますために使用できる情報を開示させるよう欺く攻撃。

phishing resistance

claimant の注意深さに依存せずに、authentication protocol が、なりすましの verifier に対して authentication secrets および有効な authenticator outputs の開示を防ぐ能力。

physical authenticator

認証プロセスの一部として、claimant が所持を証明する authenticator。

possession and control of an authenticator

authentication protocol において authenticator を有効化して使用できる能力。

predictability

個人、所有者、運用者が、personal information とそれを processing する情報システムについて、信頼できる前提を置けるようにすること。[NISTIR8062]

presentation attack

生体データ取得サブシステムに対し、生体システムの動作を妨害することを目的として提示する行為。

presentation attack detection (PAD)

presentation attack の自動判定。Presentation attack 判定手法（すなわち liveness detection）の一部では、解剖学的特徴の測定・分析、または随意・不随意の反応の測定・分析を行い、biometric sample が、生体の subject が取得地点に存在する状態で取得されているかどうかを判断する。

Privacy Impact Assessment (PIA)

personal information がどのように収集され、使用され、共有され、維持されるかを分析する方法。PIA は、プログラムやシステムの開発ライフサイクル全体を通じてプライバシーリスクを特定し、低減するために用いられる。また、情報の取り扱いがプライバシーに関する法令・規制・ポリシー要件に適合することを確保する助けにもなる。

private key

public-key 暗号アルゴリズムで使用される暗号鍵であり、主体に一意に関連付けられ、公表されない。Asymmetric-key（public-key）暗号システムでは、private key に対応する public key が存在する。アルゴリズムによって、private key は次の目的に使用され得る。

1. 対応する public key を計算する。
2. 対応する public key により検証できるデジタル署名を計算する。
3. 対応する public key で暗号化された鍵を復号する。
4. 鍵合意トランザクションにおいて共有秘密を計算する。

protected session

2 者間のメッセージが暗号化され、完全性が “session keys” と呼ばれる shared secrets の集合によって保護される session。Protected session は、片方の参加者が session keys に加えて 1 つ以上の authenticators の所持を証明し、もう一方が当該 authenticator に関連付けられたアイデンティティをセッション中に検証できる場合、authenticated であると言う。両者が認証されている場合、protected session は mutually authenticated であると言う。

pseudonym

法的氏名ではない名前。

pseudonymous identifier

無意味だが一意な identifier であり、RP が subscriber に関して推測できない一方で、RP が単一 subscriber による複数のやり取りを関連付けられるようにするもの。

public key

public-key 暗号アルゴリズムで使用される暗号鍵であり、主体に一意に関連付けられ、公表され得る。Asymmetric-key（public-key）暗号システムでは、public key に対応する private key が存在する。Public key は誰でも知り得るものであり、アルゴリズムによって次の目的に使用され得る。

1. 対応する private key を用いて生成されたデジタル署名を検証する。
2. 対応する private key により復号できる鍵を暗号化する。
3. 鍵合意トランザクションにおいて共有秘密を計算する。

public-key certificate

認証局の private key により発行され、デジタル署名されたデジタル文書であり、identifier を subscriber の public key にバインドする。証明書は、証明書に記載された subscriber が private key を単独で制御しアクセスできることを示す。[RFC5280] も参照。

public-key infrastructure (PKI)

証明書および公開鍵・秘密鍵ペアを管理するために使用される、ポリシー、プロセス、サーバープラットフォーム、ソフトウェア、ワークステーションの集合。これには、public-key certificates の発行、維持、失効ができる能力が含まれる。

reauthentication

延長された利用 session 中に、subscriber が引き続き存在し、authenticated である意思があることを確認するプロセス。

relying party (RP)

subscriber のアイデンティティに関する verifier の assertion に依拠する主体。通常、取引を処理する、または情報やシステムへのアクセスを付与するために用いられる。

remote

対面ではなく、接続されたデバイスを介して network 上で実施されるプロセスまたは取引。

replay attack

攻撃者が、正当な claimant と verifier の間で以前に捕捉したメッセージを再送することで、verifier に対してその claimant になりすましたり、あるいはその逆になりすましたりできる攻撃。

replay resistance

authenticator output を特定の認証に対してのみ有効にすることなどにより、認証プロセスが replay attacks に耐性を持つという性質。

restricted authenticator

追加の false acceptance リスクを伴う authenticator type、class、または具現化（instantiation）であり、そのため追加要件の対象となる。

risk assessment

システムの運用によって生じる、組織の運用（すなわち mission、functions、image、reputation）、組織資産、個人、他組織に対するリスクを特定し、見積もり、優先順位付けするプロセス。Risk assessment は risk management の一部であり、脅威および脆弱性の分析を取り込み、計画済みまたは実装済みのセキュリティ controls による緩和策を考慮する。“risk analysis” と同義である。

risk management

情報セキュリティリスクを管理するためのプログラムおよび支援プロセスであり、組織の運用（すなわち mission、functions、image、reputation）、組織資産、個人、他組織に対するリスクを扱う。これには、(i) リスク関連活動の文脈の確立、(ii) リスク評価、(iii) リスクが特定された後の対応、(iv) 時間経過に伴うリスクの監視、が含まれる。

salt

暗号処理で使用される非秘密値であり、通常は、あるインスタンスに対する計算結果が攻撃者によって再利用されないことを確保するために使用される。

Senior Agency Official for Privacy (SAOP)

機関がプライバシー要件に準拠し、プライバシーリスクを管理し、personal information を伴う機関の行動やポリシーすべてのプライバシー影響を考慮することを確実にする責任者。

session

subscriber と endpoint（RP または CSP のいずれか）との間の永続的な相互作用。Session は認証イベントから開始し、セッション終了イベントで終わる。Session は、subscriber のソフトウェア（例：ブラウザ、アプリケーション、OS）が RP に提示できるセッション秘密の使用によって拘束され、当該セッションが認証イベントに関連付いていることを RP に対して証明する。

session hijack attack

成功した認証交換の後に、攻撃者が claimant と verifier の間に割り込める攻撃。攻撃者は verifier に対して subscriber を装ったり、あるいはその逆を装ったりして、session データ交換を制御できる。Claimant と RP の間の sessions も同様に侵害され得る。

shared secret

subscriber と verifier に共有されている、認証に使用される秘密。

side-channel attack

物理的暗号システムからの情報漏えいによって可能となる攻撃。Side-channel attack に悪用され得る特性には、タイミング、消費電力、電磁波放射、音響放射が含まれる。

single-factor

成功した認証のために 1 つの authentication factor（すなわち something you know / something you have / something you are）のみを要求する、認証システムまたは authenticator の特性。

single sign-on (SSO)

1 つのアカウントとその authenticators を用いて、複数のアプリケーションにシームレスにアクセスする認証プロセス。一般に federation protocol により実装される。

social engineering

個人を欺いて機微情報を開示させたり、不正アクセスを得たり、詐欺を行わせたりする行為であり、その個人と関係を築いて信頼を得ることで行われる。

subject

人、組織、デバイス、ハードウェア、network、ソフトウェア、またはサービス。本ガイドラインにおいて subject は natural person である。

subscriber

CSP のアイデンティティサービスに enrollment された個人。

subscriber account

CSP が、それぞれの subscriber に対して自らのアイデンティティサービスに enrollment する際に確立するアカウントであり、subscriber に関する情報と、subscriber に登録された authenticators の記録を含む。

symmetric key

暗号操作とその逆操作（例：暗号化と復号、または message authentication code の生成と検証）の双方を実行するために使用される cryptographic key。

sync fabric

ユーザーのデバイスにローカルではない、syncable authenticators によって生成された authentication keys を保存・送信・管理するために使用される、オンプレミス、クラウドベース、またはハイブリッドのサービス。

syncable authenticators

authentication keys を複製・エクスポートして他の保管場所に移し、それらの鍵を他の authenticators（すなわちデバイス）に同期できる、ソフトウェアまたはハードウェアの暗号 authenticators。

system of record (SOR)

機関の管理下にある、個人に関する情報を含む記録の集合。記録は、個人の名前、識別番号、記号、または他の identifier によって検索できる。

System of Records Notice (SORN)

連邦機関が Federal Register に掲載し、自らの system of record を説明するための通知。

token

authenticator を参照。

transaction

digital transaction を参照。

Transport Layer Security (TLS)

ブラウザおよび web servers で広く実装されている、認証およびセキュリティプロトコル。TLS は、機密性、受信（server）endpoint の証明書ベース認証、送信元（client）endpoint の証明書ベース認証を提供する。TLS は [RFC8446] および [SP800-52] によって規定されている。

usability

指定された利用文脈において、指定されたユーザーが、効果性、効率性、満足度を伴って指定された目標を達成するために製品を利用できる程度。[ISO/IEC9241-11]

validation

applicant が提示した evidence と attributes が真正であり、正確であり、現実世界のアイデンティティに関連付いていることを確認するプロセスまたは行為。attribute validation を参照。

verification

identity proofing を受ける applicant が、検証済みの ID attributes と関連する evidence が表す、主張された現実世界のアイデンティティの保持者であることを確認するプロセスまたは行為。identity verification と同義。

verifier

claimant が authentication protocol を用いて 1 つ以上の authenticators を所持し制御していることを検証することで、claimant のアイデンティティを確認する主体。これを行うために、verifier は、authenticators と subscriber account のバインディングを確認し、subscriber account がアクティブであることを確認する必要がある。

verifier impersonation

phishing を参照。

Change Log

This appendix is informative.

本付録は、SP 800-63B の初版以降に行われた変更の概要を示す。

• Purpose、Definitions、Abbreviations の番号付きセクションを削除し、それに応じてセクション番号を振り直した。以下で参照されるセクション番号は、新しいセクション番号である。
• memorized secrets の名称を passwords に変更
• Section 2: 事前の認証チェックではなく、不正指標（fraud indicators）の利用を記述
• Section 2.3.2: AAL3 における authenticators の必須 FIPS 140 検証レベルを引き下げ
• Section 2.3.2: AAL3 において、ハードウェアベース authenticator ではなく、エクスポート不可の cryptographic authenticator を要求
• Section 3.1.1.2: 単一の認証要素として使用される passwords の最小長を増加
• Section 3.1.3: Out-of-band 認証において、primary と secondary channel の間で secrets を比較することを不許可
• Section 3.1.3.1: Out-of-band 認証における VoIP 電話番号の使用禁止を削除
• Section 3.1.3.4: Activation factor を要求する multi-factor out-of-band authenticators を認定
• Section 3.1.4 および Sec. 3.1.5: OTP アプリケーションを認識するために authenticator 名から “devices” を削除
• Section 3.1.6 および Sec. 3.1.7: Authenticator 名から “software” と “device” の区別を削除し、“authenticator characteristics” として参照
• Section 3.1.7.3: Subscriber が制御する wallets を用いた認証に関する要件を追加
• Section 3.1.7.4 および Appendix B: Syncable authenticators に関する要件を追加
• Section 3.2.3: Biometric の性能要件とメトリクスを更新
• Section 3.2.3.2: 顔認識に PAD を要求し、音声に基づく biometric comparison を禁止
• Section 3.2.5: Phishing-resistant authenticators の定義を追加し、要件を更新
• Section 3.2.10: activation secrets として知られる、ローカル検証される memorized secrets に関する要件を分離して確立
• Section 3.2.11: NFC および Bluetooth などの無線技術で接続される authenticators に関する要件を追加
• Section 3.2.11.3: Hybrid connections を、接続型 authenticators のクラスとして認定
• Section 3.2.12: 文書全体で使用されるランダム値に関する要件を集約
• Section 3.2.13: Authenticator secrets の非エクスポート性に関する要件の新セクションを追加
• セクション削除: Verifier compromise resistance を、個別に名付けられた要件として削除（一般に、選択した authenticator type の特性であるため）
• Section 4: セクション名を “Authenticator Event Management” に変更
• Section 4.1.1: Enrollment 時の binding を SP 800-63A へ移動
• Section 4.1.2.1: 追加 authenticator の binding を、すべての AAL に一般化
• Section 4.1.2.2: Endpoint に接続されない authenticators の binding 要件を追加
• Section 4.2: Account recovery の要件および方法を改訂
• Section 4.6: Subscribers に送信される notifications の要件を改訂
• Section 5.1: Device-bound session credentials の使用を認定
• Section 5.1.1: セッション維持に使用される browser cookies に関する要件を追加
• Section 5.2: Reauthentication 要件を改訂し、ここで reauthentication の全体構造を定義するとともに、AAL 要件内で timeout 値を規定
• Section 5.3: Session monitoring（continuous authentication）の使用に関するガイドラインを追加