KR20110098024A

KR20110098024A - Ｓｒｔｐ 암호변환 시스템에서의 미디어 처리 이중화 방법

Info

Publication number: KR20110098024A
Application number: KR1020100017436A
Authority: KR
Inventors: 김종성
Original assignee: (주) 바인젠
Priority date: 2010-02-26
Filing date: 2010-02-26
Publication date: 2011-09-01

Abstract

본 발명에서는 효율적인 SRTP 이중화를 위하여 꼭 필요한 데이터를 정의하고 그 프로시져를 설명한다. B 시스템에서 Session Key Derivation을 미리 적적하게 수행함으로서 절체시 시스템에 한꺼번에 부하가 걸리는 현상을 제거하고, 일시적인 미디어 delay 현상을 극복하는 방법을 설명한다.

Description

ＳＲＴＰ 암호변환 시스템에서의 미디어 처리 이중화 방법{Method for duplexing of media processing in SRTP Crytographic Transform System}

본 발명은 SBC(Session Border Controller) 또는 SRTP(Secure Real-time Transport Protocol) 암호변환 시스템에서의 미디어 처리를 이중화 하는 방법에 관한 것이다.

VoIP에서 미디어 패킷 전송에 사용되는 Real-time Transport Protocol(RTP RFC3550)와 RTCP에 기밀성, 인증 및 Replay Protection에 대한 Profile을 적용한 것을 각각 The Secure Real-time Transport Protocol(SRTP, RFC3711), SRTCP 라고 한다. 이는 최근 SBC(Session Border Controller)나 독립적인Cryptographic Transform System에 RTP 보안 기능으로 구현되어진다.

아래 그림은 행안부 인터넷전화에서의 서비스 형태를 도식화 한 것이다. SBC에서 RTP-RTP 구간간 미디어포워딩, SRTP_AES-SRTP_ARIA간 Media Cryptographic Transformation, SRTP_AES-SRTP_AES, SRTP_ARIA-SRTP_ARIA간 포워딩 서비스의 예를 보여주고 있다.

RFC3550은RTP, RTCP의 패킷 포맷 및 프로세싱 방법 및 그 절차, RFC3711은 SRTP, SRTCP의 패킷 포맷 및 프로세싱 방법 및 절차, RFC4568(Session Description Protocol Security Descriptions for Media Streams)은 양 단간에 SDP를 통한 cryptographic attribute의 공유에 대한 방법을 설명하고 있다. 하지만 한 시스템의 Fail-over에도 미디어 프로세싱 및 보안 처리 서비스를 지속하기 위한 이중화 시스템(HA System)을 구성하기 위한 기술적 방법은 언급하고 있지 않다.

SBC 또는Cryptographic Transform System을 HA(High Available) Mode로 동작하게 하기 위해서는 SRTP Cryptographic Context 데이터를 서로 공유할 필요가 있다. 본 발명에서는 미디어 서비스 이중화를 위해서 꼭 공유해야 할 데이터를 정의하고 효율적인 이중화 방안에 대하여 설명한다. SIP Signaling 처리에 대해서는 다루지 않으며, 미디어 처리를 위한 RTP, SRTP만을 다룬다.

본 발명은 SRTP 암호변환 시스템에서 미디어 처리를 효율적으로 이중화하는 방법을 제공함을 그 목적으로 한다.

SBC 또는 Cryptographic Transform System의 미디어 처리를 이중화하기 위해서 양 시스템은 RFC4568에서 정의하고 있는 Crypto-Suit, Key Parameters, Session Parameters의 값을 동일하게 가져야하며, SRTP Crypto Context를 동일하게 유지하여야 한다. 특히 SRTP에서 RoC(Round of Counter)값을 정확하게 가지고 있지 않으면 A시스템의 절체시 B시스템이 올바르게 SRTP 패킷에 대한 인증 및 복호화를 할 수 없으며, SRTCP에서 index값을 정확히 가지고 있지 않으면 A시스템의 절체시 B시스템에서 올바른 SRTCP 패킷을 생성할 수가 없다.

SRTP Crypto Context에는 여러 데이터들이 포함되는데 패킷 수신 시마다 이 값들이 변하게 되고, 이런 데이터들을 A,B 시스템간 공유하기 위해 Synchronization이 일어난다면, 시스템 및 이중화 채널에 큰 오버헤드를 가져온다.

또한 SRTP에서 정의하는 세션 Key Derivation 작업은 오버헤드가 큰 작업이기 때문에 서비스되고 있는 미디어 세션이 많을 경우, 시스템 절체시 B시스템은 서비스중인 각 세션들의 Key Derivation 작업으로 인해 시스템 과부화 및 미디어 지연 현상이 발생한다. 심지어 시스템이 가용 한계치만큼 동시 세션이 서비스 되고 있을 때 절체가 되면 Key Derivation 오버헤드로 인하여 다소의 서비스가 실패하거나 시스템이 가용 한계치를 초과하는 위험한 상태에 빠질 수 있다.

