IPSec

📡 IPSec

인터넷에서 데이터를 주고받을 때 가장 기본적인 통신 단위는 IP 패킷이다. 그런데 이 IP 계층은 설계할 때 보안을 전혀 고려하지 않았다. 누가 보냈는지 알 수 없고, 데이터가 중간에서 훼손되거나 엿보여도 이를 탐지할 방법이 없다.

그래서 등장한 것이 IPsec (IP Security)이다. IPsec은 IP 계층에 암호화, 인증, 무결성 보장 기능을 추가히주는 보안 기술이다.

IPsec은 사용자 트래픽(ex, 웹 브라우징)뿐만 아니라 라우팅 제어 메시지(ex, BGP, DNS 등) 같은 제어 트래픽까지 보호할 수 있는 유일한 표준 보안 기술이다. IPsec은 상황에 따라 두 가지 방식(모드) 중 하나로 동작한다.

Transport Mode (전송 모드)

• IP 헤더는 그대로 유지하고, 데이터(payload) 부분만 암호화/인증한다.
• TCP나 UDP 데이터, 혹은 애플리케이션 데이터를 보호하는 데 적합하다.
• 주로 종단 간 보안에 사용된다. (예: 내 컴퓨터 ↔ 서버)

예를 들어 회사 내부 직원이 원격지의 서버에 접속할 때, 통신 내용만 보호하면 되는 상황에서 사용된다.

Tunnel Mode (터널 모드)

• IP 패킷 전체(IP 헤더 + 데이터)를 암호화하고,
• 이 암호화된 패킷을 새로운 IP 헤더를 덧붙여 다시 감싼다.
• 결과적으로 암호화된 패킷을 또 하나의 IP 패킷 안에 터널링(tunneling)하는 구조가 된다.
• 주로 VPN(Virtual Private Network)이나 라우터 간 보안 연결에 사용된다.

이 방식은 예를 들어 회사 지점 간의 통신이나, 원격 사용자가 사내망에 안전하게 접속하는 경우에 사용된다.

📡 IPSec 프로토콜

IPSec은 두 개의 서로 다른 프로토콜 중 하나를 선택해 동작한다. 각 프로토콜은 보안 목표에 따라 다른 기능을 제공한다.

AH (Authentication Header)

AH는 이름 그대로 IP 패킷에 인증(authentication)과 무결성 검증(integrity) 기능을 추가하는 프로토콜이다.

• 송신자가 누구인지 확인할 수 있다. (출처 인증)
• 데이터가 전송 중에 변조되지 않았음을 보장한다. (무결성)
• 하지만 데이터 자체를 암호화하지는 않는다.

즉, 중간에 있는 공격자가 패킷 내용을 읽을 수는 있지만, 패킷을 위조하거나 조작하면 즉시 탐지된다. AH는 IP 패킷 전체(데이터 + 일부 IP 헤더 필드 포함)를 기반으로 검증 정보를 생성하므로 헤더 자체가 바뀌면 인증이 실패한다. 그만큼 민감하지만 정밀한 인증도 가능하다.

ESP (Encapsulation Security Protocol)

ESP는 AH보다 더 넓은 보안 범위를 가진다.

• 기밀성(confidentiality): 패킷 데이터를 암호화해 중간에서 내용을 볼 수 없게 만든다.
• 무결성 + 인증: AH처럼 위조와 변조도 탐지할 수 있다.

즉, AH의 모든 기능 + 암호화 기능까지 제공하는 통합적인 보안 프로토콜이다. 실제로 IPsec을 사용하는 대부분의 경우 ESP가 AH보다 훨씬 더 많이 사용된다. 특히 VPN 구성이나 터널 모드에서는 거의 항상 ESP를 사용한다.

📡 Security Associations (SAs)

IPsec은 패킷 하나하나를 독립적으로 암호화하지 않는다. 그보다는 먼저 서로 통신할 두 엔티티 간에 보안 설정 정보를 공유하고, 그 정보를 바탕으로 나중의 패킷들을 보호하는 방식으로 동작한다. 이때 만들어지는 가상의 보안 연결을 Security Association, 줄여서 SA라고 한다.

SA는 일종의 보안용 가상 연결 상태(state)로 데이터를 보내기 전에 반드시 먼저 설정해야 한다. TCP가 연결 수립 후 상태 정보를 관리하듯이, IPsec도 SA를 통해 연결 상태를 기억한다.

SA가 포함하는 정보

각 SA는 단방향이며, 송신 측에서 수신 측으로 가는 보안 연결에 대해 다음과 같은 정보를 저장한다.

