맨위로가기

IPsec

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

IPsec(Internet Protocol Security)은 인터넷 프로토콜(IP) 네트워크에서 안전한 통신을 제공하는 개방형 표준 프로토콜 제품군이다. 1970년대부터 개발이 시작되어, 1992년 IETF에서 표준화 작업이 진행되었으며, 인증 헤더(AH)와 캡슐화 보안 페이로드(ESP) 프로토콜을 사용하여 데이터 무결성, 인증, 기밀성을 제공한다. IPsec은 두 피어 간의 보안 연관(SA)을 설정하여 안전한 통신을 가능하게 하며, IKE(Internet Key Exchange) 프로토콜을 통해 SA를 구축한다. IKEv1과 IKEv2가 있으며, IKEv2가 IKEv1보다 개선되었다.

더 읽어볼만한 페이지

  • 터널링 프로토콜 - PPPoE
    PPPoE는 이더넷을 통해 PPP 연결을 설정하는 네트워크 프로토콜로, DSL과 같은 광대역 환경에서 클라이언트-서버 모델로 동작하며, 사용자의 컴퓨터를 ISP에 연결하는 데 사용되고, 디스커버리 및 PPP 세션 단계를 거쳐 연결을 설정하며 전 세계에서 널리 쓰인다.
  • 터널링 프로토콜 - 점대점 터널링 프로토콜
    점대점 터널링 프로토콜(PPTP)은 VPN 구축을 위해 개발되었으나 보안 취약점으로 인해 사용이 권장되지 않으며 대한민국에서는 정부 및 공공기관에서 사용이 금지된 프로토콜이다.
  • 가상사설망 - 계층 2 터널링 프로토콜
    계층 2 터널링 프로토콜(L2TP)은 두 네트워크 노드 간 터널을 생성하여 데이터를 전송하는 데 사용되는 네트워크 프로토콜로, L2F와 PPTP에서 비롯되어 RFC 2661로 표준화되었으며, 자체 보안 기능이 없어 IPsec과 함께 사용되어 L2TP/IPsec으로 보안을 강화한다.
  • 가상사설망 - 데이터그램 전송 계층 보안
    데이터그램 전송 계층 보안(DTLS)은 신뢰성 없는 전송 계층 프로토콜을 사용하는 애플리케이션을 위한 보안 프로토콜로, TLS를 기반으로 데이터그램 기반 프로토콜의 특성을 고려한 보안 기능을 제공하며 VPN, WebRTC 등 다양한 분야에서 활용된다.
  • 네트워크 계층 프로토콜 - IPv6
    IPv6는 IPv4 주소 고갈 문제를 해결하고자 개발된 차세대 인터넷 프로토콜로, 128비트 주소 체계를 통해 사실상 무한대에 가까운 IP 주소를 제공하며, 주소 자동 설정, 패킷 처리 효율성 향상, 보안 기능 강화 등의 특징을 갖는다.
  • 네트워크 계층 프로토콜 - X.25
    X.25는 CCITT가 1970년대 중반에 개발한 패킷 교환 데이터 통신 표준으로, 가상 회선 서비스 기반의 3계층 구조를 가지며 공중 데이터망의 기반이 되었으나 1990년대 초부터 프레임 릴레이와 TCP/IP로 대체되기 시작하여 현재는 일부 시스템 및 아마추어 무선 분야에서 사용된다.
IPsec

2. 역사

1970년대 초부터 방위고등연구계획국(DARPA)은 네이티브 ARPANET 패킷 암호화 및 TCP/IP 패킷 암호화를 위한 일련의 실험적인 ARPANET 암호화 장치를 후원했다.[2] 1986년부터 1991년까지 국가안보국(NSA)은 보안 데이터 네트워크 시스템(SDNS) 프로그램을 통해 인터넷용 보안 프로토콜 개발을 후원했으며, 모토로라 등 다양한 공급업체가 참여했다.[2] 이 작업은 1988년경부터 국립표준기술연구소(NIST)에서 공개적으로 발표되었으며, ''계층 3의 보안 프로토콜''(SP3)은 ISO 표준 네트워크 계층 보안 프로토콜(NLSP)로 발전했다.[3]

1992년, 미국 해군 연구소(NRL)는 DARPA CSTO로부터 IPv6를 구현하고 4.4 BSD에서 IP 암호화를 연구 및 구현하는 자금을 지원받았다.[5] NRL은 IPsec에 대한 IETF 표준 트랙 사양(RFC 1825 ~ RFC 1827)을 개발했으며,[5] NRL의 IPsec 구현은 1996년 USENIX 컨퍼런스 회보에 실린 논문에 설명되어 있다.[4] NRL의 오픈 소스 IPsec 구현은 MIT에서 온라인으로 제공되었으며, 대부분의 초기 상용 구현의 기반이 되었다.[5]

1992년 인터넷 기술 특별 작업반(IETF)은 IP에 대한 공개적으로 지정된 보안 확장인 ''IPsec''을 표준화하기 위해 IP 보안 워킹 그룹을 결성했다.[6] NRL이 개발한 표준은 IETF에서 RFC 1825부터 RFC 1827까지 발표되었다.[7] 1993년 12월, 소프트웨어 IP 암호화 프로토콜 :en:swIPe (protocol)은 컬럼비아 대학교와 AT&T 벨 연구소에서 존 요아니디스 등에 의해 연구되었다.

1995년, IETF의 IPsec 작업반은 오픈하고 자유롭게 이용할 수 있는 버전의 프로토콜 작성을 시작, 보안 데이터 네트워크 시스템(SDNS) 프로젝트에 관한 미국 국가 안보국의 계약 하에 개발되었다. SDNS 프로젝트가 정의한 보안 프로토콜 레이어 3(SP3)는 NIST에 의해 공개되었고, ISO의 네트워크 계층 보안 프로토콜(NLSP)[48]의 기초가 되었다. IPsec은 공식적으로 인터넷 엔지니어링 태스크 포스(IETF)의 Request for Comments(RFC) 일련의 문서로 표준화되어, 다양한 컴포넌트와 확장에 대응하고 있다.[49]

