Nexpert SIP - Security

Overview

원문은 이곳<ref>https://www.nexpert.net/276</ref>에서 확인이 가능하다.

다양한 SIP 보안 방법

SIP 에서 제공하는 보안을 위한 방법들은 다음과 같다.

• Digest Authentication (발신자 인증)

같은 도메인 내에서 적용되어 발신자를 인증하기 위해 사용하는 방식으로 가장 많이 사용한다. HTTP에서 사용되는 인증방식으로 재사용 공격 방지와 인증을 제공한다.

• TLS/IPSec

Hop by Hop 또는 End-to-End 로 Signalling 에 대한 기밀성과 무결성을 보장한다.

• S/MIME(Secure / Multipurpose Internet Mail Extension)

SIP 메시지 바디는 MIME으로 구성되어 있으며, 이 메시지를 암호화하여 기밀성 및 무결성을 제공한다.

• Network Asserted Identity(NAI)

같은 도메인 내의 사용자를 식별한다.

• SIP Identity

NAI 가 같은 도메인 내에서 발신측을 식별하였다면, SIP Identity 는 도메인과 도메인같에 발신측을 인증한다.

• SIP Privacy

외부 도메인에 대해 메시지의 특정 부분을 보호한다.

SIP Digest Authentication

SIP Digest은 INVITE, REGISTER 등과 같은 요청에 대해 서버는 NONCE 라고 하는 난수 물자열을 생성하여 전송한다. UAC는 사용자 이름, 암호 및 NONCE 를 포함하는 MD5 Hash 로 응답한다. 주고 받는 메시지 내에서 사용자 이름과 암호를 확인하기 어렵기 때문에 발신자에 대한 인증과 재사용(Replay) 공격을 방지할 수 있다. 이 인증 방법은 HTTP Digest Authentication 을 기반으로 하여 RFC 2617 에 자세히 나와 있다. 여기서, 사용자 이름과 암호는 고유하며, 쌍방간에 사전에 교환되었음을 가정한다. 따라서, 신뢰할 수 있는 도메인 내에서만 사용되는 것이다.

UAC -> Proxy
INVITE sip:9999999999@test.sip.pchero21.com;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.100.10:52049;branch=z9hG4bK-524287-1---e188803aa3bf9d83;rport
Max-Forwards: 70
Contact: <sip:test@192.168.100.10:52049;transport=UDP>
To: <sip:9999999999@test.sip.pchero21.com;transport=UDP>
From: <sip:test@test.sip.pchero21.com;transport=UDP>;tag=df29ba2b
Call-ID: io3Rq9OC_jPd0C5q8copaA..
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
User-Agent: Z 5.2.28 rv2.8.115
Allow-Events: presence, kpml, talk
Content-Length: 655
<UAC's SDP not shown>


Proxy -> UAC
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.100.10:52049;branch=z9hG4bK-524287-1---e188803aa3bf9d83;rport=52049;received=192.168.100.10
To: <sip:9999999999@test.sip.pchero21.com;transport=UDP>;tag=883012262b7bb76abb1fc00203c3e0e7.a390
From: <sip:test@test.sip.pchero21.com;transport=UDP>;tag=df29ba2b
Call-ID: io3Rq9OC_jPd0C5q8copaA..
CSeq: 1 INVITE
Proxy-Authenticate: Digest realm="test.sip.pchero21.com", nonce="XfH7cF3x+kQNger90ldf+Spo5nmM4L66"
Content-Length: 0

UAC -> Proxy
ACK sip:9999999999@test.sip.pchero21.com;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.100.10:52049;branch=z9hG4bK-524287-1---e188803aa3bf9d83;rport
Max-Forwards: 70
To: <sip:9999999999@test.sip.pchero21.com;transport=UDP>;tag=883012262b7bb76abb1fc00203c3e0e7.a390
From: <sip:test@test.sip.pchero21.com;transport=UDP>;tag=df29ba2b
Call-ID: io3Rq9OC_jPd0C5q8copaA..
CSeq: 1 ACK
Content-Length: 0

UAC의 INVITE를 받은 SIP Proxy 서버는 407 Proxy Auth Req 에러 메시지를 전송한다. 만일 SIP Redirect 나 Registra Server 라면, 401 Unauthorised 라는 에러 메시지를 전송한다. 여기서 Proxy-Authenticate 헤더는 인증에 필요한 정보를 포함하여 INVITE 를 재전송할 것을 요구하는 것이다.

