글 싣는 순서

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



앞장에서 PKI의 일반적인 내용에 대해 다루었다면, 이 번글에서는  CUCM과 전화기가 어떻게 PKI를 활용하는 지를 살펴보겠습니다. 내용의 일부가 "[연재] Cisco Secure IP Telephony 길라잡이"와 겹치기는 하지만,  설정을 위한 설명이 주였다면, 여기에서는 아키택쳐에 대한 이야기가 주입니다. 

이 번글은 이해하기 쉽게 전화기에서의 PKI, CUCM에서의 PKI로 나누어서 먼저 보겠습니다.   


전화기에서 사용하는 인증서
시스코의 모든 전화기는 PKI를 위한 개인키와 공인키를 생성할 수 있습니다. 생성된 키쌍은 CA로 부터 인증을 받아야 공유가 가능합니다. 시스코 전화기의 인증서는 크게 MIC와 LSC 두 종류가 있습니다.   

  • Manufacturing Installed Certificates (MIC)
    시스코 7900 Series 전화기는 공장 출하 시에 개인키와 공개키를 생성한 후에 MIC 인증서를 탑재합니다. MIC 인증서는 전화기의 공개키를 Cisco Manufacturing CA가 서명한 인증서입니다. 탑재된 MIC를 검증하기 위한 Cisco Manufacturing CA 인증서도 함께 탑재됩니다. 



    Cisco Manufacturing CA는 모든 전화기의 MIC 인증서의 루트 서버가 되며, Cisco Root CA의 Sub-CA이기도 합니다.  참고로 MIC의 유효기간은 기본 10년이며, RSA 키 길이는 2048 bit 입니다.


  • Locally Significant Certificate (LSC)
    시스코의 모든 6900 / 7900 / 8900 / 9900 시리즈 전화기들과 텔레프레즌스 코덱은 LSC 인증서를 가질 수 있습니다.  LSC의 루트 서버는 CUCM의 CAPF 이거나  External CA입니다. 


    위의 왼쪽 그림은 CAPF에 의한 서명된 Certificate 를 사용하는 환경이며, 오른쪽 그림은 External CA에 의해 서명된 Certificate를 사용하는 환경입니다. 참고로 Self-signed된 LSC의 유효기간은 기본 5년이며, RSA  키 길이는 512, 1024, 2048 bit 에서 선택할 수 있습니다. 

정리하면, 시스코 7900 시리즈 전화기는 MIC와 LSC를 모두 탑재할 수 있지만, LSC를 우선적으로 사용합니다. 나머지 6900, 8900, 9900 전화기들은 LSC 만을 탑재할 수 있습니다. 


CUCM의 PKI 구조
CUCM의 PKI를 이용하기 위해서는
 CAPF 서비스와 CTL Provider 서비스를 활성화해야 합니다. CAPF는 CUCM에서 CA 역할을 하거나 외부 CA 서버와 연동이 가능하도록 기능을 제공하면서 CUCM 클러스터 내에서 Publisher만이 활성화합니다. CTL Provider 는 CUCM 클러스터내의 모든 서버에서 활성화해야 합니다

CUCM의 인증서는 Self-signed한 인증서를 이용해서 자신이 루트서버가 되거나, 외부 루트 CA에 의해 서명된 인증서를 이용할 수 있습니다. 

  • CUCM의 Self-signed Certificates
    기업에 별도의 CA 서버가 없더라도 PKI를 이용하기 위해서는 Self-signed Certificate를 이용합니다. 각각 CUCM은  자신을 위한 개인키(Private Key)와 공개키(Public Key)를 생성합니다. 



    CallManager 서비스와 TFTP 서비스를 실행하는 CUCM들이 대상으로 CAPF 서비스가 실행됩니다.  시스코의 PKI는 다수의 루트 서버가 존재하는 환경입니다. 한 클러스터 내에 다수의 CUCM서버가 모두 루트 서버가 되는 구조이며, 이 외에 MIC에 대한 루트로써 Cisco Manufacturing CA가 있습니다.  


  • CUCM의 Externally Signed Certificate
    시스코의 CUCM은 키를 생성한 후에 수동 또는 자동으로 외부 서버에 의해 서명된 인증서를 사용할 수 있습니다. 


PKI 기반 환경에서 Self-signed와 Externally Signed를 선택할 때 모든 클라이언트에 대한 인증서 관리를 어디할 것인지를 고려해야 하며, 비용적인 면에서도 시스코의 Self-signed는 무료로 제공되지만, 외부 CA 서버는 경우에 따라 비용이 발생합니다


