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

質問

公開鍵認証、例えば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.11

foomufoomu

＞「どこから送られてきたかは関係ない」ままに、
＞「正しい秘密鍵を持っていて、暗号を正しく解読できる人」を
＞ 知ることができるのでしょうか？

これを理解してなかったのですね。

(1)サーバーは、データＣをクライアントが作った公開鍵Ｂで暗号化し、クライアントに送る。
(2)クライアントは、送られたデータＣをクライアントが作った秘密鍵Ｂで復号し、それに加えて、自分の署名、送りたい文書を書き、クライアントが作った公開鍵Ａで暗号化して、サーバーに送る。
(3)サーバーは、送られたデータを秘密鍵Ａで復号し、データＣの部分を最初に送ったデータと照合し、送信者が間違いなく秘密鍵Ｂをもつクライアントであることを確認する。

もっとも、データＣを、最初に何らかの安全な方法(直接手渡しなど、第3者に知られず、第3社がなりすましでない方法)でクライアントとの間で取決めしてあれば、あとは、クライアントからの送信に毎回データＣを署名のように加えるだけでよいのです。

それから、パケット情報は暗号化されてないので、この目的には使えません。それが「どこから送られたは関係ない」の意味です。

補足

>＞「どこから送られてきたかは関係ない」ままに、
>＞「正しい秘密鍵を持っていて、暗号を正しく解読できる人」を
>＞ 知ることができるのでしょうか？
>これを理解してなかったのですね。

繰り返しになってしまいますが、「正しい秘密鍵を持っていて、暗号を正しく解読できる人」であることの証明は、「正しいレスポンスを送り返すこと」でしか得られないと思っています。つまり、サーバにとっては、正しいレスポンスを送り返してきたクライアントが正しいクライアントとなります。
パケット情報はこれを証明する目的には即さないのですね。であればなおさら、「どこから送られてきたかは関係」あると思えます。

私が書いた例で見れば、サーバにとって、正しいレスポンスを送り返してきたクライアントはXです。なので、Xが認証されてしまうのではないですか？と質問しているわけです。

確かに、公開鍵・秘密鍵をお互いに用いたやり取りにおいて、秘密鍵を持たない第三者はその内容を読み取ることは不可能であり、やり取りはセキュアでしょう。
しかしながら、こと、そのセッション確立前の「認証」というフェーズにおいては（チャレンジに対する「レスポンスの検証」が秘密鍵を持つ証明となる段階においては）、例示した通り、暗号を読み取らずとも認証が通ってしまうという、中間者攻撃の隙があるのではないでしょうか？と言っているわけです。

なお、私もまた別の方法なりでこの疑問点の解消を試みてみます。。
ご協力いただいたところ恐縮ですが、解決してもしなくても、適当なところで回答は締め切らせていただきたいと思います。

回答No.10

foomufoomu

第3者には解読できない暗号文書で、しかも逆方向の暗号通信で送り主の身元も保障できるのに、それを中間で盗まれるのが不都合、というなら、インターネット、無線通信、郵便での情報のやり取りをやめて、直接手渡しするしかありません。

暗号にする目的、わかってますか？

補足

>第3者には解読できない暗号文書で、しかも逆方向の暗号通信で送り主の身元も保障できるのに、
>それを中間で盗まれるのが不都合、というなら、

えーと、「中間で盗まれるのが不都合」どうこうと言っているわけではなく。。

最初の私の質問では、「第三者介入によって不正に認証が通ってしまうことはないのですか？」とお聞きしており、それに対して「そのようなことはない」と回答いただいていると認識しています。
「そのようなことはない」理由が納得しきれなかったもので、「ではこのようなフローはあり得ないでしょうか？」と、No.7の方への補足にて具体例を書かせていただいたわけです。

仰るように、「第3者には解読できない暗号文書で、しかも逆方向の暗号通信で送り主の身元も保障できる」ならば、
では私が書いたフローのような中間者攻撃による不正認証が起こり得ない理由、その間違っているところを論理的に是非ご指摘いただきたく、まさにそこが私の知りたいところです。

「こことそこでこのような情報不整合により認証が失敗するからこのフローはあり得ず、またそれが公開鍵認証においては中間者攻撃に対する防御の仕組みになっている」というような回答を期待しているわけです。
（とはいえそのフローにはSSH実装に依存した工程が含まれてしまっているかもしれず、公開鍵認証という概念の中のみで説明がつくものなのかはわからないため、もしご専門領域を逸脱しているようであれば回答いただかなくても問題ありません。）

