1. Purpose

2. Introduction

3. Definitions and Abbreviations

4. Authenticator Assurance Levels

5. Authenticator and Verifier Requirements

6. Authenticator Lifecycle Requirements

7. Session Management

8. Threats and Security Considerations

9. Privacy Considerations

10. Usability Considerations

11. References

Appendix A — Strength of Memorized Secrets

1 Purpose

This section is informative.

informativeとは、「参考」程度の意味合いである。規格内でこれに対抗するのが"normative"である。normativeと言われたら、そこでは何かが決められ、それに従うことが求められる。

This document and its companion documents, Special Publication (SP) 800-63, SP 800-63A, and SP 800-63C, provide technical guidelines to agencies for the implementation of digital authentication.

2 Introduction

これからNIST SP800-63Bの逐条解説を試みるわけであるが、ネットには、 すでに（正確なものからジャーナリスティックなものまで含め）多くの解説が試みられている。 ここで新たに稿を起こす目的について、少し述べる。

1. NISTのこの文書は、「米連邦政府の提供するサービスで行う認証」がimplicitに仮定されている。日本では、それなりの変更を加える必要があるだろう。そのためにも、本文書の背景と技術についての知識を持っているべきである。
2. 技術は世界共通だから、Bについてはあまり影響を受けないかもしれない。しかし、法制度、ビジネス慣行、過去のインシデントからの教訓の蓄積が異なる以上、何が適用できて、何がそのままではだめかについては、上で述べたような知識が必要である。より具体的に言えば、「NISTのBに書いてあるから...」といわれても困るということである。
3. 文書Bについては、FIDOをはじめとする他団体提供技術についての知識が必須である。直接は書き込まないにしても、リンクくらいは貼っておかないと読めない。
4. これが制定されたのが2017年で、そこからの技術の進展を追う必要がある。

そこで、日本語で、各文章に対してコメントを入れることにより、逐条のような形で解説を試みることにした。 日本語訳も存在するが、ここでは「わざと」原文に対して注釈を入れ、必要だと考えたところは適宜和訳することにした。
もう一つ、筆者の関係する 学認でも、 パスワードを超えた認証強度への期待が強くなってきたことがある。2004年の オリジナルの800-63では、レベル1と2の間に大きな差があり、レベル2対応が特殊な ケースを除いて難しかった。ところが近年、スマホ、FIDOなどの技術の進展により レベル2でも対応が可能になったこと。リスク評価の結果、暗号ソフトウェア（典型的なものは ハードディスクのキーチェインに格納する電子証明書）の評価が高くてよいとなったことである。 よって、以前、筆者が提案したようなレベル (N±ε)とか、1.5のような工夫が不要に なったことがある（論文は恥ずかしいのでリンクを貼らない）。
したがって、特にAALレベル2の正確な理解が十分ペイするようになった。これはチャンスだ。 …というのがもう一つの動機である。

This section is informative.

Digital identity is the unique representation of a subject engaged in an online transaction. A digital identity is always unique in the context of a digital service, but does not necessarily need to be traceable back to a specific real-life subject. In other words, accessing a digital service may not mean that the underlying subject’s real-life representation is known. Identity proofing establishes that a subject is actually who they claim to be. Digital authentication is the process of determining the validity of one or more authenticators used to claim a digital identity. Authentication establishes that a subject attempting to access a digital service is in control of the technologies used to authenticate. For services in which return visits are applicable, successfully authenticating provides reasonable risk-based assurances that the subject accessing the service today is the same as the one who accessed the service previously. Digital identity presents a technical challenge because it often involves the proofing of individuals over an open network and always involves the authentication of individuals over an open network. This presents multiple opportunities for impersonation and other attacks which can lead to fraudulent claims of a subject’s digital identity.

ここまでは、本体、ABCに共通の部分である。オンラインの情報処理に使われる ディジタルアイデンティティと現実世界のアイデンティティの乖離が、いろいろな問題を 引き起こしている。 "fraudulent claims"がそうである。"fraudulent"は、業界で 標準的に使われている「不正な」に対応する形容詞である。 乖離を埋めるためには、アイデンティティの証明（identity proofing）と認証（authentication）が必要であるということを強調する。

なお、（IT）業界ではidentity（アイデンティティ）とidentifier（ID）をしばしば混同して 使うようであるが、これはよろしくない。本文書でもidentityは多少長くなっても「アイデンティティ」と書くことにする。ついでに混乱させれば、IDはidentity documentの略語としても用いられる。文書Aで頻繁に出てくるものである。 言葉遣いは正確に

The ongoing authentication of subscribers is central to the process of associating a subscriber with their online activity. Subscriber authentication is performed by verifying that the claimant controls one or more authenticators (called tokens in earlier versions of SP 800-63) associated with a given subscriber. A successful authentication results in the assertion of an identifier, either pseudonymous or non-pseudonymous, and optionally other identity information, to the relying party (RP).

ここでは認証という行為を定義している。 "subscriber" は、最近は「サブスク」という意味不明の略語で一気になじみになったが、ここでは「サービスを受けるために、アイデンティティが確認され、identifierや認証トークンなど、認証のための何らかの情報を与えられているもの」程度の意味で用いられている。定義は800-63文書の附録Aで与えられている。ただし、 定義を見ても全体から見ての役割はわからない。以下のような感じである。

      [普通の人] ---> (登録) ---> [利用者] --+
                     credential --^       |
                                          v

      [claimant(主張する者))------------- 検証 --> (identifierと紐づけ) 
    
    

図のうち、上の方は文書Aで論じられる「アイデンティティのライフサイクル」の一部になる。 認証関係なら、この変で十分であろうということだが、文書Aで該当する部分をを理解することはどのみち必要になる。

subscriberは以後、頻繁に出てくる用語である。 文書Bでは、以前に使われていた"token"という語はまとめて"authenticator" （認証器）に 置き換えられた。 これは、認証に使うための道具が多様化し、また、プロセスも多様化していることを反映している。 例えば、現在の「スマホでの指紋認証」は、強い認証器として人気の高いものであるが、これを 「トークン」ということは難しい。

ここで認証は次のように定義される。「当該subscriber（利用者）と結びついている一つ以上の認証器を、認証当事者の制御下に置いていることを検証することと」

「一つ以上」は、多要素認証をにらんでのことである。 claimantは「（そう）主張する者」の意味で用いている。認証が成功する前の段階にいる者に対してこの語を用いている。定義は附録Aで与えられている。

これに限らず、アイデンティティでは、認証の前後をはじめとして、様々なステージが考えられ、それぞれに名前が与えられていることがある。本文書は、きちんとこの考えに対応しているので、以後注意して読むとよい。

認証が成功すると、RPが認識するidentifierへの紐づけが行われる。identifierは仮名の可能性がある。現状技術では、生のアイデンティティをRPが把握するということもなかなかはばかられる雰囲気があり、仮名をidentifierに用いることも普通に採用されている。SAMLの出始めでは、 RPどうしで名寄せをして、利用者のプライバシーを侵害する危険性が指摘されてきた。状況はますます悪くなっている。

This document provides recommendations on types of authentication processes, including choices of authenticators, that may be used at various Authenticator Assurance Levels (AALs). It also provides recommendations on the lifecycle of authenticators, including revocation in the event of loss or theft.

この文書ではAALを定義することをここで宣言する。レベルは3つ定義する。 レベルを複数定義するというのは、21世紀初めの旧バージョンを踏襲しているが、 そのねらいとして「目的に応じて、強度の異なる認証を要求してよい」というRP側の 要求の反映ということがある。これ自身は非常に意味のあることであり、 うまく回るとよいと思う。 2020年時点でこれがまだあまりうまく行っていないことにはいくつか原因がある。

1. レベルを分けたのは良いが、高いレベルを要求するサービスが、ごく特殊なものに限られ、複数のレベルという概念が普及しなかった。
2. こちらの方が罪が重いと思うのだが、トラストフレームワークを複数レベルで 構築しようとしたときに、IdPにLoAという意味で格差をつけることを容認した。 普及前にこういうことをすると、多くのIdPは当然委縮する。

こういう意味で、認証レベルは不幸の道をたどったのだが、最近の実際の 消費者をめぐる動き、特にフィッシングを含むWebへの認証関係の攻撃に 対応するために、パスワードに代わる認証器の開発が急務になってきたことから、 「高いレベル」はようやく現実的になってきたと言えるだろう。 先人の轍を踏まず、仲良くやってほしいものである。

なお、「認証器のライフサイクル」という言葉が 出てきている。最近、認証システムが大規模化するにつれ、失効処理が現実的に大きな問題になっている。 失効は、もともと静脈系サービスである認証の中でも静脈系の最たるもので、今までは「何とかなるだろう」と後回しにされてきたものが、そうもいかなくなったということである。筆者も、 割と強力な暗号（ABE）が研究対象になったりしているのだが、失効がスケールしないということで、 いろいろめんどくさい。

This technical guideline applies to digital authentication of subjects to systems over a network. It does not address the authentication of a person for physical access (e.g., to a building), though some credentials used for digital access may also be used for physical access authentication. This technical guideline also requires that federal systems and service providers participating in authentication protocols be authenticated to subscribers.

前半はスコープの限定で、ネットワーク越しの認証が対象だということを宣言する。 後半は、「連邦政府のシステム、サービスが、利用者に対して認証されること」も要求するということで、逆方向も当てはまることを宣言する。ここで"federal"という語が出てきた。以後、あまり積極的には用いられないが、基本的に米連邦政府を想定した文書であることを示唆するものである。

The strength of an authentication transaction is characterized by an ordinal measurement known as the AAL. Stronger authentication (a higher AAL) requires malicious actors to have better capabilities and expend greater resources in order to successfully subvert the authentication process. Authentication at higher AALs can effectively reduce the risk of attacks. A high-level summary of the technical requirements for each of the AALs is provided below; see Sections 4 and 5 of this document for specific normative requirements.

認証強度（strength of an authentication transaction）は認証信頼レベル (AAL) で特徴づけると言っている。ということは、AALでは、関係するすべての要素が評価対象に なることをいっている。AALの評価基準は、後述する通り以下のものがある。 もちろん、軽重がある。

Authenticator Assurance Level 1: AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.

AAL1は、主張者が利用者アカウントに結びついた認証器を制御していることに関する"some"信頼度を 持っていることを表している。800-63の前の版でもそうだったのだが、"some"が意味するところは 「高くはないけどそれなりの」程度ということ。 これだけでは定義になっていないので、具体的に「よく使われている単要素認証、または多要素認証」と 言っているが、もちろん、その具体性は後になるまでわからない。

Authenticator Assurance Level 2: AAL2 provides high confidence that the claimant controls an authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.

AAL2は"high confidence"を要求するわけで、そのために2種類の異なる認証要素を持っていることを具体的に要求する。本文書では、このあたりから本気がでている。

Authenticator Assurance Level 3: AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication requires a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device may fulfill both these requirements. In order to authenticate at AAL3, claimants are required to prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.

AAL3は、"very high confidence"を要求するものである。ハードウェアのサポートを この時点で要求する。

The following table states which sections of the document are normative and which are informative:

Section Name	Normative/Informative
1. Purpose	Informative
2. Introduction	Informative
3. Definitions and Abbreviations	Informative
4. Authenticator Assurance Levels	Normative
5. Authenticator and Verifier Requirements	Normative
6. Authenticator Lifecycle Management	Normative
7. Session Management	Normative
8. Threat and Security Considerations	Informative
9. Privacy Considerations	Informative
10. Usability Considerations	Informative
11. References	Informative
Appendix A — Strength of Memorized Secrets	Informative

3 Definitions and Abbreviations

See SP 800-63, Appendix A for a complete set of definitions and abbreviations.

4 Authenticator Assurance Levels

This section contains both normative and informative material.

To satisfy the requirements of a given AAL, a claimant SHALL be authenticated with at least a given level of strength to be recognized as a subscriber. The result of an authentication process is an identifier that SHALL be used each time that subscriber authenticates to that RP. The identifier MAY be pseudonymous. Subscriber identifiers SHOULD NOT be reused for a different subject but SHOULD be reused when a previously-enrolled subject is re-enrolled by the CSP. Other attributes that identify the subscriber as a unique subject MAY also be provided.

慣れていない人はまずここでつまずく。ここで使われている分化された概念のいくつが有用かは、きっと後で議論の対象になり、それなりに整理されると思うが、とりあえず解説しておく。

ここで言われていることは「認証レベルを満たすということは、『そう主張する者 (claimant) 』が、そこで要求されている強度で認証され、RPの『利用者 (subscriber)』として認識されること」の 解説である。 前に出てきた図を再掲する。

　　　　　　　　　　　登録局
      [普通の人] ---> (登録) ---> [利用者] --+
                     credential --^       |
                        CSP               V

      [claimant(主張する者))------------- 検証 --> (identifierと紐づけ) 
    
    

RP側の検証が成功すると、認証が成功したことになり、利用者はidentifierを得る。 identifierは仮名でも構わない。 ここで、明示的ではないが、認証を行うための認証情報 (credential) を発行、 管理するものとしてCSP (credential service provider) が想定されている。

CSPについては本体の文書で説明されているが、この文書、および関連文書で 頻繁に使われている、著者のグループのお気に入りの概念である。

利用者のidentifierは、他の実体 (subject)に対して使うべきではないということは、 二つ意味があって、1つは共有idの禁止、もう一つは失効したidを他人に 対して再利用することの禁止を意味する。どちらも行動の追跡に支障をきたす。 後者については再登録（re-enroll）した時は、同じidentifierを割り当てられるべきだとも言っているが、これはre-enrollの範囲による。一度archiveされたり、suspendされているものであれば管理は楽だが、例えば一度大学を卒業して修飾し、10年後に 別の学部に再入学する人に同じサービスを提供できるかについては、CSPではなくて 登録局の努力が必要になるだろう。

どちらにせよ、ここ、特に後半ではアイデンティティのライフサイクル管理が 想定されていて、わかりやすいとは言えない。記述の整理が必要。

Detailed normative requirements for authenticators and verifiers at each AAL are provided in Section 5.

See SP 800-63 Section 6.2 for details on how to choose the most appropriate AAL.

FIPS 140 requirements are satisfied by FIPS 140-2 or newer revisions.

FIPS140-2は、暗号関係の技術で大切な文書であり、以後しばしば引用される。 「暗号モジュールに対するセキュリティ上の要求要件」で2002年以降、アップデートされていないが、良いのか？ 本体はここ 伝統的にレベルを4つに分けている。誰か、いっしょに再検討して、コメントをNISTにあげてみませんか？

At IAL1, it is possible that attributes are collected and made available by the digital identity service. Any PII or other personal information — whether self-asserted or validated — requires multi-factor authentication. Therefore, agencies SHALL select a minimum of AAL2 when self-asserted PII or other personal information is made available online.

PII（個人特定情報）の扱いからくる制限について述べている。 IAL1では、属性情報を収集してよいレベル（＝収集されることで重大な プライバシー侵害を引き起こすような情報は、IAL1には含めてはいけない）である。 一方PIIは、そうされては困ることを想定しているわけで、必然的に PIIを扱うならば、認証レベルは最低限AAL2と言っている。

これはあっさりしているが、結構重要な文章である。 この文書の力点はAAL2に置かれるようになった。

このセクションでは、各認証レベルの概念的な要求要件を述べ、 具体的な認証器に対する要求要件は次のセクションに回されている。

以下では、基準を述べていくわけであるが、その根拠になる方法論のリスク解析は 本体に述べられている。その意味では本体を押えておくのは必須。

4.1 Authenticator Assurance Level 1

This section is normative.

AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.

AAL1は、"some"保証を与えればよいとされる。 今まで使われてきた、広い範囲の認証方法を使うことが想定されている。 AAL1の認証が成功するということは、「セキュアな認証プロトコルを通じて、 認証器を保有し、制御していることを『そう主張するもの』が証明する」ことを 満たさなければならない。 つまり、 「他の者が認証器を使っているのではない」「プロトコルがセキュアである」（これはセッション管理も含まれる）ことが「ある程度」保証される形で 示されなければならないということである。 この書き方により4.1.2 「検証側の要求要件」4.1.3 「再認証」4.1.4 「セキュリティの統制」 4.1.5「記録の保存」という評価軸がたてられた。 ここらへんの何気ない（抽象的な）書き方で、章立てに対する合理化がなされていることに注意すべきである。

4.1.1 Permitted Authenticator Types

許容される認証器を以下に列挙する。

AAL1 authentication SHALL occur by the use of any of the following authenticator types, which are defined in Section 5:

• Memorized Secret 記憶秘密（パスワード一択だと思ってよい）(Section 5.1.1)
• Look-Up Secret 参照秘密（乱数表など）(Section 5.1.2)
• Out-of-Band Devices アウトオブバンド装置（けーたいなど）(Section 5.1.3)
• Single-Factor One-Time Password (OTP) Device 単要素ワンタイムパスワード (TOTP) 装置(Section 5.1.4)
• Multi-Factor OTP Device 多要素OTP装置（上との違いは、セクション5で）(Section 5.1.5)
• Single-Factor Cryptographic Software 単要素暗号ソフトウェア（HDに保存されている、パスワード不要の秘密鍵など）(Section 5.1.6)
• Single-Factor Cryptographic Device 単要素暗号装置（上のハードウェア版）(Section 5.1.7)
• Multi-Factor Cryptographic Software 多要素暗号ソフトウェア（HDに保存され、かつパスワードが設定されているものなど）(Section 5.1.8)
• Multi-Factor Cryptographic Device 多要素暗号装置（上のハードウェア版）(Section 5.1.9)

アウトオブバンドとは、 インターネットでオンラインで認証を行うことを前提に考えれば、 インターネットの外にある通信網を使ったものを指す。公衆電話網はその代表である。 網がインターネットの技術を利用していても、 (The) インターネットから切り離されているならそれでよい。 後で、侃々諤々の議論が展開されると思うが、SMSはこれに分類される。
out-of-bandはここではアウトオブバンドとそのまま言うことにしたが、 副チャネルのことである。ただ副チャネルとするとside channelと区別がつかない。 世の中は、用語がそれなりに乱れていて、たとえば アウトバンドメモリ (out-of-band memory)などと 言ったりするらしい。

暗号ソフトウェア・装置とは、暗号を利用する時に用いる鍵（この場合、公開鍵暗号、対称暗号どちらも考えられる）をソフトウェアでHDに格納しているか、 他から容易にアクセスできないハードウェアに格納しているものをいう。

これらの設定は、アメリカ内のインシデントの観察等からくる リスク評価がベースになっているはずである。繰り返しになるが、 日本には日本のリスク評価がある。技術の点からは世界で境界はないと考えてよいが、 法制度やそれを元にした規制など、リスク評価の結果は日米では異なる可能性がある。

4.1.2 Authenticator and Verifier Requirements

最初の要求要件を定める軸。 Verifierは、認証を検証するもの。セキュリティ業界では

1. 証明者（ここでは、認証器を統制しているということの証明のために エビデンスを提出する者。たいていは『そう主張するもの』が、利用者と 認められるまでのステージ）
2. 検証者（提出されたエビデンスを検証して、「証明」を信じても良いと いってくれる者。）

の区別をする。多分に研究業界から来た用語のような気もするし、研究に 関係なければあまり悩む必要はない。

Cryptographic authenticators used at AAL1 SHALL use approved cryptography. Software-based authenticators that operate within the context of an operating system MAY, where applicable, attempt to detect compromise (e.g., by malware) of the user endpoint in which they are running and SHOULD NOT complete the operation when such a compromise is detected.

AAL1のための暗号を用いた認証器は「承認された暗号」を使わなければならないとされる。「承認」はアメリカならFIPS 140-2だし、日本なら総務省あたりの 「政府機関の情報セキュリティ対策のための統一基準」 にあたると考えられるが、日本の場合、「政府機関等」の しばりがあるので、なかなか民間には適用しづらいかもしれない。 アメリカの場合、FIPS140-2の附録が保守されており、そこに 承認済みの暗号のリスト がある（2019年版）。

• 対象鍵暗号、AES, TDEA
• 電子署名、DSA, RSA, ECDSA
• セキュアハッシュ標準、SHA-1, SHA-224, ...
• メッセージ認証（MAC）、3DES, AES, HMAC

日本の場合はCRYPTOREC暗号リストが定められている。Camelliaが追加されていることを 除いてアメリカと同じ。2010年くらいまでは、国産の対称鍵暗号をたくさん 載せていたのだが、NISTの承認をとうとう得られなかったこともあり、2012年に 大量虐殺が行われた。

日本では、技術の点からの基準（standard）づくりが遅れていることは認めざるを得ない。 IPAががんばっていることは認めるのだが…

OSの下動作するソフトウェアベースの認証器が危殆化（compromise）したことを 検知した場合、そこから先の操作を完了させるべきではないとしている。
ここでendpointという言葉が出てきて、以後「端末」の語を充てるが、これはユーザーと直接入出力を行う装置やソフトウェアのことをいう。USBに認証器が接続されていて、それを使うのであれば その認証器が「端末」である。

Communication between the claimant and verifier (using the primary channel in the case of an out-of-band authenticator) SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to man-in-the-middle (MitM) attacks.

こちらは、「そう主張する者」と「検証者」の間の通信についてであるが、 認証で保護されたチャネルを使い、出力の秘密を保証し、中間者攻撃に対する 耐性を持つものでなければならない、と定める。 有体に言えば「TLSを使え」ということである。

Verifiers operated by government agencies at AAL1 SHALL be validated to meet the requirements of FIPS 140 Level 1.

政府機関関係はFIPS 140-2 Level 1適合のものを使うこととされる。 ここにおいても、この文書が米連邦サービスを想定して書かれていることを 示している。

4.1.3 Reauthentication

再認証の話。「再認証」とは、一度認証して、セッションが生き続けている、 または（Cookieなどを通じて）再開される状況に際して、 いつまでもフリーパスではいけないだろう、どこで認証をリセットして やり直すか、ということについて定める。7.2で定められたようにせよ、と 実際に書いていて、それで終わりなのだが、少し書いている。

Periodic reauthentication of subscriber sessions SHALL be performed as described in Section 7.2. At AAL1, reauthentication of the subscriber SHOULD be repeated at least once per 30 days during an extended usage session, regardless of user activity. The session SHOULD be terminated (i.e., logged out) when this time limit is reached.

AAL1では、セッションを張り続けていても、認証のやり直しは30日に1度はすることと定める。時間が来たらセッションは終了させるべきであるとしている。

4.1.4 Security Controls

The CSP SHALL employ appropriately-tailored security controls from the low baseline of security controls defined in SP 800-53 or equivalent federal (e.g. FEDRAMP) or industry standard. The CSP SHALL ensure that the minimum assurance-related controls for low-impact systems, or equivalent, are satisfied.

セキュリティの統制（コントロール）について定める。 対象となるのはCSPである。実際に認証を行う際のシステムのセキュリティを どう管理しているかであるが、認証自体とは関係ないものの、 これが破られると元も子もないので…という感じ。 結果としては「NIST SP800-53でもFEDRAMPでも、その他何でもいいから何か決めた 基準の低いベースラインに従え」と言っている。ここで実は大切なのは 「何らかの基準」ということで、それは外から評価の対象になるものでなければ ならない、ということである。公開されている基準にしたがっているということは、 たとえそれが自己申告であろうとも、ただただ「ちゃんとやっているから大丈夫。 信じてくれ」というのとは確実に異なる。

4.1.5 Records Retention Policy

The CSP shall comply with its respective records retention policies in accordance with applicable laws, regulations, and policies, including any National Archives and Records Administration (NARA) records retention schedules that may apply. If the CSP opts to retain records in the absence of any mandatory requirements, the CSP SHALL conduct a risk management process, including assessments of privacy and security risks, to determine how long records should be retained and SHALL inform the subscriber of that retention policy.

CSPの統制。 National Archives and Records Administration (NARA)というのは、米国立公文書記録管理局のことであり、そこで定める行政文書保存の規則に従えと言っている。 これも連邦政府サービスを前提とした文章。 日本なら「公文書管理法」であるが、行政府自らが守っていないということが近年露呈した。ちなみに、大学では年1回のアップデートが義務付けられている（はずだ）が、 これも、インデックスの管理にとどまっている。 それはともかく、その枠の外にいるCSPについても、自分でリスク管理して 記録保存をすることと言っている。ちなみに、日本においてであるが、 アクセスログの管理は、警察からの指導がある。法律での定めは、あったかなぁ

4.2 Authenticator Assurance Level 2

This section is normative.

AAL2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Proof of possession and control of two distinct authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.

AAL2について定める。「高い信頼度」を要求するのだが、それには 2つの異なる認証要素を使うことを求めている。決めているのはこれくらいで、 各論に入らないと議論が進まないのはAAL1と同じ。

4.2.1 Permitted Authenticator Types

At AAL2, authentication SHALL occur by the use of either a multi-factor authenticator or a combination of two single-factor authenticators. A multi-factor authenticator requires two factors to execute a single authentication event, such as a cryptographically-secure device with an integrated biometric sensor that is required to activate the device. Authenticator requirements are specified in Section 5.

AAL2では、多要素認証、又は単要素認証２つの組み合わせによるものでなければならない。 ２つの違いであるが、前者は、1つの認証イベントを完成するのに2つ要素を実行することを要求し、後者は、2つの認証イベントを要求することにある。もちろん、 具体的なことはセクション5に規定するわけである。

When a multi-factor authenticator is used, any of the following MAY be used:

• Multi-Factor OTP Device 多要素OTP装置　(Section 5.1.5)
• Multi-Factor Cryptographic Software 多要素暗号ソフトウェア　(Section 5.1.8)
• Multi-Factor Cryptographic Device 多要素暗号装置　(Section 5.1.9)

ここまでが許容される多要素認証。

When a combination of two single-factor authenticators is used, it SHALL include a Memorized Secret authenticator (Section 5.1.1) and one possession-based (i.e., “something you have”) authenticator from the following list:

ここからが単要素認証の組み合わせ。そのうちの一つは記憶秘密（パスワード）の 認証器でなければならない。もう一つは、所有に根拠を置く認証器でなければならない。 ここで、巧妙にであるが、パスワード＋生体認証が除外されていることに注意する。 この議論はすぐ後で行う。

• Look-Up Secret 参照秘密　(Section 5.1.2)
• Out-of-Band Device アウトオブバンド装置(Section 5.1.3)
• Single-Factor OTP Device 単要素OTP装置(Section 5.1.4)
• Single-Factor Cryptographic Software 単要素暗号ソフトウェア(Section 5.1.6)
• Single-Factor Cryptographic Device 単要素暗号装置(Section 5.1.7)

Note: When biometric authentication meets the requirements in Section 5.2.3, the device has to be authenticated in addition to the biometric — a biometric is recognized as a factor, but not recognized as an authenticator by itself. Therefore, when conducting authentication with a biometric, it is unnecessary to use two authenticators because the associated device serves as “something you have,” while the biometric serves as “something you are.”

生体認証（ここでは行動認証を含む！）を用いる装置では、生体情報を 用いるためには認証をしなければならないとしている。つまり、生体情報は 単独では認証器と認めない。結論としては、その装置は認証を一度通ったうえで 生体情報を用いるので、それだけで多要素認証の装置と考えることができる。 旧バージョンでは「生体認証は適用範囲に含めない」と、 当時の技術の不確かさもあって、消極的な姿勢を取っていたが、 今回、様々な装置の普及もあり、まじめに考えるようになったのである。 生体認証では「認証する意思」というものが問題になる。 グミによる指紋の模倣（たとえば、古いものだと 2007年のATMARKITの記事）、写真による顔情報の模倣（たとえば、新しいものだと2019年の GIGAZINEの記事）などは前から問題になっていて、 それも「認証する意思」を考えるきっかけとなっている。

4.2.2 Authenticator and Verifier Requirements

Cryptographic authenticators used at AAL2 SHALL use approved cryptography. Authenticators procured by government agencies SHALL be validated to meet the requirements of FIPS 140 Level 1. Software-based authenticators that operate within the context of an operating system MAY, where applicable, attempt to detect compromise of the platform in which they are running (e.g., by malware) and SHOULD NOT complete the operation when such a compromise is detected. At least one authenticator used at AAL2 SHALL be replay resistant as described in Section 5.2.8. Authentication at AAL2 SHOULD demonstrate authentication intent from at least one authenticator as discussed in Section 5.2.9.

前半はAAL1と同じである。後半で追加の要件として、2つの認証要素のうち、 最低1つはリプレイ攻撃への耐性があること（必須）、 さらに「認証の意思」を示しているべきであると定めている。 後者は主に生体認証への対応、前者については後で述べる。

Communication between the claimant and verifier (the primary channel in the case of an out-of-band authenticator) SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to MitM attacks.

Verifiers operated by government agencies at AAL2 SHALL be validated to meet the requirements of FIPS 140 Level 1.

ここらへんはAAL1と同じ。

When a device such as a smartphone is used in the authentication process, the unlocking of that device (typically done using a PIN or biometric) SHALL NOT be considered one of the authentication factors. Generally, it is not possible for a verifier to know that the device had been locked or if the unlock process met the requirements for the relevant authenticator type.

ここで重要なことが決められている（ここをスキップしてはいけない）。 スマホなどでは、ロックを外すのにPINを用いたり、生体認証を使うのが もはや普通になっているが、これを認証要素として採用してはいけないと定めている。 理由として、検証側がロックを外したことを検証できないこと、またロックを外すプロセスが 関係する認証のレベルを満たしているかどうかわからないことを上げているが、 この手の記述には、インシデントの裏があるはずである。 関係あるかどうかわからないが、 浮気調査 のページで ロック解除の（過去使われていた）裏技が紹介されていることなどは、 まぁ、そういうことなんだろうな、と。 また、再認証に関しても、どうい動作仕様になっているかは、検証側では 原則わからないわけであるので、どうしても信用のおける度合いは低くなる。

When a biometric factor is used in authentication at AAL2, the performance requirements stated in Section 5.2.3 SHALL be met, and the verifier SHOULD make a determination that the biometric sensor and subsequent processing meet these requirements.

生体認証をAAL2に使うときの要求要件は5.2.3に述べられている。そこに行ってから 具体的に論じる。

4.2.3 Reauthentication

Periodic reauthentication of subscriber sessions SHALL be performed as described in Section 7.2. At AAL2, authentication of the subscriber SHALL be repeated at least once per 12 hours during an extended usage session, regardless of user activity. Reauthentication of the subscriber SHALL be repeated following any period of inactivity lasting 30 minutes or longer. The session SHALL be terminated (i.e., logged out) when either of these time limits is reached.

Reauthentication of a session that has not yet reached its time limit MAY require only a memorized secret or a biometric in conjunction with the still-valid session secret. The verifier MAY prompt the user to cause activity just before the inactivity timeout.

再認証に関する要求要件は、AAL1と比較して格段に厳しくなっている。

要件	AAL1	AAL2
制限時間	30日	12時間
操作なしの制限時間	--	30分
再認証の方法	--	記憶秘密や生体のみ（1個）でも可

操作なしの場合、セッションが強制的に切られることは、最近は多くの サービスで実装されるようになった。AAL2では必須である。 上の制限時間に達していず、セッションが有効であるときでも、 パスワードや生体認証を折に触れて要求しても良いとされる。 この要件は、セッションが有効であることが強く保証されているからできることであって、 AAL1程度のものでこれをやると、新手のフィッシングと誤解される恐れはある。

