Pass-ta-key：Googleパスキーへの攻撃が本当に意味すること

パスキーは、実は安全ではないのでしょうか。Pass-ta-keyが突きつけるのは、まさにこの問いです。

Palo Alto Networks Unit 42は、マルウェアがGoogleで同期されたパスキーを悪用し、ユーザー検証を回避し、最も深刻なシナリオではアカウント内のすべてのパスキー秘密鍵を抽出できる3つの攻撃チェーンを説明しています。

3つの手法はいずれも、WebAuthn、FIDO2、使用されている公開鍵暗号を破るものではありません。すべて、被害者のWindows PCですでにマルウェアが動作していることを前提とします。これは大きな制約です。

それでも、「侵害されたエンドポイントでは、どのみちすべてが失われている」という分析では簡単に片付けすぎです。Golden Pass-ta-keyは、ローカル侵害を、同期済みパスキーすべての永続的に利用可能かつエクスポート可能なパッケージへ変えることを狙います。その影響は、単一のブラウザーセッションの窃取を超えます。

先に要点をまとめると

はい、これは新しく独立したセキュリティ上の論点です。しかし、パスキーを廃止したり、再びパスワードだけに戻したりする理由にはなりません。

正しい整理は次のとおりです。

• プロトコルは破られていない： Origin Binding、Challenge-Response、非対称暗号はいずれも破られていません。
• 特定の実装が攻撃される： 対象はUnit 42が調査したGoogle Password Manager、Chrome、Windows、TPMの組み合わせです。
• エンドポイントがすでに侵害されている必要がある： インターネット上の任意のWebサイトが、クリーンなコンピューターに対して実行できる攻撃ではありません。
• それでも潜在的な被害は重大である： 密かに生成されるログインAssertionから、同期済みパスキーすべての秘密鍵抽出まで、影響は多岐にわたります。
• 同期パスキーとデバイス紐付けパスキーではリスク特性が異なる： どちらもパスキーですが、同じセキュリティレベルではありません。
• パスワードは依然として劣る選択肢である： フィッシング、使い回し、推測、サーバーデータベースからの窃取という追加のリスクがあります。

したがって、私のリスク評価は「何も起きていない」ではなく、技術的な適用範囲は狭く前提条件も厳しいが、実行に成功した場合の影響は非常に大きくなり得る、です。

技術的な範囲と根拠

2026年8月31日時点で確認できる情報には、Unit 42が文書化した攻撃手順、WebAuthn仕様、Googleのパスキー文書、公開されているChromium Issue、同期可能なAuthenticatorに関する現行のNIST要件が含まれます。さらに、SpecterOpsのPass-the-Passkey、CVE-2026-34348、ProofpointのFIDOダウングレード、ExpelとSquareXの技術的知見も、攻撃面を評価する材料です。

この研究は8月3日に公開され、Unit 42によって8月14日に更新されました。対象は明確に、TPMを搭載したWindowsデバイス上のChromeで利用されるGoogle Password Managerです。他のブラウザー、OS、パスキープロバイダーにも似た設計上の問題が存在する可能性はありますが、これら3つの攻撃による実証はされていません。

これらの特定の手法について、実環境で活動中の攻撃キャンペーンは報告されていません。現時点の根拠は、研究、Proof of Concept、Responsible Disclosureです。リスク評価ではこの点が重要です。技術的に実証されたことは、すでに大規模に悪用されていることを意味しません。

パスキーが実際に守るもの

パスキーは、単に非常に長いパスワードではありません。非対称暗号に基づくWebAuthnの認証資格情報です。

登録時に、Authenticatorは鍵ペアを生成します。

private key -> remains with the authenticator
public key  -> is registered with the online service

WebAuthnで「Relying Party」と呼ばれるオンラインサービスは、公開鍵をCredential-IDおよびユーザーアカウントとともに保存します。後のログイン時に、サービスは新しいランダムなChallengeを送信します。Authenticatorは、そのChallengeや呼び出し元Webサイトのコンテキストなどを結び付けたデータに署名します。サーバーは、保存済みの公開鍵を使って署名を検証します。

つまり、秘密鍵はパスワードのようにサーバーへ送信されません。サービス側でデータ漏えいが起きても、攻撃者が得られるのは理想的には公開鍵だけです。それでは有効な署名を生成できません。

