Chap 10. 인증응용

목 차 1. KERBEROS 2. X.509 디렉토리 인증 서비스

Sever 사용자 로그온 Sever 인증서버 Sever

1. 인증에서의 요구 조건 공격 유형 노출(Disclosure) : 정확한 암호키를 소유하지 않은 사람이나 프로세스에게 메시지의 내용이 노출되는 것 트래픽분석 : 통신자들 사이에 트래픽 패턴을 알아내는 것 위장 : 부정한 소스로부터 나온 메시지를 네트워크 상에 삽입하는 것 내용수정 : 삽입, 삭제, 전치 및 수정을 포함한 메시지 내용의 변경 순서수정 : 삽입, 삭제 및 전치를 통한 쌍방간의 메시지 순서의 변경 시간수정 : 메시지의 지연과 재전송 부인 : 수신자가 메시지 수신을 부인하거나 발신자가 메시지의 발신 부인

1. KERBEROS 분산 환경하에서 개체 인증 서비스를 제공하는 네트워크 인증 시스템 MIT에서 개발 공개키 암호는 전혀 사용하지 않고 관용키 암호 방식만을 사용 중앙 집중식 인증 서버 이용 티켓 발급 서버(Ticket Granting Server) - Trusted Third Party TGS에서 발급받은 티켓을 이용해서 서버로부터 인증 Version 4 : 가장 널리 사용 Version 5 : Version 4의 보안 결함을 수정 Internet Draft 표준

간단한 인증 프로토콜 개방형 분산 C/S 환경: 임의의 C가 임의의 S에 접속 위협요소: 무자격 C의 신분 위장한 S접속==> S는 C의 신분확인 필요 S가 직접 신분확인 처리하는 업무부담 가중 우려 중앙 집중식 인증서버(AS: Authentication Server)를 이용한 모든 C의 신분확인 비밀키의 분배 C <==> AS ; PC(사용자의 패스워드 정보) AS <==> V ; KV(비밀키)

Ticket : EKV[IDC, ADC, IDV] 간단한 인증 프로토콜 User Login(ID, Password) Client AS (1) [IDC, PC, IDV] (2) [Ticket] (3) [IDC, Ticket] V(Server) 서비스 Ticket : EKV[IDC, ADC, IDV] (ADC : C의 네트워크 주소)

간단한 인증 프로토콜 1. U는 서버 V를 사용하기 위해 C에 로그인하고 ID와 패스워드를 입력 2. C는 사용자의 ID, 패스워드, 사용하고자 하는 서버 V의 식별자를 인증서버 AS에 전송 3. AS는 ID와 패스워드가 등록되어 있는지 검사하고 C의 네트웍 주소를 포함하는 인증 티켓을 발급(DES로 암호화해서 티켓을 만들기 때문에 티켓을 클라이언트나 외부에서 조작이 불가능) * 네트워크 주소를 포함하는 이유 : 티켓을 중간에서 가로채서 사용하려는 경우의 방지 4. V는 티켓을 복호하고 평문으로 전송된 ID와 티켓속의 ID가 일치하는지 확인, 일치하면 사용자에게 서비스 개시

간단한 인증 프로토콜의 분석 패스워드 Pc의 전송이 평문으로 전달됨  패스워드 가로채기 가능 티켓의 재사용 불가능: 티켓이 단 한번만 사용되기 때문에 새로운 서비스를 사용하기 위해서는 또 다시 패스워드 입력 필요  티켓의 재사용으로 해결 가능(티켓의 저장) 일방 인증  서버가 일방적으로 클라이언트를 인증 티켓의 다른 클라이언트 사용 방지  ADC 의 사용으로 클라이언트의 네트워크 주소 확인  IDC를 도용하여 티켓의 intercept & replay 불가(티켓을 본래 요구했던 클라이언트의 확인)  Ticket-Granting Server(TGS) 개념 도입으로 문제점 개선

TGS를 이용한 인증 프로토콜 간단한 인증 프로토콜의 개선안 TGS를 이용하여 재사용 가능한 2가지의 티켓 발행 비밀키의 분배 사용자는 메일 서버에 접속 할 때마다 패스워드를 입력(하루에도 여러 번 접속마다 별도의 인증절차 필요) AS에게서 발급 받은 티켓을 저장하여 재사용 서버의 종류와 해당 서버에서의 각 서비스 세션의 개별적 구분가능 평문 패스워드의 네트워크 전송 없이 인증하는 방법 필요 TGS를 이용하여 재사용 가능한 2가지의 티켓 발행 비밀키의 분배 C <==> AS ; KC AS <==> TGS ; Ktgs TGS <==> V ; KV

