パスキーとWebAuthn PRFによるエンドツーエンド暗号化（2025年版）

WebAuthnとパスキーは、ウェブ認証に革命をもたらし、公開鍵暗号方式を通じてフィッシング耐性のあるパスワードレスログインを提供してきました。しかし、その機能はサインインだけにとどまりません。注目すべき機能の一つが、WebAuthn疑似乱数関数（PRF）拡張機能です。この拡張機能により、ウェブアプリケーションは認証中にユーザーのパスキーやハードウェアセキュリティキーから直接秘密鍵を導出できます。これにより、別のパスワードを必要とせず、パスキーだけでエンドツーエンドで暗号化されたデータのロックを解除したり、安全な保管庫を復号したりすることが可能になります。この記事では、以下の問いに答えていきます。

• パスキーPRFのユースケース： WebAuthn PRF拡張機能を使用する興味深いユースケースは何か？
• PRF拡張機能のサポート状況： 現在、オペレーティングシステムやブラウザにおけるWebAuthn PRF拡張機能の実際のサポート状況はどうなっているか？

この記事では、WebAuthn PRF拡張機能を分析し、その技術仕様、ユースケース、実装の詳細、セキュリティに関する考慮事項、そして現在のブラウザとオペレーティングシステムのサポート状況を探ります。私たちは2025年のエコシステムにおける変化に焦点を当て、2023年にMatthew MillerとLevi Schuckが築いた基礎をさらに発展させます。彼らの以前の記事では、詳細な技術的背景、ライブデモ、オンラインテスト（暗号化を含む）が提供されています。

WebAuthn PRF拡張機能（PRF）は、WebAuthn Level 3仕様で正式に定義されています。その主な目的は、リライングパーティ（ウェブアプリケーション）が認証処理（navigator.credentials.get()）中に、特定のWebAuthnクレデンシャル（パスキー）に関連付けられた疑似乱数関数の評価を要求できるようにすることです。

PRFは、（認証器内で安全に保持され、クレデンシャルに紐づけられた）秘密鍵と、（リライングパーティから提供される）1つ以上の入力値を受け取り、決定的で暗号学的にランダムに見える出力を生成します。この出力（通常は32バイトの文字列）は、クライアントサイドのアプリケーションで、特にWebAuthn暗号化の対称鍵素材や鍵導出に利用できます。

多くの認証器、特にFIDO2セキュリティキーは、Client-to-Authenticator-Protocol（CTAP2）で定義されたhmac-secret拡張機能と呼ばれる基盤機能を実装しています。このCTAP2拡張機能は、ハードウェアで保護されたHMAC（ハッシュベースのメッセージ認証コード）関数へのアクセスを提供し、これが疑似乱数関数として機能します。WebAuthn PRF拡張機能は、ウェブアプリケーションがブラウザのWebAuthn APIを通じてこのhmac-secret機能にアクセスするための標準化された方法として機能します。

ウェブサイトが認証器を騙して、ウェブ以外の目的（ローカルOSへのログインなど）で意図されたHMACを生成させるような潜在的な競合やセキュリティ問題を避けるため、WebAuthn仕様では重要なステップが義務付けられています。ウェブサイトから提供された入力（第1および第2のソルト）は、基盤となるhmac-secret関数に渡される前に、まず特定のコンテキスト文字列（「WebAuthn PRF」とヌルバイト）でハッシュ化されます。これにより、PRFの入力空間が効果的に分割され、ウェブから導出された出力が他のコンテキストで利用される可能性のある出力とは異なることが保証されます。

認証器に紐づいた鍵を導出できることで、開発者にとっていくつかの魅力的なユースケースが生まれます。

