入門DBSC - Speaker Deck

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright © Yoshikazu Nojima 2025 自己紹介 • 能島良和 • Red Hatでミドルウェア製品のテクニカルサポートを担当 • WebAuthn4Jというライブラリの開発者 https://github.com/webauthn4j/webauthn4j Keycloak、Spring、Quarkus等で採用 • Twitter:@shiroica • GitHub:ynojima 1

Slide 3

Slide 3 text

Copyright © Yoshikazu Nojima 2025 アカウント乗っ取り攻撃と対策の現在フィッシング攻撃等、アカウント乗っ取り攻撃が急増一方で、対策としてパスキー認証への対応導入も進みつつある 2 日経（証券口座の不正アクセス対策） https://www.nikkei.com/article/ DGXZQOUD282OI0Y5A720C2000000/ 証券口座の不正アクセス対策、パスキーなどの多要素認証を必須化へ – Impress Watch https://www.watch.impress.co.jp/docs/news/2031496.html

Slide 4

Slide 4 text

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Copyright © Yoshikazu Nojima 2025 対策１：鍵保護HW（TPM等）の活用鍵保護HWは、PC等に搭載される耐タンパ性のあるセキュリティ用チップ。秘密鍵をHWの中で生成・保持し、秘密鍵を用いた署名・暗号化要求のみ受付。秘密鍵の取り出しは、正規のソフトウェア、ユーザーでも不可能 DBSCではセッション確立時にTPMで鍵ペア生成、セッション維持に利用マルウェアからのクレデンシャルの盗難を防止し、セッション確立時と同一デバイスで処理されたリクエストであることを保証（=Device Bound）課題： TPM等の鍵保護HWは、一般に全HTTPリクエスト署名には性能不足 7

Slide 9

Slide 9 text

Copyright © Yoshikazu Nojima 2025 対策２：Cookieと非対称鍵ペアのハイブリッド DBSCは各HTTPリクエストをCookieで認証し、 Cookieの更新リクエストのみ鍵ペアで認証するハイブリッド方式 8 通常アクセス：Cookieのみ Cookie更新時：電子署名ブラウザサーバーブラウザサーバー秘密鍵で電子署名 Cookie を添付応答が返却 Cookieが返却課題：各HTTPリクエストの認証に結局Cookieを使うなら、Cookieの盗難に脆弱

Slide 10

Slide 10 text

Copyright © Yoshikazu Nojima 2025 マルウェアによるCookie盗難は、盗んだCookieを闇で売る営利目的の攻撃者がメイン Cookie売買を中心とした営利的攻撃エコシステムが存在 DBSCのアプローチ鍵ペアを利用したCookie自動更新でCookie短命化し、営利目的の攻撃の成立性を低下させる対策３：鍵ペアを利用したCookie更新自動化によりCookie短命化 9 マルウェアによる攻撃者が出品別の攻撃者が購入、悪用賞味期限：1分！ DBSCは、鍵保護HW・ハイブリッド認証・Cookie短命化を組み合わせて、セッションハイジャックの抑制を狙う

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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: body: {“session_identifier”: ... } //Session Instruction JSON 200 OK Set-Cookie: <通常セッショントークンCookie> Secure-Session-Registration: (alg…); challenge=“…”; path=“<登録Endpointのパス>... サイトへのリクエスト Cookie: < DBSC保護セッショントークンCookie > 200 OK body :

Slide 13

Slide 13 text

Copyright © Yoshikazu Nojima 2025 Cookieの自動更新鍵保護機構(TPM等) ブラウザサーバーセッションストア DBSC保護セッションの利用保存されている秘密鍵で電子署名チャレンジへの署名要求署名を返却 Session Instruction JSONの検証 DBSC保護セッションに紐づけられた公開鍵で電子署名を検証 DBSC保護Cookieの更新 DBSC保護セッション新DBSC保護Cookie セッション利用鍵ペア 403 Forbidden Secure-Session-Challenge: <チャレンジ>; サイトへのリクエスト Cookie: < DBSC保護セッショントークンCookie > POST <更新エンドポイントのパス> Sec-Secure-Session-Id: 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 :

Slide 14

Slide 14 text

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 : <通常セッションに基づいた応答>

Slide 15

Slide 15 text

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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関連のリクエスト２つ目： 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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Copyright © Yoshikazu Nojima 2025 DBSCのデバッグでよくある悩み鍵保護機構(TPM等) ブラウザサーバーセッションストア DBSC保護セッションの利用保存されている秘密鍵で電子署名チャレンジへの署名要求署名を返却 Session Instruction JSONの検証 DBSC保護セッションに紐づけられた公開鍵で電子署名を検証 DBSC保護Cookieの更新 DBSC保護セッション DBSC保護Cookie セッション利用鍵ペア 403 Forbidden Secure-Session-Challenge: <チャレンジ>; サイトへのリクエスト Cookie: < DBSC保護セッショントークンCookie > POST <更新エンドポイントのパス> Sec-Secure-Session-Id: DBSC保護Cookie有効期限切れ後に、ユーザーがサイトへのリクエストが発生する操作を実施 200 OK Set-Cookie: body: {“session_identifier”: ... } //Session Instruction JSON POST <更新エンドポイントのパス> Cookie: <通常セッショントークンCookie> Secure-Session-Response: eyJ... //DBSC Proof JWT 200 OK body : 飛んでこない更新リクエストが開発者ツールで表示されない飛んでこない

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Copyright © Yoshikazu Nojima 2025 DBSCの限界セッショントークンCookieが盗まれる主なシナリオ HTTPS化が進んだ昨今、端末侵害マルウェアが主な脅威 DBSCは、Cookie短命化により盗難Cookieの悪用・売買を困難に一方で、 • CookieはBearer Tokenのままであり、盗難されたCookieの悪用を完全に防ぐものではない • 端末侵害が継続している場合、鍵保護HWは”署名オラクル”※ として悪用されうる • マルウェアが管理者権限を奪取しブラウザの改竄すら成功している場合、鍵保護HWを使わず、攻撃者の鍵ペアを使用してDBSCフローを通す可能性もあるこの場合、攻撃者の端末からも攻撃者の秘密鍵でCookieの更新が可能にセッションに対する攻撃を完全に解決するものではない ※署名オラクル：秘密鍵そのものは出さないが、攻撃者の要求に応じて「署名だけはしてくれる」装置＝攻撃者が「これに署名して」と投げると、毎回正しい署名を返してしまう存在 26

Slide 28

Slide 28 text

Slide 29

Slide 29 text

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