Chap 8. 인증과 키교환.

Presentation on theme: "Chap 8. 인증과 키교환."— Presentation transcript:

1 Chap 8. 인증과 키교환

2 목 차 1. KERBEROS 2. X.509 디렉토리 인증 서비스 3. Diffie-Hellman 키 교환
4. 디지털 서명 표준

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

4 Kerberos 티켓 발급 서버(Ticket Granting Server) - Trusted Third Party
TGS에서 발급받은 티켓을 이용해서 서버로부터 인증 대칭키 암호 방식 사용 두 가지 Version Version 4 : 가장 널리 사용 Version 5 : Version 4의 보안 결함을 수정 Internet Draft 표준 문제점 Replay attack이 가능 모든 클라이언트와 서버의 시간 동기화 문제 Kerberos 서버의 보안 문제

5 Ticket : EKV[IDC, ADC, IDV] (ADC : C의 네트워크 주소)
Kerberos 버전 4 간단한 인증 프로토콜 서비스에 접속하기 위해 인증 서버에 접속해서 인증받는 과정 (C : Client, AS : 인증 서버, V : 서비스 서버, P : 패스워드, ID : 식별자) 사 용 자 Login(ID, Password) C AS 2 IDC, PC, IDV 3 Ticket 4 IDC, Ticket V 서비스 Ticket : EKV[IDC, ADC, IDV] (ADC : C의 네트워크 주소)

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

7 간단한 인증 프로토콜의 문제점 티켓이 단 한번만 사용되기 때문에 모든 서비스를 사용하기 위해서는 반드시 패스워드 입력이 요구
 티켓의 재사용으로 해결 가능(티켓의 저장) 여러 서비스에 접속시마다 패스워드 입력이 요구  서비스마다 새로운 티켓이 요구됨 패스워드의 전송이 평문으로 전달됨  패스워드 가로채기 가능 이러한 문제점을 해결하기 위한 새로운 구조  Ticket-Granting Server(TGS)의 도입

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

9 단 한번의 패스워드 입력 및 사용자 패스워드 보호 가능한 시나리오
TGS를 이용한 인증 프로토콜의 설명 1. 클라이언트는 ID와 TGS ID를 인증 서버에 전송 2. 인증 서버는 티켓(티켓 승인 티켓) 생성후 클라이언트에 전송, 이때 클라이언트는 사용자의 패스워드 입력을 요구 * 티켓은 재사용 방지를 위해 유효기간(lifetime)을 포함 3. 클라이언트는 사용자 ID, 요구하는 서비스 ID, 티켓 승인 티켓을 TGS에 전송함으로써 서비스 승인 티켓 요구 4. TGS는 들어온 티켓을 복호하고 ID의 존재여부, 복호의 성공여부, 유효기간 확인, ID/네트워크 주소 점검 후 접속 승인 티켓 발급 5. 클라이언트는 서비스 접속 요구(ID / 서비스 승인 티켓), 서비스 서버는 이것을 인증한다. 단 한번의 패스워드 입력 및 사용자 패스워드 보호 가능한 시나리오

10 TGS를이용한 인증 프로토콜의 문제점 티켓 승인 티켓과 관련된 유효기간의 문제  유효기간이 매우 짧다면, 패스워드의 반복 입력이 요구  유효기간이 매우 길다면, 침입자의 재전송 공격 가능성 증가 (패킷을 가로채서 가지고 있다가, 사용자 로그 아웃 후 네트워크 주 소를 위조한 다음 단계 3의 메시지를 TGS에 재전송  공격 가능)  이를 방지하기 위해서는, 서비스 사용자가 티켓이 발급된 사용자 라는 것의 증명이 요구됨 서버의 인증  가짜 서버가 사용자가 입력한 정보를 가로채서 이용할 수 있음 (IP Spoofing)

11 Kerberos Version 4의 인증 프로토콜
C IDC, IDtgs, TS1 인증 서비스 교환 : 티켓 승인-티켓 획득 AS EKC(Kc, tgs,||IDtgs ||TS2|| Lifetime2||Tickettgs) 티켓 승인 티켓 TicketTGS=EKtgs[KC, tgs||IDC|| ADC|| IDtgs||TS2||Lifetime1] 티켓 승인 서비스 교환 : 서비스 승인 티켓 획득 IDV, Tickettgs ||AuthenticatorC TGS EKC, tgs[KC, V||IDV||TS4||TicketV] 클라이언트/서버 인증 교환 : 서비스 V TicketV ||AuthenticatorC EKc, v[TS5+1]

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

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

