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

ニキヌス

SP800-63Bの続きです。前編で読んだ５．セクション以外を読みます。

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

４．Authentication Assurance Levels

前編の最後にも掲載しましたが、各AALの要件の概観は以下です。
赤字が第3版から変更された箇所です。

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

基本的には表の通りですが、補足説明したいものだけ以下に記載します。

AAL1は、前編の9タイプのいずれかを利用し（SHALL）、1要素でも多要素でもどちらでもOKです。
認証希望者（Claimant）とVerifierの間の通信は、TLS等の保護された通信チャネル（Authenticated Protected Channel）で守られます（SHALL）。SP800-53のLowレベルと書いてあるのは、CSPの保護要件を指します（SHALL）。

AAL2は、多要素認証が求められます。
多要素認証とは、以下のいずれかを使用（MAY）か、
（３）Out-of-band Devicesの多要素版
（７）Multi-Factor OTP Devices
（８）Multi-Factor Cryptographic Software
（９）Multi-Factor Cryptographic Devices

（１）Memorized Secretsと以下の所有物認証のいずれかを組み合わせたものを意味し、この場合は知識認証+所有物認証の組み合わせが必要です（SHALL）。
（２）Look-Up Secret
（３）Out-of-Band Device
（４）Single-Factor OTP Device
（５）Single-Factor Cryptographic Software
（６）Single-Factor Cryptographic Device
※括弧の数字は前編の章立てを表しています。

第3版では、AAL2におけるリプレイ耐性とフィッシング耐性はいずれもNot Requiredでした。
第4版ではリプレイ耐性がRequiredとなり、使用する少なくとも1つのAuthenticatorは、リプレイ耐性を持つ必要があります（SHALL）。
また、フィッシング耐性はRecommendedとなり、「通常AAL2にフィッシング耐性は求められないものの、その危険性を考慮して可能な限りフィッシング耐性があるAuthenticatorの使用を奨励するべき(SHOULD)」との記載が加わっています。これはOMB M-22-09が背景のようです。
なお、個人情報をオンラインで利用する場合は最低でもAAL2が求められます（SHALL）。

AAL3は、ハードウェアベースのAuthenticatorとフィッシング耐性のあるAuthenticatorによる多要素認証が求められます（SHALL）。
以下のいずれかを利用します（SHALL）。
（９）Multi-Factor Cryptographic Device
（６）Single-Factor Cryptographic Device + （１）Memorized Secret
（７）Multi-Factor OTP device + （６）Single-Factor Cryptographic Device
（７）Multi-Factor OTP device (ハードウェア型) + （５）Single-Factor Cryptographic Software
（４）Single-Factor OTP device (ハードウェア型) + （８）Multi-Factor Cryptographic Software Authenticator

このうちハードウェア型のAuthenticatorとVerifierは、サイドチャネル攻撃への耐性をもつ必要があります（SHOULD)。
この他は表1.の通りです。

６．Authenticator Lifecycle Management

ここでは登録済利用者（Subscriber）のAuthenticatorの利用開始から失効までの間に起こる様々なイベントに対する要件が書かれています。

(1)Authenticatorのバインディング

Authenticatorを登録済利用者のアカウント（Subscriber Account）に紐づけて使えるようにすることを「バインディング」と呼びます。
バインディングは、新たにアカウントを登録したとき（Enrollment）にも行いますし、その後のAuthenticatorの追加や変更時にも行います。

アカウント登録（Enrollment）のタイミングでバインディングする際は、知識認証や生体認証の情報に加え、１つ以上の所有物認証に使える物理デバイスを紐づけます（SHALL）。
#ユーザのパスワード紛失に備えて、アカウント復旧用のスマホの電話番号を登録させるイメージです。

また、アカウント登録（Enrollment）とバインディングが同一セッションで完結しない場合、例えば「パスワード登録は後で」みたいなケースの場合、途中でユーザが入れ替わる懸念があります。
このために、身元確認（Identity proofing）で確認した利用希望者（Applicant）の電話番号やメアドや住所へ一時シークレットを送り、「今パスワード登録しようとしているヤツはさっき身元確認したヤツと同じか」を確認します（SHALL）。

登録済利用者のアカウント（Subscriber Account）にAuthenticatorをバインディングする際は、バインディングや関連する鍵のプロビジョニング作業を、そのAuthenticatorが使われるAALに見合ったレベルで実施する必要があります（SHALL）。
つまり、多要素のAuthenticatorをバインディングする際は、多要素認証相当の確認が必要です（SHALL）。
#例えば、MUFGのスマホアプリ利用登録時（ワンタイムパスワード登録時）に本人確認のために登録済の電話番号に電話がかかってきて、電話で伝えられたワンタイムパスワードをアプリに入力するのはこういうことかと想像

