同期パスキーの暗号化鍵 SDS は Chrome メモリーに平文で出る：端末マルウェア前提の備え

いつ使うか

• 組織で Chrome の同期パスキーを主認証にしているとき
• エンドポイントで情報窃取マルウェアを警戒しているとき
• 「パスキーにしたから端末感染後も大丈夫」と思い込みがあるとき

仕組みの要約（防御に必要な範囲）

• Unit 42 の Pass-ta-key「Golden」型: 32 バイトの SDS を奪い、暗号化済みパスキーデータと合わせて秘密鍵を復元する考え方。
• ログへの平文出力は Google が修正（CVE-2025-12910）。一方、リクエスト組み立て中にメモリー上で平文になる点は、端末で暗号処理する以上避けにくいと研究者は説明。
• 攻撃者は passkey_enclave_state を消して再登録を誘い、利用者がパスキーを使う／作る数百ミリ秒の窓で SDS を読む、という流れが解説されている。
• Google 側は「既にマルウェアが動く端末」を脅威モデル外とする立場、との整理。

実務でやること

1. 高リスクアカウント（IdP、クラウド、銀行、ソース管理）は、同期パスキーより ハードウェアセキュリティーキーや端末内の非同期パスキー を優先する。
2. EDR で passkey_enclave_state 相当の登録状態ファイルの削除・改ざん後の再登録を検知・アラートする（Unit 42 の推奨）。
3. パスキー再登録が短い期間に連続したら、利用者確認まで認証を追加ステップにする。
4. 端末感染が疑われる場合は、パスキーの有無にかかわらずセッション無効化と再登録を行う（SDS に失効の仕組みが無いとの指摘あり）。
5. 関連: パスキーは「パスワードの後に使う 2 要素目」ではなく、パスワードの代わりとして実装する、パスキーで「詰まない」ための運用のコツ

注意

• これは「パスキーが破られた」のではなく、「端末にマルウェアがいる前提では同期鍵も読まれうる」話。フィッシング耐性自体は別軸で有効。
• 再現手順や抽出コードは扱わない。監視と認証器の選択に使う。

出典

• @MalwareBibleJP · 2026-11-05