技術 約7分で読めます

Chrome 146のDBSCがセッションクッキー窃取をTPMで無効化する仕組み

Chrome セキュリティ 認証 TPM Web
いけさん目次

情報窃取マルウェア（インフォスティーラー）がセッションCookieを抜いて闇市場に流す手口は、もう何年も前からWebセキュリティの泣き所だった。
パスワードを変えても、MFAを設定しても、有効なセッションCookieを握られたら素通りされる。
Googleがこの問題に対するハードウェアレベルの回答として開発してきたDevice Bound Session Credentials（DBSC）が、Chrome 146でついにWindows全ユーザーに正式展開された。

セッションCookie窃取がなぜ厄介か

ブラウザのセッションCookieは認証トークンそのものだ。
ログイン後にサーバーから発行され、以降のリクエストに自動付与されることで「ログイン済み」状態を維持する。
問題は、このCookieがファイルやメモリに平文同然で保存されていること。

LummaC2のようなインフォスティーラーは、感染したデバイスのローカルファイルとメモリからCookieを読み取り、攻撃者のサーバーに送信する。
攻撃者は受け取ったCookieを自分のブラウザにセットするだけで、被害者のアカウントにパスワードなしでログインできる。
Cookieの有効期限が長ければ数週間〜数ヶ月にわたってアクセスが持続する。
AIエージェントを踏み台にするAMOSのように、インフォスティーラーの配布経路自体も巧妙化が進んでいる。

Google自身が「OSレベルでアクセスできるマルウェアからCookieの窃取を完全に防ぐ純ソフトウェアのソリューションは存在しない」と明言している。
ソフトウェアだけで守れないなら、ハードウェアに頼るしかない。

DBSCの仕組み

DBSCの基本的な発想は単純で、セッションをデバイスのハードウェアに紐づける。
TPM（Trusted Platform Module）に格納した秘密鍵でセッションの所有権を証明し続けなければCookieが更新されない仕組みだ。

sequenceDiagram
    participant Browser as Chrome
    participant TPM as TPM<br/>(秘密鍵保管)
    participant Server as Webサーバー

    Browser->>Server: ログイン認証
    Server->>Browser: Secure-Session-Registration ヘッダ<br/>+ 長寿命Cookie
    Browser->>TPM: 鍵ペア生成を要求
    TPM->>Browser: 公開鍵を返却<br/>（秘密鍵はTPM内に保持）
    Browser->>Server: 公開鍵をJWTで送信<br/>（登録エンドポイント）
    Server->>Browser: セッション設定<br/>+ 短寿命Cookie（10分）

    Note over Browser,Server: 10分後、Cookieが期限切れ

    Browser->>Server: リフレッシュ要求<br/>Sec-Secure-Session-Id
    Server->>Browser: チャレンジ送信<br/>Secure-Session-Challenge
    Browser->>TPM: チャレンジに署名を要求
    TPM->>Browser: 署名済みJWTを返却
    Browser->>Server: 署名済みJWT送信<br/>Secure-Session-Response
    Server->>Browser: 新しい短寿命Cookie発行

流れを分解すると以下のようになる。

1. 登録フェーズ

ユーザーがログインすると、サーバーはレスポンスに Secure-Session-Registration ヘッダを含める。
Chromeはこれを受けてTPMに公開鍵・秘密鍵のペアを生成させ、秘密鍵をTPM内に閉じ込める。
公開鍵はJWT（JSON Web Token）に載せてサーバーの登録エンドポイントに送る。
サーバーは長寿命Cookieを短寿命Cookie（通常10分程度）に置き換え、DBSCセッションの設定を返す。

2. リフレッシュフェーズ

短寿命Cookieが期限切れになると、Chromeはサーバーのリフレッシュエンドポイントにリクエストを送る。
サーバーはチャレンジ値を返し、ChromeはTPMの秘密鍵でそのチャレンジに署名して返送する。
サーバーは署名を検証し、正当なら新しい短寿命Cookieを発行する。

3. 攻撃者の手元では

仮にインフォスティーラーがCookieを盗み出しても、そのCookieは最長10分で期限切れになる。
リフレッシュにはTPM内の秘密鍵が必要だが、TPMの秘密鍵はハードウェア的にエクスポートできない。
攻撃者は別のデバイスからリフレッシュを試みても、秘密鍵の所有証明ができずに弾かれる。

TPMとは何か

TPM（Trusted Platform Module）は、暗号鍵の生成・保管・署名をハードウェアレベルで行う専用セキュリティチップだ。
Windows 11ではTPM 2.0が必須要件になっているため、現行のWindows PCにはほぼ確実に搭載されている。

DBSCの文脈でTPMが果たす役割は「秘密鍵の牢獄」だ。
TPM内で生成された秘密鍵はチップの外に出ることがなく、OSレベルのマルウェアであっても秘密鍵そのものを読み取ることはできない。
署名操作はTPMの内部で完結し、外部には署名結果だけが返る。

