Device Bound Session Credentials (DBSC) の解説

エンタープライズPasskeyホワイトペーパー. パスキープログラム向けの実践ガイド、展開パターン、KPI。

ホワイトペーパーを入手

ブラウザのサポート状況

凡例: ✅ 一般公開（GA） | 🚧 発表済み / 開発中 | ⏸️ トライアル終了 | 🔄 評価中/モニタリング中 | ❌ 未提供

注: DBSC は、Chrome 146（2026年4月）の時点で、TPM を備えた Windows で GA になっています。次に、Secure Enclave を介した macOS サポートが展開されます。Google の発表したロードマップには、専用のセキュアなハードウェアを持たないデバイスに保護を拡張するためのソフトウェアベースのキーも含まれています。

主な利点: DBSC と現在のモデルの比較

World Wide Web のアーキテクチャは、ステートレスの原則に基づいて設立されました。HTTP が最初に設計されたとき、リクエスト間でユーザーに関する情報は保持されませんでした。これを解決するために、Web サイトから送信されてユーザーのコンピュータに保存され、その後のすべてのリクエストとともに Web サイトに送り返される小さなデータである「Cookie」が発明されました。何十年もの間、このメカニズムはセッション管理の基盤として機能してきました。ユーザーがログインすると、サーバーはクレデンシャルを検証し、Cookie を発行します。この Cookie は「ベアラートークン」として機能します。現実世界では、無記名証券（ベアラー）は、保有者にそれが表す権利や資産を与える文書です。債券を持っていれば、その債券を所有していることになります。同様に、HTTP のデジタル世界では、Cookie を保持していれば、あなたがユーザーです。

このベアラー機能は、Web 最大のユーティリティであると同時に、最も深刻な脆弱性でもあります。セッション全体のセキュリティ、ひいてはユーザーのアイデンティティ、データ、および金融資産は、その Cookie 文字列の機密性に完全に依存しています。悪意のあるアクターがその文字列をコピーできれば、世界中のどこからでも、どのデバイスからでもユーザーになりすますことができ、最初の認証チェックを完全にバイパスできます。この特定の脆弱性により、「Cookie の盗難」や「セッションハイジャック」の産業規模の地下経済が生まれました。

FIDO（Fast Identity Online）標準とパスキーの採用を通じて、業界が認証の「正面玄関」を首尾よく強化するにつれて、攻撃者は焦点を「裏口」、つまりアクティブなセッションに移しています。パスワードのフィッシングは難しくなっていますが、セッション Cookie の盗難は依然として危険なほど効果的です。このエスカレートする脅威に対する業界の対応が、Device Bound Session Credentials (DBSC) です。

DBSC は、Web セッションの維持方法におけるパラダイムシフトを表しています。単なるベアラートークンから脱却し、セッションがデバイスに暗号化されてバインドされるモデルへの移行を提案しています。Chrome 146（2026年4月）が Windows 上で DBSC を GA として出荷したことで、この標準は実験的なものから、Web チームが今日展開できる本番機能へと移行しました。Chrome は Windows で TPM を使用しており、次に macOS の Secure Enclave のサポートを展開する予定です。仕様自体はキーの保存について不可知論的であり、「記載されている脅威に対して堅牢」であることだけを求めています。これにより、盗まれた Cookie の価値ははるかに低くなります。バインドされたキーがなければ、別のデバイスからリフレッシュすることはできません。

この記事では、セキュリティアーキテクト、プロダクトマネージャー、および開発者向けに設計された DBSC の徹底的な分析を提供します。技術的アーキテクチャ、「摩擦のないセキュリティ」のビジネスへの影響、Shared Signals（CAEP/RISC）などの新興標準との関係、および Corbado のようなプラットフォームを使用して組織がこの未来にどのように備えることができるかを探ります。

この記事で答える主な質問

1. 現在のセッション管理がアカウントの乗っ取りを防ぐのに失敗しているのはなぜですか？
2. DBSC は、既存の「セキュア」な Cookie や HttpOnly フラグとどう違いますか？
3. DBSC とパスキーは、どのように連携してフィッシング耐性を強化しますか？
4. トークンバインディングに何が起こり、DBSC が成功している理由は何ですか？
5. プロダクトマネージャーにとってのビジネスへの影響と ROI は何ですか？
6. 現在、どのブラウザとオペレーティングシステムが DBSC をサポートしていますか？
7. 組織はゼロから構築せずに DBSC をどのように実装できますか？
8. DBSC、DPoP、および OAuth 2.0 の関係は何ですか？
9. リアルタイムの脅威対応のために、DBSC は Shared Signals（CAEP/RISC）とどのように統合されますか？

この新しい標準の複雑さを乗り越えるには、まず現在のセッション管理の根本的な問題と、DBSC がどのように解決策を提供するかを理解する必要があります。これらの各領域は、DBSC が対処する重大な脆弱性または制限を表しています。

現在のセッション管理の根本的な失敗は、信頼の「ポータビリティ」です。サーバーがセッション Cookie を発行するとき、それは本質的に、それを保持している誰にでも機能するパスポートを発行していることになります。ブラウザは HttpOnly や Secure フラグ（JavaScript アクセスを防ぎ、HTTPS を介した送信を保証する）などの防御策を実装していますが、これらの防御策は、クロスサイトスクリプティング（XSS）やネットワークスニッフィングなどの特定の抽出ベクトルからのみ保護します。ホストデバイスで実行されているマルウェアからの保護は提供されません。「インフォスティーラー（情報窃取マルウェア）」は、ディスク上のブラウザの Cookie ストレージファイルを特定し、（多くの場合、ユーザー自身の OS レベルのクレデンシャルを使用して）復号化し、コンテンツをコマンドアンドコントロールサーバーに持ち出すように特別に設計されたマルウェアです。攻撃者が Cookie を入手すると、Pass-the-Cookie 攻撃を実行し、盗んだトークンを自分のブラウザに注入してセッションをハイジャックすることができます。サーバーは有効な Cookie を見て、リクエストが正当であると想定します。