4.2.4 Security Controls

The CSP SHALL employ appropriately-tailored security controls from the moderate baseline of security controls defined in SP 800-53 or equivalent federal (e.g., FEDRAMP) or industry standard. The CSP SHALL ensure that the minimum assurance-related controls for moderate-impact systems or equivalent are satisfied.

認証システムのセキュリティであるが、AAL1は最低レベルを満たせばよかったのが、 AAL2では、「中間くらいの」「もう少し上の」レベルを満たせとしている。 ここらへん、例えばFEDRAMPやCSAのSTAR認証でも、最低3つくらいのレベルがあることが 前提とされている。 一方、ベースラインしか決めていないものも、各種認定制度では普通にあるわけだが、 それあたりは当面使えないんだろうな。

4.2.5 Records Retention Policy

The CSP shall comply with its respective records retention policies in accordance with applicable laws, regulations, and policies, including any NARA records retention schedules that may apply. If the CSP opts to retain records in the absence of any mandatory requirements, the CSP SHALL conduct a risk management process, including assessments of privacy and security risks to determine how long records should be retained and SHALL inform the subscriber of that retention policy.

記録保持についてはAAL1と同じ。

4.3 Authenticator Assurance Level 3

This section is normative.

AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifier impersonation resistance — the same device MAY fulfill both these requirements. In order to authenticate at AAL3, claimants SHALL prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.

AAL3は「非常に高い」信頼度を要求する。AAL3では、ハードウェアをベースにした 認証器、さらに検証者に対なりすまし（impersonation）耐性を持つ認証器を 使わなければならないと定める（1つの装置が両方の要求要件を満たしても良い）。 要求要件を満たすかどうかは、やはりセクション5に行かないとわからないわけであるが。 後半はAAL2と同じである。つまりであるが、AAL3に要求するものはハードウェアと 対なりすまし耐性ということである。

4.3.1 Permitted Authenticator Types

AAL3 authentication SHALL occur by the use of one of a combination of authenticators satisfying the requirements in Section 4.3. Possible combinations are:

• Multi-Factor Cryptographic Device 多要素暗号装置　(Section 5.1.9)
• Single-Factor Cryptographic Device (Section 5.1.7) used in conjunction with Memorized Secret 単要素暗号装置プラス記憶秘密(Section 5.1.1)
• Multi-Factor OTP device (software or hardware) (Section 5.1.5) used in conjunction with a Single-Factor Cryptographic Device 多要素OTP装置プラス単要素暗号装置(Section 5.1.7)
• Multi-Factor OTP device (hardware only) (Section 5.1.5) used in conjunction with a Single-Factor Cryptographic Software 多要素OTPハードウェア装置プラス単要素暗号ソフトウェア(Section 5.1.6)
• Single-Factor OTP device (hardware only) (Section 5.1.4) used in conjunction with a Multi-Factor Cryptographic Software Authenticator 単要素OTPハードウェア装置プラス多要素暗号ソフトウェア認証器(Section 5.1.8)
• Single-Factor OTP device (hardware only) (Section 5.1.4) used in conjunction with a Single-Factor Cryptographic Software Authenticator (Section 5.1.6) and a Memorized Secret 単要素OTPハードウェア装置プラス記憶秘密利用の単要素暗号ソフトウェア認証器　(Section 5.1.1)

この詳細はセクション5で改めて論じることになるが、AAL2との違いは以下のとおりである。

• ハードウェア必須
• OTPはあまり信用しない

なお、ここに至るまでのリスク評価、インシデント事例は、規格だから当然のごとく 公開されないわけであるが、一度見て、日本ならどうなるかをきちんと評価した方が よいと思う。

4.3.2 Authenticator and Verifier Requirements

Communication between the claimant and verifier SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to MitM attacks. All cryptographic device authenticators used at AAL3 SHALL be verifier impersonation resistant as described in Section 5.2.5 and SHALL be replay resistant as described in Section 5.2.8. All authentication and reauthentication processes at AAL3 SHALL demonstrate authentication intent from at least one authenticator as described in Section 5.2.9.

ここでAAL2に追加されたことは、対なりすまし耐性のところ（のみ）。

Multi-factor authenticators used at AAL3 SHALL be hardware cryptographic modules validated at FIPS 140 Level 2 or higher overall with at least FIPS 140 Level 3 physical security. Single-factor cryptographic devices used at AAL3 SHALL be validated at FIPS 140 Level 1 or higher overall with at least FIPS 140 Level 3 physical security.

Verifiers at AAL3 SHALL be validated at FIPS 140 Level 1 or higher.

ここで、急にFIPS140への対応が詳細に定められる。 この意図は、おそらくではあるが、AAL3は、政府関係その他ごく限られたところで 使われることを想定している（はっきり言ってしまおう。連邦政府PKIの他に 何か思いつくか？）ので、政府関係の規定をそのままもってきても 大丈夫と言うことだろう。そういう意味で、この文書が一番力を入れているのは AAL2と想像できる（AAL1は弱いものとして推奨しない。AAL3は政府関係その他 限定されたシナリオでの使用を想定する）。

Verifiers at AAL3 SHALL be verifier compromise resistant as described in Section 5.2.7 with respect to at least one authentication factor.

この部分、「検証者の危殆化」への耐性をもたなければならないとされる。 ここで想定されるリスクは、認証の時に検証者が証明者について何らかの情報を 生成したり保持したりするものであり、検証者が攻撃を受けてその情報が盗まれる ことである。一部のOTPなんかはやっていそうである。詳細は後述

Hardware-based authenticators and verifiers at AAL3 SHOULD resist relevant side-channel (e.g., timing and power-consumption analysis) attacks. Relevant side-channel attacks SHALL be determined by a risk assessment performed by the CSP.

ハードウェアで提供される認証器は、サイドチャネル攻撃（対応する攻撃の種類は、CSPがリスク評価を行った上で決めなければならないとする）への耐性を持つべきであるとする。

When a device such a smartphone is used in the authentication process — presuming that the device is able to meet the requirements above — the unlocking of that device SHALL NOT be considered to satisfy one of the authentication factors. This is because it is generally not possible for verifier to know that the device had been locked nor whether the unlock process met the requirements for the relevant authenticator type.

スマホのロックに関するものはAAL2と同じ

When a biometric factor is used in authentication at AAL3, the verifier SHALL make a determination that the biometric sensor and subsequent processing meet the performance requirements stated in Section 5.2.3.

生体認証を使うときは5.2.3のものを使えと言っているのはAAL2と同じ

4.3.3 Reauthentication

Periodic reauthentication of subscriber sessions SHALL be performed as described in Section 7.2. At AAL3, authentication of the subscriber SHALL be repeated at least once per 12 hours during an extended usage session, regardless of user activity, as described in Section 7.2. Reauthentication of the subscriber SHALL be repeated following any period of inactivity lasting 15 minutes or longer. Reauthentication SHALL use both authentication factors. The session SHALL be terminated (i.e., logged out) when either of these time limits is reached. The verifier MAY prompt the user to cause activity just before the inactivity timeout.

AAL2とAAL3の違いを下にあげる。

要件	AAL2	AAL3
制限時間	12時間	12時間
操作なしの制限時間	30分	15分
再認証の方法	記憶秘密や生体のみ（1個）でも可	全部やり直し

4.3.4 Security Controls

The CSP SHALL employ appropriately-tailored security controls from the high baseline of security controls defined in SP 800-53 or an equivalent federal (e.g., FEDRAMP) or industry standard. The CSP SHALL ensure that the minimum assurance-related controls for high-impact systems or equivalent are satisfied.

CSPが守るべき基準は「高」である。

4.3.5 Records Retention Policy

The CSP shall comply with its respective records retention policies in accordance with applicable laws, regulations, and policies, including any NARA records retention schedules that may apply. If the CSP opts to retain records in the absence of any mandatory requirements, the CSP SHALL conduct a risk management process, including assessments of privacy and security risks, to determine how long records should be retained and SHALL inform the subscriber of that retention policy.

AAL1, AAL2と同じ。

4.4 Privacy Requirements

プライバシーに関すること。認証は、本人情報（いわゆる「個人情報」）を本質的に扱うので、ここで一定の規定が必要である。 プライバシーの規定は、ABCそれぞれにある。対象はそれぞれ異なる。こんな感じ。

    800-63C ---  federation <-- トラストフレームワークの守るべきプライバシー規定
			|
			|
    800-63B ---  Verifier（検証して認証アサーションを出すもの）--- CSP （認証をする本体）
                                                    　　　　　　||		
                                                    　　　　　　||
    800-63A ---                                  　　　　　　　CSP（アイデンティティ管理）
　

CSPは、AとB両方でプライバシーの規制がかかる。CSPについてはAの文書も参照が必要（時間があれば、Aにも触れる）

規制の対象になるのはCSPと、認証情報を検証して利用する政府機関（ここではagencyと言っている）。後者は連邦法の規制を受けるのだが、日本では「行政機関個人情報保護法」が 対応する。うーん、大丈夫か？ プライバシーに関する規定はヨーロッパのGDPRが大きな衝撃を与えた。 これは、例えばアメリカの CPBR (Consumers Privacy Bill of Rights, 2012) とは比較にならないほどインパクトが大きく、APECでの枠組 CBPR (Cross Border Privacy Rules) なども吹き飛ばした感がある。 実際、カルフォルニア州法のCSPPも生まれたりしている。 日本でもいい加減な解説本が一部で生まれている（研修会でセールスはじめるやつがいた）。 プライバシーに関するルール作りは、現在も流動的であると考えている。GDPRが 一番厳しいからそれに乗っておけば安心という程度。詳細は、今後いろいろな 判例が積み重なり、ビジネスの側からの外交の巻き返しがあり、その上で 落としどころが見つかるものである。

The CSP SHALL employ appropriately-tailored privacy controls defined in SP 800-53 or equivalent industry standard.

If CSPs process attributes for purposes other than identity proofing, authentication, or attribute assertions (collectively “identity service”), related fraud mitigation, or to comply with law or legal process, CSPs SHALL implement measures to maintain predictability and manageability commensurate with the privacy risk arising from the additional processing. Measures MAY include providing clear notice, obtaining subscriber consent, or enabling selective use or disclosure of attributes. When CSPs use consent measures, CSPs SHALL NOT make consent for the additional processing a condition of the identity service.

実際、CSPが認証を行う際にに求められているのは以下の2つ

• CSPが何か新しいこと（属性、属性アサーション、関連する不正行為のリスク低減、法規制への服従）を処理するときは、プライバシーリスク解析をしたうえで 対策を講じること
• 同意による対策を取るときは、CSPはアイデンティティサービスの条件を追加処理 ことへの同意であってはならない

complyは「遵守」ではなく「服従」と意図的に訳を変えてみた。 前者は属性を広くアイデンティティ情報ととらえて広く保護するものである。 後者は、CSPが強い立場にいることを前提として、前者の対策として同意を採用するときは、 サービスの条件を追加で同意の対象としてはいけないことを述べる。（実感がわかない）

Regardless of whether the CSP is an agency or private sector provider, the following requirements apply to an agency offering or using the authentication service:

1. The agency SHALL consult with their Senior Agency Official for Privacy (SAOP) and conduct an analysis to determine whether the collection of PII to issue or maintain authenticators triggers the requirements of the Privacy Act of 1974 [Privacy Act] (see Section 9.4).
   • The agency SHALL publish a System of Records Notice (SORN) to cover such collections, as applicable.
   • The agency SHALL consult with their SAOP and conduct an analysis to determine whether the collection of PII to issue or maintain authenticators triggers the requirements of the E-Government Act of 2002 [E-Gov].
   • The agency SHALL publish a Privacy Impact Assessment (PIA) to cover such collection, as applicable.

この部分は、米政府機関に対する規制。

4.5 Summary of Requirements

This section is informative.

Table 4-1 summarizes the requirements for each of the AALs:

Requirement	AAL1	AAL2	AAL3
Permitted authenticator types	Memorized Secret; Look-up Secret; Out-of-Band; SF OTP Device; MF OTP Device; SF Crypto Software; SF Crypto Device; MF Crypto Software; MF Crypto Device	MF OTP Device; MF Crypto Software; MF Crypto Device; or Memorized Secret plus:  • Look-up Secret  • Out-of-Band  • SF OTP Device  • SF Crypto Software  • SF Crypto Device	MF Crypto Device; SF Crypto Device plus   Memorized Secret; SF OTP Device plus MF Crypto Device or Software; SF OTP Device plus SF Crypto Software plus Memorized Secret
FIPS 140 validation	Level 1 (Government agency verifiers)	Level 1 (Government agency authenticators and verifiers)	Level 2 overall (MF authenticators) Level 1 overall (verifiers and SF Crypto Devices) Level 3 physical security (all authenticators)
Reauthentication	30 days	12 hours or 30 minutes inactivity; MAY use one authentication factor	12 hours or 15 minutes inactivity; SHALL use both authentication factors
Security controls	SP 800-53 Low Baseline (or equivalent)	SP 800-53 Moderate Baseline (or equivalent)	SP 800-53 High Baseline (or equivalent)
MitM resistance	Required	Required	Required
Verifier-impersonation resistance	Not required	Not required	Required
Verifier-compromise resistance	Not required	Not required	Required
Replay resistance	Not required	Required	Required
Authentication intent	Not required	Recommended	Required
Records Retention Policy	Required	Required	Required
Privacy Controls	Required	Required	Required

この表は、今までのものをまとめたものである。MitM resistenceから Replay resistenceまでの耐性は、1つの項目とするよりは、再認証のところに まとめるべきである。実際、わかりにくい。 「認証の意図」を一つの項目とするなら、生体認証の項にまとめるべきだし、 また「スマホのロックを認証要素としてはいけない」という規制も抜けている。 後で戻って、書き直してみよう。

5 Authenticator and Verifier Requirements

This section is normative.

This section provides the detailed requirements specific to each type of authenticator. With the exception of reauthentication requirements specified in Section 4 and the requirement for verifier impersonation resistance at AAL3 described in Section 5.2.5, the technical requirements for each of the authenticator types are the same regardless of the AAL at which the authenticator is used.

5.1 Requirements by Authenticator Type

以下、認証器に対する規定。構成は各論に続いて総論。え、逆？

5.1.1 Memorized Secrets

ここから、各論が始まる。最初はパスワード。話を始める前に、この文章が 発表当初、結構話題になったことを思い出そう。これは旧バージョンからの変更が大きかったこともあるし（今まで旧バージョンを信じて運用してたのに、はしごをはずされた）、特に、規制が ゆるくなったことで「これで大丈夫なのか？」という批判も起こったことに原因がある。

そこで、この文書のデザインの方針を思い出す。旧バージョンでは明示的には示されていなかったものであるが、当時からのリスク評価、管理の方法論の一定の成熟を経て、以下のようになったものである。 詳細は800-63本体を参照すること。

1. アイデンティティのモデルを定める。
2. そのモデルに従って、リスク評価の方法を定める。
3. リスク評価に従い、各々の情報資産を認証の点からどう守るか決定を下す。特に、PII関係は、AAL2以上で守ることを決める。
4. 上を具体的な装置、方法で実装する。

AAL1で守るべきものには、AAL1なりの強度を要求することにし、特にパスワードは、 AAL1の強度を満たすための強度の要求要件を満たすべきとする。だから、

• パスワードですべてを守ろうとするのは、モデルに違反する。→　自分で再設計どうぞ
• そうでなくとも、パスワードでPIIを含む結構重要な情報を守ろうとするのは、強度(AAL2)の想定が 違う。→　自分で再設計どうぞ

たとえば、日本でも 総務省の指針があり、2018年に「定期変更は不要」と 方針を転換して話題になった。ただし、上のようなモデルの提示、解析がなされていないので、 よくない。ちなみに、ページのコピーライトノーティスが2013になっているのは保守の雑さを示唆するものである。

それはともかく、この文書全体を読む時の一般的な注意がここに凝縮されている。

5.1.1.1 Memorized Secret Authenticators

Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets.

パスワードの要件。パスワードを2種類に分ける。

• 利用者が設定するもの。一般のものはこれに当てはまる。→8文字以上。CSP、または検証者は、（破られやすいパスワードの）ブラックリストからの選択を許さない場合は、利用者に再度パスワード設定を要求しなければならない。
• CSPや検証者がランダムに設定するもの。ルーターなどのアプライアンスの管理用のパスワードで、ネットワークの制限などがかかっていることを想定する。→6文字以上。数字だけを許容する。

パスワードの強度についての解析が附録にあるが、これ少し読んでみよう。→じゃーんぷ

5.1.1.2 Memorized Secret Verifiers

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well. To make allowances for likely mistyping, verifiers MAY replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length. Truncation of the secret SHALL NOT be performed. For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.

検証者（パスワードを使って認証をしようとするclaimantを検証する側）の要件。
検証者がやるべきことを次にまとめる

1. 利用者設定パスワードは最低8文字を義務付け、最低64字を受け付けるべきである。
2. printable ASCII文字、空白文字は受け付けるべきである。
3. Unicodeを受け付けるべきである。Unicode1字は1文字と扱わなければならない。
4. 連続した空白はひとつにまとめてよい。
5. パスワードを途中でちょんぎってはならない。

If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the Normalization Process for Stabilized Strings using either the NFKC or NFKD normalization defined in Section 12.1 of Unicode Standard Annex 15 [UAX 15]. This process is applied before hashing the byte string representing the memorized secret. Subscribers choosing memorized secrets containing Unicode characters SHOULD be advised that some characters may be represented differently by some endpoints, which can affect their ability to authenticate successfully.

ここではUnicodeに関する処理の制約。まずはNFKCかNFKDによって正規化せよとする。 利用者に対して、文字の一部が異なった表示をされることを断っておくことをよしとする。 ここまでしてもUnicodeを採用したいのがいるかなぁ、と考える。

Memorized secrets that are randomly chosen by the CSP (e.g., at enrollment) or by the verifier (e.g., when a user requests a new PIN) SHALL be at least 6 characters in length and SHALL be generated using an approved random bit generator [SP 800-90Ar1].

例えば登録時にCSPが、または利用者が新しいPINを要求するときに検証者がランダムにパスワードを生成する場合は最低6文字。 承認済みのランダムビット生成器を使わなければならない。 代表的なシステムのmanページを見ても、SP800-90Ar1準拠の文字は 出てこないのだが、どう検証したらよいのだろうか？

Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

検証者は、認証のヒントを、「認証を経ていない、claimant」に見せては いけないし、利用者に「秘密の質問」を見せてもいけない。 そんなこと言っても、Windowsでは、こちらがひやひやするくらい出してきますがな。 「秘密の質問」は、他人にも推測ができるかもしれない極めて弱いパスワードの一種として2015年前後から、ネガティブなレポートが出るようになった。アップルのiCloudでの2014年のインシデント 「著名人の写真に関する調査状況の報告」などは、禁止へ舵をきるきっかけに なったのかもしれない。

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:

• Passwords obtained from previous breach corpuses.
• Dictionary words.
• Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
• Context-specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

これは、パスワードのブラックリスト運用について。 ブラックリストに載せる語としては、例えば

• 以前の漏洩で明らかになったパスワード
• 辞書に載っている語
• 同じ文字の繰り返し、連続文字
• サービス名、例えばPaypalのパスワードにpaypalとか、ユーザ名がsatoとわかっているのにパスワードにもsatoとつけるとか、またはそれらを組み合わせたpaypalsatoとか。

があるが、設定しようとしたパスワードがこれらに引っ掛かる場合、CSPや検証者は 別のパスワードを設定するように、拒否の理由とともに指示しなければならない。

Verifiers SHOULD offer guidance to the subscriber, such as a password-strength meter [Meters], to assist the user in choosing a strong memorized secret. This is particularly important following the rejection of a memorized secret on the above list as it discourages trivial modification of listed (and likely very weak) memorized secrets [Blacklists].

検証者は、強いパスワードを選ぶためのパスワード強度メーターみたいなものを 提供すべきだとされ、実際に これを採用して、パスワードの強度を測るようなシステムも経験済みだが、 そのようなパスワードチェッカーのインテリジェンスもシステムによって差があるようで。

Verifiers SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2.

検証者は、レート制限をつけて、何回か認証に失敗したら認証を拒否しなければならないとする。「レート制限」は一般には「スロットリング」と呼ばれ、 多くのシステムではカーネルのパラメタとして設定が可能なはずである。

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

検証者は「パスワード作成ルール」を強制すべきではない。 この「パスワード作成ルール」には、複数文字種の組み合わせ、連続した文字の繰り返しの禁止などがある。
さらに、利用者の意思なしに、検証者が任意でパスワードを変更させるべきではないとする。これで「パスワードの定期変更」がSHOULD NOTになった。この部分は日本でも 総務省が採用して推奨から外している（すべきではないとはまだ言っていない）。 パスワードが危殆化したという証拠があがったときは、変更を強制しなければならないとする。 理由はいろいろ言われているが、よく聞くものは「作成ルールを決めると、

• 作成ルールを強制すると、よくある安易なルールに従い、推測がかえってしやすくなる
• 定期変更を強制すると、一定の作成ルールに従うことがよくあり、やはり推測がかえってしやすくなる

で、2つを同じパラグラフに入れているのは、同根だという意識があるのだろう。 実際その通りだと感じる。

Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.

検証者は、パスワードを入れる時は「コピペ」を許すべきだとする。 これは、パスワードマネージャを使うときに効果的に使える。 ここではパスワードマネージャが有効であるという評価をしているが、 現状、どうなんですかね。

In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered. This allows the claimant to verify their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry. This is particularly applicable on mobile devices.

ここでは、パスワードの表示について。許すべきだとしている。 最近、スマホのフリックなどでの入力が 増えているが、そこでの入力間違いが無視できないことも、この記述の根拠の一つ。 スマホ等の画面が見られないようにすることは大前提である。 スマホ等では、短い時間だけ表示する方式も良く見る。これもMAYとしている。

The verifier SHALL use approved encryption and an authenticated protected channel when requesting memorized secrets in order to provide resistance to eavesdropping and MitM attacks.

検証者は、承認済みの暗号方式と、MitMを防ぐための認証して保護されたチャネルを 使わなければならないとする。FIPS 140-2は、たいていのシステムは認証通っているから問題ないし、後者はTLS一択である。

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash. Their purpose is to make each password guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive. Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON]. A memory-hard function SHOULD be used because it increases the cost of an attack. The key derivation function SHALL use an approved one-way function such as Keyed Hash Message Authentication Code (HMAC) [FIPS 198-1], any approved hash function in SP 800-107, Secure Hash Algorithm 3 (SHA-3) [FIPS 202], CMAC [SP 800-38B] or Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), or ParallelHash [SP 800-185]. The chosen output length of the key derivation function SHOULD be the same as the length of the underlying one-way function output.

ここでは、パスワードハッシュの作り方を指定する。オフライン攻撃への耐性を できるだけ高めることが目的である。

1. 一方向ハッシュ関数を使え。
2. ソルトを使え。これを使うと、一律の文字列マッチができなくなり、パスワードファイルを入手しても、効率的なサーチができない意味で、攻撃側への意地悪になる。
3. コスト要素を使え。ここでは繰り返し回数やメモリーハード関数。後者を使うと、専用ハード（メモリの縛りがきつい）を使っての解析が簡単にはできなくなり、攻撃側への意地悪になる。

NISTが強いのは、この条件を出すと、すぐに例がいくつかでてくることでPBKDF2、 Ballon（これはメモリーハードでもある）などがすぐ出てくる。
ハッシュ関数としてHMAC, P800-107, SHA-3, CMAC, KMAC cSHAKE, ParallelHashが 挙げられているが、日本で、この評価がきちんとできるのはほんの一握りしか いないだろう。筆者はもちろんできない。

The salt SHALL be at least 32 bits in length and be chosen arbitrarily so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each subscriber using a memorized secret authenticator.

ソルトは最低32bit、ランダム。ハッシュ値とともに格納しなければならない。 ソルトは、暗号学的には気休めだが、攻撃者への一定の意地悪の意味は 確かにある。

For PBKDF2, the cost factor is an iteration count: the more times the PBKDF2 function is iterated, the longer it takes to compute the password hash. Therefore, the iteration count SHOULD be as large as verification server performance will allow, typically at least 10,000 iterations.

PBDKDF2では、コスト要素は繰り返し回数。普通に考えて最低10000回。

In addition, verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier. This salt value, if used, SHALL be generated by an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The secret salt value SHALL be stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module). With this additional iteration, brute-force attacks on the hashed memorized secrets are impractical as long as the secret salt value remains secret.

さらに、検証者だけが知っている秘密のソルトの指定ができる場合は、 それをすべきである。ソルトはランダムに作られなければならず、SP 800-131Aで 定める強度をもたなければならない。 この秘密のソルトは、パスワードとは別個に格納されなければならない。 ここまですると、総当たりはほとんど不可能になる。

5.1.2 Look-Up Secrets

5.1.2.1 Look-Up Secret Authenticators

CSPs creating look-up secret authenticators SHALL use an approved random bit generator [SP 800-90Ar1] to generate the list of secrets and SHALL deliver the authenticator securely to the subscriber. Look-up secrets SHALL have at least 20 bits of entropy.

いわゆる乱数表認証である。CSPが承認済みの乱数生成器により、秘密列を 生成し、セキュアに、本人に配布しなければならないとする。最低20ビット。ということは、ASCIIで4文字くらいだから、結構緩い。

Look-up secrets MAY be distributed by the CSP in person, by postal mail to the subscriber’s address of record, or by online distribution. If distributed online, look-up secrets SHALL be distributed over a secure channel in accordance with the post-enrollment binding requirements in Section 6.1.2.

配布の仕方だが、手渡しの他に、登録された住所に郵送（アメリカでも 郵便のシステムはまだ信用されていることがわかる。わき道にそれるが、この トラストを損壊することがあってはならない）、またはオンライン（この場合、 セキュアなチャネルで6.1.2で要求する登録後の利用者と認証器とのバインディングに 関する要件を満たさなければならない）であってもよい。

If the authenticator uses look-up secrets sequentially from a list, the subscriber MAY dispose of used secrets, but only after a successful authentication.

このタイプのものが、リストから順に秘密を参照するタイプのものであるとき、 利用者は、認証が成功したものに使った秘密は捨てても良い。 ふむ、このような参照秘密の運用があるんだ。

5.1.2.2 Look-Up Secret Verifiers

Verifiers of look-up secrets SHALL prompt the claimant for the next secret from their authenticator or for a specific (e.g., numbered) secret. A given secret from an authenticator SHALL be used successfully only once. If the look-up secret is derived from a grid card, each cell of the grid SHALL be used only once.

こちらは、検証する側の話。 検証側は、「次の」または、位置を特定して秘密を入力するようにプロンプトを出さなければならない。 入力された秘密は一回だけ使用しなければならない。「グリッドカード」を 使うときは、各セルの仕様は1回だけ。 ふむ、乱数表はアメリカではグリッドカードと言うのだな。

Verifiers SHALL store look-up secrets in a form that is resistant to offline attacks. Look-up secrets having at least 112 bits of entropy SHALL be hashed with an approved one-way function as described in Section 5.1.1.2. Look-up secrets with fewer than 112 bits of entropy SHALL be salted and hashed using a suitable one-way key derivation function, also described in Section 5.1.1.2. The salt value SHALL be at least 32 in bits in length and arbitrarily chosen so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each look-up secret.

For look-up secrets that have less than 64 bits of entropy, the verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2.

検証側での秘密のオフライン攻撃耐性を持つ格納方法について定める。パスワードの格納方法に準じている。

• 112bit以上のエントロピーを持つような秘密なら5.1.1.2で定めるような一方向ハッシュ関数を使うこと。
• 112bit以下なら、32bit以上のソルトをかけてハッシュを取ること。ソルトは、 衝突が起きないようにランダムに選ぶこと
• 64bit以下なら、レート制限をかけること。

The verifier SHALL use approved encryption and an authenticated protected channel when requesting look-up secrets in order to provide resistance to eavesdropping and MitM attacks.

MitMを防ぐために、承認済みの暗号と認証されて保護されたチャネルを用いて、 秘密をやりとりすること。TLS利用強制の別名。

5.1.3 Out-of-Band Devices

この部分、副チャネルで、特に公衆電話網を使うものについて スペースを割いている。SMS認証はここに分類されるのだが、 この文書の制定時と今では、少し事情が異なる。

1. 公衆電話網の信頼度が日米では異なる。
2. SMS認証の脆弱性として、フィッシング耐性が論じられるようになったのは 最近のことである。

以下、適宜言葉を足して解説する。制定の時点でいろいろ怪しいところがあったが、 そこはきちんとRestrictedとくぎをさし、 forward robustnessを満たすようにしている。規格を書くときはかくありたいものである。

5.1.3.1 Out-of-Band Authenticators

The out-of-band authenticator SHALL establish a separate channel with the verifier in order to retrieve the out-of-band secret or authentication request. This channel is considered to be out-of-band with respect to the primary communication channel (even if it terminates on the same device) provided the device does not leak information from one channel to the other without the authorization of the claimant.

アウトオブバンド認証器は、検証者と、秘密や認証要求をやり取りする ために、副チャネルを別個に確立しなければならない。 スマホのように、電話とネット双方につながるものも想定するが、その場合は 一方のチャネルから他方に（claimantの認可なしに）情報が渡らないような保証が必要である。

The out-of-band device SHOULD be uniquely addressable and communication over the secondary channel SHALL be encrypted unless sent via the public switched telephone network (PSTN). For additional authenticator requirements specific to the PSTN, see Section 5.1.3.3. Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.

アウトオブバンド装置は、一意に特定可能であるべきで、副チャネルを通しての通信は、 公衆電話網を使う以外ならば、暗号化しなければならない。公衆電話網を利用する 認証器についてはすぐ後で述べる。 所有していることを証明できないような装置（VOIP、メール）は アウトオブバンド認証器として使ってはならない。 メールを使っても良いが、それは複チャネル認証器とは認めないということである。

The out-of-band authenticator SHALL uniquely authenticate itself in one of the following ways when communicating with the verifier:

• Establish an authenticated protected channel to the verifier using approved cryptography. The key used SHALL be stored in suitably secure storage available to the authenticator application (e.g., keychain storage, TPM, TEE, secure element).

• Authenticate to a public mobile telephone network using a SIM card or equivalent that uniquely identifies the device. This method SHALL only be used if a secret is being sent from the verifier to the out-of-band device via the PSTN (SMS or voice).

このタイプの認証は、以下のどちらかひとつで行わなければならない。

• 認証され保護されたチャネルを、承認済みの暗号を用いて検証者との間に チャネルを確立する。暗号の鍵は、セキュアなところに格納し、認証器から 利用可能でなければならない。キーチェイン、TPM、TEE、セキュア要素は使ってよい「セキュアな 格納場所」である。キーチェインはOSの保護、その他はハードウェアの保護の下にある。
• 公衆携帯電話網にSIMを通してつながっており、一意に装置が同定できるようにしている。 この方法を使うときは、公衆電話網を通して検証者から秘密が送られるような タイプのみに用いる。この際の秘密にはSMSや声が含まれる。

If a secret is sent by the verifier to the out-of-band device, the device SHOULD NOT display the authentication secret while it is locked by the owner (i.e., requires an entry of a PIN, passcode, or biometric to view). However, authenticators SHOULD indicate the receipt of an authentication secret on a locked device.

