IPsec 설정. IPsec VPN

프로토콜 출현에 대한 간략한 역사적 배경

1994년 IAB(Internet Architecture Board)는 "인터넷 아키텍처의 보안" 보고서를 발표했습니다. 이 문서에서는 인터넷에서 추가 보안 도구를 적용하는 주요 영역, 즉 무단 모니터링, 패킷 스푸핑 및 데이터 흐름 제어에 대한 보호를 설명합니다. 첫 번째이자 가장 중요한 보호 조치 중에는 데이터 흐름의 무결성과 기밀성을 보장하기 위한 개념과 기본 메커니즘을 개발할 필요성이 있었습니다. TCP/IP 계열의 기본 프로토콜을 변경하면 인터넷 전체가 재구성되기 때문에 기존 프로토콜을 기반으로 개방형 통신 네트워크에서 정보 교환의 보안을 보장하는 작업이 설정되었습니다. 따라서 IPv4 및 IPv6 프로토콜을 보완하는 보안 IP 사양이 만들어지기 시작했습니다.

IPSec 아키텍처

IP 보안은 IP 패킷 전송 중 암호화, 인증 및 보안 문제를 다루는 프로토콜 세트입니다. 현재 여기에는 거의 20개의 표준 제안과 18개의 RFC가 포함되어 있습니다.
IP 보안 사양(현재 IPsec으로 알려짐)은 IETF IP 보안 프로토콜 워킹 그룹(IP Security Protocol Working Group)에 의해 개발되었습니다. IPsec에는 원래 RFC로 게시된 3가지 알고리즘 독립적 핵심 사양, 즉 IP 보안 아키텍처, AH(인증 헤더), ESP(암호화된 데이터 캡슐화)(RFC1825, 1826 및 1827)가 포함되었습니다. 1998년 11월 IP 보안 프로토콜 작업 그룹은 현재 예비 표준 상태인 이 사양의 새 버전을 제안했으며 이는 RFC2401 - RFC2412입니다. RFC1825-27은 수년 동안 더 이상 사용되지 않는 것으로 간주되어 실제로 사용되지 않습니다. 또한 MD5, SHA 및 DES 프로토콜을 사용하는 여러 알고리즘 종속 사양이 있습니다.

그림 1. IPSec 아키텍처

IP 보안 프로토콜 워킹 그룹(IP Security Protocol Working Group)은 핵심 정보 관리 프로토콜도 개발하고 있습니다. 이 그룹의 임무는 사용되는 보안 프로토콜과 독립적인 애플리케이션 수준 키 관리 프로토콜인 IKMP(인터넷 키 관리 프로토콜)를 개발하는 것입니다. 키 관리 개념은 현재 ISAKMP(인터넷 보안 협회 및 키 관리 프로토콜) 사양과 Oakley 키 결정 프로토콜을 사용하여 탐색되고 있습니다. ISAKMP 사양은 사용된 프로토콜의 속성을 협상하는 메커니즘을 설명하는 반면, Oakley 프로토콜을 사용하면 인터넷의 컴퓨터에 세션 키를 설치할 수 있습니다. 이전에는 SKIP 프로토콜의 키 관리 메커니즘을 사용할 가능성도 고려되었지만 이제는 이러한 가능성이 사실상 어느 곳에서도 사용되지 않습니다. 새로운 주요 정보 관리 표준은 Kerberos에서 사용되는 것과 유사한 주요 배포 센터를 지원할 수 있습니다. IPSec용 Kerberos 기반 키 관리 프로토콜은 현재 비교적 새로운 KINK(Kerberized Internet Negotiation of Keys) 작업 그룹에서 다루고 있습니다.
IPsec 사양의 데이터 무결성 및 기밀성 보장은 각각 인증 및 암호화 메커니즘을 통해 제공됩니다. 후자는 소위 정보 교환 당사자들의 예비 합의에 기초합니다. "보안 컨텍스트" - 적용된 암호화 알고리즘, 주요 정보 관리 알고리즘 및 해당 매개변수. IPsec 사양은 당사자들이 정보를 교환하여 데이터 패킷의 인증 및 암호화를 위한 다양한 프로토콜과 매개변수는 물론 다양한 키 배포 체계를 지원하는 기능을 제공합니다. 이 경우 보안 컨텍스트에 대한 동의의 결과로 보안 매개변수 색인(SPI)이 설정됩니다. 이는 정보 교환 당사자 내부 구조의 특정 요소를 가리키는 포인터로서 가능한 보안 매개변수 세트를 설명합니다.
기본적으로 IPv6의 핵심 부분이 될 IPSec는 세 번째 계층, 즉 네트워크 계층에서 작동합니다. 결과적으로 전송된 IP 패킷은 네트워크 애플리케이션과 인프라에 투명한 방식으로 보호됩니다. 계층 4(즉, 전송)에서 작동하고 OSI 모델의 상위 계층과 더 밀접하게 연결되는 SSL(Secure Socket Layer)과 달리 IPSec는 낮은 수준의 보안을 제공하도록 설계되었습니다.

그림 2. OSI/ISO 모델

IPSec는 보호된 패킷을 식별하기 위해 가상 사설망을 통해 전송할 준비가 된 IP 데이터에 헤더를 추가합니다. 인터넷을 통해 전송되기 전에 이러한 패킷은 다른 IP 패킷 내에 캡슐화됩니다. IPSec는 DES(데이터 암호화 표준) 및 MD5(메시지 다이제스트 5)를 포함한 여러 암호화 유형을 지원합니다.
보안 연결을 설정하려면 세션의 두 참가자 모두 인증 알고리즘 및 키와 같은 보안 매개변수에 신속하게 동의할 수 있어야 합니다. IPSec는 참가자가 세션 매개변수를 협상할 수 있는 두 가지 유형의 키 관리 체계를 지원합니다. 이러한 이중 지원은 한때 IETF 작업 그룹에 약간의 마찰을 일으켰습니다.
현재 버전의 IP인 IPv4에서는 ISAKMP(Internet Secure Association Key Management Protocol) 또는 인터넷 프로토콜용 단순 키 관리를 사용할 수 있습니다. 새로운 버전의 IP인 IPv6에서는 현재 IKE로 알려진 ISAKMP를 사용해야 하지만 SKIP을 사용할 가능성도 배제되지 않습니다. 그러나 SKIP은 오랫동안 핵심경영후보로 고려되지 않았으며, 1997년에 후보목록에서 제외되었다는 점을 명심해야 한다.

AH 및 ESP 헤더

인증 헤더 AH

AH(인증 헤더)는 일반적인 선택 헤더이며 일반적으로 IP 패킷의 기본 헤더와 데이터 필드 사이에 위치합니다. AH의 존재는 전송 및 상위 레벨에서 정보를 전송하는 프로세스에 어떤 방식으로도 영향을 미치지 않습니다. AH의 주된 유일한 목적은 네트워크 계층의 소스 주소 스푸핑을 포함하여 패킷 내용의 무단 변경과 관련된 공격으로부터 보호하는 것입니다. 수신된 데이터의 신뢰성을 확인하려면 더 높은 수준의 프로토콜을 수정해야 합니다.
AH 형식은 매우 간단하며 96비트 헤더와 32비트 워드로 구성된 가변 길이 데이터로 구성됩니다. 필드 이름은 해당 내용을 상당히 명확하게 반영합니다. 다음 헤더는 다음 헤더를 나타내고, 페이로드 Len은 패킷 길이를 나타내며, SPI는 보안 컨텍스트에 대한 포인터이며, 시퀀스 번호 필드에는 패킷의 시퀀스 번호가 포함됩니다.

그림 3. AH 헤더 형식

패킷 시퀀스 번호는 IPsec 사양 개정 프로세스의 일부로 1997년에 AH에 도입되었습니다. 이 필드의 값은 발신자에 의해 생성되며 인증 프로세스 데이터 재사용과 관련된 공격으로부터 보호하는 역할을 합니다. 인터넷은 패킷이 전달되는 순서를 보장하지 않기 때문에 수신자는 성공적으로 인증된 패킷의 최대 시퀀스 번호에 대한 정보와 이전 시퀀스 번호가 포함된 패킷의 개수(보통 64)를 수신했는지 여부에 대한 정보를 저장해야 합니다.
교환 통신 회선이나 로컬 네트워크 채널을 통해 정보를 전송하기 위한 프로토콜에 사용되며 전송 매체의 무작위 오류를 수정하는 것을 목표로 하는 체크섬 계산 알고리즘과 달리 개방형 통신 네트워크에서 데이터 무결성을 보장하는 메커니즘에는 목표 변경에 대한 보호 수단이 있어야 합니다. 그러한 메커니즘 중 하나는 MD5 알고리즘의 특별한 사용입니다. AH가 형성되는 동안 해시 함수는 패킷 자체와 미리 합의된 키의 합집합에서 순차적으로 계산되고, 그런 다음 결과 결과와 키의 합집합에서 순차적으로 계산됩니다. 변형된 키. 이는 모든 IPv6 구현에 내보내기 제한이 적용되지 않는 하나 이상의 공통 알고리즘이 있는지 확인하는 기본 메커니즘입니다.

암호화된 ESP 데이터 캡슐화