DBSC は、セッション維持ループ自体に第2要素認証を導入します。静的なシークレットである標準のセキュアな Cookie とは異なり、DBSC セッションは短期間のベアラートークンと暗号化された所持証明で構成されます。ブラウザは、デバイスに安全に保存される公開鍵と秘密鍵のペアを生成します。サーバーはセッションを公開鍵にバインドします。定期的に、ブラウザはサーバーからのチャレンジに署名することで、秘密鍵をまだ保持していることを証明する必要があります。仕様では、「記載されている脅威に対して堅牢な」キーの保存が義務付けられています。Chrome は、利用可能な場合は Windows 上で TPM を使用します。攻撃者が別のデバイスから Cookie を盗んだ場合、必要な暗号化署名を生成できないため、Cookie をリフレッシュすることはできません。「ベアラー」の側面は非常に短いウィンドウに最小化され、「バインディング」の側面は長期的な継続性を提供します。

パスキーと DBSC は、ユーザーライフサイクルのさまざまな段階を保護する補完的なテクノロジーです。パスキー（FIDO2）は、パスワードなしでセッションを開始するためにアイデンティティを証明するという認証の問題を解決し、クレデンシャルのフィッシングを排除します。DBSC は、Cookie の盗難によるセッションハイジャックを大幅に困難にすることで、認証後の問題に対処します。FIDO アライアンスは、DBSC をセッションハイジャックに対する「基準を引き上げる」補完的なテクノロジーとして位置付けています。DBSC はデバイスへの継続的なアクセスを伴うマルウェアや同じデバイスでのリアルタイムのブラウザインザミドル攻撃からは保護しませんが、これらを組み合わせることで、ログインおよびセッションのライフサイクル全体で攻撃対象領域が縮小されます。

パスキーと DBSC がどのように連携するか

DBSC は、この問題を解決しようとする最初の試みではありません。「トークンバインディング」は、Cookie を基盤となる TLS（Transport Layer Security）接続にバインドしようとした以前の標準でした。暗号化は健全でしたが、トークンバインディングは TLS レイヤーに大きく依存していたため、広く普及することはありませんでした。最新の Web では、多くの場合、TLS 接続はロードバランサー、CDN、またはリバースプロキシで終端され、アプリケーションロジックはその背後のサーバーに存在します。トークンバインディング情報をこれらの複雑なネットワークレイヤー経由で伝播することは、難しすぎることが判明しました。DBSC は、アプリケーションレイヤー（HTTP）で完全に動作することで、この失敗から学びます。基盤となるネットワーク接続に依存しないため、既存のロードバランサー、プロキシ、およびクラウドインフラストラクチャと互換性があります。

プロダクトリーダーにとって、DBSC はユーザーエクスペリエンス（UX）を向上させると同時に、セキュリティを向上させる機会を提供します。従来、高いセキュリティは短いセッションタイムアウトを意味し、ユーザーに頻繁なログイン（摩擦）を強いていました。セッションをデバイスにバインドすることで、リモートでの Cookie 盗難のリスクは大幅に減少します。盗まれた Cookie が別のデバイスからリフレッシュできないことを知っているため、企業はセッション期間を長くすることを検討できます。ただし、DBSC はデバイスの盗難、デバイス上の永続的なマルウェア、または悪意のある使用による悪用からは保護しないため、セッションの有効期間のポリシーには、これらの残存リスクを引き続き反映させる必要があります。

DBSC の背後にある緊急性を理解するには、現代の脅威の状況の洗練さを理解する必要があります。セッション Cookie の盗難は、ニッチなハッカーのトリックから、スケーラブルで自動化された業界へと卒業しました。

graph TD
    A[ユーザーが悪意のあるソフトウェアを<br/>ダウンロード] -->|実行| B[インフォスティーラーが<br/>デバイスで起動]
    B --> C[ブラウザデータを特定]
    C --> D[Chrome/Edge/Firefox<br/>のCookieストレージ]
    C --> E[パスワードデータベース]
    C --> F[暗号資産ウォレット]

    D --> G[OSクレデンシャルを<br/>使用して復号化]
    E --> G
    F --> G

    G --> H[盗んだデータを含む<br/>ログファイルを作成]
    H --> I[C2サーバーへ持ち出し]
    I --> J[ダークWebマーケットプレイス]

    J --> K[攻撃者がログを購入]
    K --> L[自分のブラウザに<br/>Cookieをインポート]
    L --> M[MFAをバイパス]
    M --> N[アカウントの乗っ取り完了]

    style A fill:#ff6b6b,color:#fff
    style B fill:#ff6b6b,color:#fff
    style N fill:#ff6b6b,color:#fff
    style J fill:#495057,color:#fff
    style M fill:#ffd43b,color:#000

MaaS（Malware-as-a-Service）は、サイバー犯罪者の参入障壁を下げました。RedLine、Raccoon、Vidar、Taurus などの「インフォスティーラー」は、Web ブラウザからのデータ引き出しという主な目標の1つを念頭に置いて設計された、市販のマルウェアファミリです。これらのスティーラーは、フィッシングメール、クラックされたソフトウェア、または悪意のある広告を介して配布されます。インストールされると、Chrome、Edge、Firefox などのブラウザがデータを保存する特定のファイルパスを標的にします。

• ターゲット: Cookies データベース（通常は SQLite ファイル）と Login Data データベース（保存されたパスワード）。
• メカニズム: ブラウザは、ユーザーの OS ログインにリンクされた Data Protection API（Windows では DPAPI）を使用して、これらのデータベースを暗号化します。マルウェアはユーザーとして実行されるため、これらのファイルの復号化を簡単に要求できます。
• 出力: マルウェアは「ログ」を生成します。これは、復号化された Cookie、パスワード、システム情報、および場合によっては暗号資産ウォレットのキーを含む zip ファイルです。

これらのログは集約され、Genesis Market（閉鎖前）や Russian Market などのダーク Web マーケットプレイスで販売されます。買い手は、「Salesforce」、「Gmail」、「Bank of America」、または「AWS Console」などの特定の価値の高いターゲットのアクティブな Cookie を含むログを検索できます。

