Windows NT는 클라이언트가 스트림 암호를 사용하여 일부 키 로 메시지 배열을 암호화하여 서버와 "안전하게"통신 할 수있는 지점 간 프로토콜을 사용했습니다 . 서버는 또한 동일한 키 응답을 암호화합니다 . 그러나이 키를 어떻게 알 수 있습니까?k
좀 더 일반적으로 : Alice와 Bob이 동일한 개인 키 에서 작동하는 암호화 / 암호 해독 알고리즘을 사용 하는 경우이 키를 안전하게 교환하는 방법은 무엇입니까? (다른 키를 사용하지 않고)
이것은 개인 키 암호화를 연구하는 동안 항상 나 자신에게 요구 한 것입니다.
답변:
대부분의 개인 키 알고리즘은 현재 컴퓨팅 인프라를 고려하여 숫자를 주요 요소로 분해하는 것과 같은 특정 계산의 실행 불가능성에 의존합니다.
동시에 암호화 및 암호 해독에 사용될 때는 대부분 계산량이 많으므로 개인 키를 사용하여 전체 메시지 스트림이 암호화되지 않습니다. 오히려 메시지는 다른 (집약적이지 않은) 알고리즘을 사용하여 암호화되며 해당 암호화에 사용 된 키는 개인 키를 사용하여 암호화됩니다.
물론, 지적한 바와 같이, 안전한 키 교환은 어느 정도까지 해결 될 수있는 문제로 남아 있습니다.
Alice와 Bob이 동일한 개인 키에 동의 할 때마다 가장 인기있는 방법은 Diffie-Hellman 을 사용하는 것 입니다. 다음과 같이 작동합니다.
두 개의 공개 값이 먼저 선택되면 및 g = 17이 됩니다. (이것은 일반적으로 매우 큰 소수이며 해당 프로토콜을 사용하는 모든 사람에게 알려져 있습니다).
Alice는 Private Value 을 선택하고 Bob은 Private Value b = 7을 선택합니다 . 이것들은 그들 자신의 것입니다.
Alice는 을 계산하고 Bob은 계산합니다 ( 이 경우 및 ). 값 및 .B = 4 A B
Alice는 을 계산하고 Bob은 계산합니다 ( 이 경우 .K = A bK = 12
이제 Alice와 Bob은 모두 가치 를 키로 합의 했습니다. 값 과 와 매우 큰 소수 이므로 도청자가이를 인수 분해하여 키 자체를 계산하는 것은 거의 불가능합니다.N g
개인 키 암호화의 문제는 MITM (Man-in-the-Middle) 공격이며 개인 키 암호화보다 공개 키 암호화를 선택하는 주요 이유 중 하나입니다.
첫째, 용어 관점 : 설명하는 것은 대칭 암호화 이며 참가자들간에 공유되는 키는 일반적으로 비밀 키라고합니다. "개인 키"는 일반적으로 한 명의 참가자 만 알고 있는 공개 키 암호화 의 키 부분을 의미합니다 .
비밀 키를 배포하는 방법에는 두 가지가 있습니다. 물리적으로 안전한 방식으로 전송되거나 다른 형태의 암호화 (일반적으로 공개 키 암호화)를 사용하여 전송 될 수 있습니다.
비밀 통신 채널이 필요없는 비밀 키를 교환하는 방법이 있습니다. 가장 인기있는 것은 Diffie-Hellman 키 교환 프로토콜입니다.. Diffie-Hellman의 원칙은 각 참가자가 고유 한 키 쌍을 생성하며 하나의 공개 키와 하나의 개인 키로 많은 수를 구성하는 수학 연산이 있다는 것입니다. 이 수학적 연산에는 매우 흥미로운 속성이 있습니다. 다수는 Alice의 개인 키와 Bob의 공개 키 또는 Bob의 개인 키와 Alice의 공개 키로 구성 할 수 있습니다. 어느 쪽이든 같은 숫자를 얻습니다. 따라서 Alice와 Bob은 공개 키를 교환하고 두 당사자는 다수를 알고 비밀 키로 사용할 수 있습니다. 도청자는 공개 키를 모두 찾을 수 있지만 공개 키만으로는 많은 수를 찾을 수 없습니다 ¹.
Diffie-Hellman 키 교환을 통해 두 사람이 누가 듣고 있든 비밀을 교환 할 수 있습니다. 그러나 Alice를 Bob에게 인증하거나 그 반대로 인증하지 않습니다. 따라서 중간자 공격이 가능합니다 . Mallory는 Alice (Bob과 대화하고 있다고 생각하는 Alice)와 Bob (Alice와 대화하고 있다고 생각하는 Bob)과 별도로 키 교환을 수행하여 결정 또는 최소한 비밀을 알고 있습니다.
공격자가 메시지를 가로 채서 주입 할 수 있으면 참가자가 서로를 인증하는 데 더 많은 암호화가 필요합니다. (수동 공격자는 효과적으로 기본 전송 프로토콜이 인증을 제공함을 의미합니다.) 쉬운 방법은 각 참가자가 서로의 공개 키를 이미 알고있는 것입니다. Alice가 Bob의 공개 키를 알고있는 경우 :
이러한 방법 중 하나 (또는 또 다른 변형)를 한 방향으로 사용하고 다른 방향으로 동일하거나 다른 방법을 사용하거나 한 방향으로 만 인증하는 많은 변형이 있습니다. 예를 들어 SSL / TLS (HTTPS, SMTPS, IMAPS 등과 같은 많은 -s 프로토콜의 암호화 계층)는 여러 가지 다른 암호 조합을 사용할 수 있으며 일반적으로 서버를 클라이언트로 인증하지만 선택적으로 클라이언트를 인증 할 수도 있습니다. Diffie-Hellman은이 애플리케이션에서 느리고 번거 롭습니다. 공개 키 배포를 통해 가장 널리 사용되는 알고리즘은 RSA 입니다.
물론 Alice와 Bob은 서로의 공개 키를 미리 알지 못할 수도 있습니다. Bob은 Alice에게 공개 키를 사용합니다. Bob은 Alice에게 공개 키와 함께이 키가 실제로 Bob의 공개 키임을 확인하는 서명 된 진술서를 보냅니다. 이 서명 된 진술서를 인증서 라고하며 세 번째 당사자는 인증 기관 입니다. 제 3자는 Bob에게 알려 지거나 제 4 자에 의해 신원이 확인 될 수 있습니다. 결국이 신뢰 체인 (… Bob을 보증하는 Charlie를위한 Dominique 보 증권)은 Bob이 이미 신뢰하는 당사자 Ron에게 도달해야합니다. 즉, Bob은 Ron의 공개 키를 가지고 Ron이 유효한 인증서 만 서명하도록 신뢰합니다.
공개 키 암호화에 의존하지 않는 프로토콜이 있습니다. 특히 Kerberos 프로토콜은 클라이언트와 서버 사이의 연결을 설정하기 위해 유닉스 기반 및 Windows 기반 네트워크 모두에서 사용됩니다. Kerberos는 KDC ( 키 배포 센터) 라는 중앙 인증 서버를 사용합니다 . KDC에는 사용자 암호가 데이터베이스에 저장되어 있어야하며 클라이언트는 일반적으로 사용자에게 암호를 묻습니다. 암호 노출을 피하기 위해 프로토콜은 암호를 직접 사용하지 않지만 암호 해시 또는 일반적으로 암호에 적용되는 키 파생 함수를 사용합니다.
이 공유 비밀을 사용하여 클라이언트와 KDC는 보안 채널을 설정하고 KDC는 클라이언트에 "티켓"을 보냅니다. 티켓에는 세션 키 (예 : 새로 생성 된 비밀 키)와 KDC와 클라이언트가 연결하려는 서버간에 공유되는 다른 대칭 키로 암호화 된 키 사본이 포함됩니다. 그런 다음 클라이언트는이 암호화 된 사본을 서버로 전달합니다. 서버는이 메시지를 해독하여 세션 키를 가져오고 세션 키로 암호화하여 클라이언트로 다시 보내는 nonce를 생성합니다. 그런 다음 클라이언트는 서버로 보안 채널을 시작하고 세션 키로 암호화 한 다음 nonce를 해독 할 수 있음을 표시하여 시작합니다. 이렇게하면 클라이언트가 서버에 인증됩니다. Kerberos 세션 설정은 Needham-Schroeder 프로토콜 의 변형입니다 .
¹ 암호 전문가들은 매우 열심히 노력했지만, 그들이 찾은 최선의 방법은 달성 할 수없는 컴퓨팅 능력을 요구합니다.
가능한 방법은 먼저 공개 키 암호화 를 사용 하여 개인 키를 교환하는 것입니다. 그러나 가능하지 않은 경우 특정 키 교환 프로토콜이 있으며 가장 잘 알려진 것은 Diffie-Hellman 프로토콜 입니다.
사소한 해결책이 항상 있습니다. 사용자가 키를 만나고 교환합니다. 이것은 많은 경우에 실용적이지 않지만 가능합니다.
DH (Diffie-Hellman) 키 교환 프로토콜 외에도 양자 키 분배 프로토콜도 있습니다. 가장 잘 알려진 QKD 프로토콜 중 하나는 Bennett-Brassard 프로토콜 인 BB84 입니다.
DH에 비해 BB84의 장점은 이산 로그를 효율적으로 수행 할 수없는 경우에만 DH가 안전하다는 것입니다 ( 이산 로그 가정 및 관련 DDH 가정 참조 ). 그러나 BB84는 정보 이론적으로 안전합니다. 즉, 일지라도 BB84는 여전히 안전하지만 DH는 안전하지 않습니다.
반대로 MIB 공격은 BB84의 문제이기도하며,이 문제를 극복하기 위해 사용자가 인증 된 채널을 사용해야한다고 가정해야합니다 (그러나 일반적으로 인증 키를 미리 공유해야하며 정사각형으로 돌아갑니다).