대칭키 암호화 방식의 한계와 비대칭키 암호화 방식의 등장을 알아보았다. 특히, 두 가지 암호화 방식을 혼합하여 효율성과 보안성을 모두 잡는 SSL/TLS의 기본 원리를 알아보았다. 그러나 이 모든 과정에서 간과할 수 없는 문제가 남아 있었으니, “수신한 공개키를 과연 신뢰할 수 있는가?”하는 의문이다. 이 근본적인 신뢰 문제를 해결하는 공개키 기반 구조(PKI: Public Key Infrastructure)와 디지털 인증서의 역할에 대해 더 자세히 알아보자
중간자 공격(MITM)과 신뢰의 필요성
PC가 서버로부터 공개키를 받아 세션 키를 암호화하여 전송하는 과정은 비대칭키 암호화의 핵심이다. 하지만, 악의적인 해커가 중간에 끼어들어 자신이 생성한 공개키를 서버의 공개키인 것처럼 위장하여 PC에게 전달한다면 어떻게 될까? 이것이 바로 중간자 공격(Man-in-the-Middle Attack)이다
MITM 공격 상황에서 PC는 해커의 공개키를 진짜 서버의 것으로 착각하고 세션 키를 암호화하게 된다. 해커는 이 암호화된 세션 키를 자신의 개인키로 복호화하여 세션 키를 탈취하고, 다시 서버의 진짜 공개키로 암호화하여 서버에 전달한다. 결과적으로 PC와 서버는 해커가 알고 있는 세션 키로 암호화 통신을 시작하며, 해커는 모든 통신 내용을 도청할 수 있게 된다
이러한 공격을 방어하려면 PC는 수신한 공개키가 정말로 통신하려는 서버의 공개키인지 확신할 수 있어야 한다. 즉, 공개키의 ‘신원’을 검증할 수 있는 공신력 있는 메커니즘이 필요하다. 여기에 마치 문서의 진위를 우체국이 보증해주는 ‘내용 증명’처럼, 인터넷 세상에서 ‘신뢰’를 보증해주는 제 3의 기관이 등장한다
공개키 기반 구조(PKI)와 디지털 인증서
신뢰 문제를 해결하기 위해 도입된 것이 바로 공개키 기반 구조(PKI)이다. PKI의 핵심 구성 요소는 인증기관(CA: Certificate Authority)과 디지털 인증서이다
웹 서버 관리자(실무자)가 자신의 서버(예: www.pki.com)에 SSL/TLS를 적용하고자 할 때의 절차는 다음과 같다
- 키 쌍 생성 및 구매 요청: 웹 서버 실무자는 보통 직접 키 쌍을 생성하기보다, 등록 기관(RA) 또는 인증기관(CA)에 웹 서버에 사용할 공개키/개인키 쌍과 함께 디지털 인증서 발급을 요청한다. 키 쌍은 일회용이 아니라, 6개월에서 1년과 같은 유효 기간을 가지고 사용된다. 이는 키 생성에 드는 전산 자원 소모를 줄이고 관리 효율성을 높이기 위함이다.
- 등록 기관(RA)에 역할: 등록 기관 (RA: Registration Authority)은 사용자의 신분을 확인하고, CA에 인증서 발급을 대행하는 기관이다. 웹 서버 실무자는 RA를 통해 CA에 인증서 발급을 의뢰한다.
- 인증기관(CA)의 역할: 인증기관(CA: Certificate Authority)은 PKI의 핵심 기관으로, 디지털 인증서를 발급하고 관리한다. CA는 요청받은 웹 서버의 키 쌍을 생성하거나, 제출된 공개키를 기반으로 인증서를 생성한다.
- 디지털 서명: CA는 웹 서버의 공개키와 도메인 정보, 유효 기간 등 다양한 정보를 포함하는 X.509 표준 형식의 디지털 인증서를 생성한다. 이때 CA는 이 인증서의 무결성(데이터가 위변조 되지 않았음)과 인증서 발급 주체의 신원을 보증하기 위해, 인증서 내용의 해시 값에 자신의 개인키(CA Private Key)로 전자 서명(Digital Signature)을 한다. 이 전자 서명은 CA가 해당 인증서의 내용을 보증한다는 것을 의미한다
- 인증서 발급 및 설치: CA는 서명된 디지털 인증서와 웹 서버의 개인키를 RA를 통해 웹 서버 실무자에게 전달하고, 실무자는 이 SSL 인증서를 웹 서버에 설치한다
이제 웹 서버는 단순한 공개키 대신, CA에 의해 전자 서명된 SSL/TLS 인증서를 제공하게 된다
SSL/TLS 인증서의 검증 과정: 신뢰의 연쇄
클라이언트(PC)가 웹 서버에 HTTPS로 접속할 때, 서버는 자신의 SSL/TLS 인증서를 클라이언트에게 보낸다. 클라이언트는 이 인증서에 포함된 서버의 공개키를 바로 사용하는 것이 아니라, 먼저 인증서의 신뢰성을 검증하는 절차를 수행한다. SSL/TLS 인증서 검증 과정은 다음과 같다
- 인증서 수신: PC는 웹 서버로부터 SSL/TLS 인증서를 수신한다
- CA 공개키 확보: PC는 미리 자신의 운영체제(예: Windows)나 브라우저에 설치되어 있는 루트 인증서(Root Certificate) 목록에서 해당 SSL/TLS 인증서를 발급한 CA의 공개키(CA Public Key)를 찾는다. Microsoft나 Google과 같은 대형 소프트웨어 벤저들은 주기적인 보안 업데이트를 통해 공신력 있는 CA들의 루트 인증서(CA 공개키 포함)를 사용자 PC에 미리 배포한다
- 전자 서명 복호화: PC는 수신한 SSL/TLS 인증서에 포함된 CA의 전자 서명(CA 개인키로 암호화된 해시 값)을 확보한 CA의 공개키로 복호화한다. 이 복호화에 성공하면, 전자 서명이 CA에 의해 만들어졌음을 확인할 수 있다
- 해시 값 비교: PC는 수신한 SSL/TLS 인증서의 전체 내용에 대해 동일한 해시 알고리즘(예: SHA-256)을 적용하여 새로운 해시 값을 계산한다. 그리고 이 계산된 해시 값을 3단계에서 복호화하여 얻은 해시 값과 비교한다
- 신뢰 확인: 만약 두 해시 값이 일치한다면, PC는 다음과 같은 결론을 내린다
- 인증서 내용이 CA에 의해 서명된 이후로 위변조되자 않았다 (무결성 보장)
- 인증서를 발급한 CA가 신뢰할 수 있는 기관이다 (인증서 발급 주체 인증)
- 이 인증서에 포함된 서버의 공개키가 진짜 서버의 공개키이다
- 세션 키 교환: 검증이 완료되면, PC는 인증서에서 추출한 서버의 진짜 공개키로 자신이 생성한 세션 키를 암호화하여 서버에게 전송한다. 이후의 통신은 이 세션 키를 이용한 대칭키 암호화로 안전하게 진행된다.
이러한 신뢰의 연쇄는 PKI 인증 체계의 핵심이다. CA는 자신의 공개키가 담긴 루트 인증서로 자신의 서명을 보증하며, 이 루트 인증서 자체는 매우 강력한 보안 조치 하에 관리된다
PKI 계층 구조 및 인증 기관의 변화
- PAA (Policy Approval Authority): 최상위 기관으로, 공인 인증서에 대한 정책을 결정하고 하위 기관의 정책을 승인한다 (예: 대한민국 과학기술정보통신부)
- PCA (Policy Certification Authority): PAA 하위 기관으로, 루트 CA를 발급하고 기본 정책을 수립한다 (예: 한국인터넷진흥원 KISA) Root CA는 모든 인증서의 기초가 되며, 자체 서명 인증서를 사용한다
- CA (Certification Authority): PCA의 하위 기관으로, 실제 인증서 발급 및 취소 등의 실질적인 업무를 수행한다. (예: 금융결제원 YESSIGN, 한국전산원 NCA, VeriSign 등) CA들은 상호 간에도 신뢰 관계를 형성한다
- RA (Registration Authority): 사용자의 신분을 확인하고 CA에 인증서 발급을 대행하는 기관이다
과거에는 CA 역할을 공공기관이나 특정 대형 기관만 수행할 수 있었으나, 법률 및 기술의 변화로 이제는 민간 기업들도 CA 역할을 수행할 수 있게 되었다. 이로 인해 은행, 네이버, 카카오 등 다양한 민간 기업에서 자체 인증서를 발급하여 서비스에 활용하고 있으며, 이는 인터넷 환경과 사용자 편의성에 큰 변화를 가져왔다