네트워크 보안 프로토콜 2~6

IPSec 세부 프로토콜
가) AH 프로토콜 (Authentication Header)
- 메시지인증코드MAC을 이용하여 무결성 인증과 송신처 인증을 제공해주는 프로토콜
- 송신측에서 MAC과 인증키를 통해 인증데이터(ICV라고도 함)를 계산해 전송하고, 수신측에서 이를 검증한다
- IP헤더의 변경 가능한 필드를 제외하고 패킷 전체를 대상으로 인증 데이터를 계산한다
(변경 가능한 필드 : TTL, Header checksum, NAT 환경일때의 Source IP)

- AH 프로토콜은 평문으로 전송된다 (암호화X)

 

낮은 버전의 IPSec 모듈 문제점
- NAT 환경에서는 Source IP가 변경되므로, 구형장비는 대응되지 않음
AH모듈은 인증오류가 나고 ESP는 정상 통신이 됨

 

메시지 인증 코드 MAC
- 무결성
- 송신처 인증
- HMAC(Hash Based MAC) HMAC-SHA1, HMAC-SHA256/384/512
- CMAC(Cipher Based MAC)
- 공통의 인증키를 Hash하여 무결성/송신처 인증을 함

디지털 서명
- 부인방지 (개인키) 메시지 인증 코드 AMC는 왜 부인방지가 안 되는가?

-> 사용자 A와 B는 공통의 인증키를 사용하므로, 둘 다 같은 MAC 값이 나온다. 디지털 서명의 경우 개인키를 가지므로 부인방지 기능이 있다

 

 

필드
Security Parameter Index (32bit)
Sequence Number (32bit) : 재전송 공격에 대한 방지
Authentication Data(Digest) : 인증 데이터

 

1) AH 프로토콜의 전송모드
- IP 헤더의 변경 가능한mutable 필드를 제외한 패킷 전체를 인증
원본 :        IP-H / IP Payload
전송모드 : IP-H / AH-H / IP Payload

 

 

2) AH 프로토콜의 터널모드
- NEW IP-H의 변경 가능한mutable 필드를 제외한 NEW IP 패킷 전체를 인증
원본 :                                                  IP-H / IP Payload
전송모드 : NEW IP-H / AH-H / (원본) IP-H / IP Payload

 

 

나) ESP 프로토콜 (Encasulating Security Protocol)
- 메시지 인증 코드MAC 과 암호화를 이용하여 무결성 인증과 송신처 인증, 기밀성을 제공
- 암호화를 선택적으로 적용할 수 있다
- ESP는 IP 헤더를 인증하지 않는다

헤더필드
- SPI : 현재 연결에 대한 보안연관SA 식별자
- Sequence Number : 재전송 공격 방지
- ESP 트레일러 : 블록암호 패딩정보 + 페이로드 프로토콜 타입
- ESP Auth : 인증 데이터

 

1) ESP 프로토콜의 전송모드
- 암호화 : 페이로드와 ESP-T(트레일러)
- 인증 : ESP-H ~ ESP-T (밑줄 표기)
원본 :        IP-H / IP Payload
전송모드 : IP-H / ESP-H / IP Payload / ESP-T / ESP Auth
=> IP 페이로드와 ESP 트레일러를 암호화하고, 암호화된 데이터와 ESP 헤더를 인증


2) ESP 프로토콜의 터널모드
- 암호화 : 원본 IP와 페이로드, ESP-T(트레일러)
- 인증 : ESP-H ~ ESP-T (밑줄 표기)
원본 :                                                     IP-H / IP Payload
전송모드 : NEW IP-H / ESP-H / (원본) IP-H / IP Payload / ESP-T / ESP Auth
=> 원본 IP패킷 전체와 ESP 트레일러를 암호화하고, 암호화된 데이터와 ESP 헤더를 인증

 

 