시스코 전화기의 Trust List(신뢰목록)의 이해
시스코 전화기에는 ITL (Initial Trust List)과 CTL (Client Trust List)이라는 두 종류의 신뢰목록 (Trust List)이 있습니다.  이 두 신뢰목록의 차이를 살펴보겠습니다.


  • CTL (Certificate Trust List)의 이해
    CTL에 대해서는 이미 "[연재] Cisco Secure IP Telephony의 이해 - (1) CTL의 개요 및 설치 (http://www.nexpert.net/356)' 라는 글에서 설치를 위한 간단한 정보를 살펴보았다면, 여기에서는 좀 더 자세하게 살펴보겠습니다. 

    CTL은 전화기가 신뢰할 수 있는 인증서의 리스트를 저장한 파일입니다. 파일은 TFTP 루트 디렉토리에 저장되며, 다음의 인증서를 포함합니다. 

    CUCM의 CallManager 및 TFTP서비스
    CAPF
    TFTP Servers
    - ASA Firewalls
    - System Administrator Security Token

    CTL File을 생성하기 위해 CTL Client를 CUCM에서 다운로드받아 설치합니다.
    CTL Client의 개인키와 공인키는  Security Token에 있으며, 공인키는 Cisco CA에 의해 서명됩니다. 


    CTL Client는 CUCM으로 부터 CUCM, TFTP, CAPF의 공인키를 다운로드 받아서 CTL 파일을 생성합니다.  전화기가 부팅하거나 리셋될 때, CTL 파일은 전화기로 TFTP를 통해 다운로드 됩니다. 전화기는 신뢰할 수 있는 인증서 목록을 안전하게 확보할 수 있게 됩니다. CTL 파일은  CTL Client의 개인키로 서명되어 있으므로 공인키를 이용하여 검증합니다. 전화기는 새로운 CTL 파일이 검증한 후에 기존의 CTL 파일을 대체합니다. 


  • ITL (Initial Trust List)의 이해
    CTL을 이용하여 전화기는 안전하게 통신을 할 수 있습니다만, 전화기가 처음 부팅하였을 때는 CTL을 가지고 있지 않습니다. 최초 부팅 시에 신뢰할 수 있는 네트워크에서 통신이 이루어진다면, 전화기는 안전하게 CTL을 다운로드 받을 수 있을 것입니다. 신뢰할 수 없는 네트워크에서의 최초 통신을 고려해 볼 수 있습니다.
     

    ITL은 이름에서 알수 있듯이 초기에 보안되지 않은 전화기와 보안 통신을 하기 위해 필요한 신뢰목록입니다. Security Token이 필요하지 않고, CUCM과의 통신을 위한 최소의 목록으로 전화기가 부팅되거나 리셋될때 TFTP로 부터 다운로드 받습니다. 전화기는 처음 ITL 파일을 자동으로 신뢰합니다. ITL 파일은 CTL 파일의 최소 버전으로 CUCM으로 구성정보를 안전하게 다운로드 받기 위한 내용만을 포함합니다. 전화기가 CTL을  다운로드 받은 후에는 CTL을 우선 사용합니다.  



외부 CA 서버로 부터 인증서를 주고 받기 위한 프로토콜들
외부 CA를 이용하기 위해서는 CSR (Certificate Signing Request)ㅇ 생성 및 외부 CA 가 서명한 인증서를 재 주입해야 합니다. 이 과정을 사람이 직접 매뉴얼하게 할 수도 있지만, 자동화되도록 하는 프로토콜 필요합니다. 10대 정도의 전화기를 대상한다면 사람이 직접하는 것이 문제가 없지만, 1000대 또는 만대의 전화기를 ㅇ연동해야 할 경우에 사람이 직접하는 것은 재앙에 가깝습니다.

대규모 PKI를 구현 시에 CA에로 부터 X.509 전자서명을 요청하고 수령하도록 개발된 프로토콜로 SCEP (Simple Certificate Enrollment Protocol), CMP (Certificate Management Protocol), CMC (Certificate Management over CMS)가 있습니다. SCEP는 현재 IETF의 드래프트 상태이나 MS, Apple, Cisco, Juniper 와 같은 제조사들이 사용하는 사실상의 업계 표준입니다. 그러나 SCEP는 신뢰할 수 있는 네트워크에서 사용을 전제로 하기 때문에 다소 보안적인 요소가 미흡합니다. 이를 보완하는 프로토콜이 CMP와 CMC입니다.  RFC 4210에 정의된 CMP (Certificate Management Protocol)와 RFC 5272에 정의된 CMC (Certificate Management over CMS)는 SCEP에 비해 복잡하다는 단점이 있고, 아직까지 구현되어 사용되는 제품을 보지 못했습니다. 

저 또한 깊이 공부를 해보지 않아서 강력하게 말씀드릴 수는 없지만, 현재의 대세는 SCEP입니다. 가까운 미래에는 CMP나 CMC를 이용하게 될 지도 모르겠습니다.  

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

라인하트 (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 라인하트
TAG , , , , ,

댓글을 달아 주세요



티스토리 툴바