1. クライアントサイド/エンドツーエンド暗号化（E2EE）： これはWebAuthn PRF拡張機能の主な動機です。ブラウザベースのアプリケーションは、ログイン時にクレデンシャルごとに一意の暗号鍵を導出できます。この鍵はWebCrypto APIと組み合わせて、ローカルやサーバーに保存されたユーザーデータを暗号化するために使用できます。データは保存中も暗号化されたままであり、ユーザーが特定のパスキーで正常に認証した後にのみ復号できるため、プライバシーとデータセキュリティが向上します。サービスプロバイダーは、平文にアクセスすることなくユーザーデータを保存できます。これは、PRF拡張機能がなければ、パスワードレスアーキテクチャに反するパスワード形式の秘密情報を追加で要求する必要があるため、パスワードレスの世界のアプリケーションにとって特に役立ちます。

2. パスワードレスでの保管庫の復号： パスワードマネージャー（例：Bitwarden、1Password）やセキュアなメモアプリ（例：Notesnook、Reflect）のようなサービスは、PRFを使用して従来のマスターパスワードを置き換えることができます。ユーザーがパスキーで認証すると、PRF拡張機能が保管庫の復号鍵を導出し、保管庫のロックが解除されます。マスターパスワードは一切不要です。Bitwardenはこの機能のサポートを発表しています。さらに、Dashlaneは最近、WebAuthn PRF拡張機能を採用し、フィッシング耐性を強化し、暗号化された保管庫へのアクセスのセキュリティを向上させました。ユーザーはパスキーを使用して認証し、PRFが保管庫の復号鍵を安全に導出することで、マスターパスワードの必要性を完全になくします。

3. 安全な鍵のローテーション： WebAuthn PRF拡張機能では、認証時に2つの入力「ソルト」（第1と第2）を提供できます。これにより、暗号鍵のローテーションスキームが容易になります。サーバーは、第1のソルトを使用して「現在の」鍵を、第2のソルトを使用して「次の」鍵を要求できます。時間が経つにつれて、サーバーはどのソルトが現在の鍵に対応するかを更新でき、ユーザーエクスペリエンスを損なうことなくシームレスなローテーションが可能になります。これは、規制要件や内部ポリシーによってすべての鍵を特定のスケジュール内でローテーションする必要がある場合に特に重要であり、セキュリティを向上させます。

4. IDウォレットと非管理型システム： PRFは、デジタルウォレット内のIDデータを保護するための鍵を導出したり、秘密鍵がサーバーサイドで決して公開されない非管理型システムを可能にしたりできます。

仕様は定義されていますが、開発者にとって重要なのは、実際のブラウザとプラットフォームのサポート状況です。サポートは進化しており、最近まで主にChromiumベースのブラウザに限定されていました。CanIUse.comにはPRF拡張機能自体の専用エントリがないため（「webauthn」で検索すると一般的なAPIサポートは表示されますが、特定の拡張機能は表示されません）、サポート状況の追跡は困難な場合があります。情報は、ブラウザのリリースノート、バグトラッカー、ステータスページから収集する必要があります。WebAuthn PRF拡張機能を正常に使用するには、技術スタックの3つの異なるレイヤー間での連携が必要です。この機能が動作するためには、各レベルでPRF拡張機能のサポートが存在しなければなりません。

1. 認証器： これは、クレデンシャルの秘密鍵を安全に保存し、実際の疑似乱数関数計算（通常はCTAP2のhmac-secret機能を使用）を実行するハードウェア（セキュリティキーなど）またはプラットフォームコンポーネント（Windows Hello、iCloudキーチェーン、および対応するハードウェアモジュール、例：TPMやSecure Enclave）です。認証器にこの基本的な暗号機能が欠けている場合、PRFは機能しません。

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

3. ブラウザ： ウェブアプリケーションのインターフェースとして、ブラウザはWebAuthn JavaScript APIを実装し、特にprf拡張機能を認識し、ウェブからのリクエストをOS/認証器向けの適切なコマンドに変換し、コンテキスト文字列で入力をハッシュ化するという重要なセキュリティステップを処理し、結果を正しく解析してアプリケーションに返す必要があります。