(실습

짤막복습 : secpol.msc = 로컬 보안 정책 / 사전키공유 보안 방식 = PSK

 

강의 영상과는 다소 차이가 있지만, 새 보안 규칙을 만들어서 확인 가능. 기본적으로 ESP에 체크되어 있다

 

인증방식에 문자열 사용(PSK) 설정

IPSec 터널을 지정하지 않음 = 전송모드로 동작시키겠다는 뜻

 

ping메시지를 날렸는데, 패킷의 IP 프로토콜의 헤더에 ICMP가 아니라 AH로 표기됨 (캡슐화된 내역을 자세히 까보면 ICMP로 표기되어 있긴 함)

=> IPSec이 적용되고 있다는 뜻

 

ESP도 Protocol에 바로 ESP로 표기됨. 암호화되어 캡슐화된 내역을 볼 수 없으므로, ICMP인지 아닌지 알 수 없다)

 

 

 

2 END --

 

 

SA (Security Association)과 SP (Security Prolicy)
가) 보안연관 SA
- 적용할 보안 설정 정보
- 단방향성/일방향성을 갖는다
- 보안 연관 데이터베이스 SAD
- 주요 항목
1. SPI 보안연관 식별자
2. Sequence Number Counter 패킷의 순서번호 카운터
3. AH/ESP 정보 : 프로토콜 정보, MAC 알고리즘, 대칭키, 관련 키 정보 등
4. Mode : IPsec 동작 모드(전송/터널)

나) 보안정책 SP
- 적용할 보안의 종류를 정의하는 것
- IP 패킷을 허용하거나, 폐기하거나, IPSec 적용을 하는 등.
- 보안 정책 데이터베이스 SPD 

 

IPSec 패킷 송수신 절차
가) 송신 절차
- SPD (보안정책 검색)
-> 정책상 Bypass 또는 SAD 검색 (보안연관 검색)
-> 보안연관이 있을 경우, IPSec 처리를 한다
-> 보안연관이 없을 경우 인터넷 키교환IKE (SA 협상) 한 뒤 다시 IPSec 처리
-> 패킷이 전달됨

나) 수신 절차
패킷 유형
1. IPSec
-> SAD 검색 (보안연관)
-> 일치 항목이 있으면 IPSec 처리, 없으면 삭제
-> 패킷 전달

2. IP 패킷
-> SPD 검색 (보안정책)
-> Bypass일 경우 패킷 전달, 그 외는 삭제
-> 패킷 전달

 

 

인터넷 키교환 IKE : Internet Key Exchange
- 보안 관련 설정들을 생성, 협상 및 관리하는 프로토콜 500/udp

1) 1단계
- 2단계에서 사용할 메시지들을 어떻게 보호할 것인지 협상하는 단계. IKE용 마스터키 생성
- 이 단계를 통해 생성된 보안연관SA를 IKE SA라고 한다. 양방향성을 가진다.

  1. Main Mode : 3쌍의 메시지를 교환하는 방식(기본). 세션 ID를 암호화하여 보안성이 높음
  2. Aggressive Mode : 비교적 빠르고 3개의 메시지 교환. 세션 ID를 암호화하지 않아 보안성이 낮다

 

2) 2단계

- IPSec SA라고 한다

- Quick Mode를 이용한다

- 단방향성을 가지며 수신용SA와 송신용SA가 생성된다

 

 

*** 보안서비스 제공 복습 (암기 필수)
1) 기밀성 Confidentiality
- 메시지가 도청되어도 내용을 알 수 없음을 보장한다
- 대칭암호화. AH 프로토콜은 암호화를 지원하지 않으며, ESP 프로토콜만 암호화를 지원

2) 비연결형 무결성 Connectionless Integrity
- 위변조되지 않았음을 보장한다
- 메시지 인증 코드MAC를 통해 (순서무관) ip 패킷별로 무결성 보장
- 송식측에서 전송된 인증데이터/MAC 계산 값을 수신측에서 검증

3) 데이터 원천 인증/송신처 인증 Data Origin Authentication
- 수신된 메시지가 올바른 송신처로부터 온 것을 보장
- 메시지 인증 코드MAC를 통해 IP 패킷을 올바른 송신처로부터 온 것임을 보장

4) 재전송 공격 방지 Protection Aginst Replays
- IP 패킷별로 순서번호를 전송하고, 수신측에서 해당 보안연관SA에 순서번호를 유지하고 검증한다