Relying-Party-IDとWeb-Originへの紐付けも重要です。example.com用のパスキーは、見た目がよく似たフィッシングドメイン上では、example.comで有効なAssertionを生成しません。ユーザーには、誤ったWebサイトに入力したり、電話で攻撃者に読み上げたりできる秘密情報がありません。

これが、フィッシング耐性の意味です。NISTはこの用語を厳密に定義しています。不正なVerifierは、認証の秘密情報も、正規サービスで利用可能な認証応答も取得できてはなりません。WebAuthnは、Verifier名への暗号学的な紐付けによってこれを実現します。

この性質はPass-ta-keyでも保たれています。マルウェアがより巧妙なフィッシングサイトを作るわけではありません。ユーザーが信頼できるAuthenticatorとして利用しているデバイス上で、すでに動作しているのです。

User PresenceとUser Verificationは同じではない

3つの攻撃を理解するには、2つのWebAuthnシグナルを区別する必要があります。

• User Presence、UP： ユーザーがSecurity Keyに触れる、ダイアログを承認するなど、存在を示す操作を実行しました。
• User Verification、UV： AuthenticatorがWindows Hello、PIN、生体認証などを通じて、ローカルでユーザー本人を検証しました。

WebAuthnのAssertionには、これらの結果がauthenticatorData内のフラグとして含まれます。サーバーは、ログイン開始時に要求した内容だけを信頼してはいけません。userVerification: "required"を要求した場合、応答でUVフラグが実際に設定されているかも確認する必要があります。

この一点の確認が重要です。Unit 42は、必要なUser Verificationが欠けていたため、GitHubに対する単純なPass-ta-key攻撃を成功させられませんでした。一方、eBayではUser Verificationが要求されていたにもかかわらず、当初はログインに成功しました。eBayは報告を受けてサーバー側の検証を修正しました。

この違いは、暗号学的に正しい署名だけでは、適切に実装された多要素認証として十分でない場合があることを示します。Relying Partyは、Authenticatorがどのセキュリティ条件を実際に確認したのかも検証しなければなりません。

同期パスキーが追加の信頼領域を生む理由

デバイス紐付けパスキーは、Hardware Security Keyやローカルで保護されたプラットフォームAuthenticatorなど、特定のAuthenticatorに残ります。一方、同期パスキーは複数のデバイスで利用できることを目的としています。そのため、秘密鍵素材を暗号化してバックアップし、Syncインフラを介して転送し、承認済みの別デバイスで復元できなければなりません。

これは小さな実装差ではありません。同期によってシステムは拡張されます。

Relying Party
    |
browser and WebAuthn client
    |
local platform authenticator
    |
passkey manager and recovery logic
    |
cloud sync and additional devices

追加される各層には、デバイスの信頼、Onboarding、Recovery、鍵の暗号化、失効に関する独自のルールが必要です。

そのためNISTは、同期可能なAuthenticatorを明確に独立したカテゴリーとして扱っています。Authentication Assurance Level 2までのシナリオに適する可能性があります。一方、AAL3では、ハードウェア保護環境または独立したAuthenticator内にある、エクスポート不可能な鍵が求められます。これは同期パスキーが弱いという意味ではありません。利便性と鍵の可搬性によって、異なるAssuranceモデルが生まれるという意味です。

Pass-ta-keyは、まさにこの追加の信頼領域を狙います。

研究の正確な対象範囲

Unit 42は、多くの見出しでは十分に伝えられなかった複数の前提条件を挙げています。

• 対象となる同期パスキーをGoogle Password Managerが管理している。
• ChromeがWindows上で動作している。
• デバイスがTPMを搭載している。
• マルウェアが被害者のユーザーコンテキストですでに動作している。
• ユーザーが該当するChromeおよびGoogle環境を設定済みである。
• 一部の攻撃では、マルウェアがローカルのChromeデータを読み、状態ファイルを改変し、またはChromeのプロセスメモリを調べる必要がある。

あらゆるパスキーに対する普遍的な攻撃は示されていません。また、事前にエンドポイントを侵害していないリモート攻撃者が、TPMからWebAuthn鍵を簡単に取り出せることも示されていません。

したがって、「パスキーが破られた」という表現は誤りです。正確には、Unit 42は、侵害済みWindowsエンドポイントにおけるGoogle同期パスキーの信頼、Onboarding、Recoveryメカニズムに対する3つの攻撃チェーンを実証した、となります。

