SSH를 통해 연결할 때 Diffie-Hellman 키 교환은 암호화되지 않은 TCP 세션을 통해 발생합니까, 아니면 교환 전에 암호화됩니까?

SSH를 통해 연결할 때 Diffie-Hellman 키 교환은 암호화되지 않은 TCP 세션을 통해 발생합니까, 아니면 교환 전에 암호화됩니까?

저는 네트워크 보안을 공부하는 학생이고 SSH 세션의 기본 흐름을 이해하고 싶습니다. 나는 최선을 다해 단계를 기록했지만 TCP 핸드셰이크 이후와 Diffie-Hellman 키 교환 이전에 무슨 일이 일어나는지 이해하는 데 도움이 필요합니다. 도와주세요:

세션 시작/TCP 핸드셰이크

  1. 클라이언트는 TCP 핸드셰이크를 시작하여 서버와의 세션을 시작합니다.
    TCP 세션의 비대칭 암호화

  2. 서버와 클라이언트는 TCP 세션에 대해 상호 지원되는 암호화 프로토콜을 반복적으로 협상하고 동의합니다.
    이 시점에서는 프로토콜 협상 후 처음에 세션이 어떻게 암호화되었는지 명확하지 않습니다. Wireshark를 사용하여 공개 키 등을 통해 보내는 클라이언트나 서버를 캡처하려고 시도했지만 프로토콜 버전 교환만 볼 수 있습니다. 어쨌든, 이 단계에 대해 설명해주세요.
    클라이언트와 서버는 Diffie-Hellman 알고리즘을 사용하여 이 세션에 대한 공유 비밀 키를 협상하여 대칭 키 암호화 세션을 설정합니다.

  3. 클라이언트와 서버는 다음을 사용하여 임시 키 쌍을 생성하는 프로세스를 시작합니다.

    1. 공유된 소수
    2. 암호화 생성기(일반적으로 AES)
    3. 개인 소수(개인 키로).
  4. 클라이언트와 서버는 이 세 가지 키를 사용하여 자체 개인 키에서 파생될 수 있는 자체 공개 키를 생성합니다.

  5. 클라이언트와 서버는 생성된 공개 키를 서로 공유합니다.

  6. 클라이언트와 서버는 각각 자신의 개인 키, 상대방의 공개 키 및 원래 공유 소수를 사용하여 동일한 비밀 키를 생성합니다.

  7. 클라이언트와 서버는 이 키를 공유 비밀로 사용하여 이 세션에서 향후 모든 통신을 암호화하고 해독합니다.

이 단계에서 클라이언트와 서버는 네트워크를 통해 키를 보내지 않고 대칭 키 암호화 세션을 성공적으로 설정했습니다.

제가 잘못 알고 있는 부분이 있다면 알려주시면 정말 감사하겠습니다. 감사해요!

답변1

Diffie-Hellman 키 교환은 초기 알고리즘 협상과 마찬가지로 암호화되지 않은 연결을 통해 발생합니다. 이는 키 교환으로 인해 대칭 키 암호화에 필요한 비밀을 생성하는 데 사용되는 공유 비밀이 생성되기 때문에 필요합니다.

암호화 또는 무결성 검사(예: AEAD 또는 HMAC 사용)가 없기 때문에 세션의 이 부분을 인증하는 것이 중요하므로 교환 해시에는 공유 비밀과 클라이언트 및 서버 버전, 클라이언트 클라이언트를 포함한 다양한 기타 데이터가 포함됩니다. 서버 Diffie-Hellman 매개변수 및 초기 알고리즘이 제공됩니다. 교환 해시는 서버(및 공개 키를 사용하는 경우 다른 데이터와 함께 클라이언트)에 의해 서명됩니다. 공격자가 이러한 값을 변조하면 교환 해시가 당사자가 계산한 것과 달라지고 서명이 확인되지 않으며 연결이 중단됩니다. 클라이언트가 공개 키를 사용하지 않더라도 해시와 키가 달라 연결이 작동하지 않습니다(MAC 오류로 인해 즉시 실패함).

서버는 Diffie-Hellman 응답을 보낼 때 교환 해시 버전에 서명합니다.

교환된 해시와 공유 비밀을 기반으로 암호화, MAC 및 초기 IV가 생성됩니다. 그런 다음 메시지를 보내고 NEWKEYS새 키를 사용하십시오.

그런 다음 클라이언트는 암호화된 연결을 통해 인증합니다. 이는 비밀번호를 사용할 수 있기 때문에 필요하며 암호화되지 않은 연결을 통해 인증하기 위해 비밀번호를 사용하는 것은 좋지 않습니다. 클라이언트가 키를 사용하는 경우 원래 교환 해시와 추가 데이터에도 서명합니다.

암호화 키, MAC 키 및 IV는 공유 비밀에서 생성되지 않습니다. 이는 무작위성이 덜 필요하고 적절한 수준의 보안이 달성된다는 것을 의미합니다. TLS도 같은 일을 합니다.

자세한 내용은 RFC 4253에 설명되어 있으며 클라이언트 인증은 RFC 4252에 설명되어 있습니다. 설명된 알고리즘 중 다수는 더 이상 사용되지 않거나 더 이상 사용되지 않습니다. 최신 알고리즘은 다른 RFC에 설명되어 있으며 때로는 구현이 지정된 경우 외부 문서에 설명되어 있습니다(즉, 이름에 기호가 포함되어 있음 @).

관련 정보