PKI

인증기관은 공개키 기반구조의 핵심 신뢰 기관으로, 디지털 인증서의 발급, 관리, 폐지를 담당하는 제3의 신뢰할 수 있는 기관이다. CA는 인증서 신청자의 신원을 확인하고, 해당 신원과 공개키를 바인딩하는 디지털 인증서를 생성하여 발급한다. 이 과정에서 CA는 자신의 개인키로 인증서에 디지털 서명을 하여 그 진위와 무결성을 보증한다.

CA의 주요 기능은 다음과 같다.

CA는 계층 구조를 형성할 수 있다. 최상위에 위치한 루트 CA는 자기 서명된 인증서를 가지며, 그 아래 중간 CA를 인증할 수 있다. 이 중간 CA는 다시 최종 사용자나 장치에 대한 인증서를 발급한다. 이러한 계층 구조는 신뢰의 연쇄를 구성하여, 최종 사용자가 루트 CA의 공개키를 신뢰하면 그 아래에서 발급된 모든 인증서를 검증할 수 있게 한다.

CA의 신뢰성은 전체 PKI 생태계의 기반이 된다. 따라서 CA는 엄격한 물리적, 기술적, 운영적 보안 정책을 준수해야 한다. 주요 CA의 공개키는 웹 브라우저나 운영체제와 같은 클라이언트 소프트웨어에 미리 내장되어 배포되며, 이를 '신뢰할 수 있는 루트 인증서 저장소'라고 부른다.

등록기관은 인증기관의 업무 부담을 분산시키고, 인증서 발급 신청자의 신원 확인을 수행하는 역할을 담당한다. 인증기관이 인증서의 최종 발급 및 서명을 책임진다면, 등록기관은 그 이전 단계인 검증과 등록 절차를 처리한다.

등록기관의 주요 임무는 인증서 발급을 요청하는 개인이나 조직의 신원을 철저히 확인하는 것이다. 이 과정에는 신청서 검토, 신분증 확인, 사업자 등록증 확인 등이 포함된다. 또한, 등록기관은 인증서 갱신, 재발급, 폐지 요청을 접수하고 검증하여 인증기관에 전달한다. 이를 통해 인증기관은 암호화 작업과 인증서 서명이라는 핵심 업무에 집중할 수 있다.

등록기관과 인증기관의 관계는 다음과 같이 구분된다.

대규모 PKI 환경에서는 별도의 등록기관을 두어 지리적으로 분산된 사용자에 대한 등록 업무를 효율적으로 처리한다. 등록기관은 인증기관의 정책에 따라 운영되며, 인증 실무 선언문에 명시된 절차를 준수해야 한다.

인증서 저장소는 발급된 디지털 인증서와 인증서 폐기 목록(CRL)을 저장하고 배포하는 역할을 담당하는 시스템 또는 디렉터리 서비스이다. 이 저장소는 일반적으로 LDAP(Lightweight Directory Access Protocol) 디렉터리나 HTTP 웹 서버를 통해 공개적으로 접근 가능하게 구성된다. 사용자나 응용 프로그램은 이 저장소에서 특정 주체의 공개키를 포함한 인증서를 조회하여 암호화나 서명 검증에 활용할 수 있다.

주요 저장소 유형은 다음과 같다.

인증서 저장소는 단순한 저장 기능을 넘어, PKI 생태계의 효율성과 보안성을 보장하는 핵심 요소이다. 저장소를 통해 최신의 CRL 정보를 제공함으로써 폐기된 인증서의 사용을 방지하고, 인증서의 유효성을 실시간으로 검증하는 OCSP(Online Certificate Status Protocol) 서버에 정보를 공급하기도 한다. 잘 관리된 저장소는 PKI 기반 서비스의 가용성과 신뢰성을 높이는 기반이 된다.

인증서 폐기 목록(Certificate Revocation List, CRL)은 인증기관(CA)이 발급한 디지털 인증서 중 유효기간이 만료되기 전에 폐지된 인증서의 일련번호 목록이다. 인증서가 도난당하거나, 개인키가 유출되었거나, 소유자의 상태가 변경되는 등 다양한 이유로 인증서를 더 이상 신뢰할 수 없게 되면, CA는 해당 인증서를 폐기한다. CRL은 이러한 폐기된 인증서 정보를 주기적으로 갱신하여 공개하는 메커니즘이다.

