TLS cipher suite 읽는 법

작년부터 시작해서 보안 버그가 일종의 PR 결전장이 된 것 같은데 — 매우 핫한 이름을 붙여가면서 — 그런 류의 글에 나오는 TLS/SSL cipher suite 읽는 법을 간략히 정리.

TLS (혹은 옛이름(?)인 SSL) cipher suite은 아래와 같은 형태로 쓴다:

이전 글의 국민은행이 사용하던 RSA_WITH_AES_256_CBC_SHA 라거나,
현재 위키백과 설정인 ECDHE_ECDSA_WITH_AES_128_GCM,
이 블로그의 현재 설정 값인 ECDHE_RSA_WITH_AES_128_GCM 이라거나.

이 각각의 기능 구분은 아래와 같다

키 교환: 밑의 벌크 암호화 알고리즘에서 사용할 키를 교환할 방법
인증: 상대방이 정말로 스스로가 생각하는 상대방이 맞는지 확인할 방법
벌크 암호화: 대칭키를 써서 실제로 메시지를 암호화 하는 방법
메시지 인증: 이 메시지가 정말로 상대방이 보낸게 맞는지 확인할 방법

이렇게 4 부분으로 쪼개진다.

키 교환과 인증

그 중 위에서 WITH 보다 앞에 있는 부분이 다음 두 가지 기능을 담당한다.

키 교환

실제로 주고 받을 메시지를 암호화 할 때 대칭키 암호화 방식을 쓰게 되는데, 여기에서 사용할 공유 비밀 정보 (shared secret) 을 생성해야 한다. 이 정보를 생성하기 위한 방식이 몇 가지 있는데, 대략, RSA, Diffie-Hellman (이하 DH), 그리고 elliptic-curve DH (ECDH) 알고리즘을 이용한다. (그리고 키 교환할 때마다 새 키를 생성하게하는 ephemeral DH (EDH), EECDH 도 있다)

인증

키를 교환한 상대방이 정말로 자기가 생각하는 상대방이 맞는지 확인하기 위해서 흔히 말하는 인증서 시스템을 이용한다. 이건 현재 RSA 혹은 DSA, ECDSA 같은 알고리즘을 이용한다. 다만 서버에선 이 값을 바로 바꿀 수 있는건 아니다. 인증서를 만들 때 인증서 서명 요청(CSR)을 작성하는데, 이 때 선택한 키 알고리즘을 서버 인증서를 이용한 인증할 때 쓴다.

즉, 국민은행 인증서는 RSA 알고리즘의 공개키를 CSR에 넣어서 제출했었기 때문에, 키 교환 알고리즘은 다음과 같은게 된다:

RSA: 키 교환 / 인증 모두 처리
DH-RSA: 키 교환은 Diffie-Hellman, 인증은 RSA
EECDH-RSA: …
… (…)

암호화 및 암호화된 메시지 인증처리

실제 암호화와 암호화된 메시지의 무결성을 검사하는게 WITH 뒷쪽 부분이다.

암호화

키를 교환해서 생성한 shared-secret으로 키를 샏성해서 암호화를 진행하는데, 암호화 자체는 (상대적으로 키교환보다 훨씬 CPU 오버헤드가 적은) 대칭키 암호화 방식인 AES (128/256), 3DES, RC4 등을 사용한다. 흔히 말하는 cipher 는 이 부분만 가리키는 것.

메시지 인증 (무결성)

그리고 이렇게 암호화한 메시지가 _내가 암호화한게 맞다_고 주장하는 부분이 message authentication code; MAC 이다. 이 부분은 흔히 암호학적 해시함수를 이용한 HMAC 방식으로 처리하는데, 그래서 AES_256_CBC + SHA1 하는 식으로 대칭키 암호화 알고리즘 과 MAC 을 생성하기 위한 해시 함수 의 조합으로 쓴다.

위에서 RSA로 키 교환 + 인증을 한꺼번에 처리한 것처럼, 암호화 및 MAC 처리를 한꺼번에 처리하는 방식도 있다. 앞에서 HMAC과 같이 쓴 방식은 CBC 모드로 동작하는 경우이고, AEAD 로 동작하는 모드 (mode-of-operation) 이 있는 암호화 알고리즘이 있다. AES-GCM 같은게 이에 해당한다.

요약

TLS cipher suite이 있으면 쪼개서 읽는다:

키교환 방식 – 인증 방식 – WITH – 암호화 알고리즘 – 메시지 인증 방식

다만 키교환+인증은 한 몸일 수 있고, 비슷하게 암호화+메시지 인증도 한 몸 일 수 있다.