Chap 10. 인증응용

1

Chap 10. 인증응용

2

목 차

1. KERBEROS2. X.509 디렉토리 인증 서비스

3

인증서버

Sever

사용자 로그온

Sever

Sever

4

1. 인증에서의 요구 조건

공격 유형 – 노출 (Disclosure) : 정확한 암호키를 소유하지 않은

사람이나 프로세스에게 메시지의 내용이 노출되는 것– 트래픽분석 : 통신자들 사이에 트래픽 패턴을 알아내는 것– 위장 : 부정한 소스로부터 나온 메시지를 네트워크 상에

삽입하는 것– 내용수정 : 삽입 , 삭제 , 전치 및 수정을 포함한 메시지

내용의 변경– 순서수정 : 삽입 , 삭제 및 전치를 통한 쌍방간의 메시지

순서의 변경– 시간수정 : 메시지의 지연과 재전송– 부인 : 수신자가 메시지 수신을 부인하거나 발신자가

메시지의 발신 부인

5

1. KERBEROS

분산 환경하에서 개체 인증 서비스를 제공하는 네트워크 인증 시스템

MIT 에서 개발 공개키 암호는 전혀 사용하지 않고 관용키 암호 방식만을 사용 중앙 집중식 인증 서버 이용 티켓 발급 서버 (Ticket Granting Server) - Trusted

Third Party TGS 에서 발급받은 티켓을 이용해서 서버로부터 인증 Version 4 : 가장 널리 사용 Version 5 : Version 4 의

보안 결함을 수정 Internet Draft 표준

6

간단한 인증 프로토콜

개방형 분산 C/S 환경 : 임의의 C 가 임의의 S 에 접속 위협요소 : 무자격 C 의 신분 위장한 S 접속 ==> S 는

C 의 신분확인 필요 S 가 직접 신분확인 처리하는 업무부담 가중 우려 중앙 집중식 인증서버 (AS: Authentication Server)

를 이용한 모든 C 의 신분확인 비밀키의 분배

– C <==> AS ; PC( 사용자의 패스워드 정보 )

– AS <==> V ; KV( 비밀키 )

7


Ticket : EKV[IDC, ADC, IDV]

(ADC : C 의 네트워크 주소 )

Client

AS

V(Server)

(1) [IDC, PC, IDV]

(2) [Ticket]

(3) [IDC, Ticket]

User

Login(ID, Password)

서비스

8


1. U 는 서버 V 를 사용하기 위해 C 에 로그인하고 ID 와 패스워드를 입력

2. C 는 사용자의 ID, 패스워드 , 사용하고자 하는 서버 V 의 식별자를

인증서버 AS 에 전송

3. AS 는 ID 와 패스워드가 등록되어 있는지 검사하고 C 의 네트웍 주소를

포함하는 인증 티켓을 발급 (DES 로 암호화해서 티켓을 만들기 때문에

티켓을 클라이언트나 외부에서 조작이 불가능 )

* 네트워크 주소를 포함하는 이유 : 티켓을 중간에서 가로채서

사용하려는 경우의 방지

4. V 는 티켓을 복호하고 평문으로 전송된 ID 와 티켓속의 ID 가

일치하는지 확인 , 일치하면 사용자에게 서비스 개시

9

간단한 인증 프로토콜의 분석 패스워드 Pc 의 전송이 평문으로 전달됨

패스워드 가로채기 가능 티켓의 재사용 불가능 : 티켓이 단 한번만 사용되기 때문에

새로운 서비스를 사용하기 위해서는 또 다시 패스워드 입력 필요 티켓의 재사용으로 해결 가능 ( 티켓의 저장 )

일방 인증 서버가 일방적으로 클라이언트를 인증

티켓의 다른 클라이언트 사용 방지 ADC 의 사용으로 클라이언트의 네트워크 주소 확인

IDC 를 도용하여 티켓의 intercept & replay 불가 ( 티켓을 본래

요구했던 클라이언트의 확인 )

Ticket-Granting Server(TGS) 개념 도입으로 문제점 개선

10

TGS 를 이용한 인증 프로토콜