CRL의 기본 구조는 X.509 표준에 정의되어 있으며, 일반적으로 다음 정보를 포함한다.

클라이언트(예: 웹 브라우저 또는 서버)는 상대방의 인증서를 검증할 때, 해당 인증서의 일련번호가 최신 CRL 목록에 등재되어 있는지 확인한다. 목록에 있다면 그 인증서는 유효하지 않은 것으로 판단하고 연결을 거부하거나 경고를 발생시킨다. CRL은 일반적으로 인증기관의 웹사이트나 LDAP 디렉토리와 같은 공개된 저장소에 배포된다.

CRL 방식은 몇 가지 한계점을 지닌다. 가장 큰 문제는 갱신 주기로 인한 정보의 지연이다. CA가 CRL을 하루에 한 번 발행한다면, 그 사이에 폐기된 인증서는 즉시 반영되지 않는다. 또한, CRL 파일의 크기가 커질수록 다운로드와 처리에 부담이 된다. 이러한 단점을 보완하기 위해 실시간 검증 프로토콜인 OCSP(Online Certificate Status Protocol)가 개발되어 함께 사용된다. OCSP는 특정 인증서의 상태만을 실시간으로 질의할 수 있지만, CA 서버에 부하를 주고 가용성 문제를 야기할 수 있다. 따라서 많은 시스템은 CRL과 OCSP를 상호보완적으로 활용한다.

공개키 암호화 시스템의 핵심은 한 쌍으로 생성되는 공개키와 개인키이다. 이 두 키는 수학적으로 밀접하게 연관되어 있지만, 한 키로 암호화한 내용은 반드시 짝이 되는 다른 키로만 복호화할 수 있다. 공개키는 이름 그대로 공개되어 누구나 알 수 있는 키이며, 개인키는 소유자만이 비밀로 보관해야 하는 키이다.

이 키 쌍의 가장 중요한 특성은 비대칭성이다. 공개키로 암호화한 데이터는 오직 해당 개인키로만 복호화할 수 있다. 반대로, 개인키로 서명한 데이터는 해당 공개키를 사용하여 서명의 진위를 검증할 수 있다. 이 원리는 디피-헬먼 키 교환과 RSA 암호 같은 알고리즘을 기반으로 한다[2].

공개키와 개인키의 역할은 다음과 같이 구분된다.

개인키의 비밀 유지는 절대적이다. 개인키가 유출되면 해당 키 쌍에 연결된 모든 디지털 신원과 보안이 무너진다. 따라서 개인키는 하드웨어 보안 모듈 같은 안전한 장치에 저장되는 경우가 많다. 반면 공개키는 자유롭게 배포되며, 디지털 인증서라는 형태로 패키징되어 신원 정보와 함께 공개된다.

디지털 서명은 공개키 암호화 기술을 활용하여 전자 문서의 무결성, 인증, 부인 방지를 보장하는 메커니즘이다. 송신자의 개인키로 데이터를 암호화(서명)하고, 수신자는 해당 송신자의 공개키로 이를 복호화(검증)하여 서명의 진위를 확인한다.

일반적인 디지털 서명 생성 및 검증 과정은 다음과 같은 단계를 거친다.

1. 송신자는 원본 문서에 해시 함수를 적용하여 고정된 길이의 메시지 다이제스트를 생성한다.

2. 생성된 다이제스트를 송신자의 개인키로 암호화한다. 이 암호화된 결과물이 바로 디지털 서명이다.

3. 송신자는 원본 문서와 디지털 서명을 수신자에게 함께 전송한다.

4. 수신자는 수신한 원본 문서에 동일한 해시 함수를 적용하여 새로운 메시지 다이제스트를 계산한다.

5. 수신자는 송신자의 공개키를 사용해 전달받은 디지털 서명을 복호화하여 원래의 메시지 다이제스트를 얻는다.

6. 수신자가 계산한 다이제스트와 서명에서 복호화한 다이제스트를 비교한다. 두 값이 일치하면 문서가 전송 중 변경되지 않았음(무결성)과 서명자가 개인키 소유자임(인증)이 증명되며, 송신자는 이후 서명 사실을 부인할 수 없다(부인 방지).

디지털 서명은 다양한 보안 응용 분야의 핵심 요소로 작동한다. SSL/TLS 인증서의 유효성 검사, 소프트웨어 배포 시 코드 서명을 통한 출처 및 변조 여부 확인, 전자 문서 및 전자 메일(S/MIME)의 법적 효력 부여 등에 광범위하게 사용된다. 이는 수기 서명의 전자적 대응물로서, 현대 사이버 보안과 전자 상거래의 신뢰 체계를 구성하는 근간이 된다.

