11. IPSec

개요

IP의 문제점에 대해 확인하고 이를 보완하는 IPSec에 대해 학습한다.

IP 문제점

네트워크란게 좀 막 만들다가 흥해버려서(원래는 자기네들끼리만 통신하려고 만들었음) 대규모로 돌리거나 할 때 문제가 발생한다. 

Loss/duplication

Best effort의 특징으로 대충 말하자면 최선을 다해서 잘 전송해보겠는데 누락될 수 있다는 의미로 packet이 loss되거나 duplicate 될 수 있다. 

Out of order

packet의 도착 순서를 완벽히 보장할 수 없다는 의미로 packet switching의 경우 패킷의 경로가 달라져 순서를 보장하지 못한다.

no authentication

별도의 인증 절차가 없기 때문에 Source IP를 바꿔 다른사람인 척(spoofing) 하는게 그리 어렵지 않다.

 

이런 이유가 위에서 말했듯이 자기네들 끼리만 사용하려고 만들었던건데 그러다보니 그 당시에는 위험한 사용자라는 개념이 없었다. 근데 이게 흥하면서 전 세계로 퍼지다보니까 악의적인 사용자가 생긴거다;;

IPSec

IP가 위험하다보니까 이 프로토콜에 대해 보안 suite를 만든 것이 이 IPSec이다. 이 IPSec의 목표는 크게 3가지로

    1. Source IP를 인증하여 Spoofing 공격 방어

    2. 순서를 보장하여 replay 공격 방어(TCP는 seq num이 있기 때문에 해당 사항 없음)

    3. 무결성 및 기밀성 보장.

그리고 이를 위한 2가지 모드가 있다. 

    1. Transport mode: payload만 조치하여 암호화하는 방식

    2. Tunnel mode: 위와 달리 Header도 같이 암호화하여 캡슐화 하는 방식

여기에 추가로 2가지 프로토콜도 있다.

    1. Authentocation Header (AH): 무결성을 보장할 수 있지만 암호화 로직이 없기에 기밀성까지는 보장하지 못함

    2. Encapsulation Security Protocol (ESP): 암호화까지 가능하여 기밀성까지 보장할 수 있다,

이렇게 2개의 모드와 2개의 프로토콜을 조합하여 총 4가지 경우의 수가 나오는데 가장 많이 사용하는 방식은 Tunnel mode with ESP로 가장 많은 처리를 하는 방식이다. 

Authentication Header

무결성을 보장하고 이에 따라 Source IP에 대해 보호하여 spoofing 공격에 대해 방어한다. 그리고 순서를 보장하기 때문에 replay 공격에 대해 방어할 수 있다. 문제는 위에서도 말했듯이 암호화 로직이 없기 때문에 기밀성까지 보장하지는 못한다.

이를 구현한 방법은 Transport 이면 Header와 payload 사이에 AH header를 삽입하는 방식, Tunnel 이면 새로운 Header를 만들고 그 뒤에 AH header를 삽입하는 방식으로 IP payload, IP header + IP payload의 해시와 대칭키를 이용한다. dst에서는 이를 받아서 AH header를 보고 무결성을 확인할 수 있는 것이다.

그리고 별도의 32bit의 seq num을 이용하여 순서를 보장해 replay 공격에 대한 방어를 할 수 있다. 

Encapsulating Security Payload

AH와 마찬가지로 32bit seq num을 이용하여 순서를 보장하고 비슷하게 무결성을 보장하는데 차이점은 대칭키를 이용하여 암호화를 진행한다. 

Transport, Tunnel 차이는 AH와 동일하기에 별도로 설명은 안하고 AH와 차이점은 기존에는 payload, header를 바로 해싱했는데 여기는 일단 암호화를 먼저 하여 대상 앞, 뒤로 header와 tailer를 만든다. 그리고 그 만든 header와 tailer까지 모두 해싱하여 맨 뒤에 ESP authentication을 만든다. 

그리고 조금 다른 점은 next header 정보가 AH에는 header에 있는데 ESP는 tailer에 있다. 

Security Associations(SAs)

위에서 해싱을 하든 암호화를 하든 결국 대칭키가 필요하다고 했는데 이 대칭키를 안전하게 전송하는 것도 중요하다. 키가 털리면 의미가 없으니까... 그래서 별도의 기관을 두어 안전하게 전송하는 방법을 이용하는데 이 기관을 SA라고 한다.

이 SA는  Key나 교환 방식 등 명세를 유지하고 있고 이를 이용하여 Recall이나 IPSec의 연결 지향을 구현한다.

뭐 아무튼 이런 명세는 별도 DB를 이용하여 저장한다. 그리고 이는 꼭 key를 교환할 때만 사용하는 것이 아니라 security policy나 session을 유지할 때도 사용된다. 

 

SPI: Security Parameter Index로 SADB의 유니크한 Index이고 SA를 식별하는 데 사용된다.

SPD: Security Policy Database로 Policy를 저장하는데 사용된다.

 

그리고 이러한 교환은 2단계에 걸쳐 진행된다.

Phase1:  end to end에 대해 negotiation 과정을 거치고 보조 채널을 만든다. 길이, 암호화, 매커니즘 등에 대해 협상을 진행하고 이는 한번만 진행한다.

Phase2: 이후 실제 키를 교환할 custom 채널을 구축하는데 이는 매번 새로 구축한다. 그리고 Diffie-Hellman 를 사용하여 직접적으로 키를 교환한다.