Upgrade to Pro — share decks privately, control downloads, hide ads and more …

入門DBSC

 入門DBSC

Avatar for Yoshikazu Nojima

Yoshikazu Nojima

February 26, 2026
Tweet

More Decks by Yoshikazu Nojima

Other Decks in Technology

Transcript

  1. Copyright © Yoshikazu Nojima 2026 入門 DBSC (Device Bound Session

    Credentials) 2026-02-25 能島 良和(Yoshikazu Nojima)
  2. Copyright © Yoshikazu Nojima 2025 自己紹介 • 能島 良和 •

    Red Hatでミドルウェア製品のテクニカルサポートを担当 • WebAuthn4Jというライブラリの開発者 https://github.com/webauthn4j/webauthn4j Keycloak、Spring、Quarkus等で採用 • Twitter:@shiroica • GitHub:ynojima 1
  3. Copyright © Yoshikazu Nojima 2025 アカウント乗っ取り攻撃と対策の現在 フィッシング攻撃等、アカウント乗っ取り攻撃が急増 一方で、対策としてパスキー認証への対応導入も進みつつある 2 日経(証券口座の不正アクセス対策)

    https://www.nikkei.com/article/ DGXZQOUD282OI0Y5A720C2000000/ 証券口座の不正アクセス対策、 パスキーなどの多要素認証を必須化へ – Impress Watch https://www.watch.impress.co.jp/docs/news/2031496.html
  4. Copyright © Yoshikazu Nojima 2025 従来のセッションの確立と利用 ブラウザ サーバー サイトへのリクエスト セッションストア

    200 OK Set-Cookie: <通常セッションのCookie> セッション作成 サイトへのリクエスト Cookie: <通常セッションのCookie> 200 OK body : <セッションに基づいた応答> セッション取得 セッション Cookie セッションの確立 セッションの利用 攻撃者 セッション取得 サイトへのリクエスト Cookie: <通常セッションのCookie> 200 OK body : <セッションに基づいた応答> 弱点:Cookieは「持っているだけで使える」クレデンシャル(=Bearer Token) 窃取されるとそのままセッションハイジャックにつながる セッションの乗っ取り 盗用Cookie
  5. Copyright © Yoshikazu Nojima 2025 DBSC (Device Bound Session Credentials)

    Cookie盗難によるセッションハイジャック問題を緩和するためのWeb標準(W3C策定中) 。 Googleが中心となって仕様策定が進められており、 ChromeではFeature Flag有効化により試用可能 ※注意点:本資料では以下をベースに調査。 ・DBSC Editor’s Draft, 21 November 2025 ・Chrome Dev 144.0.7534.3 まだ策定中の仕様であり、今後も様々な変更がされる可能性があるため、最新の情報をご確認下さい。 5
  6. Copyright © Yoshikazu Nojima 2025 対策1:鍵保護HW(TPM等)の活用 鍵保護HWは、PC等に搭載される耐タンパ性のあるセキュリティ用チップ。 秘密鍵をHWの中で生成・保持し、秘密鍵を用いた 署名・暗号化要求のみ受付。秘密鍵の取り出しは、 正規のソフトウェア、ユーザーでも不可能

    DBSCではセッション確立時にTPMで鍵ペア生成、セッション維持に利用 マルウェアからのクレデンシャルの盗難を防止し、 セッション確立時と同一デバイスで処理されたリクエストであることを保証 (=Device Bound) 課題: TPM等の鍵保護HWは、一般に全HTTPリクエスト署名には性能不足 7
  7. Copyright © Yoshikazu Nojima 2025 対策2:Cookieと非対称鍵ペアのハイブリッド DBSCは各HTTPリクエストをCookieで認証し、 Cookieの更新リクエストのみ鍵ペアで認証するハイブリッド方式 8 通常アクセス:Cookieのみ

    Cookie更新時:電子署名 ブラウザ サーバー ブラウザ サーバー 秘密鍵で 電子署名 Cookie を添付 応答が 返却 Cookieが 返却 課題: 各HTTPリクエストの認証に結局Cookieを使うなら、Cookieの盗難に脆弱
  8. Copyright © Yoshikazu Nojima 2025 マルウェアによるCookie盗難は、盗んだCookieを闇で売る営利目的の攻撃者がメイン Cookie売買を中心とした営利的攻撃エコシステムが存在 DBSCのアプローチ 鍵ペアを利用したCookie自動更新でCookie短命化し、 営利目的の攻撃の成立性を低下させる

    対策3: 鍵ペアを利用したCookie更新自動化によりCookie短命化 9 マルウェアによる 攻撃者が出品 別の攻撃者が 購入、悪用 賞味期限:1分! DBSCは、鍵保護HW・ハイブリッド認証・Cookie短命化を 組み合わせて、セッションハイジャックの抑制を狙う
  9. Copyright © Yoshikazu Nojima 2025 DBSC保護セッションの確立と利用 鍵保護機構(TPM等) ブラウザ サーバー サイトへのリクエスト

    DBSC用鍵ペアを生成 セッションストア セッション作成 DBSC用鍵ペアの生成要求 公開鍵を返却 Session Instruction JSONの検証 公開鍵を紐づけて保存し、 DBSC保護セッションに アップグレード DBSC保護セッション 通常セッション 通常セッションの確立 DBSC保護セッションの確立(非同期) DBSC保護セッションの利用 セッション利用 DBSC保護Cookie 通常のCookie 鍵ペア POST <登録Endpointのパス> Cookie: <通常セッショントークンCookie> Secure-Session-Response: eyJ... //DBSC Proof JWT 200 OK Set-Cookie: <DBSC保護セッショントークンCookie> body: {“session_identifier”: ... } //Session Instruction JSON 200 OK Set-Cookie: <通常セッショントークンCookie> Secure-Session-Registration: (alg…); challenge=“…”; path=“<登録Endpointのパス>... サイトへのリクエスト Cookie: < DBSC保護セッショントークンCookie > 200 OK body : <DBSC保護セッションに基づいた応答>
  10. Copyright © Yoshikazu Nojima 2025 Cookieの自動更新 鍵保護機構(TPM等) ブラウザ サーバー セッションストア

    DBSC保護セッションの利用 保存されている秘密鍵で電子署名 チャレンジへの署名要求 署名を返却 Session Instruction JSONの検証 DBSC保護セッションに紐づけ られた公開鍵で電子署名を検証 DBSC保護Cookieの更新 DBSC保護セッション 新DBSC保護Cookie セッション利用 鍵ペア 403 Forbidden Secure-Session-Challenge: <チャレンジ>; <DBSC保護セッショントークン> サイトへのリクエスト Cookie: < DBSC保護セッショントークンCookie > POST <更新エンドポイントのパス> Sec-Secure-Session-Id: <DBSC保護セッショントークン> DBSC保護Cookie有効期限切れ後に、サイトへの リクエストが発生するとCookie更新が差し込まれる 200 OK Set-Cookie: <新DBSC保護セッショントークンCookie> body: {“session_identifier”: ... } //Session Instruction JSON POST <更新エンドポイントのパス> Cookie: < DBSC保護セッショントークンCookie> Secure-Session-Response: eyJ... //DBSC Proof JWT 200 OK body : <DBSC保護セッションに基づいた応答>
  11. Copyright © Yoshikazu Nojima 2025 ブラウザがDBSC未対応の場合のフォールバック 鍵保護機構(TPM等) ブラウザ サーバー サイトへのリクエスト

    セッションストア セッション作成 通常セッション 通常セッションの確立 DBSC保護セッションの確立(非同期) 通常セッションの利用 セッション利用 通常のCookie 200 OK Set-Cookie: <通常セッショントークンCookie> Secure-Session-Registration: (alg…); challenge=“…”; path=“<登録Endpointのパス>... サイトへのリクエスト Cookie: < 通常セッショントークンCookie > 結果、DBSC保護セッションにアップグレードされない (通常セッショントークンCookieを送信) DBSC用鍵ペアの生成要求 ブラウザがDBSC非対応の場合、 登録処理が開始されない 200 OK body : <通常セッションに基づいた応答>
  12. Copyright © Yoshikazu Nojima 2025 DBSCのテスト方法 2025年12月現在、ChromeでDBSCはデフォルト無効 chrome://flagsから以下のフラグの設定をすることで試すことが可能 - Device

    Bound Session Credentials with software keys -> “Enabled” - Device Bound Session Credentials (Standard) -> “Enabled - For developers” - Device Bound Session Credentials (Standard) Persistence -> “Enabled” 15
  13. Copyright © Yoshikazu Nojima 2025 デモのアクセスログ #セッション確立時に発行されたDBSC registerのリクエスト 21:22:26,158 [io.qua.htt.access-log]

    - - "POST /dbsc/register HTTP/2" 200 326 # ログイン時のリクエスト 21:22:53,972 [io.qua.htt.access-log] - - "POST /login HTTP/2" 204 - 21:22:53,983 [io.qua.htt.access-log] - user "GET /login/status HTTP/2" 200 355 # 10分経過後、/login/statusへのリクエスト発行時に # 差し込まれたDBSC関連のリクエスト1つ目:DBSC refresh用challengeの取得 21:33:00,589 [io.qua.htt.access-log] - - "POST /dbsc/refresh HTTP/2" 403 - # DBSC関連のリクエスト2つ目: DBSC refreshの実行 21:33:00,598 [io.qua.htt.access-log] - - "POST /dbsc/refresh HTTP/2" 200 326 # RefreshされたCookieが付与されたリクエスト 21:33:00,607 [io.qua.htt.access-log] - user "GET /login/status HTTP/2" 200 517 17
  14. Copyright © Yoshikazu Nojima 2025 DBSCのデバッグでよくある悩み 鍵保護機構(TPM等) ブラウザ サーバー セッションストア

    DBSC保護セッションの利用 保存されている秘密鍵で電子署名 チャレンジへの署名要求 署名を返却 Session Instruction JSONの検証 DBSC保護セッションに紐づけ られた公開鍵で電子署名を検証 DBSC保護Cookieの更新 DBSC保護セッション DBSC保護Cookie セッション利用 鍵ペア 403 Forbidden Secure-Session-Challenge: <チャレンジ>; <DBSC保護セッショントークン> サイトへのリクエスト Cookie: < DBSC保護セッショントークンCookie > POST <更新エンドポイントのパス> Sec-Secure-Session-Id: <DBSC保護セッショントークン> DBSC保護Cookie有効期限切れ後に、ユーザーが サイトへのリクエストが発生する操作を実施 200 OK Set-Cookie: <DBSC保護セッショントークンCookie> body: {“session_identifier”: ... } //Session Instruction JSON POST <更新エンドポイントのパス> Cookie: <通常セッショントークンCookie> Secure-Session-Response: eyJ... //DBSC Proof JWT 200 OK body : <DBSC保護セッションに基づいた応答> 飛んでこない 更新リクエストが 開発者ツールで表示されない 飛んでこない
  15. Copyright © Yoshikazu Nojima 2025 処理エラー原因の特定:ヒストグラムの確認 24 DBSCの登録処理は、Net.DeviceBoundSessions.RegistrationResult として記録。 この例だと、RegistrationResultとして57という値が記録されているが、

    この57など、ヒストグラムのそれぞれの値が何であるかは、Chromiumの以下のコードで定義 https://chromium.googlesource.com/chromium/src/+/refs/branch- heads/7489/tools/metrics/histograms/metadata/net/enums.xml#292
  16. Copyright © Yoshikazu Nojima 2025 DBSCの限界 セッショントークンCookieが盗まれる主なシナリオ HTTPS化が進んだ昨今、端末侵害マルウェアが主な脅威 DBSCは、Cookie短命化により盗難Cookieの悪用・売買を困難に 一方で、

    • CookieはBearer Tokenのままであり、盗難されたCookieの悪用を完全に防ぐものではない • 端末侵害が継続している場合、鍵保護HWは”署名オラクル”※ として悪用されうる • マルウェアが管理者権限を奪取しブラウザの改竄すら成功している場合、 鍵保護HWを使わず、攻撃者の鍵ペアを使用してDBSCフローを通す可能性もある この場合、攻撃者の端末からも攻撃者の秘密鍵でCookieの更新が可能に セッションに対する攻撃を完全に解決するものではない ※署名オラクル: 秘密鍵そのものは出さないが、攻撃者の要求に応じて「署名だけはしてくれる」装置 =攻撃者が「これに署名して」と投げると、毎回正しい署名を返してしまう存在 26
  17. Copyright © Yoshikazu Nojima 2025 まとめと所感 まとめ • DBSC(Device Bound

    Session Credentials)は、 Cookie盗難によるセッションハイジャックの抑制を目的とした仕様 • 鍵保護HWを利用したCookie自動更新により、Cookie短命化を実現 • Cookie自体はBearer Tokenのままだが、 短命化により営利目的の攻撃の成立性を下げられる 所感 • 導入によりセキュリティは向上するが、Bearer TokenのままのCookieや、 鍵保護HWの署名オラクルとしての悪用可能性も存在し、 セッションハイジャックを完全に解決するものではない • 一方で、エンドユーザーに意識させずに導入が可能であり ユーザー教育コストが不要なのは明確なメリット • ブラウザやWebアプリフレームワークでサポートが進めば、 低コストで導入しやすい有力な選択肢になりうる 28