DO MY BEST

다음 네 가지 방법을 이용하여 키 교환/설정을 한다.

RSA - 공개키를 이용해서 세션키를 설정하는 경우에는 클라이언트는 세션키를 만들었다면 이 세션키를 서버에 공개키로 암호화 해서 전송을 하면은 서버는 안전하게 클라이언트가 만든 세션키를 받을 수  있다. 그래서 server_key_exchange에는 전송할 정보가 없다. 

Fixed Diffie-Hellman - 인증서 안에 서버가 자신의 Diffie-Hellman 파라메터를 클라이언트에게 알려주면 클라이언트 입장에서는 서버의 Diffie-Hellman 파라메터를 받았으니까 server_key-exchange에는 따로 전송할 정보가 없다. 이 DH경우에는 중간자 공격의 위험은 없 왜냐하면 서버가 보내는 DH파라메터는 인증기관이 서명하니깐 누가 중간에서 그걸 가지고 장난칠 수는 없기 때문이다. Ephemeral DH와의 차이가 뭐냐면 DH파라메터가 인증서를 보낼 때 고정되니깐 그 인증서에 나와있는 DH파라메터를 계속 사용을 하게 되는데 ephemeral DH는 필요할 때마다 서버가 자기 비밀 값을 보내주니깐 DH값을 일시적으로 사용할 수 있다. ephemeral을 사용하는 이유가 인증 프로토콜에서 순방향 안정성(FS: Forward Security)을 이용해가지고 ephemeral DH를 사용한다. 

ephemeral Diffie-Hellman - 가장 안전한 키 설정 방법이다. (forward security도 보장을 해줌) 이 경우에는 인증서에는 서버의 공개키를 전송한다. 이것만 보면 RSA 의 경우와 같지만 자신의 Diffie-Hellman 파라메터를 server_key_exchange에 포함해서 클라이언트에게 전달하게된다. 그 때 그 파라메터는 자신의 개인키로 서명을 해서 “이거는 내가 보내는것이 맞다”라는 것을 확인한다. 서버가 개인키로 서명을 했기 때문에 Diffie-Hellman의 경우에는 MITM(Man In The Middleattack)-중간자공격에 위험성이 있는데 ephemeral Diffie-Hellman은 개인키로 서명해서 보내기 때문에 MITM은 가능하지 않다. 

Anonymous Diffie-Hellman - 이건 일반적인 DH(Diffie-Hellman)이다. 가장 안전하지 않는 방법이고 이 경우에는 MITM에 취약하다.

이러한 암호 방식 리스트를 주고 받으면서 클라이언트와 서버 간에 어떤 암호 알고리즘, 해시 알고리즘, 키 교환방식을 쓰는지를 서로간에 합의를 해서 결정하게 된다. 

암호 알고리즘, 해시 알고리즘, 전자 서명 방식, 키 교환 방식을 결정하게 된다.

클라이언트가 자신이 사용할 수 있는 리스트를 서버한테 주면은 서버가 그 중 하나를 선택하게 되는데

RSA, DH_DSS, … 이런것들이 키 설정 방식을 의미한다. 

키 설정 방식을 간단하게 설명 하면 두 가지 방식이 있는데 1. 공개 키 방식 2. Diffie-Hellman 방식이 있다.

• RSA는 공개 키를 사용해서 세션키, 대칭키를 설정하는 방식이다.
• 나머지 DH_DSS, DH_RSA, DHE_DSS, DHE_RSA, DH_anon은 Diffie-Hellman 방식을 사용하는건데, 이 경우는 세 가지로 구분 되어 있다. 1. DH_DSS, DH_RSA는 fixed Diffie-Hellman 방식 2. DHE_DSS, DHE_RSA는 ephemeral Diffie-Hellman 방식 3. DH_anon는 anonymous Diffie-Hellman 방식 이 있다. 결국 키 설정은 Diffie-Hellman의 세 가지랑 공개 키 방식을 놓고 보면은 네 가지 있다고 볼 수 있다.

