ニュースを読むときに、まずここだけ押さえてください。

もう少しだけ丁寧に言い直します。パスキーの中心にある暗号技術（公開鍵暗号）には、今回まったく傷がついていません。破られたのは暗号ではなく、その周りにある「日常の手続き」のほうでした。具体的には、こんな手続きです。

• この端末は本人のものかを確かめる手続き
• 機種変更したときにパスキーを引き継ぐ手続き
• 新しい端末を登録するときの手続き
• Webサイト側が「本人確認済み」の印をちゃんと見ているか

玄関の鍵をどれだけ頑丈にしても、合鍵を作る手続きがゆるければ意味がない──今回の話は、まさにそれです。

この記事を象徴する、ひとつのたとえ

多くの人が、パスキーについてこう理解しています。

「パスキーの鍵は、パソコンの中の金庫（TPM）に入っている。
だから絶対に取り出せない」

ところが、Googleのパスワードマネージャーで複数の端末に同期されるタイプのパスキーでは、この理解が当てはまりません。

金庫の中に入っていたのは「鍵」ではなく、
「あなたの社員証」だった。

鍵そのものは、暗号化された状態でクラウドの倉庫に預けられています。金庫にあるのは、その倉庫に「私は本人です」と名乗るための社員証です。

そして今回の攻撃は、金庫をこじ開けたのではなく、金庫に「その社員証でハンコを押して」と頼んだだけでした。金庫は、頼んできたのが本人かどうかを見分けません。ここが、この記事でいちばん重要な一点です。

ではなぜ金庫は見分けてくれないのか。なぜ倉庫は偽の社員証を疑わないのか。それを第3章以降で順番にほどいていきます。その前に、多くの方が真っ先に知りたいであろう「で、私は関係あるの？」に先に答えます。

第1章 おわり — 次は第2章

この研究が検証したのは、とても限定された組み合わせです。あなたがどれに当てはまるか、まず確認してください。

そして、全タイプに共通する大前提

もうひとつ、絶対に外せない条件があります。

ここまで読んで「じゃあ大したことないのでは」と思われたかもしれません。半分はそのとおりです。しかし、残りの半分に見過ごせない点があります。

「感染しなければ大丈夫」は正しい。けれど「感染しても管理者権限を渡さなければ大丈夫」は間違い。この線引きの変化こそが、今回いちばん実務的に重い部分です。

第2章 おわり — 次は第3章

ここは飛ばしても構いませんが、読んでおくと第4章がぐっと分かりやすくなります。すでにご存じの方は次の章へどうぞ。

パスキーは「合言葉」ではなく「ハンコ」

パスワードは合言葉です。相手に伝えることで本人だと認めてもらう仕組みなので、伝えた瞬間に盗まれる危険がついてまわります。

パスキーはハンコに近い仕組みです。パスキーを作ると、対になる2つのデータができます。

ログインのときは、こう進みます。

1. Webサイトが「この紙にハンコを押してください」と、毎回ちがう紙（チャレンジ）を送ってくる
2. あなたの端末が、指紋や顔、PINで本人確認する
3. 秘密鍵でその紙に押印する（＝署名する）
4. 押印した紙だけを送り返す。ハンコ本体は送らない

ハンコ本体が一度も外に出ないので、途中で通信を盗み見られても押印の再現ができません。これがパスキーの強さです。

フィッシングに強い、本当の理由

もうひとつ、パスキーには重要な性質があります。パスキーは、作られたときのWebサイトのアドレス（ドメイン）と結びついているのです。

そして問題は「複数の端末で使いたい」から始まった

ハンコが1本しかなければ、その端末でしかログインできません。パソコンで作ったパスキーはスマホで使えず、機種変更したらすべて作り直し──それでは不便すぎます。

そこで登場したのが同期パスキーです。Googleパスワードマネージャーやアップルの iCloudキーチェーンが、パスキーをクラウド経由で全端末に配ってくれます。便利になりました。

しかし、便利さには構造の変化がついてきます。「端末から出ない鍵」だったはずのものが、「クラウドを行き来する鍵」に変わったのです。今回の研究は、まさにこの変化が生んだすき間を突いています。

第3章 おわり — 次は第4章

ここが今回の研究のいちばんおもしろく、そしていちばん誤解されている部分です。

よくある思い込み

「パスキーは安全」と説明されるとき、たいてい次のように語られます。

秘密鍵は TPM（パソコンに載っている小さなセキュリティチップ）や、スマホの Secure Enclave の中に保管されます。これらのチップからは鍵を取り出せない設計になっているため、盗まれる心配がありません。

この説明はまちがってはいません。USB型のセキュリティキーや、その端末だけで使うパスキーには、そのまま当てはまります。

しかし──Googleパスワードマネージャーで同期されるパスキーには、当てはまりません。

登場する4つの鍵を、表で整理する

ここが分かれば、この記事の8割は理解できたことになります。同期パスキーの世界には、役割の違う鍵が4種類あります。

この一点が腑に落ちれば、次の章で出てくる3つの攻撃は、すべて素直に理解できます。

第4章 おわり — 次は第5章

Unit 42が示したのは3つの攻撃です。名前は、Windowsの世界で古くから知られる「ゴールデンチケット」という攻撃にならって付けられています。基本形 → シルバー → ゴールデンの順に深刻さが増していきます。

① Pass-ta-key（基本形）── 本人確認が「そもそも求められていない」

まず基本形です。この攻撃は、実は指紋認証も顔認証も突破していません。もっと拍子抜けする話で、そもそも本人確認を求められていないのです。

流れをたどるとこうなります。

