Up-to-date: https://speakerdeck.com/kthrtty/ren-zheng-nimatuwarusekiyuriteifalsexin-chang-shi NIST SP800-63-3を翻訳し、63-B部分についてまとめました。 Errata: 6章「あるAALに必要なAuthenticatorが全て利用不能」は誤りで、「あるAALに必要なAuthentictor要素の一部または全部が利用不能」が正しいです。すみません。

1. 2017/10/27 @ LODGE
Tatsuya Katsuhara
NIST Special Publication 800-63B
Digital Identity Guidelines (翻訳版)
Authentication and Lifecycle Management

2. 本日のゴール
• ついに正式版になった NIST SP 800-63-3 について”63B”パート
のサマリを把握する
• Authenticatorタイプを具体的に想像できるようになる
• AAL(Authenticator Assurance Level)を知る
• 議論となりがちなテーマについて、NISTはどのような見解を
示したのかを知る

3. 勝原達也(@kthrtty) 1～6章/付録翻訳担当
• NRIセキュアテクノロジーズ所属
• デジタル・アイデンティティ
• OpenID／OAuth、認証／認可、OIDFJ、会員管理システム
• Web／プラットフォーム脆弱性診断
• IoT ／ハードウェア／重要インフラセキュリティ

4. 木村仁美(@hitok_) 7～11章翻訳担当
• セコム→トレンドマイクロ(JP)→同(US)
• 電子認証(PKI)
• サイバー攻撃のアナリスト、情報発信
• インシデントハンドリング「ボドゲ」
作者のひとり
• 2016年春のセキュリティエキスポで披露
• 私が好きな800-63B
• 10.2.1 Memorized Secret
• Memorized Secret に他の構成ルール ( 例 : 異なる文字タイプの混合) を課さない．
• ユーザの要求や Authenticator の危殆化の証拠がない限り，Memorized Secret は恣
意的な (例 : 定期的な) 変更を必要としない．
今日はテキサスなう

5. ガイドライン全体における位置付け
デジタル認証のガイドライン 登録プロセス、身元確認 認証とライフサイクル管理 フェデレーションとアサーション
• ざっくりいうと
• 登録済みのアカウントを使ってデジタルの世界でのユーザ認証を行い、
その結果の正しさを確認するプロセスについて記述
• Authenticator（旧Token）タイプの定義
• AAL（Authenticator Assurance Level）の定義
• とにかく色々ルールが書いてあるのでまずは要点把握が重要

6. 63Bの目次
1. 目的
2. はじめに
3. 定義及び略語
4. Authenticator Assurance Levels
5. Authenticator及びVerifierの要件
6. Authenticatorライフサイクルの要件
7. セッション管理
8. 脅威とセキュリティに関する考慮事項
9. プライバシに関する考慮事項
10. ユーザビリティに関する考慮事項
11. 参照
付録A — 記憶シークレットの強度

7. 63Bの目次
1. 目的
2. はじめに
3. 定義及び略語
4. Authenticator Assurance Levels
5. Authenticator及びVerifierの要件
6. Authenticatorライフサイクルの要件
7. セッション管理
8. 脅威とセキュリティに関する考慮事項
9. プライバシに関する考慮事項
10. ユーザビリティに関する考慮事項
11. 参照
付録A — 記憶シークレットの強度
• AAL毎の要件と、それに合致す
るAuthenticatorの話
• Authenticatorの種類や、備える
べき機能の話

8. 63Bの目次
1. 目的
2. はじめに
3. 定義及び略語
4. Authenticator Assurance Levels
5. Authenticator及びVerifierの要件
6. Authenticatorライフサイクルの要件
7. セッション管理
8. 脅威とセキュリティに関する考慮事項
9. プライバシに関する考慮事項
10. ユーザビリティに関する考慮事項
11. 参照
付録A — 記憶シークレットの強度
• Authenticatorの発行、紛失、盗
難、破棄などの要件

9. 63Bの目次
1. 目的
2. はじめに
3. 定義及び略語
4. Authenticator Assurance Levels
5. Authenticator及びVerifierの要件
6. Authenticatorライフサイクルの要件
7. セッション管理
8. 脅威とセキュリティに関する考慮事項
9. プライバシに関する考慮事項
10. ユーザビリティに関する考慮事項
11. 参照
付録A — 記憶シークレットの強度
• セッションCookie、AccessToken、
再認証など認証後のセッション
維持とその保護に関わる話