回答No.9

foomufoomu

No.7の方への補足を見ました。
＞サーバはXを正しいクライアントと認めるため、Xとサーバの間でSSH通信が開始される。
暗号化せずに送ったデータが、第3者に盗まれるのは当然のことです。これはサーバー、クライアントの認証とは関係ありません。
あなたがNo.7のかたの補足に書いたのは、要約すると、そういうことです。

盗まれては困るデータは、つねに暗号化して送らなければなりません。

また、データの送信者の身元が怪しい（なりすまし）と思ったら、最初の認証と同じ要領で、正しく解読されたチャレンジデータを毎回添えて送ってもらう必要があるでしょう。

つまり、正しい秘密鍵を持っていて、暗号を正しく解読できる人だけを信用する。それがどこから送られてきたかは関係ない。　ということです。

補足

度々お言葉を返してしまい恐縮なのですが、
未だ納得をしかねるため、返答させていただきます。

>暗号化せずに送ったデータが、第3者に盗まれるのは当然のことです。
>これはサーバー、クライアントの認証とは関係ありません。
>あなたがNo.7のかたの補足に書いたのは、要約すると、そういうことです。
>盗まれては困るデータは、つねに暗号化して送らなければなりません。

書いたフローを見ていただくとお分かりかと思いますが、第三者Xは、暗号化・復号化をそれぞれのクライアント・サーバにやらせて、認証を得ています。つまり、暗号化しようがしまいが、双方の相手方になりすましているXは、暗号解読をそれぞれのクライアント・サーバにやらせてしまうので意味がありません。
「盗まれては困るデータ」には違いないですが、「暗号化して送ればOK」で解決するフローではないはずです。

またクライアント認証の部分を見ていただければわかるように、あくまで、公開鍵秘密鍵によるチャレンジレスポンス方式（クライアント認証）の際に、
第三者Xが間に入ることにより認証が通ってしまう…と思われるやり方を書いています。「認証」というフローの中で例示しているため、当然ながら「サーバー、クライアントの認証とは関係」あります。

「暗号化せずに送ったデータが、第3者に盗まれるのは当然のこと」だと私も思いますが、その事実そのものは、私の書いた補足では特に重要ではありません。

>また、データの送信者の身元が怪しい（なりすまし）と思ったら、

怪しい（なりすまし）と思うことさえできればもちろん対策を講じようと動けますが、一般的なケースとして、本人が気付いていない状態でおこなわれることを想定しています。

>つまり、正しい秘密鍵を持っていて、暗号を正しく解読できる人だけを信用する。
>それがどこから送られてきたかは関係ない。　ということです。

「どこから送られてきたかは関係ない」ままに、「正しい秘密鍵を持っていて、暗号を正しく解読できる人」を知ることができるのでしょうか？前に書いていただいた「パケットに含まれる送信者情報」を読み取るということでしょうか？
だとすると、レスポンスを受け取ったサーバは、レスポンスの検証と同時に、パケットに含まれる送信者情報を読み取り、検証が正しければその送信者情報に記されているクライアントを認証する、という理解でよろしいでしょうか？（そうなると、判断に際する送信者情報への依存がウィークポイントとなり、送信者情報を偽装された場合を考える必要も出てきそうですが…。）

おかげさまで、いろいろとご指摘いただくことで疑問点を深掘りするきっかけをいただいているのですが、納得がいくまでこのままやり取りを続けても申し訳ないので、どこかきりの良いところで締め切らせていただくことも考えています。。

回答No.8

foomufoomu

前の回答と同じことですが、
>サーバ側としては、その正しいレスポンスを送ってきた第三者を
>正しいユーザとして認証してしまうのではないか、という疑問です。
それは不可能です。
インターネットにおいて、「送信者がだれか」は、パケットに添付されている送信者情報によって識別されます。途中の中継者の情報も付け足されますが、最初の送信者がだれなのかは残っています。
ここで(2)を暗号化せずに送ったばあい、中間に第3社が（パケットの情報を含めて）送信者情報を偽装することができるので、正規のクライアントでない、別の人が送ったように見せかけることは可能です。