(SA에 있는 Sequence Number Counter와 관련)

5) 접근 제어 Access Control

- 보안정책SP을 통해 패킷에 대한 시스템 접근 제어

- 허용Bypass, 폐기Discard, 보호Protect (IPSec 적용)

 

6) 제한된 트래픽 흐름의 기밀성 Limited Traffic Flow Confidentiality

- 트래픽 흐름이란? 패킷이 어디서 출발해, 어느 목적지로 가는지에 대한 정보 (Source IP, Destination IP)
- ESP/터널모드의 경우 New IP를 통해 터널/보안 게이트구간은 노출된다. 그러나 원본 IP 헤더는 암호화되어 게이트웨이~종단노드 구간의 기밀성은 보장된다

(특히 6번 항목은 직접 손으로 써보면서 외우는게 좋다. 보지 않고 쓰기가 애매한 항목)

 

 

 

3 END --

 

 

전송 계층 보안 - SSL/TLS
개요
- SSL은 Netscape사의 웹 브라우저를 위한 보안 프로토콜
- 국제 인터넷 표준화 기구 IETF에서 SSL3.0기반 TLS 1.0(= TLS 1.0) 버전 발표
- 클라이언트/서버 환경에서 *TCP 기반 Application에 대한 종단간 보안서비스를 제공하기 위해 만들어진 전송계층 보안 프로토콜
- 전송계층과 어플리케이션 계층 사이에서 동작
- 각 어플리케이션 프로토콜이 SSL을 이용할 경우 구분하기 위해 고유한 well-known 포트 할당
(ex https443 smtps465 ftps990 telnets992)

 

보안서비스 제공
1) 기밀성
- 대칭 암호를 이용한 암호화
2) 무결성
- 메시지 인증 코드 MAC을 통해 위변조여부 확인 가능한 무결성 제공
3) 인증
- 공개키 인증서를 이용한 상호 인증

 

SSL/TLS 프로토콜 구조

Application L	Application Protocol
SSL/TLS Layer	Handshake	Change Cipher Spec	Alert	Application data
	Record
Transport L	TCP Protocol

 

(SSL/TLS Layer는 2계층으로 상위계층에 4개, 하위계층에 1개 Record가 있다)

SSL/TLS Layer의 프로토콜 4가지
1. Handshake
2. Change Cipher Spec
3. Alert
4. Record

만약 5개를 물어본다면 Application data 도 포함

 

세부 기능

Handshake
- 종단간의 보안 파라미터를 협상하기 위한 프로토콜

Change Cipher Spec
- 협상된 보안 파라미터를 적용/변경하기 위해 상대방에게 알리는 프로토콜

(보안 파라미터 정보
- 키 교환 인증 알고리즘 (RSA, Diffie-Hellman, DSA)
- 암호 알고리즘 (암호키, 키 길이, 블럭 암호 모드(CBC, CFB, CCM, GCM 등))
- MAC 알고리즘)

Alert
- 종단간 통신중 오류 발생시 통제/알려주기 위한 프로토콜

Record
- 보안 파라미터 등을 이용해 실질적 암복호화/검증 등 역할을 하는 프로토콜

 

Application data
- 상위 프로토콜의 데이터를 전달해주기 위한 프로토콜

 

 

 

사전지식

가용량에 제한에 있으므로, 웹서버는 다수의 클라이언트 요청을 동시에 처리하기 위해 응답을 받으면 TCP 연결을 바로 종료한다
(가용량: 동시에 처리할 수 있는 최대 클라이언트 수)
그러나 이로 인한 오버헤드(잦은 연결-종료 과정에 따른)가 커지자,

HTTP/1.1 버전에 Connection: Keep-alive

해당 헤더 필드가 추가되면서 어느정도 연결을 유지할 수 있게 됨

응답 데이터 파싱Parsing
- 추가로 요청해야할 자원 (js, css, img ...)
- ex html 페이지에 있는 <script src="/경로"> <img src="/경로"> 등

