공개키 기반 구조, PKI (Public Key Infrastructure) #3

 

공개키 기반 구조, PKI (Public Key Infrastructure) #2

이전 게시글과 이어집니다

 

드디어 CA에 대해 다뤄볼 수 있게 되었습니다!

사실 CA도 정말 방대하고 해당 구조에 대해
정확하게 아는 사람은 많지 않을 것입니다. 
컴퓨터를 모두가 사용하지만,
실제 작동 원리나 구조에 대해 아는게 1%에 가까운 것처럼요.

우리는 네트워크 구조상 가장 최상단에 해당하는 어플리케이션 계층만 보고
내부적으로 어떻게 돌아가는지는 알 수 없습니다.
그저 잘 돌아간다고 믿는 것입니다.

그래서 오류가 발생하지 않는 프로그램은 존재할 수 없고
테스트는 오류가 존재함을 증명하는 활동이라 할 수 있습니다.
그게 저희가 주로하는 역할이고요.

일단 말이 길어지기 전에 시작해보겠습니다.

 

1. CA란?

Certificate Authority(인증 기관)의 약자로,
디지털 인증서를 발급하고 관리하는 신뢰할 수 있는 제3자 기관입니다.

보통 공동인증서를 발급받으면 발급해준 인증 기관을 확인할 수 있는데,
그것이 CA입니다.

CA는 yessignCA Class3 입니다!

2. CA의 역할?

CA는 사용자의 공개키(Public Key)와 식별 정보를 포함하는
디지털 인증서(Digital Certificate)를 발급하고 서명함으로써,
해당 공개키의 소유자가 누구인지 검증해주는 역할을 합니다.

1) 인증서 발급 및 서명

CSR 파일로 인증서 발급을 요청하면
CA가 검증하고 인증서를 발급 및 서명하는 역할을 합니다.
인증서 발급 시
CA의 개인키로 전자서명을 수행하여 인증서의 진위와 무결성을 보장합니다.

OpenSSL로 테스트 CSR 발급 및 CA로 인증서 발급도 가능합니다.
발급 방법은 이전 게시글을 참고해주세요.

OpenSSL CSR 발급 및 x.509 인증서 발급

 

2) 인증서 갱신 및 폐지

인증서의 유효기간이 만료되거나 보안 문제가 발생했을 경우,
인증서를 갱신하거나 폐지하며, 이를 위해 CRL(Certificate Revocation List) 또는
OCSP(Online Certificate Status Protocol)로 인증서의 상태를 관리합니다.

새로운 개념이 나왔는데, 각각 알아보도록 하겠습니다.

CRL
폐지된 인증서 목록입니다.
CA가 주기적으로 발행하는 파일로,
더 이상 유효하지 않은 인증서의 일련번호(serial number)를 담고 있습니다.

물론 CRL 또한 OpenSSL로 테스트 가능합니다.
이 부분도 추후 포스팅하겠습니다.

폐지된 인증서의 일련번호 확인!

CRL은 단순하고 구현이 쉽고
서명한 정적 파일로 제공되어서 변조 위험이 낮다는 장점이 존재하지만
치명적인 단점이 있습니다.

바로 실시간 확인이 불가하다는 점입니다.

실시간 확인이 불가한 경우
이미 폐지된 인증서로 로그인을 시도하는데
클라이언트나 서버에서 최신 CRL 반영이 안된 상태라면..
로그인이 되어버립니다.

물론 주기적으로 업데이트하는 시점을 정할 수는 있지만
너무 짧은 시간은 불가합니다.
CRL 배포 지점에 과도하게 데이터가 쌓이면
성능 저하 및 부하가 올 수 있기 때문입니다.

그래서 나온 것이 OCSP입니다.

OCSP (Online Certificate Status Protocol)

OCSP는 인증서의 실시간 폐지 여부를 확인하기 위한 프로토콜입니다.
클라이언트는 CA의 OCSP 서버에 직접 요청하여 특정 인증서가 폐지되었는지를 확인하고
CA는 OCSP 서버에 직접 요청해서 인증서 갱신 및 폐지 여부를 확인합니다.

CA ↔ OCSP 동작 방식 플로우 
* 검증자는 CA가 아닌 인증서를 실사용할 서버 및 클라이언트입니다.

[1] 인증서 발급 요청 (CSR)
    └── 클라이언트 → CA
         (공개키 + 식별자 정보)

        ↓

[2] CA가 인증서 서명 및 발급
    └── 인증서 파일(.crt) 생성
    └── 일련번호(serial) 등록
    
        ↓

[3] 인증서 유효기간 동안 사용
    └── 클라이언트 또는 서버에 적용
    └── 검증자는 CRL/OCSP를 통해 상태 확인
        │
        ├────────────────────┐
        ↓                    ↓