バインディングすると、CSPはAuthenticatorに関する情報をレコードとして管理します。レコードには以下の情報を含みます。

  • バインディングした日付（SHALL）

  • アカウント登録（Enroll）に関連するバインディングの発生源（IPアドレス等）（SHOULD)

  • 当該Authenticatorによる認証試行が失敗した際の発生源（SHOULD)

  • 認証試行の回数制限（Throttling）に関する情報（SHALL）

更に、２つ目以降のAuthenticatorをバインディングする場合があります。
仮にAuthenticatorの追加を第三者ができてしまうと、そのアカウントにアクセスするための抜け穴となるため、追加時にも必要なAALでの認証を行います（SHALL）。
Authenticatorの追加が終わったら、メール等を用いて登録済利用者（Subscriber）にその旨を通知します（SHOULD）。

(2)アカウントリカバリ

登録済利用者（Subscriber）がAuthenticatorを紛失した時に行うのがアカウントリカバリです。

物理Authenticatorを紛失したとして、Claimant（認証希望者）が他のAuthenticatorを持っているのであれば、そちらを用いて認証します（SHALL）。
全てのAuthenticatorが使えなくなってしまった場合は、身元確認（Identity Proofing）からやり直しです（SHALL）。
この際、CSP側に以前受け取った身分証明書（Evidence）がまだ残っているのであれば、身元確認（Identity Proofing）は1からやり直すのではなくVerificationのステップだけでOKです（MAY）。
アカウントリカバリができたら、登録済利用者（Subscriber）にその旨を通知します（SHOULD）。

上記は物理Authenticatorの紛失の例でしたが、パスワード忘れの場合もあります。
この場合は、生体認証が使えるならそれで認証し（SHOULD）、生体認証が使えないなら「Subscriberの住所の一つに送信された確認コードとともに2つの物理Authenticatorを用いた認証」を行うことでパスワードの再登録を認めます（SHALL）。
#2つの物理Authenticatorとは、所有物認証1要素の2段階認証を意味し、例えばOTPアプリ+メールでのコード通知みたいな組み合わせです。
#本書には明記されていないのですが、おそらくAAL2以上なのにパスワードを忘れた場合の話だと思います。

この確認コードの有効期限は以下です（SHALL）。

  • 米国本土の Address of Record に郵送される場合は21日

  • 米国本土以外の Address of Record に郵送される場合は30日

  • 記録済電話番号に (SMS ないし音声で) 送信される場合は10分

  • 記録済 Email アドレスに送信される場合は24時間

(3)紛失，盗難，破損，不正な複製

Authenticatorが盗難などで使えなくなった場合は、悪用を防ぐためにもできるだけ早く、タイムリミットを切ったうえでAuthenticator の一時停止、失効、破棄を行います。
ただ、無防備にそうした申告を受け付けると、なりすまし申告によりAuthenticatorが急に使えなくなることも考えられるため、登録済利用者（Subscriber）がCSPに紛失や盗難をセキュアに報告できるように代替的な認証手段を提供します（SHOULD）。この際に用いるのは、Memorized Secretか物理Authenticatorのどちらかです（SHALL)。
Authenticatorを一時停止した後、登録済利用者（Subscriber） が盗難紛失したものとは別のAuthenticator を使って認証し、一時停止の再開（Reactivation）を要求した場合は元に戻します (SHALL)。

(4)External Authenticatorのバインディング

ここは第4版から登場した項目です。
「authenticated endpoint」「Binding Code」など初登場する言葉があり正しく理解できているか微妙ですが、おそらく、これまで特定の端末を認証に使ってきた中で、新たな端末も認証に使えるようにバインディングしたい（例えば端末の買い替え等）。みたいな話かと思います。

基本的な流れは以下です。
① CSPがBinding Codeを生成
② Binding Codeを新たな端末、もしくは元々使っていた端末へセキュアな通信経路で送信
③ 登録済利用者（Subscriber）が、上記のコードをもう一方の端末に送信し、入力

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

  • ①について、Binding Codeは40bitまたは112bit以上のエントロピーを持ち、有効回数は1回、有効期限は10分以内（SHALL）
    事前に新端末から登録済利用者（Subscriber）の識別子をCSPに入力していた場合は40bit以上でOK（MAY）

  • ③について、Binding Codeの送信は手動かローカルのOut-of-bandな手法（QRコード等）で行う（SHOULD）。メールやSMSでの連携はNG（SHALL NOT）。

  • ③まで終わったら、CSPは登録済利用者（Subscriber）に対し、新端末から認証することを要求する（SHOULD）

  • CSPはバインディングの事故があった場合の対処方法（Authenticatorの無効化機能や連絡先）を登録済利用者（Subscriber）に提供する（SHALL）

