DO MY BEST

TLS record protocol을 살펴보면은 TLS는 handshake 프로토콜만 있는게 아니라 record 프로토콜도 같이 있는데, handshake 프로토콜에서 세션 키, MAC 키 를 결정해서 응용 메시지를 전달 할 때 MAC키를 이용해서 메시지 인증 (HMAC)을 만들고 다음으로, 세션 키로 암호화 시켜서 응용 프로토콜에 메시지를 보내게 된다. 그 과정에서 바로 TCP segment로 보내지 않고 TLS Layer에서 그것을 record로 만들어서 그것을 TCP로 보낸다. TCP segment로 만들어서 실제 망에서 전달이 일어나게 되는데 그렇게 record로 만드는 과정을 하나 더 집어넣은 이유는 TCP자체가 byte stream개념이기 때문이다. 그러니까 record를 만드는 layer를 하나 더 집어넣었다. 어플리캐이션에서 부터 내려오는 데이터를 record로 만들면서 record1,2,3,4,5 이런식으로 record 단위로 보게된다. 그래서 record 단위로 MAC을 붙이고, 또는 암호화를 하게된다. 

처음에 인증을 하고 키를 설정하는 과정에서 TLS handshake프로토콜을 거치면서 세션 키와 MAC 키가 결정되게 되면 응용 프로토콜 메시지는 TLS record가 만들어져서 전달이 이루어지게 된다. 

클라이언트와 서버는 둘만이 아는 PMS값을 갖는다고 했다. 키를 계산하는 과정은 다음과 같다.

• Master secret( MS ) , pre-master secret (PS), Client random (CR), Server random (SR)

MS = MD5( PS || SHA-1(‘A’ || PS || CR || SR)) ||  

(PS, CR, SR) 순으로 MS 값을 계산한다. 복잡해 보이지만 쭉 연결 시켜서 SHA-1으로 해쉬 시키는 방식으로 한 것이다. 

결국에는, MS에서 키를 만들어 내는데 키는 하나가 아니라 여러개의 키를 만들어 낸다. 세션키, MAC키, 초기값을 만든다.

Client nonce, server nonce, master secret으로 부터 다음의 키를 계산한다.

• Server MAC key  => (HMAC 해쉬하기 위함, 암호화를 하기 위한것 x)
• Client MAC key  => (HMAC 해쉬하기 위함, 암호화를 하기 위한것 x)
• Client encryption key  => 세션키(암호화 키)
• Server encryption key => 세션키(암호화 키)
• Server initialization vector (IV)  => 대칭키 암호화 알고리즘에 사용하는 초기값
• Client initialization vector (IV)  => 대칭키 암호화 알고리즘에 사용하는 초기값

위에 키들이 비슷한 것들이 두 개인 이유가 서로 클라이언트와 서버 양 방향에서 사용하기 때문이다.

정리하자면 PS에서 MS를 계산하는데 이 때 계산하기 위해서 같이 사용 하는 것이 CR, SR이다. 즉 MS를 PS, CR, SR로 계산한다. 그리고 MS로 부터 6개의 키 값들을 계산한다.

MS = MD5( PS || SHA-1(‘A’ || PS || CR || SR)) ||  

‘A’ 와 같은 캐릭터 스트링에 다가 PS, CR, SR을 쭉 연결해서 해쉬 해서 MS를 만들고 MS를 가지고

MD5( MS || SHA-1(‘A’ || MS || SR || CR)) ||

MS를 SR, CR을 쭉 연결 시켜서 고정된 캐릭터 스트링에 다가 해쉬해서 나오는 결과값을 일정 한 길이로 잘라서 각각을 키로 사용 한다. (밑에 그림 참조)

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

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에 취약하다.