IPsec

IPsec
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

컴퓨팅에서 IPsec(Internet Protocol Security)은 인터넷 프로토콜 네트워크를 통해 두 컴퓨터 간에 암호화된 통신을 안전하게 제공하기 위해 데이터 패킷을 인증 및 암호화하는 보안 네트워크 프로토콜 스위트입니다.Virtual Private Network(VPN; 가상개인 네트워크)에서 사용됩니다.

IPsec에는 세션 시작 시 에이전트 간에 상호 인증을 확립하는 프로토콜과 세션 중에 사용할 암호 키의 네고시에이션을 포함합니다.IPsec 는, 호스트 쌍(호스트 대 호스트), 시큐러티 게이트웨이 쌍(네트워크 대 네트워크), 또는 시큐러티 게이트웨이와 호스트(네트워크 대 호스트)[1] 사이의 데이터 플로우를 보호할 수 있습니다.IPsec은 암호화 보안 서비스를 사용하여 Internet Protocol(IP) 네트워크를 통한 통신을 보호합니다.네트워크 레벨의 피어 인증, 데이터 송신원 인증, 데이터 무결성, 데이터 기밀성(암호화) 및 재생 보호(재생 공격으로부터의 보호)를 서포트합니다.

최초의 IPv4 스위트는, 시큐러티 프로비저닝이 거의 없는 상태로 개발되었습니다.IPv4 확장의 일부로서 IPsec은 레이어 3 OSI 모델 또는 인터넷레이어 엔드 투 엔드 보안 스킴입니다.이와는 대조적으로, 트랜스포트 레이어 위에서 동작하는 Transport Layer Security(TLS; 트랜스포트 레이어 보안)나 애플리케이션레이어에서 동작하는 Secure Shell(SSH;시큐어 셸) 등, 널리 사용되고 있는 그 외의 인터넷보안 시스템은, 네트워크 레이어상에서 동작하고 있습니다만, IPsec에서는 자동적으로 애플리케이션을 시큐어하게 할 수 있습니다.

역사

1970년대 초부터 Advanced Research Projects Agency는 일련의 실험적인 ARPANET 암호화 장치를 지원했습니다.처음에는 네이티브 ARPANET 패킷 암호화용으로, 그 후에는 TCP/IP 패킷 암호화용으로 사용되었습니다.이들 중 일부는 인증 및 필드 처리되었습니다.1986년부터 1991년까지 NSA는 SDNS([2]Secure Data Network Systems) 프로그램에 따라 인터넷용 보안 프로토콜 개발을 후원했습니다.1988년 네트워크 암호화 장치를 생산한 모토로라를 비롯한 다양한 공급업체들이 모여들었다.이 연구는 1988년 NIST에 의해 공개적으로 발표되었으며, 이 중 SP3는 결국 ISO 표준 네트워크 계층 보안 프로토콜(NLSP)[3]로 변형될 것이다.

1992년부터 1995년까지 다양한 그룹이 IP 계층 암호화에 대한 연구를 수행했습니다.

  • 1. 1992년 미국 해군연구소는 IP 암호화를 연구하고 구현하기 위한 SIPP(Simple Internet Protocol Plus) 프로젝트를 시작했다.
  • 2. 1993년 Columbia University와 AT&T Bell Labs에서 John Ioannidis와 다른 사람들은 SunOS에서 소프트웨어 실험용 Software IP Encryption Protocol(swIPe)을 연구했습니다.
  • 3. 1993년, 백악관 인터넷 서비스 프로젝트의 후원을 받아 Trusted Information Systems(TIS)의 Wei Xu는 소프트웨어 IP 보안 프로토콜을 더욱 연구하여 BSD 4.1 커널로 코드화되어 x86과 SUNOS 아키텍처를 모두 지원하는 Triple [4]DES의 하드웨어 지원을 개발하였습니다.1994년 12월 TIS는 통합 3DES 하드웨어 암호화 기능을 갖춘 DARPA가 후원하는 오픈 소스 Guntlet Firewall 제품을 T1 이상의 속도로 출시했습니다.미국 동부 해안과 서부 해안에서 IPSec VPN 접속을 사용한 것은 이번이 처음입니다.이것은 최초의 상용 IPSec VPN 제품으로 알려져 있습니다.
  • 4. NRL의 DARPA에 의한 연구 활동 하에 NRL은 IPsec용 IETF 표준 트랙 사양(RFC 1825~RFC 1827)을 개발했습니다.이것은 BSD 4.4 커널로 코드화되어 x86 및 SPARC CPU 아키텍처를 [5]모두 지원합니다.NRL의 IPsec 구현은 1996년 USENIX Conference [6]Proceedings의 논문에서 설명되었습니다.NRL의 오픈 소스 IPsec 구현은 MIT에 의해 온라인으로 제공되었으며 대부분의 초기 상용 [5]구현의 기반이 되었습니다.

Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)는 1992년에 IP[7] Security Working Group을 결성하여 IP에 대한 공개 지정 보안 확장(IPSec)[8]을 표준화하고 있습니다.1995년에 작업 그룹은 5개 회사(TIS, Cisco, FTP, Checkpoint 등)의 멤버와 함께 워크샵을 몇 개 조직했습니다.IPSec 워크숍에서는 NRL의 표준과 Cisco 및 TIS의 소프트웨어가 RFC-1825로 [9]RFC-1827에 의해 공개 레퍼런스로 표준화됩니다.

보안 아키텍처

