제 10장 인증서 공개 키를 이용한 디지털 서명

10.1 주요 내용 인증서 소개 인증서를 사용하는 시나리오 인증서 규격 X.509 인증서의 구체적인 내용 공개키기반구조(PKI; Public Key Infrastructure) 인증기관

10.1.1 인증서 인증서의 개념 왜 인증서를 우리가 신뢰하는가? 신뢰를 하기 위한 전제조건 X.509 인증서 관리와 찾기가 편리하도록 만든 인증서비스 구조

인증서란 무엇인가? 공개 키 인증서에 포함되는 내용 이름이나 소속 메일 주소 등의 개인 정보 그 사람의 공개 키 인증기관(certification authority, certifying authority; CA)의 개인 키로 디지털 서명이 되어 있다. 인증기관이 「이 공개 키는 확실히 이 사람의 것이다」라고 인정하는 수단

인증기관이란? 디지털 인증서를 발급할 수 있는 권한을 가지고 사용자의 요청에 따라 인증서를 발급하는 사람이나 기관 인증서를 발급받은 사용자는 해당 인증서를 이용하여 인증을 요구하는 기관에 직접 출두하거나 신분증 등을 제시하지 않으면서도 온라인상에서 자신이 적법한자 임을 증명한다 인증서 속에 들어있는 것 궁극적으로 사용자의 공개 키

10.1.2 X.509 ITU-T 권고안 X.509는 디렉토리 서비스를 정의하는 권고안 X.500 시리즈의 한 부분 이 디렉토리를 공개키 인증서 저장소로 이용할 수도 있다. 각 인증서 속에는 신뢰할만한 인증기관의 개인키로 서명된 사용자의 공개키가 포함되어 있다. X.509는 공개키 인증서를 이용한 인증 프로토콜을 규정한다.

10.1.3 인증서를 사용하는 시나리오 인증서를 사용하는 대표적인 시나리오를 통해서 인증서의 역할을 이해해보도록 하자.

인증기관 트렌트를 이용해서 앨리스가 밥에게 암호문을 보내는 예

10.2 인증서 만들기 한국전자인증의 무료 시험 서비스를 이용해서 클래스1에 해당되는 전자메일 인증서를 실제로 만들어 보자.

10.2.1 한국전자인증의 무료 시험 서비스 e-메일 인증서(디지털 ID라 부르고 있다)를 60일간의 무료 시험판으로 만들어서 제공하는 서비스를 하고 있다. 웹 브라우저만 있으면 온라인에서 바로 발행할 수 있는 서비스이다. 본인 인증은 메일이 도착하는지의 여부만으로 확인한다(베리사인의 클래스1에 해당).

10.2.2 인증서의 작성 한국전자인증에 접속하고 글로벌인증서비스/인증서비스/e-mail 인증서/TRY IT(60일 무료)를 클릭한다. 다음과 같은 등록양식(그림 10-2)이 화면에 나타나게 된다.

한국전자인증의 e-mail 인증서 등록양식

웹브라우저에 표시되는 내용 Organization = KECA, Inc. Organizational Unit = CrossCert Class 1 Consumer Individual Subscriber CA Organizational Unit = Terms of use at www.crosscert.com/rpa (c)01 Organizational Unit = Authenticated by CrossCert Organizational Unit = Member, VeriSign Trust Network Organizational Unit = Persona Not Validated Organizational Unit = Digital ID Class 1 - Netscape Common Name = GilDong Hong Email Address = gildong@novel.ac.kr

개인용 인증서 Gildong Hong CrossCert Class 1… 2007-02…<없음>

자세하게 내용을 표시 Gildong Hong

보다 자세하게 내용을 표시 gildong@novel.co.kr, ...

인증서의 계층 표시 Gildong Hong

10.2.3 인증서 내보내기 홍길동의 인증서를 웹 브라우저로부터 내보내기를 하면 단독 파일로서 인증서를 꺼낼 수 있다. 그 다음 인증서를 일반 편집기에서 읽어보면 다음과 같다.

