NETWORK SECURITY

NETWORK SECURITY

네트워크 보안 에센셜

ESSENTIALS

4

EDITION

4.1 대칭 암호를 이용한 대칭키 분배 4.2 Kerberos

4.3 비대칭 암호를 이용한 키 분배 4.4 X.509 인증서

4.5 공개키 기반구조 4.6 통합신원관리

제4장 네트워크보안응용

4.1 대칭 암호를 이용한 대칭키 분배

1. A가 키를 선택한 뒤 B에게 직접 전달

2. 제3자가 키를 선택한 뒤에 A와 B에게 직 접 전달

3. A와 B의 공유키로 한 사람이 새 키를 만 들고 공유키로 암호화하여 상대방에게 전 송한다.

4. A와 B가 제3자인 C와 암호화된 연결이 확립되어 있다면, C가 암호화된 링크를 통해서 A와 B에게 키를 전달한다.

3

4 번째 방법에서 키 사용

• 세션키(Session key):

– 세션이라고 하는 논리적 연결이 유지되는 동안 모 든 사용자 데이터는 일회용 세션키로 암호화

– 한 세션에만 사용

• 영구 키(Permanent key):

– 영구 키는 세션키 분배에 필요한 키 – 복수 회 사용

– 키 분배 센터(KDC: key distribution center)에서 활용

4

KDC 키 분배 절차

1. A가 B와 통신을 원하면 연결 요청 패킷을 KDC에 전송한다

– A와 KDC 사이의 통신은 A와 KDC가 공유하고 있는 마스터키로 암호화

2. KDC가 연결요청 후 KDC는 일회용 세션키 생성

– 세션키를 A와 공유하고 있는 영구키로 암호화한 다 음 A에게 전송

– 동일한 방법으로 KDC는 이 세션키를 B와 공유하고 있는 영구키로 암호화한 뒤 B에게 전송

3. A와 B는 논리적 연결가능.

– 세션키를 이용하여 데이터를 암호화하여 전송

5

4.2 Kerberos

• MIT에서 개발

• 키 분배

• 사용자 인증 서비스

6

네트워크에 대한 위협

• 위협

– 사용자로 위장

– 네트워크 주소 변경 – 재전송 공격

• 방어수단

– Kerberos

• 대칭암호로만 구성

• Version 4

• Version 5

7

Kerberos 버전 4

• 내부 암호로 DES를 사용

• Athena 프로젝트의 Bill Bryant가 사용한 방법으로 구조 설명

– 가상적 절차 제시 – 문제점 파악

– 문제점 보완

– 새 가상적 절차 제안

8

단순 인증 절차

• 인증서버(AS:authentication server) 이용

– AS는 각 서버와 유일한 비밀키를 공유 – 비밀키는 안전한 방법으로 분배

• 직접전달

9

첫 번째 가상절차











V C

ID ID V

AS

C









||

V C C

K AD P

클라이언트 인증 서버

서버 사용자 C 의 식별자 서버 V의 식별자 C 의 패스워드

C 의 네트워크 주소

AS 와 V 가 공유하는 비밀 암호키 이어 붙여 쓰기

]

||

||

