ch14 – 2. 인증프로토콜

1. ch14–2. 인증프로토콜

2. 목 차 • 인증 개요 • 사용자 인증 • 인증 프로토콜 1. Kerberos 2. X.509 Authentication Service 2

3. 인증 개요 • 메시지 인증 • 메시지 암호화 방식 • 해쉬함수를 이용한 방식 • 사용자 인증 • 지문, 동공, 필적, 성문, 입술, 족적 • Password, PIN • 암호 • 일방향 인증과 양방향 인증 • 일방향 인증 : 서버(B)가 클라이언트(A)를 일방적으로 인증하는 방식 • 양방향 인증: 서버(B)와 클라이언트(A)가 서로를 인증하는 방식 3

4. 사용자 인증 • 사용자 인증 : 신분 확인 • 사용자 인증 종류 • 그 사람이 알고 있는 것 • 패스워드 • 그 사람이 가지고 있는 것 • 신분증, 여권, 인증서 • 그 사람의 물리적 특성 • 음성, 지문, 홍체, 얼굴 등 • 그 사람의 무의식적인 행동 양식 • 서명 4

5. h 사용자 인증 (계속) • 일방향 함수를 이용한 인증 Directory h (패스워드) Yes 사용자 A  패스워드 No 5

6. r R 사용자 인증 (계속) • 관용 암호 방식을 이용한 인증 방식 6

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

8. 사용자 인증 (계속) • 공개키 암호 방식을 이용한 인증 방식 r R 8

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

10. w E R 사용자 인증 (계속) • 사용자인증 구성도 10

11. ID(A), yA C(A) 사용자 인증 (계속) • T. Okamoto 방식 • 이산대수 문제 이용; 키 인증 센터(KAC) 필요 • 공개 개인식별 정보 인증서 발급 11

12. 사용자 인증 (계속) • T. Okamoto 인증의 구성 C(A), w E R1, R2 12

13. 사용자 인증 (계속) • T. Okamoto의 인증의 검증 g1R1 g2R2 yA –Emod p R1 r1 + XA1E mod q R2 r2 + XA2E mod q  g1r1 g1XA1Eg2r2 g2XA2E g1 –XA1E g2 –XA2Emod p  g1r1 g2r2mod p w  g1r1 g2r2 mod p  w mod p 13

14. 사용자 인증 (계속) • T. Okamoto의 인증방식 예 C(A), w=16 E=9 R1=2, R2=2 14

15. wB wA RB RA 사용자 인증 (계속) • 상호 인증 방식 15

16. 1. KERBEROS • MIT에서 Athena 프로젝트로 개발된 인증 서비스 • Kerberos 설계 요구사항 • 안전성(secure) : 네트워크 침입자의 공격에 대한 안전성. • 신뢰성(reliable) : Kerberos의 신뢰성이 보장 • 투명성(transparent) : 사용자가 복잡한 인증절차를 인식하지 못하도록 함. • 규모(scale) : 대규모의 Client/Server를 지원하는 분산 구조 16

17. Kerberos의 특징 • Kerberos의 두 가지 버전 • Version4 : 인증서비스 제공을 위한 초기 버전. 가장 널리 쓰임. • Version5 : Version 4의 보안 결함을 수정. • 문제점 • Replay attack이 가능 • 모든 클라이언트와 서버의 시간 동기화 문제 • Kerberos 서버의 보안 문제 • 다양한 Internet 표준 17

18. 1.1 A Simple Authentication Dialogue • 간단한 인증 프로토콜 • 서비스에 접속하기 위해 인증 서버에 접속해서 인증받는 과정 사 용 자 Login(ID, Password) C 1 2 AS IDC, PC, IDV 3 Ticket 4 V IDC, Ticket 서비스 Ticket : EKV[IDC, ADC, IDV] 여기서 C : Client, AS : 인증 서버, V : 서비스 서버, P : 패스워드, ID : 식별자 AD: 네트워크 주소, KV: AS와 V간의 비밀키 18

19. 1.1 A Simple Authentication Dialogue • 사용자는 클라이언트(C)에 ID와 패스워드를 입력. • 클라이언트(C)는 사용자의 ID, 패스워드 및서비스서버(V)의 식별자를 인증서버(AS)에 전송. • AS는 ID와 패스워드를 검사하고 클라이언트의 네트워크 주소를 포함하는 인증 티켓을 발급(DES로 암호화). • 네트워크 주소를 포함하는 이유 : 티켓이 중간에서 가로채서 사용하려는 경우의 방지. • 서비스서버(V) 는 티켓을 복호하고 전송된 ID와 티켓속의 ID가 일치하는지 확인, 일치하면 사용자에게 서비스 개시. 19