2. 1. 초기 개발

1970년대 초부터 방위고등연구계획국(DARPA)은 네이티브 ARPANET 패킷 암호화 및 TCP/IP 패킷 암호화를 위한 일련의 실험적인 ARPANET 암호화 장치를 후원했다.[2] 1986년부터 1991년까지 국가안보국(NSA)은 보안 데이터 네트워크 시스템(SDNS) 프로그램을 통해 인터넷용 보안 프로토콜 개발을 후원했으며, 모토로라 등 다양한 공급업체가 참여했다.[2] 이 작업은 1988년경부터 국립표준기술연구소(NIST)에서 공개적으로 발표되었으며, ''계층 3의 보안 프로토콜''(SP3)은 ISO 표준 네트워크 계층 보안 프로토콜(NLSP)로 발전했다.[3]

1992년, 미국 해군 연구소(NRL)는 DARPA CSTO로부터 IPv6를 구현하고 4.4 BSD에서 IP 암호화를 연구 및 구현하는 자금을 지원받았다.[5] NRL은 IPsec에 대한 IETF 표준 트랙 사양(RFC 1825 ~ RFC 1827)을 개발했으며,[5] NRL의 IPsec 구현은 1996년 USENIX 컨퍼런스 회보에 실린 논문에 설명되어 있다.[4] NRL의 오픈 소스 IPsec 구현은 MIT에서 온라인으로 제공되었으며, 대부분의 초기 상용 구현의 기반이 되었다.[5]

1992년 인터넷 기술 특별 작업반(IETF)은 IP에 대한 공개적으로 지정된 보안 확장인 ''IPsec''을 표준화하기 위해 IP 보안 워킹 그룹을 결성했다.[6] NRL이 개발한 표준은 IETF에서 RFC 1825부터 RFC 1827까지 발표되었다.[7] 1993년 12월, 소프트웨어 IP 암호화 프로토콜 :en:swIPe (protocol)은 컬럼비아 대학교와 AT&T 벨 연구소에서 존 요아니디스 등에 의해 연구되었다.

1995년, IETF의 IPsec 작업반은 오픈하고 자유롭게 이용할 수 있는 버전의 프로토콜 작성을 시작, 보안 데이터 네트워크 시스템(SDNS) 프로젝트에 관한 미국 국가 안보국의 계약 하에 개발되었다. SDNS 프로젝트가 정의한 보안 프로토콜 레이어 3(SP3)는 NIST에 의해 공개되었고, ISO의 네트워크 계층 보안 프로토콜(NLSP)[48]의 기초가 되었다. IPsec은 공식적으로 인터넷 엔지니어링 태스크 포스(IETF)의 Request for Comments(RFC) 일련의 문서로 표준화되어, 다양한 컴포넌트와 확장에 대응하고 있다.[49]

2. 2. IETF 표준화

1992년, 미국 해군 연구소(NRL)는 방위고등연구계획국(DARPA) CSTO로부터 자금을 지원받아 IPv6를 구현하고 4.4 BSD에서 IP 암호화를 연구 및 구현했으며, SPARC 및 x86 CPU 아키텍처를 모두 지원했다.[5] DARPA는 MIT를 통해 이 구현을 자유롭게 사용할 수 있도록 했다. NRL은 IPsec에 대한 IETF 표준 트랙 사양(RFC 1825 ~ RFC 1827)을 개발했다.[5] NRL의 IPsec 구현은 1996년 USENIX 컨퍼런스 회보에 실린 논문에 설명되어 있으며,[4] 대부분의 초기 상용 구현의 기반이 되었다.[5]

인터넷 기술 특별 작업반(IETF)은 1992년에 IP에 대한 공개적으로 지정된 보안 확장인 ''IPsec''을 표준화하기 위해 IP 보안 워킹 그룹을 결성했다.[6] NRL이 개발한 표준은 IETF에서 RFC 1825부터 RFC 1827까지 발표되었다.[7] IPsec 프로토콜은 원래 1995년에 게시된 RFC 1825에서 RFC 1829까지 정의되었다.

1995년, IETF의 IPsec 작업반은 보안 데이터 네트워크 시스템(SDNS) 프로젝트에 관한 미국 국가 안보국의 계약 하에 개발된 오픈하고 자유롭게 이용할 수 있는 버전의 프로토콜 작성을 시작했다.[48]

IPsec은 공식적으로 인터넷 엔지니어링 태스크 포스(IETF)의 Request for Comments(RFC) 문서로 표준화되었으며, 프로토콜 명칭은 ''IPsec''로 표기하도록 정해져 있다.[49]

2. 3. NSA 간섭 의혹

2013년, 스노든 문서를 통해 미국 국가안보국(NSA)이 불런 프로그램의 일환으로 상업용 암호화 시스템, IT 시스템, 네트워크 및 통신 장치에 취약점을 삽입하려 했다는 사실이 드러났다.[27] IPsec이 이러한 표적 중 하나였다는 주장이 제기되었다.[28]

OpenBSD IPsec 스택과 관련하여, OpenBSD의 수석 개발자 테오 데 라트는 2010년 FBI에서 일하는 제이슨 라이트 등이 OpenBSD 암호화 코드에 백도어를 삽입했다는 주장이 담긴 서신을 받았다고 밝혔다.[29] 제이슨 라이트는 이러한 주장을 부인하며, OpenBSD 운영 체제나 OpenBSD 암호화 프레임워크 (OCF)에 백도어를 추가하지 않았다고 반박했다.[30] 데 라트는 NETSEC이 백도어를 작성하도록 계약했을 가능성이 있지만, 해당 백도어가 OpenBSD 트리에 포함되지는 않았을 것이라고 언급했다.[31]

