Google パスキーに新たな攻撃面、Unit 42がGoogle同期パスキーの実装上の欠陥を報告「フィッシング耐性」と「マルウェア耐性」は別問題|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年08月05日更新日時: 2026年08月05日

Palo Alto NetworksのUnit 42は2026年8月3日、Googleの同期パスキー（パスワードレス認証）の実装に存在する新たな攻撃手法に関する調査結果を公開しました。端末上で動作するマルウェアが、オンボーディングや復旧の仕組みを悪用することで、ユーザーの操作や生体認証を経ることなく、パスキーで保護されたアカウントを乗っ取れる可能性があるという内容です。この研究についてはすでに国内メディアでも報道されていますが、本記事では、米国政府がパスキーを推奨してきた経緯や、当サイトがこれまで推奨してきたAiTM対策としてのパスキー導入との関係も含めて整理します。

この記事のサマリー

Unit 42は2026年8月3日、Googleの同期パスキーの実装に対する3種類の新たな攻撃手法をまとめた調査結果を公開しました。
対象はGoogle Password Manager（Chrome、Windows、TPM搭載端末）で、いずれの攻撃も、対象端末にすでにマルウェアが存在していることを前提としています。
3つの攻撃（Pass-ta-key、Silver Pass-ta-key、Golden Pass-ta-key）は、ユーザー確認なしのアカウント乗っ取り、生体認証済みと偽装したなりすまし、パスキーの秘密鍵一式の窃取という、それぞれ異なる深刻度を持ちます。
米国では、CISAとNISTがFIDO2/WebAuthn・パスキーを、フィッシング耐性MFAの実質的な標準（ゴールドスタンダード）として位置づけ、連邦機関への導入を求めてきました。
今回の研究は、この標準そのものの暗号方式を破るものではなく、端末側の実装と、サービス提供者側の検証不備との間に生じるギャップを突いたものです。
当サイトではこれまで、AiTM（中間者）フィッシング対策としてパスキー／FIDO2の導入を繰り返し推奨してきましたが、今回の研究は、パスキーが「フィッシング耐性」を持つことと、「マルウェアに対して無敵であること」は別の問題である点を示しています。

整理表

攻撃名	前提条件	影響
Pass-ta-key攻撃	端末上の非特権マルウェア	ユーザー操作・生体認証・端末ロック解除なしでパスキー認証を突破。ただしサービス提供者がUV（ユーザー確認）フラグを厳格に検証していれば失敗する
Silver Pass-ta-key攻撃	端末上の非特権マルウェア、UV検証を行うサービスが対象	端末を再登録させ、攻撃者が生成した鍵をUVキーとして偽装登録。以降は被害者の端末なしで生体認証済みの認証を偽装可能
Golden Pass-ta-key攻撃	端末上の非特権マルウェア、再オンボーディングの発生	パスキーの秘密鍵を復号するマスターキー（Security Domain Secret）をメモリから窃取し、既存・将来のすべての同期パスキーを復号可能に
対象範囲	Windows上のGoogle Chrome、TPM搭載端末、Google Password Managerの同期パスキー	他ブラウザ・他プラットフォームのクラウド認証器モデルにも類似の設計上の論点が及ぶ可能性

研究の背景：なぜパスキーが「フィッシング耐性の標準」とされてきたか

米国では、CISA（サイバーセキュリティ・インフラセキュリティ庁）が2022年以降、複数のファクトシートを通じてフィッシング耐性MFAの導入を強く推奨しており、FIDO2/WebAuthnを、広く利用可能な唯一のフィッシング耐性認証方式として位置づけています。この方針は、OMB（行政管理予算局）が2022年に発出した覚書M-22-09により、連邦機関に対してゼロトラストアーキテクチャの一環としてフィッシング耐性認証の導入を義務付けたことを受けたものです。

米国立標準技術研究所（NIST）も、デジタルアイデンティティに関するガイドラインSP 800-63Bの中で、認証保証レベル（AAL）という枠組みを用いてこの考え方を体系化しています。最も高い保証レベルであるAAL3では、FIDO2やPIV（政府職員証）といった暗号ベースのMFA方式のみが認められており、2026年に改訂されたガイドラインでは、AAL2の段階からフィッシング耐性を持つ認証手段を少なくとも一つ提供することが求められるようになっています。

こうした経緯から、パスキーやFIDO2/WebAuthnは、従来のパスワードやSMS・アプリ通知型のワンタイムコードに比べて、フィッシングサイトを介した認証情報の窃取や中間者攻撃に対して構造的に強いとされ、米国政府機関だけでなく民間企業においても、認証方式の見直しにあたっての事実上の到達点として広く参照されてきました。

Unit 42が報告した3つの攻撃

Unit 42の研究は、この前提を覆すものではなく、実装レベルで生じているギャップを指摘するものです。研究チームは、Googleの同期パスキーの仕組みを対象に、それぞれ異なる強度を持つ3つの攻撃を実証しています。

1つ目のPass-ta-key攻撃は、端末上で動作する非特権のマルウェアが、Chromeが本来デバイスの識別に使う鍵を悪用し、ユーザーの操作や生体認証を経ずに、クラウド認証器に対して正規の端末からのリクエストであるかのように偽装するというものです。