간단한 인증 프로토콜의 개선안– 사용자는 메일 서버에 접속 할 때마다 패스워드를 입력 ( 하루에도 여러 번

접속마다 별도의 인증절차 필요 )

• AS 에게서 발급 받은 티켓을 저장하여 재사용

– 서버의 종류와 해당 서버에서의 각 서비스 세션의 개별적 구분가능

– 평문 패스워드의 네트워크 전송 없이 인증하는 방법 필요

TGS 를 이용하여 재사용 가능한 2 가지의 티켓 발행

비밀키의 분배– C <==> AS ; KC

– AS <==> TGS ; Ktgs

– TGS <==> V ; KV

11


C

AS

TGS

(1) [IDC , IDtgs]

(2) [EKC(Tickettgs)]

(3) [IDC , IDV , Tickettgs]

U

(4) [TicketV]

V(5) [TicketV]

로그온시 한번

서비스마다 한번

서비스 세션당 한번

Tickettgs=EKtgs[IDC , ADC , IDtgs , TS1 , Lifetime1]

TicketV=EKV[IDC , ADC , IDV , TS2 , Lifetime2]

12


1. 클라이언트는 사용자 ID 와 TGS 의 ID 를 인증 서버에 전송2. 인증 서버는 티켓 승인 티켓 (Tickettgs) 생성 후 사용자

패스워드에 기반한 키로 티켓을 암호화하여 클라이언트에 전송* 티켓에 재사용 방지를 위해 발행시간 (TS1) 과 유효기간

(lifetime) 을 포함3. 클라이언트는 사용자 ID, 요구하는 서비스 ID, Tickettgs 을

TGS 에 전송함으로써 서비스 승인 티켓 (TicketV) 요구

4. TGS 는 들어온 티켓을 복호하고 복호의 성공여부 , ID 의 일치여부 , 사용자 네트워크 주소 확인 , 유효기간 확인 , 등의 수행 후 TicketV 발급

5. 클라이언트는 사용자 ID 와 TicketV 를 제시하여 서비스 접속 요구

이후 , 서버는 사용자 ID 와 TicketV 를 복호하고 검증한 다음 서비스 연결

13


장점1. 패스워드의 평문 전송 불필요2. 티켓의 재사용 가능

단점1. Tickettgs 의 유효기간 문제

유효기간이 매우 짧다면 , 패스워드의 반복 입력 요구 (시스템 부담 )

유효기간이 매우 길다면 , 침입자의 재전송 공격 가능성 증가

=>Tickettgs 를 가로채서 사용자 로그 아웃 후 (3) 의 메시지를 조작전송하여 서비스 티켓 요구 (KC , Ktgs 복호 분석 가정 )

2. 서버의 인증 불가 불법적 서버의 위장된 서비스 방지기능 필요 ( 상호인증 )

14

Kerberos Version 4 의 인증 프로토콜 TGS 를 이용한 인증 프로토콜의 개선안

– Tickettgs 와 TicketV 의 합법적 사용자임을 검증하는 강화된 방안 필요

서버에 대한 상호인증 포함하여 수행

비밀키의 분배 공유

C <==> AS ; KC

AS <==> TGS ; Ktgs

TGS <==> V ; KV

C, AS, TGS ; KC, tgs

C, TGS, V ; KC, V

15

Kerberos Version 4 의 인증 프로토콜

C

AS

TGS

(1) [IDC, IDtgs, TS1]

(2) [EKC(Kc, tgs,||IDtgs ||TS2|| Lifetime2||Tickettgs)]

(3) [IDV, Tickettgs ||AuthenticatorC]

(4) [EKC,tgs [KC,V || IDV || TS4 || TicketV]]

V(5) [TicketV ||AuthenticatorC]

Tickettgs

획득

서비스 요구

상호인증

Tickettgs=Ektgs [KC, tgs || IDC || ADC || IDtgs || TS2 || Lifetime2]

(6) [EKc, v[TS5+1]]

TicketV

획득

TicketV=EKV[KC,V , IDC , ADC , IDV , TS4 , Lifetime4]

AuthenticationC= EKC,tgs [IDC , ADC , TS3]

