パスキー万能説破れる？ Google同期パスキー実装に見つかった“想定外の穴”：利用者の操作はいらない

「パスキーは安全」。そんな認識に一石を投じる研究結果が公表された。狙われたのは暗号技術そのものではなく、Googleの同期パスキーを支える実装や復旧の仕組みだ。侵害済み端末を前提にした3つの攻撃は、認証の“信頼”をどう揺るがすのか。その手口と対策を解説する。

[＠IT]

　Palo Alto Networksは2026年8月3日（現地時間）、Googleの同期パスキー実装を狙う3つの新たな攻撃手法「Pass-ta-key」「Silver Pass-ta-key」「Golden Pass-ta-key」を公表した。

　研究では、マルウェアによって侵害された「Windows」端末上で通常ユーザー権限で動作する攻撃コードが、パスキーの登録や復旧、信頼確認の仕組みを悪用し、利用者の操作や端末解除なしで認証を成立させたり、同期パスキーを保護する暗号鍵を取得して秘密鍵を復元したりできる可能性が示された。

同期パスキー実装の隙を突く3手法　暗号を破らず認証を突破

　パスキーは公開鍵暗号を利用し、パスワードのような共有秘密を不要にすることで、フィッシングや認証情報の使い回しといった攻撃を防ぐ技術だ。Googleの同期パスキーでは、秘密鍵をクラウドの隔離環境で保護し、端末にひも付いた鍵を利用して認証を実施する。今回の研究は暗号そのものを破るものではなく、同期や復旧を支える実装や運用上の前提を悪用する点に特徴があるという。

　攻撃の準備段階では、「Google Chrome」（以下、Chrome）がWindows端末内に保存する同期データが利用される。「WebAuthnCredentialSpecifics」形式のデータには、利用するサービス名やユーザー名、認証情報識別子に加え、暗号化された秘密鍵などが保存されており、通常ユーザー権限でも参照できる。ただし、この時点で秘密鍵が平文で取得できるわけではない。

1．Pass-ta-key攻撃

　最初のPass-ta-key攻撃では、攻撃者はChromeの正規動作になりすまして「Cloud Authenticator」に認証要求を送り、その結果をサービスに転送する。Chromeの端末識別鍵はTPM（Trusted Platform Module）にひも付いているが、ラップされた秘密鍵はローカルファイルやChromeのメモリから取得でき、Windows標準の暗号APIを通じて通常ユーザー権限のまま署名処理に利用できる。

　その結果、Cloud Authenticatorが返した正当な認証結果をサービスに転送することで、利用者の同意や端末解除、生体認証を経ずにログインできる可能性がある。

　一方、サービス側が生体認証やPIN入力など利用者本人による認証を必須とし、その実施を示す「UV（User Verified）フラグ」を適切に検証していれば、この攻撃は通常成立しない。しかし研究では、「userVerification」を「required」に設定していてもUVフラグを十分に検証せず認証を受け入れるサービスが確認されたという。

　このような実装では、多要素認証を前提とした構成でも、端末識別鍵だけでアカウントを乗っ取られる恐れがある。研究チームは問題の詳細を影響を受ける事業者に報告したとしている。

2．Silver Pass-ta-key攻撃

　Silver Pass-ta-key攻撃は、既存の利用者検証鍵を無効化し、攻撃者が用意した鍵に置き換える手法だ。攻撃者は端末識別鍵を使ってCloud Authenticatorに端末削除を要求するか、ローカルに保存された「passkey_enclave_state」ファイルを削除し、Chromeに端末の再登録を実行させる。

　Windows版Chromeでは初回利用時に端末が「uv_key_pending」状態となり、利用者検証鍵は次回利用時に生成される。研究では、この再登録の過程で新たに登録される鍵が正規ハードウェアで生成されたものかどうか十分に検証されないケースが確認されたという。この間に攻撃者が自身の公開鍵を登録できれば、その後は被害端末が手元になくてもUVフラグ付きの認証を生成できるようになる。

3．Golden Pass-ta-key攻撃

　Golden Pass-ta-key攻撃では、同期パスキーを暗号化する32バイトのマスター鍵「Security Domain Secret」（SDS）を狙う。SDSは本来Cloud Authenticatorの隔離環境内で管理されるが、新しい端末の登録や再登録時にはChromeに受け渡される。

　ログへの出力は既に修正されたが、研究ではSDSがChromeのメモリに平文で存在することを確認した。攻撃者は再登録を誘発してSDSを取得し、同期データを復号することで保存されているパスキーの秘密鍵を復元できる。同じ「Google アカウント」でSDSが継続利用される限り、新たに同期されたパスキーも同じ鍵で保護されるため、現行実装ではSDSを失効・ローテーションする仕組みがなく、端末を再登録しただけでは被害を解消できないという。

同期パスキーを狙う攻撃にどう対処すればいいのか？

　対策として、サービス事業者にはuserVerificationをrequiredに設定するだけでなく、UVフラグを厳格に検証することが求められる。認証基盤を提供する側には、新たに登録される端末鍵の出どころやアテステーションを確認し、端末の復旧や再登録が不必要に繰り返されないよう検知・制限することが重要となる。また、SDSのような重要な暗号鍵をログやクライアントメモリへ露出させず、暗号処理を隔離環境内で完結させる設計も必要だ。

　利用企業や利用者にとっては、今回の攻撃はいずれも侵害済み端末が前提となる。このためEDRなどによるマルウェア対策を徹底するとともに、Chromeを最新の状態に保ち、不審なソフトウェアの実行を防ぐといった基本的な端末防御が重要になる。

　研究チームは、パスキーがパスワード由来の攻撃を大幅に減らす有効な認証方式であること自体は変わらないと評価している。一方で、端末がマルウェアに侵害され、クラウドへ送られる「信頼できる端末」という信号そのものを攻撃者が操作できる場合には、期待された安全性を完全には維持できないことも示した。

　今回の研究は、パスキーという認証方式そのものの暗号安全性を否定するものではない。同期型パスキーの実装や復旧フローにも十分な防御設計が必要であり、パスキーは端末保護や厳格な認証検証と組み合わせて運用する多層防御の一要素として捉える必要がある。