HTTPS 통신과정 쉽게 이해하기 #4(Cipher Suite, 암호문의 집합)

이 문서에서 Cipher Suite에 대해 중점적으로 다루고자 합니다. 그 전에 HTTPS 통신과정 쉽게 이해하기 #3(SSL Handshake, 협상과정)에서 언급한 Cipher Suite를 다시 정리해보겠습니다.

1. SSL Handshake는 암호화 알고리즘 결정과 대칭키(비밀키) 전달을 위해 사용
2. SSL Handshake의 첫 단계, Client가 'Client Hello'로 협상을 시작할 때 자신이 사용 가능한 'Cipher Suite'를 쭉 나열
3. Server가 'ServerHello'를 통해 자신이 고른 'Cipher Suite'를 전달

SSL Handshake의 첫 협상 단계인 'Client Hello'와 'Server Hello'에서 'Cipher Suite'가 가장 먼저 언급되는 것을 통해  'Cipher Suite'의 중요성을 알 수 있습니다. 'Cipher Suite'를 정하지 않고서는 다음 모든 단계를 처리할 수 없다는 뜻이니까요. 

 

Cipher Suite

'Cipher'와 'Suite'를 쪼개어 단어를 찾아보았더니 다음과 같은 의미가 나왔습니다.

* Cipher
1.(글로 쓰인) 암호   2. 하찮은 사람   3.(특별히 디자인된) 이름 첫 글자들

* Suite
1.(특히 호텔의) 스위트룸(연결된 몇 개의 방으로 이루어진 공간)   2.(가구·용품) 세트   3. 모음곡

출처 : 네이버 지식백과

'Cipher'의 1번 의미와 'Suite'의 3번 의미를 조합해보면 암호 모음곡(?) 정도가 되겠네요. 암호를 모아 만든 집합소로 해석하면 될 것 같습니다. 이름 한 번 참 어렵게 짓네요...... 그럼 모인 암호들을 그림으로 표현하면 어떻게 되는지 다시 한번 보겠습니다.

<Cipher Suite>

위의 그림이 Cipher Suite로 암호화 협상을 위한 알고리즘을 무엇을 쓸 것인지 모아둔 것입니다. SSL/TLS 프로토콜, 키 교환 방식, 인증서 검증, 블록 암호화 방식, 메시지 인증... 양이 좀 많군요; 그럼 프로토콜부터 하나씩 살펴보도록 하겠습니다!

 

SSL/TLS Protocol

SSL Handshake를 기반이 되는 SSL/TLS Protocol의 버전을 의미합니다. 보통 SSLv3, TLSv1.0, TLSv1.1, TLSv1.2등이 있고 Cipher suite에서는 SSL 혹은 TLS로 표기됩니다. ClientHello Packet에서 'Version' 항목을 통해 확인할 수 있습니다. 아래 보시면 TLS 1.0 임을 확인하실 수 있죠?

 

최근에 Google Chrome에서 TLSv1.0, TLSv1.1의 지원을 종료하겠다는 발표가 있었지요. 사용 가능한 Version 중 TLSv1.0, TLSv1.1을 빼겠다는 뜻이 됩니다. 해당 버전의 프로토콜을 빼게 되면 해당 프로토콜과 연결된 Cipher Suite는 사용할 수 없습니다.

<TLS Version 확인>

 

키 교환 방식(키 교환 알고리즘)

SSL Handshake의 목표이자 데이터를 암호화하는 실질적인 키인 대칭키(비밀키)를 서버에게 전달하기 위한 방법(알고리즘) 선택을 의미합니다. 주로 ECDHE, RSA 등이 사용됩니다. 여기서 잠깐 짚고 넘어가야 할 것은 RSA와 Diffie-Hellman(DH)입니다.