AES는 암호 알고리즘을 의미한다. 어떤 알고리즘을 사용 할 것인가를 말한다. 그리고 CBC는 블록체인을 말한다. 결국 AES000_CBS까지가 어떤 알고리즘을 사용 할 것인지를 말해준다.

SHA_256은 해쉬 알고리즘을 얘기한다. 

그러나 전자 서명 방식은 다른 필드에 표현되어있다.

단계 4

change_cipher_spec 메시지는 알고리즘 규격에 변화가 생겼을 때 알려준다.

그리고 finish는 클라이언트가 서버로 혹은 서버가 클라이언트로 보내서 서로간에 마지막 handshake 과정을 확인하는건데, 이 때 지금까지 받았던 모든 메시지를 다 붙여서 MAC을 계산한다. 결국 finished메시지를 통해서 단계 1,2,3,4 까지 받았던 메시지를 확인해서 무결성과 인증에 대한것을 MAC을 통해 한다. 만약 메시지가 하나라도 false가 되어 있으면 MAC값을 통해 알 수 있다. 

단계 3

비밀값을 만들고 이것을 서버에게 알려줘야 하는데 알려주는 것을 3단계의 client_key_exchange를 통해서 알려주게 된다. 만약에 RSA(공개키)를 이용해서 알려줄 경우에는 PMS를 만들어서 서버의 공개키(RSA)로 암호화 시켜서 보내면 이 값은 서버에 개인키가 없으면 이 값은 복호화 시켜서 볼 수가 없다. 결국 서버만이 볼 수가 있다. 그다음 DH를 쓰는 경우에는 DH파라메타 값을, 그리고 fixed DH의 경우에는 클라이언트의 DH key를 인증서에 넣어서 보내주게 된다. 그리고 클라이언트는 메시지에 MAC을 만들어 붙여서 전송을 하는 것이다.

 정리하자면, 서버는 클라이언트가 보낸 PMS값을 받았고 공개키를 사용 할 경우 공개키로 암호화 해서 보냈으니까 서버는 자신의 개인키로 풀면 이 값을 찾을 수 있고 만약 DH을 사용 할 경우 DH 파라메타를 보냈으니까 서버는 PMS값을 찾을 수 있는 것이다. 그러면 여기서 부터 master secret 값을 계산 하고, 여기서 나온 값을 이용해서 키를 계산한다.

암호 방식이 합의가 된 후 이걸 사용 해서 키를 설정하기 위한 파라메터 값을 서로 주고 받아야 된다. 

서버가 자신의 인증서를 보낸다. 여기에는 자신의 공개키가 들어 가 있다. (몰론 CA가 서명한 공개키 이다)

클라이언트는 이 인증서를 받게되면 서버의 🔑 (공개키)를 갖게되고 서버 인증을 하는 것이다.

그 다음에 어떤 키 설정 방식을 사용하느냐에 따라서 server_key_exchange를 가지고 필요한 정보를 전달하게 된다.[참고 키 교환 방법] ex) Diffie-Hellman방식을 사용한다면 server_key_exchange에 다가 파라메터를 넣어서 전달을 하게 되는거다.  

그리고 서버가 클라이언트에 인증 혹은 다른 정보를 위해서 클라이언트에 certificate_request를 보낸다. (이거는 optional)

모든게 제대로 되면 server_hello_done해서 단계 2의 과정이 끝난다.

여기 단계2 과정이 제대로 이루어지게 되면은 클라이언트와 서버는 서로 키를 설정할 수 있는 모든 정보를 다 갖추게 된다.

단계 2: 서버 인증과 키 설정

서버가 클라이언트에게 인증서를 보낸다. 그 때 서버의 공개키를 넣어서 보내는데 이 경우에는 키 설정을 RSA, ephemeral DH을 사용할 경우이고, 만약에 fixed DH를 사용 할 경우에는 서버가 보내는 CA(인증기관)가 인증한 DH파라메터를 넣어서 보내게 된다.