IPsec은, IPv4 스위트의 일부로서 오픈 스탠다드입니다.IPsec은 다음 프로토콜을 사용하여 다양한 [10][11]기능을 수행합니다.

  • Authentication Header(AH; 인증 헤더)는 IP 데이터그램에 대한 무접속 데이터 무결성 및 데이터 원본 인증을 제공하며 재생 [12][13]공격으로부터 보호합니다.
  • Encapsulating Security Payloads(ESP; 보안 페이로드 캡슐화)는 기밀성, 무접속 데이터 무결성, 데이터 원본 인증, 안티 리플레이 서비스(일부 시퀀스 무결성 형식) 및 제한된 트래픽흐름 [1]기밀성을 제공합니다.
  • 인터넷 보안 협회와 키 관리 프로토콜(ISAKMP)실제 인증된 키잉이 재료로 인증과 키 exchange,[14]하기 위한 골격pre-shared 키, 인터넷 핵심 거래소(IKE과 IKEv2), Kerberized 인터넷 협상 키(KINK)의, 또는 IPSECKEY DNS기록 통해 수동으로 구성하여 제공된를 제공한다.[15][16][17][18]그 목적은 AH 및 ESP 동작에 필요한 알고리즘 및 파라미터 번들과 함께 Security Association(SA; 보안 어소시에이션)을 생성하는 것입니다.

인증 헤더

터널 모드 및 트랜스포트 모드에서의 IPsec 인증 헤더 형식 사용

보안인증헤더(AH)는 1990년대 초 미국 해군연구소에서 개발되었으며 SNMP(Simple Network Management Protocol) 버전 2의 인증을 위한 이전의 IETF 표준에서 일부 파생되었습니다.Authentication Header(AH; 인증 헤더)는 IPsec 프로토콜 스위트의 멤버입니다.AH는 AH 알고리즘에서 해시함수와 비밀 공유키를 사용하여 무접속 무결성을 보장합니다.또, AH 는, IP 패킷을 인증하는 것으로, 데이터 발신기지도 보증합니다.옵션으로 시퀀스 번호를 지정하면 슬라이딩 윈도 기술을 사용하여 오래된 패킷을 폐기함으로써 IPsec 패킷의 내용을 리플레이 [19][20]공격으로부터 보호할 수 있습니다.

  • IPv4 에서는, AH 는 옵션 삽입 공격을 방지합니다.IPv6 에서는, AH 는 헤더 삽입 공격과 옵션 삽입 공격 양쪽 모두를 보호합니다.
  • IPv4 에서는, AH 는 IP 페이로드와 IP 데이터그램의 모든 헤더 필드(즉, 전송중의 변경 가능성이 있는 필드)를 제외하고, IP payload 및 IP Security 옵션(RFC 1108)등의 IP 옵션을 보호합니다.변경 가능한(따라서 인증되지 않은) IPv4 헤더필드는 DSCP/ToS, ECN, 플래그, 플래그, 프래그먼트오프셋,[13] TTL 및 헤더체크섬입니다
  • IPv6에서는 AH가 IPv6 기본 헤더, AH 자체, AH 이후의 비변환 확장 헤더 및 IP payload를 보호합니다.IPv6 헤더의 보호에서는 DSCP, ECN, 플로우라벨 및 홉 [13]제한의 가변 필드는 제외됩니다.

AH는 IP 프로토콜 번호 [21]51을 사용하여 IP 위에서 직접 작동합니다.

다음 AH 패킷 다이어그램은 AH 패킷의 구성 및 [12][13]해석 방법을 보여 줍니다.

인증 헤더 형식
오프셋 옥텟16 0 1 2 3
옥텟16 비트10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 다음 헤더 페이로드 렌 예약필
4 32 보안 파라미터 인덱스(SPI)
8 64 시퀀스 번호
C 96 무결성 검사 값(ICV)
...
... ...
다음 헤더(8비트)
보호되는 상위 계층 프로토콜을 나타내는 다음 헤더 유형입니다.값은 IP 프로토콜 번호 목록에서 가져옵니다.
페이로드 렌(8비트)
4 옥텟 단위의 이 인증 헤더의 길이(-2).예를 들어 4의 AH 값은 3×(32비트 고정길이 AH 필드) + 3×(32비트 ICV 필드) - 2이므로 4의 AH 값은 24옥텟을 의미합니다.사이즈는 4 옥텟 단위로 측정되지만 IPv6 패킷으로 전송되는 경우 이 헤더의 길이는 8 옥텟의 배수여야 합니다.이 제한은, IPv4 패킷으로 전송되는 인증 헤더에는 적용되지 않습니다.
예약 완료(16비트)
향후 사용을 위해 예약되어 있습니다(그때까지 모두 0).
보안 파라미터 인덱스(32비트)
수신측의 시큐러티 어소시에이션을 식별하기 위해서(행선지 IP 주소와 함께) 사용되는 임의의 값.
시퀀스 번호(32비트)
재생 공격을 방지하기 위해 시퀀스 번호를 엄격하게 증가시키는 모노톤(전송되는 패킷마다 1씩 증가)리플레이 검출이 네이블로 되어 있는 경우 시퀀스 번호가 재사용되지 않습니다.시퀀스 번호를 최대치를 [13]초과하여 증가시키기 전에 새로운 보안 어소시에이션을 재네고시에이트할 필요가 있기 때문입니다.
무결성 검사 값(32비트의 복수)
가변 길이 검사 값입니다.필드를 IPv6의 경우8 옥텟 경계 또는 IPv4의 경우4 옥텟 경계에 맞추기 위한 패딩을 포함할 수 있습니다.