バイパス: Cookie ログの価値は、多要素認証（MFA）をバイパスできることにあります。ほとんどの MFA チャレンジ（SMS、TOTP、プッシュ）は、ログインイベント中にのみ発生します。セッションが確立され、Cookie が発行されると、サーバーはユーザーが信頼できると想定します。有効なセッション Cookie をインポートした攻撃者は、MFA ゲートをすり抜け、アクティブなタブに戻ってきたユーザーとしてサーバーに認識されます。

クラウド生産性スイートは主要なターゲットです。Google Workspace または Microsoft Entra ID（旧 Azure AD）アカウントの盗まれたセッション Cookie は、攻撃者に企業の電子メール、ドキュメント、および内部システムへのアクセスを与える可能性があります。Google 自身の脅威インテリジェンスでは、Google アカウントにアクセスするための主要なベクトルとしての Cookie の盗難の急増を報告しており、これを DBSC への投資の推進力として明確に名指ししています。彼らは、2段階認証（2SV）とパスキーの有効化を強制するにつれて、攻撃者は単にクレデンシャルフィッシング（2SV / パスキーで阻止できる）から Cookie の盗難（2SV / パスキーでは阻止できないことが多い）に戦術を移したと指摘しています。

歴史的に、リスクエンジンは、User-Agent 文字列、画面解像度、インストールされているフォント、IP アドレスなどのデバイスフィンガープリントを分析することで、セッションの盗難を検出しようとしてきました。セッション Cookie が、キャンバスフィンガープリントがわずかに異なる新しい IP から突然現れた場合、サーバーはそれを無効にする可能性があります。問題: ブラウザにおけるプライバシーイニシアチブ（Safari の Intelligent Tracking Prevention や Chrome の Privacy Sandbox など）は、広告トラッキングを阻止するために、これらのフィンガープリントのエントロピーを積極的に減らしています。これにより、セキュリティのための「優れた」フィンガープリントはますます困難になっています。さらに、攻撃者は現在、これらのフィンガープリントを完全にスプーフィングして被害者のプロファイルに一致させることができる「アンチディテクトブラウザ」を使用しており、ヒューリスティックな検出は無効になっています。DBSC は、この確率的な推測ゲームを決定論的な暗号証明に置き換えます。

Device Bound Session Credentials (DBSC) は、クライアントデバイス上のキーにバインドされたセッションを作成するための標準化された API とプロトコルを導入します。仕様では「記載されている脅威に対して堅牢な」キーの保存が義務付けられていますが、実装については不可知論的です。Chrome は、利用可能な場合は Windows 上で TPM を使用します。このセクションでは、W3C のワーキングドラフトと Chrome のドキュメントで定義されているメカニズムについて詳しく説明します。

DBSC ライフサイクルでは、標準セッションからバインドされたセッションへのシームレスな移行が可能になり、下位互換性とプログレッシブエンハンスメントが保証されます。

sequenceDiagram
    participant User
    participant Browser
    participant HSM as HSM (TPM/Secure Enclave)
    participant Server

    Note over User,Server: フェーズ 1: 認証とバインディング
    User->>Browser: クレデンシャル/パスキーでログイン
    Browser->>Server: 認証リクエスト
    Server->>Browser: 成功 + DBSC登録ヘッダー
    Browser->>HSM: キーペアを生成
    HSM->>Browser: 公開鍵/秘密鍵 (秘密鍵はエクスポート不可)
    Browser->>Server: 公開鍵を登録 (JWT署名済み)
    Server->>Server: セッションを公開鍵にバインド
    Server->>Browser: 短命のCookie (5分)

    Note over User,Server: フェーズ 2: 通常の使用
    loop 5分以内のすべてのリクエスト
        Browser->>Server: Cookie付きのリクエスト
        Server->>Browser: レスポンス
    end

    Note over User,Server: フェーズ 3: リフレッシュ (有効期限切れ後)
    Browser->>Server: 期限切れのCookieでリクエスト
    Server->>Browser: 401 + チャレンジノンス
    Browser->>HSM: チャレンジに署名
    HSM->>Browser: 署名
    Browser->>Server: 署名の証明
    Server->>Server: 保存された公開鍵で検証
    Server->>Browser: 新しい短命のCookie
    Browser->>Server: 元のリクエストを再試行
    Server->>Browser: 成功レスポンス

バインディングプロセスは、ユーザーが標準的な方法（パスワード、パスキーなど）で認証を完了した直後に始まります。

1. サーバーからのシグナル: ログインに成功すると、サーバーはセッション Cookie を設定しますが（通常通り）、DBSC サポートを示す特定のヘッダーを追加します。

   HTTP
   HTTP/1.1 200 OK
   Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict
   Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register"
   

   • Secure-Session-Registration ヘッダーは、ブラウザに「私はアルゴリズム ES256 および RS256 をサポートしています。エンドポイント /auth/dbsc/register でバインドされたセッションを登録してください」と伝えます。

2. キーの生成: ブラウザはこのヘッダーを解析します。デバイスに安全に保存される、新しい非対称キーペア（楕円曲線 P-256 など）を生成します。

   • 実装に関する注意: Chrome は、利用可能な場合は Windows 上で TPM を使用します。仕様は保存メカニズムについて不可知論的であり、「記載されている脅威に対して堅牢」であることだけを求めています。
   • プライバシースコープ: キーのスコープは Web オリジン（例: bank.com）に設定されています。ブラウザは、このキーが retailer.com に使用されないようにし、クロスサイトトラッキングを防ぎます。

3. 登録リクエスト: ブラウザは、指定された登録パスにリクエストを送信します。このリクエストには、秘密鍵によって署名された JSON Web Token（JWT）内の、新しく生成された公開鍵が含まれます（自己署名によるアテステーション）。

   HTTP
   POST /auth/dbsc/register HTTP/1.1
   Content-Type: application/jwt
   
   \<JWT ヘッダー\>.\<公開鍵を含む JWT ペイロード\>.\<署名\>
   

4. セッションのバインディング: サーバーは署名を検証し、公開鍵が機能することを確認します。次に、データベースを更新して、ユーザーのセッション（session_id=xyz123）をこの特定の公開鍵に関連付けます。この瞬間から、セッションは「バインド」されます。