10. 63Bの目次
1. 目的
2. はじめに
3. 定義及び略語
4. Authenticator Assurance Levels
5. Authenticator及びVerifierの要件
6. Authenticatorライフサイクルの要件
7. セッション管理
8. 脅威とセキュリティに関する考慮事項
9. プライバシに関する考慮事項
10. ユーザビリティに関する考慮事項
11. 参照
付録A — 記憶シークレットの強度
• AuthenticatorやSessionに関する
リスク要因および対策
• プライバシーリスクアセスメン
ト、コントロールなどの話

11. 63Bの目次
1. 目的
2. はじめに
3. 定義及び略語
4. Authenticator Assurance Levels
5. Authenticator及びVerifierの要件
6. Authenticatorライフサイクルの要件
7. セッション管理
8. 脅威とセキュリティに関する考慮事項
9. プライバシに関する考慮事項
10. ユーザビリティに関する考慮事項
11. 参照
付録A — 記憶シークレットの強度
• Authenticationのユーザビリティ
はビジネスの成功に影響
• 高いAALは良いユーザビリティ
を要求
• Authenticatorのライフサイクル
を通じたユーザビリティ確保

12. 用語
• ユーザはライフサイクルで言い方が異なる
• Applicant→Subscriber→Claimant
• CSP(Credential Service Provider)
• Applicantの情報を登録してSubscriber化
• Subscriberに対してAuthenticatorを発行
• Authenticator(昔Tokenと呼ばれていたもの)
• ClaimantはAuthenticatorを使って認証し、
Subscriberであることを示す
• Authentication(本資料では「認証」と表記)
• 前来た人と、今来た人が
同一であることを確認する
• Verifier
• Authenticatorの出力を見て、
Subscriberかどうかを確認する
• Relying Party
• Verifierの確認結果に基づいて、
認証済みセッションを開始する
63Bの主要トピックス

13. Authenticatorのタイプ
# 原文 和訳
認証要素
Something you ***
暗号プロトコル(鍵の所持
証明)として認められるか
HWとして
認められるか
1 Memorized Secret 記憶シークレット 知識 No No
2 Look-up Secret ルックアップシークレット 所有 No No
3 Out of Band Device 経路外デバイス 所有 No No
4 SF OTP Device 単一要素OTPデバイス 所有 No Yes/No※
5 MF OTP Device 多要素OTPデバイス 所有+知識/生体 No Yes/No※
6 SF Cryptographic Software 単一要素暗号ソフトウェア 所有 Yes No
7 SF Cryptographic Device 単一要素暗号デバイス 所有 Yes Yes
8 MF Cryptographic Software 多要素暗号ソフトウェア 所有+知識/生体 Yes No
9 MF Cryptographic Device 多要素暗号デバイス 所有+知識/生体 Yes Yes
※「デバイス」という呼称と、HWとして認められるかが一致しないので少々トリッキー

14. Authenticatorのタイプ
# Authenticatorのタイプ 内容
1
Memorized Secret
記憶シークレット
ユーザが記憶するもの。
例：パスワードやPIN
※ローカル／リモートどちらであるか問わない。
2
Look-up Secret
ルックアップシークレット
Claimant（認証をしたい人）とCSP（認証情報を登
録・払い出す側）の間で共有されているシーク
レット。
例：乱数表、Googleアカウントの二要素認証のリ
カバリコードのようなもの
3
Out of Band
経路外
(RESTRICTED)
セカンダリチャネルを介してVerifierと安全に通信
できるようなもの。
例：SMSによるコード送信、QRコード読み取り、
電話によるコード読み上げ／入力
※EメールやVoIPはセカンダリチャネルとして認め
られない。

15. Authenticatorのタイプ
# Authenticatorのタイプ 内容
4
SF OTP Device
単一要素OTPデバイス
二要素目の入力によるアクティベーションを必要
とせず、所持していることで認証を実施できる。
例：パスフレーズ入力不要なOTPデバイス（スマホ
にインストールしたソフト含む）
5
MF OTP Device
多要素OTPデバイス
SF OTP Deviceに更に二要素目の入力によるアクティ
ベーションを追加したもの。
例：（スマホのロック解除とは別に）Touch IDやマ
スタPWでアクティベートし利用するOTPアプリ
6
SF Cryptographic Software
単一要素暗号ソフトウェア
ディスクあるいはソフト媒体に記録された一意な
暗号鍵。鍵はデバイス上で最もセキュアなスト
レージに保存されており、アクセスコントロール
が施されている。
例：端末毎のクライアント証明書（PW保護無し）
7
SF Cryptographic Device
単一要素暗号デバイス
保護された暗号鍵を用いて認証を行うハードウェ
アデバイス。鍵はデバイスで一意であり、エクス
ポートできてはいけない。
例：FIDO U2FのUSBドングル

