30 장 메시지 보안 , 사용자 인증과 키 관리

1HANNAM UNIVERSITYHttp://netwk.hannam.ac.kr

30.1 메시지 보안

30.2 전자서명

30.3 사용자 인증

30.4 키 관리

30.5 KERBEROS

30.6 요약

3030 장 메시지 보안장 메시지 보안 , , 사용자 인증과 키 관리사용자 인증과 키 관리


30.1 30.1 메시지 보안메시지 보안

메시지 보안의 범위 기밀성 (privacy) 인증 (authentication) 무결성 (integrity) 부인방지 (nonrepudiation)


메시지 보안메시지 보안 (( 계속계속 ))

기밀성 (privacy) 송신자와 수신자가 원하는 기밀성 전송된 메시지를 수신자 이외의 사람이 알아낼 수 없도록 하는 보안

방법 암호화를 이용

정당하지 않은 공격자가 내용을 알 수 없도록 전달 좋은 기밀성 기술은 잠재적인 공격자가 메시지의 내용을 알 수

없다는 것을 보장하는 것



대칭키 암호화를 이용한 기밀성 대칭키 암호화와 복호화를 이용 기밀성을 얻기 위한 일반적인 방법 송신자와 수신자가 키를 공유



공개키 암호화를 이용한 기밀성 공개키 암호화를 이용 암호화 키

공개키 : 공개적으로 알림 개인키 : 수신자만 소유

키 소유자에 대한 확인 ( 인증 ) 문제가 중요하게 대두



메시지 인증 수신자가 송신자의 신원을 확인하고 침입자가 메시지를 보내지

않았다는 것을 확인하는 보안 방법 전자서명을 이용

무결성 송신 데이터가 정확히 수신자에게 도착해야 한다는 것을 의미하는

보안 방법 전자서명을 이용



부인방지 수신된 메시지가 특정 송신자로부터 수신된 메시지임을 증명할 수

있는 보안 방법 부인방지에 대한 증명은 메시지 수신자의 임무 전자서명을 이용


30.2 30.2 전자서명전자서명

전자서명 인증 , 무결성 , 부인방지 보안 방법을 제공 문서에 서명하는 것과 같은 개념 서명 방법

문서 전체에 서명 문서의 다이제스트에 서명


전자서명전자서명 (( 계속계속 ))

전체 문서에 서명하기 공개키 암호화를 이용하여 문서에 서명 키 역할

개인키 : 메시지 암호화 ( 서명 ) 공개키 : 메시지 복호화 ( 서명 검증 )

제공 서비스 무결성 : 메시지의 부분 또는 전체를 바꿀 경우 복호화된 메시지를

읽을 수 없음 인증 : 제 3 자의 개인키로 암호화된 메시지를 공개키로 복호화할

경우 메시지를 읽을 수 없음 부인방지 : 송신자의 개인키와 공개키를 가지고 암호화와

복호화하여 저장된 메시지를 생성



전체 문서에 서명하기

전자서명은 기밀성을 제공하지 않는다 . 만약 기밀성이 필요하다면 암호화 / 복호화를 다른 계층에

적용해야 한다 .



다이제스트에 서명하기 공개키 암호화의 문제점은 긴 메시지에 서명하는 것이 비효율적임 문서의 다이제스트에 서명

해시 함수를 사용하여 메시지에 대한 다이제스트 생성 해시 함수로는 MD5(Message Digest 5) 와 SHA-1(Secure

Hash Algorithm) 이 일반적으로 사용 MD5 : 120 비트의 고정길이 다이제스트 생성 SHA-1 : 160 비트의 고정길이 다이제스트 생성



해시 함수의 특성 일방향 : 메시지에서 다이제스트를 생성할 수 있지만 ,

다이제스트에서 메시지를 생성하는 것은 성립하지 않음 일 - 대 - 일 : 두 메시지는 같은 다이제스트를 생성할 확률이 거의

없음



송 / 수신측 동작 송신측

생성한 다이제스트를 송신자의 개인키로 암호화 ( 서명 ) 암호화된 다이제스트를 원래의 메시지에 첨부하여 수신자에게 전송



수신측 메시지를 수신하고 다이제스트를 복호화 원래 메시지의 다이제스트를 생성하기 위해서 동일한 해시 함수를 적용 송신자의 공개키를 이용하여 수신한 다이제스트를 복호화 한 후 두