로그잼 공격 연구자들은 NSA가 디피-헬만 알고리즘을 약화시켜 IPsec VPN을 손상시켰다는 다른 설명을 제시했다.[32] 이들은 NSA가 특정 소수와 생성자에 대한 곱셈 부분군을 미리 계산하기 위해 컴퓨팅 클러스터를 구축했다고 주장한다.

또 다른 설명으로는 Equation Group이 여러 VPN 장비에 대해 제로데이 익스플로잇을 사용했다는 것이다. 이들은 카스퍼스키 랩에 의해 Equation Group과 연관된 것으로 확인되었고,[33] 제조업체에서 실제 익스플로잇으로 확인되었으며, 일부는 노출 당시 제로데이 익스플로잇이었다.[34][35][36] 시스코 PIX 및 ASA 방화벽에는 NSA가 도청에 사용한 취약점이 있었다.

또한, "공격 모드" 설정을 사용하는 IPsec VPN은 PSK의 해시를 평문으로 전송하여 오프라인 사전 공격에 취약하며, NSA가 이를 표적으로 삼았을 가능성이 제기된다.[32][37][38]

3. 보안 구조

IPsec 스위트는 개방형 표준이다. IPsec는 다음의 프로토콜을 사용하여 다양한 기능들을 수행한다:[50][51]


  • 인증 헤더(AH)는 IP 데이터그램에 대한 비연결 데이터 무결성과 데이터 출처 인증을 제공하며 IP 헤더 수정 공격 및 재생 공격으로부터 보호한다.
  • 캡슐화 보안 페이로드(ESP)는 기밀성, 비연결 데이터 무결성, 데이터 출처 인증, 재생 방지 서비스(부분 시퀀스 무결성의 한 형태), 제한된 트래픽 흐름 기밀성을 제공한다.
  • 인터넷 보안 연관 및 키 관리 프로토콜(ISAKMP)은 인증 및 키 교환 프레임워크를 제공하며,[8] 실제 인증된 키 자료는 사전 공유 키, 인터넷 키 교환(IKE 및 IKEv2), Kerberized Internet Negotiation of Keys(KINK) 또는 IPSECKEY DNS 레코드를 사용하여 수동으로 구성하여 제공된다. 그 목적은 AH 및/또는 ESP 작업에 필요한 알고리즘 및 매개변수 묶음과 함께 보안 연관(SA)을 생성하는 것이다.

IPsec은 두 개의 '''피어''' 사이에 '''SA''' (보안 연관성)라는 단방향 연결을 설정하여 피어 간의 안전한 통신을 확립한다. SA는 단방향이므로 양방향 통신을 수행하려면 상행 및 하행 2개의 SA를 설정해야 한다.

피어는 '''호스트'''와 '''보안 게이트웨이'''의 두 가지 유형으로 분류할 수 있다. 전자는 개인 단말기나 서버와 같은 IP 통신의 종단점에 해당하는 장치이다. 후자는 라우터와 같은 IP 통신의 중계를 담당하는 장치이다.

IPsec은 원칙적으로 피어가 어떤 유형인지 묻지 않는다. 따라서 호스트에서 호스트까지의 통신 전체를 직접 하나의 SA로 보호할 수도 있고, 두 개의 중계 지점마다 별도의 SA를 설정하여 통신을 보호하는 릴레이 형태의 운영도 가능하다.

IPsec의 각 피어는 '''SPD'''(security policy database, 보안 정책 데이터베이스), '''SAD'''(security association database, 보안 연관성 데이터베이스)라는 두 개의 데이터베이스를 관리한다.

SPD는 IP 주소, 프로토콜(TCP/UDP/ICMP 등), TCP 포트와 같은 정보에 따라 패킷을 폐기(discard)할지, IPsec을 사용하지 않고 전송(bypass IPsec)할지, IPsec을 사용하여 전송(apply IPsec)할지를 결정하는 '''보안 정책'''의 데이터베이스이다.

SAD는 각 피어와 SA를 설정할 때 사용하는 파라미터의 데이터베이스이다.

3. 1. 프로토콜

IPsec는 다음의 프로토콜을 사용하여 다양한 기능들을 수행한다:[50][51]

  • '''인증 헤더(AH)'''는 IP 데이터그램에 대한 비연결 데이터 무결성과 데이터 출처 인증을 제공하며 IP 헤더 수정 공격 및 재생 공격으로부터 보호한다.[9] IPv4에서 AH는 변경 가능한 필드를 제외한 IP 데이터그램의 IP 페이로드 및 모든 헤더 필드를 보호한다. IPv6에서 AH는 대부분의 IPv6 기본 헤더, AH 자체, AH 이후의 변경 불가능한 확장 헤더 및 IP 페이로드를 보호한다. AH는 IP 프로토콜 번호 51을 사용하여 IP 바로 위에서 작동한다.[10]
  • '''캡슐화 보안 페이로드(ESP)'''는 기밀성, 비연결 데이터 무결성, 데이터 출처 인증, 재생 방지 서비스(부분 시퀀스 무결성의 한 형태), 제한된 트래픽 흐름 기밀성을 제공한다. 전송 모드의 ESP는 전체 IP 패킷에 대한 무결성 및 인증을 제공하지 않지만, 터널 모드에서는 외부 헤더는 보호되지 않은 상태로 유지되면서 전체 내부 IP 패킷에 ESP 보호가 제공된다. ESP는 IP 프로토콜 번호 50을 사용하여 IP 상에서 직접 작동한다.[10]
  • '''보안 연관(SA)''' IPsec 프로토콜은 통신 당사자들이 알고리즘 및 키와 같은 공유 보안 속성을 설정하는 보안 연관을 사용한다. IPsec의 보안 연관은 인터넷 보안 연관 및 키 관리 프로토콜(ISAKMP)을 사용하여 설정된다. 발신 패킷에 대해 어떤 보호를 제공할지 결정하기 위해 IPsec은 보안 매개변수 색인(SPI)를 사용한다.


