GoogleとMicrosoftの研究者が協力してリプレイ攻撃を阻止

Google と Microsoft のエンジニアは協力して、「リプレイ攻撃」と呼ばれるものに対する保護策を提案した。

これらは、攻撃者が被害者の OAuth トークンなどを盗み、それを使用して被害者になりすまして、保護されているリソースにアクセスするときに発生します。

トークン バインディング プロトコルは、ユーザー セキュリティを中心にインターネットを書き換えるという、インターネット技術タスク フォース (IETF) の長年にわたる取り組みの次の段階です。

昔と比べると、2018 年のユーザーのセキュリティはかなり強化されています。ユーザーがアクセスする Web サイトは HTTPS で保護され、ログインは OAuth で保護されるなどです。

しかし、最近公開された Request for Comments (FRC) 8471 によると、HTTPS および OAuth (およびその他のプロトコル) がユーザーのマシンに保存するトークンは、処理が必要なリプレイ攻撃ベクトルを提供します。

トークン バインディング プロトコル バージョン 1.0 の著者である、Microsoft の Andrei Popov 氏と Magnus Nystroem 氏、Google の Dirk Ba​​lfanz 氏、および W3C が招待した専門家の Jeff Hodges 氏が登場します。

RFCでは、HTTPSセキュリティクッキーやOAuthトークンなどをTLSレイヤーにバインドするプロトコルが概説されています。この暗号化レイヤーは、攻撃者によるトークンのエクスポートを防ぎ、リプレイ攻撃をブロックします。

トークンバインディングを確立するために、ユーザーエージェントは各「ターゲット」サーバーに対して秘密鍵と公開鍵のペアを生成します。つまり、クライアントが公開鍵を提示し、ハンドシェイクによって秘密鍵が確立されます。これは、そのサーバーへのTLS接続ごとに発生します。

RFC には次のように記されています。「バインドされたセキュリティ トークンを正常にエクスポートして再生するには、攻撃者はクライアントの秘密キーも使用できる必要があります。キーが特別に保護されている場合、これは困難です。」 – たとえば、キーがハードウェア モジュールで生成された場合などです。

著者らは、通常のTLSハンドシェイクにラウンドトリップを追加しないようプロトコルを設計しました。このプロトコルは、クライアントが非対称秘密鍵を所有していることを証明するために送信する単一のメッセージで構成されます。このメッセージで問題がなければ、サーバーはクライアントのメッセージに含まれるIDを使用してバインディングを作成します。

RFC では、トークンが TLS レイヤーにバインドされる方法はアプリケーションに固有であると述べられています。トークン バインディング ID またはその暗号化ハッシュは、セキュリティ トークンに埋め込まれるか、トークンをバインディング ID にマッピングするデータベースで維持される可能性があります。

RFCでは、ユーザーが依然として脆弱なシナリオが1つあると指摘されています。それは、バインドされたトークンがユーザーのマシン上のマルウェアにアクセスできる可能性があることです。鍵生成にハードウェアモジュール（セキュリティドングルなど）を使用するという提案は、この問題に対処するためのものでした。

RFC では、攻撃者がトークン バインディング ID を自分で選択した ID に切り替えると検出されないように、バインドされたトークンの整合性を保護する必要があるという推奨事項も示されています。

プロトコル RFC は他の 2 つの RFC によってサポートされています。

Popov、Nystroem、Balfanz は、トークン バインディング プロトコルを使用して TLS 拡張機能を定義する RFC 8472 に署名しました。また、RFC 8473 (Popov、Nystroem、Balfanz、Hodges、および Google の Nick Harper) では、このプロトコルを HTTP に適用する方法を説明しました。

トークン バインディングは TLS 1.2 の RFC 段階にしか達していませんが、このインターネット ドラフトでは TLS 1.3 が無視されていないことが示されています。®