30장 메시지 보안, 사용자 인증과 키 관리 30.1 메시지 보안 30.2 전자서명 30.3 사용자 인증 30.4 키 관리 30.5 KERBEROS 30.6 요약

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

메시지 보안(계속) 기밀성(privacy) 송신자와 수신자가 원하는 기밀성 전송된 메시지를 수신자 이외의 사람이 알아낼 수 없도록 하는 보안 방법 암호화를 이용 정당하지 않은 공격자가 내용을 알 수 없도록 전달 좋은 기밀성 기술은 잠재적인 공격자가 메시지의 내용을 알 수 없다는 것을 보장하는 것

메시지 보안(계속) 대칭키 암호화를 이용한 기밀성 대칭키 암호화와 복호화를 이용 기밀성을 얻기 위한 일반적인 방법 송신자와 수신자가 키를 공유

메시지 보안(계속) 공개키 암호화를 이용한 기밀성 공개키 암호화를 이용 암호화 키 공개키 : 공개적으로 알림 개인키 : 수신자만 소유 키 소유자에 대한 확인(인증) 문제가 중요하게 대두

메시지 보안(계속) 메시지 인증 수신자가 송신자의 신원을 확인하고 침입자가 메시지를 보내지 않았다는 것을 확인하는 보안 방법 전자서명을 이용 무결성 송신 데이터가 정확히 수신자에게 도착해야 한다는 것을 의미하는 보안 방법

메시지 보안(계속) 부인방지 수신된 메시지가 특정 송신자로부터 수신된 메시지임을 증명할 수 있는 보안 방법 부인방지에 대한 증명은 메시지 수신자의 임무 전자서명을 이용

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

전자서명(계속) 전체 문서에 서명하기 공개키 암호화를 이용하여 문서에 서명 키 역할 제공 서비스 개인키 : 메시지 암호화(서명) 공개키 : 메시지 복호화(서명 검증) 제공 서비스 무결성 : 메시지의 부분 또는 전체를 바꿀 경우 복호화된 메시지를 읽을 수 없음 인증 : 제 3자의 개인키로 암호화된 메시지를 공개키로 복호화할 경우 메시지를 읽을 수 없음 부인방지 : 송신자의 개인키와 공개키를 가지고 암호화와 복호화하여 저장된 메시지를 생성

전자서명은 기밀성을 제공하지 않는다. 만약 기밀성이 필요하다면 암호화/복호화를 다른 계층에 적용해야 한다. 전자서명(계속) 전체 문서에 서명하기 전자서명은 기밀성을 제공하지 않는다. 만약 기밀성이 필요하다면 암호화/복호화를 다른 계층에 적용해야 한다.

전자서명(계속) 다이제스트에 서명하기 공개키 암호화의 문제점은 긴 메시지에 서명하는 것이 비효율적임 문서의 다이제스트에 서명 해시 함수를 사용하여 메시지에 대한 다이제스트 생성 해시 함수로는 MD5(Message Digest 5)와 SHA-1(Secure Hash Algorithm)이 일반적으로 사용 MD5 : 120비트의 고정길이 다이제스트 생성 SHA-1 : 160비트의 고정길이 다이제스트 생성

전자서명(계속) 해시 함수의 특성 일방향 : 메시지에서 다이제스트를 생성할 수 있지만, 다이제스트에서 메시지를 생성하는 것은 성립하지 않음 일-대-일 : 두 메시지는 같은 다이제스트를 생성할 확률이 거의 없음

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

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

전자서명(계속) 메시지의 안정성 입증 다이제스트가 변경되지 않았고(무결성), 다이제스트는 메시지의 표현이다. 그래서 메시지는 변경되지 않은 것이다(두 개의 메시지가 같은 다이제스트를 생성하는 것은 거의 없다는 것을 기억하라). 무결성도 제공된다. 2. 다이제스트는 실제 송신자에게서 온 것이다. 그래서 메시지 또한 실제 송신자에게서 온 것이다. 만약 공격자가 메시지를 만들었다면 메시지는 같은 다이제스트가 생성되지 않을 것이다(두 개의 메시지가 같은 다이제스트를 생성하는 것은 거의 없다). 3. 송신자는 메시지를 부인할 수 없기 때문에 다이제스트를 부인할 수 없다. 다이제스트를 생성할 수 있는 유일한 메시지일 확률이 매우 높은 메시지가 수신되었다.

30.3 사용자 인증 대칭키 암호화를 이용한 사용자 인증 첫 번째 방법 앨리스가 대칭키 KAB를 사용하여 암호화된 메시지에 자신의 신원과 비밀번호를 전송 대칭키에 자물쇠를 추가