암호화된 데이터 캡슐화가 사용되는 경우 ESP 헤더는 패킷에서 "표시되는" 선택적 헤더 중 마지막 헤더입니다. ESP의 주요 목적은 데이터 기밀성을 보장하는 것이므로 정보 유형에 따라 상당히 다른 암호화 알고리즘이 필요할 수 있습니다. 결과적으로 ESP 형식은 사용된 암호화 알고리즘에 따라 크게 변경될 수 있습니다. 그러나 보안 컨텍스트를 나타내는 SPI와 패킷의 시퀀스 번호를 포함하는 시퀀스 번호 필드는 필수 필드로 구분될 수 있습니다. "ESP 인증 데이터" 필드(체크섬)는 ESP 헤더에서 선택 사항입니다. ESP 패킷의 수신자는 ESP 헤더를 해독하고 적용된 암호화 알고리즘의 매개변수와 데이터를 사용하여 전송 계층 정보를 디코딩합니다.

그림 4. ESP 헤더 형식

ESP와 AH(및 이들의 조합)를 사용하는 데에는 전송 모드와 터널이라는 두 가지 모드가 있습니다.
전송 모드는 애플리케이션 서비스 정보를 포함하는 전송 계층 프로토콜(TCP, UDP, ICMP)을 포함하는 IP 패킷의 데이터 필드를 암호화하는 데 사용됩니다. 전송 모드 사용의 예는 전자 메일 전송입니다. 발신자에서 수신자로의 패킷 경로를 따라 있는 모든 중간 노드는 공용 네트워크 계층 정보와 일부 선택적 패킷 헤더(IPv6)만 사용합니다. 전송 모드의 단점은 패킷의 특정 발신자와 수신자를 숨기는 메커니즘과 트래픽 분석 기능이 부족하다는 것입니다. 이러한 분석의 결과는 정보 전달의 양과 방향, 가입자의 관심 분야, 관리자의 위치에 대한 정보가 될 수 있습니다.
터널 모드는 네트워크 계층 헤더를 포함하여 전체 패킷을 암호화합니다. 터널 모드는 조직과 외부 세계와의 정보 교환을 숨길 필요가 있는 경우에 사용됩니다. 이 경우 터널 모드를 사용하는 패킷의 네트워크 계층 헤더 주소 필드는 조직의 방화벽에 의해 채워지며 패킷의 특정 보낸 사람에 대한 정보는 포함되지 않습니다. 외부에서 조직의 로컬 네트워크로 정보를 전송할 때 방화벽의 네트워크 주소가 대상 주소로 사용됩니다. 방화벽이 초기 네트워크 계층 헤더의 암호를 해독한 후 패킷이 수신자에게 전달됩니다.

보안 연관

SA(보안 연결)는 이를 통과하는 트래픽에 보안 서비스를 제공하는 연결입니다. SA의 양쪽에 있는 두 대의 컴퓨터는 SA에 사용되는 모드, 프로토콜, 알고리즘 및 키를 저장합니다. 각 SA는 한 방향으로만 사용됩니다. 양방향 통신에는 두 개의 SA가 필요합니다. 각 SA는 하나의 모드와 프로토콜을 구현합니다. 따라서 하나의 패킷에 두 개의 프로토콜(예: AH 및 ESP)을 사용해야 하는 경우 두 개의 SA가 필요합니다.

보안 정책

보안 정책은 SPD(Security Policy Database)에 저장됩니다. SPD는 데이터 패킷에 대해 패킷 삭제, IPSec를 사용하여 패킷을 처리하지 않음, IPSec를 사용하여 패킷 처리 등 세 가지 작업 중 하나를 지정할 수 있습니다. 후자의 경우, SPD는 어떤 SA를 사용해야 하는지(물론 적절한 SA가 이미 생성되었다고 가정)를 나타내거나 어떤 매개변수를 사용하여 새 SA를 생성해야 하는지도 나타냅니다.
SPD는 각 패킷의 처리를 매우 효과적으로 제어할 수 있는 매우 유연한 제어 메커니즘입니다. 패킷은 많은 수의 필드로 분류되며 SPD는 적절한 조치를 결정하기 위해 필드 중 일부 또는 전부를 검사할 수 있습니다. 이로 인해 두 시스템 간의 모든 트래픽이 단일 SA를 사용하여 전달되거나 각 응용 프로그램 또는 각 TCP 연결에 대해 별도의 SA가 사용되는 결과가 발생할 수 있습니다.

ISAKMP/오클리 프로토콜

ISAKMP는 SA를 설정하고 기타 주요 관리 기능을 수행하는 데 사용되는 프로토콜의 일반적인 구조를 정의합니다. ISAKMP는 여러 DOI(Domains of Interpretation)를 지원하며 그 중 하나가 IPSec-DOI입니다. ISAKMP는 완전한 프로토콜을 정의하지 않고 다양한 DOI 및 키 교환 프로토콜에 대한 "빌딩 블록"을 제공합니다.
Oakley 프로토콜은 Diffie-Hellman 키 교체 알고리즘을 사용하는 키 검색 프로토콜입니다. Oakley 프로토콜은 PFS(Perfect Forward Secrecy)를 지원합니다. PFS가 있다는 것은 시스템의 키가 손상된 경우 모든 트래픽을 해독하는 것이 불가능하다는 것을 의미합니다.

IKE 프로토콜

IKE는 ISAKMP의 기본 키 교환 프로토콜이며 현재 유일한 프로토콜입니다. IKE는 ISAKMP 위에 위치하며 ISAKMP SA와 IPSec SA를 모두 실제로 설정합니다. IKE는 프로토콜에서 사용할 수 있는 다양한 기본 기능 세트를 지원합니다. 그 중에는 해시 함수와 의사 난수 함수(PRF)가 있습니다.
해시 함수는 충돌 방지 함수입니다. 충돌 저항성은 H(m1)=H(m2)인 두 개의 서로 다른 메시지 m1과 m2를 찾는 것이 불가능하다는 사실을 의미합니다. 여기서 H는 해시 함수입니다.
의사 난수 함수의 경우 현재 HMAC 설계에서 특수 PRF 대신 해시 함수가 사용됩니다(HMAC는 해시 함수를 사용하는 메시지 인증 메커니즘입니다). HMAC를 정의하려면 암호화 해시 함수(H라고 부르자)와 비밀 키 K가 필요합니다. H는 일련의 데이터 블록에 순차적으로 적용되는 압축 절차를 사용하여 데이터가 해시되는 해시 함수라고 가정합니다. 이러한 블록의 길이를 바이트 단위로 B로 표시하고, L(L)로 해싱의 결과로 얻은 블록의 길이를 나타냅니다.

ipad = 바이트 0x36, B번 반복됨;
opad = 바이트 0x5C가 B번 반복되었습니다.

"텍스트" 데이터에서 HMAC를 계산하려면 다음 작업을 수행해야 합니다.

H(K XOR opad, H(K XOR ipad, 텍스트))

설명에 따르면 IKE는 HASH 값을 사용하여 당사자를 인증합니다. 이 경우 HASH는 ISAKMP의 페이로드 이름만을 참조하며 이 이름은 해당 내용과 관련이 없습니다.

AH, ESP, IKE에 대한 공격

IPSec 구성 요소에 대한 모든 유형의 공격은 시스템의 한정된 리소스를 이용하는 공격(일반적인 예는 서비스 거부 공격, 서비스 거부 또는 DOS 공격), 기능을 이용하는 공격으로 나눌 수 있습니다. 특정 IPSec 구현의 오류, 그리고 마지막으로 AH 및 ESP 프로토콜 자체의 약점을 기반으로 한 공격입니다. 순전히 암호화 공격은 무시할 수 있습니다. 두 프로토콜 모두 모든 암호화가 숨겨져 있는 "변환" 개념을 정의합니다. 사용된 암호화 알고리즘이 안정적이고 이를 통해 정의된 변환이 추가적인 약점을 유발하지 않는 경우(항상 그런 것은 아니므로 전체 시스템(프로토콜-변환-알고리즘)의 강점을 고려하는 것이 더 정확합니다) 이쪽에서는 모든 것이 괜찮습니다. 남은 것은 무엇입니까? 재생 공격 - 시퀀스 번호를 사용하여 레벨화됩니다(단일 경우에는 인증 및 AH 없이 ESP를 사용하는 경우 작동하지 않습니다). 또한 작업 순서(첫 번째 암호화, 그 다음 인증)는 "불량" 패킷의 빠른 거부를 보장합니다. 또한 암호화 세계의 최근 연구에 따르면 이 작업 순서가 가장 안전합니다. 일부에서는 역순이지만 매우 특별한 경우에는 잠재적인 보안 허점이 발생할 수 있습니다. 다행스럽게도 SSL이나 IKE 또는 "먼저 인증한 다음 암호화"하는 작업 순서가 있는 기타 일반적인 프로토콜은 이러한 특별한 경우에 적용되지 않으므로 이러한 허점이 없습니다. ). 남은 것은 서비스 거부 공격입니다.

아시다시피 이것은 완전한 방어가 불가능한 공격입니다. 그러나 RFC에 따르면 불량 패킷을 신속하게 거부하고 이에 대한 외부 반응이 없기 때문에 이 공격을 어느 정도 잘 처리할 수 있습니다. 원칙적으로 대부분의 알려진 네트워크 공격(스니핑, 스푸핑, 하이재킹 등)은 올바르게 사용하면 AH 및 ESP에 의해 성공적으로 저항됩니다. IKE를 사용하면 조금 더 복잡해집니다. 프로토콜은 매우 복잡하고 분석하기 어렵습니다. 또한 작성 시의 오타(HASH_R 계산 공식)로 인해 완전히 성공적인 솔루션(동일한 HASH_R 및 HASH_I)이 아니기 때문에 여러 잠재적인 "구멍"이 포함되어 있습니다(특히 첫 번째 단계에서는 모든 페이로드가 아님). 메시지가 인증됨) 그러나 그다지 심각하지 않으며 기껏해야 연결 설정을 거부하게 됩니다. IKE는 재생, 스푸핑, 스니핑, 하이재킹과 같은 공격으로부터 어느 정도 성공적으로 자신을 보호합니다. 암호화를 사용하면 다소 복잡합니다. AH 및 ESP처럼 별도로 수행되지 않고 프로토콜 자체에서 구현됩니다. 그러나 PRF(영구 알고리즘 및 기본 형식)를 사용하면 문제가 없습니다. 어느 정도는 DES가 현재 사양에서 유일한 필수 암호화 알고리즘으로 표시되고(ESP와 IKE 모두에 해당) 56비트 키로는 더 이상 충분하지 않은 것으로 표시된다는 점은 IPsec의 약점으로 간주될 수 있습니다. . 그러나 이것은 순전히 공식적인 약점입니다. 사양 자체는 알고리즘에 독립적이며 거의 모든 잘 알려진 공급업체는 오랫동안 3DES를 구현했습니다(일부는 이미 AES를 구현했습니다). 따라서 올바르게 구현되면 가장 "위험한" 공격이 남아 있습니다. 서비스 거부 .