14 Kerberos Version 5의 인증 프로토콜
암호화 시스템에 대한 의존 : DES 사용(DES의 수출제한) Version 5는 다른 암호 알고리즘 사용 가능 인터넷 프로토콜에 대한 의존 : IP 주소 사용 Version 5는 다른 형식의 주소 사용 가능 메시지 바이트 순서 : 순서 표시 고정 Version 5 : ASN.1과 BER 인코딩 규칙 표준 사용 티켓 유효시간 : 최대 28*5 = 1280 분 동안만 사용 가능 Version 5 : 시작 시간과 끝시간 표시(충분한 유효시간) 인증의 발송이 불가능 Version 5에서는 가능 상호 인증 Version 5에서는 Kerberos 대 Kerberos의 상호 인증이 가능

15 Version 4의 기술적 결함 보완 이중 암호화 PCBC 암호화
타겟 서버의 비밀키 + 클라이언트 비밀키 두번째 암호는 필요 없음 : 버전 5에서는 제거 PCBC 암호화 버전 4에서는 DES의 비표준 모드인 PCBC 모드 사용 : 공격에 취약 버전 5에서는 표준 모드인 CBC 모드 사용 세션키 : 버전 4에서는 세션키의 연속적 사용 가능(재전송 공격) 버전 5에서는 단 1회만 사용되는 서브 세션키 협약 가능 패스워드 공격 : 패스워드를 추측하는 공격이 가능 버전 5에서는 패스워드 추측 공격이 더 어렵도록 만듦(사전 인증 기능) 패스워드 공격을 완전히 막을 수는 없음

16 2. X.509 디렉토리 인증 서비스 X.500 디렉토리 권고안의 일부 인증서의 형식 규정
인증서 : 사용자의 신원과 공개키를 결합한 일종의 증명서 안전한 전자 메일인 PEM 등에 사용(9장) 공개키 암호화 기법, 전자 서명 기술의 응용 1988년 발행, 1993년 개정 RSA를 주로 사용(권고안)

17 인증서 인증서는 신뢰된 CA(Certification Authority)에 의해 발행 인증서 형식

18 인증서 내용 버전(Version) : 인증서 형식 구분 일련번호(Serial Number) : CA 내에서 유일한 발행 번호
알고리즘 식별자 : 인증서 서명 알고리즘, 관련된 파라미터 발행자(Issuer) : 인증서를 발행하고 서명한 CA 유효기간 : 인증서가 유효한 범위(from, to) 주체 : 인증서가 가르키는 사람(소유자) 공개키 정보 : 주체의 공개키와 키가 사용될 알고리즘 식별자 서명 : 인증서의 모든 영역을 해쉬해서 CA의 개인키로 서명한 값

19 인증서의 특징 누구나 사용자의 인증서를 획득하고, 공개키를 획득할 수 있다.
인증 기관 이외의 누구도 인증서를 수정, 발급 할 수 없다. 인증서의 인증 구조 같은 인증 구조 내의 사용자들은 상호 인증서 신뢰 가능

20 인증서의 신뢰 구조 A B C D 사용자 1은 그림에서 인증기관 D에서 인증서 발급 사용자 2는 인증기관 C에게 인증서 발급
사용자 1이 사용자 2의 인증서를 확인하기 위한 과정 인증기관 C의 인증서 획득, 사용자 1의 인증서 서명 검증 인증기관 A의 인증서 획득, 인증기관 C의 인증서 서명 검증 A B C D 사용자1 사용자1

21 인증서 발급을 위한 인증기관 초기화면

22 인증서 신청과정(개인 정보 입력)

23 인증서 신청 과정(공개키, 개인키 생성)

24 패스워드 입력(인증서 보호)

25 CA에서 인증서 수신

26 수신된 인증서 내용

27 인증서의 이용( )

28 인증 절차 A (1) One Pass Authentication (1) Token AB B
Token AB = Text2 || EKab(TA, NA ||B||Text1) Ekab : 비밀키 Kab로 암호화, TA : 타임스템프, NA : 일련번호, B : B의식별자, Text1 : 임의의 text, R : 난수