フェーズゼロ：ローカルのパスキーマップ

Unit 42によると、3つの攻撃のいずれかを開始する前に、マルウェアはローカルのChrome Syncデータベースを読み取ります。そこにはWebauthnCredentialSpecificsレコードがあり、Relying Party情報、ユーザー名、Credential-ID、暗号化された秘密鍵素材などが含まれています。

研究で示されたパスは次のとおりです。

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

テストでは、これらのレコードへのアクセスに昇格権限は必要ありませんでした。秘密鍵素材そのものが平文で存在するわけではありませんが、メタデータはマルウェアに標的一覧を提供します。どのサービスにパスキーが存在するか、どのアカウントに属するか、どのCredential-IDを指定すべきかが分かります。

これはDetectionの観点ですでに重要です。Infostealerは標的を推測する必要がなくなります。まずインベントリーを作成し、その後、価値の高いアカウントを選択的に攻撃できます。

Pass-ta-key：ユーザー操作なしの有効なAssertion

最初の攻撃は、WindowsデバイスのIDをGoogle Cloud Authenticatorに証明するためにChromeが使用するデバイス鍵を悪用します。

Chromeはこの目的で、TPMに支えられたIdentity Keyを生成します。Unit 42の説明では、Chromeは秘密鍵を通常の平文鍵として保存しません。代わりにWindows CNGを介してNCRYPT_OPAQUE_KEY_BLOBとしてエクスポートします。TPMはこのBlobを保護し、同一の物理TPM上で暗号処理に再インポートできるようにします。

これは暗号学的には合理的ですが、認可の問題を自動的に解決するわけではありません。研究によると、通常のユーザーコンテキストで動くマルウェアが、保存されたwrapped_identity_private_keyを読み取るかChromeのメモリから取得し、通常のWindows CNG関数を呼び出せました。要求が技術的には正しいデバイスから来るため、TPMは署名を実行します。APIを呼び出したのがChromeかマルウェアかは判別しません。

単純化した流れは次のとおりです。

attacker requests a fresh challenge from the online service
    -> malware on the victim PC uses the TPM-bound identity key
    -> Google Cloud Authenticator accepts the device identity
    -> Cloud Authenticator creates a valid passkey assertion
    -> attacker submits the assertion to the online service

この攻撃では、パスキーの秘密鍵ファイルを必ずしもエクスポートする必要はありません。マルウェアは、侵害済みデバイスとGoogle Cloud Authenticatorを署名サービスとして利用します。

自然な制約はUVフラグです。Identity Keyはデバイスの所持を証明しますが、PINまたは生体認証が成功したことは証明しません。User Verificationを必須とし、その結果を確認するよう正しく実装されたサービスは、UV = 0のAssertionを拒否しなければなりません。

それでも、この攻撃が無害になるわけではありません。多くのサービスは、互換性やUX上の理由からUser Verificationをpreferredにしか設定していません。要求はしても、応答の確認を誤っているサービスもあります。その場合、多要素を意図したログインは、実質的にデバイスIDへのアクセスという1要素になります。

Silver Pass-ta-key：攻撃者が自身のUV IDを登録する

Silver Pass-ta-keyは、先ほどの制約を回避します。攻撃者は、Windows Helloや被害者の生体認証を破ろうとはしません。自分の鍵を、今後のUser Verificationの有効な証明としてCloud Authenticatorに受け入れさせます。

起点はRe-Onboardingプロセスです。研究によると、マルウェアはCloud Authenticatorに既存のデバイス状態を忘れさせるか、ローカルのpasskey_enclave_stateファイルを削除できます。次にパスキーを使用するとき、Chromeはデバイスを再登録する必要があります。

Windowsでは、最初のステップでUser-Verification-Keyが必ず生成されるとは限りません。ChromeはまずGoogle-Password-Manager-Recovery-PINを使用し、uv_key_pending状態を設定できます。実際のUV-Keyは次回のパスキー使用時に追加されます。ユーザーの利便性を重視したこの中間状態が、攻撃の時間窓を開きます。

準備段階では、被害者が予期せず開始されたRecoveryまたはRe-Onboardingを完了し、GPM-PINを入力する必要があります。マルウェアはPINそのものを盗む必要はありません。その後に生じたuv_key_pending状態を利用します。以後の不正ログインは、追加の操作も被害者デバイスへの到達性もなく実行できます。