키 교환은 두 당사자가 안전하지 않은 공개 채널을 통해 비밀 대칭키를 공유할 수 있게 해주는 공개키 암호화의 핵심 응용 분야이다. 이 과정을 통해 생성된 공유 비밀키는 이후 대칭키 암호 방식으로 실제 데이터를 암호화하는 데 사용된다. 가장 유명한 키 교환 프로토콜은 디피-헬먼 키 교환이다.

디피-헬먼 키 교환은 두 당사자가 각자의 개인키와 공통의 공개 파라미터(큰 소수와 원시근)를 사용하여 비밀값을 계산한다. 당사자들은 자신의 개인키와 상대방의 공개키를 결합하여 동일한 공유 비밀키를 도출한다. 이때, 개인키는 절대 공유되지 않으며, 중간에서 통신을 엿듣는 공격자는 공개된 정보만으로는 이 공유 비밀키를 계산하는 것이 계산상 불가능하다는 이산 로그 문제에 기반한 안전성을 가진다.

순수한 디피-헬먼 프로토콜은 상대방의 신원을 확인하지 않기 때문에 중간자 공격에 취약할 수 있다. 따라서 실제 응용에서는 PKI에서 발급받은 디지털 인증서를 이용해 당사자의 공개키에 대한 신원을 디지털 서명으로 검증하는 방식을 결합한다. 예를 들어, TLS 프로토콜에서는 서버의 인증서를 검증한 후, 그 서버의 공개키를 사용해 키 교환 메시지를 암호화하거나 서명을 확인하는 방식으로 안전한 키 교환을 수행한다.

X.509는 공개키 기반구조(PKI)에서 디지털 인증서의 형식, 내용, 구조를 정의하는 국제 표준이다. 국제전기통신연합(ITU-T)이 제정한 X.500 디렉터리 서비스 표준의 일부로 개발되었으며, 현재는 인터넷 기술 특별 위원회(IETF)의 PKIX(PKI for X.509) 워킹 그룹에 의해 인터넷 표준으로 관리되고 있다. 이 표준은 인증서의 발급, 취소, 검증 절차와 함께 인증서 내에 포함될 정보를 체계적으로 규정한다.

X.509 인증서의 핵심 구조는 ASN.1(Abstract Syntax Notation One) 형식으로 정의되며, 일반적으로 DER(Distinguished Encoding Rules) 인코딩을 통해 바이너리 형태로 저장되거나, PEM(Privacy-Enhanced Mail) 형식으로 Base64 인코딩되어 텍스트 파일로 배포된다. 하나의 X.509 인증서는 크게 다음 세 부분으로 구성된다[3].

표준은 버전을 거듭하며 확장되었다. 초기 X.509(v1)에는 기본 필드만 있었으나, v2에서는 발급자와 주체의 고유 식별자 필드가 추가되었고, 현재 가장 널리 사용되는 v3에서는 확장 필드가 도입되었다. 이 확장 필드를 통해 인증서의 용도(예: 서버 인증, 클라이언트 인증, 코드 서명), CRL(인증서 폐기 목록) 배포 지점, 주체 대체 이름(예: 하나의 인증서에 여러 도메인 이름 포함) 등 훨씬 더 풍부하고 유연한 정보를 담을 수 있게 되었다.

SSL/TLS 인증서는 웹 서버의 신원을 확인하고 클라이언트와 서버 간의 통신을 암호화하기 위해 사용되는 특별한 형태의 디지털 인증서이다. 이 인증서는 주로 HTTPS 프로토콜을 구현하는 데 활용되며, 웹 브라우저 주소창의 자물쇠 아이콘으로 표시된다. 인증서에는 서버의 공개키, 소유자 정보(일반적으로 도메인 이름), 발급 인증기관(CA) 정보, 유효기간 등이 포함되어 있다.

SSL/TLS 인증서는 검증 수준과 보장 범위에 따라 여러 종류로 나뉜다. 가장 기본적인 것은 도메인 소유권만을 검증하는 도메인 검증(DV) 인증서이다. 한 단계 위인 조직 검증(OV) 인증서는 도메인 소유권과 함께 조직의 법적 실체를 추가로 확인한다. 가장 높은 수준의 검증을 제공하는 확장 검증(EV) 인증서는 조직의 법적, 물리적 존재에 대한 철저한 심사를 거쳐 발급되며, 일부 브라우저에서는 주소창에 조직 이름을 직접 표시하기도 했다[4].

