Transcript 공개키 기반 구조

제 4 장. 공개키 기반구조
1
목차
개요
4.1 공개키 인증의 필요성
4.2 상호인증
4.3 공개키 기반 구조의 구성
4.4 PKI(Public Key Infrastructure)
4.5 X.509 인증서 형식
4.6 인증서 취소 목록
4.7 PKI 관리
4.9 주요 관리 기능
4.10 인증 실무 준칙
4.11 PKI 운영 프로토콜
2
개요

공개키 기반 구조(Public Key Infrastructure)
– 공개키 암호 시스템을 사용하는 암호시스템에서 사용자의 공개키를
안전하고 신뢰성 있게 공표하는 수단을 제공
– 안전하고 신뢰성 있게 사용자의 공개키를 공표
– 인터넷 전자상거래 및 정부 정보통신망에서 매우 중요한 역할
– 관련 용어
• 인증서, OID(Object Idnetifier), X.500 DN(Distinguished Name)
• 인증실무준칙(CPS : Certification Practice Statement), LDAP(Lightweight
Directory Access Protocol), FTP(File Transfer Protocol), OCSP(Online
Certificate Status Protocol)
3
4.1 공개키 인증서 필요성 및 개요



파일 전송 프로토콜, WWW, 기타 security application은 공개키
알고리즘에 바탕
– 자신의 공개키 공표, 개인키를 비밀스럽게 간직
공개키 기반 구조
– 공개키 암호 시스템을 사용한다는 전제 하에서 구축
– 공개키 인증서에 바탕을 두고 구축해야 함
인증서
– CA(Certification Authority)가 end entity를 인증하는 전자증
명서 역할 수행
– CA는 자신의 private key를 사용하여 digital signature를 생
성하여 인증서에 첨부
– CA의 public key를 사용하여 인증서 확인
– 인증서 사용자에 대한 공개키와 신분에 대한 정보 포함
4

공개키 인증서의 필요성
도청자
송신자의
개인키로
서명
송신자의 서명 부분을
자신의 서명으로
바꾸어 전송
Internet
송신자 A
수신자
A의 공개키로 서명 확인
공개키 등록
공개키 디렉토리
5

공개키 인증서(인증서)
– 사용자의 공개키와 사용자의 ID를 결합한 digital stream
– 특정 개체 확인, 특정 활동, 권한, 능력을 허가하는데 이용
– 인증 기관(CA : Certificate Authority)의 서명문을 포함
– 사용자 공개키와 사용자 신분 확인
– CA에 의해 수행 또는 등록 기관(RA : Registration Authority)
에 의해 수행
– 인증서 형식 : X.509 버전 1, 2, 3
6

인증서 구조
– 버전(Version) : 인증서 형식의 연속된 버전의 구분, 기본은 1988년
– 일련번호(Serial Number) : 발행 CA내부에서는 유일한 정수값
– 알고리즘 식별자(Algorithm Identifier) : 인증서를 생성하는데 이용되는 서명
알고리즘을 확인하기 위한 서명 알고리즘 OID
– 발행자(Issuer) : 인증서를 발행하고 표시하는 CA
– 유효기간(Period of validity) : 인증서가 유효한 첫번째와 마지막 날짜 두 개
로 구성
– 주체(Subject) : 인증서가 가리키는 사람
– 공개키 정보(Public-key information) : 주체의 공개키와 이 키가 사용될 알
고리즘의 식별자
– 서명(Signature) : CA의 개인 서명키로 서명한 서명문
7

공개키 기반 구조(PKI : Public Key Infrastructure)
– 공개키 암호 시스템에서 사용하는 공개 정보를 공표하는 보안
시스템의 일종
– 다양한 인터넷 보안 응용을 가능케 하기 위한 바탕을 제공
– 대표적인 보안 서비스
• 프라이버시 보호
• 전자서명 서비스
– 구성 요소
• 공개키 인증서(Certificate), 인증기관(Certification Authority),
등록 기관 (RA : Registration Authority)
• End entity, CA의 인증서 관리 서비스, 디렉토리 서비스 규정
• 각 개체에 대한 인증과 신분 확인 기능을 제공 – 1996년
8

CA의 공개키 – off-line으로 users에게 전달
– User들은 CA의 공개키를 항상 저장
– 해당 CA에서 발행한 인증서의 유효성을 검증하기 위해 사용

최상위 CA의 인증서
– root CA에서 서명후 발급
– 하위 CA 및 end user들에게 모두 공유