攻撃者は自分の環境で鍵ペアを生成し、公開鍵を新しいUV-Keyとして送信します。Unit 42の結果によると、Google Cloud Authenticatorはこの処理で、新しい鍵が本当に信頼できるハードウェアから生成されたかを検証しませんでした。システムは、正規のデバイスIDと並べて攻撃者の鍵を保存しました。

この時点から、攻撃者は自分の秘密鍵で要求に署名できます。Cloud AuthenticatorはそれをローカルでUser Verificationが行われたものとして扱い、UVフラグを設定したAssertionを生成します。以後のログイン時に、被害者のPCがオンラインである必要はありません。

公開されているChromium Issueは、この挙動を「GPM Passkeys Are Vulnerable to User Verification Key Abuse」と説明しています。私が確認した時点ではWAIとマークされていました。内部評価とは無関係に、この事例は重要な設計原則を示しています。新しい信頼済み鍵を紐付けるRecoveryまたはOnboardingプロセス自体が、極めて重要な認証処理なのです。

Golden Pass-ta-key：Cloud Syncからエクスポート可能な鍵素材へ

Golden Pass-ta-keyは最も深刻な攻撃です。標的は、Security Domain Secret、略してSDSです。この32バイトの秘密情報が、Google Password Managerアカウントの同期済みパスキー秘密鍵を保護します。

設計上の約束を単純化すると、Clientが保持するのは暗号化されたwrapped_secretだけです。復号は、デバイス固有の鍵を使ってCloud Authenticator内で行われます。そのため、Client上のマルウェアであっても、パスキー秘密鍵を簡単には取得できないはずです。

しかしOnboardingとRecoveryでは、SyncインフラがデバイスをSecurity Domainへ再び参加させる必要があります。Unit 42は、その際にChromeがClientからアクセス可能な形でSDSを受け取ることを発見しました。当初は、ChromeのFIDO診断ログにも表示されていました。Googleは報告後にこのログ出力を削除しました。それでも処理中には、SDSがChromeのプロセスメモリに入ります。

したがって、Golden Pass-ta-keyは任意の時点で実行できる単純なメモリダンプではありません。マルウェアはまずセキュリティ上重要なOnboardingまたはRecovery経路を強制し、Chromeプロセス内にSDSが存在する瞬間を捉える必要があります。これは攻撃を難しくしますが、抽出に成功した後、盗まれた秘密情報の適用範囲を狭めるものではありません。

攻撃チェーンは複数の手順を組み合わせます。

1. マルウェアが新しいOnboardingを強制する。
2. ローカルのEnclave状態が再生成または変更されるのを待つ。
3. 適切な瞬間にChromeのプロセスメモリを読み取り、SDSを探す。
4. SDSを、先に読み取ったSyncレコードと組み合わせる。
5. そこに含まれるパスキー秘密鍵を復号する。
6. その後、被害者デバイスから独立した攻撃者自身のAuthenticatorが、有効なAssertionを生成できる。

ここに、盗まれたSession-Cookieとの質的な違いがあります。Sessionは期限切れになったり、サーバー側で失効させられたりします。一方、Golden Pass-ta-keyは、すでに同期されているすべてのパスキー秘密鍵のエクスポートを狙います。さらにUnit 42は、同じSDSが将来作成される同期パスキーも保護しており、調査対象の設計では、このSDSをローテーションまたは失効させる明確な方法がなかったと記しています。

この説明は、調査されたGoogle実装の状態を示すものです。すべてのパスキープロバイダーが同じMaster Key構成を使用していることや、Googleが将来設計を変更できないことを証明するものではありません。

ローカルマルウェアが前提でも軽視できない理由

ログイン済みPCのユーザーコンテキストで任意のマルウェアを実行できる攻撃者には、より簡単な攻撃手段が数多くあります。Session-Cookieを盗む、ブラウザー内容を読み取る、取引を改ざんする、ファイルを流出させる、アクティブなアカウント内でユーザー本人として操作することが可能です。完全に侵害されたClientを、どの認証方式も無条件に信頼することはできません。

基本的な攻撃分類も新しくありません。侵害されたPassword Managerやブラウザーから秘密情報やアクティブなSessionを盗むことは、長年にわたりInfostealerの手法でした。Pass-ta-keyは、既存のEndpoint侵害を魔法のようなリモート攻撃に変えるものではありません。

