ch14 – 2. 인증프로토콜

충북대 네트워크 보안 연구실[ jinmun @ gmail.com ]

정보 보호 응용정보 보호 응용정보 보호 응용정보 보호 응용

ch14ch14 – – 2. 2. 인증프로토콜인증프로토콜

22007-01 정보보호응용

목 차목 차

인증 개요

사용자 인증

인증 프로토콜

1. Kerberos

2. X.509 Authentication Service


인증 개요인증 개요

메시지 인증메시지 암호화 방식

해쉬함수를 이용한 방식

사용자 인증지문 , 동공 , 필적 , 성문 , 입술 , 족적

Password, PIN

암호

일방향 인증과 양방향 인증일방향 인증 : 서버 (B) 가 클라이언트 (A) 를 일방적으로 인증하는 방식

양방향 인증 : 서버 (B) 와 클라이언트 (A) 가 서로를 인증하는 방식


사용자 인증사용자 인증

사용자 인증 : 신분 확인 사용자 인증 종류

그 사람이 알고 있는 것– 패스워드

그 사람이 가지고 있는 것– 신분증 , 여권 , 인증서

그 사람의 물리적 특성– 음성 , 지문 , 홍체 , 얼굴 등

그 사람의 무의식적인 행동 양식– 서명


사용자 인증 사용자 인증 (( 계속계속 ))

일방향 함수를 이용한 인증

h

Yes사용자 A

No패스워드

Directory

h ( 패스워드 )



관용 암호 방식을 이용한 인증 방식

사용자 A 컴퓨터

KA

R = EKA(r)

KA

난수 r

r = DKA(R) 확인R

r





공개키 암호 방식을 이용한 인증 방식

사용자 A공개 정보

PKA

컴퓨터

PKA , SKA ( 개인키 )

R = ESKA(r)

PKA

난수 r

r = DPKA(R) 확인

R

r



102007-01 정보보호응용


사용자인증 구성도


P검증자 B

난수 r

(1) commitment

w = f(r)

S : 비밀식별 정보

(3) response

R = g1(S, r, E)

(2) challenge

E R{0, 1, 2, , st–1}

(4) R 확인

w = g2(P, E, R)

R

E

w

112007-01 정보보호응용


T. Okamoto 방식이산대수 문제 이용 ; 키 인증 센터 (KAC) 필요 공개 개인식별 정보 인증서 발급


p, q, g1, g2, PKKAC

KAC

XA1, XA2

R Zq

yA g1XA1 g2

XA2 mod pS = S SKKAC

(ID(A), yA)

C(A) = (ID(A), yA, S)

C(A)

ID(A), yA

122007-01 정보보호응용


T. Okamoto 인증의 구성


p, q, g1, g2, yA

검증자 B

q | p –1

r1, r2 R Zq

w g1r1 g2

r2 mod p

R1 r1 + XA1 E mod q

R2 r2 + XA2 E mod q

C(A) 확인E R{0, 1, 2, , 2t–1}

w g1R1 g2

R2 yA –E mod p

C(A), w

E

R1, R2

132007-01 정보보호응용


T. Okamoto 의 인증의 검증

g1R1 g2

R2 yA –E mod p

R1 r1 + XA1 E mod q

R2 r2 + XA2 E mod q

g1r1 g1

XA1E g2r2 g2

XA2E g1 – XA1E g2

– XA2E mod p

g1r1 g2

r2 mod p

w g1r1 g2

r2 mod p

w mod p

142007-01 정보보호응용


T. Okamoto 의 인증방식 예


P=23, q=11, g1=3, g2=8, yA=4

검증자 B

r1=5, r2=10 R Zq

w g1r1 g2

r2 mod p

35 * 810 mod 23

16

R1 r1 + XA1 E mod q

5 + 7*9 mod 11

2 mod 11

R2 r2 + XA2 E mod q

10 + 15*9 mod 11

2 mod 11

C(A) 확인

E =9 R{0, 1, 2, , 2t–1}

g1R1 g2

R2 yA –E mod p

32 * 82 * 411-9 mod 23

9*18*16 mod 23

16

w

C(A), w=16

E=9

R1=2, R2=2

152007-01 정보보호응용


상호 인증 방식


yA , yB , p, q, g 사용자 B

KA Zq

wA gKA mod p

E = h(wA) h(wB)

RA KA + XAE mod q

wB gRB yB–E mod p

KB Zq

wB gKB mod p

E = h(wA) h(wB)

RB KB + XBE mod q

wA gRA yA–E mod p

wB

wA

RB

RA

162007-01 정보보호응용