또한, 하나의 인증서로 여러 개의 도메인 또는 하위 도메인을 보호할 수 있는 와일드카드 인증서나 다중 도메인(SAN) 인증서도 널리 사용된다. 최근에는 Let's Encrypt와 같은 공공 인증기관이 무료로 DV 인증서를 자동화하여 발급함으로써 웹 전반의 암호화 보급을 크게 촉진시켰다.

코드 서명 인증서는 소프트웨어 개발자나 배포자의 신원을 확인하고, 배포되는 코드나 실행 파일의 무결성과 출처를 보장하는 데 사용되는 특수한 디지털 인증서이다. 이 인증서를 이용해 생성된 디지털 서명은 해당 소프트웨어가 배포 과정에서 변조되거나 악성 코드가 삽입되지 않았음을 사용자에게 증명한다. 주요 운영체제와 응용 프로그램은 코드 서명을 검증하여 알 수 없는 출처의 소프트웨어 실행에 대한 경고를 표시하거나 실행을 차단할 수 있다.

코드 서명의 일반적인 절차는 다음과 같다. 먼저, 개발자는 신뢰할 수 있는 인증기관(CA)으로부터 코드 서명용 인증서를 발급받는다. 소프트웨어를 배포하기 전에, 개발자는 해당 코드의 해시 값을 생성하고 자신의 개인키로 이 해시 값에 서명하여 코드 서명 블록을 생성한다. 최종 사용자가 소프트웨어를 설치 또는 실행하려고 하면, 시스템은 첨부된 서명을 개발자의 공개키로 검증하고, 코드의 해시 값을 다시 계산하여 비교한다. 이 과정을 통해 코드가 서명된 이후 변경되지 않았고, 서명한 개발자 본인이 배포한 것임을 확인할 수 있다.

주요 사용 사례는 다음과 같다.

코드 서명 인증서의 유효 기간이 만료되거나 해당 개인키가 유출된 경우, 개발자는 인증기관을 통해 인증서를 폐지해야 한다. 시스템은 인증서 폐기 목록(CRL) 또는 OCSP(온라인 인증서 상태 프로토콜)을 통해 인증서의 상태를 확인한다. 서명 시점 타임스탬프를 추가하면, 인증서가 만료된 후에도 서명 당시에는 유효한 인증서로 생성되었음을 증명할 수 있어 소프트웨어의 장기적인 유효성을 보장한다[5].

단일 CA 계층 구조는 PKI에서 가장 기본적이고 널리 사용되는 신뢰 모델이다. 이 모델은 하나의 최상위 인증기관(루트 CA)이 존재하며, 이 루트 CA가 하위 CA들을 인증하는 계층적 트리 구조를 형성한다. 루트 CA는 스스로 자신의 신뢰성을 보증하며, 그 공개키는 시스템이나 응용 프로그램에 미리 내장(Trust Anchor)되어 배포된다. 모든 최종 사용자 인증서의 신뢰 체인은 결국 이 루트 CA로 수렴된다.

이 구조에서 신뢰는 상위에서 하위로 흐른다. 루트 CA는 중간 CA(또는 발급 CA)의 인증서에 서명하여 그 신원과 공개키의 유효성을 보증한다. 중간 CA는 다시 최종 사용자(예: 웹 서버, 개인)의 인증서에 서명한다. 클라이언트는 인증서를 검증할 때, 최종 인증서부터 시작하여 서명 체인을 따라 올라가 루트 CA의 공개키로 서명이 유효한지 확인한다. 이 과정을 통해 루트 CA를 신뢰하는 모든 주체는 그 하위에 있는 모든 인증서를 간접적으로 신뢰할 수 있게 된다.

단일 CA 계층 구조의 주요 장점은 관리의 단순성과 명확한 책임 소재에 있다. 신뢰의 근원이 하나이므로 정책 수립과 인증서 발급 절차를 통일적으로 관리하기 쉽다. 또한, 인증서 폐기와 같은 운영상의 변경 사항이 계층을 따라 효율적으로 전파될 수 있다. 그러나 단점으로는 단일 실패점(Single Point of Failure)의 위험이 있다. 루트 CA의 개인키가 유출되거나 CA 자체가 신뢰를 잃으면, 해당 계층 아래의 모든 인증서의 신뢰도가 근본적으로 훼손될 수 있다.

