CHAPTER 6 CERTIFICATES

1. CHAPTER 6CERTIFICATES CAI & SIMULATION LAB. 한기준 (박사3) 강선모 (박사2) 김진규 (석사3) 간상우 (석사3) 서인규 (석사1) CAI&Simul

2. 목차 • 인증서의 정의 • 인증서의 소개, 인증 경로. 유효기간과 취소 • 공개-개인 키 쌍의 관리 • 키 쌍의 생성 • 개인키 보호 • 키의 갱신 • 서로 다른 형식을 가지는 키의 관리 • 인증서의 발행 • 인증서 신청, 생성, 갱신 • 주체 인증 • 지역 등록 기관 • 인증서의 분배 • 서명이 포함된 인증서 • 디렉토리 서비스를 통한 분배 • 기타 분배 방법 CAI&Simul

3. 인증서의 정의 • Webster Dictionary : “a document containing a certified statement, especially as to the truth of something” • 전자 상거래 : 인증서 사용자의 집단에 의해 인식되고(recognized), 믿을 수 있는(trusted) 특정 인증 기관의 전자 서명이 첨부된 정보의 집합 ( 다양한 형태의 인증서가 다양한 목적으로 사용된다) • 대표적인 인증서:공개키 인증서(Public Key Certificate) • 키 값은 person, device, 또는 다른 개체(entity)등과 연관된다. • 공개키 인증서는 인증기관(Certification Authority)이라 불리는 개인(person) 또는 개체(entity)에 의해 전자 서명(digitally signed)된다. • 공개키 암호화와 서명 기술은 전자 상거래의 핵심 기술 :인증서는 이러한 기술을 적절히 사용할 수 있게 하는 핵심 기술. CAI&Simul

4. 1. 공개키 인증서 • 공개키 사용자 (Public Key User) : • 공개키 사본(copy)을 필요로 하는 메시지의 발신자(message originator) • 전자 서명의 검증자(verifier) • Certification authority(CA) : 인증서(CERT)를 발행 • Manual Public-Key Distribution • diskette등에 직접 공개 키를 담아 분배하는 방식 • 공개키 인증서 (Public key Certificate) • 공개키 값(public key value)과 • 인증서 주체(certificate’s subject)를 유일하게 식별하는 정보를 포함한다 • 해당 개인키를 소유하고 있는 person, device, (other) entity. • 인증서의 주체가 개인, 또는 다른 종류의 법적인 개체(legal entity)일 때 이를 CA의 가입자(subscriber)라 한다. CAI&Simul

5. 간단한 공개키 인증서 CA 개인 키 인증서(CERT) 주체의 식별 정보 (Identification Info.) 주체(Subject)의 공개키 값 Digital Signature 생성 인증국(CA)의 이름 인증국(CA)의 전자서명 CAI&Simul

6. 간단한 공개키 인증서 (2) • 비교적 간단하다. • 구현하기에 경제적이다. • 인증서의 중요한 특징을 가진다. • Certificates can be distributes without needing to be protected via the traditional communications security service of confidentiality, authentication, and integrity. • 공개키 값(따라서 인증서도)은 기밀성(confidentiality)을 유지할 필요가 없다. 인증(authentication)과 무결성(integrity)도 요구되지 않는다. • CERT’s Self Protecting : (CA의 전자서명: 인증과 무결성을 제공한다.) • 침입자가 인증서를 위조한 경우 : CA의 서명이 무효화된다. • Primary Benefit: 공개키 사용자는 한 party의 공개키(CA’s public key) 만을 알면, 다른 많은 party의 믿을 수 있는 공개키를 얻을 수 있다. CAI&Simul