それでも、この攻撃を無意味として退けるのは不十分です。研究は、これまで当然とは言えなかった、実装固有の具体的な知見を示しています。

• 権限のないプロセスが、TPMに紐付けられたChromeデバイス鍵を署名に利用できた。
• デバイス所持とユーザー検証の境界は、Relying PartyがUVフラグを正しく評価するかに依存した。
• Re-Onboarding状態によって、攻撃者が管理するUV-Keyを登録できた。
• 中心となるSync秘密情報が当初ログに現れ、その後も研究によればプロセスメモリから取得可能だった。
• 最も深刻な経路では、同期済み秘密鍵を元のデバイス外で再利用できた。
• 複数の正規デバイスが同じCredentialを利用するため、同期パスキーでは従来の署名カウンターが信頼できるCloningシグナルにならないことが多い。

「Endpointが侵害されている」ことは前提条件ですが、被害全体の説明ではありません。Incident Responseでは、攻撃者が一時的なSessionだけを盗んだのか、多数のサービスで長期利用できる秘密鍵素材を手にしたのかによって、大きな違いがあります。

Pass-ta-keyは新しい攻撃面の一部にすぎない

Pass-ta-keyは単独で登場したわけではありません。2025年と2026年の研究は、秘密鍵を数学的に破らなくても、攻撃者がパスキーの保護効果を弱められる複数の経路を示しています。

SyncとRecoveryの悪用では、Pass-ta-keyはWindows Endpoint上ですでにマルウェアが動いていることを必要とします。一方、Pass-the-Passkeyは、ログに記録されたAssertionへのアクセスとサーバー側のReplay欠陥を組み合わせます。FIDOダウングレードでは、フィッシング可能な別のログイン経路が有効なだけで足ります。Passkeys Pwnedは、悪意のあるBrowser Extensionまたはブラウザーコンテキスト内でのScript実行を前提とします。最後にInfostealerは、パスキー自体ではなく、侵害されたブラウザーやEndpointから認証済みSessionを盗みます。

これらの経路はいずれも公開鍵暗号を破りません。共通するのは、WebAuthnを取り巻く信頼層、つまりSyncとRecovery、サーバー側の検証、ブラウザー、ログイン後のSessionを攻撃することです。

この区別は単なる言葉遊びではありません。プロトコルの破綻であれば、準拠するすべての実装を根本から疑うことになります。ここで説明する事例には、Endpoint、ブラウザー、Identity、サーバーの各側で異なる対策が必要です。

Pass-the-Passkey：有効なAssertionが再利用可能になるとき

SpecterOpsはBlack Hat USA 2026に向けて、Windows 11とMicrosoft Entra IDに3つの脆弱性を特定し、そこから派生する20以上の攻撃手法を示しました。最も重要なチェーンは、意外な場所から始まりました。WindowsがWebAuthnの完全なAssertionをEvent Log Microsoft-Windows-WebAuthN/Operationalに記録していたのです。

このようなAssertionには、Credential-ID、Challenge、Authenticator Data、署名などが含まれます。これは秘密鍵ではなく、Verifierが正しく実装されていれば、対応するログインSession内で一度だけ機能するはずです。しかしSpecterOpsは、Entra IDが一定の短い時間内で、記録されたAssertionを再び受け入れることを確認しました。2つの欠陥が組み合わさったのです。

Windows logs a complete assertion
    -> an attacker reads it
    -> the verifier does not bind the challenge and assertion tightly enough to the session
    -> the same signed response is accepted again

Windows側の問題にはCVE-2026-34348が割り当てられました。Microsoftは2026年7月14日に更新を公開し、ログへ記録する署名を数バイトに短縮してReplayの元を取り除きました。さらに、一部のFIDO2 Security Keyについて、署名カウンターをサーバー側で検証する仕組みが導入されました。ただし、署名カウンターは万能な防御ではありません。一部のプラットフォームCredentialや同期Credentialは常にゼロを返すか、複数デバイスで状態を共有します。

技術的な教訓は、すでに断ち切られたこのExploit Chainだけにとどまりません。WebAuthn Assertionを診断ログやEvent Logへ保存してはいけません。Challengeはランダムかつ短命で、一度だけ使用でき、特定のログインSessionに紐付ける必要があります。有効な署名だけでは、ログインフロー全体が正しかったことの証明になりません。