IPsec은 두 개의 '''피어''' 사이에 '''SA''' (보안 연관성)라는 단방향 연결을 설정하여 피어 간의 안전한 통신을 확립한다. SA는 단방향이므로 양방향 통신을 수행하려면 상행 및 하행 2개의 SA를 설정해야 한다.

3. 2. 동작 방식

IPsec 프로토콜 AH와 ESP는 호스트 간 전송 모드와 네트워크 터널링 모드로 구현될 수 있다.[19]

IPsec 모드


전송 모드에서는 일반적으로 IP 패킷의 페이로드만 암호화되거나 인증된다. IP 헤더는 수정되거나 암호화되지 않으므로 라우팅은 그대로 유지된다. 하지만 인증 헤더가 사용될 때는 IP 주소를 네트워크 주소 변환으로 수정할 수 없다. IP 주소를 수정하면 항상 해시 값이 무효화되기 때문이다. 전송 계층과 응용 계층은 항상 해시로 보호되므로 TCP 및 UDP 포트 번호를 포트 주소 변환으로 변환하는 방식으로 수정할 수 없다.

터널 모드에서는 전체 IP 패킷이 암호화되고 인증된다. 그런 다음 새 IP 헤더가 있는 새 IP 패킷에 캡슐화된다. 터널 모드는 네트워크 간 통신(예: 사이트를 연결하기 위한 라우터 간), 호스트-네트워크 간 통신(예: 원격 사용자 액세스) 및 호스트-호스트 간 통신(예: 개인 채팅)을 위한 가상 사설망을 만드는 데 사용된다.[19]

IPsec은 네트워크 계층에서 보안을 실현하는 프로토콜이기 때문에 애플리케이션 등 상위 계층이 암호화를 지원하지 않더라도 통신 전체의 보안을 확보할 수 있다.

3. 3. 암호화 알고리즘

IPsec은 다양한 암호화 알고리즘을 사용하여 데이터의 기밀성, 무결성 및 인증을 제공한다.

  • 기밀성을 위해 트리플 DES-CBC, AES-CBC 및 AES-CTR가 사용된다.
  • 무결성 보호 및 인증을 위해 HMAC-SHA1/SHA2가 사용된다.
  • 기밀성과 인증을 함께 제공하는 알고리즘으로는 AES-GCM 및 ChaCha20-Poly1305가 있다.


키 교환 알고리즘으로는 디피-헬만 (RFC 3526), ECDH (RFC 4753) 등이 사용된다. 인증 알고리즘으로는 RSA, ECDSA (RFC 4754), PSK (RFC 6617), EdDSA (RFC 8420) 등이 있다.

AH의 MAC으로는 AES-GMAC, AES-XCBC-MAC의 출력을 96비트로 자른 것(AES-XCBC-MAC-96)이 권장된다. NULL(MAC 없음)도 가능하다.

ESP의 인증 암호로는 AES-GCM가 권장된다. Encryption-then-Mac(EtM)형 인증 암호로는 암호 부분은 NULL(암호화하지 않음)과 AES-CBC가, MAC 부분은 HMAC-SHA1의 출력을 96비트로 자른 것(HMAC-SHA1-96), 키 길이 128비트의 AES-GMAC, AES-XCBC-MAC의 출력을 96비트로 자른 것(AES-XCBC-MAC-96)이 사용될수 있다.

과거의 경위에 기반하여 요구 수준이 설정되었지만, 안전성 및 효율성 관점에서 AH에는 AES-GMAC, ESP에는 AES-GCM을 사용하는 것이 권장된다.

3. 4. Keepalive

두 종단 간의 연결이 중단되지 않았는지 확인하기 위해, 종단점은 정기적인 간격으로 Keepalive 메시지를 교환하며, 이는 연결 중단으로 인해 손실된 터널을 자동으로 다시 설정하는 데에도 사용할 수 있다.

인터넷 키 교환(IKE) 피어가 작동 중지되었는지를 감지하는 방법으로 데드 피어 감지(DPD)가 있다. 이 방법은 IPsec 트래픽 패턴을 사용하여 피어의 가용성을 확인하는 데 필요한 메시지 수를 최소화한다. DPD는 피어가 죽은 것으로 판명된 경우 손실된 자원을 되찾는 데 사용되며, IKE 피어 페일오버를 수행하는 데에도 사용된다.

UDP Keepalive는 DPD의 대안이다.

4. 프로토콜 상세

4. 1. AH (Authentication Header)

터널 및 전송 모드에서 IPsec 인증 헤더 형식 사용


'''AH''' (Authentication Header, 인증 헤더)는 IPsec 프로토콜 제품군의 구성원으로, 해시 함수와 비밀 공유 키를 사용하여 데이터 무결성과 데이터 원본 인증을 보장한다.[9] 선택적으로 슬라이딩 윈도우 기술을 사용하여 재생 공격을 방지하고 오래된 패킷을 폐기할 수 있다.[9]

AH는 IPv4와 IPv6에서 헤더 삽입 공격과 옵션 삽입 공격을 방지한다. IPv4에서는 변경 가능한 필드를 제외한 IP 데이터그램의 IP 페이로드 및 모든 헤더 필드를 보호하며, IPv6에서는 대부분의 IPv6 기본 헤더, AH 자체, AH 이후의 변경 불가능한 확장 헤더 및 IP 페이로드를 보호한다. 변경 가능한 필드는 IPv4에서는 DSCP/ToS, ECN, 플래그, 단편화 오프셋, TTL 및 헤더 체크섬이고, IPv6에서는 DSCP, ECN, 흐름 레이블 및 홉 제한이다.[10][9] AH는 IP 프로토콜 번호 51을 사용하여 IP 바로 위에서 작동한다.[10]

AH는 인증 및 변조 방지 기능을 제공하지만, 데이터 자체는 암호화되지 않으므로 도청에는 취약하다.