IPSec 프로토콜 평가

IPSec 프로토콜은 전문가들로부터 엇갈린 평가를 받았습니다. 한편, IPSec 프로토콜은 네트워크를 통해 전송되는 데이터를 보호하기 위해 이전에 개발된 모든 프로토콜(Microsoft에서 개발한 PPTP 포함) 중에서 가장 우수하다는 점에 주목합니다. 상대방에 따르면 프로토콜이 지나치게 복잡하고 중복성이 있다는 주장도 있습니다. 따라서 Niels Ferguson과 Bruce Schneier는 "IPsec의 암호화 평가"라는 작업에서 IPsec의 거의 모든 주요 구성 요소에서 심각한 보안 문제를 발견했다고 언급했습니다. 저자들은 또한 프로토콜 제품군이 우수한 수준의 보안을 제공하려면 상당한 개선이 필요하다는 점을 지적합니다.

60년대 후반에 미국 국방고등연구계획국 DARPA는 ARPANet이라는 실험 네트워크를 만들기로 결정했습니다. 70년대에 ARPANet은 미국에서 제대로 작동하는 네트워크로 간주되기 시작했으며, 이 네트워크를 통해 미국의 주요 대학 및 연구 센터에 접근할 수 있었습니다. 80년대 초반에는 프로그래밍 언어의 표준화가 시작된 후 네트워크 상호 작용 프로토콜이 시작되었습니다. 이 작업의 결과로 7단계 ISO/OSI 네트워크 상호 작용 모델과 TCP/IP 프로토콜 제품군이 개발되었으며, 이는 로컬 및 글로벌 네트워크 구축의 기초가 되었습니다.

TCP/IP 네트워크에서 정보 교환의 기본 메커니즘은 일반적으로 80년대 초반에 형성되었으며 주로 이기종 통신 채널을 사용하여 서로 다른 운영 체제 간의 데이터 패킷 전달을 보장하는 것을 목표로 했습니다. ARPANet(나중에 현대 인터넷이 됨)에 대한 아이디어는 정부 국방 기관에서 나왔지만 실제로 네트워크는 연구 세계에서 시작되었으며 학계의 개방성 전통을 이어받았습니다. 90년대 중반에 인터넷이 상용화되기 전에도 많은 저명한 연구자들은 TCP/IP 프로토콜 스택의 보안과 관련된 문제를 지적했습니다. TCP/IP 프로토콜의 기본 개념은 컴퓨터 보안에 대한 현대적인 개념을 완전히 만족시키지 못합니다(경우에 따라 모순됨).

최근까지 인터넷은 이메일, 파일 전송, 원격 액세스 등 비교적 간단한 프로토콜을 사용하여 정보를 처리하는 데 주로 사용되었습니다. 오늘날 WWW 기술의 광범위한 사용으로 인해 분산 멀티미디어 정보 처리 도구의 사용이 점점 더 늘어나고 있습니다. 동시에, 클라이언트/서버 환경에서 처리되고 많은 수의 가입자가 동시에 집단적으로 액세스할 수 있도록 의도된 데이터의 양이 증가하고 있습니다. 이메일(PEM, PGP 등), WWW(보안 HTTP, SSL 등), 네트워크 관리(SNMPv2 등)와 같은 애플리케이션에 대한 정보 보안을 보장하기 위해 여러 애플리케이션 수준 프로토콜이 개발되었습니다. 그러나 TCP/IP 제품군의 기본 프로토콜에 보안 기능이 있으면 다양한 응용 프로그램과 서비스 간의 정보 교환이 가능해집니다.

프로토콜 출현에 대한 간략한 역사적 배경

1994년 IAB(Internet Architecture Board)는 "인터넷 아키텍처의 보안" 보고서를 발표했습니다. 이 문서에서는 인터넷에서 추가 보안 도구를 적용하는 주요 영역, 즉 무단 모니터링, 패킷 스푸핑 및 데이터 흐름 제어에 대한 보호를 설명합니다. 첫 번째이자 가장 중요한 보호 조치 중에는 데이터 흐름의 무결성과 기밀성을 보장하기 위한 개념과 기본 메커니즘을 개발할 필요성이 있었습니다. TCP/IP 계열의 기본 프로토콜을 변경하면 인터넷 전체가 재구성되기 때문에 기존 프로토콜을 기반으로 개방형 통신 네트워크에서 정보 교환의 보안을 보장하는 작업이 설정되었습니다. 따라서 IPv4 및 IPv6 프로토콜을 보완하는 보안 IP 사양이 만들어지기 시작했습니다.

IPSec 아키텍처

IP 보안은 IP 패킷 전송 중 암호화, 인증 및 보안 문제를 다루는 프로토콜 세트입니다. 현재 여기에는 거의 20개의 표준 제안과 18개의 RFC가 포함되어 있습니다.

IP 보안 사양(현재 IPsec으로 알려져 있음)은 IETF IP 보안 프로토콜 작업 그룹에서 개발되었습니다. IPsec에는 원래 RFC로 게시된 3가지 알고리즘 독립적 핵심 사양, 즉 IP 보안 아키텍처, AH(인증 헤더), ESP(암호화된 데이터 캡슐화)(RFC1825, 1826 및 1827)가 포함되었습니다. 1998년 11월 IP 보안 프로토콜 작업 그룹은 현재 예비 표준 상태인 이 사양의 새 버전을 제안했으며 이는 RFC2401 - RFC2412입니다. RFC1825-27은 수년 동안 더 이상 사용되지 않는 것으로 간주되어 실제로 사용되지 않습니다. 또한 MD5, SHA 및 DES 프로토콜을 사용하는 여러 알고리즘 종속 사양이 있습니다.

쌀. 1 – IPSec 아키텍처.

IP 보안 프로토콜 워킹 그룹(IP Security Protocol Working Group)은 핵심 정보 관리 프로토콜도 개발하고 있습니다. 이 그룹의 임무는 사용되는 보안 프로토콜과 독립적인 애플리케이션 수준 키 관리 프로토콜인 IKMP(인터넷 키 관리 프로토콜)를 개발하는 것입니다. 키 관리 개념은 현재 ISAKMP(인터넷 보안 협회 및 키 관리 프로토콜) 사양과 Oakley 키 결정 프로토콜을 사용하여 탐색되고 있습니다. ISAKMP 사양은 사용된 프로토콜의 속성을 협상하는 메커니즘을 설명하는 반면, Oakley 프로토콜을 사용하면 인터넷의 컴퓨터에 세션 키를 설치할 수 있습니다. 이전에는 SKIP 프로토콜의 키 관리 메커니즘을 사용할 가능성도 고려되었지만 이제는 이러한 가능성이 사실상 어느 곳에서도 사용되지 않습니다. 새로운 주요 정보 관리 표준은 Kerberos에서 사용되는 것과 유사한 주요 배포 센터를 지원할 수 있습니다. IPSec용 Kerberos 기반 키 관리 프로토콜은 현재 비교적 새로운 KINK(Kerberized Internet Negotiation of Keys) 작업 그룹에서 다루고 있습니다.

IPsec 사양의 데이터 무결성 및 기밀성 보장은 각각 인증 및 암호화 메커니즘을 통해 제공됩니다. 후자는 소위 정보 교환 당사자들의 예비 합의에 기초합니다. "보안 컨텍스트" – 암호화 알고리즘, 주요 정보 관리 알고리즘 및 해당 매개변수를 적용했습니다. IPsec 사양은 당사자들이 정보를 교환하여 데이터 패킷의 인증 및 암호화를 위한 다양한 프로토콜과 매개변수는 물론 다양한 키 배포 체계를 지원하는 기능을 제공합니다. 이 경우 보안 컨텍스트에 대한 동의의 결과로 보안 매개변수 색인(SPI)이 설정됩니다. 이는 정보 교환 당사자 내부 구조의 특정 요소를 가리키는 포인터로서 가능한 보안 매개변수 세트를 설명합니다.

기본적으로 IPv6의 핵심 부분이 될 IPSec는 세 번째 계층, 즉 네트워크 계층에서 작동합니다. 결과적으로 전송된 IP 패킷은 네트워크 애플리케이션과 인프라에 투명한 방식으로 보호됩니다. 계층 4(즉, 전송)에서 작동하고 OSI 모델의 상위 계층과 더 밀접하게 연결되는 SSL(Secure Socket Layer)과 달리 IPSec는 낮은 수준의 보안을 제공하도록 설계되었습니다.


쌀. 2 - OSI/ISO 모델.

