SDES
SDES |
미디어 스트림용 Session Description Protocol Security Descriptions(Session Description Protocol Security Descriptions for Media Streams)는 Secure Real-time Transport Protocol의 키를 협상하는 방법이다.2006년 7월에 IETF에 표준화를 위해 제안되었다(RFC 4568 참조).
작동 방식
키는 SIP 메시지의 SDP 첨부 파일로 전송된다.즉, SIP 전송 계층은 다른 사람이 첨부 파일을 볼 수 없도록 해야 한다.이것은 TLS 전송 계층이나 S/MIME과 같은 다른 방법을 사용하여 할 수 있다. TLS를 사용하면 SIP 프록시 체인의 다음 홉을 신뢰할 수 있다고 가정하고, 요청의 보안 요건을 처리할 것이다.
이 방법의 가장 큰 장점은 극히 단순하다는 것이다.키 교환 방법은 일부 벤더가 키 전송을 위해 보안 메커니즘을 사용하지 않더라도 이미 여러 벤더에 의해 픽업되었다.이것은 이 방법을 사실상의 표준으로 만드는 중요한 이행 덩어리를 얻는 데 도움이 된다.
예를 들어 이 원리를 설명하기 위해, 전화는 대리인에게 전화를 보낸다.Sips scheme을 사용함으로써, 통화를 안전하게 해야 함을 나타낸다.키는 SDP 첨부파일로 인코딩된 base-64이다.
INVITE 홀짝거리면서 간간이:*97 @ ietf.org, user=phone SIP/2.0 비아:SIP/2.0/TLS 172.20.25.100:2049년;branch=z9hG4bK-s5kcqq8jqjv3,"123"<>에서:rport, 홀짝거리면서 간간이:123@ ietf.org><>:려면 tag=mogkxsrhm4, 홀짝거리면서 간간이:*97 @ ietf.org, user=phone>, Call-ID:3c269247a122-f0ee6wcrvkcqsnom360-000413230A07 CSeq @:1INVITEMax-Forwards:70접촉:<>.172.20.25.100 @ 입:123:2049년;transport=tls, line=gyhiepdm>reg-id=1 User-Agent: snom360/6.2.2 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO Allow-Events: talk, hold, refer Supported: timer, 100rel, replaces, callerid Session-Expires: 3600;refresher=uas Min-SE: 90 Content-Type: application/sdp Content-Length: 477 v=0 o=root 2071608643 2071608643 IN IP4 172.20.25.100 s=c=in IP4 172.20.25.100 t=0 0 m=오디오 57676 RTP/SAVP 0 8 9 2 3 18 4 101 a=crypto:1 AES_CM_128_을 호출한다.HMAC_SHA1_32 인라인:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=encryption:optional a=sendrecv
전화는 프록시로부터 응답을 수신하고 이제 양방향 보안 통화를 할 수 있다.
SIP/2.0 200 좋아 비아:SIP/2.0/TLS 172.20.25.100:2049년;branch=z9hG4bK-s5kcqq8jqjv3, rport=62401,"123"<>에서:received=66.31.106.96, 홀짝거리면서 간간이:123@ ietf.org><>:려면 tag=mogkxsrhm4, 홀짝거리면서 간간이:*97 @ ietf.org, user=phone>tag=237592673 Call-ID:3c269247a122-f0ee6wcrvkcqsnom360-000413230A07 CSeq @:1INVITE연락처:<>입:203.43.12.32 @ *97:5061, transport=tls>. S.:100rel upported,replaces Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PRACK, INFO Accept: application/sdp User-Agent: pbxnsip-PBX/1.5.1 Content-Type: application/sdp Content-Length: 298 v=0 o=- 1996782469 1996782469 IN IP4 203.43.12.32 s=- c=IN IP4 203.43.12.32 t=0 0 m=audio 57076 RTP/SAVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 a=crypto:1 AES_CM_128_HMAC_SHA1_32 인라인:bmt4MizMydnFyaWM3d282dGR5Z3g0c2k5Yx a=ptime:20 a=sendrecv
토론: 통화 시작 및 엔드 투 엔드 암호화 누락
보안 미디어의 일반적인 문제는 첫 번째 미디어 패킷이 도착할 때 키 교환이 완료되지 않을 수 있다는 것이다.처음 클릭을 피하기 위해 이러한 패킷은 삭제되어야 한다.보통 이것은 단기간(100ms 이하)에 불과하므로, 이것은 큰 문제가 되지 않는다.
SDES 방법은 "end-to-end" 미디어 암호화를 다루지 않는다.예를 들어 사용자 A가 프록시 P를 통해 사용자 B와 대화하는 경우 SDES는 A와 P 사이 또는 B와 P 사이의 키 협상을 허용하지만 A와 B 사이의 키 협상을 허용하지는 않는다.엔드 투 엔드 미디어 보안을 위해 먼저 상대방과 신뢰 관계를 설정해야 한다.이를 위해 신뢰할 수 있는 중간기기를 사용하면 통화 설정 지연이 크게 늘어나 푸시투토크 같은 애플리케이션이 어려워진다.이 피어 투 피어(Peer-to-peer)를 하면 상대편을 식별하기 어려울 수 있다.예를 들어, 운영자가 B2B를 구현할 수 있음UA 아키텍처 및 상대편의 역할을 수행하므로 여전히 엔드 투 엔드 보안이 유지되지 않음ZRTP와 같은 최신 프로토콜은 SIP/RTP 호출을 위한 엔드 투 엔드 암호화를 제공한다.