AH 헤더 형식은 다음과 같다.[9]

style="background:#781549; color:white;" |''인증 (AH) 헤더'' 형식 (RFC2402/RFC4302 형식)
OffsetsOctet160123
Octet16Bit10012345678910111213141516171819202122232425262728293031
00다음 헤더페이로드 길이예약됨
432보안 매개 변수 인덱스 (SPI)
864순서 번호
C96무결성 검사 값 (ICV)
…
……


  • 다음 헤더: 보호된 상위 계층 프로토콜을 나타낸다. IP 프로토콜 번호 목록에서 값을 가져온다.
  • 페이로드 길이: 2를 뺀 이 ''인증 헤더''의 길이(4옥텟 단위)이다. IPv6 패킷에서는 8옥텟의 배수여야 한다.
  • 예약됨: 향후 사용을 위해 예약된 필드이며, 모두 0으로 설정된다.
  • 보안 매개변수 색인(SPI): 수신 측의 보안 연관을 식별하는 데 사용되는 임의의 값이다.
  • 순서 번호: 단조롭게 증가하는 시퀀스 번호로, 재생 공격을 방지하는 데 사용된다.
  • 무결성 검사 값(ICV): 가변 길이 검사 값이다. IPv6에서는 8옥텟 경계, IPv4에서는 4옥텟 경계에 필드를 정렬하기 위한 패딩이 포함될 수 있다.

4. 2. ESP (Encapsulated Security Payload)

IPsec Encapsulating Security Payload(ESP)의 터널 및 전송 모드 사용


'''Encapsulating Security Payload''' (ESP)는 IPsec 프로토콜 제품군의 구성 요소로, 인증을 통한 원본 인증, 해시 함수를 통한 데이터 무결성, IP 패킷에 대한 암호화 보호를 통한 기밀성을 제공한다.[13][14][15] ESP는 암호화 전용 및 인증 전용 구성도 지원하지만, 인증 없이 암호화를 사용하는 것은 안전하지 않으므로 권장되지 않는다.

인증 헤더(AH)와 달리, 전송 모드의 ESP는 전체 IP 패킷에 대한 무결성 및 인증을 제공하지 않는다. 그러나 전체 원본 IP 패킷이 새로운 패킷 헤더와 함께 캡슐화되는 터널 모드에서는 외부 헤더(외부 IPv4 옵션 또는 IPv6 확장 헤더 포함)는 보호되지 않은 상태로 유지되면서 전체 내부 IP 패킷(내부 헤더 포함)에 ESP 보호가 제공된다.

ESP는 IP 프로토콜 번호 50을 사용하여 IP 상에서 직접 작동한다.[10]

ESP는 페이로드 부분을 암호화한다. 정확히는 IP 헤더, 경로 헤더, 홉 바이 홉 옵션 헤더를 제외한 부분이 암호화된다. RFC 2406 / RFC 4303 형식의 ESP에는 옵션으로 "인증 트레일러" 기능이 있어, AH를 병용하지 않고도 변조 방지 기능을 이용할 수 있게 되었다 (단, 보장되는 것은 데이터 부분뿐이며, IP 헤더 부분의 변조를 감지할 수는 없다). 또한 후자에는 AH와 마찬가지로 재생 공격 방지 기능도 추가되었다.

ESP 헤더는 IP 헤더 다음에 삽입되며, 다음 필드를 포함한다.

필드크기설명
보안 매개변수 인덱스 (SPI)32 비트수신 측의 보안 연관성을 식별하기 위해 (대상 IP 주소와 함께) 사용되는 임의의 값.
순서 번호32 비트단조 증가 시퀀스 번호 (전송되는 모든 패킷에 대해 1씩 증가)는 재생 공격으로부터 보호하기 위해 사용된다. 모든 보안 연관에 대해 별도의 카운터가 유지된다.
페이로드 데이터가변 길이암호화 알고리즘에 대한 초기화 벡터 등, 콘텐츠를 보호하는 데 사용되는 데이터를 포함하는, 원래 IP 패킷의 보호된 콘텐츠. 보호된 콘텐츠 유형은 다음 헤더 필드로 표시된다.
패딩0-255 옥텟선택 사항. 암호화의 암호 블록 크기에 맞는 크기로 페이로드 데이터를 확장하고 다음 필드를 정렬하기 위한 암호화용 패딩.
패드 길이8 비트패딩의 크기(옥텟 단위).
다음 헤더8 비트페이로드 데이터의 프로토콜 유형을 나타낸다. 예를 들어 TCP의 값은 6이다. ESP는 캡슐화 프로토콜이므로, IP in IP를 나타내는 값 4도 가능하다. 값 41은 IPv6가 IPv4에 캡슐화됨을 나타낸다, 예를 들어 6to4. 값 59 (의미: 다음 헤더 없음)는 스트림에 삽입될 수 있으며, 내용이 삭제되어야 하는 더미 패킷에 사용된다.
무결성 검사 값 (ICV)가변 길이가변 길이 검사 값. IPv6의 경우 8 옥텟 경계, IPv4의 경우 4 옥텟 경계로 필드를 정렬하기 위한 패딩을 포함할 수 있다.


4. 3. IKE (Internet Key Exchange)

'''IKE'''(Internet Key Exchange, 인터넷 키 교환)는 IPsec 프로토콜 슈트에서 SA(Security Association)를 구축하는 데 사용되는 프로토콜이다. IKE는 SAD(Security Association Database)에 SA 확립에 필요한 데이터가 없을 경우, 피어(peer)와 함께 SA에 필요한 정보를 확립하는 프로토콜을 실행한다. 2016년 현재, IKE의 최신 버전은 IKEv2이다.

IKE의 주요 기능은 피어와의 키 공유이다. SA에 필요한 정보를 확립하는 프로토콜로, IKE 대신 Kerberized Internet Negotiation of Keys/Kerberized Internet Negotiation of Keys영어(KINK)나 IPSECKEY DNS 레코드를 사용할 수도 있다.[42][43][44][45]

