エンドツーエンド暗号化のためのパスキーとWebAuthn PRF (2026年)

Live PRF testing: WebAuthn PRF Demoをお試しください。実際のデバイスやブラウザからのコミュニティ提供によるテスト結果が追加され、このページの最新情報の維持に役立っています。

1. パスキーとWebAuthn PRF拡張機能の紹介#

WebAuthnとパスキーは、フィッシング耐性のあるパスワードレスログインとして知られていますが、その機能はサインインにとどまりません。WebAuthn疑似ランダム関数(PRF)拡張機能を使用すると、Webアプリケーションは認証中にユーザーのパスキーやハードウェアセキュリティキーから直接、秘密鍵を導出できます。これにより、第2の秘密情報なしでエンドツーエンド暗号化や、パスキーで開くボルト(vault)が実現可能になります。この記事では次の3つの疑問にお答えします。

1. パスキーPRFのユースケース: この拡張機能は実際に何に役立つのでしょうか？
2. PRF拡張機能のサポート: 現在のOSおよびブラウザ間における実際のサポート状況はどうなっているのでしょうか？
3. 認証情報マネージャー: ユーザーのパスキーがプラットフォームプロバイダーではなく、1Password、Bitwarden、Enpassなどに保存されている場合はどうなるのでしょうか？

この記事は、2023年にMatthew MillerとLevi Schuckが築いた基盤の上に成り立っており、彼らは仕組みを解説し、最初の実機テストを公開しました。

2. WebAuthn PRF拡張機能とは何か、なぜ重要なのか？#

WebAuthn PRF拡張機能(PRF)は、WebAuthn Level 3仕様で正式に定義されています。これにより、リライングパーティ(Relying Party: あなたのWebアプリケーション)は、認証セレモニー(navigator.credentials.get())中に、特定のWebAuthn認証情報(パスキー)に結びついた疑似ランダム関数を評価するよう認証器(authenticator)に要求できます。

PRFは、認証器内に留まるその1つの認証情報に属する秘密鍵と、リライングパーティから提供される1つ以上の入力値(ソルト)を受け取り、ランダムと区別がつかない決定論的な出力を返します。出力は32バイトであり、対称鍵のサイズと完全に一致するため、クライアントは追加の処理なしでWebCrypto APIに渡すことができます。

多くの認証器、特にFIDO2セキュリティキーは、Client-to-Authenticator-Protocol (CTAP2)で定義されている基盤機能であるhmac-secret拡張を実装しています。このCTAP2拡張機能は、疑似ランダム関数として機能するハードウェアベースのHMAC(Hash-based Message Authentication Code)関数へのアクセスを提供します。WebAuthn PRF拡張機能は、WebアプリケーションがブラウザのWebAuthn APIを通じてこのhmac-secret機能にアクセスするための標準化された方法として機能します。

Webサイトが認証器を騙してWeb以外の目的(ローカルのOSログインなど)を意図したHMACを生成させるという潜在的な競合やセキュリティ上の問題を防ぐため、仕様では1つのステップが追加されています。Webサイトから提供されたソルトは、hmac-secret関数に到達する前に、固定のコンテキスト文字列("WebAuthn PRF"とnullバイト)と共にハッシュ化されます。これにより入力空間が分割され、Web上で導出された値が他の場所で使用される値と衝突することは絶対にありません。

3. WebAuthn PRFユースケース: エンドツーエンド暗号化の実現#

認証器に紐づく鍵は、次の4つの状況で役立ちます。

1. クライアントサイド / エンドツーエンド暗号化 (E2EE): これがPRFの本来の目的です。ブラウザアプリケーションはログイン時に認証情報ごとに1つの暗号化鍵を導出します。この鍵はWebCrypto APIで使用でき、ローカルまたはサーバーに保存されたユーザーデータを暗号化します。データは特定のパスキーでの認証が成功した後にのみ復号できるため、サービスプロバイダーが平文を保持することはありません。PRFがなければ、パスワードレスアプリケーションは鍵マテリアルを取得するためだけにいずれにせよパスワードを要求しなければならず、本末転倒になってしまいます。