Proxy-Authenticate: Digest realm="test.sip.pchero21.com", nonce="XfH7cF3x+kQNger90ldf+Spo5nmM4L66"

복잡한 내용이지만 모든것을 알아야 할 필요는 없다. realm 파라미터는 도메인 네임을 의미하며, qop="auth" 파라미터는 사용자 인증 요청을 의미한다. nonce 는 시간을 기반으로 만들어진 문자 난수열이며, MD5 로 해쉬되어 있다.

UAC -> Proxy
INVITE sip:9999999999@test.sip.pchero21.com;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.100.10:52049;branch=z9hG4bK-524287-1---e98fbd655da0654f;rport
Max-Forwards: 70
Contact: <sip:test@192.168.100.10:52049;transport=UDP>
To: <sip:9999999999@test.sip.pchero21.com;transport=UDP>
From: <sip:test@test.sip.pchero21.com;transport=UDP>;tag=df29ba2b
Call-ID: io3Rq9OC_jPd0C5q8copaA..
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
Proxy-Authorization: Digest username="test",realm="test.sip.pchero21.com",nonce="XfH7cF3x+kQNger90ldf+Spo5nmM4L66",uri="sip:9999999999@test.sip.pchero21.com;transport=UDP",response="c1e14f
3ebc88eebc094e308ba5c278",algorithm=MD5
User-Agent: Z 5.2.28 rv2.8.115
Allow-Events: presence, kpml, talk
Content-Length: 655
<UAC's SDP not shown>

407 Proxy Quth Req 에러 메시지를 받은 UAC 는 Authorization/Proxy-Authorization 헤더를 포함하여 INVITE를 재전송하며, 수신한 SIP Proxy 서버는 INVITE 를 보낸 발신자가 인증된 UAC 가 맞다는 것을 확인하는 것이다.

만일 2 개의 SIP Proxy 를 거치는 경우의 Digest 인즌은 다음과 같은 호 흐름을 사용한다.

SIPS(TLS): Hop-by-Hop Security

SIP Proxy 서버가 SIP Message를 추가 변경 삭제가 가능할 뿐만 아니라 항상 메시지 내용을 확인해야 하기 때문에 Alice 와 Bob 간의 End-to-End 로 암호화를 하는 것이 어렵다. 그래서, Hop-by-Hop 으로 처리될 수 밖에 없다.

아래 그림에서처럼 Alice 의 전화기와 Proxy 1 간에 TLS 를 이용하여 암호화를 수행하고, 복호화한 후에 다시 암호화하여 Proxy 2 로 전송하는 과정을 반복해야 한다.

TLS 는 Transport Layer Security 의 약자이며, 두 통신 시스템간의 데이터 무결성과 기밀성을 제공한다. TLS를 활용한 SIPS 는 다음과 같은 몇 가지 특징이 있다.

• TLS 를 TCP 와 같은 신뢰할 수 있는 전송 프로토콜 위에서 동작한다.
• 데이터 암호화를 위해 DES 와 같은 Symmetric 암호화를 사용한다.
• 암호화 키는 connection 마다 유일하다.
• MD5나 SHA 해쉬로 메시지 무결성을 나타낸다.
• 서버와 클라이언트간에 상호 인증을 수행한다.
• TLS 는 AES@128 bit 를 사용해야 한다.

S/MIME

S/MIME는 SDP를 암호화하거나 SIP 전체 미시지에 대한 서명, 무결성을 제공할 수 있다. 아래 그림은 Alice 가 Bob 에게 INVITE 를 보내는 과정을 나타낸 것이며, SDP 부분이 암호화 되어 있다.

위 SIP 메시지 중에 Content-Type 헤더의 application/pkcs7-mime 이라는 파라미터는 S/MIME 임을 가리킨다. S/MIME는 SHA1 인증과 3 DES 암호화 알고리즘을 사용한다. S/MIME 는 SDP 가 암호화되어 End-to-End 간 즉, Alice 와 Bob 만이 이해할 수 있다. 따라서, 중간에서 SDP 메시지를 이해해야 하는 서비스 즉, Redirect 또는 Forking 과 같은 서비스를 같이 사용할 수 없는 것이 단점이다.