1. KERBEROS1. KERBEROS

MIT 에서 Athena 프로젝트로 개발된 인증 서비스 Kerberos 설계 요구사항

안전성 (secure) : 네트워크 침입자의 공격에 대한 안전성 .

신뢰성 (reliable) : Kerberos 의 신뢰성이 보장

투명성 (transparent) : 사용자가 복잡한 인증절차를 인식하지 못하도록 함 .

규모 (scale) : 대규모의 Client/Server 를 지원하는 분산 구조

172007-01 정보보호응용

KerberosKerberos 의 특징의 특징

Kerberos 의 두 가지 버전Version4 : 인증서비스 제공을 위한 초기 버전 . 가장 널리 쓰임 .

Version5 : Version 4 의 보안 결함을 수정 .

문제점Replay attack 이 가능모든 클라이언트와 서버의 시간 동기화 문제Kerberos 서버의 보안 문제

다양한 Internet 표준

182007-01 정보보호응용

1.1 A Simple Authentication Dialogue1.1 A Simple Authentication Dialogue

간단한 인증 프로토콜서비스에 접속하기 위해 인증 서버에 접속해서 인증받는 과정

C

IDC, PC, IDV

Ticket

IDC, Ticket

Ticket : EKV[IDC, ADC, IDV]

사용자

Login(ID, Password)

2

3

4서비스

1

AS

V

여기서

C : Client, AS : 인증 서버 , V : 서비스 서버 , P : 패스워드 , ID : 식별자

AD: 네트워크 주소 , KV: AS 와 V 간의 비밀키

192007-01 정보보호응용


1. 사용자는 클라이언트 (C)에 ID와 패스워드를 입력 .

2. 클라이언트 (C)는 사용자의 ID, 패스워드 및 서비스서버 (V)의 식별자를 인증서버 (AS)에 전송 .

3. AS는 ID와 패스워드를 검사하고 클라이언트의 네트워크 주소를 포함하는 인증 티켓을 발급 (DES로 암호화 ).

네트워크 주소를 포함하는 이유 : 티켓이 중간에서 가로채서 사용하려는 경우의 방지 .

4. 서비스서버 (V) 는 티켓을 복호하고 전송된 ID와 티켓속의 ID가 일치하는지 확인 , 일치하면 사용자에게 서비스 개시 .

202007-01 정보보호응용


문제점 :패스워드가 평문으로 전달됨

패스워드 가로채기 가능

티켓의 재사용 불가능 :

새로운 서비스를 위해서는 또 다시 패스워드 입력 필요 .

티켓의 재사용으로 해결 가능 ( 티켓의 저장 )

문제점을 해결하기 위해 Ticket-Granting Server(TGS)개념을 도입 .

212007-01 정보보호응용

1.2 Secure Authentication Dialogue1.2 Secure Authentication Dialogue

간단한 인증 프로토콜의 개선사용자는 매일 서버에 접속할 대마다 패스워드를 입력

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

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

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

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

222007-01 정보보호응용


C

IDC, IDtgs

EKC(Tickettgs)

IDC, IDV, Tickettgs

사용자

TicketV

TicketV

로그온시 한번

서비스마다 한번

서비스 세션당 한번

티켓 승인 티켓 TicketTGS=EKtgs[IDC, ADC, IDtgs, Lifetime1]

서비스 승인 티켓 TicketV=EKV[IDC, ADC, IDV, Lifetime2]

• TGSTGS 를 이용한 인증 프로토콜를 이용한 인증 프로토콜

AS

TGS

V

232007-01 정보보호응용


TGS 를 이용한 인증 프로토콜 설명

1. 클라이언트는 사용자 ID 와 TGS 의 ID 를 인증 서버에 전송 .

2. 인증 서버는 패스워드에 기반한 티켓 승인 티켓 생성 후 암호화 하여 클라이언트에 전송 .

* 티켓에 재사용 방지를 위해 발행시간 과 유효시간을 포함 .

3. 클라이언트 사용자 ID, 요구하는 서비스의 ID, 을 TGS 에 전송함으로써 서비스 승인티켓 요구 .

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

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

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

242007-01 정보보호응용


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

단점Ticket 의 유효기간 문제

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

유효기간이 매우 길다면 , 침입자의 재전송 공격 가능Ticket 를 가로채서 메시지를 조작 전송하여 서비스 티켓 요구

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

252007-01 정보보호응용

1.3 Kerberos V41.3 Kerberos V4 의 인증 프로토콜의 인증 프로토콜

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

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

비밀키의 분배 공유

