Google Password Managerの同期パスキーが盗まれる、マスター鍵SDSに失効手段がない

TL;DR

---

Palo Alto Networks Unit 42は2026年8月3日、Google Password Managerの同期パスキーを狙う3種類の攻撃手法を公開した。
執筆はArie Olshteinで、パスキーの内部構造を扱ってきた連載の3本目にあたる。

パスキーはFIDO2/WebAuthnに基づくログイン方式で、サービスごとに公開鍵と秘密鍵の組を作る。認証器が秘密鍵で署名し、サービスへ渡るのは署名済みの認証応答だけだ。
フィッシングでパスワードを抜かれる経路が原理的に無くなるため、パスワードの置き換えとして普及してきた。Googleはこれをアカウントに同期し、複数端末で同じパスキーを使えるようにしている。

今回の3種類は、その同期のために足された部品を突く。パスキーの暗号は破られていない。
Unit 42自身が「本研究で示した攻撃は、基盤となる暗号を破るものではない」と明記している。

Windows上のChromeで、マルウェアが先に居る前提

検証されたのはWindows上のChromeに載ったGoogle Password Managerで、端末にTPM（鍵を外へ出さずに保管・署名する専用チップ）があることが前提になる。
macOSやAndroid、他のパスワードマネージャーの話ではない。

そして3種類とも、被害者の端末でマルウェアがすでに動いているところから始まる。マルウェアをどう送り込むかは扱っていない。
ただし管理者権限やSYSTEM権限への昇格はいらない。通常のユーザー権限のまま実行できる。

同期パスキーはクラウド側の認証器が持っている

Unit 42が2026年3月23日に公開した連載2本目が、Googleの同期の仕組みを先に解説している。

同期パスキーの秘密鍵は、Googleのクラウド認証器（cloud authenticator）が持っている。端末のTPMには入っていない。
Chromeは wss://enclave.ua5v[.]com/enclave へWebSocketで繋ぎ、Noiseプロトコルで保護した経路越しに署名を依頼する。

その秘密鍵を暗号化しているのがSecurity Domain Secret、略してSDSだ。アカウント単位の32バイトの共通鍵で、同期パスキーの全件をこれ1本で暗号化・復号する。
新しい端末がアカウントに加わるときは、PINで保護された復旧の仕組みを通してSDSを受け取る。

端末側には、TPMに紐づいた鍵が2本作られる。
1本は端末そのものを表す身元鍵（identity key）で、「持っているもの」にあたる。もう1本がユーザー検証鍵（UV鍵）で、Windows Helloの生体認証やPINを通ったあとだけ使われ、「知っているもの・本人であること」の証明に使う。
身元鍵の秘密部分はTPMで封をされた状態で、passkey_enclave_state というファイルに wrapped_identity_private_key として置かれる。

%LocalAppData%\Google\Chrome\User Data\<Profile>\passkey_enclave_state
%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

下のLevelDBがChromeの同期データベースで、同期パスキーは WebauthnCredentialSpecifics というレコードで入っている。Unit 42はここを読む段階を「ステージ・ゼロ」と呼んだ。
レコードにはユーザー名、資格情報の識別子、暗号化された秘密鍵が入っていて、読み出しに昇格した権限はいらない。攻撃者はまずここで、被害者がどのサービスでパスキーを使っているかを一覧できる。

3つの攻撃で取れるものが違う

攻撃	使うもの	到達点	被害者端末の要否	端末を外せば止まるか
Pass-ta-key	passkey_enclave_state の身元鍵	サービスへのログイン。UVフラグは立たない	必要（TPMで署名するため）	止まる
Silver Pass-ta-key	再登録時に偽のUV鍵を登録	UV済みとして完全自動でログイン	不要（登録後）	止まる
Golden Pass-ta-key	プロセスメモリ上のSDS	全パスキーの秘密鍵を平文で取得	不要（SDS取得後）	止まらない