20. 1.1 A Simple Authentication Dialogue • 문제점: • 패스워드가 평문으로 전달됨 • 패스워드 가로채기 가능 • 티켓의 재사용 불가능 : • 새로운 서비스를 위해서는 또 다시 패스워드 입력 필요. • 티켓의 재사용으로 해결 가능(티켓의 저장) 문제점을 해결하기 위해 Ticket-Granting Server(TGS)개념을 도입. 20

21. 1.2 Secure Authentication Dialogue • 간단한 인증 프로토콜의 개선 • 사용자는 매일 서버에 접속할 대마다 패스워드를 입력 • AS에게서 발급 받은 티켓을 저장하여 재사용. • 서버의 종류와 해당 서버에서 각 서비스 세션의 개별적 구분가능 • 평문 패스워드의 네트워크 전송없이 인증하는 방법 필요 • TGS를 이용하여 재사용 가능한 2가지 티켓 발행 21

22. 1.2 Secure Authentication Dialogue • TGS를 이용한 인증 프로토콜 AS C IDC, IDtgs 사용자 EKC(Tickettgs) 로그온시 한번 티켓 승인 티켓 TicketTGS=EKtgs[IDC, ADC, IDtgs, Lifetime1] TGS IDC, IDV, Tickettgs TicketV 서비스마다 한번 서비스 승인 티켓 TicketV=EKV[IDC, ADC, IDV, Lifetime2] V TicketV 서비스 세션당 한번 22

23. 1.2 Secure Authentication Dialogue • TGS를 이용한 인증 프로토콜 설명 • 클라이언트는 사용자 ID와 TGS의 ID를 인증 서버에 전송. • 인증 서버는 패스워드에 기반한 티켓 승인 티켓 생성 후 암호화 하여 클라이언트에 전송. * 티켓에 재사용 방지를 위해 발행시간 과 유효시간을 포함. • 클라이언트 사용자 ID, 요구하는 서비스의 ID, 을 TGS에 전송함으로써 서비스 승인티켓 요구. • TGS는 돌아온 티켓을 복호하고 복호의 성공여부, ID의 일치 여부, 사용자 네트워크 주소확인, 유효기간 확인 등의 수행 후 Ticket 발급. • 클라이언트는 사용자 ID와 Ticket를 제시하여 서비스 접속 요구. 이후, 서버는 사용자 ID 와 Ticket를 복호하고 검증한 다음 서비스 연결 23

24. 1.2 Secure Authentication Dialogue • 장점 • 패스워드의 평문 전송 불필요 • 티켓의 재사용 가능 • 단점 • Ticket 의 유효기간 문제 • 유효기간이 매우 짧다면, 패스워드의 반복입력 요구 (시스템 부담) • 유효기간이 매우 길다면, 침입자의 재전송 공격 가능 Ticket 를 가로채서 메시지를 조작 전송하여 서비스 티켓 요구 • 서버의 인증 불가 • 불법적 서버의 위장된 서비스 방지기능 필요(상호인증) 24

25. 1.3 Kerberos V4의 인증 프로토콜 • TGS를 이용한 인증 프로토콜의 개선안 • 서버에 대한 상호인증 포함하여 수행 • 비밀키의 분배 공유 25

26. 1.3 Kerberos V4의 인증 프로토콜 • Kerberos V4 프로토콜 설명 1. 사용자 로그온 2. TGS에 대한 접속 요구 3. 티켓 & 세션키 인증 서버(AS) 4. 서비스 승인 티켓 요구 5. 티켓 & 세션키 6. 서비스 요구 티켓승인서버(TGS) 7. 서버 인증자 제공 Sever 26

27. 1.3 Kerberos V4의 인증 프로토콜 AS C IDC, IDtgs, TS1 인증 서비스 교환 : 티켓 승인-티켓 획득 EKC(Kc, tgs,||IDtgs ||TS2|| Lifetime2||Tickettgs) TicketTGS=EKtgs[KC,tgs||IDC|| ADC|| IDtgs||TS2||Lifetime1] TGS 티켓 승인 서비스 교환 : 서비스 승인 티켓 획득 IDV, Tickettgs ||AuthenticatorC EKC, tgs[KC, V||IDV||TS4||TicketV] 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] 클라이언트/서버 인증 교환 : 서비스 V TicketV ||AuthenticatorC EKc, v[TS5+1] Ticketv=EKtgs[KC,V||IDC|| ADC|| IDV||TS4||Lifetime4] Authenticatorc=EKc,v[|IDC|| ADC|| TS5] 27