보안 페이로드 캡슐화

터널 모드 및 트랜스포트 모드에서의 IPSec 캡슐화 보안 페이로드(ESP) 사용

IP Encapsulating Security Payload(ESP;[22] IP 캡슐화 보안 페이로드)는 DARPA가 후원하는 연구 프로젝트의 일환으로 1992년부터 Naval Research Laboratory에서 개발되었으며, 1993년 12월 SIPP의 보안 확장으로 IETF[23] SIPP Working Group에 의해 초안되었다.이 ESP는 원래 ISO Network-Layer Security Protocol(NLSP)에서 파생된 것이 아니라 미국 국방부 SP3D 프로토콜에서 파생된 것입니다.SP3D 프로토콜 규격은 1980년대 후반에 NIST에 의해 발표되었지만 미국 국방부의 보안 데이터 네트워크 시스템 프로젝트에 의해 설계되었다.Encapsulating Security Payload(ESP)는 IPsec 프로토콜 스위트의 멤버입니다.소스 인증을 통한 오리진 인증, 해시 함수를 통한 데이터 무결성 및 IP 패킷 암호화 보호를 통한 기밀성을 제공합니다.ESP는 암호화 전용 및 인증 전용 설정도 지원하지만 인증 없이 암호화를 사용하는 것은 안전하지 [24][25][26]않기 때문에 권장되지 않습니다.

Authentication Header(AH; 인증 헤더)와 달리 트랜스포트 모드의 ESP는 IP 패킷 전체에 대해 무결성 및 인증을 제공하지 않습니다.단, 터널 모드에서는 원래 IP 패킷 전체가 새로운 패킷헤더로 캡슐화되어 내부 IP 패킷 전체(내부 헤더 포함)에 ESP 보호가 제공되지만 외부 헤더(외부 IPv4 옵션 또는 IPv6 확장 헤더 포함)는 보호되지 않습니다.ESP는 IP 프로토콜 번호 [21]50을 사용하여 IP 상단에서 직접 작동합니다.

다음 ESP 패킷 다이어그램은 ESP 패킷의 구성 및 [1][27]해석 방법을 보여 줍니다.

보안 페이로드 포맷 캡슐화
오프셋 옥텟16 0 1 2 3
옥텟16 비트10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 보안 파라미터 인덱스(SPI)
4 32 시퀀스 번호
8 64 페이로드 데이터
... ...
... ...
... ... 패딩(0~255 옥텟)
... ... 패드 길이 다음 헤더
... ... 무결성 검사 값(ICV)
...
... ...
보안 파라미터 인덱스(32비트)
수신측의 시큐러티 어소시에이션 식별에 사용되는 임의의 값(행선지 IP 주소와 함께).
시퀀스 번호(32비트)
재생 공격으로부터 보호하기 위해서, 단조롭게 증가하는 시퀀스 번호(전송되는 패킷마다 1씩 증가).각 보안 어소시에이션에는 별도의 카운터가 있습니다.
페이로드 데이터(변수)
원래의 IP 패킷의 보호된 컨텐츠.콘텐츠 보호에 사용되는 데이터를 포함합니다(암호화 알고리즘의 초기화 벡터 등).보호된 콘텐츠의 유형은 [Next Header]필드로 표시됩니다.
패딩(0~255 옥텟)
암호화용 패딩, 암호화의 암호 블록 크기에 맞는 크기로 페이로드 데이터를 확장하고 다음 필드를 정렬합니다.
패드 길이(8비트)
패딩 크기(8진수 단위).
다음 헤더(8비트)
다음 헤더의 유형입니다.값은 IP 프로토콜 번호 목록에서 가져옵니다.
무결성 검사 값(32비트의 복수)
가변 길이 검사 값입니다.필드를 IPv6의 경우8 옥텟 경계 또는 IPv4의 경우4 옥텟 경계에 맞추기 위한 패딩을 포함할 수 있습니다.

보안 어소시에이션

주요 기사:보안 어소시에이션

IPsec 프로토콜은 통신 당사자가 알고리즘 및 키와 같은 공유 보안 속성을 설정하는 보안 어소시에이션을 사용합니다.따라서 IPsec은 AH 또는 ESP 중 어느 쪽을 사용할지 결정되면 다양한 옵션을 제공합니다.데이터를 교환하기 전에 두 호스트는 AES나 ChaCha20 등의 IP 패킷 암호화에 사용되는 대칭 암호화 알고리즘과 블레이크2나 SHA256 등의 데이터의 무결성을 확보하기 위해 사용되는 해시 함수에 대해 합의합니다.이들 파라미터는 라이프타임과 세션키를 [28]합의해야 하는 특정 세션에 대해 합의됩니다.

데이터 전송이 이루어지기 전에 인증 알고리즘도 합의되어 IPsec은 다양한 방식을 지원합니다.인증은 사전 공유 키를 통해 가능합니다.이 경우 대칭 키는 이미 양쪽 호스트에 있고 호스트는 공유 키의 해시를 서로 전송하여 같은 키를 소유하고 있음을 증명합니다.IPsec은 공개 키 암호화도 지원합니다.여기서 각 호스트는 공개 키와 개인 키를 교환하고 각 호스트는 다른 호스트의 공개 키로 암호화된 난스를 서로 전송합니다.또는 양쪽 호스트가 인증국으로부터의 공개 키 증명서를 보유하고 있는 경우는, IPsec [29]인증에 사용할 수 있습니다.