7. 인증서 경로 • 하나의 CA에서 전세계의 모든 사용자에게 인증서를 발행하고, 모든 사용자들이 이 인증서를 신용한다면 공개키 분배 문제를 해결할 수 있다 :현실적으로 불가능 : 여러개의 CA를 둔다. • 사용자가 (안전하게) 통신하기를 원하는 상대방의 인증서를 발행하는 CA의 공개키를 이미 가지고 있다고 가정할 수는 없다. • CA의 공개키를 얻기위해 또 다른 인증서를 찾아서 이용할 수 있다. ( 공개키 사용자가 공개키를 이미 안전하게 소지하고 있는 CA에서 발행한 (다른) CA 공개키의 인증서) • 인증서 개념을 재귀적(recursively)으로 적용, 많은 수의 CA 공개키를 얻을 수 있다. • Certificate chain, Certificate path • 공개키 사용자는 root CA의 공개키를 먼저 얻는다. • 공개키 사용자는 root에서 원하는 상대방(nola)까지 certificate path가 설정되어 있으면, 이들 중간 CA를 통해 공개키를 인증받을 수 있다. CAI&Simul

8. 인증서 경로 (2) 공개키 사용자 Root Public Key (인증국 A) Certificate 2 주체 =인증국 A Certificate 1 주체 공개키 주체 =인증국 B 발행인 = 인증국 B 주체 공개키 발행인=인증국 A Certificate 3 주체 = 노라 주체 공개키 Nola Public Key key Pair 발행인 = 인증국 C CAI&Simul

9. 유효기간, 인증서 취소 • 기본적인 인증서(basic Certificate)와 인증 경로 모델(Certification path model)의 실제 응용을 위한 개선 • Timeliness가 반드시 인식되어야 한다. • 공개-비밀 키 쌍이 항상 유효하다고 가정하지 않는다. • 따라서 인증서의 유효 기간이 정해져야 한다. • Start date/time과 Expiration date/time을 정의 • 인증서 기간이 만료되면 새로운 인증서를 발행한다. • 인증서의 철회 • ex) 키 값이 알려진(compromised) 경우, 인증서 철회 가능. CAI&Simul

10. 법(法)적 관계 • 인증국과 가입자 사이에 두 가지 중요한 관계가 성립한다. • Closed Community: 인증국과 가입자는 모두 하나의 법적 개체(one legal entity) ( 가능하면 비공식적으로) 또는 confederation다. • 예) 고객이 모두 은행 ATM 서비스의 고객인 경우 • 은행이 CA를 겸한다. • Open Community: 가입자 측에서 볼 때, CA는 독립된 법적 개체 • 상업 방송 서비스 제공자, CA 서비스 제공자. • 서비스에 대한 요금을 지불하는 사용자에게 인증서를 발행 • 이러한 CA를 Third-party CA라 한다. CAI&Simul

11. 법(法)적 관계 • CA의 기능은 아니지만, CA는 다음의 기능을 공고히 한다. (1) 주체 인증 • CA는 인증서의 공개키에 대응되는 개인키의 소유자가 • 인증서내에 명기된 인물과 동일한지를 확인해야 한다. (2)개인키의 보호 • (1)에서 인증된 주체만이 개인키를 사용하는지 계속적으로 확인하게 된다. CAI&Simul

12. 2. 공개-개인 키 쌍의 관리 Key-Pair의 생성 • 새로운 키 쌍이 생성될 때 • Private-Key를 Key-Pair holder system과 , back-up과 기록보관(archival)이 필요한 경우에는, back-up과 기록보관(archival) 시스템으로 • Public-Key를 하나 이상의 인증국(certificate authority)으로 (인증서 생성 함수의 입력으로 for input to certificate generation functions) 의 안전하게 전송해야 한다. CAI&Simul

13. 키 쌍의 생성 (2) • Key-pair의 생성 장소 • Key-pair holder system에서 key-pair가 생성된다. • 전자 서명을 위한 키 쌍은 부인봉쇄(non-repudiation)을 지원하는데 이용된다. • private-key의 수명(lifetime)동안 원래의 환경을 떠날 수 없다 • 다른 기관(party)이 private-key 정보를 얻을 수 없다 - 증거물 역할. • ANSI X9.57 standard에서 사용되는 예 • Central System: Key-Pair는 특정 중앙 시스템에서 생성되고 안전하게 key-pair holder 시스템으로 전송된다. • 중앙 시스템이 더 많은 자원과 성능을 가지므로 양질( 예측, 계산이 어려운)의 key-pair를 생성할 수 있는 장점이 있다. • 중앙 시스템이 CA의 기능을 가지는 것이 좋다. • 한 시스템에서 키 생성, backup, archival을 수행하는 것이 편리하다. CAI&Simul

