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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22. 30.4 키 관리 • 대칭키 분배 • 대칭키 분배의 문제점 • n 명의 사람이 서로 통신하기를 원할 경우, n(n-1)/2개의 대칭키가 필요 • n 명의 그룹에서 각 사람은 n-1개의 키를 가지고 있으며, 그룹 내의 다른 사람에 대한 n-1개의 키를 기억해야 함 • 안전한 키의 공유와 분배가 가능해야 함

23. 키 관리(계속) • 세션키 • 대칭키 분배의 문제점은 당사자의 대칭키가 동적일 경우 효과적 • 각 세션마다 키를 생성하고 세션이 끝날 경우 키를 폐기 양측의 대칭키는 단지 한 번만 사용될 때 효과적이다. 즉 세션마다 키를 생성하고 세션이 끝날 때 키를 폐기한다.

24. 키 관리(계속) • Diffe-Hellman 방법 • 송/수신자를 위한 일회용 세션키를 제공 • 데이터를 교환하기 위해 세션키를 사용 • 인터넷을 통한 키 동의 • 전제 조건 • 대칭키를 확립하기 이전에 송/수신자는 두 개의 수 N과 G를 선택 • N : (N-1)/2가 소수라는 제한을 가진 큰 소수 • G : 소수 • N과 G는 기밀성을 필요로 하지 않음

25. 키 관리(계속) • Diffe-Hellman 방법

26. 키 관리(계속) • 절차 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

27. 키 관리(계속) • 예제 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이다.

28. 키 관리(계속) • 중간자 공격(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자와 공유한 키를 서로간의 공유한 키로 생각

29. 키 관리(계속) • 중간자 공격 절차

30. 키 관리(계속) • 키 분배 센터(KDC, key distribution center) • 중간자 공격을 막기 위해서 송/수신자가 신뢰할 수 있는 대칭키를 필요로 함 • 송/수신자가 키 분배 센터와 대칭키를 공유 • 앨리스와 키 분배 센터 사이의 대칭키 : KA • 밥과 키 분배 센터 사이의 대칭키 : KB

31. 키 관리(계속) • KDC를 이용한 첫번째 접근법

32. 키 관리(계속) • Needham-Schroeder 프로토콜 • 송/수신자간의 완벽한 프로토콜을 얻기 위해서 다중 챌린지-응답(challenge-response)를 사용 • 4개의 서로 다른 비표를 사용 • RA, RB, R1, R2 • 7 단계의 프로토콜 절차를 가짐

33. 키 관리(계속) • Needham-Schroeder 프로토콜

34. 키 관리(계속) • Otway-Rees 프로토콜 • 5단계의 절차를 가짐

35. 키 관리(계속) • 공개키 인증 • 공개키 암호화에서는 대칭 공유키를 알 필요가 없음 • 앨리스가 밥에게 메시지를 보낼 경우 밥의 공개키만을 획득하여 이용 • 공개키 암호화에서 개인키는 보호하고 공개키는 알림 공개키 암호화에서는 모든 사람의 공개키를 얻을 수 있다.

36. 키 관리(계속) • 문제점 • 공개키를 공개하고, 제 3자의 위협 없이 안전하게 만드는 방법이 문제 • 예 • 밥의 공개키를 앨리스에게 보낼 경우, 제 3자가 이를 가로채고 자신의 공개키를 앨리스에게 전송 • 앨리스가 수신된 공개키를 이용하여 암호화한 후 전송하면, 제 3자가 가로채 자신의 개인키로 복호화

37. 키 관리(계속) • 인증기관(CA, certificate authority) • 개체와 공개키를 연관시키고 인증서를 발행하는 연방 또는 정부 기관 • 인증기관을 통한 공개키 증명 • 인증기관에서 밥의 신원을 확인한 후에 공개키 인증서를 발행 • 밥의 공개키를 원할 경우 인증서와 암호화된 다이제스트를 획득 • 인증서를 통한 다이제스트와 인증기관의 공개키를 이용하여 복호화한 다이제스트를 비교 • 두 다이제스트가 일치할 경우 해당 공개키는 밥의 것임을 증명

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

39. 키 관리(계속) • 공개키 기반구조(PKI, public key infrastructure) • 공개키 질의 문제를 해결하기 위한 계층적 구조 • PKI 계층 구조 • 첫번째 레벨 : Root CA • 두번째 레벨 : 지리적, 논리적 영역 • 세번째 레벨 : 두번째 레벨보다 작은 지리적 영역 • 모든 레벨은 루트를 신뢰 • 인증서를 발행한 인증기관을 신뢰하기 위해서는 상위 CA에 조회할 수 있으며, 이는 루트까지 갈 수 있음

40. 키 관리(계속) • 공개키 기반구조 계층

41. 30.5 KERBEROS • Kerberos • 인증 프로토콜 • KDC와 같은 시기에 일반화 • MIT에서 설계되었으며, 다양한 버전이 존재 • 버전 4 : 가장 유명한 버전 • 버전 5 : 가장 최근의 버전

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

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

44. KERBEROS(계속) • 동작

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

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

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

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

49. 30.6 요약