IPSec
- VPN의 안전을 위해 사용되는 프로토콜 → IP버전 6(IPv6) 필요
VPN: 양 끝단에 안전한 통로를 생성하는 응용체계
특징
- 암호화, 무결성, 보호 및 인증기능 제공
- 네트워크 계층에 존재하기 때문에 운영체제의 일부
- IPSec을 구현하기 위해선 운영체제에 변화가 일어남
- 모든 작업이 OS(운영체제)에서 일어나기 때문에 응용프로그램의 변화 X← 가장 중요한 장점(응용프로그램에서 자유로움)
- IPSec은 2가지 주요한 부분으로 구성
- IKE(Internet Key Exchange)
- 상호인증과 대칭키 공유를 설정해 줌
- SSL세션 및 접속과 유사하게 2가지 단계가 존재
- 보안 페이로드 캡슐화 및 인증 헤더(ESP/AH)
- AH는 무결성만 제공하는 반면 ESP는 암호화 및 IP 패킷의 무결성을 제공
- IKE(Internet Key Exchange)
결점
- 너무 과도하게 기술적임 → 구현이 어렵고 복잡성으로 인해 야기되는 결함이 있음
- IPSec 표준이 3가지 부분으로 나뉘어 있을 뿐만 아니라 표준마다 저자가 모두 다름
- RFC 2407, RFC 2408, RFC 2409
- RFC 2407, RFC 2408, RFC 2409
- IPSec 표준이 3가지 부분으로 나뉘어 있을 뿐만 아니라 표준마다 저자가 모두 다름
- 심각한 보안상 결함을 가지고 있음
- 상호운용성 문제 O
IKE
- IKE는 1단계, 2단계로 구성되는데 1단계가 더 복잡
- 1단계 : IKE 보안 연계(SA)가 성립
- SSL의 세션 성립과 대략적으로 유사
- 반드시 필요한 단계
- 2단계 : IPSec 보안 연계가 성립
- SSL의 접속 성립과 비교될 수 있다
- 반드시 필요하진 않음 → 2단계가 반복해 발생하지 않는다면 낭비 → IPSec은 과도하게 기술적
- 1단계 : IKE 보안 연계(SA)가 성립
IKE 1단계의 키 옵션
- 4가지 다른 키 옵션이 존재
- 공개키 암호화(원래 버전)
- 공개키 암호화(개선 버전)
- 전자서명
- 대칭키
- 각각 키 옵션에 대해 주모드와 적극모드가 있음 → 1단계에는 총 8개의 버전이 존재 → 과도하게 기술적
- 공개키 암호화와 전자서명 옵션이 있는 이유
- 앨리스는 항상 자신의 개인키를 알고 있지만, 밥의 공개키를 최초에는 모를 수 있다.
- 전자서명 버전
- 앨리스는 밥의 공개키를 사전에 알지 않아도 됨
→ 밥의 공개키 처리에 드는 불필요한 메시지를 줄일 수 있음
- 앨리스는 밥의 공개키를 사전에 알지 않아도 됨
- 전자서명 버전
- 앨리스는 항상 자신의 개인키를 알고 있지만, 밥의 공개키를 최초에는 모를 수 있다.
- 1단계의 각 변형은 세션키를 구현하기 위해 일회성 디피-헬먼 키 교환을 사용
- PFS를 달성한다는 장점
- 다음과 같은 표현 사용
- a와 b는 각각 앨리스와 밥의 디피-헬먼 지수이며 g는 생성자, p는 디피-헬먼에 사용되는 소수이다.
- p와 q는 공개된 키다.
IKE 1단계 : 전자서명(변형)
- 디지털 서명 주모드이다.
- 약속된 표현
- CP = 제시된 암호기법
- CS = 선정된 암호기법
- IC = 요청자 “쿠키”
- RC = 응답자 “쿠키”
- K = h(IC, RC, g^{ab} mod p, R_A, R_B)
- SKEYID =h(R_A, R_B, g^{ab} mod p)
- proof_A = [h(SKEYID, g^a mod p, g^b mod p, IC, RC, CP, "앨리스")]_{앨리스}
- 디지털 서명, 주모드
디지털 서명, 주모드에서 주고받기
- 과정
- 앨리스는 자신이 지원하고 있는 암호에 정보를 쿠키와 함께 제공
- 밥은 앨리스의 암호 중 하나를 선택하고 쿠키는 두 번째 메시지에 실어 보낸다.
- 앨리스는 nonce와 앨리스의 디피-헬먼 값을 포함해 전송
- 밥은 유사하게 nonce와 자신의 디피-헬먼 값을 제공한다.
- 마지막 2개의 메시지는 앨리스와 밥이 각기 전자서명을 통해 상대방을 인증한다.
- 특징
- 해당 프로토콜에서 수동형 공격자는 앨리스 또는 밥의 신분을 찾을 수 없다
→ 익명성을 제공 - “암호기법 제안”과 “암호기법 수용”의 일부로 g 및 p 값을 흥정할 수 있다.
- 해당 프로토콜에서 수동형 공격자는 앨리스 또는 밥의 신분을 찾을 수 없다
- 과정
- 디지털 서명, 적극모드
디지털 서명, 적극모드
- 주모드와 달리 앨리스나 밥의 신분을 의도적으로 숨기려 하지 않기에 단순함
- 디피-헬먼 값 g^a mod p 가 첫 번째 메시지의 일부임 → q, p 값 흥정이 불가능함
→ 적극모드가 구현되어야 한다면 각각의 키 옵션에 대해 주모 들어가 구현되어야 한다. - 결론 - 1단계 전자서명 버전
- 수동형 공격자는 적극모드에서는 밥과 앨리스의 신분을 알 수 있지만, 주모드에서는 알 수 없다.
- 능동형 공격자는 적극모드와 주모드 둘 다 밥과 앨리스의 신분을 알 수 있다.
IKE 1단계 : 대칭키
- 약속된 표현
- K_{AB} = 사전에 공유된 대칭키
- K = h(IC, RC, g^{ab} mod p, R_A, R_B, K_{AB})
- SKEYID = h(K, g^{ab} mod p)
- proof_A = h(SKEYID, g^a mod p, g^b p, IC, RC, CP, 앨리스)
- 과정
- 약속된 표현만 다를 뿐 “디지털 서명, 주모드”와 같다.
- 약속된 표현만 다를 뿐 “디지털 서명, 주모드”와 같다.
- 대칭키 주모드
- 5번째 메시지에서 키 K로 암호화해 자신의 신분을 전송하는데
키 K를 결정하기 위해 밥은 K_{AB}를 알아야 함 → 주모드에선 익명성이 보장됨
→ 상대가 앨리스라는 것을 알기 전에 앨리스와 공유하는 대칭키 K_{AB}를 어떻게 사용?
→ 자기모순에 빠지게 됨 - 밥이 프로토콜과는 독립적으로 앨리스의 신분을 알 수 있는 다른 방법이 필요
→ 앨리스의 IP 주소를 앨리스의 신분 역할로 이용하기 때문에 생긴 결과
- 5번째 메시지에서 키 K로 암호화해 자신의 신분을 전송하는데
- 대칭키 적극모드
- 디지털 서명, 적극모드와 동일한 프로토콜을 가지고 있다.
- 디지털 서명, 적극모드와 동일한 프로토콜을 가지고 있다.
- 특징
- 대칭키 주모 들어가 매우 복잡한데도 불구하고 신분을 감추는데 실패한다. → 사용하는 의미가 없음.
- 적극모드 또한 신분을 숨기지 못해 의미 없음
IKE 1단계 : 공개키 암호
- 약속된 표현
- K = h(IC, RC, g^{ab} p, R_A, R_B)
- SKEYID = h(R_A, R_B, g^{ab} mod p)
- proof_A = h(SKEYID, g^a mod p, g^b mod p, IC, RC, CP, "앨리스")
- 공개키 암호화, 주모드
- 약속된 표현만 제외하면 전자서명 주모드 방식과 같음
공개키 암호화, 주모드
- 약속된 표현만 제외하면 전자서명 주모드 방식과 같음
- 공개키 암호화 적극모드
공개키 암호화 적극모드
- 트루디가 디피-헬먼 지수 a, b와 무작위 nonce R_A, R_B를 생성한다고 가정
→ 프로토콜에 나오는 모든 나머지 숫자를 모두 계산할 수 있다.- g^{ab} mod p, K, SKEYID, proof_A, proof_B
- 가능한 이유
→ 앨리스와 밥의 공개키가 이미 공개되어 있기 때문 - 트루디가 모든 값을 생성해야 하는 이유
거짓 대화 생성 - 앨리스와 밥 간의 하자 없는 거래인 것처럼 IPSec 접속 설정 가능
- 모든 관찰자에게 하자가 없는 것처럼 보임
- 트루디가 거짓 대화를 생성할 수 있는 명백한 결함 발생 → “그럴듯한 부인권"
- 트루디가 디피-헬먼 지수 a, b와 무작위 nonce R_A, R_B를 생성한다고 가정
- 특징
- 명백한 결함인 “그럴듯한 부인권”을 IPSec이 가지고 있는 보안 특성 중 하나로 인식
- “그럴듯한 부인권”을 가지고 있는 프로토콜은 앨리스와 밥이 대화했던 것 자체를 부정가능
← 트루디가 모든 것을 거짓으로 속임수를 사용했을 수도 있기 때문- 하지만 해당 방식도 보안상 문제 발생
- 앨리스가 밥으로부터 구매했어도, 밥이 앨리스에게 전자서명을 요구하지 않았다면
나중에 앨리스는 그 구매를 거절할 수 있다.
- 앨리스가 밥으로부터 구매했어도, 밥이 앨리스에게 전자서명을 요구하지 않았다면
- 하지만 해당 방식도 보안상 문제 발생
- “그럴듯한 부인권”을 가지고 있는 프로토콜은 앨리스와 밥이 대화했던 것 자체를 부정가능
- 명백한 결함인 “그럴듯한 부인권”을 IPSec이 가지고 있는 보안 특성 중 하나로 인식
IPSec 쿠키
- IPSec 프로토콜에 나오는 쿠키 IC와 RC
- 클로킹 방지 토큰으로 표현
- 서비스를 거부(Dos)하거나 공격을 보다 어렵기 하기 위한 목적으로 사용
- 상태를 유지하기 위해 사용되는 웹 쿠키와는 관련이 없음
- TCP SYN 플러딩
- 전형적인 Dos 공격
- TCP SYN 요청이 있을 때마다 3-방향 핸드세이크의 세 번째 단계에서 해당 ACK 도착
→ 반개방 접속을 기억해야 함 → 상태 정보를 유지해야 함 - 상태유지 기능을 이용해 공격자가 DoS를 생성할 수 있음
- 공격자가 대량의 SYN 패킷 폭격 → 반개방 접속 발생 → 접속 종결하지 않으면 서버 자원이 고갈
→ 서버는 정상적인 SYN 요구를 처리할 수 없어 DoS 공격을 허용
- DoS의 위협 감소를 위해 서버는 비상태성을 유지해야 함
→ 각 주모드 프로토콜에서 서버는 첫 번째 메시지로부터 암호 제안 CP를 기억해야 한다.
← 서버는 6번째 메시지에서 계산을 위해 그 값이 필요하기 때문 - 첫 번째 메시지와 함께 시작하는 상태를 유지해야 함
- IPSec 쿠키는 Dos를 방지하는 측면에선 그다지 도움 안됨
IKE 1단계 요약
- IKE 1단계 최종 결과물
- 상호인증
- 대칭키 공유
- IKE 보안 연계(SA)
- 1단계는 비용이 많이 듦 → 1단계 IKE 보안결합이 이뤄진 이후 사용할 수 있는 2단계 포함
- 공개키 모드 계산 비용
- 주모 드는 6개의 메시지가 필요
IKE 2단계
- IKE 1단계보다 단순함 → 1단계에 비해 비용이 적게 듦
- IKE 2단계를 시도하기 전에 IKE 1단계를 선행
- 공유 대칭키 K, IPSec 쿠키, IC, RC, IKE 보안 연계 등은 모두 실현됐음
- IKE 2단계 프로토콜 적용사항
- ESP나 AH를 포함하여 암호기법을 제안한다.
- SA는 IKE 보안 연계(SA)를 의미한다.
- 해시 1,2,3은 SKEYID, R_A, R_B, 1단계의 IKE SA에 의존한다.
- 키는 KEYMAT = h(SKEYID, R_A, R_B, junk)로부터 유도되며,
”junk”는 공격자를 포함한 누구에게나 알려져 있다. - SKEYID의 값은 1단계 키 방법에 의존한다.
- 선택적으로 PFS를 달성될 수 있다. 일회성 디피-헬먼 교환을 통해 이를 구현할 수 있다.
- IKE 2단계 프로토콜
- R_A와 R_B는 IKE 1단계와 다름 → 결과적으로 각 2단계 “연결”에서 생성된 키는 모두 다름
- IKE 1단계에서 IKE 보안 연계를 실현, 2단계에서 IPSec 보안 연계 실현
- 이 시점에서 앨리스와 밥 모두 인증
- 현재 연결에서 사용할 수 있는 공유 대칭키를 가짐
IPSec의 목적
- 목적 : 상호인증과 IP 데이터그램으로 알려진 IP 패킷을 보호하는 것
- 상호인증 → IKE 1단계에서 구현
- 데이터그램 보호 → IKE 2단계에서 구현
IPSec과 IP 데이터그램의 비교
- IP 데이터그램
- 헤더와 데이터로 구성
- 라우터들이 패킷을 전송하기 위해 IP헤더를 볼 수 있어야 한다.
→ IPSec은 IPSec은 IP 헤더를 암호화할 수 없다. - TTL 항목의 숫자는 패킷이 하나씩 전송될 때마다 감소
→ 전송과정에서 변하는 헤더는 무결성 보장 XTTL: 패킷이 사라지기 전에 남은 조각의 수
- IPSec은 IP 데이터그램을 보호하기 위해 ESP 또는 AH를 사용
- 선택에 따라 ESP 헤더나 AH 헤더가 새로운 IPSec으로 보호된 데이터그램에 포함
전송모드 및 터널모드
- ESP 또는 AH 사용과는 독립적으로 IPSec은 전송모드 또는 터널모드 사용 가능
- IPSec 전송모드
- 새로운 ESP/AH 헤더는 IP 헤더와 데이터 사이에 끼어있음
- 전송 모드는 추가적인 헤더정보를 최소한으로 추가하기 때문에 효율적
- 원래 IP 헤더는 변하지 않는다.
- 단점 : 수동형 공격자가 헤더를 볼 수 있다.
- 호스트와 호스트 간의 통신을 위해 설계됨
- IPSec 터널모드
- 전체 IP 패킷은 새로운 IP 패킷에 캡슐화됨
- 최종 도착지 방화벽으로부터 최종 도착지 호스트까지 패킷을 전송하기 위해 원래 IP 헤더 필요
→ 방화벽 간 보호된 트래픽을 위해 터널모드가 필요 - 장점
- 패킷이 암호화되었다는 가정하에 원래의 IP헤더는 더 이상 공격자에게 노출되지 않는다.
- 터널 모드가 방화벽간에 사용된다면 특히 유용
- 패킷이 암호화되었다는 가정하에 원래의 IP헤더는 더 이상 공격자에게 노출되지 않는다.
- 단점
- 추가적인 IP 헤더로 인한 부담
- 추가적인 IP 헤더로 인한 부담
- 비교
- 기존 IP패킷을 새로운 보안 IPSec패킷에 항상 캡슐화 가능 → 전송모드가 반드시 필요하진 않다.
- 전송모드가 좀 더 효율적이기 때문에 호스트 간 트래픽이 보호될 때는 전송모드가 선호
- 터널모드는 호스트 간의 경우, 발송지와 도착지의 주소를 보호하지 않는다.
← 이러한 주소는 새로운 IP 헤더에 반복적으로 나타나기 때문
ESP와 AH
- 모드 선택(전송/터널) 후, 데이터그램에 적용하고자 하는 보호 형태를 고려해야 함
- 비밀성, 무결성 또는 둘 다 선택 가능
- 더불어 헤더에 적용하고자 하는 보호 형태도 고려해야 함
- IPSec에서는 ESP와 AH 중 하나만 선택 가능
- AH
- 인증 헤더(AH)는 무결성만 제공 → 암호화가 없음
- 무결성 보호는 모든 IP 헤더 외의 내용과 헤더의 일부 필드에 적용
- AH는 IP 헤더 항목을 “변하는” 항목과 “변하지 않는” 항목으로 구분
→ “변하지 않는” 항목을 무결성 보호 적용
- ESP
- 캡슐화된 페이로드(ESP)는 무결성과 비밀성을 제공
- IP 관점에서, 데이터에 해당하는 IP 헤더 외의 모든 데이터에 비밀성과 무결성이 모두 보호
- ESP로 무결성만을 보호하는 법 → NULL 암호를 선택하는 것 → AH와 동일한 기능
- AH의 존재 이유
- ESP는 IP헤더에 어떤 보호도 제공하지 않지만, AH는 변하지 않는 항목에 대한 무결성 보호 제공
- ESP는 NULL 암호가 아닌 것을 선택하면 IP 헤더를 제외한 나머지 모든 것을 암호화
→ 방화벽은 TCP 헤더를 시험하기 위해 패킷 내용을 볼 수 없게 된다.
→ 방화벽은 TCP 헤더를 읽을 수 있는지 여부를 모름 - 마이크로소프트사를 귀찮게 만들고 싶어서(싫어서,,)(?)