14. 개인 키 보호 • 공개키, 공개키 인증서의 사용 : 인증된 person, device, entity만이 개인키를 사용한다는 전제하에 수행되는 기술 • 허가되지 않은 개인키 사용 방지가 중요하다. • 개인키의 저장 1. tamper-resistant hardware module, 또는 token에 보관 • ex) smart card, PCMCIA card 등 • 비용이 많이 든다. 2. 암호화된 데이터 파일로 일반저장 매체에 저장 • 전자지갑 등에서 사용하는 방식 • password나 PIN을 사용한다. • 또는, 정당한 개안키 사용자만이 알고 있는 password나 PIN으로부터 수학적으로 계산된 대칭 키(symmetric key)를 이용할 수도 있다. CAI&Simul

15. 키 쌍의 갱신 • 실제 암호화 제품은 항상 공개/개인 키 쌍을 갱신할 수 있도록 준비가 되어 있어야 한다. • 정상적인 만료기간, 키가 노출되는 등의 예외적인 상황에 대비. • 새로운 키가 생성되면 새로운 인증서가 생성되고, • 이전의 인증서는 취소된다. • 만료기간 이전에 취소 가능 CAI&Simul

16. 서로 다른 형식을 가지는 키의 관리 • 하나 이상의 키 쌍(인증서)이 필요한 경우 -사업, 정책적인 이유 • ex) 두 개 이상의 신용 카드를 소지 • ex) 서명과 암호화를 목적으로 서로 다른 키를 소지 • 서명을 목적으로 하는 키의 관리 1. 서명용 개인키는 수명동안 노출되지 않도록 한다. • 부인 봉쇄를 목적으로 한다. • 하나의 모듈에서 생성, 사용, 파괴된다. 2. 키 손실에 대비한 보관이 일반적으로 불필요 • 키가 분실되면 새로운 키를 쉽게 생성할 수 있다. 3. 서명용 키는 보관(archived)될 필요가 없다. • 1.에 위배 4. 전자서명 공개키(인증서)는 보관될 필요가 없다. • 실질적으로 사용하지 않는 오래된 서명의 검증에 필요. CAI&Simul

17. 서로 다른 형식을 가지는 키의 관리 (2) • 암호화를 목적으로 하는 키 쌍의 관리 1. 암호화용 공개키는 backup, archived된다. • 암호화된 정보를 복구하는 유일한 방법이 된다. 2. 알고리즘에 따라, 암호화용 공개키는 backup/archived되거나 그렇지 않을 수 있다. • Ex) RSA 키 전송의 경우, 공개키는 저장된 암호화된 데이터의 복구에는 불필요. Diffie-Hellman 키 교환의 경우, 암호화된 데이터의 복구에 공개키가 필요, 즉 공개키의 backup이 필요하다. 3. 암호화용 비밀키는 비밀리에 파기될 필요가 없다. (1)의 이유로 파기하지 않는 것이 유리하다. CAI&Simul

18. 인증서의 발행 • CA가 인증서를 발행하기 전에, 고객(subscriber)는 CA에 등록이 되어있어야 한다. • 일반적으로 certificate application에 의해 수행 • 이를 통해 CA와 고객사이의 관계, 특정 고객의 저장소가 설정된다. • 환경에 따라, 특정 고객에게는 간단한 등록과정이 적용 될(되지 않을) 수 있다. • 고용주가 고용인들의 인증서를 발행하는 경우(등록 과정은 자동화) • 제 3인증기관의 경우: • 명시적인 등록과정이 중요하다. • 가입자의 동의가 필수 CAI&Simul

