II부 접근제어.

Presentation on theme: "II부 접근제어."— Presentation transcript:

1 II부 접근제어

2 접근제어 접근제어에 대한 2가지 개념 인증: 그 곳에 있는 사람은 누구인가? 접근이 허용되었는가를 결정 기계에게 인간을 인증 기계에게 기계를 인증 인가: 당신이 그것을 하는 것이 허용되었는가? 접근이 허용된 후, 당신은 무엇을 할 수 있을까? 사용자 행위에 대하여 강제로 제약을 줌. 주의: 가끔은 접근제어가 인가와 동의어로 사용됨.

3 인증프로토콜

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

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

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

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

8 사용자 A 컴퓨터 KA R = EKA(r) 난수 r r = DKA(R) 확인 사용자 인증 (계속)
관용 암호 방식을 이용한 인증 방식 사용자 A 컴퓨터 KA R = EKA(r) 난수 r r = DKA(R) 확인 R r

9 사용자 인증 (계속)

10 사용자 인증 (계속) 공개키 암호 방식을 이용한 인증 방식 사용자 A 공개 정보 PKA 컴퓨터 PKA , SKA (개인키) R = ESKA(r) 난수 r r = DPKA(R) 확인 r R

11 사용자 인증 (계속) (개인키)

12 사용자 인증 (계속) 사용자인증 구성도 w E R 사용자 A 공개 정보 P 검증자 B 난수 r 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

13 이산대수 문제 이용; 키 인증 센터(KAC) 필요 공개 개인식별 정보 인증서 발급
사용자 인증 (계속) T. Okamoto 방식 이산대수 문제 이용; 키 인증 센터(KAC) 필요 공개 개인식별 정보 인증서 발급 사용자 A 공개 정보 p, q, g1, g2, PKKAC KAC XA1, XA2R Zq yA  g1XA1 g2XA2 mod p S = S SKKAC(ID(A), yA) C(A) = (ID(A), yA, S) C(A) ID(A), yA

14 사용자 인증 (계속) T. Okamoto 인증의 구성 C(A), w E R1, R2 사용자 A 공개 정보
p, q, g1, g2, yA 검증자 B q | p –1 r1, r2  R Zq w  g1r1 g2r2 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 g2R2 yA –E mod p C(A), w E R1, R2

15 사용자 인증 (계속) T. Okamoto의 인증의 검증 g1R1 g2R2 yA –E mod p R1  r1 + XA1 E mod q R2  r2 + XA2 E mod q  g1r1 g1XA1E g2r2 g2XA2E g1 – XA1E g2 – XA2E mod p  g1r1 g2r2 mod p w  g1r1 g2r2 mod p  w mod p

16 사용자 인증 (계속) T. Okamoto의 인증방식 예 E=9 R1=2, R2=2 C(A), w=16 사용자 A 공개 정보
P=23, q=11, g1=3, g2=8, yA=4 검증자 B r1=5, r2=10  R Zq w  g1r1 g2r2 mod p  35 * mod 23  16 R1  r1 + XA1 E mod q  5 + 7*9 mod 11  2 mod 11 R2  r2 + XA2 E mod q  *9 mod 11 C(A) 확인 E =9 R{0, 1, 2, , 2t–1} g1R1 g2R2 yA –E mod p 32 * 82 * mod 23 9*18*16 mod 23 16  w C(A), w=16 E=9 R1=2, R2=2

17 사용자 인증 (계속) 상호 인증 방식 wB wA RB RA 사용자 A 공개 정보 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 RB  KB + XBE mod q wA  gRA yA–E mod p wB wA RB RA

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

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

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

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

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

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

24 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 서비스 세션당 한번

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

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

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

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

29 Kerberos V4의 인증 프로토콜 AS C TGS V 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] 클라이언트/서버 인증 교환 : 서비스 TicketV ||AuthenticatorC V EKc, v[TS5+1] Ticketv=EKtgs[KC,V||IDC|| ADC|| IDV||TS4||Lifetime4] Authenticatorc=EKc,v[|IDC|| ADC|| TS5]

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

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

32 Kerberos V4의 인증 프로토콜 서로 다른 영역에서의 서비스

33 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

34 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의 상호 인증이 가능

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

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

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

38 Kerberos V5의 인증 프로토콜 Flag 의 미 INITIAL PRE-AUTHENT HW-AUTHENT RENEWABLE
MAY-POSTDATE POSTDATED INVALID PROXIABLE PROXY FORWARDABLE FORWADED AS 프로토콜을 이용하여 발행 C는 티켓이 발행되기 전에 KDC에 의해 인증 하드웨어의 이용이 필요한 초기 인증요구 교체 티켓을 얻기 위해 재사용될 수 있음 표시 날짜가 지난 티켓이 발행된 것임을 알림 날짜가 지났음을 가리킴 사용전에 KDC에 의해 유효성 검증 필요 이 티켓이 대리인임을 가리킴 다른 네트워크 주소를 이용하여 발행 가능 인증을 기반으로 발행된 것임을 가리킴

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

40 X.509 인증서

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

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

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

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

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

46 사용자 인증 인증 절차 그림14.5 : 3가지 인증 절차

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

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

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