보안협상으로 설정된 내용을 연결시마다 같이 공유하여 오버헤드를 줄이자
=> 세션 설정 & 연결 설정
=> 세션 설정 = 완전 협상(13단계) / 연결 설정 = 단축협상(6단계)

 

 

 

상태 유지 프로토콜Stateful

1) 세션Session과 연결Connection 기반의 상태 유지 프로토콜
- 완전 협상을 통해 세션을 생성하고, 이 세션정보를 공유하는 다수의 연결을 단축협상을 통해 생성한다

완전협상 - 주로 암호 알고리즘 결정    단축협상 - 주로 암호키/비밀키 결정       └ 연결당 암호키가 다 다름

* 커코프Kerckhoff의 원리
- 암호 강도는 암호 알고리즘을 숨김에 의해 유지되는 것이 아니라, 암호키의 기밀성을 통해 유지된다

 

2) 세션 상태 정보
- 완전 협상을 통해 생성되는 상태정보. 세션이 유지되는 동안 보안 파라미터가 관리된다.
- 대표적으로 대칭암호 알고리즘, HMAC용 해시 알고리즘 등 

필드
- session ID : 세션 식별자. 32byte
- chiper spec (암호명세) : 대칭 암호 알고리즘, 키길이, 블럭 암호 모드, HMAC 용 해시 알고리즘 등
- master secret : 키 블럭을 생성하기 위해 서버-클라가 공유하는 48Byte 비밀값
                             premaster secrect, server random, dlient random을 조합/해시하여 생성
                             두 random값은 salt 역할

 

3) SSL/TLS 연결 상태 정보
- 실제 통신이 이루어지는 단위로 단축 협상을 통해 생성
- 세션 상태를 공유하며 통신 수행
- 암호키, 인증키 등

 

필드

server/client random : 단축 협상을 통해 서버/클라가 생성한 32byte 난수 값
server/client write key : 암호화 비밀키
server/client write MAC secret : 메시지 인증 코드MAC 생성시 사용하는 인증키
server/client write IV : 블록암호모드에 사용하는 IV

 

 

4) 세션 상태정보와 연결 상태정보를 이용한 키 생성
완전 협상을 통해 주고 받은 사전 마스터 비밀Premaster Secret과 client random, server random을 조합 해시하여 마스터 비밀Master secret을 생성함
-> 세션상태에 저장
-> 단축협상을 통해 주고받은 client random, server random, Master secret을 조합해시하여 키블럭Key Block 생성
-> 키블럭을 통해 서버/클라의 암호용 비밀키, MAC용 인증키, 블럭 암호용 IV 등을 계산한다

 

 

4 END --

 

 

완전협상과정 (Handshake 프로토콜)
가) Cline Hello 메시지
- 클라이언트가 지원 가능한 SSL/TLS 버전, 암호 도구 목록Cipher suites, 압축 방식 등을 서버에 전달
- Client random : 32바이트 난수값 (master secret과 키 블럭 생성시 salt 역할)
- Session ID : 서버 세션을 식별하기 위한 ID. 완전협상때는 빈 값, 단축 협상때는 ID를 담아서 전송
- 암호 도구 목록Cipher suite
1. 클라이언트에서 지원 가능한 chiper suite 정보들
2. 키 교환 및 인증 알고리즘, 암호 명세cipher spec로 구성 (ex SSL/TLS_(A)_WITH_(B))
3. 대칭 암호 알고리즘, 암호키 길이, 블럭 암호 모드, hmac용 해시 알고리즘 등으로 구성
ex TLS_DHE_DSS_WITH_AES_256_GCM_SHA256
키교환 알고리즘은 DHE, 인증서명 알고리즘은 DSS, 대칭암호 알고리즘은 AES, 암호키길이는 256비트, 블럭암호모드는 GCM이고 GMAC 해시 알고리즘은 SHA-256이다

디피-헬만Diffie-Hellman 키교환 유형
1. 매우 큰 소수 P와 P를 기반으로 한 원시근 G를 설정한다
2. 사용자 A는 난수A 생성, 사용자 B는 난수B 생성
            A                                     B
