私はネットワークセキュリティを勉強している学生であり、SSHセッションの基本的な流れを理解したいと思います。私は最善を尽くしてステップを記録しましたが、TCPハンドシェイクの後とDiffie-Hellmanキー交換の前に何が起こったのかを理解するのに役立ちます。助けてください:
セッション開始/TCPハンドシェイク
クライアントはTCPハンドシェイクを開始してサーバーとのセッションを開始します。
TCPセッションの非対称暗号化サーバーとクライアントは、TCPセッションに対して相互にサポートされている暗号化プロトコルを繰り返しネゴシエートし、同意します。
この時点では、プロトコルネゴシエーション後に最初にセッションがどのように暗号化されたかは明らかではありません。 Wiresharkを使用して公開鍵などを介して送信するクライアントまたはサーバーをキャプチャしようとしましたが、プロトコルバージョンの交換のみを表示できます。とにかく、このステップについて説明してください。
クライアントとサーバーは、Diffie-Hellmanアルゴリズムを使用して、このセッションの共有秘密鍵をネゴシエートして対称鍵暗号化セッションを確立します。クライアントとサーバーは、次を使用して一時キーペアを生成するプロセスを開始します。
- 共有された素数
- 暗号化ジェネレータ(通常はAES)
- 個人素数(個人キーで)。
クライアントとサーバーはこれら3つのキーを使用して、独自の秘密鍵から派生することができる独自の公開鍵を生成します。
クライアントとサーバーは、生成された公開鍵を互いに共有します。
クライアントとサーバーは、それぞれ独自の秘密鍵、相手の公開鍵、および元の共有素数を使用して同じ秘密鍵を生成します。
クライアントとサーバーはこの鍵を共有秘密として使用して、このセッションで将来のすべての通信を暗号化および復号化します。
この段階で、クライアントとサーバーはネットワークを介して鍵を送信せずに、対称鍵暗号化セッションを正常に確立しました。
私が間違って知っている部分があれば教えてくれれば本当に感謝します。ありがとうございます!
答え1
Diffie-Hellman 鍵交換は、初期アルゴリズムのネゴシエーションと同様に、暗号化されていない接続を介して行われます。これは、鍵交換により、対称鍵暗号化に必要な秘密を生成するために使用される共有秘密が生成されるために必要である。
暗号化または整合性チェック(AEADやHMACなど)がないため、セッションのこの部分を認証することが重要であるため、交換ハッシュには、共有秘密とクライアントとサーバーのバージョン、クライアントクライアントを含むさまざまな他のデータが含まれます。サーバーDiffie-Hellmanパラメーターと初期アルゴリズムが提供されています。交換ハッシュは、サーバー(および公開鍵を使用している場合は他のデータと共にクライアント)によって署名されます。攻撃者がこれらの値を改ざんすると、交換ハッシュが当事者が計算したものとは異なり、署名が検証されず、接続が中断されます。クライアントが公開鍵を使用していなくても、ハッシュと鍵が異なるため、接続は機能しません(MACエラーのためすぐに失敗します)。
サーバーは、Diffie-Hellman 応答を送信すると、交換ハッシュバージョンに署名します。
交換されたハッシュと共有秘密に基づいて、暗号化、MAC、および初期IVが生成されます。その後、メッセージを送信してNEWKEYS
新しいキーを使用します。
その後、クライアントは暗号化された接続を介して認証します。これはパスワードを使用できるため必要であり、暗号化されていない接続を介して認証するためにパスワードを使用することはお勧めできません。クライアントがキーを使用している場合は、元の交換ハッシュと追加データにも署名します。
暗号鍵、MAC鍵、IVは共有秘密では生成されません。これは、ランダム性が少なく、適切なレベルのセキュリティが達成されることを意味します。 TLSも同じことをします。
詳細は RFC 4253 で説明されており、クライアント認証は RFC 4252 で説明されています。説明されているアルゴリズムの多くは廃止されたか、廃止されました。最新のアルゴリズムは他のRFCで説明されており、実装が指定されている場合は外部文書に記載されています(つまり、名前に記号が含まれています@
)。