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

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

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

Entra IDの外部認証プロバイダの利用機能がPreview公開されています

Entra IDで外部の認証手段が使えるようになったようです。

https://techcommunity.microsoft.com/t5/microsoft-entra-blog/public-preview-external-authentication-methods-in-microsoft/ba-p/4078808

むかーし、3rdパーティの多要素認証プロバイダの設定を行う機能が一瞬出て消えていったものの後継ですね。当時はPremium P2ライセンスが必要でDuoやRSA、Trusonaなどプリセットされたものを認証プロバイダとして利用することができました。

当時の記録

https://idmlab.eidentity.jp/2018/02/azure-adduo-security3rd.html

まぁ、中身はid_token_hintを使ってIdPをチェインさせているだけだった気がしますが、当時はあんまり流行らなかったんですかね・・・。

今回のアナウンスとドキュメントを見ているとやはりid_token_hintを使った認証状態の引き回しとチェインであることには変わらなさそうですが、より柔軟に構成を行うことができるようになっていますね。ライセンスもPremium P1でOKっぽいですし。

ということで私のテナントでも機能が有効になったのでおいおい試してみたいと思います。

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

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

前回に引き続きNIST SP800-63-3の追補版を見ていきます。

だいぶ中身に入ってきました。
早速読んでいきます。

Updates on the Allowance of Cloning Authentication Keys

SP 800-63B のセクション 5.1.8.1「多要素暗号化ソフトウェア認証機能」は、認証器があるデバイスから別のデバイスへ暗号化認証鍵を「クローン」することを制限している。具体的には、以下のとおりである：

多要素暗号化ソフトウェア認証器は、複数のデバイスへの秘密鍵のクローニングを抑制すべきであり、促進してはならない（SHALL NOT）。

同期可能な認証器は、デバイスや異なるプラットフォーム・プロバイダにまたがって、以前に 登録した認証器へのアクセスをユーザに提供するため、明示的に鍵の複製を促進する。NISTがSP 800-63B-4の初期公開草案(ipd)からこの制限を削除したことで、この現実が認識された。本文書の発行時点で、5.1.8.1 項の上記の記述は、本補足により置き換えられ、本補足に規定される要件に基 づいて導入される同期可能な認証器は、AAL2 で想定される脅威から保護するのに十分であるとみなされるものとする。

そうです、元々のSP 800-63Bでは秘密鍵のクローニングを制限していたわけです。今回の更新でこの点について緩和が行われたわけです。

ただ、そのために満たすべき要件を以下の通り定義しています。

同期可能な認証器のすべての使用に関する一般要件：

• すべての鍵は、承認された暗号技術を用いて生成されなければならない。
• デバイスからクローンまたはエクスポートされた秘密鍵は、暗号化された形式でのみ保存されるものとする。
• すべての認証トランザクションは、デバイス上で生成された、または同期ファブリック（クラウドストレージ など）から復元された暗号鍵を使用して、ローカル・デバイス上で秘密鍵操作を実行しなければならな い。
• クラウドベースのアカウントに保存された秘密鍵は、認証されたユーザのみがシンクファブリック内の秘密鍵にアクセスできるよう、アクセス制御メカニズムによって保護されなければならない。
• 同期ファブリック内の秘密鍵へのユーザ・アクセスは、同期された鍵を使用する認証プロトコルの完全性を保持するために、AAL2相当のMFAによって保護されなければならない。
• これらの一般的要件および同期可能な認証器の使用に関するその他の機関固有の要件は、文書化し、公開ウェブサイトおよびデジタル・サービス・ポリシー（該当する場合）を含め、周知されるも のとする。

ちゃんと認定された暗号技術を使うこと、同期された鍵を使って認証に必要な操作を行う場合はローカルで操作を行うこと（要するにリモート署名なんかはNGってことですね）、秘密鍵へのアクセス制御を行うこと、具体的にはAAL2相当の認証強度で保護されていること、同期可能な認証器を使っていることをポリシーとして公開・周知すること、が記載されています。要は、同期してもいいけどちゃんと認められた方法で管理し、その旨を周知せよ、ということですね。

また、追加要件として以下のについても定義されています。 

連邦企業が同期可能な認証器を使用するための追加要件： 

