728x90

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

 

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

'서버 > 암호' 카테고리의 다른 글

TLS Layer  (0) 2021.03.23
키(🔑 "key") 계산  (0) 2021.03.22
암호 방식 리스트 or 암호 알고리즘 리스트(Cipher Suite)  (0) 2021.03.21
TLS Handshake 프로토콜 (4 단계)  (0) 2021.03.21
TLS Handshake 프로토콜 (3 단계)  (0) 2021.03.21

+ Recent posts