セキュリティとパフォーマンス（安全なキー操作によりレイテンシが追加される可能性がある）のバランスを取るため、DBSC はデュアルトークンシステムを使用します。

1. 発行: サーバーは、有効期間の短い新しい Cookie（例: 5分間有効）を発行します。これを access_token と呼びましょう。
2. 使用: ブラウザは、すべての通常のリクエスト（画像の取得、API 呼び出し、ページの移動）にこの access_token を使用します。Cookie が有効である限り、暗号化操作は実行されません。これにより、ブラウジングは高速に保たれます。
3. 有効期限: 5分後、access_token は期限切れになります。

これがセキュリティメカニズムの核心です。有効期間の短い Cookie が期限切れになると、別のデバイスにいる攻撃者はロックアウトされますが、正当なユーザー（バインドされたキーへのアクセス権を持つ）は続行できます。

1. 検出: ブラウザがリクエストを試行します。Cookie の期限が切れていることに気付きます（またはサーバーが 401 や特定の Secure-Session-Challenge ヘッダーを返します）。
2. インターセプト: ブラウザはネットワークリクエストを一時停止します。ユーザーにはエラーを表示しません。
3. リフレッシュリクエスト: ブラウザは、セッション設定で定義されたリフレッシュエンドポイントを自動的に呼び出します。
   • サーバーは暗号化チャレンジ（ノンス）を送信します。
   • ブラウザはバインドされたキーを使用して、このチャレンジに署名します。
   • 署名は秘密鍵の所持を証明します。
4. 送信: ブラウザは署名されたチャレンジをサーバーに送り返します。

   HTTP
   POST /auth/dbsc/refresh HTTP/1.1
   Sec-Secure-Session-Id: \<Session ID\>
   Secure-Session-Response: \<JWT Signature of Challenge\>
   

5. 検証: サーバーは保存された公開鍵を使用して署名を検証します。
   • 有効な場合: サーバーは、リクエストがセッションを開始したのと同じ物理デバイスから来ていることを認識します。新しい短命の access_token（さらに5分間有効）を発行します。
   • 無効な場合: リクエストは拒否されます。セッションは終了します。
6. 再開: ブラウザは新しい Cookie を取得し、一時停止されていた元のリクエストを透過的に再試行します。ユーザーは中断を経験しません。

graph LR
    subgraph "被害者のデバイス"
        A[DBSC保護された<br/>ユーザーセッション]
        B[HSM/TPM<br/>秘密鍵]
        C[Cookie +<br/>セッションID]
        A --> B
        A --> C
        B -.->|エクスポート不可| X[秘密鍵は抽出<br/>できない]
    end

    subgraph "攻撃シナリオ"
        D[RedLineスティーラーが<br/>デバイスに感染]
        D --> E[Cookieとセッション<br/>IDを盗む]
        E --> F[攻撃者へ<br/>エクスポート]
    end

    subgraph "攻撃者のデバイス"
        G[盗んだCookie<br/>をインポート]
        H[セッションの<br/>使用を試みる]
        I[サーバーがDBSCリフ<br/>レッシュを要求]
        J[チャレンジに<br/>署名できない]
        K[セッション拒否]

        G --> H
        H --> I
        I --> J
        J --> K
    end

    C -.->|盗難| E
    F --> G

    style D fill:#ff6b6b,color:#fff
    style K fill:#51cf66,color:#fff
    style B fill:#4c6ef5,color:#fff
    style X fill:#51cf66,color:#fff
    style J fill:#ff6b6b,color:#fff

RedLine Stealer でユーザーの PC に感染した攻撃者を考えてみましょう。彼らは access_token と session_id を盗み出します。彼らはこれらを自分たちのブラウザにインポートします。

• シナリオ A（5分以内）: 短命なトークンの期限が切れるまで、攻撃者は数分間アクセスできるかもしれません。
• シナリオ B（有効期限切れ後）: 攻撃者のブラウザ（別のデバイスにある）がトークンを使用しようとします。サーバーはそれを拒否し、リフレッシュを要求します。攻撃者のブラウザは DBSC ヘッダーを見ますが、バインドされた秘密鍵を持っていないためリフレッシュを実行できません。攻撃は失敗します。

プライバシーは、DBSC の中心的な設計目標です。W3C 仕様では、ユーザーをサイト間でトラッキングできるグローバル識別子の使用を明示的に禁止しています。

• オリジンごとのキー: ブラウザはサイトごとに一意のキーペアを生成します。google.com はキー A を認識し、amazon.com はキー B を認識します。それらの間に相関関係はありません。
• ユーザーのクリア: ユーザーが Cookie/サイトデータをクリアすると、ブラウザは関連する DBSC キーも削除します。これにより、DBSC が削除されたアイデンティティを復活させる「スーパークッキー」として使用されることを防ぎます。

DBSC を実装するには、サーバーが公開鍵に関する状態を維持する必要があります。

• データベーススキーマ: user_id と session_expiry と一緒に public_key と last_challenge を保存するように、セッションテーブルを更新する必要があります。
• パフォーマンス: リフレッシュ操作には暗号化検証（ECDSA 署名の検証など）が含まれます。高速ですが、単純な文字列のチェックよりも CPU を消費します。ただし、リフレッシュは数分ごとにのみ発生するため（すべてのリクエストで発生するわけではありません）、オーバーヘッドは無視できます。

技術仕様を超えて、DBSC はビジネス戦略、製品ロードマップ、およびコンプライアンスの姿勢に重大な影響を与えます。

セキュリティイニシアチブは、多くの場合、コストセンターまたは摩擦の発生源と見なされます。DBSC はこの物語を覆します。次の図は、デバイスバインディングがビジネス上のメリットをどのように連鎖させるかを示しています。

• 不正の削減: アカウント乗っ取り（ATO）の主要なベクトルを無効化することで、企業は不正による損失を数百万ドル節約できます。
• サポートコスト: アカウントの回復にはコストがかかります。最初の段階でハッキングを防ぐことで、この運用上の負担を直接軽減できます。
• コンバージョンの最適化: eコマースでは、ログインプロンプトはすべてドロップオフのポイントになる可能性があります。DBSC は、アグレッシブな「ログインしたままにする」ポリシーを可能にし、パスワードプロンプトなしで即時チェックアウトを可能にします。

