NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（４）

こんにちは、富士榮です。

引き続きNIST SP800-63B-3の同期可能な認証器に関する追補版についてみていきましょう。

今回は実際にインプリメンテーションを行う場合の考慮事項や要求事項についてです。

Implementation Considerations and Requirements

同期可能な認証器は、W3CのWebAuthn仕様に基づいて構築されており、共通のデータ構造、チャレンジ・レスポンス暗号プロトコル、公開鍵認証情報を活用するためのAPIを提供している。この仕様は柔軟で適応性があるため、WebAuthnクレデンシャルのすべてのデプロイが連邦政府機関の実装要件を満たすとは限らない。

この仕様には一連の「フラグ」があり、依拠当事者（RP）アプリケーションは、認証イベ ントの追加コンテキストを提供し、それが RPのアクセス・ポリシーに適合するかどうかを判断す るために、認証者に要求することができる。本節では、RPとして活動する連邦機関が、NIST AAL2 脅威緩和策に適合する同期可能な認証器の実装を構築する際に理解し、問い合わせる必要がある、WebAuthn仕様の特定のフラグについて 説明する。

表2, WebAuthn Level 3 flags

フラグ	説明	要求事項と推奨事項
User Present（UP）	ユーザが認証器と対話したことを確認するための「プレゼンス」テストを示す（例：USBポートに挿入されたハードウェアトークンのタッピング）。	連邦機関は、ユーザ提示フラグが設定されていることを確認しなければならない（SHALL）。認証意図をサポートする。
User Verified（UV）	利用可能な「ユーザー検証」メソッドのいずれかを使用して、ユーザーが認証者によってローカル認証されたことを示す。	連邦機関は、UV が優先されることを示さなければならず（SHALL）、すべてのアサーションは、UV フラグの値を確認するために検査されなければならない（SHALL）。これは、認証器が多要素暗号認証器として扱えるかどうかを示す。ユーザが検証されない場合、機関は、認証イベントに RP 固有の暗記秘密を追加することで、認証器を1要素暗号認証器として扱うことができる。WebAuthn レベル 3 仕様のさらなる拡張により、機関がローカル認証イベントのコンテキストを得ようとする場合、検証方法に関する追加データが提供される。
Backup Eligibility	認証器を別のデバイスに同期できるかどうか（すなわち、鍵を別の場所に保存できるかどうか）を示す。同期可能だからといって、同期済みであることを意味しないことに注意。	連邦機関は、同期可能な認証器の使用を制限するポリシーを確立する場合、このフラグを使用してもよい。このフラグは、デバイスにバインドされる認証子と、複数のデバイスにクローンされる 認証子を区別するために必要である。
Backup State	認証器が別のデバイスに同期されたかどうかを示す。	連邦機関は、他のデバイスに同期された認証器に対する制限を確立する場合、このフラグを使用してもよい。公開アプリケーションの場合、連邦政府機関は、ユーザエクスペリエンス上の懸念から、このフラグに基づいて受諾を変更すべきではない(SHOULD NOT)。企業の判断のために、このフラグは、特定のアプリケーションのために同期可能な 認証器の制限をサポートするために使用してもよい[MAY]。

以前パスキー対応の認証機能を実装した際にも出てきたフラグですね。

https://idmlab.eidentity.jp/2024/02/api.html

同期可能かどうかの判断にはBEやBSを使うわけです。アプリによってはこのフラグを見て同期可能な認証器を受け入れるかどうかを決める、と言うことです。

 

表2に示されるフラグに加えて、機関は、実装および受け入れを選択する同期可能な認証器のオリジンおよび機能について、より詳細な情報を得ることを望むかもしれない。FIDO2 WebAuthn のコンテキストにおいて、認証者の中には、特定の認証者の能力および製造者を 判断するために使用できる認証機能をサポートしているものがある。企業ユースケースの場合、各機関は、プラットフォームプロバイダが提供する機能に基づいて、認証機能を実装するべきである(SHOULD)。好ましくは、RP が認証器に関する一意の識別情報を要求するエンタープライズ認証の形をとる。

構成証明（Attestation)は、広範な公衆向けアプリケーションに使用すべきではない（SHOULD NOT）。このような要件（すなわち、構成証明に対応していない場合、一部の一般ユーザの同期可能な認証器をブロックする要件）は、ユーザをショートメッセージサービス（SMS）のワンタイムパスワード（OTP）のような、フィッシングに脆弱な安全性の低い認証オプションに誘導する可能性がある。

この視点は面白いですね。パブリック（共有端末とかのイメージかな？）なアプリケーションで同期可能な認証器を使うとってしまうまずいので同期可能なクレデンシャルをブロックすると言うポリシーを適用すると、手軽な認証手段を実装しがちになる、という話でしょうか？（@Shiroicaさんご指摘ありがとうございます）

RP がフラグおよび認証データを要求しても、認証器は要求された情報をすべて返さないかもしれないし、リソースへのアクセスに要求される期待応答と矛盾する情報を返すかもしれない。したがって、各機関は、同期可能な認証器を使用するユースケースを評価し、返された情報に基づいて適切なアクセスポリシー決定を行うことが決定的に重要である。

こちらも現実論として全ての認証器がちゃんとフラグを返してくるということは期待してはいけない、ちゃんとリスクを含め評価をしてポリシーを決めようね、ということです。これ非常に大事だと思います。

ということでまだ続きますが、今回はここまでです。