글 싣는 순서

1. Secure IP Telephony의 개요 
2. 암호화 (Encryption)와 인증 (Authentication)
3. 전자서명 (Digital Signature)
4. PKI의 이해
5. Cisco Secure IP Telephony의 이해 
6. TLS & SRTP



"Secure IP Telephony의 이해"에서 가장 중요한 글을 이야기하라면, 단연코 지금 설명하는 PKI입니다. 공개키 기반 구조를 이해해야 TLS와 SRTP를 이용한 Secure IPT를 이해할 수 있습니다. 사실 이 글 이후에 나오는 6장 TLS 및 SRTP와 5장은 시스코 IP Telephony는 시스템이 알아서 동작하는 구조를 설명하는 것입니다. 여기까지는 정확히 알아야 Secure IP Telephony에 대한 이야기가 가능합니다.  

이번 글에서는 공개키 기반 구조 (Public Key Infrastructure)에 대한 이야기를 해 보겠습니다. 


PKI의 개요
PKI는  공개 키 암호 방식을 바탕으로 한 디지털 인증서를 활용하는 소프트웨어, 하드웨어, 정책 등을 총칭하며, 공개키 암호 기술이 안전하게 사용되는 환경을 말합니다. PKI는 인증서의 발급, 관리, 배포, 취소 등을 다룹니다.


위의 그림은 공개키 기반 구조와 인증서 관리를 모두 다루는 복잡한 그림이지만, 이해하기는 수월합니다. PKI를 구성하는 핵심 컴포넌트는 CA(Trusted Introducer, 인증기관)과 Certificate(인증서)입니다.  RA(Registration Authority)는  PKI  사용자 (End Entity)의 신분 또는 ID를 확인하고, 인증서를 등록하는 기능을 수행하고, Directory Services는 인증서를 저장 및 관리합니다. 그림의 테두리는 인증서의 생성, 배포, 폐기, 기간만료, 재생성의 과정을 나타내고 있습니다.   

이번 글에서는 인증서 관리 및 폐기에 대한 부분은 논외로 하겠습니다. 향후에 시간나면 부록으로 다루겠습니다. 워낙에 연재해야 할 양이 많아 중요한 것 부터 먼저 갑니다. -,-:?

간단하게 언급했던 것처럼 PKI의 주요 구성요소에 대해 살펴보겠습니다. 

  • CA (Certificate Authority) :인증기관
    Trusted Introducer의 역할을 수행하며, PKI 사용자나 기기의 공개키 (Public Key)를 서명합니다. CA는 인증 정책을 수립하고, 다른 CA와 상호 인증을 수행합니다. 
     
  • PKI 사용자 또는 Entity
    안전하게 자신의 공개키를 배포하기를 원하는 사용자, 기기, 어플리케이션을 말합니다.

  • Certificates : 인증서
    PKI 사용자의 ID, 공개키 등을 포함하며, X.509 v3 표준 포맷으로 생성합니다.

  • CRL (Certificate Revocation List) : 인증서 취소 목록
    인증서의 분실 또는 유효기간 만료 등의 이유로 더 이상 신뢰할 수 없는 인증서의 목록



PKI는 왜 필요한가?
암호화를 구축할 때 가장 큰 이슈는 안전한 키교환입니다. 사용자 A가 직접 사용자 B에게 보안키를 직접 전달하는 것이 가장 안전한 방법이지만  확장성이 매우 떨어집니다.  사용자 A는 알지도 못하는 다수와 보안 통신을 해야 하므로 직접 보안키를 전달하는 것은 불가능합니다. 수동이 아닌 자동화된 프로세스를 통해 안전하게 키를 교환하는 방법이 필요합니다.  

키를 교환하는 방법은 Diffie-Hellman 알고리즘을 이용한 방법과 비대칭 암호화 알고리즘인 RSA를 이용한 방법이 있습니다.  Diffie-Hellman 알고리즘은 암호화 통신을 해야 할 사용자 A와 사용자 B가 암호화 키를 교환하기 하지 않고, 암호화 키를 계산을 통해 산출하는 방법입니다. 정말 복잡한 방법이지만, 직접 키를 교환하지 않고도 연산을 할 수 있으므로 안전한 방법입니다.  