• SPI (Security Parameter Index): 32비트 숫자로, 어떤 SA인지 식별하는 역할을 한다.
• 송신자/수신자 IP 주소: 어떤 엔티티 간의 연결인지 명시
• 암호화 알고리즘: 사용 중인 암호화 방식 (예: AES-CBC, 3DES 등)
• 암호화 키: 해당 연결에서 사용하는 대칭키
• 무결성 확인 방식: 어떤 해시 함수를 사용하는지 (예: HMAC-SHA256)
• 인증 키: 메시지 인증을 위한 키

이 정보들은 송신자와 수신자가 동일한 방식으로 패킷을 암호화하고 해석할 수 있도록 해준다. SA가 없다면 패킷을 어떻게 처리해야 할지 전혀 알 수 없게 된다.

SA는 왜 중요한가?

IP는 본래 상태를 기억하지 않는 구조다. 반면 IPsec은 보안을 위해 다음과 같은 동작이 필요하다.

• ‘이 패킷은 어떤 알고리즘으로 암호화해야 하지?’
• ‘검증할 때 사용할 키는 어떤 것이었지?’
• ‘이 암호문은 무결성을 어떻게 확인해야 하지?’

이 모든 질문에 답해주는 것이 SA다. IPsec은 ‘상태 없는 IP 위에 상태를 얹는 구조’를 통해 보안을 구현한다.

📡 IPSec datagram

IPsec에서 ESP(Encapsulation Security Protocol)는 암호화와 인증을 동시에 제공하는 프로토콜이다. 특히 터널 모드에서는 하나의 IP 패킷 전체를 암호화하고 다시 새로운 IP 헤더를 덧붙여 전송한다. 이 과정을 통해 원래의 IP 주소와 데이터를 모두 보호할 수 있게 된다.

• 먼저, 패킷의 가장 앞에는 새로운 IP 헤더가 추가된다.
  • 실제로 통신이 이루어지는 양 끝단(ex, VPN 게이트웨이 간의 주소 정보)을 담고 있다. 외부에서는 이 헤더만 보일 뿐, 실제 목적지 IP나 내부 구조는 전혀 드러나지 않는다.
• 그 다음에는 ESP 헤더가 위치한다.
  • 이 안에는 SPI(Security Parameter Index)와 시퀀스 번호가 담겨 있다. SPI는 수신 측에서 어떤 보안 연결(Security Association)을 기반으로 이 패킷을 처리해야 하는지를 알려주는 식별자 역할을 한다.
  • 시퀀스 번호는 리플레이 공격을 방지하는 데 사용되고 수신 측은 이 번호를 통해 중복된 패킷을 걸러낼 수 있다.
• ESP 헤더 다음에는 암호화된 부분이 온다.
  • 이 부분은 원래 IP 패킷의 내용 전체, 즉 원래의 IP 헤더와 실제 데이터(payload)를 포함한다. 암호화가 적용되기 때문에 이 영역은 네트워크 상에서 완전히 숨겨진다. 공격자는 출발지나 목적지 주소뿐 아니라, 어떤 서비스가 사용 중인지조차 알 수 없다.
  • 맨 뒤에는 ESP 트레일러가 따라온다. 트레일러에는 블록 암호 방식에 따라 추가된 패딩 정보가 포함되고 패딩의 길이와 그 뒤에 어떤 프로토콜이 들어 있는지를 알려주는 식별자도 함께 존재한다. 이를 통해 수신자는 원래 데이터의 경계를 정확히 복원할 수 있다.
• 마지막에는 인증 값을 담은 영역이 있다.
  • 송신 측과 수신 측이 공유하는 비밀 키를 기반으로 계산된 이 메시지 인증 코드(MAC)는, 패킷이 전송 중에 변경되지 않았음을 보장해준다. 수신자는 이를 검증함으로써 무결성과 출처의 진위를 동시에 확인할 수 있다.

데이터를 암호화하는 것과 더불어 누가 보냈는지, 중간에서 바뀌지는 않았는지를 함께 확인할 수 있게 해준다. 터널 모드에서는 기존 IP 패킷이 완전히 감춰지기 때문에 통신 경로와 목적지까지도 외부에 드러나지 않는다.

📡 ESP tunnel mode

왜 이런 처리가 필요한가