これら3つの層（認証器の機能、OSによる公開、ブラウザの実装）のいずれかで障害やサポートの欠如があると、PRF拡張機能は動作しません。

このシーケンス図は、これらの要素がどのように連携してPRFサポートを実現するかを簡略化して示しています。

PRFワークフローが機能するには、WebAuthn ↔ CTAPチェーンのすべてのレイヤーが連携する必要があります。\明確にするために、議論を（1）ブラウザ＋オペレーティングシステムの動作と（2）認証器の動作に分けて説明します。

広範なPRFサポートへの道のりは、ウェブ標準拡張機能に共通する課題を浮き彫りにします。つまり、実装はしばしば段階的に行われ、プラットフォーム固有の問題を解決する必要があります。私たちはこの表を最新の状態に保つよう努めますが、PRF拡張機能は互換性チェーン全体が適応する必要がある最新の追加機能の1つであるため、継続的な調整が予想されることを念頭に置いてください。

以下に、オペレーティングシステムごとのサポート状況をまとめます。

WindowsでのWebAuthn PRF拡張機能のサポートは限定的です。ネイティブのプラットフォーム認証器（Windows Hello）には現在、必要なhmac-secret機能が欠けているためです。したがって、PRF機能は外部のセキュリティキーに依存します。

macOS 15では、プラットフォーム認証器のPRFサポートが導入されました。SafariとChromeの両方がiCloudキーチェーン経由でPRFをサポートしています。プラットフォーム認証器に対するFirefoxのサポートはまだ保留中です。セキュリティキーはChromeでのみ動作します。

iOSおよびiPadOSの状況はmacOSと同様で、PRFはiCloudキーチェーン経由で動作します。しかし、重大な注意点があります。iOS 18の初期バージョンにはデータ損失につながる可能性のあるバグがあり、外部セキュリティキーのサポートはまだ実装されていません。

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

上記の表には、ファーストパーティのパスキープロバイダーのサポートに関する最も重要な組み合わせを含めました。しかし、パスワードマネージャーをサードパーティのパスキープロバイダーとして使用する場合、その特定の機能は別途考慮する必要があります。例えば、1PasswordはAndroid版ではPRFをサポートしていますが、iOS版ではサポートしていません。また、認証器としてのChromeプロファイルはprfをサポートしていません。認証器の詳細については以下を参照してください。

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

1. PRFサポートなし：古いプラットフォーム認証器（例：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で動作します。

4. 完全なCTAP 2.2準拠（PRF + 作成時に最初のPRF値）：パスキーを同期するプラットフォーム認証器（iCloud KeychainやGoogle Password Managerなど）は、リクエストに応じて、navigator.credentials.create()の時点ですでに最初のPRF出力を返すことができ、鍵確立フローを効率化します。

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

インタラクティブなWebAuthn PRFデモアプリケーションを使用して、WebAuthn PRF拡張機能を直接体験できます。このデモでは、以下のことが可能です。

• PRFを使用してパスキーを登録し、お使いの認証器がこの強力な拡張機能をサポートしているか確認する。
• パスキーを使用して認証し、PRFによって生成された暗号学的値が実際に動作するのを見る。

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

少し時間を取ってデモを試し、ご自身の環境のPRF対応能力を理解することは、ユーザーに合わせた安全なパスワードレス体験を計画する上で役立ちます。

PRFの力を試す準備はできましたか？上の画像をクリックするか、このリンクをたどって、実践的な探求を始めましょう。

WebAuthn PRF拡張機能は、データの保存や導出に関連する唯一のWebAuthn拡張機能ではありません。パスキーPRFは他とどう違うのでしょうか？