1. Chromeが保存している、暗号化されたパスキーの一覧を見つける
2. TPMの中の「端末の身分証」に、Windowsの標準機能を使って押印を頼む
3. TPMは頼まれたとおりに押印する（管理者権限もロック解除も不要）
4. その署名をGoogleのクラウド窓口へ送ると、「正規の端末からの依頼だ」と認められてしまう

できあがった署名は、本物のログインとほとんど区別がつきません。違いはたった1ビット──「本人確認済み」を表す小さな印（UVフラグ）が立っていない、それだけです。

そして、ここからが大事なところです。この1ビットを、Webサイト側がちゃんと見ているかどうかで結果が変わります。

② Silver Pass-ta-key ── 本人確認の鍵を、丸ごと差し替える

基本形は、きちんと設定されたサイトなら防げました。では攻撃者はどうするか。「本人確認済み」の印を、本当に立てられるようにしてしまうのです。

ここで狙われるのが、第4章の表にあったUV鍵（本人確認の鍵）です。

1. マルウェアが、端末に保存されている本人確認の状態をリセットする
2. Chromeが「本人確認の鍵をもう一度登録しなければ」という状態になる
3. Chromeが正しい鍵を作るより先に、攻撃者が自分の鍵を登録する
4. Googleのクラウド窓口は、その鍵が本物のハードウェアで作られたものか確認していないため、そのまま受理する

もうひとつ怖いのは、この攻撃はあなたがパソコンの前にいなくても成立するという点です。攻撃者が自分の鍵を登録してしまえば、あとは自分の環境からログインできます。

③ Golden Pass-ta-key ── 倉庫のマスターキーを盗む

最後が、いちばん深刻な攻撃です。狙うのは、第4章の表に出てきた SDS（マスターキー）。同期されているパスキーの秘密鍵を、すべて復号できる32バイトのデータです。

ふだんSDSは暗号化されていて手が出せません。しかし、ひとつだけ無防備になる瞬間があります。新しい端末を登録するときと、アクセスを復旧するときです。

そして、ここが巧妙なところです。攻撃者は、その瞬間が自然にやってくるのを待ちません。②のSilver Pass-ta-keyで使った「再登録を強制する」手口をそのまま使えば、無防備な瞬間を自分の手で作り出せるからです。つまり②と③は、別々の攻撃というよりひと続きの流れになっています。

さらに研究チームは、Chromeの内部ログ画面（chrome://device-log）にこのマスターキーがそのまま表示されていたことも見つけました。この点はGoogleに報告され、すでにログから削除されています。

そして、この攻撃が「ゴールデン」と呼ばれる本当の理由がここです。

3つを並べて比べる

第5章 おわり — 次は第6章

このニュースを日本語で最初に報じたのは、PC Watchの記事「Googleパスワードマネージャーに脆弱性、マルウェアでパスキー保護を突破可能に」（宇都宮充氏／2026年8月5日）です。短くよくまとまった記事なのですが、専門用語が多く、一読しただけでは何が起きたのか掴みにくいのも事実だと思います。

この章では、その記事に出てくる言い回しを一つずつ日常のことばに翻訳していきます。ニュースを読んで「難しくてよく分からなかった」という方は、ここだけ読んでも大丈夫です。

まず、見出しの「脆弱性」という言葉について

見出しには「Googleパスワードマネージャーに脆弱性」とあります。ここで多くの人が思い浮かべるのは、「プログラムのバグが見つかって、修正プログラムを当てれば直るもの」ではないでしょうか。

ニュースの表現を、そのまま翻訳してみる

左が記事に出てくる表現、右がその意味です。第4章と第5章を読んだあとなら、すべて見覚えのある話になっているはずです。

Unit 42が示した対策は、3つの立場に分かれている

記事の後半では対策が挙げられていますが、誰に向けた話なのかが混ざっていて分かりにくい部分です。立場ごとに整理すると、こうなります。

第6章 おわり — 次は第7章

研究チーム自身が、破ったのは暗号ではないとはっきり述べています。では何を破ったのか。整理すると4つのすき間に行き着きます。

Webサイトを運営している方へ

この記事の読者のなかには、サービスを運営している方もいらっしゃると思います。今回いちばん即効性のある対策は、実はサイト側にあります。

// 1. リクエスト時に「本人確認は必須」と伝える
userVerification: "required"

// 2. ここが抜けやすい ──
//    返ってきた応答の「本人確認済みフラグ（UV）」を
//    必ず自分で検証する
if (authenticatorData.flags.uv !== true) {
    // 本人確認されていない → 受け付けない
    reject();
}

第7章 おわり — 次は第8章

この手のニュースでは「Googleが修正しました」で締めくくられがちですが、2026年8月5日時点の実際の状況は、もう少し複雑です。

それでも、パスキーをやめる理由にはならない

ここは強調しておきたい部分です。今回の研究でパスキーの価値が下がったわけではありません。

表を見れば分かるとおり、5つのうち4つでパスキーは変わらず強いままです。そして最後の1行「端末がウイルス感染」については、パスワードでも同じかそれ以上に危険です。パスワードに戻して得をすることは何もありません。

第8章 おわり — 次は第9章

今回の攻撃は、すべて「先に感染していること」から始まります。ということは、対策の中心も自然に決まります。

まず、最初にやること3ステップ

3番目の「守りを1段上げる」を具体的に

全部のアカウントを完璧にする必要はありません。そこを乗っ取られると他も芋づる式に取られてしまうアカウントだけを選んで手当てします。典型的には、Googleアカウント、Appleアカウント、メール、ネットバンキング、証券口座です。

第9章 おわり — 次はよくある質問