서버가 필요한 정보를 server_key_exchange 메세지를 보내는데 anonymous의 경우에는 DH 파라메터값을 그냥 보내는거고 ephemeral DH는 자신의 개인키로 서명을 해서 보내는 것이다. 주의 할 점은 fixed DH는 이미 인증서에 파라메터를 보냈기 때문에 server_key_exchange 메시지에 보낼 필요가 없다.

만약에 클라이언트에 인증서가 필요하면 certificate_request를 하게 된다. 

모든것을 다 하면 server_hello_done을 보낸다.

이런 메시지를 보낼 때 메시지의 무결성과 인증을 위해서 hash(client_rand || server_rand || server parameters). 이 세개의 값을 해쉬하고 나온 값을 서버의 개인키로 서명을 해서 주고받는 메시지들에 붙인다. 이것이 MAC이다.    *client_rand = 클라이언트의 nonce,  server_rand = 서버의 nonce ( 이 두 개는 단계 1에서 이미 서로 hello 메시지를 주고 받으며 handshake를 하면서 갖고있는 값이다.)

이렇게 MAC을 붙여서 주고 받는 메시지의 무결성과 인증을 해준다.

Thus, 단계 1에서 클라이언트가 자신의 nonce값을 client_hello메시지로 보냈고 서버가 클라이언트의 nonce값을 갖고있고, 그 다음 서버도 자신의 nonce값을 클라이언트에게 보냈다. 이 과정에서 그냥 텍스트를 보낸거고 누구든지 이 메시지(nonce값)들을 볼 수 있다. 그리고 클라이언트와 서버가 할 수 있는 것은 없으니까 그대로 메시지를 전송하는 것이다. 그다음에 단계 2에서 인증서를 보내면서 클라이언트는 서버의 공개 키를 갖게된다. 만약 DH방식으로 키를 설정하면 서버는 클라이언트에게 서버의 DH 파라메터값을 보낸다. 그래서 파라메터 값들을 공유하고 있는 것이다. 그러면 클라이언트는 서버하고 같이 사용할 수 있는 세션키를 만들어야 하는데 이것을 만들기 위해서는 클라이언트와 서버만이 알고 있는 값으로 만들어야 해서 비밀값을 만드는데 이 비밀값의 이름이 PMS(Pre-Master Secret)이다. 비밀값을 만드는 방식은 [키 교환 방법을 참고]. 

TLS handshake 프로토콜은 이 메시지들을 주고받게된다.

• 단계 1 : 세션 설정과 보안 리스트 교환

여기서 말하는 세션은 TLS세션을 말하는 것이다. 이 세션은 처음에 hanshake를 하면서 클라이언트 서버 간에 인증을 하고 키를 설정한다. 설정한 키는 이 세션에서 유효한 것이다. 만약 이 키가 끝나면 다시 handshake 과정을 거쳐 키도 새로 만들고 인증도 새로 해야하는 것이다. 그래서 이 통신하는 단위를 세션이라고 한다. 이 TLS 세션을 단계 1에서 “hello 메시지를 교환하면서 설정 과정이 이루어지게 되고 그때 보안 리스트(암호화 알고리즘)를 결정하게 된다.  

client_hello_message와 server_hello_message의 구성