2. パスワードレスボルトの復号: パスワードマネージャー(例: Bitwarden、1Password)やセキュアなノートアプリ(例: Notesnook、Reflect)などのサービスは、従来のマスターパスワードを置き換えるためにPRFを使用できます。ユーザーはパスキーで認証し、PRFがボルト復号鍵を導出してボルトが開きます。マスターパスワードは一切関与しません。BitwardenやDashlaneは既にこれを出荷しています。これはマネージャーが自身のボルトのリライングパーティとして機能していることに注意してください。これはPRFの結果をあなたのサイトに返すこととは異なります(セクション5.3を参照)。

3. セキュアな鍵のローテーション: PRFは1回の認証でfirstとsecondという2つの入力ソルトを受け付けます。これがローテーションを可能にする理由です。サーバーはfirstで現在の鍵を要求し、secondで次の鍵を要求します。時間の経過とともに、サーバーはどのソルトが現在の鍵に対応するかを更新できるため、ユーザーによる再登録の手間なしで鍵をローテーションできます。これは、ポリシーや規制がローテーションスケジュールを規定している場合に重要です。

4. アイデンティティウォレットとノンカストディアルシステム: PRFは、デジタルウォレット内のアイデンティティデータを保護するための鍵を導出したり、秘密鍵がサーバー側に一切露出しないノンカストディアルシステムを実現したりできます。

4. PRF拡張機能のサポート: ブラウザ、OS、認証器#

CanIUse.comにはPRF拡張機能のエントリがないため、サポート状況はリリースノートやバグトラッカーからつなぎ合わせる必要があります。以下の表はそれを行ったものです。この機能が動作するには、スタックの3つの層すべてでサポートが存在している必要があります。

1. 認証器: これは、ハードウェア(セキュリティキーなど)またはプラットフォームコンポーネント(Windows Hello、iCloudキーチェーンや、TPMまたはSecure Enclaveなどの対応するハードウェアモジュールなど)であり、認証情報の秘密鍵を安全に保存し、実際の疑似ランダム関数計算(通常はCTAP2のhmac-secret機能を使用)を実行します。これがなければ、スタックのさらに上位層は役に立ちません。

2. オペレーティングシステム (OS): OSはブラウザと認証器の間のブリッジとして機能します。OSは、ブラウザが認証器(特にプラットフォーム認証器やUSB/NFC/Bluetooth経由で接続されたもの)を発見し、通信し、操作を要求するために必要なドライバとシステムレベルのAPIを提供します。OSは認証器のPRF(hmac-secret)機能を認識し、ブラウザに公開できなければなりません。OSがこの経路を提供しない場合、ブラウザはこの機能にアクセスできません。

3. ブラウザ: Webアプリケーションのインターフェースとして、ブラウザはWebAuthn JavaScript APIを実装し、特にprf拡張機能を認識し、WebからのリクエストをOSと認証器が期待するコマンドに変換し、入力とコンテキスト文字列をハッシュ化し、結果をパースしてアプリケーションに返す必要があります。

認証器の機能、OSの公開、またはブラウザの実装というこれらの3つの階層のいずれかで障害またはサポート不足がある場合、PRF拡張機能は動作しません。

このシーケンス図は、これらのアクターが連携してPRFサポートをどのように促進するかの簡略版を示しています。

5. スタック全体のWebAuthn PRFサポート状況を理解する (2026年8月更新)#

機能するPRFワークフローには、WebAuthn ↔ CTAPチェーンのすべての層が連携する必要があります。 明確にするため、(1) ブラウザ＋OSの動作と (2) 認証器の動作を分けて説明します。

5.1 ブラウザおよびOSにおけるWebAuthn PRFサポート#

5.1.1 Windows WebAuthn PRFサポート#

これまでWindows Helloには必要なhmac-secret機能が欠けていたため、WindowsにおけるPRFサポートは限定的でした。これが変わったのは2026年2月の累積更新プログラム(KB5077181)で、これにより25H2 (ビルド 26200.7840以降) のWindows Helloにhmac-secretサポートがパッチとして追加されました。この更新前の以前の25H2ビルドにはPRFサポートはありません。これは最初にBitwardenコミュニティによって報告されました。

