SDES är en akronym för Session Description Protocol Security Descriptions, som kan översättas till SDP Security Descriptors for Streaming, en av nyckelutbytesmetoderna för Secure Real-time Transport SRTP-protokollet . Den standardiserades av Internet Engineering Task Force ( IETF ) i juli 2006 som RFC 4568 Arkiverad 24 januari 2009 på Wayback Machine .
För att överföra nycklar används SDP- protokollbilagor i SIP - Invite-meddelanden. Detta förutsätter SIP-bärarens integritet , vilket bör säkerställa att bilagan inte är tillgänglig för en trolig man i mitten . Detta kan uppnås med hjälp av TLS- transport eller någon annan metod som S/MIME . Användningen av TLS förutsätter att nästa hopp i SIP -proxykedjan kan litas på och detta kommer att uppfylla säkerhetskraven för inbjudningsförfrågan. Fördelen med denna metod är att den är extremt enkel att implementera. Denna metod har redan implementerats av flera utvecklare. Även om vissa utvecklare inte använder en tillräckligt säker nyckelutbytesmekanism, hjälper det verkligen att använda denna metod som en de facto-standard i de flesta applikationer.
Låt oss illustrera denna princip med ett exempel där telefonen skickar en samtalsförfrågan till en SIP -proxyserver. Formatet för SIP Invite- förfrågan anger uttryckligen att det efterföljande samtalet ska göras som säkert. Krypteringsnyckeln är base-64- kodad som en SDP - bilaga :
INVIT sips :[email protected];user=phone SIP/2.0 Via: SIP/2.0/TLS 10.20.30.40:1055;branch=z9hG4bK-s5kcqq8jqjv3;rport Från: "222" < sips:[email protected] >;tag=mogkxsrhm4 Till: < sips:[email protected];user=phone > Call-ID: 3c269247a122-f0ee6wcrvkcq@CSCO79XX-000129287FC1 CSeq: 1 INBJUDNING Max forwards: 70 Kontakt: < sip:[email protected]:1055;transport=tls;line=demoline >;reg-id=1 Användaragent: CSCO79XX/8.3.2 Acceptera: ansökan/sdp Tillåt: BJUD IN, ACK, CANCEL, BYE, REFER, ALTERNATIV, MEDDELA, PRENUMERERA, PRACK, MEDDELANDE, INFO Tillåt-händelser: prata, håll, hänvisa Stöds: timer, 100rel, ersätter, callerid Session-Expires: 3600;refresher=uas Min SE: 90 Innehållstyp: applikation/sdp Innehållslängd: 477 v=0 o=root 2071608643 2071608643 IN IP4 10.20.30.40 s=samtal c=IN IP4 10.20.30.40 t=0 0 m=ljud 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 telefon-event/8000 a=fmtp:101 0-16 a=ptime:20 a=kryptering:valfritt a=sendrecvTelefonen får ett svar från proxyservern och med hjälp av mottagna data kan den på så sätt organisera en dubbelriktad (Tx / Rx) krypterad anslutning:
SIP/2.0 200 Ok Via: SIP/2.0/TLS 10.20.30.40:1055;branch=z9hG4bK-s5kcqq8jqjv3;rport=62401;received=66.31.106.96 Från: "222" < sips:[email protected] >;tag=mogkxsrhm4 Till: < sips:[email protected];user=phone >;tag=123456789 Call-ID: 3c269247a122-f0ee6wcrvkcq@CSCO79XX-000413230A07 CSeq: 1 INBJUDNING Kontakt: < sip:[email protected]:5061;transport=tls > Stöds: 100rel, ersätter Tillåt-Event: se Tillåt: BJUD IN, ACK, CANCEL, BYE, REFER, OPTIONS, PRACK, INFO Acceptera: ansökan/sdp Användaragent: Asterisk/1.4.21-1 Innehållstyp: applikation/sdp Innehållslängd: 298 v=0 o=- 349587934875 349587934875 IN IP4 10.0.0.1 s=- c=IN IP4 10.0.0.1 t=0 0 m=ljud 57076 RTP/AVP 0 101 a=rtpmap:0pcmu/8000 a=rtpmap:101 telefon-event/8000 a=fmtp:101 0-11 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:bmt4MzIzMmYxdnFyaWM3d282dGR5Z3g0c2k5M3Yx a=ptime:20 a=sendrecvDet allmänna säkerhetsproblemet är att nyckelutbytet måste ske innan det första mediapaketet kommer för att kunna kryptera samma mediapaket med nycklarna. För att undvika irriterande klick i början bör de första mediepaketen ignoreras. Detta är vanligtvis en mycket kort tidsperiod (mindre än 100 millisekunder), så detta är inget problem.
SDES-metoden tillhandahåller inte end-to-end mediakryptering. Det kan dock diskuteras hur realistiskt detta krav är. Å ena sidan vill legitima brottsbekämpande myndigheter ha tillgång till innehållet i telefonsamtal. Å andra sidan kan många andra parametrar - IP-adresser, portnummer, STUN- lösenord - kräva skydd mot DoS-attacker .
Dessutom, för fullständig mediesäkerhet från-till-och-till, måste du först upprätta en direkt förtroenderelation med den andra parten (abonnenten). Om du använder en infrastruktur för nyckelutbyte med en certifikatutfärdare som mellanliggande, så finns det en fördröjning varje gång en anslutning upprättas, där varje part måste autentisera sin nyckel i en sådan auktoritet, vilket skapar ytterligare svårigheter för att starta en konversation. Om en peer-to-peer-anslutning används blir det svårt att identifiera den andra parten. Till exempel utvecklar operatören B2BUA- arkitekturen och abonnenter tvingas inte ansluta direkt, utan via IP-PBX . I det här fallet ökar möjligheten för "närvaro" av en man i mitten , och man kan inte tala om fullständig säkerhet.