* RSA(로널드 라이베스트(R), 아디 샤미르(S), 레너드 애들먼(A) 이름의 앞글자) 암호
공개키 알고리즘입니다. 앞서 HTTPS 통신과정 #2에서 한 쌍의 공개키와 개인키가 있다고 말씀드렸던 게 기억나시나요? 바로 각기 다른 키인 공개키와 개인키를 이용하여 암호화/복호화하는 알고리즘입니다. 공개키로 암호화하여 개인키로 복호화하거나, 개인키로 암호화하여 공개키로 복호화합니다. CA(Certificate Authority)가 자신이 발급한 인증서를 암/복호화하는데도 사용하죠.

* DH(Diffie-Hellman) 키 교환 
RSA와는 약간 다른 알고리즘이지만 데이터를 암호화/복호화하기 위해 하나의 키를 쓰는 알고리즘입니다. RSA가 공개키와 개인키를 생성하여 공개키를 모두에게 공개하는 것과 달리, DH 키 교환 알고리즘은 Parameter(매개변수), 즉 키를 생성할 재료를 교환합니다. 매개변수는 공개적으로 교환하며 노출되어도 상관없습니다. 매개변수를 교환한 후, Client와 Server 모두 동일한 대칭키(비밀키)를 얻게 됩니다. 종류로는 DH, DHE(Diffie-Hellman Ephemeral), ECDHE(Elliptic Curve Diffie-Hellman Exchange)가 있습니다. 

이전 글에서 인증기관인 CA가 발급한 SSL 인증서에 서버가 발행한 공개키가 들어있다고 말씀드렸는데 기억나시나요? SSL 인증서에 서버의 공개키가 들어있다는 것은 서버가 대칭키(비밀키)를 암호화하기 위한 키 교환 알고리즘 선택 시 RSA를 선택했다는 것을 의미합니다. 왜냐하면 공개키가 있다는 것은 곧 서버가 공개키-개인키 쌍(RSA)을 생성하여 SSL 인증서 생성 시 공개키를 제출했기 때문이죠. 다시 말해 공개키 암호 방식을 선택한 것입니다. 그리고 SSL Handshake의 'Client Key Exchange' 과정에서 사용자는 서버의 공개키를 이용해 대칭키(비밀키)를 암호화하고 서버에 전달하게 됩니다.

 

Diffie-Hellman(DH)를 선택하면 어떻게 될까요? 위의 설명처럼 Diffe-Hellman(DH) 알고리즘은 공개키-개인키 쌍을 생성하지 않지 않고 Key Paramenter(이하 키 매개변수)만을 교환하면 동일한 대칭키(비밀키)를 얻을 수 있기 때문에 SSL 인증서 내부에 서버의 공개키가 존재하지 않습니다. 그리고 사용자와 서버는 SSL Handshake의 'Client Key Exchange'와 'Server Key Exchange'를 통해 서로 키 매개변수를 교환합니다.

 

인증서 검증

말 그대로 인증서를 검증하기 위한, 인증기관인 CA가 발급한 SSL 인증서를 검증하기 위한 알고리즘을 선택합니다. 여기서 검증이란 CA의 개인키로 암호화된 SSL 인증서를 CA의 공개키로 복호화하는 과정을 의미합니다. SSL 인증서가 CA가 발급한 것이 맞다면 CA가 공개한 공개키로 인증서가 복호화될 것입니다. 만약 인증서가 RSA 알고리즘으로 암호화되어있다면 당연 서버는 RSA 알고리즘이 담긴 Cipher Suite를 선택하겠지요?

인증서 검증에는 RSA 혹은 타원곡선(ECC) 암호 알고리즘 ECDSA만이 가능합니다. 대칭키 하나만을 갖는 DHE를 쓸 경우, 인증서가 진짜인지 가짜인지 밝힐 수단이 없습니다. 암호화에도 복호화에도 하나의 키를 이용한다면 인증기관인 CA가 이 키를 공개할 수도, 그렇다고 공개하지 않을 수도 없거든요. 반면, RSA는 공개키와 개인키가 존재하기 때문에 암호화와 복호화에 각각 사용할 수 있습니다.

 

암호화 알고리즘(블록 암호화 방식)