WindowsはWEBAUTHN_API_VERSION_8によって必要なプラットフォームサポートを導入し、認証情報の作成と認証の両方でPRFの評価を公開しました。

ブラウザ側では、**Firefox 148+**がこれを正しく処理し、作成および認証の両方においてWindows HelloのPRFを完全にサポートしています(作成時のサポートはFirefox 147にバックポートされました)。Chrome 147は、Windowsでの作成時PRF(PRF-on-create)のサポートをコミットしており(課題 446157741でトラッキング)、デフォルトで有効になっています。Chrome/Edge 146以前では、作成時のWindows HelloからのPRFサポートはまだ表面化されていません。

5.1.2 macOS WebAuthn PRFサポート#

macOS 15により、プラットフォーム認証器向けのPRFサポートが提供されました。SafariとChromeの両方がiCloudキーチェーン経由でPRFをサポートしています。Firefoxでのプラットフォーム認証器のサポートは、Firefox 139以降で利用可能です。セキュリティキーはChromeでのみ機能します。

macOS 26.4 / iPadOS 26.4のSafariには、CTAP2セキュリティキーでのPRFに影響する2つの未解決のWebKitバグもあります(プラットフォーム認証器は影響を受けません)。WebKit 311099はUSB/NFCキーでAES-256-CBCで暗号化されたhmac-secretを復号せずに返し、クロスブラウザの相互運用性を損ないます。また、WebKit 314934は、PIN入力フローをスキップするYubiKey BioなどのintervalUVキーに対してnullのPRF結果を返します。

5.1.3 iOSおよびiPadOS WebAuthn PRFサポート#

iOSとiPadOSでの状況はmacOSと似ており、PRFはiCloudキーチェーン経由で動作します。ただし、重要な注意事項があります。iOS 18の初期バージョンのバグはデータ損失を引き起こす可能性があり、外部セキュリティキーのサポートはiOSにはまだ実装されておらず、iPadOS 26.4はmacOSのセクションで説明したのと同じWebKitセキュリティキーPRFの問題を抱えています。

5.1.4 Android WebAuthn PRFサポート#

Androidは現在、最も幅広いPRFサポートを提供しています。Google パスワードマネージャーに保存されたパスキーはデフォルトでPRFサポートを含んでおり、Firefoxを除くほとんどの主要なブラウザで動作します。

これらの表は、ファーストパーティのパスキープロバイダーを対象としています。サードパーティの認証情報マネージャーに保存されたパスキーは、そのマネージャーの機能に従います。これについてはセクション5.3で説明します。知っておくべき例外が1つあります。Chromeプロファイル認証器はPRFをまったくサポートしていません。

5.2 WebAuthn PRF拡張機能に対する認証器のサポート#

WebAuthnはリライングパーティが_何を_要求できるかを規定していますが、**Client-to-Authenticator Protocol (CTAP)**は認証器が_どのように_振る舞うべきかを定義しています。実際には、認証器は以下の4つのカテゴリーに分類されます。

1. PRFサポートなし: 古いプラットフォーム認証器(例: 25H2ビルド以前のWindows Hello)、hmac-secret拡張機能のないレガシーセキュリティキー、およびまだPRFを採用していないサードパーティプロバイダー。

2. 認証情報作成時にPRFフラグが設定された場合のみPRFをサポート: 一部のCTAP 2.0/2.1セキュリティキーはhmac-secretを公開しますが、シークレットを初期化するために認証情報が最初に作成されたときにリライングパーティが要求していなければ、PRFの評価を拒否します。

3. 作成時に要求されていなくても認証時にPRFが利用可能: 新しいハードウェアトークン、iCloudキーチェーン、およびGoogle パスワードマネージャーは、無条件にhmac-secretを公開します。フラグなしで作成された認証情報であっても、navigator.credentials.get()中にPRFが機能します。 Samsung Passもここに属しており、これが実際にこのカテゴリが重要である理由です。Galaxy電話での私たちの登録では、PRF拡張機能の結果がまったく返されず、それに続く認証で値が返されました。登録時に判断するリライングパーティであれば、これを除外していたでしょう。