[4A] 인증서 갱신       [4B] 인증서 폐지 요청
    └── 만료 전 재발급   └── 키 유출, 퇴사 등 사유
        │                    │
        ↓                    ↓

[5A] 새 인증서 발급        [5B] 폐지 처리
    └── 새로운 일련번호 부여 └── CA는 폐지 사유 기록
                                └── CRL에 추가 or OCSP 응답 상태 = "revoked"
        │                    │
        ↓                    ↓

[6A] 클라이언트는 새 인증서 사용
[6B] 폐지된 인증서는 더 이상 유효하지 않음
    └── 검증 시 실패 처리됨

3) 신뢰체계 유지

CA는 신뢰할 수 있는 인증기관입니다.
CA에서 발급되었다는 사실은
해당 서비스와의 통신이 안전하다고 여기게 되는 것입니다.

그래서 CA는 신뢰체계를 유지하기 위해
체계적인 구조와 다양한 기술을 적용합니다. 
그리고 여기서 등장하는 핵심 개념은 체인 구조입니다.

신뢰 사슬, 체인 구조(Chain of Trust)
CA는 단일 주체가 아니라 계층적으로 구성된 신뢰 체계입니다.
최상위에는 스스로 서명한 Root CA가 있으며,
이 Root CA는 하나 이상의 중간 CA(Intermediate CA)에게 권한을 위임합니다.
최종적으로 서버나 사용자가 사용하는 인증서는 중간 CA로부터 발급됩니다.

위에서 봤던 CA인 yessignCA Class3은 중간 CA입니다.
이 중간 CA의 위에 Root CA가 존재합니다.

체인 구조 플로우

Root CA
  ↓ 서명
중간 CA (인증서 발급/갱신/폐지/재발급 등 인증서 전반에 대한 관리)
  ↓ 서명
End-Entity Certificate (서버/클라이언트)

중간 CA는 Root CA의 정책에 따라
다수 생성이 가능합니다.
주로 용도에 맞게 분리해서 생성합니다.

 

Root CA는 전 세계적으로 신뢰되고 있습니다.
모든 인증서가 Root CA에서 직접 나오면 운영이 불가능합니다.
그래서 중간 CA를 용도별(SSL, 개인, 기업, 코드 서명 등)로 나누고,
다양한 신뢰 경로(체인)를 만들 수 있도록 분리합니다.

 

 

중간 CA 용도 구분

구분	설명
SSL/TLS 인증서 발급용 CA	웹사이트용 HTTPS 인증서 발급 담당 예: www.example.com
개인 인증용 CA	공동인증서, 전자서명용 개인 인증서 발급
기업 인증서 발급용 CA	조직명 포함 인증서, 전자세금계산서, 기업 서명용
코드 서명용 CA	소프트웨어, 드라이버 등에 서명하는 인증서 발급
메일 서명/암호화용 CA (S/MIME)	이메일 인증 및 암호화 인증서 발급
모바일/IoT 인증용 CA	기기 인증, IoT 장비의 키 교환 인증서 등
VPN/네트워크 장비용 CA	내부 시스템 접속을 위한 사용자/장비 인증서 발급
테스트/개발 전용 CA	테스트 환경에서만 신뢰되는 인증서 발급 (실제 서비스 미사용)
하이애슈어런스(Hardware Token용) CA	HSM, USB 토큰 등에 저장되는 고보안 인증서 발급용

 

키 보관 방법

중간 CA 키가 유출되면 해당 체인만 폐기하면 되지만,
Root CA 키가 유출되면 모든 체인과 신뢰를 버려야 합니다.

그래서 Root CA 및 중간 CA의 키는
오프라인, HSM(하드웨어 보안모듈)등 격리된 공간에 보관됩니다.


운영 정책 및 감사

CA는 모든 운영에 대한 정책(CPS: Certification Practice Statement) 을 수립하고
이 정책은 다음을 포함해야 합니다.

인증서 발급 절차
갱신/재발급 조건
폐지 기준
키 보관 및 보호 방법

정기적인 제3자 감사(WebTrust, ETSI 등)를 통해 투명성을 확보합니다.

CTLog (Certificate Transparency Log)

투명한 발급 기록(로그)을 확인 가능해야 합니다.
CA가 발급한 인증서를 공개 로그에 등록해서
누구나 해당 인증서의 존재 여부를 검증하고
부정 및 위조 발급을 감지 가능합니다.
검증자는 CT 로그에 등록된 인증서만을 안전한 인증서로 처리하는 방식입니다.

다음은 CA의 인증서 관리 체계에 있어
빠질 수 없는 ACME 프로토콜에 대해 다뤄보겠습니다.