IPSec는 보호된 패킷을 식별하기 위해 가상 사설망을 통해 전송할 준비가 된 IP 데이터에 헤더를 추가합니다. 인터넷을 통해 전송되기 전에 이러한 패킷은 다른 IP 패킷 내에 캡슐화됩니다. IPSec는 DES(데이터 암호화 표준) 및 MD5(메시지 다이제스트 5)를 포함한 여러 암호화 유형을 지원합니다.

보안 연결을 설정하려면 세션의 두 참가자 모두 인증 알고리즘 및 키와 같은 보안 매개변수에 신속하게 동의할 수 있어야 합니다. IPSec는 참가자가 세션 매개변수를 협상할 수 있는 두 가지 유형의 키 관리 체계를 지원합니다. 이러한 이중 지원은 한때 IETF 작업 그룹에 약간의 마찰을 일으켰습니다.

현재 버전의 IP인 IPv4에서는 ISAKMP(Internet Secure Association Key Management Protocol) 또는 인터넷 프로토콜용 단순 키 관리를 사용할 수 있습니다. 새로운 버전의 IP인 IPv6에서는 현재 IKE로 알려진 ISAKMP를 사용해야 하지만 SKIP을 사용할 가능성도 배제되지 않습니다. 그러나 SKIP은 오랫동안 핵심경영후보로 고려되지 않았으며, 1997년에 후보목록에서 제외되었다는 점을 명심해야 한다.

헤더 AH

AH(인증 헤더)는 일반적인 선택 헤더이며 일반적으로 IP 패킷의 기본 헤더와 데이터 필드 사이에 위치합니다. AH의 존재는 전송 및 상위 레벨에서 정보를 전송하는 프로세스에 어떤 방식으로도 영향을 미치지 않습니다. AH의 주된 유일한 목적은 네트워크 계층의 소스 주소 스푸핑을 포함하여 패킷 내용의 무단 변경과 관련된 공격으로부터 보호하는 것입니다. 수신된 데이터의 신뢰성을 확인하려면 더 높은 수준의 프로토콜을 수정해야 합니다.

AH 형식은 매우 간단하며 96비트 헤더와 32비트 워드로 구성된 가변 길이 데이터로 구성됩니다. 필드 이름은 해당 내용을 상당히 명확하게 반영합니다. 다음 헤더는 다음 헤더를 나타내고, 페이로드 Len은 패킷 길이를 나타내며, SPI는 보안 컨텍스트에 대한 포인터이며, 시퀀스 번호 필드에는 패킷의 시퀀스 번호가 포함됩니다.


쌀. 3 - AH 헤더 형식.

패킷 시퀀스 번호는 IPsec 사양 개정 프로세스의 일부로 1997년에 AH에 도입되었습니다. 이 필드의 값은 발신자에 의해 생성되며 인증 프로세스 데이터 재사용과 관련된 공격으로부터 보호하는 역할을 합니다. 인터넷은 패킷이 전달되는 순서를 보장하지 않기 때문에 수신자는 성공적으로 인증된 패킷의 최대 시퀀스 번호에 대한 정보와 이전 시퀀스 번호가 포함된 패킷의 개수(보통 64)를 수신했는지 여부에 대한 정보를 저장해야 합니다.

교환 통신 회선이나 로컬 네트워크 채널을 통해 정보를 전송하기 위한 프로토콜에 사용되며 전송 매체의 무작위 오류를 수정하는 것을 목표로 하는 체크섬 계산 알고리즘과 달리 개방형 통신 네트워크에서 데이터 무결성을 보장하는 메커니즘에는 목표 변경에 대한 보호 수단이 있어야 합니다. 그러한 메커니즘 중 하나는 MD5 알고리즘의 특별한 사용입니다. AH가 형성되는 동안 해시 함수는 패킷 자체와 미리 합의된 키의 합집합에서 순차적으로 계산되고, 그런 다음 결과 결과와 키의 합집합에서 순차적으로 계산됩니다. 변형된 키. 이는 모든 IPv6 구현에 내보내기 제한이 적용되지 않는 하나 이상의 공통 알고리즘이 있는지 확인하는 기본 메커니즘입니다.

ESP 헤더

암호화된 데이터 캡슐화가 사용되는 경우 ESP 헤더는 패킷에서 "표시되는" 선택적 헤더 중 마지막 헤더입니다. ESP의 주요 목적은 데이터 기밀성을 보장하는 것이므로 정보 유형에 따라 상당히 다른 암호화 알고리즘이 필요할 수 있습니다. 결과적으로 ESP 형식은 사용된 암호화 알고리즘에 따라 크게 변경될 수 있습니다. 그러나 보안 컨텍스트를 나타내는 SPI와 패킷의 시퀀스 번호를 포함하는 시퀀스 번호 필드는 필수 필드로 구분될 수 있습니다. "ESP 인증 데이터" 필드(체크섬)는 ESP 헤더에서 선택 사항입니다. ESP 패킷의 수신자는 ESP 헤더를 해독하고 적용된 암호화 알고리즘의 매개변수와 데이터를 사용하여 전송 계층 정보를 디코딩합니다.


쌀. 4 - ESP 헤더 형식.

ESP와 AH(및 이들의 조합)를 사용하는 모드에는 전송 모드와 터널 모드가 있습니다.

운송 모드

전송 모드는 애플리케이션 서비스 정보를 포함하는 전송 계층 프로토콜(TCP, UDP, ICMP)을 포함하는 IP 패킷의 데이터 필드를 암호화하는 데 사용됩니다. 전송 모드 사용의 예는 전자 메일 전송입니다. 발신자에서 수신자로의 패킷 경로를 따라 있는 모든 중간 노드는 공용 네트워크 계층 정보와 일부 선택적 패킷 헤더(IPv6)만 사용합니다. 전송 모드의 단점은 패킷의 특정 발신자와 수신자를 숨기는 메커니즘과 트래픽 분석 기능이 부족하다는 것입니다. 이러한 분석의 결과는 정보 전달의 양과 방향, 가입자의 관심 분야, 관리자의 위치에 대한 정보가 될 수 있습니다.

터널 모드

터널 모드는 네트워크 계층 헤더를 포함하여 전체 패킷을 암호화합니다. 터널 모드는 조직과 외부 세계와의 정보 교환을 숨길 필요가 있는 경우에 사용됩니다. 이 경우 터널 모드를 사용하는 패킷의 네트워크 계층 헤더 주소 필드는 조직의 방화벽에 의해 채워지며 패킷의 특정 보낸 사람에 대한 정보는 포함되지 않습니다. 외부에서 조직의 로컬 네트워크로 정보를 전송할 때 방화벽의 네트워크 주소가 대상 주소로 사용됩니다. 방화벽이 초기 네트워크 계층 헤더의 암호를 해독한 후 패킷이 수신자에게 전달됩니다.

보안 연관

SA(보안 연결)는 이를 통과하는 트래픽에 보안 서비스를 제공하는 연결입니다. SA의 양쪽에 있는 두 대의 컴퓨터는 SA에 사용되는 모드, 프로토콜, 알고리즘 및 키를 저장합니다. 각 SA는 한 방향으로만 사용됩니다. 양방향 통신에는 두 개의 SA가 필요합니다. 각 SA는 하나의 모드와 프로토콜을 구현합니다. 따라서 하나의 패킷에 두 개의 프로토콜(예: AH 및 ESP)을 사용해야 하는 경우 두 개의 SA가 필요합니다.

보안 정책

보안 정책은 SPD(Security Policy Database)에 저장됩니다. SPD는 데이터 패킷에 대해 패킷 삭제, IPSec를 사용하여 패킷을 처리하지 않음, IPSec를 사용하여 패킷 처리 등 세 가지 작업 중 하나를 지정할 수 있습니다. 후자의 경우, SPD는 어떤 SA를 사용해야 하는지(물론 적절한 SA가 이미 생성되었다고 가정)를 나타내거나 어떤 매개변수를 사용하여 새 SA를 생성해야 하는지도 나타냅니다.

SPD는 각 패킷의 처리를 매우 효과적으로 제어할 수 있는 매우 유연한 제어 메커니즘입니다. 패킷은 많은 수의 필드로 분류되며 SPD는 적절한 조치를 결정하기 위해 필드 중 일부 또는 전부를 검사할 수 있습니다. 이로 인해 두 시스템 간의 모든 트래픽이 단일 SA를 사용하여 전달되거나 각 응용 프로그램 또는 각 TCP 연결에 대해 별도의 SA가 사용되는 결과가 발생할 수 있습니다.

ISAKMP/오클리

ISAKMP는 SA를 설정하고 기타 주요 관리 기능을 수행하는 데 사용되는 프로토콜의 일반적인 구조를 정의합니다. ISAKMP는 여러 DOI(Domains of Interpretation)를 지원하며 그 중 하나가 IPSec-DOI입니다. ISAKMP는 완전한 프로토콜을 정의하지 않고 다양한 DOI 및 키 교환 프로토콜에 대한 "빌딩 블록"을 제공합니다.

Oakley 프로토콜은 Diffie-Hellman 키 교체 알고리즘을 사용하는 키 검색 프로토콜입니다. Oakley 프로토콜은 PFS(Perfect Forward Secrecy)를 지원합니다. PFS가 있다는 것은 시스템의 키가 손상된 경우 모든 트래픽을 해독하는 것이 불가능하다는 것을 의미합니다.

이케

IKE는 ISAKMP의 기본 키 교환 프로토콜이며 현재 유일한 프로토콜입니다. IKE는 ISAKMP 위에 위치하며 ISAKMP SA와 IPSec SA를 모두 실제로 설정합니다. IKE는 프로토콜에서 사용할 수 있는 다양한 기본 기능 세트를 지원합니다. 그 중에는 해시 함수와 의사 난수 함수(PRF)가 있습니다.