ヨーロッパの GDPR（一般データ保護規則）などの規制の枠組みでは、組織はセキュリティを確保するために「適切な技術的および組織的対策」を実施する必要があります。

• 防御可能なセキュリティ: DBSC が標準になるにつれて、セッション管理の「最新技術（State of the Art）」として解釈されるようになるでしょう。侵害が発生した場合、DBSC が実装されたことを証明することは、過失の主張に対する強力な防御になり得ます。
• 銀行の基準（PSD2）: 決済サービス指令2では、「強力な顧客認証（SCA）」が求められています。SCA はログインに焦点を当てていますが、デバイスへのセッションの動的なリンクは、認証を特定の金額や受取人にバインドするという指令の目的と完全に一致しています。

FIDO アライアンスのホワイトペーパーでは、「保証レベル」の概念が強調されています。

• 中保証: 同期されたパスキー（iCloud キーチェーンにあるようなもの）を使用します。コンシューマアプリに最適で、復元可能で使いやすいです。
• 高保証: デバイスバウンドのキーが必要です。これは DBSC が輝くところです。エンタープライズリソース（人事ポータル、コードリポジトリ）や価値の高い銀行業務の場合、組織は特定の管理されたデバイスにバインドされたセッションからのアクセスのみを許可するポリシーを実施する場合があります。DBSC は、このポリシーに対する技術的な実施メカニズムを提供します。

DBSC を十分に理解するには、同様の問題を解決しようと試みた他のテクノロジーと比較する必要があります。

graph RL
    subgraph "従来のCookie"
        TC1[ベアラートークンのみ]
        TC2[盗難に脆弱]
        TC3[長いセッション＝リスク]
        TC1 --> TC2
        TC2 --> TC3
    end

    subgraph "トークンバインディング"
        TB1[TLSレイヤーのバインディング]
        TB2[❌ 失敗: 複雑なインフラ]
        TB3[ロードバランサーで破損]
        TB1 --> TB2
        TB2 --> TB3
    end

    subgraph "DPoP"
        DP1[OAuthトークンバインディング]
        DP2[✅ API保護]
        DP3[ブラウザセッション向けではない]
        DP1 --> DP2
        DP2 --> DP3
    end

    subgraph "DBSC"
        D1[HTTPレイヤーのバインディング]
        D2[✅ ハードウェアキーによる保護]
        D3[✅ CDN/LBで機能する]
        D4[✅ ブラウザセッション]
        D1 --> D2
        D2 --> D3
        D3 --> D4
    end

    style TC2 fill:#ff6b6b,color:#fff
    style TB2 fill:#ff6b6b,color:#fff
    style D2 fill:#51cf66,color:#fff
    style D3 fill:#51cf66,color:#fff
    style D4 fill:#51cf66,color:#fff
    style DP2 fill:#51cf66,color:#fff

前述のとおり、トークンバインディングはセッションを TLS レイヤーにバインドしようとしました。

• トークンバインディング: クライアント、サーバー、およびその間のすべてのホップ（ロードバランサー、TLS ターミネーター）からのサポートが必要でした。接続が終了して再暗号化されると、壊れてしまいました。
• DBSC: HTTP アプリケーションレイヤーで動作します。標準のヘッダー/Cookie としてロードバランサーを透過的に通過します。TLS が多くの場合クラウドプロバイダーのエッジネットワークによって処理される、最新のクラウドアーキテクチャ（AWS/GCP/Azure）への展開がはるかに簡単です。

DPoP（RFC 9449）は、「送信者制約」の OAuth トークン標準です。これは、アクセストークンとリフレッシュトークンの両方を公開鍵にバインドします。リフレッシュトークン自体が長寿命のベアラークレデンシャルであるため、これは重要です。各 API リクエストには DPoP 証明（HTTP メソッド、URL、タイムスタンプ、および一意識別子を含む署名付き JWT）が含まれます。FAPI 2.0 のような高保証の仕様では、送信者制約トークンが義務付けられています。mTLS が利用できない場合は、DPoP が推奨される方法です。

主な違い: DPoP キーはアプリケーションコンテキストに存在します。ベストプラクティスは、抽出不可能なストレージに OS API を使用することですが、これは強制されていません。多くの実装では、キーを JavaScript からアクセス可能なメモリに保持しています。攻撃者が任意のコード（XSS、マルウェア）を実行できる場合、DPoP キーにアクセスしたり、オンデマンドで証明を生成したりする可能性があります。DPoP は、異なるクライアント間でのトークンのリプレイを停止しますが、侵害されたブラウザコンテキストを保護することはできません。

DBSC は、所持の証明をブラウザとハードウェアに移動させます。秘密鍵は、JavaScript が読み取ったりエクスポートしたりできない TPM または Secure Enclave に存在します。ブラウザはプロトコルを処理し、アプリケーションコードにキーを公開することなく署名を生成します。Web アプリが完全に侵害されたとしても、攻撃者は別のマシン上で、盗まれた Cookie に対する新しい証明を鋳造することはできません。

相乗効果: FIDO アライアンスが指摘しているように、パスキーはログイン時のフィッシングを排除し、DBSC/DPoP は認証後のトークンを保護します。最新のアーキテクチャでは、両方を組み合わせています。OAuth API（特に規制対象のオープンバンキング）には DPoP を、ブラウザセッションには DBSC を使用します。これらを組み合わせることで、セッションのライフサイクル全体にわたって「リフトアンドシフト」攻撃ベクトルを閉じます。

単に Cookie の有効期間を（たとえば 15 分に）短くするだけでもセキュリティは向上しますが、UX は損なわれます。ユーザーは常にログインを強いられます。DBSC は、30 日間の Cookie と同じユーザーエクスペリエンスで、5 分間の Cookie と事実上同じセキュリティを可能にします。