IKEv1 ()과 IKEv2 ()가 정의되어 있으며, 2016년 현재 최신 버전은 후자이다. IKEv1/v2 외에도 포투리스/Photuris영어 (), KINK () 등의 키 교환 프로토콜이 제안되었다.

IPsec는 AH의 인증 기능, ESP의 암호 기능을 조합하여 사용할 수 있으며, AH/ESP 각각에 다양한 알고리즘을 지정할 수 있다. 이러한 설정 가능한 조합이 방대하여 통신하는 두 지점 간의 모든 설정이 일치해야 통신이 성립한다. IPsec 설정을 자동화하고 보안을 강화하기 위해 IKEv1, IKEv2, KINK, Photuris 등의 프로토콜이 제안되었지만, 각 프로토콜은 호환성이 없다. 가장 널리 사용되는 IKEv1에서도 동작 모드, 인증 파라미터, 인증 방식, 키 교환 알고리즘, 암호 알고리즘 및 인증 알고리즘 등 설정 항목의 조합이 다양하며, IPsec을 능숙하게 사용하기 위해서는 일반적으로 고도의 전문 지식이 요구된다.

UDP포트 번호 500번에서 통신하는 키 교환프로토콜인 IKEv1은 두 단계(페이즈 1, 페이즈 2)로 키 교환을 수행한다. 페이즈 1은 IKE 프로토콜 간의 인증 및 암호 교환(ISAKMP SA 교환)을, 페이즈 2는 IPsec 적용 조건 및 키 정보 교환(IPsec SA 교환)을 수행한다.

페이즈 1에는 Main Mode와 Aggressive Mode 두 가지 절차가 있다. Aggressive Mode는 Main Mode보다 패킷 교환 횟수를 줄여 효율적이지만(3왕복 6패킷 → 1.5왕복 3패킷), ID 정보가 암호화되지 않아 도청 위험이 있다.

페이즈 2 통신은 페이즈 1에서 성립된 공유 키로 암호화되며, Quick Mode 절차를 따른다. Quick Mode는 ISAKMP에는 없고 IKEv1에 새로 정의된 것이다.

공개 키 암호를 사용한 키 교환 절차인 Oakley는 알고리즘으로 디피-헬만 키 공유(DH-MODP)와 타원 곡선 암호(EC2N) 두 종류가 있다.

IKE 통신 노드는 IKE 피어라고 하며, 요청 발행 쪽은 이니시에이터, 수신 쪽은 응답자라고 한다. Oakley 파라미터 및 IPsec SA 세부 사항은 이니시에이터가 제시하고(프로포절), 응답자가 선택하여 합의한다.

IKEv1은 키 교환과 함께 상대 피어 인증을 수행하며, 인증 방식에는 사전 키 공유 방식(PSK), 디지털 서명 방식, 공개 키 암호 방식 등이 있다.

페이즈 2에서 생성되는 IPsec SA 키 정보는 페이즈 1 공유 키에서 생성되지만, Perfect Forward Secrecy(PFS) 옵션으로 개별 페이즈 2 교환 시 새로운 Oakley 키 교환을 수행하여 기밀성을 높일 수 있다.

IKEv1은 복잡성, 난해한 용어, 다양한 모드/파라미터/옵션 조합으로 인해 이종 기기 간 접속이 어렵다는 문제가 있다. 이러한 문제로 인해 IETF는 IKEv2를 통해 표준화를 다시 시도하고 있다. IKEv2는 IKEv1에 비해 상당히 많은 개선이 이루어졌다.

4. 3. 1. IKEv1

UDP포트 번호 500번에서 통신하는 키 교환프로토콜인 IKEv1은 Internet Key Exchange protocol version 1을 의미하며, 두 단계(페이즈 1, 페이즈 2)로 키 교환을 수행한다. 페이즈 1은 IKE 프로토콜 간의 인증 및 암호 교환(ISAKMP SA 교환)을, 페이즈 2는 IPsec 적용 조건 및 키 정보 교환(IPsec SA 교환)을 수행한다.

페이즈 1에는 Main Mode와 Aggressive Mode 두 가지 절차가 있다. Main Mode는 ISAKMP 사양의 Identity Protection Exchange 절차, Aggressive Mode는 Aggressive Exchange 절차에 해당한다. Aggressive Mode는 Main Mode보다 패킷 교환 횟수를 줄여 효율적이지만(3왕복 6패킷 → 1.5왕복 3패킷), ID 정보가 암호화되지 않아 도청 위험이 있다.

페이즈 2 통신은 페이즈 1에서 성립된 공유 키로 암호화되며, Quick Mode 절차를 따른다. Quick Mode는 ISAKMP에는 없고 IKEv1에 새로 정의된 것이다.

공개 키 암호를 사용한 키 교환 절차인 Oakley는 알고리즘으로 디피-헬만 키 공유(DH-MODP)와 타원 곡선 암호(EC2N) 두 종류가 있다. 키 길이는 DH-MODP에서 768, 1024, 1536, 2048, 3072, 4096, 6144, 8192bit, EC2N에서 155, 188, 163, 283, 409, 571bit가 정의되어 있다.

IKE 통신 노드는 IKE 피어라고 하며, 요청 발행 쪽은 이니시에이터, 수신 쪽은 응답자라고 한다. Oakley 파라미터 및 IPsec SA 세부 사항은 이니시에이터가 제시하고(프로포절), 응답자가 선택하여 합의한다.

IKEv1은 키 교환과 함께 상대 피어 인증을 수행하며, 인증 방식에는 사전 키 공유 방식(PSK), 디지털 서명 방식, 공개 키 암호 방식 등이 있다.

