항상 그런 것은 아닙니다. 인증서 개인키와 과거 세션의 대칭키는 역할이 다릅니다. 세션에서 ephemeral Diffie–Hellman 교환으로 만든 비밀이 유출 시점까지 보존되지 않았고 재사용 등 문제가 없다면, 나중에 인증용 장기키가 유출되어도 그 키만으로 과거 세션 키를 계산하기 어렵게 하는 성질을 forward secrecy라고 합니다.
반대로 TLS 1.2의 static RSA 키 교환이나 비임시 DH 계열은 forward secrecy를 제공하지 않아 장기키가 나중에 노출될 때 과거 트래픽이 위험해질 수 있습니다. 세션 재개에서는 PSK만 사용하는지 PSK-DHE를 사용하는지, ticket 암호화 키와 오래된 재개 상태를 어떻게 관리했는지도 확인해야 합니다. 아래 사례는 직접 만든 교육용입니다.
인증키와 세션 키는 같은 비밀이 아닙니다
HTTPS 연결에서 서버 인증서의 공개키는 서버 신원을 확인하는 과정에 쓰이고, 인증서에 대응하는 개인키는 그 신원을 증명하는 장기 비밀입니다. 실제 응용 데이터는 보통 handshake에서 협의한 세션 키로 암호화합니다. 따라서 ‘서버 개인키가 유출됐다’는 사실만으로 저장된 모든 과거 암호문이 곧바로 풀린다고 말할 수는 없습니다. 어떤 키 교환을 사용했는지, 그때 만든 비밀이나 세션 티켓 키가 보존됐는지, 공격자가 과거 암호문을 가지고 있는지까지 나눠야 합니다.
Forward secrecy는 장기 인증키가 나중에 노출되더라도 이전 통신의 세션 키를 그 장기키만으로 역산하기 어렵게 만드는 목표입니다. Diffie–Hellman 계열의 임시(ephemeral) 비밀을 연결마다 생성하고, 세션이 끝난 뒤 필요한 비밀을 안전하게 폐기하면 장기키만으로 과거 통신을 복구하기 어렵습니다. RFC 9325는 TLS/DTLS에서 forward secrecy를 제공하는 암호군을 선호하도록 권고하고, RFC 10015는 TLS 1.2 및 DTLS 1.2의 오래된 static key exchange 방식에 더 강한 제한을 적용했습니다. 이 권고를 특정 서버가 실제로 지켰다는 증거와 혼동하면 안 됩니다.
| 가상 연결 기록 | 나중에 유출된 비밀 | 과거 통신 판단 | 확인할 조건 |
|---|---|---|---|
| 연결 A: TLS 1.2 static RSA key transport | 인증서 개인키와 과거 암호문 | forward secrecy가 없어 과거 세션이 위험할 수 있음 | 실제 협상 cipher suite, 캡처 시점과 키 보유 자료 |
| 연결 B: 연결별 ephemeral ECDHE | 서버 인증서 개인키만 | 인증키만으로 과거 세션 키를 바로 복구하기 어렵도록 설계됨 | ephemeral 비밀 재사용·유출 여부, 협상 기록 |
| 연결 C: TLS 1.3 PSK resumption | 장기 PSK 또는 ticket key | DHE가 포함됐는지와 티켓 관리 기간에 따라 판단 | psk_dhe_ke 여부, key_share, ticket 암호화키 교체·폐기 |
한 줄의 ‘개인키 유출’만으로 결론을 내리지 않습니다
사고 메모에 ‘11월 3일 서버 인증서 개인키가 유출됐고 10월 28일 TLS 트래픽을 저장해 두었다’고 적혀 있다고 합시다. 이 정보만으로 과거 통신이 모두 복호화된다고 결론내리지 않습니다. 먼저 각 연결의 negotiated key exchange를 확인합니다. static RSA 또는 static DH라면 이후 인증서 개인키 유출이 과거 세션 기밀성에 영향을 줄 수 있습니다. ephemeral ECDHE였다면 장기키와 세션 키가 분리되므로 인증키 유출만으로 예전 세션을 복원하기 어렵지만, 임시 비밀이 호스트에서 함께 유출됐거나 재사용됐다면 그 보호가 깨질 수 있습니다.
‘서버가 PSK를 썼다’는 기록만으로도 답은 끝나지 않습니다. RFC 9325는 TLS 1.3 session resumption에서 forward secrecy를 얻기 위해 psk_dhe_ke와 새 key_share를 사용하는 방법을 권고합니다. PSK와 기존 세션 상태만으로 재개했는지, 새 임시 교환을 추가했는지를 구분해야 합니다. TLS 1.2 ticket을 쓰는 경우에는 ticket 암호화 키를 정기적으로 바꾸고 유효기간이 끝난 키를 폐기하는지, 너무 오래된 상태를 재개하지 않는지 살펴야 합니다. 티켓을 보호하는 장기 비밀이 탈취되면 forward secrecy의 이점이 약해질 수 있습니다.
복호화 가능성을 다섯 가지 질문으로 나눕니다
- 유출된 것이 인증서 개인키인지, PSK인지, ticket 암호화 키인지, 세션별 ephemeral 비밀인지 식별합니다.
- 문제의 연결이 static RSA·static DH·ephemeral DH 중 무엇을 협상했는지 handshake 기록에서 확인합니다.
- ephemeral 비밀이 연결마다 새로 생성됐는지, 호스트에서 유출되거나 재사용된 단서가 있는지 확인합니다.
- session resumption이면 PSK-DHE 또는 PSK-only 여부와 ticket key 교체·폐기 기간을 따로 확인합니다.
- 캡처한 암호문, 암호 제품군, 유출 범위와 시점을 맞춘 뒤 확정된 사실과 가능성을 분리해 보고합니다.
이 방법은 ‘개인키가 나갔으니 전부 복호화’와 ‘ECDHE니까 절대 안전’이라는 두 극단을 모두 피합니다. Forward secrecy는 뒤늦은 장기키 유출의 영향을 제한하는 성질이지, 종단 서버가 침해된 시점의 메모리나 악성코드가 세션 키를 읽지 못하게 하는 보증은 아닙니다. 현재 연결을 실시간으로 장악했거나 임시 비밀을 확보했다면 결과가 달라집니다. 실제 침해 대응에서는 서버 로그, TLS 설정 기록, key rotation 이력과 메모리·덤프 보존 범위를 보안 담당자가 승인된 절차로 확인해야 합니다.
‘키 유출’과 ‘세션 키 유출’을 구별합니다
자주 하는 실수는 인증서 개인키가 모든 응용 데이터를 직접 암호화한다고 생각하거나, forward secrecy를 지원하는 협상이 한 번 있었다는 사실만으로 전체 접속 이력을 안전하다고 단정하는 것입니다. 암호화된 ticket을 재사용하는 세션은 ticket key 관리가 추가로 중요합니다. 임시 비밀을 지나치게 오래 저장하거나 같은 값을 재사용하면 forward secrecy 효과를 해칠 수 있습니다. 답안에서는 ‘키 교환 방식, 유출된 키의 종류, 임시 비밀 관리, 재개 세션 조건을 확인한다’고 조건을 적으면 단일 키 이름만 외우는 것보다 정확합니다.
유출된 키와 TLS 교환 방식을 짝지어 봅니다
회상 연습: A는 TLS 1.2 static RSA로 기록됐고 서버 인증서 개인키가 다음 달 유출됐습니다. B는 연결별 ephemeral ECDHE를 썼고 인증서 개인키만 유출됐습니다. C는 PSK session resumption을 썼지만 기록에는 새 DHE 교환 여부가 없습니다. A는 과거 통신이 위험할 수 있습니다. B는 인증서 개인키만으로 과거 세션을 복원하기 어렵지만 세션별 비밀 유출 여부는 확인해야 합니다. C는 PSK-DHE 여부와 ticket key 관리 자료가 없어 결론을 보류합니다. 세 사례가 모두 실제 복호화됐다고 말할 수는 없습니다. 이 연습은 직접 작성한 교육 자료이며 시험 기출이나 판매 카드가 아닙니다. 상품 구성은 /decks/security#focus-180에서 확인하세요.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
TLS 기록 세 건 중 A는 TLS 1.2 static RSA, B는 연결별 ephemeral ECDHE, C는 PSK resumption이나 DHE 정보가 없다. 서버 인증서 개인키만 나중에 유출됐다면 각 사례의 과거 통신 복호화 판단을 어떻게 나눌까?
정답과 해설 확인
A는 forward secrecy가 없어 과거 세션이 위험할 수 있다. B는 인증서 개인키만으로 과거 세션 키를 복구하기 어렵도록 설계됐지만 세션별 비밀 유출·재사용 여부를 확인한다. C는 PSK-DHE 여부와 ticket key 관리가 확인될 때까지 판단을 보류한다.RFC 10015는 static RSA에 forward secrecy가 없음을 명시하고 RFC 9325는 ephemeral 교환과 PSK-DHE 재개 및 ticket key 수명 관리가 중요하다고 설명한다. 실제 복호화 성공은 별도의 암호문·키·침해 증거가 있어야 확인할 수 있다.