が、それが何の役に立つのでしょう？
その場合、サーバーは、送った情報が正規のクライアントに届かず、別に人の届いたと思い、最終的に通信をやめるだけです。通信を妨害することにはなりますが、それ以上のメリットはないでしょう。

(2)を暗号化して送った場合は、暗号文書内の送信者情報を偽装することができないので、被害が出る可能性は皆無です。

前の回答にもありますが、インターネットは多くの人を中継して送られるものなので、中間の人が内容も知らずに受け渡しをするのは、当たり前に行われていることです。

補足

度々ご返答いただきありがとうございます。
お手数おかけしましておそれいります。
No.7の方への補足において、私の認識している中間者攻撃のフローを書かせていただきました。
SSHの具体的な実装についてはご存知ないとのことなので、うまく伝わるかはわからないのですが…

どこまでの偽装が現実的に有り得るのかわからないのですが、クライアントと第三者X、もしくはXとサーバの間で、パケットに添付されている送信者情報の整合性を保つことはできないのでしょうか。だとすれば確かに、パケットに含まれる送信者情報が、中間者攻撃を防ぐ肝になるのだと思います。

回答No.7

Lchan0211b

No.3,6です。

> 「(2)のデータの正しい値を生成できる人」であることの証明は、
> 「(2)のデータを送信」することでしか得られないと思っているのですが、この時点で間違っているでしょうか？

それはそうですが、そのデータを第三者に中継されても別にかまいません。
というか、第三者に中継してもらうのが普通です。
普通、ネットワークと言うのは、第三者が何も改ざんせずバケツリレーでデータを中継します。
自宅のPCからgoogleにアクセスする時、必ず「プロバイダ」という第三者を中継しますし、
プロバイダからgoogleにパケットを届けるまでの間もあなたの知らないたくさんの
第三者のルーターが中継します。どのルーターもルーター管理者なら転送データを
覗き見たりその内容を改ざんすることが簡単にできます。
そのルーターによる中継を中間者攻撃と言ったら、全て中間者攻撃だらけです。

「ルーターは送信元IPアドレスを変更しないけど、中間者攻撃は送信元IPが変わる」
という反論があるなら、それは違います。送信元IPアドレスを変更するNATルーターも
たくさんあります。
だから、そもそも認証用のデータとして送信元IPアドレスは使われません。
つまり、認証するのに「誰が送ったデータか」なんてそもそも見てないのです。
誰が送ったか(誰が中継したか)なんてどうでもよくて、公開鍵で暗号化した
データを正しく復元できる人と通信しているかどうかを確認しているということです。

> つまり、サーバ側から見ると、正しい値をとあるユーザ（実は第三者）が返してきた、という事実しかなく、
> 本当は別の正しいユーザがレスポンス値を生成した、ということまで見抜けないのではないかと思うのです。
> （逆に見抜けるとしたら何故でしょうか？）

正しい値が返ってきたなら、誰を中継して送信したものかはわかりませんが、
クライアントの秘密鍵を持っている正しいユーザと通信していると言えます。
秘密鍵を知らない第三者が勝手に正しいレスポンス値を生成することはできないからです。

> 中間者攻撃というものを誤解しているのかもしれませんが、
> しかしどうにも、チャレンジ・レスポンス方式では正しい答えを奪われる＝認証を乗っ取られる可能性があるのではないかと思ってしまいます。

(2)のレスポンスデータを第三者が知ったからと言って、何も認証を乗っ取られていません。
「認証を乗っ取る」と言うなら、本来のクライアントの秘密鍵を盗みとったり
第三者の公開鍵を本来のクライアントの公開鍵と勘違いさせるようなことができない限り、
第三者は何もできません。
(2)のレスポンスデータを知ることでそれができるなら、その方法を示してみてください。
あるいは別の方法で本来のクライアントの秘密データを盗み見たり情報を勝手に変更したり
する方法を示してください。
それができれば中間者攻撃成立と言えます。

補足

度々ご返答いただきありがとうございます。
おかげさまで徐々に疑問解消に向かっていると思うのですが…
未だ考えのモヤモヤが晴れず、大変お手数おかけしますが、よろしければもう少しだけお付き合いいただければ幸いです。

>それはそうですが、そのデータを第三者に中継されても別にかまいません。
>というか、第三者に中継してもらうのが普通です。

第三者を通るのがルーティングであり通常のネットワークである、という旨は理解しました。ただ、中継という言葉の使い方が適切でなかったかもしれないのですが、私が考えている「中間者攻撃」とは以下のようなものです。