[ E

||

: V C

(3)

: C AS

) 2 (

||

||

: AS C

) 1 (

V C

C K

C

V C

C

ID AD

ID Ticket

Ticket ID

Ticket

ID P

ID









10

ID _V 와 ID _C 사용 목적

 변경이나 위조를 막기 위해 티켓 암호화

 서버 ID(

ID

 티켓이 C 에게 발행되었다는 것을 명시하 기 위해 티켓 속에

ID

11

AD _C 사용 목적

• 티켓을 요청한 워크스테이션에서만 티켓 을 사용할 수 있게 함

12

보다 안전한 인증 절차

• 인증문제 해결

• 아직 해결되지 않은 문제

– 입력패스워드 수 과다

• 서버 접속 마다 매번 패스워드 입력

• 해결방법: 티켓 재사용

• 문제는 다른 서버 접속 시 패스워드 입력

– 패스워드를 평문으로 전송

• 도청 가능

• 해결방법: 티켓발행서버(TGS: Ticket-Granting Server) 도입

13

가능한 공격 시나리오

 티켓을 가로챈 뒤 해당 사용자가 워크스테 이션에서 로그오프 할 때까지 대기

 공격자는 자신의 워크스테이션 주소를 조 작해서 공격대상컴퓨터와 동일 주소 갖도 록 조작

 티켓을 재사용하여 TGS 를 속인다

14

대비책

• 티켓 안에 타임스탬프 포함

– 티켓 발행 시점 표기 – 티켓 유효기간 표기

15

개선된 가상적 절차

• 사용자 로그온 세션마다 한 번:

• 서비스 유형마다 한 번:

] [

E :

C AS

) 2 (

||

:

AS C

) 1 (

tgs K

tgs C

Ticket ID ID





V

tgs V

C

Ticket

Ticket ID

ID

C TGS

) 4 (

||

||

:

TGS C

) 3 (





16

개선된 가상적 절차

• 서비스 세션마다 한 번:

]

||

||

||

||

[ E

]

||

||

||

||

[ E

||

:

V C

) 5 (

2 2

1 1

Lifetime TS

ID AD

ID Ticket

Lifetime TS

ID AD

ID Ticket

Ticket ID

V C

C K

V

tgs C

C K

tgs

V C

V tg s







17

버전 4 인증절차

• 첫 번째 시나리오 보다 안전해짐

• 또 다른 두 가지 문제점 발생

18

개선된 가상절차의 문제점

• 티켓-승인 티켓의 유효기간 없음

– 티켓-승인 티켓 유효기간 문제 – 서비스-승인 티켓 유효기간 문제

• 서버를 사용자에게 인증하는 절차 없음

19

티켓-승인 티켓의 유효기간 부재

• 재전송 공격 가능

• 서비스-승인 티켓의 유효기간도 동일한 위 험

• 티켓 제시자와 티켓 발행 받은 자의 동일 성 확인 필요

• 해결방법: AS와 TGS가 공유하는 비밀값(세 션키) 활용

– 분배방법이 필요

20

서버를 사용자에게 인증하는 절차 부재

• 문제점

– 특정 서버로 전달되는 메시지를 다른 곳으로 송신

– 위장서버 가능

– 사용자로부터의 정보 갈취

– 사용자에게 제공되는 서비스 방해

21

더욱 개선된 방법(Kerberos Ver4)

(a) 인증서비스 교환: 티켓-발행 티켓 취득

22

더욱 개선된 방법(Kerberos Ver4)

(b) 티켓-발행 서비스 교환: 서비스-발행 티 켓 취득

23

더욱 개선된 방법(Kerberos Ver4)

(c) 클라이언트/서버 인증 교환: 서비스 취득

24

Kerberos 버전 4 프로토콜 기본

25

Kerberos 버전 4 프로토콜 기본

26

Kerberos 버전 4 프로토콜 기본

27

Kerberos 버전 4 프로토콜 기본

28

Kerberos 버전 4 프로토콜 기본

29

Kerberos 동작 개요

30

Kerberos 공동체와 다중 Kerberi

• 완전한 Kerberos 환경 조건

– Kerberos 서버는 반드시 ID(UID) 와 모든 사용 자의 해시된 패스워드를 데이터베이스에 저장 – 모든 사용자는 Kerberos 서버에 등록

– Kerberos 서버는 필히 각 서버들과 비밀키를 공유

– 모든 서버는 Kerberos 서버에 등록

• Kerberos 공동체(realm)

– 여러 개의 공동체간 서비스 가능

31

Kerberos 공동체와 다중 Kerberi

• 완전한 Kerberos 환경 추가조건

– 상호 교류하는 각 공동체에 속한 Kerberos 서 버들은 다른 공동체 서버들과 비밀키를 공유 – 두 개의 Kerberos 서버는 상호간에 등록

32

다른 공동 체 서비스

요청

33

Kerberos 교환절차

1 C→AS: 𝐼𝐷_𝐶 ∥ 𝐼𝐷_𝑡𝑔𝑠 ∥ 𝑇𝑆₁

2 AS→C: 𝐸[𝐾_𝐶, [𝐾_{𝑐,𝑡𝑔𝑠} ∥ 𝐼𝐷_𝑡𝑔𝑠 ∥ 𝑇𝑆₂ ∥ 𝐿𝑖𝑓𝑒𝑡𝑖𝑚𝑒₂ ∥ 𝑇𝑖𝑐𝑘𝑒𝑡_𝑡𝑔𝑠]]

3 C→TGS: 𝐼𝐷_{𝑡𝑔𝑠𝑟𝑒𝑚} ∥ 𝑇𝑖𝑐𝑘𝑒𝑡_𝑡𝑔𝑠 ∥ 𝐴𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑜𝑟_𝑐

4 TGS→C: 𝐸 𝐾_{𝑐,𝑡𝑔𝑠}, 𝐾_{𝑐,𝑡𝑔𝑠𝑟𝑒𝑚} ∥ 𝐼𝐷_{𝑡𝑔𝑠𝑟𝑒𝑚} ∥ 𝑇𝑆₄ ∥ 𝑇𝑖𝑐𝑘𝑒𝑡_{𝑡𝑔𝑠𝑟𝑒𝑚} 5 C→TGSrem: 𝐼𝐷^{𝑉𝑟𝑒𝑚} ∥ 𝑇𝑖𝑐𝑘𝑒𝑡_{𝑡𝑔𝑠𝑟𝑒𝑚} ∥ 𝐴𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑜𝑟_𝑐

6 TGSrem→C: 𝐸 𝐾^{𝑐,𝑡𝑔𝑠𝑟𝑒𝑚}, 𝐾_{𝑐,𝑉𝑟𝑒𝑚} ∥ 𝐼𝐷_{𝑉𝑟𝑒𝑚} ∥ 𝑇𝑆₆ ∥ 𝑇𝑖𝑐𝑘𝑒𝑡_{𝑉𝑟𝑒𝑚} (7)C→Vrem: 𝑇𝑖𝑐𝑘𝑒𝑡_{𝑉𝑟𝑒𝑚} ∥ 𝐴𝑢𝑡ℎ𝑒𝑛𝑡𝑖𝑐𝑎𝑡𝑜𝑟_𝑐

34

Kerberos 버전 5

• 버전 5: RFC 1510

35

버전 4와 버전 5의 차이점

• 환경적 결함(environmental shortcomings)

• 기술적 결함(technical deficiencies)

36

환경적 결함

• 암호화 시스템 의존성(Encryption system dependence):

• 인터넷 프로토콜 의존성(Internet protocol dependence):

• 메시지 바이트 순서(Message byte ordering):

• 티켓 유효기간(Ticket lifetime):

• 인증 전달(Authentication forwarding):

• 공동체간 인증(Interrealm authentication):

37

기술적 결함

• 이중 암호화(Double encryption):

• PCBC 암호화(PCBC encryption):

• 메시지 바이트 순서(Message byte ordering):

• 세션키(Session keys):재전송 공격 위험

• 패스워드 공격(Password attacks):

38

버전 5 인증 절차

• 인증 서비스 교환: 티켓-발행 티켓 취득

• 티켓-발행 서비스 교환: 서비스-발행 티켓 취득

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

39

인증 서비스 교환

• 티켓-발행 티켓 취득

40

인증 서비스 교환

• 공동체(Realm):

– 사용자의 공동체

• 선택사항(Options):

– 돌아오는 티켓 안의 특정 플래그의 설정을 요청할 때 사용

• 시간(Times):

– 클라이언트가 티켓 속 시간설정 요청 시 사용

• from: 요청된 티켓 사용 개시시간

• till: 요청된 티켓의 사용 만료시간

• rtime: 요구되는 재시작부터 만료시간까지의 시간

• 비표(Nonce):

– 메시지 (2)에서 반복 사용되는 랜덤넘버 – 응답이 재전송된 것이 아님을 확신

41

티켓-발행 서비스 교환

• 서비스-발행 티켓 취득

42

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

• 서비스 취득

43

버전 5 인증 절차

•

44

4.3 비대칭 암호를 이용한 키 분배

• 공개키 암호의 용도

– 공개키 분배

– 대칭 비밀키 분배

45

공개키 인증서

• 안전한 공개키 전달

– 공개키 인증서(public-key certificate)

• 공개키와 키 소유자의 사용자 ID로 구성

• 이를 신뢰할 만한 제 3자가 서명

• 제3자라 하면 정부기관이나 금융기관 같은 사용자 모두가 신뢰하는 인증기관(CA: certificate

authority)

46

공개키 인증서 사용

47

공개키를 이용한 비밀키 분배

• Diffie-Hellman 키교환을 이용

– 사실 이 방법은 널리 이용

– 두 통신자 사이에 인증을 제공하지 못함

• 강력한 대안

– 공개키 인증서 활용

48

방법

1. 메시지를 준비한다.

2. 일회용 세션키를 이용하는 관용암호 기법 으로 메시지를 암호화한다.

3. 앨리스의 공개키를 이용해서 그 세션키를 암호화한다.

4. 암호화된 세션키를 메시지에 첨부해서 앨 리스에게 보낸다.

49

4.4 X.509 인증서

• ITU-T 권고안 X.509는 디렉터리 서비스를 정의하는 권고안 X.500 시리즈의 한 부분

• 디렉터리

– 사용자 정보 데이터베이스를 관리하는 하나의 서버 또는 분산 서버 집단

• X.509는 인증 서비스의 구조를 규정

• 공개키 인증서의 저장소로 이용

50

X.509 인증서 형식 사용처

• 사용처

– S/MIME(5장) – IP Security(6장) – SSL/TLS, SET(7장)

• 소개

– 1988년 최초 소개 – 1993년 수정권고 – 1995년 버전3

– 2000년 수정안

51

X.509 형식

52

인증서

인증서를 정의: 표현을 이용한다:

CA<<A>>= CA {V, SN, AI, CA, UCA, A, UA, Ap, T^A} 여기서

Y<<X>> = 인증기관 Y 가 발행한 사용자 X 의 인증서

Y{I} = I 에 대한 Y 의 서명. I 에 암호화된 해시 코드를 붙여 작성 V = 인증서 버전

SN = 일련번호

AI = 서명에 사용된 알고리즘 식별자 CA =인증기관명

UCA = CA 식별자(옵션) A = 사용자 A의 이름(옵션) UA = 사용자 A 식별자(옵션) Ap = 사용자 A의 공개키 T^A= 유효기간

53

사용자 인증서 얻기

• CA가 발행한 사용자 인증서 특성

– CA의 공개키를 얻을 수 있는 어떤 사용자도 특정 사용자의 인증된 공개키를 확인할 수 있 다.

– 인증기관을 제외한 어느 누구도 들키지 않게 인증서를 변경할 수 없다.

54

디지털 서명 프로세스

M에 대한 밥의 서명 앨리스가 밥의서명 검증

55

인증서 체인(chain of certificate)

• A가 X.509 형식에 따라 B의 공개키 구하기 X₁<<X₂>>X₂<<B>>

• N개의 요소로 구성된 체인

X₁<<X₂>>X₂ <<X₃>>∙∙∙X_N <<B>>

• 체인 (X_i, X_i+1) 안 쌍방은 상호 인증서 발행

56

X.509 계층구조

57

CA의 디렉터리 내 두 종류 인증서

• 순방향 인증서(Forward certificates):

– 다른 CA에 의해서 생성된 X의 인증서

• 역방향 인증서(Reverse certificates):

– X가 생성한 다른 CA의 인증서

58

A가 B의 인증서를 얻는 체인

X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>>

59

B가 A의 인증서를 얻는 체인

Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>

60

인증서 취소

• 취소해야 하는 경우

1. 사용자 개인키가 노출, 훼손시

2. CA가 사용자를 더 이상 인증해줄 수 없을 때 3. CA의 인증서가 노출, 훼손시

61

취소 인증서 목록

(CRL: Certificate Revocation List)

 각 CA 는 취소했지만 유효기간이 아직 끝 나지 않은 인증서 목록을 보관

 취소된 인증서들은 사용자에게 발행한 것 과 다른 CA 들에게 발행한 것 모두를 포함

 취소목록을 디렉토리에 공개

62

취소인증서목록 사항

•

•

•

•

63

X.509 버전 3

버전 2의 약점

1. 신원정보 결여

• 주체 필드가 키 소유자 신원을 전달하기에 부적 합

• 자세한 신원정보가 결여

2. 주체 필드의 수용능력 부족

• 개체를 이메일 주소, URL 혹은 다른 형태의 인터 넷 관련 신원을 통해 인식하기에 부적합

3. 보안 정책 정보 표시가 필요

• IPSec 같은 보안 응용프로그램이나 보안 기능이 X.509 인증서를 주어진 정책에 이용가능

64

X.509 버전 3

버전 2의 약점

4. CA에 대한 견제기능 필요

• 특정 인증서 사용에 제약조건을 설치하여 악의가 있는 CA에 의해 유발되는 피해를 줄인다

5. 시간별 사용하는 키 구별이 필요

• 키 소유자가 다른 시간에 사용하는 다른 키를 구 별하는 능력필요

• 이 기능은 키의 수명 관리를 지원

• 특히 사용자와 CA의 키 쌍을 정기적, 예외적인 환 경하에서 갱신가능

65

인증서 확장

• 키와 정책정보

• 인증서 주체와 발행자 속성

• 인증경로 제약조건

66

키와 정책정보

• 주체와 발행자 키에 관한 추가적인 정보, 인증서 정책 표시자를 처리

• 인증서를 특정 집단이나 일상적인 보안 사 항을 요구하는 응용 프로그램 집단에 적용 할 수 있는지 없는지를 판단

67

포함된 내용

• 기관 키 식별자(Authority key identifier):

• 주체 키 식별자(Subject key identifier):

• 키 용도(Key usage):

• 개인키 유효기간(Private-key usage period):

• 인증서 정책(Certificate policies):

• 정책 매핑(Policy mapping):

68

인증서 주체와 발행자 속성

• 주체 대체 이름(Subject alternative name):

• 발행자 대체 이름(Issuer alternative name):

• 주체 디렉터리 속성(Subject directory attributes):

69

인증경로 제약조건

• 기본 제약(Basic constraints):

• 이름 제약(Name constraints):

• 정책 제약(Policy constraints):

70

4.5 공개키 기반구조

 공개키 기반구조(PKI: Public-Key Infrastructure)

– RFC 2822(Internet Security Glossary)에서 정의

– 비대칭 암호시스템에 기초해서 디지털 인증서를 생성하고, 관리하고, 저장하고, 배분하며 취소하는 데 필요한 하드웨 어, 소프트웨어, 사람, 정책 및 절차

 PKI 개발 목적

– 안전하고, 편리하고, 효율적인 공개키 획득

 IETF(Internet Engineering Task Force) 공개키 기반구 조 X.509(PKIX) 작업그룹

– X.509에 기초해서 형식적(종합적)인 모델 구성

 X.509

– 인터넷 상에서 인증서기반 아키텍처를 활용에 적합

71

PKIX 구조적 모델

72

PKIX 구조적 모델

• 종단 개체(End entity):

• 인증기관(CA: Certificate authority):

• 등록기관(RA: Registration authority):

• CRL 발행자(CRL issuer):

• 저장소(Repository):

73

PKIX 관리 기능

• 등록(Registration):

• 초기화(Initialization):

• 인증(Certification):

• 키 쌍 복구(Key pair recovery):

• 키 쌍 갱신(Key pair update):

• 취소 요청(Revocation request):

• 교차인증(Cross certification):

74

PKIX 관리 프로토콜

• 인증서 관리 프로토콜(CMP: Certificate management protocol)

• 암호 메시지 구문(CMS: Cryptographic message syntax)

75

4.6 통합신원관리

• 통합신원관리(Federated identity management)

– 상대적으로 새로운 개념

– 다수의 기업과 많은 응용 프로그램을 관리하 는 일반적 신원관리시스템

– 수천 또는 수백만 명의 사용자를 지원하는 관 리시스템

76

신원관리

• 신원관리(identity management)

– 접근 권한을 가진 개인이 자원에 접근하는 절 차를 중앙 집중화, 자동화 방법

– 각 사용자 신원정, 속성과 신원 연관, 사용자 가 신원인증 방법을 강요

• 싱글사인온(SSO: single sign-on)

– 신원관리 시스템의 중심적 개념

– 사용자가 한 번만 인증하면 네트워크 모든 자 원에 접속가능

77

신원관리 원칙

• 인증(Authentication):

• 허가(Authorization):

• 계정(Accounting):

• 제공(Provisioning):

• 작업절차 자동화(Workflow automation):

• 관리위임(Delegated administration):

• 패스워드 동기화(Password synchronization):

• 셀프-서비스 패스워드 리셋(Self-service password reset):

• 통합(Federation):

78

일반 신원관리 구조

79

신원 통합

• 신원 통합(identity federation)

– 다중 보안 도메인으로 확장된 신원관리

• 자치적 내부 비즈니스 단위

• 외부 비즈니스 파트너

• 기타 제3자 응용 및 서비스

– 목적

• 디지털 신원 공유를 통해 싱글 사인온을 제공

• 중앙집중화 된 통제가 불가능

• 안전한 디지털 신원 공유를 위해 표준화나 상호 신 뢰수준에 동의해서 통합

80

통합 신원 동작

81

표준

• 조직에서는 협업 파트너가 처리할 수 있는 일종의 보안 티켓을 사용자에게 발행

• 신원 통합 표준

– 티켓 내용과 형식을 정의하고, 티켓 교환용 프 로토콜을 제공하고, 다양한 관리업무를 수행 하는 것

• 속성 전달 수행에 필요한 시스템 구성

• 신원 매핑

• 로그인 수행

• 감사

82

SAML

(Security Assertion Markup language)

• OASIS(Organization for the Advancement of Structured Information Standards)가

통합신원관리용으로 발행한 광범위한 표 준 집합의 일부

• 통합신원관리 구현 문제

– 안전하고 사용자에게 편리한 유틸리티를 제공 하기 위해 다수의 기술, 표준, 서비스를 집약 의 어려움

83

사례

• 3가지 시나리오

– 시나리오 1(그림 4.10(a))

• Health.com과 맺은 Workplace.com 계약에 의해 직원은 건강 혜택을 제공받는다

– 시나리오 2(브라우저-기반)(그림 4.10(b))

• PartsSupplier.com은 Workplace.com에 정기적으로 부품을 제공

– 시나리오 3(문서-기반)(그림 4.10(c))

• Workplace.com은 PinSupplies.com과 구매동의를 한 상태이고, PinSupplies.com은 E-Ship.com 사와 비즈니스 관계

84

시나리오 1

85

시나리오 2

86

시나리오 3

87