인증 경로
– 여러 개 인증서들의 chain
– 신뢰 체인(Trusted Path)라고도 함
– 검증 : 각 CA가 발행한 CRL(Certificate Revocation List)을 검증하
여 만기 이전의 폐기 상태를 함께 검증
9
• SET에서의 hierarchical CA structure
Root CA
Brand CA
GCA
CCA
Card holder
Sign
CCA
Merchant
Signature
Merchant
Key EX
PCA
PG
Signature
PG
Key EX
10

인증서 소유자
– 인증서의 주체 필드(subject field)를 X.500 directory의 DN(Distinguished
Name)으로 유일하게 확인

X.500 directory
– 전화번호부와 비슷한 역할

X.500 directory entry
– 특정인의 주소, 전화번호, 이름, 조직, e-mail address, 직위 등의 부가 정보
를 제공
– 개체의 공개키를 규정하는 인증서를 포함
– 유일하게 구별 가능한 이름인 DN을 할당받음
– DN의 유일성을 보장하기 위해 X.500 directory는 계층적 구조를
DIT(Directory Information Tree)로 구성
– Root node를 제외한 모든 node는 RDN(Relative Distingusihed Name)을 할
당 받음
11

X.500 directory entry
(Continued)
– Root node아래에는 두 개의 문자로 구성된 나라를 나타내는
RDN이 할당
• ISO에 의해 할당
– 정부조직, 일반 회사, 지방 정부, 국영 회사 등의 entry등이 존
재
• 각 entry는 unique RDN을 할당 받음
– End organization은 포함하고 있는 다양한 개체들을 나타내
는 entry들을 포함
• Unique RDN이 할당
12
X.500 DN
Root
RDN = KR
한국
미국
RDN = SCH
순천향대
정부
정부
IBM
RDN = K.D.Hong
홍길동
DN : {C=KR, O=SCH,
CN=K.D.Hong }
속성
CN : K.D.Hong
전화번호 : 0418-542-8819
전자우편 주소 : [email protected]
직위 : 연구원
13
4.2 상호인증

모든 최종 개체가 하나의 CA로부터 인증서를 발급받는 것은 불가
능
– 여러 보안 구역으로 나뉘고, 해당하는 CA로부터 인증서 발급
– 다른 보안 영역에 존재하는 CA간의 상호 인증(Crosscertification)이 요구

상호 인증시 연결점이 필요

인증 경로
– PKI 계층에서 신뢰의 연결 고리

신뢰구간 확장을 위한 CA구조
– 계층적 구조
– 네트워크형 평면적 구조
– 두 방식을 결합한 구조
14

상호 인증 및 인증 경로
CA Y
CA X
CA Z
Bob의 인증서
Alice의 인증서
Bob
Alice
15

CA 계층 구조
– PAA(Policy Approving Authority)
• 최상위 계층이면서 다음 하위 계층인 PCA로 인증서를 발행
– PCA(Policy Certification Authority)
• 응용에 따른 인증서 정책을 결정
– CA(Certification Authority)
• 특정의 그룹 및 조직 구성원에게 인증서를 발행

인증
– CA가 최종 개체를 위하여 인증서를 발행
– 인증서 사용자가 인증서에 대한 유효성을 검증

인증의 유형
– ID 인증 (Identity Authentication)
– 자격 인증(Credential Authentication)
16

확장자(extention)
– 인증서 정책, 인증서 정책 매핑 필드, 대체 이름 필드, 개체 디렉토리
속성 필드, 인증 경로 제한 속성 필드 등을 포함

X.509 버전 3
– 기존 버전 1, 2에 비해 확장자의 개념을 도입

인증 경로의 제한
– 특정 CA로 부터 나올 수 있는 인증 경로의 유형을 제한하는 기능을
수행
– 인증 경로를 현재의 인증서로부터 특정의 이름 공간, 그리고 특정의
정책 하에서 발행된 상호 인증서로 제한하는 기능을 수행
– 버전 3에만 있는 기능으로서 매우 중요한 의미를 가짐
17
4.3 공개키 기반 구조의 구성

PKI 방식 : 순수 계층 방식과 네트워크 구조 방식
– 순수 계층 방식
• 최상위 인증 기관인 root CA에 바탕을 둠
• 최상위 계층의 root CA
– 전반적인 PKI 정책을 수립
– 제 2계층 CA를 인증
• 제 2계층 CA
– 루트 CA에 의해 설정된 정책 하에 자신의 정책을 수립
– 제 3계층 CA를 인증
• 제 3계층 CA
– 사용자를 인증
• 하부의 CA간의 상호 인증은 원칙적으로 배제
• 루트 CA간의 상호인증을 통한 국제간 상호 동작을 원활히 함
18
• 순수계층 구조
루트-CA
제2계층
- CA
제 3계층
-CA
사용자
19
• 네트워크 구조
– 모든 구조가 평면적으로 구성
– 모든 CA간에 상호인증을 허용
• 상호인증의 수가 대폭 증가하는 단점이 있다.
개별 기반구조
사용자
20
4.4 PKI 구성 요소 정의

