ASA 8.0에서 IPsec VPN을 수행하고 있었으며 이에 대해 약간 이해하고 있습니다. 초기자는 ISAKMP 정책을 응답자에게 전송하여 시작하고 응답자는 일치하는 정책을 다시 보냅니다. 그런 다음 Diffie-Hellman 키가 교환 된 후 사전 공유 키를 다른 공유 키로 보내 인증합니다.
이제 두 개의 키가 있습니다 :
사전 공유 키를 암호화하는 데 어떤 키가 사용됩니까?
답변:
당신은 좋은 질문을했습니다. 질문은 매우 단순 해 보이지만 실제로는 다소 복잡합니다. 간결하게 대답하기 위해 최선을 다하겠습니다. 또한 ISAKMP를 언급 했으므로 IKEv1에 관심이 있다고 가정합니다. IKEv2의 상황은 약간 바뀌었지만 (아래, 많이) 아래 답변은 IKEv1과 관련이 있다고 언급하고 싶습니다.
1 단계는 메인 모드와 공격 모드의 두 가지 모드로 수행 할 수 있습니다. 어느 모드에서든 첫 번째 메시지는 개시 자에 의해 전송되고 두 번째 메시지는 응답자에 의해 전송됩니다. 이 두 메시지 모두 암호화 세계에서 Nonce 로 알려진 것을 포함합니다 . Nonce는 키 생성에 사용할 무작위로 생성 된 숫자입니다. (Nonce라는 용어는 _Once_를 사용하는 _N_umber에서 온 것입니다) . 따라서 메시지 1과 메시지 2 후에 양측은 서로의 Nonces를 알고 있습니다.
Nonce는 Pre-Shared-Key와 결합되어 비밀 키 생성을위한 Seed 값을 생성합니다. IKE RFC 의 상대 부분 은 다음과 같습니다.
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID는 나중에 추가 비밀 키를 생성하는 데 사용되는 Seed 값입니다. Pre-Shared-Key와 Nonce 값 (Ni_b는 개시 자 Nonce, Nr_B는 응답자 Nons)은 PRF 또는 Psuedo Random Function을 사용하여 결합됩니다. PRF는 결과가 필요한만큼 많은 비트가 될 수 있다는 점을 제외하면 해싱 알고리즘과 같습니다.
이제 처음 주 모드를 수행 한 경우 메시지 3과 4는 초 기자와 응답자의 (각각) Diffie-Hellman 공개 키를 공유합니다. 둘 다이 값을 사용하여 Diffie-Hellman 공유 비밀 을 생성합니다 . 공격적 모드를 수행 한 경우 이러한 DH 공개 값은 메시지 1 및 메시지 2 (Nonces와 함께)에도 포함됩니다.
그런 다음 Seed 값을 DH Shared Secret (및 몇 가지 다른 값)과 결합하여 세 개의 세션 키 ( Derevative 키, 인증 키 및 암호화 키)를 만듭니다. RFC는 다음과 같이 말합니다.
주 모드 또는 공격 모드의 결과는 인증 된 키 자료의 세 그룹입니다.
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
SKEYID_d, _a 및 _e는 위에서 언급 한 세 개의 세션 키입니다. SKEYIDSeed 값입니다. g^xyDH 공유 비밀입니다. CKY-I그리고 CKI-R기자 및 응답자 쿠키, 이러한이 특정 ISAKMP 교환 및 보안 연결을 식별하기 위해 나중에 사용된다 단지 추가 무작위로 생성 된 값입니다 있습니다. 0 1 2리터럴 숫자 0, 1 및 2입니다. 파이프 기호 |는 연결을 나타냅니다.
어쨌든 이러한 모든 값은 세 개의 세션 키를 생성하는 PRF를 사용하여 함께 결합됩니다.
인증 키 및 암호화 키는 후속 Phase2 협상을 보호 / 암호화하는 데 사용됩니다. 주 모드에서 Phase1의 메시지 5와 6도이 키로 보호됩니다. 또한 향후 ISAKMP 정보 교환 (DPD, Rekey 이벤트, Delete 메시지 등)도이 두 키로 보호됩니다.
파생 키는 IPsec으로 전달되며 IPsec은이 키에서 자체 키 자료를 생성합니다. IPsec에 본질적으로 키 교환 메커니즘이 포함되어 있지 않기 때문에 비밀 키를 얻는 유일한 방법은 수동으로 키를 설정하는 것 (고풍스럽고 더 이상은 절대로 수행하지 않음) 또는 외부 서비스에 의존하는 것입니다 ISAKMP와 같은 키 자료를 제공합니다.
RFC는 다음과 같이 말합니다.
SKEYID_e는 ISAKMP SA가 메시지의 기밀성을 보호하기 위해 사용하는 키 자료입니다.
SKEYID_a는 ISAKMP SA가 메시지를 인증하는 데 사용하는 키 자료입니다.
SKEYID_d는 ISAKMP 이외의 보안 연결에 대한 키를 도출하는 데 사용되는 키 자료입니다.
모든 말과 함께, 우리는 당신의 질문으로 되돌아 갈 수 있습니다 : Pre-Shared-Key를 보호하기 위해 어떤 키가 사용됩니까?
주 모드에서 PSK (Pre-Shared-Key)는 메시지 5와 6에서 확인됩니다. 메시지 5와 6은 위에서 설명한 ISAKMP가 생성 한 세션 키로 보호됩니다.
공격 모드에서는 협상의 메시지가 암호화되지 않습니다. PSK는 메시지 2와 3에서 검증되었습니다. 두 경우 모두 PSK가 검증 되었으며 PSK가 교환 되었다고 말한 적이 없습니다 . 공격적 모드의 어떤 것도 암호화되어 있지 않고 암호화되지 않은 상태로 유선을 통해 사전 공유 키를 전송 한 경우에는 큰 보안 취약점이 발생합니다.
운 좋게도 ISAKMP의 작가들은 이미 그 점을 생각했습니다. 그 결과 각 당사자가 실제로 PSK를 공유하지 않고도 올바른 PSK를 가지고 있는지 확인하는 특별한 방법을 만들었습니다. 각각의 피어에 대해 동일한 PSK를 가지고 있는지 각각의 피어에 대해 검증하는 데 사용되는 두 가지 항목 인 Identity Method 와 Identity Hash가 있습니다.
VPN 피어는 다양한 방법으로 자신을 식별하도록 선택할 수 있습니다. 가장 일반적으로 피어는 단순히 소스 IP 주소를 사용합니다. 그러나 FQDN 또는 호스트 이름을 사용하는 옵션이 있습니다. 이들 각각은 선택된 방법에 대한 상관 값과 함께 아이덴티티 방법을 구성합니다. 예를 들어, IP 5.5.5.5가 있고 내 IP 주소를 사용하여 본인을 식별 하려는 경우 내 ID 방법 은 효과적으로 [IP Address, 5.5.5.5]가 됩니다. (참고 : BOTH 값은 전체 ID 방법을 구성합니다)
그런 다음 ID 방법을 PRF를 사용하여 앞에서 설명한 Seed 값 (SKEYID) 및 몇 가지 다른 값과 결합하여 Identity Hash 를 만듭니다 . 처음에 SKEYID를 생성 한 것은 Pre-Shared-Key였습니다.
그런 다음 ID 방법과 ID 해시가 유선으로 전송되고 상대방이 동일한 공식을 사용하여 ID 해시를 다시 만들려고 시도합니다. 수신자가 동일한 ID 해시를 다시 작성할 수있는 경우 수신자에게 송신자가 올바른 사전 공유 키를 가지고 있었음을 증명합니다.
이에 대한 RFC는 다음과 같습니다.
두 교환을 인증하기 위해 프로토콜의 초기자가 HASH_I를 생성하고 응답자가 HASH_R을 생성합니다.
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
IDii와 IDir은 ID 방법입니다. HASH_I 및 HASH_R은 초 기자 및 응답자 해시입니다. 둘 다 Phase1에서 공유됩니다. RFC에서 :
사전 공유 키 인증을 수행 할 때 주 모드는 다음과 같이 정의됩니다.
Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_R사전 공유 키가있는 공격 모드는 다음과 같습니다.
Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I -->
이제 귀하의 질문에 완전히 대답 할 수 있습니다.
Pre-Shared-Key는 Nonces와의 PRF 및 협상에서 다른 사람에게 알려진 다른 많은 값을 사용하여 결합됩니다. 결과는 두 당사자가 동일한 사전 공유 키라고하는 동일한 값으로 시작한 경우 두 당사자 만 상호 달성 할 수있는 값입니다. 결과 값은 유선으로 공유되는 값이며, 두 당사자가 사전 공유 키 자체에 대한 정보를 실제로 노출시키지 않고 일치하는 사전 공유 키가 있는지 확인할 수 있습니다.
주 모드는 위에서 설명한 "결과 값"의 교환을 암호화하여보다 안전한 단계를 수행하므로 사전 공유 키가 무엇인지에 대한 유용한 정보를 추출하기가 훨씬 어렵습니다.
(간결하게 대답하는 데 비참하게 실패한 것 같습니다)
귀하의 답변은 귀하의 질문에 있습니다 : Diffie-Hellman 교환은 공통 키 (예 : 사전 공유)를 안전하게 교환하기 위해 공통 키를 생성하는 데 사용됩니다.
이것을 참조하십시오 : /security/67953/understanding-diffie-hellman-key-exchange