페이즈 2에서 생성되는 IPsec SA 키 정보는 페이즈 1 공유 키에서 생성되지만, Perfect Forward Secrecy(PFS) 옵션으로 개별 페이즈 2 교환 시 새로운 Oakley 키 교환을 수행하여 기밀성을 높일 수 있다.

IKEv1은 복잡성, 난해한 용어, 다양한 모드/파라미터/옵션 조합으로 인해 이종 기기 간 접속이 어렵다는 문제가 있다. 이러한 문제로 인해 IETF는 IKEv2를 통해 표준화를 다시 시도하고 있다.

4. 3. 2. IKEv2

IKEv2는 IKEv1에 비해 상당히 많은 개선이 이루어졌다.

5. 대한민국에서의 활용

6. 관련 RFC

IPsec 프로토콜은 원래 1995년에 게시된 RFC 1825에서 RFC 1829까지 정의되었다. 1998년에는 RFC 2401 및 RFC 2412로 대체되었으며, 인터넷 키 교환(IKE) 프로토콜이 정의되었다. 2005년 12월에는 RFC 4301 및 RFC 4309에 새로운 표준이 정의되었으며, IKEv2가 포함되었다. 3세대 문서는 IPsec의 약자를 대문자 "IP"와 소문자 "sec"로 표준화했다. "ESP"는 일반적으로 RFC 4303을 지칭한다.

2008년 중반부터 IETF에서 IPsec 유지보수 및 확장(ipsecme) 작업 그룹이 활동하고 있다.

IPsec은 IPv6와 함께 개발되었으며, RFC 6434가 권장 사항으로 변경하기 전에는 모든 표준 준수 IPv6 구현에서 지원해야 했다.[24] IPsec은 IPv4 구현에서도 선택 사항이며, IPv4 트래픽을 보호하는 데 가장 일반적으로 사용된다.

다음은 IPsec 관련 RFC 목록의 일부이다.

RFC 번호내용
RFC 1829ESP DES-CBC 변환
RFC 2403ESP 및 AH 내에서 HMAC-MD5-96의 사용
RFC 2404ESP 및 AH 내에서 HMAC-SHA-1-96의 사용
RFC 2405명시적 IV를 사용한 ESP DES-CBC 암호 알고리즘
RFC 2410NULL 암호화 알고리즘과 IPsec과의 사용
RFC 2451ESP CBC 모드 암호 알고리즘
RFC 2857ESP 및 AH 내에서 HMAC-RIPEMD-160-96의 사용
RFC 3526인터넷 키 교환(IKE)을 위한 더 많은 모듈식 지수(MODP) 디피-헬만 그룹
RFC 3602AES-CBC 암호 알고리즘과 IPsec과의 사용
RFC 3686IPsec 캡슐화 보안 페이로드(ESP)와 함께 고급 암호화 표준(AES) 카운터 모드 사용
RFC 3947IKE에서 NAT-Traversal 협상
RFC 3948IPsec ESP 패킷의 UDP 캡슐화
RFC 4106IPsec 캡슐화 보안 페이로드(ESP)에서 갈루아/카운터 모드(GCM) 사용
RFC 4301인터넷 프로토콜의 보안 아키텍처
RFC 4302IP 인증 헤더
RFC 4303IP 캡슐화 보안 페이로드
RFC 4304인터넷 보안 연관 및 키 관리 프로토콜(ISAKMP)을 위한 IPsec DOI(Domain of Interpretation)에 대한 확장 시퀀스 번호(ESN) 부록
RFC 4307인터넷 키 교환 버전 2(IKEv2)에서 사용하기 위한 암호화 알고리즘
RFC 4308IPsec용 암호화 제품군
RFC 4309IPsec 캡슐화 보안 페이로드(ESP)와 함께 고급 암호화 표준(AES) CCM 모드 사용
RFC 4543IPsec ESP 및 AH에서 갈루아 메시지 인증 코드(GMAC) 사용
RFC 4555IKEv2 이동성 및 멀티호밍 프로토콜(MOBIKE)
RFC 4806IKEv2에 대한 온라인 인증서 상태 프로토콜(OCSP) 확장
RFC 4868IPsec과 함께 HMAC-SHA-256, HMAC-SHA-384 및 HMAC-SHA-512 사용
RFC 4945IKEv1/ISAKMP, IKEv2 및 PKIX의 인터넷 IP 보안 PKI 프로필
RFC 5282인터넷 키 교환 버전 2(IKEv2) 프로토콜의 암호화된 페이로드와 함께 인증된 암호화 알고리즘 사용
RFC 5386Better-Than-Nothing 보안: IPsec의 비인증 모드
RFC 5529IPsec과 함께 사용할 Camellia의 작동 모드
RFC 5685인터넷 키 교환 프로토콜 버전 2(IKEv2)용 리디렉션 메커니즘
RFC 5723인터넷 키 교환 프로토콜 버전 2(IKEv2) 세션 재개
RFC 5857IPsec을 통한 강력한 헤더 압축 지원을 위한 IKEv2 확장
RFC 5858IPsec을 통한 강력한 헤더 압축 지원을 위한 IPsec 확장
RFC 7296인터넷 키 교환 프로토콜 버전 2(IKEv2)
RFC 7321캡슐화 보안 페이로드(ESP) 및 인증 헤더(AH)에 대한 암호화 알고리즘 구현 요구 사항 및 사용 지침
RFC 7383인터넷 키 교환 프로토콜 버전 2(IKEv2) 메시지 단편화
RFC 7427인터넷 키 교환 버전 2(IKEv2)의 서명 인증
RFC 7634ChaCha20, Poly1305 및 인터넷 키 교환 프로토콜(IKE) 및 IPsec에서의 사용
RFC 4478인터넷 키 교환(IKEv2) 프로토콜에서 반복적인 인증
RFC 2367PF_KEY 인터페이스
RFC 2412OAKLEY 키 결정 프로토콜
RFC 3706트래픽 기반의 Dead Internet Key Exchange (IKE) 피어 감지 방법
RFC 3715IPsec-네트워크 주소 변환 (NAT) 호환성 요구 사항
RFC 4621IKEv2 이동성 및 멀티호밍 (MOBIKE) 프로토콜 설계
RFC 4809IPsec 인증서 관리 프로필 요구 사항
RFC 5387Better-Than-Nothing Security (BTNS) 문제 및 적용 가능성 명세
RFC 5856IPsec 보안 연결을 통한 강력한 헤더 압축 통합
RFC 5930Internet Key Exchange 버전 02 (IKEv2) 프로토콜과 Advanced Encryption Standard Counter Mode (AES-CTR) 사용
RFC 6027IPsec 클러스터 문제 명세
RFC 6071IPsec 및 IKE 문서 로드맵
RFC 6467Internet Key Exchange 버전 2 (IKEv2)를 위한 보안 비밀번호 프레임워크
RFC 5406IPsec 버전 2 사용 지침


