[네트워킹] 대칭키, 비대칭키와 관련된 글 입니다!
배경
사람들은 네트워크를 통해 패킷을 주고 받습니다. 주고받으며 여러 스위치, 라우터 등을 지나가는데요, 네트워크 상에 공격자가 그 패킷을 훔쳐 데이터를 열람할 수 있습니다!
이를 미연에 방지하기 위해 "네트워크 데이터를 암호화하자"라는 의견이 나왔습니다. 암호화 해 패킷을 가로채도 데이터를 볼 수 없게 만드는 것입니다.
위 글에서 대표적인 암호화 구조인 대칭키, 비대칭키 구조에 대해 알아보았습니다. 하지만 두 구조는 각 장단점을 갖고있는데요, 두 방식의 단점을 서로가 보완하는 방식인 SSL에 대해 알아보도록 하겠습니다.
SSL
'SSL(Secure Socket Layer)' 또는 'TLS(Transport Layer Security)'라는 보안 프로토콜을 통해 클라이언트(브라우저)와 서버(웹서버)가 보안이 향상된 통신을 하는 것으로 대칭키와 공개키 통합 암호화 방식을 기본으로 함
- 공개키 암호화 방식의 단점
= 너무 복잡해서 암/복호화에 시간이 오래 걸리고 CPU도 많이 잡아먹음 - 대칭키 암호화 방식의 단점
= 대칭키의 관리가 어려움. 위험한 대칭키 공유
👉 공개키 암호화를 대칭키를 보내는 용도로만 사용하자!
이렇게 한다면 공개키 기법으로 대칭키를 주고 받기 때문에 해독키를 들킬 염려가 없고 실제 암호화와 해독 작업은 대칭키로 하기 때문에 비용을 세이브할 수 있습니다!!
동작방식
참여자
- 사이트 서버에 접속하고자 하는 클라이언트(웹 브라우저)
- 사이트
- 인증기관(CA)
내가 접속한 사이트가 진짜인지 보증하는 기관으로 사이트 인증서 발급을 책임짐
목표
웹브라우저와 사이트가 데이터를 주고 받을 때 대칭키를 이용합니다. 대칭키를 이용한 암호화 방식은 이 글에 있으니 여기서는 대칭키 교환까지의 과정을 알아보도록 하겠습니다!
우선, 비대칭키 암호화 방식으로 대칭키를 교환한다고 했죠? 그리고 사용자는 사이트가 믿을만한 사이트인지 확인을 해야합니다!
따라서, 사이트는 인증기관에 사이트가 믿을만한 곳이라는 검증을 받고 인증서를 발급 받습니다. 그 인증서 안에는 사용자가 대칭키 전송 시 사용할 사이트의 공개키가 담겨있어야겠네요!
선행과정
사이트는 인증기관을 통해 인증서를 발급받는다
① 인증요청
사이트는 (사이트 정보, 사이트 공개키)를 인증기관에 전달하며 인증서 발급을 요청한다
② 사이트 인증서 제작
검증을 거친 후 (사이트 정보, 사이트 공개키)를 인증기관 개인키로 암호화한 인증서를 제작한다
인증기관 개인키로 암호화?
인증기관이 보낸 것이라는 보장
③ 사이트로 인증서 발급
웹 브라우저는 인증기관의 공개키를 받는다
추후 사이트의 인증서를 받았을 때 이 공개키로 복호화 할 수 있다면 인증기관에서 발급해 준 인증서라는게 보장되겠네요!
대칭키 교환
① 접속요청
② 사이트의 인증서 전달
인증서 = CA의 개인키(사이트 정보, 사이트 공개키)
③ 사이트 정보, 사이트 공개키 획득
브라우저에 저장되어 있던 CA의 공개키를 이용해 인증서를 복호화 하고 사이트 정보를 얻는다
CA의 공개키(CA의 개인키(사이트 정보, 사이트 공개키)) 👉 (사이트 정보, 사이트 공개키)
④ 사이트의 공개키로 대칭키를 암호화
따라서, 사이트만 이 데이터를 복호화해 대칭키를 획득할 수 있다!!
✔️ 대칭키 공유의 위험을 비대칭키 암호화 방식을 통해 해결
⑤ 암호화된 대칭키 전송
⑥ 사이트의 개인키로 대칭키 획득 ❗️
사이트의 개인키(사이트의 공개키(대칭키)) 👉 대칭키
이렇게 공유된 대칭키를 이용해 안전하고 빠르게 통신을 할 수 있게 되었습니다 ! 🤓
ref.
