米国時間2024年4月22日に、米国立標準技術研究所（NIST）が、米国の連邦政府機関のシステム向けとしての電子的な本人確認に係るデジタルアイデンティティガイドラインであるNIST SP 800-63の現行版である第3版での、当人認証とその保証レベルについてのパートB（NIST SP 800-63B-3）用の補足文書（原文では「サプリメント」）を公表した[1]。
この補足文書は、複数の端末に同期して安全かつ便利な認証に使える（同期）パスキーといった「同期可能な認証器」（“syncable authenticator”）を、現在有効なNIST SP 800-63B-3に取り込むためとされている。
ちなみにNIST SP 800-63については、2022年12月に次版である第4版のドラフトが公開されている。次版のドラフトについてもNRIセキュアブログにて解説している。
【解説】デジタルアイデンティティガイドライン「NIST SP 800-63」第4版ドラフトはどう変わる？＜全体編＞
【解説】デジタルアイデンティティガイドライン「NIST SP 800-63」第4版ドラフトはどう変わる？＜身元確認編＞
【解説】デジタルアイデンティティガイドライン「NIST SP 800-63」第4版ドラフトはどう変わる？＜当人認証編＞
【解説】デジタルアイデンティティガイドライン「NIST SP 800-63」第4版ドラフトはどう変わる？＜フェデレーション編＞
これまでのNIST SP 800-63B-3では、「多要素暗号ソフトウェア認証器は秘密鍵を複数の端末に複製することを非推奨とするのが望ましく（SHOULD）、かつ行わないこと（SHALL NOT）」と規定されていたため、秘密鍵を異なる端末でも使えるようにする「（同期）パスキー」の利用は米国の連邦政府機関のシステムで認められていなかった。しかし、本補足文書によって、一定の条件下でNISTが定める中段の当人認証保証レベルであるAAL 2の認証手段としてパスキーを利用できるようになった。
なお、パスキーの普及促進に取り組んでいるFIDOアライアンスでは、パスキーを複数の端末間で同期するもの（同期パスキー）と一つの端末から外に出ないもの（デバイス固定パスキー）と区別している[2]。NISTの本補足文書では、FIDOアライアンスが定義する同期パスキーを指して「パスキー」と記述しているように見受けられる。NISTの補足文書の記載を踏襲し、本記事ではFIDOアライアンスでの「同期パスキー」に該当するものを「パスキー」ないし「（同期）パスキー」と記述する。
この記事では、今回公表された補足文書の内容として、パスキーをNISTの認証保証レベル（AAL）2の認証手段として利用できる条件、パスキー以外に新たに加えられた概念や、NISTが憂慮するパスキーの考慮事項や懸念事項などを読み解き、NISTがパスキーをどのように捉えているのかを考察する。
NISTは、今回の補足文書で、同期可能な認証器（（同期）パスキー）を現行のNIST SP 800-63B-3におけるAAL2の認証手段として扱うにあたり、PIN/パスワードや生体認証といった他の認証を行ってからパスキーを使えるようにするローカル認証を必須としている。そのほかに、AAL2での要件に照らし合わせて、適切に実装されたパスキーが各種要件をどのように満たしているかも以下の表の通り説明している。
|
|
要件 |
AAL2での是非 |
同期可能な認証器（パスキーなど）が要件をどのように満たしているか |
|
① |
中間者攻撃への耐性 |
必須 |
要件達成 認証に使うデータを認証済みかつ保護された経路でやり取りしている。 |
|
② |
検証者なりすましへの耐性 |
非必須 |
要件達成 一意の公開・秘密鍵のペアを、生成されたドメインのみで使えるようにしている。 偽のウェブサイトなどが認証器からの出力情報を窃取して再利用することを防いでいる。 |
|
③ |
検証者侵害への耐性 |
非必須 |
要件達成 検証者側には公開鍵のみが保管されている。公開鍵はユーザーとして認証するのには使えない。 シンクファブリック（訳注：パスキーを端末間で同期させる仕組み）に保管された秘密鍵は認定された暗号方法で暗号化されている。当該の保管された鍵にアクセスできるのは認証されたユーザーのみに制限されるようにアクセス管理がなされている。 |
|
④ |
リプレイ攻撃への耐性 |
必須 |
要件達成 毎回の認証処理にランダムなナンスが使われており、リプレイ攻撃への耐性がある。 |
|
⑤ |
認証意思確認 |
推奨 |
要件達成 ユーザーが暗号を用いた認証プロトコルを開始するにあたり、有効化シークレットを入力することを要求している。この要求は認証の意思確認となり、ユーザーが主体的に参画しない限り認証を進められないようにしている。 |
同期可能な認証器（（同期）パスキー）について、一般利用での要件は以下の通り明記されている。
これらの一般利用での要件に加えて、政府機関内部向けシステム（詳細は後述）での追加の要件として以下が挙げられている。
なお、パスキーの認証の技術仕様であるWebAuthnの仕様で定義されているフラグについての要件も本補足で規定されているが、文量の都合上本記事での解説は割愛する。
NISTの今回の補足文書では、同期可能な認証器（（同期）パスキーなど）の脅威と対処方法案も挙げられている。
|
脅威や考慮事項 |
説明 |
同期可能な認証器（（同期）パスキーなど）での対処方法 |
|
許可されていない鍵の利用や、鍵の制御不能 |
誤った利用（悪用）ができる他のユーザー（の端末）に秘密鍵を共有可能な実装 |
• デバイス管理機能や管理プロファイルで鍵の共有を防止 • 鍵の共有が発生したらユーザーに通知 • 鍵の共有状態などを確認できる仕組みをユーザーに提供 • 鍵の許可されていない利用のリスクについてユーザーに注意喚起 |
|
シンクファブリック（訳注：パスキーを端末間で同期などさせる仕組み）の侵害 |
鍵を同期するためにアカウントと紐づく複数の端末とつながったシンクファブリックの存在 |
• 暗号化されたキーマテリアルのみを保管 • 認証されたユーザー以外が秘密鍵にアクセスできないようにシンクファブリックのアクセス管理を実装 • クラウドサービスのセキュリティ基準を評価（FISMAなど） • HSM（ハードウェアセキュリティモジュール）で暗号化された鍵をさらに保護 |
|
シンクファブリックへの許可されていないアクセスとリカバリ |
同期された鍵がクラウドベースのアカウントリカバリ手順でアクセス可能で、リカバリ手法は潜在的な弱点になりえる |
• NIST SP 800-63Bに沿う認証リカバリ手段を実装 • デバイス管理やアカウント管理機能を通してリカバリを制限 • AAL2以上の複数の認証手段をリカバリ用に設定 • シンクファブリックにアクセスできる新たな認証手段を追加させるときは、AAL2以上の認証を要求 • 政府機関内部システムでの利用では（身元確認を行った状態にてさらに追加するような）導出認証手段としてのみ利用 • リカバリ時にはユーザーに通知 • ユーザーのみが管理する要素で鍵の暗号化と復号を実施 |
|
失効 |
同期可能な認証器はRP（訳注：パスキーで認証する先）ごとに異なる鍵を使うため、一括ですべての鍵を失効させることが困難 |
• 出身機関の中央ID管理アカウントで認証器を失効可能にする • SSOとフェデレーションを活用しRP固有の鍵の数を減らす • ユーザーに定期的に鍵の有効性と状態を確認させる |
これらの懸念と対処方法のほかに、認証器自体の機能や出自を検証可能にするアテステーションの活用についても今回の補足文書では言及がなされている。
政府機関内部向けシステムでの利用においては、（米国連邦政府の）機関はプラットフォームプロバイダが提供するアテステーションの機能を実装することが望ましいとされている。また、アテステーションが、認証器について一意に識別される情報をRPが要求する際に使える形になることが理想ともされている。
他方で、公衆向けシステムでは、アテステーションが利用されることは望ましくないとしている（禁止ではなく非推奨）。その理由として、一部ユーザーのアテステーションに対応していない同期可能な認証器の利用を拒否する要件が、当該ユーザーをフィッシングに弱いSMS-OTPといったより脆弱な認証に誘導してしまうことを挙げている。
NISTが挙げるこのような理由は、SMS-OTPといった他の認証手段では認証時のフィッシングの脅威が非常に大きく、認証時にフィッシング耐性のあるパスキーを使ってもらいたいというメッセージが込められているようにも見受けられる。他方、これはアテステーションに対応していない同期可能な認証器（（同期）パスキー）がすでに存在してしまっている現状において、公的なサービスが公衆によるパスキーの利用を制限しないようにという利用者包摂の観点も背景にあることが推測される。
今回の補足文書で他に興味深い点として、パスキーなどの鍵を共有できることについて第7章を丸々割いて記述されていることが挙げられる。
背景として、（同期）パスキーでは同じユーザーの端末間でパスキーを同期できるだけでなく、他のユーザーの端末にも共有できるという事情がある。
政府機関内部向けシステムでの利用においてはユーザーのデバイス管理を行うことで鍵（パスキー）の共有の懸念は低減できるとされている。他方で、公衆向けシステムでの利用においてはデバイス管理のような対処法は現状取れず、組織は利用者の認証器で（パスキーの）共有が起こりえるという前提を置くべきとも推奨している。
なお、共有がなされるというリスクは（同期）パスキー独特のものではなく、すべてのAAL2の認証手段にも適用され、例えばパスワード、OTP、経路外認証、プッシュ認証などであっても、ユーザーが共有しようと思えば共有可能という点もNISTの本補足文書は指摘している。
そのうえで、組織には提供するサービスのリスク、脅威、利便性を踏まえて認証手段を決定してもらうようにとも補足文書には記載されている。
今回のNIST SP 800-63B-3の補足文書により、米国の連邦政府機関でも（同期）パスキーを公式に使えるようになった意義は大きいと考えられる。パスキーの利用が進み、認証時のフィッシングが減ることも期待される。
他方で、同期や共有ができるという利便性に伴う考慮事項も存在することは事実で、NIST SP 800-63自体と本補足文書が米国の連邦政府機関内向けのガイドラインという背景を踏まえつつ、日本の組織においてもNISTが挙げたような対処法を参考にして（同期）パスキーの活用を進めることは考えられる。
また、NIST SP 800-63全体としては、パスキー以外に“Public identity”と“Public-facing applications”、“Federal enterprise identity”と“Enterprise-facing applications”の概念が、次に公表されうるNIST SP 800-63-4の2つ目のドラフトとしてパートBの当人認証以外にもパートAの身元確認やパートCのフェデレーションにどのように取り込まれるかも注視したい。
[1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63Bsup1.pdf
[2] https://fidoalliance.org/passkeys/?lang=ja
[3] https://www.w3.org/TR/webauthn-3/#attestation
[4] https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf