公開鍵認証における第三者介入の可能性について

質問

公開鍵認証、例えばSSHによるアクセスにおける「クライアント（ユーザ）認証」のやり取りについて、中間者攻撃やなりすましの可能性、及びそれに対する防御がどう考慮されているのかがわからず、質問させていただきます。

まず、チャレンジ・レスポンス方式によるクライアント認証は、以下のような流れだと認識しています。

(1)サーバ側が、公開鍵（あらかじめユーザが配置したauthorized_keys）を用いて認証用のランダムデータを暗号化し、クライアント側に送る（チャレンジ）。
※ここで第三者がデータを盗っても、正しいユーザ以外は対応する秘密鍵を持ってないのでどうすることもできない

(2)クライアント側は、公開鍵に対応する秘密鍵によってデータを復号し、サーバへ送り返す（レスポンス）。
※これは安全なのでしょうか…？（疑問点として詳細後述）

(3)サーバ側では、クライアントから送られてきた復号済みデータと、元データと比較し、
合っていれば正しいクライアント（ユーザ）であると認証できる。

ここで、何か大きな思い違いをしているのかもしれませんが、
以下の疑問が生じています。
--------------------------------------
◆疑問点1
(2)において、復号済みデータ自体がネット回線上に流れた際に、それが盗まれる可能性は存在すると思います。
第三者による不正な認証に使われてしまったりしないのでしょうか？
もしかして、先に正しいクライアントが認証されれば、同じ復号済みデータは二度と使えなくなるから安全、とか…？
でも、正しいクライアントが認証される前に悪意ある第三者が認証されてしまう可能性はないのでしょうか？（疑問点2に繋がります。

◆疑問点2
(2)において、悪意ある第三者が介入し、サーバ側には届かないように復号済みデータを横取りし、あたかも自身が復号したデータであるかのようにそのままサーバへ送り、認証自体を横取りしてしまう（第三者が正しいクライアントとして認証されてしまう）ことはありうるのでしょうか？
（→中間者攻撃：man-in-the-middle attack？なりすまし？）
--------------------------------------

上記、2つの疑問点についてご教授いただきたいです。

公開鍵、秘密鍵の性質は理解しているつもりなのですが、
データの暗号化・復号化自体をそれぞれの正しいクライアント・サーバにやらせつつ
第三者がやり取りの中間に立つようなことが可能なのであれば、
認証自体が第三者に横取りされ、そこでアクセスが確立しまうのではないかと思った次第です。
（この方法がおそらく無理だからこそ、公開鍵認証が安全なセキュリティ技術として普及しているのだと思いますが、何故無理なのかがわからず…。）

お手数ですがどうぞよろしくお願いいたします。

回答No.12

Lchan0211b · ベストアンサー

No.3,6,7です。

回答が遅くなりましたが、まず1点訂正させてください。
No.3回答で、クライアント認証が完了したら
共通鍵を生成して、以後全てのデータ通信は
共通鍵で暗号化してデータ送受信すると書きましたが、
共通鍵で暗号化を開始するのは、クライアント認証後ではなく
クライアント認証の前のサーバー認証完了時点からでした。

つまりクライアント認証を行う時点では、既に通信路は
共通鍵で暗号化された状態になっています。
このため「(2)のレスポンスデータは暗号化しない生データが送られる」
と書きましたが、実際には共通鍵で暗号化した状態で送られます。
また(1)のチャレンジデータも実際のところはクライアントの公開鍵
で暗号化したものをさらに共通鍵で暗号化した状態で送られます。

http://www.omoikane.co.jp/man30/w_ssh.html
の図がサーバ認証(=ホスト認証)、クライアント認証(=ユーザ認証)
合わせた全体で解説されており、わかりやすいと思います。

これを踏まえて回答します。

> ◆サーバ認証
> サーバ側の公開鍵Sを、クライアント側のknown_hosts情報と照らし合わせるもの
>
> [X]⇔[サーバ]
> サーバが公開鍵Sを送ってくる。悪意あるXは特に検証もする必要なくOKを返せば、この関係上でのサーバ認証は完了
>
> [クライアント]⇔[X]
> Xは、サーバから送られてきた公開鍵Sを、クライアントに送る。クライアントのknown_hostsに公開鍵Sが保管されているとすると、比較検証によって一致する。（known_hostsに保管されていない場合でも、ユーザがyesと入力、つまり許可すれば新たに保管され、通る。）
> よって認証OKと見なされ、この関係上でのサーバ認証も完了。