秘密が検証者から送られる場合、装置にロックがかかっているときには、その秘密を 表示すべきではない。ただし、その場合でも秘密が送られてきたという情報は与えるべきである。これ、スマホのメッセージを不要に設計するとだめになりそう。

If the out-of-band authenticator sends an approval message over the secondary communication channel — rather than by the claimant transferring a received secret to the primary communication channel — it SHALL do one of the following:

• The authenticator SHALL accept transfer of the secret from the primary channel which it SHALL send to the verifier over the secondary channel to associate the approval with the authentication transaction. The claimant MAY perform the transfer manually or use a technology such as a barcode or QR code to effect the transfer.

• The authenticator SHALL present a secret received via the secondary channel from the verifier and prompt the claimant to verify the consistency of that secret with the primary channel, prior to accepting a yes/no response from the claimant. It SHALL then send that response to the verifier.

これは、アウトオブバンド装置が承認メッセージを副チャネルを通して送る場合の規定。以下のどれか一つをやらなければならない。

• 認証器は、検証者に、（副チャネルを通して送らなければならない）承認のメッセージを主チャネルに転送することを許さなければならない。この転送は、人手を介しても良いし、また送られたバーコードやQRコードを流し込むものでもよい。 TiQRは、この方式（のはず）。
• 認証器は、副チャネルを通して検証者から送られた秘密を提示し、主チャネルからの情報との整合性を検証するように求めなければならない。claimantによる検証の結果は、検証者に送らなければならない。

これを見ると、アウトオブバンド認証器のデザインと実装についてわりと厳しめ（というか、具体的というか、実装者に親切）に規定していることがわかる。

5.1.3.2 Out-of-Band Verifiers

For additional verification requirements specific to the PSTN, see Section 5.1.3.3.

If out-of-band verification is to be made using a secure application, such as on a smart phone, the verifier MAY send a push notification to that device. The verifier then waits for the establishment of an authenticated protected channel and verifies the authenticator’s identifying key. The verifier SHALL NOT store the identifying key itself, but SHALL use a verification method (e.g., an approved hash function or proof of possession of the identifying key) to uniquely identify the authenticator. Once authenticated, the verifier transmits the authentication secret to the authenticator.

アウトオブバンド認証の検証を、スマホなどの装置の上のセキュアなアプリで行うとき、 通知をその装置に送っても良い。 その時は、認証され保護されたチャネルを確立するまで待ち、その上で 認証器の識別キーを送ることになる。 識別キー自体は検証者は記憶してはいけない。その代わりにハッシュ関数や識別キーの 所持証明などの検証方法を用いて認証器を一位に識別しなければならない。 一度この識別の認証が確立された後で、秘密を認証器に送り込むことになる。

Depending on the type of out-of-band authenticator, one of the following SHALL take place:

• Transfer of secret to primary channel: The verifier MAY signal the device containing the subscriber’s authenticator to indicate readiness to authenticate. It SHALL then transmit a random secret to the out-of-band authenticator. The verifier SHALL then wait for the secret to be returned on the primary communication channel.

• Transfer of secret to secondary channel: The verifier SHALL display a random authentication secret to the claimant via the primary channel. It SHALL then wait for the secret to be returned on the secondary channel from the claimant’s out-of-band authenticator.

• Verification of secrets by claimant: The verifier SHALL display a random authentication secret to the claimant via the primary channel, and SHALL send the same secret to the out-of-band authenticator via the secondary channel for presentation to the claimant. It SHALL then wait for an approval (or disapproval) message via the secondary channel.

In all cases, the authentication SHALL be considered invalid if not completed within 10 minutes. In order to provide replay resistance as described in Section 5.2.8, verifiers SHALL accept a given authentication secret only once during the validity period.

検証者の取るべき行為は、以下のうち一つ。

• 秘密を主チャネルに送るとき、
• 秘密を副チャネルに送るとき、
• claimantによる秘密の検証をするとき、

いずれの場合でも、有効期限は10分以内。リプレイ攻撃耐性を高めるに、秘密は、有効な期限内では 検証者が秘密を受け入れるのは一回だけ。攻撃側に余裕を与えない、一度使った秘密を盗んで、 再度認証に使う攻撃を防止する。

The verifier SHALL generate random authentication secrets with at least 20 bits of entropy using an approved random bit generator [SP 800-90Ar1]. If the authentication secret has less than 64 bits of entropy, the verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2.

検証者が認証の秘密として乱数を生成するときは最低20bit、承認済みの乱数生成器を使わなければならない。 乱数が64bit未満のときは、レート制限をかけなければならない、とする。

5.1.3.3 Authentication using the Public Switched Telephone Network

ここからが公衆電話網を使うときの規定。ここと5.2.10での制限を適用することが求められる。

Use of the PSTN for out-of-band verification is RESTRICTED as described in this section and in Section 5.2.10. If out-of-band verification is to be made using the PSTN, the verifier SHALL verify that the pre-registered telephone number being used is associated with a specific physical device. Changing the pre-registered telephone number is considered to be the binding of a new authenticator and SHALL only occur as described in Section 6.1.2.

検証者は、使用するあらかじめ登録している電話番号が、具体的な装置と 結びついていることを検証しなければならない。電話番号の変更は、新規扱いとし、6.1.2 (利用者登録後に装置を登録するときの規定) に従わなければならない。

Verifiers SHOULD consider risk indicators such as device swap, SIM change, number porting, or other abnormal behavior before using the PSTN to deliver an out-of-band authentication secret.

検証者は、装置の交換、SIM交換、番号移行などに伴うリスクを考慮すべきである。 公衆電話網では、SS7の脆弱性が指摘されていて、真偽はともかく ドイツでのSMS盗聴攻撃などが報告されている。 日本での報告はまだないようであるが… さらに、公衆網を使ったSMS送信は、主チャネルとの結合の確認がおろそかになりがち（誰でもメッセージを送りつけることができる）であり、そこが切れると 銀行への攻撃などが起きるわけである。 これは、CSRFの一種と言えるかもしれない。
これらは、例えばSmishingなどと称されるSMSを使ったフィッシングなどと並んで本質的な脆弱性であり、公衆電話網を使ったSMS認証が敬遠される理由ともなっている。

NOTE: Consistent with the restriction of authenticators in Section 5.2.10, NIST may adjust the RESTRICTED status of the PSTN over time based on the evolution of the threat landscape and the technical operation of the PSTN.

この「保留」は、現在「禁止」の方向に動いている。

5.1.4 Single-Factor OTP Device

5.1.4.1 Single-Factor OTP Authenticators

Single-factor OTP authenticators contain two persistent values. The first is a symmetric key that persists for the device’s lifetime. The second is a nonce that is either changed each time the authenticator is used or is based on a real-time clock.

単要素OTPは、昔でいえば、RSAのSecuriD（昔、使っているのを見たことがある）を代表とするものであり、この文書の旧版では、 製品名指定で多要素認証と認定されていた。この文書が制定されるずっと前から、米国政府関係で 積極的に使われていたことが背景にある。
単要素OTPは、装置に紐づく暗号鍵（対象鍵）と、各回ごとに異なるnonceから構成される。 nonceは、例えばSecuriDでは時間をキーとして生成されていた。

The secret key and its algorithm SHALL provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The nonce SHALL be of sufficient length to ensure that it is unique for each operation of the device over its lifetime. OTP authenticators — particularly software-based OTP generators — SHOULD discourage and SHALL NOT facilitate the cloning of the secret key onto multiple devices.

秘密鍵とアルゴリズムの強度は、SP 800-131Aを最低限満たしていなければならない。「セキュリティ強度」は、実はSP 800-57で定義されている。引用する。
A number associated with the amount of work (that is, the number of operations) that is required to break a cryptographic algorithm or system. In this Recommendation, security strength is specified in bits and is a specific value from the set.
なんてことはない、アルゴリズムを定めた時の鍵長なのだが、それを800-131Aで決めている。131Aの文書名は
Transitioning the Use of Cryptographic Algorithms and Key Lengths
とそのままだが、これはNISTが将来にわたって暗号の強度を評価し、移行を促していくということの決意表明である。RSAの鍵長が長くなったのもこのせい。次の移行として、 2020年、次いで2023年に一部の暗号長が無効になる予定。 ところで、SecuriDは、この枠組みにはまっている？
nonceについては装置のEOLが来るまで、過去とだぶりがないように十分な長さを 持っていなければならない。特にソフトウェアOTP生成器は、複数の装置に 複製をもたれないようにしなければならない。

The authenticator output is obtained by using an approved block cipher or hash function to combine the key and nonce in a secure manner. The authenticator output MAY be truncated to as few as 6 decimal digits (approximately 20 bits of entropy).

If the nonce used to generate the authenticator output is based on a real-time clock, the nonce SHALL be changed at least once every 2 minutes. The OTP value associated with a given nonce SHALL be accepted only once.

特に、実時間をベースにしてnonceが作られる場合は、最低2分毎にnonceを変更しなければならない。発行されたOTPが有効なのは一回だけ（当たりまえのようだが、 入力の間違い等でやり直しをしたくなる時がある。現在、筆者はなんちゃってOTPによる 認証を一部でしているのだが、そこでしているのは時間制限であり、回数制限はない。まずいんじゃないかなぁ ）

5.1.4.2 Single-Factor OTP Verifiers

Single-factor OTP verifiers effectively duplicate the process of generating the OTP used by the authenticator. As such, the symmetric keys used by authenticators are also present in the verifier, and SHALL be strongly protected against compromise.

こちらは検証者についての要件。 検証者は認証器と同じようにOTPを生成するのだから、生成に使う対象鍵は 危殆化しないように強力に守らなければならない。

When a single-factor OTP authenticator is being associated with a subscriber account, the verifier or associated CSP SHALL use approved cryptography to either generate and exchange or to obtain the secrets required to duplicate the authenticator output.

OTP生成が利用者アカウントごとになされるのであれば、承認された暗号を用いて 認証器の生成に必要な秘密をやりとりしなければならない。

The verifier SHALL use approved encryption and an authenticated protected channel when collecting the OTP in order to provide resistance to eavesdropping and MitM attacks. Time-based OTPs [RFC 6238] SHALL have a defined lifetime that is determined by the expected clock drift — in either direction — of the authenticator over its lifetime, plus allowance for network delay and user entry of the OTP. In order to provide replay resistance as described in Section 5.2.8, verifiers SHALL accept a given time-based OTP only once during the validity period.

OTPの入力を検証者に渡すときは「承認された暗号と認証されて保護されたチャネル」（今後面倒だから「TLS相当」と書く）を使わなければならない。これは中間者攻撃対策。 時間をベースにしたOTPは有効期限を定めなければならない。時計のずれ、ネットワーク遅延、利用者の入力にかかる時間を勘案することになる。 リプレイ攻撃は、攻撃者がOTPをどこかで盗んで、一度成功した認証に対して 再度そのOTPで認証を要求するときに起きるが、それを防ぐために、有効期間内に OTPは一度だけ利用可能でなければならない。
時間ベースのOTPはTOTPと略され、この文書で言及があるようにRFC6238で定められている。RFC6238で定められているのはHMAC-SHA-***を元にしたもの。

If the authenticator output has less than 64 bits of entropy, the verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2.

認証器の出力が64bitより小さいエントロピーであるとき、レート制限を かけなければならない。

で、結局SecuriDはどうなったのさ

5.1.5 Multi-Factor OTP Devices

5.1.5.1 Multi-Factor OTP Authenticators

Multi-factor OTP authenticators operate in a similar manner to single-factor OTP authenticators (see Section 5.1.4.1), except that they require the entry of either a memorized secret or the use of a biometric to obtain the OTP from the authenticator. Each use of the authenticator SHALL require the input of the additional factor.

In addition to activation information, multi-factor OTP authenticators contain two persistent values. The first is a symmetric key that persists for the device’s lifetime. The second is a nonce that is either changed each time the authenticator is used or is based on a real-time clock.

The secret key and its algorithm SHALL provide at least the minimum security strength specified in the latest revision of [SP 800-131A] (112 bits as of the date of this publication). The nonce SHALL be of sufficient length to ensure that it is unique for each operation of the device over its lifetime. OTP authenticators — particularly software-based OTP generators — SHOULD discourage and SHALL NOT facilitate the cloning of the secret key onto multiple devices.

The authenticator output is obtained by using an approved block cipher or hash function to combine the key and nonce in a secure manner. The authenticator output MAY be truncated to as few as 6 decimal digits (approximately 20 bits of entropy).

If the nonce used to generate the authenticator output is based on a real-time clock, the nonce SHALL be changed at least once every 2 minutes. The OTP value associated with a given nonce SHALL be accepted only once.

単要素OTPと多要素OTPの違いは、記憶秘密か生体認証を使ってアクティベーションを しなければならないところにある。 あとは、対象鍵とnonceを使ってOTPを生成するところは単要素と同じ。 この部分は、単要素と同じ記述が並んでいる。

Any memorized secret used by the authenticator for activation SHALL be a randomly-chosen numeric secret at least 6 decimal digits in length or other memorized secret meeting the requirements of Section 5.1.1.2 and SHALL be rate limited as specified in Section 5.2.2. A biometric activation factor SHALL meet the requirements of Section 5.2.3, including limits on the number of consecutive authentication failures.

パスワードは、ランダムに指定した6文字以上の数字か、5.1.1.2で定めたパスワードの 要件を満たすものでなければならない。 ここには必ずレート制限をかけること。
生体認証の場合、5.2.3で定める要件を満たすこと。最大許容失敗回数を定めること。

The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — SHALL be zeroized immediately after an OTP has been generated.

鍵を復号したもの、アクティベーションに使った秘密、認証に使った生体情報は OTPを生成した直後に消しておかなければならない。

5.1.5.2 Multi-Factor OTP Verifiers

Multi-factor OTP verifiers effectively duplicate the process of generating the OTP used by the authenticator, but without the requirement that a second factor be provided. As such, the symmetric keys used by authenticators SHALL be strongly protected against compromise.

When a multi-factor OTP authenticator is being associated with a subscriber account, the verifier or associated CSP SHALL use approved cryptography to either generate and exchange or to obtain the secrets required to duplicate the authenticator output. The verifier or CSP SHALL also establish, via the authenticator source, that the authenticator is a multi-factor device. In the absence of a trusted statement that it is a multi-factor device, the verifier SHALL treat the authenticator as single-factor, in accordance with Section 5.1.4.

The verifier SHALL use approved encryption and an authenticated protected channel when collecting the OTP in order to provide resistance to eavesdropping and MitM attacks. Time-based OTPs [RFC 6238] SHALL have a defined lifetime that is determined by the expected clock drift — in either direction — of the authenticator over its lifetime, plus allowance for network delay and user entry of the OTP. In order to provide replay resistance as described in Section 5.2.8, verifiers SHALL accept a given time-based OTP only once during the validity period. In the event a claimant’s authentication is denied due to duplicate use of an OTP, verifiers MAY warn the claimant in case an attacker has been able to authenticate in advance. Verifiers MAY also warn a subscriber in an existing session of the attempted duplicate use of an OTP.

If the authenticator output or activation secret has less than 64 bits of entropy, the verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2. A biometric activation factor SHALL meet the requirements of Section 5.2.3, including limits on the number of consecutive authentication failures.

この部分は単要素OTPと本質的に同じ。調整されているところをあげておく。

1. 認証器が多要素認証器であるという確証が必要。そうでない場合は単要素OTPとして扱わなければならない。
2. OTPを重複して使用したということでclaimantの認証要求を拒否する場合、またセッションの途中で重複して使用しようとしたとき、検証者は、 攻撃者がいるかもしれないという警告を利用者に出しても良い。

二番目がある理由は以下のとおりである。
多要素OTP装置は、単独でAAL2の認証器として用いることができる。 しかも、claimantがいきなり飛び込みで認証要求をかける形になる（単要素OTPの 場合は、パスワードを使った認証が済んでいる形になっているので、この リスクが減じられる）ので、セッションを確立するまでの攻撃のリスクの 見積もりが必要である。

5.1.6 Single-Factor Cryptographic Software

5.1.6.1 Single-Factor Cryptographic Software Authenticators

Single-factor software cryptographic authenticators encapsulate one or more secret keys unique to the authenticator. The key SHALL be stored in suitably secure storage available to the authenticator application (e.g., keychain storage, TPM, or TEE if available). The key SHALL be strongly protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access. Single-factor cryptographic software authenticators SHOULD discourage and SHALL NOT facilitate the cloning of the secret key onto multiple devices.

いや、絶対疲れてるって。こんなに簡単な記述で許されるはずがない。
単要素ソフトウェア暗号認証器とは、1つ以上の秘密鍵を中に封入したものである。 認証器のアプリケーションで利用可能なセキュアな場所に格納しなければならない。 これにはキーチェイン、TPM, TEEが含まれる。Windowsなら証明書ストアが 対応する。 鍵は、オーソライズされていない鍵の開示から強く守られていなければならない。 これにはアクセスを要求するソフトウェアのみにアクセスを許すような制限を かけていなければならない。 たとえば証明書ストアが「セキュアな場所」というのは、DCMが制御しているから ということになっている。 秘密鍵をコピーして複製を作ることをやってはいけないし、利用者にやらせることを 抑止すべきである。
代表的なものとしてはSSHの公開鍵認証用の秘密鍵、証明書認証用の秘密鍵がある。 IISが、サーバ証明書の鍵を生成と同時にしまい込むのは上記運用の典型例。
TPMとTEEについて追加の説明をする。TPM（Trusted Platform Module）は、 秘密鍵を封入できるチップセットで、RSAを始めとする暗号計算が、チップの 中でできるものである。セキュリティの要件が業界団体である TCG (Trusted Computing Group) で定められている。現在は多くの計算機の上に搭載されるようになった。 2015年にISO/IEC規格になった。 TEEは、IntelがTPMを拡張して、ある程度の普通の計算もできるようにしたものである。

5.1.6.2 Single-Factor Cryptographic Software Verifiers

The requirements for a single-factor cryptographic software verifier are identical to those for a single-factor cryptographic device verifier, described in Section 5.1.7.2.

5.1.7.2でまとめて述べるよといっているだけ。 後のものもそうだが、「装置」に関する要件を書いたのちに「ソフトウェア」の 要件を書いたというのが想像できる書き方である。

5.1.7 Single-Factor Cryptographic Devices

5.1.7.1 Single-Factor Cryptographic Device Authenticators

Single-factor cryptographic device authenticators encapsulate one or more secret keys unique to the device that SHALL NOT be exportable (i.e., cannot be removed from the device). The authenticator operates by signing a challenge nonce presented through a direct computer interface (e.g., a USB port). Alternatively, the authenticator could be a suitably secure processor integrated with the user endpoint itself (e.g., a hardware TPM). Although cryptographic devices contain software, they differ from cryptographic software authenticators in that all embedded software is under control of the CSP or issuer and that the entire authenticator is subject to all applicable FIPS 140 requirements at the AAL being authenticated.

単要素暗号装置認証器とは、1つ以上の、装置に一意な秘密鍵を封入した装置である。 秘密鍵はエクスポート可能であってはならない。 計算機に直接接続する、USBポートなどのるインターフェイスを通じてチャレンジされたnonceに署名を行う。 または、ハードウェアTPMなど、利用者の端末自身と一体化したセキュアな処理装置であってもよい。 この装置の中のソフトウェアは、CSPまたは装置の発行者の制御下に完全に置かれている点、さらに認証器全体がFIPS 140の要求要件を満たさなければならない点で 「暗号ソフトウェア認証器」と区別する。
ここでTPMに言及するのは、暗号の鍵とアルゴリズムについてはFIPS 140を満たしていることを 前提に、耐タンパ性についてはTCGに信頼を置いていることを表している。

The secret key and its algorithm SHALL provide at least the minimum security length specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The challenge nonce SHALL be at least 64 bits in length. Approved cryptography SHALL be used.

暗号鍵とアルゴリズムはSP 800-131Aに従わなければならない。チャレンジのnonceは 最低64bit。 ここらへん、国内の規格を自然に指定できるのがアメリカの強いところなんだろう。

Single-factor cryptographic device authenticators SHOULD require a physical input (e.g., the pressing of a button) in order to operate. This provides defense against unintended operation of the device, which might occur if the endpoint to which it is connected is compromised.

単要素暗号装置認証器は、ボタンを押すなどの物理的な操作を要求すべきである。 こうすることで、端末が危殆化しているときなどに意図しない操作が行われるのを 防止することができる。

5.1.7.2 Single-Factor Cryptographic Device Verifiers

Single-factor cryptographic device verifiers generate a challenge nonce, send it to the corresponding authenticator, and use the authenticator output to verify possession of the device. The authenticator output is highly dependent on the specific cryptographic device and protocol, but it is generally some type of signed message.

単要素暗号装置は、チャレンジ・アンド・レスポンス方式でその所有を確認する。
challenge and responseは、以下のような認証方式である。

1. セットアップとして、サーバとクライアントが情報を「共有」する。それは パスワードのハッシュであっても良いし、公開鍵であっても良い。対話的ゼロ知識証明の時は、共有される問題かもしれない。
2. サーバが認証プロセスを開始する。nonceを生成 (challenge) してクライアントに送る。
3. クライアントは、送られたnonceに対して、一定の操作を行う。 パスワードの場合は、ハッシュを追加してさらにハッシュを取ることかもしれないし、 公開鍵暗号の場合は、クライアントの秘密鍵でnonceを暗号化することかもしれない。 生成したデータ（response）をサーバに送る。
4. サーバは、responseとchallengeが整合しているかどうかをverifyする。

たとえば、Webのダイジェスト認証は、典型例である。通信路を通るデータからは 秘密の情報（パスワード本体や秘密鍵）を復元できないので、安全性が高い。 しかし、ここでチャレンジ・アンド・レスポンスを指定するんだな。これしか ないんだろうけど。
認証器の出力は、利用者の端末に直接接続して提供されるが、その方式は装置とプロトコルごとに決まっていてよい。電子署名の形をとることが多かろう。

The verifier has either symmetric or asymmetric cryptographic keys corresponding to each authenticator. While both types of keys SHALL be protected against modification, symmetric keys SHALL additionally be protected against unauthorized disclosure.

検証者は、対応する対象鍵か非対象鍵を持っているはずで、それは変更に対して 保護されていなければならない。対象鍵の場合は、さらにオーソライズされていない 開示に対して保護されなければならないとしている。

The challenge nonce SHALL be at least 64 bits in length, and SHALL either be unique over the authenticator’s lifetime or statistically unique (i.e., generated using an approved random bit generator [SP 800-90Ar1]). The verification operation SHALL use approved cryptography.

nonceは最低64ビット。認証器に対して一意、または統計的に一意でなければならない。 後者は、800-90Ar1に定めるランダムビット生成器を用いて生成されたもので なければならないことを意味する。検証には承認済みの暗号を使わなければならない。

5.1.8 Multi-Factor Cryptographic Software

5.1.8.1 Multi-Factor Cryptographic Software Authenticators

Multi-factor software cryptographic authenticators encapsulate one or more secret keys unique to the authenticator and accessible only through the input of an additional factor, either a memorized secret or a biometric. The key SHOULD be stored in suitably secure storage available to the authenticator application (e.g., keychain storage, TPM, TEE). The key SHALL be strongly protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access. Multi-factor cryptographic software authenticators SHOULD discourage and SHALL NOT facilitate the cloning of the secret key onto multiple devices.

Each authentication operation using the authenticator SHALL require the input of both factors.

ここも、単要素暗号ソフトウェアのほとんどコピペ。 違いをあげておく。まず「記憶秘密か生体情報を使った追加要素の入力で アクセス可能になること」と、第二要素を定義していること。 鍵の格納場所はセキュアな場所にするべきである、と単要素に比べて一段階要求を さげていることである。下げても良いのは、第二要素で守られているから。

Any memorized secret used by the authenticator for activation SHALL be a randomly-chosen numeric value at least 6 decimal digits in length or other memorized secret meeting the requirements of Section 5.1.1.2 and SHALL be rate limited as specified in Section 5.2.2. A biometric activation factor SHALL meet the requirements of Section 5.2.3, including limits on the number of consecutive authentication failures.

パスワードと生体情報については、要件を定めておく。パスワードは、最低6桁以上の数字でなければならないとする。それ以外でもよいが、その場合は、5.1.1.2で定めた要件を満たすこと。さらに、レート制限をかけなければならないとする。 現実的には6桁以上の数字だろうか。ちなみにJALの会員カードは 数字6桁。それをWebへのパスワードに流用しているのはいろいろ批判の対象になるだろう。 生体情報についても5.2.3で示す要件を満たすこととする。これについても、連続した失敗に対する制限をかけておかなければならない。 ちなみに、これとは関係ないが、佐藤のスマホの指紋認証、結構失敗するのだが…

The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — SHALL be zeroized immediately after an authentication transaction has taken place.

認証時に、暗号化されていない鍵、アクティベーションに使った パスワードや生体情報の採取された標本は、認証のトランザクション終了後 直ちに消去しなければならないとする。どこかで事故があった？

5.1.8.2 Multi-Factor Cryptographic Software Verifiers

The requirements for a multi-factor cryptographic software verifier are identical to those for a single-factor cryptographic device verifier, described in Section 5.1.7.2. Verification of the output from a multi-factor cryptographic software authenticator proves use of the activation factor.

これは検証する側に対する要求要件。チャレンジ・レスポンス方式をはじめ、 単要素暗号ソフトウェアに対するものと同じ。 この検証で、アクティベーションに使った要素を使ったことの証明もできる。

5.1.9 Multi-Factor Cryptographic Devices

5.1.9.1 Multi-Factor Cryptographic Device Authenticators

Multi-factor cryptographic device authenticators use tamper-resistant hardware to encapsulate one or more secret keys unique to the authenticator and accessible only through the input of an additional factor, either a memorized secret or a biometric. The authenticator operates by signing a challenge nonce presented through a direct computer interface (e.g., a USB port). Alternatively, the authenticator could be a suitably secure processor integrated with the user endpoint itself (e.g., a hardware TPM). Although cryptographic devices contain software, they differ from cryptographic software authenticators in that all embedded software is under control of the CSP or issuer, and that the entire authenticator is subject to any applicable FIPS 140 requirements at the selected AAL.

The secret key and its algorithm SHALL provide at least the minimum security length specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The challenge nonce SHALL be at least 64 bits in length. Approved cryptography SHALL be used.

ここまでの記述は、単要素ソフトウェア装置と、アクティベーションの要件を追加した以外はほぼ同じ。 ただし、 秘密鍵は耐タンパ性を持つハードウェアを用いて保護することを規定し、単要素の場合の 「エクスポート可能であってはならない」の条件を補強する。

Each authentication operation using the authenticator SHOULD require the input of the additional factor. Input of the additional factor MAY be accomplished via either direct input on the device or via a hardware connection (e.g., USB, smartcard).

認証は、追加要素の入力を求める「べき」であるとする。 直接入力でもよいが、直接ハード的な接続を追加要素としても良いとする。 え？

Any memorized secret used by the authenticator for activation SHALL be a randomly-chosen numeric value at least 6 decimal digits in length or other memorized secret meeting the requirements of Section 5.1.1.2 and SHALL be rate limited as specified in Section 5.2.2. A biometric activation factor SHALL meet the requirements of Section 5.2.3, including limits on the number of consecutive authentication failures.

The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — SHALL be zeroized immediately after an authentication transaction has taken place.

ここは、単要素暗号ソフトウェアのものと同一。

5.1.9.2 Multi-Factor Cryptographic Device Verifiers

The requirements for a multi-factor cryptographic device verifier are identical to those for a single-factor cryptographic device verifier, described in Section 5.1.7.2. Verification of the authenticator output from a multi-factor cryptographic device proves use of the activation factor.

ここも、単要素暗号ソフトウェアのものと同一。

5.2 General Authenticator Requirements

ここでは、書く認証器に共通の一般的な要件を定める。 ここで書かれていることは、一定の脅威モデルを前提とするので、 本当は8. Threats and Security Considerations を対照して読むのがよろしい。

5.2.1 Physical Authenticators

CSPs SHALL provide subscriber instructions on how to appropriately protect the authenticator against theft or loss. The CSP SHALL provide a mechanism to revoke or suspend the authenticator immediately upon notification from subscriber that loss or theft of the authenticator is suspected.

まずは認証器実体に対する要件。 CSPに対する要件として、利用者に、盗難、紛失対策をどうしたらよいか指示を 与えなければならないとする。 また、盗難、紛失が疑われると通知をうけた時点で直ちに失効 (revoke)、停止(suspend) ができる方式を提供しなければならないとする。失効、停止の執行はCSPが することはもちろんである。

5.2.2 Rate Limiting (Throttling)

When required by the authenticator type descriptions in Section 5.1, the verifier SHALL implement controls to protect against online guessing attacks. Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts on a single account to no more than 100.

これは、オンラインでの推測に対するセキュリティ対策。 検証者が実装しなければならないものとする。 具体的な認証器について規定しない限り、検証者は、同一のアカウントについて、 連続した認証失敗を100未満に制限しなければならない。

Additional techniques MAY be used to reduce the likelihood that an attacker will lock the legitimate claimant out as a result of rate limiting. These include:

以下、攻撃者が、逆にこれを利用して正当な利用者をロックしようとする攻撃の 可能性を減らすためにしてもよいことをあげる。

• Requiring the claimant to complete a CAPTCHA before attempting authentication.

  CAPTCHAの利用

• Requiring the claimant to wait following a failed attempt for a period of time that increases as the account approaches its maximum allowance for consecutive failed attempts (e.g., 30 seconds up to an hour).

  認証が失敗したら一定の時間待つことになるが、失敗を重ねる度に増やしていくこと

• Accepting only authentication requests that come from a white list of IP addresses from which the subscriber has been successfully authenticated before.

  利用者が以前成功したIPアドレスをホワイトリストとして取ってい置いて、 そこからのアクセスしか許さないこと

• Leveraging other risk-based or adaptive authentication techniques to identify user behavior that falls within, or out of, typical norms.

  その他、一定の規準にしたがう振舞をもとにした、リスクベース、または適応的な認証を行うこと

たとえばGoogleなどは、利用している装置のMACアドレスや、アクセスしているIPアドレスの地域をもとにして振舞解析を利用し、そこから認証を突破したものについては 利用者のメールアドレスに警告を送るようにしている。これなどは、最後の項に 当てはまる。

When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts for that user from the same IP address.

一回認証に成功したら、同一IPアドレスからの失敗の履歴は捨てるべきであるとする。スロットリングは、結構弱い方法である。「認証失敗」は攻撃者でもできるからである。それを避けるための方法は…難しいだろうなぁ。

5.2.3 Use of Biometrics

The use of biometrics (something you are) in authentication includes both measurement of physical characteristics (e.g., fingerprint, iris, facial characteristics) and behavioral characteristics (e.g., typing cadence). Both classes are considered biometric modalities, although different modalities may differ in the extent to which they establish authentication intent as described in Section 5.2.9.

ここでは生体情報の利用について説明する。2004年の版では、「生体認証は扱わない」 としていたが、このご時勢、何か決めて制御しておかないといけないという 判断が働いたのだろう。

For a variety of reasons, this document supports only limited use of biometrics for authentication. These reasons include:

• The biometric False Match Rate (FMR) does not provide confidence in the authentication of the subscriber by itself. In addition, FMR does not account for spoofing attacks.