別の攻撃手法は、Windows WebAuthn APIのParent-Window-Handleに関係します。ローカルプロセスは、本物のパスキーダイアログを、ブラウザーやメールクライアントなど信頼できるプログラムに属しているように見せて配置できます。この場合もSystem UI自体は本物ですが、呼び出し元のコンテキストは誤解を招く可能性があります。したがってユーザーは、予期しないパスキーやWindows Helloの要求を、予期しないMFA Push通知と同じように扱うべきです。

最も弱いFallbackが実際のセキュリティレベルを決める

Proofpointは2025年、Microsoft Entra IDに対するFIDOダウングレードを実証しました。改変したEvilginx Flowが、FIDOをサポートしないブラウザーになりすまします。すると対象プラットフォームが別のログイン方式を提示しました。被害者がSMS、OTP、または別のフィッシング可能な方式を選ぶと、Adversary-in-the-Middle Flow内で認証情報とSessionを盗み取れました。

この攻撃はOrigin Bindingを回避しません。WebAuthn Ceremonyがそもそも開始されないようにします。アカウントでパスキーに加えて弱い方式が許可されている場合にのみ成立します。このダウングレードが実環境で悪用された事例は報告されていません。

企業にとっては、不都合でも明確な原則が導かれます。パスキーを登録しただけでは、ポリシーがフィッシング耐性を持つとは言えません。対象の保護要件に対し、ログインがフィッシング可能な代替経路を受け入れなくなって初めて、フィッシング耐性を持ちます。RecoveryとHelpdesk Resetも同じ評価に含める必要があります。

ブラウザーもセキュリティモデルの一部である

SquareXはPasskeys Pwnedという名称で、悪意のあるBrowser Extensionやブラウザーコンテキスト内のScript実行が、navigator.credentials.create()とnavigator.credentials.get()の呼び出しに介入できることを示しました。特に重要なのが登録です。攻撃者が適切なタイミングで自分の鍵素材を差し込めれば、ユーザーには本物の生体認証ダイアログが見えていても、裏では攻撃者が管理するCredentialが紐付けられる可能性があります。

この研究はセキュリティベンダーによるもので、普遍的なブラウザーExploitと同一視すべきではありません。必要な前提条件はすでに重大です。ExtensionまたはScript ContextがWebAuthn経路に介入できなければなりません。それでも、設計上の教訓は有効です。Browser Extension、Content Script、正規のWebAuthn Proxy機能はTrusted Computing Baseの一部です。管理環境におけるExtension Allowlistと特権Browser APIの制御は、単なるブラウザー衛生ではなくIdentity保護です。

パスキーはログインを守るが、その後のSessionまで自動的には守らない

ログインに成功した後、Webサービスは通常、Session-CookieまたはTokenで処理を続けます。InfostealerがブラウザーからこのSession artefactを盗み、サーバーが別デバイスからの再利用を許せば、攻撃者はパスワードもパスキーも必要としません。すでに認証済みのSessionを攻撃します。

現在、これはここで説明した多くの研究上のProof of Conceptよりも実用的な攻撃経路です。パスキーは、ログイン前およびログイン中の攻撃面を大きく減らします。しかし、安全なToken保存、リスクに応じた短いSession期間、重要操作での再認証、Token失効、そして可能であれば価値の高いSessionを利用デバイスへ暗号学的に紐付ける仕組みの代わりにはなりません。

Session窃取で「MFAが回避された」という表現は、しばしば誤解を招きます。MFAは正常に完了しています。その後の結果が盗まれたのです。

PoisonSeedが示した、研究が急速に誇張へ変わる危険

Expelは2025年7月、当初、パスキーのCross-Device Authenticationに対する攻撃とみられる事例を報告しました。攻撃者が正規のQR Codeをフィッシングページ経由で被害者に転送し、遠隔からログインを奪取できるという主張でした。数日後、Expelは中心的な主張を公に撤回し、謝罪しました。

その後の分析では、Cross-Device Authenticationで想定されているローカル近接性の確認を、実際には突破できていなかったことが分かりました。必要な近接性がなければ処理はタイムアウトし、すべてのMFA試行が失敗し、攻撃者はアクセスを得られませんでした。

この事例は、現在の議論に特に有用です。QR Code、フィッシング、パスキーを組み合わせたもっともらしい話が、すべて機能するFIDO Bypassとは限りません。優れたセキュリティコミュニケーションでは、観測されたAccount Takeover、再現可能なProof of Concept、理論上の攻撃、否定された仮説を区別する必要があります。

