--- url: 'https://www.corbado.com/ja/blog/passkeys-prf-webauthn' title: 'エンドツーエンド暗号化のためのパスキーとWebAuthn PRF (2026年)' description: 'WebAuthn PRF拡張機能について解説します。Passkey PRF Demoを試し、OSやブラウザのサポート状況を確認し、PRFがエンドツーエンド暗号化をどのように実現するかを学びましょう。' lang: 'ja' author: 'Vincent Delitz' date: '2025-08-08T11:44:29.220Z' lastModified: '2026-09-15T11:09:10.932Z' keywords: 'PRF, エンドツーエンド暗号化, PRF ユースケース, 疑似ランダム関数, パスキー暗号化, PRF サポート, PRF 拡張機能, WebAuthn Level 3' category: 'Authentication' --- # エンドツーエンド暗号化のためのパスキーとWebAuthn PRF (2026年) **Live PRF testing:** [WebAuthn PRF Demo](https://webauthn-passkeys-prf-demo.explore.corbado.com/)をお試しください。実際のデバイスやブラウザからのコミュニティ提供によるテスト結果が追加され、このページの最新情報の維持に役立っています。 ## Key Facts - **Androidは最も幅広いPRFサポートを提供しています。** Google パスワードマネージャーのパスキーは、Chrome、Edge、Samsung Internet全体でデフォルトでPRFを含んでいます。 - **Windows HelloはWindows 11 25H2以降でPRF値を返します。** Firefox 148+が最初に対応し、Chrome 147で作成時PRF(PRF-on-create)が追加されました。 - **macOS 15はiCloudキーチェーン経由でPRFを有効にしました。** Safari 18+、Chrome 132+、Firefox 139全体でサポートされ、iOS 18.4+では以前のデータ損失のバグが修正されています。 - **PRFは、1つのパスキー認証情報に紐づく決定論的な32バイトの出力を生成し、** WebCrypto暗号化のための対称鍵マテリアルとして使用可能です。 - **Corbado PRF Demoを通じたコミュニティテスト(2026年8月)** では、AppleパスワードとGoogle パスワードマネージャーは100%の成功率ですが、サードパーティ製マネージャーは100%から0%まで幅があります。 ## 1. パスキーとWebAuthn PRF拡張機能の紹介 WebAuthnとパスキーは、フィッシング耐性のあるパスワードレスログインとして知られていますが、その機能はサインインにとどまりません。**WebAuthn疑似ランダム関数(PRF)拡張機能**を使用すると、Webアプリケーションは認証中にユーザーのパスキーやハードウェアセキュリティキーから直接、秘密鍵を導出できます。これにより、第2の秘密情報なしでエンドツーエンド暗号化や、パスキーで開くボルト(vault)が実現可能になります。この記事では次の3つの疑問にお答えします。 1. **パスキーPRFのユースケース:** この拡張機能は実際に何に役立つのでしょうか？ 2. **PRF拡張機能のサポート:** 現在のOSおよびブラウザ間における実際のサポート状況はどうなっているのでしょうか？ 3. **認証情報マネージャー:** ユーザーのパスキーがプラットフォームプロバイダーではなく、1Password、Bitwarden、Enpassなどに保存されている場合はどうなるのでしょうか？ この記事は、2023年に[Matthew Miller](https://blog.millerti.me/2023/01/22/encrypting-data-in-the-browser-using-webauthn/)と[Levi Schuck](https://levischuck.com/blog/2023-02-prf-webauthn)が築いた基盤の上に成り立っており、彼らは仕組みを解説し、最初の実機テストを公開しました。 ## 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拡張機能は動作しません。 ![WebAuthn PRF Extension Flow](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/Web_Authn_PRF_Extension_Flow_3069c8090d.png) このシーケンス図は、これらのアクターが連携して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)](https://support.microsoft.com/en-us/topic/february-10-2026-kb5077181-os-builds-26200-7840-and-26100-7840-f0fa9e54-a22a-4a06-96b6-bf5b2aded506)で、これにより**25H2 (ビルド 26200.7840以降)** のWindows Helloに`hmac-secret`サポートがパッチとして追加されました。この更新前の以前の25H2ビルドにはPRFサポートはありません。これは最初に[Bitwardenコミュニティによって報告されました](https://community.bitwarden.com/t/encryption-prf-via-windows-hello-passkey/94236/21)。 Windowsは[`WEBAUTHN_API_VERSION_8`](https://github.com/microsoft/webauthn/commit/706d98d73a8c3d888e77f0d524f630d551b194c3)によって必要なプラットフォームサポートを導入し、認証情報の作成と認証の両方でPRFの評価を公開しました。 ブラウザ側では、**Firefox 148+**がこれを正しく処理し、作成および認証の両方においてWindows HelloのPRFを完全にサポートしています(作成時のサポートは[Firefox 147にバックポート](https://bugzilla.mozilla.org/show_bug.cgi?id=1993280)されました)。**Chrome 147**は、Windowsでの[作成時PRF(PRF-on-create)のサポートをコミット](https://chromium-review.googlesource.com/c/chromium/src/+/7569106)しており([課題 446157741](https://issues.chromium.org/issues/446157741)でトラッキング)、[デフォルトで有効](https://chromium-review.googlesource.com/c/chromium/src/+/7600513)になっています。Chrome/Edge 146以前では、作成時のWindows HelloからのPRFサポートはまだ表面化されていません。 | オペレーティングシステム | ブラウザ | プラットフォーム認証器 | セキュリティキー | クロスデバイス認証 (CDA/ハイブリッド) | 備考 | | ----------------------------------- | ----------------------------------------------------------------- | ---------------------- | ------------ | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Windows 10 | すべて | ❌ | ❌ | ❌ | 基盤となるOS/認証器のサポートがありません。 | | Windows 11 (2026年2月更新前) | Chrome/Edge ([116+](https://issues.chromium.org/issues/40140659)) | ❌ | ✅ | ✅ | Windows Helloにhmac-secretがありません。セキュリティキーにはhmac-secretとdiscoverable credentialが必要です。 | | Windows 11 (2026年2月更新前) | Firefox 139+ | ❌ | ✅ | ✅ | Windows Helloにhmac-secretがありません。セキュリティキーにはhmac-secretとdiscoverable credentialが必要です。 | | Windows 11 25H2 (2026年2月以降) | Firefox 148+ | ✅ | ✅ | ✅ | Windows HelloがPRF値を返すようになりました。Firefoxは作成および認証時にPRFを正しく検出します。 | | Windows 11 25H2 (2026年2月以降) | Chrome/Edge 146 | ⚠️ (認証のみ) | ✅ | ✅ | 認証器はPRFを提供しますが、Chrome/Edge 146は作成時にそれを表面化しません。 | | Windows 11 25H2 (2026年2月以降) | Chrome/Edge 147+ | ✅ | ✅ | ✅ | 作成時PRF(PRF-on-create)が[コミット](https://chromium-review.googlesource.com/c/chromium/src/+/7569106)され、[デフォルトで有効](https://chromium-review.googlesource.com/c/chromium/src/+/7600513)になりました。`WEBAUTHN_API_VERSION_8`が必要です。 | #### 5.1.2 macOS WebAuthn PRFサポート macOS 15により、プラットフォーム認証器向けのPRFサポートが提供されました。SafariとChromeの両方がiCloudキーチェーン経由でPRFをサポートしています。Firefoxでのプラットフォーム認証器のサポートは、Firefox 139以降で利用可能です。セキュリティキーはChromeでのみ機能します。 | オペレーティングシステム | ブラウザ | プラットフォーム認証器 | セキュリティキー | クロスデバイス認証 (CDA/ハイブリッド) | 備考 | | ---------------- | ----------- | ---------------------- | ------------ | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | | macOS 15+ | Safari 18+ | ✅ | ❌ | ✅ | | | macOS 15+ | Chrome 132+ | ✅ | ✅ | ✅ | ChromeはiCloudキーチェーンプラットフォーム認証器サポートを[実装](https://chromium-review.googlesource.com/c/chromium/src/+/6001891)しました。 | | macOS 15+ | Firefox 139 | ✅ | ✅ | ✅ | Firefoxはバージョン139でPRFサポートをリリースしました。 | macOS 26.4 / iPadOS 26.4のSafariには、CTAP2セキュリティキーでのPRFに影響する2つの未解決のWebKitバグもあります(プラットフォーム認証器は影響を受けません)。[WebKit 311099](https://bugs.webkit.org/show_bug.cgi?id=311099)はUSB/NFCキーでAES-256-CBCで暗号化されたhmac-secretを復号せずに返し、クロスブラウザの相互運用性を損ないます。また、[WebKit 314934](https://bugs.webkit.org/show_bug.cgi?id=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の問題を抱えています。 | オペレーティングシステム | ブラウザ | プラットフォーム認証器 | セキュリティキー | クロスデバイス認証 (CDA/ハイブリッド) | 備考 | | ---------------- | ---------- | ---------------------- | ------------ | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | iOS/iPadOS 18+ | Safari 18+ | ✅ | ❌ | 🆘 / ✅ (18.4+) | 🚨🆘 18.0-18.3において、[CDAソースとしてのデータ損失](https://developer.apple.com/forums/thread/764730?answerId=832494022#832494022)を引き起こすバグがあります。 | | iOS/iPadOS 18+ | Chrome | ✅ | ❌ | 🆘 / ✅ (18.4+) | Safariエンジン(WebKit)を使用します。上記を参照してください。 | | iOS/iPadOS 18+ | Firefox | ✅ | ❌ | 🆘 / ✅ (18.4+) | Safariエンジン(WebKit)を使用します。上記を参照してください。 | #### 5.1.4 Android WebAuthn PRFサポート Androidは現在、最も幅広いPRFサポートを提供しています。Google パスワードマネージャーに保存されたパスキーはデフォルトでPRFサポートを含んでおり、Firefoxを除くほとんどの主要なブラウザで動作します。 | オペレーティングシステム | ブラウザ | プラットフォーム認証器 | セキュリティキー | クロスデバイス認証 (CDA/ハイブリッド) | 備考 | | ---------------- | ---------------- | ---------------------- | ------------ | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | | Android | Chrome/Edge | ✅ | ✅ | ✅ | Google パスワードマネージャーに保存されたすべての[パスキー](https://github.com/w3c/webauthn/issues/1830#issuecomment-1774092530)はPRFサポートを持っています。 | | Android | Samsung Internet | ✅ | ✅ | ✅ | | | Android | 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出力を返すことができるため、鍵確立のための個別の認証ラウンドを節約できます。_ バックアップ、移行、または鍵確立ロジックを設計する際には、認証器がどのバケツに属するかを知ることが不可欠です。私たちの[デモ](https://webauthn-passkeys-prf-demo.explore.corbado.com/)には、これらのシナリオのテストも含まれています。 ### 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 | 取得時PRF | 備考 | | -------------------------- | ------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Apple パスワード | ✅ | ✅ | CTAP 2.2認証器のように動作します。macOS 26.3、Safari 26.3で私たちがテストしました(下のスクリーンショット)。macOSおよびiOSのSafari、Chrome、Firefoxにおけるデモデータでは100%の成功率です。 | | Google パスワードマネージャー | ✅ | ✅ | GPMに保存されているすべてのパスキーがPRFをサポートしています。macOS 26.3、Chrome 151で私たちがテストし、値は作成時と取得時で安定しています。デモデータでは作成時に91～100%、取得時に100%の成功率です。 | | Windows Hello | ✅ | ✅ | クライアント側でChrome/Edge 147+またはFirefox 148+が必要であり、25H2上の2026年2月の更新プログラムからのhmac-secretが必要です(セクション5.1.1を参照)。デモデータでは取得時に88～100%の成功率です。 | | Microsoft パスワードマネージャー | ✅ | ❌ | Windows Helloとは異なり、これはEdgeに組み込まれたマネージャーであり、自身のAAGUID `d3452668-01fd-4c12-926c-83a4204853aa`を報告します。Windows 11、Edge 151で私たちがテストしました。登録時にPRF値が返され、ユーザーがすでにパスキーを選択した後のPRFを要求するすべての後続の`get()`は`NotAllowedError`で失敗します。同じ認証情報に対する拡張機能なしのモーダルな`get()`は成功するため、拡張機能の要求自体がセレモニーを失敗させています。 | **サードパーティ認証情報マネージャー**。どこまで機能するかでソートしています。 | 認証情報マネージャー | 作成時PRF | 取得時PRF | 備考 | | ------------------- | ------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1Password | ✅ | ✅ | macOS 26.3、Chrome 150で私たちがテストし、3つのチェックはすべてパスしました(下のスクリーンショット)。1Passwordは、ブラウザ拡張機能、Android、iOS 18での取得パスを[文書化](https://1password.com/blog/encrypt-data-saved-passkeys)しています。 | | Proton Pass | ✅ | ✅ | macOS 26.3、Chrome 151で私たちがテストしました。拡張機能は作成時にすでに最初のPRF値を返し、次の認証時に同じ値を返します。これはCTAP 2.2の形です。これは、1Password、Enpass、Keeperと並んで、私たちが完全なラウンドトリップを測定した4つのサードパーティマネージャーのうちの1つです。 | | KeePassDX (Android) | ✅ | ✅ | Androidのみ。Android 16とChromeにおいて作成時に95%、取得時に100%であり、デモデータにおいてサードパーティで最も強い結果です。 | | Enpass | ✅ | ✅ | macOS 26.3、Chrome 151で私たちが2回テストしました。拡張機能は作成時にPRF値を返し、次の認証時に同じ値を返します。これはCTAP 2.2の形です。Chromeは事前に`extension:prf`を`false`と報告したため、機能フラグはこの行を見つけられません。ベンダーへの連絡はオープンであり、彼ら自身が私たちのPRFデモに対してテストしています。 | | Keeper | ✅ | ✅ | macOS 26.3、Chrome 151で私たちがテストしました。作成時にPRF値を返し、次の認証時に同じ値を返します。Keeperは長い間、パスキーを作成し、アサーションでは何も返さないものとしてリストされていましたが、私たち自身の実行ではそれが再現されないため、Keeperがギャップを埋めたか、古い数値が異なるプラットフォームからのものであったかのいずれかです。 | | KeePassXC | 🟡 | ✅ | macOSのChromeで、作成時に21%、取得時に81%です。作成パスは利用不可として扱ってください。 | | Bitwarden | 🟡 | 🟡 | 表の中で最も明確にプラットフォームが分かれます。macOSでは完全に失敗します。macOS 26.3、Chrome 151で私たちがテストし、ブラウザが`extension:prf`をサポートしていると報告したにもかかわらず、登録時にPRF拡張機能の結果がまったく返されなかった2回目の実行で確認しました(下のスクリーンショット)。コミュニティデータ: LinuxのFirefoxで取得時に100%、AndroidのChromeで29%、iOSのSafariで0%。プロバイダーパスは[2025年以降オープン](https://github.com/orgs/bitwarden/discussions/13838)です。 | | Dashlane | ❌ | ❌ | macOS 26.3、Chrome 151で私たちがテストし、3つのチェックはすべてネガティブでした(下のスクリーンショット)。2026年8月にデプロイされたHTTPSオリジンで再テストしましたが、登録時にPRF拡張機能の結果はまったく返されませんでした。Dashlaneは自身のボルトにPRFを使用し、依然としてサードパーティのサイトには何も返しません。 | | NordPass | ❌ | ❌ | macOS 26.3、Chrome 151で私たちがテストし、3つのチェックはすべてネガティブでした(下のスクリーンショット)。NordPassは登録時に拡張機能に対して明示的に`prf.enabled: false`と応答し、アサーションでは値を返さないため、少なくとも障害はリライングパーティから見えます。 | | Samsung Pass | ❌ | ✅ | Galaxy電話とChrome 151で私たちがテストしました。登録時にPRF拡張機能の結果はまったく返されず、次の認証時に値が返されます。これは無条件の`hmac-secret`の動作です。登録結果に基づいて機能をゲートすると、機能するにもかかわらずSamsung Passを除外してしまうことになります。 | パーセンテージは、[PRFデモ](https://webauthn-passkeys-prf-demo.explore.corbado.com/)の匿名コミュニティ結果(2026年8月のスナップショット)からのものであり、すべてのデータポイントは1つの認証器、OS、およびブラウザの組み合わせです。これらは試行ごとの成功率であるため、中止されたセレモニーは失敗としてカウントされ、数値はクリーンなラボテストで得られるものよりも低くなります。単一の数値の背後にあるサンプル数は小さいです。数値をベンチマークとしてではなく方向性として読み取り、真ん中の値は「時々」を意味し、本番環境では「信頼できない」ことと同じであることに注意してください。 ![Apple Passwords returning PRF on create and on get, macOS 26.3 with Safari 26.3](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/prf_apple_macos_safari_3f0ea1a3bd.png) _macOS 26.3とSafari 26.3でのApple パスワード。他のすべての行がこれを基準に測定されるベースラインです。認証時に返されるPRF値は登録時のものと同一であり、これは暗号化ユースケース全体が依存するプロパティです。ボックス内の「macOS 10.15.7」は無視してください。Safariは何年もの間、その凍結されたバージョン文字列を報告しています。_ ![1Password returning PRF on create and on get, macOS 26.3 with Chrome 150](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/prf_1password_macos_chrome_fecbc3006c.png) _macOS 26.3とChrome 150での1Password。3つのチェックすべてがパスし、Authenticatorボックスはプロバイダーとして1Passwordを指名しています。これが、iCloudキーチェーンによって生成された結果とこれを区別するものです。_ ![Bitwarden returning no PRF on create or get, macOS 26.3 with Chrome 151](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/prf_bitwarden_macos_chrome_f39e96f8d7.png) _同じマシン、同じ日のBitwarden。パスキーが作成され、認証は成功しますが、PRF値は返ってきません。これはあなたのコードが生き残らなければならない障害モードであり、PRF出力を要求するまで見えません。_ ![Dashlane returning no PRF on create or get, macOS 26.3 with Chrome 151](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/prf_dashlane_macos_chrome_b3d1afe110.png) _Dashlane、同じマシン、同じ結果。これはリライングパーティの区別を具体的に示す行です。DashlaneはPRFを介してパスキーから自身のボルトキーを導出してそれを宣伝していますが、あなたのサイトには何も渡しません。_ ![NordPass returning no PRF on create or get, macOS 26.3 with Chrome 151](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/prf_nordpass_macos_chrome_cfb5023c9c.png) _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デモ](https://webauthn-passkeys-prf-demo.explore.corbado.com/)は、あなた自身のセットアップに対してセレモニーを実行します。次のことができます。 - **PRFを使用してパスキーを登録し**、認証器がそれをサポートしているかどうかを確認します。 - **認証して**、実際のPRF値を読み取ります。 - セクション5.3の数値の元となる**コミュニティ結果と比較します**。 ![WebAuthn PRF Extension Demo](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/demo_passkey_prf_4923217177.png) PRF値を自身で確認することで、安全で鍵ベースの操作にパスキーを使用することの実際的な意味合いが浮き彫りになります。これにより、**PRF拡張機能**に対する認証器の互換性を直接検証し、PRFから導出された鍵がパスワードなしで**WebAuthnエンドツーエンド暗号化**と安全なボルトの復号をどのように強化できるかを観察できます。 時間を取ってデモを試してみてください。特定の環境のPRF機能を理解することは、ユーザーに合わせて調整された安全でパスワードレスな体験をより適切に計画するのに役立ちます。結果は匿名で共有されるため、すべての実行はこの記事の互換性データを改善することにもつながります。 PRFの威力をテストする準備はできましたか？上の画像をクリックするか、この[リンク](https://webauthn-passkeys-prf-demo.explore.corbado.com/)に従ってハンズオンの調査を開始してください。 ## 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](https://issues.chromium.org/issues/40283676)の開発者は、将来的に開発が行われる可能性はありますが、ほとんどのユースケースにおいて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)のサポートをコミット](https://chromium-review.googlesource.com/c/chromium/src/+/7569106)し、[デフォルトで有効](https://chromium-review.googlesource.com/c/chromium/src/+/7600513)にしています。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](https://www.corbado.com/observe)は、まさにそれを既存のパスキーフローの上で測定します。 [Watch on YouTube](https://www.youtube.com/watch?v=Fq-A3uj1LB4) - **ユーザーベース全体の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)サポートを追加](https://chromium-review.googlesource.com/c/chromium/src/+/7569106)しています。 - **認証情報マネージャー:** これがまだ断片化されている軸です。プラットフォームプロバイダーは信頼性がありますが、サードパーティマネージャーはそうではなく、いくつかは取得時(on-get)なしの作成時(on-create)を出荷しており、これはユーザーがすでにコミットした後にのみ失敗します。PRFをハードな依存関係にする前に、自分自身のトラフィック内のプロバイダー構成を測定してください。 実践的な結論は変わりません。PRFを強化として扱い、フォールバックパスを構築し、失われたパスキーが鍵の唯一のコピーを持ち去ることを決して許さないでください。 ## よくある質問 ### 登録時に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準拠のものです。認証器がどのカテゴリに属するかを知ることは、バックアップと鍵確立ロジックを設計する上で不可欠です。