이 모델을 운영할 때는 루트 CA의 보안을 극대화하는 것이 필수적이다. 일반적으로 루트 CA는 오프라인 상태로 유지하여 직접적인 네트워크 공격으로부터 보호하며, 실제 인증서 발급 업무는 온라인 중간 CA들이 담당한다. 이는 보안과 실용성을 절충한 일반적인 운영 방식이다.

교차 인증은 서로 다른 두 개의 인증기관 간에 신뢰 관계를 수립하는 과정이다. 이는 각 CA가 발급한 디지털 인증서를 상대방의 사용자나 시스템이 신뢰할 수 있도록 만든다. 일반적으로 독립적인 PKI 도메인(예: 서로 다른 조직, 국가, 또는 특정 커뮤니티)을 연결할 때 사용된다.

교차 인증을 구현하는 주요 방법은 두 CA가 서로를 상대방의 사용자처럼 간주하고 교차 인증서를 발급하는 것이다. 즉, CA A가 CA B의 공개키에 대해 서명한 인증서를 발급하고, 반대로 CA B도 CA A의 공개키에 대해 서명한 인증서를 발급한다. 이를 통해 양측 PKI 사용자들은 상대방 CA의 인증서 체인을 자신의 신뢰 앵커를 통해 검증할 수 있게 된다.

교차 인증의 구조는 크게 두 가지 모델로 나뉜다. 일대일 양방향 교차 인증은 앞서 설명한 대로 두 CA가 서로를 동등하게 신뢰하는 관계를 구축한다. 반면, 계층적 교차 인증은 한 CA가 다른 CA의 상위 CA 역할을 하거나, 양측이 모두 제3의 상위 CA를 공통 신뢰 앵커로 사용하는 형태이다. 이는 복잡한 신뢰 체인을 관리하는 데 유용하다.

교차 인증은 조직 간 협업이나 정부 기관 간 전자 문서 교환과 같은 시나리오에서 폐쇄적인 PKI 시스템을 개방적으로 연결하는 핵심 수단이다. 그러나 교차 인증 관계가 증가하면 신뢰 경로가 복잡해지고, 한 CA의 보안 침해가 연결된 모든 PKI 도메인으로 전파될 수 있는 위험도 함께 관리해야 한다[7].

웹 신뢰 모델은 월드 와이드 웹 환경에서 공개키 기반구조의 신뢰가 확립되는 방식을 설명한다. 이 모델의 핵심은 웹 브라우저와 운영체제에 미리 내장된, 신뢰할 수 있는 루트 인증기관 목록이다. 사용자가 HTTPS를 사용하는 웹사이트에 접속하면, 브라우저는 해당 사이트의 서버 인증서를 검증한다. 이 검증 과정은 서버 인증서의 발급 경로를 트레이스하여 최종적으로 사용자 장치에 내장된 신뢰할 수 있는 루트 CA의 서명이 있는지 확인하는 방식으로 이루어진다.

이 모델은 중앙 집중식 신뢰 체계를 기반으로 한다. 주요 상용 인증기관들은 자신들의 루트 인증서를 마이크로소프트, 구글, 애플, 모질라와 같은 주요 소프트웨어 벤더에게 제출하여 해당 회사의 브라우저나 운영체제의 '신뢰할 수 있는 루트 인증서 저장소'에 포함되도록 한다. 이 과정은 매우 엄격한 감사와 기준을 통과해야 한다. 일단 포함되면, 해당 CA가 발급한 모든 인증서는 사용자 측에서 추가 조치 없이 자동으로 신뢰받게 된다.

웹 신뢰 모델은 다음과 같은 특징을 가진다.

이 모델의 주요 취약점은 신뢰의 사슬이 가장 약한 고리에서 끊어질 수 있다는 점이다. 만약 내장된 루트 CA 중 하나가 해커에 의해 침해되거나, 부실한 관행으로 잘못된 인증서를 발급한다면, 전체 시스템의 신뢰가 훼손될 수 있다. 이러한 사건은 과거에 여러 차례 발생했으며, 이에 대한 대응으로 인증서 투명성과 같은 보완 기술이 도입되었다. 인증서 투명성은 모든 SSL/TLS 인증서의 발급 내역을 공개 로그에 기록하여 불법적이거나 오류가 있는 인증서 발급을 감시하고 탐지할 수 있게 한다.