IPsec의 보안 어소시에이션은 Internet Security Association and Key Management Protocol(ISAKMP)을 사용하여 확립됩니다.ISAKMP는 사전 공유 비밀, Internet Key Exchange(IKE 및 IKEv2), Kerberized Internet Negotiation of Keys(KINK) 및 IPSECKEY DNS [18][30][31]레코드를 사용한 수동 설정에 의해 구현됩니다.RFC 5386에서는 Better-Than-Nothing Security(BTNS; Better-Than-Nothing 보안)는 확장 IKE 프로토콜을 사용하는 IPSec의 인증되지 않은 모드로 정의되어 있습니다.C. 메도우스, C.Cremers 등은 IKEv1 및 [32]IKEv2에 존재하는 다양한 이상을 식별하기 위해 정식 방법을 사용하고 있습니다.

발신 패킷에 대해 어떤 보호를 제공할지를 결정하기 위해 IPsec은 Security Parameter Index(SPI; 보안 파라미터 인덱스)를 패킷헤더 내의 수신처 주소와 함께 사용합니다.SPI는 패킷의 보안 어소시에이션을 일의로 식별합니다.착신 패킷에 대해서도 같은 순서가 실행됩니다.IPsec 에서는, 시큐러티 어소시에이션 데이터베이스로부터 복호화 및 검증 키가 수집됩니다.

IP 멀티캐스트의 경우 그룹에 보안 어소시에이션이 제공되어 그룹의 모든 인가된 리시버에 복제됩니다.그룹에는 여러 SPI를 사용하여 여러 보안 어소시에이션이 존재할 수 있습니다.이것에 의해, 그룹내에서 복수의 레벨과 시큐러티를 설정할 수 있습니다.실제로, 수신자는 키를 알고 있는 누군가가 데이터를 송신한 것만을 알 수 있기 때문에, 각 송신자는 복수의 시큐러티 어소시에이션을 설정할 수 있습니다.관련 표준은 관련 협회가 어떻게 선택되고 그룹 전체에서 중복되는지를 기술하지 않으며, 책임 있는 당사자가 선택한 것으로 가정한다.

동작 모드

IPsec 프로토콜 AH 및 ESP는 호스트 간 전송 모드 및 네트워크 터널링 모드로 구현할 수 있습니다.

IPsec 모드

전송 모드

트랜스포트 모드에서는 보통 IP 패킷의 payload만 암호화 또는 인증됩니다.IP 헤더는 변경도 암호화도 되지 않기 때문에 라우팅은 변경되지 않습니다.다만, 인증 헤더가 사용되고 있는 경우, IP 주소는 항상 해시 값이 무효가 되기 때문에, 네트워크주소 변환에 의해서 변경할 수 없습니다.트랜스포트 레이어와 애플리케이션레이어는 항상 해시에 의해 보호되기 때문에 포트 번호 변환 등의 방법으로 변경할 수 없습니다.

NAT 트래버설용 IPsec 메시지를 캡슐화하는 방법은 NAT-T 메커니즘을 설명하는 RFC 문서에 의해 정의되어 있습니다.

터널 모드

주요 기사:터널링 프로토콜

터널 모드에서는 IP 패킷 전체가 암호화되어 인증됩니다.그런 다음 새로운 IP 헤더를 가진 새로운 IP 패킷에 캡슐화됩니다.터널 모드는 네트워크 간 통신(예: 라우터와 링크 사이트 간), 호스트 간 통신(예: 원격 사용자 액세스) 및 호스트 간 통신(예: 개인 채팅)[33]을 위한 가상 개인 네트워크를 생성하기 위해 사용됩니다.

터널 모드에서는 NAT 트래버설이 지원됩니다.

알고리즘

대칭 암호화 알고리즘

IPsec에서 사용하기 위해 정의된 암호화 알고리즘은 다음과 같습니다.

상세한 것에 대하여는, RFC 8221 을 참조해 주세요.

키 교환 알고리즘

인증 알고리즘

실장

IPsec 는, operating system의 IP 스택에 실장할 수 있습니다.이것에 의해, 소스 코드를 변경할 필요가 있습니다.이 실장 방법은 호스트 및 보안 게이트웨이에 대해 실행됩니다.HP나 IBM [34]등, 기업으로부터 다양한 IPsec 대응의 IP 스택을 입수할 수 있습니다.다른 방법으로는 Bump-In-the-Stack(BITS; 범프인더스택) 구현이라고 불리며 운영체제소스 코드를 변경할 필요가 없습니다.여기서 IPsec은 IP 스택과 네트워크 드라이버 사이에 설치됩니다.이와 같이, operating system에 IPsec 를 재장착할 수 있습니다.이 실장 방법은 호스트와 게이트웨이에도 사용됩니다.단, IPsec을 새로 장착할 경우 IP 패킷의 캡슐화로 인해 자동 경로 MTU 디스커버리에 문제가 발생할 수 있습니다.이 경우, 2개의 IP 호스트간의 네트워크 패스상의 Maximum Transmission Unit(MTU; 최대 전송 유닛) 사이즈가 확립됩니다.호스트 또는 게이트웨이에 개별 크립토프로세서가 탑재되어 있는 경우, 이것은 군에서 공통으로 상용 시스템에서도 사용할 수 있습니다.IPSec의 이른바 Bump-In-the-Wire(BITW; 범프인더-Wire) 실장이 가능합니다.[35]

