【要点抽出】NIST SP800-63B-4（前編）

ニキヌス

今回は認証（Authentication）についての情報が詰まった63Bを読みます。

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

はじめに

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

また、63Bについて簡潔に知りたい方は以下をご覧になったほうがよほど分かりやすいです。
https://speakerdeck.com/kthrtty/ren-zheng-nimatuwarusekiyuriteifalsexin-chang-shi
ただ、上記は第3版の内容であるのに対して一応こちらは第4版であることと、自分の勉強のために本noteをまとめています。

何の本？

NIST SP800-63の兄弟的な文書で、63Bはアカウント登録後の認証（Authentication）の要件を取り扱います。

構成は？

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

また、本書では4.セクションに本題としての各AALの要件が定められていますが、それを理解するためには先に5.セクションを読んでおいたほうがよさそうです。
今回は2.～7.セクションをまとめることとし、本note(前編)ではまず5.セクションを読みます。

  1. Purpose（Informative）

  2. Introduction（Informative）

  3. Definitions and Abbreviations（Informative）

  4. Authentication Assurance Levels（Normative）

  5. Authenticator and Verifier Requirements（Normative）

  6. Authenticator Lifecycle Management（Normative）

  7. Session Management（Normative）

  8. Threat and Security Considerations（Informative）

  9. Privacy Considerations（Informative）

  10. Usability Considerations（Informative）

  11. Equity Considerations（Informative）

前提知識

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

  • 本ガイドラインは 、建物などへの物理アクセスに対する認証はスコープ外です。

５．Authenticator and Verifier Requirements

各AALで利用を認められるAuthenticatorのタイプを見ていきます。
全9タイプあります。

（１）Memorized Secrets

パスワードやPINです。今回は便宜上「パスワード」とだけ書きます。
知識認証にあたります。
本書ではAuthenticatorとVerifierに求められる要件をそれぞれ記載していますが、ここではパスワード設定時、保存時、入力時に分けて記載します。
AuthenticatorとVerifierって何だっけ、という方はこちらを参照ください。

ａ．パスワード設定時

  • パスワードの長さは8文字以上（SHALL）

  • 登録済利用者（Subscriber）が決めるか、CSPがランダムに決める（SHALL)

  • 最大長について、少なくとも64文字までは入力可能とする(SHOULD)

  • すべてのASCII文字と空白文字、Unicode文字を使えるようにする(SHOULD)。ただし、Unicode文字を許可する場合は、登録済利用者（Subscriber）の環境によっては異なる方法で表現されるため、認証がうまくいかなくなる可能性があることを伝える（SHOULD）とともに、ハッシュ化する前に文字列を正規化する（SHOULD）

  • 認証前の登録済利用者（Subscriber）に対して、アクセスするためのヒント情報を保存するような機能は持たない（SHALL NOT）

  • 秘密の質問（Knowledge-Based Authentication）を使わせてはならない（SHALL NOT）

  • パスワードの設定または変更を受け付ける際に、Verifierは、侵害済や推測されやすい「使ってはならないパスワードリスト」（Blocklist）と比較する（SHALL）。リストの観点は例えば以下。

    • 侵害済パスワード

    • 辞書の単語

    • 反復または連続した文字 (例: aaaaaaや1234abcd)

    • サービス名やユーザ名など,コンテキスト特有の単語

  • ユーザのストレスになるため、Blocklistを過度に育てない（SHOULD NOT）

  • 登録済利用者（Subscriber）が入力したパスワードがリストに合致した場合は拒否し、その理由を提示するとともに別のパスワード設定を求める（SHALL）。この際、強いパスワードを設定するためのガイダンスも提供する（SHALL）

  • パスワードの侵害が認められた場合は、ユーザに変更を求める（SHALL）

  • 上記以外の複雑さの要件は課さない（SHALL NOT）

  • パスワードの定期変更は求めない（SHALL NOT)
    　#上記2点は、第3版でSHOULD NOTだったのが強調された様子