28. 1.3 Kerberos V4의 인증 프로토콜 • Kerberos V4 프로토콜 설명 • 세션키 분배 • 5개의 비밀키 사용 : • 타임 스탬프 • 5개의 타임 스탬프 사용 • 인증자의 추가 • 매우짧은 유효기간, 단 한번만 인증자(Authenticator) 사용 • 재사용 공격 방지 • 서버의 상호 인증 구현 • 인증자내의 타임스탬프 +1 값을 리턴 • 클라이언트는 메시지를 복호후, 타임 스탬프 확인 • 메시지의 복호가 가능하려면 세션키를 알고 있어야 하기 때문에 서버가 V라는 것을 확신 28

29. 1.3 Kerberos V4의 인증 프로토콜 • 다중 Kerberos • Kerberos서버, 여러 개의 클라이언트 및 응용 서버들로 구성 • Kerberos 서버는 반드시 ID와 사용자의 해쉬된 패스워드 데이터베이스 보유 • 모든 서버는 Kerberos 서버에 등록하고 각각 비밀키를 공유 • 영역(realm) : 클라이언트와 서버의 관리 조직 환경 • 상호 영역간의 인증 메커니즘이 필요 • 상호운영 영역에 있는 Kerberos서버는 비밀키를 다른 영역의 서버와 공유(각 서버는 상호 등록하고 신뢰 관계 필요) • 다른 영역에 있는 서버의 서비스 요구 • 동일 영역에서 일반적인 절차 접속 • 원격 TGS에 티켓-승인 티켓 요구(원격 TGS에 접속) • 원하는 서버에 대한 서비스-승인 티켓 요구 29

30. 1.3 Kerberos V4의 인증 프로토콜 • 서로 다른 영역에서의 서비스 30

31. 1.3 Kerberos V4의 인증 프로토콜 • 영역 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 31

32. 1.4 Kerberos V5의 인증 프로토콜 • 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의 상호 인증이 가능 32

33. 1.4 Kerberos V5의 인증 프로토콜 • Kerberos V4의 기술적 결함 보완 • 이중 암호화 • 타겟 서버의 비밀키, 클라이언트 비밀키 • PCBC 암호화 • 버전 4에서는 DES의 비표준 모드인 PCBC 모드 사용 :공격에 취약 • 버전 5에서는 표준 모드인 CBC 모드 사용 • 세션키 :버전 4에서는 세션키의 연속적 사용 가능(재전송 공격) • 버전 5에서는 단 1회만 사용되는 서브 세션키 협약 가능 • 패스워드 공격 :패스워드를 추측하는 공격이 가능 • 버전 5에서는 패스워드 추측 공격이 어렵(사전 인증 기능) • 패스워드 공격을 완전히 막을 수는 없음 33

34. 1.4 Kerberos V5의 인증 프로토콜 • Kerberos서버, 여러 개의 클라이언트 및 응용 서버들로 구성된 Kerberos의 서비스 환경은 다음을 요구 • Kerberos 서버는 반드시 ID와 사용자의 해쉬된 패스워드 DB를 보유 • 모든 서버는 Kerberos 서버에 등록하고 각각 비밀키를 공유 • 영역(realm) : 클라이언트와 서버의 관리 조직 환경 • 상호 영역간의 인증 메커니즘이 필요 • 상호운영 영역에 있는 Kerberos서버는 비밀키를 다른 영역의 서버와 공유(각 서버는 상호 등록하고 신뢰 관계 필요) • 다른 영역에 있는 서버의 서비스 요구 • 동일 영역에서 일반적인 절차 접속 • 원격 TGS에 티켓-승인 티켓 요구(원격 TGS에 접속) • 원하는 서버에 대한 서비스-승인 티켓 요구 34

35. 1.4 Kerberos V5의 인증 프로토콜 • Realm:사용자의 영역 • Options:전달 티켓에 어떤 flag 설정되도록 요구 • Times:클라이언트가 티켓에 시간 설정 요구위해 사용 • from:티켓에서 요구하는 시작시간 • till:티켓에서 요구하는 유효 종료시간 • rtime:재갱신 유효시간 • Nonce:응답이 올바르다는 것을 보증하기 위하여 메시지(2)에서 반복되는 난수 값 • Subkey:특정한 응용 세션을 보호하기 위해 클라이언트가 서브키 사용가능(없으면 Kc,v(세션키) 사용) • Seq#:응용 세션동안의 순서번호 지정(재전송 판단) 35

36. 1.4 Kerberos V5의 인증 프로토콜 36