참조

[1] 웹사이트 A Cryptographic Evaluation of IPsec https://www.schneier[...] 2024-12-01
[2] 논문 Implementation of IPSec Protocol IEEE
[3] 웹사이트 Network Encryption – history and patents http://www.toad.com/[...] 2014-02-18
[4] 웹사이트 USENIX 1996 ANNUAL TECHNICAL CONFERENCE https://www.usenix.o[...]
[5] 웹사이트 IPv6 + IPSEC + ISAKMP Distribution Page https://web.mit.edu/[...]
[6] 웹사이트 IP Security Protocol (ipsec) - https://datatracker.[...]
[7] 웹사이트 NRL ITD Accomplishments - IPSec and IPv6 https://www.nrl.navy[...]
[8] 문서 Internet Key Exchange (IKE), RFC 2409, §1 Abstract
[9] 서적 Carrier-Scale IP Networks: Designing and Operating Internet Networks IET
[10] 웹사이트 Protocol Numbers https://www.iana.org[...] 2010-05-27
[11] 웹사이트 SIPP Encapsulating Security Payload http://www.toad.com/[...] IETF SIPP Working Group 2013-08-07
[12] 웹사이트 Draft SIPP Specification http://tools.ietf.or[...] IETF
[13] 논문 Problem Areas for the IP Security Protocols https://www.cs.colum[...] 2007-07-09
[14] 논문 Cryptography in theory and practice: The case of encryption in IPsec http://eprint.iacr.o[...] 2007-08-13
[15] 논문 Attacking the IPsec Standards in Encryption-only Configurations http://eprint.iacr.o[...] 2007-08-13
[16] 서적 Carrier-Scale IP Networks: Designing and Operating Internet Networks IET
[17] 서적 Carrier-Scale IP Networks: Designing and Operating Internet Networks IET
[18] 논문 Key Exchange in IPsec Revisited: Formal Analysis of IKEv1 and IKEv2 Springer
[19] 서적 Cryptography and Network Security, 4/E Pearson Education India
[20] 서적 Carrier-Scale IP Networks: Designing and Operating Internet Networks IET
[21] 서적 Carrier-Scale IP Networks: Designing and Operating Internet Networks IET
[22] 간행물 PF_KEYv2 Key Management API
[23] 논문 Implementation and performance evaluation of embedded IPsec in microkernel OS https://publikations[...] IEEE 2015
[24] 간행물 IPv6 Node Requirements
[25] 웹사이트 ipsecme charter https://datatracker.[...] 2015-10-26
[26] 웹사이트 ipsecme status https://tools.ietf.o[...] 2015-10-26
[27] 뉴스 Secret Documents Reveal N.S.A. Campaign Against Encryption https://www.nytimes.[...]
[28] 웹사이트 Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN" http://www.mail-arch[...]
[29] 웹사이트 Allegations regarding OpenBSD IPSEC http://marc.info/?l=[...]
[30] 웹사이트 Allegations regarding OpenBSD IPSEC http://marc.info/?l=[...]
[31] 웹사이트 Update on the OpenBSD IPSEC backdoor allegation https://lwn.net/Arti[...]
[32] 논문 Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security
[33] 뉴스 Confirmed: hacking tool leak came from "omnipotent" NSA-tied group https://arstechnica.[...] 2016-08-16
[34] 뉴스 Cisco confirms two of the Shadow Brokers' 'NSA' vulns are real https://www.theregis[...] 2016-08-17
[35] 뉴스 Equation Group exploit hits newer Cisco ASA, Juniper Netscreen https://www.theregis[...] 2016-08-24
[36] 뉴스 Fortinet follows Cisco in confirming Shadow Broker vuln https://www.theregis[...] 2016-08-18
[37] 웹사이트 key exchange - What are the problems of IKEv1 aggressive mode (compared to IKEv1 main mode or IKEv2)? https://crypto.stack[...]
[38] 웹사이트 Don't stop using IPsec just yet https://nohats.ca/wo[...] 2014-12-29
[39] 서적 Foundations of modern networking : SDN, NFV, QoE, IoT, and Cloud https://www.worldcat[...] 2016
[40] 문서 RFC6434
[41] 문서 RFC6071 등
[42] rfc The Internet Key Exchange (IKE) IETF 1998-11
[43] rfc IKE Version 2 IETF
[44] rfc Kerberized Internet Negotiation of Keys (KINK) IETF 1998-11
[45] rfc A Method for Storing IPsec Keying Material in DNS IETF 2005-02
[46] 웹사이트 SIPP Encapsulating Security Payload https://datatracker.[...] IETF SIPP Working Group
[47] 웹사이트 Draft SIPP Specification http://tools.ietf.or[...] IETF
[48] 웹사이트 http://www.toad.com/[...]
[49] 웹사이트 RFC4301: Security Architecture for the Internet Protocol https://datatracker.[...] Network Working Group of the IETF 2005-12
[50] rfc RFC 2411
[51] rfc RFC 4308


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com