%%{init: {
  "theme": "default",
  "themeVariables": {
    "actorBkg": "#ffffff",
    "actorBorder": "#000000",
    "noteBkgColor": "#f1f3f5",
    "noteTextColor": "#000000",
    "activationBkgColor": "#e0e0e0",
    "actorColours": {
      "ST": "#ff6b6b",
      "IdP": "#4c6ef5"
    }
  }
}}%%

sequenceDiagram
    participant ST as セキュリティツール<br/>(CrowdStrike, Defender)
    participant IdP as アイデンティティプロバイダ<br/>(Okta, Google, Azure)
    participant SP1 as サービスプロバイダ 1<br/>(Slack)
    participant SP2 as サービスプロバイダ 2<br/>(Salesforce)
    participant SP3 as サービスプロバイダ 3<br/>(銀行アプリ)
    participant Session as ユーザーセッション<br/>(DBSC保護)

    Note over ST,Session: 脅威検出フェーズ
    ST->>ST: ユーザーデバイスで<br/>マルウェアを検出
    ST->>IdP: RISCシグナル:<br/>「デバイスが侵害されました」

    Note over IdP,SP3: シグナル伝播フェーズ
    IdP->>SP1: CAEPイベント:<br/>「デバイスが侵害されました」
    IdP->>SP2: CAEPイベント:<br/>「デバイスが侵害されました」
    IdP->>SP3: CAEPイベント:<br/>「デバイスが侵害されました」

    Note over SP1,Session: 強制フェーズ (DBSCあり)
    Session->>SP1: 次のリフレッシュ試行<br/>(数分以内)
    SP1-->>Session: x 署名を拒否
    Session->>SP2: 次のリフレッシュ試行
    SP2-->>Session: x 署名を拒否
    Session->>SP3: 次のリフレッシュ試行
    SP3-->>Session: x 署名を拒否

    Note over Session: セッションは次のリフレッシュ試行時に終了可能

DBSC の可能性は、Shared Signals Framework（SSF）、特に Continuous Access Evaluation Profile（CAEP） と Risk Management（RISC） を組み合わせることで増幅されます。注: SSF/CAEP は新しいエコシステム機能であり、アーキテクチャパターンは定義されていますが、広範なクロスベンダーの展開はまだ成熟しつつある段階です。

古いモデルでは、ユーザーのデバイスが侵害された場合、アイデンティティプロバイダ（IdP）はサービスプロバイダ（SP）にセッションを今すぐ強制終了するように指示する方法がありませんでした。SP は Cookie の有効期限が切れるのを待たなければなりませんでした。

想定される DBSC + CAEP のフロー:

1. トリガー: エンドポイントセキュリティツール（CrowdStrike や Microsoft Defender など）が、ユーザーのラップトップでマルウェアを検出します。
2. シグナル: セキュリティツールは、アイデンティティプロバイダ（Okta/Google など）に RISC シグナルを送信します。
3. 伝播: IdP は、接続されているアプリに「デバイスが侵害されました」という CAEP イベントをプッシュします。
4. 強制（DBSC）: ブラウザが次回 DBSC の短命 Cookie をリフレッシュしようとすると、サーバーは署名を拒否し、セッションを強制終了します。このアーキテクチャパターンにより、より迅速な取り消しが可能になります。実際のレイテンシは、サイトのリフレッシュ期間と、DBSC と SSF の両方を実装しているかどうかによって異なります。

DBSC の採用はブラウザベンダーにかかっています。2026年の状況は大きく変化しました。Chrome はオリジントライアルから Windows で一般公開（GA）に DBSC を移行させ、次に macOS も予定されています。他のブラウザはまだ評価中です。

Google は DBSC の主な推進力であり、これを広く出荷した最初のブラウザです。

• ステータス（2026年4月）: Chrome 146 では Windows で DBSC が GA として提供され、オリジントライアルフェーズが終了しました。Secure Enclave を使用する macOS サポートは、今後の Chrome リリースで発表されています。
• ハードウェア: Windows は TPM を使用し、macOS は Secure Enclave を使用します。Google は、専用のセキュアなハードウェアを持たないデバイスに DBSC の保護を拡張するために、ソフトウェアベースのキーも検討していると述べています。
• ロードマップ: Google の GA 発表では、次のステップのロードマップも公開されました。
  • フェデレーションアイデンティティの保護: リライングパーティ（RP）セッションがアイデンティティプロバイダ（IdP）セッションと同じデバイスキーにバインドされたままになるクロスオリジン DBSC バインディングにより、SSO 全体で途切れない信頼チェーンを維持します。
  • 高度な登録: サインイン時に新しいキーを生成するのではなく、mTLS 証明書やハードウェアセキュリティキーなどの既存の信頼できるキーマテリアルに DBSC セッションをバインドします。
  • 幅広いデバイスのサポート: TPM / Secure Enclave のないデバイス向けのソフトウェアベースのキー。
• 運用の結果: 展開中、Google は DBSC によって保護されたセッションで「セッションの盗難が大幅に減少した」と報告しています。
• Google アカウント: これとは別に、Google はエンタープライズポリシーを介して制御される、Windows 上の Chrome 向け Google アカウント Cookie に対して DBSC スタイルの保護をすでに展開していました。これは Gmail/Workspace を保護し、現在は一般 Web 向けに GA となっているのと同じテクノロジーファミリーです。

Microsoft は積極的に参加しています。

• ステータス: Edge は Windows で DBSC オリジントライアルを実行していましたが、2025年10月に終了しました。代替のトライアルや GA は発表されていません。
• エンタープライズコンテキスト: Edge は、Entra/Azure AD SSO に概念的に DBSC に似ている「Primary Refresh Token」（PRT）アーキテクチャを利用しています。PRT は Microsoft 固有のメカニズムにとどまっており、サードパーティのサイト向けに DBSC Web 標準と統一する計画は発表されていません。

モバイルのカバー範囲には Apple のスタンスが重要です。

• ステータス: WebKit には、使いやすさやプライバシーに関する懸念を指摘しつつ DBSC を評価する標準ポジションの問題があります。Safari のリリースノートでは DBSC について言及されていません。「積極的に実装中」という公の声明は存在しません。
• プライバシーファースト: Apple の主な懸念は、DBSC が「スーパークッキー」（削除不可能なトラッキング）に使用される可能性があることです。W3C 仕様では、Web サイトのデータとともにキーを確実にクリアすることでこれに対処しています。
• エンゲージメント: WebKit は標準化プロセスに関与していますが、実装の状況は不明です（「開発中」ではなく「議論中」）。

