공개 키 기반 구조
1. 개요
1. 개요
공개 키 기반 구조(Public Key Infrastructure, PKI)는 공개 키 암호화 기술을 사용하여 네트워크 상에서 신원 확인(인증), 데이터 암호화, 디지털 서명 등의 보안 서비스를 제공하는 일련의 정책, 하드웨어, 소프트웨어 및 절차의 프레임워크이다. 이 구조는 디지털 세계에서 신뢰할 수 있는 제3자인 인증 기관(CA)을 중심으로 작동하며, 개인과 기기의 디지털 신원을 증명하는 디지털 인증서를 발급하고 관리하는 역할을 한다.
PKI의 핵심 목표는 공개된 네트워크 환경에서도 안전한 통신과 거래를 가능하게 하는 것이다. 이를 위해 각 사용자는 공개적으로 알려져도 무방한 공개 키와 비밀로 보관해야 하는 개인 키로 구성된 비대칭 키 쌍을 생성한다. PKI는 이 공개 키가 특정 주체(예: 개인, 서버, 조직)에 확실히 속해 있음을 보증하는 체계를 제공한다. 예를 들어, 웹사이트에 접속할 때 브라우저가 확인하는 SSL/TLS 인증서는 PKI가 적용된 대표적인 사례이다.
이 구조는 일반적으로 몇 가지 핵심 구성 요소로 이루어진다. 인증 기관(CA)은 인증서를 발급하고 서명하는 최상위 신뢰 기관이다. 등록 기관(RA)은 CA를 대신하여 인증서 발급 요청자의 신원을 검증한다. 발급된 인증서는 인증서 저장소에 공개적으로 게시되며, 폐기된 인증서 정보는 인증서 폐기 목록(CRL)이나 온라인 상태 검증 프로토콜을 통해 관리된다. 이러한 구성 요소들이 협력하여 디지털 신뢰의 기반을 형성한다.
PKI는 현대 인터넷 보안의 근간을 이루며, HTTPS를 통한 웹 보안, S/MIME을 이용한 안전한 이메일, 소프트웨어 코드 서명, 가상 사설망(VPN) 접근 제어 등 다양한 분야에서 필수적으로 활용된다. 또한, 운영 모델에 따라 모든 사용자에게 공개된 공개 PKI와 조직 내부에서만 사용되는 사설 PKI(Private PKI)로 구분된다.
2. PKI의 기본 구성 요소
2. PKI의 기본 구성 요소
인증 기관은 공개 키 기반 구조의 핵심 구성 요소로, 디지털 인증서를 발급하고 관리하는 신뢰할 수 있는 제3자 기관이다. CA는 인증서 신청자의 신원을 확인한 후, 해당 신청자의 공개 키와 신원 정보를 자신의 개인 키로 서명하여 디지털 인증서를 생성하고 발급한다. 이 과정을 통해 CA는 인증서 소유자의 공개 키와 신원 간의 바인딩을 보증한다. 주요 CA의 공개 키는 웹 브라우저나 운영체제에 미리 내장된 '신뢰할 수 있는 루트 인증서' 형태로 배포되어 신뢰의 기초를 형성한다.
등록 기관은 CA와 최종 사용자 사이에서 중개 역할을 수행한다. RA는 인증서 발급을 요청하는 사용자의 신원 확인 작업을 직접 수행하고, 해당 정보를 CA에 전달하여 인증서 발급을 요청한다. RA는 인증서를 직접 발급하지 않지만, 사용자 등록, 신원 검증, 인증서 갱신 또는 폐지 요청을 처리하는 업무를 담당한다. 이는 대규모 공개 키 기반 구조 환경에서 CA의 부담을 분산시키고, 등록 절차를 효율화하는 데 기여한다.
인증서 저장소는 발급된 디지털 인증서와 인증서 폐기 목록을 저장하고 배포하는 공개된 디렉터리 서비스이다. 일반적으로 LDAP 디렉터리나 웹 서버를 통해 제공되며, 사용자와 응용 프로그램이 특정 공개 키나 인증서 정보를 쉽게 조회하고 검증할 수 있도록 한다.
인증서 폐기 목록은 유효 기간이 만료되기 전에 폐지된 인증서의 고유 일련번호 목록이다. 인증서의 개인 키가 유출되거나, 소속 기관이 변경되는 등 인증서를 더 이상 신뢰할 수 없게 되는 경우 CA는 해당 인증서를 CRL에 등록한다. 인증서 유효성을 검증하는 주체는 반드시 최신 CRL을 확인하여 인증서가 폐지되지 않았는지 확인해야 한다. CRL의 대안으로 실시간 상태 확인 프로토콜인 OCSP가 사용되기도 한다.
구성 요소 | 주요 역할 | 비고 |
|---|---|---|
디지털 인증서 발급 및 서명, 신뢰 앵커 제공 | 루트 CA와 중간 CA로 구분됨 | |
사용자 신원 검증 및 등록 관리, CA에 대한 요청 전달 | CA의 확장 역할 | |
인증서 저장소 | 발급된 인증서 및 CRL의 공개 저장 및 배포 | LDAP, HTTP 등을 통해 접근 |
폐지된 인증서 목록 게시로 유효성 검증 지원 | 주기적으로 갱신되며, OCSP가 대안으로 사용됨 |
2.1. 인증 기관 (CA)
2.1. 인증 기관 (CA)
인증 기관은 공개 키 기반 구조의 핵심 구성 요소로서, 디지털 세계에서 신원 확인과 신뢰의 근간을 제공하는 제3의 신뢰 기관이다. CA는 개인, 조직, 장치 등의 신원을 검증하고 해당 실체의 공개 키를 포함한 정보를 디지털 인증서에 담아 전자적으로 서명하여 발급한다. 이 서명은 CA의 개인 키로 생성되며, 인증서를 받은 실체의 신원이 CA에 의해 확인되었음을 보증한다. 사용자는 널리 알려진 CA의 공개 키를 통해 이 서명의 유효성을 검증할 수 있다.
CA의 주요 역할은 다음과 같다.
* 신원 검증: 인증서 발급을 요청하는 실체의 신원 정보(예: 도메인 소유권, 조직 등록 정보)를 정책에 따라 엄격하게 확인한다.
* 인증서 발급: 검증이 완료되면, 요청자의 공개 키, 신원 정보, 유효 기간 등을 담은 디지털 인증서를 생성하고 CA의 디지털 서명으로 감싸 발급한다.
* 인증서 관리: 발급된 인증서의 상태를 추적하고, 키가 손상되거나 정보가 변경되는 등 사유가 발생할 경우 해당 인증서를 인증서 폐기 목록에 등록하여 폐기한다.
CA는 신뢰 체계에서의 위치와 운영 범위에 따라 여러 유형으로 나뉜다. 최상위에 위치하여 자기 자신을 신뢰의 근원으로 서명하는 루트 인증 기관이 있으며, 이 루트 CA의 인증서는 주요 웹 브라우저와 운영체제에 미리 설치(신뢰 앵커)되어 있다. 루트 CA는 일반적으로 최종 사용자에게 직접 인증서를 발급하기보다는, 중간 CA를 인증하여 실제 발급 업무를 위임하는 계층적 구조를 형성한다.
CA의 신뢰성은 전체 PKI 생태계의 보안을 좌우한다. 만약 CA의 개인 키가 유출되거나 CA가 부적절하게 인증서를 발급하면, 공격자가 합법적인 사이트를 사칭하는 위조 인증서를 생성할 수 있어 중간자 공격 등 심각한 보안 위협으로 이어질 수 있다[1]. 따라서 CA는 물리적 보안, 키 생성 및 저장 절차, 운영 정책 등에서 매우 높은 수준의 보안 기준을 준수해야 한다.
2.2. 등록 기관 (RA)
2.2. 등록 기관 (RA)
등록 기관은 인증 기관의 업무 부담을 분산시키고, 인증서 발급 신청자의 신원 확인을 담당하는 엔터티이다. 인증 기관이 디지털 인증서를 생성하고 서명하는 핵심 역할을 한다면, 등록 기관은 그 전단계인 검증과 등록 절차를 처리한다.
등록 기관의 주요 업무는 인증서 발급을 요청하는 개인이나 조직의 신원을 확인하는 것이다. 여기에는 신청서 제출 자료의 검토, 신청자와의 직접 통신을 통한 확인, 필요한 경우 대면 확인 등이 포함된다. 또한, 등록 기관은 인증서 갱신, 재발급, 폐지 요청을 접수하고 검증하여 인증 기관에 전달하는 역할도 수행한다. 일부 모델에서는 등록 기관이 인증서 폐기 목록을 관리하거나 배포하는 작업에도 관여한다.
등록 기관과 인증 기관의 관계는 조직 구조에 따라 다르다. 인증 기관의 완전한 하위 기관으로 운영될 수도 있고, 독립된 제3자 기관이 계약을 통해 등록 기관의 기능을 제공할 수도 있다. 현대의 대규모 공개 키 기반 구조 환경에서는 인증 기관의 확장성과 효율성을 높이기 위해 등록 기관의 역할이 필수적이다.
2.3. 인증서 저장소
2.3. 인증서 저장소
인증서 저장소는 디지털 인증서와 해당 인증서의 개인 키 또는 공개 키를 안전하게 저장하고 관리하는 시스템 또는 저장소를 의미한다. 이 저장소는 PKI 환경에서 발급된 인증서의 생명주기 관리를 위한 핵심 인프라 중 하나로 작동한다.
주요 저장소 유형으로는 클라이언트 측 저장소와 서버 측 저장소가 있다. 클라이언트 측 저장소는 일반적으로 사용자의 컴퓨터나 스마트카드에 위치하며, 공개 키 기반 구조를 이용하는 응용 프로그램(예: 웹 브라우저, 이메일 클라이언트)이 접근한다. 대표적인 예로 마이크로소프트 윈도우의 '인증서 저장소'나 모질라 파이어폭스의 자체 인증서 관리자가 있다. 서버 측 저장소는 인증 기관이나 기업 내부에서 중앙 집중식으로 인증서를 관리할 때 사용된다.
인증서 저장소는 단순한 저장 기능을 넘어 다음과 같은 관리 기능을 제공한다.
기능 | 설명 |
|---|---|
저장 및 구성 | 발급받은 인증서와 키를 체계적으로 분류하여 저장한다. |
조회 및 검색 | 필요한 인증서를 빠르게 찾아 검증 과정에 제공한다. |
가져오기/내보내기 | 인증서와 키를 백업하거나 다른 시스템으로 이동시킨다. |
접근 제어 | 개인 키와 같은 민감한 정보에 대한 무단 접근을 방지한다. |
효율적인 인증서 저장소 관리는 PKI의 보안과 신뢰성을 유지하는 데 필수적이다. 저장소가 손상되거나 부적절하게 관리되면 개인 키 유출로 인한 디지털 서명 위조나 암호화 통신의 차단 등 심각한 보안 사고로 이어질 수 있다.
2.4. 인증서 폐기 목록 (CRL)
2.4. 인증서 폐기 목록 (CRL)
인증서 폐기 목록은 인증 기관이 발급한 디지털 인증서 중 유효기간이 만료되기 전에 폐지되어 더 이상 유효하지 않은 인증서의 고유 일련번호 목록이다. 주로 인증서의 개인 키가 유출되었거나, 소유자의 상태가 변경되었을 때 발행된다. CRL은 인증서를 사용하는 당사자(의뢰자)가 특정 인증서의 현재 유효성을 확인하는 데 필수적인 참조 자료 역할을 한다.
CRL은 주기적으로 갱신되며, 일반적으로 X.509 표준 형식을 따른다. 목록에는 각 폐기된 인증서의 일련번호, 폐기 일시, 폐기 사유 코드 등의 정보가 포함된다. 폐기 사유는 키 손상, CA 손상, 소속 변경, 증명서 대체, 운영 중지, 증명서 보유 등으로 구분된다[2]. 의뢰자는 TLS 핸드셰이크나 문서 서명 검증과 같은 과정에서 상대방의 인증서를 확인할 때, 해당 CA가 발행한 최신 CRL을 조회하여 인증서가 폐기되지 않았는지 검증해야 한다.
항목 | 설명 |
|---|---|
발행자 (Issuer) | |
이번 업데이트 일시 (This Update) | 이 CRL이 발행된 날짜와 시간 |
다음 업데이트 일시 (Next Update) | 다음 CRL이 발행될 것으로 예상되는 날짜와 시간 |
폐기된 인증서 목록 (Revoked Certificates) | 폐기된 각 인증서의 일련번호, 폐기 일시, 폐기 사유를 나열한 목록 |
CRL 방식은 몇 가지 단점을 가지고 있다. 가장 큰 문제는 목록의 크기가 시간이 지남에 따라 계속 커져 관리 부담이 생길 수 있다는 점이다. 또한, CRL이 캐시되거나 다음 업데이트 주기 전까지는 새로 폐기된 인증서를 즉시 반영하지 못할 수 있는 '유예 기간' 문제가 있다. 이러한 한계를 보완하기 위해 온라인 인증서 상태 프로토콜 같은 대체 수단이 개발되었다.
3. 공개 키 암호화 원리
3. 공개 키 암호화 원리
공개 키 암호화는 하나의 키 쌍, 즉 공개 키와 개인 키를 사용하는 비대칭 암호화 방식을 기반으로 한다. 이 두 키는 수학적으로 연관되어 있지만, 한 키로 암호화한 내용은 반드시 쌍을 이루는 다른 키로만 복호화할 수 있다. 공개 키는 누구나 알 수 있도록 공개되며, 개인 키는 소유자만이 비밀로 보관한다. 이 원리는 기밀성, 무결성, 인증 및 부인 방지와 같은 정보 보안의 핵심 요구사항을 충족시키는 데 활용된다.
주요 기능은 크게 세 가지로 나눌 수 있다. 첫째는 기밀 통신을 위한 키 교환이다. 송신자는 수신자의 공개 키를 이용해 메시지를 암호화하여 전송하면, 수신자는 자신만이 가진 개인 키로 이를 복호화하여 읽을 수 있다. 둘째는 디지털 서명이다. 서명자는 자신의 개인 키로 메시지의 해시값을 암호화하여 서명을 생성한다. 수신자는 서명자의 공개 키로 이 서명을 복호화하여 원본 메시지의 해시값과 비교함으로써 메시지의 무결성과 발신자의 신원을 검증할 수 있다. 셋째는 키 교환 프로토콜(예: 디피-헬만 키 교환)을 통한 안전한 대칭 키 공유이다.
기능 | 사용되는 키 | 목적 |
|---|---|---|
암호화 (기밀성) | 수신자의 공개 키로 암호화 | 오직 수신자만이 자신의 개인 키로 내용을 읽을 수 있도록 보장 |
디지털 서명 (무결성/인증) | 송신자의 개인 키로 서명 생성 | 메시지 변조 방지 및 송신자 신원 확인 |
키 합의 (키 교환) | 각 당사자의 공개/개인 키 쌍 | 안전한 채널을 통해 대칭 암호화에 사용할 세션 키를 공유 |
이러한 비대칭 암호화의 수학적 기반은 큰 소수의 인수 분해 문제(예: RSA 암호)나 이산 로그 문제(예: 타원곡선 암호)와 같이 계산상 어려운 문제에 의존한다. 공개 키 암호화 원리는 공개 키 기반 구조의 근간이 되어, 디지털 인증서의 생성과 검증, 그리고 안전한 통신 채널 수립을 가능하게 한다.
3.1. 비대칭 키 쌍
3.1. 비대칭 키 쌍
비대칭 키 쌍은 공개 키 암호화의 핵심 요소로, 수학적으로 연결된 한 쌍의 암호화 키를 의미한다. 이 쌍은 공개 키와 개인 키로 구성되며, 두 키는 서로 다른 용도로 사용된다. 공개 키는 누구에게나 공개되어 암호화나 서명 검증에 사용되는 반면, 개인 키는 소유자만이 비밀로 보관하여 복호화나 서명 생성에 사용한다. 두 키는 수학적 관계를 가지고 있지만, 공개 키로부터 개인 키를 추론하는 것은 현실적으로 불가능한 것이 보안의 기본 전제이다.
비대칭 키 쌍의 동작 원리는 다음과 같이 요약할 수 있다.
용도 | 공개 키의 역할 | 개인 키의 역할 |
|---|---|---|
기밀성 보장 (암호화/복호화) | 데이터를 암호화하는 데 사용 | 암호화된 데이터를 복호화하는 데 사용 |
인증 및 무결성 보장 (디지털 서명) | 서명을 검증하는 데 사용 | 디지털 서명을 생성하는 데 사용 |
예를 들어, 앨리스가 밥에게 비밀 메시지를 보내고 싶다면, 밥의 공개 키로 메시지를 암호화한다. 암호화된 메시지는 밥의 개인 키를 가진 밥만이 복호화하여 읽을 수 있다. 반대로, 앨리스가 자신이 보낸 메시지임을 증명하고 싶다면 자신의 개인 키로 메시지에 서명을 생성한다. 수신자는 앨리스의 공개 키로 그 서명을 검증하여 발신자와 메시지의 무결성을 확인할 수 있다.
이 방식은 대칭 키 암호화의 근본적인 문제인 키 배포 문제를 해결한다. 대칭 키 방식에서는 암호화와 복호화에 같은 키를 사용하므로, 안전하게 키를 교환해야 하는 부담이 있다. 비대칭 키 쌍을 사용하면 공개 키는 자유롭게 배포할 수 있어, 사전에 비밀 키를 공유하지 않은 당사자 간에도 안전한 통신과 인증이 가능해진다. RSA, 타원곡선 암호(ECC), 디피-헬먼 키 교환 등이 대표적인 비대칭 키 알고리즘이다.
3.2. 디지털 서명
3.2. 디지털 서명
디지털 서명은 공개 키 암호화 기술을 활용하여 전자 문서의 진본성, 무결성, 부인 방지를 보장하는 전자적 서명 방식이다. 송신자의 개인 키로 서명을 생성하고, 수신자는 해당 송신자의 공개 키를 사용하여 그 서명을 검증한다.
디지털 서명의 생성과 검증 과정은 다음과 같다. 먼저, 서명 생성자는 원본 문서에 해시 함수를 적용하여 고정된 길이의 메시지 다이제스트를 생성한다. 이 다이제스트를 서명자의 개인 키로 암호화한 결과가 디지털 서명이 된다. 서명과 원본 문서는 함께 수신자에게 전송된다. 수신자는 송신자의 공개 키로 서명을 복호화하여 메시지 다이제스트 A를 얻고, 동일한 해시 함수를 수신한 원본 문서에 적용하여 메시지 다이제스트 B를 별도로 생성한다. A와 B가 일치하면, 문서가 전송 중 변경되지 않았고(무결성), 서명을 생성한 개인 키의 소유자에 의해 서명되었음(진본성)을 확인할 수 있다.
단계 | 행위자 | 수행 작업 | 목적 |
|---|---|---|---|
1. 서명 생성 | 송신자 | 문서의 해시값을 생성하고, 개인 키로 암호화 | 디지털 서명 생성 |
2. 전송 | 송신자 | 원본 문서와 디지털 서명을 함께 전송 | 데이터 발송 |
3. 검증 | 수신자 | 송신자의 공개 키로 서명을 복호화, 수신 문서의 해시값을 별도 계산 | 무결성 및 진본성 확인 |
이 기술은 단순히 문서에 서명하는 것을 넘어, 소프트웨어 배포 시 코드 변조 여부 확인, 전자 상거래 계약의 법적 효력 부여, 그리고 공개 키 기반 구조에서 디지털 인증서 자체에 서명하는 데 핵심적으로 사용된다. 디지털 서명은 수학적 원리에 기반하므로, 서명자의 개인 키가 안전하게 보호된다는 전제 하에 위조나 부인을 사실상 불가능하게 만든다.
3.3. 키 교환
3.3. 키 교환
키 교환은 공개 키 암호화를 이용하여 두 당사자가 보안이 취약한 공개 채널을 통해 대칭 키를 안전하게 공유하는 과정이다. 이렇게 교환된 대칭 키는 이후 대량의 데이터를 효율적으로 암호화하는 데 사용된다. 가장 대표적인 키 교환 프로토콜은 디피-헬만 키 교환이다.
디피-헬만 키 교환은 각 당사자가 자신의 비밀 키와 상대방의 공개 키를 사용하여 동일한 공유 비밀 값을 계산하는 수학적 원리에 기반한다. 이 과정에서 실제 비밀 키는 네트워크를 통해 전송되지 않으며, 공개 채널에서 교환되는 정보만으로는 공유 비밀 값을 계산하기 어렵다는 이산 로그 문제에 보안이 의존한다[3].
교환 단계 | 당사자 A의 동작 | 당사자 B의 동작 | 공개 채널을 통해 교환되는 정보 |
|---|---|---|---|
1. 매개변수 합의 | 공개 소수 | 동일한 | 소수 |
2. 공개 값 생성 | 비밀 정수 | 비밀 정수 | A의 공개값 |
3. 공유 비밀 계산 | 수신한 | 수신한 | 없음 (각자 독립적으로 계산) |
이 결과, 양측은 동일한 공유 비밀 값 s를 얻게 되며, 이를 기반으로 AES나 3DES와 같은 대칭 키 암호의 세션 키를 유도한다. 디피-헬만 자체는 인증을 제공하지 않으므로, PKI의 디지털 인증서와 결합된 ECDH(타원 곡선 디피-헬만) 등의 변형이 TLS와 같은 현대 보안 프로토콜에서 널리 사용된다.
4. 디지털 인증서
4. 디지털 인증서
디지털 인증서는 공개 키 암호화 시스템에서 특정 개체(사용자, 장치, 서버 등)의 신원과 그에 연결된 공개 키를 바인딩하는 전자 문서이다. 이 인증서는 신뢰할 수 있는 제삼자인 인증 기관이 서명하여 발급하며, 인증서 소유자의 신원을 확인하고 해당 공개 키의 소유권을 보증하는 역할을 한다. 인증서의 주요 목적은 통신 상대방의 공개 키를 안전하게 획득하고 그 진위를 검증할 수 있도록 하는 것이다.
가장 널리 사용되는 디지털 인증서 형식은 X.509 표준을 따른다. X.509 인증서는 다음과 같은 핵심 정보를 포함한다.
필드 | 설명 |
|---|---|
주체 (Subject) | 인증서 소유자의 식별 정보 (예: 일반 이름, 조직) |
발급자 (Issuer) | 인증서를 발급한 인증 기관의 정보 |
공개 키 (Public Key) | 주체의 공개 키 |
유효 기간 (Validity Period) | 인증서가 유효한 시작일과 만료일 |
디지털 서명 (Digital Signature) | 발급 기관의 디지털 서명 |
여러 개의 디지털 인증서는 서로 연결되어 인증서 체인을 형성하며, 이는 신뢰 계층 구조의 기반이 된다. 최상위에는 최상위 인증 기관 또는 루트 인증 기관의 자체 서명된 인증서가 위치한다. 중간 인증 기관의 인증서는 상위 기관에 의해 서명되고, 최종 사용자나 서버의 인증서(리프 인증서)는 중간 인증 기관에 의해 서명된다. 클라이언트는 미리 내장된 루트 인증 기관 인증서를 신뢰하고, 이를 출발점으로 하여 체인을 따라 검증함으로써 최종 인증서의 유효성을 확인한다.
인증서의 유효성은 만료 날짜 확인 외에도 인증서 폐기 목록이나 온라인 인증서 상태 프로토콜을 통해 폐기 상태를 조회해야 완전히 검증된다. 또한, 인증서는 전자 서명, 키 교환, 데이터 암호화 등 다양한 용도로 사용될 수 있으며, 인증서 내의 확장 필드를 통해 그 용도가 제한될 수 있다.
4.1. 인증서 형식 (예: X.509)
4.1. 인증서 형식 (예: X.509)
디지털 인증서는 표준화된 형식으로 구조화되어 상호 운용성을 보장한다. 가장 널리 채택된 형식은 ITU-T의 X.509 표준이다. X.509 인증서는 ASN.1 표기법을 사용하여 정의되며, 일반적으로 DER 인코딩된 바이너리 형식으로 저장되거나, Base64로 인코딩되어 .pem 또는 .cer 확장자를 가진 텍스트 파일로 배포된다.
X.509 인증서의 핵심 구조는 몇 가지 필수 필드로 구성된다. 다음은 주요 필드와 그 내용을 보여주는 표이다.
필드 | 설명 |
|---|---|
버전 (Version) | 인증서의 X.509 버전 번호 (예: v3) |
일련번호 (Serial Number) | 발행 인증 기관이 부여한 고유 식별자 |
서명 알고리즘 (Signature Algorithm) | 인증서 서명에 사용된 알고리즘 (예: sha256WithRSAEncryption) |
발행자 (Issuer) | |
유효기간 (Validity) | 인증서가 유효한 시작일과 종료일 |
주체 (Subject) | 인증서 소유자(공개 키의 주인)의 고유 이름 |
주체 공개 키 정보 (Subject Public Key Info) | 소유자의 공개 키와 사용된 알고리즘 |
확장 영역 (Extensions) | v3 인증서에서 추가 정보를 제공하는 필드[4] |
버전 3 (X.509v3)은 확장 영역을 도입하여 인증서의 기능과 유연성을 크게 향상시켰다. 확장 필드를 통해 인증서의 용도를 구체적으로 제한하거나(키 사용 확장), 주체의 이메일 주소나 DNS 이름과 같은 대체 식별자를 포함하거나(주체 대체 이름 확장), 인증서 폐기 목록의 위치를 명시하는 것이 가능해졌다. 이 표준화된 형식 덕분에 다양한 운영 체제, 웹 브라우저, 응용 프로그램이 동일한 인증서를 일관되게 해석하고 검증할 수 있다.
4.2. 인증서 체인과 신뢰 계층
4.2. 인증서 체인과 신뢰 계층
인증서 체인은 여러 계층의 디지털 인증서가 연결되어 최종 사용자 인증서의 유효성을 검증하는 신뢰 구조이다. 최상위에는 루트 인증 기관의 자체 서명된 인증서가 위치하며, 이는 모든 신뢰의 근원이 된다. 루트 CA는 중간 인증 기관의 인증서에 서명하고, 중간 CA는 다시 최종 엔티티(웹 서버, 사용자 등)의 인증서에 서명한다. 이렇게 연결된 인증서들의 순차적 목록을 인증서 체인 또는 신뢰 체인이라고 부른다.
신뢰 계층은 이러한 위계적 구조를 통해 신뢰를 확장하는 방식을 의미한다. 클라이언트(예: 웹 브라우저)는 사전에 내장된 루트 CA 인증서 목록을 신뢰한다. 검증 과정에서 클라이언트는 서버로부터 받은 인증서 체인을 따라 올라가, 체인 상의 모든 인증서 서명이 유효하고 최종적으로 신뢰하는 루트 CA에 도달할 때까지 확인한다. 이 구조는 루트 CA의 개인 키를 오프라인으로 안전하게 보호하면서도 대량의 인증서 발급 업무를 중간 CA에 위임할 수 있게 해준다.
인증서 체인의 일반적인 구성은 다음과 같다.
계층 | 역할 | 설명 |
|---|---|---|
루트 CA | 신뢰의 최상위 앵커 | 자체 서명된 인증서를 가지며, 그 공개 키가 클라이언트에 신뢰할 수 있는 것으로 미리 설치된다. |
중간 CA | 인증서 발급 위임 | 루트 CA에 의해 서명받고, 최종 엔티티 인증서 발급을 담당한다. 보안 강화를 위해 여러 계층이 존재할 수 있다. |
최종 엔티티 인증서 | 실제 서비스/개인 식별 | 웹 서버, 이메일 사용자, 코드 등 특정 주체에 발급되며, 중간 CA에 의해 서명된다. |
이 계층 구조의 주요 장점은 모듈성과 보안성이다. 만약 중간 CA의 개인 키가 유출되더라도 해당 중간 CA만 폐지하면 되며, 루트 CA 전체를 교체할 필요가 없다. 반면, 체인이 길어질수록 검증 과정이 복잡해지고, 체인 상의 어떤 인증서라도 유효하지 않거나 폐지되면 전체 신뢰가 깨질 수 있다는 단점도 존재한다.
5. PKI의 주요 응용 분야
5. PKI의 주요 응용 분야
공개 키 기반 구조는 다양한 디지털 보안 서비스의 근간을 제공하며, 여러 핵심 응용 분야에서 널리 사용된다. 그 주요 응용 분야는 다음과 같다.
가장 대표적인 응용은 웹 보안이다. HTTPS 프로토콜은 SSL/TLS를 통해 웹 서버의 신원을 확인하고 클라이언트와 서버 간 통신을 암호화하는 데 PKI를 사용한다. 웹 브라우저는 서버가 제시하는 디지털 인증서를 검증하여 사용자가 의도한 사이트에 접속하고 있음을 보장한다. 이를 통해 중간자 공격과 데이터 탈취를 방지한다.
전자 메일 보안에도 활용된다. S/MIME 표준은 PKI를 기반으로 이메일의 기밀성, 무결성, 발신자 인증 및 부인 방지를 제공한다. 발신자는 개인 키로 메일에 디지털 서명을 하여 신원을 증명하고, 수신자의 공개 키로 메일 내용을 암호화할 수 있다. 또한, 코드 서명은 소프트웨어 개발자가 배포하는 애플리케이션이나 스크립트에 디지털 서명을 하는 기술이다. 이를 통해 최종 사용자는 해당 코드가 알려진 출처에서 왔으며, 전송 중 변조되지 않았음을 확인할 수 있다. 이는 악성 코드의 유포를 방지하는 데 중요하다.
VPN 및 네트워크 접근 제어 분야에서도 중요하게 작동한다. 많은 기업용 VPN 솔루션은 사용자나 장치의 인증을 위해 X.509 인증서를 사용한다. 또한, 802.1X 프로토콜을 통한 유선/무선 네트워크 접근 제어에서도 클라이언트 인증 수단으로 PKI 기반 인증서가 자주 활용된다. 이는 허가된 사용자와 장치만 네트워크 자원에 접근할 수 있도록 한다.
5.1. 웹 보안 (HTTPS/SSL/TLS)
5.1. 웹 보안 (HTTPS/SSL/TLS)
공개 키 기반 구조의 가장 보편적이고 가시적인 응용 분야는 월드 와이드 웹의 보안을 강화하는 것이다. HTTPS 프로토콜은 HTTP에 SSL 또는 그 후속 프로토콜인 TLS를 결합하여, 웹 브라우저와 서버 간의 통신을 암호화하고 서버의 신원을 확인한다. 이 과정의 핵심에는 디지털 인증서와 PKI가 있다.
사용자가 HTTPS로 보호된 웹사이트에 접속하면, 웹 서버는 자신의 공개 키가 포함된 디지털 인증서를 브라우저에 전송한다. 브라우저는 이 인증서가 신뢰할 수 있는 인증 기관에 의해 서명되었는지, 유효 기간이 지나지 않았는지, 그리고 접속하려는 도메인 이름과 일치하는지 검증한다. 검증이 성공하면 브라우저는 서버의 공개 키를 사용하여 안전한 대칭 키를 생성하고 교환한다. 이후 모든 통신은 이 세션 키로 암호화되어 도청이나 변조로부터 보호된다.
프로토콜/용어 | 설명 |
|---|---|
SSL (Secure Sockets Layer) | 넷스케이프사가 개발한 초기 보안 프로토콜. 현재는 사용되지 않음. |
TLS (Transport Layer Security) | SSL의 후속이자 현대 표준 프로토콜. 지속적으로 업데이트됨. |
HTTPS (HTTP Secure) | HTTP over TLS/SSL. 기본 포트는 443번. |
핸드셰이크 (Handshake) | TLS 연결 설정 초기에 암호 스위트 협상 및 키 교환을 수행하는 과정. |
이 메커니즘은 온라인 뱅킹, 전자 상거래, 소셜 미디어 로그인 등 민감한 정보를 교환하는 모든 웹사이트의 보안 기반을 이룬다. 최근에는 모든 웹사이트에 HTTPS를 적용하는 것이 보편화되었으며, 주요 브라우저들은 HTTP 사이트에 대해 '안전하지 않음' 경고를 표시한다. 이는 피싱 사이트를 차단하고 사용자 데이터의 기밀성과 무결성을 보장하는 데 PKI가 결정적인 역할을 하고 있음을 보여준다.
5.2. 전자 메일 보안 (S/MIME)
5.2. 전자 메일 보안 (S/MIME)
S/MIME은 공개 키 기반 구조를 활용하여 전자 메일의 기밀성, 무결성, 인증, 부인 방지를 제공하는 프로토콜이다. 이는 인터넷 메일 접근 프로토콜의 확장으로, MIME으로 인코딩된 이메일 콘텐츠에 디지털 서명과 암호화를 적용한다. 송신자는 자신의 개인 키로 메시지에 서명하여 발신자 인증과 메시지 변조 방지를 제공하고, 수신자의 공개 키로 메시지를 암호화하여 기밀성을 보장한다.
S/MIME의 동작은 디지털 인증서에 의존한다. 사용자는 신뢰할 수 있는 인증 기관으로부터 자신의 공개 키가 포함된 X.509 형식의 인증서를 발급받아야 한다. 이메일 클라이언트는 이 인증서를 설치하고 관리한다. 메시지를 서명할 때는 발신자의 개인 키와 인증서가 사용되며, 암호화할 때는 수신자의 공개 키 인증서가 필요하다. 대부분의 현대 이메일 클라이언트는 S/MIME 기능을 내장하고 있다.
기능 | 구현 방법 | 제공하는 보안 속성 |
|---|---|---|
디지털 서명 | 발신자의 개인 키로 메시지 다이제스트 서명 | 무결성, 인증, 부인 방지 |
메시지 암호화 | 수신자의 공개 키로 세션 키를 암호화하여 전송[5] | 기밀성 |
인증서 관리 | 이메일 클라이언트에 인증서 저장 및 신뢰 체인 검증 | 신뢰성 확립 |
S/MIME은 기업 환경에서 중요한 비즈니스 통신의 보안을 강화하는 데 널리 사용된다. 그러나 광범위한 채택을 위해서는 모든 통신 당사자가 S/MIME을 지원하는 클라이언트를 사용하고 유효한 인증서를 보유해야 한다는 전제 조건이 있다. 또한 엔드투엔드 암호화를 제공하지만, 메타데이터(제목, 수신자, 발신자 등)는 암호화되지 않는다는 점이 한계로 지적된다.
5.3. 코드 서명
5.3. 코드 서명
코드 서명은 소프트웨어 개발자나 배포자가 생성한 디지털 서명을 실행 파일, 스크립트, 드라이버, 펌웨어 업데이트 패키지와 같은 소프트웨어에 첨부하는 과정이다. 이 서명은 소프트웨어가 알려진 출처에서 왔으며, 배포 이후 변조되거나 악의적으로 수정되지 않았음을 검증하는 데 사용된다. 코드 서명은 공개 키 기반 구조를 활용하여 소프트웨어의 무결성과 신뢰성을 보장하는 핵심적인 응용 분야 중 하나이다.
코드 서명의 주요 목적은 최종 사용자에게 소프트웨어의 진위와 무결성을 보증하는 것이다. 개발자는 소프트웨어를 릴리스하기 전에 자신의 비대칭 키 쌍 중 개인 키를 사용하여 코드의 해시 값에 서명한다. 이렇게 생성된 서명은 소프트웨어와 함께 패키징되어 배포된다. 사용자가 해당 소프트웨어를 설치하거나 실행하려고 하면, 운영체제나 응용 프로그램은 첨부된 서명을 개발자의 공개 키(일반적으로 디지털 인증서에 포함됨)를 사용하여 검증한다. 검증 과정에서 코드의 해시 값을 재계산하고 서명과 비교함으로써, 코드가 서명된 이후 단일 바이트라도 변경되었는지 확인한다.
주요 운영체제와 플랫폼은 코드 서명을 강제하거나 권장하여 보안을 강화한다. 예를 들어, 마이크로소프트 윈도우는 드라이버와 일부 시스템 수준 소프트웨어에 대한 서명을 요구하며, 애플의 macOS는 게이트키퍼 기능을 통해 확인된 개발자의 서명이 없는 응용 프로그램 실행을 제한할 수 있다. 모바일 플랫폼인 안드로이드와 iOS 역시 앱 스토어를 통한 배포 시 모든 앱에 코드 서명을 의무화한다. 이는 사용자가 악성 소프트웨어를 실수로 설치하는 위험을 크게 줄인다.
코드 서명 인증서는 일반적으로 신뢰할 수 있는 상업적 인증 기관으로부터 발급받는다. CA는 개발자나 조직의 신원을 확인한 후 코드 서명 인증서를 발급한다. 타임스탬핑은 코드 서명의 중요한 부가 기능으로, 서명 당시의 인증서가 유효했음을 증명한다. 이는 인증서의 유효 기간이 만료된 후에도 서명의 유효성이 계속 유지되도록 보장한다.
5.4. VPN 및 네트워크 접근 제어
5.4. VPN 및 네트워크 접근 제어
공개 키 기반 구조는 VPN 구축과 네트워크 접근 제어를 위한 핵심적인 신원 확인 및 암호화 메커니즘을 제공한다. VPN은 공용 네트워크를 통해 사설 네트워크처럼 안전한 통신 터널을 생성하는 기술이다. 이 터널의 보안을 확립하고 통신 당사자의 신원을 검증하기 위해 PKI가 광범위하게 활용된다. 특히 IPsec VPN과 SSL/TLS VPN은 모두 디지털 인증서를 사용하여 장치나 사용자를 인증하고, 세션 키를 안전하게 교환하며, 데이터의 무결성과 기밀성을 보장한다.
네트워크 접근 제어 분야에서 PKI는 "장치 기반 인증"의 표준 방법으로 자리 잡았다. 유선 또는 무선 네트워크에 접속하려는 각 클라이언트 장치(예: 노트북, 스마트폰, IoT 기기)에게 고유한 클라이언트 인증서가 발급된다. 사용자가 네트워크에 연결을 시도하면, 네트워크 접근 제어 서버는 해당 장치의 인증서를 검증한다. 이 과정을 통해 장치의 신원이 확인되고, 미리 정의된 정책에 따라 특정 네트워크 세그먼트나 리소스에 대한 접근 권한이 부여된다. 이 방식은 단순한 암호 기반 인증보다 훨씬 강력한 보안을 제공하며, 자격 증명 도난이나 공유의 위험을 줄인다.
다음은 PKI가 적용되는 주요 네트워크 보안 시나리오를 정리한 표이다.
적용 분야 | PKI의 역할 | 주요 프로토콜/표준 |
|---|---|---|
사이트 대 사이트 VPN | 각 사이트의 라우터/방화벽을 상호 인증하고, 안전한 터널을 설정한다. | IPsec (IKE 프로토콜에서 인증서 사용) |
원격 접근 VPN | 원격 사용자나 장치의 신원을 인증하여 내부 네트워크에 안전하게 접속하게 한다. | |
무선 네트워크 보안 | 장치와 무선 액세스 포인트의 상호 인증을 수행한다. (엔터프라이즈 모드) | WPA2-Enterprise / WPA3-Enterprise (EAP-TLS) |
유선 네트워크 인증 | 스위치 포트에 연결되는 장치의 신원을 인증하여 네트워크 접근을 제어한다. | IEEE 802.1X (EAP-TLS) |
이러한 접근 방식은 네트워크 경계를 보호하는 데 그치지 않고, 제로 트러스트 보안 모델의 실현을 위한 기초가 된다. 제로 트러스트 모델에서는 내부 네트워크에 위치한 장치라도 기본적으로 신뢰하지 않고, 지속적인 검증을 요구한다. PKI를 통해 발급된 강력한 디지털 신원은 각 접속 시도와 트랜잭션에 대한 신뢰의 근간을 형성한다. 결과적으로 PKI는 물리적 위치에 관계없이 사용자와 장치의 신원을 안전하게 증명함으로써 현대적인 네트워크 보안 아키텍처의 필수 구성 요소가 되었다.
6. PKI 운영 모델
6. PKI 운영 모델
PKI 운영 모델은 인증 기관의 신뢰 범위와 서비스 대상에 따라 크게 공개 PKI, 사설 PKI, 그리고 이 둘을 결합한 하이브리드 모델로 구분된다. 각 모델은 서로 다른 환경과 요구사항에 맞게 설계되어 있다.
공개 PKI는 공인된 상업적 또는 공공 인증 기관이 일반 대중이나 불특정 다수의 기업에 디지털 인증서를 발급하는 모델이다. 이 모델의 핵심은 광범위한 신뢰 체인을 구축하는 것이다. 주요 웹 브라우저와 운영체제에는 루트 인증 기관의 공개 키가 미리 내장되어 있어, 이들이 발급한 인증서를 통해 HTTPS 웹사이트의 신원을 확인할 수 있다. 공개 PKI는 인터넷 상의 익명의 당사자 간 보안 통신을 가능하게 하는 기반이지만, 인증 기관의 신뢰성 문제나 중앙 집중적 관리에 따른 단일 장애점 위험을 내포한다.
사설 PKI는 특정 조직이나 기업 내부에서 독자적으로 운영되는 폐쇄적인 모델이다. 조직은 자체 루트 인증 기관을 구축하고 내부 시스템, 직원, 디바이스에 대한 인증서를 발급한다. 이 모델은 외부에 노출되지 않는 내부 네트워크, VPN 접근, 애플리케이션 서명, 사물인터넷 디바이스 관리 등에 주로 사용된다. 사설 PKI는 조직의 정책에 완전히 부합하는 인증서 생명주기 관리를 가능하게 하고, 비용을 통제할 수 있으며, 외부 의존성을 줄인다는 장점이 있다. 그러나 자체 구축한 루트 인증서를 모든 클라이언트 장치에 신뢰할 수 있는 인증서로 배포해야 하는 관리 부담이 따른다.
하이브리드 모델은 공개 PKI와 사설 PKI의 장점을 결합한다. 일반적인 방식은 조직이 사설 PKI의 루트 인증 기관을 공개 PKI의 상위 인증 기관으로부터 발급받은 중간 인증서로 서명하는 것이다. 이를 통해 내부적으로는 자체 인증서를 유연하게 관리하면서도, 필요할 경우 공개적으로 신뢰받는 인증서 체인을 활용할 수 있다. 또 다른 접근법은 공개 웹 서비스에는 공개 PKI 인증서를, 내부 서비스에는 사설 PKI 인증서를 병행 사용하는 것이다. 이 모델은 복잡성이 증가하지만, 보안 요구사항과 비용, 관리 편의성을 균형 있게 맞출 수 있는 유연성을 제공한다.
운영 모델 | 신뢰 근원 | 주요 사용처 | 장점 | 단점 |
|---|---|---|---|---|
공개 PKI | 브라우저/OS에 내장된 공인 루트 인증 기관 | 공개 웹사이트(HTTPS), 인터넷 상의 전자상거래 | 광범위한 호환성, 익명 당사자 간 신뢰 구축 | 인증 기관 신뢰 문제, 비용, 중앙 집중적 위험 |
사설 PKI | 조직 내부에서 구축한 자체 루트 인증 기관 | 내부 시스템, 직원 인증, 사물인터넷, VPN | 정책 통제, 비용 효율, 외부 의존성 낮음 | 자체 루트 인증서 배포 관리 부담, 공개 호환성 없음 |
하이브리드 모델 | 공개 PKI 체인에 연결된 사설 인증 기관 | 공개 및 내부 서비스 병행 필요 조직 | 유연성, 내부 관리와 공개 신뢰의 결합 | 구조와 관리가 복잡해질 수 있음 |
6.1. 공개 PKI
6.1. 공개 PKI
공개 PKI는 공개적으로 신뢰되는 인증 기관이 발급한 디지털 인증서를 사용하여, 인터넷 상의 불특정 다수 사용자 간 신원 확인과 보안 통신을 가능하게 하는 모델이다. 주로 웹사이트의 SSL/TLS 인증서, 코드 서명, S/MIME 전자 메일 보안 등에 널리 사용된다. 이 모델의 핵심은 운영체제나 웹 브라우저에 미리 내장된 '신뢰할 수 있는 루트 인증서 저장소'에 있다. 사용자는 자신의 브라우저나 시스템이 신뢰하는 루트 CA 목록에 포함된 기관으로부터 발급된 인증서를 가진 상대방과 안전하게 통신할 수 있다.
공개 PKI의 주요 장점은 보편성과 상호 운용성이다. 전 세계적으로 인정받는 루트 인증 기관이 발급한 인증서는 어떤 사용자나 장치에서도 유효성 검증이 가능하다. 이는 전자 상거래, 온라인 뱅킹, 정부 포털 등 공공 서비스에 필수적이다. 그러나 이 모델은 중앙 집중식 신뢰 구조에 의존하기 때문에, 루트 CA 자체가 해킹되거나 잘못된 인증서를 발급하면 전 세계적인 보안 위협으로 이어질 수 있다는 단점을 가진다. 역사적으로 몇몇 주요 CA의 보안 침해 사건은 이러한 취약점을 드러냈다[6].
공개 PKI의 운영은 엄격한 감사와 규정 준수를 요구한다. CA/브라우저 포럼과 같은 산업 컨소시엄은 인증서 발급 기준과 기술 요구사항을 정립한다. 인증서 유효성 검증을 위한 OCSP나 CRL 같은 프로토콜도 공개 PKI 생태계의 중요한 부분이다. 최근에는 Let's Encrypt와 같은 자동화된 무료 CA의 등장으로 공개 PKI의 접근성이 크게 향상되었다.
6.2. 사설 PKI
6.2. 사설 PKI
사설 PKI는 특정 조직이나 기업 내부에서 독자적으로 구축하고 운영하는 공개 키 기반 구조를 의미한다. 외부 공개 PKI와 달리 폐쇄된 환경에서 신뢰 체계를 구성하며, 조직의 내부 시스템, 직원, 디바이스, 애플리케이션 간의 신원 확인과 보안 통신을 위해 사용된다. 주로 기업 내부망, 정부 기관, 연구 시설 등 외부에 공개되지 않는 서비스의 인증에 적합하다.
사설 PKI의 핵심은 조직이 자체적인 루트 인증 기관을 보유하고 이를 기반으로 인증서 계층을 관리한다는 점이다. 이는 외부 CA에 대한 의존성을 제거하고, 인증서 발급 정책, 비용, 유효기간 등을 조직의 필요에 따라 완전히 통제할 수 있게 한다. 예를 들어, 내부 웹 서버, VPN 접속, 파일 서명, 이메일 암호화, 스마트 카드 인증 등에 사용되는 디지털 인증서를 자체적으로 발급하고 관리한다.
사설 PKI 운영에는 몇 가지 주요 장점과 고려사항이 존재한다. 장점으로는 외부 CA 비용 절감, 내부 보안 정책에 맞춘 유연한 인증서 정책 수립, 외부 CA의 해킹이나 오류로 인한 신뢰 위협에서 벗어날 수 있다는 점을 들 수 있다. 반면, 조직이 인프라 구축과 유지보수, 키의 안전한 저장 및 관리, 인증서 폐기 목록 배포 등 모든 운영 부담을 직접 떠안아야 한다. 또한, 사설 PKI로 발급된 인증서는 해당 조직 내부에서만 신뢰되므로, 공개 인터넷 서비스에는 적합하지 않다.
특징 | 사설 PKI | 공개 PKI |
|---|---|---|
신뢰 범위 | 특정 조직 내부 | 전 세계적 (인터넷) |
운영 주체 | 조직 자체 | 상업적 또는 공공 인증 기관 |
주요 용도 | 내부 시스템, 직원, 디바이스 인증 | 공개 웹사이트, 범용 이메일, 상업적 코드 서명 |
비용 구조 | 초기 구축 및 유지보수 비용 | 인증서 발급 및 갱신 수수료 |
정책 통제도 | 완전한 통제 | CA의 정책에 따름 |
신뢰 설정 | 조직 내 클라이언트에 루트 CA 인증서를 수동 배포 | OS/브라우저에 미리 내장됨 |
따라서 조직은 서비스의 범위와 보안 요구사항을 고려하여 공개 PKI를 사용할지, 사설 PKI를 구축할지, 또는 양자를 결합한 하이브리드 모델을 채택할지 결정해야 한다.
6.3. 하이브리드 모델
6.3. 하이브리드 모델
하이브리드 모델은 공개 PKI와 사설 PKI의 장점을 결합한 운영 방식이다. 이 모델에서는 조직이 내부 네트워크와 시스템에 대해 자체 사설 PKI를 운영하면서, 외부와의 통신이나 공개 서비스를 위해 상업적 또는 공공 인증 기관이 발급한 인증서를 함께 사용한다. 이를 통해 내부 통제의 유연성과 외부 신뢰성이라는 두 가지 목표를 동시에 달성할 수 있다.
일반적인 구현 방식은 내부 직원, 장비, 애플리케이션에 대한 인증에는 사설 루트 인증서를 사용하고, 고객이 접속하는 공식 웹사이트나 이메일 서버 등에는 공인 인증 기관의 인증서를 적용하는 것이다. 이렇게 하면 내부 시스템의 변경이나 확장에 빠르게 대응할 수 있는 반면, 외부 사용자에게는 광범위하게 신뢰받는 인증서를 제공할 수 있다.
하이브리드 모델 운영 시 고려사항은 다음과 같다.
고려사항 | 설명 |
|---|---|
인증서 관리 복잡성 | 공인 CA와 사설 CA를 모두 관리해야 하므로 정책, 수명 주기, 폐지 절차가 통일되지 않을 수 있다. |
비용 절감 | 모든 인증서를 공인 CA에서 구매하는 것보다 비용을 절감할 수 있다. |
신뢰 체계 분리 | 내부와 외부 신뢰 체계를 명확히 분리하고, 해당 정책을 사용자와 시스템에 정확히 전달해야 한다. |
유효성 검증 | 클라이언트 측에서 내부 사설 CA의 루트 인증서를 신뢰할 수 있도록 설치해야 정상적으로 인증서를 검증할 수 있다. |
이 모델은 대기업, 금융 기관, 정부 기관 등에서 내부 보안 요구사항과 외부 서비스 요구사항을 모두 충족시켜야 할 때 효과적이다. 그러나 두 체계를 통합적으로 관리하고 모니터링하기 위한 강력한 키 관리 시스템과 정책이 필수적으로 요구된다.
7. 보안 고려사항과 위협
7. 보안 고려사항과 위협
공개 키 기반 구조의 안전한 운영은 여러 보안 고려사항을 충족해야 하며, 다양한 위협에 대비해야 합니다. 가장 근본적인 문제는 인증 기관에 대한 신뢰입니다. PKI의 전체 보안 모델은 최상위 인증 기관의 개인 키가 안전하게 보호되고, 해당 기관이 인증서 발급 정책을 엄격히 준수한다는 가정에 기반합니다. 만약 인증 기관이 해킹되거나 악의적으로 행동하여 잘못된 인증서를 발급하면, 공격자는 합법적인 사이트로 위장하여 사용자의 통신을 가로챌 수 있습니다[7]. 또한, 일부 국가에서는 법적 강제력을 통해 인증 기관에게 특정 도메인에 대한 인증서 발급을 요구할 수 있어, 전역적인 신뢰 체계에 영향을 미칠 수 있습니다.
키 관리의 중요성은 절대적입니다. 사용자의 개인 키가 유출되면, 해당 키와 연결된 모든 디지털 신원과 서명은 더 이상 신뢰할 수 없게 됩니다. 개인 키는 하드웨어 보안 모듈과 같은 안전한 저장소에 보관하고, 강력한 패스프레이즈로 보호해야 합니다. 또한, 키의 수명 주기 관리, 즉 적절한 키 생성, 안전한 배포, 정기적인 갱신, 그리고 폐기 시 완전한 삭제가 필수적입니다. 약한 키 생성 알고리즘이나 짧은 키 길이를 사용하는 것도 주요 위협 요소입니다.
인증서 유효성 검증 과정에도 위험이 도사리고 있습니다. 클라이언트 소프트웨어(예: 웹 브라우저)는 접속 시점에 서버의 디지털 인증서가 유효한지 확인해야 합니다. 이 과정에는 인증서의 서명 체인 검증, 유효기간 확인, 그리고 인증서 폐기 목록 또는 온라인 인증서 상태 프로토콜을 통한 폐기 상태 조회가 포함됩니다. 그러나 CRL은 갱신 지연 문제가 있을 수 있으며, OCSP 응답을 가로채는 공격(OCSP 스테이플링을 사용하지 않을 경우)이나 검증 로직 자체의 결함으로 인해 유효하지 않은 인증서가 통과될 수 있습니다. 이러한 검증 실패는 중간자 공격을 가능하게 합니다.
7.1. 인증 기관의 신뢰 문제
7.1. 인증 기관의 신뢰 문제
인증 기관의 신뢰는 공개 키 기반 구조 전체의 근간을 이루지만, 이 신뢰 모델에는 여러 취약점과 위협이 존재한다. 가장 큰 문제는 인증 기관 자체가 공격 대상이 되어 위조된 디지털 인증서를 발급할 수 있다는 점이다. 만약 신뢰할 수 있는 루트 인증 기관이 해킹되거나 내부자가 악의적으로 행동하면, 공격자는 합법적인 웹사이트를 사칭하는 데 사용될 수 있는 인증서를 생성할 수 있다. 이러한 사건은 실제로 발생했으며, 이로 인해 브라우저 제조사는 문제가 된 인증 기관의 루트 인증서를 신뢰 목록에서 제거하는 조치를 취하기도 했다.
또 다른 주요 문제는 다수의 인증 기관이 존재한다는 점에서 비롯된다. 대부분의 운영 체제와 웹 브라우저는 수백 개의 서로 다른 루트 인증 기관을 기본적으로 신뢰한다. 이는 '가장 약한 고리' 문제를 초래한다. 즉, 수백 개의 인증 기관 중 하나만 보안이 취약해도 전체 인증서 생태계의 신뢰도가 훼손될 수 있다. 공격자는 보안 수준이 낮거나 규제가 느슨한 지역의 인증 기관을 표적으로 삼아 악성 인증서를 획득하려 시도할 수 있다.
위협 유형 | 설명 | 사례 또는 영향 |
|---|---|---|
인증 기관 해킹 | 공격자가 인증 기관의 시스템을 침입하여 인증서 발급 키를 탈취하거나 위조 인증서를 발급함. | DigiNotar[8], Comodo 해킹 시도. |
내부자 위협 | 인증 기관 내부 직원이 권한을 남용하여 부정한 인증서를 발급함. | 엄격한 감사와 분리된 역할이 필요함. |
약한 인증 기관 | 보안 관행이 미흡하거나 검증 절차가 약한 인증 기관이 존재함. | 전체 신뢰 체인의 취약점이 됨. |
국가 강제 인증 기관 | 일부 국가는 자국 인증 기관을 강제로 신뢰 목록에 포함시켜 감시나 검열에 활용할 수 있음. | 사용자에 대한 투명한 통제 부재. |
이러한 신뢰 문제를 완화하기 위해 인증서 투명성, 인증서 고정, 다중 서명 인증서 같은 기술과 정책이 도입되었다. 특히 인증서 투명성은 모든 발급된 인증서를 공개 로그에 기록하여 누구나 감시할 수 있게 함으로써, 인증 기관이 감추어져 인증서를 발급하는 것을 방지하는 데 기여한다.
7.2. 키 관리의 중요성
7.2. 키 관리의 중요성
키 관리는 공개 키 기반 구조의 보안성을 유지하는 핵심 과정이다. 이는 비대칭 키 쌍의 생성, 저장, 배포, 사용, 갱신, 백업, 폐기까지 전 주기에 걸친 체계적인 관리를 의미한다. 특히 개인 키의 비밀성 보장이 가장 중요하며, 개인 키가 유출되면 해당 키로 서명된 모든 디지털 인증서와 거래의 신뢰성이 근본적으로 훼손된다. 따라서 개인 키는 하드웨어 보안 모듈과 같은 안전한 저장소에 보관하거나, 강력한 암호로 보호해야 한다.
키의 수명 주기 관리도 필수적이다. 암호화 키는 영구적으로 사용되지 않으며, 정기적인 키 갱신과 순환 정책을 수립해야 한다. 이는 키가 장기간 사용될수록 유출되거나 암호학적 공격에 취약해질 위험을 줄이기 위함이다. 또한 키가 분실되거나 직원이 퇴사하는 경우 등을 대비한 키 복구 및 폐지 절차가 명확해야 한다. 폐기된 키는 완전히 삭제되어 향후 악용될 가능성을 차단해야 한다.
관리 대상 | 주요 관리 활동 | 보안 목표 |
|---|---|---|
안전한 생성, 암호화 저장, 접근 통제, 물리적 보호 | 비밀성, 무결성 유지 | |
신뢰할 수 있는 경로를 통한 배포 (인증서 형태) | 가용성, 진위성 보장 | |
키 쌍 전체 | 정기적 갱신(키 순환), 백업, 안전한 폐기 | 가용성 유지, 위험 감소 |
효과적인 키 관리는 기술적 조치뿐만 아니라 조직의 정책과 절차를 포함한다. 키 관리 정책은 키 사용 권한, 접근 승인 절차, 감사 로그 기록 요구사항 등을 명시해야 한다. 이러한 종합적인 접근이 없으면 PKI 전체의 신뢰 체인이 무너질 수 있다.
7.3. 인증서 유효성 검증
7.3. 인증서 유효성 검증
인증서 유효성 검증은 디지털 인증서가 신뢰할 수 있고 현재 유효한지를 확인하는 일련의 과정이다. 이 과정은 공개 키 기반 구조의 신뢰 모델이 제대로 작동하기 위한 핵심 절차이다. 검증은 일반적으로 인증서의 서명 체인을 추적하여 루트 인증 기관에 도달하고, 인증서의 상태와 속성을 점검하는 방식으로 이루어진다.
검증 프로세스는 주로 다음과 같은 단계를 포함한다.
1. 서명 체인 검증: 클라이언트는 제시된 인증서의 발행자(인증 기관)를 확인하고, 해당 CA의 인증서를 사용해 서명을 검증한다. 이 과정은 신뢰하는 루트 CA 인증서 저장소에 등록된 신뢰 앵커까지 체인을 구성하며 반복된다.
2. 유효기간 확인: 인증서의 "유효 기간 시작일(Not Before)"과 "만료일(Not After)"을 확인하여 현재 시간이 그 범위 내에 있는지 검사한다.
3. 상태 확인: 인증서가 조기에 폐지되지 않았는지 확인한다. 이는 주로 인증서 폐기 목록을 조회하거나 온라인 인증서 상태 프로토콜 서버에 질의하는 방식으로 수행된다.
4. 용도 및 정책 확인: 인증서의 확장 필드에 명시된 키 용도(예: 서명, 암호화)나 정책 제약 조건이 현재 사용 목적과 일치하는지 검증한다.
검증 단계 | 주요 확인 사항 | 일반적인 검증 방법 |
|---|---|---|
신뢰 체인 | 서명의 유효성, 루트 CA 신뢰 | 체인 탐색 및 서명 검증 알고리즘 |
상태 | 인증서의 폐지 여부 | |
유효성 | 유효 기간 내 사용 여부 | 시스템 시간과 인증서 내 날짜 필드 비교 |
적합성 | 지정된 용도와의 일치 여부 | 인증서 확장 필드(Key Usage, Extended Key Usage) 분석 |
이러한 검증은 웹 브라우저가 HTTPS 웹사이트에 접속할 때, 또는 클라이언트 소프트웨어가 서버를 인증할 때 백그라운드에서 자동으로 수행된다. 검증 실패 시 사용자에게 경고가 표시되거나 연결이 차단된다. 시간이 지남에 따라 인증서 투명성 로그와 같은 추가 메커니즘이 도입되어, CA가 실수나 악의적으로 잘못 발급한 인증서를 공개적으로 모니터링하고 탐지할 수 있게 되었다[9].
8. 표준과 프로토콜
8. 표준과 프로토콜
공개 키 기반 구조의 구현과 상호운용성을 보장하는 핵심은 잘 정의된 표준과 프로토콜에 있다. 이 표준들은 디지털 인증서의 형식, 암호화 작업의 방식, 그리고 시스템 구성 요소 간의 통신 방법을 규정한다.
가장 근간이 되는 표준은 X.509이다. 이는 국제 전기 통신 연합의 ITU-T에서 정의한 표준으로, 공개 키 인증서와 인증서 폐기 목록의 구조와 데이터 형식을 명시한다. X.509 인증서에는 소유자의 식별 정보, 공개 키, 발행 기관(인증 기관)의 디지털 서명, 유효 기간 등이 포함된다. 이 표준의 다양한 버전(예: v1, v2, v3)이 발전해 왔으며, v3은 확장 필드를 도입하여 인증서의 용도와 정책을 더욱 세밀하게 정의할 수 있게 했다.
암호화 메시지 구문과 키 관리에 관한 사실상의 표준은 RSA Laboratories에서 제정한 PKCS(Public-Key Cryptography Standards) 시리즈이다. 주요 표준은 다음과 같다.
표준 번호 | 주요 내용 |
|---|---|
RSA 암호 표준. 암호화 및 서명을 위한 알고리즘과 패딩 스킴(예: OAEP, PSS)을 정의한다. | |
암호화 메시지 구문. 디지털 서명, 암호화, 인증서와 CRL을 함께 묶는 방법을 규정한다. S/MIME의 기반이 된다. | |
인증서 서명 요청(CSR) 형식. 최종 엔티티가 CA에 인증서 발급을 요청할 때 사용하는 형식이다. | |
암호화 토큰 인터페이스(Cryptoki). 하드웨어 보안 모듈 같은 암호화 장치에 대한 플랫폼 독립적인 API를 제공한다. | |
개인 정보 교환 형식. 하나의 파일에 개인 키, 공개 키 인증서, 루트 인증서를 안전하게 묶어 보관 및 이동할 수 있게 한다. |
이 외에도 SSL/TLS 프로토콜은 안전한 통신 채널 수립 과정에서 PKI를 활용하는 방법을 정의하며, OCSP(Online Certificate Status Protocol)는 인증서의 실시간 상태(폐지 여부)를 조회하기 위한 프로토콜이다. 이러한 표준과 프로토콜의 조합이 전 세계적으로 신뢰할 수 있는 디지털 인증 및 암호화 체계의 기반을 형성한다.
8.1. X.509 표준
8.1. X.509 표준
X.509는 공개 키 기반 구조에서 디지털 인증서의 형식과 구조, 그리고 관련된 유효성 검증 절차를 정의하는 국제 표준이다. 국제 전기 통신 연합 산하의 국제 전신 전화 자문 위원회가 처음 제정하였으며, 현재는 국제 표준화 기구와 국제 전기 표준 회의의 공동 표준으로 유지 관리되고 있다. 이 표준은 주로 인증서의 데이터 필드, 인코딩 규칙, 그리고 인증 기관이 발행하는 인증서의 계층적 구조를 규정한다.
X.509 인증서의 핵심 구조는 버전, 일련번호, 서명 알고리즘, 발급자, 유효기간, 소유자, 소유자의 공개 키 정보 등으로 구성된다. 이러한 정보는 추상 문법 표기법 1을 사용하여 정의되며, 일반적으로 DER 인코딩 규칙에 따라 이진 형식으로 인코딩되어 파일로 저장된다. 가장 흔히 접하는 파일 확장자는 .cer, .crt, .der이다. 또한 Base64로 인코딩된 텍스트 형식(.pem)도 널리 사용된다.
표준은 지속적으로 개정되어 왔으며, 주요 버전과 추가된 기능은 다음과 같다.
버전 | 주요 특징 및 추가 사항 |
|---|---|
X.509 v1 (1988) | 기본적인 인증서 필드(발급자, 소유자, 공개키, 유효기간, 서명)를 정의했다. |
X.509 v2 (1993) | 발급자와 소유자의 고유 식별자 필드를 추가했다. |
X.509 v3 (1996) | 확장 필드를 도입하여 인증서의 용도(키 사용), 대체 이름, 기본 제약, 인증서 정책 등을 유연하게 정의할 수 있게 했다. 현재 가장 널리 사용되는 버전이다. |
X.509 v4 (2000년대) | 프라이버시 강화 및 새로운 확장 기능을 제안했으나, v3에 비해 보급도는 낮다. |
X.509 표준은 단순히 인증서 형식만을 정의하는 것이 아니라, 인증서 폐기 목록의 형식과 온라인 인증서 상태 프로토콜 같은 인증서 상태 확인 프로토콜의 기반이 되는 데이터 구조도 포함한다. 이를 통해 공개 키 기반 구조의 상호운용성을 보장하고, 다양한 보안 응용 프로그램(전송 계층 보안, S/MIME, 가상 사설망)이 일관된 방식으로 디지털 신원을 확인하고 암호화 통신을 설정할 수 있게 한다.
8.2. PKCS 시리즈
8.2. PKCS 시리즈
PKCS는 공개 키 기반 구조에서 사용되는 암호화 기술의 상호 운용성을 보장하기 위해 개발된 일련의 표준 규격이다. 주로 RSA Laboratories에서 주도하여 개발되었으며, 공개 키 암호화, 디지털 서명, 인증서 형식, 안전한 키 저장 등 다양한 암호학적 기능을 표준화한다. 이 표준들은 소프트웨어와 하드웨어 제조사들이 호환되는 제품을 개발하는 데 기초를 제공한다.
가장 널리 알려진 표준으로는 PKCS #7과 PKCS #12가 있다. PKCS #7은 암호화 메시지 구문 표준으로, 디지털 서명과 암호화를 적용한 데이터의 구조를 정의하며, S/MIME 같은 프로토콜의 기반이 된다. PKCS #12는 개인 키, 공개 키 인증서 및 기타 보안 개체를 하나의 파일(일반적으로 .p12 또는 .pfx 확장자)로 안전하게 저장하고 이동하는 포맷을 규정한다. 다른 주요 표준은 다음과 같다.
표준 번호 | 주요 내용 |
|---|---|
PKCS #1 | RSA 암호화 표준. RSA 공개 키와 개인 키의 형식, 그리고 암호화와 서명을 위한 패딩 스키마(예: OAEP, PSS)를 정의한다. |
PKCS #7 | 암호화 메시지 구문 표준. 디지털 서명이나 암호화가 적용된 데이터의 일반적인 구문을 정의한다. |
PKCS #10 | 인증서 요청 표준. 인증 기관에 디지털 인증서를 요청할 때 사용되는 형식(CSR)을 정의한다. |
PKCS #11 | 암호화 토큰 인터페이스 표준(Cryptoki). 하드웨어 보안 모듈 같은 암호화 장치에 대한 플랫폼 독립적인 프로그래밍 인터페이스를 제공한다. |
PKCS #12 | 개인 정보 교환 구문 표준. 개인 키와 인증서를 패스워드로 보호된 단일 파일로 묶어 이동/백업할 수 있게 한다. |
이 표준들은 시간이 지남에 따라 다른 공식 표준에 통합되거나 영향을 주었다. 예를 들어, PKCS #1의 내용은 RFC 문서들(RFC 8017 등)로 발전했으며, PKCS #7은 CMS로 표준화되었다. PKCS #11 인터페이스는 스마트 카드나 HSM을 활용하는 보안 애플리케이션 개발에 광범위하게 사용된다. PKCS 시리즈는 상용 및 오픈소스 암호화 라이브러리에서 광범위하게 구현되어, 현대 디지털 인증서 관리와 보안 통신의 실질적인 토대를 형성한다.
9. 관련 기술 및 발전
9. 관련 기술 및 발전
블록체인 기술을 활용한 분산 공개 키 기반 구조는 기존의 중앙 집중식 인증 기관 모델에 대한 대안으로 연구되고 있다. 이 모델에서는 신뢰할 수 있는 제3자 인증 기관 대신 블록체인의 분산 원장과 합의 메커니즘을 통해 공개 키와 신원 정보의 등록 및 검증을 관리한다. 이를 통해 단일 실패 지점을 제거하고, 인증서의 투명성과 변조 방지성을 높이며, 인증 기관에 대한 의존도를 낮추는 것을 목표로 한다. 그러나 확장성, 처리 속도, 규제 준수와 같은 과제가 남아 있다.
자동화된 인증서 발급 서비스인 Let's Encrypt는 공개 키 기반 구조의 접근성을 혁신적으로 높였다. 무료로 도메인 유효성 검증 디지털 인증서를 제공하여 HTTPS의 광범위한 채택을 촉진했다. 이 서비스는 ACME 프로토콜을 사용하여 인증서 발급, 갱신, 폐지 과정을 완전히 자동화한다. 이로 인해 수동 관리의 부담과 비용 장벽이 크게 줄어들었지만, 주로 단순한 도메인 유효성 검증 인증서에 국한되어 있으며, 확장된 유효성 검증이 필요한 경우에는 여전히 유료 인증 기관이 필요하다.
기술/개념 | 핵심 특징 | 주요 장점 | 한계 또는 고려사항 |
|---|---|---|---|
분산 원장, 합의 알고리즘, 인증 기관 의존도 감소 | 단일 실패 지점 제거, 투명성 및 변조 방지성 향상 | 확장성, 처리 속도, 법적/규제적 프레임워크 부재 | |
무료 도메인 유효성 검증 인증서, ACME 프로토콜 기반 자동화 | HTTPS 채용 장벽 해소, 관리 비용 및 복잡성 감소 | 도메인 유효성 검증 인증서에 한정, 조직 신원 검증 불가 |
이러한 발전은 공개 키 기반 구조가 더욱 접근 가능하고, 탄력적이며, 자동화된 방향으로 진화하고 있음을 보여준다.
9.1. 블록체인 기반 분산 PKI
9.1. 블록체인 기반 분산 PKI
전통적인 공개 키 기반 구조는 중앙 집중식 인증 기관에 의존하는 구조로, 단일 실패점과 신뢰 문제가 존재한다. 블록체인 기술을 활용한 분산 PKI는 이러한 문제를 해결하기 위한 대안으로 등장했다. 이 모델에서는 블록체인의 분산 원장 기술을 통해 인증서의 발급, 저장, 검증, 폐기 과정을 탈중앙화하여 관리한다.
블록체인 기반 PKI의 핵심 아이디어는 신뢰를 단일 CA에서 네트워크 참여자 전체로 분산시키는 것이다. 인증서의 발행 및 상태(유효/폐기) 정보가 블록체인에 기록되고, 모든 참여자가 이를 검증할 수 있다. 이를 통해 CA의 불법적이거나 오류에 의한 인증서 발급을 방지하고, 인증서 폐기 목록의 실시간 동기화 문제를 완화할 수 있다. 대표적인 구현 방식으로는 공개 블록체인에 인증서의 해시값을 타임스탬프로 저장하거나, 허가형 블록체인을 통해 신원 확인된 노드들만이 인증서 상태를 관리하는 컨소시엄 모델이 있다.
이 접근법의 주요 장점과 과제는 다음과 같이 정리할 수 있다.
장점 | 과제 |
|---|---|
신뢰의 분산과 단일 실패점 제거 | 블록체인 네트워크의 성능과 확장성 문제 |
인증서 투명성과 조작 방지 증가 | 기존 인프라 및 프로토콜과의 통합 복잡성 |
CRL/OCSP[10] 의존도 감소 | 새로운 키 관리 및 프라이버시 고려사항 발생 |
자동화된 감사와 불변의 기록 제공 | 법적, 규제적 프레임워크의 부재 |
블록체인 기반 분산 PKI는 아직 실험 및 초기 도입 단계에 있지만, 사물 인터넷 디바이스 인증, 분산 신원 확인, 공급망 보안 등 중앙화된 신뢰 기관이 부적합한 영역에서 잠재력을 보이고 있다. 이는 전통적인 PKI의 보완재이거나 특정 영역을 대체하는 진화 모델로 간주된다.
9.2. 자체 서명 인증서와 Let's Encrypt
9.2. 자체 서명 인증서와 Let's Encrypt
자체 서명 인증서는 공인된 인증 기관의 서명 없이 생성자 자신이 직접 서명한 디지털 인증서이다. 이 인증서는 내부 테스트나 폐쇄된 사설 네트워크 환경에서 사용되며, 공개 인터넷에서 사용할 경우 대부분의 웹 브라우저나 클라이언트가 신뢰할 수 없는 인증서로 판단하여 보안 경고를 표시한다. 자체 서명 인증서의 주요 문제는 인증서의 진위와 소유자 신원에 대한 제3자의 검증이 부재한다는 점이다.
전통적인 공인 인증 기관은 유료로 인증서를 발급해왔으나, 이는 웹 보안의 보편화에 장벽이 되었다. 이러한 상황에서 등장한 Let's Encrypt는 인터넷 보안 연구 그룹(ISRG)이 운영하는 비영리 무료 자동화 인증 기관이다. 2015년 출범한 이 서비스의 핵심 목표는 HTTPS 채택 장벽을 낮추어 전체 웹의 보안을 강화하는 것이다. Let's Encrypt는 ACME 프로토콜을 사용하여 도메인 소유권 검증과 인증서 발급, 갱신 과정을 완전히 자동화한다.
Let's Encrypt의 운영 모델과 영향은 다음과 같이 요약할 수 있다.
특징 | 설명 |
|---|---|
비용 | 인증서 발급 및 갱신이 완전 무료이다. |
자동화 | ACME 프로토콜 기반의 자동화 도구(예: Certbot)를 통해 인증서 생명 주기 관리가 가능하다. |
유효기간 | 발급된 인증서의 유효 기간은 90일로 짧게 설정되어 정기적인 갱신과 자동화를 유도한다. |
신뢰 근거 | 주요 소프트웨어 벤더의 루트 인증서 프로그램에 포함되어 대부분의 브라우저와 장치에서 신뢰된다. |
주요 영향 | 웹상의 HTTPS 암호화 트래픽 비율을 급격히 높이는 데 기여했다. |
이 서비스의 등장은 공개 키 기반 구조 생태계에 큰 변화를 가져왔다. 무료와 자동화라는 접근성을 제공함으로써 소규모 웹사이트 운영자도 쉽게 TLS/SSL 인증서를 획득할 수 있게 되었고, 이는 결국 전체 인터넷 트래픽의 암호화 표준을 높이는 결과를 낳았다. 그러나 자동화된 발급 과정은 도메인 유효성 검증에 집중할 뿐, 조직 신원 검증(OV)이나 확장 검증(EV)을 제공하지 않는다는 점에서 기존 상용 인증 기관의 서비스와 차별화된다.