IPsec에서 ESP(Encapsulation Security Protocol)를 사용할 때, 특히 터널 모드(tunnel mode는 데이터 보호를 넘어 전체 IP 패킷 자체를 은닉하고 보호하는 데 초점이 맞춰져 있다. 이 모드는 VPN(Virtual Private Network)처럼 서로 떨어진 네트워크 간에 보안 터널을 만들어야 하는 경우에 자주 사용된다.

기존의 IP는 ‘누가 누구에게 무엇을 보내는가’를 아주 명확하게 보여주기 때문에, 패킷을 중간에서 가로채거나 분석하는 것이 어렵지 않다. 이때 ESP 터널 모드를 사용하면, 원래의 IP 패킷 전체를 암호화한 뒤, 새로운 IP 헤더를 덧붙여 외부에서는 내부 정보가 보이지 않도록 감출 수 있다. 즉 데이터뿐 아니라 주소 정보까지 보호한다는 점에서 매우 강력한 보안 기능을 제공한다.

송신 측(R1)에서는 무슨 일이 벌어지는가

ESP 터널 모드에서 송신자는 다음과 같은 과정을 통해 패킷을 가공한다. 이 작업은 모두 사전에 설정된 보안 연결(Security Association, SA) 정보를 기반으로 이루어진다.

먼저 R1은 원래의 IP 패킷을 그대로 보존한 채 그 뒤에 ESP 트레일러를 추가한다. 이 트레일러는 블록 암호 방식에 맞게 데이터 길이를 조정할 수 있도록 패딩을 포함하고 있고 복호화할 때 필요한 프로토콜 정보도 함께 담는다. 암호화 준비 단계라고 볼 수 있다.

이제 원래의 IP 패킷과 방금 추가한 트레일러까지 포함된 전체 내용이 한꺼번에 암호화된다. 이때 사용되는 알고리즘과 키는 SA에 미리 지정되어 있고 대칭키 방식(ex, AES)이 일반적이다. 암호화가 완료되면 패킷의 내부 구조는 전혀 알아볼 수 없게 된다.

그 다음, 암호화된 블록의 앞쪽에 ESP 헤더가 붙는다. 이 안에는 SPI(Security Parameter Index)와 시퀀스 번호가 포함되어 있는데, 이는 수신 측에서 어떤 방식으로 복호화하고 어떤 키를 써야 하는지를 구분할 수 있게 해준다. 또한 시퀀스 번호는 리플레이 공격(패킷 재전송을 통한 위조 시도)을 방지하는 데도 사용된다.

이제 거의 완성된 ESP 패킷에 대해 R1은 전체 암호화된 부분에 대해 메시지 인증 코드(MAC)를 계산한다. 이 MAC은 송신자와 수신자만 공유하는 비밀 키로 생성되고 패킷이 전송 중에 변조되지 않았음을 확인하는 데 쓰인다. 계산된 MAC은 패킷의 마지막에 추가된다.

모든 보안 처리가 완료되면 R1은 새로운 IP 헤더를 만들어 이 암호화된 ESP 패킷을 감싼다. 이 새 헤더에는 터널의 종단 지점(ex, 수신 라우터)의 IP 주소가 담긴다. 외부에서는 이 헤더만 보이기 때문에 실제 송신자와 수신자의 내부 IP 정보는 완전히 숨겨진다.

📡 IPSec sequence numbers

왜 필요한가

네트워크에서 보안 기능이 제대로 작동하더라도, 공격자는 여전히 이미 유효했던 패킷을 그대로 다시 보내는 공격, 즉 리플레이 공격(replay attack)을 시도할 수 있다.

이런 공격은 암호화된 내용을 읽지 못하더라도, 과거에 통과했던 유효한 패킷을 재전송함으로써 시스템을 교란시키는 데 사용할 수 있다. 예를 들어, 한 번만 실행돼야 하는 송금 요청을 다시 보내면 심각한 문제가 발생할 수 있다.

IPsec은 이런 상황을 막기 위해 각 패킷마다 고유한 시퀀스 번호를 부여해 같은 패킷이 두 번 이상 도착하지 않았는지를 확인한다.

동작 방식

보안 연결(Security Association, SA)이 새롭게 설정되면 송신 측은 시퀀스 번호를 0부터 시작한다. 그 후 패킷이 하나 전송될 때마다 번호를 1씩 증가시키고 해당 번호를 ESP 헤더 안에 포함시킨다.

수신 측에서는 시퀀스 번호를 통해 아래와 같이 리플레이 공격을 방지한다.

1. 현재까지 받은 시퀀스 번호를 추적해 새로 도착한 번호가 이전에 본 적 없는 값인지 확인한다.
2. 이미 처리한 번호와 동일한 시퀀스 번호가 다시 들어오면 중복된 패킷으로 간주하고 무시한다.

이때 수신 측은 모든 시퀀스 번호를 무한히 기억하지는 않는다. 대신 ‘슬라이딩 윈도우(sliding window)’ 방식을 사용한다. 예를 들어 최근 64개의 시퀀스 번호만 추적하면서 그 범위 내에서만 중복 여부를 검사한다.

📡 IPSec security database

IPsec은 IP 계층에서 동작하는 보안 프로토콜인 만큼, 개별 패킷에 대해 다음과 같은 질문에 답을 해 볼 필요가 있다.

1. 이 패킷에 보안을 적용할지 말지, 적용한다면 어떤 기준으로?
2. 적용한다면 구체적으로 어떤 방식과 키, 알고리즘으로 처리할지?

이 두 질문에 각각 답해주는 것이 바로 SPD와 SAD, 두 개의 보안 데이터베이스이다. IPsec이 자동으로 패킷을 검사하고 암호화하거나 인증할 수 있는 건 이 두 구조 덕분이다.

SPD (Security Policy Database)

SPD는 보안 정책(Security Policy)을 저장해 두는 데이터베이스다. 이곳에는 어떤 IP 패킷에 IPsec을 적용할지, 적용한다면 어떤 방식(ex, AH, ESP)을 사용할지에 대한 조건이 정리되어 있다.

예를 들어 다음과 같은 조건이 SPD에 기록될 수 있다.

• 출발지 IP가 192.168.1.0/24이고 목적지 IP가 203.0.113.42이며 TCP 포트가 443이면 ESP 암호화를 사용한다.
• 내부망 주소로 가는 DNS 트래픽은 암호화하지 않고 그냥 통과한다.

송신자는 각 패킷에 대해 “이건 IPsec 처리 대상인가?“를 판단할 수 있게 된다. 따라서 SPD는 ‘무엇을 해야 하는가’를 결정하는 장치라고 볼 수 있다.

SAD (Security Association Database)

SPD가 ‘무엇을 해야 하는지’ 알려줬다면, SAD는 그 다음 단계인 ‘어떻게 할 것인가’를 구체적으로 실행하는 데 필요한 정보를 담고 있다. 여기에는 각 보안 연결(Security Association, SA)의 상태 정보가 저장되어 있다.

• 이 연결에서는 어떤 암호화 알고리즘을 사용할 것인지,
• 어떤 키를 사용할지,
• 어떤 SPI 번호가 할당되어 있는지,
• 어떤 무결성 검사 방식을 사용할지,

같은 세부 정보가 SAD에 기록된다.

송신 측에서 IPsec 처리가 필요한 패킷을 만나면, 먼저 SPD를 통해 그 정책을 확인한 뒤 해당 정책이 지정한 SA를 SAD에서 찾아 패킷을 암호화하거나 인증하게 된다. 수신 측도 마찬가지다. IPsec 패킷이 도착하면 그 안에 포함된 SPI 값을 기준으로 SAD에서 일치하는 SA를 찾아 해당 방식대로 복호화와 인증을 수행한다.

📡 IKE

IPsec을 사용하려면 먼저 보안 연결(Security Association, SA)을 설정해야 한다. SA에는 어떤 알고리즘을 사용할지, 어떤 키를 쓸지, 어떤 SPI(Security Parameter Index) 번호를 부여할지 같은 세부 정보가 담긴다.

예를 들어 하나의 SA는 다음과 같이 구성될 수 있다.

• SPI: 12345
• 출발지 IP: 200.168.1.100
• 목적지 IP: 193.68.2.23
• 사용 프로토콜: ESP
• 암호화 알고리즘: 3DES-CBC
• 인증 알고리즘: HMAC-MD5
• 암호화 키: 0x7aeaca…
• 인증 키: 0xc0291f…

이렇게 구성된 SA는 송신자와 수신자 모두에게 동일하게 설정되어 있어야 IPsec이 제대로 동작할 수 있다. 그런데 이 과정을 수동으로 설정한다면, 설정 실수나 관리 복잡성 문제가 쉽게 생긴다. 특히 VPN처럼 수십, 수백 개의 네트워크 노드 간에 연결을 맺어야 하는 경우, 이런 수동 설정은 사실상 불가능에 가깝다.

바로 이 점에서 IKE(Internet Key Exchange)가 필요해진다.

IKE의 역할

IKE는 서로 통신하려는 양쪽 IPsec 엔드포인트가 서로를 인증하고, 자동으로 SA를 설정할 수 있도록 해주는 프로토콜이다. 수동으로 설정하던 SPI, 키, 알고리즘 등을 IKE가 실시간으로 협상하고 교환해준다. 복잡한 키 설정과 보안 정책을 수동으로 구성하는 부담 없이도 IPsec을 안정적으로 운영할 수 있게 된다.

📡 PSK, PKI

IKE는 서로를 인증하는 방식으로 두 가지 방법을 제공한다. 하나는 사전에 비밀을 공유하는 방식(PSK)이고, 다른 하나는 공개키 기반 구조(PKI)를 사용하는 방식이다.

PSK (Pre-Shared Key)

PSK 방식에서는 양쪽이 이미 같은 비밀 값을 사전에 공유하고 있다는 전제 하에 시작한다. 이 비밀 키를 바탕으로 서로의 정체를 확인하고, IKE는 여기에 기반해 양방향 IPsec SA를 설정한다.

각 SA는 암호화 키와 인증 키를 포함하고 있으며, 통신이 가능한 두 개의 SA(송신용, 수신용)가 만들어진다. 구현이 간단하고 설정이 빠르지만, 비밀 키를 미리 안전하게 공유해야 한다는 부담이 있다. 작은 규모나 고정된 환경에서는 유용하지만 키 관리가 어려운 대규모 네트워크에는 부적합할 수 있다.

PKI (Public Key Infrastructure)

PKI 방식에서는 각 통신 주체가 자신의 공개키/개인키 쌍과 자신의 신원을 증명하는 디지털 인증서를 갖고 시작한다. 이 인증서는 보통 신뢰할 수 있는 인증 기관(CA)이 발급한다.

IKE는 이 인증서를 사용해 서로를 인증하고, 이후 동일하게 양방향 IPsec SA를 설정한다. 이 방식은 TLS나 HTTPS에서 사용하는 공개키 기반 핸드셰이크와 구조가 매우 비슷하다. PKI는 키 공유 없이도 안전한 인증이 가능하고 중앙 관리가 가능하기 때문에 대규모 조직이나 공공 네트워크 환경에 적합하다.

IKE(Internet Key Exchange)는 IPsec에서 보안 연결을 자동으로 설정하기 위해 사용되는 프로토콜이다. 이 과정은 단순히 키를 교환하는 것이 아니라, 서로를 인증하고, 필요한 보안 설정을 협상하며, 이후 사용할 키와 알고리즘을 결정하는 복잡한 절차를 포함한다.

이 과정을 효율적이고 안전하게 진행하기 위해 IKE는 **두 개의 단계(Phase 1과 Phase 2)**로 나뉘어 동작한다.

Phase 1: IKE SA 설정

첫 번째 단계에서는 IKE 자체의 통신을 보호하기 위한 보안 연결인 IKE SA(IKE Security Association)를 설정한다.

이 SA는 우리가 평소 IPsec에서 사용하는 SA와는 다르다. ISAKMP SA(ISAKMP: Internet Security Association and Key Management Protocol)라고도 불린다.

이 단계의 목적은 다음과 같다.

• 서로의 정체를 인증 (PSK 또는 인증서 사용)
• 공유된 세션 키를 생성 (보통 Diffie-Hellman 방식)
• 이후 통신을 위한 안전한 채널 형성

Phase 1이 끝나면, 양쪽은 IKE 프로토콜 자체를 안전하게 사용할 수 있는 기반을 확보하게 된다. 이 단계에는 두 가지 모드가 있다.

• Main Mode: 더 많은 메시지를 주고받지만, 사용자의 정체를 암호화하여 보호할 수 있어 보안성이 높다.
• Aggressive Mode: 메시지 수가 적고 빠르지만, 상대적으로 식별 정보가 노출될 수 있다.

실제 운영 환경에서는 보안이 중요한 경우 대부분 Main Mode가 사용된다.

Phase 2: IPsec SA 설정

Phase 1에서 안전한 채널이 형성되면, 그 위에서 실제 IPsec 통신에 사용할 SA들을 협상하고 설정하는 단계가 Phase 2다.

이 단계에서는 다음과 같은 작업이 수행된다.

• 암호화 및 인증 알고리즘 선택 (예: AES, HMAC-SHA)
• IPsec SA 각각에 대한 키 생성
• SA 수명, SPI 등 파라미터 협상

이 과정을 통해 양쪽은 양방향 IPsec SA(송신용, 수신용)를 갖추게 되고 이후의 실제 데이터 전송은 이 설정을 바탕으로 암호화되고 인증된다.