HTTPS는 HTTP 프로토콜에 전송 계층 보안(TLS) 또는 그 전신인 SSL 프로토콜을 결합한 보안 통신 프로토콜이다. 이 프로토콜의 핵심은 PKI가 제공하는 디지털 인증서를 통해 서버의 신원을 확인하고, 클라이언트와 서버 간의 통신을 암호화하는 것이다. 사용자가 HTTPS로 보호된 웹사이트에 접속하면, 브라우저는 서버로부터 제공받은 인증서를 검증한다. 이 검증 과정에는 인증서가 신뢰할 수 있는 인증기관(CA)에 의해 발급되었는지, 유효 기간이 지나지 않았는지, 그리고 접속하려는 도메인 이름과 인증서 내의 도메인이 일치하는지 확인하는 작업이 포함된다. 검증이 성공하면, 브라우저는 서버의 공개키를 안전하게 획득하게 되고, 이를 기반으로 대칭 암호화 키를 교환하여 이후 모든 데이터 통신을 암호화한다.

HTTPS의 주요 보안 목표는 세 가지이다. 첫째는 기밀성으로, 암호화를 통해 제3자가 통신 내용을 도청하더라도 해독할 수 없게 만든다. 둘째는 무결성으로, 메시지 인증 코드(MAC) 등을 통해 전송 중 데이터가 변조되거나 손상되지 않았음을 보장한다. 셋째는 인증으로, 서버가 자신이 주장하는 정당한 소유자임을 디지털 서명을 통해 증명한다. 이 인증은 피싱 사이트와 같은 위장된 서버로부터 사용자를 보호하는 데 결정적인 역할을 한다.

현대 웹에서 HTTPS의 적용은 필수적이다. 모든 주요 웹 브라우저는 HTTPS를 사용하지 않는 사이트에 대해 '안전하지 않음' 경고를 표시한다[9]. 또한 검색 엔진 최적화(SEO) 랭킹에서 HTTPS는 긍정적인 신호로 작용한다. HTTP/2 및 HTTP/3와 같은 최신 프로토콜의 기능 대부분도 HTTPS 위에서만 동작하도록 설계되었다. 이는 암호화되지 않은 평문 통신이 개인정보 노출, 세션 하이재킹, 중간자 공격 등에 취약하기 때문이다.

HTTPS 구현을 위해 웹사이트 운영자는 인증기관으로부터 도메인 검증(DV), 조직 검증(OV), 확장 검증(EV) 등 다양한 수준의 SSL/TLS 인증서를 발급받는다. 최근에는 Let's Encrypt와 같은 무료 자동화된 CA의 등장으로 HTTPS의 보급 장벽이 크게 낮아졌다. 결과적으로, 전자상거래와 금융 거래뿐만 아니라 일반적인 정보 제공 사이트, 블로그에 이르기까지 웹 전반에 걸쳐 HTTPS가 표준 프로토콜로 자리 잡았다.

PKI는 전자문서와 이메일의 기밀성, 무결성, 부인 방지 및 인증을 보장하는 핵심 기술로 활용된다. 디지털 서명과 공개키 암호화를 기반으로 하여, 종이 문서의 서명과 봉인에 상응하는 디지털 기능을 제공한다.

전자문서 보안에서 PKI는 문서의 작성자를 확인하고(인증), 문서가 전송 중 변경되지 않았음을 증명하며(무결성), 서명자가 나중에 서명 사실을 부인할 수 없게 한다(부인 방지). 이는 전자계약, 전자납품, 전자세금신고 등 법적 효력이 필요한 다양한 비즈니스와 행정 절차에서 필수적이다. 예를 들어, 공인인증서(구)*는 한국에서 오랫동안 공공기관 전자문서 제출에 사용된 대표적인 PKI 기반 기술이었다[10].

이메일 보안 분야에서는 S/MIME 표준이 PKI를 활용한다. 발신자는 자신의 개인키로 이메일에 디지털 서명하여 신원을 증명하고, 수신자의 공개키로 메일 내용을 암호화하여 기밀성을 유지한다. 이를 통해 피싱 메일이나 스푸핑 공격을 방지하고, 중요한 정보가 담긴 이메일을 안전하게 주고받을 수 있다. 주요 이메일 클라이언트 소프트웨어들은 대부분 S/MIME 기능을 지원한다.