다이제스트를 비교



메시지의 안정성 입증1. 다이제스트가 변경되지 않았고 ( 무결성 ), 다이제스트는 메시지의 표현이다 . 그래서

메시지는 변경되지 않은 것이다 ( 두 개의 메시지가 같은 다이제스트를 생성하는 것은 거의 없다는 것을 기억하라 ). 무결성도 제공된다 .

2. 다이제스트는 실제 송신자에게서 온 것이다 . 그래서 메시지 또한 실제 송신자에게서 온 것이다 . 만약 공격자가 메시지를 만들었다면 메시지는 같은 다이제스트가 생성되지 않을 것이다 ( 두 개의 메시지가 같은 다이제스트를 생성하는 것은 거의 없다 ).

3. 송신자는 메시지를 부인할 수 없기 때문에 다이제스트를 부인할 수 없다 . 다이제스트를 생성할 수 있는 유일한 메시지일 확률이 매우 높은 메시지가 수신되었다 .


30.3 30.3 사용자 인증사용자 인증

대칭키 암호화를 이용한 사용자 인증 첫 번째 방법

앨리스가 대칭키 KAB 를 사용하여 암호화된 메시지에 자신의 신원과 비밀번호를 전송

대칭키에 자물쇠를 추가


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

문제점 제 3 자가 앨리스의 메시지를 가로채어 나중에 밥에게 전송할 경우 밥은

수신된 메시지가 이전 메시지인지 새로운 메시지인지 구별할 수 없음 재전송 공격 (replay attack) 이 발생

두 번째 방법 재전송 공격을 방지하기 위해서 비표 (nonce) 를 추가 비표는 오직 한번만 사용되는 임의의 수로 일회용 수 인증의 단계

앨리스가 평문으로 자신의 신원을 밥에게 전송 밥은 평문으로 비표 RB 를 전송 앨리스는 비표를 다시 보내고 , 대칭키를 이용하여 복호화하여 메시지에

응답



비표 사용 ( 메시지의 재전송을 방지 )



양 방향 인증 양 방향 인증 절차 및 위험성

앨리스가 자신의 신분과 비표를 밥에게 전송 밥이 자신의 비표를 앨리스에게 전송 앨리스가 밥의 신청에 응답 재전송 공격 및 다중 인증에는 안전하지만 , 반사 공격 (reflection

attack) 이 발생할 가능성이 있음



양 방향 인증 절차



공개키 암호화를 이용한 사용자 인증 사용자 인증을 위해서 공개키 암호화를 사용 사용자 인증 방법 ( 그림 30.9 에서 )

앨리스가 개인키로 메시지를 암호화 밥이 앨리스의 공개키를 이용하여 메시지 복호화

문제점 중간자 공격 (man-in-the-middle)


30.4 30.4 키 관리키 관리

대칭키 분배 대칭키 분배의 문제점

n 명의 사람이 서로 통신하기를 원할 경우 , n(n-1)/2 개의 대칭키가 필요

n 명의 그룹에서 각 사람은 n-1 개의 키를 가지고 있으며 , 그룹 내의 다른 사람에 대한 n-1 개의 키를 기억해야 함

안전한 키의 공유와 분배가 가능해야 함


키 관리키 관리 (( 계속계속 ))

세션키 대칭키 분배의 문제점은 당사자의 대칭키가 동적일 경우 효과적 각 세션마다 키를 생성하고 세션이 끝날 경우 키를 폐기

양측의 대칭키는 단지 한 번만 사용될 때 효과적이다 . 즉 세션마다 키를 생성하고 세션이 끝날 때 키를

폐기한다 .



Diffe-Hellman 방법 송 / 수신자를 위한 일회용 세션키를 제공 데이터를 교환하기 위해 세션키를 사용 인터넷을 통한 키 동의 전제 조건

대칭키를 확립하기 이전에 송 / 수신자는 두 개의 수 N 과 G 를 선택• N : (N-1)/2 가 소수라는 제한을 가진 큰 소수• G : 소수

N 과 G 는 기밀성을 필요로 하지 않음



Diffe-Hellman 방법