flowchart TD
    A["マルウェアが動いている<br/>Windows端末"] --> B["Sync Data の LevelDB を読む<br/>ステージ・ゼロ"]
    B --> C["passkey_enclave_state から<br/>wrapped_identity_private_key"]
    C --> D["Pass-ta-key<br/>端末に成りすまして署名依頼"]
    D --> E["UVフラグなしの<br/>正当なアサーション"]
    A --> F["state ファイルを消して<br/>端末の再登録を起こす"]
    F --> G["Silver<br/>攻撃者が作ったUV鍵を登録"]
    F --> H["Golden<br/>Chromeのメモリから SDS を採取"]
    G --> I["UV済みとして<br/>アカウント乗っ取り"]
    H --> J["全パスキーを復号<br/>持ち出し・売買が可能"]

身元鍵で端末に成りすますPass-ta-key

1つ目は、passkey_enclave_state から wrapped_identity_private_key を取り出すところから始まる。この鍵はTPMで封をされているので、ファイルをコピーしても他の端末では開けない。
しかし同じ端末の上でなら、Windowsの暗号APIであるCNG（NCryptOpenStorageProvider、NCryptImportKey、NCryptSignHash）を呼んで、TPMに署名させることはできる。鍵の中身を読み取らずに、TPMに鍵を使わせている。

あとはクラウド認証器とWebSocketのハンドシェイクを開き、ハンドシェイクのハッシュと署名要求を抜き取った身元鍵で署名する。
クラウド認証器側は正規の端末からの依頼として扱い、有効なアサーション（サービスへ提出する署名済みの認証応答）を返す。攻撃者はそれをサービスへ転送すればログインが通る。

ただしこの経路には制約がある。生成されるアサーションは暗号的に正当でサービス側の公開鍵とも一致するが、UVフラグが立たない。生体認証やPINを実際に通ったことを示す1ビットで、身元鍵だけで署名した場合は0のままになる。
Unit 42の検証では、userVerification=required を要求したうえで返ってきたUVフラグまで検証しているサービスでは失敗し、要求だけで済ませているサービスでは通ってしまう。

UV鍵を偽造するSilver Pass-ta-key

そのUVフラグの制約を外しにいくのが2つ目だ。

まず passkey_enclave_state を削除するか、端末の登録解除にあたるコマンドを発行して、Chromeに端末の再オンボーディングを起こさせる。再登録の途中には、UV鍵の登録待ちにあたる uv_key_pending という状態がある。
ここで攻撃者は自前で鍵ペアを作り、その公開鍵を device/add_uv_key としてクラウド認証器へ送る。

クラウド認証器は、新しく登録されるUV鍵のアテステーション（その鍵が本当に安全なハードウェアで作られたことの証明）を検証していない。
Unit 42はここを「クラウド認証器は、新規登録されたUV鍵のアテステーションを検証せず、それが安全なハードウェア由来かどうかを確かめない」と書いている。結果として、攻撃者の手元にある鍵がユーザー検証用の鍵として通る。

これが通ると、攻撃者は自分の環境でUVフラグを立てた署名を作れる。Windows Helloの画面は出ないし、被害者の端末をその都度オンラインにしておく必要もない。
被害者側から見ると、何も表示されないまま認証が完了する。

もっとも、この攻撃は端末の登録を解除するか登録し直せば無効になる。攻撃者が登録させたUV鍵も、そのときに消える。

マスター鍵ごと持っていくGolden Pass-ta-key

入口は3つ目もSilverと同じで、再オンボーディングを強制する。

新しい端末がアカウントへ加わる瞬間、SDSは復旧の仕組みを通ってChromeへ渡される。この受け渡しの間、SDSはChromeのプロセスメモリ上に平文で存在する。
攻撃者は passkey_enclave_state の再作成や変更を監視し、その瞬間にChromeのプロセスメモリをダンプしてSDSを拾う。

SDSさえ手に入れば、あとは同期データベースから WebauthnCredentialSpecifics を取り出し、暗号化されていた秘密鍵を復号できる。
復号できるのはパスキーの秘密鍵そのものなので、他人へ渡すことも売ることもできる。

SDSはアカウント単位の1本で、現在の実装にはこれを回転させたり失効させたりする方法がない。
侵害に気づいて端末を登録解除しても、攻撃者が持っているSDSは有効なままで、その後に新しく作るパスキーも同じ鍵で暗号化される。