PAA
– 전체 PKI 시스템 내에서 수행되는 정책을 설정하는 당국
– 모든 사용자와 사용자의 연합, CA들이 지켜야 할 전반적인 사용지침을 생성
– 하부 PCA에 대한 인증기능 및 국가적, 다국적 기반 구조의 PAA들과의 상호
인증(상호인증서 발급) 기능 수행
– 모든 하부 PCA의 지역적인 정보와 정책을 공표
– 인증서에 대한 취소 요구 정보 수신 및 확인
– 자신이 발급한 인증서에 대한 CRL 생성
– 호주 PKAF ; PARRA
– 캐나다 GOC PKI ; PMA
– 유럽 ICE –TEL PKI ; ICE-TEL CA 등
21

PCA
– PAA에서 승인된 전반적인 정책을 확장하거나 세부화된 정책을 생성
– 정책 생성 당국이라는 표현이 더 정확함
– 조직 혹은 공동사회(COI, Community of Interest)에서 사용될 정책
을 설정
• 누가 키를 생성할 것인가?
• 계수의 범위를 얼마로 할 것인가?
• 인증서의 유효기간을 얼마로 할 것인가?
• 어떻게 CRL이 취급될 것인지?…
– 등등의 세부 사항을 명세화
22

CA
– PAA/PCA의 정책에 따라서 사용자에게 공개키 인증서를 발급
– 타 CA에 대한 상호 인증서를 발급하는 기능
– PCA의 정책 규제 조건을 만족하는 키 생성 계수를 사용하여 키 쌍을
생성
– 생성한 키 쌍에 대해 PCA의 규제 조건을 만족하는지 확인
– 하위에 또 다른 CA를 둠으로써 일종의 PCA역할을 겸할 수도 있다.
23

ORA(Organizational Registration Authority)
– 사용자와 CA 중간에서 인증서 요구 및 전달 역할을 수행
– 사용자와 CA가 서로 원거리에 있을 경우
– GOC PKI에서는 LRA(Local Registration Authority)라고 함
– 사용자 신원 확인
– 사용자의 신원 정보와 공개키를 서명 후 CA에게 전송
– CA로부터 인증서 수신 및 확인
– 인증서 취소 요구를 받아 정당성 확인 및 CA에게 인증서 취소 요구
를 전달
24
4.5 X.509 인증서 형식

X.509
– ITU에 의해 제안된 인증서에 대한 기본 형식을 정의한 규격
– 인증서 데이터 형식
– 인증서를 이용한 공개키의 효율적인 분배 방법을 정의
– X.509 v1, v2
• 인증서 취소 목록(CRL:Certificate Revocation List)를 포함
– X.509 v3
• 인증서를 정의하는 다양한 환경에 맞는 조건과 서명 알고리즘들의 선택
이 가능하도록 확장영역을 추가
25
X.509 v1


1988년 발표
인증서 구성 요소
– CA의 개인키로 서명
26
X.509 v1

인증 경로
– DTI(Directory Information Tree)에서의 노드들의 경로
– 다른 보안 영역 CA들간의 사용자간 통신시에 이용
– 유효기간이 경과

CA는 해당 인증서를 디렉토리에서 제거
– 추후 부인 봉쇄 서비스를 위해 일정기간 보관

인증서의 폐기
– 개인키가 공개키로 유출되었다고 판단되는 경우
– 해당 사용자가 CA에 신고함으로서 수행
27
X.509 v2

X.509 v1 형식과 거의 비슷

두 개의 옵션을 추가
– 발급자 고유 ID(issuer unique identifier)
• 선택영역
• 발급자 CA의 X.500 이름에 대한 부가 정보를 포함
• 관리가 어렵고 식별이 용이치 않아서 대부분의 구현 제품들에서 사용되
지 않음
– 주체 고유 ID(subject unique identifier)
• 선택영역
• 인증서 주체의 X.500 이름에 대한 부가 정보를 포함
28
X.509 v3