절차1 단계 : 앨리스는 임의의 큰 수 x 를 선택하고 R1=Gx mod N 을 계산2 단계 : 앨리스가 밥에게 R1 을 전송3 단계 : 밥이 또 다른 큰 수 y 를 선택하고 R2=Gy mod N 을 계산4 단계 : 밥이 앨리스에게 R2 를 전송5 단계 : 앨리스가 K=(R2)x mod N 을 계산 , 밥이 K=(R1)y mod N

을 계산

K 가 세션 동안 대칭키로 사용

(Gx mod N)y mod N = (Gy mod N)x mod N = Gxy mod N



예제 1 : G=7, N=23 일 경우1. 앨리스가 x=3 을 선택하고 R1=73 mod 23=21 을 계산2. 앨리스가 21 을 밥에게 전송3. 밥은 y=6 을 선택하고 R2=76 mod 23=4 를 계산4. 밥이 4 를 앨리스에게 전송5. 앨리스는 대칭키 K=43 mod 23=18 을 계산6. 밥은 대칭키 K=216 mod 23=18 을 계산

밥과 앨리스 모두 K=18 을 대칭키로 사용

Diffe-Hellman 프로토콜에서 대칭키 K=Gxy mod N 이다 .



중간자 공격 (man-in-the-middle attack) Diffe-Hellman 은 매우 복잡한 프로토콜이지만 , 제 3 자가 x 또는 y

값을 알아내지 않아도 되기 때문에 중간에서 밥과 앨리스를 속이는 것이 가능하다 .

중간자 공격 절차1. 앨리스가 x 를 선택한 후 R1=Gx 를 계산하여 R1 을 밥에게 전송2. 제 3 자가 R1 을 가로챈 후 , z 를 선택한 다음 R2=Gz mod N 을 계산하여

R2 를 앨리스와 밥에게 전송3. 밥이 y 를 선택한 다음 R3=Gy mod N 을 계산해서 R3 을 앨리스에게 전송 ,

R3 을 제 3 자가 가로챔4. 앨리스와 제 3 자가 공유한 키 K1=Gxz mod N 을 계산5. 제 3 자와 밥은 공유한 키 K2=Gzy mod N 을 계산

이 경우 앨리스와 밥은 제 3 자와 공유한 키를 서로간의 공유한 키로 생각



중간자 공격 절차



키 분배 센터 (KDC, key distribution center) 중간자 공격을 막기 위해서 송 / 수신자가 신뢰할 수 있는 대칭키를

필요로 함 송 / 수신자가 키 분배 센터와 대칭키를 공유

앨리스와 키 분배 센터 사이의 대칭키 : KA

밥과 키 분배 센터 사이의 대칭키 : KB



KDC 를 이용한 첫번째 접근법



Needham-Schroeder 프로토콜 송 / 수신자간의 완벽한 프로토콜을 얻기 위해서 다중 챌린지 - 응답

(challenge-response) 를 사용 4 개의 서로 다른 비표를 사용

RA, RB, R1, R2

7 단계의 프로토콜 절차를 가짐



Needham-Schroeder 프로토콜



Otway-Rees 프로토콜 5 단계의 절차를 가짐



공개키 인증 공개키 암호화에서는 대칭 공유키를 알 필요가 없음 앨리스가 밥에게 메시지를 보낼 경우 밥의 공개키만을 획득하여

이용 공개키 암호화에서 개인키는 보호하고 공개키는 알림

공개키 암호화에서는 모든 사람의 공개키를 얻을 수 있다 .



문제점 공개키를 공개하고 , 제 3 자의 위협 없이 안전하게 만드는 방법이

문제 예

밥의 공개키를 앨리스에게 보낼 경우 , 제 3 자가 이를 가로채고 자신의 공개키를 앨리스에게 전송

앨리스가 수신된 공개키를 이용하여 암호화한 후 전송하면 , 제 3 자가 가로채 자신의 개인키로 복호화



인증기관 (CA, certificate authority) 개체와 공개키를 연관시키고 인증서를 발행하는 연방 또는 정부 기관 인증기관을 통한 공개키 증명

인증기관에서 밥의 신원을 확인한 후에 공개키 인증서를 발행 밥의 공개키를 원할 경우 인증서와 암호화된 다이제스트를 획득 인증서를 통한 다이제스트와 인증기관의 공개키를 이용하여 복호화한

다이제스트를 비교 두 다이제스트가 일치할 경우 해당 공개키는 밥의 것임을 증명