G의 A제곱 mod P ->    <- G의 B제곱 mod P
       (공개키)                           (공개키)
3. 각자 공개키를 서로에게 전송한다
4. 각자 공개키를 난수로 제곱한다

                          A                                                                  B
(G의 B제곱 mod P)를 A제곱 mod P            (G의 A제곱 mod P)를 B제곱 mod P
         = G의 A*B 제곱 mod P                                     = G의 A*B 제곱 mod P
지수간 교환법식에 의해 두 사람의 공통키는 같은 값을 가진다

 

P, G, 디피헬만의 공개키는 공개되어도 무방함 = 공개 Diffie-Hellman의 매개변수/파라미터라고 부름

 

1. Ephemeral 임시 디피-헬만 이페머럴
- 매 협상시마다 새로운 Diffie-Hellman 개인키를 생성하고, 공개 Diffie-Hellman 매개변수에 대한 서명(cipher suite의 인증)을 통해 인증 수행
- 서명 알고리즘은 중간자공격에 대비한것

2. Anonymous 익명 디피-헬만
- 매 협상시마다 새로운 Diffie-Hellman 개인키를 생성. 그러나 매개변수에 대한 인증을 수행하지 않기 때문에 중간자공격MITM에 취약하여 사용하지 않는 것을 권장

공개키 인증은 MITM (중간자공격)에 취약함.
그래서 나온 것이 PKI (Public Key infrastructure)

 

나) S->C  Server Hello 메시지
- 사용할 SSL/TLS 버전, 암호 도구, 압축 방식 등을 클라이언트에 전달
- 서버 랜덤Server random : 서버가 생성하는 32바이트 난수값. salt 역할
- Session ID : 새롭게 생성됨

다) S->C  Server Certificate 메시지
- 서버 인증서 목록 (인증서에 서명한 인증기관들의 인증서)

라) S->C  Server Key Exchange 메시지
- 필요시 키 교환에 필요한 정보를 전달하는 메시지

(Ephemeral 디피헬만 사용시 공개 디피헬만 매개변수(소수 P, 원시근 G, 서버 Diffie-Hellman 공개키)를 서명 알고리즘으로 서명해 서명값과 전달)

마) S->C  Certificate Request 메시지
- 필요시 클라이언트 인증을 위한 인증서를 요청하는 메시지

바) S->C  Server Hello Done 메시지
- 과정 종료 알림

 

사) C->S Client Certificate 메시지

- 필요시 클라이언트 인증서 목록 전달

아) C->S Client Key Exchange 메시지
- 키 교환에 필요한 사전 마스터 비밀Premaster secret 를 생성하여 서버에 전달하는 메시지.
- RSA 방식 : Premaster secret 생성후 수신 서버 인증서의 공개키를 이용해 암호화
- Diffie-Hellman 방식 : 클라이언트 Diffie-Hellman 공개키를 생성해 서버에 전달, 클라이언트와 서버는 각각 Diffie-Hellman 연산을 통해 공통의 premaster secret를 생성함

 

자) C->S Certificate Verity 메시지
- 필요시 클라이언트가 보낸 인증서에 대한 개인키를 클라이언트가 가지고 있었음을 증명

차) C->S Change cihper spec 메시지
- 협상한 암호 명세cipher spec를 이후부터 적용/변경함을 알리는 메시지

카) C->S Finished 메시지
협상완료

타) S->C Change cihper spec 메시지
- 협상한 암호 명세cipher spec를 이후부터 적용/변경함을 알리는 메시지

파) S->C Finished 메시지
협상완료

 

 

단축 협상 Abbreviated Handshake 과정
가) Client Hello
- 서버에 사용할 session id와 client random을 전달

- 서버는 session id가 존재할 경우 기존 세션을 재사용하고, 없으면 새로운 session id를 부여해 전달한다

나) Server Hello
- 클라이언트에 server random 전달

- change cihper spec 메시지를 통해 협상된 암호명세를 이후부터 적용/변경함을 알리고 FInished

다) Finished 

- 클라이언트도 change cihper spec 메시지를 보내고 종료

 

 

