Invisible Safety,

Proven by Intelligence

보이지 않는 안전을 인텔리전스로 증명하다.

기술 노트
IT 산업의 변화를 이끄는 MDS인텔리전스의
기술 인사이트를 만나보세요.
사이버 보안 & 암호화
[NeoCertManager] TLS 1.2에서 TLS 1.3으로의 진화 ⑶ - TLS 1.3의 핵심 원리 — ECDHE를 이용한 키 생성
2026년 08월 05일

지난 기술노트에서 TLS 1.3은 “키를 전달하지 않고 함께 만든다”는 이야기를 했습니다. 그런데 이 말은 언뜻 마법처럼 들리는데요. 서로 아무것도 주고받지 않고 어떻게 똑같은 키에 도달할 수 있을까요? 이번 편에서는 이걸 가능하게 하는 실제 계산, ECDHE(Elliptic Curve Diffie-Hellman Ephemeral)의 원리를 하나씩 풀어봅니다. 이름은 길고 어렵지만 핵심 아이디어는 의외로 단순합니다.​


이름부터 뜯어보기

 · EC (Elliptic Curve): 타원곡선이라는 수학적 구조를 이용합니다.

 · DH (Diffie-Hellman): 1976년에 나온, 공개된 값만 교환해서 같은 비밀을 만드는 키 교환 방식의 원조.

 · E (Ephemeral): 매번 새로 만들고 쓰고 버리는, 일회성이라는 뜻.


즉 ECDHE는 “타원곡선을 이용한, 매번 새로 만드는 Diffie-Hellman 키 교환”입니다.




핵심 아이디어: 각자 비밀 숫자 하나씩

클라이언트와 서버는 각자 아무도 모르는 자신만의 비밀 숫자를 하나 정합니다.(클라이언트는 a, 서버는 b). 이 값은 절대로 외부에 공개하지 않습니다. 대신 여기서 파생된, 공개해도 안전한 값을 만듭니다. 클라이언트는 A = a × G를, 서버는 B = b × G를 만든다. 여기서 G는 타원곡선 위의 정해진 기준점(Generator Point)으로, 전 세계 누구나 알고 있는 공개된 값입니다. 네트워크로는 이 A와 B만 오갑니다. 각자의 비밀 숫자 a, b는 단 한 번도 전송되지 않습니다.


[그림 2] TLS 1.3 ECDHE Handshake ─ KeyShare 교환과 Shared Secret 계산



어떻게 같은 값에 도달하는가

 이제 각자 상대방이 보낸 공개 값을 받아서, 자신의 비밀 숫자와 곱합니다. 클라이언트는 a × B = a × (b × G) = abG를 계산하고, 서버는 b × A = b × (a × G) = baG를 계산합니다..

 곱셈은 교환법칙이 성립하므로 abG와 baG는 완전히 같은 값입니다.양쪽은 서로의 비밀 숫자를 전혀 모른 채로, 각자의 계산만으로 완전히 같은 결과값에 도달합니다.이 값이 바로 Shared Secret입니다.


[그림 3] 클라이언트와 서버가 각자 계산해 동일한 Shared Secret에 도달하는 과정


공격자는 왜 같은 값을 계산할 수 없을까

​공격자가 네트워크를 도청한다고 해보죠. 공격자가 볼 수 있는 것은 A와 B, 즉 공개된 값뿐입니다. 비밀 숫자 a와 b는 절대 볼 수 없습니다.


abG를 계산하려면 a나 b 중 하나는 알아야 합니다. 그런데 A = a × G라는 식에서 A와 G를 알고 있다고 해서 a를 역산해낼 수 있을까요?

이 역산 문제가 바로 타원곡선 이산대수 문제(Elliptic Curve Discrete Logarithm Problem, ECDLP)입니다. 타원곡선 위에서는 A = a × G라는 “곱하기”(정확히는 점 덧셈의 반복) 연산은 쉽지만, 그 반대인 “A와 G를 보고 a를 알아내는” 연산은 현재 알려진 어떤 알고리즘으로도 현실적인 시간 안에 풀 수 없습니다. 이 비대칭성 — 한쪽 방향은 쉽고 반대 방향은 사실상 불가능한 성질 — 이 ECDHE 안전성의 수학적 근거입니다.


이 방식이 왜 1편의 문제를 해결하는가

1편에서 지적한 TLS 1.2의 문제를 떠올려보자. RSA 개인키 하나가 유출되면, 과거에 저장해 둔 암호화된 Premaster Secret을 복호화해서 과거 세션키까지 전부 복원할 수 있었습니다.

ECDHE 방식에서는 이 공격이 통하지 않습니다. 이유는 두 가지입니다.

 첫째, 네트워크로 전송된 “비밀”이 애초에 없습니다. TLS 1.2에서는 Premaster Secret이라는 실체가 암호화되어 네트워크를 오갔다. 훔쳐서 보관해 둘 대상이 있었던 것입니다. 반면 ECDHE에서는 A, B처럼 공개해도 안전한 값만 오갑니다. Shared Secret 자체는 한 번도 전송된 적이 없으니, 나중에 무언가를 훔쳐서 복호화할 방법 자체가 없습니다.

 둘째, 비밀 숫자 a, b는 세션이 끝나면 사라진다. 클라이언트와 서버는 세션마다 새로운 a, b를 생성하고, 통신이 끝나면 즉시 폐기합니다. 설령 미래에 서버의 인증서 개인키가 유출되더라도, 이미 사라진 그 세션만의 a, b를 복원할 방법은 없습니다. Ephemeral(일회성)이라는 이름이 붙은 이유가 바로 여기에 있습니다.


[그림 6] 세션마다 생성되고 즉시 폐기되는 ECDHE 비밀 숫자


Shared Secret 에서 실제 AES 키까지

한 가지 짚어야 할 점은, ECDHE로 만든 Shared Secret이 곧바로 AES 키로 쓰이는 건 아니라는 것입니다. Shared Secret은 그저 하나의 “원재료”에 불과합니다.

 TLS 1.3은 이 값을 HKDF(HMAC 기반 키 유도 함수)에 넣어 단계적으로 가공합니다. 이 과정에서 Handshake를 보호하는 키, 최종 데이터를 암호화하는 클라이언트/서버 각각의 키 등 목적이 다른 여러 키가 독립적으로 파생됩니다. 하나의 키가 문제가 생기더라도 다른 키까지 연쇄적으로 위험해지지 않도록 하기 위해서입니다.

[그림 8] Shared Secret에서 AES 세션키까지의 HKDF 파생 과정


정리

ECDHE의 핵심을 한 문장으로 요약하면 이렇습니다.

"각자 비밀 숫자를 갖고, 공개 가능한 값만 교환해서, 곱셈의 교환 법칙을 이용해 양쪽이 동일한 값에 도달한다. 그리고 그 비밀 숫자는 세션이 끝나면 사라진다."

이 방식 덕분에 TLS 1.3은 “키를 훔쳐서 복호화하는” 공격 자체가 성립하지 않는 구조를 갖게 됐고, 이는 곧 Forward Secrecy를 기본으로 제공하는 프로토콜로 이어졌습니다.


다음 편에서는 지금까지 살펴본 TLS 1.2와 TLS 1.3을 항목별로 정리하고, 전체적인 관점에서 두 버전의 차이를 한눈에 비교해보겠습니다.


📧 nkm_biz@mdsit.co.kr       ✍️ 문의남기기