RSAフィンガープリントは、実際に直接接続したい相手に接続していることを確認するために使用されており、そのサイトを装った他の誰かではないことを理解しています。
git Push
、それはあなたにRSAキーを表示します、そしてあなたはウェブページに行きそしてあなたが得たキーが彼らのウェブページ上のキーと一致するかどうか見ることができます。
しかし、そのサイトのふりをするために、サイトが使用している公開RSAキーを他の誰かが見つけ、同じキーで返信するのを阻止するにはどうすればよいでしょうか。
他の回答にもいくつかの良い情報がありますが、質問に直接回答するには:
しかし、そのサイトのふりをするために、サイトが使用している公開RSAキーを他の誰かが見つけて、同じキーで返信するのを阻止するにはどうすればよいでしょうか。
攻撃者がこれを行う可能性があり、攻撃者はあなたをだまして公開鍵を使用してデータを暗号化し、それらに送信する可能性があります。ただし、対応する秘密鍵がないと、この情報を解読できないため、この情報は役に立ちません。
公開鍵はまさにそれです-公開、配布を目的としています。公開鍵のコピーを持っているだけでは、鍵の所有者になりすますことはできません。公開鍵に対応する秘密鍵を使用して、所有者のみが復号化できる方法で所有者に送信するデータを暗号化する機能を提供します。また、秘密鍵を使用して暗号化されたデータを復号化して、データが秘密鍵の所有者からのものであることを証明することもできます。これは、ここでの使用です-公開鍵のコピーにより、サーバーがとの通信は信頼できる(秘密キーの所有者を信頼して、その秘密キーの機密性を維持できる範囲で)。
所有者が秘密キーを秘密にしておけば、システムは意図したとおりに動作します。
公開鍵暗号法 に関するWikipediaの記事では、RSA、DSAなどの仕組みの概要を説明しています。
フィンガープリントは関連する公開鍵から計算され、コンピューターで計算できます。フィンガープリントが期待と一致する場合、暗号化するキーはターゲットに適したものです。
偽のフィンガープリントを報告することはできますが、実際の所有キーから独立して計算できるという事実は、フィンガープリントに使用されるハッシュが衝突を現実的に可能にするほど小さい場合を除いて、ほとんど役に立ちません。衝突がなければ、データの交換は引き続き適切な公開鍵で暗号化され(使用しているものが予想されるハッシュと一致することが確認されているため)、対応する秘密鍵なしでは復号化できません。
SSHホスト認証は 鍵交換 中に発生します。鍵の交換は一般的に Diffie-Hellman を使用して行われます。これにより、対称セッション鍵として使用できる共有秘密を生成できます。
鍵交換の開始時に、署名アルゴリズムがネゴシエートされます(これはRSA、DSAなどの場合があります)。 キー交換 の最後に、ホストはこの署名アルゴリズムとその秘密キーを使用して サイン 以前に交換されたデータに使用します。ホストはその公開鍵と署名をクライアントに(Diffie-Hellmanのものとともに)送信し、クライアントはホストの公開鍵を使用して署名を検証します。署名は秘密鍵でのみ作成できるため、クライアントは、ホストが提示した公開鍵に対応する秘密鍵にホストがアクセスできることを知っています。
クライアントには、正しいホストと通信していることを確認するいくつかの方法があります。以前にホストに接続したことがある場合は、ホストの公開鍵をローカルデータベースと照合して、ホストが以前と同じ公開鍵を提示したことを確認できます。
鍵交換中に、ホストは、公開鍵だけを送信する代わりに、クライアントが信頼する [〜#〜] ca [〜#〜] によって署名された証明書を送信することもできます。その後、クライアントはホストの公開鍵がCAによって署名されたことを確認できます(ただし、実際には証明書はsshで頻繁に使用されません)。
ホストキーを自動的に検証できない場合、フィンガープリント(ホストの公開キーのハッシュ)がユーザーに提示され、ユーザーが手動で検証できるようにしますアウトオブバンド。ユーザーが受け入れた場合、公開鍵は通常、将来の接続の自動検証を可能にするために保存されます。
質問に答えるには:どのホストも他のホストの公開鍵をコピーできますが、鍵交換用の有効な署名を生成できません。クライアントはエラーで中止されます。ホストキーのフィンガープリントout-of-bandを確認している限り(Webサイトを確認する場合と同様に、HTTPS経由で希望)、MitMは阻止されます。
MITMは、サーバーを装ってサーバーに送信するプライベートメッセージを復号化するために、サーバーの秘密鍵を必要とします。サーバーの公開鍵は、サーバーが署名したメッセージを認証し、プライベートメッセージをサーバーに送信するためのものなので、フィンガープリントを確認する必要があります。 MITMにも公開鍵があれば問題ありません。つまり、MITMはサーバーからのメッセージを認証し、プライベートメッセージをサーバーに送信することもできます。
一般に、すべての公開鍵がすべての人に知られている場合、誰でも誰でも署名を認証でき、誰でもプライベートメッセージを誰にでも送信できます。秘密鍵は署名と復号化を制御するため、理想的には、他のユーザーになりすますことも、他のユーザーに送信されたプライベートメッセージを読むこともできません。
注:以下は、公開鍵のフィンガープリントの要点を示すことを目的とした、教育目的のみの簡略化されたモデルです。 SSHの詳細については この他の質問 を参照してください。
レビュー。簡単にするために、コンピュータネットワーク経由のSSHではなく、エージェントがテキストメモを投稿できるパブリックコルクボードを検討してください。最初、ボードは空白です。エージェントA
およびS
は通信を希望し、悪意のあるエージェントM
からメッセージのプライバシーと整合性を保護したいと考えています。秘密鍵はそれぞれの所有者だけが知っていると想定します。
A
投稿A_pub
、およびS
投稿S_pub
。A
は、S_pub
でメッセージを暗号化し、A_priv
で署名し、投稿します。S
はS_priv
を使用してメッセージを復号化し、A_pub
を使用して署名を検証します。S
は、A_pub
で応答を暗号化し、S_priv
で署名し、投稿します。A
の機能を知っていると思います。エージェントM
はこれらのメッセージを復号化できません。 M
can暗号化されたメッセージをS
またはA
に投稿できます。ただし、偽造の試みは失敗します。 M_priv
で署名されたメッセージは、A_pub
またはS_pub
を使用した検証に合格しませんでした。
次に、公開鍵のフィンガープリントの機能について説明します。M
がM_pub
とM_priv
を作成し、投稿によってA
をだまそうとするとします。 M_pub
をS_pub
として:
Dear A,
My public key is
[contents of M_pub]
Love,
S
A
がこの嘘を信じている場合、A
はM_pub
を使用してS
へのメッセージを暗号化し、M
がメッセージを復号化し、M
がM_priv
を使用してS
としてメッセージを偽造できるようにします。ただし、A
にS_pub
のフィンガープリントがある場合、A
はそれをM_pub
のフィンガープリントと比較して、嘘を発見できます。したがって、A
は、S
へのメッセージの暗号化およびS
からのメッセージの認証にM_pub
の使用を拒否します。
したがって、SSHが公開キーのフィンガープリントが不明または変更されていることについて警告を表示する場合、それはMITM攻撃の被害者である可能性があることを意味します。続行すると、MITMはメッセージを復号化し、サーバーとして応答を偽造できます。指紋チェックが成功した場合、あなたはMITMの犠牲者ではないという非常に高い信頼を持っています。あなたが持っている指紋がサーバーの本当の指紋であると仮定すると、秘密鍵(あなたとサーバーの両方)は確かに秘密であり、SSHの実装です正しいものであり、公開鍵の暗号計算は危険にさらされていません。
RSAキーが表示されるだけではありません。また、公開鍵と秘密鍵のペア(RSA鍵を含む)を使用して通信を暗号化します。これにより、サーバーXのみがサーバーになることができます(通常、サーバーXのみが秘密キーを持っているため)。
公開鍵と秘密鍵の詳細については、 ここ を参照してください。かなりの数の数学が関係しています。