CHAPTER 6 CERTIFICATES CAI & SIMULATION LAB. 한기준 (박사3) 강선모 (박사2)

Presentation on theme: "CHAPTER 6 CERTIFICATES CAI & SIMULATION LAB. 한기준 (박사3) 강선모 (박사2)"— Presentation transcript:

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

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

3 대표적인 인증서 : 공개키 인증서(Public Key Certificate)
인증서의 정의 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 (Identification Info.)
간단한 공개키 인증서 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) Nola 공개키 사용자 Certificate 2 주체 =인증국 A Certificate 1 주체 공개키
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) 주체 인증 (2)개인키의 보호
인증서내에 명기된 인물과 동일한지를 확인해야 한다. (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) 을 통해, 인증서를 신청하고 전송 받을 수 있는 메시지 형식을 정의. Web은 적합한 표준과 규정이 정의된다면 특정 서버 보다도 보편적인 인증서 보급 수단이 될 전망. CAI&Simul

28 6.5 X.509 Certification Format
Version 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 Subject Unique Identifier Certification Authority’s Digital Signature key X.509 Versions 1 and 2 Certification format Not it ver1. Generate Digital Signature ISO/IEC/ITU X.509 가장 널리 알려진 표준 공개키 인증 형식 보증서 형식 version 1 : 1988 version 2 : 1993 version 3 : 1996 version: x.509의 버젼을 기입한다. serial number : CA이 발행, 이 보증서의 유일한 식별 번호이다. signature algorithm identifier:CA이 보증서에 서명할 때 사용한 서명 알고지즘 Issuer: 발행 CA의 x.500 name validity : 보증서의 시작 만료 시간/날짜 subject : 인증 받은 공개키에 대한 비밀키를 유지하는 x.500 이름 subject public-key information : subject에 대한 공개키 값(공개키가 사용된 알고리즘 식별자를 포함) Issuer unique idnetifier : 선택적인 비트 스트링 subject unique identifier : CAI&Simul

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

30 Figure 6.4 Example X.500 Name Construction
Root Canada USA Canadian Government Danille’s Machine Makers U.S. Government Sharon’s Steelcorp Roy Mills Attribute Common Name Roy Mills Tel Title CEO RDN: C=US O=Sharon’s Steelcorp. Inc. CN = Roy Mills Common Attribute Types: C : Country O : Organization CN : Common Name Distinguished Name DN = {C = US, O = Sharon’s Steelcorp, Inc., CN= Roy Mills} 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
{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 Table 6.2 Some Common Algorithm identifiers
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 Digital signature : DSA with SHA-1 {ISO (1) member-body (2) us (840) x9-57 (10040) x9algorithm (4) dsa-with-sha1 (3)} 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 {ISO (1) member-body (2) us (840) rsadsi (11340) pkcs (1) pkcs-1(1) md5withRSAEncryption (4)} U.S. Department of Defense MISSI program Digital signature : RSA with MD5 RSA Data Security , Inc. PKCS #1 CAI&Simul

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

36 Figure 6.6 X.509 version 3 Certificate
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 extension part를 제외하고는 version 2와 동일. extension type: extension type을 표시하는 object identifier value Critical indicator:Critical/Non-critical Public Key Value Optional Issuer Unique Identifier Extension Type Crit./Non-crit Extension Field Value Subject Unique Identifier Extensions Extension Type Crit./Non-crit Extension Field Value Certification Authority’s Digital Signature Extension Type Crit./Non-crit Extension Field Value CAI&Simul

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

38 Standard Certificate Extensions
ISO/IEC, ITU, ANSI X9 표준 기관에 의해 발달 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) 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 Standard Certificate Extensions
Subject and Issuer Attributes extensions Subject Alternative Name : 보증서가 X.500 디렉토리 시스템을 사용하지 않고 고유의name 형태를 사용하는 응용( ) Issuer Alternative Name : 하나 이상의 발행자 name을 포함 Subject Directory Attributes :subject에 대한 속성 값 제공 Certification Path Constraints extensions Basic Constraints :subject가 CA 또는 객체로 행동 할 것인가를 표시 name Constraints :name-space 제한 Policy Constraints :인증 정책에 관한 constrain Subject Alternative Name subject에 대한 하나 이상의 name을 포함하는 field. Issuer Alternative Name :발행자에 대한 하나 이상의 name 포함하는 field CAI&Simul

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

