반응형
키 교환(Key Exchange)은 한 줄로 말하면:
서로 처음 만난 두 사람이
안전하게 같은 대칭키를 만드는 과정이다.
왜 키 교환이 필요할까?
대칭키 암호(AES)는 빠르다.
하지만 문제:
"그 AES 키를 어떻게 상대방에게 안전하게 전달?"이다.
그냥 보내면 안 되나?
예:
클라이언트 → 서버
AES_KEY=ABC123이렇게 보내면:
중간 감청자가 키를 보면 끝이다.
이후 모든 통신 복호화 가능.
그래서 필요한 게 키 교환
목표는:
인터넷 중간에서 누가 보고 있어도
둘만 같은 비밀키를 공유하는 것.
핵심 개념
키 교환은:
대칭키를 직접 보내지 않는다가 중요하다.
대표 방식 1 — RSA 기반 키 교환
옛 HTTPS 방식.
STEP 1
서버가 공개키 공개.
SERVER_PUBLIC_KEYSTEP 2
클라이언트가 랜덤 AES 키 생성.
SESSION_KEYSTEP 3
그 키를:
서버 공개키로 암호화해서 전송.
STEP 4
서버만 개인키로 복호화 가능.
즉 둘만:
같은 AES 키 공유하게 된다.
그런데 현대는 이 방식 잘 안 씀
왜냐면:
Forward Secrecy 문제때문.
문제 상황
만약 미래에:
서버 개인키 유출되면,
예전에 녹음된 통신까지 복호화 가능할 수 있다.
그래서 현재는 Diffie-Hellman 계열 사용
대표:
- Diffie–Hellman key exchange
- ECDHE
핵심 아이디어
엄청 신기한데:
중간에서 다 봐도
최종 비밀키는 계산 못 하게만든다.
아주 쉬운 비유
색깔 섞기 비유가 유명하다.
STEP 1 — 공용 색 공개
둘 다 아는 공개 색:
노란색STEP 2 — 각자 비밀 색 추가
클라이언트:
노란색 + 파랑서버:
노란색 + 빨강STEP 3 — 서로 결과 교환
하지만:
원래 비밀 색은 안 알려줌STEP 4 — 다시 자기 비밀색 추가
결과적으로 둘 다:
같은 최종 색완성 가능.
감청자는 왜 못 구하나?
중간에서:
- 공개 색
- 중간 결과
는 보지만,
원래 비밀값은 모른다.
실제 수학은?
실제 DH는:
g^a mod p
같은 계산 사용.
클라이언트
비밀값:
a서버
비밀값:
b공개값 교환
클라이언트:
A=g^a mod p
서버:
B=g^b mod p
최종 계산
클라이언트:
B^a mod p
서버:
A^b mod p
결과가 같아짐
수학적으로:
g^(ab) mod p
가 된다.
즉 둘 다 같은 값을 얻는다.
핵심 포인트
엄청 중요한 건:
AES 키를 직접 전송하지 않았음이다.
그냥:
각자 계산해서
같은 키를 만든 것이다.
ECDHE는 뭐냐?
현재 HTTPS 핵심.
Elliptic-curve Diffie–Hellman
즉:
Diffie-Hellman을
ECC 기반으로 최적화한 것.
왜 현대 HTTPS는 ECDHE 사용?
장점:
- 빠름
- 키 작음
- 모바일 강함
- Perfect Forward Secrecy 제공
Perfect Forward Secrecy(PFS)
엄청 중요.
뜻:
미래에 서버 개인키 털려도
과거 통신은 안전왜 가능?
세션마다:
일회용 세션키를 새로 만들기 때문이다.
실제 HTTPS 흐름
인증
RSA/ECDSA 인증서로:
"진짜 서버 맞는지"검증.
키 교환
ECDHE로:
세션 AES 키 생성실제 통신
AES-GCM 사용.
핵심 한 줄
키 교환이란:
상대방과 직접 비밀키를 보내지 않고도,
둘만 같은 대칭키를 안전하게 만들어 공유하는 과정이다.
반응형
댓글