Network Asserted Identity/Privacy (Trusted)

도메인 내에서 Digest 가 사용자를 인증한다면, NAI 는 사용자 식별을 위해 사용되는 매커니즘이다. 둘다 비슷하지만 구체적으로는 약간의 차이가 있다.

위의 그림은 Alice 가 Audrey 에게 INVITE 를 전송하는 과정이다. 즉, UAC 가 보내는 INVITE 메시지이다. 내용을 간단히 살펴보면, From 헤더는 anonymous 로 표시되고, P-Preferred-Identity 헤더에 사용자 정보가 포함된다.

Privacy 헤더는 "none"으로 표시되어 P-Asserted-Identity 가 있던 없던 상관하지 않겠다는 의미이다.

여기서 From 헤더가 anonymous 로 표시된 것은 P-Preferred-Identity 가 우선적으로 사용되기 때문이다.

• P-Asserted-Identity(PAI)

이 헤더는 신뢰할 수 있는 SIP Entity 사이에 사용되며, SIP message 를 보내는 사용자를 확인한다. 이 헤더는 From 헤더와 달리 다른 값으로 변경이 불가능하며 우선순위가 더 높아 From 의 값보다는 PAI 값을 사용한다. 서버 측에서 인증하고 생성하는 P-Asserted-Identity 가 과금 정보에 주로 사용된다.

• P-Preferred-Identity(PPI)

이 헤더는 신뢰할 수 있는 도메인 내에서 UAC가 선호하는 URI 를 지정한다. 즉, UAC가 신뢰할 수 있는 Proxy Server 에게 SIP Message 를 보내는 자신의 정확한 ID 를 명기하는 것이다.

• Privacy

Privacy에 "id"가 있으면, 신뢰할 수 없는 곳으로 SIP Message를 전달할 때, P-Asserted-Identity Header를 삭제하고 전달해야 하며, "none"으로 표시되어 있으면 삭제하지 않고 전달한다. 만일, Privacy 헤더가 없다면, P-Asserted-Identity 헤더의 추가 또는 삭제를 마음대로 할 수 있다.

아래 그림은 SIP Proxy 서버가 407 에러를 전송하여 Digest 인증을 요청하는 그림이다.

재전송되는 INVITE 메시지를 보면 "INVITE sips:audrey@atlanta.com SIP/2.0"로 변경되어 SIPS URI 를 사용하며, TLS 또는 IPSec이 사용된다는 것을 알 수 있다. 위의 메시지에서 Privacy 헤더의 파라미터가 "none" 에서 "id"로 변경되었다. 즉, Proxy Server 에게 신뢰할 수 없는 곳으로는 P-Asserted-Identity 를 전송하지 말라고 요청하는 것이다.

Digest 인증을 통해 SIP Proxy 서버는 Alice 를 인증하였으며, Audrey 는 같은 도메인내에 존재하는 신뢰할 수 있는 사용자이므로 P-Asserted-Identity 를 출가하여 INVITE Message 를 전송한다.

지금까지 NAI(Network Asserted Identity)의 매커니즘을 살펴보았으며, RFC 3325 Private Extensions to the SIP for Asserted Identity within Trusted Netowrks 에 자세히 나와있다. RFC 3325 의 내용을 간략히 정리하면 다음과 같다.

• NAI는 신뢰할 수 있는 SIP 서버 네트워크가 인증된 사용자들을 식별해주며, 그들간에 프라이버시를 형성할 수 있도록 해준다.
• SIP Server가 P-Asserted 헤더를 가진 신뢰할 수 있는 Entity 로부터 SIP 메시지를 받는다면, 새로운 Digest 인증과정을 거치는 대신에 인증목적으로 이 필드를 사용할 수도 있다.
• SIP Server 가 신뢰할 수 없는 곳으로 이 메시지를 전송할 때 PAI 헤더를 제거한다면, Privacy 헤더 값은 "id"로 설정된다.
• UAS 가 PAI 헤더를 포함한 메시지를 받는다면, From 헤더보다 더 신뢰한다. 그래서 일반적으로 From 헤더를 <anonymous>로 설정한다.

See also

• https://www.nexpert.net/276

References

<references />