한국전자인증이 작성한 홍길동의 인증서 -----BEGIN CERTIFICATE----- MIIE5TCCBE6gAwIBAgIQF6tKhH1sFY55TC7o6CZ9IzANBgkqhkiG9w0BAQQFADCBsjETMBEGA1UEChMKS0VDQSwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE8MDoGA1UECxMzVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LmNyb3NzY2VydC5jb20vcnBhIChjKTAxMTwwOgYDVQQDEzNDcm9zc0NlcnQgQ2xhc3MgMSBDb25zdW1lciBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EwHhcNMDYxMjI0MDAwMDAwWhcNMDcwMjIyMjM1OTU5WjCCAVUxEzARBgNVBAoUCktFQ0EsIEluYy4xPDA6BgNVBAsUM0Nyb3NzQ2VydCBDbGFzcyAxIENvbnN1bWVyIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTE0MDIGA1UECxMrVGVybXMgb2YgdXNlIGF0IHd3dy5jcm9zc2NlcnQuY29tL3JwYSAoYykwMTEjMCEGA1UECxMaQXV0aGVudGljYXRlZCBieSBDcm9zc0NlcnQxJzAlBgNVBAsTHk1lbWJlciwgVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSYwJAYDVQQLEx1EaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZTETMBEGA1UEAxMKVGFlSWwgSmVvbjEfMB0GCSqGSIb3DQEJARYQdGlqZW9uQGRqdS5hYy5rcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4whHBeppbO/ZjFmgefxKhKVEkTuSTBwJTubG+4hnQj67/nV1uTiXNdxrIMoHLXH6+tUYUfT3taCHFx4IOsu+I/gWPakzGVM4RbfkijFlWyas0GpGw1AttLK84Bb8Ix05i72TDsGsQBA/4uhObiCIbKskucVbsfs/mhBGD6FXmyMCAwEAAaOCAVQwggFQMAkGA1UdEwQCMAAwbgYDVR0fBGcwZTBjoGGgX4ZdaHR0cDovL29uc2l0ZWNybC5jcm9zc2NlcnQuY29tL0tFQ0FJbmNDcm9zc0NlcnRDbGFzczFDb25zdW1lckluZGl2aWR1YWxTdWJzY3JpYmVyQ0EvTGF0ZXN0Q1JMMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEBBAUAA4GBAGiQNr7YFsV0/FLHXrBDbgMlmuZebMvcwRHAKnDeuhIogPqb+iB/50f2ESGh5tkqPsSLg87Z5Hc5wWEP5U8nIsHK9SlzjfBYSA51KA/2nhB2yo2NCQSE/aY4Xqn3Vi37qCPcpEVYvFQbF2fG2oprrg5x234gRVgMZ5feAIz7UeAE -----END CERTIFICATE-----

10.2.4 인증서의 내용 CertView라는 무료 소프트웨어를 사용하면 인증서의 내용을 자세히 표시할 수도 있다.

인증서의 상세한 내용 (CertView에 의한 표시)