AuthenticationC= EKC,V [IDC , ADC , TS5]

16

Kerberos Version 4 의 인증 프로토콜

인증 서버 (AS)

티켓승인서버 (TGS)

Sever

(5) 서비스 요구

사용자 로그온(1) TGS 에 대한 접속 요구

(2) 티켓 & 세션키

(3) 서비스 승인 티켓 요구

(4) 티켓 & 세션키

(6) 서버 인증자 제공

로그온마다 한번

서비스 유형마다 한번

서비스 세션마다 한번

17

Kerberos Version 5 의 인증 프로토콜 V4 의 결점 보완

– 암호화 시스템에 대한 의존 : DES 사용 (DES 의 수출제한 )

• V5 는 다른 암호 알고리즘 사용 가능

– 인터넷 프로토콜에 대한 의존 : V4 는 IP 주소 사용만 허용

• V5 는 다른 형식의 주소 사용 가능

– 메시지 바이트 순서 : 순서 표시 고정

• V5 : 추상구문표기법 ASN.1(Abstract Syntax Notation) 과 기본부호규칙

BER(Basic Encoding Rule) 인코딩 규칙 표준 사용

– 티켓 유효시간 : 최대 28*5 = 1280 분 동안만 사용 가능

• V5 : 시작 시간과 끝시간 표시 ( 충분한 유효시간 )

– V5 에서는 인증서의 발송이 가능

– V5 에서는 상호영역 사이에서 효과적 인증수행 가능

18

Kerberos Version 5 의 인증 프로토콜(a) 인증 서비스 교환 : 티켓 - 승인 티켓을 얻기위해

(1) C → AS: Options∥IDc∥Realmc∥Times∥Nonce1

(2) AS → C: Realmc∥IDc∥Tickettgs∥EKc[Kc,tgs || Times || Nonce1 || Realmtgs || IDtgs]

Tickettgs = EKtgs [Flags∥Kc,tgs || Realmc || IDc || ADc || Times]

(b) 티켓 - 승인 서비스 교환 : 서비스 - 승인 티켓을 얻기 위해

(3) C → TGS: Options || IDV || Times∥Nonce2∥Tickettgs∥Authenticatorc

(4) TGS → C: Realmc∥IDc∥Ticketv∥EKc,tgs[Kcv || Times || Nonce2 || Realmv || IDV]

Tickettgs = EKtgs[Flags∥Kc,tgs || Realmc || IDc || ADc || Times]

Ticketv = EKv[Flags∥Kc,v || Realmc || IDc || ADc || Times]

Authenticatorc = EKc,tgs[IDc || Realmc || TS1]

(c) 클라이언트 /서버 인증 교환 ; 서비스를 얻기 위해

(5) C → V: Options ∥ Ticketv || Authenticatorc