새로운 개념이 많이 도입
– 확장자 도입
• X.509 실현자가 그들의 용도에 적합하게 인증서 내용을 정의할 수 있게
하기 위함
– 표준 확장자(standard extension)
• 인증서 정책 정보, 주체(subject) 디렉토리 속성, 인증 경로 제한, 확장
된 CRL 기능들을 제공
• 사용자 공개키에 대한 정보, 인증서 관리를 위한 부가적인 사항을 표시
– 확장 영역은 크게 3개의 부분으로 구분
• 키 및 정책 확장자, 주체와 발급자에 대한 속성 정보, 인증서 경로 규제
정보
29
• X.509 v3 인증서 형식
30

키 및 정책 확장자
– 주체 및 발급자 키에 대한 부가적인 정보를 포함
– CA 키 고유번호(Authority Key Identifier)
• 하나의 CA는 여러 개의 키를 보유할 수 있는데 이를 확인하기 위한 기
능을 수행
– 키 속성(Key Attribute)
• 인증서에 포함된 공개키에 대한 속성을 표시
– 인증서 정책(Certificate Policy)
• 대규모 PKI 등에 있어서 필수적인 요소
• 사용하고 있는 정책에 관한 정보
– 키 사용 규제(Key Usage Restriction)
• 인증서에 포함된 키의 용도에 따른 정책과 관련된 규제를 정의
– 정책매핑(Policy Mapping)
• 타 CA에서 사용되는 정책과의 정책 매핑을 규정
31

주체와 발급자에 대한 속성 정보
– 인증서 사용자에게 신뢰성을 주기 위한 영역
– 주체와 발급자에 대한 부가적인 정보를 가짐
– 주체 대체 이름(Subject Alternative Name)
• 인증서의 사용자 주체의 이름 혹은 또 다른 별개의 이름에 대한 부가정
보를 표시
• 사용자 ID, e-mail / IP 주소, DNS 이름 등
– 발행자 대체 이름(Issuer Alternative Name)
• 인증서 발급자의 이름 혹은 별개의 이름에 대한 부가정보 표시
• 인증서 발급자 이름, 발급자 ID, E-mail / IP 주소, DNS 이름 등
– 주체 디렉토리 속성(Subject Directory Attribute)
• 인증서 사용자 주체에 대한 X.500 속성 값을 의미
32

인증서 경로 규제 정보
– 키 사용 규제, 기본 규제, 이름 규제, 정책 규제 영역은 상당히 중요
한 의미를 지님
– 기본 규제(Basic Constraints)
• 주체가 CA인지, 인증 경로에 대한 정보 포함되어야 함
– 이름 규제(Name Constraints)
• 인증 경로 하부에 형성되는 CA들에 대한 이름 명명에 관한 일련의 규
제를 의미
• 인증서 체인에 대한 정보를 쉽게 알 수 있다.
– 정책 규제(Policy Constraints)
• PKI내의 다른 정책과의 호환성을 유지하기 위하여 정책 결정에 대한 제
한 범위를 규정
33

CRL을 위한 확장자
– 인증서가 취소되었을 경우 CRL에 접근할 수 있는 위치를 지정
– 델타 CRL(delta-CRL)의 유지 여부, 다른 인증기관에 의하여 유지되
는 간접 CRL 위치를 나타냄
– CRL 분배점(Distribution Points)
• CA :다양한 방법으로 분할, 관리
• 각각의 CRL부분은 다른 분배점을 통해 접근
– 델타 CRL(Delta-CRLs)
• CRL의 크기를 줄이는 또 다른 방법을 제공
• 마지막으로 전체 CRL을 발표한 후 새로 취소된 인증서 목록만을 발행
– 간접 CRL(Indirect CRLs)
• 해당 인증서 발행 CA가 아닌 다른 개체로부터 CRL이 발행될 수 있게
한다.
• 여러 인증 기관에 의해 발행된 CRL을 하나로 모음
34
4.6 인증서 취소 목록

인증서 취소
– 인증서 발행 조직에서의 탈퇴
– 비밀키의 손상
– 비밀키 유출의 의심

인증서 취소 메커니즘
– X.509에 정의된 CRL 메커니즘

인증서 취소 목록의 기본 영역
–
–
–
–
–
–
–
서명 알고리즘 : CRL에 서명한 서명 알고리즘 ID 및 관련 데이터
발급자 : 발급자 CA의 X.509 이름
최근 수정 일자 : 최근 수정 일자(UTC Time)
차후 수정 일자 : 다음 수정 일자(UTC Time)
취소 인증서 목록 : 취소된 인증서 목록들
CRL확장자 : CRL 확장자 유무 및 내용
발급자 서명문 : 발급자의 서명문
35

