CA와 필요성
공개키의 신뢰 문제
공개키 암호화는 강력한 보안을 제공하지만, 근본적인 문제가 있다. "이 공개키가 정말 그 사람의 것인가?"를 어떻게 확인할 수 있을까?
Alice가 Bob에게 암호화된 메시지를 보내려고 한다. Bob의 공개키로 암호화하면 Bob만 복호화할 수 있다. 하지만 Trudy가 중간에서 자신의 공개키를 "Bob의 공개키"라고 속여서 전달하면 어떻게 될까? Alice는 Trudy의 공개키로 메시지를 암호화하게 되고, Trudy가 이를 복호화해서 읽을 수 있다.
이것이 중간자 공격(Man-in-the-Middle Attack)이다. 공개키 암호화의 보안은 공개키의 진위 여부를 확인할 수 있느냐에 달려 있다.
CA란 무엇인가
CA(Certificate Authority, 인증 기관)는 공개키와 그 소유자의 신원을 연결해주는 신뢰할 수 있는 제3자다. 실생활에서 공증인이 문서의 진위를 증명하는 것처럼, CA는 "이 공개키는 정말 이 사람(또는 조직)의 것이다"라고 보증한다.
CA의 역할은 다음과 같다. 먼저 신원 확인을 수행한다. 공개키 소유자가 실제로 그 조직이나 개인인지 검증한다. 도메인 소유권, 사업자 등록증, 신분증 등을 확인한다. 그 다음 인증서 발급을 한다. 검증이 완료되면 공개키와 소유자 정보를 담은 디지털 인증서를 발급한다. 이 인증서에는 CA의 디지털 서명이 포함된다.
디지털 인증서의 구조
디지털 인증서는 X.509 표준을 따르며, 주요 구성 요소는 다음과 같다.
주체(Subject)는 인증서 소유자의 정보다. 웹사이트의 경우 도메인 이름이 여기에 해당한다. 공개키(Public Key)는 주체의 공개키 값이다. 발급자(Issuer)는 이 인증서를 발급한 CA의 정보다. 유효 기간(Validity)은 인증서가 유효한 시작일과 만료일이다. 일반적으로 1~2년이다. 서명(Signature)은 CA가 자신의 개인키로 생성한 디지털 서명이다. 인증서의 무결성과 진위를 보장한다.
인증서를 받은 사람은 CA의 공개키로 서명을 검증할 수 있다. 서명이 유효하면 인증서가 위조되지 않았고, 실제로 해당 CA가 발급한 것임을 확신할 수 있다.
인증서 체인
실제 PKI(Public Key Infrastructure)는 계층 구조로 운영된다.
루트 CA(Root CA)는 최상위 인증 기관이다. 자기 자신의 인증서에 서명한다(자체 서명 인증서). 운영체제나 브라우저에 미리 신뢰할 수 있는 루트 CA 목록이 내장되어 있다. 중간 CA(Intermediate CA)는 루트 CA가 인증한 하위 CA다. 실제 웹사이트 인증서 발급은 대부분 중간 CA가 담당한다. 최종 인증서(End-entity Certificate)는 실제 웹사이트나 서버에 발급되는 인증서다.
이런 계층 구조를 사용하는 이유는 보안 때문이다. 루트 CA의 개인키가 유출되면 전체 PKI가 무너진다. 루트 CA는 오프라인으로 격리하고, 일상적인 인증서 발급은 중간 CA가 처리하면 위험을 분산할 수 있다.
인증서 검증 과정
브라우저가 HTTPS 사이트에 접속할 때 다음과 같은 검증이 이루어진다.
서버가 자신의 인증서와 중간 CA 인증서를 전송한다. 브라우저는 인증서 체인을 따라 올라가며 각 서명을 검증한다. 최종적으로 브라우저에 내장된 루트 CA까지 체인이 연결되는지 확인한다. 인증서의 유효 기간, 도메인 일치 여부 등도 함께 검사한다.
검증에 실패하면 브라우저는 경고 메시지를 표시한다. "이 연결은 안전하지 않습니다" 같은 메시지가 바로 인증서 검증 실패를 의미한다.
CA의 중요성과 한계
CA 시스템은 인터넷 보안의 근간이다. HTTPS, 코드 서명, 이메일 암호화 등 대부분의 보안 프로토콜이 CA 기반 PKI에 의존한다.
하지만 한계도 있다. CA가 해킹당하거나 실수로 잘못된 인증서를 발급하면 심각한 보안 문제가 발생한다. 2011년 DigiNotar 해킹 사건에서는 공격자가 가짜 google.com 인증서를 발급받아 실제 공격에 사용했다. 이 사건 이후 인증서 투명성(Certificate Transparency)이라는 보완 메커니즘이 도입되어, 발급되는 모든 인증서를 공개 로그에 기록하고 모니터링할 수 있게 되었다.