Mozilla には、複雑さとプライバシーに関する懸念を指摘しつつ DBSC を評価する標準ポジションの問題があります。標準が安定した後に実装するという公の確約はありません。

DBSC とパスキーに対する現在のエコシステムサポートを考慮し、組織はこれらの補完的なテクノロジーの実装に向けて段階的なアプローチを取る必要があります。以下のロードマップは、当面の行動と戦略的な計画のマイルストーンの概要を示しています。

1. まずパスキーを展開する: 認証レイヤーを保護するために、パスキーの実装から始めます。これにより、クレデンシャルフィッシングに対する即時の保護が提供され、DBSC の真の価値を引き出すための前提条件となります。

2. DBSC 登録およびリフレッシュエンドポイントのリリース: Chrome 146 GA に伴い、現実的な作業はバックエンドの統合になりました。ログインのレスポンスに Secure-Session-Registration ヘッダーを追加し、/dbsc/register と署名付きチャレンジを検証するリフレッシュエンドポイントを実装します。フロントエンドコードを変更する必要はありません。

3. リフレッシュトークンを使用した短命セッションの実装: DBSC の準備がまだ整っていない場合は、リフレッシュメカニズムを備えた短命トークンのアーキテクチャパターンを採用します。これにより、今日のセキュリティを向上させながら、バックエンドを DBSC に備えることができます。

1. ハイブリッドアプローチの採用: 機能検出を使用して、対応ブラウザ（現在は Windows の Chrome 146 以降、次は macOS Secure Enclave）に DBSC を提供する一方で、フォールバックオプションを維持します。これにより、Safari、Firefox、または Edge のユーザーを排除することなく、セキュリティを最大化できます。

2. 次のロードマップ項目に備える: Google は、フェデレーションアイデンティティ（クロスオリジン SSO バインディング）、高度な登録（mTLS / ハードウェアキー）、およびより幅広いデバイスをカバーするためのソフトウェアベースのキーを明確に求めています。SSO または IdP レイヤーを運用している場合は、今すぐクロスオリジンバインディングのスコープ定義を開始してください。

3. アイデンティティプロバイダとの統合: Okta、Auth0、または同様の IdP を使用している場合は、彼らと協力して SDK での DBSC サポートを有効にしてください。多くの企業がオリジントライアルに参加しており、Chrome が GA になった現在、DBSC 機能を積極的にリリースしています。

• 価値の高いターゲットから始める: 管理者パネル、金融取引、機密データへのアクセスに DBSC を優先します。
• マネージドソリューションを使用する: DBSC 実装の複雑さやブラウザの互換性を処理する Corbado のようなプラットフォームを検討してください。
• 測定して反復する: セッションハイジャックの試行、サポートチケット、ユーザーの摩擦などの指標を追跡して、ROI を実証します。
• コンプライアンスの準備: 機密データを処理するためのコンプライアンス要件になる可能性が高いため、DBSC の実装を文書化します。

DBSC をゼロから実装することは、エンジニアリングの大きな負担です。暗号化に関する専門知識、ブラウザの不整合に関する深い知識、キーとチャレンジを管理するための堅牢なサーバー側インフラストラクチャが必要です。ここで、Corbado がイネーブラーとして機能します。

低保証のログインの上に高保証のセッションを構築することはできません。ユーザーが弱いパスワードでログインした場合、セッションはそのパスワードと同じくらいしか安全ではありません。Corbado のコア製品（マネージドパスキー）は必要な基盤を提供します。Corbado を統合することで、組織はパスキーを簡単に展開し、セッションの開始がフィッシング耐性を持つことを保証できます。

Corbado は DBSC を活用して、信頼できるデバイスの検出を強化します。DBSC シグナルが利用可能な場合、それらはセッションが特定のデバイスから発生しているという暗号証明を提供し、それに応じて Corbado が認証の信頼レベルを高めることを可能にします。

• 同期されたパスキーの曖昧さの解決: 同期されたパスキーは便利ですが、信頼のギャップを生み出します。ユーザーが同期されたパスキーで認証した場合、それがいつものラップトップなのか、クレデンシャルを同期したばかりの新しいデバイスなのかを見分けることができません。DBSC はこのギャップを埋めます。デバイスに確立された DBSC バインディングがあるかどうかをチェックすることで、Corbado は、デバイスが初めての同期ではなく、本当に既知であり信頼されていることを確認できます。
• 既知のデバイスに対する高い信頼: DBSC シグナルが以前にそのデバイスが確認されていることを確定した場合、Corbado はより確実なリスク決定を下すことができます。つまり、正当な再訪ユーザーに対するステップアップ認証のプロンプトを減らし、認識されないデバイスからのセッションに対する精査を厳格にします。
• Passkey Intelligence の補完: DBSC シグナルは、Corbado の既存のPasskey Intelligence エンジンと統合されています。パスキーベースの認証と DBSC ベースのデバイスバインディングを組み合わせることで、ログインからセッションライフサイクル全体にわたる完全な信頼チェーンが作成されます。

Corbado が DBSC を自社プラットフォームにどのように統合する計画であるかについての質問は、チームにお問い合わせください。

今後数年間は、Web はハイブリッドになるでしょう。一部のユーザーは DBSC 対応ブラウザ（Windows 11 の Chrome）を使用し、他のユーザーは古いシステムを使用します。この断片化に対処するのは困難です。Corbado の Passkey Intelligence エンジンは、まさにこの種のフォールバックロジックを処理するように設計されており、対応するデバイスにはパスキーを提供し、その他のデバイスにはフォールバックを提供します。この同じインテリジェンスがセッションバインディングにも適用され、デバイスの機能に応じてすべてのユーザーのセキュリティが最大化されることを保証します。