42 Certificate Revocation Lists(CRLs)
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 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 , 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 을 이용 secure 을 사용함으로써 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 Process Time-line
(d) (c) (b) (e) (a) Issue of CRL 1 Compromise Event Revocation Request Revocation Time Issue of CRL 2 Time Figure 6.8 Revocation 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 Figure 6.9 X.509 CRL Format CRL Issuer’s Digital Signature
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) User Certificate (Serial Number) Revocation Date CRL Entry Extensions CRL Extensions Generate Digital Signature CRL Issuer’s Private Key CAI&Simul

50 General Extensions Standard Extension General extension
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

51 CRL Distribution Points
통신 오버헤드와 프로세싱 오버헤드 발생 취소 발생시 CRL에 entry 추가 취소 발생률은 예측 불가 Subject 집단의 크기와 보증서 유효기간에 의해 결정 짧은 유효기간: 높은 수행 비용 등 문제점 발생 X. 509 version 1&2 one for end-user subjects 수용할 수 없는 크기로 증가할 위험요소 가짐 one for other CA 매우 짧은 리스트 CRL 프로세싱 오버헤드 감소 CAI&Simul

52 CRL Distribution Points
X. 509 version 3 & version 2 CRL을 이용 모집단을 분할하여 해결 CA에 의해 최대 크기 제어 CRL distribution point는 name 등으로 식별 CRL Distribution Points 취소 알림이 발생하였을 때, CRL을 분배하는 분배 지점을 표시 Issuing Distribution Point CRL Distribution Point name과 취소 제한을 표시 CRL 서명 부분과 사용자에 의한 검증 요구 CRL에 다른 CRL을 대치시키거나 유효한 CRL을 취소하는 경우 발생 CAI&Simul

53 Delta-CRLs CRL의 크기 감소시키는 방법 통신 오버헤드를 감소
CRL 발행 이후에 생성하고 디지털 서명을 소유한 CRL 통신 오버헤드를 감소 모든 CRL을 처리하지 않고 DataBase의 현재 상태를 변경 안전한 저장 장치 필요 일반 PC에서 뿐만 아니라 큰 서버 상에서도 실행 가능 Delta CRL Indicator delta CRL을 나타냄 reason code extension 사용 유효기간 만료와 같은 이유로 entry를 제거 CAI&Simul

54 Indirect CRLs Issuing Distribution Point extension
다른 CA에서 CRL 생성. CRL을 여러 CA에서 획득할 수 있다. 처리해야 할 CRL의 수를 줄임으로써 performance를 줄일 수 있다. 보증서와 CRL distribution point에 대한 CRL extension를 사용 CRL 발행자와 보증서 발행자가 다를 때,CRL 발행자를 식별하는 field 보증서 발행자가 CRL 발행자에게 자신의 권한을 위임 CRL이 인정 받은 CRL 발행자에 의해 서명 되었음을 확인 Issuing Distribution Point extension 보증서 사용자는 CRL에서 모든 entry에 대한 보증서 발행자를 검사하도록 경고하는 기능 Certification Issuer CRL entry와 관련 있는 보증서 발행자를 표시 default 규칙 (a) 모든 취소에 대해 모든 community에 하나의 리스트만을 설치. 이 경우 자주 분배하고 체크 해야 한다. 점진적으로 확장되지 않기를 기대한다. (b)인증 경로를 처리할 때, CRL은 경로에 대해 모든 보증서를 확인해야 한다. 큰 기업이나 사회에서 CA의 보증서들의 모든 취소를 포함하는 CRL을 생성함으로써 실행능력이 향상된다. CAI&Simul

55 Certificate Suspension
사용자는 특별한 상태에 대한 보증서가 필요 Certificate suspension 기법 사용(ASNI X9) CRL에 대한 item 유지. entry 상태는 취소상태로 변화 또는 CRL로부터 제거. “held” 상태는 reason code CRL entry extension에 값으로 표시 Instruction code 등록된 instruction identifier의 inclusion이 행동을 나타내는 기능 보증서를 사용하기 전에 CA를 호출 사용자의 card/token을 회복시킨다. CAI&Simul