글 싣는 순서
1. Secure IP Telephony의 개요
2. 암호화 (Encryption)와 인증 (Authentication)
3. 전자서명 (Digital Signature)
4. PKI의 이해
5. Cisco Secure IP Telephony의 이해
6. TLS & SRTP
TLS (Transport Layer Security)의 전신인 SSL (Secure Socket Layer Protocol)은 넷스케이프 사에 전자 상거래 등의 보안을 위해 개발한 프로토콜로 IETF에 의해 RFC 2246으로 1999년에 표준화되었습니다. TLS는 OSI 7 Layer 중에서 4단계인 Transport Layer (전송 계층)에서 이루어지는 암호화 방식이기 때문에 HTTP, XMPP, FTP 등의 어플리케이션 계층에 상관없이 사용할 수 있습니다. TLS는 기밀성, 무결성 및 사용자 인증까지 동시에 제공할 수 있는 프로토콜로써 확장성 및 효율성이 뛰어나 광범위하게 사용되며, VoIP에서는 시그널링의 암호화를 위해 사용합니다. 아래 그림은 TLS를 잘 표현한 다이어그램입니다.
TLS 프로토콜은 실제 TLS 협상을 위한 TLS Handshake Protocol과 실제 데이타를 전송하는 TLS Record Protocol 두 가지로 되어 있습니다. TLS Handshake 는 새로운 세션을 처음 시작할 때는 Full Handshake 협상을 하지만, 이전 세션을 다시 시작할 때는 Abbreviated Handshake를 합니다.
TLS 에 관한 협상이 어떻게 이루어지는 지 전화기와 CUCM 사이의 메세지를 통해 살펴보겠습니다.
- TLS Hello
TLS 세션의 속성 또는 파라미터 값인 암호화 알고리즘을 협상하기 위해 사용합니다. 클라이언트 Hello가 전송된 후에 CallManager (CUCM)가 Server Hello를 전송합니다. - Certificate Exchange (인증서 교환) - CUCM 서버 인증서 전송
CUCM은 서버 인증서및 전화기 인증서 요청 메세지를 동시에 전송합니다. 클라이언트인 전화기는 검증(Verification)을 위해 서버의 인증서가 자신의 인증서 목록에 있는 지를 확인합니다. 자신의 인증서 목록은 이미 전화기의 등록과정에서 CTL (Certificate Trust List) File로 수신하였습니다. 만일 CTL에 없는 CUCM서버의 인증서를 수신하면, 전화기는 세션을 종료합니다. 전화기는 검증 (Verification)이 완료된 후에 서버의 인증서에서 Public Key를 추출합니다. - Certificate Exchange (인증서 교환) - 전화기의 인증서 전송
CUCM 서버는 전화기의 인증서를 수신한 후에 자신의 데이타베이스를 이용하여 TLS 세션을 연결할 권한을 가진 클라이언트인지를 판단합니다. 전화기의 인증서는 CUCM 서버의 CAPF 인증서를 통해 검증되면, 전화기의 인증서에서 전화기의 Public Key를 추출합니다. - Server-to-phone Authentication
전화기는 랜덤 문자열을 생성하여 CUCM 서버로 전송합니다. CUCM 서버는 자신의 개인키 (Private Key)로 서명한 후에 응답합니다. 전화기는 서명된 응답을 이미 추출한 CUCM 서버의 공개키(Public Key)로 검증합니다. . - Phone-to-Server Authentication (일반적으로 옵션)
CUCM서버는 랜덤 문자열을 생성하여 전화기로 전송합니다. 전화기는 자신의 개인키로 서명한 후에 응답합니다. 서버는 서명된 응답을 이미 추출한 CUCM 서버의 공개키로 검증합니다. 특히, 전화기의 인증서는 전화기의 공개키 뿐만 아니라 맥주소와 같은 ID가 포함되어 있어 전화기의 identifier (식별자)로 활용됩니다. - TLS Session Key 교환
이제 CUCM 서버와 전화기는 상호간 인증을 완료하였습니다. 기억하실 지 모르겠지만, 실제 공개키와 개인키를 이용한 비대칭 암호화는 엄청난 리소스 소모가 발생하므로 실시간 통신에는 사용할 수 없습니다. 실시간 통신에 적합한 것은 대칭 암호화이며, 비대칭 암호화 방식을 이용하여 대칭 암호화를 위한 암호화 키를 교환하는 것이 Key Exchange (키교환)입니다. 바로 여기서 키를 교환합니다.
클라이언트인 전화기는 SHA-1 HMAC 패킷 인증과 AES 패킷 암호화를 위한 각각의 세션 키를 생성합니다. 전화기는 CUCM 서버의 Public Key로 세션 키를 암호화하여 전송합니다. 서버는 메세지를 복호화합니다. 이제 클라이언트 전화기와 CUCM 서버는 동일한 세션키를 안전하게 확보합니다. - Finished
Session Key를 교환 후 필요한 암호화 방식을 변경하거나 세션을 종료합니다.
SRTP (Secure Real-Time Transport Protocol)는 음성 및 영상을 실시간으로 전송하는 RTP를 암호화하는 프로토콜로 RFC 3711로 표준화 되었습니다. SRTP는 RTP와 동일한 포맷으로 이루어져 있지만, 실제 미디어인 RTP Payload가 암호화되어 있다는 점과 인증을 위해 Authentication Tag가 붙는다는 점이 틀립니다.
SHA-1 Authentication Tag (인증 테그)는 RTP 헤더와 페이로드를 전부를 헤슁한 값으로 32비트에서 160비트까지 일정한 크기의 문자열로 표시됩니다. SRTP MKI(Master Key Index)는 Secure IP Telephony에서는 사용되지 않습니다.
SRTP 패킷 인증
SRTP 패킷 헤더에 포함된 SHA-1 Authentication Tag를 이용한 인증 방식을 살펴보겠습니다.
전화기는 RTP 헤더와 페이로드(Payload)를 SHA-1으로 해슁할 때 TLS를 통해 교환된 세션 키를 함께 사용합니다. 헤쉬된 Authentication Tag는 SRTP헤더의 맨 뒤에 붙여서 상대 전화기로 전송합니다. SRTP는 받은 수신 전화기는 같은 SHA-1 알고리즘과 키로 수신한 패킷을 해쉬하여 검증합니다.
SRTP 패킷 암호화
SRTP는 실제 음성을 암호화하기 위해 AES 암호화 알고리즘과 TLS를 통해 교환된 세션키로 함께 암호화합니다. 수신 전화기는 같은 AES 알고리즘과 키로 수신한 패킷을 복화화합니다.
와이어샤크(Wireshark)와 같은 프로토콜 분석기를 가지고 SRTP 패킷을 캡쳐하여 재생할 경우에는 이해할 수 없는 잡음으로 들릴 것입니다.
Secure IP Telephony에서의 Call Flow
지금까지 TLS와 SRTP에 대해 정리하였습니다. 이제 두 대의 전화기가 통화할 때의 호 흐름을 정리해 보겠습니다.
1. 전화기들과 CUCM 서버는 TLS Handshake 프로토콜을 이용하여 인증서를 교환합니다.
2. 전화기들과 CUCM 서버는 랜덤 문자열 서명을 통해 상호 인증합니다.
3. 각각의 전화기들은 TLS 세션키를 생성합니다. TLS SHA-1인증을 위한 키와 TLS AES 암호화를 위한 키입니다.
4. 각각의 전화기들은 세션 키를 CUCM 서버의 공개키로 암호화여 CUCM으로 전송합니다.
5. 각각의 전화기들은 CUCM과 세션 키를 공유하여 시그널링 메세지 송수신합니다.
6. 두 대의 전화기가 통화를 시도할 경우, 각각의 전화기들은 SRTP 세션 키를 생성합니다.
7. CUCM서버는 생성된 SRTP 세션 키를 TLS 세션을 이용하여 두 대의 전화기로 전송합니다.
8. 두 대의 전화기는 안전하게 암호화 통신을 시작합니다.
TLS와 SRTP를 왜 반드시 함께 사용해야 하는 가?
TLS와 SRTP는 서로 다른 프로토콜이므로 경우에 따라 같이 사용하거나 따로 사용하는 것이 가능합니다. 일반적으로 시그널링을 통한 정보 보다 음성을 암호화하는 것이 더 중요하므로 TLS를 구성하지 않을 수도 있습니다. 그러나, SRTP의 암호화 키는 시그널링을 통해 교환됩니다. TLS를 이용하여 암호화되지 않을 경우 키가 그대로 노출되므로 SRTP 정보는 해커에게 쉽게 노출될 수 있습니다.
마치며
두 개의 연재를 동시에 진행하면서 지금까지 가장 많은 글을 가장 짧은 시간에 포스팅했던 2012년 11월입니다. 이 글은 11월 달에 마지막으로 포스팅하는 글입니다. 이 글을 통해 모든 엔지니어들이 Secure IP Telephony에 대한 기본적인 이해를 가지길 바라며, Cisco IP Telephony를 사용하는 엔지니어들은 특히 쉽게 설치까지 할 수 있기를 기대합니다.
12월 달에는 남아 있는 글을 마무리짓도록 하겠습니다.
----------------- --------------------------------------------------------
라인하트 (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를 공부하는 사람들이 모인 구글 구룹스)
정리하고 보니 나도 디지털 네이티브 _____________________________________________________
