パスキーは「破られていない」が実装は狙われる — 同期パスキーの鍵を奪うPass-ta-keyと、イベントログから署名を掘り起こすPass-the-Passkey

パスキー（passkey）は、パスワードに代わる認証方式として、Microsoft・Google・Appleがそろって推進している。パスワードと違い、共有する秘密がなく、フィッシングに強いのが特徴だ。日本でも政府や企業の認証基盤への導入が進んでいる。

しかし2026年7月下旬から8月上旬にかけ、パスキーの「周辺の仕組み」を突く研究が相次いで公開された。Palo Alto Networksの研究組織Unit 42による 「Pass-ta-key」 と、SpecterOpsの研究員Michael Grafnetter氏による 「Pass-the-Passkey」（8月5日のBlack Hat USA 2026で発表）だ。

いずれもパスキーの暗号技術そのものは破っていない。破られているのは、実装とその周辺だ。2つの研究が示したのは、「パスキーにすれば安全」ではなく、「導入済みの仕組みをどう守るか」を考え直す必要がある、ということだ。

前提: どちらの攻撃も「端末がすでに侵害されている」

2つの研究に共通する前提は、マルウェアがすでに被害者の端末で動いていることだ。遠隔からパスキーを盗む攻撃ではなく、侵害済みエンドポイントで「パスキーが守ってくれるはずの部分」をすり抜ける攻撃である点は押さえておきたい。

Pass-ta-key: Google同期パスキーを乗っ取る3つの攻撃（Unit 42）

Unit 42は8月3日、**Google Password ManagerがChrome（Windows）で提供する「同期パスキー」**を狙う3つの攻撃を公開した。すべて非特権のマルウェアで実行でき、管理者権限の昇格は不要だ。

同期パスキーでは、秘密鍵が端末ごとに存在せず、クラウド上の認証基盤（クラウドオーセンティケーター）が復号を担う設計になっている。Googleはこの設計について「パスキーの秘密データを盗むことを難しくするのが主目的」と説明している。Unit 42は、その設計の「境界」を個別に突破した。

まず、Chromeの同期データベース（Sync Data\LevelDB）には、ユーザーがどのサイトでパスキーを使っているか、暗号化された秘密鍵などの情報が保存されている。管理者権限なしで読めるため、攻撃者は標的のパスキーの一覧を把握できる。

1. Pass-ta-key（基本形） — Chromeの「デバイスIDキー」というハードウェア由来の署名を、マルウェアが正規のChromeと同じAPI経由で呼び出し、クラウドオーセンティケーターを「正規の端末」と信じ込ませる。ユーザー操作なしで認証アサーションを得られる。効果が出るのは、認証先サービスがユーザー検証（UV）を必須にしていない場合だ
2. Silver Pass-ta-key — ユーザー検証を必須にしているサービス向け。ローカルのパスキー状態ファイルを削除するなどして端末の再登録（再オンボーディング）を強制し、その隙に攻撃者管理の「ユーザー検証キー」を登録する。クラウドオーセンティケーターは新しいキーの来歴（attestation）を検証しないため、攻撃者は以降、検証必須のサービスにも自動でログインできる
3. Golden Pass-ta-key（最重要） — 同期パスキー全体を保護するマスターキー「SDS（Security Domain Secret、32バイト）」を奪う攻撃。Unit 42は、この秘密がChromeのデバイスログ（chrome://device-log/FIDO）に出力されているのを発見した。Googleは報告を受けてログからの出力を削除したが、再登録時にはプロセスメモリ上に現れるため、再登録を強制された端末からは依然として抽出できる。SDSを奪えば、そのアカウントの全パスキー（現在・将来）を復号できる。さらに、Googleの現行実装にはSDSをローテーション・失効させる手段がない

なおUnit 42は、ユーザー検証のフラグ（UVフラグ）を検証していない認証先サービスが存在するとも指摘した。デモではeBayで、ユーザー検証必須の設定にもかかわらず認証が通ってしまった。Unit 42の報告後、eBayはUVフラグの検証を修正している（GitHubのログイン画面では正しく拒否されることも確認されている）。

Pass-the-Passkey: イベントログとEntra IDの隙（SpecterOps）

SpecterOpsは、Windows 11とMicrosoft Entra IDにまたがる3つのゼロデイを実証した。ホワイトペーパー（2026年7月17日付）とBlack Hat USA 2026の講演で公開されている。

1. Windowsがイベントログに「完全な署名」を残す（CVE-2026-34348）

Windows 11は、パスキー認証のたびに、WebAuthnの認証応答（アサーション）を丸ごとイベントログに記録している（チャネル: Microsoft-Windows-WebAuthN/Operational、イベントID 2106）。記録されるのは、チャレンジ、認証データ、署名、ユーザーハンドル、資格情報IDだ。これは「そのユーザーになりすます」ために必要な情報がすべてそろったデータで、Windows Helloだけでなく、YubiKey等のローミング認証器、1Password等の認証器プラグイン、iPhone・Androidとのハイブリッド認証にも及ぶ。

