2025年末時点で、世界70億件以上のオンラインアカウントがパスキーによるサインインに対応している。Googleはパスキーがパスワードより40%高速にサインインできると報告し、Intuitは97%のサインイン成功率を達成した。Apple、Google、Microsoftが2022年5月に共同でFIDO標準の拡大支持を表明して以来、「パスワードの時代は終わる」という物語は着実に現実味を帯びてきた。
この物語の技術的支柱がパスキー（FIDO2/WebAuthn規格に基づく同期可能な認証資格情報）である。公開鍵暗号により、サーバー側には秘密鍵が一切渡らない。フィッシングで偽サイトに誘導されても、窃取できる認証情報がない。資格情報の大量漏洩（データベース侵害）も意味をなさない。パスワードが抱えていた脆弱性のカテゴリそのものを消去する設計だった。
Googleはこのパスキーをクラウド同期に対応させる際、利便性以上のものを約束した。同社は公式にこう述べている。「（クラウド）エンクレーブ認証器の主要な機能は、パスキーの秘密データを窃取しにくくすることである。もしローカルに利用可能であれば、マルウェアの明白な標的になるからだ」。つまり、Googleのクラウド認証器（Cloud Authenticator）は、エンドポイントが侵害されてもパスキーの秘密鍵を守ることを明示的な設計目標としていた。
その設計目標が、2026年8月3日に公開されたUnit 42の研究「Pass the Passkey: A Novel Attack Surface in Passwordless Authentication」によって、3つの異なる角度から突き崩された。
「暗号を破らない」攻撃がなぜ成立するのか
まず前提を整理する。Unit 42が示した攻撃は、パスキーの暗号的基盤（P-256 ECDSA署名、公開鍵暗号の数学）を一切破っていない。FIDO Allianceが繰り返し強調してきた「パスキーの暗号自体に脆弱性はない」という主張は、この研究によっても揺らいでいない。
攻撃が突いたのは、Chromeがデバイスの信頼を管理し、資格情報のメタデータを保存し、クラウドへの再登録を処理する「運用層」である。暗号が金庫の鍵そのものだとすれば、Unit 42が示したのは金庫の鍵ではなく、金庫を管理する係員の動きの隙間だった。
すべての攻撃に共通する前提条件がある。被害者のWindowsマシンにマルウェアがすでに存在していること。ただし、管理者権限や特権昇格は不要である。通常のユーザー権限で動作するマルウェアで十分だ。
3段階で深まる侵害の全体像
Unit 42は攻撃を3つのレベルに分類した。それぞれが前の攻撃の限界を克服する構造になっている。
| 攻撃名 | 必要な条件 | 得られるもの | UVフラグ | 持続性 |
|---|---|---|---|---|
| Pass-TA-Key | 非特権マルウェア | 単発のログインアサーション | 0（未検証） | なし（1回限り） |
| Silver Pass-TA-Key | 同上＋再登録のトリガー | 攻撃者自身のUV鍵の登録 | 1（検証済み） | 半永続（再登録まで） |
| Golden Pass-TA-Key | 同上＋メモリダンプ | 全同期パスキーの秘密鍵 | 1（検証済み） | 永続（SDSローテーション不可） |
Stage 0: 暗号化されていない索引を偵察する
攻撃の準備段階として、マルウェアはChromeのローカル同期データベースを読み取る。Windows上では、Chromeは同期されたパスキーのメタデータを %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB に保存している。このLevelDBデータベースは暗号化されておらず、proto形式の WebauthnCredentialSpecifics レコードとして、被害者がどのサービスでパスキーを使っているか、ユーザー名、資格情報ID、暗号化された秘密鍵のインデックスを平文で提供する。
特権は不要。ファイルシステム上の読み取り権限だけで十分だ。
Pass-TA-Key: 1ビットの隙間
最初の攻撃は、ChromeがTPMに格納するデバイスのアイデンティティ鍵を抽出するところから始まる。Chromeは NcryptCreatePersistedKey を鍵名なしで呼び出し、TPM内で鍵を永続化しない。代わりに NcryptExportKey で NCRYPT_OPAQUE_KEY_BLOB としてエクスポートし、passkey_enclave_state ファイルに wrapped_identity_private_key として保存する。マルウェアはこのファイルをディスクから読み取るか、Chromeのメモリから抽出できる。
抽出した鍵を使い、マルウェアはWindows標準のCNG API（NCryptOpenStorageProvider、NCryptImportKey、NCryptSignHash）を呼び出して、Googleのクラウド認証器への認証リクエストに署名する。クラウド認証器の視点では、これは信頼されたデバイスからの正当なリクエストに見える。有効なアサーションが返される。
ここで問題になるのが、WebAuthnの認証器データに含まれるUVフラグ（User Verified flag）である。これは1ビットの値で、ユーザーが生体認証やPINで本人確認を行った場合に1、行わなかった場合に0がセットされる。アイデンティティ鍵で署名した場合、このフラグは0のままになる。
本来、userVerification = required を設定しているサービス（金融機関やGitHubなど）はこのフラグが0なら認証を拒否すべきだ。実際、GitHubは正しく拒否した。しかしUnit 42のテストでは、eBayが userVerification = required を設定していながらUVフラグを検証せず、攻撃を受け入れていた。eBayは責任ある開示を受けて修正済みである。
多くのrelying party（サービス提供者）は userVerification を required ではなく preferred に設定している。これは多様なデバイスとユーザー体験をサポートするための設定だが、Pass-TA-Key攻撃に対しては実質的に無防備になる。
Silver Pass-TA-Key: 再登録を武器にする
UVフラグの検証を完全に回避するのがSilver攻撃である。マルウェアはChromeのローカルなパスキー状態（passkey_enclave_state）を意図的に破損・削除する。するとChromeはデバイスの再登録（re-enrollment）を強いられる。
ここに設計上の盲点がある。Googleのクラウド認証器は、新しく登録されるユーザー検証鍵（UV鍵）がセキュアハードウェアに由来するかどうかを検証しない。再登録プロセス中に、攻撃者は自分自身の鍵をUV鍵として登録できる。
以降、攻撃者は自分のハードウェアから、正当なUVフラグ（=1）付きのアサーションを生成できる。被害者のデバイスに一切触れることなく、完全に「本人確認済み」として認証が通る。この状態は、被害者がデバイスを再登録し直すまで持続する。
Golden Pass-TA-Key: マスターキーを盗む
最も深刻なのがGolden攻撃である。標的はSecurity Domain Secret（SDS） と呼ばれる32バイトの対称マスターキーだ。SDSはクラウド認証器がすべての同期パスキーの秘密鍵を暗号化・復号するために使う唯一の鍵であり、この設計の要である。
通常、SDSはデバイス上に暗号化された wrapped_secret としてのみ存在し、復号はクラウド認証器の隔離環境内でのみ行われる。しかしUnit 42は、デバイス登録（オンボーディング）またはアカウント復旧の際に、SDSが平文の形でChromeのプロセスメモリに一時的に展開されることを発見した。
攻撃手順はSilver攻撃と同じく再登録を強制し、passkey_enclave_state ファイルが再作成された瞬間にChromeのプロセスメモリをダンプしてSDSを抽出する。SDSを手にした攻撃者は、同期データベースに保存されたすべてのパスキーの暗号化された秘密鍵を復号し、外部に持ち出し、任意のデバイスから認証できる。
当初、Unit 42はSDSがChromeの内部FIDOログ（chrome://device-log/FIDO）に平文で記録されていることも発見した。Googleは報告を受けてログへの出力を削除したが、SDSがクライアントのプロセスメモリを通過するという根本的な問題は残っている。
そして決定的な問題がもう一つある。Googleの現在の実装には、SDSのローテーション（定期交換）やリボケーション（失効）の仕組みが存在しない。一度SDSが盗まれると、現在のパスキーに加え、将来そのアカウントに同期されるすべてのパスキーが同じマスターキーで保護され続ける。Silver攻撃はデバイスの再登録で軽減できるが、Golden攻撃に対しては、被害者が取りうる対策が事実上存在しない。
これは「パスキーの脆弱性」か。脅威モデルの境界線
この研究をどう位置づけるかは、セキュリティコミュニティで意見が分かれる問題である。
FIDO Allianceは以前から、エンドポイントが侵害された状況はパスキーの脅威モデルの範囲外だと明言してきた。FIDO仕様のセキュリティ仮定SA-3は「ユーザーデバイス上のアプリケーションが安全なチャネルを確立できること」、SA-4は「FIDO操作に関わるコンピューティング環境が信頼できるエージェントとして振る舞うこと」を前提としている。マルウェアが存在する環境は、この前提の外にある。
2025年8月には、同種の主張（マルウェアでパスキーを盗めるという研究）に対して、Ars Technicaが「パスキーの脅威モデルを誤読している」と厳しく批判した経緯もある。
しかしUnit 42の研究には、この反論がそのまま適用しにくい側面がある。Google自身が、クラウド認証器の設計目的を「マルウェアからパスキーの秘密データを守る」と明言している。ローカルのパスキー実装（例: セキュリティキーやデバイスバウンド鍵）なら「エンドポイント侵害は脅威モデル外」という議論で済むが、Googleは同期パスキーにおいて、その脅威に対する防御を追加した。その防御が突破されたなら、それは「設計目標の未達」として評価されるべきだという論理である。
Unit 42自身も、論文の免責事項で「これらの攻撃はすべて、初期段階で被害者のデバイスにマルウェアがすでに存在していることに依存する」と明記している。暗号を破ったわけでも、パスキー規格の欠陥を突いたわけでもない。しかし、Googleが「マルウェアから守る」と約束した層が、非特権マルウェアで突破されたという事実は重い。
残された問い
この研究が突きつける未解決の問題は少なくとも3つある。
第一に、SDSのローテーション機構の実装。Unit 42は、Chromeがクラウド認証器の持つ「クライアントデバイス上で復号せずに復旧フローを仲介する仕組み」を使わず、SDSをアクセス可能な形で復旧していることを指摘している。iOS/Android版のGoogle Password Managerはクラウド認証器を使わずマスターキーを直接取得する必要があるため、Chromeも同じ復旧モデルに従っている可能性が考えられるが、デスクトップ版にはより隔離されたアプローチが技術的に可能だとUnit 42は示唆している。
第二に、再登録フローにおける鍵の出所検証。Silver攻撃が成立するのは、クラウド認証器が新規登録されるUV鍵のハードウェア由来を検証しないためである。TPMアテーション（ハードウェアが鍵の生成を証明する仕組み）を再登録フローに組み込むことで防げる可能性があるが、実装のコストと互換性の問題は未検証である。
第三に、relying party側のUVフラグ検証の徹底。eBayの事例が示すように、userVerification = required を設定しながらフラグを検証しない実装が存在する。これは規格の実装ガイドラインと実際のデプロイメントの乖離であり、監査や認証制度（FIDO Certification）の範囲をどこまで広げるかという政策課題でもある。
パスキーの暗号は壊れていない。フィッシング耐性も、資格情報の大量漏洩に対する防御も、設計通り機能している。Unit 42が示したのは、その暗号を「届ける」仕組み、つまり同期とクラウド復旧の実装に、マルウェアが滑り込める隙間があるという事実である。パスワードを殺した技術が、別の殺し方に対してどこまで持ちこたえるか。その答えは、暗号ではなく実装の細部にある。