ｂ．パスワード(ハッシュ)保存時

  • オフライン攻撃（パスワードハッシュの解析）への対策として、パスワードに32ビット以上のソルトを付与した上でハッシュ化する（SHALL)
    NIST は特定のハッシュスキームに関するガイドラインを公開していないが、そのような関数の例にはArgon2やscryptなどがある。一方向関数の例には、SHA-3, CMAC, KMAC, cSHAKE, ParallelHashがある。

  • PBKDF2を使ってハッシュ計算する場合は、ソルトではなく10,000回以上のストレッチングによりオフライン攻撃に備える（SHOULD)

  • 更にVerifierは、Verifierのみが知っているシークレットキーを使って、パスワードハッシュそのものを暗号化する（本書では「鍵付き Hashまたは暗号化オペレーションの追加の反復を実行」と記載）（SHOULD）。
    このシークレットキーはSP800-131Aで指定されるセキュリティ強度を守る（執筆時点では112ビット以上）（SHALL）。
    シークレットキーの値は、ハッシュ化したパスワードとは別に、HSM等で保護する（SHALL）

ｃ．パスワード入力時（認証試行時）

  • 認証試行回数を制限する（SHALL）

  • パスワードマネージャーの使用を許可し(SHALL)、認証希望者（Claimant）がペーストによりパスワードを入力できるようにする（SHALL）

  • ユーザがタイプミスすること考慮して、Verifierは入力されたパスワードを検証する際に、以下のような点はある程度緩くみてもよい（MAY）
    ・先頭や末尾に入っている空白
    ・先頭の文字が大文字か小文字かという違い

  • 認証希望者（Claimant）が正しいパスワードを入力しやすくなるよう、認証希望者（Claimant）の選択に応じて入力中のパスワードを画面上でマスク(●とか＊への置換）しないオプションを提供する（SHOULD）。
    あるいは、入力された個々の文字(パスワード全体ではなく1文字ずつ)を、入力直後の短時間のみそのまま画面表示してもよい（MAY）。
    #ユーザがaと入力したら1秒ほど画面上に「a」と表示されて、その後●とかにマスクされるヤツのことです。

（２）Look-Up Secrets

表形式に数字が並んだ乱数表や、回復キーとして発行される非常に長い文字列(例えばGoogle2段階認証を設定する際のキーコード）です。
本書では、Look-up Secretは別のAuthenticatorの紛失・故障時のための１回限りの回復キーとしての用途が一般的だと書かれています。
所有物認証にあたります。

Authenticatorに求められる要件は以下です。

  • CSPは、SP800-90Ar1に定められたApproved Random Bit Generatorを使って20ビット以上のエントロピー(※)を持つシークレットを生成する（SHALL）

  • 登録済利用者（Subscriber）にAuthenticatorを安全に配布する（SHALL）。この配布方法は、対面、郵便、オンラインが考えられる（MAY）

    ※私は暗号技術に詳しくないのでざっくりしたイメージだけですが、エントロピーは暗号のランダム性であり、ビット数が高いほどより完全なランダムに近く推測されにくい、と理解しています。20ビットは結構緩い印象です。

Verifierに求められる要件は以下です。

  • シークレットは1回限りの利用。乱数表の各セルも1度しか使えない（SHALL）

  • シークレットのエントロピーが112ビット以上の場合は、ハッシュ化した上で保存する（SHALL）

  • エントロピーが112ビット未満の場合は、32ビット以上のソルトを付与した上でハッシュ化して保存する（SHALL）

  • エントロピーが64ビット未満の場合は、認証試行回数の制限を設ける（SHALL）

（３）Out-of-Band Devices

SMSによるコード通知や電話での音声コード通知など、認証希望者（Claimant）が認証に使うメインのチャネルとは別の通信チャネルを用いた認証です。
所有物認証にあたります。

シークレットを認証希望者（Claimant）のセカンダリチャネルに送って、プライマリチャネル側に入力させる方法と、
シークレットを認証希望者（Claimant）のプライマリチャネルに送って、セカンダリチャネル側に入力させる方法があります。
以下では前者を前提に、スマホにシークレットが届くイメージで読むとよさそうです。

なお、第3版までは、プライマリとセカンダリにシークレットを送って比較させる手法も挙げられていましたが、これは削除されました。
理由として、実際には比較をせずに、単にVerifierからのプッシュ通知を受けてセカンダリチャネル側のデバイスで「承認」操作だけするような使い方が見受けられたためとしています。
これは2022年末頃に話題になったMFA疲労攻撃（MFA Fartigue Attack）を考慮したものと思われます。

また、ここまで「別の通信チャネル」と書いていますが、別にデバイスごとプライマリとセカンダリで分ける必要はありません。
互いチャネルが情報を漏らさないように分離されていればout-of-bandとしてみなされます。

Authenticatorに求められる要件は以下です。

  • Out-of-bandデバイスは, Verifierによって一意にアドレス指定が可能である必要がある（SHOULD）。特定のデバイスの所有を証明しないため、VOIP電話番号やメールアドレスはこの方式には使用できない（SHALL NOT）
    ＃でも、メアドは実際には多くのところで使われていますね。

  • デバイス内に保存したキーまたはSIMカードを使ってAuthenticator自身を認証する（SHALL）

  • デバイスにシークレットが届いたことをユーザに通知する（SHOULD）ものの、画面ロックがかかっている限り内容は表示しない（SHOULD NOT）

  • セカンダリチャネルの通信は基本的に暗号化する（SHALL）
    #基本的にと書いたのは、SMSなどの電話網を使う場合は暗号化できないためです。こうした理由や、SIMスワップの懸念から、この方法は制限付き（Restricted）扱いとされ、長期的には他の方式に移行する前提となります。

なお、認証希望者（Claimant）がAuthenticatorを利用する際に知識認証か生体認証によるチェックを追加することで、この認証タイプは多要素認証として扱われます。

Verifierに求められる要件は以下です。

  • ランダムなシークレットをAuthenticatorに送り、それがプライマリチャネルから返ってくるのを待つ（SHALL）
    ＃方式によってはプライマリ・セカンダリの関係が逆の場合もあります

  • シークレットの有効期限は10分（SHALL）

  • シークレットの有効回数は1回限り（SHALL）

  • デバイスにプッシュ通知する場合、前回の認証成功以降に送るプッシュ通知数に制限を設ける（SHOULD）

（４）Single-Factor OTP Device

Google Authenticatorのようなソフトウェア型のワンタイムパスワードを用いた手法です。所有物認証にあたります。
（４）以降の方式については、一般的には自前でAuthenticatorやVerifierを用意せずに専用サービスを使うでしょうから、要件の多くは割愛します。

Authenticatorに求められる要件は以下です。
ここでいうAuthenticatorはスマホ側のOTPアプリにあたり、Authenticatorは暗号鍵とNonceを腹持ちします。

  • 暗号鍵はSP800-131Aで指定されるセキュリティ強度を守る（執筆時点では112ビット以上）（SHALL）

  • 暗号鍵とNonceをもとに生成したOTPは6桁の10進数に切り詰めてよい（MAY）

  • Nonceが時刻に基づいている場合は、少なくとも2分ごとに変更する（SHALL）

  • 生成したOTPのエントロピーが64ビット未満の場合は、認証試行回数に制限をかける（SHALL）

Verifierに求められる要件は割愛します。

（５）Single-Factor Cryptographic Software

クライアント証明書などのディスクやソフトメディアに格納された秘密鍵です。所有物認証にあたります。

Authenticatorに求められる要件は以下です。

  • 秘密鍵はTPMなどの安全な場所に格納し、秘密鍵にアクセスできるソフトウェアも制限することで、不正アクセスから守る（SHALL）

Verifierに求められる要件は割愛します。

（６）Single-Factor Cryptographic Devices

YubiKeyのような、暗号鍵が内包されたUSBデバイス等を直接端末につなぐ方式です。Verifierから求められるChallenge-nonceに対して暗号鍵を用いて署名をすることで動作します。
所有物認証にあたります。

Authenticatorに求められる要件は以下です。

  • 暗号鍵はエクスポートできないようにする（SHALL）
    #もしエクスポート出来る場合、そのデバイスは（５）の「Cryptographic Software」とみなされます。

  • 例えばデバイスを接続している端末がマルウェア等により侵害された際に、当該デバイスを意図せず利用されないために、Cryptographic Deviceが動作するために物理的な入力 (例: ボタンを押す) を要求する（SHOULD）

Verifierに求められる要件は割愛します。

（７）Multi-Factor OTP Devices

（８）Multi-Factor Cryptographic Software

（９）Multi-Factor Cryptographic Devices

（７）～（９）はいずれも、最初に知識認証か生体認証を用いて認証することで、OTP DeviceやCryptographic SoftwareやCryptographic Deviceを活性化（Activation）します。これにより多要素として扱う方式です。
それ以外はSingle-Factorと同じです。

やっと9タイプの説明が終わりました。
次に、Authenticatorのタイプによらない共通的な要件の中からめぼしいものをピックアップします。

（１０）共通的な要件

ａ．Rate Limiting (Throttling)

  • 原則、同一アカウントに対する連続的な認証失敗の試行を100回以下に制限する（SHALL）

  • アカウントハッキング等の攻撃により正規の認証希望者（Claimant）がロックされてしまう可能性を下げるために、以下の合わせ技が有効（MAY）

    • CAPTCHA認証などによるボット対策を認証の前に挟む

    • 複数回失敗した際に、認証希望者（Claimant）に一定時間、再試行までの待ち時間を求める

    • 登録済利用者（Subscriber）が過去に認証成功したIPアドレスからの認証要求だけ受け入れる

    • IPアドレスやブラウザのメタデータ等も考慮して正規のユーザらしさを識別する

ｂ．Use of Biometrics
生体認証については63Aでも少し触れましたが、こちらのほうが詳述されています。
生体認証には、指紋や顔等の身体的特徴だけでなく、タイピングのリズム等の行動的特徴も含まれます。

  • 生体認証は、それ単体での利用は認められず、所有物認証と組み合わせた多要素認証の一部としてのみ認められる（SHALL）

  • FMR（False-Match Rate）は0.01%未満（SHALL）

  • 顔写真やフェイクの生体情報を用いたプレゼンテーション攻撃に対して、90%以上の耐性を持つ対策機能（PAD）を実装する（SHOULD）

  • 認証の連続失敗が5回（PAD有の場合は10回）で30秒以上の再試行待ちを要求する（SHALL）

  • 認証の連続失敗が50回（PAD有の場合は100回）で生体認証機能を無効化する（SHALL）

  • 生体情報の比較は中央のVerifierでもデバイス上のローカルでも可能だが、基本的には後者を選ぶ（SHOULD）
    #前者を選んだ場合は追加の考慮点がありますが、ここでは割愛します

ｃ．Phishing (Verifier Impersonation) Resistance
フィッシング耐性とは、攻撃者が作った偽のRPに対するシークレットや認証情報（Authenticator Output）の開示を、登録済利用者（Subscriber）の警戒に頼ることなく防止する機能と定義しています。
この際、ポイントとなるのは認証情報（Authenticator Output）を特定のセッション（Authenticated session）にバインドすることであり、このポイントを満たさないアウトオブバンド認証やOTP製品を用いたコード類を手動入力する方法はフィッシング耐性があるとはみなされません(SHALL NOT)。

フィッシング耐性がある手法は「Channel Binding」と「Verifier Name Binding」の2つと書かれています。前者のほうがより強度が高いようです。

Channel Bindingは一言でいえばクライアント証明書を用いたTLSが例です。
Verifier Name Bindingはいまいち理解できていませんが、事前に定めたVerifierのホスト名にしか認証情報（Authenticator Output）を送らない的な制御に見えました。

ｄ．Replay Resistance
攻撃者が過去にやりとりした認証情報を何らかの方法で入手し、そのまま悪用しようとするリプレイ攻撃に耐えるための要件です。
OTPデバイス、Cryptographic Authenticator、Look-Up Secretはやりとりされる認証情報が1回限りのため、リプレイ耐性があります。
一方でパスワードやPINなどのMemorized Secretはリプレイ耐性がありません。
＃本書では、その理由として「Secretそのものが認証ごとに提供される」とありますが、パスワードを使っていてもCHAP認証だとどう考えるのかが気になりました。

ｅ．Activation Secrets
Out-of-Band Devices、Cryptographic Software、Cryptographic Devicesを利用する前に、記憶認証や生体認証のステップを挟むことで多要素認証とみなすことができます。
この事前チェックのステップをActivationと呼び、Activationに用いるシークレットをActivation Secretと呼びます。
Activation Secretの要件は以下です。

  • ユーザのデバイス内に保存される（SHALL）

  • 6文字以上の長さが必要（SHALL）

  • 全て数字でもよい（MAY）が、英数字とする場合はASCII、空白文字、Unicodeに対応する（SHOULD）

  • 少なくとも10個の「シークレットとして使ってはならないリスト」（Blocklist)を持つ（SHALL）

  • シークレットの入力を10回連続で失敗した場合、Authenticatorを無効化する（SHALL）

後編ではいよいよ各AALの要件に入ります。
以下の表がその答えですが、先に5．セクションを読んだことでもう怖くない状態だと思います。

表１．「Table 1 AAL Summary of Requirements」をもとに作成

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

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

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