HTTPS 통신과정은 데이터를 암호화하여 전송하기 위한 협의 과정이라고 말씀드린 적이 있지요. '암호화 알고리즘'은 데이터를 실질적으로 암호화하기 위해 사용되는 알고리즘입니다. Client와 Server가 공유하는 대칭키(비밀키)와 선택한 암호화 알고리즘(블록 암호화 방식)을 가지고 데이터를 암호화하게 됩니다. 블록 암호화 방식으로 불리는 이유는 데이터를 일정 길이의 블록으로 쪼개어 암호화하기 때문입니다. 보통 암호화에 사용되는 대칭키(비밀키)의 길이가 길면 길수록 암호화의 강도가 강해지고 암호화/복호화에 사용되는 리소스 소모가 커지는데요. 이 키 길이는 어떤 암호화 알고리즘을 사용하느냐에 따라 달라집니다. 암호화 알고리즘의 종류와 키 길이, 블록 길이는 다음과 같습니다.

<출처 : IT 위키(https://itwiki.kr/w/암호화알고리즘)>

또한 암호화 알고리즘은 '양방향'이라는 특성을 갖기 때문에 원본 데이터를 암호화 데이터로 암호화할 수 있고 암호화 데이터를 원본 데이터로 복호화할 수 있습니다. 

 

메시지 인증 코드(Message Authentication Code, MAC)

암호화된 데이터를 서로 주고받는다 하더라도 이 데이터가 정말로 누군가의 조작에 의해 변했는지, 변하지 않았는지 알 수 없습니다. 이를 확인하기 위해 특정 알고리즘을 사용해 원본 데이터를 일정한 길이의 암호화된 문자열로 변경합니다. 이 특정 알고리즘은 원본 데이터마다 일정한 결괏값을 도출하며 원본 데이터가 변경되면 결괏값 또한 달라지는 특성을 지닙니다. 이 특정 알고리즘을 Hash 알고리즘(이하 해시 알고리즘)이라고 부르며 해시 알고리즘이 적용된 암호화된 문자열를 Hash 값(이하 해시값)라고 부릅니다. 해시 알고리즘의 종류에는 MD5, SHA-128, SHA-256 등이 있습니다. 아래 그림은 SHA-256 해시 알고리즘을 평문에 적용했을 때의 값을 나타낸 것입니다. 같은 단어를 사용하였음에도 순서가 다르자 완전 다른 해시값이 나타나는 것을 알 수 있지요.

<평문에 'SHA-256' 해시 알고리즘을 적용하여 생성한 해시값>

송신자는 원본 데이터(암호화 알고리즘에 의해 암호화된)와 해시 알고리즘이 적용된 데이터를 함께 전송하고 수신자는 약속한 해시 알고리즘을 이용해 원본 데이터에 적용해봅니다. 해시 알고리즘이 적용된 원본 데이터가 상대방이 보낸 '해시 알고리즘이 적용된 데이터'와 결과가 같다면 이것은 변조되지 않은 메시지임을 알게 됩니다. 해시 알고리즘의 종류에는 MD5, SHA-128, SHA-256 등이 있습니다.

<해시 알고리즘의 종류>

해시 알고리즘은 '일방향'이라는 특성을 갖기 때문에 해시 알고리즘이 적용된 결과값에서 원본 메시지로 되돌릴 수 없다는 특성을 지닙니다. 다시 말해 해시값을 원본 데이터로 되돌릴 수 있다면 취약한 알고리즘임을 뜻하는 것이죠.

 

여기서 암호화 알고리즘과 해시 알고리즘의 차이가 드러나는데요. 암호화 알고리즘은 원본 데이터를 암호화할 수 있고 암호화된 데이터를 복호화하여 원본 데이터로 되돌릴 수 있지만 해시 알고리즘은 일방향 특성을 갖기 때문에 해시가 적용된 데이터를 원본 데이터로 되돌릴 수 없습니다.

 

여기까지가 Cipher Suite에 대한 이야기입니다. 다음 문서에서는 SSL 인증서를 사용자에게 발급하는 존재인 Certificate Authority(CA), 인증기관에 대해 알아보도록 하겠습니다.