• PRF vs. credBlob / largeBlob：

  • credBlob：クレデンシャルと共に、おそらく作成時に、小さな（32バイト）静的なブロブを保存できます。これは主に秘密情報のために設計されたものではなく、特に発見不可能なクレデンシャルでのサポートは限られています。

  • largeBlob：_発見可能な_クレデンシャルでより多くのデータ（約1KB）を保存でき、多くは証明書のような補助データを対象としています。サポートも限られています（iOS 17以降、iCloudキーチェーンでサポートされていますが、GPMではサポートされていません）。Chromeの開発者は、ほとんどのユースケースでlargeBlobよりもPRFに焦点を当てることを明確に支持していますが、将来的には開発が行われる可能性もあります。

  • PRF： 対照的に、PRFは静的なブロブを保存するのではなく、認証中にハードウェアに紐づいた秘密情報を使用して、_オンデマンドで_秘密鍵を_導出する_ために特別に設計されています。一般的に、パスキーに紐づいた暗号鍵を導出するための最も適切で安全な標準メカニズムと見なされています。秘密情報のためのブロブの議論から、PRFの標準化と実装への焦点の移行は、このユースケースのための専用ソリューションとしてPRFに収束していることを示唆しています。

• PRF vs. パスワード由来の鍵（例：PBKDF2）： 伝統的に、クライアントサイドの暗号鍵はユーザーのパスワードから導出されていました。PRFは大きな利点を提供します。

  • より強力なソース： 鍵は、潜在的に脆弱または再利用されたパスワードではなく、認証器内の強力な暗号素材から導出されます。

  • フィッシング耐性： 鍵の導出は、フィッシング耐性のあるWebAuthn認証フローに結びついています。

  • パスワードレス： パスワードを一切必要とせずに、保管庫の復号などのユースケースを可能にします。

• PRF vs. 他のWebAuthnデータ： WebAuthnレスポンスの他の部分（署名、authenticatorData、公開鍵など）から鍵を導出しようとすることは、根本的に安全ではなく、不適切です。これらのコンポーネントは公開されているか、秘密ではなく、鍵導出ではなく検証のために設計されています。

WebAuthnクレデンシャルやパスキーに直接リンクされた暗号鍵素材を安全に導出するためには、WebAuthn PRF拡張機能が専用に構築された推奨される標準的なアプローチです。

PRF拡張機能をアプリケーションに統合する際は、以下の実践的なガイドラインを考慮してください。

以下の推奨事項は、開発者がPRF拡張機能サポートの現状を効果的に把握し、将来の発展に備えるのに役立ちます。

• PRFをオポチュニスティックに扱う：**WebAuthn PRF拡張機能**のサポートは現在、ブラウザ、オペレーティングシステム、認証器によって大きく異なります。したがって、PRFの統合はコアな依存関係ではなく、機能強化として扱うべきです。

• PRFへの致命的な依存を避ける：\ミッションクリティカルな機能にPRFを必須にすることは避けてください。現在のサポート、特にmacOS上のSafariやiOSのようなプラットフォームでは、依然として一貫性がなく不完全です。

• パスキー紛失シナリオに備える：\PRFから導出された鍵で暗号化されたデータは、その特定のパスキーに排他的に紐づけられていることを忘れないでください。パスキーを失うと、暗号化されたデータは永久にアクセスできなくなります。常に堅牢なバックアップと回復メカニズムを実装してください。

• 2026年までの広範なサポートを予測する：\PRF拡張機能のサポートは急速に成熟しています。2026年までには、主要なブラウザ、オペレーティングシステム、認証器、特にファーストパーティのパスキープロバイダーで一貫した利用可能性が期待されます。

• Windowsエコシステムを監視する：[Windows Hello](/glossary/windows-hello)を介したプラットフォーム認証器のサポートは現在ありません。Windows環境での完全なPRF統合は、Microsoftの採用戦略に大きく依存しているため、このエコシステムを注意深く観察し続けてください。

これらのガイドラインに従うことで、開発者は採用段階で互換性とセキュリティを維持しながら、スムーズにPRFを組み込むことができます。

PRFが全体的なパスキー戦略とどのように連携するかを理解することで、不必要な複雑さを伴わずにその利点を最大限に活用できます。