19. 인증서의 발행 (2) • 인터넷을 이용한 인증서의 발행 • online을 이용한 등록 • 사용자의 web browser과 • 서버의 front-end CA service사이에서 이루어진다. • CA는 공개키 값, 고객의 정보가 전송 중에 변조되지 않았는지를 확인한다. • 지속적인 고객 정보의 획득이 필요 - online또는 관련 database이용 • 일반적인 사용 예 1. Off-line :고객이 직접 출석, 신분증을 제시하고, password를 할당 받는다. 2. 이후, 인증서를 신청, 전송받는다. CAI&Simul

20. 인증서의 생성 • 인증국이 필요한 인증서 관련 정보를 제출받는다. • 인증국은 위 정보들이 정확한지 검증한다. • 인증서는 인증국의 private-key로 서명된다. • 인증서의 사본은 가입자(subscriber)에게로 보내지며, 필요하다면, 접수 확인 여부가 가입자로부터 반환된다. • CA 서비스로, 인증서 사본이, 출판, 디렉토리 서비스와 같은 인증서 저장소(certificate repository)에 제출된다. • 선택적인 CA 서비스로, 인증서 사본이 인증국의 저장소에 보관된다. • 인증국은 적당한 인증서 생성의 세부 과정을 기록한다. CAI&Simul

21. 주체의 인증 • 인증서 발행 이전에 인증국은 반드시 private-key를 소유한 공개키 사용자(person, device 또는 entity)의 identity가 인증서에 포함된 public-key와 대응되는지 확인해야 한다. • 인증 기법 • 직접출석(personal presence) • 증명서(Identification documents) CAI&Simul

22. 지역(local) 등록 기관 LRA(Local Registration Authority)의 기능은 다음을 포함한다. • 한 인증국이 모든 고객을 직접적으로 확인하는 것이 불가능 • 직접 인증서를 발행하지는 않는다. • 등록(registering) , 재 등록(de-registering), 가입자의 속성 변경 • 가입자의 확인과 인증(identifying and authenticating) • key-pair의 인증요구나 인증서 생성요구 또는 backed-up keys의 재생 요구를 받아들인다. • 인증서의 정지나 취소(suspension or revocation) 요구를 받아들이고 인증한다. • 인증받은 사용자에게 직접적으로 personal token을 분배하거나, 이들로부터 폐기된 token을 회수한다. CAI&Simul

23. 인증서의 갱신 • 모든 인증서는 수명의 제한을 받는다. • CA에서 “취소-revocation”의 역할을 담당한다. • 인증서는 , 보통 유효기간의 만료로 대치된다. • 키 쌍이 대치되면, 인증서도 대치될 필요가 있다. • 인증서의 갱신은 고객에게 “투명하게” 수행되어야 한다. • 어떤 암호화 제품은 사용자 개입없이, 키의 만료기간을 인식, 갱신하며, CA와 통신이 가능하다. • 고객의 신상 정보나 CA의 정책 변경 시 고객을 참여시켜야 한다. • 고객은 인증서의 갱신을 인지하고, 새로운 인증서의 획득 여부를 공표하여야 한다. CAI&Simul

24. 4. 인증서 분배 • 원거리에 있는 상대방에게 전송할 데이터를 암호화 하거나 디지털 서명을 검증하게 위해, 상대방의 공개키 사본을 얻을 필요가 있다. • 부가하여, 완전한 인증 경로를 형성하기 위해 필요한 인증국의 인증서도 필요하다. • 보안의 문제가 아닌 데이터 보급(dissemination)의 문제 • 인증서는 안전한 시스템 또는 프로토콜을 통해 전송되지 않아도 무방 • certificate’s self protecting CAI&Simul

25. 서명이 부가된 인증서 • 전자 서명을 이용한 인증서 분배 방법 • 자신의 전자 서명에 인증서의 사본을 attach시킨다. • 서명의 검증을 원하는 사람은 (공개키 사용자) 누구나 인증서를 획득할 수 있다. • 다른 CA가 발행한 서명자 CA의 공개키 인증서를 같이 attach할 수도 있다. • 통신과 저장 용량의 낭비를 막을 수 있다. CAI&Simul