해시 함수는 충돌 방지 함수입니다. 충돌 저항이란 두 가지 다른 메시지를 찾는 것이 불가능하다는 사실을 의미합니다. m 1그리고 m 2, 그렇게 H(m 1)=H(m2), 어디 시간— 해시 함수.

의사 난수 함수의 경우 현재 HMAC 설계에서 특수 PRF 대신 해시 함수가 사용됩니다(HMAC는 해시 함수를 사용하는 메시지 인증 메커니즘입니다). HMAC를 정의하려면 암호화 해시 함수(H라고 부르자)와 비밀 키 K가 필요합니다. H는 일련의 데이터 블록에 순차적으로 적용되는 압축 절차를 사용하여 데이터가 해시되는 해시 함수라고 가정합니다. 이러한 블록의 길이를 바이트 단위로 B로 표시하고, L(L)로 해싱의 결과로 얻은 블록의 길이를 나타냅니다.

Ipad = 바이트 0x36, B번 반복됨;
opad = 바이트 0x5C가 B번 반복되었습니다.

"텍스트" 데이터에서 HMAC를 계산하려면 다음 작업을 수행해야 합니다.

H(K XOR opad, H(K XOR ipad, 텍스트))

설명에 따르면 IKE는 HASH 값을 사용하여 당사자를 인증합니다. 이 경우 HASH는 ISAKMP의 페이로드 이름만을 참조하며 이 이름은 해당 내용과 관련이 없습니다.

AH, ESP 및 IKE에 대한 공격.

IPSec 구성 요소에 대한 모든 유형의 공격은 시스템의 한정된 리소스를 이용하는 공격(일반적인 예는 서비스 거부 공격, 서비스 거부 또는 DOS 공격), 기능을 이용하는 공격으로 나눌 수 있습니다. 특정 IPSec 구현의 오류, 그리고 마지막으로 프로토콜 자체의 약점을 기반으로 한 공격이 있습니다. 아 그리고 ESP. 순전히 암호화 공격은 무시할 수 있습니다. 두 프로토콜 모두 모든 암호화가 숨겨져 있는 "변환" 개념을 정의합니다. 사용된 암호화 알고리즘이 안정적이고 이를 통해 정의된 변환이 추가적인 약점을 유발하지 않는 경우(항상 그런 것은 아니므로 전체 시스템(프로토콜-변환-알고리즘)의 강점을 고려하는 것이 더 정확합니다) 이쪽에서는 모든 것이 괜찮습니다. 남은 것은 무엇입니까? 재생 공격 - 시퀀스 번호를 사용하여 레벨링됩니다(단일 경우에는 인증 및 AH 없이 ESP를 사용하는 경우 작동하지 않습니다). 또한 작업 순서(첫 번째 암호화, 그 다음 인증)는 "불량" 패킷의 빠른 거부를 보장합니다. 또한 암호화 세계의 최근 연구에 따르면 이 작업 순서가 가장 안전합니다. 일부에서는 역순이지만 매우 특별한 경우에는 잠재적인 보안 허점이 발생할 수 있습니다. 다행스럽게도 SSL이나 IKE 또는 "먼저 인증한 다음 암호화"하는 작업 순서가 있는 기타 일반적인 프로토콜은 이러한 특별한 경우에 적용되지 않으므로 이러한 허점이 없습니다. ). 남은 것은 서비스 거부 공격입니다. 아시다시피 이것은 완전한 방어가 불가능한 공격입니다. 그러나 RFC에 따르면 불량 패킷을 신속하게 거부하고 이에 대한 외부 반응이 없기 때문에 이 공격을 어느 정도 잘 처리할 수 있습니다. 원칙적으로 대부분의 알려진 네트워크 공격(스니핑, 스푸핑, 하이재킹 등)은 올바르게 사용하면 AH 및 ESP에 의해 성공적으로 저항됩니다. IKE를 사용하면 조금 더 복잡해집니다. 프로토콜은 매우 복잡하고 분석하기 어렵습니다. 또한 작성 시의 오타(HASH_R 계산 공식)로 인해 완전히 성공적인 솔루션(동일한 HASH_R 및 HASH_I)이 아니기 때문에 여러 잠재적인 "구멍"이 포함되어 있습니다(특히 첫 번째 단계에서는 모든 페이로드가 아님). 메시지가 인증됨) 그러나 그다지 심각하지 않으며 기껏해야 연결 설정을 거부하게 됩니다. IKE는 재생, 스푸핑, 스니핑, 하이재킹과 같은 공격으로부터 어느 정도 성공적으로 자신을 보호합니다. 암호화는 다소 더 복잡합니다. AH 및 ESP처럼 별도로 수행되지 않고 프로토콜 자체에서 구현됩니다. 그러나 PRF(영구 알고리즘 및 기본 형식)를 사용하면 문제가 없습니다. 어느 정도는 DES가 현재 사양에서 유일한 필수 암호화 알고리즘으로 표시되고(ESP와 IKE 모두에 해당) 56비트 키로는 더 이상 충분하지 않은 것으로 표시된다는 점은 IPsec의 약점으로 간주될 수 있습니다. . 그러나 이것은 순전히 공식적인 약점입니다. 사양 자체는 알고리즘에 독립적이며 거의 모든 잘 알려진 공급업체는 오랫동안 3DES를 구현했습니다(일부는 이미 AES를 구현했습니다). 따라서 올바르게 구현되면 가장 "위험한" 공격이 남아 있습니다. 서비스 거부 .

프로토콜 평가

IPSec 프로토콜은 전문가들로부터 엇갈린 평가를 받았습니다. 한편, IPSec 프로토콜은 네트워크를 통해 전송되는 데이터를 보호하기 위해 이전에 개발된 모든 프로토콜(Microsoft에서 개발한 PPTP 포함) 중에서 가장 우수하다는 점에 주목합니다. 상대방에 따르면 프로토콜이 지나치게 복잡하고 중복성이 있다는 주장도 있습니다. 따라서 Niels Ferguson과 Bruce Schneier는 "IPsec의 암호화 평가"라는 작업에서 IPsec의 거의 모든 주요 구성 요소에서 심각한 보안 문제를 발견했다고 언급했습니다. 저자들은 또한 프로토콜 제품군이 우수한 수준의 보안을 제공하려면 상당한 개선이 필요하다는 점을 지적합니다. 이 문서에서는 일반 데이터 처리 체계의 약점과 암호화 알고리즘의 약점을 모두 이용하는 다양한 공격에 대해 설명합니다.

결론

이 기사에서는 IPsec 네트워크 보안 프로토콜에 관한 몇 가지 기본 사항을 다루었습니다. IPsec 프로토콜이 대부분의 가상 사설망 구현을 지배한다는 점은 주목할 가치가 있습니다. 현재 시장에서는 소프트웨어 구현(예: Microsoft Windows 2000 운영 체제에서 구현되는 프로토콜)과 IPsec의 하드웨어 및 소프트웨어 구현을 모두 제공합니다. 이는 Cisco, Nokia의 솔루션입니다. 다양한 솔루션에도 불구하고 모두 서로 호환됩니다. 이 기사는 IPSec과 현재 널리 사용되는 SSL을 비교하는 표로 마무리됩니다.

특징 IPSec SSL
하드웨어 독립성
암호 애플리케이션 변경이 필요하지 않습니다. TCP/IP 스택 소스 코드에 대한 액세스가 필요할 수 있습니다. 애플리케이션 변경이 필요합니다. 새로운 DLL이 필요하거나 애플리케이션 소스 코드에 대한 액세스가 필요할 수 있습니다.
보호 전체 IP 패킷. 더 높은 수준의 프로토콜에 대한 보호를 활성화합니다. 응용 프로그램 수준만 해당됩니다.
패킷 필터링 인증된 헤더, 보낸 사람, 받는 사람 주소 등을 기반으로 합니다. 간단하고 저렴합니다. 라우터에 적합합니다. 높은 수준의 콘텐츠와 의미론을 기반으로 합니다. 더 지능적이고 더 복잡해졌습니다.
성능 컨텍스트 전환 및 데이터 이동이 적습니다. 더 많은 컨텍스트 전환 및 데이터 이동. 대규모 데이터 블록은 암호화 작업 속도를 높이고 더 나은 압축을 제공할 수 있습니다.
플랫폼 라우터를 포함한 모든 시스템 주로 최종 시스템(클라이언트/서버)과 방화벽도 있습니다.
방화벽/VPN 모든 트래픽이 보호됩니다. 애플리케이션 수준 트래픽만 보호됩니다. ICMP, RSVP, QoS 등 보호되지 않을 수 있습니다.
투명도 사용자 및 애플리케이션용. 사용자에게만 해당됩니다.
현재 상태 새로운 표준. WWW 브라우저에서 널리 사용되며 일부 다른 제품에서도 사용됩니다.

연결

  • www.ietf.org/html.charters/ipsec-charter.html - IETF 워킹 그룹의 홈 페이지입니다. RFC 및 표준 제안에 대한 링크도 있습니다.
  • www.microsoft.com/rus/windows2000/library/security/w2k_IPSecurity.asp – Windows2000 Server의 IPSec 프로토콜 구현에 대한 정보.

감사의 말

접촉 중

급우