CRL의 확장자 영역 : 기본 확장자 + 개체 확장자
– 기본 확장자
• CA 키 고유 번호 : CRL에 서명한 키 번호
• 발급자 대체 이름 : CRL 발급자의 대체 이름(e-mail, IP 주소 등)
• CRL 발급자 번호 : CRL에 대한 일련 번호
• 발급 분배점 : CRL 분배점 이름
• 델타 CRL지시자 : 최근에 취소된 목록만을 저장한 델타 CRL 지시자
– CRL 개체 확장자 영역
• 취소 이유 부호 : 인증서가 취소된 이유
• 명령 부호 : 해당 인증서를 만났을 경우 취해져야 할 명령
• 무효화 날짜 : 해당 인증서가 무효화된 날짜
• 인증서 발급자 : 간접 CRL에서의 해당 인증서 발급자
36

인증서 취소 요구
– 인증서 소유자 또는 인증서 소유자의 대리인의 요구에 의해

CRL 공개
– 취소된 인증서에 대한 목록을 공개 디렉토리에 보관
– 네트워크를 통해 접속할 수 있도록 함

CRL 생성 방법
– 주기적인 CRL 생성 방식
– 즉각 CRL 생성 방식
• 신속성, 안전성 면에서 우수
• 해당 CA에 상당한 부하가 예상
– 두 방식의 절충 방식이 바람직
37
4.7 PKI 관리


IETF의 표준안을 중심으로 관리모델, 관리 메시지의 데이터 구조,
PKI 관리 기능을 정의
개요
– 관리 프로토콜
• PKI 구성 요소들 사이에 온라인 상호 작용을 지원해야 함
• CA와 클라이언트 사이에 이용, 또는 상호 인증서를 발행하는 두 CA 사
이에 이용 가능 해야 함
– PKI 관리 모델
• 인증기관(CA), 등록기관(RA), 최종개체(EE), 저장소(Repository)로 구
성
– PKI 관리를 위한 주요 요소
• 최종 요소, 인증기관, 등록기관
38

최종 개체(EE : End Entity)
– 주체 필드와 혼돈을 피하기 위해 사용
– PKI 관리 동작을 위한 모든 프로토콜에 영향

인증기관(CA)
– 최종 개체와 다른 CA들에게 인증서를 발행하는 신뢰된 개체
– 단순히 신뢰 되는 개체임을 나타냄
– “하부 CA” : 루트 CA 이외의 CA를 지칭

RA(Registration Authority)
– CA를 대신하여 사용자의 신분을 확인
– 개인 사용자 확인, 토큰 분배, 취소 보고, 이름 할당, 키 생성, 키 쌍
등록 등의 기능을 수행
– RA가 존재하지 않을 때, CA가 RA의 기능들을 대신
– 최종 개체가 직접 CA와 통신할 수 있다.
39

PKI 관리 프로토콜을 위한 요구사항 -IETF
– 정기적으로 키 생신 가능
– 기밀성의 사용은 최소화
– 다양한 상용 보안 알고리즘의 사용 가능
– 최종 개체, RA, CA에 의한 키 쌍의 생성을 배제해서는 안됨
– 최종 개체, RA, CA를 위한 인증서의 공표를 지원해야 됨
– E-mail, HTTP, TCP/IP, FTP와 같은 다양한 전송 메커니즘을 이용할
수 있어야 함
– 인증서 생성에 대한 최종 책임은 CA에게 있음
– CA 키 쌍의 갱신은 자연스럽고 계획적으로 이루어져야 함
– CA는 RA의 기능들을 수행할 수 있어야 함
– 최종 개체가 인증서를 요구할 경우, 최종 개체는 공개키에 대응하는
개인키를 증명할 수 있어야 한다.
40
인증서 발급 및 취소를 위한 주요 절차
(1) 초기 등록 및 인증
 등록/인증 초기화, 최종 개체에 대한 메시지 인증, 최종 개체를
위한 공개키의 생성, 사용자 인증 과정 등을 포함
– 최종 개체, RA 또는 CA 등에서 시작
– 인증 기관은 최종 개체에 의해 생성된 온라인 메시지들을 검증해야
한다.
– 최종 개체에서 PKI(RA, CA)까지의 모든 메시지에 대해 발신처 인증
을 수행해야 한다.
– 키 생성
• 최종 개체를 위한 공개키 및 개인키 쌍이 처음으로 발생하는 것
• 어디서든지 생성되고 키 쌍은 해당 개체로 전송되어야 함
• 키를 생성 개체 : 최종 개체, RA, CA
41
(1) 초기 등록 및 인증
 공개키/개인키 생성 방식