4. 完全なCTAP 2.2準拠 (PRF + 作成時の最初のPRF値): iCloudキーチェーンやGoogle パスワードマネージャーのようなパスキーを同期するプラットフォーム認証器は、要求に応じてnavigator.credentials.create()中にすでに最初のPRF出力を返すことができるため、鍵確立のための個別の認証ラウンドを節約できます。

バックアップ、移行、または鍵確立ロジックを設計する際には、認証器がどのバケツに属するかを知ることが不可欠です。私たちのデモには、これらのシナリオのテストも含まれています。

5.3 認証情報マネージャーごとのPRFサポート#

上記の表は、ブラウザ、OS、および認証器のクラスをカバーしています。本番環境では、3番目の軸が結果を決定します。それはユーザーが制御するものです。つまり、どの認証情報マネージャーがデフォルトのパスキープロバイダーとして設定されているかです。

AndroidでGoogle パスワードマネージャーを使用しているユーザーと、サードパーティのマネージャーを使用している同じユーザーとでは異なる結果が得られます。Android 14およびWindows 11 25H2以降、サードパーティのマネージャーは完全なパスキープロバイダーとして機能するため、これはもはやエッジケースではありません。

表を読む前に、1つの区別が重要です。認証情報マネージャーは、2つのまったく異なる役割でPRFを使用できます。

• リライングパーティとして。 パスキーから独自のボルトキーを導出します。これがマスターパスワードを置き換えるものです。DashlaneとBitwardenはどちらもこれを出荷しており、その方法を文書化しています。
• プロバイダーとして。 自身のボルトに保存されたパスキーに対するPRFの結果を、_あなたの_Webサイトに返します。これが、あなたの暗号化機能が機能するかどうかを決定する役割です。

ベンダーの発表は通常、最初の役割について説明しています。ユーザーが必要としているのは2番目の役割です。これら2つは真に独立しています。DashlaneとBitwardenはどちらも自社のボルトにPRFを使用していますが、macOS上の私たちのテストサイトには何も返しませんでした。ベンダーのPRFの発表を、あなたのインテグレーションに関する声明として読むことは、ここで最もよくある間違いです。

ステータス: 2026年8月。 ✅は、私たちが測定したすべての組み合わせで機能します。🟡は部分的であり、一部のプラットフォームまたはブラウザでは機能するが他のものでは機能しないか、試行の一部でのみ成功するか、ベンダーによって主張されているが私たち自身は確認していないことを意味します。❌は、私たちが測定した組み合わせでPRF出力を返しません。"わからない"を示す記号はありません。ここのすべての行は、私たちが実行したか、私たちが指し示すことができる数値です。

OSに同梱されているプロバイダー。残りのベースラインとして以下にリストします。

サードパーティ認証情報マネージャー。どこまで機能するかでソートしています。

パーセンテージは、PRFデモの匿名コミュニティ結果(2026年8月のスナップショット)からのものであり、すべてのデータポイントは1つの認証器、OS、およびブラウザの組み合わせです。これらは試行ごとの成功率であるため、中止されたセレモニーは失敗としてカウントされ、数値はクリーンなラボテストで得られるものよりも低くなります。単一の数値の背後にあるサンプル数は小さいです。数値をベンチマークとしてではなく方向性として読み取り、真ん中の値は「時々」を意味し、本番環境では「信頼できない」ことと同じであることに注意してください。

macOS 26.3とSafari 26.3でのApple パスワード。他のすべての行がこれを基準に測定されるベースラインです。認証時に返されるPRF値は登録時のものと同一であり、これは暗号化ユースケース全体が依存するプロパティです。ボックス内の「macOS 10.15.7」は無視してください。Safariは何年もの間、その凍結されたバージョン文字列を報告しています。

macOS 26.3とChrome 150での1Password。3つのチェックすべてがパスし、Authenticatorボックスはプロバイダーとして1Passwordを指名しています。これが、iCloudキーチェーンによって生成された結果とこれを区別するものです。

