--- url: 'https://www.corbado.com/ja/blog/device-bound-session-credentials-dbsc' title: 'Device Bound Session Credentials (DBSC) の解説' description: 'Device Bound Session Credentials (DBSC) がセッションハイジャックやCookieの盗難をどのように防ぐかを解説します。ブラウザのサポート状況やエンタープライズセキュリティについて学びます。' lang: 'ja' author: 'Vincent Delitz' date: '2026-06-15T13:56:28.885Z' lastModified: '2026-06-16T06:02:45.214Z' keywords: 'Device Bound Session Credentials, DBSC, セッションハイジャック防止, Cookie盗難対策, TPMセッションバインディング' category: 'Authentication' --- # Device Bound Session Credentials (DBSC) の解説 **ブラウザのサポート状況** > **最新情報（2026年4月）:** [Chrome](https://www.corbado.com/ja/blog/digital-credentials-api) 146 では > [Windows で DBSC が一般公開（GA）され](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)、この機能はオリジントライアルから移行しました。[macOS](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos) > のサポート（[Secure Enclave](https://www.corbado.com/glossary/secure-enclave) を使用）は今後の > [Chrome](https://www.corbado.com/ja/blog/digital-credentials-api) > のリリースで提供される予定です。Google はまた、フェデレーションアイデンティティ（クロスオリジン > [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) バインディング）、高度な登録（mTLS > / ハードウェアキー）、およびセキュアなハードウェアを持たないデバイス向けのソフトウェアベースのキーのパブリックロードマップも発表しました。 | ブラウザ | Windows | macOS | Linux | Android | iOS | ステータス | | ----------- | ------------------------ | ------------------------- | ----------------- | ----------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Chrome** | ✅ GA（Chrome 146、TPM） | 🚧 予定（Secure Enclave） | ❌ | ❌ | ❌ | [Windows で GA](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)（2026年4月）、macOS は今後のリリースで対応予定 | | **Edge** | ⏸️ トライアル終了 | ❌ | ❌ | ❌ | ❌ | オリジントライアルは2025年10月に終了、GA の発表はなし | | **Safari** | 該当なし | 🔄 評価中 | 該当なし | 該当なし | 🔄 評価中 | WebKit で議論中、実装の発表はなし | | **Firefox** | 🔄 モニタリング中 | 🔄 モニタリング中 | 🔄 モニタリング中 | 🔄 モニタリング中 | 🔄 モニタリング中 | 評価中、実装の確約はなし | **凡例:** ✅ 一般公開（GA） | 🚧 発表済み / 開発中 | ⏸️ トライアル終了 | 🔄 評価中/モニタリング中 | ❌ 未提供 **注:** [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) は、[Chrome](https://www.corbado.com/ja/blog/digital-credentials-api) 146（2026年4月）の時点で、TPM を備えた Windows で GA になっています。次に、[Secure Enclave](https://www.corbado.com/glossary/secure-enclave) を介した [macOS](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos) サポートが展開されます。Google の発表したロードマップには、専用のセキュアなハードウェアを持たないデバイスに保護を拡張するためのソフトウェアベースのキーも含まれています。 **主な利点: DBSC と現在のモデルの比較** | **機能** | **現在の Cookie モデル** | **DBSC モデル** | | ------------------ | ---------------------------- | ------------------------------------------ | | **トークンの種類** | ベアラー（所有 ＝ アクセス） | バウンド（所有 ＋ キー ＝ アクセス） | | **盗難の結果** | アカウントの完全な乗っ取り | トークンの無効化（リフレッシュ不可） | | **セッション期間** | 短い（セキュリティ上の理由） | 長い / 無期限（セキュアバイデザイン） | | **ユーザーの摩擦** | 高い（頻繁なログイン） | 低い（目に見えないセキュリティ） | | **MFA のバイパス** | 脆弱（Pass-the-Cookie） | 耐性あり（デバイスが必要） | | **取り消し** | 遅い（有効期限切れを待つ） | ほぼリアルタイム（次のリフレッシュで失敗） | ## Key Facts - **DBSC** は、Web セッションをデバイスが保持する暗号化キーにバインドし、別のデバイスからリフレッシュできないようにすることで、盗まれた Cookie を無用なものにします。 - ブラウザは、エクスポート不可能な秘密鍵を **TPM** に保存し、ユーザーの操作なしにデバイスの所有を証明するために、5分ごとにサーバーのチャレンジに署名します。 - TLS レイヤーのインフラストラクチャの複雑さのために失敗した**トークンバインディング**とは異なり、DBSC は HTTP アプリケーションレイヤーで動作し、既存のロードバランサーや CDN と透過的に機能します。 - **Chrome 146 は、Windows 上で DBSC を GA として出荷しており（2026年4月）**、macOS の Secure Enclave サポートは今後のリリースで提供される予定です。Google の公開ロードマップでは、フェデレーションアイデンティティ（クロスオリジン SSO バインディング）、高度な登録（mTLS / ハードウェアキー）、およびセキュアなハードウェアを持たないデバイス向けのソフトウェアベースのキーもカバーされています。Safari と Firefox はまだ評価中であり、Edge のオリジントライアルは2025年10月に終了し、GA は発表されていません。 ## 1. はじめに: Device Bound Session Credentials (DBSC) World Wide Web のアーキテクチャは、ステートレスの原則に基づいて設立されました。HTTP が最初に設計されたとき、リクエスト間でユーザーに関する情報は保持されませんでした。これを解決するために、Web サイトから送信されてユーザーのコンピュータに保存され、その後のすべてのリクエストとともに Web サイトに送り返される小さなデータである「Cookie」が発明されました。何十年もの間、このメカニズムはセッション管理の基盤として機能してきました。ユーザーがログインすると、サーバーはクレデンシャルを検証し、Cookie を発行します。この Cookie は「ベアラートークン」として機能します。現実世界では、無記名証券（ベアラー）は、保有者にそれが表す権利や資産を与える文書です。債券を持っていれば、その債券を所有していることになります。同様に、HTTP のデジタル世界では、Cookie を保持していれば、あなたがユーザーです。 このベアラー機能は、Web 最大のユーティリティであると同時に、最も深刻な脆弱性でもあります。セッション全体のセキュリティ、ひいてはユーザーのアイデンティティ、データ、および金融資産は、その Cookie 文字列の機密性に完全に依存しています。悪意のあるアクターがその文字列をコピーできれば、世界中のどこからでも、どのデバイスからでもユーザーになりすますことができ、最初の認証チェックを完全にバイパスできます。この特定の脆弱性により、「Cookie の盗難」や「セッションハイジャック」の産業規模の地下経済が生まれました。 [FIDO](https://www.corbado.com/ja/blog/emv-3ds-acs-passkeys-fido-spc-katsuyou)（Fast Identity Online）標準とパスキーの採用を通じて、業界が認証の「正面玄関」を首尾よく強化するにつれて、攻撃者は焦点を「裏口」、つまりアクティブなセッションに移しています。パスワードのフィッシングは難しくなっていますが、セッション Cookie の盗難は依然として危険なほど効果的です。このエスカレートする脅威に対する業界の対応が、**Device Bound Session Credentials (DBSC)** です。 [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) は、Web セッションの維持方法におけるパラダイムシフトを表しています。単なるベアラートークンから脱却し、セッションが[デバイスに暗号化されてバインドされる](https://www.w3.org/TR/dbsc/)モデルへの移行を提案しています。[Chrome 146（2026年4月）が Windows 上で DBSC を GA として出荷した](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)ことで、この標準は実験的なものから、Web チームが今日展開できる本番機能へと移行しました。Chrome は Windows で TPM を使用しており、次に [macOS](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos) の [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) のサポートを展開する予定です。仕様自体はキーの保存について不可知論的であり、「記載されている脅威に対して堅牢」であることだけを求めています。これにより、盗まれた Cookie の価値ははるかに低くなります。バインドされたキーがなければ、別のデバイスからリフレッシュすることはできません。 この記事では、セキュリティアーキテクト、プロダクトマネージャー、および開発者向けに設計された [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-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](https://www.corbado.com/glossary/oauth2) の関係は何ですか？ 9. リアルタイムの脅威対応のために、DBSC は Shared Signals（CAEP/RISC）とどのように統合されますか？ ## 2. コアな問題と解決策の理解 この新しい標準の複雑さを乗り越えるには、まず現在のセッション管理の根本的な問題と、DBSC がどのように解決策を提供するかを理解する必要があります。これらの各領域は、DBSC が対処する重大な脆弱性または制限を表しています。 ### 2.1 現在のセッション管理の失敗 現在のセッション管理の根本的な失敗は、信頼の「ポータビリティ」です。サーバーがセッション Cookie を発行するとき、それは本質的に、それを保持している誰にでも機能するパスポートを発行していることになります。ブラウザは [HttpOnly や Secure フラグ](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies)（JavaScript アクセスを防ぎ、HTTPS を介した送信を保証する）などの防御策を実装していますが、これらの防御策は、クロスサイトスクリプティング（XSS）やネットワークスニッフィングなどの特定の抽出ベクトルからのみ保護します。ホストデバイスで実行されているマルウェアからの保護は提供されません。「インフォスティーラー（情報窃取マルウェア）」は、ディスク上のブラウザの Cookie ストレージファイルを特定し、（多くの場合、ユーザー自身の OS レベルのクレデンシャルを使用して）復号化し、コンテンツをコマンドアンドコントロールサーバーに持ち出すように特別に設計されたマルウェアです。攻撃者が Cookie を入手すると、[Pass-the-Cookie 攻撃](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html)を実行し、盗んだトークンを自分のブラウザに注入してセッションをハイジャックすることができます。サーバーは有効な Cookie を見て、リクエストが正当であると想定します。 ### 2.2 従来のセキュアな Cookie に対する DBSC の暗号化の優位性 DBSC は、セッション維持ループ自体に第2要素認証を導入します。静的なシークレットである標準のセキュアな Cookie とは異なり、DBSC セッションは短期間のベアラートークンと暗号化された所持証明で構成されます。ブラウザは、デバイスに安全に保存される公開鍵と秘密鍵のペアを生成します。サーバーはセッションを公開鍵にバインドします。定期的に、ブラウザはサーバーからのチャレンジに署名することで、秘密鍵をまだ保持していることを証明する必要があります。[仕様では](https://www.w3.org/TR/dbsc/)、「記載されている脅威に対して堅牢な」キーの保存が義務付けられています。Chrome は、利用可能な場合は Windows 上で TPM を使用します。攻撃者が別のデバイスから Cookie を盗んだ場合、必要な暗号化署名を生成できないため、Cookie をリフレッシュすることはできません。「ベアラー」の側面は非常に短いウィンドウに最小化され、「バインディング」の側面は長期的な継続性を提供します。 ### 2.3 パスキーと DBSC の相乗効果 パスキーと DBSC は、ユーザーライフサイクルのさまざまな段階を保護する補完的なテクノロジーです。パスキー（[FIDO2](https://www.corbado.com/glossary/fido2)）は、パスワードなしでセッションを開始するためにアイデンティティを証明するという*認証*の問題を解決し、クレデンシャルのフィッシングを排除します。DBSC は、Cookie の盗難によるセッションハイジャックを大幅に困難にすることで、*認証後*の問題に対処します。[FIDO アライアンスは、DBSC を](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)セッションハイジャックに対する「基準を引き上げる」補完的なテクノロジーとして位置付けています。DBSC はデバイスへの継続的なアクセスを伴うマルウェアや同じデバイスでのリアルタイムのブラウザインザミドル攻撃からは保護しませんが、これらを組み合わせることで、ログインおよびセッションのライフサイクル全体で攻撃対象領域が縮小されます。 | テクノロジー | リモートフィッシング | クレデンシャルスタッフィング | トークン盗難 | | -------------------------- | -------------------- | ---------------------------- | ------------ | | **パスキー** | ✅ | ✅ | ❌ | | **DBSC / DPoP** | ❌ | ❌ | ✅ | | **パスキー + DBSC / DPoP** | ✅ | ✅ | ✅ | **パスキーと DBSC がどのように連携するか** | **側面** | **パスキー** | **DBSC** | **組み合わせの利点** | | ---------------------------- | ---------------------------------------------------- | ------------------------------------------- | ------------------------------------------ | | **スコープ** | 認証（ログイン） | セッション管理 | エンドツーエンドの保護 | | **軽減される脅威** | パスワードフィッシング、クレデンシャルスタッフィング | リモートセッションハイジャック、Cookie 盗難 | アカウント乗っ取りのハードルが大幅に上昇 | | **ユーザーエクスペリエンス** | パスワードレスログイン | 透過的なセッション保護 | シームレスでセキュアな体験 | | **キーの保存** | デバイスバウンドまたは同期されたクレデンシャル | デバイスバウンド（利用可能な場合は HSM） | 柔軟な認証、厳格なセッションバインディング | | **展開** | パスワードを置き換える | 既存のセッションを強化する | 段階的なセキュリティの向上 | ### 2.4 トークンバインディングの失敗から学ぶ DBSC は、この問題を解決しようとする最初の試みではありません。「トークンバインディング」は、Cookie を基盤となる TLS（Transport Layer Security）接続にバインドしようとした以前の標準でした。暗号化は健全でしたが、トークンバインディングは TLS レイヤーに大きく依存していたため、広く普及することはありませんでした。最新の Web では、多くの場合、TLS 接続はロードバランサー、CDN、またはリバースプロキシで終端され、アプリケーションロジックはその背後のサーバーに存在します。トークンバインディング情報をこれらの複雑なネットワークレイヤー経由で伝播することは、難しすぎることが判明しました。DBSC は、[アプリケーションレイヤー（HTTP）で完全に動作する](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)ことで、この失敗から学びます。基盤となるネットワーク接続に依存しないため、既存のロードバランサー、プロキシ、およびクラウドインフラストラクチャと互換性があります。 ### 2.5 ビジネスへの影響と ROI の機会 プロダクトリーダーにとって、DBSC はユーザーエクスペリエンス（UX）を向上させると同時に、セキュリティを向上させる機会を提供します。従来、高いセキュリティは短いセッションタイムアウトを意味し、ユーザーに頻繁なログイン（摩擦）を強いていました。セッションをデバイスにバインドすることで、*リモート*での Cookie 盗難のリスクは大幅に減少します。盗まれた Cookie が別のデバイスからリフレッシュできないことを知っているため、企業はセッション期間を長くすることを検討できます。ただし、DBSC はデバイスの盗難、デバイス上の永続的なマルウェア、または悪意のある使用による悪用からは保護しないため、セッションの有効期間のポリシーには、これらの残存リスクを引き続き反映させる必要があります。 ## 3. 脅威の状況: Cookie 盗難の産業化 DBSC の背後にある緊急性を理解するには、現代の脅威の状況の洗練さを理解する必要があります。セッション Cookie の盗難は、ニッチなハッカーのトリックから、スケーラブルで自動化された業界へと卒業しました。 ### 3.1 インフォスティーラーの台頭 ```mermaid graph TD A[ユーザーが悪意のあるソフトウェアを
ダウンロード] -->|実行| B[インフォスティーラーが
デバイスで起動] B --> C[ブラウザデータを特定] C --> D[Chrome/Edge/Firefox
のCookieストレージ] C --> E[パスワードデータベース] C --> F[暗号資産ウォレット] D --> G[OSクレデンシャルを
使用して復号化] E --> G F --> G G --> H[盗んだデータを含む
ログファイルを作成] H --> I[C2サーバーへ持ち出し] I --> J[ダークWebマーケットプレイス] J --> K[攻撃者がログを購入] K --> L[自分のブラウザに
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](https://www.corbado.com/glossary/malware)-as-a-Service）は、サイバー犯罪者の参入障壁を下げました。RedLine、Raccoon、Vidar、Taurus などの「インフォスティーラー」は、Web ブラウザからのデータ引き出しという主な目標の1つを念頭に置いて設計された、市販のマルウェアファミリです。これらのスティーラーは、フィッシングメール、クラックされたソフトウェア、または悪意のある広告を介して配布されます。インストールされると、Chrome、Edge、[Firefox](https://www.corbado.com/ja/blog/digital-credentials-api) などのブラウザがデータを保存する特定のファイルパスを標的にします。 - **ターゲット:** Cookies データベース（通常は [SQLite](https://www.corbado.com/blog/passkey-webauthn-database-guide) ファイル）と Login Data データベース（保存されたパスワード）。 - **メカニズム:** ブラウザは、ユーザーの OS ログインにリンクされた Data Protection API（Windows では DPAPI）を使用して、これらのデータベースを暗号化します。マルウェアは*ユーザーとして*実行されるため、これらのファイルの復号化を簡単に要求できます。 - **出力:** マルウェアは「ログ」を生成します。これは、復号化された Cookie、パスワード、システム情報、および場合によっては暗号資産ウォレットのキーを含む zip ファイルです。 ### 3.2 「ログ」の市場 これらのログは集約され、Genesis Market（閉鎖前）や Russian Market などのダーク Web [マーケットプレイス](https://www.corbado.com/passkeys-for-e-commerce)で販売されます。買い手は、「Salesforce」、「Gmail」、「Bank of America」、または「[AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) Console」などの特定の価値の高いターゲットのアクティブな Cookie を含むログを検索できます。 **バイパス:** Cookie ログの価値は、多要素認証（[MFA](https://www.corbado.com/ja/blog/application-security-risks)）をバイパスできることにあります。ほとんどの [MFA](https://www.corbado.com/ja/blog/application-security-risks) チャレンジ（SMS、TOTP、プッシュ）は、*ログイン*イベント中にのみ発生します。セッションが確立され、Cookie が発行されると、サーバーはユーザーが信頼できると想定します。有効なセッション Cookie をインポートした攻撃者は、[MFA ゲートをすり抜け](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc)、アクティブなタブに戻ってきたユーザーとしてサーバーに認識されます。 ### 3.3 Google Workspace と Microsoft Entra の脅威 クラウド生産性スイートは主要なターゲットです。Google Workspace または Microsoft Entra ID（旧 Azure AD）アカウントの盗まれたセッション Cookie は、攻撃者に企業の電子メール、ドキュメント、および内部システムへのアクセスを与える可能性があります。[Google 自身の脅威インテリジェンス](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html)では、Google アカウントにアクセスするための主要なベクトルとしての Cookie の盗難の急増を報告しており、これを DBSC への投資の推進力として明確に名指ししています。彼らは、2段階認証（[2SV](https://www.corbado.com/blog/2sv-vs-2fa)）とパスキーの有効化を強制するにつれて、攻撃者は単にクレデンシャルフィッシング（[2SV](https://www.corbado.com/blog/2sv-vs-2fa) / パスキーで阻止できる）から Cookie の盗難（[2SV](https://www.corbado.com/blog/2sv-vs-2fa) / パスキーでは阻止できないことが多い）に戦術を移したと指摘しています。 ### 3.4 「デバイスフィンガープリント」の限界 歴史的に、リスクエンジンは、[User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) 文字列、画面解像度、インストールされているフォント、IP アドレスなどのデバイスフィンガープリントを分析することで、セッションの盗難を検出しようとしてきました。セッション Cookie が、キャンバスフィンガープリントがわずかに異なる新しい IP から突然現れた場合、サーバーはそれを無効にする可能性があります。**問題:** ブラウザにおけるプライバシーイニシアチブ（[Safari](https://www.corbado.com/ja/blog/digital-credentials-api) の Intelligent Tracking Prevention や Chrome の Privacy Sandbox など）は、広告トラッキングを阻止するために、これらのフィンガープリントのエントロピーを積極的に減らしています。これにより、セキュリティのための「優れた」フィンガープリントはますます困難になっています。さらに、攻撃者は現在、これらのフィンガープリントを完全にスプーフィングして被害者のプロファイルに一致させることができる「アンチディテクトブラウザ」を使用しており、ヒューリスティックな検出は無効になっています。DBSC は、この確率的な推測ゲームを決定論的な暗号証明に置き換えます。 ## 4. 技術アーキテクチャ: DBSC の仕組み [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) は、クライアントデバイス上のキーにバインドされたセッションを作成するための[標準化された API とプロトコル](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials)を導入します。仕様では「記載されている脅威に対して堅牢な」キーの保存が義務付けられていますが、実装については不可知論的です。Chrome は、利用可能な場合は Windows 上で TPM を使用します。このセクションでは、[W3C](https://www.corbado.com/ja/blog/digital-credentials-api) のワーキングドラフトと Chrome のドキュメントで定義されているメカニズムについて詳しく説明します。 ### 4.1 コアコンポーネント | **コンポーネント** | **説明** | **DBSC における役割** | | ------------------------------------ | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | **ユーザーエージェント（ブラウザ）** | クライアントアプリケーション（Chrome、Edge など）。 | キーペアを管理し、HSM との対話を処理し、ネットワークリクエストをインターセプトして証明を添付します。 | | **リライングパーティ（サーバー）** | Web アプリケーション（銀行ポータルなど）。 | チャレンジを発行し、署名を検証し、セッションライフサイクルを管理します。 | | **キーストレージ** | セキュアストレージ（TPM、Secure Enclave、またはその他） | 秘密鍵を保存します。Chrome は Windows で利用可能な場合に TPM を使用します。仕様は実装について不可知論的です。 | | **セッション Cookie** | 標準の HTTP Cookie。 | ベアラートークンとして使用されますが、寿命が非常に短くなっています（例: 5～10分）。 | | **所持の証明** | 暗号化署名。 | 秘密鍵をまだ持っていることを証明するためにブラウザから送信される JWT。 | ### 4.2 DBSC プロトコルのライフサイクル DBSC ライフサイクルでは、標準セッションからバインドされたセッションへのシームレスな移行が可能になり、下位互換性とプログレッシブエンハンスメントが保証されます。 ```mermaid 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: 成功レスポンス ``` #### 4.2.1 フェーズ 1: 開始とバインディング バインディングプロセスは、ユーザーが標準的な方法（パスワード、パスキーなど）で認証を完了した直後に始まります。 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 ペイロード\>.\<署名\> ``` 4. **セッションのバインディング:** サーバーは署名を検証し、公開鍵が機能することを確認します。次に、データベースを更新して、ユーザーのセッション（session_id=xyz123）をこの特定の公開鍵に関連付けます。この瞬間から、セッションは「バインド」されます。 #### 4.2.2 フェーズ 2: 短命 Cookie のループ セキュリティとパフォーマンス（安全なキー操作によりレイテンシが追加される可能性がある）のバランスを取るため、DBSC はデュアルトークンシステムを使用します。 1. **発行:** サーバーは、有効期間の短い*新しい* Cookie（例: 5分間有効）を発行します。これを `access_token` と呼びましょう。 2. **使用:** ブラウザは、すべての通常のリクエスト（画像の取得、API 呼び出し、ページの移動）にこの `access_token` を使用します。Cookie が有効である限り、暗号化操作は実行されません。これにより、ブラウジングは高速に保たれます。 3. **有効期限:** 5分後、`access_token` は期限切れになります。 #### 4.2.3 フェーズ 3: リフレッシュ（所持の証明） これがセキュリティメカニズムの核心です。有効期間の短い Cookie が期限切れになると、別のデバイスにいる攻撃者はロックアウトされますが、正当なユーザー（バインドされたキーへのアクセス権を持つ）は続行できます。 1. **検出:** ブラウザがリクエストを試行します。Cookie の期限が切れていることに気付きます（またはサーバーが 401 や特定の `Secure-Session-Challenge` ヘッダーを返します）。 2. **インターセプト:** ブラウザはネットワークリクエストを*一時停止*します。ユーザーにはエラーを表示しません。 3. **リフレッシュリクエスト:** ブラウザは、セッション設定で定義されたリフレッシュエンドポイントを自動的に呼び出します。 - サーバーは暗号化**チャレンジ**（ノンス）を送信します。 - ブラウザはバインドされたキーを使用して、このチャレンジに署名します。 - 署名は秘密鍵の所持を証明します。 4. **送信:** ブラウザは署名されたチャレンジをサーバーに送り返します。 ``` HTTP POST /auth/dbsc/refresh HTTP/1.1 Sec-Secure-Session-Id: \ Secure-Session-Response: \ ``` 5. **検証:** サーバーは保存された公開鍵を使用して署名を検証します。 - _有効な場合:_ サーバーは、リクエストがセッションを開始したのと同じ物理デバイスから来ていることを認識します。*新しい*短命の `access_token`（さらに5分間有効）を発行します。 - _無効な場合:_ リクエストは拒否されます。セッションは終了します。 6. **再開:** ブラウザは新しい Cookie を取得し、一時停止されていた元のリクエストを透過的に再試行します。[ユーザーは中断を経験しません](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials)。 ### 4.3 実装のニュアンス #### 4.3.1 「リフトアンドシフト」の防御 ```mermaid graph LR subgraph "被害者のデバイス" A[DBSC保護された
ユーザーセッション] B[HSM/TPM
秘密鍵] C[Cookie +
セッションID] A --> B A --> C B -.->|エクスポート不可| X[秘密鍵は抽出
できない] end subgraph "攻撃シナリオ" D[RedLineスティーラーが
デバイスに感染] D --> E[Cookieとセッション
IDを盗む] E --> F[攻撃者へ
エクスポート] end subgraph "攻撃者のデバイス" G[盗んだCookie
をインポート] H[セッションの
使用を試みる] I[サーバーがDBSCリフ
レッシュを要求] J[チャレンジに
署名できない] 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 ヘッダーを見ますが、バインドされた秘密鍵を持っていないためリフレッシュを実行できません。攻撃は失敗します。 #### 4.3.2 スコープとプライバシー プライバシーは、DBSC の中心的な設計目標です。[W3C 仕様](https://www.w3.org/TR/dbsc/)では、ユーザーをサイト間でトラッキングできるグローバル識別子の使用を明示的に禁止しています。 - **オリジンごとのキー:** ブラウザはサイトごとに一意のキーペアを生成します。google.com はキー A を認識し、amazon.com はキー B を認識します。それらの間に相関関係はありません。 - **ユーザーのクリア:** ユーザーが Cookie/サイトデータをクリアすると、ブラウザは関連する DBSC キーも削除します。これにより、DBSC が削除されたアイデンティティを復活させる「スーパークッキー」として使用されることを防ぎます。 #### 4.3.3 サーバー側の考慮事項 DBSC を実装するには、サーバーが公開鍵に関する状態を維持する必要があります。 - **データベーススキーマ:** `user_id` と `session_expiry` と一緒に `public_key` と `last_challenge` を保存するように、セッションテーブルを更新する必要があります。 - **パフォーマンス:** リフレッシュ操作には暗号化検証（ECDSA 署名の検証など）が含まれます。高速ですが、単純な文字列のチェックよりも CPU を消費します。ただし、リフレッシュは数分ごとにのみ発生するため（すべてのリクエストで発生するわけではありません）、オーバーヘッドは無視できます。 ## 5. ビジネスおよびプロダクトへの影響 技術仕様を超えて、DBSC はビジネス戦略、製品ロードマップ、およびコンプライアンスの姿勢に重大な影響を与えます。 ### 5.1 摩擦のないセキュリティの ROI セキュリティイニシアチブは、多くの場合、コストセンターまたは摩擦の発生源と見なされます。DBSC はこの物語を覆します。次の図は、デバイスバインディングがビジネス上のメリットをどのように連鎖させるかを示しています。 - **不正の削減:** アカウント乗っ取り（ATO）の主要なベクトルを無効化することで、企業は不正による損失を数百万ドル節約できます。 - **サポートコスト:** アカウントの回復にはコストがかかります。[最初の段階でハッキングを防ぐ](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)ことで、この運用上の負担を直接軽減できます。 - **コンバージョンの最適化:** [eコマース](https://www.corbado.com/passkeys-for-e-commerce)では、ログインプロンプトはすべてドロップオフのポイントになる可能性があります。DBSC は、アグレッシブな「ログインしたままにする」ポリシーを可能にし、パスワードプロンプトなしで即時チェックアウトを可能にします。 ### 5.2 コンプライアンスと「最新技術」 ヨーロッパの GDPR（一般データ保護規則）などの規制の枠組みでは、組織はセキュリティを確保するために「適切な技術的および組織的対策」を実施する必要があります。 - **防御可能なセキュリティ:** DBSC が標準になるにつれて、セッション管理の「最新技術（State of the Art）」として解釈されるようになるでしょう。侵害が発生した場合、DBSC が実装されたことを証明することは、過失の主張に対する強力な防御になり得ます。 - **銀行の基準（PSD2）:** [決済](https://www.corbado.com/ja/blog/digital-credentials-payments-strategy)サービス指令2では、「強力な顧客認証（[SCA](https://www.corbado.com/ja/blog/passkey-deployment-mistakes-banks)）」が求められています。[SCA](https://www.corbado.com/ja/blog/passkey-deployment-mistakes-banks) はログインに焦点を当てていますが、デバイスへのセッションの動的なリンクは、認証を特定の金額や受取人にバインドするという指令の目的と完全に一致しています。 ### 5.3 高保証 vs. 中保証 [FIDO アライアンスのホワイトペーパー](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/)では、「保証レベル」の概念が強調されています。 - **中保証:** 同期されたパスキー（iCloud キーチェーンにあるようなもの）を使用します。コンシューマアプリに最適で、復元可能で使いやすいです。 - **高保証:** デバイスバウンドのキーが必要です。これは DBSC が輝くところです。エンタープライズリソース（人事ポータル、コードリポジトリ）や価値の高い[銀行業務](https://www.corbado.com/passkeys-for-banking)の場合、組織は特定の管理されたデバイスにバインドされたセッションからのアクセスのみを許可するポリシーを実施する場合があります。DBSC は、このポリシーに対する技術的な実施メカニズムを提供します。 ## 6. DBSC と代替手段の比較 DBSC を十分に理解するには、同様の問題を解決しようと試みた他のテクノロジーと比較する必要があります。 ```mermaid 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 ``` ### 6.1 DBSC vs. トークンバインディング 前述のとおり、トークンバインディングはセッションを TLS レイヤーにバインドしようとしました。 - **トークンバインディング:** クライアント、サーバー、*および*その間のすべてのホップ（ロードバランサー、TLS ターミネーター）からのサポートが必要でした。接続が終了して再暗号化されると、壊れてしまいました。 - **DBSC:** [HTTP アプリケーションレイヤーで動作します](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)。標準のヘッダー/Cookie としてロードバランサーを透過的に通過します。TLS が多くの場合クラウドプロバイダーのエッジネットワークによって処理される、最新のクラウドアーキテクチャ（[AWS](https://www.corbado.com/blog/passkeys-amazon-cognito)/GCP/Azure）への展開がはるかに簡単です。 ### 6.2 DBSC vs. DPoP (Demonstrating Proof of Possession) [DPoP（RFC 9449）](https://datatracker.ietf.org/doc/html/rfc9449)は、「送信者制約」の OAuth トークン標準です。これは、アクセストークンとリフレッシュトークンの*両方*を公開鍵にバインドします。リフレッシュトークン自体が長寿命のベアラークレデンシャルであるため、これは重要です。各 API リクエストには DPoP 証明（HTTP メソッド、URL、タイムスタンプ、および一意識別子を含む署名付き JWT）が含まれます。[FAPI 2.0](https://openid.net/specs/fapi-2_0-security-profile.html) のような高保証の仕様では、送信者制約トークンが義務付けられています。mTLS が利用できない場合は、DPoP が推奨される方法です。 **主な違い:** DPoP キーはアプリケーションコンテキストに存在します。ベストプラクティスは、抽出不可能なストレージに OS API を使用することですが、これは強制されていません。多くの実装では、キーを JavaScript からアクセス可能なメモリに保持しています。攻撃者が任意のコード（XSS、マルウェア）を実行できる場合、DPoP キーにアクセスしたり、オンデマンドで証明を生成したりする可能性があります。DPoP は、*異なるクライアント間*でのトークンのリプレイを停止しますが、侵害されたブラウザコンテキストを保護することはできません。 DBSC は、所持の証明をブラウザとハードウェアに移動させます。秘密鍵は、JavaScript が読み取ったりエクスポートしたりできない TPM または Secure Enclave に存在します。ブラウザはプロトコルを処理し、アプリケーションコードにキーを公開することなく署名を生成します。Web アプリが完全に侵害されたとしても、攻撃者は別のマシン上で、盗まれた Cookie に対する新しい証明を鋳造することはできません。 | 側面 | DPoP | DBSC | | -------------- | ------------------------------------------------ | --------------------------- | | **ターゲット** | OAuth アクセス + リフレッシュトークン | ブラウザセッション Cookie | | **キーの保存** | アプリコンテキスト（ベストプラクティス: OS API） | ハードウェアバックド（TPM） | | **XSS 耐性** | ⚠️ 実装に依存 | ✅ キーはエクスポート不可 | | **主な用途** | ネイティブアプリ、SPA、FAPI 2.0 | ユーザー向け Web セッション | **相乗効果:** [FIDO アライアンスが指摘しているように](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)、パスキーはログイン時のフィッシングを排除し、DBSC/DPoP は認証後のトークンを保護します。最新のアーキテクチャでは、両方を組み合わせています。OAuth API（特に規制対象のオープン[バンキング](https://www.corbado.com/passkeys-for-banking)）には DPoP を、ブラウザセッションには DBSC を使用します。これらを組み合わせることで、セッションのライフサイクル全体にわたって「リフトアンドシフト」攻撃ベクトルを閉じます。 ### 6.3 DBSC vs. 短命な Cookie（単独） 単に Cookie の有効期間を（たとえば 15 分に）短くするだけでもセキュリティは向上しますが、UX は損なわれます。ユーザーは常にログインを強いられます。DBSC は、30 日間の Cookie と同じ*ユーザーエクスペリエンス*で、5 分間の Cookie と*事実上*同じセキュリティを可能にします。 ## 7. Shared Signals と動的対応（CAEP/RISC） ```mermaid %%{init: { "theme": "default", "themeVariables": { "actorBkg": "#ffffff", "actorBorder": "#000000", "noteBkgColor": "#f1f3f5", "noteTextColor": "#000000", "activationBkgColor": "#e0e0e0", "actorColours": { "ST": "#ff6b6b", "IdP": "#4c6ef5" } } }}%% sequenceDiagram participant ST as セキュリティツール
(CrowdStrike, Defender) participant IdP as アイデンティティプロバイダ
(Okta, Google, Azure) participant SP1 as サービスプロバイダ 1
(Slack) participant SP2 as サービスプロバイダ 2
(Salesforce) participant SP3 as サービスプロバイダ 3
(銀行アプリ) participant Session as ユーザーセッション
(DBSC保護) Note over ST,Session: 脅威検出フェーズ ST->>ST: ユーザーデバイスで
マルウェアを検出 ST->>IdP: RISCシグナル:
「デバイスが侵害されました」 Note over IdP,SP3: シグナル伝播フェーズ IdP->>SP1: CAEPイベント:
「デバイスが侵害されました」 IdP->>SP2: CAEPイベント:
「デバイスが侵害されました」 IdP->>SP3: CAEPイベント:
「デバイスが侵害されました」 Note over SP1,Session: 強制フェーズ (DBSCあり) Session->>SP1: 次のリフレッシュ試行
(数分以内) SP1-->>Session: x 署名を拒否 Session->>SP2: 次のリフレッシュ試行 SP2-->>Session: x 署名を拒否 Session->>SP3: 次のリフレッシュ試行 SP3-->>Session: x 署名を拒否 Note over Session: セッションは次のリフレッシュ試行時に終了可能 ``` DBSC の可能性は、[**Shared Signals Framework（SSF）**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/)、特に **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 をリフレッシュしようとすると、サーバーは署名を拒否し、セッションを強制終了します。この[アーキテクチャパターン](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/)により、より迅速な取り消しが可能になります。実際のレイテンシは、サイトのリフレッシュ期間と、DBSC と SSF の両方を実装しているかどうかによって異なります。 ## 8. ブラウザおよびエコシステムのサポート DBSC の採用はブラウザベンダーにかかっています。2026年の状況は大きく変化しました。Chrome はオリジントライアルから Windows で一般公開（GA）に DBSC を移行させ、次に macOS も予定されています。他のブラウザはまだ評価中です。 ### 8.1 Google Chrome Google は DBSC の主な推進力であり、これを広く出荷した最初のブラウザです。 - **ステータス（2026年4月）:** [Chrome 146 では Windows で DBSC が GA として提供され](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)、オリジントライアルフェーズが終了しました。Secure Enclave を使用する macOS サポートは、今後の Chrome リリースで発表されています。 - **ハードウェア:** Windows は TPM を使用し、macOS は Secure Enclave を使用します。Google は、専用のセキュアなハードウェアを持たないデバイスに DBSC の保護を拡張するために、**ソフトウェアベースのキー**も検討していると述べています。 - **ロードマップ:** Google の GA 発表では、次のステップのロードマップも公開されました。 - **フェデレーションアイデンティティの保護:** リライングパーティ（RP）セッションがアイデンティティプロバイダ（IdP）セッションと同じデバイスキーにバインドされたままになるクロスオリジン DBSC バインディングにより、[SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) 全体で途切れない信頼チェーンを維持します。 - **高度な登録:** サインイン時に新しいキーを生成するのではなく、**mTLS 証明書**や**ハードウェアセキュリティキー**などの既存の信頼できるキーマテリアルに DBSC セッションをバインドします。 - **幅広いデバイスのサポート:** TPM / Secure Enclave のないデバイス向けのソフトウェアベースのキー。 - **運用の結果:** 展開中、Google は DBSC によって保護されたセッションで「セッションの盗難が大幅に減少した」と報告しています。 - **Google アカウント:** これとは別に、Google はエンタープライズポリシーを介して制御される、[Windows 上の Chrome 向け Google アカウント Cookie](https://support.google.com/chrome/a/answer/2657289) に対して DBSC スタイルの保護をすでに展開していました。これは Gmail/Workspace を保護し、現在は一般 Web 向けに GA となっているのと同じテクノロジーファミリーです。 ### 8.2 Microsoft Edge および Windows Microsoft は積極的に参加しています。 - **ステータス:** Edge は Windows で [DBSC オリジントライアル](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d)を実行していましたが、2025年10月に終了しました。代替のトライアルや GA は発表されていません。 - **エンタープライズコンテキスト:** Edge は、Entra/Azure AD [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) に概念的に DBSC に似ている[「Primary Refresh Token」（PRT）アーキテクチャ](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token)を利用しています。PRT は Microsoft 固有のメカニズムにとどまっており、サードパーティのサイト向けに DBSC Web 標準と統一する計画は発表されていません。 ### 8.3 Apple Safari (WebKit) モバイルのカバー範囲には [Apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos) のスタンスが重要です。 - **ステータス:** WebKit には、使いやすさやプライバシーに関する懸念を指摘しつつ DBSC を評価する[標準ポジションの問題](https://github.com/WebKit/standards-positions/issues/281)があります。[Safari](https://www.corbado.com/ja/blog/digital-credentials-api) のリリースノートでは DBSC について言及されていません。「積極的に実装中」という公の声明は存在しません。 - **プライバシーファースト:** [Apple](https://www.corbado.com/ja/blog/how-to-enable-passkeys-macos) の主な懸念は、DBSC が「スーパークッキー」（削除不可能なトラッキング）に使用される可能性があることです。[W3C](https://www.corbado.com/ja/blog/digital-credentials-api) 仕様では、Web サイトのデータとともにキーを確実にクリアすることでこれに対処しています。 - **エンゲージメント:** WebKit は標準化プロセスに関与していますが、実装の状況は不明です（「開発中」ではなく「議論中」）。 ### 8.4 Mozilla Firefox Mozilla には、複雑さとプライバシーに関する懸念を指摘しつつ DBSC を評価する[標準ポジションの問題](https://github.com/mozilla/standards-positions/issues/912)があります。標準が安定した後に実装するという公の確約はありません。 ## 9. 推奨事項: 今日のユーザーの保護 DBSC とパスキーに対する現在のエコシステムサポートを考慮し、組織はこれらの補完的なテクノロジーの実装に向けて段階的なアプローチを取る必要があります。以下のロードマップは、当面の行動と戦略的な計画のマイルストーンの概要を示しています。 ### 9.1 当面のアクション（Chrome 146 が GA となった現在） 1. **まずパスキーを展開する**: 認証レイヤーを保護するために、パスキーの実装から始めます。これにより、クレデンシャルフィッシングに対する即時の保護が提供され、DBSC の真の価値を引き出すための前提条件となります。 2. **DBSC 登録およびリフレッシュエンドポイントのリリース**: Chrome 146 GA に伴い、現実的な作業はバックエンドの統合になりました。ログインのレスポンスに `Secure-Session-Registration` ヘッダーを追加し、`/dbsc/register` と署名付きチャレンジを検証するリフレッシュエンドポイントを実装します。フロントエンドコードを変更する必要はありません。 3. **リフレッシュトークンを使用した短命セッションの実装**: DBSC の準備がまだ整っていない場合は、リフレッシュメカニズムを備えた短命トークンのアーキテクチャパターンを採用します。これにより、今日のセキュリティを向上させながら、バックエンドを DBSC に備えることができます。 ### 9.2 戦略計画（今後 12 か月） 1. **ハイブリッドアプローチの採用**: 機能検出を使用して、対応ブラウザ（現在は Windows の Chrome 146 以降、次は macOS Secure Enclave）に DBSC を提供する一方で、フォールバックオプションを維持します。これにより、[Safari](https://www.corbado.com/ja/blog/digital-credentials-api)、[Firefox](https://www.corbado.com/ja/blog/digital-credentials-api)、または Edge のユーザーを排除することなく、セキュリティを最大化できます。 2. **次のロードマップ項目に備える**: Google は、フェデレーションアイデンティティ（クロスオリジン SSO バインディング）、高度な登録（mTLS / ハードウェアキー）、およびより幅広いデバイスをカバーするためのソフトウェアベースのキーを明確に求めています。SSO または IdP レイヤーを運用している場合は、今すぐクロスオリジンバインディングのスコープ定義を開始してください。 3. **アイデンティティプロバイダとの統合**: Okta、[Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis)、または同様の IdP を使用している場合は、彼らと協力して SDK での DBSC サポートを有効にしてください。多くの企業がオリジントライアルに参加しており、Chrome が GA になった現在、DBSC 機能を積極的にリリースしています。 ### 9.3 実装のベストプラクティス - **価値の高いターゲットから始める**: 管理者パネル、金融取引、機密データへのアクセスに DBSC を優先します。 - **マネージドソリューションを使用する**: DBSC 実装の複雑さやブラウザの互換性を処理する Corbado のようなプラットフォームを検討してください。 - **測定して反復する**: セッションハイジャックの試行、サポートチケット、ユーザーの摩擦などの指標を追跡して、ROI を実証します。 - **コンプライアンスの準備**: 機密データを処理するためのコンプライアンス要件になる可能性が高いため、DBSC の実装を文書化します。 ## 10. Corbado の支援方法: 未来への架け橋 DBSC をゼロから実装することは、エンジニアリングの大きな負担です。暗号化に関する専門知識、ブラウザの不整合に関する深い知識、キーとチャレンジを管理するための堅牢なサーバー側インフラストラクチャが必要です。ここで、**Corbado** がイネーブラーとして機能します。 ### 10.1 基盤: パスキー 低保証のログインの上に高保証のセッションを構築することはできません。ユーザーが弱いパスワードでログインした場合、セッションはそのパスワードと同じくらいしか安全ではありません。Corbado のコア製品（**マネージドパスキー**）は必要な基盤を提供します。Corbado を統合することで、組織はパスキーを簡単に展開し、セッションの開始がフィッシング耐性を持つことを保証できます。 ### 10.2 未来: 信頼できるデバイス検出のための DBSC Corbado は DBSC を活用して、信頼できるデバイスの検出を強化します。DBSC シグナルが利用可能な場合、それらはセッションが特定のデバイスから発生しているという暗号証明を提供し、それに応じて Corbado が認証の信頼レベルを高めることを可能にします。 - **同期されたパスキーの曖昧さの解決:** 同期されたパスキーは便利ですが、信頼のギャップを生み出します。ユーザーが同期されたパスキーで認証した場合、それがいつものラップトップなのか、クレデンシャルを同期したばかりの新しいデバイスなのかを見分けることができません。DBSC はこのギャップを埋めます。デバイスに確立された DBSC バインディングがあるかどうかをチェックすることで、Corbado は、デバイスが初めての同期ではなく、本当に既知であり信頼されていることを確認できます。 - **既知のデバイスに対する高い信頼:** DBSC シグナルが以前にそのデバイスが確認されていることを確定した場合、Corbado はより確実なリスク決定を下すことができます。つまり、正当な再訪ユーザーに対するステップアップ認証のプロンプトを減らし、認識されないデバイスからのセッションに対する精査を厳格にします。 - **Passkey Intelligence の補完:** DBSC シグナルは、Corbado の既存の[**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) エンジンと統合されています。パスキーベースの認証と DBSC ベースのデバイスバインディングを組み合わせることで、ログインからセッションライフサイクル全体にわたる完全な信頼チェーンが作成されます。 Corbado が DBSC を自社プラットフォームにどのように統合する計画であるかについての質問は、[チームにお問い合わせください](https://www.corbado.com/contact)。 ### 10.3 適切なフォールバック（「ハイブリッド」な現実） 今後数年間は、Web はハイブリッドになるでしょう。一部のユーザーは DBSC 対応ブラウザ（[Windows 11](https://www.corbado.com/blog/passkeys-windows-11) の Chrome）を使用し、他のユーザーは古いシステムを使用します。この断片化に対処するのは困難です。Corbado の [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) エンジンは、まさにこの種のフォールバックロジックを処理するように設計されており、対応するデバイスにはパスキーを提供し、その他のデバイスにはフォールバックを提供します。この同じインテリジェンスがセッションバインディングにも適用され、デバイスの機能に応じてすべてのユーザーのセキュリティが最大化されることを保証します。 ## 11. 結論: DBSC の今後の道筋 「ベアラートークン」の時代は終わりに近づいています。現在のセッション管理は壊滅的に失敗しています。ベアラートークンは産業規模のマルウェア運用によって盗まれ、あらゆるデバイスから使用される可能性があり、最も強力な認証方法でさえもバイパスするアカウントの乗っ取りを可能にしています。この根本的な脆弱性により、数十億ドル規模の地下経済が生まれました。 [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) は、業界の新たな答えを表しています。HttpOnly フラグと静的シークレットを備えた従来のセキュアな Cookie とは異なり、DBSC はデバイスバウンドキーによる暗号化された所持証明を追加します。これにより、盗まれた Cookie の価値ははるかに低くなります。別のデバイスからリフレッシュすることはできません。トークンバインディングがすべてのインフラストラクチャで複雑な TLS レイヤーの変更を要求して失敗したのに対し、DBSC は HTTP アプリケーションレイヤーで動作し、既存のロードバランサーや CDN アーキテクチャと互換性があることで成功しています。注: DBSC には、ブラウザがバインディングをスキップするドキュメント化されたフォールバックパス（TPM が利用できない、ネットワークエラーなど）があるため、Cookie の盗難リスクを大幅に減らしますが、排除するものではありません。 DBSC とパスキーの相乗効果により、カスタマージャーニー全体で攻撃者に対するハードルが大幅に高まります。パスキーはログイン時のクレデンシャルフィッシングを排除し、DBSC はリモートでの Cookie 盗難によるセッションハイジャックをはるかに困難にします。これらが一体となって、[FIDO](https://www.corbado.com/ja/blog/emv-3ds-acs-passkeys-fido-spc-katsuyou) アライアンスが構想する「高保証」アイデンティティフレームワークを形成しています。[Chrome 146 が 2026 年 4 月に Windows で DBSC を GA として出荷し](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)、次に macOS の Secure Enclave サポートが提供されることで、標準は準備フェーズからロールアウトフェーズに移行しました。Google の公開ロードマップ（フェデレーションアイデンティティ、mTLS / ハードウェアキー登録、ソフトウェアベースのキー）は、今後 12 か月の拡大を示唆しています。 プロダクトマネージャーにとって、ビジネスケースは説得力があります。DBSC は、不正行為による損失とサポートコストを同時に削減しながら、ログインの摩擦を劇的に減らす「無期限の」セキュアなセッションを可能にします。ROI は、コンバージョン率の向上、パスワードリセットのチケットの減少、アカウント乗っ取りのインシデントの排除という形で現れます。OAuth を使用する組織は、DPoP を通じて API トークンに同じキーバインディングの概念を活用できます。また、Shared Signals（CAEP/RISC）との統合により、リアルタイムの脅威への対応が可能になり、次のリフレッシュの試行時に侵害されたセッションを即座に取り消すことができます。 実装をゼロから構築する必要はありません。[Corbado](https://www.corbado.com/features) のようなプラットフォームは、パスキーのインフラストラクチャを提供しており、ブラウザのサポートが成熟するにつれてデバイスバインディングを統合するために DBSC の開発を追跡しています。[W3C 仕様](https://www.w3.org/TR/dbsc/)はアクティブなワーキングドラフトであり、Chrome 146 は Windows で GA となり macOS にも展開されていますが、他のブラウザはまだこの標準を評価中です。 軌道は明確です。今日からパスキーと DBSC の採用を開始する組織は、パスワードのない、フィッシングに強い未来に向けて最適な位置につくでしょう。デバイスバウンドセッションを実装するかどうかではなく、ユーザーとビジネスを保護するためにどれだけ早く展開できるかが問題です。Web セキュリティの未来は、単に認証されるだけでなく、私たちが信頼するデバイスに暗号的にバインドされます。 ## よくある質問 (FAQ) ### DBSC は、侵害されたセッションをリアルタイムで取り消すために CAEP や RISC とどのように連携しますか？ CrowdStrike などのエンドポイントセキュリティツールがマルウェアを検出すると、RISC シグナルをアイデンティティプロバイダに送信し、アイデンティティプロバイダは接続されているアプリに「デバイスが侵害されました」という CAEP イベントをプッシュします。次の DBSC リフレッシュ試行時（数分以内）に、それらのアプリはセッション署名を拒否し、アクセスを終了します。クロスベンダーの CAEP/RISC の展開はまだ成熟しつつある段階です。 ### Web アプリケーションセッションの保護において、DBSC と DPoP の違いは何ですか？ DPoP（RFC 9449）は、OAuth のアクセストークンとリフレッシュトークンをアプリケーションレイヤーの公開鍵にバインドし、主にネイティブアプリと SPA での API 呼び出しを保護します。DBSC は、ブラウザのセッション Cookie を、JavaScript が読み取ったりエクスポートしたりできないハードウェアでバックアップされた TPM キーにバインドし、Web アプリ自体が XSS やマルウェアによって侵害された場合でも、ユーザー向けセッションを保護します。 ### セキュリティリスクを高めることなく、DBSC によってセッション時間を長くできるのはなぜですか？ 従来のセキュアな設計では、Cookie が盗まれてリモートでリプレイされた場合の被害を抑えるために、短いセッションタイムアウトが義務付けられています。DBSC は、リフレッシュ機能を元のデバイスの秘密鍵にバインドするため、別のデバイスから使用された盗まれた Cookie は暗号化チャレンジに失敗します。リモートでのリプレイ攻撃が中和されるため、セッションは事実上無期限にすることができます。 ### DBSC を展開することで、企業はどのようなビジネス ROI を期待できますか？ DBSC は、アカウントの乗っ取りの主なベクトルとしての Cookie の盗難を中和し、不正行為による損失とアカウント回復のサポートコストを直接削減します。安全で長いセッションにより、繰り返しのログインプロンプトが不要になり、eコマースでのコンバージョン率が向上し、ドロップオフが減少します。[FIDO](https://www.corbado.com/ja/blog/emv-3ds-acs-passkeys-fido-spc-katsuyou) アライアンスは、DBSC を、ユーザーの摩擦を減らすと同時にセキュリティの基準を引き上げるものとして位置付けています。