– 단말 개체에서 생성할 수 있는 방식
• 강력한 부인방지 기능 제공
• 안전성 높음
– 인증 기관 또는 제3의 신뢰기관에서 생성하는 집중형 키 생성 방식
• 단말개체에서 공개키/개인키 쌍을 생성할 수 없는 경우
• 키가 훼손된 경우에 키의 복구가 용이하다는 장점
– 최종 개체의 인증서 생성 후 인증 기관은 EE가 성공적으로 인증서를
수신했다는 것을 확신할 수 있어야 함
• 확신 메시지 -초기 인증키나 또는 다른 방법들에 의해 보호
42
기본 키 생성 방식
1. Alice의
토큰 생성
CA
6. LADP을 이용하여
인증서 공표
Directory
Service
2. 생성된 토큰
Alice에게 전달
5. 인증 응답
4. 인증 요구
3. Alice는 자신의
공개키/개인키 쌍 생성
Alice
43
중앙 집중형 키 생성 방식
CA
6. LADP을 이용하여
인증서 공표
Directory
Service
1. Alice의 개인키/공개키 쌍 생성
Alice의 인증서 생성
인증서를 토큰에 저장
2. 토큰을 Alice에게
전달
Alice
4. Alice는 인증서를
사용함
44
(2) 개인키 소유 증명(POP, Proof of Possession)
 CA/RA는 최종 개체가 공개키에 대응하는 개인키를 소지하고 있
다는 사실을 확신해야 한다.

키의 유형에 따라 각각 다른 방법으로 수행될 수 있다.
– 서명키
• 서명문을 작성, CA/RA로 전달하여 공개키로 서명문의 유효성을 검증
함으로써 개인키 소유 검증
– 개인키
• CA/RA에 개인키를 제공하거나 특정값을 암호화한 암호문을 복호할 수
있는지를 판별함으로써 검증
– 키 일치키
• 최종 개체가 개인키를 소지 했음을 증명하기 위해 분배된 비밀키를 공
유해야 한다.
45
(3) 루트 CA 키 갱신
 루트 CA가 자신의 키 쌍을 갱신하는 절차

CA는 새로운 공개키를 이전의 개인키를 이용하여 보호한다.
– 키 변경 동작 절차
• 새로운 키 쌍 생성
• 새 개인키로 서명된 CA의 공개키를 포함하는 인증서를 생성
• 옛 개인키로 서명된 새로운 CA 공개키를 포함하는 인증서를 생성
• 새로운 개인키로 서명된 새로운 CA 공개키를 포함하는 인증서를 생성
• 디렉토리 혹은 다른 방법을 통하여 새 인증서를 공표
• 최종 개체가 새 CA 공개키를 획득한다.
46
(4) 인증서 취소 요구 및 처리
가. 키 손상 및 문제 발생
– 일부 개체의 키가 손상된 경우 개체와 관련된 인증서는 취소되어야
함
– 사용자의 소속이 변경되었을 경우에도 해당 사용자 또는 해당 CA의
공개키 인증서는 취소되어야 함
• 이러한 상황은 전화 혹은 기타 방법을 통하여 고지되어야 함
– 원칙적으로 키 손상 등의 문제 발생시 개체는 해당 CA에게 문제 발
생을 고지할 책임이 있다.
– CA
• 해당 사용자에 대한 인증서 문제점 발생 여부 확인
• CRL 일렬번호와 차기 CRL 생성 일자를 첨부하여 해당 사용자의 인증
서를 CRL에 추가시켜야 한다.
47
(나) 키 손상에 대한 복구
– CA 키의 손상
• 하부의 모든 사용자의 인증서를 재발급해야 함
• 인증서를 발급하기 이전에 모든 사용자들에 대한 생성과정이 선행되어
야함
– CA에게 매우 부담스러운 일
– 이중 CA구조를 가지고 있으며,
– 두 개의 CA에 의해 발급된 공개키 인증서를 가지고 있다면 CA키 손
상에 대한 회복 절차는 휠씬 용이
48
(다) CRL 획득 절차
– 모든 CA들은 CRL을 생성
– 주기적으로 생성 또는 취소 상황 발생시 마다 생성
– PKI에서 CRL을 얻기 위한 방법
• CA가 CRL을 생성하고 자동으로 하부 CA로 CRL을 보냄
– 즉각적인 통보가 필요
• 디렉토리에 문의하여 CRL을 얻는 방법
– 디렉토리 서비스 중단시 문제 발생, 비실용적
• CRL을 DB에서 획득하는 방법
– 제안되어 있는 대부분의 방법
• 모든 개체들은 디렉토리를 통해 CRL을 얻는다.
49
(라) 키 생성 및 재인증
– 키가 손상되지 않았을지라도 주기적으로 키 쌍을 재생성해야 함
– 키 변환 방법
• 매년 같은 날 모든 개체들이 키를 변환
• 각각의 개체에 의해 선택된 날에 키를 변환
– 어떠한 방법이라도 변경일 이전에 개체들은 새로운 키 쌍을 가져야 한다.
– 새로운 키 쌍과 인증서는 변경일 이전에 생성되어야 함
• CA의 옛 개인키에 의해 서명되고 분배되어야 한다는 것을 의미
– 키 재생성 방법은 PKI내의 모든 계층에서 적용된다.
50
4.9 주요 관리 기능