今回紹介したURLの解説図にある通り、クライアントは公開鍵Sを受け取った後、サーバに対して
チャレンジレスポンスのやりとりを行います。あなたが想定している攻撃者[X]は、
おそらくこのデータも素通りさせて、サーバー認証を完了させるのだと思いますが、
その後、クライアントはデータ通信用の共通鍵を生成し、公開鍵Sで暗号化し
サーバに送付します。以後、全てのデータ送受信はこの共通鍵で暗号化して通信します。
このため、これ以降(クライアント認証含め)攻撃者[X]は、データの中身を見ることも
改ざんすることもできません。

それなら、サーバ認証のチャレンジレスポンス時にレスポンスデータは
生データが流れるので、その時点で横取りすればよいとお考えかもしれません。
その場合、あなたの想定する中間者攻撃は以下のようになりますよね。
--------------------------------------------------
[クライアント]→[X]
クライアントは公開鍵Sを用いてチャレンジデータを生成、Xに送る。
Xはこれをサーバーに投げる

[X]→[サーバ]
Xからチャレンジを受け取ったサーバは、正しい秘密鍵Sを持っているため、正しいレスポンスをXに返す。
悪意あるXが、サーバ側とやり取りしたいならば、Xはレスポンスを検証する必要もなく認証をOKとすれば、サーバとXの間でSSH通信が開始される。
一方、Xがクライアント側に用があるならサーバは用済みなのでレスポンスエラーなどを返して切断する。

[X]→[クライアント]
> クライアントとやり取りしたい場合のXは、上の過程で正しいレスポンスを手に入れているため、それをクライアントに返す。クライアントはXを正しいサーバと認めるため、Xとクライアントの間でSSH通信が開始される。
--------------------------------------------------

この中で[X]→[クライアント]の
「クライアントはXを正しいサーバと認めるため、Xとクライアントの間でSSH通信が開始される。」
というのが認識不足なのだと思います。
この処理は具体的には
1.クライアントがデータ通信用の共通鍵を生成
2.公開鍵Sで暗号化してサーバに送付
3.サーバが秘密鍵Sで復号化し、共通鍵を取得
4.以後、全てのデータ送受信はこの共通鍵で暗号化して通信
ということです。
今回の場合、サーバの代わりにXが公開鍵Sで暗号化した共通鍵を受け取るのだと
思いますが、Xは秘密鍵Sを持っていないので、共通鍵を取りだせないのです。
したがって、Xはそのデータを破棄するかそのままサーバに伝えるかしかできず、
サーバに伝えればサーバとクライアントの間でSSH通信が開始されるということに
なります。

もう一方の[X]→[サーバ]の
「Xはレスポンスを検証する必要もなく認証をOKとすれば、サーバとXの間でSSH通信が開始される。」
という部分は、上述の手順でクライアントがデータ通信用の共通鍵を生成して
サーバに送付しない限りデータ通信開始できません。Xがそれをクライアントに促すには、
Xからクライアントに正しいレスポンスを送信するしかなく、その後は上述の通りです。
結局、その後のやりとりはクライアントとサーバの間で共通鍵で暗号化してやりとりするため、
攻撃者Xは何もできないということです。

納得いただけましたでしょうか?

お礼

明快なご回答、まことにありがとうございます。
共通鍵を用いる流れと、介入した第三者が共通鍵を得られないがためにその後何もできなくなるというお話で、おかげさまで納得・理解ができました。
論理立ったご説明をいただき、感謝いたします。

回答No.1

foomufoomu

公開鍵方式の鍵の意味ですが、

公開鍵：普通の文書を暗号文にするのに使う鍵
秘密鍵：暗号文を普通の文書にもどすのに使う鍵

秘密鍵と公開鍵は、もちろん、ふか～い関係がありますが、
秘密鍵から公開鍵を作るのは簡単ですが、公開鍵から秘密鍵を作るには何億年もコンピュータを動かさないとできない、という性質を持っています。

でもって、（2）は間違っています。正しくは、
クライアント側は、公開鍵によってデータを復号し、サーバへ送り返す（レスポンス）。
です。

普通の文書を暗号に変換するのに秘密鍵は必要ありません。秘密鍵は一切公開することはないので、第3者は暗号を横取りしても普通の文書に戻すことはできません。