DHで取得したキーの非対称暗号署名がMITMを防ぐと主張する次の記事を見つけました。
http://www.gremwell.com/ssh-mitm-public-key-authentication
重要なアイデア:
'signature'の値は、次のデータの対応する秘密鍵による次の順序での署名です。
string session identifier byte SSH_MSG_USERAUTH_REQUEST
現在、クライアントとサーバーはセッションIDがどうあるべきかについて異なる考えを持っているため、攻撃者は問題を抱えています。明らかに、サーバーはクライアントから提供された署名を拒否し、公開鍵認証は失敗します。
これに対する私の理解が正しいかどうかを確認したいのですが。
アリス(A
)をクライアント、MITM(M
)を攻撃者、ボブ(B
)をsshサーバーとします。
仮定:
M
は通信の真ん中に位置し、A
とB
間のすべての通信を傍受します
M
どういうわけかA
をだましてB
だと思い込ませ、B
をだましてA
だと思い込ませた(指紋など)。
ただし、M
はA
のマシンにもB
のマシンにも侵入できず、A
の公開鍵はA
のアカウントに残っていますB
マシンはそのまま
上記の条件がこの条件に当てはまる限り:
セッションIDは、(特に)Diffie-Hellmanアルゴリズムを使用してピアがネゴシエートした共有シークレットに基づいて計算されます。
=> M
はA
とB
へのDH交換を偽造できますが、それらは必ず2つの異なる(偽の)共有シークレットである必要があります(M
modifying交換されたDH番号を観察することではなく、それらを交換することで妥協します)。
この共有シークレットが署名付きデータ(セッション識別子の一部または全体)を作成するコンポーネントとして使用される場合、M
が偽造できず、知らないのは、A
の秘密鍵です。 (1番目の)偽の共有秘密に基づいてセッションIDに署名するために使用されます。
したがって、セッションIDのデジタル署名(+上記の説明にある他のセッションデータ)がB
での検証に失敗するか、セッションIDが一致せず、通信が実質的に切断されます。
質問:
この推論は正しいですか?そうでない場合、どこに間違いがありますか?
セッションIDの作成はこのチェーンの「最も弱いリンク」ですか?つまり、M
がそれを予測でき(たとえば、DH自体がそうでなくても、統計的攻撃を受けやすい予測可能な一方向ハッシュである場合)、それを何らかの方法で推測します(非常にありそうもありませんが、そうです)理論的にも不可能ですか?)、M
はA
によって署名された「本物の」セッションIDを持っているので、B
は認証署名がOKであると考えますか?
これは実際にはほぼ不可能だと思いますが、理論的には完全に理論的には不可能です?
1.はい、正しいです。 2つの可能な方法があります。
A)アリスは、攻撃者のギャラリーからの新しい指紋を盲目的に受け入れます。アリスとマロリーは、互いに接続して認証することができます。マロリーのここでの問題は、ボブと交換されたセッションIDに署名できなかったことです。マロリーはアリスの秘密鍵を所有していないからです。また、Malloryは、署名されたセッションIDをAliceからBobにリダイレクトできませんでした。これは、セッションIDが異なる可能性が高いためです。
B)アリスが新しい指紋を盲目的に受け入れない場合、マロリーは公開鍵とその指紋をボブから送信することができます。ここでの問題は、マロリーがボブからの秘密鍵を所有していなかったため、マロリーがアリスに認証できなかったことです。
注意:ケースA)では、アリスがパスワード認証も受け入れると、malloryはパスワード認証でクライアントを認証するようにサーバーを構成し、malloryはユーザー名とパスワードを取得します。
2.はい、理論的には可能です。 A)を参照してください。なぜアリスはボブからの正しい署名付きIDを受け入れないのですか?彼女は:)を受け入れ、アリスはボブからの正しい署名付きIDも受け入れます。マロリーは、接続の構築時にボブからのアリス公開鍵を表示するだけで済みます。
これが失敗するところです。あなたは仮定します:
M somehow tricked A into thinking that he's B and also tricked B into thinking he's A (re fingerprints etc).
指紋は複製できないものです。フィンガープリント(別名HMAC)は、秘密鍵のハッシュです。秘密鍵は送信されませんが、クライアントとサーバーの両方がpreshsaredマスター鍵を使用して個別に計算します。
PKIでは、秘密鍵と公開鍵が役立ちます。これは、a)公開鍵から秘密鍵を導出できないこと、およびb)公開鍵を使用して、サーバーの秘密鍵で復号化できるデータを暗号化できること、およびその逆のことです。
したがって、サーバーの秘密鍵を知らないと、SSHセッションで有用なMITM攻撃を実行することはできません。さらに、ほとんどの場合、SSHは新しいセッションをネゴシエートするのではなく、単にセッションを再開します。これには、セッションIDをプレーンテキストで送信することを含みますが、このシナリオでは、攻撃者には知られていない、所定の暗号スイート([M])を使用して暗号化を再開します。