【解説】デジタルアイデンティティガイドライン「NIST SP 800-63B-3」にパスキーが登場

米国時間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がパスキーをどのように捉えているのかを考察する。

事例で語る！内部不正対策のポイントとは ～すぐ導入できるアクセス制御・ログ取得ツールを紹介～

2024年5月23日(木) 11:00開催ウェビナー

パスキーが一定条件下でAAL2に適合

NISTは、今回の補足文書で、同期可能な認証器（（同期）パスキー）を現行のNIST SP 800-63B-3におけるAAL2の認証手段として扱うにあたり、PIN/パスワードや生体認証といった他の認証を行ってからパスキーを使えるようにするローカル認証を必須としている。そのほかに、AAL2での要件に照らし合わせて、適切に実装されたパスキーが各種要件をどのように満たしているかも以下の表の通り説明している。

NISTが示す適切に実装されたパスキーによるAAL2を満たす箇所の概観像

同期可能な認証器（（同期）パスキー）について、一般利用での要件は以下の通り明記されている。

• 秘密鍵（パスキー）を使えるようにするためのローカル認証（必須）
• すべての鍵の認定された暗号技術の利用（必須）
• 端末から複製やエクスポートされる秘密鍵を暗号化された状態に置く（必須）
• すべての認証処理をローカルの端末上で秘密鍵を用いて実施（必須）
• クラウドベースのアカウントに秘密鍵が保管されている場合は、認証されたユーザーのみが秘密鍵にアクセスできるようなアクセス管理のメカニズムで保護（必須）
• 秘密鍵にアクセスできるユーザーはAAL2と同等の多要素認証が用いられて、秘密鍵を用いた認証のプロトコルの完全性を確保（必須）
• これらの一般的な要件や組織ごとの要件がすべて文書化かつ共有されている（必須）

これらの一般利用での要件に加えて、政府機関内部向けシステム（詳細は後述）での追加の要件として以下が挙げられている。

• FISMA（米国連邦政府情報セキュリティ管理法）の中程度ないしそれと同等の手法で、同期する仕組み上にある秘密鍵を保護（必須）
• 秘密鍵を生成、保管、同期する端末はMDM（モバイル端末管理）ないし他の端末管理手法を用いて、許可されていない端末や同期する仕組みへの鍵の同期や共有から保護（必須）
• 組織が秘密鍵のライフサイクルを管理するために、鍵を同期する仕組みへのアクセスを組織が管理するアカウントによって管理（必須）
• 秘密鍵を生成する認証器は、認証器自体の機能や出自を検証可能にするためのアテステーション（W3Cによるウェブ認証技術の標準仕様であるWebAuthn仕様において、認証器の出自を検証可能な形で証明する情報^[3]）の仕組みを具備（推奨）

なお、パスキーの認証の技術仕様であるWebAuthnの仕様で定義されているフラグについての要件も本補足で規定されているが、文量の都合上本記事での解説は割愛する。

【コラム】公衆向けシステムと内部向けシステムという新たな概念

• 本補足文書で、（同期）パスキーをAAL2の認証手段として許容する条件が加えられた以外に、今までのNIST SP 800-63に存在しなかった“Public-facing applications”と“Enterprise-facing applications”という二つの新たな概念も加えられた。
•  
• “Public-facing applications”と“Enterprise-facing applications”の概念は、2019年5月21日に米国行政管理予算局（OMB）による『改善されたアイデンティティ、クレデンシャル、アクセス管理を通したミッション遂行のための覚書』（OMB M-19-17^[4]）で定義された“Public identity”と“Federal-enterprise identity”の概念が踏まえられている。
•  
• 今回のNIST SP 800-63B-3の補足文書において、“Public-facing applications”は“Public identity”に係る米国連邦政府の情報システムとされている。OMB M-19-17において“Public identity”は、米国連邦政府機関が直接管理せずとも、ミッションやビジネスの目標を達成するために米国連邦政府機関が係る対象を指している。
• ここから、“Public-facing applications”は米国連邦政府機関が直接的に管理しない対象向けのシステムと解釈できる。
• このようなシステムは、米国連邦政府機関が市民向けに提供するサービス（例えば日本の国税庁に相当する米国内国歳入庁の確定申告用のウェブサイトなど）が想定される。原文の英単語も踏まえ、本記事では当該のシステムを「公衆向けシステム」とする。
•  
• 他方で“Enterprise-facing applications”は主に“Federal enterprise identity”に係る米国連邦政府の情報システムとされている。“Federal enterprise identity”は米国連邦政府機関がミッションとビジネスの目標を達成するために管理する従業員、請負業者、ミッションやビジネスパートナー、端末、技術といった対象を指している。
• ここから、“Federal-facing applications”は米国連邦政府機関が直接管理する対象向けのシステムで、政府機関内部用のものと解釈できる。こちらのシステムを本記事では「政府機関内部向けシステム」とする。
•  
• なお、“Public identity”と“Public-facing applications”、“Federal enterprise identity”と“Enterprise-facing applications”の概念はこれまでのNIST SP 800-63-3や、2022年12月に公表されたNIST SP 800-63-4の一つ目のドラフトの中には強調された記述がない。これらの概念が、NIST SP 800-63-4の次のドラフトや最終版で、パスキー以外の箇所にも含められるのか注視が必要と考えられる。

NISTが思慮する（同期）パスキーの考慮事項と対処方法案

NISTの今回の補足文書では、同期可能な認証器（（同期）パスキーなど）の脅威と対処方法案も挙げられている。

これらの懸念と対処方法のほかに、認証器自体の機能や出自を検証可能にするアテステーションの活用についても今回の補足文書では言及がなされている。

政府機関内部向けシステムでの利用においては、（米国連邦政府の）機関はプラットフォームプロバイダが提供するアテステーションの機能を実装することが望ましいとされている。また、アテステーションが、認証器について一意に識別される情報を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