• 柔軟な統合：[パスキー作成](/blog/passkey-creation-best-practices)の瞬間にPRFを活用するかどうかを決める必要はありません。既存のパスキーは、後から追加のクレデンシャル管理のオーバーヘッドなしに、PRFのユースケースとシームレスに統合できます。

• PRFの後付け：\PRFは認証フェーズ（navigator.credentials.get()）で動作するため、以前に作成されたパスキーも後からPRFベースのワークフローをサポートできます。これにより、アプリケーションは確立された認証方法を妨げることなく、段階的にセキュリティを強化できます。このアプローチは、iCloudキーチェーンやGoogleパスワードマネージャー（GPM）、および新しいセキュリティキーで機能します。古いセキュリティキーの場合、hmac-secretはクレデンシャル作成時に要求された場合にのみ生成されることがあります。

• パスキーの複雑さに関する考慮事項：\クレデンシャルの同期、クロスデバイス認証、回復プロセスなど、パスキー管理に固有の複雑さは、PRFを使用する場合にも同様に適用されます。PRFの実装が、全体的なパスキー認証戦略と一貫して連携し、合理化されたユーザーエクスペリエンスと堅牢なセキュリティ制御を維持するようにしてください。

PRFを包括的なパスキー戦略の一部として考慮することで、より安全でユーザーフレンドリーな認証手法へのスムーズな移行が可能になります。

機密性の高いユーザーデータを扱うエンタープライズサービスプロバイダーにとって、パスキーと並行してWebAuthn PRFを活用する能力は、セキュリティとユーザーエクスペリエンスを向上させる可能性を広げます。特に、個人を特定できる情報（PII）のクライアントサイド暗号化や、エンドツーエンド暗号化を必要とするアプリケーションの保護といったシナリオで有効です。Corbado Connectは主にシームレスなエンタープライズ向けパスキー統合のために設計されていますが、SPCやPRFといったパスキー拡張機能の実装も促進できます。

CorbadoがPRFの統合を検討している組織をどのように支援できるかを以下に示します。

• 暗号化ストレージのためのPRFの促進： エンタープライズ環境では、機密情報を安全に保存する必要がある場合があります。サーバーサイドのPII露出を最小限に抑えるために、クライアントサイドで直接保存することもあります。Corbado Connectは、パスキー認証フロー（navigator.credentials.get()）中にPRF値を要求するように設定でき、アプリケーションが必要な暗号鍵を導出できるようにします。
• 柔軟なストレージパターン： PRFから導出された鍵を使用して暗号化されたデータは、セキュリティ要件とアーキテクチャに応じてさまざまな方法で保存できます。
  • クライアントサイド： localStorageやセキュアなCookieなどのメカニズムを使用してブラウザに直接保存されます。平文データは、復号時にクライアント上で一時的にのみ存在します。
  • Corbadoバックエンド（E2EE）： Corbadoは通常、顧客のPIIを保存しませんが、PRFメカニズムは技術的に_クライアントサイドで暗号化された_データをCorbadoのサーバーに保存することを可能にします。Corbadoはこのデータを復号する鍵を持たず、復号は成功したユーザー認証後にクライアントサイドで行われます。
  • クライアントのバックエンド： 暗号化されたデータは、エンタープライズ自身のバックエンドシステムに送信して保存することもでき、引き続きクライアントサイド暗号化の恩恵を受けられます。
• 安全な鍵導出フロー： Corbado Connectコンポーネントは、WebAuthn APIとの対話を管理します。PRFが要求されると：
  1. ユーザー固有のPRF出力が、個々のパスキーに紐づいて認証器によって生成されます。
  2. この出力は、クライアントサイドのアプリケーションに安全に返されます。
  3. アプリケーションは、WebCrypto API（例：HKDF）を介して鍵導出関数（KDF）を使用し、PRF出力から堅牢な対称暗号鍵を導出する必要があります。
  4. この対称鍵は、WebCrypto（例：AES-GCM）と共に使用され、対象の情報（PIIなど）を暗号化または復号します。