PKI는 네트워크에 접근하려는 사용자나 디바이스의 신원을 확인하고, 그에 따른 접근 권한을 부여하는 네트워크 접근 제어 시스템의 핵심 기술로 활용된다. 이는 유선 또는 무선 네트워크 환경에서 인가되지 않은 접근을 차단하고, 보안 정책을 효과적으로 적용하는 데 기여한다.

주요 구현 방식으로는 802.1X 표준 기반의 인증이 있다. 이 방식에서는 접근을 시도하는 클라이언트(신청자), 네트워크 접근 장치(인증자), 그리고 RADIUS 서버와 같은 인증 서버가 협력하여 동작한다. 클라이언트는 서버에 제출할 디지털 인증서를 보유하고, 인증 서버는 신뢰할 수 있는 인증기관에 의해 발급된 인증서를 검증한다. 인증서 검증이 성공하면, 서버는 클라이언트의 신원을 확인하고 미리 정의된 정책에 따라 네트워크 접근을 허용하거나 특정 VLAN으로 할당한다.

이 기술은 기업 내부 네트워크, 캠퍼스 네트워크, 공공 와이파이 등 다양한 환경에 적용된다. 특히, 개인 디바이스의 기업망 접근(BYOD)이나 IoT 기기의 안전한 네트워크 등록을 관리하는 데 필수적이다. PKI 기반 인증은 단순한 아이디/비밀번호 방식보다 훨씬 강력한 보안을 제공하며, 인증서의 만료와 폐지를 통해 접근 권한을 동적으로 관리할 수 있는 장점이 있다.

인증서 생명주기 관리는 디지털 인증서가 생성, 배포, 사용, 갱신, 폐지, 만료에 이르기까지 전 과정을 체계적으로 관리하는 활동이다. 이는 PKI 시스템의 안정성과 신뢰성을 유지하는 핵심 절차이다. 생명주기는 일반적으로 크게 발급, 운영, 폐지의 세 단계로 구분된다.

발급 단계는 인증서의 시작점으로, 등록기관(RA)을 통해 신원 확인이 이루어진 후 인증기관(CA)이 인증서를 생성하고 서명한다. 운영 단계에서는 발급된 인증서가 실제 서비스나 통신에 사용되며, 이 기간 동안 인증서의 상태를 지속적으로 모니터링한다. 폐지 단계는 인증서가 만료되기 전에 키가 유출되거나 소유자의 상태가 변경되는 등 특정 사유로 인해 사용을 중단해야 할 때 진행된다. 이때 CA는 해당 인증서를 인증서 폐기 목록(CRL)에 등록하거나 OCSP(Online Certificate Status Protocol)를 통해 폐지 상태를 공개한다.

인증서 생명주기 관리를 효율적으로 수행하기 위해 자동화된 관리 시스템이 널리 사용된다. 이러한 시스템은 인증서 만료 일자를 사전에 감지하여 갱신 프로세스를 자동으로 시작하거나, 정책에 따라 인증서의 사용을 제한할 수 있다. 주요 관리 작업은 다음 표와 같다.

생명주기 관리의 궁극적 목표는 유효하지 않거나 위험한 인증서가 시스템에 남아있지 않도록 하는 것이다. 이를 위해 정기적인 감사와 인증 실무 선언문(CPS)에 명시된 정책의 이행이 필수적이다. 관리 부주의로 인한 만료 인증서의 방치는 서비스 중단을, 적절하지 않은 폐지 관리는 보안 위협을 초래할 수 있다.

PKI 운영에서 인증기관은 자신의 서비스와 책임 범위를 명확히 정의하기 위해 두 가지 핵심 문서를 발행한다. 바로 인증 정책(CP, Certificate Policy)과 인증 실무 선언문(CPS, Certification Practice Statement)이다. 이 두 문서는 PKI의 신뢰 기반을 공식화하고 운영의 투명성과 일관성을 보장하는 역할을 한다.

인증 정책은 특정 인증서 집합에 적용되는 규칙 세트를 정의한다. 이는 인증서가 발급되고 관리되며 사용되는 목적, 범위, 그리고 법적, 조직적, 기술적 요구사항을 기술한다. 예를 들어, 특정 CP는 "기업 간 전자 문서 교환" 또는 "서버 SSL/TLS 인증"과 같은 특정 응용 분야를 위한 인증서에 적용된다. 반면, 인증 실무 선언문은 특정 인증기관이 인증 정책을 어떻게 구체적으로 준수하며 운영하는지에 대한 상세한 절차와 실행 방법을 기술한 문서이다. CPS는 인증서의 신청, 검증, 발급, 갱신, 폐지, 보관 등 전 생명주기에 걸친 구체적인 운영 절차, 보안 통제, 기술 표준, 감사 요건 등을 포함한다.

