デバイスバウンドセッション認証情報によるクッキーの保護

Ben Ackerman（Chrome チーム）、Daniel Rubery（Chrome チーム）、Guillaume Ehinger（Google アカウント セキュリティ チーム）による投稿

2024年4月の発表に続き、デバイスバウンドセッション認証情報（DBSC）は現在Chrome 146のWindowsユーザー向けに公開利用可能となり、今後のChromeリリースではmacOSにも拡大します。このプロジェクトは、現代のセキュリティ環境において依然として蔓延している脅威であるセッション盗難に対処するための継続的な取り組みにおいて、大きな前進を表しています。

セッション盗難は通常、ユーザーが不注意でデバイスにマルウェアをダウンロードした場合に発生します。一度アクティブになると、マルウェアはブラウザから既存のセッションクッキーを静かに抽出することができます。または、ユーザーが新しいアカウントにログインするのを待ってから、これらのトークンを攻撃者が管理するサーバーに流出させることができます。LummaC2などの情報窃取型マルウェア系統は、これらの認証情報を収集する際の高度さが増してきています。クッキーはしばしば長い有効期限を持っているため、攻撃者はパスワードを必要としないままユーザーのアカウントへの不正アクセスを得るために使用することができます。このアクセスはその後、脅威主体の間でバンドルされ、取引され、または売却されることがよくあります。

重要なことに、一度高度なマルウェアがマシンへのアクセスを獲得すると、ブラウザが認証クッキーを保存するローカルファイルとメモリを読み取ることができます。結果として、任意のオペレーティングシステム上でソフトウェアのみを使用してクッキーの流出を防ぐ信頼できる方法はありません。歴史的には、セッション盗難の軽減は、複雑な一連の悪用ヒューリスティックを使用して盗まれた認証情報を事後的に検出することに依存していました。これは持続的な攻撃者がしばしば回避できる反応的なアプローチです。DBSCは、反応的な検出から主動的な予防へのパラダイム転換により、この脅威に対する防御のウェブの能力を根本的に変え、成功裏に流出したクッキーがユーザーのアカウントへのアクセスに使用されないようにします。

DBSCの仕組み

DBSCは、認証セッションを特定のデバイスに暗号的にバインドすることによってセッション盗難から保護します。これは、Windows上のトラステッドプラットフォームモジュール（TPM）やmacOS上のセキュアエンクレーブなどのハードウェアに支援されたセキュリティモジュールを使用して、マシンからエクスポートできない一意の公開鍵/秘密鍵ペアを生成することによって行われます。新しい短命なセッションクッキーの発行は、Chromeが対応する秘密鍵の所持をサーバーに証明することに条件付きです。攻撃者はこの鍵を盗むことはできないため、流出したクッキーはすぐに期限切れになり、それらの攻撃者にとって無用になります。この設計により、大規模および小規模なウェブサイトは、既存のフロントエンドとの完全な互換性を維持しながら、バックエンドに専用の登録とリフレッシュエンドポイントを追加することにより、安全なハードウェアバウンドセッションにアップグレードできます。ブラウザはバックグラウンドで複雑な暗号処理とクッキーのローテーションを処理し、ウェブアプリケーションが以前と同じようにアクセスのための標準的なクッキーを使い続けることを可能にします。

Googleは昨年、このプロトコルの初期版をロールアウトしました。DBSCで保護されたセッションについて、私たちはその起動以来、セッション盗難の大幅な削減を観察しました。

ブラウザとサーバー間の相互作用を示すDBSCプロトコルの概要。

デザイン上のプライベート性

DBSCアーキテクチャの中核的な原則はユーザープライバシーの保護です。各セッションは異なるキーによって支援されており、ウェブサイトがこれらの認証情報を使用して、同じデバイス上の異なるセッションまたはサイト間でユーザーのアクティビティを相関させるのを防ぎます。さらに、プロトコルはリーンに設計されています。所持の証明を証明するために必要なセッションごとの公開鍵を超えて、デバイス識別子または証拠データをサーバーにリークしません。この最小限の情報交換は、DBSCがクロスサイトトラッキングを有効にしたり、デバイスフィンガープリント機構として機能したりせずにセッションを保護するのに役立つようにします。

エコシステムとの協力

DBSCは最初からW3Cプロセスを通じた開放的なウェブ標準であるように設計され、ウェブアプリケーションセキュリティワーキンググループによって採用されました。このプロセスを通じて、私たちはMicrosoftとパートナーシップを組んでウェブのために機能することを確認するための標準を設計し、ウェブセキュリティに責任を持つ業界の多くから意見を得ました。

さらに、過去1年間で、DBSCがより広いウェブコミュニティの要件を効果的に果たすことを確認するために、2つのオリジンテストを実施しました。Oktaを含む多くのウェブプラットフォームは、これらのテストと独自のテストに積極的に参加し、プロトコルが彼らの多様なニーズに効果的に対処することを確認するための不可欠なフィードバックを提供しました。

ウェブ開発者で、セッション盗難からユーザーを保護する方法を探している場合は、実装の詳細については開発者ガイドを参照してください。さらに、DBSCに関するすべての詳細は、仕様書と対応するgithubで見つけることができます。バグを報告したり、機能リクエストを提供したりするには、issuesページを自由に使用してください。

今後の改善

DBSC標準を進化させ続けるにつれて、今後の反復は、多様なエコシステム全体のサポートを増加させ、複雑なエンタープライズ環境向けに調整された高度な機能を導入することに焦点を当てます。継続的な開発の主要な領域は以下を含みます：

• フェデレーテッドアイデンティティの保護：現代のエンタープライズ環境では、シングルサインオン（SSO）は遍在しています。私たちはDBSCプロトコルを拡張してクロスオリジンバインディングをサポートし、依存当事者（RP）セッションが同じアイデンティティプロバイダー（IdP）で使用されている元のデバイスキーに継続的にバインドされたままであることを確認しています。これにより、初期デバイスバインディングの高い保証セキュリティがフェデレーテッドログインプロセス全体にわたって維持され、信頼の継続的なチェーンが作成されることが保証されます。
• 高度な登録機能：DBSCは確立されたクッキーに対して堅牢な保護を提供しますが、セッションが最初に作成されるときに、一部の環境はさらに強い基盤を必要とします。私たちは、サインイン時に新しい鍵を生成するのではなく、DBSCセッションを既存の信頼できるキーマテリアルにバインドするメカニズムを開発しています。この高度な機能により、ウェブサイトはmTLS証明書またはハードウェアセキュリティキーなどの補完的なテクノロジーを統合でき、高度に安全な登録環境を作成できます。
• より広範なデバイスサポート：また、専用のセキュアハードウェアを持たないデバイスへの保護を拡張するために、ソフトウェアベースのキーの追加の可能性を積極的に探索しています。