生体情報のFMR (False Match Rate, False Positiveを発生させる確率)は それ単独では利用者認証の信頼性を表すものではないし、なりすまし攻撃が発生した根拠となるものでもない。FMRについて、アメリカではなにかご機嫌な誤解が広まっている？広まっているなら、早晩日本に「正しい」ものとして紹介する人が出てくるぞ（予言）。

• Biometric comparison is probabilistic, whereas the other authentication factors are deterministic.

他の認証方法が決定的であるのに対し、生体認証は確率的な性格を持つ。False positive, False negativeの可能性を考えておかなければならない。

• Biometric template protection schemes provide a method for revoking biometric credentials that is comparable to other authentication factors (e.g., PKI certificates and passwords). However, the availability of such solutions is limited, and standards for testing these methods are under development.

  生体テンプレートとは、生体情報から特徴量を抽出しておいて、採取された標本とマッチングを とれるようにしたもの。そのプロテクションは、その情報を不正にゲットすることから防御する方法。PKIの証明書に対するパスワードを考えるとわかりやすいが、防御方法を定めておくと、情報の失効が可能になる（所謂アクティベーションのために、1ステップ要求するため）。しかし、この方法論はまだ開発途上であるとしている。たとえば、 Biometric Template Protection: Bridging the Performance Gap Between Theory and Practice などが参考になるかもしれない。

• Biometric characteristics do not constitute secrets. They can be obtained online or by taking a picture of someone with a camera phone (e.g., facial images) with or without their knowledge, lifted from objects someone touches (e.g., latent fingerprints), or captured with high resolution images (e.g., iris patterns). While presentation attack detection (PAD) technologies (e.g., liveness detection) can mitigate the risk of these types of attacks, additional trust in the sensor or biometric processing is required to ensure that PAD is operating in accordance with the needs of the CSP and the subscriber.

  そして、生体情報は秘密ではないことをここで確認する。顔などは、オンラインや、そうでなくても写真を取ることで知らない間に「流出」するし、指紋などはどこかにさわればそこから流出するし、また光彩は細精度イメージから取得できる。日本でも、ネットにころがっている画像、特に スマホで取った画像や写真からどのような生体情報が取得できるかがが議論されたことがあった。 指紋などは楽勝らしい。もっとも、これを積極的に利用しようとする 日立 のような方向もあるのでなかなか悩ましい。PAD (presentation attack detection)とよばれる提示攻撃検出技術で、これらのリスクは軽減できるが、センサーや処理側で、CSPや利用者の需要に応じて、PADが動作していることを保証するなんらかの追加の信用が必要になる。

生体認証にかかる限界に関する問題点を列挙しているが、もちろん、これ以外にもある。このように、問題を列挙してそれを解決するというスタイルは、まぁ、アメリカンなのだが、そこから漏れた問題を無視しがちというのもまたアメリカンである。例えば、生体認証業界ではFMRと並べてFRR (False Rejection Rate)などのさまざまな指標が問題になるが、セキュリティの観点からは拒否する分には問題ないということだろう。

Therefore, the limited use of biometrics for authentication is supported with the following requirements and guidelines:

このように限界があるので、制限された形で使うのがよかろう。そのための 要求要件とガイドラインを以下にあげる。

Biometrics SHALL be used only as part of multi-factor authentication with a physical authenticator (something you have).

まず1点目。生体情報は、物理的認証器を使った多要素認証の一部として使わなければならない。 これで、生体認証単独は禁止（確率的認証の性格、PADの未熟さ）生体認証＋パスワードは禁止。

An authenticated protected channel between sensor (or an endpoint containing a sensor that resists sensor replacement) and verifier SHALL be established and the sensor or endpoint SHALL be established and the sensor or endpoint SHALL be authenticated prior to capturing the biometric sample from the claimant.

2点目。認証に用いるセンサーと検証者間のチャネルは認証して確立しなければならない。センサーは、claimantから生体情報の標本を取得する前に認証して確立しておかなければならない。攻撃側が支配することがより容易であることを反映しているのだろう。

The biometric system SHALL operate with an FMR [ISO/IEC 2382-37] of 1 in 1000 or better. This FMR SHALL be achieved under conditions of a conformant attack (i.e., zero-effort impostor attempt) as defined in [ISO/IEC 30107-1].

3点目。FMRは1/1000以下。conformant attack (これ自身は生体情報の提示攻撃を定義するISO 30107内で定義され、攻撃者がなんの工夫も加えずに間違って認証に成功してしまうことを指す。 認証が確率的だからこういうことが起きる)の条件の下で計測して達成しなければならない。 詳細はねぇ、例えば NISTの生体認証の強さに関する文書とか、FIDOの文書を参照するのが良いのではないか。
提示攻撃（presentation attack）検出について、少し解説を加える。 ISO30107-1は、これについて規定するものである。まず、提示攻撃のタイプを以下のように定義する。

人工的なもの

完全型	グミ、顔のビデオ撮影
部分型	指に塗る糊、サングラス、メーキャップ

人間に由来するもの

Lifeless	死体の利用、切断部分の利用
Altered	部分切断、指紋の取替え手術
Coerced	無意識下の窃取、脅しによる強制
Conformant	zero effort imposter attempt (確率性を利用した間違いの期待)

引用するだけで気分が悪くなるが、その中で、この文書が相手にするのは、zero effort imposter attemptだけである。 これに対して、以下のような検出手法を定める。 データ取得時

Lifeless	人工物の検出、livenessの検出、障害物の検出
Altered	パターン検出
Coerced	non-conformanceのパターン検出、強制されたときのストレス検査

システムレベル

失敗回数のカウント

地理的、時間的な情報の利用

監視カメラによる監視

軍事や治安などクリティカルなところ、消費者むけでも、銀行などは今でもきちんとやっているだろう。 ただし、これらが本格的に配備される可能性は必ずしも高くない。近い将来でも。下でPAD配備が必須の方向であると言っているが、ちょっとねぇ。

The biometric system SHOULD implement PAD. Testing of the biometric system to be deployed SHOULD demonstrate at least 90% resistance to presentation attacks for each relevant attack type (i.e., species), where resistance is defined as the number of thwarted presentation attacks divided by the number of trial presentation attacks. Testing of presentation attack resistance SHALL be in accordance with Clause 12 of [ISO/IEC 30107-3]. The PAD decision MAY be made either locally on the claimant’s device or by a central verifier.

4点目。PADは実装しておくべきである。提示攻撃の各攻撃タイプに対して90%以上の耐性率を示すべきである。 耐性率は、(撃退数/トライ数) とする。 提示攻撃耐性の試験は、ISO 30107-3のClause 12に準拠しなければならない。 PADは、claimantの装置でローカルに判断を下してもよいし、また検証者が中央的に下してもよい。 PADは、将来的には必須のものになる予定である。

Note: PAD is being considered as a mandatory requirement in future editions of this guideline.

The biometric system SHALL allow no more than 5 consecutive failed authentication attempts or 10 consecutive failed attempts if PAD meeting the above requirements is implemented. Once that limit has been reached, the biometric authenticator SHALL either:

• Impose a delay of at least 30 seconds before the next attempt, increasing exponentially with each successive attempt (e.g., 1 minute before the following failed attempt, 2 minutes before the second following attempt), or
• Disable the biometric user authentication and offer another factor (e.g., a different biometric modality or a PIN/Passcode if it is not already a required factor) if such an alternative method is already available.

5点目。生体認証は、5回以上連続した失敗を許容してはいけない。PADが実装されていれば、 10回以上の連続した失敗を許容してはならない。制限を超たえときの処理は、以下のうちの一つとしなければならない。

• 次回のトライまで最低30秒間をおく。これ以降は間隔を倍々（指数関数的）で増やしておくこと。
• その認証方式をdisableする。他の方式が利用可能ならばそれを提供する。

The verifier SHALL make a determination of sensor and endpoint performance, integrity, and authenticity. Acceptable methods for making this determination include, but are not limited to:

• Authentication of the sensor or endpoint.
• Certification by an approved accreditation authority.
• Runtime interrogation of signed metadata (e.g., attestation) as described in Section 5.2.4.

6点目。今度は検証者の方。センサーの性能、品質、信頼性についての要件を自ら定めなければならない。要件は以下を含む（これに限定はされないが）

• センサーの信頼度
• 承認されたクレデンシャルの権威の認定
• 下(5.2.4)で記述した署名ずみメタデータの実行時の検査

Biometric comparison can be performed locally on claimant’s device or at a central verifier. Since the potential for attacks on a larger scale is greater at central verifiers, local comparison is preferred.

7点目の前提。生体認証はclaimantの装置でローカルに行うか、検証者のほうで中央的に 行うかどちらかになる。中央で行うと大規模攻撃の可能性がある場合は、ローカルに行うほうがよい。 それで、中央で行う場合の要件。

If comparison is performed centrally:

• Use of the biometric as an authentication factor SHALL be limited to one or more specific devices that are identified using approved cryptography. Since the biometric has not yet unlocked the main authentication key, a separate key SHALL be used for identifying the device.
• Biometric revocation, referred to as biometric template protection in ISO/IEC 24745, SHALL be implemented.
• All transmission of biometrics SHALL be over the authenticated protected channel.

7点目。中央で認証を行う場合。

• 生体認証を行う場合は、装置を特定して実施すること。特定には承認された暗号技術を用いること。特定のための鍵は生体認証とは別のものを使うこと。
• 失効（生体テンプレート防御）ではISO24745を実装すること。
• 生体情報を通信で送る場合は認証されて保護されたチャネルを用いること。

Biometric samples collected in the authentication process MAY be used to train comparison algorithms or — with user consent — for other research purposes. Biometric samples and any biometric data derived from the biometric sample such as a probe produced through signal processing SHALL be zeroized immediately after any training or research data has been derived.

8点目。認証のために収集した生体情報の標本は、利用者同意を取ったうえで、 他の研究目的のために比較アルゴリズムの学習に用いてもよい。標本から二次的に生成した生体に関するデータ（プローブなど）は、学習や生成を行った後直ちに消去しなければならない。
要件は以上である。

Biometrics are also used in some cases to prevent repudiation of enrollment and to verify that the same individual participates in all phases of the enrollment process as described in SP 800-63A.

生体認証は、認証の他にも、否認否定にも用いられる。63A文書参照。

5.2.4 Attestation

An attestation is information conveyed to the verifier regarding a directly-connected authenticator or the endpoint involved in an authentication operation. Information conveyed by attestation MAY include, but is not limited to:

attestationの訳としては「証明書」「認定書」などがあてられているが、これだと certification (認証の行為自体) 、やverification (「検証」) validation (「検定」])などと紛らわしい。ここでは仮に「認定情報」と訳しておくが悩ましい。関係者、原語を併記するのを忘れずに。ちなみに、つい最近C++のpseudo signatureに「疑似署名」の訳語をあてているのを某所で発見した。これは、JISで訳語が決っているはずなのにそれを無視していること、どうみても間違っているのにスルーしていることなど、何重にも罪が重い。
さて、認定情報は、直接接続された認証器や、認証におけるエンドポイントに関して検証者に送られる情報である。以下のものを含んでよい（これに限定されるものではない）。

• The provenance (e.g., manufacturer or supplier certification), health, and integrity of the authenticator and endpoint.

  製品情報、活死情報、認定情報

• Security features of the authenticator.

  セキュリティ情報

• Security and performance characteristics of biometric sensor(s).

  生体情報のセンサーの場合、セキュリティと検知精度の情報

• Sensor modality.

  センサーのモード情報

If this attestation is signed, it SHALL be signed using a digital signature that provides at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication).

もし、この情報に署名をつけるなら、NIST 800-131Aで定める最低限のセキュリティレベルは保証しなければならない。

Attestation information MAY be used as part of a verifier’s risk-based authentication decision.

検証者は、この情報をリスクベースの決定に利用することが許される。

5.2.5 Verifier Impersonation Resistance

Verifier impersonation attacks, sometimes referred to as “phishing attacks,” are attempts by fraudulent verifiers and RPs to fool an unwary claimant into authenticating to an impostor website. In prior versions of SP 800-63, protocols resistant to verifier-impersonation attacks were also referred to as “strongly MitM resistant.”

対検証者なりすまし攻撃耐性、いわゆる「フィッシング攻撃」への対処。 にせの検証者とRPによって、claimantの不注意につけこんでにせのWebサイトへの認証に誘導するもの。前のバージョンの本文書では、これへの耐性を持つプロトコルを「強MitM耐性」と呼んでいた。 （今は、フィッシングの方がピンとくる）。 以下、耐性をもつ「プロトコル」への擬術的な要求要件をあげる。一般にいわれる「気を付ける」「アドレスバーを確認する」などの精神（運用）的な条項をあげるのではない。

A verifier impersonation-resistant authentication protocol SHALL establish an authenticated protected channel with the verifier. It SHALL then strongly and irreversibly bind a channel identifier that was negotiated in establishing the authenticated protected channel to the authenticator output (e.g., by signing the two values together using a private key controlled by the claimant for which the public key is known to the verifier). The verifier SHALL validate the signature or other information used to prove verifier impersonation resistance. This prevents an impostor verifier, even one that has obtained a certificate representing the actual verifier, from replaying that authentication on a different authenticated protected channel.

対検証者なりすまし攻撃耐性をもつプロトコルは、認証済の保護されたチャネルを検証者と確立しなければならない。その後、そのチャネルの確立の対象になったチャネルの識別子と認証器の出力を結合 (bind) しなければならない。結合の手段には、例えば検証者に公開されている公開鍵に対応する秘密鍵（claimantの制御下にあるもの）を用いて、チャネルの識別子と出力に対して署名することが含まれる。 検証者は、その署名等を検証（validate）しなければならない。 これによって、検証者のなりすましを、たとえ検証者の証明書を手に入れていても、認証済みで保護された他のチャネルに対する認証のリプレイ攻撃を抑止することができる。

Approved cryptographic algorithms SHALL be used to establish verifier impersonation resistance where it is required. Keys used for this purpose SHALL provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication).

ここでは、必要に応じて承認された暗号アルゴリズムを使わなければならない。 用いる鍵は、NIST 800-131Aで定める最低限のセキュリティレベルは保証しなければならない。 ここらへんは、定番の言い回しである。

One example of a verifier impersonation-resistant authentication protocol is client-authenticated TLS, because the client signs the authenticator output along with earlier messages from the protocol that are unique to the particular TLS connection being negotiated.

ここで、例として、クライアントが認証されたTLSをあげる。TLSの特定の接続にユニークな、プロトコル使用以前のメッセージとともに、認証器の出力に署名を付けることから、上の娘懸下満されることになる。

Authenticators that involve the manual entry of an authenticator output, such as out-of-band and OTP authenticators, SHALL NOT be considered verifier impersonation-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated. In a MitM attack, an impostor verifier could replay the OTP authenticator output to the verifier and successfully authenticate.

認証器の手動でのエントリーを含むようなものは、対検証者なりすまし攻撃耐性を持つものと してはならない（アウトオブバンド、OTPなど）。手動でのエントリーは、認証器の出力と認証されるセッションを結合しないと考えるのである。MitM攻撃では、なりすまし検証者は、検証者に対して、OTP認証器の出力をリプレイすることで認証に成功することが可能だろう。 ということで、フィッシング耐性を持つと認められるには、プロトコルで定めるものによる、セッションと認証器の自動的な結合が必須。

5.2.6 Verifier-CSP Communications

In situations where the verifier and CSP are separate entities (as shown by the dotted line in SP 800-63-3 Figure 4-1), communications between the verifier and CSP SHALL occur through a mutually-authenticated secure channel (such as a client-authenticated TLS connection) using approved cryptography.

検証者とCSPが異なる場合がある。フェデレーションプロトコルではよくあることで、 SAMLでは、artifactとして定義されている。このとき、検証者とCSPの間の通信は、クライアント認証されたTLSなどの相互に認証したセキュアなチャネルを通して行わなければならない。もちろん、使う暗号は承認済みのもので。

5.2.7 Verifier-Compromise Resistance

検証者の危殆化への対応

Use of some types of authenticators requires that the verifier store a copy of the authenticator secret. For example, an OTP authenticator (described in Section 5.1.4) requires that the verifier independently generate the authenticator output for comparison against the value sent by the claimant. Because of the potential for the verifier to be compromised and stored secrets stolen, authentication protocols that do not require the verifier to persistently store secrets that could be used for authentication are considered stronger, and are described herein as being verifier compromise resistant. Note that such verifiers are not resistant to all attacks. A verifier could be compromised in a different way, such as being manipulated into always accepting a particular authenticator output.

認証器の一部のやり方では、検証者が認証器の秘密のコピーを持つことを要求しているものがある。 たとえば、OTPの一部は、検証者が独立に認証器の出力を生成して、claimantの送る値と比較をする 形式のものがある。SecuriDのことだな。検証者側が危殆化し、秘密が盗まれる可能性を考えれば、 検証者にそのような秘密を格納しておくことを求めない認証プロトコルは、強いものであり、対検証者危殆化耐性を持つものと言えるだろう。まぁ、そんなことを言っても、上記のようにしても、すべての攻撃に耐性があるわけではない。たとえば、特定の認証器の出力すべてを受け取るようにハックされたらそれだけで終りである。

Verifier compromise resistance can be achieved in different ways, for example:

やり方はいくつかあって、

• Use a cryptographic authenticator that requires the verifier store a public key corresponding to a private key held by the authenticator.

  検証者に、認証器の持つ秘密鍵に対応する公開鍵を格納するようにする暗号を使った認証器を使う

• Store the expected authenticator output in hashed form. This method can be used with some look-up secret authenticators (described in Section 5.1.2), for example.

  出力をハッシュして格納する。たとえば参照型の認証器ではこれが採用されている

To be considered verifier compromise resistant, public keys stored by the verifier SHALL be associated with the use of approved cryptographic algorithms and SHALL provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication).

ここは、列挙の前半に対応するもの。このためには、検証者の格納する公開鍵は、承認済の暗号アルゴリズムのものでなければならない。まぁ当りまえだな。

Other verifier compromise resistant secrets SHALL use approved hash algorithms and the underlying secrets SHALL have at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). Secrets (e.g., memorized secrets) having lower complexity SHALL NOT be considered verifier compromise resistant when hashed because of the potential to defeat the hashing process through dictionary lookup or exhaustive search.

こちらは、列挙の後半に対応するもの。使うハッシュ関数は承認ずみのもので、 最低限のセキュリティ要件を満していなければならない。そうでなければ、辞書攻撃やブルートフォース攻撃への耐性はないと考えるべきである。

5.2.8 Replay Resistance

An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Replay resistance is in addition to the replay-resistant nature of authenticated protected channel protocols, since the output could be stolen prior to entry into the protected channel. Protocols that use nonces or challenges to prove the “freshness” of the transaction are resistant to replay attacks since the verifier will easily detect when old protocol messages are replayed since they will not contain the appropriate nonces or timeliness data.

リプレイ攻撃とは、過去の認証関連メッセージを記録しておいて、再生して認証を通り抜けることを言う。たとえば、5.2.5でいわゆるフィッシング攻撃への耐性を述べたが、それに追加の条件が加わる。 出力は、保護されるチャネルへ入力する以前に盗まれる可能性があるからである。nonceや、freshnessを証明するチャレンジを使うものはレプレイ攻撃への耐性があると考えてよい。過去のメッセージのレプレイを容易に検知できるからである。

Examples of replay-resistant authenticators are OTP devices, cryptographic authenticators, and look-up secrets.

In contrast, memorized secrets are not considered replay resistant because the authenticator output — the secret itself — is provided for each authentication.

OTP装置、暗号認証器、参照秘密は、対レプレイ耐性があるものの例としてあげられる。一方、記憶秘密（パスワード）はそうでない。認証器から同じパスワード（を加工した出力）が流れてくるからである。

5.2.9 Authentication Intent

An authentication process demonstrates intent if it requires the subject to explicitly respond to each authentication or reauthentication request. The goal of authentication intent is to make it more difficult for directly-connected physical authenticators (e.g., multi-factor cryptographic devices) to be used without the subject’s knowledge, such as by malware on the endpoint. Authentication intent SHALL be established by the authenticator itself, although multi-factor cryptographic devices MAY establish intent by reentry of the other authentication factor on the endpoint with which the authenticator is used.

認証の意図の話。主体（ここだけsubject。今まではclaimantと言っていたはず）が認証または 再認証において、明確な形で応答することを要求するとき、認証プロセスは意図を示すと言う事にする。直接接続した認証器が、主体の知らない間に用いられることを防ぐのが目的である。例えば端末に仕込まれたマルウェアは、陰に隠れて認証を突破しようとするだろう。認証意図は、認証器自身で確立されなければならない。ただし、多要素認証暗号装置であれば、一つの認証要素の確認を以て意図の確立としてよい。 ここら辺は該当する部分で議論した。SHALLの後にalthoughをつなげるのは、はっきり言って頭が悪い！

Authentication intent MAY be established in a number of ways. Authentication processes that require the subject’s intervention (e.g., a claimant entering an authenticator output from an OTP device) establish intent. Cryptographic devices that require user action (e.g., pushing a button or reinsertion) for each authentication or reauthentication operation are also establish intent.

認証の意図の確立は、特定の方法に囚われなくてもよい。認証がそのプロセスの中で主体者とのやり取り（OTP装置からの出力をclaimanが入力するなど）を要求するならば、「意図」は確立されることになる。

Depending on the modality, presentation of a biometric may or may not establish authentication intent. Presentation of a fingerprint would normally establish intent, while observation of the claimant’s face using a camera normally would not by itself. Behavioral biometrics similarly are less likely to establish authentication intent because they do not always require a specific action on the claimant’s part.

生体情報の提示をする場合は、認証意図の確立は装置のモードに依存する。 指紋を提示するのは、通常意図を確立することになるだろう。一方、カメラを使ってclaimantの顔を 示すのは、それだけでは意図を確立しない。同様に、振舞情報は認証意図を確立するとはいえない。 振舞情報はclaimant側で特定のアクションを要求することは普通はない。

5.2.10 Restricted Authenticators

As threats evolve, authenticators’ capability to resist attacks typically degrades. Conversely, some authenticators’ performance may improve — for example, when changes to their underlying standards increases their ability to resist particular attacks.

To account for these changes in authenticator performance, NIST places additional restrictions on authenticator types or specific classes or instantiations of an authenticator type.

脅威が進化するにつれて、認証器の攻撃耐性は劣化するのであるが、一方、認証器側でも、 標準の進化につれて性能があがり、特定の攻撃への耐性が上る可能性がある。
この手の変化を勘案して、認証器のタイプ、少なくとも特定のクラスや具体例に対して追加の「制限」をかけることにしている。

The use of a RESTRICTED authenticator requires that the implementing organization assess, understand, and accept the risks associated with that RESTRICTED authenticator and acknowledge that risk will likely increase over time. It is the responsibility of the organization to determine the level of acceptable risk for their system(s) and associated data and to define any methods for mitigating excessive risks. If at any time the organization determines that the risk to any party is unacceptable, then that authenticator SHALL NOT be used.

制限付きの認証器を使うためには、組織の評価、理解、関連するリスクの受容、さらにリスクは時間を経るにしたがい増大することを認めることが必要である。

Further, the risk of an authentication error is typically borne by multiple parties, including the implementing organization, organizations that rely on the authentication decision, and the subscriber. Because the subscriber may be exposed to additional risk when an organization accepts a RESTRICTED authenticator and that the subscriber may have a limited understanding of and ability to control that risk, the CSP SHALL:

さらに、認証エラーのリスクは、実装する会社やその認証を使うと決定した組織、離幼者を含む、複数の関係者が持つものである。 組織が制限付き認証器を採用し、利用者がそのリスクを制御するための知識を十分に持っていないことが考えられる時、CSP側で、以下の対応をしなければならない。

1. Offer subscribers at least one alternate authenticator that is not RESTRICTED and can be used to authenticate at the required AAL.

   利用者に、制限付きでない、同じAALを提供できる別の選択肢を最低１つ用意すること。

2. Provide meaningful notice to subscribers regarding the security risks of the RESTRICTED authenticator and availability of alternative(s) that are not RESTRICTED.

   制限付き認証器のセキュリティリスクと、選択肢として示される制限付きでない認証器の 利用可能性について、十分理解できる通知を行うこと

3. Address any additional risk to subscribers in its risk assessment.

   利用者に対して、リスク評価中（触れられていない）他のリスクに触れておくこと。

4. Develop a migration plan for the possibility that the RESTRICTED authenticator is no longer acceptable at some point in the future and include this migration plan in its digital identity acceptance statement.

   制限付き認証器が、将来のある時点で採用可能でなくなる可能性について、緩和策を策定し、 その緩和策をNIST SP800-53で定める「ディジタルアイデンティティ受容声明」中に含めること。

別の選択肢を用意せよ、というのは、アメリカの公的セクターで強く求められていることで、 ここでもこれがでてきた。
800-53で定める「ディジタルアイデンティティ受容声明」とは、リスク管理の一環として、 アイデンティティとアカウントをどのような場合に利用可能にするかを宣言するものである。 53でなくても、認証フェデレーションで同じことが要求されるものである。

ここで、5.2 一般的な条項について、まとめておく。5.2.3 生体認証は除くと、

1. 認証器実体に関する物理的要件 (Physical)
2. レート制限 (throttling)
3. 認定情報の利用 (attestation)
4. 検証者なりすまし攻撃
5. 検証者-CSP間の通信
6. 検証者危殆化
7. リプレイ耐性
8. 認証意図
9. 制限付き認証器の利用

認証器個別の議論のベースに、以上の項目から導き出せる脅威モデルに対応することが求められる。 論文を書いたり、製品報告を書くときの評価項目として使える。脅威モデルは、Sect. 8で改めて示されるが、この議論（と、Sect. 6, 7）を元にしている。関係者は参考にされたい（私も一応関係者 :)

6 Authenticator Lifecycle Management

This section is normative.

認証器のライフサイクル管理。この部分はnormative

A number of events can occur over the lifecycle of a subscriber’s authenticator that affect that authenticator’s use. These events include binding, loss, theft, unauthorized duplication, expiration, and revocation. This section describes the actions to be taken in response to those events.

認証器のライフサイクル中で、関係するものについて議論する。対象は以下の通り。

1. 結合
2. 紛失, 盗難 , 無許可での複製
3. 期限切れ
4. 失効

6.1 Authenticator Binding

Authenticator binding refers to the establishment of an association between a specific authenticator and a subscriber’s account, enabling the authenticator to be used — possibly in conjunction with other authenticators — to authenticate for that account.

認証器の結合（認証器と利用者のバインディングと言った方が分かりやすい？）とは、認証器を特定して、それを利用者のアカウントと結合し、必要なら他の認証器と併用して、当該認証器を使って認証をすることを可能にすることの確立のことである。 認証器を利用可能にするこのプロセスは、ライフサイクルの中でも特に重要なものである。 そして、この重要さに目くらまされて、失効などのいわゆる静脈系のプロセスを おろそかにした運用が珍しくない。

Authenticators SHALL be bound to subscriber accounts by either:

• Issuance by the CSP as part of enrollment; or
• Associating a subscriber-provided authenticator that is acceptable to the CSP.

These guidelines refer to the binding rather than the issuance of an authenticator as to accommodate both options.

認証器は、以下の方法で利用者アカウントに結合（バインド）しなければならない。

• CSPが、加入手続きの一環として認証器を発行する。
• CSPにアクセス可能な認証器を利用者が使うことで結合する

双方に対応するために「結合」という言葉を使う。「発行」は使わない。
この後、6.1.1--6.1.4で、各タイプについて説明する。4つあるので、ここでも項目を 4つ立てたらいいのに、と強く思う。疲れてる？

Throughout the digital identity lifecycle, CSPs SHALL maintain a record of all authenticators that are or have been associated with each identity. The CSP or verifier SHALL maintain the information required for throttling authentication attempts when required, as described in Section 5.2.2. The CSP SHALL also verify the type of user-provided authenticator (e.g., single-factor cryptographic device vs. multi-factor cryptographic device) so verifiers can determine compliance with requirements at each AAL.

アイデンティティのライフサイクルを通じて、CSPは、各アイデンティティに結合されている認証器の記録を保守（＝記録と状態の更新）しなければならない。 CSP又は検証者は5.2.2で述べた（このセクションはレート制限）認証のレート制限に必要な情報を保守しなければならない。 CSPは、各AALにおいて検証者が要求事項に準拠しているかどうかを判定できるように、 利用者が提示する認証器のタイプ（例：単要素暗号装置か多要素暗号装置かの区別）を 検証しなければならない。
ここら辺の情報は、登録時にしかわからないので、CSPの責任は結構重い。 でも、真ん中の項目はどうか？ここに書くことか？

The record created by the CSP SHALL contain the date and time the authenticator was bound to the account. The record SHOULD include information about the source of the binding (e.g., IP address, device identifier) of any device associated with the enrollment. If available, the record SHOULD also contain information about the source of unsuccessful authentications attempted with the authenticator.

CSPの作成する記録は認証器がアカウントに結合された日付、時刻を含まなければならない。 記録には、利用者登録時の装置の結合のやり方の情報（IPアドレス、装置の識別子）を 含まれるべきである。 可能ならば、その認証器を使った認証失敗の理由についての情報も含むべきである。
if availableの後にshouldをつけるのは頭が悪い。

When any new authenticator is bound to a subscriber account, the CSP SHALL ensure that the binding protocol and the protocol for provisioning the associated key(s) are done at a level of security commensurate with the AAL at which the authenticator will be used. For example, protocols for key provisioning SHALL use authenticated protected channels or be performed in person to protect against man-in-the-middle attacks. Binding of multi-factor authenticators SHALL require multi-factor authentication or equivalent (e.g., association with the session in which identity proofing has been just completed) be used in order to bind the authenticator. The same conditions apply when a key pair is generated by the authenticator and the public key is sent to the CSP.

新規の認証器が利用者アカウントに結合されるとき、CSPは結合に用いるプロトコルと結合された鍵を提供するプロトコルが認証器が使用されるAALと同等のセキュリティレベルで行われるように保証しなければならない。
として、例をあげる。 鍵提供のプロトコルは、認証済みの保護されたチャネルを使うか、MitM攻撃から守られるように本人対面のもと行われなければならない。 多要素認証器の結合時には、多要素認証か、それと同等のものを要求しなければならない。 たとえば、アイデンティティ証明が完了した直後のセッションと結合するとか。 鍵ペアが認証器内で生成され、公開鍵をCSPに送るときも、同様の条件を要求しなければならない。
これは、公開鍵と利用者アカウントの結合だから、公開鍵として別のものを潜り込まされてはいけないということ。公開鍵だから窃取について心配しているのではない。これくらいのことは書こうぜ。

以下、結合の各様態について説明を加える。

6.1.1 Binding at Enrollment

最初は、利用者登録と同時に認証器を結合する場合の説明

The following requirements apply when an authenticator is bound to an identity as a result of a successful identity proofing transaction, as described in SP 800-63A. Since Executive Order 13681 [EO 13681] requires the use of multi-factor authentication for the release of any personal data, it is important that authenticators be bound to subscriber accounts at enrollment, enabling access to personal data, including that established by identity proofing.

アイデンティティ証明に成功した結果として、認証器を同時にそのアイデンティティに結合する場合、 以下の要件を満たさなければならない。 個人情報をリリースする場合、多要素認証を要求するので、認証器が登録時に利用者アカウントに 結合され、その上で個人データ（アイデンティティ証明によって確立されたものを含む）に アクセスできるようにすることが重要である。
ここでExecutive Order 13768というのは、今やトランプによって乱発されている感のある「大統領令」で 発令年は2014年、発令者は当時のオバマ大統領、 消費者の金融取引のセキュリティ改善に関するものである。