[クライアント]⇔[X]⇔[サーバ]

クライアントから見れば第三者であるXはサーバとして振る舞い、サーバから見ればXはクライアントとして振る舞います。Xは双方の相手方になりすましているという想定です。
これはネット上のルーティングや中継とは異なり、このような攻撃的な介入手段があるのだと認識しています。
参考）http://www.net.c.dendai.ac.jp/~daniel/#A2_2

この状態、つまり中間者攻撃が入った場合における、SSHの認証手順（私が有り得るのではないかと思うもの）を初めから以下に示してみます。根本的な勘違いが見られる場合はお手数ですがご指摘いただきたく存じます。
※以後、クライアントが用意した秘密鍵及び公開鍵をそれぞれ秘密鍵C公開鍵C(ClientのC)、サーバが用意した秘密鍵及び公開鍵をそれぞれ秘密鍵S公開鍵S(ServerのS)とします。
------------------------------------
◆接続開始
クライアントは、サーバにSSH接続しようとしますが、実際はXが接続要求を受けるとします。またそこで、Xは本来ユーザが接続したかった正しいサーバに接続を試みます。
[クライアント]⇔[X]、及び、[X]⇔[サーバ]においてプロトコル確認等の前提をクリアすると（"認証"ではないためクリアは容易と考えます）、サーバ認証に移ります。

◆サーバ認証
サーバ側の公開鍵Sを、クライアント側のknown_hosts情報と照らし合わせるもの

[X]⇔[サーバ]
サーバが公開鍵Sを送ってくる。悪意あるXは特に検証もする必要なくOKを返せば、この関係上でのサーバ認証は完了

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

次にクライアント認証です。

◆クライアント認証
[X]⇔[サーバ]
サーバは公開鍵Cを用いてチャレンジデータを生成、Xに送る。
Xはこれをクライアントに投げる（以下）

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

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

せっかく仰っていただいているご回答をちゃんと理解できていないのかもしれず恐縮ですが、未だに上記のようなことが可能なのではないかと思ってしまっています。
いろんなサイトで調べると、中間者攻撃という手法は確かにあるようなのです。
ただ、私の考えのようなことが起こり得ないとしたら、上記の流れで間違っている（事実上不可能である）のはどの部分なのでしょうか。。

回答No.6

Lchan0211b

No.3です。

そもそも、SSHの秘密鍵・公開鍵ペアを使ったユーザ認証方式では、
(2)のデータは、暗号化しないままの生データが送られます。

別にその(2)のデータを第三者に奪い取って使われたって何の問題もありません。

(2)のデータを奪い取った第三者は、本当のクライアントが返した
データを返す代わりにどうするのですか?

違うデータを返したら、サーバーはチャレンジに対するレスポンスが
違うため認証を失敗するだけです。

第三者が同じデータを返したら、サーバーは認証成功します。
でも、それって第三者が何もしてないのと一緒じゃないですか。

サーバーは、(2)のデータを送信した人を正しいクライアントと
認識しているのではなく、(2)のデータの正しい値を生成できる人を
正しいクライアントと認識しているということです。
(2)のデータの正しい値は、クライアントの秘密鍵を持っていないと
生成(復号化)できませんから、サーバーはクライアントの秘密鍵を
持っている人を正しいクライアントと認識したということです。

補足

>そもそも、SSHの秘密鍵・公開鍵ペアを使ったユーザ認証方式では、
>(2)のデータは、暗号化しないままの生データが送られます。

なるほどです。SSHの場合、仰っていただいたように私が質問にて書いたフローが正しく、認証時のレスポンス(2)は暗号化されないのですね。

>サーバーは、(2)のデータを送信した人を正しいクライアントと
>認識しているのではなく、(2)のデータの正しい値を生成できる人を
>正しいクライアントと認識しているということです。

「(2)のデータの正しい値を生成できる人」であることの証明は、
「(2)のデータを送信」することでしか得られないと思っているのですが、この時点で間違っているでしょうか？
つまり、サーバ側から見ると、正しい値をとあるユーザ（実は第三者）が返してきた、という事実しかなく、
本当は別の正しいユーザがレスポンス値を生成した、ということまで見抜けないのではないかと思うのです。
（逆に見抜けるとしたら何故でしょうか？）