또다른 방법은 위의 그림에서 설명하는 비대칭 암호화 알고리즘을 이용한 키 교환 방법입니다. 
사용자 A는 사용자B와 보안 통신을 위한 AES Key를 RSA라는 비대칭 암호화 알고리즘으로 전달합니다. 사용자 A는 대칭 암호화키인 AES 키를 생성한 후에 사용자 B의 공개키를 이용하여 암호화합니다. 이 메세지를 복호화할 수 있는 사람은 사용자 B 뿐입니다. 이유는 사용자 B의 개인키 (Private Key)만이 유일한 키쌍이기 때문입니다. 

비대칭 암호화 알고리즘을 이용한 키교환 방법은 분명 효과적이지만, 다음과 같은 문제가 있습니다.
    • 모든 사용자의 공개키를 확보
      사용자 A가 수많은 사람과 통신하는 것을 가정한다면, 모든 공개키를 확보할 수 있어야 합니다. 

    • 신뢰성 확보 
      사용자 A가 사용한 사용자 B의 공개키는 사용자 B의 것이다라는 전제가 필요합니다. 제 삼자가 사용자 B의 공개키임을 확인시켜 준다면 충분히 신뢰성은 확보될 수 있습니다. 

    • "man in the middle attack" 취약
      제 삼자가 사용자 B의 공개키를 제공할 때 전송 간에 문제가 발생할 수 있습니다. 

문제를 해결할 수 있는 방안은 공개키의 신뢰성과 확장성입니다. PKI (Public Key Infrastructure)는 공개키의 신뢰성을 확보하는 방법은 약하지만, 확장성 문제를 해결할 수 있습니다. 사용자가 모든 사용자의 공개키를 확보하는 것은 불가능하므로 단 하나의 Trusted Introducer를 통해 해결합니다. 모든 사용자들은 Trusted Introducer의 공개키를 확보하고, Trusted Introducer가 모든 사용자의 공개키를 보유합니다. 사용자들이 다른 사용자의 공개키가 필요할 경우에 Trusted Introducer가 서명을 하여 공개키를 전송하므로써 안전하게 사용할 수 있습니다. 

Cisco Secure IP Telephony는 비대칭 암호화 알고리즘을 이용한 방법을 이용합니다.  


PKI의 동작 방식
위의 간략한 정리를 기반으로 PKI 기반의 키 생성 및 관리에 대해 상세히 살펴보겠습니다. 

  • 키 생성
    모든 PKI 사용자들은 각 자의 개인키(Private Key)와 공개키 (Public Key)를 생성합니다. 아래 그림에서 사용자 A, 사용자 B, Trusted Introducer (CA)는 각자의 키쌍 (Key Pair)을 생성합니다. 



  • Trusted Introducer (CA)의 공개키 배포
    PKI 내의 모든 사용자는 Trusted Introducer에 의해 제공되는 모든 정보를 전자서명을 통해 신뢰합니다.  Trusted Introducer의 전자 서명을 신뢰하기 위해 Trusted Introducer의 공개키를 확보합니다. 



  • 사용자의 공개키 등록
    PKI에서 모든 사용자들은 신뢰할 수 있는 단 하나의 Trusted Introducer (CA)를 가지고 있으며, 자신의 공개키를 등록합니다.  아래그림에서 Trusted Introducer는 사용자 A와 사용자 C의  공개키를 확보하였습니다. 




  • 공개키 서명
    Trusted Introducer는 사용자의 공개키와 ID를 확인한 후에 자신의 개인키로 전자서명을 합니다. 이 것을 Certification (인증서)라고 합니다. 아래 그림에서 사용자 A가 제공한 공개키를 Trusted Introducer의 개인키를 RSA 알고리즘을 통해 서명을 하여 인증서를 생성합니다.  




  • 인증서 수령
    Trusted Introducer가 생성한 인증서를 각 사용자에게 제공합니다. 사용자들은 다음의 키를 보유합니다.

    - 사용자의 개인키
    - 사용자의 공개키
    - Trusted Introducer (CA)의 공개키
    - Trusted Introducer (CA)가 서명한 사용자의 공개키 : Certificate

    인증서를 수령한 사용자 A는 자신의 Trusted Introducer가 제대로 서명을 했는 지 확인하기 위해서는 Trusted Introducer의 공개키로 인증서를 복호화하면 됩니다. 




  • 인증서 교환
    이제 사용자들은 Trusted Introducer의 도움없이 직접 사용자간에 인증서를 교환하여 안전한 통신을 할 수 있습니다. 아래 그림에서 사용자 A가 사용자 C의 인증서를 받은 후에 Trusted Introducer의 공개키로 복호화하면 사용자 C의 공개키에 대한 신뢰성을 확보할 수 있습니다. 사용자 C의 인증서 서명은 Trusted Introducer만이 할 수 있고, Trusted Introducer는 사용자 C가 진짜라는 것을 이미 확인하였기 때문입니다. 