IPsec 가 커널에 실장되면, 키 관리 및 ISAKMP/IKE 네고시에이션이 유저 스페이스로부터 실행됩니다.NRL에서 개발되어 공개적으로 지정된 "PF_KEY KEY Management API, 버전 2"는 종종 응용 프로그램 공간 키 관리 응용 프로그램이 커널 공간 IPsec 구현 [36]내에 저장된IPsec 보안 어소시에이션을 갱신할 수 있도록 하기 위해 사용됩니다.기존의 IPsec 실장에는 보통 ESP, AH 및 IKE 버전2 가 포함됩니다.Solaris 나 Linux 등의 Unix 유사 운영체제시스템에서의 기존 IPsec 실장에는 보통 PF_KEY 버전2가 포함되어 있습니다.

임베디드 IPsec 를 사용하면,[37] 제약이 있는 자원 시스템상에서 실행되고 있는 애플리케이션간의 시큐어 통신을, 오버헤드가 적은 상태로 확보할 수 있습니다.

표준 상태

IPsec은 IPv6와 함께 개발되었으며 RFC 6434가 권장 [38]사항으로 규정하기 전에는 IPv6의 모든 표준 준거 구현에서 지원되어야 했습니다.IPv4 의 실장에서는, IPsec 는 옵션입니다.IPsec 는, IPv4 트래픽의 [citation needed]시큐러티 보호에 가장 일반적으로 사용됩니다.

IPsec 프로토콜은 원래 RFC 1825에서 RFC 1829까지 정의되었으며, 1995년에 발행되었습니다.1998년에 이들 문서는 RFC 2401 및 RFC 2412로 대체되었습니다.단, 개념적으로는 동일하지만 호환되지 않는 엔지니어링 세부사항이 몇 가지 있습니다.또한 보안 연결을 만들고 관리하기 위해 상호 인증 및 키 교환 프로토콜 IKE(Internet Key Exchange)가 정의되었습니다.2005년 12월, RFC 4301 및 RFC 4309에 새로운 표준이 정의되었습니다.이는 인터넷키 익스체인지 표준 IKEv2의 두 번째 버전을 탑재한 이전 에디션의 대부분 슈퍼셋입니다.이러한 3세대 문서에서는 IPsec의 약어를 대문자인 "IP"와 소문자인 "sec"로 표준화했습니다."ESP"는 일반적으로 RFC 4303을 가리키며, 이는 이 사양의 최신 버전입니다.

2008년 중반 이후 IETF에서 [39][40]IPsec Maintenance and Extensions(ipsecme; 유지보수 및 확장) 워킹그룹이 활성화 되었습니다.

NSA 간섭 혐의

2013년 스노든 유출의 일환으로 미 국가안보국은 Bullrun [41]프로그램의 일환으로 "타깃이 사용하는 상용 암호화 시스템, IT 시스템, 네트워크 및 엔드포인트 통신 장치에 취약성 삽입"에 적극적으로 대처하고 있는 것으로 밝혀졌다.IPsec이 표적 암호화 [42]시스템이었다는 주장이 있습니다.

OpenBSD IPsec 스택은 나중에 출시되어 널리 복사되었습니다.OpenBSD의 수석 개발자 Theo de Raadt가 2010년 12월 11일 Gregory Perry로부터 받은 서한에서 Jason Wright와 FBI에서 일하는 다른 사람들은 OpenBSD 암호 코드에 "다수의 백도어 및 사이드 채널 키 누출 메커니즘"을 삽입했다고 주장되고 있습니다.2010년부터 전송 된 이메일에서 Theo de Raadt는 처음에 이메일 [43]전송에 대한 암묵적인 지지 외에 클레임의 유효성에 대한 공식적인 입장을 표명하지 않았다.이 주장에 대한 제이슨 라이트의 답변: "모든 도시 전설은 실명, 날짜, 시간을 포함시킴으로써 더 사실적으로 만들어 진다.그레고리 페리의 이메일은 이 범주에 속합니다.…OpenB에 백도어를 추가하지 않았음을 명확히 설명하겠습니다.SD 운영체제 또는 OpenBSD 암호화 프레임워크(OCF)[44]입니다." 며칠 후 de Raadt는 다음과 같이 말했습니다.NETSEC은 아마도 주장대로 백도어를 기술하는 계약을 체결한 것 같습니다.…이것들이 적혀있다면, 그들이 우리 [45]트리에 들어왔다고는 생각하지 않습니다."이것은 스노든이 유출되기 전에 출판되었다.

Logjam 공격의 작성자가 제시한 대체 설명은 NSA가 키 교환에 사용되는 Diffie-Hellman 알고리즘을 약화시킴으로써 IPsec VPN을 손상시켰음을 나타냅니다.그들은 논문에서 [46]NSA가 RFC 2409에 정의된 두 번째 Oakley 그룹과 같은 특정 소수점 및 생성자에 대해 곱셈 하위 그룹을 미리 계산하기 위해 컴퓨팅 클러스터를 특별히 구축했다고 주장합니다.2015년 5월 현재 주소 지정 가능한 IPsec VPN의 90%가 IKE의 일부로 두 번째 Oakley 그룹을 지원하고 있습니다.조직이 이 그룹을 미리 계산하면 교환되는 키를 도출하여 소프트웨어 백도어를 삽입하지 않고 트래픽을 복호화할 수 있습니다.

앞으로 나아갔다 두번째 대안적인 설명은 그 방정식 그룹은 방정식 Group[47] 제조사들의 지수 함수의 시간을 실제로 위업, 일부로 공개된 것으로 유효성을 묶어는 카스퍼스키 랩이 검사의 제조 업체들의 VPN장비를 공개 대담하고 했었죠.osure.[48][49][50] Cisco PIX 및 ASA 방화벽에는 NSA에[citation needed] 의한 감청에 사용되는 취약성이 있습니다.

