パスキー神話の崩壊？Googleパスワードマネジャーの脆弱性が突きつける現実

「パスワードレスこそがセキュリティの最終解」――我々エンジニアは、長らくそう信じて疑わなかった。しかし、米Palo Alto NetworksのUnit 42が突きつけた事実は、その楽観論を根底から覆すものだ。GoogleパスワードマネジャーとWindows上のTPM（Trusted Platform Module）を組み合わせた認証基盤に、致命的な脆弱性が発見された。これは単なるバグではない。認証の根幹である「ハードウェアによる信頼」が、マルウェアという泥臭い現実の前にいかに無力であるかを露呈させたのだ。

今回明らかになった3つの攻撃手法「Pass-ta-key」「Silver Pass-ta-key」「Golden Pass-ta-key」は、いずれも端末がマルウェアに感染しているという前提条件こそあるものの、管理者権限を必要としないという点で極めて危険だ。特に「Pass-ta-key」は、eBayでの実証成功が示す通り、サービス側の検証ロジックが甘ければ、いとも簡単に認証をバイパスできてしまう。我々が実装する認証フローにおいて、「本人確認の結果」を盲信していないだろうか？ サービス側が「認証成功」というフラグだけを見て、その背後にあるハードウェアの正当性や、認証プロセスそのものの整合性を検証していないのであれば、それはデッドロックに陥ったシステムを放置するのと同じくらい無責任な設計と言わざるを得ない。

エンジニアとして痛感するのは、パスキーという「魔法の杖」に頼りすぎた結果、ブラウザやOSのメモリ管理、あるいはTPMとの通信プロトコルといった「足元」のセキュリティを軽視していたのではないかという点だ。特に「Golden Pass-ta-key」において、Chromeのメモリ上にマスターキー（SDS）が平文で展開される瞬間を狙う手法は、メモリダンプやプロセスインジェクションといった古典的かつ強力な攻撃手法が、現代の最新認証技術に対しても依然として有効であることを示している。我々は、パスキーという抽象化されたレイヤーの裏側で、OSやブラウザがどのようなメモリ管理を行っているのか、その「スパゲッティコード」のような複雑な依存関係を、もう一度直視しなければならない。

今回報告された3つの攻撃手法は、攻撃のフェーズごとに明確な役割分担がなされている。まず「Pass-ta-key」は、TPMからIDキーを直接収集する。これは、ハードウェアが安全であるという前提を、マルウェアによる物理的（論理的）アクセスで崩す手法だ。次に「Silver Pass-ta-key」は、認証システムが「新規キー登録」の際に、そのキーが本当にセキュアなハードウェアから生成されたものかを検証しないという設計上の欠陥を突いている。これは、認証プロトコルにおける「信頼の連鎖（Chain of Trust）」が、実装の不備によっていとも簡単に断ち切られることを意味する。

さらに深刻なのが「Golden Pass-ta-key」だ。これは、Chromeに同期された全パスキーを復号するためのマスターキー（SDS）を奪取する。一度このキーが盗まれれば、被害者のアカウントは完全に攻撃者の支配下に置かれる。以下の表は、今回報告された攻撃手法の特性を整理したものだが、これを見ればわかる通り、攻撃の難易度は決して高くない。

これらの攻撃手法を前にして、我々開発者が取るべき対策は何か。Unit 42は、サービス事業者に対して「ログイン時の本人確認情報の確実な検証」と「不審な再登録の検知」を求めている。しかし、これは対症療法に過ぎない。根本的な問題は、ブラウザという巨大なアプリケーションが、パスキーのような極めて機密性の高い情報を、メモリという「誰でも覗ける場所」に一時的に置かざるを得ないというアーキテクチャの限界にある。我々が明日から行うべきは、認証フローの厳格化だけではない。エンドポイントのセキュリティ、すなわちEDR（Endpoint Detection and Response）の導入や、ブラウザのメモリ保護機能の強化といった、より低レイヤーでの防御策を、認証基盤の設計とセットで考えることだ。パスキーを導入すれば安全、という思考停止は、今すぐ捨てるべきだ。

今回の脆弱性は、我々エンジニアに「信頼の根拠」を再定義することを迫っている。パスキーは確かにパスワードの脆弱性を解決したが、それは「パスワードという弱点」を「実装という弱点」に置き換えたに過ぎないのかもしれない。我々は、技術の進化を信じるあまり、その技術が依存するプラットフォームの脆弱性を過小評価していないだろうか。深夜の障害対応でログを追いかける際、我々は「認証が通った」という事実だけで安心し、その認証がどのようなプロセスを経て行われたのか、その背後にあるハードウェアの健全性まで疑うことは稀だ。

しかし、これからの時代、認証は「成功したか否か」というバイナリな判断から、「どのようなコンテキストで、どのようなハードウェアによって、どのようなプロセスで認証されたか」という多次元的な検証へとシフトしなければならない。これは、ゼロトラストアーキテクチャの基本原則そのものだが、パスキーという便利な技術の裏側で、この原則が忘れ去られていたことは否めない。我々エンジニアは、自らが構築するシステムが、いかに脆弱な基盤の上に成り立っているかを常に意識し、最悪の事態を想定した「防御的プログラミング」を認証フローにも適用すべきだ。

最後に、読者であるあなたに問いかけたい。あなたのサービスでパスキーを導入する際、あなたは「認証成功」の裏側にあるハードウェアの正当性を、どこまで検証しているだろうか？ もし、その検証が「ブラウザ任せ」であるならば、それは明日、あなたのサービスが乗っ取られる可能性を放置しているのと同じことだ。技術の利便性を享受する代償として、我々は「疑うこと」を忘れてはならない。明日から、認証ログの精査項目に「ハードウェアの正当性」や「不審なキー登録のパターン」を追加すること。それが、この脆弱性が我々に突きつけた、最も実践的で痛烈な処方箋である。技術は常に進化するが、攻撃者もまた、その進化の隙間を縫って進化し続けている。我々が守るべきは、パスキーという技術そのものではなく、その先にあるユーザーの信頼なのだから。