262007-01 정보보호응용


Kerberos V4 프로토콜 설명

인증 서버 (AS)

티켓승인서버 (TGS)

Sever

6. 서비스 요구

1. 사용자 로그온

2. TGS 에 대한 접속 요구

3. 티켓 & 세션키

4. 서비스 승인 티켓 요구5. 티켓 & 세션키

7. 서버 인증자 제공

272007-01 정보보호응용


IDC, IDtgs, TS1

EKC(Kc, tgs,||IDtgs ||TS2|| Lifetime2||Tickettgs)

IDV, Tickettgs ||AuthenticatorC

EKC, tgs[KC, V||IDV||TS4||TicketV]

TicketV ||AuthenticatorC

인증 서비스교환 : 티켓 승인 - 티켓 획득

티켓 승인서비스 교환: 서비스 승인티켓 획득

클라이언트 / 서버인증 교환: 서비스

TicketTGS=EKtgs[KC,tgs||IDC|| ADC|| IDtgs||TS2||Lifetime1]

EKc, v[TS5+1]

TicketTGS=EKtgs[KC,tgs||IDC|| ADC|| IDV||TS2||Lifetime2]Ticketv=EKtgs[KC,V, tgs||IDC|| ADC|| IDV||TS4||Lifetime4]Authenticatorc=Ekc,tgs[|IDC|| ADC|| TS3]

Ticketv=EKtgs[KC,V||IDC|| ADC|| IDV||TS4||Lifetime4]Authenticatorc=EKc,v[|IDC|| ADC|| TS5]

C

AS

TGS

V

282007-01 정보보호응용


Kerberos V4 프로토콜 설명

세션키 분배 5 개의 비밀키 사용 :

타임 스탬프 5 개의 타임 스탬프 사용

인증자의 추가 매우짧은 유효기간 , 단 한번만 인증자 (Authenticator) 사용

재사용 공격 방지서버의 상호 인증 구현

인증자내의 타임스탬프 +1 값을 리턴 클라이언트는 메시지를 복호후 , 타임 스탬프 확인 메시지의 복호가 가능하려면 세션키를 알고 있어야 하기 때문에 서버가 V 라는 것을 확신

292007-01 정보보호응용


다중 Kerberos Kerberos 서버 , 여러 개의 클라이언트 및 응용 서버들로 구성

Kerberos 서버는 반드시 ID 와 사용자의 해쉬된 패스워드 데이터베이스 보유

모든 서버는 Kerberos 서버에 등록하고 각각 비밀키를 공유영역 (realm) : 클라이언트와 서버의 관리 조직 환경

상호 영역간의 인증 메커니즘이 필요 상호운영 영역에 있는 Kerberos 서버는 비밀키를 다른 영역의

서버와 공유 ( 각 서버는 상호 등록하고 신뢰 관계 필요 )

다른 영역에 있는 서버의 서비스 요구 동일 영역에서 일반적인 절차 접속 원격 TGS 에 티켓 - 승인 티켓 요구 ( 원격 TGS 에 접속 ) 원하는 서버에 대한 서비스 - 승인 티켓 요구

302007-01 정보보호응용


서로 다른 영역에서의 서비스

312007-01 정보보호응용


영역 A 의 클라이언트가 영역 B 의 서버의 서비스를 요구(1) C → AS : IDc∥IDtgs ∥TS1

(2) AS → C : EKc[Kc,tgs∥IDtgs∥TS2∥Lifetime2∥Tickettgs]

(3) C → TGS : IDtgsrem ∥Tickettgs ∥Authenticatorc

(4) TGS → C : EKc,tgs[Kc,tgsrem ∥IDtgsrem∥TS4 ∥Tickettgsrem]

(5) C → TGSrem : IDvrem ∥Tickettgsrem ∥Authenticatorc

(6) TGSrem → C : EKc,tgsrem[Kc,vrem∥IDvrem ∥TS6 ∥Ticketvrem ]

(7) C → Vrem : Ticketvrem ∥Authenticatorc

322007-01 정보보호응용


Version 4 의 결점 보완암호화 시스템에 대한 의존 : DES 사용 (DES의 수출제한 )

Version 5는 다른 암호 알고리즘 사용 가능인터넷 프로토콜에 대한 의존 :V4는 IP 주소 사용만 허용

Version 5는 다른 형식의 주소 사용 가능메시지 바이트 순서 : v4 순서 표시 고정

V5 : ASN.1(추상구문 표기법 ) V5 : BER 인코딩 규칙 표준 사용 ( 기본 부호규칙 )

