이 문서를 읽고 IPSec에 대한 정리한 글이다.
IPSec protocol은 두 개의 main components로 구성되어 있다.
- Encapsulating Security Payload(ESP) protocol
- 두 IPSec endpoint들 간에 전송되는 IP 패킷을 secure 하는 프로토콜
- Internet Key Exchange Version 2(IKEv2) auxiliary protocol
- IPSec endpoint간의 상호 인증
- IKEv2 management protocol과 ESP payload protection에 대한 data integrity sesstion keys, encryption 자동 생성
Encapsulation Security Payload (ESP)
ESP는 Network layer에서 IP Packet을 전송할 때 암호화를 허용한다.
IPSec Transport Mode
IPSec Transport mode에서는 Original IP 헤더가 유지되고 IP 패킷에 의해 운반되는 Layer4 payload는 암호화된다.
ESP 헤더는 Original IP 헤더와 암호화된 페이로드 사이에 삽입된다.
IPSec Transport mode는 주로 Layer 2 Tunneling Protocol(L2TP)을 secure 하기 위해 사용되고 있다.
IPSec Tunnel Mode
IPSec Tunnel mode에서는 ESP와 outer IP header(터널의 시작, 종료 IP주소 등 정보 포함)에 의해 IP packet 전체(헤더와 페이로드)가 캡슐화된다.
ESP Packet Structure
ESP Packet은 ESP header, 암호화된 IP Payload body 그리고 padding을 위한 ESP trailer로 이루어져있다.
ESP trailer란?
ESP 패킷의 마지막 부분에 추가되는 데이터 영역이다. 암호화된 데이터의 길이를 블록 암호 알고리즘의 블록 크기에 맞추기 위한 Padding과 암호화된 페이러도의 프로토콜 타입을 나타는 필드, 패딩 데이터의 길이와 같은 정보들을 포함하고 있다.
암호화 체크섬으로서 Authentication Data는 데이터 무결성을 보장한다.
receiving IPSec peer는 32bit SPI를 커널 기반 DB의 Index로 사용해 ESP 패킷의 암호를 해독하고 인증하는 데 필요한 세션 키를 검색한다. 또한 암호 해독 후 inbound plaintext IP packet(ESP 패킷이 복호화된 후 수신되는 일반 IP 패킷)에 적용해야 하는 IPSec 보안 정책을 결정하는 데 사용된다.
IPSec 통신은 두 개의 IPSec endpoing 간에 이루어지며, 이 중 하나가 ESP 패킷을 전송하는 sending IPSec peer고 다른 하나가 ESP 패킷을 수신해 처리하는 receiving IPSec peer다.
Internet Key Exchange Version 2 (IKEv2)
IKEv2는 IPSec connection들에 대한 설정을 관리하며 source 및 destination 포트가 모두 잘 알려진 UDP 포트 500으로 설정된 UDP 데이터그램을 사용한다.
IKE_SA_INIT Request/Response
IPSec 통신을 위해서는 IKE protocol을 통해 SA(Security Association)을 설정해야 한다. IKE_SA_INIT은 SA 설정을 위한 초기 negotiation이 이루어진다.
Initiator(클라이언트)가 IKE_SA_INIT Request를 보내고 이 메시지를 통해 Responder(서버)와 암호화 알고리즘, 키 교환 방식 등의 보안 파라미터를 협상한다. Responder가 Initiator의 제안을 수락하는 Response Message를 보내면 양측은 SA를 설정할 수 있게 된다.
만약 Responder가 자신이 DoS 공격을 받고 있다고 생각되면, Response 내에 계산 비용이 많이 드는 Key Exchange(KE) payload를 보내기 전에 Initiator에게 Cookie를 요쳥해 효율적으로 IP spoofing을 방지할 수 있다.
Key Exchange(KE) payload
Diffie-Hellman 키 교환 알고리즘을 사용해 Initiator와 Responder가 shared secret key를 생성할 수 있게 한다. 이들은 각자의 공개 키를 KE payload에 포함하여 교환하고 이를 통해 shared secret key를 계산할 수 있게 된다.
Nonces(N) payload
Nonces payload에는 랜덤 하게 생성된 숫자(Nonce)가 포함된다. Initiator와 Responder는 각자의 Nonce를 교환하여, 이를 shared secret key 생성에 사용하고 message의 freshness를 보장하는데 이용한다.
Initiator와 Responder는 KE payload과 N payload의 교환을 통해 shared secret key를 생성한다. 이제 이 둘은 `IKE_SA`를 설정할 수 있다. `IKE_SA`에는 양측이 합의한 보안 파라미터를 나타내는 SA1i와 SA1r payload가 포함되어 이후 IKE 메시지들이 암호화되어 전송될 수 있게 한다.
IKE_AUTH Request/Response
Certificate-based Authentication
Initiator는 IKE_AUTH request message에서 자신의 id(IDi), Digital Signature(AUTHi)와 선택적으로 인증서(CERTi)를 보낸다. 또한 첫 번째 CHILD_SA에 사용될 Security Association proposal(SA2i)과 Traffic selectors(TSi, TSr)을 보낸다.
CHILD_SA란?
IPSec 통신을 위해 IKE protocol을 통해 설정되는 SA로 IPSec payload packet의 암호화와 무결성 보장을 위한 보안 파라미터가 포함된다.
이를 통해 IPSec Tunnel이 설정되고 실제 데이터 트래픽이 보호된다.
Responder는 IKE_AUTH response message에서 자신의 Digital Signature`AUTHr`과 선택적으로 인증서 CERTr를 보낸다. 또한 Initiator가 보낸 SA2i를 선택하고, 필요한 경우 Traffic selectors(TSi, TSr)을 조정한다. 추가로 Initiator가 보낸 인증서 CERTi의 유효성과 신뢰성을 검증하는데 이를 위해 Responder는 X.509 인증서 체인을 따라 올라가서 로컬에 저장된 루트 CA 인증서와 비교한다.
결과적으로 상호 인증이 완료되면, Initiator와 Responder는 IKE_AUTH 메시지에 포함된 정보를 바탕으로 CHILD_SA를 설정할 수 있다.
PSK-based Authentication
Authentication에 Pre-Shared Key(PSK)가 사용되는 경우 AUTHi와 AUTHr payload는 교환된 IKEv2 message와 pre-shared secret에 대한 해시를 가지고 있다.
PSK는 사용자가 직접 설정하는 공유 비밀키다.
IKE_AUTH 교환 시 Initiator가 먼저 AUTHi payload에 PSK hash를 보낸다. 이때 PSK의 암호 수준이 약하다면 MITM(Man In The Middle - 중간자 공격자)가 offline dictionary 공격이나 무차별 대입 공격을 통해 PSK를 크래킹 할 수 있다.
따라서 충분한 강도의 PSK를 사용할 수 없다면 PSK 기반 인증을 사용하지 말고 RSA signature 기반 인증 등 다른 인증 방식을 사용하는 것이 좋다.
EAP-based Authentication
MITM를 방어하기 위해 EAP-based Authentication이 IKEv2 표준으로 도입되었다.
만약 Initiator가 IKE_AUTH request에 AUTHi payload를 포함하지 않았다면 Responder는 AUTHr payload에 강력한 Digital Signature를 먼저 보낸다. 이로서 신뢰할 수 있는 Initiator 임을 확인하고 동시에 IKE_AUTH response에 첫 EAP request를 포함시켜서 EAP protocol을 시작한다.
CREATE_CHILD_SA Request/Response
CREATE_CHILD_SA Request/Response pairs는 CHILD_SA를 추가로 협상할 때 사용된다.
추가로 IKE_SA와 CHILD_SA는 일정 시간이 지나면 보안상의 이유로 rekeying(재협상)되어야 하는데 CREATE_CHILD_SA message pair를 사용해 이러한 rekeying을 수행할 수 있다.
- IKE_SA rekey
- IKE_SA rekey 시 N(REKEY_SA) 알림이 포함되지 않는다.
- 새로운 Key Exchange(KE) payload가 포함되어 Perfect Forward Secrecy(PFS)가 보장된다.
- PFS는 각 통신 세션마다 고유한 세션 키를 생성하는 키 유도 함수를 사용해 한 세션의 키가 노출되더라도 다른 세션의 키에는 영향을 주지 않는다. 즉, long-term secret key가 노출되더라도 과거의 통신 내용이 안전하게 유지되는 것이다.
- CHILD_SA rekey
- CHILD_SA rekey 시 N 알림이 포함된다.
- KE payload는 선택적으로 포함될 수 있다.
따라서 N 알림이 포함되면 CREATE_CHILD_SA Request/Response가 CHILD_SA rekey를 위한 것임을 알 수 있다.
NAT Traversal
IPSec VPN에서는 ESP(IP protocol 50)과 IKE(UDP 500)이 사용된다. 여기서 ESP 프로토콜은 포트 개념이 존재하지 않으므로 PAT(Port Address Translation) 방식으로는 NAT router를 통과할 수 없다. 따라서 NAT Traversal이 등장하게 되었다.
NAT Traversal
NAT Traversal은 UDP encapsulation을 통해 구현된다. ESP 패킷을 UDP 패킷으로 캡슐화해 NAT device에서 포트 변환이 가능하도록 한다. 이를 통해 ESP traffic이 NAT router를 통과할 수 있는 것이다.
어떤 NAT 라우터들은 IPSec Passthrough라고 부르는 기능을 갖고 있다. NAT device 뒤에 있는 single host에서 outbound IKE traffic을 감지하고 아래 그림과 같이 inbound IKE 및 ESP packet을 특정 host로 전달한다.
하지만 이 방식은 동일한 VPN Gateway와 통신하는 여러 IPSec Client가 있는 경우는 작동하지 않는다. 이 문제를 해결하기 위해 제안된 솔루션은 ESP 패킷을 UDP Datagram으로 캡슐화하여 PAT를 적용하는 것이다.
IKE_SA_INIT 교환 시 전송되는 NAT_DETECTION_SOURCE_IP 및 NAT_DETECTION_DESTINATION_IP 알림을 통해 NAT 상황을 감지하고 이를 통해 ESP 트래픽이 NAT 라우터를 통과할 수 있게 된다.
NAT 상황이 없다고 해도 encap=yes 옵션을 설정하면 ESP-in-UDP 캡슐화를 강제할 수 있다. charon deamon이 조작된 NAT_DETECTION_SOURCE_IP 알림 payload를 전송하여 remote peer에게 NAT 상황이 있는 것처럼 보이게 하는 것이다.
ESP-in-UDP Encapsulation
ESP 패킷에 UDP Header를 추가해 ESP 패킷이 NAT device를 통과할 수 있게 한다. 결과적으로 IPSec 통신의 범위가 확장된다.
UDP Header가 ESP 패킷의 IP Header와 ESP Header 사이에 삽입된다.
정리
IPSec은 IP 트래픽에 대한 보안 기능을 제공하는 네트워크 프로토콜이다. IPSec의 ESP 프로토콜과 IKEv2 프로토콜로 구성되어 있고, ESP는 IP 패킷을 암호화하여 전송하고, IKEv2는 IPSec 연결 설정을 관리한다.
IPSec은 Transport 모드와 Tunnel 모드로 동작하며, NAT 환경에서 작동하기 위해 NAT Traversal 기술을 사용한다.
IKEv2는 상호 인증을 위해 PSK, Digital Signature 등의 인증 방식을 사용한다.
'VPN' 카테고리의 다른 글
| Netfilter에서의 IPsec VPN (strongSwan) (0) | 2024.07.31 |
|---|---|
| strongSwan이란? (0) | 2024.05.31 |