인증서의 상세한 내용 버전(Version) 일련번호(Serial number) 서명 알고리즘 식별자(Signature algorithm identifier) 발행자 이름(Issuer name) 유효기간(Period of validity) 소유자 이름(Subject name) 소유자의 공개키 정보(Subject's public-key information) 발행자 유일 식별자(Issuer unique identifier) 소유자 유일 식별자(Subject unique identifier) 확장(Extensions) 서명(Signature)

10.2.5 인증서의 표준 규격 X.509 인증서의 형식 통일 인증서는 인증기관에서 발행하고, 이용자가 그것을 검증하는 것이 되기 때문에 인증서의 형식이 서로 다르면 매우 불편하다. 가장 널리 사용되고 있는 인증서의 표준 규격은 ITU(International Telecommunication Union)나 ISO(International Organization for Standardization)에서 정하고 있는 X.509 규격이다. X.509는 인증서의 작성/교환을 수행할 때의 표준 규격으로서 많은 애플리케이션에서 지원되고 있다.

X.509의 인증서의 주요 세 부분 서명 전 인증서 디지털 서명 알고리즘 디지털 서명 본체 디지털 서명의 대상이 되는 정보 서명 전 인증서에 서명할 때에 사용하는 알고리즘 디지털 서명 본체 서명 전 인증서에 한 디지털 서명 그 자체

인증서 규격 X.509 개요

10.3 공개 키 기반(PKI) 인증서의 규격만으로는 공개 키의 실제로 운용하기에 불충분하다. 인증서를 누가 어떻게 만들었는지 인증서를 무효는 어떻게 해야 하는지 컴퓨터끼리 데이터를 교환할 때의 형식은 어떻게 하는 것인지 이 절에서는 공개 키를 효과적으로 사용하기 위한 공개 키 기반(PKI)에 대해 설명을 한다.

10.3.1 공개 키 기반(PKI) 공개 키 기반(public-key infrastructure)은 공개 키를 효과적으로 운용하기 위해 정해진 많은 규격이나 선택사양의 총칭이다. 문서 RFC 2822(Internet Security Glossary)참조. 이 문서는 공개키 기반구조(PKI: Public-Key Infrastructure)를 비대칭 암호시스템에 기초해서 디지털 인증서 생성 관리 저장 배분 취소 에 필요한 하드웨어, 소프트웨어, 사람, 정책 및 절차라고 정의한다.

PKI를 개발하게 된 주요한 목적 안전하고, 편리하고, 효율적으로 공개키를 획득하는 데 있다.

10.3.2 PKI 구성 요소 이용자 인증기관 저장소 PKI를 이용하는 사람 인증서를 발행하는 사람 인증서를 보관하고 있는 데이터베이스

PKI 구성 요소

이용자 공개 키를 등록하는 이용자가 행하는 것 키 페어를 작성한다(인증기관이 작성하는 경우도 있다) 인증기관에 공개 키를 등록한다 인증기관으로부터 인증서를 발행 받는다 필요할 경우 인증기관에 신청해서 등록한 공개 키를 무효로 한다 수신한 암호문을 복호화한다 메시지에 디지털 서명을 한다

이용자 등록되어 있는 공개 키를 사용하는 이용자가 수행하는 것 메시지를 암호화해서 수신자에게 송신한다 디지털 서명을 검증 한다

한국의 전자서명 인증관리 체계도

인증기관(CA) 키 쌍의 작성 공개 키 등록 때 본인에 대한 인증 인증서 작성 및 발행 인증서 폐지 이용자가 작성하는 경우도 있다 공개 키 등록 때 본인에 대한 인증 인증서 작성 및 발행 인증서 폐지

등록기관(registration authority; RA) 장점: 인증기관의 일 중 「공개 키의 등록과 본인에 대한 인증」대행을 분담 등록기관에 일을 분담하면 인증기관은 인증서 발행에만 주력 인증기관의 부담을 경감 단점 인증기관은 등록기관 자체에 대한 추가 인증필요 구성 요소확대로 주고받는 것이 복잡 공격의 대상이 되는 지점의 수의 확대로 보안상 취약

저장소 인증서를 보존해 두고, PKI의 이용자가 인증서를 입수할 수 있도록 한 데이터베이스를 말한다. 전화에 있어서 전화번호부와 같은 역할을 한다. 앨리스가 밥의 인증서를 입수할 때 저장소를 이용할 수 있다. 저장소는 인증서 디렉토리라 부르기도 한다.

10.3.3 PKIX 관리 기능 등록(Registration): 초기화(Initialization): CA가 사용자에게 인증서를 발급하기 전에 사용자가 (직접적으로 혹은 RA를 통해서)최초로 CA에게 자신을 알리는 절차 초기화(Initialization): 클라이언트 시스템을 안전하게 작동하기 전에 기반구조의 다른 곳에 저장된 키와 적절한 관계를 가지고 있는 키를 설치하는 것

PKIX 관리 기능 인증(Certification): 키 쌍 복구(Key pair recovery): 한 쌍의 키를 이용해서 암호/복호화를 할 경우에 부득이하게 정상적인 키를 사용하는 것이 불가능 할 경우가 생길 수 있다. 이런 상황에 대비하여 복호화 키를 획득할 수 있는 메커니즘을 제공

PKIX 관리 기능 키 쌍 갱신(Key pair update): 폐지 요청(Revocation request): 모든 키 쌍은 정기적으로 갱신하고 새로운 인증서를 발급받아야 한다. 갱신은 인증서 유효기간이 종료될 때나 인증서가 취소될 경우에 필요한 절차이다. 폐지 요청(Revocation request): 사용자들은 공개 키 인증서를 사용하는 도중에 자신의 공개 키 인증서를 폐지해야할 상황이 생긴다. 폐지 이유는 개인키가 침해를 받았거나 가입 상태가 변경되었거나 이름이 변경될 경우 등이다. 이 경우에 폐지를 원하는 사용자는 CA로 하여금 인증서를 폐지하도록 요청할 수 있다.

PKIX 관리 기능 교차 인증(Cross certification): 두 개의 CA는 교차인증을 위해 정보를 교환한다. 교차인증이란 한 CA1이 다른 CA2에게 인증서를 발급해주는 것 CA1 자신의 공개 키를 CA1자신의 개인 키로 서명하여 보내는 것

PKIX 관리 프로토콜 관리 기능들을 지원하기 위해서 두 개의 대체가 가능한 PKIX 개체 사이의 관리 프로토콜을 정의 RFC 2510 문서에서는 인증서 관리 프로토콜(CMP: Certificate management protocol)을 정의 RFC 2797은 CMS 위에서 인증서 관리 메시지를 정의 CMS는 RFC 2630인 암호 메시지 구문(Cryptographic message syntax)을 나타낸다

10.3.4 인증기관의 역할 키 쌍의 작성 인증서 등록 인증서 폐지와 CRL

키 쌍의 작성 키 쌍을 작성 두 가지 방법 PKI의 이용자 스스로가 수행하는 경우 인증기관이 수행하는 경우 인증기관은 한 쌍의 공개 키와 개인키를 작성 안전한 방법으로 「개인 키를 이용자에게 보내는」 일을 할 필요가 있다. 그 방법은 PKCS #12(Personal Information Exchange Syntax Standard) 규격

인증서 등록 이용자 스스로가 키 쌍을 만들었을 경우에 이용자는 인증기관에 공개 키를 등록하기 위해서 해당 공개 키를 인증기관에 보내고 인증서 작성을 의뢰한다. 인증서를 신청할 때의 규격은 PKCS #10(Certification Request Syntax Standard) 등으로 정해져 있다.

인증서 폐지와 CRL 개인 키의 분실, 도난 등의 경우 인증기관은 인증서를 폐지(revoke)해서 무효화 한다. 또한 개인 키가 제대로 관리되고 있어도 인증서를 폐지할 경우가 있다. 퇴직 등으로 인해 본인이 개인 키를 사용할 권한 상실 이름이 바뀌어 인증서의 기재 내용과 맞지 않게 되었을 경우 등.

인증서 폐지 목록(Certificate Revocation List)  CRL은 인증기관이 폐지한 인증서 목록이다. 구체적으로 말하면 폐지된 인증서의 일련 번호의 목록에 대해 인증기관이 디지털 서명을 붙인 것이다. 인증서의 일련 번호: 그 인증기관이 발행한 인증서에 붙여진 순서 번호 인증서 속에 반드시 기재되어 있다

10.3.5 계층 구조를 갖는 인증서 디지털 서명 검증에 사용하는 인증기관의 공개 키는 어떻게 하면 「바르다」라고 판단할 수 있는 것일까? 이를 위해 인증기관의 공개 키에 대해 다른 인증기관이 디지털 서명을 하는 것으로 인증기관의 공개 키를 검증할 수가 있다. 즉 인증기관의 공개 키 인증서를 작성하는 것이다.

인증서 체인(Chain of Certificate) 이러한 인증절차의 기본적인 요건으로는 각각의 CA가 발행한 다른 CA들에 대한 인증서들이 모두 디렉토리에 있어야 한다. 또한 사용자는 다른 사용자의 공개키 인증서에 이르는 경로를 따라가기 위해 어떻게 CA들이 연결되어 있는지를 알 필요가 있다. X.509는 CA들을 계층구조(트리구조)로 만들어놓았기 때문에 탐색은 아주 간단하다.

계층 구조를 갖는 인증기관

10.3.6 다양한 PKI 공개 키 기반(PKI)이라는 명칭으로부터 우리들은 종종 「권위 있는 인증기관이 공적으로 하나만 존재하고 있다」라고 생각하거나, 또는 「전 세계의 공개 키는 단 하나의 루트 CA 하에서 인증된다」라고 생각하기 쉽다. 그러나 그것은 잘못된 생각이다. 실제로 세계에는 무수히 많은 인증기관이 있다

10.4 인증서에 대한 공격 인증서에 대한 공격과 그 대책을 생각해 보자. 인증서에는 디지털 서명이 사용되고 있기 때문에 디지털 서명에 대한 공격은 모두 인증서에 대해서도 위협이 된다. 주로 PKI에 대한 공격을 중심으로 생각하기로 한다.

10.4.1 공개 키 등록 이전 공격 디지털 서명이 되기 전에 공개 키를 공격 공격방법 디지털 서명이 행하여진 후에는 공격하기 어려워진다 공격방법 밥은 키 쌍을 만들어 공개 키를 인증기관에 등록하려고 한다. 인증기관이 디지털 서명을 수행하기 이전에 적극적 공격자 맬로리가 공개 키를 자신의 것과 살짝 바꿔치기 한다

방어방법 밥이 공개 키를 인증기관에 등록할 때 인증기관의 공개 키를 사용해서 밥의 공개 키를 암호화한다. 또한 인증기관이 밥 본인을 확인할 때 공개 키의 핑거 프린트도 함께 받아 밥을 확인한다.

10.4.2 닮은 사람이 등록하는 공격 예를 들면 밥의 사용자 정보의 이름 부분이 다음과 같이 되어 있다고 하자. Name = Bob       (첫 글자만 대문자)   여기에서 맬로리가 Name = BOB      (전부 대문자) 이라는 다른 사용자 정보를 갖는 공개 키를 인증기관에 등록

10.4.3 인증기관의 개인 키를 훔쳐내는 방법 인증기관의 개인 키를 훔쳐내기 인증기관의 개인 키가 손에 들어오면 누구라도 그 인증기관이 발행하는 인증서를 만들 수 있게 된다.

10.4.4 공격자 자신이 인증기관이 되는 공격 적극적 공격자 맬로리는 자신이 인증기관이되어 인증서를 발급한다. 인증기관이 된 맬로리는 자신의 공개 키라도 「이것은 밥의 공개 키이다」라고 주장하는 인증서를 자유롭게 발행할 수 있다. 그리고 그 인증서를 앨리스에게 보낼 수도 있을 것이다. 인증기관을 신뢰할 수 없으면 인증서가 아무리 바르더라도 그 공개 키를 사용해서는 안 된다

10.4.5 CRL의 허점을 찌르는 공격(1) 공개 키가 무효가 되고나서 인증서 폐지 목록(CRL)이 앨리스에게 도착하기까지는 시간이 걸린다. 적극적 공격자 맬로리는 CRL이 도착할 때까지의 시간차를 이용한 빠른 공격을 시도한다.

이런 공격에 대한 대책 공개 키가 무효가 되면 가능한 한 빨리 인증기관에 전한다(밥) CRL은 신속하게 발행한다(트렌트) 공개 키를 이용하기 전에는 공개 키가 무효가 되지 않았나를 재확인한다(앨리스)

10.5 인증서에 대한 Q&A 여기에서 인증서에 대한 이해를 높이기 위해 Q&A 형식으로 정리해 보자.

10.5.1 인증서의 필요성 의문 인증서의 필요성을 모르겠다. 인증기관의 인증서를 사용해서 공개 키를 입수하는 것과, 공개 키만을 받는 것과는 같은 것이 아닌가? 답 신뢰할 수 없는 경로(예를 들면 메일)로 공개 키를 입수하는 경우에는, 앞에서 말한 것 같은 중간자(man-in-the-middle)공격이 가능해 진다. 앨리스는 밥의 공개 키라고 생각했는데, 실은 입수한 것이 적극적 공격자 맬로리의 공개 키일지도 모른다.

신뢰할 수 있는 공개 키를 입수할 수 있다면 인증기관은 불필요하다. 신뢰할 수 있는 인증기관의 공개 키를 가지고 있고, 인증기관의 본인 확인을 신뢰한다면, 그 인증기관이 발행한 인증서에 의해 입수한 공개 키는 신용할 수 있다.

10.5.3 인증기관에 대한 신뢰 의문 인증기관의 기능은 대강 이해를 했지만, 결국 맴도는 것 같은 느낌이 든다. 공개 키를 신뢰하기 위해서는 인증서를 발행한 인증기관을 신뢰해야 하는데, 그렇다면 인증기관은 어떻게 신뢰하는 것일까? 다른 인증기관에 의한 인증서가 있다고 하더라도, 이번에는 그 인증기관을 어떻게 신뢰할까라고 하는 문제가 생기는 것은 아닌가?

답 이 의문은 정당하다. 어떻게 해서 우리들이 은행에 돈을 맡길 수 있는 것인가, 지갑에 들어있는 지폐를 가게에서 사용할 수 있다고 생각하는 것은 왜인가, 레스토랑에서 나오는 음식을 먹어도 안전하다고 생각하는 것은 왜인가와 같은 질문이다. 인증기관을 신뢰하는 이유는 복수의 신뢰할 수 있는 정보원으로부터 얻은 정보에 근거하고 있는 것이다.