티켓 유효시간 : v4는 최대 1280분 ( 약 21시간 ) 동안만 사용 가능 Version 5 : 시작 시간과 끝시간 표시 ( 충분한 유효시간 )

인증의 발송이 불가능 Version 5에서는 가능

상호 인증 Version 5에서는 Kerberos 대 Kerberos의 상호 인증이 가능

332007-01 정보보호응용


Kerberos V4 의 기술적 결함 보완 이중 암호화

타겟 서버의 비밀키 , 클라이언트 비밀키PCBC 암호화

버전 4 에서는 DES의 비표준 모드인 PCBC 모드 사용 : 공격에 취약

버전 5 에서는 표준 모드인 CBC 모드 사용세션키 : 버전 4 에서는 세션키의 연속적 사용 가능 ( 재전송

공격 ) 버전 5 에서는 단 1 회만 사용되는 서브 세션키 협약 가능

패스워드 공격 : 패스워드를 추측하는 공격이 가능 버전 5 에서는 패스워드 추측 공격이 어렵 ( 사전 인증 기능 )

패스워드 공격을 완전히 막을 수는 없음

342007-01 정보보호응용


Kerberos서버 , 여러 개의 클라이언트 및 응용 서버들로 구성된 Kerberos의 서비스 환경은 다음을 요구Kerberos 서버는 반드시 ID와 사용자의 해쉬된 패스워드 DB를

보유모든 서버는 Kerberos 서버에 등록하고 각각 비밀키를 공유

영역 (realm) : 클라이언트와 서버의 관리 조직 환경상호 영역간의 인증 메커니즘이 필요상호운영 영역에 있는 Kerberos서버는 비밀키를 다른 영역의 서버와

공유 ( 각 서버는 상호 등록하고 신뢰 관계 필요 )

다른 영역에 있는 서버의 서비스 요구동일 영역에서 일반적인 절차 접속원격 TGS에 티켓 - 승인 티켓 요구 ( 원격 TGS에 접속 )원하는 서버에 대한 서비스 - 승인 티켓 요구

352007-01 정보보호응용


Realm: 사용자의 영역 Options: 전달 티켓에 어떤 flag 설정되도록 요구 Times: 클라이언트가 티켓에 시간 설정 요구위해 사용

from: 티켓에서 요구하는 시작시간till: 티켓에서 요구하는 유효 종료시간rtime: 재갱신 유효시간

Nonce: 응답이 올바르다는 것을 보증하기 위하여 메시지 (2) 에서 반복되는 난수 값

Subkey: 특정한 응용 세션을 보호하기 위해 클라이언트가 서브키 사용가능 ( 없으면 Kc,v( 세션키 ) 사용 )

Seq#: 응용 세션동안의 순서번호 지정 ( 재전송 판단 )

362007-01 정보보호응용


Flag 의 미

INITIAL

PRE-AUTHENT

HW-AUTHENT

RENEWABLE

MAY-POSTDATE

POSTDATED

INVALID

PROXIABLE

PROXY FORWARDABLE

FORWADED

AS 프로토콜을 이용하여 발행

C 는 티켓이 발행되기 전에 KDC 에 의해 인증

하드웨어의 이용이 필요한 초기 인증요구

교체 티켓을 얻기 위해 재사용될 수 있음 표시

날짜가 지난 티켓이 발행된 것임을 알림

날짜가 지났음을 가리킴

사용전에 KDC 에 의해 유효성 검증 필요

이 티켓이 대리인임을 가리킴

다른 네트워크 주소를 이용하여 발행 가능

인증을 기반으로 발행된 것임을 가리킴

372007-01 정보보호응용

2. X.509 2. X.509 인증 서비스인증 서비스 ITU 와 ISO/IEC/JTC1/SC21 협동 프로젝트로 1985 년부터 개발에

착수 디렉토리 서비스를 정의하는 X.500 시리즈 권고안의 일부 디렉토리 :

사용자 정보 데이터베이스를 관리하는 서버공개키 인증서의 저장소 역할도 수행

X.509 : 사용자에게 X.500 디렉토리에 의한 인증 서비스의 규정을 정의인증서의 구조인증 프로토콜

X.509 의 기반공개키 암호화 기법디지털 서명

공개키 인증서의 내용 : 공개키의 사용자 정보를 인증기관의 개인키로 서명

382007-01 정보보호응용

2.1 X.509 2.1 X.509 인증서인증서

392007-01 정보보호응용

2.1 X.5092.1 X.509 인증서인증서