The CSP SHALL bind at least one, and SHOULD bind at least two, physical (something you have) authenticators to the subscriber’s online identity, in addition to a memorized secret or one or more biometrics. Binding of multiple authenticators is preferred in order to recover from the loss or theft of the subscriber’s primary authenticator.

CSPは、記憶秘密（パスワード）又は、1つ以上の生体情報に加えて、 最低限一つの物理的に所有証明になる認証器を利用者のオンラインアイデンティティに 結合しなければならない。この個数は複数にすべきである。こうすると、利用者の主たる認証器の紛失、盗難からの回復をすることができる。

この発想はなかった。と言う人がいるのではないだろうか。

While all identifying information is self-asserted at IAL1, preservation of online material or an online reputation makes it undesirable to lose control of an account due to the loss of an authenticator. The second authenticator makes it possible to securely recover from an authenticator loss. For this reason, a CSP SHOULD bind at least two physical authenticators to the subscriber’s credential at IAL1 as well.

以降、各IALについて、結合の強さとの関係を述べる。
IAL1では、すべての識別情報は自己申告になるが、 オンラインの資料やオンラインの評価（レピュテーション）を保存しておけば、 認証器の紛失によってアカウントの統制を失なうことが望ましくないことにできる。
ん？ undesirableってなんだ？
メインでない認証器があると、メインの認証器の紛失からの回復をセキュアにすることができる。 したがって、IAL1であっても、CSPは、最低限2個の物理的な認証器を利用者のクレデンシャルに結合するべきである。

At IAL2 and above, identifying information is associated with the digital identity and the subscriber has undergone an identity proofing process as described in SP 800-63A. As a result, authenticators at the same AAL as the desired IAL SHALL be bound to the account. For example, if the subscriber has successfully completed proofing at IAL2, then AAL2 or AAL3 authenticators are appropriate to bind to the IAL2 identity. While a CSP MAY bind an AAL1 authenticator to an IAL2 identity, if the subscriber is authenticated at AAL1, the CSP SHALL NOT expose personal information, even if self-asserted, to the subscriber. As stated in the previous paragraph, the availability of additional authenticators provides backup methods for authentication if an authenticator is damaged, lost, or stolen.

IAL2以上であれば、識別情報はディジタルアイデンティティと結合され、 利用者はアイデンティティ証明プロセスを経てきている(63A)。 結果として、IALと同じレベルのAALを持つ認証器は、アカウントに結合されなければならない。たとえば、利用者がIAL2のアイデンティティ証明に成功しているなら、AAL2かAAL3のレベルの認証器は、IAL2レベルのアイデンティティに結合するのが適当である。 CSPが、AAL1レベルの認証器をIAL2レベルのアイデンティティに結合することは許されるが、AAL1で認証された利用者に対しては、CSPは個人情報を開示してはならない。 この個人情報が自己申告のものであってもである。 上で述べた通り、追加の認証器は、（メインの）認証器が損壊、紛失、盗難された場合のバックアップ手段として使える。
desirableの意味が何か特殊？それとも、執筆者のくせ？

If enrollment and binding cannot be completed in a single physical encounter or electronic transaction (i.e., within a single protected session), the following methods SHALL be used to ensure that the same party acts as the applicant throughout the processes:

加入と結合が、単一の物理的、または電子的なトランザクション（単一の保護されたセッション内）で完結しないとき、以下の方法を使って、一連のプロセスの中で、同一の者が申請者として動いていることを保証しなければならない。

For remote transactions:

1. The applicant SHALL identify themselves in each new binding transaction by presenting a temporary secret which was either established during a prior transaction, or sent to the applicant’s phone number, email address, or postal address of record.

2. Long-term authenticator secrets SHALL only be issued to the applicant within a protected session.

こちらはリモートでの結合の場合。

1. 申請者は、各トランザクションで、前のトランザクションで確立したか、 記録されている申請者の電話番号、Eメールアドレス、郵便住所宛てに送られた一時秘密を提示して、自分自身の身元確認をしなければならない。
2. 長期の認証用秘密は、保護されたセッション内でのみ、申請者に発行しなければならない。
   このonly、何にかかっているかわかんないんだよなぁ。普通に考えれば within...なんだけど、be issuedにかかっている？

For in-person transactions:

1. The applicant SHALL identify themselves in person by either using a secret as described in remote transaction (1) above, or through use of a biometric that was recorded during a prior encounter.

2. Temporary secrets SHALL NOT be reused.

3. If the CSP issues long-term authenticator secrets during a physical transaction, then they SHALL be loaded locally onto a physical device that is issued in person to the applicant or delivered in a manner that confirms the address of record.

こちらは、対面での場合。

1. 申請者は、リモートの場合と同じように身元確認を行うか、以前に記録されている生体情報を使って身元確認を行わなければならない。
2. 一時秘密は再利用してはならない。
3. CSPが物理的なトランザクション中に長期の認証用秘密を発行する場合、 その秘密は、対面で申請者に発行されたか、記録中のアドレスで確認したうえで配送された物理装置にローカルに格納しなければならない。

6.1.2 Post-Enrollment Binding

加入後の認証器の結合。こちらも大切。

6.1.2.1 Binding of an Additional Authenticator at Existing AAL

まず立てる項目として、既存のAALで、追加の認証器を結合する場合

With the exception of memorized secrets, CSPs and verifiers SHOULD encourage subscribers to maintain at least two valid authenticators of each factor that they will be using. For example, a subscriber who usually uses an OTP device as a physical authenticator MAY also be issued a number of look-up secret authenticators, or register a device for out-of-band authentication, in case the physical authenticator is lost, stolen, or damaged. See Section 6.1.2.3 for more information on replacement of memorized secret authenticators.

記憶秘密は別として、CSPと検証者は、各認証要素に対して、利用者に対し最低限2つの正当な認証器を持つように便宜をはかるべきである。 たとえば、通常OTP装置を物理認証器として使っている利用者には、その物理認証器の紛失、盗難、損壊に備えて、参照秘密型の認証器を発行するか、アウトオブバンド認証のための装置を登録しておいてよい。記憶秘密認証器の認証器の補充については6.1.2.3（すぐあと）で説明する。

Accordingly, CSPs SHOULD permit the binding of additional authenticators to a subscriber’s account. Before adding the new authenticator, the CSP SHALL first require the subscriber to authenticate at the AAL (or a higher AAL) at which the new authenticator will be used. When an authenticator is added, the CSP SHOULD send a notification to the subscriber via a mechanism that is independent of the transaction binding the new authenticator (e.g., email to an address previously associated with the subscriber). The CSP MAY limit the number of authenticators that may be bound in this manner.

対応してCSPは、利用者アカウントに追加の認証器の結合を許すべきである。 新規の認証器を追加する前に、CSPは利用者に対して、利用時のAALかそれ以上で 認証することを要求しなければならない。 認証器が追加されたら、CSPは、新規認証器を結合するのとは独立な方法を使って利用者に対する通知を行うべきである。 その例として、前から利用者と結合しているアドレスにメールを送ることがあげられる。 CSPは、結合する認証器の数に制限を設けてもよい。

6.1.2.2 Adding an Additional Factor to a Single-Factor Account

単要素を使っているアカウントに、認証要素を追加する場合

If the subscriber’s account has only one authentication factor bound to it (i.e., at IAL1/AAL1) and an additional authenticator of a different authentication factor is to be added, the subscriber MAY request that the account be upgraded to AAL2. The IAL would remain at IAL1.

利用者アカウントに結合されている認証要素が一つしかなく（IAL1/AAL1の場合）、 それとは異なる認証要素を追加する場合、利用者はそのアカウントをAAL2に アップグレードすることを要求することは許される。IALはそれとは独立にIAL1の ままのはずである。

Before binding the new authenticator, the CSP SHALL require the subscriber to authenticate at AAL1. The CSP SHOULD send a notification of the event to the subscriber via a mechanism independent of the transaction binding the new authenticator (e.g., email to an address previously associated with the subscriber).

新規の認証器を結合する前に、CSPは、AAL1で認証することを利用者に要求しなければならない。 認証器が追加されたら、CSPは、新規認証器を結合するのとは独立な方法を使って利用者に対する通知を行うべきである。

6.1.2.3 Replacement of a Lost Authentication Factor

紛失した認証要素の補充

If a subscriber loses all authenticators of a factor necessary to complete multi-factor authentication and has been identity proofed at IAL2 or IAL3, that subscriber SHALL repeat the identity proofing process described in SP 800-63A. An abbreviated proofing process, confirming the binding of the claimant to previously-supplied evidence, MAY be used if the CSP has retained the evidence from the original proofing process pursuant to a privacy risk assessment as described in SP 800-63A Section 4.2. The CSP SHALL require the claimant to authenticate using an authenticator of the remaining factor, if any, to confirm binding to the existing identity. Reestablishment of authentication factors at IAL3 SHALL be done in person, or through a supervised remote process as described in SP 800-63A Section 5.3.3.2, and SHALL verify the biometric collected during the original proofing process.

利用者が、多要素認証を完結するために必要な要素の認証器をすべて失ったとき、 もしIAL2/3でアイデンティティ証明されていても、利用者は、アイデンティティ証明プロセスを再度行わなければならない。 CSPが63-Aの4.2に記述した通りのプライバシーリスク評価に続いて、 元のアイデンティティ証明でのエビデンスを保有しているならば、claimantと前に提供されたエビデンスを結合を確認して、アイデンティティ証明のプロセスを省略してもよい。 CSPは、claimantに対して、既存のアイデンティティとの結合を確認するために、残りの認証要素を用いて認証するように要求しなければならない。 IAL3での認証要素の再確立は、対面か、63A 5.3.3.2で定める監督付きのリモートプロセスを通して行わなければならない。 さらに、元の証明プロセスで生体情報を収集していれば、それを検証しなければならない。

利用者は、認証器をなくした時点でclaimantに格下げして、そこからまたアイデンティティ証明を行わなければならない。これをするための手続きがここで決められているが、 結構ちゃんとしなければだわ。

The CSP SHOULD send a notification of the event to the subscriber. This MAY be the same notice as is required as part of the proofing process.

CSPは、関係する通知を利用者に行うべきである。 アイデンティティ証明の一環で求められる通知と同一であってよい。

Replacement of a lost (i.e., forgotten) memorized secret is problematic because it is very common. Additional “backup” memorized secrets do not mitigate this because they are just as likely to also have been forgotten. If a biometric is bound to the account, the biometric and associated physical authenticator SHOULD be used to establish a new memorized secret.

As an alternative to the above re-proofing process when there is no biometric bound to the account, the CSP MAY bind a new memorized secret with authentication using two physical authenticators, along with a confirmation code that has been sent to one of the subscriber’s addresses of record. The confirmation code SHALL consist of at least 6 random alphanumeric characters generated by an approved random bit generator [SP 800-90Ar1]. Those sent to a postal address of record SHALL be valid for a maximum of 7 days but MAY be made valid up to 21 days via an exception process to accommodate addresses outside the direct reach of the U.S. Postal Service. Confirmation codes sent by means other than physical mail SHALL be valid for a maximum of 10 minutes.

紛失した記憶秘密（＝パスワードを忘れた）の補充は、頻発するだけに問題である。 バックアップの記憶秘密は、それ自身が忘れられやすいために、このリスクを軽減しない。 アカウントに生体情報が結合されているならば、生体情報とそこに結合されている物理認証器を使って 新規の記憶秘密を確立すべきである。

アカウントに結合されている生体情報がない場合、 CSPは代替策として2個の認証器を用い、登録されている利用者のアドレス宛に確認コードを送付 することでアイデンティティの再証明をしてもよい。 確認コードは、6文字以上の、承認されたランダムビット生成器（SP800-90Ar1、これは 前にさんざん出てきた）によってランダムに生成されたアルファベットと数字の組み合わせでなければならない。 登録されている住所に郵送された確認コードは最大7日間有効でなければならない。 ただし、米郵便公社の直接サービス範囲外に送る場合、例外の手続きをして有効期間を21日間までは 延長しても良い。 それ以外（オンラインなど）の場合の有効期間は最大10分でなければならない。

パスワードのことをここにしのばせるの、よくない。それはさておき、どこかでやられているな。 それを採用したのだろう。筆者も、査読サイトでよくパスワードを忘れる（勘違いで、別のサイトのパスワードを入力）ことがあり、登録メールアドレスに、パスワードリセット用のURLを送ってくる。 これなんかは弱いんだろう。

6.1.3 Binding to a Subscriber-provided Authenticator

利用者持ち込みの認証器への結合

A subscriber may already possess authenticators suitable for authentication at a particular AAL. For example, they may have a two-factor authenticator from a social network provider, considered AAL2 and IAL1, and would like to use those credentials at an RP that requires IAL2.

利用者がすでに、特定のAALでの認証ができると認められる認証器を保持している場合がある。 たとえば、SNS業者から2要素認証器（AAL2/IAL1に相応）を受け取っていて、それをIAL2を要求するRP用に使いたいと思うことはある。

CSPs SHOULD, where practical, accommodate the use of subscriber-provided authenticators in order to relieve the burden to the subscriber of managing a large number of authenticators. Binding of these authenticators SHALL be done as described in Section 6.1.2.1. In situations where the authenticator strength is not self-evident (e.g., between single-factor and multi-factor authenticators of a given type), the CSP SHOULD assume the use of the weaker authenticator unless it is able to establish that the stronger authenticator is in fact being used (e.g., by verification with the issuer or manufacturer of the authenticator).

CSPは、実用上、このような利用者の持ち込み認証器を受け入れるべきである。これによって大量の認証器を管理する利用者の負担を解放することができる。 これらの認証器の結合は、「加入後の認証器の結合」（6.1.2.1）の通りになされなければならない。 認証器の強度が自明でない場合（たとえば、あるタイプの認証器が単要素か多要素か迷う場合）、 CSPは、強い方が実際に使われると確認できない限り、弱い方に推認すべきである。

6.1.4 Renewal

更新。結構重要である。

The CSP SHOULD bind an updated authenticator an appropriate amount of time before an existing authenticator’s expiration. The process for this SHOULD conform closely to the initial authenticator binding process (e.g., confirming address of record). Following successful use of the new authenticator, the CSP MAY revoke the authenticator that it is replacing.

CSPは、認証器の更新のために、期限切れの前に十分な時間を取るべきである。手続きは、最初の認証器の結合プロセスにできるだけ適合させるべきである。これには、登録住所の確認などが含まれる。 新規の認証器が動作することを確認後に、前の認証器を失効させてよい。 期限切れの確認を機械的にできるかどうかは必ずしも自明ではないからね。

ところで、1文め、bindというtechnical termと誤解されかねない語を不用意に使うのはとてもよくない。

6.2 Loss, Theft, Damage, and Unauthorized Duplication

ここからライフサイクルの中でも静脈系の話。まずは紛失、盗難、損壊、無許可複製。

Compromised authenticators include those that have been lost, stolen, or subject to unauthorized duplication. Generally, one must assume that a lost authenticator has been stolen or compromised by someone that is not the legitimate subscriber of the authenticator. Damaged or malfunctioning authenticators are also considered compromised to guard against any possibility of extraction of the authenticator secret. One notable exception is a memorized secret that has been forgotten without other indications of having been compromised, such as having been obtained by an attacker.

認証器の危殆化には、紛失、盗難、無許可複製が含まれる。 一般に、認証器が紛失したら、盗まれたか、正当な利用者以外の誰かによって危殆化されたと推認しなければならない。 認証器の損壊、故障も、認証器の秘密を取り出そうとする行為への防御の結果と して危殆化したとみなすことができる。 考慮を要する例外として、記憶秘密の場合に、攻撃者によって盗まれたなどの危殆化の印なしに忘れてしまうことがある。

で、どうしろと。

Suspension, revocation, or destruction of compromised authenticators SHOULD occur as promptly as practical following detection. Agencies SHOULD establish time limits for this process.

危殆化した認証器の停止、失効、破壊は、検知に続いてできるだけ速やかに（可及的速やかに、とでも いうのか。可及的…は日本語では意味が決まっているので、対応しているかどうかよくわからない） agencyは、この処理のために期限を切るべきである。このagencyは、暗に政府機関を指していると 思うのだが、一般にCSPと書いてだめなのか？

To facilitate secure reporting of the loss, theft, or damage to an authenticator, the CSP SHOULD provide the subscriber with a method of authenticating to the CSP using a backup or alternate authenticator. This backup authenticator SHALL be either a memorized secret or a physical authenticator. Either MAY be used, but only one authentication factor is required to make this report. Alternatively, the subscriber MAY establish an authenticated protected channel to the CSP and verify information collected during the proofing process. The CSP MAY choose to verify an address of record (i.e., email, telephone, postal) and suspend authenticator(s) reported to have been compromised. The suspension SHALL be reversible if the subscriber successfully authenticates to the CSP using a valid (i.e., not suspended) authenticator and requests reactivation of an authenticator suspended in this manner. The CSP MAY set a time limit after which a suspended authenticator can no longer be reactivated.

認証器の紛失、盗難、損壊のセキュアな報告方法として、 CSPは、利用者にバックアップか代替認証器を用いてCSPに対して認証する方法を提供すべきである。 バックアップ認証器は、記憶秘密か物理認証器でなければならない。 一方だけを使っても良いが、報告するには1つだけの認証要素が要求される。 バックアップ認証器を使わない場合、利用者は認証されて保護されたチャネルをCSPと確立し、 アイデンティティ証明プロセス中に収集した情報を検証しても良い。 CSPは、登録されたアドレス（メール、電話、郵便）の検証をして危殆化の報告があった認証器を停止することを 行ってよい。 つまり、利用者がCSPに対して正当な（停止中の認証器でない）認証器を 用いての認証に成功し、認証器の再アクティベーションを要求した場合、停止は解除しなければならない。 CSPは、停止した認証器の再アクティベーションができなくなるまでの制限時間を設定してよい。

6.3 Expiration

期限切れ

CSPs MAY issue authenticators that expire. If and when an authenticator expires, it SHALL NOT be usable for authentication. When an authentication is attempted using an expired authenticator, the CSP SHOULD give an indication to the subscriber that the authentication failure is due to expiration rather than some other cause.

The CSP SHALL require subscribers to surrender or prove destruction of any physical authenticator containing attribute certificates signed by the CSP as soon as practical after expiration or receipt of a renewed authenticator.

CSPは、有効期限付き認証器を発行しても良い。認証器が期限を迎えたならその時、それは認証に使用してはならない。 if and whenは、法律用語。で、なぜここに？期限切れの認証器を用いて認証をしようとした時、 CSPは利用者に対して、他ならぬ期限切れのために認証が失敗したと通知すべきである。 rather than some other causeも、以て回った言い方。どこかから文章を借りてきた？

CSPは、署名付き属性証明書を含む物理認証器を発行している場合、 利用者に対して期限切れ、または認証器の更新の領収書の受け取り後、実際上できるだけ速やかに 破棄、または破壊の証明を利用者に対して要求しなければならない。 attribute certificateって、専門用語なんだけどなぁ。ここでは属性が含まれるデータを CSPが署名している場合くらいの軽い気持ちで使われている気がする。

6.4 Revocation and Termination

失効と終了

Revocation of an authenticator — sometimes referred to as termination, especially in the context of PIV authenticators — refers to removal of the binding between an authenticator and a credential the CSP maintains.

認証器の失効（特に個人アイデンティティ検証 (PIV) 認証器の場合、時に終了と言われる）とは、 認証器とCSPの保持するクレデンシャルの結合を解消することである。ここで定義を与えるのだが、 "PIV" (personal identity verification)がいきなり出てきたり、これもどこからか持ってきたな。

CSPs SHALL revoke the binding of authenticators promptly when an online identity ceases to exist (e.g., subscriber’s death, discovery of a fraudulent subscriber), when requested by the subscriber, or when the CSP determines that the subscriber no longer meets its eligibility requirements.

利用者の死亡、非実在性の発見などでオンラインアイデンティティが存在しなくなった時、利用者から 要求があった時、利用者が適格性の要件を満たさないとCSPが決定した時、CSPは 速やかに認証器の結合を失効させなければならない。

The CSP SHALL require subscribers to surrender or certify destruction of any physical authenticator containing certified attributes signed by the CSP as soon as practical after revocation or termination takes place. This is necessary to block the use of the authenticator’s certified attributes in offline situations between revocation/termination and expiration of the certification.

Further requirements on the termination of PIV authenticators are found in FIPS 201.

CSPは、署名付き属性証明書を含む物理認証器を発行している場合、 利用者に対して、失効または終了が発生した後実際上できるだけ速やかに 破棄、または破壊の証明を利用者に対して要求しなければならない。 これは、認証器中の署名された属性を、失効/終了と証明書の期限切れの間でオフライン使用されるのをブロックするために 必要である。 PIV認証器の終了についての追加の要求要件についてはFIPS201を参照すること。

7 Session Management

This section is normative.

このセクションはnormative

Once an authentication event has taken place, it is often desirable to allow the subscriber to continue using the application across multiple subsequent interactions without requiring them to repeat the authentication event. This requirement is particularly true for federation scenarios — described in SP 800-63C — where the authentication event necessarily involves several components and parties coordinating across a network.

認証が一度確立されると、利用者に対して認証を繰り返すことを要求することなしに、複数の後続のやり取りにまたがってアプリケーションを使い続けることを利用者に許容することが望ましいことがしばしばある。利用者にとって、アプリケーションを使うときには認証は一度通ったらそれが利用中は、そして何回か中断しても有効であってほしい。ところが、利用者にとっては一連の処理であっても、システムから見るとそれが必ずしも担保されない。っていうか、アプリケーションを使うときに、認証を一度通ったとして、それがどのくらいの時間有効として認められるかの問題がある。これは、63Cで記述するフェデレーションの利用シナリオでは特に問題になる。 フェデレーションでは、必然的に、認証がネットワーク越しに複数の参加者が参加するからである。

To facilitate this behavior, a session MAY be started in response to an authentication event, and continue the session until such time that it is terminated. The session MAY be terminated for any number of reasons, including but not limited to an inactivity timeout, an explicit logout event, or other means. The session MAY be continued through a reauthentication event — described in Section 7.2 — wherein the user repeats some or all of the initial authentication event, thereby re-establishing the session.

セッションは、認証イベントの通過に応える形で開始し、終了するまで継続してよい。 第一文、文法おかしいよ（主語が迷走している）。 セッションを終了させる理由にはいろいろある。活動しなくなってタイムアウトがかかるとか、明示的にログアウトするとかは代表的な理由だが、それには限らない。 セッションは再認証（7.2で説明する）を経て継続してもよい。再認証では、userが、初期認証の一部または全部を繰り返してセッションを再確立する。 userが未定義で出てきたが、これはsubscriberの意味で使ってるんだろう。

Session management is preferable over continual presentation of credentials as the poor usability of continual presentation often creates incentives for workarounds such as cached unlocking credentials, negating the freshness of the authentication event.

クレデンシャルを何回も提示することより、セッション管理をした方がよい。何回も提示することはユーザビリティに劣り、そうすると、人間はクレデンシャルのキャッシュなどの回避策に逃げがちである。

7.1 Session Bindings

セッションの結合。bindingは、ここでは専門用語 session bindingとして 使われているはず。

A session occurs between the software that a subscriber is running — such as a browser, application, or operating system (i.e., the session subject) — and the RP or CSP that the subscriber is accessing (i.e., the session host). A session secret SHALL be shared between the subscriber’s software and the service being accessed. This secret binds the two ends of the session, allowing the subscriber to continue using the service over time. The secret SHALL be presented directly by the subscriber’s software or possession of the secret SHALL be proven using a cryptographic mechanism.

アプリケーション利用のセッションの定義をまず行う。occurなんて使わずに定義する方が良いと思う。それはともかく
セッションは、ブラウザ、アプリ又はOSなどの利用者が実行するソフトウェアと、利用者がアクセスするRPやCSPの間で結ばれる。 セッションに使われる秘密は利用者のソフトウェアとサービス側で共有されなければならない。 この秘密を使って、セッションの利用者とソフトウェアを結合し、利用者が サービスを使い続けることが可能になる。 秘密は、利用者が使っているソフトウェアに直接提示されなければならない。選択肢として、利用者が秘密を保持していることを暗号的な方法を使って証明されなければならない。
この「秘密」とは、通信のために交換される鍵のことである。

The secret used for session binding SHALL be generated by the session host in direct response to an authentication event. A session SHOULD inherit the AAL properties of the authentication event which triggered its creation. A session MAY be considered at a lower AAL than the authentication event but SHALL NOT be considered at a higher AAL than the authentication event.

セッションの結合のために用いる秘密は、認証のイベントに直接応答する形でセッションのホストが生成しなければならない。セッションは、生成のきっかけになった認証イベントのAALを引き継ぐべきである。 この場合、より低いAALを持つと考えても良いが、より高いAALを持つとみなしてはならない。 以下、セッション用の秘密の要求要件を規定する。

Secrets used for session binding:

1. SHALL be generated by the session host during an interaction, typically immediately following authentication.
2. SHALL be generated by an approved random bit generator [SP 800-90Ar1] and contain at least 64 bits of entropy.
3. SHALL be erased or invalidated by the session subject when the subscriber logs out.
4. SHOULD be erased on the subscriber endpoint when the user logs out or when the secret is deemed to have expired.
5. SHOULD NOT be placed in insecure locations such as HTML5 Local Storage due to the potential exposure of local storage to cross-site scripting (XSS) attacks.
6. SHALL be sent to and received from the device using an authenticated protected channel.
7. SHALL time out and not be accepted after the times specified in Sections 4.1.4, 4.2.4, and 4.3.4, as appropriate for the AAL.
8. SHALL NOT be available to insecure communications between the host and subscriber’s endpoint. Authenticated sessions SHALL NOT fall back to an insecure transport, such as from https to http, following authentication.

1. 秘密は、セッション中、特に認証の直後に、セッションのホストが生成しなければならない。
2. SP 800-90Ar1で承認されたランダムビット生成器によって、最低64bitエントロピーを持つように生成しなければならない。
3. 利用者がログアウトしたら、セッションの主体 (ホストと利用者装置双方と思うのだが、 単数になっているのはどういうことか) は、秘密を消去するか、無効化しなければならない。
4. 利用者がログアウト、または秘密が有効期限を過ぎたら、 利用者の端末側で消去するべきである。
5. セキュアでない場所に置くべきではない。HTML5のローカル記憶は、XSSに使われる可能性があるので、セキュアな場所ではない。
6. 秘密は、認証されて保護されたチャネルを用いて装置と送受信しなければならない。
7. 4.1.4, 4.2.4, 4.3.4 において、各AALに対して要求されている有効期限を過ぎたら、秘密を受け付けてはならない。ものぐさな人のために書いておくと、これは4.1.3, 4.2.3, 4.3.3 再認証のことだと思われる。制限時間、操作なしの制限時間はAAL1 では30日、（なし）AAL2では12時間, 30分、AAL3では12時間、15分。
8. セッションのホストと利用者の端末間のセキュアでない通信において利用してはならない。 認証に続いて、セキュアでない通信にグレードダウンしてはならない。

この部分、用語が揺れている。subscriberに対してuserとは何か、とかね。

URLs or POST content SHALL contain a session identifier that SHALL be verified by the RP to ensure that actions taken outside the session do not affect the protected session.

URLやPOSTの本体は、セッションの識別子を含んだものでなければならない。 RPは、それを検証しなければならない。これで、セッション外のアクションが保護されたセッションに影響を与えないことを確かにすることができる。これ、本当は63Cに移すべきではないのか。 アプリケーション独自のプロトコル（各種フレームワークで提供している認証モジュールとか）が 今後のしてくることを想定しているのかもしれない。

There are several mechanisms for managing a session over time. The following sections give different examples along with additional requirements and considerations particular to each example technology. Additional informative guidance is available in the OWASP Session Management Cheat Sheet [OWASP-session].

セッション管理の方式は、長年にわたって作られてきた。以降で、いくつかの例を、その例に特有の追加の要求要件と考慮要件とともに示す。それ以外は、たとえばOWASPのセッション管理チートシートが参考になる。ということで、以下に例を3つあげる。

7.1.1 Browser Cookies

Browser cookies are the predominant mechanism by which a session will be created and tracked for a subscriber accessing a service.

Cookies:

1. SHALL be tagged to be accessible only on secure (HTTPS) sessions.
2. SHALL be accessible to the minimum practical set of hostnames and paths.
3. SHOULD be tagged to be inaccessible via JavaScript (HttpOnly).
4. SHOULD be tagged to expire at, or soon after, the session’s validity period. This requirement is intended to limit the accumulation of cookies, but SHALL NOT be depended upon to enforce session timeouts.

ブラウザのCookie。
利用者がサービスにアクセスするときにセッションを生成、追跡するときに使われる。 セッション管理を考える時にはまずこれ。

1. cookieは、HTTPSのセッションだけでアクセスできるように設定しなければならない。 tagはここでは「設定」と訳している。
2. 最小限必要なホスト名とパスのみからアクセス可能でなければならない。
3. HttpOnlyを設定して、JavaScriptからの利用を禁止すべきである。
4. セッションの有効期間が過ぎたら、即座またはできるだけ早く期限切れになるように設定すべきである。これは、cookieを収集することを制限するためである。ただし、セッションの強制タイムアウトをこれで行ってはならない。

7.1.2 Access Tokens

An access token — such as found in OAuth — is used to allow an application to access a set of services on a subscriber’s behalf following an authentication event. The presence of an OAuth access token SHALL NOT be interpreted by the RP as presence of the subscriber, in the absence of other signals. The OAuth access token, and any associated refresh tokens, MAY be valid long after the authentication session has ended and the subscriber has left the application.

アクセストークン。OAuthやその後継（OIDCを含む）はこれを使う。
アプリケーションは、これを使って、認証に引き続き利用者に代わって一連のサービスにアクセスできる。RPでは、OAuthのアクセストークンを、それ単独では利用者の存在と解釈してはならない。 これは有名な話で、しかも認証トークンに拡大解釈されてきたのは、2010年代の始めには普通にあったらしい。RFCでこれを禁止。佐藤自体はJ. Bradlyのブログで知った。 OAuthのアクセストークンと関連するリフレッシュのためのトークンは、認証が終わって、 利用者がアプリケーションを終了した後でも有効であってよい（無効化する必要はない）。

7.1.3 Device Identification

Other methods of secure device identification — including but not limited to mutual TLS, token binding, or other mechanisms — MAY be used to enact a session between a subscriber and a service.

装置の識別
TLSの相互認証（クライアント認証を含む）などで装置をセキュアにを識別する方法があれば、 それを使って、利用者とサービス間のセッションを確立しても良い。

7.2 Reauthentication

セッションの再認証

Continuity of authenticated sessions SHALL be based upon the possession of a session secret issued by the verifier at the time of authentication and optionally refreshed during the session. The nature of a session depends on the application, including:

1. A web browser session with a “session” cookie, or
2. An instance of a mobile application that retains a session secret.

セッションの結合に続いてセッションの再認証の話。認証されたセッションを継続するときは、 検証者が認証時に発行し、途中でリフレッシュされるセッションの秘密の保有をベースにしなければならない。セッションで考えるべきことはアプリケーションに依存する。例えば