현재까지 SRTP 패킷을 다루는 SBC 또는 Cryptographic Transform System의 이중화에 필요한 데이터 및 절차를 정의하는 문서는 없는 것으로 보인다. 본 발명은 SRTP 이중화가 필요한 시스템에 있어 효율적/안정적인 벙안을 제시하고 있다.

도 1은 행안부 인터넷 전화에서의 서비스 형태를 도식화한 것이다.

이하에서는 첨부도면을 참조하여 본 발명에 대해 상세히 설명한다.

본 발명에서는,

1. 효율적인 SRTP 이중화를 위하여 꼭 필요한 데이터를 정의하고 그 프로시져를 설명한다.

2. B 시스템에서 Session Key Derivation을 미리 적적하게 수행함으로서 절체시 시스템에 한꺼번에 부하가 걸리는 현상을 제거하고, 일시적인 미디어 delay 현상을 극복하는 방법을 설명한다.

- 기본적 공유해야 할 데이터는 각 Media session에 대한, 세션 구분자(IP/PORT), Crypto Context 중 {encryption/authentication algorithm, master key, master salt, n_e, n_a}, Crypto-Suit, Key Parameters, Session Parameter (RFC4568 6.1, 6.2, 6.3에 기술) 이다.

- Key derivation : Active 장비는 첫 SRTP/SRTCP 패킷을 받았을 경우, 그리고 Key derivation rate에 따라 Session Salt key, Session authentication key, Session encryption key를 생성하게 된다. Active 장비의 fault로 Standby 장비가 Active로 Mode가 바뀔 때 이런 key derivation을 하게 되면 시스템에 큰 부하를 주게되므로, A 장비에서 유지되던 media session이 B장비로의 안정적인 서비스를보장받을 수 없다. 따라서, A,B System간에는 key derivation이 일어날 때마다 아래의 데이터를 공유함으로 standby 장비가Session key를 항상 유지하도록 하며 그것을 위한 공유 데이터는 아래와 같다.

SRTP 일경우 : {세션 구분자, SSRC, RoC, S_l, MKI, MKI length}

SRTCP일 경우 : {세변 구분자, SSRC, SRTCP index, MKI, MKI length}

- RoC, : RTP는 2^16의 sequence number를 가진다. SRTP에서는 2^32의 RoC(Round of Counter)를 가져 총 2^48개의 RTP 데이터를 전송하는 방법을 제공한다. 하지만 SRTP에서는 RoC 및S_l 값를 모르면 2^48까지 가능한 정확한 index 값을 알수 없어, Authentication 및 en/decryption, replay protection 기능을 할 수 없다. 따라서 RFC 3711 index의 determination을 위한 RoC 및 S_ㅣ 값을 정의하고 그 Update 방법을 제공한다. 이 RoC 값은 update가 일어날 때 마다 양 system간 이중화 되어야하며, 그 데이터는 아래와 같다.

{Session 구분자, RoC}

- SRTCP index : RFC3550(RTP)에서 RTCP 패킷 포맷에서는 index 필드가 없다. 하지만 RFC3711의 SRTCP 포맷에서는 2^31의 index 필드가 추가되었다. 이 index값은 SRTCP패패킷이 송수신될 때 마다 이중화 되어야 한다. 그 데이터는 아래와 같다.

{Session 구분자, SRTCP index}

- RFC3711에서는 Replay Protection을 위하여 패킷을 받을때마다 Replay Window를 갱신하고 Replay 유무를 체크하는 방법을 제공한다. 하지만 이 window는 모든 RTP 패킷의 수신때마다 변경되어야 하므로, 이중화를 하기에 너무 큰 오버헤드를 필요로 한다. 하지만 replay window를 유지하지 않아도 서비스에는 전혀 문제가 되지 않는다. 따라서 Replay window의 이중화는 implementation의 고려 사항으로 남겨둔다. 본사의 시스템에서는 Replay window의 이중화는 하지 않는다.

이제까지 본 발명에 대하여 그 바람직한 실시예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

Claims

Active 장비가 첫 SRTP/SRTCP 패킷을 수신한 경우 Key derivation rate에 따라 Session Salt key, Session authentication key, Session encryption key를 생성하는 단계를 포함하는 것으로서,
Active 장비와 Standby 장비간에는
a) SRTP 패킷일 경우에는 {세션 구분자, SSRC, RoC, S_1, MKI, MKI length}
b) SRTCP 패킷일 경우에는 {세션 구분자, SSRC, SRTCP index, MKI, MKI length}
의 데이터를 서로 공유하는 것을 특징으로 하는 미디어 처리 이중화 방법.