NIST SP 800-63-4のドラフトの主要な変更事項を読み解く全4回の連載、第3回目はSP 800-63B「デジタルアイデンティティの当人認証とその保証レベル」を取り上げます。NIST SP 800-63の概要については第1回全体編をご覧ください。
本連載の関連記事はこちら
【解説】デジタルアイデンティティガイドライン「NIST SP 800-63」第4版ドラフトはどう変わる？＜全体編＞
【解説】デジタルアイデンティティガイドライン「NIST SP 800-63」第4版ドラフトはどう変わる？＜身元確認編＞
【解説】デジタルアイデンティティガイドライン「NIST SP 800-63」第4版ドラフトはどう変わる？＜フェデレーション編＞
▶「大規模ユーザを管理する顧客ID統合プロジェクト成功の秘訣」をダウンロードする
NIST SP 800-63B 「デジタルアイデンティティの当人認証とその保証レベル」とは
NIST SP 800-63Bは4つの文書で構成されているNIST SP 800-63のうち、デジタルアイデンティティにおける認証について記載されている文書です。本文書では3つの認証保証レベル（AAL）が定義されており、それぞれのAALにおけるリモートユーザ認証の為のクレデンシャル・サービス・プロバイダ（CSP）に対する要件について記載されています。
NIST SP 800-63B-4のドラフトでの章立ての変更点
まずは全体を俯瞰するために章立てから変更点を見ていきましょう。NIST SP 800-63B-3とNIST SP 800-63B-4ドラフトのそれぞれで、同じような内容についての箇所は同列に配置しています。また、表に色を付けて示しているのは項目自体が無くなったり追加されたり、項目名が変更されたりした箇所です。
章立てで見ると、 NIST SP 800-63B-4ドラフトでは、第11章（権利に関する考慮事項）の内容が追加された程度で全体的に大きな変更はありませんが、各章の要件は細かい変更がされています。
NIST SP 800-63B-4の第3版と第4版の章立ての比較
NIST SP 800-63B-4のドラフトの項目の変更点
全体像を俯瞰した上で、各項目の中身を見ていきます。全ての項目の変化事項を記載しきれないため、ここでは主要かつ重要な箇所として、2章・4章・5章を取り上げていきます。
第2章（イントロダクション）
第4版ドラフトでは、AALの名前が「Authenticator Assurance Level」から「Authentication Assurance Level」へ変更となりました。また、配慮すべき事項として公平性（Equity）に関する事項が追加されている点が変更点です。
またAALの各レベルの定義は第3版から変更されていないですが、以下の通りです。
- AAL1
幅広く利用可能な認証技術を利用して、単一要素または多要素による認証が必要です。 - AAL2
セキュアな認証プロトコルを介した二要素による認証が必要です。また、AAL2以上では承認された暗号技術を利用する必要があります。 - AAL3
セキュアな認証プロトコルを介した二要素による認証が必要で、認証器についてはハードウェアベースの認証器またはフィッシング耐性のある認証器が必要です。また、AAL2同様に承認された暗号技術を利用する必要があります。
第4章（認証保証レベル”AAL”）
第4章では各AALに対して求められる要件についてまとめられています。第4版ドラフトでは、AAL2で許可されている認証機器のタイプとして多要素経路外デバイスが追加され、また、中間者攻撃の呼称が"Man in the Middle"から"Attacker in the Middle"と変更されました。
更に、AAL2においてはフィッシング耐性のある認証器の利用を推奨する方針とされました。第3版では、AAL2でのフィッシング耐性のある認証器の利用については記載されていませんでした。フィッシング攻撃は世界的に増加傾向にあるため、第3版よりも耐性について具体的に標記するようにした意図があると考えられます。
各AALの要件は上記以外に変更はありません。各AALの要件を表に示します。
| 要件 | AAL1 | AAL2 | AAL3 |
| 許可されている認証器のタイプ（4.1.1.、4.2.1.、4.3.1.） | ・記憶シークレット ・ルックアップシークレット ・経路外デバイス ・単一要素OTPデバイス ・多要素OTPデバイス ・単一要素暗号ソフトウェア ・単一要素暗号デバイス ・多要素暗号ソフトウェア ・多要素暗号デバイス |
・多要素経路外デバイス ・多要素OTPデバイス ・多要素暗号ソフトウェア ・多要素暗号デバイス ・記憶シークレット +以下のいずれか1つ ・ルックアップシークレット ・経路外デバイス ・単一要素OTPデバイス ・単一要素暗号ソフトウェア ・単一要素暗号デバイス |
・多要素暗号デバイス ・単一要素暗号デバイス+記憶シークレット ・単一要素OTPデバイス+多要素暗号デバイスorソフトウェア ・単一要素OTPデバイス+単一要素暗号ソフトウェア+記憶シークレット |
| FIPS140適合 （4.1.2.、4.2.2.、4.3.2.） |
Level 1 (政府機関の検証者) | Level 1 (政府機関の認証器及び検証者) | Level 1 総合 (検証者及び単一要素暗号デバイス) Level 2 総合 (多要素認証器) Level 3 物理セキュリティ (全ての認証器) |
| AitM（中間者攻撃）耐性 （4.1.2.、4.2.2.、4.3.2.） |
必須 | 必須 | 必須 |
| フィッシング耐性 （4.1.2.、4.2.2.、4.3.2.） |
不要 | 推奨 | 必須 |
| 検証者改竄耐性 （4.1.2.、4.2.2.、4.3.2.） |
不要 | 不要 | 必須 |
| リプレイ耐性 （4.1.2.、4.2.2.、4.3.2.） |
不要 | 必須 | 必須 |
| 認証意図 （4.1.2.、4.2.2.、4.3.2.） |
不要 | 推奨 | 必須 |
| 再認証の期間 （4.1.3.、4.2.3.、4.3.3.） |
ユーザのアクティブ状況に関係無く30日に1度再認証 | ユーザのアクティブ状況に関係無く12時間に1度、または30分非アクティブであった場合、1つの認証要素を利用した再認証 | ユーザのアクティブ状況に関係無く12時間に1度、または15分非アクティブであった場合、両方の認証要素を利用して再認証 |
| セキュリティコントロール （4.1.4.、4.2.4.、4.3.4.） |
[SP800-53]の低い基準（またはそれと同等のもの） | [SP800-53]の中度の基準（またはそれと同等のもの） | [SP800-53]の高い基準（またはそれと同等のもの） |
許可されている認証器のタイプ（4.1.1.、4.2.1.、4.3.1.）の詳細については第5章で解説します。
第5章（認証器と検証者の要件）
第5章では各認証器と検証に対して求められる要件についてまとめられています。まず、各認証器の概要を表に示します。
| 認証器のタイプ | 概要 |
| 記憶シークレット Memorized Secrets |
知識要素 ユーザが記憶する秘密の値 例：パスワードやPIN |
|
ルックアップシークレット Look-Up Secrets |
所有要素 認証要求者とCSPの間で共有される一連のシークレットを格納する物理的または電子的な記録 例：乱数表 |
| 経路外デバイス Out-of-Band Devices |
所有要素 一意にアドレスの指定が可能で、セカンダリチャネルと呼ばれる通信チャネルを介して検証者と安全に通信出来る物理デバイス 例：SMSによるコードの送信、表示されたQRコードの読み取り |
| 単一要素OTPデバイス Single-Factor OTP Device |
所有要素 ワンタイムパスワード（OTP）を生成するデバイス 例：スマートフォンにインストールされたOTPアプリケーション（Google Authenticatorなど） |
| 多要素OTPデバイス Multi-Factor OTP Devices |
所有要素 +知識要素 or 生体要素 単一要素OTPデバイスに更に二要素目（知識要素か生体要素）によるアクティベーションを追加したもの 例：スマートフォンのTouch IDやパスワードでアクティベーションされるOTPアプリケーション |
|
単一要素暗号ソフトウェア Single-Factor Cryptographic Software |
所有要素 ディスク上またはその他のソフトに記録された暗号鍵 例：端末毎のクライアント証明書（PW保護無し） |
| 単一要素暗号デバイス Single-Factor Cryptographic Devices |
所有要素 保護された暗号鍵を用いて認証を行うデバイス 例：FIDO U2FのUSBドングル |
| 多要素暗号ソフトウェア Multi-Factor Cryptographic Software |
所有要素 +知識要素 or 生体要素 単一要素暗号ソフトウェアに更に二要素目（知識要素か生体要素）によるアクティベーションを追加したもの 例：指紋認証を行うことで有効化されるクライアント証明書 |
| 多要素暗号デバイス Multi-Factor Cryptographic Devices |
所有要素 +知識要素 or 生体要素 単一要素暗号デバイスに更に二要素目（知識要素か生体要素）によるアクティベーションを追加したもの 例：指紋認証を行うことで有効化されるFIDO U2FのUSBドングル |
各認証器の概要は第3版の内容から変更はありませんが、詳細では変更点がありますので、それぞれの各認証器の変更点について見ていきます。
5.1.1.（記憶シークレット）
5.1.1.1.（記憶シークレット認証器）では、記憶シークレットを加入者へCSPがランダムに割り当てるような場合は、第3版では最低6文字かつ数字のみでも良いとされていましたが、第4版ドラフトでは最低8文字とする要件に変更になっています。補足ですが、加入者が記憶シークレットを設定する場合は、最低8文字とする要件は変更されておりません。
そして、5.1.1.2.（記憶シークレットの検証）では、タイプミスに関する考慮事項の内容が変更され、更にブロックリストに関する内容が追加されています。タイプミスに関する考慮事項として、第3版では、検証者が記憶シークレットを検証する前に、連続するスペースを一つのスペースに置換し検証してよいと記載されておりましたが、第4版ドラフトでは記憶シークレットの検証前について以下のように記載されています。
- 記憶シークレットの先頭と末尾にあるスペースの削除をしてもよい
- 記憶シークレットの先頭文字の大文字と小文字の違いを許容してもよい
ブロックリストに関しては、記憶シークレットが攻撃者によって推測され、侵入されるような攻撃を防ぐ目的で、ブロックリストを作成し、記憶シークレットと比較したほうが良い事が記載されました。ブロックリストを利用する事で、例えばパスワードを登録する際に、加入者が攻撃者に推測されやすい脆弱なパスワードを登録する事を防ぐことが出来ます。ブロックリストの例は以下の通りです。
- 侵害事例から得られた値
- 辞書の単語
- 反復または連続した文字（例：aaaaaa,1234abcd）
- サービス名、ユーザ名など
また、ブロックリストを作成する際は十分なサイズにする必要があるものの、過度に大きいサイズにする必要は無いとしています。これは、過度に大きいサイズのBlocklistによって許容される記憶シークレットが少なくなり、かえってセキュリティ強度が低下する為です。
5.1.1.2.では更に、一部の記載内容が”should/should not（～すべき/しないべきである。※推奨）”から”shall/shall not（～するもの/しないものとする。※必須）”に変更となりました。記載内容が変更になった点は以下の通りです。
- 検証者は、加入者が強力な記憶シークレットを選択する為のガイダンスの提供を行う
- 検証者は、以下を加入者に求めない
①記憶シークレットの構成規則
（異なる文字種の混在を要求する、連続して繰り返される文字を禁止するなど）
②記憶シークレットの定期変更
※認証器が危殆化した証拠がある場合、変更を強制するものとする
最後に、記憶シークレットを保持する際の、パスワードハッシュ関数の選択についても二点変更がありました。一点目は、鍵導出関数※1の要件についてです。第3版では、メモリーハード※2である鍵導出関数を選択する必要がある記載でしたが、第4版ドラフトではコンピュートハード※3も満たす鍵導出関数を選択する必要があるとの記載に変更されています。
二点目は一点目の記載の変更に伴い、選択する鍵導出関数の例が変更されました。第3版では、PBKDF2、Balloonが例として記載されていたのに対し、第4版ドラフトではArgon2、scryptが例として記載されました。
※1：パスワードから共通鍵暗号用の鍵を生成する関数ですが、パスワードハッシュ関数としても利用されており、本要件内では後者の関数の意味合いです。
※2：メモリーハードとは、解読をする為に大量のメモリーを消費するような関数を指します。
※3：コンピュートハードとは、効率的に解読を行えるアルゴリズムが無く、現状解読の計算が困難な関数を指します。
5.1.3.（経路外デバイス）
第3版では、経路外デバイスを利用した認証方法は3パターンありましたが、第4版ドラフトでは2パターンになりました。採用されなくなった方法は以下の方法です。
- プライマリチャネルと、セカンダリチャネルで受信したシークレットを比較し、セカンダリチャネルを利用して認証する
上記の認証方法は実装されることが稀であり、受け入れられる方法ではない為、第4版ドラフトのタイミングで採用されなくなっています。さらに、当該方法は実際にシークレットを比較せずに認証してしまう恐れがあったという理由と、関連してプッシュ通知だけを認証器に送ってボタンを押させるような方法は経路外デバイスの要件を満たさないとも明記されました。
また、第4版ドラフトには記載がされておりませんが、この認証方法は、昨年度特に流行っていたMFA Fatigue Attack※４に対して脆弱であった、という点も不採用となった理由の内の一つでは無いかと推測しております。
※４：日本語の場合、多要素認証（MFA）疲労攻撃と呼ばれることが多いです。被害者のデバイスに大量の二要素認証通知を出させ疲労させることで、被害者のデバイスによる承認を促すような攻撃になります。
ちなみに、採用されている2パターンは以下の通りです。
１．経路外デバイスによってセカンダリチャネルで受信したシークレットを、プライマリチャネルを利用して送信して認証する方法
以下の図では、左下のPCを利用してサービスへ認証しようとしており、経路外デバイスであるスマートフォンのアプリケーションでコードを表示させ、PCでそのコードを入力し認証しています。
２．プライマリチャネルで受信したシークレットを経路外デバイスによってセカンダリチャネルを利用して送信して認証する方法
以下の図では、左下のPCを利用してサービスへ認証しようとしており、PCでコードを表示させ、経路外デバイスであるスマートフォンのアプリケーションでそのコードを入力し認証しています。
5.1.3.1.（経路外認証器）では、電子メールを利用した経路外認証は無効である記載が第3版から引き続き記載されました。電子メールは特定の経路外デバイスの所有を証明することはできないことに加えて、電子メールへのアクセスは一般的に記憶シークレットだけで可能な為と理由が追加で記載されました。
5.1.3.2.（経路外検証）では、CSPが5.1.3.4.（多要素外部経路認証器）の要件を満たさない限り、経路外認証は単一要素認証とみなす事になる記載が追加されました。更に、経路外認証器にプッシュ通知を利用してシークレットを送信するような実装の場合、認証に成功した後に送信されるプッシュ通知に制限を実装する必要があるとの記載も追加されました。
5.1.3.3.（公衆公開電話網を利用した認証）では、公衆公開電話網を利用することが出来ないユーザへの配慮事項が追記されています。具体的には、公衆公開電話網を利用した経路外認証を行う場合、公衆公開電話網を利用することが出来ないユーザがいる可能性を考慮して、代替の認証器を利用できるようにする必要があり、このような制約について事前にユーザへ通知する必要があると記載されています。
5.1.3.4.（多要素経路外認証器）では、経路外認証を多要素認証とみなす為の要件が追加されました。多要素認証とみなす場合はまず、認証器の利用の度に、認証器のアクティベーションを行う必要があり、アクティベーションシークレットを利用する場合は、5.2.11.（アクティベーションシークレット）を、生体認証によるアクティベーションを行う場合は認証の連続失敗回数の制限も含めて5.2.3.（生体認証の利用）の要件をそれぞれ満たす必要があります。
そして、アクティベーションを行う場合は認証器自体（スマートフォンなど）のロック解除とは別の操作で行う必要があります。この際、アクティベーションする為の要素は、認証機器自体のロック解除に利用した情報（指紋認証や顔認証など）を利用して問題ありません。
5.1.4.（単一要素OTPデバイス）
5.1.4.1.（単一要素OTP認証器）では、単一要素OTPデバイスの利用を変更する際の要件が追加されました。単一要素OTP認証機器として使用する、Google AuthenticatorなどのOTP生成アプリケーションがインストールされたスマートフォンなどのデバイスを変更する場合、変更したデバイスのみで単一要素OTP認証機器を有効とし、変更前のデバイスでは無効化する必要があります。
5.1.4.2.（単一要素OTP 検証）では、OTPが重複利用された場合に関する要件が追加されました。OTPが重複利用され、認証要求者の認証が拒否された場合、検証者は攻撃者が既に認証できている場合に備えて認証要求者へ警告をしてもよくなりました。また、OTPの重複利用が確認された場合、既に認証しているユーザへも警告をしてよくなりました。
5.1.5.（多要素OTPデバイス）
5.1.5.1.（多要素OTP認証器）では、5.1.4.1.（単一要素OTP認証器）と同様の内容で、多要素OTPデバイスの利用を変更する際の要件が追加されました。
5.1.6.（単一要素暗号ソフトウェア）
5.1.6.1.（単一要素暗号ソフトウェア認証器）では、秘密鍵を取り出すことの出来る仕様を有しているような、暗号ハードウェア認証器の要件を満たしていない外付けの暗号認証器（秘密鍵を取り出すことの出来る仕様のものなど）も、単一要素暗号ソフトウェア認証器と見なされるようになりました。
FIDO認証において認証器に保存された資格情報（秘密鍵）を、複数の認証器で同期する仕組み（同期可能なパスキー）が提案されたことが関係していると推察します。
FIDO認証では、以前は秘密鍵を認証器から取り出すことができない前提でしたが、同期可能なパスキーによって、認証器から取り出すことが出来るようになっており、直近の技術動向を反映しているのではないでしょうか。
5.1.8.（多要素暗号ソフトウェア）
5.1.8.1.（多要素暗号ソフトウェア認証器）では、5.1.6.1.（単一要素暗号ソフトウェア認証器）と同様の内容で、秘密鍵のエクスポートを許可する仕様を有しているような、暗号ハードウェア認証器の要件を満たしていない外付けの暗号認証器も、暗号ソフトウェア認証器と見なされるようになりました。ただし、これらの認証器は5.2.12（接続された認証器）の要件を満たしている必要があります。
また、認証の度に認証器をアクティベートする必要がありますが、アクティベーション方法は5.1.3.4.（多要素経路外認証器）と同様の内容です。
5.1.9.（多要素暗号デバイス）
基本的に第3版と内容は同等ですが、認証前の認証器のアクティベーションに関する記述が5.1.3.4.（多要素経路外認証器）と同様の記載に変更されました。
各認証器のタイプで、第3版から第4版ドラフトにかけて要件が変更となった点は以上です。記憶シークレットの要件については、シークレットの長さに関する記述が必ず8文字以上に統一されていたり、第3版で必須としなかった記述が必須とするようになったりと、より厳格な要件となりました。
続いて、5.2.（一般的な認証器の要件）について第3版との変更点を見ていきます。
5.2.1.（物理的な認証器)
本要件では、認証器を紛失や盗難した場合の対応について記載されています。このような場合に、CSPは認証器を失効させる、または一時停止させるように第3版では記載されていましたが、第4版ドラフトでは認よりシンプルに、認証器を無効化するよう求めるようになりました。
5.2.2.（レート制限”スロットリング”）
本要件では、攻撃者によるパスワード推測のような攻撃を対策する為の制御の実装（認証の連続失敗数の制限など）について記載されています。本要件では内容に変更はありませんが、第3版ではCAPTCHAを導入してもよいと記載されておりましたが、第4版ドラフトではCAPTCHAという単語から” a bot detection and mitigation challenge（ボットの検出と緩和のチャレンジ）”という単語に変更されています。
botの対策についてはCAPTCHA以外にもWAFやbot攻撃対策ソリューションの導入といった方法もある為、第4版ドラフトでは広義な表現にしたのではないかと推測しています。
5.2.3.（生体認証の利用）
本要件では、新たに公平性に関する考慮事項が記載されました。内容は以下の通りです。
- バイオメトリクス認証技術は、異なる人口統計学的タイプ（人種的背景、性別、民族性など）の加入者 に対しても、同様の性能を提供しなければならない
5.2.5.（フィッシング）
本要件では、”Verifier impersonation attacks（検証者なりすまし攻撃）”から” Phishing attacks（フィッシング攻撃）”と、攻撃名に変更があり、どのような攻撃かイメージがしやすくなりました。
また、加入者がフィッシング攻撃に対して耐性があると判断できるのは、加入者の利用する認証手段全てにフィッシング耐性がある場合のみであるとの記載が新たに追加されました。更に、フィッシング攻撃に対する対策として新たに、5.2.5.1.（チャネルバインディング）と5.2.5.2.（検証者名前バインディング）という2つの方法に関する記載が追加されました。
1つ目の方法である5.2.5.1.（チャネルバインディング）のチャネルバインディングとは、認証器と検証者間の通信チャネルの事を指しています。チャネルバインディングを利用するプロトコルとして、第4版ドラフトではクライアント認証プロトコルを推奨しています。
クライアント認証プロトコルとは、例としてmutual-TLS（相互認証）が挙げられます。HTTPS等の通常のTLSでは、クライアントがサーバの証明書を検証しますが、mutual-TLSではサーバ検証に加えて、サーバからクライアントの証明書を検証するような、相互の検証を行います。
もう一つの方法である5.2.5.2.（検証者名前バインディング）の検証者名前バインディングとは、具体的に本章にどのような方式か記載がありませんが、利用する認証器に予め検証者のドメインを登録させておき、登録されたドメインのみ認証プロセスを生成するような方式であると推測されます。
5.2.11.（アクティベーションシークレット）
本要件は、第4版ドラフトで新しく追加された項目です。アクティベーションシークレットとは、多要素認証器のアクティベーション要素として使用される記憶シークレットの事です。
アクティベーションシークレットはFIDOでも利用されるもので、FIDOの普及に向けて要件を具体化したのでは無いかと推測しています。アクティベーションシークレットに関する要件を以下の表に示します。5.1.1.（記憶シークレット）の要件と異なりますので、アクティベーションシークレットを利用する場合は注意して下さい。
|
要件 |
内容 |
|
長さに関する要件 |
6文字以上とする |
|
文字種に関する要件 |
・PIN（すべて数字）であってもよい ・英数字の値が許可されている場合は、すべての表示可能なASCII文字と空白文字を受け入れる必要がある |
|
ブロックリストに関する要件 |
よく使用される値を10個以上登録することとする |
|
入力による失敗数 |
認証器で連続して失敗して良い回数は10回までとし、上限に達した場合、その認証器は無効化されることとする。その場合、別の認証器を利用することとする |
|
レート制限について |
・正しくないアクティベーションシークレットの入力により、認証器が無効な値を検証者へ送信する場合、検証者側でレート制限してもよい ・上記以外の場合は認証器でレート制限することとする |
|
その他 |
・アクティベーションシークレットを暗号鍵の複合に利用するケース以外では、検証は、ハードウェアベースの認証器内か、TEEやTPMのようなセキュアハードウェア内で実行されるものとする |
5.2.12.（接続された認証器）
暗号認証器に関する新規の要件です。まず、暗号認証器（例：FIDO U2FのUSBドングル）は認証対象のエンドポイント（例：PC）と直接接続されている必要があります。
接続方法は、有線（USB等）か無線（Bluetooth等）のどちらでも認められています。ただし、無線で接続する場合、盗聴や中間者攻撃の恐れがありますので、対策が必要です。
無線接続では、無線の有効範囲によって要件が変わります。まず、1m以上の有効範囲での動作が保証されている認証器の場合、認証器とエンドポイント間の通信は暗号化して接続することとします。この暗号化通信を行う為に、認証器とエンドポイントをペアリングする必要があり、このペアリングのプロセスで鍵を生成することとします。もしくは、一時的に有線接続をしてペアリングしてもよいです。
ここで、ペアリングコードについては、20bit以上か、10進数で6桁以上のエントロピーを有することとします。入力方法は手動入力か、QRコードのような光学的に伝達される提示方法を利用することとします。認証のトランザクションには、ペアリングのプロセスによって生成された鍵を利用して暗号化することとします。
次に、1m未満の有効範囲での動作が保証されている認証器で、エンドポイントから認証器へアクティベーションシークレットを送信する場合は、ペアリングプロセスか一時的な有線接続で生成された鍵を利用してアクティベーションシークレットを暗号化することとします。
ペアリングプロセスで生成された鍵は、永続的に有効であっても良いです。ただし、永続的に有効な場合、鍵を削除することの出来る機能を実装しておく必要があります。また、無線接続の有効範囲に関係なく、暗号化には承認された暗号技術を採用する必要があります。
NIST SP 800-63B-4のドラフトの変更点を踏まえて
第3版と比較して、大きく変更点のあった要件はありませんでしたが、FIDOの普及を目指しての変更と思われる以下のような点がありました。
- 複数の認証器で秘密鍵を同期可能なパスキーの技術動向が反映された（5.1.6. 単一要素暗号ソフトウェア）
- FIDOでも利用するアクティベーションシークレットについて、記憶シークレットとは別として定義された（5.2.11. アクティベーションシークレット）
パスキー利用は以下のような課題が挙げられるため、正式版の発行までに課題解決の為に認証器に関する要件の変更が発生する可能性が考えられます。
- 同期可能なパスキーでは、サービス認証のセキュリティ強度が、パスキー保管先の認証強度に依存する
- なりすまし被害を受けた際の、パスキーの無効化と再登録の難易度が高い
- パスキー保管先を失った場合などには、パスキーの利用が出来ず、利用者がサービスのアカウントを復旧することが困難になる可能性がある
また、記憶シークレットの要件では、ユーザへ複雑さの要件や定期変更の要件を課さないことが推奨から必須へ変更となり、今後他のガイドラインにも波及する可能性が考えられます。
次回は、第4回目として認証連携について読み解いていきます。
NRIセキュアは今回取り上げたようなデジタルアイデンティティガイドラインを含む様々なガイドラインや各種標準仕様の内容も踏まえ、サービスに必要な認証レベル等に関するコンサルティングや実際のシステムのユーザ認証方式等の設計レビューのご支援を行っております。また、自社開発のコンシューマ向けID管理製品「Uni-ID Libra」や多要素認証エンジン「Uni-ID MFA」等のソリューションのご提供も可能ですので、お気軽にご相談ください。