同じマシン、同じ日のBitwarden。パスキーが作成され、認証は成功しますが、PRF値は返ってきません。これはあなたのコードが生き残らなければならない障害モードであり、PRF出力を要求するまで見えません。

Dashlane、同じマシン、同じ結果。これはリライングパーティの区別を具体的に示す行です。DashlaneはPRFを介してパスキーから自身のボルトキーを導出してそれを宣伝していますが、あなたのサイトには何も渡しません。

macOS 26.3とChrome 151でのNordPass、3つのチェックすべてがネガティブです。ある点でBitwardenやDashlaneと異なります。登録時にPRF結果がまったくないのではなくprf.enabled: falseが返されるため、リライングパーティは「いいえ」と「応答なし」の違いを区別できます。

1Passwordは私たちの測定で同じように振る舞います。作成時にPRF値を返し、次の認証時に同じ値を返します。そのラウンドトリップは暗号化機能が依存するプロパティであり、これがこれら2つを拡張機能を受け入れるだけのマネージャーから区別するものです。

機能フラグを約束として読むことについての警告が1つあります。同じセッションで、ChromeはBitwarden、Dashlane、Proton Passがアクティブな状態でextension:prfがサポートされていると報告し、その後、BitwardenとDashlaneの登録ではPRF拡張機能の結果がまったく返されませんでした。フラグはクライアントが転送するものを表しており、返ってくるものではありません。L3サポートマトリックスには、12のプロバイダーにわたる完全な比較があります。

表から2つのことがわかります。第1に、作成と取得は別々の機能であり、マネージャーはそのうちの正確に1つだけを出荷する可能性があります。Samsung Passは最も顕著な例です。登録時には何もなく、次の認証時に値が返されます。KeePassXCも同様の傾向があり、Microsoft パスワードマネージャーは逆の傾向があります。第2に、同じマネージャーがプラットフォームごとに異なる動作をします。BitwardenはLinuxのFirefoxで100%からiOSのSafariで0%になるため、ベンダーごとに1つの判定を下すのは嘘になります。Keeperは以前は最初のポイントの標準的な例でしたが、もはやそうではありません。2026年8月の私たち自身の実行では両側で値が返されたため、行が移動しました。

Samsung Passを含め、両方の表のすべてのセルは現在測定値となっており、結論を出すためにGalaxy電話が必要でした。これらの製品のいずれかをメンテナンスしており、行が間違っている場合は、お知らせいただければ再テストします。PRFだけでなく、すべてのLevel 3機能にわたるより広い全体像は、当社のWebAuthn L3サポートマトリックスにあります。

5.4 組み込みプロバイダーへのフォールバックがビジネス上の問題である理由#

PRFが利用できない場合、通常の回答はフォールバックすることです。つまり、ユーザーにOSの組み込みプロバイダー(Apple パスワード、Google パスワードマネージャー、またはWindows Hello)でパスキーを作成するように依頼するか、そのセッションの暗号化機能をドロップします。「プラットフォーム認証器」は、これに対する適切な言葉ではありません。なぜなら、1Passwordのようなサードパーティマネージャーもプラットフォーム認証器として登録されますが、それでもPRFを返さない場合があるからです。実際にフォールバックしているのは、OSに同梱されているプロバイダーです。

技術的にはそれは健全です。商業的には無料ではありません。

認証情報マネージャーをインストールしたユーザーは、自身の認証情報がどこに保存されるかを制御するためにそうしました。「あなたのパスワードマネージャーはこれを実行できません。代わりにAppleまたはGoogleを使用してください」というフローは、彼らにまさにその制御を放棄するように求めています。認証情報マネージャーのベンダーは、これを日本での明示的なユーザーの懸念事項として報告しており、ドイツではエンタープライズの調達において、認証情報の保管場所は詳細ではなく標準的な質問として現れます。

実装への2つの影響:

• フォールバックをダウングレードとしてではなく、選択肢として記述する。 「この機能にはPRFをサポートするプロバイダーが必要です」は、「あなたのパスワードマネージャーはサポートされていません」とは異なる文です。
• ユーザーの3分の1が持っていない可能性のある機能に基づいてコア機能を構築しない。 PRFをハードな依存関係にする前に、自身のトラフィックにおけるプロバイダーの分布を確認してください。