(6) V → C: EKc,v [TS2 ∥ Subkey ∥ Seq#]

Ticketv = EKv [Flags ∥ Kc,v || Realmc ∥ IDc ∥ ADc || Times]

Authenticatorc = EKc,v[IDc || Realmc ∥ TS2 ∥ Subkey || Seq#]

X.509 인증 서비스

20

X.500 디렉토리 서비스

ITU와 ISO/IEC/JTC1/SC21 협동 프로젝트로 1985년부터 개발에 착수 1988년 X.500 시리즈 권고사항으로 발표

DB 구축기술 , 분산처리기술 , 정보보호 및 통신프로토콜 기술 등이 광범위하게 복합적으로 적용된 대형 분산서버의 집합

개념적 모델의 관점– 기능모델 : 광범위한 지역의 디렉토리 정보를 기능적으로 어떻게

분산구성 , 정보교환 및 체계적 관리

– 정보모델 : 실세계에 관심있는 정보들을 디렉토리에 논리적으로 어떻게 표현

– 서비스모델 : 디렉토리 정보들이 사용자에게 어떻게 서비스되는가

– 정보보호 모델 : 디렉토리를 이용한 정보보호 서비스 이용방법

21

기능모델 디렉토리는 사람 , 조직 , 서비스 등과 같은 실세계의 객체 (Object) 에 관한 정보를

보유하고 사용자에게 이들 정보에 대한 서비스를 제공하는 온라인 분산 시스템으로써 디렉토리 프로토콜을 실행하는 일련의 협동하는 시스템들로 구성

– DSA(Directory System Agent): 디 렉 토 리 의 역할 을 나타내 는 프 로 세 스 (server, 디렉토리는 DSA 통신 집합 )

– DUA(Directory User Agent): 응용 프로세스에 의하여 디렉토리와 상호작용 (client, 사람이나 컴퓨터 프로그램 )

– DAP(Directory Access Protocol): 디렉토리 서비스를 요구하는 하나의 DUA 와 DSA 사이의 프로토콜

– DSP(Directory System Protocol) : 디렉토리 서비스의 연결을 지원하는 두 DSA 사이의 프로토콜

– DISP(Directory Information Shadowing Protocol) : 복제 정보의 교환을 지원하기 위하여 shadowing 등의 선정에 관한 두 DSA 사이의 프로토콜

– DOP(Directory Operational Binding Protocol) : 두 DSA 사이의 관리 정보교환에 관한 프로토콜

– chaining, referal, multicasting 기법 사용

22

기능모델Directory System AgentDirectory User AgentDirectorey Access ProtocolDirectory System ProtocolDirectory Information Shadowing

ProtocolDirectory Operational Binding Protocol

DUADUA

DUADUA

DUADUA

DUADUA

DSADSA

DSADSA

DSADSA

DIRECTORYDIRECTORY

DAPDAP DAP, DAP, DSP, DISP, DOPDSP, DISP, DOP

23

정보보호 모델

디렉토리 시스템에 관한 정보보호 대책

– authorization: 디렉토리 사용자가 미리 정의된 access

control policy 에 일치하는 접근 권한을 가진 사용자인지

판별하여 규정된 접근만을 인정

– authentication: DSA와 디렉토리 사용자의 신분 , 그리고

접근점에 접수된 정보의 발신처 신분을 확인하는 인증서비스를

제공

– authentication 에서는 사용자의 이름과 패스워드 등을

사용하는 단순 인증과 공개키를 이용한 암호화 기법 등을

사용하는 강한 인증방법 제시

24

X.509 표준문서 주요내용

단순 인증 : 사용자 DN (Distinguished Name), 패스워드 , 난수 , 타임스탬프 이용 인증

강한 인증

– PKCS 을 이용한 인증방법

– CA 가 서명한 인증서를 통한 사용자 공개키의 획득

– 전자서명 : 서명자 X 의 키 쌍 ; Xs/Xp

X{Info} = Info,Xs{h(Info)}

– One-Way, Two-Way, Three-Way 3 가지의 인증절차 제시

– 키 쌍의 생성 : 사용자 , 제 3 자 , CA 가 생성

– 인증서의 관리 : 인증서의 생성 , 보관 , 취소

25

인증서

X.509 구조의 핵심은 공개키인증서

사용자 인증서를 인증기관 (CA: Certification

Authority) 에서 발행

인증서는 사용자나 CA 가 디렉토리에 보관

디렉토리는 사용자가 인증서를 획득할 수 있는 접속장소를

제공

26

인증서의 형식V ersion

C ertifica teseria l num ber

A lgorithm

P aram eters

Issuer nam e

N ot before

N ot a fte r

S ub ject nam e

A lgorithm

P aram eters

K ey

Issuer un iqueidentifie r

S ub ject un iqueidentifie r

E xtensions

A lgorithm

P aram eters

E ncrypted

Vers

ion 1

Vers

ion 2

Vers

ion 3

all

vers

ions

S ignaturealgorithmidentifier

P eriod o f valid ity

S ubjec t'spublic - key

info

S ignature

27

사용자 인증서 구조

Authority Key IdentifierC ertificate P o lic iesB as ic C onstraints

Vers ionS erial N umberS ignatureIssuerValid ityS ubjec tS ubjec t P ublic Key InfoE xtensions

Issuer's S ignature

X.509 v3 C ertific ate

E nd- U ser C ertific ate

28

인증기관 인증서 구조

Authority C ertific ate


Issuer's S ignature


Authority Key IdentifierS ubjec t Key IdentifierC ertificate P o lic iesP o licy M appingsB as ic C onstraintsN ame C onstraintsP o licy C onstraints

29

인증서 구성요소 버전 (version)

– 인증서 형식의 X.509 버전 일련번호 (Serial Number)

– CA 에 의해서 발행된 모든 공개키 인증서 내에서 인증서의 유일한 ID 를 표시한다 .

서명 알고리즘 (Signature Algorithm)

– CA 가 인증서에 서명하기 위해서 사용한 알고리즘 발행자 이름 (Issuer Name)

– 발행자의 이름은 인증서를 서명하고 생성한 CA 의 ID 를 표시 유효기간 (Validity Period)

– 인증서의 시작 날짜와 만기일에 대한 날짜와 시간을 지정 사용자 이름 (Subject Name)

– 인증서에 있는 공개키에 대응하는 개인키를 가진 소유주의 ID

사용자 공개키의 정보 (Subject Public Key Information)

– 사용자의 공개키와 사용될 알고리즘 식별자

30

인증서 구성요소 발 행 기 관 식 별 자 (Issuer Unique Identifier, version 2

only)– X.500 X.500 이름이 다른 실체에서 재사용될 경우 이름이 다른 실체에서 재사용될 경우 CACA 을 유일하게 을 유일하게

식별하기 위한 선택적인 필드식별하기 위한 선택적인 필드 사 용 자 식 별 자 (Subject Unique Identifier, version 2

only)– X.500 X.500 이름이 다른 실체에서 재사용될 경우 사용자를이름이 다른 실체에서 재사용될 경우 사용자를 유일하게 유일하게

식별하기 위한 선택적인 필드식별하기 위한 선택적인 필드 확장 (Extensions)

– 하나 이상의 확장 필드들의 집합하나 이상의 확장 필드들의 집합 . . 확장들은 버전확장들은 버전 33 에서 추가에서 추가– 확장필드 이름과 확장필드 이름과 critical critical 여부와 값으로 구성 여부와 값으로 구성 – 만약 확장필드가 만약 확장필드가 criticalcritical 이라면 클라이언트는 그 확장필드를 처리할 이라면 클라이언트는 그 확장필드를 처리할

수 있어야 한다수 있어야 한다 .. 서명 (Signature)

– 인증서의 다른 모든 영역을 해쉬 코드로 구성하여 인증서의 다른 모든 영역을 해쉬 코드로 구성하여 CACA 의 개인키로 의 개인키로 암호화암호화

– 이 영역은 서명 알고리즘 식별자를 포함이 영역은 서명 알고리즘 식별자를 포함

31

인증서 예제

Version: 2 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5withRSAEncryption Issuer: C=US, SP=California, L=Oakland, O=Univeristy of California, OU=UC Davis Validity: Not Before: Jul 31 12:00:00 1997 GMT Not After: Jul 31 12:00:00 1998 GMT Subject: C=US, SP=CA, L=Oakland, O=University of California, OU=UC Davis, CN=J. P. Student/[email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption Public Key: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: 00:00:00:00:00 Exponent: 65537 (0x10001) X509v3 extensions: Netscape CA Revocation Url: http://ca.ucdavis.edu/ca-crl.pem Netscape Comment: Any comment you wish. Identifier: Certificate Type Critical: no Certified Usage: SSL Client Secure E-mail Identifier: Authority Key Identifier Critical: no Key Identifier: 74:ee:01:98:78:27:18:03:67:34:fd: 23:a3:ef:16:60:ea:cc:1a:ee Identifier: Campus Unique Identifier Critical: no Value: 000022811 Signature Info: Signature Algorithm: md5withRSAEncryption Signature: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

Version

Certificateserial number

Algorithm

Parameters

Issuer name

Not before

Not after

Subject name

Algorithm

Parameters

Key

Issuer uniqueidentifier

Subject uniqueidentifier

Extensions

Algorithm

Parameters

Encrypted

Signaturealgorithmidentifier

Period of validity

Subject'spublic-key

info

Signature

32

인증서 정의와 서명

인증서 정의

– CA<<A>>=CA{V, SN, AI, CA, TA, A, Ap}

• Y<<X>> 는 인증 기관 Y에 의해 발행된 사용자 X 의 인증서

• Y{I} 는 Y에 의한 I의 서명 .

– 이것은 암호화된 해쉬 코드를 추가한 I로 구성되어 있다 .

– CA 는 개인키로 인증서에 서명을 한다 .

– 일치하는 공개키가 사용자에게 알려져 있으면 그 사용자는 CA 에

의해 서명된 인증서가 유효한 것으로 확인할 수 있다 .

33

인증서 계층 구조 순 방향 인 증 서 (forward

certificate): 다 른 CA 에 의해 생성된 X 의 인증서

역 방 향 인 증 서 (reverse certificate): X 가 생 성 한 다른 CA 의 인증서

A ==> B: Xp . X << W >> W << V >> V << Y >> Y << Z >> Z << B >> = Bp

B==> A: Zp . Z << Y >> Y << V >> V << W >> W << X >> X << A >> = Ap

A==> B: EBp[M]

U

V

W Y

X Z

C A B

U <<V>>V <<U >>

V <<W >>W <<V>>

W <<X>>X<<W >>X<<Z>>

V <<Y>>Y<<V >>

Y<<Z>>Z<<Y>>Z<<X>>

Z<<B >>X<<A >>X<<C >>.

34

인증서의 취소

인증서의 취소 사유

– 사용자의 개인키가 손상된 것으로 간주될 때사용자의 개인키가 손상된 것으로 간주될 때 ..

– 사용자가 이 사용자가 이 CACA 에 의해 더 이상 인증되지 않을 때에 의해 더 이상 인증되지 않을 때 ..

– CACA 의 인증서가 손상된 것으로 간주될 때의 인증서가 손상된 것으로 간주될 때 ..

사용자는 인증서 획득 시에 취소된 인증서 인지 검사 필요

– 인증서 받을 때마다 확인 : 취소 인증서 캐쉬보관 , CRL 구성 등

효과적 탐색 및 인증서 유효성 안전한 검증방안 필요

응용분야에 따라서 부인방지 서비스 희망

– 유효기한이 만료되었거나 취소된 인증서도 일정기간 보존

35

인증서 취소목록 형식

취소 인증서 발행자 이름

취소 인증서 목록의 생성

날짜

각 취소된 인증서 목록

– 해당 인증서의 일련 번호

– 해당 인증서의 취소 날짜

발행자의 서명

V ersion

A lgorithm

P aram eters

Issuer nam e

N ext U pdate

S ignaturealgorithmidentifier

R evokedcertificate

This U pdate

U ser certifica te seria l #

R evocation date

U ser certifica te seria l #

R evocation date

A lgorithm s

P aram eters

E ncrypted

R evokedcertificate

S ignature

E xtensions

36

인증서와 CRL 의 관계

Vers ionS ignatureIssuerThis U pdateN ext U pdateR evoked C ertific ates

C RL E xtensions

Issuer's S ignature

X.509 v2 C RL

Indirect CRL


Issuer's S ignature


CRL Dist. PointCRL Issuer

C RL D istribution Point

S erial N umberR evocation DateC R L E ntry E xtns .

R eason C ode

Inva lid ity D ate

Instruct. C ode

Cert. Issuer

C R L D istribution P o int C R L 는 인 증 서 에 대 한 이

.어 디 에 있 는 지 가 리킨다

C R L C R L발 행 자 는 에 C A .서명한 를 식 별 한 다

인 증 서 발 행 자 는 취소 된 인 C A 증 서 를 발 행 한 를 가 리

Ind irec t C R L 키 기 위 해 과 . 함께 사 용 된 다 만약

Ind irec t C R L 에 서 이 영역 이 생략되 면 발 행 자 는 취소

리 스 트 에 서 이 전 에 취소 된 인 증 서 의 발 행 자 로 부 터 상

. 속 받 는 다

37

X.509 의 강한 인증절차

One-way 인증

– AAB: A{tB: A{tAA, r, rAA, B, sgnData, E, B, sgnData, EKUbKUb[K[Kabab]} ]}

Two-way 인증

– AAB: A{tB: A{tAA, r, rAA, B, sgnData, E, B, sgnData, EKUbKUb[K[Kabab]}]}

– BBA: B{tA: B{tBB, r, rBB, A, r, A, rAA, sgnData, E, sgnData, EKUaKUa[K[Kbaba]}]}

Three-way 인증

– AAB: A{tB: A{tAA, r, rAA, B, sgnData, E, B, sgnData, EKUbKUb[K[Kabab]} ]}

– BBA: B{tA: B{tBB, r, rBB, A, r, A, rAA, sgnData, E, sgnData, EKUaKUa[K[Kbaba]}]}

– AAB: A{rB: A{rBB,B},B}

38

PKI 기술 개요

공개키기반구조 (PKI) 정의– PKI 는 인증 , 암호화 , 무결성 및 부인방지를 지원하기 위하여 공개키를

관리하는 Infrastructure 를 말함 (by ITU X.509)

– 공개키 암호에 기반하여 공개키인증서를 발급 , 관리 , 저장 , 분배 , 폐지에 필요한 H/W, S/W, 인적자원 , 정책 및 절차의 총체 (by IETF PKIX)

공개키 기반구조의 구성– 공개키 인증서를 발급 , 폐지하는 인증기관

– 공개키와 인증서 소유자 사이의 관계를 확인하는 등록기관

– 인증서를 발급받고 , 전자문서에 서명하고 암호화를 할 수 있는 공개키 인증서의 소유자

– 인증기관의 공개키를 사용하여 인증경로 및 전자서명을 검증하는 사용자

– 공개키 인증서와 CRL 을 저장하는 저장소

39

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

한국정보인증한국정보인증 (( 주주 ))

RARARARA

............ ............사용자사용자사용자사용자

인증업무인증업무인증업무인증업무및및및및

인증관리체계인증관리체계인증관리체계인증관리체계 운영운영운영운영

공인인증기관공인인증기관공인인증기관공인인증기관지정을지정을지정을지정을 위한위한위한위한심사심사심사심사 및및및및 평가평가평가평가

공인인증기관공인인증기관공인인증기관공인인증기관검사검사검사검사 및및및및 안전운영안전운영안전운영안전운영

지원지원지원지원

상호인정 지원상호인정 지원및및

상호인증상호인증보안통제보안통제보안통제보안통제

기술개발기술개발기술개발기술개발

외국외국외국외국

인증기관인증기관

외국정부외국정부외국정부외국정부정부정부상호상호상호상호

인정인정인정인정

상호상호상호상호

인정인정인정인정


인증인증인증인증

지역등록기관지역등록기관지역등록기관지역등록기관((((RA)RA)RA)RA)

최상위인증기관최상위인증기관 :: 한국정보보호진흥원한국정보보호진흥원((Root Root CA)CA)

사용자사용자사용자사용자 사용자사용자사용자사용자 사용자사용자사용자사용자사용자사용자사용자사용자............

외국정부외국정부외국정부외국정부


인증인증인증인증

인증서 교부인증서 교부

외국외국인증기관인증기관

금융결제원금융결제원

((CA)CA) ((CA)CA) ((CA)CA)

한국증권전산한국증권전산 (( 주주 ))

((CA)CA)

한국전자인증㈜한국전자인증㈜

인증서 교부인증서 교부

한국전산원한국전산원((CA)CA)

40

전자서명과 스마트카드

전자서명 정보처리를 위하여 안전하고 , 휴대 간편한 저장매체 필요

스마트카드– 중요 데이터의 보관 및 처리기능이 있는 일반 신용카드 크기의 보안장치

– 마이크로 프로세서 (MPU), 운영체제 (COS), 저장장치 등으로 구성

스마트카드 특징– 저장된 정보 및 활용의 안전성 제공

– 물리적인 보안 안전성 제공

– 보관 및 휴대의 편리성

활용분야– 공인 인증서 관련 정보 보관 , 전자화폐 , 신용카드

– 전화카드 , 교통카드 , 신분증으로서의 활용 전망

41

한 학기동안 고생 많았습니다 .

Documents

Chap 10. 인증응용