인증서 주요 항목들버젼 필드 : 인증서 형식을 나타냄일련번호 : CA 내에서 유일함서명 알고리즘 : 인증서를 서명하는데 사용된 알고리즘발행인 : CA 의 이름유효기간 : 날짜의 쌍으로 인증서는 두 날짜 사이의 기간동안

유효함주체 이름 : 인증서가 발급된 사용자의 이름주체 공개키 필드 : 알고리듬과 공개키를 포함서명 : CA 의 서명

402007-01 정보보호응용

2.2 2.2 사용자 인증서사용자 인증서

인증서에서의 표기법CA<<A>> = CA{V, SN, AI, CA, TA, A, AP}

Y<<X>> : 인증기관 Y에 의하여 발행된 사용자 X 의 인증서

Y{I} : Y 에 의한 I의 서명

인증서 요청 처리 절차인증서 요청은 CA 로부터 서명을 받고자 하는 개인 사용자에

의하여 시작됨인증서 요청 ( 사용자 이름 , 전자우편주소 , 공개키 등의 정보를

포함함 ) 은 개인키로 암호화되어 CA 에게 전달됨CA 는 사용자 이름과 공개키를 추출하여 공개키가 요청자의

것인지를 확인하여 인증서를 발행하여 요청자에게 전달함

412007-01 정보보호응용


사용자의 인증서 획득CA 에 의해 생성된 사용자 인증서의 특성

CA 의 공개키에 접근하는 모든 사용자는 확인된 사용자 공개키를 검증할 수 있음

인증기관 이외의 누구도 발각되지 않고 인증서를 수정할 수 없음

CA 의 계층 구조 ( 그림 14.4) 상위 계층이 하위 계층을 신뢰하는 개념 임의의 A 는 두 가지 형태의 인증서를 가짐 ( 예 : CA X)

– 순방향 인증서 : 다른 CA 에 의하여 생성된 X 의 인증서– 역방향 인증서 : X 에 의하여 생성된 다른 CA 의 인증서

422007-01 정보보호응용


사용자의 인증서 획득 사용자 A 의 B 에 대한 인증서

경로를 만들기 위한 인증서 획득 순서 X<<W>>W<<V>>V<<Y>

>Y<<Z>>Z<<B>>

A 는 이 인증서 경로를 이용하여 B의 공개키를 얻고 B 의 공개키를 이용하여 암호화된 메시지를 B에게 전달 B 가 A 이 공개키를 필요로 하면 Z<<Y>>Y<<V>>V<<W>

>W<<X>>X<<A>>

의 인증서 경로를 이용하여 획득함

432007-01 정보보호응용


사용자의 인증서 취소인증서는 신용카드와 유사한 유효기간을 가지고 있음 . 인증서는

다음 이유 중 한가지 때문에 취소하는 것이 바람직 할 때가 있음 사용자의 개인키가 손상된 것으로 간주될 때 사용자가 이 CA 에 의해 더 이상 인증되지 않을 때 CA 의 인증서가 손상된 것으로 간주될 때

CA 는 취소된 인증서의 목록을 관리하여야 함 ( 그림 14.3b)

442007-01 정보보호응용

2.3 2.3 사용자 인증사용자 인증

인증 절차

그림 14.5 : 3 가지 인증 절차

452007-01 정보보호응용


모든 절차는 공개키 서명을 이용함

상대방의 공개키는 알고 있는 것으로 가정1) 일방향 인증 (One-Way Authentication)

단방향 인증은 한 사용자 A 로부터 다른 사용자 B 로 정보의 전달이 한 번 이루어짐

처리 결과 A 에 대한 신원 확인과 메시지가 A 에 의해 생성되었음 메시지가 B 에게 전송될 의도임 메시지의 무결성과 원본성 ( 여러 번 보내지 않았음 )

개시자의 확인만 가능

462007-01 정보보호응용


Two-Way Authentication

일방향의 인증의 세가지 요소에 다음과 같은 요소를 추가

B 에 대한 신원 확인과 응답 메시지가 B 에 의하여 생성되었음

메시지가 A 에게 전송될 의도임

응답의 무결성과 원본성

양쪽의 당사자를 인정함

472007-01 정보보호응용


Three-Way Authentication임시비표의 서명된 복사본이 A 로부터 B 로 가는 마지막 메시지가 내포됨타임 스탬프의 점검이 불필요

⇒ 각 임시비표는 상대편에 의해 반향되기 때문에 사용 당사자는 재전송 공격을 예방하기 위해 돌아온 임시비표를 점검할 수 있음

동기화된 시계가 사용 불가능한 경우 유용

Documents

ch14 – 2. 인증프로토콜