例外は、プライベートブラウジング（Edge InPrivate・Chromeシークレット）と、WindowsのWebAuthn APIを介さず直接オートフィルする一部の拡張機能のみだ。

さらに、認証済みの非特権ユーザー（遠隔のユーザーを含む）がこのログを読める。SpecterOpsは、過去のYubiKey認証の署名が平文で保存されており、これを読み取れることを実証した。この情報漏えいの脆弱性は CVE-2026-34348（Windows Event Logging Service、CVSS 6.5）として採番され、2026年7月のセキュリティ更新プログラムで修正済みだ。

2. Entra IDがリプレイ（再利用）を防いでいなかった

SpecterOpsがもう1つ見つけたのは、Microsoft Entra IDがWebAuthnアサーションのリプレイ対策を実装していなかったことだ。Entra IDのチャレンジはランダム値ではなく署名付きJWTで、有効期間は5分（実測では最大10分受け付ける）。また、署名カウンター（同じ鍵で何回認証したかを示す値）を追跡していない。つまり、1で取得した署名を10分以内にそのまま再送すれば、フィッシング耐性MFAを必須にした条件付きアクセスポリシーを満たしたまま、特権クラウドIDになりすませる。

SpecterOpsによると、Microsoftは2026年5月にFIDO2セキュリティキー（YubiKey等）向けの署名カウンター追跡を静かに展開し、この経路の一部を緩和した。ただし、Windows Helloのパスキーは常にカウンター値0を送るため、Entra ID登録デバイスのWindows Helloパスキーは依然としてリプレイの影響を受けるとしている。また、Microsoft 365 E5（Identity Protection・Defender for Identityを含む）でテストしてもセキュリティアラートは発生しなかったという。

3. パスキープロンプト偽装（未修正）

3つ目は、Windowsの資格情報ダイアログのウィンドウハンドルを偽装し、正規に見えるパスキー承認プロンプトを大量に表示してユーザーに承認を強いる攻撃だ（CVSS 8.0）。MSRC（Microsoft Security Response Center）はこれを「低重要度（Defense in Depth）」としてクローズしており、修正は提供されていない。SpecterOpsは今回の研究で、このほかにも20を超える攻撃テクニックと、検証用のオープンソースツール群を公開している。

なお、同時期には、サインイン済みセッションからWindows Hello for Businessキーを「借りる」手法も、Entra ID研究者のDirk-jan Mollema氏が公開している（dirkjanm.io）。パスキー周辺の攻撃研究が短期間に集中した格好だ。

なぜ今、この研究が重要なのか

Microsoftは2026年9月1日から、Entra IDでパスキーをデフォルトの認証方法にする。SMS・音声認証を利用中のユーザーにはパスキーが自動的に有効化され、Microsoft提供のSMS・音声認証は2027年2月1日に廃止される予定だ。日本でも、Entra IDを認証基盤に使う組織がパスキーへの移行を進めている。

今回の研究は、その移行を「やめる理由」ではなく、「正しく移行するための注意点」を示している。パスキーの暗号技術は依然として強力で、パスワードよりはるかに安全だ。問題は、その周辺の実装と運用にある。

今何をすべきか

エンドユーザー・管理者向け:

• Windowsの更新を適用する — CVE-2026-34348（7月の更新）が未適用の端末は、署名を読み取られる可能性がある
• 不審なパスキー承認プロンプトを承認しない — 心当たりのない認証ダイアログはキャンセルする（未修正のプロンプト偽装攻撃への対策）
• エンドポイントのマルウェア対策を前提にする — 両研究とも「端末が侵害されていれば」が前提。認証を強くしても、端末の防御を弱くしたままでは意味がない

Entra IDを運用する組織向け:

• 条件付きアクセスの「フィッシング耐性MFA要求」だけに依存しない — SpecterOpsは、高価値のID・アプリケーションについてはこの要件だけを当てにしないよう推奨している
• 高価値アカウントにはデバイスバインド型パスキー（端末に固定されるタイプ）を — 同期型より攻撃対象が狭い。可能ならattestation（認証器の来歴検証）を強制する
• 想定外のパスキー再登録や、デバイスIDのない認証の監視を検討する

認証サービスを運営する側向け（Unit 42の指摘）:

• userVerification: required を設定するだけでなく、受け取ったアサーションのUVフラグを実際に検証する
• 登録されたデバイスキー・UVキーの来歴（attestation）を検証する
• 認証データをログに残さない

パスキーはパスワードより安全で、導入を進める価値は変わらない。ただし「認証方式を変える」だけでは不十分で、「端末の防御」と「認証基盤の実装確認」をセットで進める必要がある。9月1日のEntra ID移行を前に、自組織の対応状況を確認しておきたい。

出典: Unit 42 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication / SpecterOps — Pass-the-Passkey Family of Attacks（Whitepaper）・GitHubリポジトリ / NVD — CVE-2026-34348 / Microsoft Security Update Guide — CVE-2026-34348 / Microsoft Learn — Passkeys by default and retirement of Microsoft-provided SMS and voice authentication / dirkjanm.io — Borrowing Windows Hello keys