なお、SDSはChromeの内部ログ（chrome://device-log/FIDO）にも平文で出ていた。Googleは報告を受けてログ出力からSDSを削除している。
ただしこれはログに出さなくなっただけで、SDSがクライアントへ送られてプロセスメモリに載る構造は変わっていない。

UVフラグを検証していないサービスがある

Pass-ta-keyが弾かれる条件は、サービス側が userVerification=required を要求し、返ってきた応答のUVフラグを実際に検証していることだ。
この2つは別物で、要求だけして検証していない実装がある。

Unit 42はUVフラグを検証していないサービスを見つけ、そこではパスキーによる多要素認証が実質的に単要素まで下がると指摘した。
名前が挙がっているのはeBayで、報告を受けて修正され、現在は検証するようになっている。

このビットが入っているのは認証応答の authenticatorData で、userVerification=required を指定した場合はサービス側が明示的に検証する必要がある。
認証応答の検証処理がこのビットまで踏み込んでいないサービスでは、Pass-ta-keyのアサーションがそのまま通る。

ログからは消えたが、SDSはクライアントへ送られ続ける

Googleは報告を受けてログ出力からSDSを取り除いた。一方でUnit 42は、その修正後もSDSはクライアントへ送られ、Chromeのプロセスメモリ上に残ると報告している。
Unit 42が引用したGoogleの回答は、クラウド認証器の設計目的についての次の説明だ。

The (cloud) enclave authenticator’s primary function is to make it difficult to steal passkey private data, which would be an obvious target for malware if it were locally available.

（クラウド版の認証器の主目的は、パスキーの秘密データを盗みにくくすることにある。ローカルに置かれていれば、それは明らかにマルウェアの標的になる）

秘密鍵をローカルに置かない構成そのものが、マルウェア対策として設計されている。
今回の研究は、そのクラウド側へ寄せる過程で端末を信頼せざるを得ない箇所を対象にしている。

WebAuthnの署名カウンターは、対応している認証器なら認証が成功するたびに増える値で、複製された資格情報を見つける手掛かりになる。
Unit 42の解析では、Google Cloud Authenticatorのこの値は常に0だった。この実装では検知に使えない。Googleは、複数の端末とプラットフォームで整合したカウンターを実装するのは難しいと回答している。

Unit 42の記事は責任ある開示を経ていると書いているが、日付入りのタイムラインは載っていない。
3つの経路すべてが塞がったかどうかも、公開情報からは確認できない。

サービス側と実装側でできること

Unit 42が挙げた対策は、サービス側と実装側に向いたものばかりで、利用者が自分でできることは出てこない。

サービス側がいますぐできるのは、UV検証を厳格にすることだ。userVerification=required を要求したうえで、認証応答のUVフラグを必ず検証する。
これでPass-ta-keyの経路は塞がる。

資格情報マネージャー側に向けた項目はもっと多い。新しく登録される端末鍵のアテステーションを検証すること、状態ファイルを消しただけで再オンボーディングが始まる挙動を抑えて復旧フローを固くすること、マスター鍵をクライアント環境へ露出させず暗号処理をサーバー側で完結させること、同期データベースと passkey_enclave_state へのアクセスをブラウザプロセスに限ること、そして同期を織り込んだ署名カウンターを実装することが挙げられている。
マスター鍵をクライアントへ出さない設計は、このうちGoldenの入口を塞ぐ項目にあたる。SDSの回転や失効のほうは対策に挙がっていなくて、現行実装にその方法がないことは、Goldenが後々まで残る理由として書かれている。

パスキーの弱点として先に議論になったのは、認証用の資格情報に暗号化の役割まで持たせる設計だった。こちらはPasskeysのPRF拡張を鍵導出に使うリスクの記事に書いている。
今回のPass-ta-keyは、パスキーを複数端末で使えるようにするための同期と復旧の側から入っている。

参考

• Unit 42: Pass the Passkey — A Novel Attack Surface in Passwordless Authentication
• Unit 42: Google Cloud Authenticator — The Hidden Mechanisms of Passwordless Authentication
• BleepingComputer: New Pass-ta-key attacks let malware hijack Google-synced passkeys
• The Hacker News: Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts