HTTPS가 뭐고 왜 쓰나요? (Feat. 대칭키 vs. 비대칭키)
대칭키
암호화, 복호화에 같은 키를 사용하는 암호화 방식
- 공개키에 비해 속도가 빠름
- 키를 교환 할 때 키가 탈취될 수 있음
- 사용자가 증가할수록 키를 따로 교환해야하기 때문에 관리해야할 키가 방대해짐
해결방안
- 키 사전 공유
- 키 배포센터
- diffie-hellman 키 교환 알고리즘
- 두 사용자가 사전에 어떤 비밀 교환 없이도 공통키를 교환하게 해주는 알고리즘
- 상대방의 공개키와 나의 공개키를 이용하여 계산을 하면 비밀키가 나온다는 것
공개키/비대칭키
암호화, 복호화에 사용하는 키가 서로 다른 암호화 방식
- 송수신자 모두 한쌍의 키를 갖게 된다.
- 대칭키 키교환 문제 해결하기위해 등장
- 공개키는 모든사람이 접근가능한 키, 개인키는 각 사용자가 가지고 있는 키
- 사용자가 본인의 개인키로 데이터를 복호화
1) B 공개키/개인키 쌍 생성
2) 공개키 공개(등록), 개인키는 본인이 소유
3) A가 B의 공개키를 받아옴
4) A가 B의 공개키를 사용해 데이터를 암호화
5) 암호화된 데이터를 B에게 전송
6) B는 암호화된 데이터를 B의 개인키로 복호화 (개인키는 B만 가지고 있기 때문에 B만 볼 수 있음)
- 키 교환, 분배 필요 X
- 중간 공격자가 B의 공개키를 얻는다고 해도 B의 개인키로만 복호화가 가능하기 때문에 기밀성 제공
- 개인키를 가진 수신자만이 복호화할 수 있으므로 일종의 인증 기능도 제공
- 속도가 느림
대칭키와 공개키 암호화 방식을 적절히 혼합해보면? (하이브리드 방식)
SSL 탄생의 시초가 됨
1. A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화하고 B에게 보냄
2. B는 암호문을 받고, 자신의 비밀키로 복호화함
3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보냄
4. A는 자신의 대칭키로 암호문을 복호화함
5. 앞으로 이 대칭키로 암호화를 통신함즉, 대칭키를 주고받을 때만 공개키 암호화 방식을 사용하고 이후에는 계속 대칭키 암호화 방식으로 통신하는 것!
대칭키, 공개키가 사용되는 방식
네이버가 공개키를 뿌린다
네이버인지 어떻게 검증하는가 ? - CA
- 브라우저에 CA의 목록이 내장되어 있다.
- 사용자 브라우저를 상대되는 개념인 클라이언트라고 한다.
- 클라이언트는 서버를 신뢰하지 못한다.
- 클라이언트와 서버가 서로 탐색하는 과정 → handshake
-
클라이언트가 랜덤데이터를 생성해서 보냄
-
서버는 답변으로 서버측에서 생성한 무작위의 데이터와 인증서를 실어보냄
⇒ hadshaked
-
클라이언트는 인증서가 진짜인지 CA정보를 통해 확인 → 비대칭키 시스템 활용
-
- CA인증을 받은 인증서들은 CA의 개인키로 암호화 되어있음
- 브라우저에 저장된 CA공개키로 복호화 할 수 있음
- 공개키로 복호화된 인증서를 발급할 수있는건 CA뿐이기 때문
- 성공적으로 복호화된 인증서에는 서버의 공개키가 포함되어있음
- 비대칭키, 대칭키 혼합 사용
- 대칭키가 데이터를 주고받는 데 더 효율적
- 대칭키를 공유할 때 비대칭키를 사용