5 END --

 

 

Record 프로토콜 동작방식
- 단편화Fragmentation : 일정 크기로 단편화
- 압축 후 MAC 추가 : 단편화된 데이터를 협상을 통해 적용된 압축 알고리즘으로 압축하고 MAC값 추가
- 암호화 : 협상된 암호 알고리즘으로 암호화
- Record 헤더 추가

 

(+ ssllabs.com - SSL/TLS 점검 가능한 사이트 (도메인 주소로) )

SSL/TLS 완전 순방향 비밀성(PFS: Perfect Forward Secrecy)
가) SSL/TLS 통신 서버 개인키 노출시의 문제점
1) RSA 방식으로 서버 공개키와 개인키를 이용해 키 교환을 수행할 경우, 중간자공격MITM을 통해 트래픽을 가로채고 서버 개인키를 이용해 세션키/비밀키 및 송수신 데이터를 복호화할 수 있다.
2) 유출된 서버 인증서를 폐기해도, 유출된 서버 개인키로 보호되는 이전 트래픽 정보를 공격자가 갖고있다면 이들 모두 복호화될 수 있다
3) 해결을 위해 등장한 암호학적 성질을 순방향 비밀성FS 또는 완전 순방향 비밀성PFS 라고 함

나) 완전 순방향 비밀성 PFS
1) 서버 개인키가 노출되어도 이전 트래픽 정보의 기밀성은 그대로 유지되는 암호학적 성질
2) 클라이언트-서버 간 키 교환에 사용되는 서버 개인키가 노출되어도, 이전 트래픽의 세션/비밀키 기밀성은 그대로 유지되어 통신 내용을 알수 없는 암호학적 성질

다) SSL/TLS 통신의 완전 순방향 비밀성PFS 지원
- 키 교환시마다 클라이언트/서버가 새로운 Diffie-hellman 개인키를 생성하는 임시Ephemeral 디피-헬만 키 교환을 통해 클라이언트/서버간 공통의 비밀값을 생성하고, 서버 개인키는 서버 디피-헬만 파라미터를 인증하는 목적으로만 사용함으로써, 서버 개인키가 노출되어도 통신 내용을 알 수 없는 완전 순방향 비밀성을 지원함.

 

라) 완전 순방향 비밀성만 적용하기 어려운 이유
1) RSA에 비해 처리 속도가 느리다. 성능상의 이유로 임시 디피헬만DHE, 타원곡선 디피헬만ECDHE(Elliptic Curve DHE) 관련 cipher suite를 비활성화 하는 경우가 있다.
2) 브라우저 호환을 위해 RSA 방식의 키 교환을 함께 사용

 

 

 

-- 6 END

 

 

 

간략하게 정리하기
전송모드 : 페이로드만 암호화
터널모드 : New IP Header를 만들고, 원본 IP 패킷 전체 암호화

AH 프로토콜 : 메세지인증코드MAC, 무결성/송신처 인증, 암호화X
ESP 프로토콜 : 메세지인증코드MAC, 무결성/송신처 인증, 선택적 암호화O, IP헤더 인증X

AH 프로토콜
- 전송모드 : IP 헤더의 변경가능 필드를 제외한 패킷 전체 인증 
- 터널모드 : New IP Header의 변경가능 필드 제외한 New IP 패킷 전체 인증

ESP 프로토콜
- 전송모드 : IP 페이로드+ESP 트레일러 암호화 -> 암호화데이터 + ESP 헤더 인증
- 터널모드 : 원본 IP 패킷 전체 + ESP 트레일러 암호화 -> 암호화 데이터 + ESP 헤더 인증

 

보안서비스
1. 기밀성
2. 비연결형 무결성
3. 데이터 원천인증/송신처 인증
4. 재전송 공격 방지
5. 접근 제어
6. 제한된 트래픽 흐름의 기밀성 (ESP/터널모드의 경우 New ip Header를 생성하여 터널/보안 게이트구간이 노출된다. 대신 원본 IP 헤더는 암호화되어 게이트웨이와 종단노드 구간의 기밀성은 보장된다)