攻撃者が利用者ID、PWを搾取したとしてもログインできないのはなぜか、といった趣旨の問いかと思いますが、厳密にいうと以下のどれがベスト回答でしょうか？
  ・クライアント証明書がないから
  ・クライアント証明書&それに対応する秘密鍵がないから
  ・クライアント証明書に対応する秘密鍵がないから


また、もう一つ質問となりますが、クライアント証明書に対応する秘密鍵はいつどのような用途で使われますでしょうか？
TLS通信開始までの一連の流れでサーバ側からクライアント認証求められた時は、クライアント証明書を送付すると思いますが、この時、クライアント証明書に対応する秘密鍵は何かしら使われているのでしょうか？

この投稿は投稿者により削除されました。(2020.10.12 12:57)

回答としては、クライアント証明書に対応する秘密鍵がないからで良いと思います。

クライアント証明書に対応する秘密鍵はいつどのような用途で使われるかですが、
サーバ側でクライアントの認証(クライアントの署名の検証)をする際にに使われます。
法人利用者の場合、クライアントは、証明書と一緒にHelloメッセージを署名したものを送信します。
そして、サーバが署名を検証することになります。

> 攻撃者が利用者ID、PWを搾取したとしてもログインできないのはなぜか、といった趣旨の問いかと思いますが、厳密にいうと以下のどれがベスト回答でしょうか？
私は「クライアント証明書&それに対応する秘密鍵がないから」が一番正確かと思います。

なぜなら、TLS通信でクライアント認証する場合は今回のクライアント証明書をサーバに送信することが必要ですが、クライアント証明書は利用者の保持する秘密鍵だけでは生成できないからです。
（クライアント証明書の作成にはクライアントが管理する鍵ペアと、認証局が証明書に付与するデジタル署名が不可欠なので、利用者の秘密鍵だけでは作れません。）

また、通常、サーバ証明書はオープンなものなので入手が用意ですが、クライアント証明書は相手先のサーバくらいにしか渡さないものなので、攻撃者は利用者からサーバへのアクセスを何かしらの手段で傍受するor自分に送信させるor利用者のPCから直接盗み出す等して窃取する必要があります。

> クライアント証明書に対応する秘密鍵はいつどのような用途で使われますでしょうか？
> TLS通信開始までの一連の流れでサーバ側からクライアント認証求められた時は、クライアント証明書を送付すると思いますが、この時、クライアント証明書に対応する秘密鍵は何かしら使われているのでしょうか？
TLS通信では本通信を暗号化するための共通鍵を交換する必要がありますが、これ自体は基本的にDiffie-Hellman (DH) の鍵交換技術を使って行われます。ただ、証明書の認証をする際には、この共通鍵を証明書に対応する秘密鍵で暗号化して渡します。相手は受け取った証明書の中に入っている公開鍵を使って暗号化された共通鍵を復号することで、相手が証明書の公開鍵に対応する秘密鍵の保持者であることを検証する事ができます。

この辺は、「SEの道標」さんのところの下記のページがわかりやすいかと思います。URLは載せられないのでタイトルで検索してみてください
【図解】よく分かるデジタル証明書(SSL証明書)の仕組み 〜https通信フロー,発行手順,CSR,自己署名(オレオレ)証明書,ルート証明書,中間証明書の必要性や扱いについて〜

クライアントの証明書はTLSハンドシェイクが確立される前に送信されるため証明書自体を攻撃者が入手することは可能ですが、対応する秘密鍵はクライアントの端末内にしか存在しないため攻撃者は入手できません。そのため攻撃者が正しい署名を作成できないのでなりすましを防ぐことができます。

クライアントの証明書及びそれに対応する秘密鍵の用途については、鍵交換とは別でクライアントが正規の利用者かを検証するためだけに使用されます。

この投稿は投稿者により削除されました。(2020.10.12 16:28)

この投稿は投稿者により削除されました。(2020.10.12 16:53)

この投稿は投稿者により削除されました。(2020.10.12 17:04)

> この共通鍵を証明書に対応する秘密鍵で暗号化して渡します
すいません、これ間違いです。
暗号化するのは共通鍵そのものではなく、共通鍵の元になるPreMasterSecretという値です。
ただ、この辺りもちょっと私の理解が不十分なので、いったん、上記の私の話は忘れてください。

クライアント証明書の秘密鍵の利用はTLSのCertificateVerifyで送信するデジタル署名の話になるかと思いますが、私の理解が結構怪しいので、詳細は他の方か別の解説サイトにお任せしたいと思います。むしろ、私も詳しく教えていただけると助かりますので、是非、よろしくお願いします

> 勉強中さん、グルタミンさん
PreMasterSecretを暗号化するのは鍵交換にRSA方式を指定した場合です。
鍵交換にDH方式を指定した場合はDHの公開パラメータをそのまま渡します。
なお、RSA方式による鍵交換はTLS1.3で削除されました。
参考サイト：https://www.ipa.go.jp/security/rfc/RFC5246-07JA.html#0747

クライアント証明書の検証はCertificateVerifyのやりとりで行います。
概要としては、今まで送受信したメッセージを連結させたデータのハッシュ値をとり、そのハッシュ値をクライアント証明書に紐づく秘密鍵で署名し、そのデジタル署名を相手に送信します。
今まで送受信したメッセージはサーバも知っているので、サーバ側は自分でハッシュ値を計算し、クライアント証明書に含まれる公開鍵を使ってCertificateVerifyで送られたデジタル署名を復号し、自分で計算したハッシュ値と一致しているかを検証することで相手が本人であることを認証します。
参考サイト：https://www.ipa.go.jp/security/rfc/RFC5246-07JA.html#0748

> AAAさん
> クライアントの証明書はTLSハンドシェイクが確立される前に送信されるため証明書自体を攻撃者が入手することは可能ですが、
狙ったクライアントの証明書を入手するためには、その利用者に攻撃者のサイトにアクセスしてもらう等の必要があるので、偶然以外だと何かしらの攻撃（標準型メール等）が成功しないと難しい気がするのですが、何か他に簡単に入手する方法があるのでしょうか？

> 狙ったクライアントの証明書を入手するためには、その利用者に攻撃者のサイトにアクセスしてもらう等の必要があるので、偶然以外だと何かしらの攻撃（標準型メール等）が成功しないと難しい気がするのですが、何か他に簡単に入手する方法があるのでしょうか？

マルウェアJはログイン画面の改ざんができるとのことだったので、通信の内容を見たりすることは簡単だと思ったのですが、違ってたらすみません。

> マルウェアJはログイン画面の改ざんができるとのことだったので、通信の内容を見たりすることは簡単だと思ったのですが、違ってたらすみません。
なるほど、マルウェアJの機能を失念していました。
マルウェアJは偽サイトへの誘導はしないというところを見て、マルウェアJの機能では無理と判断してしまいましたが、よくよく考えると認証情報を盗むということは何かしら攻撃者と通信できる機能があるということですよね。普通に考えればわかりそうなものですが、すっかり抜け落ちていました。

回答ありがとうございます。