간단히 말해, 인증 정책은 "무엇을" 해야 하는지(규칙과 요구사항)를 정의하고, 인증 실무 선언문은 "어떻게" 그것을 수행하는지(구체적인 운영 절차)를 설명한다. 하나의 인증 정책을 여러 인증기관이 따를 수 있으며, 각 인증기관은 자신의 운영 환경에 맞는 고유한 CPS를 작성한다. 이 두 문서의 관계는 아래 표를 통해 명확히 구분할 수 있다.

이 문서들은 인증서 사용자(의존 당사자)가 해당 PKI의 신뢰 수준과 운영 방식을 평가할 수 있는 근거를 제공한다. 또한, 서로 다른 인증기관 간의 교차 인증을 논의할 때 상대방의 CP와 CPS를 검토하여 정책과 운영의 호환성을 판단하는 기준이 된다. 국제 표준인 X.509와 RFC 3647은 이러한 문서의 작성 가이드라인을 제시한다.

인증서 위변조는 공격자가 합법적인 디지털 인증서를 변조하거나, 도난당한 개인키를 이용해 위조 인증서를 생성하는 행위를 말한다. 이러한 인증서는 공격자가 합법적인 웹사이트나 서비스인 것처럼 위장하여 피싱 공격을 수행하거나, 중간자 공격을 통해 통신 내용을 탈취 및 변조하는 데 악용될 수 있다. 인증서 도용은 주로 인증기관의 시스템 침해, 소프트웨어 취약점 악용, 또는 사용자 시스템에서의 키 유출을 통해 발생한다.

공격 유형은 다음과 같이 구분된다.

이러한 위협에 대응하기 위해 인증서 투명성 로그, OCSP 스테이플링, 키 고정 등의 기술이 도입되었다. 인증서 투명성은 모든 발급된 SSL/TLS 인증서를 공개 로그에 기록하여 불법적으로 발급된 인증서를 탐지할 수 있게 한다. 또한, 인증서 폐기 목록과 온라인 인증서 상태 프로토콜을 적극적으로 활용하여 유효하지 않게 된 인증서를 신속히 확인하는 것이 중요하다.

인증기관의 신뢰성은 전체 공개키 기반구조 체계의 근간을 이룬다. CA는 디지털 인증서를 발급하고, 해당 인증서에 서명함으로써 인증서 내 공개키와 주체 정보의 유효성을 보증하는 제3의 신뢰 기관 역할을 한다. 따라서 CA 자체의 운영 보안과 정책 준수는 절대적이다. 만약 CA의 개인키가 유출되거나, CA가 악의적이거나 부실한 검증 절차를 통해 인증서를 발급한다면, 공격자는 합법적인 것처럼 위조된 인증서를 생성하여 피싱 사이트 구축이나 중간자 공격에 활용할 수 있다.

역사적으로 주요 CA의 보안 침해 사례는 여러 차례 발생했다. 예를 들어, 2011년 네덜란드의 DigiNotar CA가 해킹되어 수백 개의 위조 SSL/TLS 인증서가 발급된 사건은 구글, 야후, 모질라 등 주요 도메인을 대상으로 한 대규모 감시 공격으로 이어졌다[12]. 이는 단일 CA의 취약점이 전 세계 수많은 사용자와 시스템의 보안을 위협할 수 있음을 보여주는 대표적 사례이다.

CA 신뢰 모델의 근본적 문제점 중 하나는 '모든 것이 루트 CA를 신뢰하는 데 기반한다'는 것이다. 대부분의 운영체제와 웹 브라우저는 사전 설치된 루트 CA 인증서 목록을 포함하는데, 이 목록에 등록된 수백 개의 CA 중 어느 하나라도 문제를 일으키면 전체 시스템의 신뢰 체계가 흔들린다. 이러한 중앙집중적 신뢰 모델의 위험을 완화하기 위해 인증서 투명성 로그, 다중 서명, 그리고 자체 서명 인증서 기반의 분산 신원 시스템 등 대안적 기술과 정책이 제시되고 있다.