macOS版ChromeではTPMの代わりにSecure Enclaveが同じ役割を果たす予定だが、macOS版の展開時期はまだ発表されていない。

TPMを搭載していないデバイスや、TPMの署名処理がビジー状態の場合、DBSCは従来の長寿命Cookieにフォールバックする。
セキュリティが下がるだけで、サイトが使えなくなるわけではない。

HTTPヘッダの詳細

DBSCはW3Cの Web Application Security Working Group で標準化が進められた。プロトコルで使うHTTPヘッダを整理する。

ヘッダ名方向用途
Secure-Session-RegistrationレスポンスDBSC登録の開始。対応アルゴリズムと登録エンドポイントを通知
Secure-Session-Challengeレスポンスリフレッシュ時のチャレンジ値を送信
Secure-Session-Responseリクエストチャレンジに対する署名済みJWT（DBSC proof）を送信
Sec-Secure-Session-Idリクエストリフレッシュ対象のセッションIDを指定

署名アルゴリズムはES256（ECDSA + SHA-256）とRS256（RSA + SHA-256）に対応する。
JWTのヘッダには "typ": "dbsc+jwt" を指定し、ペイロードにはチャレンジ値（jti）、リフレッシュURLを示すオーディエンス（aud）、公開鍵（jwk）を含める。

サーバー側の対応

DBSCの展開でよく出る疑問が「サーバー側の改修はどの程度か」という点だ。
Googleの説明によれば、フロントエンドのコード変更は不要で、バックエンドに登録エンドポイントとリフレッシュエンドポイントを追加するだけで対応できる。

サーバーが実装する処理は以下の通り。

  1. ログインレスポンスに Secure-Session-Registration ヘッダを付与
  2. 登録エンドポイントでJWTを受け取り、公開鍵を保存し、セッション設定（スコープ、保護対象Cookie、リフレッシュURL）をJSONで返す
  3. リフレッシュエンドポイントでチャレンジを発行し、署名を検証し、新しい短寿命Cookieを発行する
  4. 長寿命Cookieと短寿命Cookieを併用するデュアルCookie方式を採用し、DBSCの一時的な障害時にも基本的なセッション維持を可能にする

GoogleはすでにOktaと共同でテストを行い、自社サービスでも過去1年にわたって先行バージョンを運用してきた。
その結果「デプロイ開始以来、セッション窃取の測定可能な減少」が確認されたとしている。

プライバシー設計

セキュリティ機能がトラッキングの道具に化けた過去の事例は少なくない。
DBSCはそうならないよう、プライバシー面で意識的な制約を設けている。

セッションごとに異なる鍵ペアを生成するため、サイトが鍵を使ってユーザーのセッション間の紐づけを行うことはできない。
異なるサイト間での相関も不可能だ。
サーバーに送信されるのはセッション固有の公開鍵だけで、デバイス識別子やアテステーションデータは一切共有されない。
DBSCをフィンガープリンティングに悪用することはプロトコル設計上できない。

制約と今後の展開

現時点でのDBSCの制約を挙げる。

  • Windows版Chrome 146限定。macOS版は今後のリリースで対応予定だがタイムラインは未発表
  • HTTPSページでのみ動作
  • Partitioned 属性のCookieとは互換性がない（Privacy Sandboxのパーティショニングとの共存はまだ）
  • サードパーティCookieをブロックしている環境では機能しない
  • TPMの処理能力には上限があり、システム全体でTPMへの署名リクエストが集中すると遅延が発生する可能性がある

Chrome 135でのオリジントライアルから約1年かけて正式リリースに至った。
現在GoogleはDBSCの適用範囲をさらに広げる開発を進めている。

  • フェデレーテッドID対応 — SSOで認証プロバイダ経由でログインした場合に、リライングパーティ（サービス提供側）のセッションも同一デバイスキーに紐づけ、認証チェーン全体を保護する
  • 拡張登録 — mTLS証明書やハードウェアセキュリティキーなど、既存の信頼済み鍵素材にDBSCセッションを紐づける仕組み
  • ソフトウェアベースの鍵サポート — TPMやSecure Enclaveを搭載していないデバイスでも、ソフトウェア鍵でDBSCを利用可能にする。セキュリティ強度は下がるが、カバレッジを優先する判断

Chrome 146では Dawn（WebGPU実装）のゼロデイ脆弱性CVE-2026-5281 や SkiaとV8のゼロデイ2件 などセキュリティアップデートが相次いでいる。
DBSCはそれらの脆弱性修正とは異なり、セッションCookie窃取というインフォスティーラーの最も実入りのいい攻撃手法に対して「盗んでも使えない」状態を作り出す、攻撃のビジネスモデル自体を潰しにいく仕組みだ。