Googleのパスキーエコシステムは静かに強力なクラウド側コンポーネントに依存しており、「パスワードレス信頼」が実際に存在する場所を変え、その変化により実世界でのアカウント乗っ取りの新たな道を開く可能性があります。
ほとんどのパスキーの議論はWebAuthnとFIDO仕様に焦点を当てていますが、攻撃者は仕様ではなく実装に関心があります。
Googleの場合、同期されたパスキーはChrome、OS、TPMハードウェア、およびenclave.ua5v[.]comで到達可能なクラウド認証器の上に位置します。
このレイヤード設計はユーザビリティとクロスデバイス同期を提供します。ただし、これはリスクを、主に見えないところで動作するいくつかの高価値コンポーネントに集中させます。
レポートによると、Googleのアーキテクチャは強力なデバイスバインディングを維持しながら、ユーザーが回復とローミングできるようにすることを目指しており、これはまさに攻撃者が弱点を探す場所です。
このスタックが実際にどのように機能するかを理解することは、成熟した企業でのパスワードレス環境の脅威モデリングにとって必須になりました。
Googleのクラウド認証器内部
ユーザーがデスクトップでGoogle Password Manager (GPM)パスキーを有効にすると、Chromeはenclave.ua5v[.]comの背後で実行されるクラウドベースの認証器にデバイスをサイレントにオンボードします。
ブラウザは2つのTPM対応キーペアを生成します：物理デバイスを表す識別キーと、Windows Helloまたはもしくはローカルロック解除方法でゲートされるユーザー検証（UV）キーです。
Chromeはその後デバイスをクラウドサービスに登録し、これらのキーの公開部分と、識別公開キーから派生したデバイス識別子を送信します。
クラウド認証器はこれらのハードウェアバウンドされた公開キーを保存し、Chromeが不透明なブロブとしてローカルにキャッシュするシークレットを暗号化するために使用される、デバイスごとのラッピングキーを作成します。
また、メンバーキーペアを発行し、デバイスがユーザーの「セキュリティドメイン」（同期されたパスキーにアクセスを許可される信頼できるエンドポイントのセット）に参加できるようにします。これは信頼がハードウェアに固定されているが、クラウドで調整されるハイブリッドモデルの始まりです。
最初に登録されたデバイスでは、ChromeとGoogle認証器がさらに進み、アカウントレベルのシークレットを確立します。
セキュリティドメインシークレット（SDS）、つまり対称的なマスターキーを派生させ、クラウドサービスがそのアカウントのすべてのパスキー秘密鍵を暗号化するために使用します。同時に、ユーザーはGoogle Password Manager PINを作成し、同じセキュリティドメインにデバイスを追加または復復するためのゲートになります。
Googleの信頼されたボルトとChrome同期インフラストラクチャはこれらを一緒に結び、暗号化キーを管理し、登録されたデバイス間でパスキーマテリアルを配布します。
ローカルでは、Chromeはpasskey_enclave_stateファイルを書き込み、これはシールされたデバイスキー、ラップされたSDSとPINデータを保持し、完全なオンボーディングフローを繰り返さずに将来の操作を可能にします。このファイルはクラウド認証器がデバイスを再度信頼する必要があるすべてのコンパクトなマップになります。
サイトがnavigator.credentials.create()を呼び出し、ユーザーがGPMを選択すると、Chromeはクラウド認証器への暗号化されたセッションを開き、デバイスIDとラップされたSDSブロブを含む「passkeys/create」リクエストを送信します。
クラウドサービスはデバイスごとのラッピングキーを見つけ、SDSをアンラップし、新しいP‑256パスキーキーペアを生成し、秘密鍵をSDSで暗号化してから送り返します。
Chromeはその公開キーを証明書利用者に転送し、暗号化された認証情報レコード（WebauthnCredentialSpecifics）を同期レイヤーに保存し、他の信頼されたデバイスがそれを使用できるようにします。
ログインの場合、navigator.credentials.get()は同じチャネルを通じて「passkeys/assert」リクエストをトリガーします。クラウド認証器は再度SDSを派生させ、パスキー秘密鍵を復号化し、WebAuthn認証器データを構築して署名し、ウェブサイトが以前登録された公開キーで検証する標準的なアサーションを返します。
証明書利用者の観点からは、秘密鍵操作がクラウドエンクレーブで発生したにもかかわらず、これは通常のハードウェア対応WebAuthnアサーションのように見えます。
セキュアトンネルとデバイスバインディング
すべてのデバイスクラウドトラフィックは、Google OAuth2、WebSocket、Noiseフレームワーク、TPMバウンドされた署名の上に階層化される専用のセキュアな通信プロトコルでラップされています。
Chromeは最初に特別なセキュアアイデンティティスコープを持つアクセストークンを取得し、enclave.ua5v[.]comへのWebSocketを開き、ブラウザに焼き込まれた静的なクラウド公開キーを使用してNoise_NK_P256_AESGCM_SHA256ハンドシェイクを実行します。
その後、各リクエストは識別キーまたはUVキーを使用して署名され、署名はCBORエンコードペイロードとNoiseハンドシェイクハッシュの両方をカバーし、操作を物理デバイスと活動的なセッションの両方にバインドします。
Windowsでは、Chromeはプラットフォームのcng APIとWindows Helloを活用してこれらの署名をTPM内で実行し、クラウド認証器は保存された公開キーに対してそれらを検証します。
この設計は、暗号化されたアサーションがクラウドで生成されるにもかかわらず、実際のエンドポイント上のハードウェア保護キーからの所有証明を必要とすることを保証しようとしています。
秘密鍵操作をクラウドエンクレーブに移動しながらデバイスキーを強力なアンカーとして保つことで、Googleは大規模なセキュリティ、ユーザビリティ、および復復のバランスを取ろうとしています。
同時に、これはクラウド認証器、復復フロー、およびNoiseセッション、OAuthトークン、およびハードウェアバウンドされたキー間のバインディングに収束する新しいパスワードレス攻撃経路のクラスを導入します。
将来の研究では、攻撃者が同期されたデバイスを偽装する方法、復復を悪用する方法、またはFIDO自体を「破壊」することなく有効なWebAuthnアサーションを取得するためにエンクレーブロジックに干渉する方法を尋ねる必要があります。
それまでの間、防衛者はパスワードレスデプロイメントをパスワードの上の魔法のアップグレードではなく、複雑な分散システムとして扱い、監視、強化、およびアーキテクチャレビューがこれらの隠されたパスキーコントロールプレーンまですべて拡張されることを確認すべきです。
翻訳元: https://gbhackers.com/google-authenticators-passkey/