6. WebAuthnとパスキーPRFテストデモ#

私たちのWebAuthn PRFデモは、あなた自身のセットアップに対してセレモニーを実行します。次のことができます。

• PRFを使用してパスキーを登録し、認証器がそれをサポートしているかどうかを確認します。
• 認証して、実際のPRF値を読み取ります。
• セクション5.3の数値の元となるコミュニティ結果と比較します。

PRF値を自身で確認することで、安全で鍵ベースの操作にパスキーを使用することの実際的な意味合いが浮き彫りになります。これにより、PRF拡張機能に対する認証器の互換性を直接検証し、PRFから導出された鍵がパスワードなしでWebAuthnエンドツーエンド暗号化と安全なボルトの復号をどのように強化できるかを観察できます。

時間を取ってデモを試してみてください。特定の環境のPRF機能を理解することは、ユーザーに合わせて調整された安全でパスワードレスな体験をより適切に計画するのに役立ちます。結果は匿名で共有されるため、すべての実行はこの記事の互換性データを改善することにもつながります。

PRFの威力をテストする準備はできましたか？上の画像をクリックするか、このリンクに従ってハンズオンの調査を開始してください。

7. WebAuthn PRF vs. credBlob、largeBlob、およびパスワードから導出された鍵#

秘密データを取り扱うWebAuthn拡張機能はPRFだけではありません。違いは以下の通りです。

• PRF vs. credBlob / largeBlob:

  • credBlob: 認証情報と_一緒に_小さな(32バイト)静的BLOBを保存できるようにします(おそらく作成時)。これは主に秘密情報を対象として設計されたものではなく、特にdiscoverable credentialではない場合はサポートが制限されます。

  • largeBlob: より多くのデータ(約1KB)を_discoverable_ credentialと一緒に保存できるようにします。多くの場合、証明書などの補助データを意図しています。サポートも限定的です(iOS 17以降のiCloudキーチェーンではサポートされていますが、GPMではサポートされていません)。Chromeの開発者は、将来的に開発が行われる可能性はありますが、ほとんどのユースケースにおいてlargeBlobよりもPRFに焦点を当てることを明示的に支持しました。

  • PRF: PRFは静的BLOBを保存するのではなく、ハードウェアに結びついたシークレットから認証中に_オンデマンド_で秘密鍵を_導出_します。これが、BLOB拡張機能ではなくPRFが、パスキーに結びついた暗号化鍵の標準メカニズムである理由です。

• PRF vs. パスワードから導出された鍵 (例: PBKDF2): 従来、クライアントサイドの暗号化鍵はユーザーのパスワードから導出されていました。PRFは大きな利点を提供します。

  • より強力なソース: 鍵マテリアルは、弱かったり再利用されたりする可能性のあるパスワードからではなく、認証器から来ます。

  • フィッシング耐性: 導出は、フィッシング耐性のあるWebAuthnフローに関連付けられています。

  • パスワードレス: パスワードを全く要求することなくボルトを復号できます。

• PRF vs. その他のWebAuthnデータ: WebAuthn応答の他の部分(署名、authenticatorData、公開鍵など)から鍵を導出しようとする試みは、根本的に安全でなく間違っています。これらのコンポーネントは公開されているか、秘密でないか、検証用に設計されており、鍵の導出用ではありません。

8. WebAuthn PRF拡張機能を統合するための開発者向け推奨事項#

8.1 PRF拡張機能サポートの一般的な推奨事項#

• PRFを依存関係ではなく強化として扱う: ブラウザ、OS、認証情報マネージャー、認証器全体でサポートが依然として異なるため、ミッションクリティカルな機能でこれを必須にすべきではありません。macOSとiOSのSafariは現在最も弱い組み合わせです。

• 失われたパスキーに備える: PRFから導出された鍵は、パスキーが存在する間だけ存在します。パスキーがなくなると、暗号化されたデータも完全に失われます。機能をリリースした後ではなく、リリースする前にバックアップと復旧パスを構築してください。