1. セッションcookieを持つブラウザのセッション
2. セッションの秘密を保持するスマホのアプリケーションのインスタンス

Session secrets SHALL be non-persistent. That is, they SHALL NOT be retained across a restart of the associated application or a reboot of the host device.

Periodic reauthentication of sessions SHALL be performed to confirm the continued presence of the subscriber at an authenticated session (i.e., that the subscriber has not walked away without logging out).

セッションの秘密は、永続的であったはならない。つまり、関連するアプリケーションの再スタートやホスト装置のリブートをまたがって保持してはならない。
認証されたセッション中、利用者が継続して存在している（利用者がログアウトしないまま どこかへふらふらと行ってしまうようなことがない）ことを確認するために、定期的に再認証を実施しなければならない。

A session SHALL NOT be extended past the guidelines in Sections 4.1.3, 4.2.3, and 4.3.3 (depending on AAL) based on presentation of the session secret alone. Prior to session expiration, the reauthentication time limit SHALL be extended by prompting the subscriber for the authentication factor(s) specified in Table 7-1.

セッションは各AALごとに4.1.3, 4.2.3, 4.3.3で示した期間を越えて、 セッションの秘密の提示のみを根拠として延長してはならない。 セッションの期限切れ前に再認証の有効期限を延長するときは、利用者に下表で指定した認証要素を使わせなければならない。

When a session has been terminated, due to a time-out or other action, the user SHALL be required to establish a new session by authenticating again.

セッションがタイムアウトその他で終了したときは、userに、認証を再度行って新しいセッションを確立することを要求しなければならない。

Table 7-1 AAL Reauthentication Requirements

AAL	Requirement
1	Presentation of any one factor 認証時の任意の要素を1つ提示
2	Presentation of a memorized secret or biometric 記憶秘密または生体情報の提示
3	Presentation of all factors 認証時のすべての要素の提示

Note: At AAL2, a memorized secret or biometric, and not a physical authenticator, is required because the session secret is something you have, and an additional authentication factor is required to continue the session.

AAL2で物理的認証器ではなく、記憶秘密または生体情報を要求するのは、セッションの秘密が something you haveであり、セッションの継続にためにはそれ以外の要素が要求されるからである。

7.2.1 Reauthentication from a Federation or Assertion

フェデレーションのアサーションを使った再認証
これ、セッション番号が変である。2つ以上必要。

When using a federation protocol as described in SP 800-63C, Section 5 to connect the CSP and RP, special considerations apply to session management and reauthentication. The federation protocol communicates an authentication event between the CSP and the RP but establishes no session between them. Since the CSP and RP often employ separate session management technologies, there SHALL NOT be any assumption of correlation between these sessions. Consequently, when an RP session expires and the RP requires reauthentication, it is entirely possible that the session at the CSP has not expired and that a new assertion could be generated from this session at the CSP without reauthenticating the user.

63C Sect. 5で記述したフェデレーションのプロトコルを使ってCSP又はRPに接続するときは、 セッション管理と再認証には別途考慮が必要である。このプロトコルでは、CSPとRPの間で認証イベントを交換するが、両者間でセッションが確立されるわけではない。 両者管では独立のセッション管理技術を採用しており、セッション間で両者のセッションの 関係について特定の仮定をおいてはならない。 結果として、RPのセッションが期限切れになって再認証を要求したとき、CSP側ではセッションは切れていない可能性があり、そこで新しいアサーションが、userの再認証なしに生成されることはあり得る。

An RP requiring reauthentication through a federation protocol SHALL — if possible within the protocol — specify the maximum acceptable authentication age to the CSP, and the CSP SHALL reauthenticate the subscriber if they have not been authenticated within that time period. The CSP SHALL communicate the authentication event time to the RP to allow the RP to decide if the assertion is sufficient for reauthentication and to determine the time for the next reauthentication event.

RPがフェデレーションプロトコルを使って再認証を要求するときに、可能であればだが、 CSPに対して、認証に利用可能な最大有効期限を定めなければならない。 その期間内に認証がなされなければ、CSPは、利用者を再認証しなければならない。 CSPは、認証した時刻をRPに送らなければならない。RPは、それを使ってアサーションが再認証に十分なのか決定できるし、次回の再認証の時刻を決定することができる。

8 Threats and Security Considerations

This section is informative.

このセクションはinformative。ここでは、脅威モデルとそれへの対応について述べる。 対象は、認証器本体とセッション。

8.1 Authenticator Threats

認証器に対する脅威

An attacker who can gain control of an authenticator will often be able to masquerade as the authenticator’s owner. Threats to authenticators can be categorized based on attacks on the types of authentication factors that comprise the authenticator:

認証器をコントロールできるようになった攻撃者は、本来の所有者に成りすますことができる。 認証器に対する脅威は、認証要素のタイプごとに考えられる攻撃で、以下のように分類できる。

• Something you know may be disclosed to an attacker. The attacker might guess a memorized secret. Where the authenticator is a shared secret, the attacker could gain access to the CSP or verifier and obtain the secret value or perform a dictionary attack on a hash of that value. An attacker may observe the entry of a PIN or passcode, find a written record or journal entry of a PIN or passcode, or may install malicious software (e.g., a keyboard logger) to capture the secret. Additionally, an attacker may determine the secret through offline attacks on a password database maintained by the verifier.

• Something you have may be lost, damaged, stolen from the owner, or cloned by an attacker. For example, an attacker who gains access to the owner’s computer might copy a software authenticator. A hardware authenticator might be stolen, tampered with, or duplicated. Out-of-band secrets may be intercepted by an attacker and used to authenticate their own session.

• Something you are may be replicated. For example, an attacker may obtain a copy of the subscriber’s fingerprint and construct a replica.

• something you know. これはパスワード。 利用者とCSPで共有される秘密の場合（これはパスワードを含めごく普通）、攻撃者は CSPや検証者にアクセスして秘密を直接獲得するか、秘密のハッシュ値に対して辞書攻撃をすることが考えられる。 PINやパスコードのエントリーを見たり、文書での記録やジャーナル（いろいろなログ記録）の該当するエントリーを見たり、キーロガーなどのマルウェアを仕込んで秘密を窃取するかもしれない。 オフラインでも、検証者の保守するパスワードデータベースに対する攻撃が考えられる。 なんでもありですな。
• something you have. 紛失、損壊、盗難、または攻撃者による複製が考えられる。 攻撃者が所有者のコンピュータにアクセスできるようになれば、ソフトウェア認証器をコピーすることが 考えられる。ハードウェア認証器なら、盗難、改変、複製が考えられる。アウトオブバンド秘密なら 攻撃者が傍受して、その秘密を使うセッションの認証に使うことが考えられる。
• something you are. 複製が考えられる。利用者の指紋をコピーして複製を作るなど。

This document assumes that the subscriber is not colluding with an attacker who is attempting to falsely authenticate to the verifier. With this assumption in mind, the threats to the authenticator(s) used for digital authentication are listed in Table 8-1, along with some examples.

ここでは、利用者が攻撃者と共謀して検証者の検証をだますことは想定しない。ディジタル認証に用いる認証器に対する脅威を表8-1にまとめる。ここ、大切なところですよ。

Table 8-1 Authenticator Threats

Authenticator Threat/Attack	Description	Examples
Assertion Manufacture or Modification アサーションの改変(なぜこれが最初に？)	The attacker generates a false assertion 攻撃者が不正なアサーションを生成する	Compromised CSP asserts identity of a claimant who has not properly authenticated CSPが危殆化して、政党に認証されていないclaimantのアイデンティティに関するアサーションを発行する
	The attacker modifies an existing assertion 攻撃者がアサーションを改変する	Compromised proxy that changes AAL of an authentication assertion 危殆化したproxyがアサーションのAALを改変する
Theft 盗難	A physical authenticator is stolen by an Attacker. 物理的認証器が攻撃者に盗まれる	A hardware cryptographic device is stolen. ハードウエア暗号装置が盗まれる
		An OTP device is stolen. OTP装置が盗まれる
		A look-up secret authenticator is stolen. 参照型認証器が盗まれる
		A cell phone is stolen. スマホの盗難
Duplication 複製	The subscriber’s authenticator has been copied with or without their knowledge. 利用者の認証器の複製が意図的、非意図的にとられる	Passwords written on paper are disclosed. 紙に書いたパスワードがあばかれる
		Passwords stored in an electronic file are copied. ファイルにしまっておいたパスワードがコピーされる
		Software PKI authenticator (private key) copied. ソフトウェアPKI認証器の私有鍵がコピーされる
		Look-up secret authenticator copied. 参照型秘密認証器がコピーされる
		Counterfeit biometric authenticator manufactured. 偽造生体情報が作られる
Eavesdropping 盗聴	The authenticator secret or authenticator output is revealed to the attacker as the subscriber is authenticating. 認証器の秘密または認証器の出力が認証中に攻撃者に晒される	Memorized secrets are obtained by watching keyboard entry. 記憶秘密がキーボードでの入力をウォッチしてとられてしまう
		Memorized secrets or authenticator outputs are intercepted by keystroke logging software. 記憶秘密または認証器の出力がキーロガーで盗聴される
		A PIN is captured from a PIN pad device. PINが装置から盗まれる
		A hashed password is obtained and used by an attacker for another authentication (pass-the-hash attack). パスワードのハッシュが盗られてしまう
	An out-of-band secret is intercepted by the attacker by compromising the communication channel. 副チャネルで送られる秘密が、通信チャネルの危殆化によって盗聴される	An out-of-band secret is transmitted via unencrypted Wi-Fi and received by the attacker. 暗号化されていないWi-Fi上でアウトオブバンド秘密が送信される
Offline Cracking オフライン攻撃	The authenticator is exposed using analytical methods outside the authentication mechanism. 認証器が、その方式と関係ない方法で解析され晒される	A software PKI authenticator is subjected to dictionary attack to identify the correct password to use to decrypt the private key. ソフトウェアPKI認証器は、私有鍵を復号するためのパスワードを特定するための辞書攻撃にさらされる
Side Channel Attack 副チャネル攻撃	The authenticator secret is exposed using physical characteristics of the authenticator. 認証器の物理的な特徴を使って、認証器の秘密が晒される	A key is extracted by differential power analysis on a hardware cryptographic authenticator. ハードウェア暗号認証器上で、電力差分解析を使って鍵が引き出される。
		A cryptographic authenticator secret is extracted by analysis of the response time of the authenticator over a number of attempts. 応答時間解析によって暗号認証器の秘密が引き出される
Phishing or Pharming フィッシング、ファーミング	The authenticator output is captured by fooling the subscriber into thinking the attacker is a verifier or RP. 利用者に対して、攻撃者を検証者又はRPだと誤認させて、認証器の出力を捕捉する。	A password is revealed by subscriber to a website impersonating the verifier. 攻撃者が検証者に成りすますことで、利用者がパスワードを攻撃者のWebサイトにさらす。
		A memorized secret is revealed by a bank subscriber in response to an email inquiry from a phisher pretending to represent the bank. 攻撃者が銀行に成りすまして、メールへの返送によって、銀行利用者の記憶秘密をあばく
		A memorized secret is revealed by the subscriber at a bogus verifier website reached through DNS spoofing. DNS spoofingによって誘導された偽の検証者のWebサイトにおいて、利用者の記憶秘密をあばく
Social Engineering ソーシャルエンジニアリング	The attacker establishes a level of trust with a subscriber in order to convince the subscriber to reveal their authenticator secret or authenticator output. 攻撃者が、利用者と一定のレベルのトラストを確立し、利用者の納得ずくで認証器の秘密や出力を外に出す	A memorized secret is revealed by the subscriber to an officemate asking for the password on behalf of the subscriber’s boss. 職場の同僚が、上司に成り代わってという理由をつけて、利用者の記憶秘密を聞き出す
		A memorized secret is revealed by a subscriber in a telephone inquiry from an attacker masquerading as a system administrator. シスアドに成りすまして電話で問い合わせをかけて記憶秘密を聞き出す
		An out of band secret sent via SMS is received by an attacker who has convinced the mobile operator to redirect the victim’s mobile phone to the attacker. SMSで送られてきたアウトオブバンド秘密を、オペレータをだまして、利用者のスマホから攻撃者に転送させる
Online Guessing オンラインあてずっぽう推測	The attacker connects to the verifier online and attempts to guess a valid authenticator output in the context of that verifier. 攻撃者が検証者にオンラインでアクセスし、正当な認証器出力を推測する	Online dictionary attacks are used to guess memorized secrets. オンラインでの辞書攻撃で記憶秘密を推測する
		Online guessing is used to guess authenticator outputs for an OTP device registered to a legitimate claimant. オンライン推測は、正当なclaimantに対応するものとして登録されたOTP装置の認証器出力を推測するために使われる
Endpoint Compromise 端末の危殆化	Malicious code on the endpoint proxies remote access to a connected authenticator without the subscriber’s consent. 端末のproxyでのマルウェアが、利用者の同意なしに認証器に外からアクセスする	A cryptographic authenticator connected to the endpoint is used to authenticate remote attackers. 端末に接続した暗号認証器が、リモートの攻撃者の認証に使われる
	Malicious code on the endpoint causes authentication to other than the intended verifier. 端末側のマルウェアが、意図した検証者以外の認証をしてしまう	Authentication is performed on behalf of an attacker rather than the subscriber. マルウェアが、利用者ではなく攻撃者の認証をしてしまう
		A malicious app on the endpoint reads an out-of-band secret sent via SMS and the attacker uses the secret to authenticate. 端末側のマルウェアがSMSで送ったアウトオブバンド秘密を読み取り、攻撃者によって使われる
	Malicious code on the endpoint compromises a multi-factor software cryptographic authenticator. 端末側でのマルウェアが多要素ソフトウェア暗号認証器を危殆化させる。	Malicious code proxies authentication or exports authenticator keys from the endpoint. マルウェアが認証のproxyを行うか、端末の認証鍵を送出する
Unauthorized Binding 認可されていない結合	An attacker is able to cause an authenticator under their control to be bound to a subscriber’s account. 攻撃者が、ハックした認証器に対し、利用者のアカウントに結合する	An attacker intercepts an authenticator or provisioning key en route to the subscriber. 攻撃者が、認証器または利用者のプロビジョニングのための鍵を盗聴する

8.2 Threat Mitigation Strategies

Related mechanisms that assist in mitigating the threats identified above are summarized in Table 8-2.

表8.2に、上で挙げられた脅威を緩和するための関連するやり方をあげる。 この部分、リアルタイムに更新する必要があるだろう。アメリカのやり方として「現状としてこう」 と状態と固定し、それに対する対策を文書としてまとめる（ので、成果が見えているように見える） というのがあるが、まぁ、何もやらないよりましだ以上の感想が浮かばない。

Table 8-2 Mitigating Authenticator Threats

Authenticator Threat/Attack	Threat Mitigation Mechanisms	Normative Reference(s)
Theft 盗難	Use multi-factor authenticators that need to be activated through a memorized secret or biometric. 記憶秘密または生体情報でアクティベートしなければならない多要素認証器を使用すること	4.2.1, 4.3.1
	Use a combination of authenticators that includes a memorized secret or biometric. 記憶秘密または生体認証を含む認証器を組み合わせて使用すること	4.2.1, 4.3.1
Duplication 複製	Use authenticators from which it is difficult to extract and duplicate long-term authentication secrets. 長期認証秘密を暴露、複製することが困難な認証器を使用すること	4.2.2, 4.3.2, 5.1.7.1
Eavesdropping 盗聴	Ensure the security of the endpoint, especially with respect to freedom from malware such as key loggers, prior to use. 使用前に、キーロガーなどのマルウェアが使われていないことなど、端末のセキュリティの保証をすること	4.2.2
	Avoid use of non-trusted wireless networks as unencrypted secondary out-of-band authentication channels. 信用のおけない無線ネットワークを副チャネルでアウトオブバンド認証に使わないこと	5.1.3.1
	Authenticate over authenticated protected channels (e.g., observe lock icon in browser window). 認証され保護されたチャネル（例えばブラウザ上のHTTPSを表す「鍵」アイコンを確認する）上で認証すること	4.1.2, 4.2.2, 4.3.2
	Use authentication protocols that are resistant to replay attacks such as pass-the-hash. pass-the-hashなどのリプレイ攻撃耐性のある認証プロトコルを使う	5.2.8
	Use authentication endpoints that employ trusted input and trusted display capabilities. 入力、表示が信頼できる端末上で認証する	5.1.6.1, 5.1.8.1
Offline Cracking オフライン攻撃	Use an authenticator with a high entropy authenticator secret. 高エントロピーの認証器秘密を使う	5.1.2.1, 5.1.4.1, 5.1.5.1, 5.1.7.1, 5.1.9.1
	Store memorized secrets in a salted, hashed form, including a keyed hash. 記憶秘密は、ソルトをかけ、(keyed) ハッシュを取る	5.1.1.2, 5.2.7
Side Channel Attack 副チャネル攻撃	Use authenticator algorithms that are designed to maintain constant power consumption and timing regardless of secret values. 電力消費と処理時間が秘密の値に依存しないように設計された認証器アルゴリズムを使う	4.3.2
Phishing or Pharming フィッシング、ファーミング	Use authenticators that provide verifier impersonation resistance. 検証者なりすましに対する耐性を持つ認証器を使う	5.2.5
Social Engineering ソーシャルエンジニアリング	Avoid use of authenticators that present a risk of social engineering of third parties such as customer service agents. 「お客様サービス代理店」などの第三者のソーシャルエンジニアリングのリスクのある認証器を使わない	6.1.2.1, 6.1.2.3
Online Guessing オンラインあてずっぽう推測	Use authenticators that generate high entropy output. 高エントロピーを持つ認証器を使う	5.1.2.1, 5.1.7.1, 5.1.9.1
	Use an authenticator that locks up after a number of repeated failed activation attempts. アクティベーションを何回も失敗するとロックがかかる認証器を使う	5.2.2
Endpoint Compromise 端末の危殆化	Use hardware authenticators that require physical action by the subscriber. 利用に際し、利用者の物理的な動作を要求するハードウェア認証器を使う	5.2.9
	Maintain software-based keys in restricted-access storage. アクセス制限のかかる場所にソフトウェアで実装した鍵を格納する	5.1.3.1, 5.1.6.1, 5.1.8.1
Unauthorized Binding 認可されていない結合	Use MitM-resistant protocols for provisioning of authenticators and associated keys. 認証器と関連する鍵のプロビジョニングに、中間者攻撃耐性のあるプロトコルを使う	6.1

対策は抽象的なので、具体的には右端の各論を参照、という作り。 認証プロトコルと深く関係するので、63Cと一部被るはずなのだが、 一度まとめた方が良いと思う。このままでは十分ではない。

Several other strategies may be applied to mitigate the threats described in Table 8-1:

以下、その他の脅威緩和のための一般論

• Multiple factors make successful attacks more difficult to accomplish. If an attacker needs to both steal a cryptographic authenticator and guess a memorized secret, then the work to discover both factors may be too high.

  複数認証要素を使うと、攻撃は完遂が難しくナウ。攻撃者が暗号認証器と記憶秘密両方を盗むことが必要になれば、両方を見つける努力はとても難しいだろう

• Physical security mechanisms may be employed to protect a stolen authenticator from duplication. Physical security mechanisms can provide tamper evidence, detection, and response.

  物理セキュリティを確保すると、認証器の複製を防御できる。 物理セキュリティの方式を用いて不正の証拠の提供、不正の検知、不正への応答が可能になる。

• Requiring the use of long memorized secrets that don’t appear in common dictionaries may force attackers to try every possible value.

  記憶秘密として、辞書にない長いものを要求すると、攻撃者側の糸口をつぶすことができる。

• System and network security controls may be employed to prevent an attacker from gaining access to a system or installing malicious software.

  システムセキュリティ、ネットワークセキュリティ統制によって、 攻撃者がシステムにアクセス可能になったり、マルウェアをインストールさせることを防ぐことができる。

• Periodic training may be performed to ensure subscribers understand when and how to report compromise — or suspicion of compromise — or otherwise recognize patterns of behavior that may signify an attacker attempting to compromise the authentication process.

  定期的な訓練を利用者に対して行うことにより、危殆化（疑いを含む）の報告をいつどのようにすればよいか理解を深める、 または攻撃者が認証プロセスを危殆化させる試みを意味する振る舞いのパターンの認識を深めることができる。

• Out of band techniques may be employed to verify proof of possession of registered devices (e.g., cell phones).

  アウトオブバンド技術 (携帯電話など)を用いることで、登録装置の保有の検証ができる。

8.3 Authenticator Recovery

認証器の復帰

The weak point in many authentication mechanisms is the process followed when a subscriber loses control of one or more authenticators and needs to replace them. In many cases, the options remaining available to authenticate the subscriber are limited, and economic concerns (e.g., cost of maintaining call centers) motivate the use of inexpensive, and often less secure, backup authentication methods. To the extent that authenticator recovery is human-assisted, there is also the risk of social engineering attacks.

多くの認証の方式の弱点として、利用者が認証器の制御を失って、補充が必要になったときの プロセスがあげられる。この時、多くの場合、利用者を認証できるものとしてまだ利用可能な方法には 限りがあり、コールセンターの保守のコストなどの経済的な理由で、安価な、そしてしばしばセキュアでないバックアップの認証方法を採用することになる。 認証器の復帰に人間がかかわる度合いによっては、ソーシャルエンジニアリングのリスクにも晒される。。
静脈系の中でも、もっとも面倒なところですよ。

To maintain the integrity of the authentication factors, it is essential that it not be possible to leverage an authentication involving one factor to obtain an authenticator of a different factor. For example, a memorized secret must not be usable to obtain a new list of look-up secrets.

認証要素のレベルを維持するには、1つの認証要素を用いた認証を使うことで他の認証器を発行することが可能であってはならないということが基本である。たとえば、記憶秘密を使って、 新規の参照秘密を発行することが可能であってはならない。
で、どうしろと。それが6.1.2.3 replacementの項で議論されていた。このセクション、必要？

8.4 Session Attacks

セッション攻撃

The above discussion focuses on threats to the authentication event itself, but hijacking attacks on the session following an authentication event can have similar security impacts. The session management guidelines in Section 7 are essential to maintain session integrity against attacks, such as XSS. In addition, it is important to sanitize all information to be displayed [OWASP-XSS-prevention] to ensure that it does not contain executable content. These guidelines also recommend that session secrets be made inaccessible to mobile code in order to provide extra protection against exfiltration of session secrets.

以上、認証の事象そのものへの脅威に注目してきたが、実は、認証に引き続くセッションに対する セッションハイジャックも同様のセキュリティ上の影響力がある。 Section 7で論じたセッション管理のガイドラインが、XSS等の攻撃に対してセッションの統合性を維持するのに本質的である。 加えて、画面表示される情報をサニタイズして、実行可能なコンテンツを表に出さないようにするのが重要である。ガイドラインでは、セッションの秘密をモバイルアプリからアクセスできないようにしておくことも推奨している。これによってこのパスを使ったセッションの秘密の抜き出しに対する防御策になる。

Another post-authentication threat, cross-site request forgery (CSRF), takes advantage of users’ tendency to have multiple sessions active at the same time. It is important to embed and verify a session identifier into web requests to prevent the ability for a valid URL or request to be unintentionally or maliciously activated.

認証後の脅威としては、CSRFがある。これは、ユーザが同時に複数のセッションをアクティブにしがちなことを利用する。正当なURLまたは要求が意図せず、または悪意のある形でアクティベートされないように、セッションの識別子を埋め込んでおいて検証することが重要である。
そんなこと言っても、それはブラウザの責任ですやん。

9 Privacy Considerations

These privacy considerations supplement the guidance in Section 4. This section is informative.

このセクションはSection 4の補足。informative
執筆分担が別の人になっており、役人言葉のにおいがする。

9.1 Privacy Risk Assessment

プライバシーリスク評価

Sections 4.1.5, 4.2.5, and 4.3.5 require the CSP to conduct a privacy risk assessment for records retention. Such a privacy risk assessment would include:

1. The likelihood that the records retention could create a problem for the subscriber, such as invasiveness or unauthorized access to the information.
2. The impact if such a problem did occur.

CSPは、記録を保有することについてプライバシーリスク評価を行わなければならない。 その中には以下が含まれるだろう。

1. 記録の保有が原因で利用者に、侵入や情報への認可されないアクセスなどの問題を引き起こす可能性
2. そのような問題が引き起こす影響度

CSPs should be able to reasonably justify any response they take to identified privacy risks, including accepting the risk, mitigating the risk, and sharing the risk. The use of subscriber consent is a form of sharing the risk, and therefore appropriate for use only when a subscriber could reasonably be expected to have the capacity to assess and accept the shared risk.

CSPは、特定されたプライバシーリスクへの対策に合理的な正当化ができるようにすべきである。 対策には、リスクの需要、緩和、共有が含まれる。リスク共有は、ここでは保険を含むより広い概念である。利用者の同意を取ることは、リスク共有の一つであり、利用者が、共有されるリスクを評価し、受容する能力を合理的に期待できるときに限って有効である。で、合意の取り方が問題になるわけで、現状 この基準を満たすものはほとんどないのではないか。

9.2 Privacy Controls

プライバシー統制

Section 4.4 requires CSPs to employ appropriately-tailored privacy controls. SP 800-53 provides a set of privacy controls for CSPs to consider when deploying authentication mechanisms. These controls cover notices, redress, and other important considerations for successful and trustworthy deployments.

4.4では、CSPが適切に調整したプライバシーの統制を行うことを要求している。 SP 800-53では、認証の方式を配備するときにCSP考慮すべきプライバシー統制の集合 (= 通知、軽減その他配備を適切に行うあめに考慮すべきこと)を 規定している。やっぱりSP 800-53、一度本格的に読まないとだめなんじゃないですか。 「SP800-53 Appendix J Privacy Control Catalogに統制の仕方が並べられている」くらいのことは書いておかないといけないんじゃないですか？

9.3 Use Limitation

使用の制限

Section 4.4 requires CSPs to use measures to maintain the objectives of predictability (enabling reliable assumptions by individuals, owners, and operators about PII and its processing by an information system) and manageability (providing the capability for granular administration of PII, including alteration, deletion, and selective disclosure) commensurate with privacy risks that can arise from the processing of attributes for purposes other than identity proofing, authentication, authorization, or attribute assertion, related fraud mitigation, or to comply with law or legal process NISTIR8062.

4.4に書いてあることは、予測可能性と管理可能性の目的を維持するためにCSPが対策を講じることを 要求することであった。前者は個人特定情報とその情報システムよる処理に関係する個人、所有者、オペレータによる信頼のおける仮定を置くことを可能にすることであり、後者は個人特定情報の変更、削除、選択的開示を含む細粒度の管理をする能力を提供することである。 これらは、アイデンティティ証明、認証、認可、または属性アサーション、関連する詐欺リスクの緩和以外の目的で属性を処理することから生じるプライバシーリスクへの対応になっており、つまり 法的プロセスを遵守することである。
すげー悪文。それはともかく、ここではattribute（属性）が、個人情報と同等に使われている。

CSPs may have various business purposes for processing attributes, including providing non-identity services to subscribers. However, processing attributes for other purposes than those specified at collection can create privacy risks when individuals are not expecting or comfortable with the additional processing. CSPs can determine appropriate measures commensurate with the privacy risk arising from the additional processing. For example, absent applicable law, regulation or policy, it may not be necessary to get consent when processing attributes to provide non-identity services requested by subscribers, although notices may help subscribers maintain reliable assumptions about the processing (predictability). Other processing of attributes may carry different privacy risks that call for obtaining consent or allowing subscribers more control over the use or disclosure of specific attributes (manageability). Subscriber consent needs to be meaningful; therefore, as stated in Section 4.4, when CSPs use consent measures, acceptance by the subscriber of additional uses SHALL NOT be a condition of providing authentication services.

CSPは、属性を処理するいろいろな事業目的（利用者にアイデンティティ以外のサービスを提供することを含む）を持っている。 しかし、属性を収集するときに指定した収集目的以外で属性を処理すると、個人が想定していなかったり、不快に思えば、そこにプライバシーリスクが発生する CSPは、追加処理で生じるプライバシーリスクへの対応になる策を決定することができる。 一例として、適用法令、規則、ポリシーがなければ、属性を処理して利用者がアイデンティティに関係しないサービスを要求してそれに応える時にも同意を得ることは不要かもしれない。ただし、通知しておけば、利用者が、属性処理に関する信頼のおける仮定を維持するのに役に立つかもしれない。これが 予測可能性ということである。 他の属性処理には、同意取得、または利用者に特定の属性の使用や開示についてのより強い制御を許すことを求める違う種類のプライバシーリスクを伴うかもしれない。この同意取得や制御が管理可能性ということである。 CSPが同意取得を対策として採用するとき、4.4で述べたように、利用者同意は、意味のあるものである必要がある。そして利用者が追加的な利用を承諾することが、認証を提供する条件であってはならない。
　9.3, 絶対エディタが他と違う。

Consult your SAOP if there are questions about whether the proposed processing falls outside the scope of the permitted processing or the appropriate privacy risk mitigation measures.

この部分は連邦政府に対する規制。 やろうとする処理が許可された処理、またはプライバシーリスク緩和策のスコープの外に あるかどうか疑問がある時はSAOPに問い合わせること。
SAOPは、seniro agency official for privacyのことで、担当官ですね。

9.4 Agency-Specific Privacy Compliance

この部分は、米連邦政府特有のプライバシーコンプライアンス。 日本では異なるし、GDPRとも違うが、参考のために解説を加える。

Section 4.4 covers specific compliance obligations for federal CSPs. It is critical to involve your agency’s SAOP in the earliest stages of digital authentication system development in order to assess and mitigate privacy risks and advise the agency on compliance requirements, such as whether or not the collection of PII to issue or maintain authenticators triggers the Privacy Act of 1974 Privacy Act or the E-Government Act of 2002 E-Gov requirement to conduct a PIA. For example, with respect to centralized maintenance of biometrics, it is likely that the Privacy Act requirements will be triggered and require coverage by either a new or existing Privacy Act system of records due to the collection and maintenance of PII and any other attributes necessary for authentication. The SAOP can similarly assist the agency in determining whether a PIA is required.

プライバシーに関し、連邦政府の運営するCSPのプライバシー要件は4.4で記述していた （訳していない。訳すか…）。 そこではSAOPがいるはずで、認証システムの開発のごく初期の段階からSAOPを参加させることが本質的に重要である。 参加させたうえでプライバシーリスクの評価と緩和、コンプライアンス上の要請に対してエージェンシーに助言を行うべきである。 コンプライアンス上の要請には、1974 Privacy ActやPIA (プライバシー影響度評価) を行うための2002 E-Government Actがある。 たとえば、生体情報を中央管理することに関しては、Privacy Act上の要請が生じ、 個人特定情報その他認証に必要な他の情報の収集と保守のために、 今までそれに対応すべく行ってきた（ないなら新規に作ることになる）記録システムが 新たにカバーしなければならなくなる。 SAOPは、エージェンシーに対して、PIAが必要かどうかの決定にも同様に助言できる。
SAOPは、GDPRで言えばData Controllerに対応するだろう。日本の個人情報保護法というか、プライバシーマークで言えば「個人情報保護管理者」。そういえば、日本には 「個人情報保護士」と言う資格があるそうだ。知らなかった… PIAを行えというのは、もはや全世界で共通のステップになっている。