私のセキュリティ評価

Pass-ta-keyの技術的な適用範囲は限定的です。攻撃チェーンが実証されたのは、TPMを搭載するWindowsシステム上のChromeで動くGoogle Password Managerに対してです。すでにマルウェアがローカルで動作し、攻撃によっては状態やプロセスメモリを狙って操作する必要があるため、発生可能性は中程度から低程度です。

一方、潜在的な影響は大きいか、非常に大きくなります。攻撃に成功すれば、Account Takeover、永続的なリモートアクセス、複数の秘密鍵抽出につながる可能性があります。WebAuthn、Origin Binding、公開鍵暗号は破られていないため、プロトコル自体のリスクは低いままです。

一般のユーザーにとって、同期パスキーは通常、SMSコードまたはTOTP付きパスワードより安全です。多くの現実的な攻撃経路から、フィッシング、Credential Stuffing、再利用可能なパスワードデータの窃取を取り除きます。

しかし、特権管理者、財務承認、本番環境アクセス、厳格に規制されたシステムには、この一般論だけでは不十分です。同期パスキーが求めるAssurance Levelを満たすか、組織が意識して判断する必要があります。デバイス紐付けプラットフォーム鍵や独立したFIDO2 Hardware Keyの方が、こうしたアカウントには適切な境界となる場合があります。

これはSync Passkeyの否定ではありません。段階的なセキュリティアーキテクチャです。

Webサービス運営者が確認すべきこと

Relying Partyにとって最も重要な教訓は、特殊なものではありません。WebAuthnを正しく検証することです。

サーバーでは、次の対策が必要です。

• ユースケースが実際のローカルUser Verificationを必要とするなら、userVerification: "required"を設定する。
• authenticatorDataで返されたUVフラグを必ず確認する。
• Challenge、Origin、Relying-Party-ID、署名をすべて検証する。
• Challengeを毎回ランダムに生成し、有効期間を短くし、一度だけ受け入れ、特定のSessionに紐付ける。
• 完全なAssertion、署名、その他再利用可能な認証artefactをログへ保存しない。
• パスキーの登録、削除、Account Recoveryを高リスクEventとして記録する。
• 特権アカウントへの新しいAuthenticator追加は、強力な再認証後にのみ許可する。
• 可能であればAuthenticatorの出所と特性を記録する。
• 高セキュリティ用途では、Attestationと管理対象Authenticatorを検討する。
• 通常と異なるデバイス変更、地域変更、新しいパスキー紐付けをIdentity Telemetryへ取り込む。
• リスクの高い変更後はSessionを失効させ、重要操作で再認証する。
• プラットフォームとアプリケーションが堅牢に対応した時点で、デバイス紐付けSessionを使用する。

実績のあるWebAuthnライブラリは、不完全な独自実装のリスクを減らしますが、運営者が設定を確認する責任までなくすものではありません。eBayの事例は、1つの未検証フラグが意図したセキュリティレベルを下げることを示しています。さらにPass-the-Passkeyは、ChallengeとSessionが正しく対応していなければ、正しい署名さえ無価値になることを示しました。

企業がパスキー導入で変えるべきこと

パスキープロジェクトは、IAMプロジェクトとして計画されることがよくあります。Pass-ta-keyは、同時にEndpoint、ブラウザー、Recoveryのプロジェクトでもあることを示しています。

一般の従業員アカウントには、同期パスキーを引き続き有効に活用できます。Helpdeskの負担を減らし、ユーザーをフィッシングから非常に効果的に守ります。ただし特権ロールでは、保護要件に応じてポリシーを明確に区別すべきです。

通常のユーザーアカウントは、管理対象デバイスで同期パスキーを使用し、Endpoint ProtectionとConditional Accessを組み合わせられます。機密性の高い業務アカウントには、管理対象プラットフォームAuthenticator、またはデバイスとの紐付けを強めた制限付きSync環境が適しています。Admin、Break-Glass、その他の高価値アカウントには、独立したデバイス紐付けFIDO2 Hardware Key、厳格に管理されたRecovery、管理されていないCloud Syncを許可しない構成が必要です。

さらに企業は、次の対策を実施すべきです。