X.509 인증서를 위한 표준 프로토콜 구조적 방식으로 인증서를 기술하는 방법 ASN.1(abstract syntax notation 1) 으로 필드를 정의 인증서 필드

Field Explanation

Version Version number of X.509

Serial number The unique identifier used by the CA

Signature The certificate signature

Issuer The name of the CA defined by X.509

Validity period Start and end period that certificate is valid

Subject name The entity whose public key is being certified

Public key The subject public key and the algorithms that use it



공개키 기반구조 (PKI, public key infrastructure) 공개키 질의 문제를 해결하기 위한 계층적 구조 PKI 계층 구조

첫번째 레벨 : Root CA 두번째 레벨 : 지리적 , 논리적 영역 세번째 레벨 : 두번째 레벨보다 작은 지리적 영역 모든 레벨은 루트를 신뢰 인증서를 발행한 인증기관을 신뢰하기 위해서는 상위 CA 에 조회할 수

있으며 , 이는 루트까지 갈 수 있음



공개키 기반구조 계층


30.5 KERBEROS30.5 KERBEROS

Kerberos 인증 프로토콜 KDC 와 같은 시기에 일반화 MIT 에서 설계되었으며 , 다양한 버전이 존재

버전 4 : 가장 유명한 버전 버전 5 : 가장 최근의 버전


KERBEROS(KERBEROS( 계속계속 ))

인증 서버 KDC( 키 분배 센터 ) 사용자 신원과 이와 일치하는 비밀번호를 가진 데이터베이스 사용자를 검증하고 , 앨리스 ( 서비스 요청 ) 와 TGS 사이에

사용되는 세션키를 발행하며 , TGS 를 위한 티켓을 발행 티켓 승인 서버

밥 ( 실제 서버 ) 에게 티켓을 발행 앨리스와 밥 사이의 세션키 (KAB) 를 제공 티켓을 발행하기 위해서 사용자 검증을 하지 않기 때문에 ,

한번의 검증을 통과할 경우 TGS 와 여러 번 통신하여 세션키를 받을 수 있음



실제 서버 앨리스 ( 서비스 요청자 ) 에게 서비스를 제공하는 서버 FTP 와 같이 클라이언트 - 서버 프로그램으로 설계되었으므로 , 사

람 - 대 - 사람에 대한 인증을 하지 않음



동작



동작 과정1 단계 : 신원을 평문으로 AS 에 전송

2 단계 : AS 가 앨리스의 대칭키 KA 로 메시지를 암호화하여 전송 ( 메시지는 TGS 와의 통신을 위한 세션키 KS 와 TGS 의 대칭키 KTG 로 암호화한 TGS 티켓을 포함 ), 앨리스가 메시지를 복호화하여 KS 와 티켓을 추출

3 단계 : 메시지 (AS 로부터 받은 티켓 , 실제 서버 이름 , KS 로 암호화된 타임스탬프 ) 를 TGS 로 전송

4 단계 : TGS 가 앨리스와 밥 간의 세션키 (KAB) 가 들어있는 티켓을 전송

5 단계 : 앨리스가 KAB 로 암호화된 타임스탬프가 들어 있는 밥의 티켓을 전송

6 단계 : 밥이 타임스탬프에 1 을 더한 후 , 메시지를 KAB 로 암호화하고 앨리스에게 전송



서비스 요구와 서비스 수신 동작 과정에서 6 단계 이후 앨리스는 대칭키와 같은 KAB 를 이용하여

밥에게 서비스를 요청하고 받을 수 있음

서로 다른 서버의 사용 앨리스가 다른 서버로부터 서비스를 받기를 원할 경우 4 단계

이후만 반복 Kerberos 에서는 신원의 검증을 반복하지 않음



Kerberos 버전 5 버전 4 와 버전 5 의 차이점

버전 5 의 티켓 수명이 더 길다 버전 5 는 티켓이 갱신된다 버전 5 는 모든 대칭키 알고리즘을 쓸 수 있다 버전 5 는 데이터 유형을 기술하기 위해 서로 다른 프로토콜을

사용한다 버전 5 는 버전 4 보다 더 많은 오버헤드를 가진다



영역 (realms) 각 시스템으로 AS 와 TGS 의 광범위한 분산 영역은 각 AS 와 TGS 가 커버하는 서비스 영역을 의미


30.6 30.6 요약요약

Documents

30 장 메시지 보안 , 사용자 인증과 키 관리