또, 「어그레시브 모드」설정을 사용하고 있는 IPsec VPN은, PSK 의 해시를 클리어 상태로 송신합니다.이는 오프라인 사전 [46][51][52]공격을 사용하는 NSA의 표적이 될 수 있습니다.

IETF 매뉴얼

표준 트랙

  • RFC 1829:ESP DES-CBC 트랜스폼
  • RFC 2403:ESP 및 AH에서의 HMAC-MD5-96 사용
  • RFC 2404:ESP 및 AH에서의 HMAC-SHA-1-96 사용
  • RFC 2405:명시적 IV를 사용한ESP DES-CBC 암호 알고리즘
  • RFC 2410:NULL 암호화 알고리즘과 IPsec에서의 사용
  • RFC 2451:ESP CBC 모드 암호 알고리즘
  • RFC 2857:ESP 및 AH에서의 HMAC-RIPEMD-160-96 사용
  • RFC 3526: Internet Key Exchange(IKE; 인터넷키 익스체인지)용 모듈러 지수(MODP) Diffie-Hellman 그룹 추가
  • RFC 3602:AES-CBC 암호 알고리즘과 IPsec에서의 사용
  • RFC 3686: IPsec 캡슐화 보안 페이로드(ESP)에서의 Advanced Encryption Standard(AES) 카운터 모드 사용
  • RFC 3947: IKE에서의 NAT-Traversal 네고시에이션
  • RFC 3948: IPsec ESP 패킷의 UDP 캡슐화
  • RFC 4106:IPsec Encapsulating Security Payload(ESP; 보안 페이로드)에서의 Galois/Counter Mode(GCM; 갈로이스/카운터 모드) 사용
  • RFC 4301: 인터넷 프로토콜의 보안 아키텍처
  • RFC 4302: IP 인증 헤더
  • RFC 4303: IP 캡슐화 보안 페이로드
  • RFC 4304: Internet Security Association and Key Management Protocol(ISAKMP)용 IPsec Domain of Interpreter(DOI; 도메인 오브 인터프리터) 확장 시퀀스 번호(ESN) 부록
  • RFC 4307: Internet Key Exchange 버전 2(IKEv2)에서 사용되는 암호화 알고리즘
  • RFC 4308: IPSec용 암호화 스위트
  • RFC 4309: IPsec 캡슐화 보안 페이로드(ESP)에서의 Advanced Encryption Standard(AES) CCM 모드 사용
  • RFC 4543:IPsec ESP 및 AH에서의 Galois Message Authentication Code(GMAC; 갈로아 메시지 인증 코드) 사용
  • RFC 4555: IKEv2 Mobility and Multihoming Protocol(MOBIKE)
  • RFC 4806: IKEv2에 대한 온라인 Certificate Status Protocol(OCSP) 확장
  • RFC 4868: IPsec에서의 HMAC-SHA-256, HMAC-SHA-384 및 HMAC-SHA-512 사용
  • RFC 4945:IKEv1/ISAKMP, IKEv2 및 PKIX의 인터넷 IP 보안 PKI 프로파일
  • RFC 5280: 인터넷 X.509 공개키 인프라스트럭처 증명서 및 증명서 취소 리스트(CRL) 프로파일
  • RFC 5282: Internet Key Exchange 버전 2(IKEv2) 프로토콜의 암호화된 페이로드에서의 인증된 암호화 알고리즘 사용
  • RFC 5386: 아무것도 없는 것보다 뛰어난 보안:IPsec의 비인증 모드
  • RFC 5529: IPSec과 함께 사용하는 동백의 동작 모드
  • RFC 5685: Internet Key Exchange Protocol 버전 2(IKEv2)의 리다이렉트 메커니즘
  • RFC 5723:Internet Key Exchange Protocol 버전 2(IKEv2) 세션 재개
  • RFC 5857: IPSec을 통한 견고한 헤더 압축을 지원하기 위한 IKEv2 확장
  • RFC 5858: IPsec을 통한 견고한 헤더 압축을 지원하기 위한 IPsec 확장
  • RFC 7296: Internet Key Exchange Protocol 버전 2(IKEv2)
  • RFC 7321: 보안 페이로드(ESP) 및 인증 헤더(AH) 캡슐화를 위한 암호화 알고리즘 구현 요건 및 사용 가이드라인
  • RFC 7383: Internet Key Exchange Protocol 버전 2(IKEv2) 메시지 플래그멘테이션
  • RFC 7427: Internet Key Exchange 버전 2(IKEv2)에서의 시그니처 인증
  • RFC 7634: Internet Key Exchange Protocol(IKE) 및 IPsec에서의 ChaCha20, Poly1305 및 이들의 사용

실험 RFC

  • RFC 4478: Internet Key Exchange(IKEv2) 프로토콜에서의 반복 인증