(인터넷 키 교환(IKE)) - 키 교환.

  • RFC 2410(NULL 암호화 알고리즘 및 IPsec과의 사용) - Null 암호화 알고리즘 및 해당 사용입니다.
  • RFC 2411(IP 보안 문서 로드맵) - 표준의 추가 개발입니다.
  • RFC 2412(OAKLEY 키 결정 프로토콜) - 키 준수 확인.
  • IPsec 아키텍처

    다른 잘 알려진 프로토콜과 달리 IPsec 프로토콜 SSL그리고 TLS, 네트워크 수준(레이어 3)에서 작동 OSI 모델). 이를 통해 IPsec을 보다 유연하게 만들어 다음을 기반으로 하는 모든 프로토콜을 보호하는 데 사용할 수 있습니다. TCP그리고 UDP. IPsec을 사용하여 두 장치 간에 보안을 제공할 수 있습니다. IP 노드, 둘 사이 게이트웨이보안 또는 IP 노드와 보안 게이트웨이 사이. 프로토콜은 IP 프로토콜 위에 있는 "상위 구조"이며, 아래 설명된 방식으로 생성된 IP 패킷을 처리합니다. IPsec은 네트워크를 통해 전송되는 데이터의 무결성 및/또는 기밀성을 보장할 수 있습니다.

    IPsec은 다음 프로토콜을 사용하여 다양한 기능을 수행합니다.

    • 인증 헤더(AH)는 가상 연결(전송된 데이터)의 무결성을 보장하고, 정보 출처에 대한 인증 및 이를 방지하는 추가 기능을 제공합니다. 패킷 재전송
    • ESP(Encapsulated Security Payload)는 개인 정보 보호를 제공할 수 있습니다( 암호화) 정보를 전송하여 기밀 트래픽의 흐름을 제한합니다. 또한 가상 연결(전송된 데이터)의 무결성을 보장할 수 있으며, 입증정보 출처 및 방지를 위한 추가 기능 패킷 재전송(ESP를 사용할 때마다 하나 이상의 보안 서비스 데이터 세트를 사용해야 함)
    • SA(보안 연결)는 AH ​​및/또는 ESP 작동에 필요한 매개변수를 제공하는 일련의 알고리즘과 데이터를 제공합니다. ISAKMP(인터넷 보안 협회 및 키 관리 프로토콜)는 인증 및 키 교환을 위한 기반을 제공하여 키의 신뢰성을 확인합니다.

    보안 협회

    "보안 가상 연결"(SA, "보안 협회") 개념은 IPsec 아키텍처의 기본입니다. SA는 단순 연결, 해당 트래픽을 이를 통해 전송하기 위해 형성됩니다. 보안 서비스를 구현할 때 AH 또는 ESP 프로토콜(또는 둘 다 동시에)을 사용하여 SA가 형성됩니다. SA는 지점 간 개념에 따라 정의되며 전송 모드(PTP)와 두 가지 모드로 작동할 수 있습니다. 터널링(RTU). 전송 모드는 두 IP 노드 사이의 SA를 통해 구현됩니다. 터널링 모드에서 SA는 다음을 생성합니다. IP 터널.

    모든 SA는 IPsec 모듈의 SADB(Security Associations Database) 데이터베이스에 저장됩니다. 각 SA에는 다음 세 가지 요소로 구성된 고유한 토큰이 있습니다.

    • 보안 매개변수 인덱스(SPI)
    • 대상 IP 주소
    • 보안 프로토콜 식별자(ESP 또는 AH)

    이러한 세 가지 매개변수가 있는 IPsec 모듈은 SADB에서 특정 SA에 대한 항목을 찾을 수 있습니다. SA 구성 요소 목록에는 다음이 포함됩니다.

    일련번호필드를 형성하는 데 사용되는 32비트 값 시퀀스 번호 AH 및 ESP 헤더에 있습니다. 시퀀스 번호 카운터 오버플로시퀀스 번호 카운터가 오버플로되었음을 알리는 플래그입니다. 재생 공격을 억제하기 위한 창패킷 재전송을 결정하는 데 사용됩니다. 필드의 값인 경우 시퀀스 번호지정된 범위에 속하지 않으면 패킷이 파기됩니다. 정보 아아사용된 인증 알고리즘, 필수 키, 키 수명 및 기타 매개변수. ESP 정보암호화 및 인증 알고리즘, 필수 키, 초기화 매개변수(예: IV), 키 수명 및 기타 매개변수 IPsec 작동 모드터널이나 대중교통 MTU조각화 없이 가상 채널을 통해 전송할 수 있는 최대 패킷 크기입니다.

    보안 가상 연결(SA)은 단순한, 그러면 조직의 경우 듀플렉스채널에는 최소한 2개의 SA가 필요합니다. 또한 각 프로토콜(ESP/AH)에는 각 방향에 대한 자체 SA가 있어야 합니다. 즉, AH+ESP 조합에는 4개의 SA가 필요합니다. 이 모든 데이터는 SADB에 있습니다.

    • AH: 인증 알고리즘.
    • AH: 인증을 위한 비밀키
    • ESP: 암호화 알고리즘.
    • ESP: 암호화 비밀 키.
    • ESP: 인증을 사용합니다(예/아니요).
    • 키 교환 옵션
    • 라우팅 제한
    • IP 필터링 정책

    SADB 데이터베이스 외에도 IPsec 구현은 SPD(보안 정책 데이터베이스) 데이터베이스를 지원합니다. SPD 항목은 IP 헤더 필드 값과 상위 계층 프로토콜 헤더 필드의 집합으로 구성됩니다. 이러한 필드를 선택기라고 합니다. 선택기는 나가는 패킷을 필터링하여 각 패킷을 특정 SA와 일치시키는 데 사용됩니다. 패킷이 생성되면 패킷의 해당 필드(선택기 필드)의 값이 SPD에 포함된 값과 비교됩니다. 해당 SA를 찾았습니다. 그런 다음 패킷에 대한 SA(있는 경우) 및 관련 SPI(보안 매개변수 인덱스)가 결정됩니다. 그런 다음 IPsec 작업(AH 또는 ESP 프로토콜 작업)이 수행됩니다.

    SPD에 포함된 선택기의 예:

    • 대상 IP 주소
    • 발신자 IP 주소
    • IPsec 프로토콜(AH, ESP 또는 AH+ESP)
    • 송신자 및 수신자 포트

    인증 헤더

    인증 헤더체재
    오프셋 옥텟 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
    8 64 시퀀스 번호
    96 무결성 검사 값(ICV)
    다음 헤더(8비트) AH 헤더 뒤에 오는 프로토콜 헤더 유형입니다. 이 필드를 사용하여 수신 IP-sec 모듈은 보호되는 상위 수준 프로토콜에 대해 학습합니다. 다양한 프로토콜에 대한 이 필드의 의미는 RFC 1700에서 찾을 수 있습니다. 페이로드 렌(8비트) 이 필드는 AH 헤더의 전체 크기를 32비트 단어에서 2를 뺀 값으로 지정합니다. 그러나 IPv6를 사용하는 경우 헤더 길이는 8바이트의 배수여야 합니다. 예약된(16비트) 예약되어 있습니다. 0으로 채워져 있습니다. 보안 매개변수 색인(32비트) 보안 매개변수의 색인입니다. 대상 IP 주소 및 보안 프로토콜(AN 프로토콜)과 함께 이 필드의 값은 이 패킷에 대한 보안 가상 연결(SA)을 고유하게 식별합니다. SPI 값 범위 1...255는 IANA에 의해 예약되어 있습니다. 시퀀스 번호(32비트) 일련 번호입니다. 재전송을 방지하는 역할을 합니다. 필드에는 단조롭게 증가하는 매개변수 값이 포함되어 있습니다. 수신자는 패킷 재생 보호 서비스를 거부할 수 있지만 이는 필수이며 항상 AH 헤더에 존재합니다. 송신 IPsec 모듈은 항상 이 필드를 사용하지만 수신자는 이를 처리하지 않을 수 있습니다. 무결성 검사 값

    AH 프로토콜은 인증, 즉 우리가 생각하는 사람과 통신하고 있는지, 우리가 수신하는 데이터가 전송 중에 손상되지 않았는지 확인하는 데 사용됩니다.

    출력 IP 패킷 처리

    송신 IPsec 모듈은 패킷이 AH 처리와 관련된 SA와 연결되어 있음을 확인하면 처리를 시작합니다. 모드(전송 모드 또는 터널링 모드)에 따라 AH 헤더를 IP 패킷에 다르게 삽입합니다. 전송 모드에서 AH 헤더는 IP 프로토콜 헤더 뒤, 상위 계층 프로토콜 헤더 앞에 위치합니다(일반적으로 TCP또는 UDP). 터널링 모드에서는 원본 IP 패킷 전체가 먼저 AH 헤더로 둘러싸인 다음 IP 프로토콜 헤더로 둘러싸여 있습니다. 이 헤더를 외부라고 하며 원래 IP 패킷의 헤더를 내부라고 합니다. 그 후 송신 IPsec 모듈은 일련 번호를 생성하여 필드에 기록해야 합니다. 시퀀스 번호. SA가 설정되면 시퀀스 번호는 0으로 설정되고 각 IPsec 패킷이 전송되기 전에 1씩 증가됩니다. 또한 카운터가 루프에 빠졌는지 확인하는 검사도 수행됩니다. 최대값에 도달한 경우 다시 0으로 설정됩니다. 재생 방지 서비스를 사용하는 경우 카운터가 최대값에 도달하면 송신 IPsec 모듈이 SA를 재설정합니다. 이는 다음으로부터 보호를 보장합니다. 패킷을 다시 보내는 중- 수신 IPsec 모듈이 필드를 확인합니다. 시퀀스 번호, 다시 도착하는 패킷을 무시합니다. 다음으로 ICV 체크섬이 계산됩니다. 여기서 체크섬은 비밀 키를 사용하여 계산됩니다. 이 키가 없으면 공격자는 해시를 다시 계산할 수 있지만 키를 모르면 올바른 체크섬을 생성할 수 없습니다. ICV를 계산하는 데 사용되는 특정 알고리즘은 RFC 4305에서 찾을 수 있습니다. 예를 들어 현재는 HMAC-SHA1-96 또는 AES-XCBC-MAC-96 알고리즘을 사용할 수 있습니다. AH 프로토콜은 IPsec 패킷의 다음 필드를 기반으로 체크섬(ICV)을 계산합니다.

    • 번역 중에 수정되지 않았거나 가장 중요한 것으로 식별된 IP 헤더 필드
    • AH 헤더(필드: “Next Header”, “Payload Len”, “Reserved”, “SPI”, “Sequence Number”, “Integrity Check Value”. ICV 계산 시 “Integrity Check Value” 필드는 0으로 설정됩니다.
    • 상위 계층 프로토콜 데이터
    전송 중에 필드가 변경될 수 있는 경우 ICV를 계산하기 전에 해당 값이 0으로 설정됩니다. 변경될 수 있지만 수신 시 해당 값을 예측할 수 있는 필드는 예외입니다. ICV를 계산할 때 0으로 채워지지 않습니다. 변경 가능한 필드의 예로는 체크섬 필드가 있고, 변경 가능하지만 미리 정의된 필드의 예로는 수신자의 IP 주소가 있습니다. ICV를 계산할 때 어떤 필드가 고려되는지에 대한 자세한 설명은 RFC 2402 표준에서 확인할 수 있습니다.

    입력 IP 패킷 처리

    IPsec 수신 모듈은 AH 프로토콜 메시지가 포함된 패킷을 수신한 후 수신자의 IP 주소, 보안 프로토콜(SA) 및 SPI 인덱스를 사용하여 해당 SADB(Security Associations Database)를 찾습니다. 일치하는 SA가 없으면 패킷이 삭제됩니다. 발견된 보안 가상 연결(SA)은 패킷 재생 방지 서비스가 사용 중인지 여부를 나타냅니다. 현장 확인이 필요한 경우 시퀀스 번호. 서비스가 사용되는 경우 해당 필드가 확인됩니다. 이를 위해 슬라이딩 윈도우 방식이 사용됩니다. 수신 IPsec 모듈은 너비가 W인 창을 생성합니다. 창의 왼쪽 가장자리는 최소 시퀀스 번호( 시퀀스 번호) 올바르게 수신된 패킷의 N개입니다. 필드가 포함된 패키지 시퀀스 번호 N+1부터 N+W까지의 값을 포함하는 가 올바르게 승인됩니다. 수신된 패킷이 창의 왼쪽 경계에 있으면 파기됩니다. 그런 다음 IPsec 수신 모듈은 SA 레코드에서 학습한 인증 알고리즘을 사용하여 수신된 패킷의 해당 필드에서 ICV를 계산하고 그 결과를 무결성 검사 값 필드에 있는 ICV 값과 비교합니다. 계산된 ICV 값이 수신된 값과 일치하면 들어오는 패킷은 유효한 것으로 간주되어 추가 IP 처리를 위해 허용됩니다. 검사 결과가 부정적이면 수신 패킷이 파기됩니다.

    보안 페이로드 캡슐화체재
    오프셋 옥텟 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 주소 및 보안 프로토콜(AN 프로토콜)과 함께 이 필드의 값은 이 패킷에 대한 보안 가상 연결(SA)을 고유하게 식별합니다. SPI 값 범위 1...255는 향후 사용을 위해 IANA에 의해 예약되어 있습니다. 시퀀스 번호(32비트) 일련 번호입니다. 재전송을 방지하는 역할을 합니다. 필드에는 단조롭게 증가하는 매개변수 값이 포함되어 있습니다. 수신자가 패킷 재전송 보호 서비스를 거부할 수 있음에도 불구하고 AH 헤더에는 항상 존재합니다. 발신자(발신 IPsec 모듈)는 항상 이 필드를 사용해야 하지만 수신자는 이를 처리할 필요가 없을 수도 있습니다. 페이로드 데이터(변수) 이 필드에는 "다음 헤더" 필드에 따른 데이터가 포함됩니다. 이 필드는 필수이며 정수 바이트로 구성됩니다. 이 필드를 암호화하는 데 사용되는 알고리즘에 암호화 프로세스를 동기화하기 위한 데이터(예: 초기화 벡터)가 필요한 경우 이 필드에 이 데이터가 명시적으로 포함될 수 있습니다. (0-255 옥텟) 추가. 예를 들어 블록 암호의 블록 크기와 같이 일반 텍스트가 일부 바이트의 배수가 되어야 하는 알고리즘에 필요합니다. 패드 길이(8비트) 패딩 크기(바이트)입니다. 다음 헤더(8비트) 이 필드는 "페이로드 데이터" 필드에 포함된 데이터 유형을 지정합니다. 무결성 검사 값합계를 확인하세요. IPv6의 경우 8바이트의 배수, IPv4의 경우 4바이트의 배수여야 합니다.

    IPsec 출력 패킷 처리

    송신 IPsec 모듈은 패킷이 ESP 처리가 필요한 SA와 연결되어 있음을 확인하면 처리를 시작합니다. 모드(전송 모드 또는 터널링 모드)에 따라 원래 IP 패킷이 다르게 처리됩니다. 전송 모드에서 송신 IPsec 모듈은 상위 수준 프로토콜을 프레이밍(캡슐화)하는 절차를 수행합니다(예: TCP또는 UDP), 원래 IP 패킷의 헤더에 영향을 주지 않고 ESP 헤더와 ESP 트레일러를 사용합니다. 터널링 모드에서 IP 패킷은 ESP 헤더와 ESP 트레일러로 둘러싸인 다음 외부 IP 헤더로 둘러싸여 있습니다. 다음으로 암호화가 수행됩니다. 전송 모드에서는 기본 계층 위의 프로토콜 메시지만 암호화됩니다(즉, 소스 패킷의 IP 헤더 뒤에 있는 모든 내용). 터널링 모드에서는 전체 소스 IP 패킷이 암호화됩니다. 송신 IPsec 모듈은 SA 레코드에서 암호화 알고리즘과 비밀 키를 결정합니다. IPsec 표준에서는 Triple-DES, AES 및 Blowfish 암호화 알고리즘을 사용할 수 있습니다. 일반 텍스트의 크기는 특정 바이트 수의 배수(예: 블록 알고리즘의 블록 크기)여야 하므로 암호화된 메시지에 필요한 패딩도 암호화 전에 수행됩니다. 암호화된 메시지가 필드에 배치됩니다. 페이로드 데이터. 현장에서 패드 길이추가 길이에 맞습니다. 그런 다음 AH에서와 같이 계산됩니다. 시퀀스 번호. 그런 다음 체크섬(ICV)이 계산됩니다. 체크섬은 IP 헤더의 일부 필드를 계산할 때 고려하는 AH 프로토콜과 달리 ESP에서는 ICV 필드를 뺀 ESP 패킷 필드에서만 계산됩니다. 체크섬이 계산되기 전에는 0으로 채워집니다. AH 프로토콜에서와 마찬가지로 ICV 계산 알고리즘은 처리 중인 패킷과 관련된 SA 기록에서 전송 IPsec 모듈을 통해 학습됩니다.

    들어오는 IPsec 패킷 처리

    ESP 프로토콜 메시지가 포함된 패킷을 수신한 후 IPsec 수신 모듈은 수신자의 IP 주소, ESP(보안 프로토콜) 및 SPI 인덱스를 사용하여 SADB(Security Associations Database)에서 해당 보안 가상 연결(SA)을 찾습니다. 일치하는 SA가 없으면 패킷이 삭제됩니다. 발견된 보안 가상 연결(SA)은 패킷 재생 방지 서비스가 사용 중인지 여부를 나타냅니다. 시퀀스 번호 필드를 확인해야 합니다. 서비스가 사용되는 경우 해당 필드가 확인됩니다. 이를 위해 AH와 마찬가지로 슬라이딩 윈도우 방식을 사용한다. 수신 IPsec 모듈은 너비 W의 창을 생성합니다. 창의 왼쪽 가장자리는 올바르게 수신된 패킷의 최소 시퀀스 번호 N에 해당합니다. N+1부터 N+W까지의 값을 포함하는 시퀀스 번호 필드가 있는 패킷이 올바르게 수신됩니다. 수신된 패킷이 창의 왼쪽 경계에 있으면 파기됩니다. 그런 다음 인증 서비스가 사용되는 경우 IPsec 수신 모듈은 SA 레코드에서 학습한 인증 알고리즘을 사용하여 수신된 패킷의 해당 필드에서 ICV를 계산하고 그 결과를 무결성 검사 값 필드에 있는 ICV 값과 비교합니다. 계산된 ICV 값이 수신된 값과 일치하면 들어오는 패킷이 유효한 것으로 간주됩니다. 검사 결과가 부정적이면 수신 패킷이 파기됩니다. 다음으로 패킷이 해독됩니다. IPsec 수신 모듈은 SA 레코드로부터 어떤 암호화 알고리즘이 사용되는지와 비밀 키를 학습합니다. 체크섬 확인 및 암호 해독 절차는 순차적으로 수행될 뿐만 아니라 병렬로 수행될 수도 있습니다. 후자의 경우 복호화 절차 이전에 체크섬 확인 절차가 완료되어야 하며, ICV 검사에 실패하면 복호화 절차도 종료되어야 합니다. 이를 통해 손상된 패킷을 신속하게 식별할 수 있으며, 결과적으로 서비스 거부 공격(DOS 공격)에 대한 보호 수준이 높아집니다. 다음은 해당 필드에 따라 복호화된 메시지입니다. 다음 헤더추가 처리를 위해 전송되었습니다.

    용법

    IPsec 프로토콜은 주로 조직화에 사용됩니다. VPN 터널. 이 경우 ESP 및 AH 프로토콜은 터널링 모드에서 작동합니다. 또한 특정 방식으로 보안 정책을 구성하면 해당 프로토콜을 사용하여 방화벽을 만들 수 있습니다. 방화벽의 핵심은 지정된 규칙에 따라 방화벽을 통과하는 패킷을 제어하고 필터링한다는 것입니다. 일련의 규칙이 설치되고 화면은 이를 통과하는 모든 패킷을 봅니다. 전송된 패킷이 이러한 규칙의 범위에 속하면 방화벽은 이에 따라 패킷을 처리합니다. 예를 들어 특정 패킷을 거부하여 안전하지 않은 연결을 중지할 수 있습니다. 그에 따라 보안 정책을 설정하면 인터넷 트래픽을 차단하는 등의 작업을 수행할 수 있습니다. 이를 위해서는 프로토콜 메시지가 포함된 패킷 전송을 금지하는 것으로 충분합니다. HTTP그리고 HTTPS. IPsec은 서버를 보호하는 데에도 사용할 수 있습니다. 이를 위해 서버 기능의 올바른 실행에 필요한 패킷을 제외하고 모든 패킷이 삭제됩니다. 예를 들어 웹 서버의 경우 TCP 포트 80을 통한 연결을 제외한 모든 트래픽을 차단하거나 다음과 같은 경우 TCP 포트 443을 통한 연결을 차단할 수 있습니다. HTTPS.

    또한보십시오

    연결

    • IPSec 구성 설명(cisco.com)

    IPSec는 다양한 기술과 암호화 방법에 의존하지만 IPSec는 일반적으로 다음과 같은 주요 단계로 간주될 수 있습니다.

      1 단계. IPSec 프로세스 시작. IPSec 당사자가 동의한 IPSec 보안 정책에 따라 암호화가 필요한 트래픽은 IKE 프로세스를 시작합니다.

      2 단계. IKE 1단계. IKE 프로세스는 IPSec 당사자를 인증하고 IKE 보안 연결 매개변수를 협상하여 IKE의 두 번째 단계 동안 IPSec 보안 연결 매개변수를 협상하기 위한 보안 채널을 생성합니다.

      3단계. IKE 2단계. IKE 프로세스는 IPSec 보안 연결 매개변수를 협상하고 통신 당사자의 장치에 대한 적절한 IPSec 보안 연결을 설정합니다.

      4단계. 데이터 전송. IPSec 매개변수와 보안 연결 데이터베이스에 저장된 키를 기반으로 통신하는 IPSec 당사자 간에 통신이 발생합니다.

      5단계. IPSec 터널 종료. IPSec 보안 연결은 삭제되거나 수명 제한이 초과되었기 때문에 종료됩니다.

    IPSec 작동 모드

    IPSec 작동에는 전송 모드와 터널 모드의 두 가지가 있습니다.

    전송 모드에서는 IP 패킷의 정보 부분만 암호화됩니다. IP 패킷 헤더가 변경되지 않으므로 라우팅에는 영향이 없습니다. 전송 모드는 일반적으로 호스트 간 연결을 설정하는 데 사용됩니다.

    터널 모드에서는 전체 IP 패킷이 암호화됩니다. 네트워크를 통해 전송되기 위해서는 다른 IP 패킷에 배치됩니다. 그러면 보안 IP 터널이 생성됩니다. 터널 모드를 사용하면 원격 컴퓨터를 가상 사설망에 연결하거나 게이트웨이 간 개방형 통신 채널(인터넷)을 통해 보안 데이터 전송을 구성하여 가상 사설망의 여러 부분을 연결할 수 있습니다.

    IPSec 변환 협상

    IKE 프로토콜은 IPSec 변환(IPSec 보안 알고리즘)을 협상합니다. IPSec 변환 및 관련 암호화 알고리즘은 다음과 같습니다.

      AH 프로토콜(인증 헤더 - 인증 헤더).인증 및 (선택 사항) 재생 감지 서비스를 제공하는 보안 프로토콜입니다. AH 프로토콜은 디지털 서명 역할을 하며 IP 패킷의 데이터가 변조되지 않도록 보장합니다. AH 프로토콜은 데이터 암호화 및 복호화 서비스를 제공하지 않습니다. 이 프로토콜은 독립적으로 사용하거나 ESP 프로토콜과 함께 사용할 수 있습니다.

      ESP(보안 페이로드 캡슐화) 프로토콜.기밀성 및 데이터 보호는 물론 (선택 사항) 인증 및 재생 감지 서비스를 제공하는 보안 프로토콜입니다. Cisco IPSec 지원 제품은 ESP를 사용하여 IP 패킷의 페이로드를 암호화합니다. ESP 프로토콜은 독립적으로 사용하거나 AH와 함께 사용할 수 있습니다.

      DES 표준(데이터 암호화 표준 - 데이터 암호화 표준).패킷 데이터를 암호화하고 해독하는 알고리즘입니다. DES 알고리즘은 IPSec과 IKE 모두에서 사용됩니다. DES 알고리즘은 56비트 키를 사용하므로 컴퓨팅 리소스를 더 많이 소비할 뿐만 아니라 암호화도 더욱 강력해집니다. DES 알고리즘은 통신하는 각 IPSec 당사자의 장치에 동일한 비밀 암호화 키가 필요한 대칭 암호화 알고리즘입니다. Diffie-Hellman 알고리즘은 대칭 키를 생성하는 데 사용됩니다. IKE와 IPSec는 DES 알고리즘을 사용하여 메시지를 암호화합니다.

      "트리플" DES(3DES).세 개의 서로 다른 키가 있는 표준 DES의 세 가지 반복을 사용하는 DES의 변형으로, 본질적으로 DES의 강도를 세 배로 늘립니다. 3DES 알고리즘은 IPSec 내에서 데이터 스트림을 암호화하고 해독하는 데 사용됩니다. 이 알고리즘은 168비트 키를 사용하므로 높은 암호화 신뢰성을 보장합니다. IKE와 IPSec는 3DES 알고리즘을 사용하여 메시지를 암호화합니다.

      AES(고급 암호화 표준). AES 프로토콜은 훨씬 더 강력한 암호화를 제공하는 Rine Dale4 암호화 알고리즘을 사용합니다. 많은 암호학자들은 AES가 일반적으로 깨지지 않는다고 믿습니다. AES는 이제 연방 정보 처리 표준입니다. 이는 미국 정부 기관이 민감하지만 분류되지 않은 정보를 보호하기 위해 사용하는 암호화 알고리즘으로 정의됩니다. AES의 문제점은 유사한 프로토콜보다 구현하는 데 더 많은 컴퓨팅 성능이 필요하다는 것입니다.

    IPSec 변환은 또한 두 가지 표준 해싱 알고리즘을 사용하여 데이터 인증을 제공합니다.

      MD5 알고리즘(메시지 다이제스트 5).데이터 패킷을 인증하는 데 사용되는 해싱 알고리즘입니다. Cisco 제품은 해싱을 통해 추가로 보호되는 메시지 인증 코드의 변형인 MD5 계산 HMAC(해시된 메시지 인증 코드)를 사용합니다. 해싱은 임의 길이의 입력 메시지에 대해 고정 길이 출력을 생성하는 단방향(즉, 되돌릴 수 없는) 암호화 프로세스입니다. IKE, AH 및 ESP는 데이터 인증을 위해 MD5를 사용합니다.

      알고리즘 SHA-1(Secure Hash Algorithm-1 - 보안 해싱 알고리즘 1).데이터 패킷을 인증하는 데 사용되는 해싱 알고리즘입니다. Cisco 제품은 SHA-1을 사용하여 계산된 HMAC 코드의 변형을 사용합니다. IKE, AH 및 ESP는 데이터 인증에 SHA-1을 사용합니다.

    IKE 프로토콜에서는 DES, 3DES, MD5 및 SHA를 사용하는 Diffie-Hellman 알고리즘을 사용하여 대칭 키가 생성됩니다. Diffie-Hellman 프로토콜은 공개 키 사용을 기반으로 하는 암호화 프로토콜입니다. 이를 통해 두 당사자는 충분히 안전한 통신 채널 없이도 공유 비밀 키에 동의할 수 있습니다. DES 및 NMAC 알고리즘에는 공유 비밀 키가 필요합니다. Diffie-Hellman 알고리즘은 IKE 내에서 세션 키를 생성하는 데 사용됩니다. DH(Diffie-Hellman) 그룹 – 키 교환 절차에 사용되는 암호화 키의 "강도"를 정의합니다. 그룹 번호가 높을수록 키가 "더 강력"하고 보안이 강화됩니다. 그러나 DH 그룹 번호가 증가하면 키의 "강도"와 보안 수준이 높아지지만 동시에 "더 강력한" 키를 생성하려면 중앙 프로세서의 부하도 증가한다는 사실을 고려해야 합니다. 더 많은 시간과 자원.

    WatchGuard 장치는 DH 그룹 1, 2, 5를 지원합니다.

      DH 그룹 1: 768비트 키

      DH 그룹 2: 1024비트 키

      DH 그룹 5: 1536비트 키

    VPN을 통해 통신하는 두 장치는 모두 동일한 DH 그룹을 사용해야 합니다. 장치에서 사용할 DH 그룹은 IPSec 1단계 절차 중에 선택됩니다.