2つ目のSilver Pass-ta-key攻撃は、より深刻です。サービス提供者側がユーザー確認（UV）を必須にしている場合でも、攻撃者は被害者の端末の登録を無効化したうえで、自ら生成した鍵をユーザー確認用の鍵として登録させることができます。これにより、以降は被害者の端末を経由せずとも、攻撃者自身の環境から、生体認証済みであるかのような認証を継続的に行えるようになります。

3つ目のGolden Pass-ta-key攻撃は、最も影響範囲が広い攻撃です。同期パスキーの秘密鍵を復号するために使われるマスターキー（Security Domain Secret）が、本来アクセスできないはずのクライアント側のメモリ上に一時的に平文で存在する状態を突き、これを窃取します。このマスターキーを入手した攻撃者は、既存のすべての同期パスキーだけでなく、今後新たに作成されるパスキーまで復号できてしまうとされています。

なぜ影響が生じるのか：設計と実装のギャップ

Unit 42は、これらの攻撃が暗号方式そのものの欠陥ではなく、クライアントデバイスへの信頼、サービス提供者側での検証の一貫性の欠如、オンボーディングおよび復旧フローの弱さという3つのギャップに起因すると結論づけています。

とりわけ実務上重要なのは、ユーザー確認（UV）フラグの検証にまつわる指摘です。認証データの中には、生体認証やPINによる確認が行われたかどうかを示す1ビットのフラグが含まれていますが、このフラグを厳密に検証していないサービス提供者が存在することが、今回の調査で確認されています。研究チームは実例として、フラグ検証を行っていなかったeBayに対する攻撃の再現に成功したことを示しており、報告を受けてeBayはすでに修正を行っています。フラグの検証が行われない場合、本来は複数要素で保護されているはずの認証が、実質的に単一要素まで弱まってしまうことになります。

対象範囲と留意点

今回の研究で示された攻撃はいずれも、対象端末にあらかじめマルウェアが存在していることを前提としています。

攻撃者が正規の端末を経由せずにゼロからパスキーを窃取できるわけではなく、エンドポイントの侵害が引き続き脅威モデルの中心にある点は変わりません。

また、検証の対象はWindows上のGoogle Chrome、TPM搭載端末におけるGoogle Password Managerの同期パスキーに限定されています。Unit 42は、同種のクラウド認証器モデルは他のパスキー提供事業者やブラウザ・プラットフォームでも採用されていると述べており、同様の設計上の論点が他の実装にも及ぶ可能性を指摘しています。

なお、研究チームはGoogleに対しても責任ある開示を行っており、マスターキーがログに平文で出力されていた問題については、報告を受けてGoogleがログ出力の仕様を修正しています。

パスキーは「フィッシング耐性」であって「マルウェア耐性」ではない

当サイトではこれまで、中間者攻撃（AiTM攻撃）とはや、中国語圏PhaaSが日本を標的にサイバー攻撃、ロシア系APT「UNC1151/Ghostwriter」がGmailを標的にサイバー攻撃などの記事で、SMSや認証アプリによるOTPベースのMFAがAiTM攻撃によって突破される問題への対策として、FIDO2/WebAuthnおよびパスキーへの移行を繰り返し推奨してきました。

この推奨自体は、今回のUnit 42の研究によっても変わりません。パスキーが、認証情報をドメインに暗号的に紐付けることで、偽サイトへの入力を無効化するという設計は今回の攻撃でも破られておらず、フィッシングサイトを介した認証情報の窃取という観点では、パスキーは引き続き有効な対策です。

一方で今回の研究が示しているのは、パスキーの安全性が、端末そのものが健全であるという前提の上に成り立っている点です。端末がすでにマルウェアに感染している場合、パスキーはAiTM攻撃には強くても、エンドポイントの侵害そのものを防ぐものではありません。パスキーとは？メリットや概要を解説や多要素認証(MFA)とは？メリットや必要性を解説であわせて導入を検討する際も、パスキーへの移行とあわせて、エンドポイントの保護（EDR等によるマルウェア対策）を組み合わせる必要がある点を押さえておくことをおすすめします。

情報システム部門が確認すべき対策ポイント

自社が利用・提供しているサービスについて、WebAuthnのuserVerificationパラメータをrequiredに設定し、認証レスポンス内のUVフラグを実際に検証しているかを確認してください。検証していない場合、MFAが実質的に単一要素まで弱まっている可能性があります。
新たに登録される端末鍵・ユーザー確認鍵について、その出所とアテステーション（真正性の証明）を検証する仕組みがあるかを確認してください。
パスキーの復旧・再オンボーディングのフローが、通常の認証時には想定されない頻度で発生していないかを監視してください。想定外の復旧プロンプトの発生は、フィッシングやローカルでの状態操作の兆候である可能性があります。
パスキーに関連するローカルの保存領域（Chromeの同期データベースやローカル状態ファイルなど）へのアクセスを、ブラウザプロセスおよびプラットフォームのアクセス制御の範囲内に限定してください。
パスキー・FIDO2の導入を、エンドポイント保護やマルウェア対策と切り離して考えないでください。今回の研究が示すとおり、認証方式の強化と、端末そのものの健全性維持は、両輪で進める必要があります。
自社サービスの認証実装について、署名カウンター（signCount）などの仕組みを用いて、同一の認証情報が想定外の環境から繰り返し使われていないかを検知できる体制があるかを点検してください。