• 次回ログイン時のシームレスな復号： ユーザーが同じパスキーを使用して再度認証すると、Corbado Connectが同じPRFリクエストを開始します。これにより同一のPRF出力が得られ、アプリケーションは_同じ_対称鍵を再導出して、以前に保存された情報をクライアントサイドで復号できます。
• PRF採用インテリジェンス： PRFを実装するには、ユーザーの環境（OS、ブラウザ、認証器）がそれをサポートしているかを知る必要があります。Corbado Connectは、認証中にユーザーのデバイスと機能に関するシグナルを収集します。このインテリジェンスは、以下に利用できます。
  • PRF依存の機能を完全に有効にする_前に_、ユーザーベース全体でのPRF準備状況を判断する。
  • PRFをオポチュニスティックに実装し、サポートされているユーザーには機能強化として提供し、サポートされていないユーザーにはフォールバックメカニズム（再検証のプロンプトや代替方法の使用など）を維持する。
• PIIの可用性の合理化： PRFを使用して検証済みのPII（例：検証フローで取得したID属性）を暗号化し、クライアントサイドに保存することで、アプリケーションはパスキーログイン後にこのデータを後続の対話や取引ですぐに利用できるようにし、再検証やアプリベースのフローと比較して摩擦を大幅に削減します。
• カスタムE2EEシステムの実現： Corbado Connectは標準フロー用のUIコンポーネントを提供しますが、その基本原則により、開発者はPRF機能を機密性の高いアプリケーションにより深く統合できます。これにより、フロントエンドアプリケーションが既存または新規のデータに対する複雑な暗号操作にPRF由来の鍵を直接活用する、エンドツーエンド暗号化システムを構築できます。当面の間、これは依然としてオポチュニスティックにのみ可能であり、フォールバックメカニズムはこれらの情報を保存するために別の方法を実装する必要があります。

Corbadoは、パスキーとPRF統合の複雑さを簡素化し、エンタープライズが標準を安全かつ効果的に活用し、進化する状況に対応しながらクライアントサイドのPII暗号化などの特定のユースケースに適応できるようにすることを目指しています。

WebAuthn PRF拡張機能は、真にパスワードレスでエンドツーエンド暗号化されたアプリケーションを現実のものにするための重要な一歩を示しています。パスキーを活用して暗号鍵を安全に導出することで、プライバシーを損なうことなく、シームレスで安全なユーザーエクスペリエンスを提供します。

この記事の冒頭で提起された質問に直接答えます。

• 興味深いPRFのユースケース： PRFは、エンドツーエンドで暗号化されたデータストレージ、パスワードマネージャーのためのパスワードレス保管庫復号、安全な暗号鍵ローテーションスキーム、そして秘密鍵がクライアントデバイスから決して離れないことを保証することでユーザーのプライバシーを保護する安全なIDウォレットや非管理型システムなど、魅力的なユースケースを可能にします。

• PRFサポートの現状（2025年6月）： サポートは依然として断片的で進化の途上にあります。Androidはブラウザと認証器全体で堅牢なサポートを持っていますが、macOSや特にiOSのようなプラットフォームは、特に深刻なバグを伴うCDAソースとして不安定です。Windowsのサポートは主に外部セキュリティキーに限定されており、Windows Helloを介したネイティブプラットフォームのサポートは著しく欠けています。

PRF拡張機能を検討している開発者は、急速な改善を期待しつつも、現在の制限を適切に処理できる回復力のあるアプリケーションを構築し、慎重に進めるべきです。主要なプラットフォームや認証器エコシステムでより広範な採用が進むにつれて、PRFによるパスワードレス暗号化の未来は明るく、ウェブ認証におけるプライバシーと使いやすさの向上を約束します。