26. 디렉토리 서비스를 통한 분배 • 메시지 암호화를 위해 공개키 기법을 이용하는 경우, 메시지 발신자는 모든 수신자에 대한 인증된 공개키를 획득해야 한다. • 메시지 발신자는 지역적으로 (locally)저장된 인증서 사본만을 구할 수 있다. 즉, 다른 인증서가 필요하다면 이를 직접 찾아야만 한다. • 이러한 상황을 지원하기 위한 인증서를 분배하기 위한 공개(public) 디렉토리 서비스 또는 저장소(repository)가 특히 적당(attractive) • 메시지 발신자는, 단순히 디렉토리 query를 통해, 수신자의 인증서를 얻을 수 있다. • ITU X.500 Directory Service : 서비스 제공자, 정부, 개인 단체 등 국제적인 규모의 상호 연결된 시스템으로 구성되는 다목적 분배 서비스를 구성하기 위한 기술 표준. • 특정 소프트웨어 환경을 위한 디렉토리 시스템 • Microsoft Exchange Directory, Lotus Note Directory, Novell’s Netware Directory Directory Service(NDS) • LDAP(internet Lightweight Directory Access protocol) • X.500과 호환 • 단순한 access protocol- 기반 디렉토리 database기술은 제공하지 않는다. CAI&Simul

27. 기타 분배 모델 • 여러가지 방법이 인증서를 분배하는데 사용될 수 있다 • 인증서는 특별한 보호 메커니즘을 필요로 하지 않으며, 안전하지 않은 채널을 통해 전송이 가능하다. • 예) S/MIME과 MOSS사양은 (chapter.5) e-mail을 통해, 인증서를 신청하고 전송 받을 수 있는 메시지 형식을 정의. • Web은 적합한 표준과 규정이 정의된다면 특정 서버 보다도 보편적인 인증서 보급 수단이 될 전망. CAI&Simul

28. Version key Serial Number Signature algorithm Identifier Issuer(CA) (X.500 name) Validity Period (start and Expiry Dates/Time) Subject (X.500 name) Subject Public Key Information Algorithm Identifier Public Key Value Issuer Unique Identifier Generate Digital Signature Not it ver1. Subject Unique Identifier Certification Authority’s Digital Signature X.509 Versions 1 and 2 Certification format 6.5 X.509 Certification Format • ISO/IEC/ITU X.509 • 가장 널리 알려진 표준 공개키 인증 형식 • 보증서 형식 • version 1 : 1988 • version 2 : 1993 • version 3 : 1996 CAI&Simul

29. X.500 Names • X.509 보증서는 X.500 directory system을 사용 • Version 1&2는 X.500 names사용: subject와 issuers 식별하기 위해 사람, 기관, 장치와 같은 확실히 구별되는 이름, 실제 개체와 관계 있는 entry DN은 개체의 속성을 나타내는 값을 포함하고 있다. EX> common name, telephone number, e-mail address DN은 RDN을 이용하여 인접한 하위 entry의 DN과 결합하여 구성된다 DN 모든 entry가 트리 구조로 구성 단일 root와 여러 개의 정점으로 구성 각 정점은 디렉토리 entry와 일치, DN을 포함 DIT 인접한 하위 entry로부터 자신의 하위 entry 를 구별 각 entry에 관한 하나 이상의 속성 값에 관해 상술 EX) Common Name = Roy Mills RDN CAI&Simul

30. Common Attribute Types: C : Country O : Organization CN : Common Name RDN: C=US Root RDN: O=Sharon’s Steelcorp. Inc. Canada USA RDN: CN =Roy Mills Canadian Government Danille’s Machine Makers U.S. Government Sharon’s Steelcorp Roy Mills Attribute Attribute Common NameRoy Mills Tel. +1 212 222-2222 Attribute Attribute Distinguished Name DN = {C = US, O = Sharon’s Steelcorp, Inc., CN= Roy Mills} E-mail Rmills@sharons.com Title CEO Figure 6.4 Example X.500 Name Construction CAI&Simul