TicketV=EKV[IDC , ADC , IDV , TS2 , Lifetime2] TGS를 이용한 인증 프로토콜 U C (1) [IDC , IDtgs] AS (2) [EKC(Tickettgs)] 로그온시 한번 Tickettgs=EKtgs[IDC , ADC , IDtgs , TS1 , Lifetime1] TGS (3) [IDC , IDV , Tickettgs] (4) [TicketV] 서비스마다 한번 TicketV=EKV[IDC , ADC , IDV , TS2 , Lifetime2] V (5) [TicketV] 서비스 세션당 한번

TGS를 이용한 인증 프로토콜 1. 클라이언트는 사용자 ID와 TGS의 ID를 인증 서버에 전송 2. 인증 서버는 티켓 승인 티켓(Tickettgs) 생성 후 사용자 패스워드에 기반한 키로 티켓을 암호화하여 클라이언트에 전송 * 티켓에 재사용 방지를 위해 발행시간(TS1)과 유효기간(lifetime)을 포함 3. 클라이언트는 사용자 ID, 요구하는 서비스 ID, Tickettgs 을 TGS에 전송함으로써 서비스 승인 티켓(TicketV) 요구 4. TGS는 들어온 티켓을 복호하고 복호의 성공여부, ID의 일치여부, 사용자 네트워크 주소 확인, 유효기간 확인, 등의 수행 후 TicketV 발급 5. 클라이언트는 사용자 ID와 TicketV 를 제시하여 서비스 접속 요구 이후, 서버는 사용자 ID와 TicketV를 복호하고 검증한 다음 서비스 연결

TGS를 이용한 인증 프로토콜 장점 단점 1. 패스워드의 평문 전송 불필요 2. 티켓의 재사용 가능 1. Tickettgs의 유효기간 문제  유효기간이 매우 짧다면, 패스워드의 반복 입력 요구(시스템 부담)  유효기간이 매우 길다면, 침입자의 재전송 공격 가능성 증가 =>Tickettgs를 가로채서 사용자 로그 아웃 후 (3)의 메시지를 조작전송하여 서비스 티켓 요구(KC , Ktgs 복호 분석 가정) 2. 서버의 인증 불가  불법적 서버의 위장된 서비스 방지기능 필요(상호인증)

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

Kerberos Version 4의 인증 프로토콜 C (1) [IDC, IDtgs, TS1] Tickettgs 획득 AS (2) [EKC(Kc, tgs,||IDtgs ||TS2|| Lifetime2||Tickettgs)] Tickettgs=Ektgs [KC, tgs || IDC || ADC || IDtgs || TS2 || Lifetime2] (3) [IDV, Tickettgs ||AuthenticatorC] TGS TicketV 획득 (4) [EKC,tgs [KC,V || IDV || TS4 || TicketV]] TicketV=EKV[KC,V , IDC , ADC , IDV , TS4 , Lifetime4] AuthenticationC= EKC,tgs [IDC , ADC , TS3] V (5) [TicketV ||AuthenticatorC] 서비스 요구 상호인증 (6) [EKc, v[TS5+1]] AuthenticationC= EKC,V [IDC , ADC , TS5]

Kerberos Version 4의 인증 프로토콜 인증 서버(AS) 티켓승인서버(TGS) Sever (5) 서비스 요구 사용자 로그온 (1) TGS에 대한 접속 요구 (2) 티켓 & 세션키 (3) 서비스 승인 티켓 요구 (4) 티켓 & 세션키 (6) 서버 인증자 제공 로그온마다 한번 서비스 유형마다 한번 서비스 세션마다 한번

Kerberos Version 5의 인증 프로토콜 암호화 시스템에 대한 의존 : DES 사용(DES의 수출제한) V5는 다른 암호 알고리즘 사용 가능 인터넷 프로토콜에 대한 의존 : V4는 IP 주소 사용만 허용 V5는 다른 형식의 주소 사용 가능 메시지 바이트 순서 : 순서 표시 고정 V5 : 추상구문표기법 ASN.1(Abstract Syntax Notation)과 기본부호규칙BER(Basic Encoding Rule) 인코딩 규칙 표준 사용 티켓 유효시간 : 최대 28*5 = 1280 분 동안만 사용 가능 V5 : 시작 시간과 끝시간 표시(충분한 유효시간) V5에서는 인증서의 발송이 가능 V5에서는 상호영역 사이에서 효과적 인증수행 가능

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 인증 서비스

