こんにちは、富士榮です。
今週は大阪でFIDO Allianceのセミナ〜Plenaryですね。ちょうど昨日、私もPlenaryでゲストスピーカーとしてOpenID FoundationおよびOpenIDファウンデーションジャパンとFIDO Allianceとの協業について話をしました。
さて、そんなFIDOイベントの中でPlayStationアカウントのパスキー対応のアップデートについて話がありました。（4月ごろアップデートされたそうです）
このブログでも以前書いたものですね。
https://idmlab.eidentity.jp/2024/02/playstation_01288657578.html
ポイントは、これまでアカウントのリカバリを行う際に一旦パスワードを生成してからパスキーの登録、パスワードが無効化される、という流れだったところをダイレクトにパスキーを生成できるようになった、というところです。
と言うことで試してみました。
パスワード忘れ、パスキーにアクセスできない人はこちら、ということでリカバリプロセスに入ります。
ここが更新されたポイントですね。パスワードを生成、に加えてパスキーを生成のメニューができています。
アカウントのリカバリプロセスのAssurance Levelの低下は大きな問題につながる可能性が高いので、一時的にでもパスワードのような強度の低い認証手段に落とさずにリカバリできるのはとてもいいですね。
こんにちは、富士榮です。
NIST SP 800-63B-3の追補版も最後のまとめ部分を残すのみです。
早速ですが本文書でどのように結論づけているのかをみていきましょう
同期可能な認証器は、認証の状況、特に多要素暗号認証子の使用における実質的な技術的変化を示すものである。暗号鍵の複製とクラウド・インフラへの保存を許可することに関連するトレードオフの 評価は、必然的に行われることになる。このことは、明確なリスク（認証鍵に対する企業管理の喪失など）をもたらすが、同時に、 一般市民や企業にとっての主要な脅威ベクトルを排除する、便利でフィッシングに強い認証機能への道筋を提供する。同期可能な認証器は、すべてのユースケースに適しているわけではない。しかし、本補足文書に含まれるガイドラインに沿った方法で導入される場合、AAL2 リスク軽減策との整合性を達成し、フィッシング耐性認証の採用をより広範に促進することができる。
企業等で利用する場合は鍵が制御外のファブリック（iCloudなど）に保存されることによるリスクがありますが、一般ユーザのシナリオではフィッシング耐性のない認証器を使うよりはマシっていうことなんでしょうねぇ。要はユースケースに応じたリスク分析をちゃんとやろうねっていうNISTのガイドラインの根本は変わらないわけで。
この文書は、既存のデジタル・アイデンティティ・ガイドラインに付随するものであり、各省庁 が十分な情報に基づきリスクベースの決定を行い、適切な場合には最新の業界イノベーション を統合するための情報を提供する。
改めて本文書は既存のガイドラインの付随文書であることを強調し、先に書いたとおりちゃんとしたリスク分析に則って対策を考えましょう、ということです。
ということでこれで一通り見てきたわけですが、私的なまとめとしては、
こんにちは、富士榮です。
少し間が開きましたがNIST SP 800-63B-3の追補版の続きです。
今回は同期と共有は違うぞ！という話のうちの共有の部分です。１回目にも書きましたがAppleの共有パスワードグループの話などもありますので、非常に重要な部分だと思います。
サイバーセキュリティ・ガイドラインは、歴史的に、ユーザ間で認証器を共有しないよう警告してきた。このガイダンスにもかかわらず、一部のユーザ・グループやアプリケーションでは、個人がデジタル・アカウントへのアクセスを共有できるようにするために、認証器とパスワードの共有が行われている。
表 3 に示すように、一部の同期可能な認証器の実装は、このようなユーザの行動を受け入れ、 異なるユーザ間で認証キーを共有する方法を確立している。さらに、一部の実装は、一般的なサービスにおいて、パスワード共有に代わる便利で より安全な方法として、同期可能な認証器の共有を積極的に推奨している。
言われてますよ、Appleさん。。
企業ユースケースの場合、鍵の共有に関する懸念は、鍵が承認されたデバイスや同期 ファブリックから移動されることを制限するデバイス管理技術を使用することで、効果的に緩和することができる。しかし、公衆向けのユースケースでは、同様の緩和策は現在のところ利用できないため、 リライングパーティは、同期可能な認証プロバイダが採用する共有モデルに依存することになる。公衆向けアプリケーションの所有者は、共有認証器に関連するリスクを認識する必要がある。公衆と対話する場合、機関は、ユーザがどの特定の認証器を使用しているのかについて限られ た可視性しか持たないため、すべての同期可能な認証器が共有の対象となる可能性があることを想定する必要がある。多くの共有モデルには、リスクを最小化する実質的な制御（例えば、共有を許可するためにデバイス間の近接を要求する）があるが、他の実装はそれほど制限的ではない。
やっぱり共有を制御する方法とセットになっていることが必要なんじゃないかと思いますね。この辺りの判断をリライングパーティに全部任せちゃうのは実質不可能だと思いますし。
この新しいクラスの認証者がもたらす共有のリスクは、特別なものではない。実際には、すべての AAL2 認証タイプに適用され、中には同期可能な認証タイプより弱いものもある。AAL2 のどの認証子も、それを共有しようとするユーザによって共有される可能性がある。ユーザは、パスワード、OTP、帯域外認証子、さらにはプッシュ認証イベントを積極的に共有したり、被指名人（正式か否かを問わない）がエンドユーザに代わって認証を行うことを許可したりすることができる。
各省庁は、直面する特定のリスク、脅威、およびユーザビリティの考慮事項に基づいて、アプリ ケーションにどの認証手段を受け入れるかを決定する。同期可能な認証方式は、AAL2 までの実装を求めるアプリケーションの新しいオプションとして提供されるかもしれず、他の認証方式と同様に、この技術のトレードオフは、セキュリティ、プライバシー、公平性、およびユーザビリティに対する期待される結果に基づいて、うまくバランスをとるべきである。
そろそろこのレポートもおしまいです。
というか早くSP800-63-4の次のドラフトが出て欲しいですね。
Implementation Considerations and Requirements
同期可能な認証器は、W3CのWebAuthn仕様に基づいて構築されており、共通のデータ構造、チャレンジ・レスポンス暗号プロトコル、公開鍵認証情報を活用するためのAPIを提供している。この仕様は柔軟で適応性があるため、WebAuthnクレデンシャルのすべてのデプロイが連邦政府機関の実装要件を満たすとは限らない。この仕様には一連の「フラグ」があり、依拠当事者（RP）アプリケーションは、認証イベ ントの追加コンテキストを提供し、それが RPのアクセス・ポリシーに適合するかどうかを判断す るために、認証者に要求することができる。本節では、RPとして活動する連邦機関が、NIST AAL2 脅威緩和策に適合する同期可能な認証器の実装を構築する際に理解し、問い合わせる必要がある、WebAuthn仕様の特定のフラグについて 説明する。表2, WebAuthn Level 3 flags
以前パスキー対応の認証機能を実装した際にも出てきたフラグですね。
https://idmlab.eidentity.jp/2024/02/api.html
同期可能かどうかの判断にはBEやBSを使うわけです。アプリによってはこのフラグを見て同期可能な認証器を受け入れるかどうかを決める、と言うことです。
表2に示されるフラグに加えて、機関は、実装および受け入れを選択する同期可能な認証器のオリジンおよび機能について、より詳細な情報を得ることを望むかもしれない。FIDO2 WebAuthn のコンテキストにおいて、認証者の中には、特定の認証者の能力および製造者を 判断するために使用できる認証機能をサポートしているものがある。企業ユースケースの場合、各機関は、プラットフォームプロバイダが提供する機能に基づいて、認証機能を実装するべきである(SHOULD)。好ましくは、RP が認証器に関する一意の識別情報を要求するエンタープライズ認証の形をとる。構成証明（Attestation)は、広範な公衆向けアプリケーションに使用すべきではない（SHOULD NOT）。このような要件（すなわち、構成証明に対応していない場合、一部の一般ユーザの同期可能な認証器をブロックする要件）は、ユーザをショートメッセージサービス（SMS）のワンタイムパスワード（OTP）のような、フィッシングに脆弱な安全性の低い認証オプションに誘導する可能性がある。
この視点は面白いですね。パブリック（共有端末とかのイメージかな？）なアプリケーションで同期可能な認証器を使うとってしまうまずいので同期可能なクレデンシャルをブロックすると言うポリシーを適用すると、手軽な認証手段を実装しがちになる、という話でしょうか？（@Shiroicaさんご指摘ありがとうございます）
RP がフラグおよび認証データを要求しても、認証器は要求された情報をすべて返さないかもしれないし、リソースへのアクセスに要求される期待応答と矛盾する情報を返すかもしれない。したがって、各機関は、同期可能な認証器を使用するユースケースを評価し、返された情報に基づいて適切なアクセスポリシー決定を行うことが決定的に重要である。
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-63-3の追補版を見ていきます。
前回はイントロ、文書の目的について読みましたが今回はAAL2の要件と同期可能な認証器の関係性について見ていきます。
では早速。
Syncable Authenticators Achieve AAL2
NIST の認証機関保証レベルは、主に、認証プロセスに対する特定の脅威から保護する認証機 関の能力を中心に構成されている。AAL2 では、ユーザが 2 つの 1 要素認証子、またはユーザ・アカウントにバインドされた多要素 認証子を所持しているという高い信頼性を提供することが意図されている。表 1 は、SP800-63-3 から要求される脅威の緩和と、適切に構成された同期可能な認証子がこれらの 脅威からどのように保護されるかを示している。
SP 800-63-3 による必要な脅威の緩和（表 4-1）
セクション5では、同期可能な認証器の設定に関する追加的な考慮事項について論じる。
AAL2 要件を満たすために、同期可能な認証器は、ローカルに保存された鍵をアンロックするた めにローカル認証イベントを利用しなければならない[SHALL]。あるいは、ローカル認証の仕組みが 利用できない場合は、別の認証手段(たとえば、ユーザが選択したパスワード)と併用しなければ ならない[SHALL]。FIDO2 Web認証(WebAuthn)コンテキストでは、W3C Web認証仕様の認証子データで利用可能な User Verificationフラグの値によって示される。FIDO2 WebAuthn 認証データフラグの詳細については、セクション5を参照のこと。
ポイントは最後の一文で、やはり同期クレデンシャル「だけ」ではダメで、ちゃんとローカル認証イベント（たとえば端末アンロックの利用など）を使う必要がある、ということに触れたところでしょうか。
次回も引き続き読んでいきたいと思います。
こんにちは、富士榮です。
前回、Entra IDの条件付きアクセスがデバイスコードフローなどの認証フロー単位で適用できるようになった（Preview）という話をしました。
https://idmlab.eidentity.jp/2024/03/entra-id.html
すると、某FacebXXkで某氏よりTeams Roomとかで使えそう、かつWindows Helloを除外した上でYubikeyなどFIDOキーを使った認証を強制できると良さそう、、というコメントをもらったのでやってみました。
やることは、
です。
認証強度、というとよくわかりませんが、認証方法をカスタムで設定できるEntra IDのセキュリティ機能です。
認証方法→認証強度のメニューで「新しい認証強度」の追加を行います。この際に、パスキー（FIDO2）を選択します。Windows Hello for Businessや証明書ベース認証などと分けて設定ができるので、Windows Helloなどとは分けて設定ができます。ちなみにここでパスキー（FIDO2）として設定を行うとtransportがusb/nfcに設定されるっぽいのでplatform authenticatorは除外できます。細かいパラメータは先日のポストで書きましたので知りたい方はこちらへどうぞ。
また、詳細オプションを設定することでAuthenticator Attestation GUID（AAGUID）を設定することもできるので認証器の種類まで絞り込むこともできます。
前回のポストで紹介したデバイスコードフローをブロックするポリシーをベースにカスタマイズしてみます。
やりたいことは、
しばらく設定が馴染むまで待ちましょう。
ざっくりいうと、パスワードで認証するとパスキーでの追加認証が求められ、最初からパスキーで認証するとそのままログインが完了します。
以下の例ではまずはパスワードで認証しています。
確かに某氏が言うように割と不特定多数が触れる環境（例えばゲスト用の会議室など）でデバイスコードフローを使う場合にPINのみでログインされてしまう可能性などを鑑みるとこう言う使い方もありかもしれませんね。
こんにちは、富士榮です。
そういえばAuth0（Okta CIC）の管理画面へのログインにパスキーなどが使えるので使ってみたいと思います。
ちなみにちょっとだけ癖があります。簡単に書くと、
という感じです。最初からplatform認証器が登録できればいいのに。ちょっと実装が古いのかな。
さて、始める前に基本的な話を。IDaaSを使ってID基盤を構築するときに忘れてはいけないのはIDaaS自体の認証強化とアクセス制限です。
こんにちは、富士榮です。
そういえばパスキーの実験をしていた頃のコードを公開するのを忘れていた気がするので公開しておこうと思います。
これまでのパスとでやったことはこちらです。
こんにちは、富士榮です。
前回の続きです。前回はログイン処理の前段部分まで実装できたので今回はcredential.get()の結果の検証を行います。
その前に、これまでのポストはこちらです。
こんにちは、富士榮です。
そういえばPlayStation Network（PSN）がパスキーに対応したというニュースが1月末ごろに流れたので確認してみていたのですが、その時点ではUSアカウントしかサポートしていない？みたいな状態だったのでしばらく放置していましたが、先ほど確認してみたら私のアカウントでもパスキーが使えるようになっていました。
ポイントはこちらです。
まぁ利便性などを考えると仕方ないのかもしれませんが、メール到達性＋生年月日で回復できてしまうのは微妙だなぁ、、と思いつつ。
5/22追記）リカバリプロセスが更新されています。詳しくはこちら
実機（といってもPS4しか持っていない）での確認は次回以降でやりたいと思いますが、とりあえずブラウザでの設定関係についてまとめておきます。
とりあえずTouchIDで生成していきます。
生成が完了するとログアウトされます。
なお、Autofillを無視してサインインIDにメールアドレスを入力して次へ、をクリックすると「パスキーでサインイン」しか出てこずパスワードでのログインはできないようになっています。
パスキーの管理メニューを開くと登録済みのパスキーの一覧が出てきます。
パスキーの識別にはUser-Agentが使われるようです。自分で名前がつけられる方が親切な気はしますがまぁいいかと思います。
メールアドレスを入力しパスキーでサインインから他端末で読ませるQRを表示する方法もありますが、リカバリの流れで他端末を使ったサインインもサポートしています。
他の端末を含め全部ロストしてしまったケース用の動線も用意されています。
具体的にはアカウント回復用のメール＋秘密の質問もしくは生年月日を使います。
検証に成功するとパスワードの生成を求められます。
この段階でパスキーが無効になりますので、パスワードでログインした後に再度パスキーを登録する必要があります。
なお、パスキーが無効化された状態でパスキーでログインしようとするとエラーが表示されます。
とりあえずはブラウザで試しましたが実機を触る時間ができたら実機でも試してみたいと思います。
投稿
すべてのコメント