CA와 RA가 가져야 할 기능
– 루트 CA 초기화
• self-certificate의 생성
• 자신의 공개키에 대한 fingerprint 생성
• 최종 개체에 전달
• 최종 개체는 CA의 자가 인증서의 유효성을 지문을 이용하여 검증
– 루트 CA 키 갱신
• CA 키들은 유한의 수명을 가짐
• 주기적으로 갱신되어야 함
51

하부 CA 초기화
– 하부 CA의 초기화는 최종 개체의 초기화와 같다.
– 차이
• 하부 CA는 초기의 인증서 취소 목록을 생성해야 한다.

CRL 생성
– 새롭게 설립된 CA는 어떤 인증서들을 발행하기 전에 “내용이 없는”
CRL을 생성해야 한다.

PKI 정보 요청
– 개체들이 CA의 현재 상태에 대한 정보를 얻고 싶을 경우, 이 정보를
요청할 수 있다.
– CA는 모든 정보를 제공하여야 한다.
– 제공 불가능 : 요청자에게 에러 메시지 전송
52

상호 인증
– CA는 상호 인증서의 주체
– 기법 : 일방향 동작
– 하나의 새로운 인증서 발급 필요

최종 개체의 초기화
– CA들과 마찬가지로 최종 개체들도 초기화
– PKI 정보 획득 단계
• 루트 CA의 공개키
• 인증 경로
• CA가 지원하는 각종 보안 알고리즘과 알고리즘 파라메터
– 루트 CA 공개키의 검증 단계
53

인증서 요청
– 초기화된 최종 개체는 언제라도 인증서 발행을 요청할 수 있다.
– 인증서 요청 메시지 이용하여 생성
– 개체의 전자서명에 의해 보호

키 갱신
– CA에 대해 새로운 키 쌍에 대해 새로운 인증서를 발행하도록 요청
– 키 갱신 요청 메시지를 이용하여 생성
• 개체의 전자서명으로 보호
– CA는 키 갱신 응답 메시지에 새로운 인증서를 보낸다.
54
4.10 인증실무준칙

정의
– 인증실무준칙 --CPS :Certification Practice Statements
– 인증기관이 인증서를 발급하기 위해 사용한 실무 절차에 관한 세부
규정
– 인증서 신뢰, 인증 업무에 대한 이해를 위해 CA에 의해 발행되는 인
증업무에 대한 세부적인 기술 문서
– 인증 정책에 비해 좀 더 구체적
– 인증 정책, 사용자 인증 절차, 비밀 키 관리 절차 등이 포함
– CA는 이 규정에 의해 모든 업무 수행
• 반드시 CPS를 작성하여 공개
• 사용자들은 이를 이용 CA의 신뢰도를 측정
55

인증실무준칙 구조
– 개체 정의 및 용도 명시
– 인증 서비스를 구성하고 있는 요소들에 대해 설명
– 인증서의 사용용도와 인증기관이 인증 서비스를 위해 사용하는 여러
가지 표준들에 대해 명시
• 즉, CA, RA, EE에 대한 정의와 인증서의 종류, 인증서의 적용 예, 그리
고 인증서 사용에 관한 규정을 설명
– 인증 서비스를 위해 사용되는 기술들에 대한 표준 사용 여부를 설명
56

신원 확인 및 인증 정책
– 특정 공개키가 정당한 소유자에게 속해 있음을 증명하는데 있어서
기본이 되는 요소
– 신원 확인 및 인증이 필요한 경우에 신청인이 제출해야 하는 여러 가
지 정보를 정의, 이에 대한 확인 절차를 기술

자국 보안 정책
– 인증 기관의 기능을 안전하게 수행하기 위해서 사용되는 비 기술적
인 보안 규제에 대해서 정의
• 물리적 관리, 직원 관리, 업무 절차 관리로 구분
57

