대칭키 알고리즘
•
암호화와 복호화할 때 키가 같은 알고리즘
•
장점
◦
참여자들은 같은 키를 가지고, 암복호화하기 때문에 과정이 단순하여 속도 빠름
•
단점
◦
안전한 대칭키 분배과정이 필요
공개키(비대칭키) 알고리즘
•
암호화와 복호화할 때 키가 다른 알고리즘
•
통신 참여자는 공개키-개인키 쌍을 생성
◦
공개키 : 누구나 볼 수 있는 키
◦
개인키(비밀키) : 공개하면 안되는 키
◦
공개키로 암호화한 메시지는 개인키로만 복호화 가능하며, 반대로 개인키로 암호화한 메시지는 공개키로만 복호화 가능
•
장점
◦
키 분배가 필요X
▪
공개되어 있는 상대방의 공개키로 암호화하여 메시지 전송
•
단점
◦
속도 느림
SSL
•
공개키방식과 대칭키방식의 혼합
•
통신 시 사용하는 암호화 방식== 대칭키 알고리즘
•
대칭키를 안전하게 교환하기 위한 암호화 방식 == 공개키 알고리즘
1.
상대방의 공개키로 대칭키 암호화하여 전송
2.
상대방은 자신의 개인키로 암호문을복호화하여 대칭키 획득
•
SSL Handshake 과정 (추가된 참고 내용은 색칠표시함)
1.
서버 만드는 회사는 공개키와 개인키 생성 후, 공개키를 CA에 위탁
•
CA
◦
공개키를 저장하는 신뢰기관
◦
서버나 클라이언트가 실재하는 사실을 증명
◦
CA 공개키는 누구나 가지고 있음
2.
CA기업은 그 서버 공개키를 CA개인키로 암호화하여 SSL인증서를 생성 후, 서버회사에 전달
3.
서버는 서버 공개키로 암호화되지 않은 요청이 오면, 이 인증서를 전송
4.
(SSL HandShake 시작)
5.
CLIENT HELLO (서버 공개키로 암호화되지 않은 요청)
•
클라이언트는 암호 알고리즘과 압축방식 등 정보가 담긴 Client Hello 메시지를 서버에게 전송
6.
SERVER HELLO
•
서버는 Client Hello의 응답으로, 세션 ID와 서버 공개키 인증서(서버의 SSL 인증서)가 담긴 Server Hello 메시지를 전송
7.
PRE MASTER SECRET
•
클라이언트는 CA 개인키로 암호화된 서버 인증서를 CA 공개키를 복호화하여 서버의 공개키를 획득
•
이 키를 이용하여 난수를 암호화하여 예비 마스터 암호를 서버에게 전송
8.
SESSION KEY CREATION
•
서버는 예비 마스터 암호를 자신의 개인키로 복호화하여, 난수를 획득
•
이 난수를 획득함으로써, 서버와 클라이언트는 마스터키를 완성
•
마스터 키를 이용하여 세션키를 생성
9.
CLIENT FINISHED
•
클라이언트는 지금까지 교환한 내역을 해시 후 세션키로 암호화하여 FINISHED 메시지를 서버에게 전송
10.
SERVER FINISHED
•
서버도 교환 내역을 해시하고, 그 결과와 클라이언트에게 받은 FINISHED가 일치한지 비교
•
일치할 경우, 해당 세션키를 대칭키로 사용
11.
EXCHANGE MESSAGES
•
세션키를 이용하여 메시지를 대칭키 방식으로 암호화한 후, 통신
•
cf. 태희 질문
◦
Q. 클라이언트 측은 공개키-비밀키 쌍 생성 안해도 되나?
A. 서버도 클라이언트의 SSL 인증서를 요구하는 방식도 있긴 함.
여기서 설명하는 SSL Handshake 과정은 서버 공개키만 이용하는 방식임
