Chromeが実装した「DBSC」とは何か#
GoogleのChromeブラウザが、アカウント乗っ取りに対抗する新たな保護機能「デバイスバウンドセッション認証情報（DBSC：Device-Bound Session Credentials）」を導入した。この機能は、2要素認証（2FA）やパスキーといった従来の保護手段が普及するなかで急増している、セッションクッキー盗難を起点としたアカウント侵害に対する有力な対抗策として注目されている。
セッションクッキー盗難という脅威#
そもそも「セッションクッキー」とは、ウェブサイトがブラウザに保存する固有の文字列であり、ログイン済みであることを証明するために利用される。これにより、ページを開くたびにパスワードを入力する手間が省ける便利な仕組みだ。
しかし、2FAやパスキーの普及によって単純なパスワード盗難やフィッシング攻撃の効果が薄れた結果、攻撃者はセッションクッキーの窃取へと手口を移しつつある。具体的には、インフォスティーラー型マルウェアや**中間者攻撃（AiTM攻撃）**を用いてクッキーを盗み出し、攻撃者自身のブラウザにそのクッキーを貼り付けることで、正規ユーザーと同等のアクセス権を一時的に得ることができてしまう。
DBSCの仕組み：ハードウェアの力で鍵を守る#
DBSCはこの問題に対し、デバイス内のハードウェアセキュリティ領域を活用することで対応する。具体的には、ブラウザが動作するデバイスに内蔵された「シリコン上のセキュリティ領域」に固有の暗号鍵を保存する。
- Windowsの場合：TPM（Trusted Platform Module）と呼ばれるチップ
- macOS・iOSの場合：セキュアエンクレーブ（Secure Enclave）
ウェブサイトがセッションクッキーをセットすると、ブラウザはそのクッキーをTPMまたはセキュアエンクレーブに保存された秘密鍵で署名した形式で送信しなければならない。これらのハードウェア領域は、鍵の外部への抽出を構造的に防ぐ設計になっている。
セキュリティ研究者でReport URI創設者のScott Helme氏はこの仕組みについて、「攻撃者はTPM／セキュアエンクレーブから秘密鍵を盗み出すことができない。それがこの保護の核心だ。クッキーを盗むことはできても、デバイス上に安全に保管された秘密鍵でDBSCチャレンジに署名して応答することはできない」と説明している。
ウェブサーバー側は訪問者の公開鍵を保存しておき、セッションクッキーを含む認証チャレンジを送信する。その応答（認証アサーション）がTPMまたはセキュアエンクレーブ内の秘密鍵で署名されていない場合、アクセスは拒否される。この仕組みはパスキーと同様の考え方に基づいている。
現在の対応状況と確認方法#
現時点では、DBSCは以下の環境でのみサポートされている。
- Windows版 Chrome 147
- macOS版 Chrome 150
ただし、現状では限られたユーザーに対してのみ有効化されており、Googleが広く展開する前のテスト段階とみられる。
Chrome上でDBSCが有効かどうかを確認するには、デベロッパーツールを開き、上部の「Application」タブをクリックしてスクロールダウンすることで確認できる。DBSCをサポートするサイトにログインしている状態で保護が有効であれば、「device bound sessions」という項目が表示される。
なお、他のChromiumベースのブラウザへの展開時期や可否については現時点では明確ではないが、対応が進む可能性はあるとされている。
また、DBSCはW3Cの標準化作業としても進められており、ドラフト仕様が公開されている。ただし、その仕様書の「非目標（Non-goals）」セクションには、「セッション登録時点でユーザーエージェントを置き換えたり注入したりする攻撃者に対しては防御できない」という制限事項も明記されている点には注意が必要だ。
まとめ#
DBSCは、「共有秘密（パスワード）への依存を排除する」という認証の進化において重要な一歩だ。セッションクッキー盗難というアカウント乗っ取りの主要手口に対し、ハードウェアレベルで対抗する点が最大の特徴といえる。
筆者の見解： W3C標準化と並行してChromeへの実装が進んでいることは、ウェブ全体でのセキュリティ底上げに向けた動きとして注目に値する。一方で、仕様書が示すように万能ではなく、攻撃手法の進化との継続的なイタチごっこは避けられない。今後、対応サイトがどれほど広がるかが普及の鍵を握るだろう。
出典: Chrome adopts what may be the best protection yet against account takeovers
