Google同期パスキーに未修正の構造的欠陥、マスターキー窃取後は無効化できず
2026年8月7日 01:01
Palo Alto Networksの脅威インテリジェンス部門Unit 42は、Googleの同期パスキーシステムに構造的な欠陥が存在することを明らかにした。Windows版Chromeのプロセスメモリからパスキーのマスターキーが抽出される可能性があり、一度盗まれたキーはローテーションや無効化ができない。現時点でこの問題に対する根本的な修正は提供されておらず、エンドポイントのマルウェア対策を徹底することが求められる。
■Googleパスキーに潜む構造的欠陥
パスキーは認証情報の窃取を過去のものにするはずだった。しかし、Palo Alto Networksの脅威インテリジェンス部門Unit 42の新たな調査により、Googleの同期パスキーシステムには、現時点で修正策のない構造的な欠陥があることが明らかになった。被害者のGoogleアカウント内にあるすべてのパスキーを暗号化する32バイトのマスターキーが、Chromeのプロセスメモリを平文で通過する。このため、一般的なエンドポイントマルウェアによって抽出される可能性があり、一度盗まれるとローテーションや無効化ができない。Unit 42は2026年8月3日に調査結果の全容を公開した。
マルウェアを駆除し、パスワードを変更して、侵害への対処を終えたと考えている人が知っておくべきなのは、キーが盗まれた場合、現時点ではそれを無効にする手段がないという点である。被害者が今後、同じGoogleアカウントで作成するすべてのパスキーも、盗まれたものと同じマスターキーによって保護されることになる。
Unit 42の研究者Arie Olshteinは、2026年8月3日、「Pass the Passkey: A Novel Attack Surface in Passwordless Authentication」と題する論文で調査結果を発表した。この開示では、トラステッドプラットフォームモジュール（TPM）を搭載したWindowsデバイス上のChromeで動作するGoogleパスワードマネージャーを標的とした、3つの異なる攻撃経路が特定されている。これらは総称して「Pass-ta-key」と名付けられた。3つの攻撃はいずれもWebAuthnの基盤となる暗号技術を破るものではなく、被害者のデバイスにマルウェアがすでに存在することを前提としている。そのうち少なくとも1つは、マルウェアを削除した後も無期限に続く侵害を引き起こす。
■最初の攻撃前の偵察
すべてのPass-ta-key攻撃は偵察から始まるが、その偵察に特別な権限や手法は必要ない。
Chromeは、同期されたパスキーのメタデータを「%LocalAppData%\Google\Chrome\User Data\
■攻撃1：指紋スキャンなしのサイレントログイン
基本的なPass-ta-key攻撃では、通常の非特権ユーザーとして実行されるマルウェアが、パスキー認証フローにおいて被害者のChromeになりすますことができる。生体認証のプロンプトもデバイスのロック解除も必要なく、被害者に気づかれることもない。
この仕組みは、ChromeがWindows上でデバイスIDキーを処理する方法を悪用する。ChromeはTPMで保護されたキーを作成した後、Windows Cryptography API: Next Generation（CNG）を使い、暗号化されたBLOBとして直ちにエクスポートする。技術的には「NCRYPT_OPAQUE_KEY_BLOB」と呼ばれる形式である。ChromeはこのIDキーをBLOBとしてエクスポートし、ディスク上の「passkey_enclave_state」というファイルに保存する。重要なのは、このBLOBのエクスポートと再インポートに管理者権限が必要なく、ユーザー向けのセキュリティプロンプトも表示されないことだ。この種類のキーに対するTPMの暗号学的な保護は、使用のたびに厳格な承認を求めることではなく、デバイス間の移植性を実現する目的で設計されているためである。
マルウェアはBLOBを読み取り、標準のCNG APIを使ってインポートしたうえで、GoogleのCloud Authenticatorへのリクエストに署名する。マルウェアと正規のChromeを区別できないCloud Authenticatorは、有効なWebAuthnアサーションを返す。攻撃者はそのアサーションを、Googleのパスキーを信頼する任意のウェブサイトに転送し、被害者のアカウントにアクセスする。
■「生体認証必須」が生体認証を意味しない場合
WebAuthnの認証応答には、デバイスが署名前に実際にユーザー本人を確認したかどうかを示すビットが含まれている。これはユーザー検証（User Verified、UV）フラグと呼ばれる。W3CのWebAuthn仕様では、このフラグはオーセンティケーターデータのバイト内にあるビット2として定義されている。ChromeがデバイスIDキーを使用する場合、UVフラグは0に設定される。一方、Windows Helloの指紋認証やPINで保護された別のUVキーを使用する場合、UVフラグは1に設定される。
パスキー設定を「userVerification = required」としているウェブサイトは、UVフラグが0のアサーションを拒否することになっている。しかし実際には、一部のサイトがこのフラグを確認していない。
Unit 42は、「userVerification = required」を設定しながら、受信したアサーションのUVフラグを検証していなかったサイトとしてeBayを特定した。その結果、eBayの設定では名目上、ユーザー検証が必須だったにもかかわらず、生体認証を一切行わずにパスキーによるログインが成功した。eBayはUnit 42の報告を受け、その後この問題を修正した。研究者らは、この不備はeBayに限ったものではないと指摘し、すべてのリライングパーティに対してUVフラグの検証処理を監査するよう求めている。
■被害者のデバイスなしでのパスキー攻撃（Silver Pass-ta-key）
「Silver Pass-ta-key」攻撃は、被害者のUVキーを攻撃者が制御するキーに置き換える。これにより攻撃者は、最初の侵害後は被害者のデバイスにアクセスしなくても、自身のマシンからUV検証を通過できる。
既存のUVキーを無効にするのは難しくない。攻撃者はIDキーを使ってデバイスを登録解除するコマンドを発行するか、単に「passkey_enclave_state」ファイルを削除できる。このファイルの削除を防ぐOSレベルの保護はない。Chromeは状態ファイルがなくなったことを検出し、被害者が次にパスキーを使用する際に再オンボーディングを開始する。
再オンボーディング中、Chromeは「uv_key_pending」と呼ばれる保留状態に入り、実際のUVキーはまだ作成されない。これはユーザー体験への配慮によるものだ。Chromeがオンボーディング中にUVキーを直ちに作成すると、Windows Helloの生体認証プロンプトとGoogleパスワードマネージャー（GPM）のリカバリPINプロンプトを続けて表示する必要があり、ユーザーを混乱させる可能性がある。そのためChromeは、UVキーの作成を次回のパスキー使用時まで先送りする。
この保留期間中、攻撃者は独自の非対称鍵ペアを生成し、攻撃者の公開鍵をUVキーとして指定した「device/add_uv_key」コマンドをCloud Authenticatorに送信する。GoogleのCloud Authenticatorは、新たに登録されるUVキーが安全なハードウェアで生成されたものかどうかを確認するためのアテステーションを検証しない。このため、アテステーションのない新規UVキーも受け入れる。それ以降、攻撃者は正規のものとして認識されるUVキーを保有し、被害者のデバイスをオンラインにすることなく、自身のマシンからUVフラグを1にして被害者のアカウントに認証できる。
■取り消し不可能：マルウェア駆除だけでは不十分な理由（Golden Pass-ta-key）
「Golden Pass-ta-key」攻撃は、その影響が侵害への対処後も残るため、3つの中で最も重大である。
Googleアカウント内のすべての同期パスキーは、Security Domain Secret（SDS）と呼ばれる単一の対称マスターキーで暗号化されている。この32バイトのキーは本来、隔離された暗号環境で保護されたGoogleのCloud Authenticator内にとどまることが想定されている。ユーザーのアカウントに同期されたパスキーの秘密鍵はSDSで暗号化されており、Chromeは同期パスキーを使用する前に、Cloud AuthenticatorにSDSのラップ解除を要求しなければならない。
しかし、デバイスの登録および再登録時には、SDSをGoogleのクラウドインフラからChromeへ送る必要がある。Chromeに到着したSDSは、一時的ではあるものの、攻撃者が取得できるだけの時間、プロセスメモリ上に平文で置かれる。
Unit 42は当初、さらにアクセスしやすい場所でSDSを発見した。「chrome://device-log/FIDO」から表示できるChrome内蔵のデバイスログで、SDSがJSON出力に平文で記録されていた。GoogleはUnit 42による責任ある開示を受け、このログへの露出を修正した。
しかし、ログを修正しても侵入経路が完全に閉じられたわけではない。SDSは再登録時に、依然としてChromeのプロセスメモリへ送られる。Silver攻撃と同じ「passkey_enclave_state」ファイルの削除手法で再登録を強制し、適切なタイミングでChromeのプロセスメモリをダンプすれば、攻撃者はSDSを抽出できる。6段階からなるGolden攻撃を実行することで、攻撃者はChromeの同期データベースにあるすべてのパスキーの秘密鍵を復号する。
SDSを手にした攻撃者は、Chromeの同期データベースに保存された過去および将来のすべてのパスキーの秘密鍵を復号できる。Cloud Authenticatorも不要になる。攻撃者はWebAuthnの認証チャレンジに直接署名し、Googleの同期パスキーを利用する任意のウェブサイトで被害者になりすますことができる。
そして、現時点で修正策がないのが次の問題だ。Googleの実装にはSDSをローテーションする仕組みがない。攻撃者が一度SDSを入手すれば、その効力は恒久的に残る。感染を発見してマルウェアを削除し、パスワードを変更しても保護されない。侵害中に抽出されたSDSによって、引き続きすべてのパスキーを復号できるためだ。今後、同じGoogleアカウントで作成するパスキーも、盗まれたものと同じSDSで暗号化される。
Unit 42は、SDSがメモリ上に置かれる理由の一部をクロスプラットフォーム互換性にあるとしている。iOSおよびAndroid上のGoogleパスワードマネージャーはCloud Authenticatorモデルを使用せず、同期パスキーを復号するためにSDSを直接受け取る必要がある。理論上はCloud AuthenticatorがSDSをクライアントに送ることなく復号処理を実行できるが、Windows版Chromeもデフォルトでは同じリカバリモデルを採用している。
■Googleが修正した点と未解決の課題
Googleは、Unit 42による責任ある開示を受けて、「chrome://device-log/FIDO」におけるSDSのログ露出を修正した。eBayも通知を受けた後、UVフラグの検証不備を修正した。Googleはまた、同期パスキーシステムにおける署名カウンターの一貫性に関する課題を認識している。複製された認証情報を検出するための「signCount」メカニズムは、同期型の実装では通常、一定の値を返す。このため、リライングパーティが認証情報の異常な使用を検出する能力が低下する。
公開時点で未解決だった問題は次の通りである。再登録時に、SDSが引き続きChromeのプロセスメモリを平文で通過する。GoogleのCloud Authenticatorが、新たに登録されるUVキーのアテステーションを検証しない。SDSをローテーションする仕組みが存在しない。「passkey_enclave_state」ファイルには、削除を防ぐOSレベルの書き込み保護がない。
■ウェブサイト開発者とセキュリティチームが今できること
Unit 42は、各レイヤーに対して具体的な対策を示している。
ウェブサイトおよびアプリ開発者は、WebAuthn設定で「userVerification = required」を指定するだけでなく、認証応答を受け入れる前に、毎回UVフラグを実際に検証する必要がある。名目上はユーザー検証を必須としていても、UVビットを確認しない設定には、ユーザー検証を要求しない設定と比べてセキュリティ上の利点がない。Unit 42の緩和策の項目では、この確認を実装するためのオーセンティケーターデータの構造が詳しく説明されている。
認証情報マネージャーおよびプラットフォームのベンダーは、新たに登録されるデバイスキーについて、IDキーとUVキーの双方を受け入れる前に、ハードウェアのアテステーションを検証する必要がある。SDSを含む機密性の高い鍵情報は、復号可能な形でクライアント環境へ転送すべきではない。Cloud Authenticatorが生のキーをクライアントへ送ることなく、サーバー側で暗号処理を実行すべきである。
企業のセキュリティチームは、GPMリカバリPINフローが予期せず起動した場合にアラートを出す必要がある。通常、このフローが表示されるのはデバイスを初めて登録するときだけであり、日常的なパスキー認証中には表示されないはずだ。予期しない再オンボーディングのプロンプトは、特にChromeのパスキー状態ファイルが削除または変更された後に表示された場合、侵害を示す可能性のある兆候として扱う必要がある。また、プラットフォームのアクセス制御を使い、LevelDB同期データベースや「passkey_enclave_state」ファイルなど、パスキー関連の保存先へのアクセスをChromeブラウザのプロセスだけに制限すべきである。
■パスキーは依然としてパスワードより優れている（ただし注意点あり）
これらの発見によって、パスキー導入の妥当性が覆るわけではない。パスキーは、過去20年間の大規模なアカウント侵害の大半を引き起こしてきたフィッシング、クレデンシャルスタッフィング、パスワードの使い回しによる攻撃を排除する。Pass-ta-keyの調査が示しているのは、セキュリティが失われたということではなく、脅威モデルが変化したということだ。
ここで説明した攻撃には、エンドポイント上にすでに存在するマルウェアが必要である。デバイス上でコードを実行できない攻撃者は、これらの攻撃経路を利用できない。個人ユーザーにとっては、パスキーへ完全に移行した後も、マルウェア対策ソフト、迅速なOSアップデート、悪意のあるnpmパッケージやトロイの木馬化されたソフトウェアといった情報窃取型マルウェアの侵入経路への警戒など、エンドポイントセキュリティが引き続き不可欠だということを意味する。Unit 42は、これらの攻撃はパスキーの暗号技術を破るのではなく、設計上の想定と現実の実装との間にある隙を悪用するものだと結論付けている。
Pass-ta-keyの調査は、Unit 42とCyberArkが共同で進めてきたGoogleのパスキーアーキテクチャに関する調査シリーズの第3弾である。CyberArkが公開した第1弾では、パスキーのエコシステムを世界規模で検証した。Unit 42が公開した第2弾では、GoogleのCloud Authenticatorの仕組みを詳しく説明している。
なお、Unit 42はサイバーセキュリティベンダーであるPalo Alto Networksの脅威調査部門である。本調査は責任ある開示のガイドラインに基づいて実施され、公開前にGoogleとeBayへ通知された。
■注目ポイントQ&A
●指紋認証が必要な設定にしていても、パスキーが盗まれることはありますか？
はい、特定の状況ではあり得ます。Silver Pass-ta-key攻撃が示すように、Chromeが動作するエンドポイントを一時的に侵害した攻撃者は、デバイスのUV（ユーザー検証）キーの状態を削除し、自身が制御するUVキーを代わりに登録できます。この際、Windows Helloを回避したり、被害者の指紋センサーに触れたりする必要はありません。代替キーが登録されると、Cloud Authenticatorは攻撃者のキーによる確認を正規のユーザー検証として受け入れます。パスキーでログインする前に指紋確認を要求しているサイトも、この置き換え後は、知らないうちに攻撃者自身のマシンで行われた確認を受け入れる可能性があります。
●Security Domain Secret（SDS）とは何ですか？なぜ変更できないのですか？
Security Domain Secretは、Googleアカウントの同期データベースに保存されたすべてのパスキーの秘密鍵を暗号化する、32バイトの対称キーです。同期されたパスキー全体に対する単一の暗号化ルートとなります。Googleの現在の実装ではSDSをローテーションできません。新しいSDSを生成し、保存されているすべてのパスキーを新しいキーで再暗号化する仕組みがないためです。Googleは、課題管理システムでこのアーキテクチャ上の問題を認識しています。SDSがChromeのプロセスメモリを通過するのは、クロスプラットフォーム互換性を考慮した設計によるものです。iOSおよびAndroid上のGoogleパスワードマネージャーはCloud Authenticatorモデルを使用せず、同期パスキーを復号するためにSDSを直接受け取る必要があります。
●デバイスがマルウェアに感染し、その後駆除した場合でも、パスキーは侵害されたままですか？
デバイスからマルウェアを駆除する前に、攻撃者がSecurity Domain Secretを抽出していた場合、その可能性があります。SDSはローテーションできないため、侵害中にSDSを取得した攻撃者は、パスキーの秘密鍵を無期限に復号できる状態を維持します。マルウェアの削除、パスワードの変更、さらにはパスキーの再登録を行っても、盗まれたSDSは無効になりません。Windows版Chromeでパスキーを使用していた期間にデバイスが侵害された可能性がある場合は、特に重要なサービスについて新しいGoogleアカウントを作成し、異なるSDSを持つそのアカウントでパスキーを再登録することを検討してください。
●これらの攻撃は、AppleデバイスやAndroidスマートフォンのパスキーにも影響しますか？
Pass-ta-keyの調査は、Cloud Authenticatorモデルを使用するデスクトップ環境、具体的にはWindows版ChromeのGoogleパスワードマネージャーを対象としています。AppleのiCloudキーチェーンとAndroidの認証情報マネージャーは異なるアーキテクチャを使用しており、この調査では分析されていません。Unit 42は、Cloud Authenticatorモデルが複数のブラウザやプラットフォーム上のさまざまなパスキープロバイダーで使われているため、同様のアーキテクチャ上の問題が別の環境にも当てはまる可能性があると指摘しています。ただし、この調査でAppleまたはAndroidに固有の脆弱性が開示されたわけではありません。
元記事: Google Passkey Master Key Leaks to Chrome Memory and Cannot Be Revoked