X.500 디렉토리 서비스 ITU와 ISO/IEC/JTC1/SC21 협동 프로젝트로 1985년부터 개발에 착수 DB 구축기술, 분산처리기술, 정보보호 및 통신프로토콜 기술 등이 광범위하게 복합적으로 적용된 대형 분산서버의 집합 개념적 모델의 관점 기능모델: 광범위한 지역의 디렉토리 정보를 기능적으로 어떻게 분산구성, 정보교환 및 체계적 관리 정보모델: 실세계에 관심있는 정보들을 디렉토리에 논리적으로 어떻게 표현 서비스모델: 디렉토리 정보들이 사용자에게 어떻게 서비스되는가 정보보호 모델: 디렉토리를 이용한 정보보호 서비스 이용방법

기능모델 디렉토리는 사람, 조직, 서비스 등과 같은 실세계의 객체(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 기법 사용

기능모델 DIRECTORY DUA DSA DAP DAP, DSP, DISP, DOP Directory System Agent Directory User Agent Directorey Access Protocol Directory System Protocol Directory Information Shadowing Protocol Directory Operational Binding Protocol DUA DSA DIRECTORY DAP DAP, DSP, DISP, DOP

정보보호 모델 디렉토리 시스템에 관한 정보보호 대책 authorization: 디렉토리 사용자가 미리 정의된access control policy에 일치하는 접근 권한을 가진 사용자인지 판별하여 규정된 접근만을 인정 authentication: DSA와 디렉토리 사용자의 신분, 그리고 접근점에 접수된 정보의 발신처 신분을 확인하는 인증서비스를 제공 authentication에서는 사용자의 이름과 패스워드 등을 사용하는 단순 인증과 공개키를 이용한 암호화 기법 등을 사용하는 강한 인증방법 제시

X{Info} = Info,Xs{h(Info)} 단순 인증: 사용자 DN (Distinguished Name), 패스워드, 난수, 타임스탬프 이용 인증 강한 인증 PKCS을 이용한 인증방법 CA가 서명한 인증서를 통한 사용자 공개키의 획득 전자서명: 서명자 X의 키 쌍; Xs/Xp X{Info} = Info,Xs{h(Info)} One-Way, Two-Way, Three-Way 3가지의 인증절차 제시 키 쌍의 생성: 사용자, 제3자, CA가 생성 인증서의 관리: 인증서의 생성, 보관, 취소

인증서 X.509 구조의 핵심은 공개키인증서 사용자 인증서를 인증기관(CA: Certification Authority)에서 발행 인증서는 사용자나 CA가 디렉토리에 보관 디렉토리는 사용자가 인증서를 획득할 수 있는 접속장소를 제공

인증서의 형식

사용자 인증서 구조

인증기관 인증서 구조

인증서 구성요소 버전(version) 일련번호(Serial Number) 서명 알고리즘(Signature Algorithm) 인증서 형식의 X.509 버전 일련번호(Serial Number) CA에 의해서 발행된 모든 공개키 인증서 내에서 인증서의 유일한 ID를 표시한다. 서명 알고리즘(Signature Algorithm) CA가 인증서에 서명하기 위해서 사용한 알고리즘 발행자 이름(Issuer Name) 발행자의 이름은 인증서를 서명하고 생성한 CA의 ID를 표시 유효기간(Validity Period) 인증서의 시작 날짜와 만기일에 대한 날짜와 시간을 지정 사용자 이름(Subject Name) 인증서에 있는 공개키에 대응하는 개인키를 가진 소유주의 ID 사용자 공개키의 정보(Subject Public Key Information) 사용자의 공개키와 사용될 알고리즘 식별자

인증서 구성요소 발행 기관 식별자(Issuer Unique Identifier, version 2 only) X.500 이름이 다른 실체에서 재사용될 경우 CA을 유일하게 식별하기 위한 선택적인 필드 사용자 식별자(Subject Unique Identifier, version 2 only) X.500 이름이 다른 실체에서 재사용될 경우 사용자를 유일하게 식별하기 위한 선택적인 필드 확장(Extensions) 하나 이상의 확장 필드들의 집합. 확장들은 버전3에서 추가 확장필드 이름과 critical 여부와 값으로 구성 만약 확장필드가 critical이라면 클라이언트는 그 확장필드를 처리할 수 있어야 한다. 서명(Signature) 인증서의 다른 모든 영역을 해쉬 코드로 구성하여 CA의 개인키로 암호화 이 영역은 서명 알고리즘 식별자를 포함

인증서 예제 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=jpstudent@ucdavis.edu 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 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 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 Value: 000022811 Signature Info: 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 인증서 예제 Version Certificate serial number Algorithm Parameters Issuer name Not before Not after Subject name Key Issuer unique identifier Subject unique Extensions Encrypted Signature algorithm identifier Period of validity Subject's public-key info Signature

인증서 정의와 서명 인증서 정의 CA<<A>>=CA{V, SN, AI, CA, TA, A, Ap} Y<<X>> 는 인증 기관 Y에 의해 발행된 사용자 X의 인증서 Y{I} 는 Y에 의한 I의 서명. 이것은 암호화된 해쉬 코드를 추가한 I로 구성되어 있다. CA는 개인키로 인증서에 서명을 한다. 일치하는 공개키가 사용자에게 알려져 있으면 그 사용자는 CA에 의해 서명된 인증서가 유효한 것으로 확인할 수 있다.

인증서 계층 구조 순방향 인증서(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]

인증서의 취소 인증서의 취소 사유 사용자는 인증서 획득 시에 취소된 인증서 인지 검사 필요 사용자의 개인키가 손상된 것으로 간주될 때. 사용자가 이 CA에 의해 더 이상 인증되지 않을 때. CA의 인증서가 손상된 것으로 간주될 때. 사용자는 인증서 획득 시에 취소된 인증서 인지 검사 필요 인증서 받을 때마다 확인: 취소 인증서 캐쉬보관, CRL 구성 등 효과적 탐색 및 인증서 유효성 안전한 검증방안 필요 응용분야에 따라서 부인방지 서비스 희망 유효기한이 만료되었거나 취소된 인증서도 일정기간 보존

인증서 취소목록 형식 취소 인증서 발행자 이름 취소 인증서 목록의 생성 날짜 각 취소된 인증서 목록 발행자의 서명 해당 인증서의 일련 번호 해당 인증서의 취소 날짜 발행자의 서명

인증서와 CRL의 관계

X.509의 강한 인증절차 One-way 인증 Two-way 인증 Three-way 인증 AB: A{tA, rA, B, sgnData, EKUb[Kab]} Two-way 인증  BA: B{tB, rB, A, rA, sgnData, EKUa[Kba]} Three-way 인증 AB: A{rB,B}

PKI 기술 개요 공개키기반구조(PKI) 정의 공개키 기반구조의 구성 PKI는 인증, 암호화, 무결성 및 부인방지를 지원하기 위하여 공개키를 관리하는 Infrastructure를 말함(by ITU X.509) 공개키 암호에 기반하여 공개키인증서를 발급, 관리, 저장, 분배, 폐지에 필요한 H/W, S/W, 인적자원, 정책 및 절차의 총체 (by IETF PKIX) 공개키 기반구조의 구성 공개키 인증서를 발급, 폐지하는 인증기관 공개키와 인증서 소유자 사이의 관계를 확인하는 등록기관 인증서를 발급받고, 전자문서에 서명하고 암호화를 할 수 있는 공개키 인증서의 소유자 인증기관의 공개키를 사용하여 인증경로 및 전자서명을 검증하는 사용자 공개키 인증서와 CRL을 저장하는 저장소

... 한국전자서명인증관리 체계도 정부 한국정보인증(주) 외국정부 상호 인정 인증 ( RA) 최상위인증기관:한국정보보호진흥원 사용자 인증업무 및 인증관리체계 운영 공인인증기관 지정을 위한 심사 평가 검사 안전운영 지원 상호인정 지원 상호인증 보안통제 기술개발 외국 인증기관 외국정부 정부 상호 인정 인증 지역등록기관 ( RA) 최상위인증기관:한국정보보호진흥원 (Root CA) 인증서 교부 금융결제원 (CA) 한국증권전산(주) 한국전자인증㈜ 한국전산원

전자서명과 스마트카드 전자서명 정보처리를 위하여 안전하고, 휴대 간편한 저장매체 필요 스마트카드 스마트카드 특징 활용분야 중요 데이터의 보관 및 처리기능이 있는 일반 신용카드 크기의 보안장치 마이크로 프로세서 (MPU), 운영체제 (COS), 저장장치 등으로 구성 스마트카드 특징 저장된 정보 및 활용의 안전성 제공 물리적인 보안 안전성 제공 보관 및 휴대의 편리성 활용분야 공인 인증서 관련 정보 보관, 전자화폐, 신용카드 전화카드, 교통카드, 신분증으로서의 활용 전망

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