• ChromeとWindowsを最新に保つ。
• CVE-2026-34348に対するWindowsのセキュリティ状態を確認する。
• 内蔵Browser Managerへのパスキー保存を、Enterprise Policyで意図的に許可または制限する。
• Browser ExtensionをAllowlistで管理し、特権WebAuthn Proxy機能を監視する。
• EDRとApplication Controlの対象にユーザープロセスも含める。
• Browser Syncデータベースへのアクセスと、Chromeプロセスメモリのダンプを監視する。
• passkey_enclave_stateの削除や予期しない再生成を調査する。
• Google-Password-Manager-Recovery-PINの繰り返しまたは予期しない要求を警告シグナルとして扱う。
• 既存のデバイス紛失およびAccount Recoveryプロセスが悪用されないかテストする。
• 特権アカウントからフィッシング可能なFallbackを削除するか、Authentication-Strength-Policyで除外する。
• 予期しないパスキー要求、新しいCredential登録、通常と異なるプロセスからのWebAuthn利用を調査する。
• 重要サービスが同期Credentialとデバイス紐付けCredentialのどちらを使用しているか把握する。

組織として重要な点は、Endpoint Detectionをパスキープロジェクトとは無関係の予算項目として扱わないことです。AuthenticatorがブラウザーとClient上に存在するなら、Endpointセキュリティは認証モデルそのものに含まれます。

ユーザーが今すべきこと

念のためにすべてのパスキーを削除し、より弱いパスワードへ戻す合理的な理由はありません。

有効な対策は次のとおりです。

• ChromeとWindowsを速やかに更新する。
• 信頼できるソフトウェアとBrowser Extensionだけをインストールする。
• デバイス保護、Windows Hello、マルウェア対策を有効に保つ。
• 予期しないパスキーまたはWindows Helloのダイアログを承認しない。
• 予期しないRecovery-PINやRe-Onboarding要求を安易に承認しない。
• Google Password Managerと重要サービスで、登録済みデバイスおよびパスキーを確認する。
• 特に価値の高いアカウントには、独立したHardware Security Keyを検討する。
• 不審なEndpointをそのまま使い続けず、隔離して調査する。

マルウェア、改変されたChrome状態、メモリダンプの具体的な兆候がある場合、CredentialとSessionが盗まれた可能性を想定すべきです。その場合、パスワード変更だけでは不十分です。Endpointの再構築または信頼できる駆除、アクティブSessionの失効、Recovery方式の確認、不明なパスキーの削除、信頼できるAuthenticatorの再登録が必要です。

Golden Pass-ta-keyの可能性があるインシデントでは、特に注意が必要です。公開された研究では、ユーザーがSDSを簡単にローテーションする方法は説明されていません。つまり、PIN変更や1つのパスキーを作り直すだけで問題が確実に解決すると主張してはいけません。価値の高いアカウントでは、Endpointの駆除後に新しいデバイス紐付けCredentialを登録し、古い同期Credentialを削除し、ProviderまたはIncident Responseチームを復旧に関与させることを勧めます。

本当に学ぶべきこと

パスキーは、あらゆる侵害を防ぐ盾ではありません。解決するのは、具体的で非常に大きな問題です。人が、再利用可能な秘密情報をサーバーや偽装されているかもしれないWebサイトへ渡す必要をなくします。

Pass-ta-keyは次の層を示しています。秘密鍵をデバイス間で便利に同期するなら、鍵暗号化、デバイス信頼、Recoveryのためのインフラが生まれます。基礎となるWebAuthnプロトコルが正しくても、このインフラには欠陥が入り得ます。

誤った反応は、パスキーが失敗したと宣言することです。同じく誤っているのは、ローカルマルウェア感染後の攻撃をすべて平凡なものとして退けることです。

私の結論は明確です。パスキーの導入は続けつつ、セキュリティ上の約束を正確に表現すべきです。同期パスキーはフィッシングに対して非常に有効です。デバイス紐付けHardware Keyは、高価値アカウントにより強い境界を提供します。そして、どのAuthenticatorも、クリーンなEndpoint、管理されたRecoveryプロセス、正しく実装されたサーバー側検証の代わりにはなりません。

パスキーは、フィッシングに対する扉をはるかに強固に施錠しました。Pass-ta-keyは、すでに家の中にいる攻撃者には、別の防御が必要だと気付かせてくれます。

それでは、また次回。
Joe

よくある質問