These considerations should not be read as a requirement to develop a Privacy Act SORN or PIA for authentication alone. In many cases it will make the most sense to draft a PIA and SORN that encompasses the entire digital authentication process or include the digital authentication process as part of a larger programmatic PIA that discusses the service or benefit to which the agency is establishing online.

このことをもって、認証単独のためにPrivacy ActのSORN (System of Records Notice)やPIAを行えと考えるべきではない。 ほとんどのケースにおいて、PIAやSORNの草案を作る（設計する）のに、 最も良いのは、ディジタル認証プロセス全体にわたるようにするか、 またはディジタル認証プロセスをエージェンシーがオンラインで確立しようとしているサービスや利益を議論するたっめのより大きいシステマティックなPIAの一部として 行うことである。

Due to the many components of digital authentication, it is important for the SAOP to have an awareness and understanding of each individual component. For example, other privacy artifacts may be applicable to an agency offering or using federated CSP or RP services (e.g., Data Use Agreements, Computer Matching Agreements). The SAOP can assist the agency in determining what additional requirements apply. Moreover, a thorough understanding of the individual components of digital authentication will enable the SAOP to thoroughly assess and mitigate privacy risks either through compliance processes or by other means.

SAOPにとってディジタル認証の各要素（たくさんある）を認識し、理解しておくのは 重要である。 たとえば、連邦政府の運営するCSPやRPを提供したり利用したりすると、 エージェンシーには他のプライバシー関連の契約等が適用されるかもしれない （Data Use Agreements, Computer Matching Agreementsなど）。 SAOPは、他に適用される要求要件を決定するためにエージェンシーに助言することができる。さらに、ディジタル認証の各要素を完全にりかいすることで、SAOPはコンプライアンスチェックのプロセスその他を通じてプライバシーリスクを評価し、緩和することができるようになる。
63Cにもよるが、トラストフレームワークのポリシーが一番大きい要素になるだろう。 この文書、役人が書いた文書をそのまま持ってきたのではないか。意味がとりにくい 悪文ではないし、前から順に読んでいけばむしろわかりやすいのだが…

10 Usability Considerations

This section is informative.

使いやすさのための条件。このセクションはinformative。 この部分、執筆分担が他と違う。もちろん、書き方も違う。
usabilityという語は、技術用語として 「ユーザビリティ」と訳したが、本当は少し良い語があるはず。 「有用性」はしっくりこない。「ユーザビリティ」は、翻訳の放棄。 と思ったら Wikipediaでも色々苦労しているようで。ISO 9241-11はJIS化されていない？

ISO/IEC 9241-11 defines usability as the “extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” This definition focuses on users, their goals, and the context of use as key elements necessary for achieving effectiveness, efficiency, and satisfaction. A holistic approach that accounts for these key elements is necessary to achieve usability.

ISO/IEC 9241-11では、「ユーザビリティ」を以下のように定義している。
製品が特定の利用者に使われ、特定の目標を達成するときの特定の使用の文脈における 有効性、効率、満足度の度合い
ここでは、利用者、目標、使用の文脈に注目し、それらを 有効性、効率、満足度を達成する鍵となる要素であるとしている。 これら鍵となる要素を上げるための総合的なアプローチが「ユーザビリティ」を 達成するのに必要である。

A user’s goal for accessing an information system is to perform an intended task. Authentication is the function that enables this goal. However, from the user’s perspective, authentication stands between them and their intended task. Effective design and implementation of authentication makes it easy to do the right thing, hard to do the wrong thing, and easy to recover when the wrong thing happens.

情報システムへアクセスする利用者の目標は、意図したタスクを実行することである。 認証はその目標を可能にする機能である。しかし、利用者の視点からは、 認証は利用者とタスクの間にあって邪魔になるものである。 認証を効果的に設計、実装することにより、正しいことを容易に行い、間違ったことをすることを難しくし、またそれが起こっても回復するのが容易になる。

Organizations need to be cognizant of the overall implications of their stakeholders’ entire digital authentication ecosystem. Users often employ one or more authenticator, each for a different RP. They then struggle to remember passwords, to recall which authenticator goes with which RP, and to carry multiple physical authentication devices. Evaluating the usability of authentication is critical, as poor usability often results in coping mechanisms and unintended work-arounds that can ultimately degrade the effectiveness of security controls.

組織は、関係者の作るディジタル認証のエコシステム全体の持つ意味を理解する必要がある。 利用者がRPごとに異なる認証器を1個または複数個持つことはよくある。 そうすると、パスワードを覚えようと苦闘したり、どの認証器がどのRPに対応するか思い出そうと苦闘したり、複数の物理認証装置を持ち歩こうとする。 認証のユーザビリティは、それが貧弱であればコピーしたり、意図しない回避策を取ることによって結果的にセキュリティの統制の効果を毀損したりする。

Integrating usability into the development process can lead to authentication solutions that are secure and usable while still addressing users’ authentication needs and organizations’ business goals.

The impact of usability across digital systems needs to be considered as part of the risk assessment when deciding on the appropriate AAL. Authenticators with a higher AAL sometimes offer better usability and should be allowed for use for lower AAL applications.

Leveraging federation for authentication can alleviate many of the usability issues, though such an approach has its own tradeoffs, as discussed in SP 800-63C.

ユーザビリティを開発プロセス中に統合しようとすると、セキュアで使いやすい認証のソルーションを導入することになるが、それでも利用者の認証の必要性と組織の事業目標を実現しなければならない。

ディジタルシステムをまたがったユーザビリティの影響度は、適切なAALを決定するときのリスク評価の一部として考慮されなければならない。

認証フェデレーションを利用してユーザビリティの問題の多くを軽減することができる。 しかし、このアプローチも、63Cで議論されるように、それ自身のトレードオフ問題を 抱えている。

This section provides general usability considerations and possible implementations, but does not recommend specific solutions. The implementations mentioned are examples to encourage innovative technological approaches to address specific usability needs. Further, usability considerations and their implementations are sensitive to many factors that prevent a one-size-fits-all solution. For example, a font size that works in the desktop computing environment may force text to scroll off of a small OTP device screen. Performing a usability evaluation on the selected authenticator is a critical component of implementation. It is important to conduct evaluations with representative users, realistic goals and tasks, and appropriate contexts of use.

このセクションでは、一般的なユーザビリティの考慮とあり得る実装の仕方について 述べるが、特定のソルーションを推奨することはしない。 実装に言及しても、それは特定のユーザビリティの必要性を実現するための技術的なアプローチを積極的に取れるようにするための例に過ぎない。 さらに、ユーザビリティの考慮と実装は、多くの要素に敏感に影響し、"one-size-fits-all"なソルーションを得るのは無理である。 たとえば、デスクトップ環境でうまく動くようにしたフォントサイズは、 小さなOTP装置では、テキストがスクロールして流れてしまうだろう。 しかし、特定の認証器を選択してその上でユーザビリティの評価をすることは実装上、絶対にやらなければならない。大切なことは代表的な利用者、現実的な目標とタスク、適切な使用文脈を想定して評価を行うことである。

これ、ユーザビリティの研究をしている人か、仕事をしている人を引っ張ってきて 書かせたんだろうな。「ユーザビリティとは」から説き起こしているが、 必要なんだろうか。

ASSUMPTIONS

In this section, the term “users” means “claimants” or “subscribers.”

Guidelines and considerations are described from the users’ perspective.

Accessibility differs from usability and is out of scope for this document. Section 508 was enacted to eliminate barriers in information technology and require federal agencies to make their online public content accessible to people with disabilities. Refer to Section 508 law and standards for accessibility guidance.

以下、「利用者」とは、今まで言ってきたclaimantまたはsubscriberのことを言う。 ガイドライン、考慮は、利用者の視点から記述している。 アクセシビリティはユーザビリティとは異なる概念で、この文書の範囲外である。 Section 508は、情報技術の障害を取り除き、障害を持った人に公共のオンラインコンテンツを アクセスしやすいようにするために連邦政府のエージェンシーに要求している。 詳細はアクセシビリティに関するSection 508の法律と規準を参照。
以下、ユーザビリティについて規定するが、共通の事項、個別の事項、生体認証 にわけて記述する。

10.1 Usability Considerations Common to Authenticators

ユーザビリティのうち、認証器に共通の事項

When selecting and implementing an authentication system, consider usability across the entire lifecycle of the selected authenticators (e.g., typical use and intermittent events), while being mindful of the combination of users, their goals, and context of use.

認証システムを選択して、それを実装するとき、そのライフサイクル全体、たとえば典型的な使用法と使用中におきる事象を見渡してユーザビリティを考慮することが大切である。 利用者、目標、使用文脈に配慮することはもちろんのことである。

A single authenticator type usually does not suffice for the entire user population. Therefore, whenever possible — based on AAL requirements — CSPs should support alternative authenticator types and allow users to choose based on their needs. Task immediacy, perceived cost benefit tradeoffs, and unfamiliarity with certain authenticators often impact choice. Users tend to choose options that incur the least burden or cost at that moment. For example, if a task requires immediate access to an information system, a user may prefer to create a new account and password rather than select an authenticator requiring more steps. Alternatively, users may choose a federated identity option — approved at the appropriate AAL — if they already have an account with an identity provider. Users may understand some authenticators better than others, and have different levels of trust based on their understanding and experience.

利用者全体をカバーするのに1種類の認証器だけを提供しても普通は十分ではない。 したがって、AALの要求要件に基づき、可能ならば、CSPは代わりの認証器のタイプを サポートし、利用者に対し、必要に応じて選択できるようにしておくべきである。 タスクの緊急性（コスト-利益のトレードオフ）と、ある認証器に不慣れであることは 選択に影響することがしばしばである。たとえば、情報システムに緊急にアクセスしなければならないなら、利用者は、煩雑な手続きを踏む認証器を使うよりも、手っ取り早く新しいアカウントとパスワードを作ることを 好むかもしれない。 もしくは、適切なAALを承認されたフェデレーション内のIdPに持つアカウントのアイデンティティを選択するかもしれない。 利用者は、ある認証器を他よりよく理解しているかもしれないし、その理解と経験により、異なるレベルの信頼を置いているかもしれない。

Positive user authentication experiences are integral to the success of an organization achieving desired business outcomes. Therefore, they should strive to consider authenticators from the users’ perspective. The overarching authentication usability goal is to minimize user burden and authentication friction (e.g., the number of times a user has to authenticate, the steps involved, and the amount of information he or she has to track). Single sign-on exemplifies one such minimization strategy.

利用者の認証に関する成功体験は、組織が目標とした事業成果を達成するのに不可欠である。 したがって、利用者の視点から認証器を考えるように努力すべきである。 認証のユーザビリティの包括的な目標は、利用者の負担と認証の際のストレスの最小化である。たとえば、認証に要する回数、ステップ数、追跡しなければならない情報の総量などはこの例である。SSOは、このような最小化戦略の一つの例と理解できる。

Usability considerations applicable to most authenticators are described below. Subsequent sections describe usability considerations specific to a particular authenticator.

ほとんどの認証器に適用できるユーザビリティ上の考慮を下にあげる。 10.2では、特定の認証器に徳級の考慮事項をあげる。

Usability considerations for typical usage of all authenticators include:

• Provide information on the use and maintenance of the authenticator, e.g., what to do if the authenticator is lost or stolen, and instructions for use — especially if there are different requirements for first-time use or initialization.

• Authenticator availability should also be considered as users will need to remember to have their authenticator readily available. Consider the need for alternate authentication options to protect against loss, damage, or other negative impacts to the original authenticator.

• Whenever possible, based on AAL requirements, users should be provided with alternate authentication options. This allows users to choose an authenticator based on their context, goals, and tasks (e.g., the frequency and immediacy of the task). Alternate authentication options also help address availability issues that may occur with a particular authenticator.

• Characteristics of user-facing text:
  • Write user-facing text (e.g., instructions, prompts, notifications, error messages) in plain language for the intended audience. Avoid technical jargon and, typically, write for a 6th to 8th grade literacy level.
  • Consider the legibility of user-facing and user-entered text, including font style, size, color, and contrast with surrounding background. Illegible text contributes to user entry errors. To enhance legibility, consider the use of:
    • High contrast. The highest contrast is black on white.
    • Sans serif fonts for electronic displays. Serif fonts for printed materials.
    • Fonts that clearly distinguish between easily confusable characters (e.g., the capital letter “O” and the number “0”).
    • A minimum font size of 12 points as long as the text fits for display on the device.
• User experience during authenticator entry:
  • Offer the option to display text during entry, as masked text entry is error-prone. Once a given character is displayed long enough for the user to see, it can be hidden. Consider the device when determining masking delay time, as it takes longer to enter memorized secrets on mobile devices (e.g., tablets and smartphones) than on traditional desktop computers. Ensure masking delay durations are consistent with user needs.
  • Ensure the time allowed for text entry is adequate (i.e., the entry screen does not time out prematurely). Ensure allowed text entry times are consistent with user needs.
  • Provide clear, meaningful and actionable feedback on entry errors to reduce user confusion and frustration. Significant usability implications arise when users do not know they have entered text incorrectly.
  • Allow at least 10 entry attempts for authenticators requiring the entry of the authenticator output by the user. The longer and more complex the entry text, the greater the likelihood of user entry errors.
  • Provide clear, meaningful feedback on the number of remaining allowed attempts. For rate limiting (i.e., throttling), inform users how long they have to wait until the next attempt to reduce confusion and frustration.
• Minimize the impact of form-factor constraints, such as limited touch and display areas on mobile devices:
  • Larger touch areas improve usability for text entry since typing on small devices is significantly more error prone and time consuming than typing on a full-size keyboard. The smaller the onscreen keyboard, the more difficult it is to type, due to the size of the input mechanism (e.g., a finger) relative to the size of the on-screen target.
  • Follow good user interface and information design for small displays.

ユーザビリティ上の考慮事項

• 認証器の利用と維持についての情報を提供する。紛失盗難の際の扱い、初回の使用または初期化に特別なことをしなければならなければそのための指示事項など

• 認証器の利用可能性も考慮すべきである。利用者は認証器がすでに利用可能になっていることを覚えておく必要があるからである。紛失、損壊その他元の認証器が 使えなくなるような影響を受けた時に代替となる認証手段の必要性も考慮すべきである。

• AALの要求要件に基づき、可能ならば常に、利用者は、大体の認証手段を提供されるべきである。こうすることで、利用者は自分の文脈、目標、タスクの性質（頻度、緊急度など）に基づいて認証器を選択することができる。代替認証手段は、特定の認証器に起きうる可用性の問題の解決にも役立つ可能性がある。

• 利用者が向かい合うことになるテキストについて
  • 利用者が目にするテキストには、指示行、プロンプト、通知、エラーメッセージがあるが、それは想定する利用者層にとって平易な言葉で書くべきである。技術的なジャーゴンを使うのは避け、小学校1-3年生レベルを想定して書くこと
  • 利用者が目にするテキスト、利用者が入力するテキストの判読性に配慮すべきである。たとえばフォントのスタイル、大きさ、色、背景とのコントラストなど。 判読性の低いテキストを使うとエラーを誘発する。判読性を上げるには、以下を使うように配慮すること。
    • 高コントラスト。最大のコントラストは白地に黒。
    • ディスプレイ上ではSans serif フォントを使う。印刷物ではSerifフォントを使う。

      この部分、特にmobile機器ではsans serifの視認性の良さというのは、常識になっているようである。sans serif/serifはフォントの大分類なので、その下にまたいろいろある。 serifの代表例はTimes New Roman。sans serifの代表例はよく知らない。

    • 誤読しやすい文字をはっきり区別できるフォントを使う (大文字のオーと数字のゼロなど)
    • （テキストが装置上のディスプレイに収まることを前提に）フォントは最低12ポイント。

      若い人はわからないだろうけど、中高年までIT機器を使うようになると、老眼対策で、この部分重要。余裕があれば、フォントサイズを大きくできる機能をもつべきだ。

• 認証器の入力中の利用者エクスペリエンス
  • 入力中にテキストを表示するオプションを提供する。マスキングされると入力間違いが起こりやすい。文字については、利用者が視認するのに十分な時間表示したらマスクをかけてよい。マスキングをするための表示時間（遅延時間）は装置ごとに考慮すべきである。パスワードをデスクトップで入力するよりはタブレットやスマホなどのモバイル装置の方が時間がかかるだろう。この表示時間は利用者の必要性と合致するようにすること。
  • テキスト入力に許される時間が適切かどうか確認すべきである。つまり、入力中スクリーンがタイムアウトしないようにすべきである。この入力時間は利用者の必要性と合致するようにすること。
  • 入力エラーに対して明確で意味があり、次の行動がとれるようなフィードバックをすること。これによって利用者が混乱したり、ストレスをためたりすることを軽減できる。利用者は、入力したテキストが正しくないとわからないと、ユーザビリティ上の大きな問題が発生する。
  • 利用者による認証器出力の入力を要求するような認証では、最低10回のトライを許すべきである。入力テキストが複雑で長くなるほどエラーの確立が増す。
  • トライの残り回数について、明確で意味のあるフィードバックをすること。 レート制限（スロットリング）では、利用者の混乱とストレスを軽減するために、次のトライまでどれくらい待たないといけないか通知すること。
• 形状からくる制限がある時は、その影響を最小限にすること。これには、モバイル装置上のタッチ領域の制限や表示エリアが含まれる。form-factorはスマホなど形状の大きさ、重さなどの各要素のこと。小さい装置にはそれなりの制限がある。form-factorって言われてわかる人、多くないと思うぞ。「使うな」と前に言っていた技術的なジャーゴンの典型例じゃないんですかねぇ。
  • タッチ領域が大きければ、ユーザビリティの向上が図れる。これは、フルサイズのキーボード上のタイピングに比べて、小さい装置上でのタイピングが非常に間違いが起こりやすいからである。 スクリーン上に表示する形のキーボードが小さければそれにつれて、（指など、入力方式に必要な大きさを考えると）タイピングは難しくなる。
  • 小さいディスプレイに対しては、良いとされるユーザインターフェースとデザインに従うべきである。

Intermittent events include events such as reauthentication, account lock-out, expiration, revocation, damage, loss, theft, and non-functional software.

Usability considerations for intermittent events across authenticator types include:

使用中に起きる事象には、再認証、アカウントのロック、期限切れ、失効、損壊、紛失、 盗難とソフトウェアのバグが含まれる。

このような事象に対するユーザビリティ上の配慮には以下のようなものが含まれる。

• To prevent users from needing to reauthenticate due to user inactivity, prompt users in order to trigger activity just before (e.g., 2 minutes) an inactivity timeout would otherwise occur.

• Prompt users with adequate time (e.g., 1 hour) to save their work before the fixed periodic reauthentication event required regardless of user activity.

• Clearly communicate how and where to acquire technical assistance. For example, provide users with information such as a link to an online self-service feature, chat sessions or a phone number for help desk support. Ideally, sufficient information can be provided to enable users to recover from intermittent events on their own without outside intervention.

• 利用者が、利用しなくなったことを理由に再認証を要求する必要をなくすため、 利用者にタイムアウトの直前（たとえば2分前くらい）に、再度アクションを起こすことをうながす。

• 利用者の行動の如何に関わらず再認証を定期的に要求することがあるが、 その場合、再認証する前に、十分な時間（たとえば1時間前くらい）をとって、それまでの仕事をセーブするように利用者にうながす

• 技術的支援をどこでどのように得られるかを知らせておく。たとえば、オンラインでのセルフサービスへのリンク先、チャットの場、ヘルプデスクサポートの電話番号など。情報を十分に提供すれば、（理想的には）利用者は使用中に起きる事象から外の助けなしに回復できるだろう。

10.2 Usability Considerations by Authenticator Type

認証器のタイプごとのユーザビリティの考慮点

In addition to the previously described general usability considerations applicable to most authenticators (Section 10.1), the following sections describe other usability considerations specific to particular authenticator types.

一般論に加えて、個別に考慮しなければならない点をあげる。実は、これがSection 5で いろいろ規定されていることのうち、ユーザビリティに関係することの根拠になっている。

10.2.1 Memorized Secrets

記憶秘密。このセクションだて、よくないと思う。少なくとも、 認証器のタイプごとに、参照すべきセクションのリストをどこかにまとめておくべきだ。 この部分、（力尽きて）読んでいない人、結構いるんじゃないか。

Typical Usage

典型的な使用法

Users manually input the memorized secret (commonly referred to as a password or PIN).

Usability considerations for typical usage include:

利用者は、手で記憶秘密（パスワード、PIN）を入力する。 考慮すべきユーザビリティには以下のようなものがある

• Memorability of the memorized secret.
  • The likelihood of recall failure increases as there are more items for users to remember. With fewer memorized secrets, users can more easily recall the specific memorized secret needed for a particular RP.
  • The memory burden is greater for a less frequently used password.
• User experience during entry of the memorized secret.
  • Support copy and paste functionality in fields for entering memorized secrets, including passphrases.
• 記憶秘密の記憶しやすさ
  • 思い出せないという確率は、利用者が覚えなければいけないパスワードの個数が増えるにしたがって増加する。パスワードの個数を少なくすれば、特定のRP（サービス提供者SPという言葉は使わずに、信頼するものRP Relying Partyという言葉を使う。）利用に必要な特定の記憶秘密を思い出しやすくなる。
  • あまり使わなければ使わないほどそのパスワードを覚えておく負担は大きい。
• 記憶秘密を入力中の利用者エクスペリエンス
  • 記憶秘密（パスフレーズを含む）を入力するフィールドにコピペができるようにすること。

Intermittent Events

使用中に起きる事象

Usability considerations for intermittent events include:

• When users create and change memorized secrets:
  • Clearly communicate information on how to create and change memorized secrets.
  • Clearly communicate memorized secret requirements, as specified in Section 5.1.1.
  • Allow at least 64 characters in length to support the use of passphrases. Encourage users to make memorized secrets as lengthy as they want, using any characters they like (including spaces), thus aiding memorization.
  • Do not impose other composition rules (e.g. mixtures of different character types) on memorized secrets.
  • Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise. (See Section 5.1.1 for additional information).
• Provide clear, meaningful and actionable feedback when chosen passwords are rejected (e.g., when it appears on a “black list” of unacceptable passwords or has been used previously).
• 利用者が記憶秘密を生成、変更する場合
  • どのようにするかその方法について、きちんと情報を交換する
  • 5.1.1で規定する記憶秘密に対する要求要件について、きちんと情報を交換する
  • パスフレーズ利用のために最低64文字を許すこと。利用者に対して、記憶秘密を生成するときに 長さ、文字種（空白を含む）についての制限をなくし、記憶秘密を記憶しやすくすべきである。
  • この他のルールは記憶秘密には課さない。異なった文字種の使用を強制するのが典型的である。
  • 記憶秘密を、利用者の意思に関係なく（例えば、定期変更）変更することを要求しない。 ただし、利用者が要求したり、記憶秘密が危殆化した証拠があがればこの限りではない。 ここまで、5.1.1に書いてあることと重複する。だから、構成がよくないって。
• 利用者が選択したパスワードを設定拒否する場合、きちんとした、意味のある、対応可能なフィードバックをかけること。たとえば、受容できないパスワードのブラックリストに載っているとか、過去に使っていたとか。

10.2.2 Look-Up Secrets

参照秘密

Typical Usage

典型的な使用法

Users use the authenticator — printed or electronic — to look up the appropriate secret(s) needed to respond to a verifier’s prompt. For example, a user may be asked to provide a specific subset of the numeric or character strings printed on a card in table format.

利用者が、検証者の要求に応える必要があって、参照認証器（物理媒体、電子媒体ともに）の対応する秘密を参照する。 たとえば、カードに表形式で印字された文字数字の列の特定の一部を入力するように求められる。

Usability considerations for typical usage include:

• User experience during entry of look-up secrets.
  • Consider the prompts’ complexity and size. The larger the subset of secrets a user is prompted to look up, the greater the usability implications. Both the cognitive workload and physical difficulty for entry should be taken into account when selecting the quantity and complexity of look-up secrets for authentication.
• 参照秘密を入力中の利用者エクスペリエンス
  • 要求する入力の複雑さとサイズに考慮すべきである。 参照すべきものが多くなるほどユーザビリティに影響する。 参照秘密の和人複雑さを設定するときは、入力に際しての認知的な負担（つまり面倒さ）と物理的な困難さを考慮すべきである。

10.2.3 Out-of-Band

アウトオブバンド

Typical Usage

典型的な使用法

Out-of-band authentication requires users have access to a primary and secondary communication channel.

アウトオブバンド認証では、利用者が正と副チャネルにアクセスすることを要求する。

Usability considerations for typical usage:

典型的な使用法に関するユーザビリティ上の考慮点

• Notify users of the receipt of a secret on a locked device. However, if the out of band device is locked, authentication to the device should be required to access the secret.

• Depending on the implementation, consider form-factor constraints as they are particularly problematic when users must enter text on mobile devices. Providing larger touch areas will improve usability for entering secrets on mobile devices.

• A better usability option is to offer features that do not require text entry on mobile devices (e.g., a single tap on the screen, or a copy feature so users can copy and paste out-of-band secrets). Providing users such features is particularly helpful when the primary and secondary channels are on the same device. For example, it is difficult for users to transfer the authentication secret on a smartphone because they must switch back and forth—potentially multiple times—between the out of band application and the primary channel.

• 利用者に、ロック済みの装置上に秘密のレシートを送る。アウトオブバンド装置にロックがかかっている場合は、その秘密にアクセスするときに装置への認証を要求すべきである。

• 実装にもよるが、形状からくる制約を考慮すること。 特に、利用者がモバイル装置上でテキストを入力するとき、特に問題になる。 タッチ領域を広く取っておくと、モバイル装置上で秘密を入力するときのユーザビリティが向上する。

• より良いのは、モバイル装置上での利用者からテキスト入力を求めないことである。 たとえば、スクリーンをタップするとか、アウトオブバンド秘密をコピペできる機能など。 特に正/副チャネルが同じ装置上に乗っているときに特に役に立つ。 たとえば、スマホに送られた認証の秘密を送るのは、アウトオブバンド秘密を送られるアプリケーションと正チャネルの間で行ったり来たりしなければならないことを考えると、テキスト入力を求めると、ユーザビリティ上は難しい。

10.2.4 Single-Factor OTP Device

単要素OTP装置

Typical Usage

典型的な使用法

Users access the OTP generated by the single-factor OTP device. The authenticator output is typically displayed on the device and the user enters it for the verifier.

単葉をOTP装置の生成したOTPにアクセスする。認証器の出力が装置に表示され、利用者がそれを検証者に入力するのが典型的である。

Usability considerations for typical usage include:

• Authenticator output allows at least one minute between changes, but ideally allows users the full two minutes as specified in Section 5.1.4.1. Users need adequate time to enter the authenticator output (including looking back and forth between the single-factor OTP device and the entry screen).

• Depending on the implementation, the following are additional usability considerations for implementers:

  • If the single-factor OTP device supplies its output via an electronic interface (e.g, USB) this is preferable since users do not have to manually enter the authenticator output. However, if a physical input (e.g., pressing a button) is required to operate, the location of the USB ports could pose usability difficulties. For example, the USB ports of some computers are located on the back of the computer and will be difficult for users to reach.
  • Limited availability of a direct computer interface such as a USB port could pose usability difficulties. For example, the number of USB ports on laptop computers is often very limited. This may force users to unplug other USB peripherals in order to use the single-factor OTP device.

• 認証器の出力は、次の変更まで最低1分は確保。理想的には5.1.4.1で規定したように、2分は確保すべきである。利用者は、認証器からの出力を入力するのに十分な時間が必要である。 単要素OTP装置と入力画面を行ったり来たりする時間も考慮しなければならない。

• 実装にもよるが、以下のユーザビリティを追加で実装者は考慮すべきである。

  • 単要素OTP装置は、USBなどを通じて電子的に出力するのが望ましい。利用者は、手で認証器の出力を入力する必要がなくなる。ボタンを押すなどの物理的な行動が要求されると、USBポートの位置がユーザビリティ上の問題を引き起こすことがある。たとえば、筐体の後ろにしかUSBポートがないコンピュータだと、手をのばすことが難しくなる。
  • USBポートなど、コンピュータに直接差し込む形のインターフェースに制限があると、ユーザビリティ上の問題を引き起こすことがある。たとえば、ノートPCについているUSBポートの数は少ないのが一般的だが、そうすると単要素OTP装置を使うのに、他のUSB周辺装置を引っこ抜かなければならなくなる。
だんだん大喜利みたいになってきたぞ。ユーザビリティを論じる時に（ExperienceでもHCIでも）一般にそうだが アドホックなコメントの集合体になりがちで、全体としてどうなのかについての大局観に欠ける。 しかも、informativeと言いながら、根拠（となる論文とか、業界の常識とか）を示さないから、それが重要なものか、些細なものかがわからない。 「あぁ、これで終わりか」と思っていたら「あと…」とか「あ、思い出した」と話を継がれるときのストレスに通じるものがある。

10.2.5 Multi-Factor OTP Device

多要素OTP装置

Typical Usage

典型的な使用法

Users access the OTP generated by the multi-factor OTP device through a second authentication factor. The OTP is typically displayed on the device and the user manually enters it for the verifier. The second authentication factor may be achieved through some kind of integral entry pad to enter a memorized secret, an integral biometric (e.g., fingerprint) reader, or a direct computer interface (e.g., USB port). Usability considerations for the additional factor apply as well — see Section 10.2.1 for memorized secrets and Section 10.4 for biometrics used in multi-factor authenticators.

利用者が、多要素OTP装置に、2番目の認証要素を通してアクセスする。 OTPは、装置上に表示され、利用者はそれを検証者に対して手で入力するのが典型的な使用法である。 第2認証要素は、装置上の記憶秘密を入力するパッド、装置上の生体情報（指紋など）リーダー、 USBポートなどの直接コンピュータに接続する形で与えられる。 追加認証要素に関するユーザビリティ上の考慮点は、それぞれの事項（記憶秘密なら10.2.1、生体情報なら10.4）での 説明が当てはまる。

Usability considerations for typical usage include:

• User experience during manual entry of the authenticator output.
  • For time-based OTP, provide a grace period in addition to the time during which the OTP is displayed. Users need adequate time to enter the authenticator output, including looking back and forth between the multi-factor OTP device and the entry screen.
  • Consider form-factor constraints if users must unlock the multi-factor OTP device via an integral entry pad or enter the authenticator output on mobile devices. Typing on small devices is significantly more error prone and time-consuming than typing on a traditional keyboard. The smaller the integral entry pad and onscreen keyboard, the more difficult it is to type. Providing larger touch areas improves usability for unlocking the multi-factor OTP device or entering the authenticator output on mobile devices.
  • Limited availability of a direct computer interface like a USB port could pose usability difficulties. For example, laptop computers often have a limited number of USB ports, which may force users to unplug other USB peripherals to use the multi-factor OTP device.