16. Authenticatorのタイプ
# Authenticatorのタイプ 内容
8
MF Cryptographic Software
多要素暗号ソフトウェア
単一要素暗号ソフトウェアに対して、更にアク
ティベートするための2要素目が必要となったもの。
例：指紋認証を行うことで有効化されるクライア
ント証明書
9
MF Cryptographic Device
多要素暗号デバイス
単一要素暗号デバイスに対して、更にアクティ
ベートするための2要素目が必要となったもの。
例：パスワードまたはバイオメトリクスでアク
ティベートしなければ利用できないようになって
いるUSBトークン、FIDO対応スマホ、TouchIDや
FaceID

17. AAL(Authenticator Assurance Level）
• 「Claimant＝Subscriberであること」の確認(認証)の信頼性を3段階に分類したもの
• 観点は複数あり、同時に満たした場合に当該レベルに適合
• 認証要素（Something you ***）は同じ要素を2つ使っても1要素とカウント
• 利用する暗号アルゴリズム要件は63-3記載の「承認済みのもの」利用
要求事項 AAL 1 AAL 2 AAL 3
許容される
Authenticator
タイプ
• 9タイプ全部OK（何でも良い）
• Authenticator単独で2要素以上
• またはPW(知識)＋2要素目(所有,特徴)
• 2要素以上
• 暗号鍵の所持証明要素
• ハードウェア関与
• 記憶シークレット
• ルックアップシークレット
• 経路外
• 単一要素OTPデバイス
• 多要素OTPデバイス
• 単一要素暗号ソフトウェア
• 単一要素暗号デバイス
• 多要素暗号ソフトウェア
• 多要素暗号デバイス
• 多要素OTPデバイス
• 多要素暗号ソフトウェア
• 多要素暗号デバイス
• 記憶シークレット＋以下
• ルックアップシークレット
• 経路外
• 単一要素OTPデバイス
• 単一要素暗号ソフトウェア
• 単一要素暗号デバイス
• 多要素暗号デバイス
• 単一要素暗号デバイス
＋記憶シークレット
• 多要素OTPデバイス(SW/HW)
＋単一要素暗号デバイス
• 多要素OTPデバイス(HW)
＋単一要素暗号ソフトウェア
• 単一要素OTPデバイス(HW)
+多要素暗号ソフトウェア
• 単一要素OTPデバイス(HW)
+単一暗号ソフトウェア
+記憶シークレット

18. 要求事項 AAL 1 AAL 2 AAL 3
許容される
Authenticatorタイプ
• 9タイプ全部OK
（何でも良い）
• Authenticator単独で2要素以上
• またはPW(知識)＋2要素目(所有,生体)
• 2要素以上
• 暗号鍵の所持証明要素
• ハードウェア関与
FIPS 140適合 Level 1 (政府機関のVerifier)
Level 1 (政府機関のAuthenticator及び
Verifier)
Level 2 総合 (多要素Authenticator)
Level 1 総合 (Verifier及び単一要素暗号デバイス)
Level 3 物理セキュリティ (全てのAuthenticator)
再認証 30 日
12 時間または30分間活動なしの場合に、
1つの認証要素を利用して再認証(任意)
12 時間または15分間活動なしの場合に、 両方の
認証要素を利用して再認証(必須)
セキュリティ統制
[SP 800-53] 低い基準
(または 等価なもの)
[SP 800-53] 中度の基準
(または等価なもの)
[SP 800-53] 高い基準
(または等価なもの)
中間者攻撃耐性 必須 必須 必須
Verifierなりすまし
耐性
不要 不要 必須
Verifier改竄耐性 不要 不要 必須
リプレイ耐性 不要 必須 必須
認証意図
(AuthN Intent)
不要 推奨 必須
レコード保持ポリシ 必須 必須 必須
プライバシ統制 必須 必須 必須
AAL(Authenticator Assurance Level）

19. パスワードからパスフレーズへ
「 5.1.1 記憶シークレット」では大きな変更あり。
• ユーザが選択したパスワードは8文字以上
• 最低64文字のパスワードを許容すべき
• その他のパスワードの複雑さに関する要件を課すべきではない
• 空白許容（パスフレーズ対応）
• Unicode許容
• リストとの突合（漏洩PW、辞書、繰り返し／シーケンシャル、文脈で
特定可能なもの）
• パスワード強度メーター
• ペースト機能（長いパスフレーズ入力大変、パスワードマネージャ）
• バリエーションに富んだ可視化（入力完了後マスク、1文字単位マスク、
マスク解除）

20. 取扱が厳しくなった秘密の質問
• SP800-63-2では”Pre-registered Knowledge Token”と呼称。
• SP800-63-3では記憶シークレットの一部に再編され
「やってはいけない」記憶シークレットの例として記載される
ことになった。
• サービス事業者の立場では「厳しい」かもしれない。
• 秘密の質問に頼らない、より安全なパスワードリマインダの再設計
5.1.1.2 記憶シークレットVerifier
記憶シークレットを選択する際，VerifierはSubscriberに対して特
定のタイプの情報（例えば，「あなたが飼った最初のペットの
名前はなんですか？」といったもの）の入力を求めないものと
する(SHALL NOT)．

21. 地味に影響がありそうな乱数表の制限追加
• 乱数表で各セルの値の使い回しが禁止された。
• 5.1.2.2に「もしルックアップシークレットが格子状のカードから得られる場合，格
子の各セルは1度だけ利用するものとする(SHALL)． 」という要件追加。
• 直感的にはビンゴカードに近い（使ったセルが使えなくなっていく）と推測される。
• NISTが想定しているのは二要素認証の有効化時に表示されるような「リカバリコー
ド」。
• 米国政府での「日本的」な乱数表の利用は考慮されていない。
• ドラフト改訂作業において「米国政府では乱数表の利用はかなり少ないから関係な
い」と言及されており、他業界への影響について考慮しているか怪しい。
• 参考URL https://github.com/usnistgov/800-63-3/issues/56
乱数表（例：キャッシュカード裏面）
今回は「あA→いC→おB→うB」を入力してください。
杓子定規に受け取ると、
25文字の入力にしか使えない！

22. パスワードの定期変更は条件付”SHOULD NOT”
強制されるとユーザは結果として「弱いパスワード」を使うよう
になってしまう研究結果（CMU教授兼FTC主任技術者が言及）
例）
password Passw0rd P@ssw0rd P@ssw0rd! P@ssw0rd!1 P@ssw0rd!2
5.1.1.2 記憶シークレットVerifier
記憶シークレットを任意で(例えば，定期的に)変更するよう要求すべきで
はない(SHOULD NOT)．しかしながらAuthenticatorが危殆化している証拠が
ある場合は，変更を強制するものとする(SHALL)．
大文字/数字 記号 桁数 定期変更#1 定期変更#2

23. 経路外認証は引き続き使えるが”RESTRICTED”
• ドラフト改訂の当初は、公衆交換電話網(PSTN)を使っている
場合、SMSの経路外認証は非推奨に。
• PasswordCon 2016 での議論で大盛り上がり
• CMU教授兼FTCの主任技術者 Lorrie Cranor
• http://arstechnica.com/security/2016/08/frequent-password-changes-are-
the-enemy-of-security-ftc-technologist-says/
• 最終的には”RESTRICTED”という記載で許容された。
• VoIPやEメールはNG（特定デバイスの所有証明とならない方式のため）
• 事前登録済みの電話番号は物理デバイスと結びついていることを確認
• スマホのPush通知インフラはセカンダリチャネルとして利用可能
• 電話番号の変更は、新しいAuthenticatorのバインディングとみなされ、
特別な要件を追加（6章）
• 状況が変われば制約追加がありうる旨明言

24. バイオメトリクスの位置付け
5.2.3 バイオメトリクスの利用
限定サポートというのがNISTの見解。そのため、バイオメトリクスは
単独でAuthenticatorとしてはカウントされず、補助的な認証要素とい
う位置づけになっている。
大きな理由
• FMR（例：異なる指紋を比較して一致判定される確率）が低いから
といってAuthenticationの確実性が高まるわけではない。
• バイオメトリクスマッチングは確率的なものであるが、一方他の認
証要素は決定的なものである。
• 特徴点情報などの保護や無効化のための標準がまだない。
• バイオメトリクス特性はシークレットではない。
• プレゼンテーション攻撃を防ぐPADは今後必須化する見込み。

25. バインディング(6章)
• Authenticatorライフサイクルを通じて、AALを意識したプロセスが必要。
• 複数のAuthenticatorのバインディングを推奨。
登録時バインディング 登録後バインディング
バインドされ
た状態
未バインド
状態 同時にバインド実施
リモートトランザクション（途切れてしまう場合）
• 一時シークレット（TEL、Email、住所へ送付）を用いて再開
ローカルトランザクション（途切れてしまう場合）
• 一時シークレット（TEL、Email、住所へ送付）を用いて再開（再利用禁止）
• バイオメトリクス利用
あるAALに必要な
Authenticatorが全て
利用不能
Authenticator追加(AAL1手段の複数登録または、AAL2にアップグレード)
• 追加するAuthenticatorが利用されるAAL以上で認証。
• 通常は、保有しているAuthenticatorのAALで新Authenticatorを登録。
• AALのアップグレード(AAL1→2のみ)実施。
所有する一部のAuthenticatorが紛
失、盗難、破損、有効期限切れ、
失効
所有する一部のAuthenticatorが紛失、
盗難、破損、有効期限切れ、失効
置き換え（ AAL2/3の場合のAuthentication要素不足に対応）
• 基本的にはIdentity Proofingを伴う当初のリモート/ローカル
トランザクションと同様のバインディング手続きを実施
• 一時シークレットまたはバイオメトリクス利用
紛失、盗難、破損、有効期限
切れなどで失効、または解約
したAuthenticatorのバイン
ディングは削除する必要あり。
(63-A記載のIdentity Proofingを伴う)
63B記載内容から作成した簡易な状態遷移例

26. セッション管理(7章)
• セッションシークレット（実質的にセッション識別子）の守るべき
内容について言及している。
• NIST承認済みの乱数生成器で作った64ビット以上のセッション識別子
• XSS攻撃を想定して、HTML5ローカルストレージには配置しない
• セッション識別子は安全なチャネルで送受信されること
• OWASPS Session Management Cheat Sheetが参考になる
• ブラウザCookie／Access Tokenは具体的に個別内容を記載
• 再認証やFederation時のシステム間のセッション管理の独立性に言及
• 再認証に関する考え方の再整理と63-C(Federation and Assertion)での考え方に
ついても言及（Relying Partyはそれぞれセッション管理方法が異なる）
• RPでセッションが切れてCSPで再認証を行うと、CSPではセッションが有効な
ため明示的な認証なしにAssertionがすぐに生成されることがありうる
• Authentication Context Class Referenceの考え方を実装に組み込むなどの検討が必要かも

27. 脅威とセキュリティに関する考慮事項(8章)
Authenticatorに対する脅威(左図)および、
各項目ごとに対策案・緩和策を提示
• 4章、5章、6章に記載してある対策のまとめ
その他、セッションに対する攻撃も言及
• XSSによるセッション情報窃取防止
• OWSAP対策文書を参照
• CSRF対策のための検証値導入
# Authenticatorの脅威/攻撃
1 盗難
2 複製
3 盗聴
4 オフラインクラッキング
5 サイドチャネル攻撃
6 フィッシング／ファーミング
7 ソーシャルエンジニアリング
8 エンドポイントの危殆化
9 未認可のバインディング

28. プライバシに関する考慮事項(9章)
• セキュリティアセスメントの実施要件(4.1.5、4.2.5、4.3.5)に改
めて言及
• やれるのか問題。
• ただし、この標準はあくまで米国連邦政府向け
• プライバシーコントロール要件(4.4)
• 基本的にはNIST SP800-53と、63Aを参照。
• 事業者としては一考の記述。
1. 収集時の利用目的に限定されていることを保証する施策をうつこと。
2. 法律を元にしたガチガチのプライバシポリシや一般的な利用規約を作って、
（明示的な目的外の用途など）広範な内容を丸め込まないこと。
3. 仮にユーザが「プライバシ」に関する追加要件に同意しなくてもサービスは提
供しつづけること。

29. ユーザビリティに関する考慮事項(10章)
• Authenticatorタイプ毎にユーザ目線で考慮事項を記載
• ユーザの負担を最小化することが目的。
• ビジネスの成功に「認証」のユーザビリティは非常に重要。
• ライフサイクル（認証実施、利用再開、情報開示、など）
に渡るAuthenticatorイベントを考慮。
• ユーザビリティ文脈でも「パスワード」について以
下記載があるのは興味深い
• 異なる文字タイプの混合のようなルールを課さない。
• ユーザの要求や Authenticator の危殆化の証拠がない限り，
定期的な変更を必要としない。
• バイオメトリクスの考慮事項も記載
• 殆どが「◯◯すると精度に影響するかもしれな
い」要因の列挙

30. まとめ
• パスワードからパスフレーズに（狙った効果が得られるか今
後の展開が楽しみ）
• 「秘密の質問／パスワードの定期変更」にNISTの見解が出た
• 経路外Authenticatorについては状況変化とともに制約が変わ
る可能性があり、利用に際しては継続的なウォッチ必要
• 生体認証は「現時点」ではセキュアというよりは利便性を提
供する補助的な認証要素という意味合いが強い印象