• 連邦企業の秘密鍵（すなわち、連邦鍵）は、FISMA Moderateの保護または同等の保護を達成した同期ファブリックに保管しなければならない。
• 連邦企業の秘密鍵を含む認証器を生成、保管、同期するデバイス（携帯電話、ノート型パソコン、タブレットなど）は、モバイル・デバイス管理ソフトウェアまたはその他のデバイス・コンフィギュレーショ ン・コントロールによって保護され、権限のないデバイスまたは同期ファブリックへの鍵の同期または共有を防止しなければならない。
• 同期ファブリックへのアクセスは、省庁が管理するアカウント（例えば、中央アイデンティティ・アクセス管理ソリューションまたはプラットフォーム・ベースの管理アカウント）によって制御され、 秘密鍵のライフ・サイクルに対する企業管理を維持するものとする。
• 秘密鍵を生成する認証器は、認証器の能力およびソースを検証するために使用できる認証機能（例えば、エンタープライズ認証）をサポートすべきである（SHOULD）。

これらの管理は、特に同期をサポートし、FIPS 140 の検証を含む、既存の多要素ソフトウ ェア暗号認証の要件および AAL2 の要件に追加するものとみなされるものとする。

秘密鍵の同期に使うファブリック（要するにクラウドストレージやiCloudやGoogle Platformなど）の保護レベルはFISMA（米国連邦政府のセキュリティ基準）のModerate（平均レベル）もしくは同等が求められています。

また、同期ファブリックへのアクセス制御についてはIAMなどによりしっかり管理されている必要がある、ということなので共有パスワードグループはこの辺りに引っかかるんじゃないかな、、と思います。多分、企業などでiOSやmacOSを使う場合はMDMなどで共有パスワードグループを制御する（できるかどうかは知りませんが）ことが必要になりそうです。

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

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

引き続きNIST SP800-63-3の追補版を見ていきます。

前回はイントロ、文書の目的について読みましたが今回はAAL2の要件と同期可能な認証器の関係性について見ていきます。

では早速。

Syncable Authenticators Achieve AAL2

NIST の認証機関保証レベルは、主に、認証プロセスに対する特定の脅威から保護する認証機 関の能力を中心に構成されている。AAL2 では、ユーザが 2 つの 1 要素認証子、またはユーザ・アカウントにバインドされた多要素 認証子を所持しているという高い信頼性を提供することが意図されている。表 1 は、SP800-63-3 から要求される脅威の緩和と、適切に構成された同期可能な認証子がこれらの 脅威からどのように保護されるかを示している。

SP 800-63-3 による必要な脅威の緩和（表 4-1） 

