TLS / SSLおよびリプレイ攻撃時のクライアント認証
SSL-Handshake 中にクライアント認証がどのように機能するかについて、この説明を見つけました。 Oracleによると、クライアント認証は次のように機能します。
- クライアントは自分の証明書、ランダムデータ、およびそのランダムデータの署名をサーバーに送信します。
- サーバーは、証明書の公開鍵を使用してランダムデータの署名を確認します。
- サーバーは証明書の有効期間をチェックします。
- サーバーは、証明書のCAが信頼できるCAかどうかを確認します。
- サーバーはCAの公開鍵を使用して、証明書の署名を検証します。
これらの5つのステップの後、ユーザーが認証されます。
質問：攻撃者がユーザー証明書、ランダムデータ、およびそのランダムデータの署名を取得した場合、攻撃者はリプレイ攻撃を開始できますか？
ランダムデータは、リプレイアタックを防ぐためにチェルランジュである必要があると思います。では、クライアント証明書を使用してユーザーを認証する一般的な方法は何ですか？
クライアント認証がどのように機能するかを完全に理解していなかったと思います。引用した記事では、クライアント認証は簡単な方法でしか説明されていません。この記事から引用するには：
SSLプロトコルでは、ハンドシェイク中にランダムに生成され、クライアントとサーバーだけが知っているデータから一方向ハッシュを作成して、クライアントがデジタル署名を作成する必要があります。
インポートの部分は、これらはクライアントによってのみ生成されるランダムデータではなく、ランダムデータのその部分はクライアントによって生成され、別のランダムデータはサーバーによって生成されるということです。または、より正確に言うと、クライアントはこれまでに送受信されたすべてのメッセージに証明書を使用して署名します。これらのメッセージには、クライアントによって生成された256ビットのランダムデータ、およびサーバーによって生成された別の256ビットのランダムデータも含まれます。詳細は RFC 5246（TLS 1.2）セクション7.4.8 を参照してください。
攻撃者がユーザー証明書、ランダムデータ、およびそのランダムデータの署名を取得した場合、攻撃者はリプレイ攻撃を開始できますか？
CertificateVerifyメッセージの署名はサーバーによって生成されたランダムデータにも依存するため、サーバーがハンドシェイクで以前ランダムにスニッフィングしたハンドシェイクと同じランダムデータをサーバーが使用する場合にのみ、リプレイアタックを実行できます。ただし、これが発生するのは、サーバーのランダムジェネレーターが 重大な破損 である場合、またはサーバーが前のハンドシェイクとまったく同じ256ビットの乱数を使用する確率がほとんどないため、攻撃者が非常に幸運である場合のみですゼロ。