• 認証器の出力を手で入力するときの利用者エクスペリエンスUser experience during manual entry of the authenticator output.
  • 時間を基にしたOTPでは、OTPが表示される時間に加えて十分な間隔をおくこと。利用者は、認証器からの出力を入力するのに十分な時間が必要である。 多要素OTP装置と入力画面を行ったり来たりする時間も考慮しなければならない。
  • 利用者が、多要素OTP装置を、装置上の入力パッドやモバイル装置に送られる認証器出力を使ってロックを外すときは、 形状からくる制約を考慮すべきである。小さい装置上でのタイピングは普通のキーボードに比べて間違いを誘発しまた時間もかかる。 装置上の入力パッドが小さいほど、タイピングは難しくなる。タッチ領域を大きくとると、これら入力のときのユーザビリティが向上する。
  • USBポートなど、コンピュータに直接差し込む形のインターフェースに制限があると、ユーザビリティ上の問題を引き起こすことがある。たとえば、ノートPCについているUSBポートの数は少ないのが一般的だが、そうすると単要素OTP装置を使うのに、他のUSB周辺装置を引っこ抜かなければならなくなる。
これ、前に言ってきたことをかき集めてきた感じ。きちんと「10.2.4（単要素OTP装置）の議論がそのまま当てはまる」と書くべきだ。

10.2.6 Single-Factor Cryptographic Software

単要素暗号ソフトウェア

Typical Usage

典型的な使用法

Users authenticate by proving possession and control of the cryptographic software key.

利用者が、暗号ソフトウェアの鍵を保有し、制御していることを証明することで認証する。

Usability considerations for typical usage include:

• Give cryptographic keys appropriately descriptive names that are meaningful to users since users have to recognize and recall which cryptographic key to use for which authentication task. This prevents users from having to deal with multiple similarly- and ambiguously-named cryptographic keys. Selecting from multiple cryptographic keys on smaller mobile devices may be particularly problematic if the names of the cryptographic keys are shortened due to reduced screen size.
• 暗号鍵には、利用者にとって意味があるように記述した名前をつけること。 利用者は、どの認証タスクにどの暗号鍵を使ったらよいか、いちいち意識して思い出さなければならないからである。 複数の暗号鍵を似たような、しかも曖昧な名前で管理しなくてもよくなる。 小さいモバイル機器上で複数の暗号鍵から選択しなければならず、スクリーンサイズが小さいために暗号鍵の名前が短縮されて表示されるときに特に問題になる。
これだけかよ。

10.2.7 Single-Factor Cryptographic Device

単要素暗号装置

Typical Usage

典型的な使用法

Users authenticate by proving possession of the single-factor cryptographic device.

利用者が、暗号装置の鍵を保有し、制御していることを証明することで認証する。

Usability considerations for typical usage include:

• Requiring a physical input (e.g., pressing a button) to operate the single-factor cryptographic device could pose usability difficulties. For example, some USB ports are located on the back of computers, making it difficult for users to reach.

• Limited availability of a direct computer interface like a USB port could pose usability difficulties. For example, laptop computers often have a limited number of USB ports, which may force users to unplug other USB peripherals to use the single-factor cryptographic device.

• ボタンを押すなどの物理的な行動が要求されると、USBポートの位置がユーザビリティ上の問題を引き起こすことがある。たとえば、筐体の後ろにしかUSBポートがないコンピュータだと、手をのばすことが難しくなる。
• USBポートなど、コンピュータに直接差し込む形のインターフェースに制限があると、ユーザビリティ上の問題を引き起こすことがある。たとえば、ノートPCについているUSBポートの数は少ないのが一般的だが、そうすると単要素OTP装置を使うのに、他のUSB周辺装置を引っこ抜かなければならなくなる。
これ、前（単/多要素OTP装置）からのコピペ。ならそうと書くべきだ。後で表を書いて整理していて 対応したつもりになっているかもしれないが。

10.2.8 Multi-Factor Cryptographic Software

多要素暗号ソフトウェア

Typical Usage

典型的な使用法

In order to authenticate, users prove possession and control of the cryptographic key stored on disk or some other “soft” media that requires activation. The activation is through the input of a second authentication factor, either a memorized secret or a biometric. Usability considerations for the additional factor apply as well — see Section 10.2.1 for memorized secrets and Section 10.4 for biometrics used in multi-factor authenticators.

利用者は、ディスクその他各種ソフトメディア上に格納し、アクティベーションを必要とする秘密鍵 を保有、制御していることを証明することで認証を行う。 アクティベーションは、第2要素（記憶秘密または生体情報）の入力で行う。 第2要素のユーザビリティ上の考慮は10.2.1または10.4の各事項がそのまま当てはまる。

Usability considerations for typical usage include:

• Give cryptographic keys appropriately descriptive names that are meaningful to users since users have to recognize and recall which cryptographic key to use for which authentication task. This prevents users from having to deal with multiple similarly- and ambiguously-named cryptographic keys. Selecting from multiple cryptographic keys on smaller mobile devices may be particularly problematic if the names of the cryptographic keys are shortened due to reduced screen size.
• 暗号鍵には、利用者にとって意味があるように記述した名前をつけること。 利用者は、どの認証タスクにどの暗号鍵を使ったらよいか、いちいち意識して思い出さなければならないからである。 複数の暗号鍵を似たような、しかも曖昧な名前で管理しなくてもよくなる。 小さいモバイル機器上で複数の暗号鍵から選択しなければならず、スクリーンサイズが小さいために暗号鍵の名前が短縮されて表示されるときに特に問題になる。
これ、単要素暗号ソフトウェアのコピペ。

10.2.9 Multi-Factor Cryptographic Device

多要素暗号装置

Typical Usage

典型的な使用法

Users authenticate by proving possession of the multi-factor cryptographic device and control of the protected cryptographic key. The device is activated by a second authentication factor, either a memorized secret or a biometric. Usability considerations for the additional factor apply as well — see Section 10.2.1 for memorized secrets and Section 10.4 for biometrics used in multi-factor authenticators.

利用者は、多要素暗号装置を保有し、暗号鍵を制御していることを証明することで認証を行う。 アクティベーションは、第2要素（記憶秘密または生体情報）の入力で行う。 第2要素のユーザビリティ上の考慮は10.2.1または10.4の各事項がそのまま当てはまる。

Usability considerations for typical usage include:

• Do not require users to keep multi-factor cryptographic devices connected following authentication. Users may forget to disconnect the multi-factor cryptographic device when they are done with it (e.g., forgetting a smartcard in the smartcard reader and walking away from the computer).
  • Users need to be informed regarding whether the multi-factor cryptographic device is required to stay connected or not.

• Give cryptographic keys appropriately descriptive names that are meaningful to users since users have to recognize and recall which cryptographic key to use for which authentication task. This prevents users being faced with multiple similarly and ambiguously named cryptographic keys. Selecting from multiple cryptographic keys on smaller mobile devices (such as smartphones) may be particularly problematic if the names of the cryptographic keys are shortened due to reduced screen size.

• Limited availability of a direct computer interface like a USB port could pose usability difficulties. For example, laptop computers often have a limited number of USB ports, which may force users to unplug other USB peripherals to use the multi-factor cryptographic device.
• 利用者に、認証に引き続き暗号装置を接続したままにすることを要求してはならない。 認証が済んだら多要素暗号装置を取り外し忘れるかもしれない。たとえば、ICカードを リーダーに差し込んだままコンピュータから去っていくかもしれない。そういえば、「スマートカード」は、本格的普及前から筆者も意識して使っていたのだが、いつのまにか「ICカード」の方が優勢になっちゃって…
  • 利用者は多要素暗号装置を接続したままにしなければならないかどうかの通知されなければならない。
• 暗号鍵には、利用者にとって意味があるように記述した名前をつけること。 利用者は、どの認証タスクにどの暗号鍵を使ったらよいか、いちいち意識して思い出さなければならないからである。 複数の暗号鍵を似たような、しかも曖昧な名前で管理しなくてもよくなる。 小さいモバイル機器上で複数の暗号鍵から選択しなければならず、スクリーンサイズが小さいために暗号鍵の名前が短縮されて表示されるときに特に問題になる。
• USBポートなど、コンピュータに直接差し込む形のインターフェースに制限があると、ユーザビリティ上の問題を引き起こすことがある。たとえば、ノートPCについているUSBポートの数は少ないのが一般的だが、そうすると単要素OTP装置を使うのに、他のUSB周辺装置を引っこ抜かなければならなくなる。
コピペが過ぎる。

10.3 Summary of Usability Considerations

ユーザビリティ考慮のまとめ

Table 10-1 summarizes the usability considerations for typical usage and intermittent events for each authenticator type. Many of the usability considerations for typical usage apply to most of the authenticator types, as demonstrated in the rows. The table highlights common and divergent usability characteristics across the authenticator types. Each column allows readers to easily identify the usability attributes to address for each authenticator. Depending on users’ goals and context of use, certain attributes may be valued over others. Whenever possible, provide alternative authenticator types and allow users to choose between them.

Multi-factor authenticators (e.g., multi-factor OTP devices, multi-factor cryptographic software, and multi-factor cryptographic devices) also inherit their secondary factor’s usability considerations. As biometrics are only allowed as an activation factor in multi-factor authentication solutions, usability considerations for biometrics are not included in Table 10-1 and are discussed in Section 10.4.

Table 10-1 Usability Considerations Summary by Authenticator Type



10.4 Biometrics Usability Considerations

生体情報のユーザビリティ上の考慮点

This section provides a high-level overview of general usability considerations for biometrics. A more detailed discussion of biometric usability can be found in Usability & Biometrics, Ensuring Successful Biometric Systems NIST Usability.

このセクションでは、生体情報のユーザビリティ上の考慮点一般の高レベルに概観する。 詳細はNIST Usability () 内のBiometrics, Ensuring Successful Biometric Systemsのセクションを参照。…とかいてあるのだが、ここリンク切れ（2020/03/29現在）。ここらへん、動きが激しいからねぇ。

Although there are other biometric modalities, the following three biometric modalities are more commonly used for authentication: fingerprint, face and iris.

生体様態のなかで、認証に最もよく使われるものは指紋、顔、虹彩である。

Typical Usage

典型的な使用法

• For all modalities, user familiarity and practice with the device improves performance.

  すべての様態について、利用者は、それをよく知っていたり、よく使っていると、 動作がよくなる。

• Device affordances (i.e., properties of a device that allow a user to perform an action), feedback, and clear instructions are critical to a user’s success with the biometric device. For example, provide clear instructions on the required actions for liveness detection.

  装置のアフォーダンス（利用者が動作をするための装置の性質）、フィードバック、明瞭な指示は、 生体情報装置を上手に使うために本質的に重要である。たとえば、リブネス検知のためには、検知のために要求される動作について明瞭な指示を与えなければならない。

• Ideally, users can select the modality they are most comfortable with for their second authentication factor. The user population may be more comfortable and familiar with — and accepting of — some biometric modalities than others.

  理想的には、利用者は第2要素として最も使いやすい生体様態を選択できるようになっている。 生体様態のうち、いくつかが、使いやすくて馴染みがあり、利用者全員に受け入れやすくなっている。

• User experience with biometrics as an activation factor.

  アクティベーション要素としての生体情報エクスペリエンス

  • Provide clear, meaningful feedback on the number of remaining allowed attempts. For example, for rate limiting (i.e., throttling), inform users of the time period they have to wait until next attempt to reduce user confusion and frustration.

    トライの残り回数について、明確で意味のあるフィードバックをすること。 レート制限（スロットリング）では、利用者の混乱とストレスを軽減するために、次のトライまでどれくらい待たないといけないか通知すること。

• Fingerprint Usability Considerations:

  指紋のユーザビリティ上の考慮点

  • Users have to remember which finger(s) they used for initial enrollment.

    利用者は、最初の登録のときにどの指を登録したか覚えておかなければならない。

  • The amount of moisture on the finger(s) affects the sensor’s ability for successful capture.

    指の湿り具合がセンサーの性能に影響する。

  • Additional factors influencing fingerprint capture quality include age, gender, and occupation (e.g., users handling chemicals or working extensively with their hands may have degraded friction ridges).

    その他で指紋採取に影響する要素として、年齢、性別、職業がある。有機溶剤を扱っていたり、手を頻繁に使う職業の利用者なら、指紋が磨滅しているかもしれない。

• Face Usability Considerations:

  顔情報のユーザビリティ上の考慮点

  • Users have to remember whether they wore any artifacts (e.g., glasses) during enrollment because it affects facial recognition accuracy.

    利用者は登録時にメガネなどをつけていたかどうか覚えておかなければならない。これは、 顔認識の精度に影響する。

  • Differences in environmental lighting conditions can affect facial recognition accuracy.

    ライティング環境の違いが顔認識の精度に影響する。

  • Facial expressions affect facial recognition accuracy (e.g., smiling versus neutral expression).

    表情が顔認識の精度に影響する。（笑っているときといないときなど）

  • Facial poses affect facial recognition accuracy (e.g., looking down or away from the camera).

    ポーズが顔認識の精度に影響する。（カメラに対して下を向いているとか、顔を背けているとか）

• Iris Usability Considerations:

  虹彩のユーザビリティ上の考慮点

  • Wearing colored contacts may affect the iris recognition accuracy.

    カラーコンタクトをつけていると、虹彩認識の精度に影響する。

  • Users who have had eye surgery may need to re-enroll post-surgery.

    眼の手術を受けるとその後に再登録が必要である。

  • Differences in environmental lighting conditions can affect iris recognition accuracy, especially for certain iris colors.

    ライティング環境の違いが顔認識の精度、特に特定の虹彩の色に対する精度に影響する。

Intermittent Events

使用中の事象

As biometrics are only permitted as a second factor for multi-factor authentication, usability considerations for intermittent events with the primary factor still apply. Intermittent events with biometrics use include, but are not limited to, the following, which may affect recognition accuracy:

生体情報は多要素認証の第2要素としてのみ許容される。したがって、主要素に対する使用中の事象に関する ユーザビリティ上の考慮点はそのまま当てはまる。認識の精度に影響するものとして、以下のものがある。ただし、 これには限らない。

• If users injure their enrolled finger(s), fingerprint recognition may not work. Fingerprint authentication will be difficult for users with degraded fingerprints.

  利用者が、登録した指に傷を追ったら、指紋認識はできなくなるかもしれない。指紋認証は、指紋が磨滅すると 難しくなる。

• The time elapsed between the time of facial recognition for authentication and the time of the initial enrollment can affect recognition accuracy as a user’s face changes naturally over time. A user’s weight change may also be a factor.

  顔認識と初期登録の間の時間の差によって認識の精度に影響することがある。顔の経年変化や体重の変化が影響する。

• Iris recognition may not work for people who had eye surgery, unless they re-enroll.

  眼の手術をすると虹彩認識するためには再登録が必要になる可能性がある。

Across all biometric modalities, usability considerations for intermittent events include:

生体様態すべてについて、仕様中の事象に考慮すべきユーザビリティ上の考慮点として以下のものがある。

• An alternative authentication method must be available and functioning. In cases where biometrics do not work, allow users to use a memorized secret as an alternative second factor.

  認証の代替手段が利用可能でかつ機能していなければならない。生体情報が使えない場合、代替第2要素として 記憶秘密を利用できるようにしなければならない。

• Provisions for technical assistance:

  技術的な支援対策

  • Clearly communicate information on how and where to acquire technical assistance. For example, provide users information such as a link to an online self-service feature and a phone number for help desk support. Ideally, provide sufficient information to enable users to recover from intermittent events on their own without outside intervention.

    技術的支援をどこでどのように得られるかを知らせておく。たとえば、オンラインでのセルフサービスへのリンク先、チャットの場、ヘルプデスクサポートの電話番号など。情報を十分に提供すれば、（理想的には）利用者は使用中に起きる事象から外の助けなしに回復できるだろう。

  • Inform users of factors that may affect the sensitivity of the biometric sensor (e.g., cleanliness of the sensor).

    生体センサーの感度に影響する要素を利用者に知らせておくこと。たとえばセンサーのきれいさとか。

11 References

This section is informative.

11.1 General References

[BALLOON] Boneh, Dan, Corrigan-Gibbs, Henry, and Stuart Schechter. “Balloon Hashing: A Memory-Hard Function Providing Provable Protection Against Sequential Attacks,” Asiacrypt 2016, October, 2016. Available at: https://eprint.iacr.org/2016/027.

[Blacklists] Habib, Hana, Jessica Colnago, William Melicher, Blase Ur, Sean Segreti, Lujo Bauer, Nicolas Christin, and Lorrie Cranor. “Password Creation in the Presence of Blacklists,” 2017. Available at: https://www.internetsociety.org/sites/default/files/usec2017_01_3_Habib_paper.pdf

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

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

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

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

[ICAM] National Security Systems and Identity, Credential and Access Management Sub-Committee Focus Group, Federal CIO Council, ICAM Lexicon, Version 0.5, March 2011.

[M-03-22] OMB Memorandum M-03-22, OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002, September 26, 2003, available at: https://georgewbush-whitehouse.archives.gov/omb/memoranda/m03-22.html.

[M-04-04] OMB Memorandum M-04-04, E-Authentication Guidance for Federal Agencies, December 16, 2003, available at: https://georgewbush-whitehouse.archives.gov/omb/memoranda/fy04/m04-04.pdf.

[Meters] de Carné de Carnavalet, Xavier and Mohammad Mannan. “From Very Weak to Very Strong: Analyzing Password-Strength Meters.” In Proceedings of the Network and Distributed System Security Symposium (NDSS), 2014. Available at: http://www.internetsociety.org/sites/default/files/06_3_1.pdf

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

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

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

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

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

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

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

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

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

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

11.2 Standards

[BCP 195] Sheffer, Y., Holz, R., and P. Saint-Andre, Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), BCP 195, RFC 7525,DOI 10.17487/RFC7525, May 2015, https://doi.org/10.17487/RFC7525.

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

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

[ISO/IEC 10646] International Standards Organization, Universal Coded Character Set, 2014, available at: http://standards.iso.org/ittf/PubliclyAvailableStandards/c063182_ISO_IEC_10646_2014.zip.

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

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

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

[RFC 20] Cerf, V., ASCII format for network interchange, STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, https://doi.org/10.17487/RFC0020.

[RFC 5246] IETF, The Transport Layer Security (TLS) Protocol Version 1.2, RFC 5246, DOI 10.17487/RFC5246, August 2008, https://doi.org/10.17487/RFC5246.

[RFC 5280] IETF, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC 5280, DOI 10.17487/RFC5280, May 2008, https://doi.org/10.17487/RFC5280.

[RFC 6238] IETF, TOTP: Time-Based One-Time Password Algorithm,RFC 6238, DOI 10.17487/RFC6238, https://doi.org/10.17487/RFC6238.

[RFC 6960] IETF, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, RFC 6960, DOI 10.17487/RFC6960, https://doi.org/10.17487/RFC6960.

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

11.3 NIST Special Publications

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

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

[SP 800-52] NIST Special Publication 800-52 Revision 1, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, April, 2014, http://dx.doi.org/10.6028/NIST.SP.800-52r1

[SP 800-53] NIST Special Publication 800-53 Revision 4, Recommended Security and Privacy Controls for Federal Information Systems and Organizations, April 2013 (updated January 22, 2015), http://dx.doi.org/10.6028/NIST.SP.800-53r4.

[SP 800-57 Part 1] NIST Special Publication 800-57 Part 1, Revision 4, Recommendation for Key Management, Part 1: General, January 2016, http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4.

[SP 800-63-3] NIST Special Publication 800-63-3, Digital Identity Guidelines, June 2017, https://doi.org/10.6028/NIST.SP.800-63-3.

[SP 800-63A] NIST Special Publication 800-63A, Digital Identity Guidelines: Enrollment and Identity Proofing Requirements, June 2017, https://doi.org/10.6028/NIST.SP.800-63a.

[SP 800-63C] NIST Special Publication 800-63C, Digital Identity Guidelines: Federation and Assertions, June 2017, https://doi.org/10.6028/NIST.SP.800-63c.

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

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

[SP 800-131A] NIST Special Publication 800-131A Revision 1, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, November 2015, http://dx.doi.org/10.6028/NIST.SP.800-131Ar1

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

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

11.4 Federal Information Processing Standards

[FIPS 140-2] Federal Information Processing Standard Publication 140-2, Security Requirements for Cryptographic Modules, May 25, 2001 (with Change Notices through December 3, 2002), https://doi.org/10.6028/NIST.FIPS.140-2.

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

[FIPS 201] Federal Information Processing Standard Publication 201-2, Personal Identity Verification (PIV) of Federal Employees and Contractors, August 2013, http://dx.doi.org/10.6028/NIST.FIPS.201-2.

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

Appendix A—Strength of Memorized Secrets

This appendix is informative.

Throughout this appendix, the word “password” is used for ease of discussion. Where used, it should be interpreted to include passphrases and PINs as well as passwords.

A.1 Introduction

Despite widespread frustration with the use of passwords from both a usability and security standpoint, they remain a very widely used form of authentication [Persistence]. Humans, however, have only a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed. To address the resultant security concerns, online services have introduced rules in an effort to increase the complexity of these memorized secrets. The most notable form of these is composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought [Policies], although the impact on usability and memorability is severe.

まずはイントロ。まず2012年の論文を引いて、パスワードの需要は根強いと言う。 しかし、人間に覚えられる複雑さには限界があることから、安易な方向（簡単なパスワードを設定）に流れ勝ちである。それを食い止めるのがパスワードポリシーであった。 今でも、ポリシーを設定しているところはたくさんある。カードのオンラインサイトとか、つい最近（2020年）もいくつか経験した。 代表的なポリシーには以下のようなものがある。

• 複数の文字種（数字、大文字、記号）を使うこと
ポリシーはシステムで設定できるようにしているものがある。標準にはとうとうならなかったが、OpenLDAP、Windows等のログインパスワードのチェックなどは、今でも設定可能である。 しかし、その効果は実は現在では限定的であることが明らかになってきた。具体的に2010年の文献をあげているが、その現在での有効性はともかく、いろいろ悩んできたのである。

Complexity of user-chosen passwords has often been characterized using the information theory concept of entropy [Shannon]. While entropy can be readily calculated for data having deterministic distribution functions, estimating the entropy for user-chosen passwords is difficult and past efforts to do so have not been particularly accurate. For this reason, a different and somewhat simpler approach, based primarily on password length, is presented herein.

利用者が選択したパスワードの複雑さを測るには、情報理論のエントロピーを 使うのがよくやる手口であるが、難しいし、正確さもそれほどでもない。 そこで、ここでは「長さ」を採用することにする。
と言っているのだが、ここで大きな決断をしている。長さを尺度とすれば、 今までやってきた議論がひっくり返される。この部分で、きちんとつっこまないとだわ。

Many attacks associated with the use of passwords are not affected by password complexity and length. Keystroke logging, phishing, and social engineering attacks are equally effective on lengthy, complex passwords as simple ones. These attacks are outside the scope of this Appendix.

ここで扱う脅威は、長さと複雑さに関係するものに限定する。キーロギング、 フィッシング、ソーシャルエンジニアリングは、考慮外とする。 これは、脅威モデルの限定の仕方を指定することでオーソドックスなやり方。

A.2 Length

Password length has been found to be a primary factor in characterizing password strength [Strength] [Composition]. Passwords that are too short yield to brute force attacks as well as to dictionary attacks using words and commonly chosen passwords.

パスワードの長さは、強度の主要素であることは、言を俟たない。 短かすぎるパスワードは、辞書攻撃とともに、総当たり攻撃に弱い。

The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted. In order to prevent an attacker (or a persistent claimant with poor typing skills) from easily inflicting a denial-of-service attack on the subscriber by making many incorrect guesses, passwords need to be complex enough that rate limiting does not occur after a modest number of erroneous attempts, but does occur before there is a significant chance of a successful guess.

最低パスワード長は、脅威モデルとして何を取るかに依存する。 攻撃があっても、スロットリングなどのレート制限で対策しておけば、リスクは低減される。 攻撃側によるDoSを防ぐには、何回か失敗してもレート制限がおこらないように 十分複雑にしておかなければならない。
ここでは、スロットリングなどでオンラインでの攻撃には十分対策を取っておくことを 要求している。 スロットリングの設定は、WindowsサーバならSet-ThrottloingPolicyで できるはず。Linuxならカーネルのどこかのパラメタをいじればよいはずなんだが…

Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.

オフラインの攻撃への対処の仕方がここで述べられる。 攻撃の前提として、パスワードのハッシュ値が流出することがある。 もちろん、ハッシュ値にはソルトはかかっているし、ハッシュアルゴリズムも 十分複雑なものは採用されているのだろうが、現在の計算能力を考えれば、 オンライン攻撃への耐性より数段高い耐性を求める必要がある。
現状、大手では「パスワードが流出する」（ハッシュ値がばれる）と「もうだめだ」 と、パスワードの一斉変更を要請することが多いようである。

Users should be encouraged to make their passwords as lengthy as they want, within reason. Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely long passwords (perhaps megabytes in length) could conceivably require excessive processing time to hash, so it is reasonable to have some limit.

利用者は、パスワードの長さに制限を加えられないようにすべきである。 パスワードをハッシュ値で保存する限り、どんな長いパスワードを設定しても ハッシュ値のサイズは変わらないから、システムの側でも長さに制限を加える 合理性はないはずであるが、長すぎるものだと、さすがに処理速度に効いてくるから、 その意味の制限は許される。数百字くらいではびくともしないので、 短歌一首くらいは余裕。柿本人麻呂のながいながい長歌でも大丈夫なはずである。

A.3 Complexity

As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.

パスワード作成ルール（複数種の文字種の組み合わせ）は普通に使われていて、 今もなくなっていないのは、筆者の経験からも実感しているが、 実際、それを強制されると、（攻撃側にも）予測可能なやり方を取りがちである。 password --> Pasword1 (大文字と数字入れろ！)　--> Password1!（記号も入れろ！） などなど。

Users also express frustration when attempts to create complex passwords are rejected by online services. Many services reject passwords with spaces and various special characters. In some cases, the special characters that are not accepted might be an effort to avoid attacks like SQL injection that depend on those characters. But a properly hashed password would not be sent intact to a database in any case, so such precautions are unnecessary. Users should also be able to include space characters to allow the use of phrases. Spaces themselves, however, add little to the complexity of passwords and may introduce usability issues (e.g., the undetected use of two spaces rather than one), so it may be beneficial to remove repeated spaces in typed passwords prior to verification.

さらに自分で考えた「複雑なパスワード」の作り方が、システムから許容されないと またストレスがたまる。空白などの特殊な文字がSQL injectionなどの攻撃を回避するために 使えるかもしれない。（本当か？実例を求む） そんなわけで、特に空白文字を許して、パスワードとしてフレーズを利用するときなどに 対応して空白文字を許すのがよろしかろう。 ただし、空白文字をパスワードに許すのは、複雑さを増すというよりは利用感を改善する効果の 方が大きい。この意味では空白を含むパスワードは「正規化」して、連続する 空白は一つにするというのは、利益があるかもしれない。 ただし、これをやっているところ、現状ではあまりないのではないか。

Users’ password choices are very predictable, so attackers are likely to guess passwords that have been successful in the past. These include dictionary words and passwords from previous breaches, such as the “Password1!” example above. For this reason, it is recommended that passwords chosen by users be compared against a “black list” of unacceptable passwords. This list should include passwords from previous breach corpuses, dictionary words, and specific words (such as the name of the service itself) that users are likely to choose. Since user choice of passwords will also be governed by a minimum length requirement, this dictionary need only include entries meeting that requirement.

パスワードの選択と言っても、利用者側の行動など、だいたいお見通しなので、 辞書や、過去の「ブラックリスト」を参照することで破ることはできるだろう。 守る側はそのブラックリストを参照して、その中に入っている語を 設定することを禁止することは意味のあることである。 毎年決まった時期になると、12345678とかpasswordとかqwertyとかが 「よく設定されるパスワード」として発表されるが、それを禁止する意味でも この設定は大事。 NIST Bad Passwordsなんかの お遊びのサイトもあるし、 オンラインのパスワードチェッカー もあったりする。 攻撃側のツールも、少し前は結構簡単にアクセスできたりしたのだが…

Highly complex memorized secrets introduce a new potential vulnerability: they are less likely to be memorable, and it is more likely that they will be written down or stored electronically in an unsafe manner. While these practices are not necessarily vulnerable, statistically some methods of recording such secrets will be. This is an additional motivation not to require excessively long or complex memorized secrets.

複雑すぎるパスワードをつけると、覚えきれなくてどこかに覚えておくかもしれない。 これ自身が脆弱性になる。覚えきれないほど長くて複雑なパスワードを 要求することはこの点からもよくない。

A.4 Randomly-Chosen Secrets

Another factor that determines the strength of memorized secrets is the process by which they are generated. Secrets that are randomly chosen (in most cases by the verifier or CSP) and are uniformly distributed will be more difficult to guess or brute-force attack than user-chosen secrets meeting the same length and complexity requirements. Accordingly, at LOA2, SP 800-63-2 permitted the use of randomly generated PINs with 6 or more digits while requiring user-chosen memorized secrets to be a minimum of 8 characters long.

パスワードの複雑さを決めるもう一つの要因として、ランダムに生成されたかどうか がある。たとえば、WiFiのパスワードなど、一度設定すればあとは自動で認証を 行うようなものについては、利用者は覚える必要がなく、「一度設定する」作業のみが 必要である。このようなランダムなパスワードについては利用者自身が設定するもの よりも、総当たり攻撃への耐性は高い。ランダムに生成したパスワードなら6文字（数字のみでも可）を許容しているのはそういう理由がある。

As discussed above, the threat model being addressed with memorized secret length requirements includes rate-limited online attacks, but not offline attacks. With this limitation, 6 digit randomly-generated PINs are still considered adequate for memorized secrets.

もちろん、オフラインの攻撃にさらされればだめなわけだが、オンライン攻撃への 耐性のみを求めるのであれば、6文字はまだ許容範囲であると言える。

A.5 Summary

Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as blacklists, secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed.

以上要するにだ、8文字（またはランダムに6文字）を超える制限をかけると、 パスワードも難しくしなければならないし、利用者のストレスもたまり、 絶対に回避策を講じてくる。これはよくない、という結論である。 パスワードの複雑さを増すよりは、ブラックリストのチェック、ハッシュかけて セキュアに格納しておく、レート制限をする方が（総当たり攻撃に対しては）よほど効果的である。
視点を変えよう。この文書に不満を持つ前にだ、次をチェックしてみよう。 ブラックリストのチェックしてる？システムのセキュリティは ちゃんとしてる？スロットリングちゃんとかけてる？ この文書に文句付けるなら、まずそこらへんの対策を適用してからだろう。 これは筆者も賛成するところである。

さて、手元に、古文書がある。

• R. Farrow, UNIX System Security, How to Protect Your Data and Prevent Intruders, 1991.
この時代、パスワードを使ってシステムを守るしか術がなかった時代に何が書かれたか、 少し見てみることにしよう。
まず、20ページ。「最善のパスワードは、文字、数字、区切り文字をランダムに組み合わせたものだが、覚えにくいし、どこかに書き留めたり（して、今でいうソーシャルエンジニアリングでパスワードを盗まれる）問題を引き起こす。
次に、「人間は、自分のパスワードを決めるとなると、一般にはうまく振舞えない。 パスワードによく使われるものとしては、名前、ログイン名の繰り返し、またはそれらに数字一つを組み合わせたものがせいぜい。」と、昔から人間の行動などお見通しだったのである。
その次に、よいパスワードのつけ方として、いろいろ言った後、「パスワードは長く使うな」「パスワードの使いまわしはするな」と言う。パスワード使いまわしを避けるには 幹となる語にprefixをいろいろつければOKなどと書く（今は推奨されない）。3章では、当時、役に立つと思われていたpassword aging（期限切れ機能）についても触れている。