37. 2. X.509 인증 서비스 • ITU와 ISO/IEC/JTC1/SC21 협동 프로젝트로 1985년부터 개발에 착수 • 디렉토리 서비스를 정의하는 X.500 시리즈 권고안의 일부 • 디렉토리 : • 사용자 정보 데이터베이스를 관리하는 서버 • 공개키 인증서의 저장소 역할도 수행 • X.509 : 사용자에게 X.500 디렉토리에 의한 인증 서비스의 규정을 정의 • 인증서의 구조 • 인증 프로토콜 • X.509의 기반 • 공개키 암호화 기법 • 디지털 서명 • 공개키 인증서의 내용 : 공개키의 사용자 정보를 인증기관의 개인키로 서명 37

38. 2.1 X.509 인증서 38

39. 2.1 X.509인증서 • 인증서 주요 항목들 • 버젼필드 : 인증서형식을나타냄 • 일련번호 : CA 내에서유일함 • 서명알고리즘 : 인증서를서명하는데사용된알고리즘 • 발행인 : CA 의이름 • 유효기간 : 날짜의쌍으로 인증서는두날짜사이의기간동안유효함 • 주체 이름 : 인증서가발급된사용자의이름 • 주체공개키필드 : 알고리듬과공개키를포함 • 서명 : CA 의서명 39

40. 2.2 사용자 인증서 • 인증서에서의 표기법 • CA<<A>> = CA{V, SN, AI, CA, TA, A, AP} Y<<X>> : 인증기관 Y에 의하여 발행된 사용자 X의 인증서 Y{I} : Y에 의한 I의 서명 • 인증서 요청 처리 절차 • 인증서 요청은 CA로부터 서명을 받고자 하는 개인 사용자에 의하여 시작됨 • 인증서 요청(사용자 이름, 전자우편주소, 공개키 등의 정보를 포함함)은 개인키로 암호화되어 CA에게 전달됨 • CA는 사용자 이름과 공개키를 추출하여 공개키가 요청자의 것인지를 확인하여 인증서를 발행하여 요청자에게 전달함 40

41. 2.2 사용자 인증서 • 사용자의 인증서 획득 • CA에 의해 생성된 사용자 인증서의 특성 • CA의 공개키에 접근하는 모든 사용자는 확인된 사용자 공개키를 검증할 수 있음 • 인증기관 이외의 누구도 발각되지 않고 인증서를 수정할 수 없음 • CA의 계층 구조(그림 14.4) • 상위 계층이 하위 계층을 신뢰하는 개념 • 임의의 A는 두 가지 형태의 인증서를 가짐(예 : CA X) • 순방향 인증서 : 다른 CA에 의하여 생성된 X의 인증서 • 역방향 인증서 : X에 의하여 생성된 다른 CA의 인증서 41

42. 2.2 사용자 인증서 • 사용자의 인증서 획득 • 사용자 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>> 의 인증서 경로를 이용하여 획득함 42

43. 2.2 사용자 인증서 • 사용자의 인증서 취소 • 인증서는 신용카드와 유사한 유효기간을 가지고 있음. 인증서는 다음 이유 중 한가지 때문에 취소하는 것이 바람직 할 때가 있음 • 사용자의 개인키가 손상된 것으로 간주될 때 • 사용자가 이 CA에 의해 더 이상 인증되지 않을 때 • CA의 인증서가 손상된 것으로 간주될 때 • CA는 취소된 인증서의 목록을 관리하여야 함(그림 14.3b) 43

44. 2.3 사용자 인증 • 인증 절차 그림14.5 : 3가지 인증 절차 44

45. 2.3 사용자 인증 • 모든 절차는 공개키 서명을 이용함 • 상대방의 공개키는 알고 있는 것으로 가정 • 일방향 인증 (One-Way Authentication) • 단방향 인증은 한 사용자 A로부터 다른 사용자 B로 정보의 전달이 한 번 이루어짐 • 처리 결과 • A에 대한 신원 확인과 메시지가 A에 의해 생성되었음 • 메시지가 B에게 전송될 의도임 • 메시지의 무결성과 원본성(여러 번 보내지 않았음) • 개시자의 확인만 가능 45

46. 2.3 사용자 인증 • Two-Way Authentication • 일방향의 인증의 세가지 요소에 다음과 같은 요소를 추가 • B에 대한 신원 확인과 응답 메시지가 B에 의하여 생성되었음 • 메시지가 A에게 전송될 의도임 • 응답의 무결성과 원본성 • 양쪽의 당사자를 인정함 46

47. 2.3 사용자 인증 • Three-Way Authentication • 임시비표의 서명된 복사본이 A로부터 B로 가는 마지막 메시지가 내포됨 • 타임 스탬프의 점검이 불필요 ⇒ 각 임시비표는 상대편에 의해 반향되기 때문에 사용 당사자는 재전송 공격을 예방하기 위해 돌아온 임시비표를 점검할 수 있음 • 동기화된 시계가 사용 불가능한 경우 유용 47