「ベアラートークン」の時代は終わりに近づいています。現在のセッション管理は壊滅的に失敗しています。ベアラートークンは産業規模のマルウェア運用によって盗まれ、あらゆるデバイスから使用される可能性があり、最も強力な認証方法でさえもバイパスするアカウントの乗っ取りを可能にしています。この根本的な脆弱性により、数十億ドル規模の地下経済が生まれました。

Device Bound Session Credentials (DBSC) は、業界の新たな答えを表しています。HttpOnly フラグと静的シークレットを備えた従来のセキュアな Cookie とは異なり、DBSC はデバイスバウンドキーによる暗号化された所持証明を追加します。これにより、盗まれた Cookie の価値ははるかに低くなります。別のデバイスからリフレッシュすることはできません。トークンバインディングがすべてのインフラストラクチャで複雑な TLS レイヤーの変更を要求して失敗したのに対し、DBSC は HTTP アプリケーションレイヤーで動作し、既存のロードバランサーや CDN アーキテクチャと互換性があることで成功しています。注: DBSC には、ブラウザがバインディングをスキップするドキュメント化されたフォールバックパス（TPM が利用できない、ネットワークエラーなど）があるため、Cookie の盗難リスクを大幅に減らしますが、排除するものではありません。

DBSC とパスキーの相乗効果により、カスタマージャーニー全体で攻撃者に対するハードルが大幅に高まります。パスキーはログイン時のクレデンシャルフィッシングを排除し、DBSC はリモートでの Cookie 盗難によるセッションハイジャックをはるかに困難にします。これらが一体となって、FIDO アライアンスが構想する「高保証」アイデンティティフレームワークを形成しています。Chrome 146 が 2026 年 4 月に Windows で DBSC を GA として出荷し、次に macOS の Secure Enclave サポートが提供されることで、標準は準備フェーズからロールアウトフェーズに移行しました。Google の公開ロードマップ（フェデレーションアイデンティティ、mTLS / ハードウェアキー登録、ソフトウェアベースのキー）は、今後 12 か月の拡大を示唆しています。

プロダクトマネージャーにとって、ビジネスケースは説得力があります。DBSC は、不正行為による損失とサポートコストを同時に削減しながら、ログインの摩擦を劇的に減らす「無期限の」セキュアなセッションを可能にします。ROI は、コンバージョン率の向上、パスワードリセットのチケットの減少、アカウント乗っ取りのインシデントの排除という形で現れます。OAuth を使用する組織は、DPoP を通じて API トークンに同じキーバインディングの概念を活用できます。また、Shared Signals（CAEP/RISC）との統合により、リアルタイムの脅威への対応が可能になり、次のリフレッシュの試行時に侵害されたセッションを即座に取り消すことができます。

実装をゼロから構築する必要はありません。Corbado のようなプラットフォームは、パスキーのインフラストラクチャを提供しており、ブラウザのサポートが成熟するにつれてデバイスバインディングを統合するために DBSC の開発を追跡しています。W3C 仕様はアクティブなワーキングドラフトであり、Chrome 146 は Windows で GA となり macOS にも展開されていますが、他のブラウザはまだこの標準を評価中です。

軌道は明確です。今日からパスキーと DBSC の採用を開始する組織は、パスワードのない、フィッシングに強い未来に向けて最適な位置につくでしょう。デバイスバウンドセッションを実装するかどうかではなく、ユーザーとビジネスを保護するためにどれだけ早く展開できるかが問題です。Web セキュリティの未来は、単に認証されるだけでなく、私たちが信頼するデバイスに暗号的にバインドされます。

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのPasskey Intelligence Platformです。IDPのログや一般的なanalyticsツールでは見えないものを可視化します。どのデバイス、OSバージョン、ブラウザ、credential managerがpasskeyに対応しているか、なぜ登録がログインにつながらないのか、WebAuthnフローのどこで失敗するか、OSやブラウザのアップデートがいつ静かにログインを壊すか — Okta、Auth0、Ping、Cognito、あるいは自社IDPを置き換えることなく、すべてを把握できます。2つのプロダクト：Corbado Observeは passkeyとその他あらゆるログイン方式のobservabilityを提供します。Corbado Connectは analytics内蔵のmanaged passkeyを追加します（既存のIDPと併用）。VicRoadsはCorbadoで500万人超のユーザーにpasskeyを提供しています（passkey有効化率+80%）。 Passkeyエキスパートに相談する →

CrowdStrike などのエンドポイントセキュリティツールがマルウェアを検出すると、RISC シグナルをアイデンティティプロバイダに送信し、アイデンティティプロバイダは接続されているアプリに「デバイスが侵害されました」という CAEP イベントをプッシュします。次の DBSC リフレッシュ試行時（数分以内）に、それらのアプリはセッション署名を拒否し、アクセスを終了します。クロスベンダーの CAEP/RISC の展開はまだ成熟しつつある段階です。

DPoP（RFC 9449）は、OAuth のアクセストークンとリフレッシュトークンをアプリケーションレイヤーの公開鍵にバインドし、主にネイティブアプリと SPA での API 呼び出しを保護します。DBSC は、ブラウザのセッション Cookie を、JavaScript が読み取ったりエクスポートしたりできないハードウェアでバックアップされた TPM キーにバインドし、Web アプリ自体が XSS やマルウェアによって侵害された場合でも、ユーザー向けセッションを保護します。

従来のセキュアな設計では、Cookie が盗まれてリモートでリプレイされた場合の被害を抑えるために、短いセッションタイムアウトが義務付けられています。DBSC は、リフレッシュ機能を元のデバイスの秘密鍵にバインドするため、別のデバイスから使用された盗まれた Cookie は暗号化チャレンジに失敗します。リモートでのリプレイ攻撃が中和されるため、セッションは事実上無期限にすることができます。

DBSC は、アカウントの乗っ取りの主なベクトルとしての Cookie の盗難を中和し、不正行為による損失とアカウント回復のサポートコストを直接削減します。安全で長いセッションにより、繰り返しのログインプロンプトが不要になり、eコマースでのコンバージョン率が向上し、ドロップオフが減少します。FIDO アライアンスは、DBSC を、ユーザーの摩擦を減らすと同時にセキュリティの基準を引き上げるものとして位置付けています。