• Windowsエコシステムを監視する: Windows 11 25H2のWindows Helloは、WEBAUTHN_API_VERSION_8を介してPRF値を返し始めました。Firefox 148+はこの機能を完全にサポートしており、Chrome 147は作成時PRF(PRF-on-create)のサポートをコミットし、デフォルトで有効にしています。Windowsは、リリースごとに状況がまだ変化するプラットフォームです。

8.2 パスキー戦略へのPRFの統合#

PRFが全体的なパスキー戦略とどのように一致するかを理解することは、不必要な複雑さを伴わずにその利点を最大化するのに役立ちます。

• 柔軟な統合: パスキー作成の瞬間にPRFを活用するかどうかを決定する必要はありません。既存のパスキーは、後で追加の認証情報管理のオーバーヘッドなしにPRFのユースケースにシームレスに統合できます。

• PRFの遡及的な適用: PRFは認証フェーズ(navigator.credentials.get())中に動作するため、以前に作成されたパスキーは、新しい認証情報を発行することなく、後の段階でPRFベースのワークフローをサポートできます。これにより、アプリケーションは確立された認証方法を中断することなく段階的にセキュリティを強化できます。このアプローチは、iCloudキーチェーン、Google パスワードマネージャー(GPM)、および新しいセキュリティキーで機能します。古いセキュリティキーの場合、hmac-secretは認証情報の作成時に要求された場合にのみ生成される可能性があります。

• パスキーの複雑さの考慮事項: 認証情報の同期、クロスデバイス認証、リカバリプロセスなど、パスキー管理に固有の複雑さは、PRFを使用する場合にも等しく適用されます。PRFの実装が全体的なパスキー認証戦略と一貫して連携し、合理化されたユーザー体験と堅牢なセキュリティコントロールを維持していることを確認してください。

全体的なパスキー戦略の一部としてPRFを検討することで、より安全でユーザーフレンドリーな認証プラクティスへのスムーズな移行が可能になります。

9. Corbadoがどのように役立つか#

セクション4と5が示すように、PRFのサポートはOS、ブラウザ、認証器全体で断片化されています。暗号化機能をPRFに依存させる前に、_あなたの_ユーザーのどれだけが実際にそれを使用できるかを知る必要があり、サポートマトリックスを読み取るだけでは不十分です。Corbado Observeは、まさにそれを既存のパスキーフローの上で測定します。

• ユーザーベース全体のPRF準備状況を測定する: ObserveのClient Capabilitiesは、ブラウザのgetClientCapabilities()を読み取り、PRF拡張機能(extension:prf)が利用可能かどうかを、conditionalCreateやプラットフォーム認証器のサポートなどの関連機能とともに、デバイスごと、および時間の経過とともにOS別にセグメント化して報告します。
• 仮定ではなく実際のデータからロールアウトを決定する: 他の全員のためにフォールバックパスを構築する前に、実際のトラフィックでのPRFの可用性が、PRFに依存する機能を出荷するのに十分高いかどうか、そしてどのセグメントに対して出荷できるかを確認します。

範囲に関する注意事項: ここでのCorbadoの役割は測定です。PRFを有効にしても安全な場所を教えてくれますが、PRFの鍵導出とクライアントサイド暗号化自体はアプリケーション内にとどまります。

10. 結論: PRFを使用したWebAuthnエンドツーエンド暗号化#

PRFは、鍵マテリアルのためにパスワードにフォールバックすることなく、パスワードレスアプリケーションがエンドツーエンド暗号化を実行できるようにするものです。最初に出た3つの質問に答えます。

• PRFユースケース: エンドツーエンドの暗号化ストレージ、マスターパスワードなしのボルト復号、2つのソルトによる鍵のローテーション、および秘密鍵がクライアントから離れることがなく、ユーザーのプライバシーがオペレーターに依存しないアイデンティティウォレットやノンカストディアルシステム。

