SDES
SDES ( Session Description Protocol Security Descriptions ) för mediaströmmar är ett sätt att förhandla fram nyckeln till Secure Real-time Transport Protocol. Det har föreslagits för standardisering till IETF i juli 2006 (se RFC khh.)
Hur det fungerar
Nycklarna transporteras i SDP- bilagan till ett SIP -meddelande. Det betyder att SIP-transportlagret måste se till att ingen annan kan se bilagan. Detta kan göras genom att använda TLS transportlager eller andra metoder som S/MIME. Att använda TLS förutsätter att nästa hopp i SIP-proxykedjan kan litas på och det kommer att ta hand om säkerhetskraven för begäran.
Den största fördelen med denna metod är att den är extremt enkel. Nyckelbytesmetoden har redan plockats upp av flera leverantörer, även om vissa leverantörer inte använder en säker mekanism för att transportera nyckeln. Detta hjälper till att få den kritiska massan av implementering för att göra denna metod till de facto standard.
För att illustrera denna princip med ett exempel skickar telefonen ett samtal till proxyn. Genom att använda sips-schemat indikerar det att samtalet måste göras säkert. Nyckeln är base-64-kodad i SDP-tillbehöret.
INVITE sips:*[email protected];user=phone SIP/2.0 Via: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport Från: "123"@ sips:12 > ;tag=mogkxsrhm4 Till: < sips:*[email protected];user=phone > Call-ID: 3c269247a122-f0ee6wcrvkcq@snom360-000413230A07 CSeq: 1 INVITE Max-Forward.20s: 7p 0 :2049;transport=tls;line=gyhiepdm >;reg-id=1 User-Agent: snom360/6.2.2 Acceptera: application/sdp Tillåt: BJUD IN, ACK, AVBRYT, BYE, REFER, ALTERNATIV, MEDDELA, PRENUMERERA, PRACK , MEDDELANDE, INFO Tillåt-Händelser: prata, håll, referera Stöds: timer, 100rel, ersätter, callerid Session-Utlöper: 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=ring c=IN IP4 172.20.25.100 t=0 0 m=ljud 57676 RTP/SAVP 0 3 8 1 2 CM_4 1 8 1 1 2 CM 8_HMAC_SHA1_32 inline:WbTBosdVUZqEb6Htqhn+ m3z7wUh4RJVR8nE15GbN a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:9 g722/8000 a=rtpmap:2 g726-32/8000 a=rtp800map:3 gs201 a=rtp800map:p801 8000 a=rtpmap:4 g723/8000 a=rtpmap:101 phone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=kryptering:valfritt a=sendrecv
Telefonen får svaret från proxyn och nu kan det bli ett tvåvägs säkert samtal:
SIP/2.0 200 Ok Via: SIP/2.0/TLS 172.20.25.100:2049;branch=z9hG4bK-s5kcqq8jqjv3;rport=62401;received=66.31.106.936 Från : 1f2tag mogkxsrhm4 Till: < sips:*[email protected];user=phone >;tag=237592673 Call-ID: 3c269247a122-f0ee6wcrvkcq@snom360-000413230A07 CSeq: 7 CSeq: 7.2 INVITE: 7.2 INVITE: 7.2 5061; transport=tls > Stöds: 100rel, ersätter Allow-Events: se Tillåt: BJUD IN, ACK, CANCEL, BYE, REFER, OPTIONS, PRACK, INFO Acceptera: application/sdp User-Agent: pbxnsip-PBX/1.5.1 Content-Type : applikation/sdp Innehåll-Längd: 298 v=0 o=- 1996782469 1996782469 IN IP4 203.43.12.32 s=- c=IN IP4 203.43.12.32 t=0 0 m=ljud 0 RTP/10107 m pcmu/8000 a=rtpmap:101 phone-event/8000 a=fmtp:101 0-11 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:bmt4MzIzMmYxdnFyaWM3d282dGR5Z3g3Yx a=p5Mtime:c2 a
Diskussion: samtalsinitiering och saknad end-to-end-kryptering
Ett vanligt problem med säker media är att nyckelutbytet kanske inte är avslutat när det första mediepaketet anländer. För att undvika första klick måste dessa paket släppas. Vanligtvis är detta bara en kort tidsperiod (under 100 ms), så detta är inget större problem.
SDES-metoden adresserar inte "end-to-end" mediakrypteringen. Till exempel, om användare A pratar med användare B via en proxy P, tillåter SDES förhandling av nycklar mellan A och P eller mellan B och P, men inte mellan A och B. För end-to-end mediasäkerhet måste du först upprätta ett förtroendeförhållande med den andra sidan. Om du använder en pålitlig mellanhand för detta kommer samtalsfördröjningen att öka avsevärt, vilket gör applikationer som push-to-talk svåra. Om du gör detta peer-to-peer kan det vara svårt för dig att identifiera den andra sidan. Till exempel kan din operatör implementera en B2BUA-arkitektur och spela rollen som den andra sidan, så att du fortfarande inte har end-to-end-säkerhet. Nyare, moderna protokoll, som ZRTP , erbjuder end-to-end-kryptering för SIP/RTP-samtal.
Se även
- MIKEY nyckelbytesmetod
- ZRTP- nyckelutbytesförslag från början till slut
- DTLS-SRTP end-to-end nyckelutbyte IETF-standard