29 A (2) Two Pass Authentication (1) Token AB (2) Token BA B
Token AB = Text2 || EKab(TA, NA||B||Text1) Token BA = Text4 || EKab(TB, NB||A||Text3)

30 Token AB = Text3 || EKab(RA||RB||B||Text2)
(3) Three Pass Authentication (1) RB||Text1 (2) Token AB (3) Token BA A B Token AB = Text3 || EKab(RA||RB||B||Text2) Token BA = Text5 || EKab(RB||RA||Text4)

31 참고. One-time Password 하나의 접근을 위한 유효한 Password를 예측할 수 없도록 동적으로 산출하는 것
목적 : 인증시에 사용되었던 서로 다른 Password를 구분하고 reply attack이 이루어지지 못하도록 하는 것 Token Card를 사용 (Smart Card)

32 Challenge-Response 방법 1) 사용자의 login 시도 2) 서버가 사용자에게 Challenge
3) 사용자는 생성기에 PIN(Personal Identification Number) 입력 4) 생성기는 One-time password를 생성 5) 서버에게 password 전송 (1) (2) (5) (4) (3)

33 DES Challenge-Response 방법
1) 사용자는 인증 서버에게 PIN 전달 2) 서버는 난수를 생성해서 Challenge로 반환 3) 사용자는 자신의 비밀키로 난수를 DES 알고리즘으로 암호화 4) 암호화된 난수로 Response 전달 5) 서버는 사용자의 PIN으로 키를 검색, 난수를 DES로 암호화한 후 비교 (1) PIN (2) “123456” (4) R (3) R=EKEY(123456) (5) R=?=EKEY(123456)

34 One time 패스워드를 위한 인증 제품 PIN 번호를 입력하면 난수를 생성(One-time password)
다양한 제품이 존재함

35 3. Diffie-Hellman 키교환 공개키 암호의 시초 두 사용자가 안전하게 키를 교환하는 방식 이산대수 알고리즘에 근거
y=gx 형태에서 y를 알더라도 x를 계산하기는 불가능 사용자 A와 B의 키교환 A : 공개키 Ya=gXa , 비밀키 Xa B : 공개키 Yb=gXb , 비밀키 Xb A는 B의 공개키 Yb 획득, 자신의 비밀키를 승산 (Yb)Xa = (gXb)Xa = g XbXa B는 A의 공개키 Ya 획득, 자신의 비밀키를 승산 (Ya)Xb = (gXa)Xb = g XaXb 비밀 정보의 누출 없이 A, B 간의 공통키 g XaXb 설정

36 4. 미국 디지털 서명 표준 : DSS 1991년 미국 NIST에서 표준안으로 개발
SHA를 사용하는 DSA(Digital Signature Algorithm) 공개키 기술을 사용 RSA와는 달리 암호화/키 교환에는 이용되지 않음 서명만을 위한 알고리즘 이산 대수의 어려움에 기반을 둔 알고리즘 ElGamal과 Schnorr에 의해 제안된 알고리즘에 기반을 둠

37 RSA와 DSS의 접근법 비교 H | | M M KRa 비교 KUa H E EKRa[H(M)] D H | | M M s H
DSA H | | M M KUG KRa KUG KUa s H Sig r 비교 Ver k

38 DSS 알고리즘 요약 서명 준비 과정 모든 사용자 집단에 공통적으로 사용되는 세개의 매개 변수 비밀키 선택, 공개키 생성
160비트 길이의 소수 q 선택 512~1024 사이의 소수 p 선택 g = h (p-1)/q mod p ( 1<h<(p-1) ) 비밀키 선택, 공개키 생성 랜덤한 비밀키 x 선택 (0<x<q) 공개키 y 계산 y=gx mod p

39 서명 과정 p q g f2 r k M H f1 s 메시지별 비밀번호 k를 랜덤하게 생성(0<k<q) 서명
r=(gk mod p) mod q s=[k-1(H(M)+xr)] mod q Signature = (r, s) p q g f2 r k x q M H f1 s

40 확인 과정 확인 w=s-1 mod q u1=[(H(M)w)] mod q u2= rw mod q
v=[(gu1 yu2) mod p] mod q TEST : v = r y q g H M f4 q s f3 r 비교