PKI는 Trusted Introducer를 이용하여 확장성 및 신뢰성 문제를 해결할 수 있습니다. PKI의 개요에서 CA와 Certificate에 대해 정리하였습니다. CA는 Trusted Introducer로써 모든 PKI 사용자의 공개키에 서명을 하여 Certificate를 생성합니다. Certificate는 PKI 사용자의 ID와 공개키를 포함합니다. Certificate는 Trusted Introducer의 공개키만 있으면 누구나 확인할 수 있는 문서입니다. 즉, 암호화될 필요가 없는 것으로 신뢰성과 무결성을 보장하는 데 초점을 둡니다.



인증서 (Certificate)의 개요 
인증서는 X.509 v3 표준에 기반한 데이타 포맷으로 생성됩니다. 아래의 표는 X.509 v3에 포함되는 내용을 순서대로 표시한 것이며, 그 아래는 실제 CUCM에서 Self-signed된 인증서입니다.  


[
  Version: V3
  Serial Number: 129112970749297966055322864464585290340
  SignatureAlgorithm: SHA1withRSA (1.2.840.113549.1.1.5)
  Issuer Name: L=Seoul, ST=Seoul, CN=CUCM91, OU=Collaboration, O=Cisco_labs, C=KR
  Validity From: Tue Nov 06 22:08:08 KST 2012
           To:   Sun Nov 05 22:08:07 KST 2017
  Subject Name: L=Seoul, ST=Seoul, CN=CUCM91, OU=Collaboration, O=Cisco_labs, C=KR
  Key: RSA (1.2.840.113549.1.1.1)
    Key value: 30818902818100bdf7a7464276f7e3049e0389b21e0c779fe4e5df051b47dec55381aaebdcffc2935e3e28d7571aa54c068c19ca0c9b41c50d21fd14fc78309fbf20e47413f01d2362766c3f8afdf71ed73529abb5dffec561350163a2299826777c4c8092b15c9fb4cd67c35cc49995bc585861e325348d97daf0ebcb98a0c2edf369f3b212650203010001
  Extensions: 3 present
  [ 
     Extension: KeyUsage (OID.2.5.29.15)
     Critical: false
     Usages: digitalSignature, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, 
  ]
  [ 
     Extension: ExtKeyUsageSyntax (OID.2.5.29.37)
     Critical: false
     Usage oids: 1.3.6.1.5.5.7.3.1, 1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.5, 
  ]
  [ 
     Extension: SubjectKeyIdentifier (OID.2.5.29.14)
     Critical: false
     keyID: 04f6f55aa5afb2e18fd599fe47b5f27cdf7d50d8
  ]


  Signature: 
  0000: 15 7d c0 fa 96 47 11 dd d3 38 62 94 7e 98 39 22 [.}...G...8b.~.9"]
  0010: 6e a1 33 04 a7 20 05 84 52 6f 42 af 78 0d a0 19 [n.3.. ..RoB.x...]
  0020: 09 9d 67 6a 16 e8 40 0b 6d c6 e8 73 5e 41 02 02 [..gj..@.m..s^A..]
  0030: cb 80 5b 5a 46 ca 35 9b 79 a9 40 98 61 6a 83 be [..[ZF.5.y.@.aj..]
  0040: 12 bc 4f ce 23 fd f9 aa fc f7 ac 7e d0 36 34 0c [..O.#......~.64.]
  0050: 98 ae f1 f4 01 01 7e 39 b2 36 f4 d7 13 b1 b1 13 [......~9.6......]
  0060: c1 37 0f 31 35 e7 f6 c1 f4 02 99 c9 e6 33 3e 00 [.7.15........3>.]
  0070: 0b 52 3e a4 0a a8 35 c1 6f 9b 2f a8 35 3e 5f e2 [.R>...5.o./.5>_.]
]

X.509의 인증서는 다음과 같은 내용을 포함합니다.

  • Version : X.509 버전
  • Serial Number : 인증서를 발행 번호 
  • Signature Algorithm : 인증서를 서명할 때 사용한 RSA 알고리즘 
  • Issuer Name: 인증서를 발행한 CA
  • Validity Period : 인증서의 유효기간
  • Subject Name :  인증서를 요청한 사용자 정보로  CN=은 호스트네임, O=기관명, C=국가명이 포함됩니다.   CUCM을 설치할 때 조직, 호스트네임, 국가, 주, 도시명을 넣는 란이 있습니다. 여기서 가지고 오므로 변경이 필요하다면, 설치를 다시해야 하는 아픔이 있습니다.
  • Key : 사용자의 공개키
  • Extension : 추가적으로 포함할 사항
  • Signature : CA의 개인키로 서명


인증서는 .pem 과 . der 파일 형식을 주로 사용합니다.  

  • .PEM 파일 : Privacy Enhanced Mail의 약자로 Based 64로 엔코딩 됨
  • .DER 파일 : 바이너리 포맷으로 되어 있음
이 두 가지 파일은 상호 호환및 변환이 가능합니다. 위에서 보여드린 예제는 .der 파일이며, .pem 파일은 아래와 같습니다. 

-----BEGIN CERTIFICATE REQUEST-----
MIIBrTCCARYCAQAwIzELMAkGA1UEBhMCSU4xFDASBgNVBAMTC1Rlc3RSZXF1ZXN0
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCotPg1kgOmqdluAcKYD747n+vn
FhP5jZXePk4gLqXqSf7O5mhGMuh4MAD+q/CknxyjgjHlqwVVIRgo830dIwePmEZl
oR6yBs5Kmd2Pe9YHkWcq12tdhgXZ67tSd5D6pN+YpmgV1wCBdJN/aTD3fEZl6WZy
nRcz2n4hwvUs19jIcQIDAQABoEowSAYJKoZIhvcNAQkOMTswOTAOBgNVHQ8BAf8E
BAMCBaAwJwYDVR0lBCAwHgYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDBTAN
BgkqhkiG9w0BAQQFAAOBgQAryrzHEwcsEH3BZBunY+++3uOd9bhzQx3ilGYJYrn4
hQ7CJCM9VV/V4Eu78hNlC1wq6P1s44qGD3gPDPhkEAjIBvuhLUhq3c5hRYE/TwfG
eyJLLRLkWQT3+XfMkN4hGwISF29gpiIi6CF44Iw1mWmlY7m67BT5J9+UR/7UBwHj
gA==
-----END CERTIFICATE REQUEST----- 


왜 Self-signed Certificate가 필요한가?
위의 X.509 예에서는 Issuer와 Subject Name이 동일합니다. 따라서, Self-signed된 인증서임을 알수가 있습니다. 왜 Self-signed Certificate가 만들어졌는 지를 살펴보겠습니다.

PKI에서는 모든  Public Key는 인증서 (Certificate) 형식으로 배포됩니다. PKI 사용자들은 자신의 Public Key를 CA (Trusted Introducer)에 서명되므로써 인증서를 배포할 수 있습니다. 그렇다면, CA는 누가 서명을 해주어야 합니까? CA는 일반적으로 Subordinate CA와 Root CA로 나뉩니다. Root CA는 최상위의 CA로 하위 CA가 신뢰할 수 있도록 서명을 합니다. Root CA는 최상위에 위치하므로 아무도 서명을 대신해 줄 수 없습니다. 그래서, Self-signed 가 필요한 것입니다. 

또한, 특정 CA는 존재하지 않지만, PKI 기반의 암호화를 사용하고자 할 경우에도 Self-signed Certificate를 이용할수 있습니다. 


안전하게 PKI 등록하기
PKI는 안전하게 보안통신을 할 수 있는 방안이지만, 지금까지 살펴본 바로 CA 서버에 사용자를 등록할 때 신뢰할 수 있는 네트워크 내에서 이루어지는 것이 안전합니다.  신뢰할수 없는 네트워크(untrusted netwrok)에서는 Man-in the middle attack에 취약합니다. 공격자가 CA와 PKI 사용자를 속일 수 있는 여지가 남아 있습니다. 

따라서, 신뢰할 수 있는 네트워크에서 PKI 등록을 수행한 후에 일반 인터넷이나 신뢰할수 없는 네트워크에서 안전하게 사용하는 것이 좋습니다. 신뢰할 수 있는 네트워크는 물리적으로 완벽하게 분리된 네트웍이나 IPSec등에 의해 안전한 네트워크를 의미합니다.  

신뢰할 수 없는 네트워크에서도 안전하게 PKI 등록을 하는 방법을 살펴보겠습니다. 우선, CA와 PKI 사용자는 각자가 직접 각각의 Certification을 직접 확인(Verification)해야 합니다. 

가장 확실한 방법은 Out-of-band verification으로 전화를 이용하거나, 별도의 방법을 사용하는 것입니다. 위의 그림에서는 CA의 공개키를 헤쉬한 것과 사용자 A가 받은 CA의 공개키를 헤쉬한 것을 비교하여 확인하는 것입니다. 

이러한 등록 과정의 문제를 해결하기 위해 은행에서 다양한 보안카드나 One-time Password 키 등을 이용하여 사용자가 은행을 확인하고, 은행은 사용자를 확인할 수 있도록 합니다. 인터넷은 신뢰할 수 없는 네트워크이지만, 다양한 Out-of-band Verification을 통해 안전하게 사용할 수 있는 것입니다. 
 

마치며
PKI에 대한 전반적인 내용을 살펴보았습니다. PKI Revocation 과 키 관리를 위한 CRL과 OCSP(On-line Certificate Status Protocol) 대한 내용도 적지 않으므로 이번 글에서는 다루지 않았습니다. 앞서 말씀드린 대로 부록으로 설명을 하도록 하겠습니다.

우선은 실전을 위한 "Secure IP Telephony 길라잡이" 연재를 먼저 마무리 짓도록 하겠습니다. 두 개의 연재를 동시에 폭풍집필하기는 처음입니다. ^^


----------------- --------------------------------------------------------

라인하트 (CCIEV #18487) 
ucwana@gmail.com (라인하트의 구글 이메일) 
http://twitter.com/ucwana (라인하트의 트위터 ) 
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항) 
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스) 
http://groups.google.com/group/ucforum (벤더에 상관없이 UC를 공부하는 사람들이 모인 구글 구룹스) 
정리하고 보니 나도 디지털 네이티브 _____________________________________________________

  

저작자 표시 비영리
신고
Posted by 라인하트

댓글을 달아 주세요

  1. Favicon of http://kaluta.blog.me BlogIcon 주범식 2013.11.15 10:19 신고  댓글주소  수정/삭제  댓글쓰기

    CUCM에서 받은 인증서에 포함되는 subject name을 변경해야 하는 경우는 언제인가요?
    변경하기 위해서는 cli에서 set web-security명령어로 수정만 하면 문제 없는건 아닌지요?



티스토리 툴바