31. X.500 Names • Issuer unique identifier & subject unique identifier field • X.509 version 2에 포함 • 목적: X.500 access control facility를 지원하기 위해 • X.500 name을 재사용하는 것을 방지 • Unique Identifier로 해결 • 문제점 • 관리의 어려움 • implementation에서 무시 또는 생략 • View에서 숨겨지는 경향 EX> 같은 이름의 사람이 존재 할 때 문제점 발생 X.500 name이 확실함(uniqueness)을 확인함으로써 해결 Relative Distinguish Name을 이용 EX> employee number 이용 CAI&Simul

32. Object Registration(1) • algorithm identifier : CA의 서명과 공개키가 사용된 알고리즘을 식별 • Algorithm identifiers a) Digital signature, using DSS with the SHA hash function b) Digital signature, using RSA with the MD5 hash function c) Encryption Key establishment, using RSA key transport d) Encryption key establishment, using a certified Diffie-Hellman technique • Object registration system : Object identifier mechanism • Object identifier • top-most level에 할당된 값(value) • 0 (for ITU use), 1(for ISO use), 2 (for joint ISO-ITU use) CAI&Simul

33. Figure 6.5 Object Identifier Example Object Identifier: {Joint-ISO-ITU-T(2) country(16)us(840) organization (1) sharons (15678) algorithms (1) sharons-super-algorithm (66) } O(ITU-T) 1(ISO) 2 (Joint-ISO-ITU-T) 16 (country) 840 (US) 1 (organization) 15678(sharons) 1 (algorithms) 4 (policies) 66 (sharons-super-algorithm) CAI&Simul