정보 RFC

  • RFC 2367: PF_KEY 인터페이스
  • RFC 2412:OAKLEY 키 결정 프로토콜
  • RFC 3706: 데드 인터넷키 익스체인지(IKE) 피어 검출 트래픽 기반 방법
  • RFC 3715: IPsec-Network Address Translation(NAT; 네트워크주소 변환) 호환성 요건
  • RFC 4621: IKEv2 Mobility and Multihoming(MOBIKE) 프로토콜 설계
  • RFC 4809: IPsec 증명서 관리 프로파일의 요건
  • RFC 5387: BTNS(Better-Than-Nothing Security)의 문제와 적용 가능성
  • RFC 5856: IPSec SA를 통한 견고한 헤더 압축 통합
  • RFC 5930: Internet Key Exchange 버전 02(IKEv2) 프로토콜에서의 AES-CTR(Advanced Encryption Standard Counter Mode) 사용
  • RFC 6027: IPsec 클러스터 문제 설명
  • RFC 6071: IPSec 및 IKE 문서 로드맵
  • RFC 6379: 스위트B 암호화 스위트(IPSec
  • RFC 6380: Internet Protocol Security(IPSec)용 스위트B 프로파일
  • RFC 6467: Internet Key Exchange 버전 2(IKEv2)의 안전한 패스워드 프레임워크

현재의 베스트 프랙티스 RFC

  • RFC 5406: IPsec 버전2의 사용을 지정하기 위한 가이드라인

구식/이력 RFC

  • RFC 1825: 인터넷 프로토콜의 보안 아키텍처(RFC 2401에 의해 폐지됨)
  • RFC 1826: IP 인증 헤더(RFC 2402에 의해 폐지)
  • RFC 1827: IP Encapsulating Security Payload(ESP; 보안 페이로드)(RFC 2406에 의해 폐지됨)
  • RFC 1828: 키 달린 MD5를 사용한IP 인증(이력)
  • RFC 2401: 인터넷 프로토콜을 위한 보안 아키텍처(IPSec 개요)(RFC 4301에 의해 폐지됨)
  • RFC 2406: IP Encapsulating Security Payload(ESP; IP 캡슐화 보안 페이로드) (RFC 4303 및 RFC 4305에 의해 폐지)
  • RFC 2407:ISAKMP의 인터넷 IP 보안 해석 도메인(RFC 4306에 의해 폐지)
  • RFC 2409:인터넷 키 교환(RFC 4306에 의해 폐지)
  • RFC 4305: 보안 페이로드(ESP) 및 인증 헤더(AH) 캡슐화를 위한 암호화 알고리즘 구현 요건(RFC 4835에 의해 폐지됨)
  • RFC 4306: Internet Key Exchange(IKEv2) 프로토콜(RFC 5996에 의해 폐지)
  • RFC 4718: IKEv2의 설명 및 구현 가이드라인(RFC 7296에 의해 폐지)
  • RFC 4835: 보안 페이로드(ESP) 및 인증 헤더(AH) 캡슐화를 위한 암호화 알고리즘 구현 요건(RFC 7321에 의해 폐지됨)
  • RFC 5996:Internet Key Exchange Protocol 버전 2(IKEv2) (RFC 7296에 의해 폐지)

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c Kent, S.; Atkinson, R. (November 1998). IP Encapsulating Security Payload (ESP). IETF. doi:10.17487/RFC2406. RFC 2406.
  2. ^ "Implementation of IPSec Protocol - IEEE Conference Publication". doi:10.1109/ACCT.2012.64. S2CID 16526652. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  3. ^ Gilmore, John. "Network Encryption – history and patents". Archived from the original on 2014-09-03. Retrieved 2014-02-18.
  4. ^ "The History of VPN creation Purpose of VPN". Le VPN. August 17, 2018.
  5. ^ a b "IPv6 + IPSEC + ISAKMP Distribution Page". web.mit.edu.
  6. ^ "USENIX 1996 ANNUAL TECHNICAL CONFERENCE". www.usenix.org.
  7. ^ "IP Security Protocol (ipsec) -". datatracker.ietf.org.
  8. ^ Seo, Karen; Kent, Stephen (December 2005). "RFC4301: Security Architecture for the Internet Protocol". Network Working Group of the IETF: 4. The spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other capitalizations of IPsec [...] are deprecated. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  9. ^ "NRL ITD Accomplishments - IPSec and IPv6" (PDF). US Naval Research Laboratories.
  10. ^ Thayer, R.; Doraswamy, N.; Glenn, R. (November 1998). IP Security Document Roadmap. IETF. doi:10.17487/RFC2411. RFC 2411.
  11. ^ Hoffman, P. (December 2005). Cryptographic Suites for IPsec. IETF. doi:10.17487/RFC4308. RFC 4308.
  12. ^ a b Kent, S.; Atkinson, R. (November 1998). IP Authentication Header. IETF. doi:10.17487/RFC2402. RFC 2402.
  13. ^ a b c d e Kent, S. (December 2005). IP Authentication Header. IETF. doi:10.17487/RFC4302. RFC 4302.
  14. ^ Internet Key Exchange(IKE), RFC 2409, 1 Abstract
  15. ^ Harkins, D.; Carrel, D. (November 1998). The Internet Key Exchange (IKE). IETF. doi:10.17487/RFC2409. RFC 2409.
  16. ^ Kaufman, C. (ed.). IKE Version 2. IETF. doi:10.17487/RFC4306. RFC 4306.
  17. ^ Sakane, S.; Kamada, K.; Thomas, M.; Vilhuber, J. (November 1998). Kerberized Internet Negotiation of Keys (KINK). IETF. doi:10.17487/RFC4430. RFC 4430.
  18. ^ a b Richardson, M. (February 2005). A Method for Storing IPsec Keying Material in DNS. IETF. doi:10.17487/RFC4025. RFC 4025.
  19. ^ Peter Willis (2001). Carrier-Scale IP Networks: Designing and Operating Internet Networks. IET. p. 270. ISBN 9780852969823.
  20. ^ R. Shirey (August 2007). Internet Security Glossary, Version 2. Network Working Group. doi:10.17487/RFC4949. RFC 4949.
  21. ^ a b "Protocol Numbers". IANA. IANA. 2010-05-27. Archived from the original on 2010-05-29.
  22. ^ "SIPP Encapsulating Security Payload". IETF SIPP Working Group. 1993. Archived from the original on 2016-09-09. Retrieved 2013-08-07.
  23. ^ Deering, Steve E. (1993). "Draft SIPP Specification". IETF: 21. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  24. ^ Bellovin, Steven M. (1996). "Problem Areas for the IP Security Protocols" (PostScript). Proceedings of the Sixth Usenix Unix Security Symposium. San Jose, CA. pp. 1–16. Retrieved 2007-07-09.
  25. ^ Paterson, Kenneth G.; Yau, Arnold K.L. (2006-04-24). "Cryptography in theory and practice: The case of encryption in IPsec" (PDF). Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004. Berlin. pp. 12–29. Retrieved 2007-08-13.
  26. ^ Degabriele, Jean Paul; Paterson, Kenneth G. (2007-08-09). "Attacking the IPsec Standards in Encryption-only Configurations" (PDF). IEEE Symposium on Security and Privacy, IEEE Computer Society. Oakland, CA. pp. 335–349. Retrieved 2007-08-13.
  27. ^ Kent, S. (December 2005). IP Encapsulating Security Payload (ESP). IETF. doi:10.17487/RFC4303. RFC 4303.
  28. ^ Peter Willis (2001). Carrier-Scale IP Networks: Designing and Operating Internet Networks. IET. p. 271. ISBN 9780852969823.
  29. ^ Peter Willis (2001). Carrier-Scale IP Networks: Designing and Operating Internet Networks. IET. pp. 272–3. ISBN 9780852969823.
  30. ^ RFC 2406, 문서 1, 2페이지
  31. ^ Thomas, M. (June 2001). Requirements for Kerberized Internet Negotiation of Keys. doi:10.17487/RFC3129. RFC 3129.
  32. ^ C. Cremers (2011). Key Exchange in IPsec Revisited: Formal Analysis of IKEv1 and IKEv2, ESORICS 2011. Lecture Notes in Computer Science. Springer. pp. 315–334. doi:10.1007/978-3-642-23822-2_18. hdl:20.500.11850/69608. ISBN 9783642238222.
  33. ^ William, S. & Stallings, W. (2006)암호 및 네트워크 보안, 4/E. Pearson Education India. 페이지 492-493
  34. ^ Peter Willis (2001). Carrier-Scale IP Networks: Designing and Operating Internet Networks. IET. p. 266. ISBN 9780852969823.
  35. ^ Peter Willis (2001). Carrier-Scale IP Networks: Designing and Operating Internet Networks. IET. p. 267. ISBN 9780852969823.
  36. ^ RFC 2367, PF_KEYV2 키 관리 API, Dan McDonald, Bao Phan 및 Craig Metz(1998년 7월)
  37. ^ Hamad, Mohammad; Prevelakis, Vassilis (2015). Implementation and performance evaluation of embedded IPsec in microkernel OS. 2015 World Symposium on Computer Networks and Information Security (WSCNIS). IEEE. doi:10.1109/wscnis.2015.7368294. ISBN 9781479999064. S2CID 16935000.
  38. ^ RFC 6434, "IPv6 노드 요건", E. 얀키에비치, J. Loughney, T. Narten (2011년 12월)
  39. ^ "ipsecme charter". Retrieved 2015-10-26.
  40. ^ "ipsecme status". Retrieved 2015-10-26.
  41. ^ "Secret Documents Reveal N.S.A. Campaign Against Encryption". New York Times.
  42. ^ John Gilmore. "Re: [Cryptography] Opening Discussion: Speculation on "BULLRUN"".
  43. ^ Theo de Raadt. "Allegations regarding OpenBSD IPSEC".
  44. ^ Jason Wright. "Allegations regarding OpenBSD IPSEC".
  45. ^ Theo de Raadt. "Update on the OpenBSD IPSEC backdoor allegation".
  46. ^ a b Adrian, David; Bhargavan, Karthikeyan; Durumeric, Zakir; Gaudry, Pierrick; Green, Matthew; Halderman, J. Alex; Heninger, Nadia; Springall, Drew; Thomé, Emmanuel; Valenta, Luke; Vandersloot, Benjamin; Wustrow, Eric; Zanella-Béguelin, Santiago; Zimmermann, Paul (2015). "Imperfect Forward Secrecy". Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. pp. 5–17. doi:10.1145/2810103.2813707. ISBN 9781450338325. S2CID 347988.
  47. ^ Goodin, Dan (August 16, 2016). "Confirmed: hacking tool leak came from "omnipotent" NSA-tied group". Ars Technica. Retrieved August 19, 2016.
  48. ^ Thomson, Iain (August 17, 2016). "Cisco confirms two of the Shadow Brokers' 'NSA' vulns are real". The Register. Retrieved September 16, 2016.
  49. ^ Pauli, Darren (August 24, 2016). "Equation Group exploit hits newer Cisco ASA, Juniper Netscreen". The Register. Retrieved September 16, 2016.
  50. ^ Chirgwin, Richard (August 18, 2016). "Fortinet follows Cisco in confirming Shadow Broker vuln". The Register. Retrieved September 16, 2016.
  51. ^ "key exchange - What are the problems of IKEv1 aggressive mode (compared to IKEv1 main mode or IKEv2)?". Cryptography Stack Exchange.
  52. ^ "Don't stop using IPsec just yet". No Hats. December 29, 2014.

외부 링크