この他に、本セクションではAuthenticatorの更新、登録済利用者（Subscriber）が持ち込んだAuthenticatorのバインディング、Authenticatorの期限切れや無効化といったテーマが扱われていますが、ここでは割愛します。

７．Session Management

認証完了後、アクセスされるサービスはセッション管理により認証済であることを確認します。
この際重要なのがセッションシークレットと呼ばれる情報であり、これが第三者に奪われるとなりすまし等に繋がるため、いかにこれを守るかが論点となります。セッションシークレットの代表例はCookieです。
(本書では他にもモバイルアプリのセッションシークレットや、OAuthにおけるアクセストークン等も触れています）

セッションシークレット（以下シークレット）のライフサイクルは以下の流れです。
① 認証後、セッションホスト（RPやCSP）がシークレットを発行する
② セッションホストが登録済利用者（Subscriber）のエンドポイントにシークレットを渡す
③ 登録済利用者（Subscriber）のエンドポイントがシークレットを保存する
④ 登録済利用者（Subscriber）のエンドポイントがセッションホストにシークレットを提示する
⑤ 登録済利用者（Subscriber）のエンドポイントがシークレットを破棄する

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

  • ①について、シークレットは認証のやりとりの中で（直後に）生成し、64bit以上のエントロピーを持つ（SHALL）

  • ①について、Cookieの場合は必要最小限のホスト名やパスでのみアクセスできるようにする（SHALL）

  • ①について、Cookieには平文の個人情報を含まない（SHOULD NOT）

  • ②、④について、シークレットは暗号化された通信上でのみやりとりされる（SHALL）
    #CookieにおけるSecure属性の指定

  • ③について、シークレットはHTML5ローカルストレージのようなセキュアでない場所に保存しない（SHOULD NOT）

  • ③について、Cookieの場合はJavaScriptからアクセスできないようにHttpOnly属性を付与する（SHOULD)

  • ④について、AALごとに定められたタイムアウトの時間を超えたらシークレットを受け入れない（SHALL）

  • ④について、CSRF対策のために、URLやPOSTコンテンツにRPが検証するセッション識別子を含める（SHALL)

  • ⑤について、登録済利用者（Subscriber）がログアウトしたらシークレットを消去・無効化する（SHALL）

また、再認証する際の要件も挙げられています。
再認証とは、セッションの有効期限内に登録済利用者（Subscriber）が引き続き存在することを確認することであり、定期的な再認証を求めています（SHALL）。
各AALごとにセッションの有効期限が定められていましたが、これを延長するためには下表の確認が必要（SHALL）であり、Cookieなどのシークレットの提示だけで延長してはいけません（SHALL NOT）。
延長が間に合わずにタイムアウトになってしまった場合は、認証をやりなおして新たなセッションを確立します（SHALL）。

表２．「Table 2 AAL Reauthentication Requirements」より

本来は多要素認証を求められるAAL2が、再認証の場合は1要素でよいところが特徴ですね。ただし、再認証において所有物認証は認められません。

余談として、残り8～11セクションは本noteでは扱いませんが、10.Usabilityが面白い内容でした。
いかにユーザにストレスを与えないようにするかを洗い出しており、例えばごく一部ですが以下が挙げられています。

  • パスワード等の入力が途中でタイムアウトにならないよう、十分な時間を与える

  • パスワード等の入力ミスを考慮して少なくとも10回は試行を許可する

  • 残りの試行回数や、次に試行できるまでの待ち時間をユーザーに知らせる

  • セッションの非アクティブによるタイムアウトが発生する前に、ユーザに何らかの動作を促す

  • 固定の定期的な再認証を求める場合、セッション断に備えてユーザーに作業内容を保存するよう促す

  • パスワード等の入力フィールドにおいてコピペを許可する（パスフレーズのような長い文字列の支援）

  • アウトオブバンド認証について、通知されたコードを手入力しなくて済むような機能（タップやコピペ）を提供する

  • OTP認証について、新しいコード発行まで2分間の猶予を与えることが望ましい

  • USB接続を伴うデバイスを用いた認証について、PCのUSBポートが足りないかもしれない懸念や、USBポートが背面にあって使いにくいかもしれない懸念

  • 生体認証について、指の湿気がセンサーの読取精度に影響するかもしれない懸念

めっちゃ親切…。
そして、ここでは載せませんが、「Figure 3 Usability Considerations Summary by Authenticator Type」には認証タイプごとのユーザビリティ向上策が表形式でまとまっています。

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

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

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