確かに第三者は何もしておらず、しいて言うなら、ユーザのレスポンスをそのままバケツリレーしているに過ぎません。
しかしこのバケツリレー、つまり、第三者が中継することで、
サーバ側からすれば、正しい値を送ってきたのは第三者のように見えるのではないでしょうか。

ややこしい質問ですみません。。
中間者攻撃というものを誤解しているのかもしれませんが、
しかしどうにも、チャレンジ・レスポンス方式では正しい答えを奪われる＝認証を乗っ取られる可能性があるのではないかと思ってしまいます。

回答No.5

foomufoomu

>これによって第三者介入を防ぐことができるメカニズムとは
>どのようなものでしょうか。
最初に(1)で送り出した文書を正しく復元できるのは、秘密鍵Bをもっている正しいクライアントだけです。
なので、この復元された文書とクライアントの署名を並べて公開鍵Aで暗号化することができるのは正しいクライアントだけです。

仮に第3者が横取りしたとしても、公開鍵Aで暗号化された文書が手に入るだけ(復元は不可能)なので、意味も分からず中継するだけに終わります。

補足

>最初に(1)で送り出した文書を正しく復元できるのは、秘密鍵Bをもっている正しいクライアントだけです。
>なので、この復元された文書とクライアントの署名を並べて公開鍵Aで暗号化することができるのは正しいクライアントだけです。

秘密鍵Bで復元し公開鍵Aで暗号化する、つまり正しいレスポンスを生成できるのは正しいクライアントのみ、ということは理解できます。
ただ疑問に思っているのはそのレスポンスを送信する際のことです。

>仮に第3者が横取りしたとしても、公開鍵Aで暗号化された文書が手に入るだけ(復元は不可能)なので、意味も分からず中継するだけに終わります。

「公開鍵Aで暗号化された文書が手に入るだけ（復元は不可能）」ではあるものの、この文書は認証における正しい答え（レスポンス）ですよね。
つまり、第三者は自身で復元する必要はなく、意味をわかる必要もなく、あたかも自身のレスポンスとしてそのままサーバへ送るだけで、
サーバ側としては、その正しいレスポンスを送ってきた第三者を正しいユーザとして認証してしまうのではないか、という疑問です。

回答No.4

foomufoomu

>第三者がサーバにレスポンスを返す。
これを防ぐには、(2)で、正しいクライアントがサーバーからの文書を送り返すとき、文書の最後にクライアントの署名（メールアドレス等）を加えればよいのではないでしょうか。

前に少し書いた、公開鍵B,公開鍵Aで2重に暗号化する方法では、この点についても解決するらしいのですが(鍵が署名の代わりになる)、どうするのだったか覚えていません。

それから、私は、現実のSSHがどのようにしているのかは知りませんので、あしからず。

お礼

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

>文書の最後にクライアントの署名（メールアドレス等）を加えればよいのではないでしょうか。
これによって第三者介入を防ぐことができるメカニズムとはどのようなものでしょうか。サーバ側で、クライアント署名が正しいかどうか比較検証する仕組みがあるとしても、第三者が中継していることには気付けないように思います。

なお具体的なSSHの実装については承知しました。
諸々お答えいただきありがとうございました。

回答No.3

Lchan0211b

あなたが質問に書いている手順は、
http://www.unixuser.org/~euske/doc/openssh/book/chap3.html#what-is-pubkey-authentication
に解説されている、秘密鍵・公開鍵ペアを使ったSSHのユーザ認証方式であり、その手順通りで間違いありません。

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

第三者が(2)のデータを盗み見ることは可能です。
しかし、そのデータはあなたが書かれた手順の(1)に書かれている通り「ランダムデータ」です。
チャレンジのたびに変わりますので、再利用されることはありません。

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

第三者に(2)のデータを見られたって、何の問題もありません。

この後、サーバーはクライアントの認証ができたので、
データ通信を暗号化するための共通鍵を生成し、それをクライアントの
公開鍵で暗号化してクライアントに送信します。
それを受け取ったクライアントは、自分の秘密鍵で復号化して
共通鍵を受け取ります。
以後、全てのデータ通信はその共通鍵で暗号化した状態で
送受信されます。

第三者は(2)のデータを知っていますが、何の意味もありません。
クライアントの秘密鍵がわからないと、サーバーから送付された
共通鍵はわかりませんし、共通鍵がわからないと、以後送受信される
データの内容はわかりませんし、改ざんもできません。