• 버전: client_hello_message와 server_hello_message를 보낸다고 했는데 이것들은 버전이 있다. 가장 높은 SSL 버전이고 TLS인 경우는 1.2 버전이다. 
• 랜덤(Random) : 이 랜덤값은 ‘nonce’ 이다. 이 값은 랜덤값을 사용할 수 있고 타임스탬프(time stamp)를 사용할 수있다.
• 세션ID: 메시지들을 주고 받을 때 메시지들이 어떤 세션에 속하는지는 여기 ID값으로 구분이 된다. 그래서 이 ID에 합의된 key값들이 정해져 있는 것이다.(ID가 다르면 사용하는 key가 달라진다.)
• 암호 방식 리스트 or 암호 알고리즘 리스트(Cipher Suite) : 먼저 client_hello_message로 클라이언트가 자기가 사용할 수 있는 암호 알고리즘을 서버한테 알려주는데, 자기가 사용하고 싶은 것 부터 순서대로 알려준다. 그러면 server_hello_message로 서버는 그 중에서 가장 적합한 것을 선택해서 그 알고리즘으로 통신 하는데 앞으로 통신하는데 사용 하는 것이다.
• 압축방식 : 보안하고 상관 없는 내용이라 생략.

TLS에서 핵심된 절차가 밑의 두 가지 단계로 이루어진다고 볼 수 있다.

두 가지 과정으로 구별을 해서 볼 수 있다. 이 과정들은 메시지를 안전하게 전송하기 위해서 이루어지는 과정이 되겠는데, 

클라이언트와 서버는 인사(Handshake)과정을 거친다, 즉 서로간의 존재를 확인하는 과정이다. 

이 과정에서 두 가지로 나뉜다. 

1. 서버인증이 있다. (서버 인증은 필수이고, 클라이언트 인증은 optional이다.)
2. 서버와 클라이언트의 키 설정 방법 + 둘 사이에 사용할 암호 알고리즘(대칭키 알고리즘, 해쉬 알고리즘, 전자서명) 이 있다. 

즉, Handshake 과정에서는 어떤 방법을 사용하여 안전한 통신을 할 것인지를 이 과정에서 서로 확인한다.

인사(Handshake) 과정에서 주고받은 파라메터 값을 가지고 키 설정(Keys computation)을 한다.   *Keys 🔑 (MAC key, session key etc…)

Finally, 이렇게 설정한 키를 가지고 안전한 메시지 전송을 할 수 있고, 통신이 끝나면 세션을 종료한다. 

이 두가지 방법은 TLS의 경우에도 사용하고있다.

• (공개키 사용 방법) 클라이언트가 서버에 접속을 하고싶다고 서버에 말을 하면, 서버가 “내가 진짜 서버다” 라고 인증을 하는데 그 과정에서 공인인증서를 사용자에게 준다. 그러면 사용자는 서버의 공개키를 받고 그   공개키로 대칭키를 만들 수 있다. 그래서 대칭키를 만들어서 서버한테 안전하게 전달시켜준다. 안전하게 서버에게 전달하는 과정은, 클라이언트가 아까 받았던 서버의 공개키를 사용해서 대칭키를 암호화 시켜서 보낸다. 이렇게 하면 암호화된 내용은 누구든지 볼 수 있지만 서버에 개인키가 없으면 대칭키를 복호화할 수 없다. 오로지 서버만이 이 메시지를 복호화할 수 있다. 그래서 서버는 클라이언트가 만든 동일한 세션키를 가질 수 있게 된다.

• (Diffe-Hellman 방법) 클라이언트가 서버에 접속을 하고싶다고 서버에 말을 하면, 서버가 “내가 진짜 서버다” 라고 인증을 하는데 그 과정에서 공인인증서를 사용자에게 준다. 그러면 서버가 자신의 비밀값을 만든다. 그래서 Diffie-Hellman 파라메터를 클라이언트에게 전달하고, 클라이언트도 자신의 비밀값을 만든다. 그리고 클라이언트도 Diffie-Hellman 파라메터를 서버에게 전달한다. 그래서 클라이언트와 서버는 각자 받은 값(Diffie-Hellman 파라메터)과 각자의 비밀값을 가지고 계산을 하면은 둘만이 공유하는 비밀값이 되겠고, 계산해서 나온 값을 이용해서 세션키 혹은 다른 키를 이용해서 사용한다.