• 現在のPRFサポート状況 (2026年8月): Androidはブラウザと認証器間で機能します。macOSとiOSはiCloudキーチェーン経由で機能しますが、iOS 18.0〜18.3にはデータを破壊する可能性のあるクロスデバイスバグがあった(18.4+で修正済み)という注意点があります。Windowsは長年の空白でしたが、現在は埋まりました。Windows 11 25H2上のWindows HelloはWEBAUTHN_API_VERSION_8経由でPRF値を返し、Firefox 148+はそれを完全にサポートし、Chrome 147は作成時PRF(PRF-on-create)サポートを追加しています。

• 認証情報マネージャー: これがまだ断片化されている軸です。プラットフォームプロバイダーは信頼性がありますが、サードパーティマネージャーはそうではなく、いくつかは取得時(on-get)なしの作成時(on-create)を出荷しており、これはユーザーがすでにコミットした後にのみ失敗します。PRFをハードな依存関係にする前に、自分自身のトラフィック内のプロバイダー構成を測定してください。

実践的な結論は変わりません。PRFを強化として扱い、フォールバックパスを構築し、失われたパスキーが鍵の唯一のコピーを持ち去ることを決して許さないでください。

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのPasskey Intelligence Platformです。IDPのログや一般的なanalyticsツールでは見えないものを可視化します。どのデバイス、OSバージョン、ブラウザ、credential managerがpasskeyに対応しているか、なぜ登録がログインにつながらないのか、WebAuthnフローのどこで失敗するか、OSやブラウザのアップデートがいつ静かにログインを壊すか、 Okta、Auth0、Ping、Cognito、あるいは自社IDPを置き換えることなく、すべてを把握できます。2つのプロダクト：Corbado Observeは passkeyとその他あらゆるログイン方式のobservabilityを提供します。Corbado Connectは analytics内蔵のmanaged passkeyを追加します（既存のIDPと併用）。VicRoadsはCorbadoで500万人超のユーザーにpasskeyを提供しています（passkey有効化率+80%）。 Passkeyエキスパートに相談する →

よくある質問#

登録時にPRF拡張機能を要求せずに作成済みのパスキーにPRFサポートを追加できますか？#

PRFは認証フェーズ(navigator.credentials.get())中に動作するため、以前に作成されたパスキーは、新しい認証情報を発行することなくPRFベースのワークフローをサポートできます。この遡及的適用は、iCloudキーチェーン、Google パスワードマネージャー、および新しいセキュリティキーで機能します。ただし、古いセキュリティキーは、認証情報の作成時に明示的に要求された場合にのみhmac-secretを生成する可能性があります。

鍵の導出においてWebAuthn PRFとlargeBlobの違いは何ですか？#

PRFは、ハードウェアに結びついたHMACシークレットを使用して認証中にオンデマンドで秘密鍵を導出するために特別に設計されており、鍵の導出のための専用の標準となっています。largeBlobは、discoverable credentialと共に約1KBの補助データを保存できるようにしますが、秘密鍵の導出を目的として設計されていません。Chromeの開発者は、暗号化のユースケースにおいてlargeBlobよりもPRFを明示的に支持しました。

ユーザーがパスキーを紛失した場合、PRFで導出された鍵で暗号化されたデータはどうなりますか？#

PRFで導出された鍵は、認証時に使用された特定のパスキーに排他的に紐付けられます。そのパスキーが失われると、元の認証情報なしに同じPRF出力を再現できないため、暗号化されたデータは永久にアクセスできなくなります。PRFベースの暗号化をユーザーに提供する前に、バックアップとリカバリパスを構築してください。

PRFのサポートは認証器の種類によってどのように異なりますか？#

認証器は4つのカテゴリに分類されます。PRFサポートがまったくないもの(古いプラットフォーム認証器やレガシーなセキュリティキー)、認証情報作成時にフラグが設定された場合のみPRFをサポートするもの(一部のCTAP 2.0/2.1セキュリティキー)、フラグなしで作成された認証情報でも無条件でPRFを利用できるもの(iCloudキーチェーンやGoogle パスワードマネージャー)、そして認証情報作成時にすでに最初のPRF出力が返される完全なCTAP 2.2準拠のものです。認証器がどのカテゴリに属するかを知ることは、バックアップと鍵確立ロジックを設計する上で不可欠です。