逆の立場で、クライアントが正しいサーバーに接続していることを保証する
という観点もありますので、実際にはホスト認証とあわせて実施します。

お礼

ご回答いただきありがとうございます。
認証が通ったあとは共通鍵でやり取りされるというご説明、とてもわかりやすいです。

ただ、やはり私の根本的な思い違いがあるのか、質問に書いた疑問点は未だ解決できていないため、上の補足に改めて書かせていただきます。

補足

>チャレンジのたびに変わりますので、再利用されることはありません。

書いていただいた通り、(2)のレスポンスデータが「チャレンジのたびに変わる」ということは、もちろん次回以降のチャレンジで再利用は不可能だと思いますが、「その時点でのチャレンジ」では当然ながら有効ですよね。
つまり、そのレスポンスを第三者が奪い取り、正しいユーザの変わりにサーバへ送れば、その第三者が認証されてしまうのではないか、ということです。
「盗み見られる」ではなく、「その時点で奪い取って使われる」可能性についてです。
例えば以下のような流れです。

(2)-1
[クライアント]→→→
サーバにレスポンス(公開鍵Aで暗号化したもの)を送る（送ったつもり）

(2)-2
[クライアント]→→→[第三者]
だが第三者が介入してそれを受信する

(2)-3
[クライアント]　　　[第三者]→→→[サーバ]
第三者が、正しいクライアントの代わりにサーバにレスポンスを送る。
サーバが復号&比較すると正しいため、第三者を正しいクライアントだと認識してしまう

第三者が認証されてしまったら、その後のセキュアなはずの共通鍵交換も、第三者とサーバの間でおこなわれてしまいますよね。

ただこれは、ユーザのレスポンスが正しいサーバに届かない（第三者が用意した偽サーバに届く）ことを想定したものとなります。
いわゆる中間者攻撃と呼ばれるものだと思っているのですが、こういったケースはあり得るのか、あり得ないとしたら何故か、あり得るとしたらどう考慮されているのか、が知りたい次第です。
何か前提を履き違えていたら申し訳ございません。。

回答No.2

foomufoomu

あ、すみません、　サーバーがクライアントを認証する方法ですね。

これは、双方がサーバーになる必要があります。サーバーが作った秘密鍵A、公開鍵Aの他に、あらかじめ、クライアントも秘密鍵B、公開鍵Bを用意しておきます。

(1)サーバーは、ある文書(ランダムデータ)を公開鍵Bで暗号化し、クライアントに送る
(2)クライアントは、送られてきた暗号を秘密鍵Bで普通文書にして、公開鍵Aで暗号化し、サーバーに送り返す。
(3)サーバーは暗号を秘密鍵Aで普通文書にし、最初に送った文書と比較する。

で、良いんじゃないでしょうか。ものの本には、公開鍵Aで暗号化し、さらに公開鍵Bで2重に暗号化する方法も載っていますが。

お礼

ご回答いただきありがとうございます。
なるほどです、秘密鍵・公開鍵は計2組、双方が必要なのですね。。大変勉強になります。
（SSH(OpenSSH?)の仕組みで言うと、サーバにある秘密鍵は/etc/ssh/ssh_host_rsa_key、それに対応する公開鍵はクライアントにあるknown_hostsファイル内の文字列、ですよねおそらく。。）

ただ、やはり私が何か勘違いしてしまっているのか、
質問に書かせていただいた疑問点は未だ残っており、
改めて補足に書かせていただきます。

補足

回答にて書いていただいた(2)の段階において、
クライアントは公開鍵Aで暗号化しサーバーに送り返す、
とありますが、ここで以下のようなことは起こらないのでしょうか？
---------------------------
(2)-1
[クライアント]→→→
サーバにレスポンス(公開鍵Aで暗号化したもの)を送る（送ったつもり）

(2)-2
[クライアント]→→→[第三者]
だが第三者が介入してそれを受信する

(2)-3
[クライアント]　　　[第三者]→→→[サーバ]
第三者がサーバにレスポンスを返す。
サーバが復号&比較すると正しいため、第三者を正しいクライアントだと認識してしまう。
---------------------------

公開鍵で閉め秘密鍵で開ける、としても、送信途中で横取りしてしまうことがもし可能なら、上記のような認証乗っ取り(?)も起こりうるのではないかと思っている次第です。