사용자 인증(계속) 두 번째 방법 문제점 재전송 공격을 방지하기 위해서 비표(nonce)를 추가 제 3자가 앨리스의 메시지를 가로채어 나중에 밥에게 전송할 경우 밥은 수신된 메시지가 이전 메시지인지 새로운 메시지인지 구별할 수 없음 재전송 공격(replay attack)이 발생 두 번째 방법 재전송 공격을 방지하기 위해서 비표(nonce)를 추가 비표는 오직 한번만 사용되는 임의의 수로 일회용 수 인증의 단계 앨리스가 평문으로 자신의 신원을 밥에게 전송 밥은 평문으로 비표 RB를 전송 앨리스는 비표를 다시 보내고, 대칭키를 이용하여 복호화하여 메시지에 응답

사용자 인증(계속) 비표 사용(메시지의 재전송을 방지)

사용자 인증(계속) 양 방향 인증 양 방향 인증 절차 및 위험성 앨리스가 자신의 신분과 비표를 밥에게 전송 밥이 자신의 비표를 앨리스에게 전송 앨리스가 밥의 신청에 응답 재전송 공격 및 다중 인증에는 안전하지만, 반사 공격(reflection attack)이 발생할 가능성이 있음

사용자 인증(계속) 양 방향 인증 절차

사용자 인증(계속) 공개키 암호화를 이용한 사용자 인증 사용자 인증을 위해서 공개키 암호화를 사용 사용자 인증 방법(그림 30.9에서) 앨리스가 개인키로 메시지를 암호화 밥이 앨리스의 공개키를 이용하여 메시지 복호화 문제점 중간자 공격(man-in-the-middle)

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 방법

(Gx mod N)y mod N = (Gy mod N)x mod N = Gxy mod N 키 관리(계속) 절차 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

Diffe-Hellman 프로토콜에서 대칭키 K=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 KERBEROS Kerberos 인증 프로토콜 KDC와 같은 시기에 일반화 MIT에서 설계되었으며, 다양한 버전이 존재 버전 4 : 가장 유명한 버전 버전 5 : 가장 최근의 버전

KERBEROS(계속) 인증 서버 티켓 승인 서버 KDC(키 분배 센터) 사용자 신원과 이와 일치하는 비밀번호를 가진 데이터베이스 사용자를 검증하고, 앨리스(서비스 요청)와 TGS 사이에 사용되는 세션키를 발행하며, TGS를 위한 티켓을 발행 티켓 승인 서버 밥(실제 서버)에게 티켓을 발행 앨리스와 밥 사이의 세션키(KAB)를 제공 티켓을 발행하기 위해서 사용자 검증을 하지 않기 때문에, 한번의 검증을 통과할 경우 TGS와 여러 번 통신하여 세션키를 받을 수 있음

KERBEROS(계속) 실제 서버 앨리스(서비스 요청자)에게 서비스를 제공하는 서버 FTP와 같이 클라이언트-서버 프로그램으로 설계되었으므로, 사람-대-사람에 대한 인증을 하지 않음

KERBEROS(계속) 동작

KERBEROS(계속) 동작 과정 1단계 : 신원을 평문으로 AS에 전송 2단계 : AS가 앨리스의 대칭키 KA로 메시지를 암호화하여 전송(메시지는 TGS와의 통신을 위한 세션키 KS와 TGS의 대칭키 KTG로 암호화한 TGS 티켓을 포함), 앨리스가 메시지를 복호화하여 KS와 티켓을 추출 3단계 : 메시지(AS로부터 받은 티켓, 실제 서버 이름, KS로 암호화된 타임스탬프)를 TGS로 전송 4단계 : TGS가 앨리스와 밥 간의 세션키(KAB)가 들어있는 티켓을 전송 5단계 : 앨리스가 KAB로 암호화된 타임스탬프가 들어 있는 밥의 티켓을 전송 6단계 : 밥이 타임스탬프에 1을 더한 후, 메시지를 KAB로 암호화하고 앨리스에게 전송

KERBEROS(계속) 서로 다른 서버의 사용 서비스 요구와 서비스 수신 동작 과정에서 6단계 이후 앨리스는 대칭키와 같은 KAB를 이용하여 밥에게 서비스를 요청하고 받을 수 있음 서로 다른 서버의 사용 앨리스가 다른 서버로부터 서비스를 받기를 원할 경우 4단계 이후만 반복 Kerberos에서는 신원의 검증을 반복하지 않음

KERBEROS(계속) Kerberos 버전 5 버전 4와 버전 5의 차이점 버전 5의 티켓 수명이 더 길다 버전 5는 티켓이 갱신된다 버전 5는 모든 대칭키 알고리즘을 쓸 수 있다 버전 5는 데이터 유형을 기술하기 위해 서로 다른 프로토콜을 사용한다 버전 5는 버전 4보다 더 많은 오버헤드를 가진다

KERBEROS(계속) 영역(realms) 각 시스템으로 AS와 TGS의 광범위한 분산

30.6 요약