34. Object Identifier Algorithm Source of Specification { ISO(1) identified-organization (3) oiw (14) secsig (3) algorithm(2) 29 Digital signature : RSA with SHA-1 NIST Open Systems Environment Implementors’ Workshop(OIW) agreement {ISO (1) member-body (2) us (840) x9-57 (10040) x9algorithm (4) dsa-with-sha1 (3)} Digital signature : DSA with SHA-1 ANSI X9.57 {Joint-ISO-CCITT (2) country (16) us (840) organization (1) us-government (101) dod (2) infosec (1) algorithms (1) 2 Digital signature : DSA with SHA -1 U.S. Department of Defense MISSI program {ISO (1) member-body (2) us (840) rsadsi (11340) pkcs (1) pkcs-1(1) md5withRSAEncryption (4)} Digital signature : RSA with MD5 RSA Data Security , Inc. PKCS #1 Table 6.2 Some Common Algorithm identifiers CAI&Simul

35. Extended(version 3) Certificate Format (1) • X. 509 version 1 & 2의 결점 발견(1993-94) • X. 509의 요구사항 • (a) 한 subject에 대한 여러 개의 보증서와 키-쌍이 할당되었을 때, subject와 보증서 사이에 구분 가능 • (b) 추가적인 subject-identifying information 요구 • (c) 사용자의 신분 확인을 위한 다른 Application 요구 • (d) 보증서 사용자는 발행된 보증서가 어떤 목적으로 사용되는지 확인 요구 • 다른 보증서 정책을 따르는 다른 보증서는 다른 목적으로 사용 • (e) 보증서 경로가 길고 복잡한 것을 허용하지 않음 • 인증할 보증서에 대한 보증서 부분 집합만을 인식 새로운 형태의 X.509 version 3로 확장 CAI&Simul

36. Extension Type Crit./Non-crit. Extension Field Value Extension Type Crit./Non-crit. Extension Field Value Extension Type Crit./Non-crit. Extension Field Value Figure 6.6 X.509 version 3 Certificate Version Certification Authority Private Key Serial Number Signature algorithm Identifier Issuer(CA) X.500 name Generate Digital Signature Issuer (Certification Authority) X. 500 Name Validity Period (start and Expiry Dates/Time) Subject X.500 name Extension을 인식하기 위해 Simple flag: Non-critical, critical Algorithm Identifier Subject Public Key Information Public Key Value Optional Issuer Unique Identifier Subject Unique Identifier Extensions Certification Authority’s Digital Signature CAI&Simul

37. Naming in X.509 Version 3 • 기존의 version과 X.509 version 3의 차이점 • naming과의 관계 • 각 entity들은 여러 개의 이름(name)을 가질 수 있다. • X.509 표준에서 인식되는 name 형식 • internet e-mail address; • Internet domain name; • X.400 e-mail address; • X.500 directory name; • EDI party name; • Web Uniform Resource Identifier; • Internet IP address; • Registered identifier; • other name CAI&Simul

38. Standard extension group Key and policy information subject와 issuer key 정보 indicator of certificate policy. Implementation of PKI에 사용 보증서 사용 목적 제한 Subject and Issuer attributes subject와 issuer의 name 표현 subject에 대한 추가적인 속성 정보 제공 Certification path constraint 다른 기관이 우리의 하부구조에 연결 정보 제공 Extension related to certificate revocation lists(CRLs) Standard Certificate Extensions ISO/IEC, ITU, ANSI X9 표준 기관에 의해 발달 CAI&Simul

39. Standard Certificate Extensions • Key and Policy Information Extension • Authority Key Identifier • 다양한 보증서-서명 키와 구별하기 위해 사용 • key identifier • 다른 보증서 pointer • key identifier와 certificate pointer • Subject Key Identifier • Key Usage • Private-key Usage Period • Certificate Policies • Police Mapping CAI&Simul

40. Subject and Issuer Attributes extensions Subject Alternative Name : 보증서가 X.500 디렉토리 시스템을 사용하지 않고 고유의name 형태를 사용하는 응용(E-mail) Issuer Alternative Name : 하나 이상의 발행자 name을 포함 Subject Directory Attributes :subject에 대한 속성 값 제공 Certification Path Constraints extensions Basic Constraints :subject가 CA 또는 객체로 행동 할 것인가를 표시 name Constraints :name-space 제한 Policy Constraints :인증 정책에 관한 constrain Standard Certificate Extensions CAI&Simul

41. 6.6 Certificate Revocation • 취소 결정은 CA의 책임. • subscriber는 보증서 취소 요청 • 자신의 보증서의 경우 • CA은 subscriber의 보증서 취소 • 권한이 있는 환경하에서 • 타인도 보증서 취소를 요청 • 고용주와 고용자 사이에서 발생 • CA는 취소 요청 source를 인증 • local registration authority의 책임 • 보증서의 유효 기간을 제한 • 유효 기간 • start date/time + expiration date/time • 기간은 발행 CA의 정책 문제 • 유효 기간이 만료되기 전에 보증서를 포기하는 경우 • 직원이 회사 퇴사시 • name의 변경, subject와 보증서 사이의 관계 변경, 비밀키 손상 CAI&Simul

42. Certificate Revocation Lists(CRLs) • CA은 보증서가 취소되었을 때 취소되었음을 공개 • CRL : CA이 서명한 취소 보증서의 time-stamped 리스트 • 서명과 유효 기간을 확인, 가장 최근의 CRL을 요구, serial number가 CRL에 존재 여부 확인 • 보증서는 발행기관의 정책에 따라 발행 • CRL은 주기적으로 리스트에 추가 • CRL은 공개키 보증서와 같은 방법으로 분배 • 데이터의 무결성을 강력히 요구하지 않음 • 안전한 통신 경로와 신뢰하는 서버를 요구 않음 • 취소 방식의 제한 • CRL 발행 시기 제한 • Off-cycle CRL의 경우 CAI&Simul

43. Figure 6.7 Simple Certificate Revocation Lists(CRLs) Issuer Name CRL Issue Time/Date Certification Authority’s private Key Certificate Serial Number Revocation Time/Date Certification Serial Number Revocation Time/Date Certification Serial Number Revocation Time/Date Generate Digital Signature Issuer’s Digital Signature CAI&Simul

44. Broadcast Revocation Lists(1) • Pull method of CRL distribution • 필요할 때 보증서를 디렉토리에서 회복시키는 방법(periodic revocation list의 성질) • Push method : 취소 리스트를 시스템에 알리는 방법 • 안전한 통신 경로를 사용(secure e-mail, protected transaction protocol) • 중요한 취소의 경우 빨리 알릴 수 있다는 장점 • 문제점 • 안전한 분배를 요구 • 많은 통신량 • 결정 문제 • 표준 문제 CAI&Simul

45. Broadcast Revocation Lists(2) • MISSI(The U.S. Department of Defense Multi-level Information System) • Broadcast Revocation Lists는 MOSAIC 키 관리 개념에서 사용 • 주기적인 취소 리스트를 사용하여 구현 • 키 손상이 발생할 때, broadcast 방식 사용 • X.509 version 2 형식을 사용하여 새로운 indirect CRLs구현 • CKL (Compromised Key list)분배는 secure e-mail을 이용 • secure e-mail을 사용함으로써 Broadcast revocation list의 문제점 해소 • entire network에서 사용 • global, open commercial infrastructure에 부적합 CAI&Simul

46. Immediate Revocation • 주기적인 취소의 경우 키 손상과 같은 경우 큰 손해 • 취소된 보증서가 즉시 사용될 수 있는 취소 방법 • real-time revocation checking or online status checking의 경우 • 보증서 실행을 검증하기 위해 • CA와 협력하여 보증서 기간을 확인 • 시스템은 발행 CA과 협력하여 online 상의 거래를 실행 • 안전한 transaction: 현재의 보증서 취소 상태를 반송 • CA의 서명을 발생, 서명을 검증하기 요구 • Real-time 취소 검사는 어떤 환경에서든 잘 작동한다. • 비용에 대한 문제가 발생(operation 비용) • (a) Removal From repository: 가장 간단한 접근법 • (b) Trusted certificate server or directory: (a)를 강화 • (c) Fine granularity periodic CRLs CAI&Simul

47. Revocation Request Issue of CRL 1 Issue of CRL 2 (a) (b) (c) (d) (e) Time Compromise Event Revocation Time Figure 6.8 Revocation Time-line Revocation Process Time-line (a) Issue of CRL 1 : 취소가 발생하기 전에 발행한 CRL (b) Compromise occurs (c) Revocation Request (d) Revocation Time (e) Issue of CRL 2: 취소가 포함된 CRL을 발행하고 공개 CAI&Simul

48. Revocation Process Time-line • Period (b) - (c) • 손상이 발생 단계 • CA는 손상에 대해 알지 못함 • subscriber는 위험 요소 발생 가능성 존재 • Period (c) - (b) : • 취소에 대해 공개하지 않는 단계 • CA는 손상에 대한 알고 있음 • Period (d) - (e) • 취소되었음을 공개 단계 • 사용자는 CRL 2가 발행될 때 까지 알지 못함(periodic CRL의 경우) • 사용자가 이 기간에 취소 되었음을 앎(Immediate revocation의 경우) • Period after (e) • CA의 책임 완료 단계 • 취소될 보증서를 사용할 경우, 사용자의 책임 CAI&Simul

49. Version (of CRL Format) Signature Algorithm(for CRL Issuer’s Signature) CRL Issuer (X.509 Name) This Update(date/time) Next update(Date/Time)(Optional) CRL Issuer’s Private Key Generate Digital Signature User Certificate (Serial Number) Revocation Date CRL Entry Extensions User Certificate (Serial Number) Revocation Date CRL Entry Extensions CRL Extensions CRL Issuer’s Digital Signature Figure 6.9 X.509 CRL Format CAI&Simul

50. General Extensions • Standard Extension • General extensions • CRL distribution points • Delta-CRLs • remove from CRL • Indirect CRLs; and, • Certificate suspension • Certificate hold • Authority Key Identifier • Issuer Alternative Name • General extension • CRL Number • Reason Code • Invalidity Date • reason code extension • Key Compromise • CA Compromise • Affiliation Changed • Superceded • Cessation of Operation CAI&Simul