SDES je akronym pro popis zabezpečení protokolu relace, který lze přeložit jako popisovače zabezpečení SDP pro streamování, jednu z klíčových metod výměny protokolu SRTP Secure Real-time Transport . To bylo standardizováno Internet Engineering Task Force ( IETF ) v červenci 2006 jako RFC 4568 Archived 24. ledna 2009 na Wayback Machine .
K přenosu klíčů se ve zprávách SIP - Invite používají přílohy protokolu SDP . To předpokládá soukromí nositele SIP , což by mělo zajistit, že připojení nebude přístupné pravděpodobnému muži uprostřed . Toho lze dosáhnout pomocí přenosu TLS nebo jiné metody, jako je S/MIME . Použití TLS předpokládá, že dalšímu skoku v řetězci SIP proxy lze důvěřovat a to splní bezpečnostní požadavky požadavku Invite. Výhodou této metody je velmi snadná implementace. Tuto metodu již implementovalo několik vývojářů. I když někteří vývojáři nepoužívají dostatečně bezpečný mechanismus výměny klíčů, opravdu pomáhá používat tuto metodu jako de facto standard ve většině aplikací.
Ukažme si tento princip na příkladu, kdy telefon odešle požadavek na volání na SIP proxy server. Formát požadavku SIP Invite výslovně uvádí, že následující hovor má být uskutečněn jako zabezpečený. Šifrovací klíč je zakódován na bázi 64 jako příloha SDP :
INVITE sips:[email protected];user=phone SIP/2.0 Přes: SIP/2.0/TLS 10.20.30.40:1055;branch=z9hG4bK-s5kcqq8jqjv3;rport From: "222" < sips:[email protected] >;tag=mogkxsrhm4 Komu: < sips:[email protected];user=phone > Call-ID: 3c269247a122-f0ee6wcrvkcq@CSCO79XX-000129287FC1 CSeq: 1 POZVÁNKA Maximální počet vpřed: 70 Kontakt: < sip:[email protected]:1055;transport=tls;line=demoline >;reg-id=1 User-Agent: CSCO79XX/8.3.2 Přijmout: aplikace/sdp Povolit: POZVAT, POKRAČOVAT, ZRUŠIT, BYE, REFEROVAT, MOŽNOSTI, OZNÁMIT, ODBĚROVAT, PRACK, ZPRÁVU, INFO Povolit události: mluvit, držet, odkazovat Podporované: časovač, 100rel, nahrazuje, callerid Platnost relace: 3600;refresher=uas Min SE: 90 Typ obsahu: aplikace/sdp Délka obsahu: 477 v=0 o=root 2071608643 2071608643 IN IP4 10.20.30.40 s=volání c=IN IP4 10.20.30.40 t=00 m=audio 42501 RTP/AVP 0 8 9 18 4 101 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+m3z7wUh4RJVR8nE15GbN a=rtpmap:0pcmu/8000 a=rtpmap:8pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telefonní událost/8000 a=fmtp:101 0-16 a=ptime:20 a=šifrování:nepovinné a=sendrecvTelefon obdrží odpověď od proxy serveru a pomocí přijatých dat tak může organizovat obousměrné (Tx / Rx) šifrované spojení:
SIP/2.0 200 Ok Přes: SIP/2.0/TLS 10.20.30.40:1055;větev=z9hG4bK-s5kcqq8jqjv3;rport=62401;přijato=66.31.106.96 From: "222" < sips:[email protected] >;tag=mogkxsrhm4 Komu: < sips:[email protected];user=phone >;tag=123456789 Call-ID: 3c269247a122-f0ee6wcrvkcq@CSCO79XX-000413230A07 CSeq: 1 POZVÁNKA Kontakt: < sip:[email protected]:5061;transport=tls > Podporováno: 100 rel, nahrazuje Povolit události: viz Povolit: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PRACK, INFO Přijmout: aplikace/sdp User Agent: Asterisk/1.4.21-1 Typ obsahu: aplikace/sdp Délka obsahu: 298 v=0 o=- 349587934875 349587934875 IN IP4 10.0.0.1 s=- c=IN IP4 10.0.0.1 t=00 m=audio 57076 RTP/AVP 0 101 a=rtpmap:0pcmu/8000 a=rtpmap:101 telefonní událost/8000 a=fmtp:101 0-11 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:bmt4MzIzMmYxdnFyaWM3d282dGR5Z3g0c2k5M3Yx a=ptime:20 a=sendrecvObecným bezpečnostním problémem je, že výměna klíčů musí proběhnout před příchodem prvního mediálního paketu, aby bylo možné zašifrovat stejné mediální pakety pomocí klíčů. Aby se předešlo nepříjemnému klikání na začátku, první pakety médií by měly být ignorovány. Obvykle se jedná o velmi krátký časový úsek (méně než 100 milisekund), takže to není problém.
Metoda SDES neposkytuje end-to-end šifrování médií. Je však diskutabilní, nakolik je tento požadavek reálný. Na jedné straně chtějí mít legitimní orgány činné v trestním řízení přístup k obsahu telefonických rozhovorů. Na druhou stranu mnoho dalších parametrů – IP adresy, čísla portů, STUN hesla – může vyžadovat ochranu před DoS útoky .
Navíc pro úplné zabezpečení médií od-do-do musíte nejprve vytvořit přímý vztah důvěry s druhou stranou (předplatitelem). Pokud používáte infrastrukturu pro výměnu klíčů s certifikační autoritou jako prostředníkem, dojde při každém navázání spojení ke zpoždění, ve kterém každá strana musí ověřit svůj klíč v takové autoritě, což vytváří další potíže se zahájením konverzace. Pokud je použito připojení peer-to-peer , je obtížné identifikovat druhou stranu. Operátor například vyvíjí architekturu B2BUA a účastníci jsou nuceni se připojovat nikoli přímo, ale prostřednictvím IP-PBX . V tomto případě se zvyšuje možnost „přítomnosti“ Muže_uprostřed a nelze hovořit o úplné bezpečnosti.