Googleは、Chrome 146のWindowsユーザー向けにDevice Bound Session Credentials（DBSC）の一般提供を開始した。この技術は2024年4月に初めて発表されており、今後のChromeのリリースでmacOSにも拡大される予定だ。DBSCは、セッションセキュリティにおける最も一般的な問題の一つである、攻撃者がパスワードを必要とせずにアカウントへアクセスできるCookieの窃取を対象としている。
セッションの窃取は通常、ユーザーが意図せずマルウェアをダウンロードした際に発生する。マルウェアは実行後、ブラウザーから現在のCookieを抽出したり、ユーザーが新しいアカウントにログインするのを待ったりして、その後これらのトークンを攻撃者が管理するサーバーへ送信できる。Googleは、LummaC2などの情報窃取マルウェアファミリーが、認証情報の収集において一層高度化していると指摘している。
一部のCookieは有効期間が長いため、こうしたCookieの危険性はさらに高まる。攻撃者はそれらを使ってアカウントへ不正アクセスし、その後、犯罪関係者の間で収集、取引、販売できる。また、高度なマルウェアはデバイスに侵入すると、ブラウザーが認証Cookieを保存しているファイルやメモリを読み取ることができる。そのためGoogleは、OSにかかわらず、ソフトウェアだけに依存してCookieの抽出を防ぐ信頼できる方法は存在しないと考えている。
デバイスから離れない鍵にセッションを結び付ける
DBSCは、認証セッションを特定のデバイスに暗号学的に結び付けることで、このモデルを変える。この技術は、WindowsのTPMやmacOSのSecure Enclaveなど、ハードウェアで保護されたセキュリティモジュールを使用して、固有の公開鍵と秘密鍵のペアを生成する。秘密鍵をデバイスからエクスポートすることはできない。
サーバーは、Chromeがセッションに関連付けられた秘密鍵を所有していることを証明した後にのみ、新しい短期間有効なCookieを発行する。攻撃者はこの鍵を盗めないため、抽出されたCookieはすぐに期限切れとなり、アカウントへのアクセスには役立たなくなる。Googleによると、昨年、プロトコルの初期版を導入して以来、DBSCで保護されたセッションの窃取が大幅に減少した。
大規模なサイトでも小規模なサイトでも、バックエンドシステムに登録および更新用の専用エンドポイントを追加することで、ハードウェアに結び付いたセッションを導入でき、既存のフロントエンド互換性を維持できる。複雑な暗号処理とCookieのバックグラウンドでのローテーションはブラウザーが担い、Webアプリケーションは引き続き標準Cookieを使用してサービスにアクセスする。
ユーザーを追跡せずにセッションを保護
DBSCはプライバシーを考慮して設計されている。各セッションは個別の鍵に基づくため、サイトがこれらの認証情報を使って、同じデバイス上で異なるセッション間、または複数のサイト間でユーザーの活動を結び付けることを防ぐ。また、このプロトコルがサーバーに送信するのは、デバイス識別子や認証データではなく、秘密鍵の保有を証明するために必要なセッション固有の公開鍵だけである。
Googleによると、この情報交換の制限により、この技術がサイト間の追跡やデバイスの識別用フィンガープリントの構築に利用されるリスクが抑えられる。
オープン標準と継続的な開発
DBSCは当初から、W3CのプロセスとWebアプリケーションセキュリティワーキンググループの承認を通じた、Web向けのオープン標準として設計されている。GoogleはMicrosoftと標準の設計で協力し、Oktaを含む多数のWebプラットフォームが昨年のOrigin Trialsに参加し、テストと利用に基づくフィードバックを提供した。
Googleは開発者向けに実装ガイドを提供しているほか、プロトコル仕様、GitHubリポジトリ、バグの報告や機能提案を行うためのページも提供している。
今後の開発分野には以下が含まれる。
- 統合アイデンティティの保護：DBSCを拡張して異なる資産間の結び付けをサポートし、シングルサインオンのプロセス全体を通じて、依拠当事者のセッションをアイデンティティプロバイダーで使用された元のデバイス鍵に結び付けたままにする。
- 高度な登録機能：ログイン時に新しい鍵を生成する代わりに、mTLS証明書やハードウェアセキュリティキーなど、既存の信頼できる鍵素材にセッションを結び付ける。
- より広範なデバイスのサポート：専用のセキュリティハードウェアを搭載していないデバイスを保護するため、ソフトウェアベースの鍵の追加を検討する。