要求事項	AAL2	同期可能な認証器（パスキーなど）
Man in the Middleに対する耐性	必須	達成 適切に構成された同期可能な認証器は、認証され保護されたチャネルによって、すべての認証デー タを交換する。
Verifierに関するなりすまし耐性	必須ではない	達成 適切に設定された同期可能な認証器は、一意の公開鍵または秘密鍵のペアを作成し、そのペアの使用は、作成されたドメインに限定される(つまり、鍵は特定のウェブサイトまたはRelying Partyでのみ使用できる）。これにより、改ざんされたウェブ・ページが認証子の出力をキャプチャして再利用することを防ぐことができる。
Verifierに関する侵害耐性	必須ではない	達成 適切に設定された同期可能な認証器は、検証者側にのみ公開鍵を保存する。これらの鍵は、ユーザ認証には使用できない。同期ファブリックによって保存される秘密鍵は、承認された暗号化技術を使用して暗号化された形でのみ保存される。アクセス制御により、認証されたユーザー以外が保存された鍵にアクセスすることはできない。
リプレイ耐性	必須	達成 同期可能な認証器は、各認証トランザクションに組み込まれたランダムなノンスを使用する ことで、リプレイ耐性（すなわち、将来のトランザクションでの再利用防止）を防ぐ。
認証の意図	推奨	達成 同期可能な認証器は、暗号化認証プロトコルを開始するために、ユーザがアクティ ベーション・シークレットを入力することを要求する。これは、ユーザの積極的な参加なしにはイベントが進行しないため、認証の意図として機能する。

セクション5では、同期可能な認証器の設定に関する追加的な考慮事項について論じる。

AAL2 要件を満たすために、同期可能な認証器は、ローカルに保存された鍵をアンロックするた めにローカル認証イベントを利用しなければならない[SHALL]。あるいは、ローカル認証の仕組みが 利用できない場合は、別の認証手段(たとえば、ユーザが選択したパスワード)と併用しなければ ならない[SHALL]。FIDO2 Web認証(WebAuthn)コンテキストでは、W3C Web認証仕様の認証子データで利用可能な User Verificationフラグの値によって示される。FIDO2 WebAuthn 認証データフラグの詳細については、セクション5を参照のこと。

ポイントは最後の一文で、やはり同期クレデンシャル「だけ」ではダメで、ちゃんとローカル認証イベント（たとえば端末アンロックの利用など）を使う必要がある、ということに触れたところでしょうか。

次回も引き続き読んでいきたいと思います。

DIFのClaims & Credentials WGの新しいワーキングアイテムに関するWebinarがあります

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

またまた日本時間だと辛い時間帯ではありますが、DIF（Decentralized Identity Foundation）のClaims and Credentialsワーキンググループの新しいワーキングアイテムである、

• Reusable KYC credentials
• Age Verification
• Proof of Humanity

の互換性に関する取り組みのWebinarが日本時間5/15 1am-2amで開催されます。

（申込ページより）

申込ページ

https://www.eventbrite.com/e/difs-new-claims-and-credentials-efforts-tickets-895529882987

KYCクレデンシャルの応用や年齢確認、（AgentやIoTデバイスなどではなく）人間が操作していることの証明など、あちこちで議論はされていますので、どこの動きを集中的にウォッチすべきか迷う部分はあると思いますし、ともすると車輪の再発明になるので注意は必要ですが、動向は追いかけておいても良いと思います。いずれ日本においても議論しなければならない話ばかりだと思いますので。

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

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

先日紹介した通り、NIST SP800-63-3の追補版という形で同期可能なクレデンシャルの取り扱いに関する文書がリリースされました。

今回から中身を少し見ていこうと思います。

しかし、ちょうど最近iOSやmacOSの共有パスワードグループでAirDrop環境外でもパスワードに加えてパスキーまで共有ができるようになった、というアナウンスが界隈では話題に上りました。なんだか単純な同期の話だけでは済まなくなってきてしまった気もしますが、この機能がこのガイドラインにどのような影響を与えるのかは継続ウォッチということで、まずはガイドライン（追補版）を見ていきましょう。

参考）共有パスワードグループ

　　https://support.apple.com/ja-jp/guide/iphone/iphe6b2b7043/ios

とりあえずイントロです。例によってDeeplで機械翻訳です。

Introduction

NIST デジタル ID ガイドラインは、ID 証明、認証、およびフェデレーションを 含む、デジタル ID のプロセスと技術要件を規定している。NIST 特別刊行物（SP）800-63B（SP 800-63-3 に関連する第 B 巻）は、認証およびライフサイクル管理 の要件を特に取り上げている。改訂 3 は、このガイドラインの最新の大幅な改訂であり、2017 年 6 月に発行された。シリーズ全体の更新が進行中であり、改訂 4 で完結する予定であるが、技術のペースは NIST の典型的な文書開発およびレビューのプロセスよりも速いため、この補足的な更新が正当化される。

SP 800-63B で扱われるこのような認証タイプは、多要素暗号認証である。通常、この認証タイプは、ハードウェアまたはソフトウェアで暗号鍵を保護し、第 2 の認証要素（記憶された秘密またはバイオメトリック特性のいずれか）による起動を必要とする。秘密鍵を不正な暴露から保護することは、多要素暗号認証機のセキュリティ・モデルの基本である。これには従来、秘密鍵がエクスポートまたはクローン可能でないことを保証することが含まれる。しかし、このパラダイムは変わり始めている。特に、新しい一連の認証プロトコルと仕様により、同期可能な認証子（一般に「パスキー」と呼ばれる）が急速に採用されるようになり、ユーザが異なるデバイス間で秘密鍵を同期（つまり、 複製）できるようになった。

SP 800-63-3 が 2017 年に発行されたとき、2 つの重要なサポート仕様である Fast Identity Online (FIDO) Client to Authenticator Protocol (CTAP) と W3C の Web Authentication（一緒に使用される場合は FIDO2 として知られる）は存在せず、実装の強固でよく理解されたエコシステムもなかった。当時利用可能であった暗号認証の種類に基づき、2017年のガイドラインは、多要素暗号認証が他のデバイスに鍵を「クローン」する能力を制限した。しかし、この2年間でエコシステムは急速に加速し、現在ではほとんどの主要なプラットフォーム・プロバイダが、スケーラブルで同期可能な認証機能を実装している。これらの認証機能は、耐フィッシング性のサポート、特定の依拠当事者にバインドする機能、パスワー ドを送信する必要性の排除、認証機能のリカバリの簡素化、保存された秘密鍵に付随する第 2 要素とし ての多様なデバイス固有の生体認証および PIN の使用など、多くの利点を提供する。また、ますますマルチデバイス、マルチプラットフォーム化する世界に適合する利便性も提供する。どのような新しい技術もそうであるように、技術革新の約束には、探求し理解しなければならない新たな脅威と課題が伴う。そのため、この補遺では、連邦機関が同期可能な認証機能を実装するかどうか、またどのように実装す るかを決定する際に、現代の脅威を含めて考慮すべき事項の概要を示す。

まぁ、先日のポストにも書いた通り、時代が変わったのでver.4を待たずに追補版で同期可能なパスキーに関してちゃんと分析して考慮をしよう、という話です。

次に文書の目的です。

Purpose

この文書の目的は、変化する認証およびクレデンシャルの市場を反映するために、現行の NIST ガイドラインを適合させることである。この補足では、SP 800-63-3 で確立された認証保証レベルと一致する方法で、同期可能な認証機能がどのように脅威を軽減するかを説明し、SP 800-63-3 認証保証レベル 2（AAL2）を達成するために活用できる同期可能な認証機能の理解を連邦機関に提供する。また、SP 800-63B の第 5.1.8 節で説明されているソフトウェア暗号化認証子の使用に関する最新情報、 特に、鍵が別のデバイスに複製（例えば、「クローン」または「同期」）された場合でも、当該認証子が AAL2 認証要件をサポートする能力についても提供する。最後に、本文書は、公衆向けアプリケーション（すなわち、OMB Memorandum M-19-17 に記 載されているように、公衆 ID と相互作用する連邦情報システム）と連邦エンタープライズ・ アプリケーション（すなわち、OMB Memorandum M19-17 に記載されているように、主に連邦エ ンタープライズ ID と相互作用する連邦情報システム）という 2 つのユースケースに基づ いて、実装に関するいくつかの考慮事項を示す。この文書は、SP 800-63-3 にある既存のガイダンスを補足するものであり、SP 800-63B-4 の最終版に取って代わられる。

記載の通りですが、同期可能であってもAAL2を達成できることを説明するための資料になっているってことですね。また、当然ですが最終的にはver.4へ統合されていく文書というわけです。

ということで、ちょっと長めのシリーズになりそうですが徐々に見ていきたいと思いますので、今回はここまでです。

Entra External IDがGAされています

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

長らくPreviewだったEntra External ID（旧Azure AD B2B、およびCIAM）がGAされました。（といっても特にCIAMはまだまだPreviewの機能だらけなんですけどね・・・）

https://techcommunity.microsoft.com/t5/microsoft-entra-blog/announcing-general-availability-of-microsoft-entra-external-id/ba-p/3974961

個人的にポイントだと思っているのは、いわゆるワークフォースIDであるEntra ID（Azure AD）との機能面での統合が進んだこと、そしてEntra Verified IDとの連携ですね。

しかし、もうここまでくると単なるID基盤という枠には収まらず、他のAzureリソースとの組み合わせを意識した統合的なアイデンティティ・プラットフォームになってきていますね。いよいよインフラとしての設計も難しくなってきてますので、ちゃんとプロ（国井さんとか）の教育を受けて使うことをお勧めします。

個人的にも気になってきたAzure AD B2Cからのトランジションについてはまだまだ情報が不足していますが、現状のCIAMの機能ではとてもじゃないけどAzure AD B2Cの自由度のカバーはできないので、まだしばらくは並行してサポートされていくことになると思います。本社の開発チームの話ではマイグレーションパスなどもゆくゆくは用意していくということなので、こちらも継続ウォッチですね。