키 관리 정책
– CA, RA, EE에 대해 해당 암호키나 주요 보안 파라메터를 보호하기
위한 수단을 정의
– 키 관리 범위
• 키 생성, 저장, 사용, 보관 및 취소에 이르기까지의 모든 과정을 포함
– 키 관리에 대한 인증 실무 준칙 예
• CA 키 쌍의 생성 : FIPS PUB 140-1 level 2를 따르는 암호키 생성 시
스템을 사용
• CA 개인키의 저장 :CA 개인키는 3개 이상으로 분리, 128비트 DES 암
호화되어 스마트 카드에 저장, 각각 다른 관리자들에 의해 관리
• CA 개이키의 백업 :CA의 개인키와 개인키 저장에 사용되는 암호키는
CA 운영 시스템과 분리하여 백업
• CA 개인키의 보관 : 인증서의 유효기간이 지난 후에도 필요한 경우를
대비하여 3년간 복수 관리자에 의해 보관
58

기술적 보안 정책
– CA의 기능을 안전하게 수행하기 위해서 사용되는 기술적인 보안 관
리에 대해 정의
– 컴퓨터 보안 관리, 생명 주기 보안 관리, 네트워크 보안 관리, 암호
모듈 보안 관리로 구분

운영 정책
– 인증서 취소, 감사, 기록 보관, 키 변경, 키 복구 등과 관련된 정책을
규정

법적 문제
– 인증 서비스의 신뢰도를 높이기 위해 법적 문제들에 대한 기술이 필
요
– 각 개체에 대한 의무 및 책임성에 대한 규정
– 인증기관의 재정 상태, 인증 서비스와 관련된 법규정, 서비스 요금
등에 대한 명시가 필요
59

인증서 및 CRL 프로파일
– 인증서와 CRL의 버전과 인증기관에서 지원하는 확장 영역에 대해
정의
– 세부 내용
• 인증서 버전 및 정책 OID(Object Identifier)
• CA, RA, EE에게 사용되는 이름 형식 및 이름의 제한
• 사용되는 인증서 확정 영역
• CRL버전 및 CRL 확장 영역

정책 관리
– 정책의 수립, 유지, 해석 등을 책임지는 기관을 정의
– 계약 정보, 정책 변경 절차, 정책 공개의 세 부분으로 나뉨
60
4.11 PKI 운영 프로토콜

인증서 및 CRL의 상태를 저장소로부터 조회하기 위한 프로토콜
– LDAP(Lightweight Directory Access Protocol)
– FTP(File Transfer Protocol)

인증서 온라인 상태의 유효성을 검증
– OCSP(Online Certificate Status Protocol)

PKI 운영 프로토콜의 기본 모델
– 최종개체
– CA
– 저장소
LDAP나 FTP를 이용하여 저장소로부터
인증서나 CRL들을 검색
61
LDAP(Lightweight Directory Access Protocol)

PKI 운영 프로토콜
– 인증서 및 CRL 보관소에 저장된 PKI 정보를 부가하고 삭제하며, 변
경하는 절차를 규정
– LDAP 프로토콜로 실현

LDAP 프로토콜 동작
– 보관소 읽기, 보관소 탐색, 보관소 내용 변경

보관소 읽기(Repository Read)
– EE와 CA가 엔트리의 이름을 알고 있을 경우
– 보관소로부터 특정 엔트리에 관련된 PKI정보를 검색하기 위한 수단
을 제공

보관소 탐색(Repository Search)
– 엔트리의 이름이 알려져 있지 않고 후보 엔트리를 필터링하기 위한
부가적인 정보를 저장소로 제공할 수 있을 경우
– 특정 엔트리와 관련된 PKI 정보를 검색하는 수단을 제공
62

보관소 변경(Repository Modify)
– 보관소가 저장되어 있는 PKI 정보를 부가하고, 삭제하며, 변경하기
위한 수단을 제공한다.
63
FTP(File Transfer Protocol)

일반적으로 CA는 인증서 사용자들이 이용 가능한 디렉토리에
CRL을 공표
– 디렉토리 서비스들은 인터넷 환경에서는 부적절

인증서와 CRL 분배를 위한 또 다른 방법
– FTP를 이용

인증서 확장자와 CRL 확장자
– CRL들의 분배점을 포함
– 인증서나 CRL을 가져오기 위해 인증된 FTP나 anonymous FTP를
사용하는 것을 의미

FTP의 장점
– .cer 확장자 : 인증서를 포함하는 파일
– .crl 확장자 : CRL을 포함하는 파일
64