Az SDES a Session Description Protocol Security Descriptions (Session Description Protocol Security Descriptions) mozaikszó, amely SDP Security Descriptors for Streaming névre fordítható, amely a Secure Real-time Transport SRTP protokoll egyik kulcsfontosságú cseremódszere . Az Internet Engineering Task Force ( IETF ) szabványosította 2006 júliusában RFC 4568 néven. Archiválva 2009. január 24-én a Wayback Machine -nél .
A kulcsok átviteléhez SDP -protokoll-mellékleteket használnak a SIP - Invite messages. Ez feltételezi a SIP hordozó adatvédelmét , aminek biztosítania kell, hogy a csatolmány ne legyen elérhető egy középen álló személy számára . Ez elérhető TLS szállítással vagy más módszerrel, például S/MIME -vel . A TLS használata feltételezi, hogy a SIP proxylánc következő ugrása megbízható, és ez megfelel a Meghívás kérés biztonsági követelményeinek. Ennek a módszernek az az előnye, hogy rendkívül könnyen kivitelezhető. Ezt a módszert már több fejlesztő is megvalósította. Annak ellenére, hogy egyes fejlesztők nem használnak kellően biztonságos kulcscsere-mechanizmust, valóban segít, ha ezt a módszert de facto szabványként használják a legtöbb alkalmazásban.
Illusztráljuk ezt az elvet egy példával, ahol a telefon híváskérést küld egy SIP proxy szervernek. A SIP Invite kérés formátuma kifejezetten kimondja, hogy a következő hívást biztonságosnak kell végrehajtani. A titkosítási kulcs base-64 kódolású SDP - mellékletként :
INVITE sips:[email protected];user=phone SIP/2.0 Via: SIP/2.0/TLS 10.20.30.40:1055;branch=z9hG4bK-s5kcqq8jqjv3;rport Feladó: "222" < sips:[email protected] >;tag=mogkxsrhm4 Címzett: < sips:[email protected];user=phone > Hívásazonosító: 3c269247a122-f0ee6wcrvkcq@CSCO79XX-000129287FC1 CSeq: 1 MEGHÍVÁS Max előre: 70 Kapcsolatfelvétel: < sip:[email protected]:1055;transport=tls;line=demoline >;reg-id=1 User-Agent: CSCO79XX/8.3.2 Elfogadás: application/sdp Engedélyezés: MEGHÍVÁS, VISSZA, VISSZA, HÍVÁS, OPCIÓK, ÉRTESÍTÉS, ELŐFIZETÉS, PRACK, ÜZENET, INFORMÁCIÓ Események engedélyezése: beszéljen, tartson, utaljon Támogatott: időzítő, 100rel, csere, hívóazonosító Session-Expires: 3600;refresher=uas Min. DK: 90 Tartalom típusa: Application/sdp Tartalom hossza: 477 v=0 o=gyökér 2071608643 2071608643 IN IP4 10.20.30.40 s=hívás c=IN IP4 10.20.30.40 t=0 0 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 phone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=titkosítás:nem kötelező a=sendrecvA telefon választ kap a proxy szervertől, és a kapott adatok felhasználásával kétirányú (Tx / Rx) titkosított kapcsolatot tud szervezni:
SIP/2.0 200 Rendben Via: SIP/2.0/TLS 10.20.30.40:1055;ág=z9hG4bK-s5kcqq8jqjv3;rport=62401;fogadott=66.31.106.96 Feladó: "222" < sips:[email protected] >;tag=mogkxsrhm4 Címzett: < sips:[email protected];user=phone >;tag=123456789 Hívásazonosító: 3c269247a122-f0ee6wcrvkcq@CSCO79XX-000413230A07 CSeq: 1 MEGHÍVÁS Kapcsolatfelvétel: < sip:[email protected]:5061;transport=tls > Támogatott: 100rel, helyettesíti Események engedélyezése: lásd Engedélyezés: MEGHÍVÁS, NYÚJTÁS, MÉGSEM, BYE, REFER, OPTIONS, PRACK, INFO Elfogadás: application/sdp Felhasználói ügynök: Asterisk/1.4.21-1 Tartalom típusa: Application/sdp Tartalom hossza: 298 v=0 o=- 349587934875 349587934875 IN IP4 10.0.0.1 s=- c=IN IP4 10.0.0.1 t=0 0 m = audio 57076 RTP/AVP 0 101 a=rtpmap:0pcmu/8000 a=rtpmap:101 phone-event/8000 a=fmtp:101 0-11 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:bmt4MzIzMmYxdnFyaWM3d282dGR5Z3g0c2k5M3Yx a=ptime:20 a=sendrecvAz általános biztonsági probléma az, hogy a kulcscserének az első médiacsomag megérkezése előtt meg kell történnie, hogy ugyanazokat a médiacsomagokat titkosíthassuk a kulcsokkal. A bosszantó kattintások elkerülése érdekében az első médiacsomagokat figyelmen kívül kell hagyni. Ez általában nagyon rövid idő (kevesebb, mint 100 ezredmásodperc), így ez nem jelent problémát.
Az SDES módszer nem biztosít végpontok közötti adathordozó titkosítást. Az azonban vitatható, hogy ez a követelmény mennyire reális. Egyrészt a törvényes rendvédelmi szervek hozzá akarnak férni a telefonbeszélgetések tartalmához. Másrészt sok más paraméter - IP-címek, portszámok, STUN jelszavak - védelmet igényelhet a DoS támadásokkal szemben .
Ezenkívül a teljes médiabiztonság érdekében először közvetlen bizalmi kapcsolatot kell kialakítania a másik féllel (az előfizetővel). Ha kulcscsere-infrastruktúrát használ egy tanúsító hatósággal közvetítőként, akkor minden kapcsolat létrejöttekor késés következik be, amelyben minden félnek hitelesítenie kell a kulcsát egy ilyen jogosultságban, ami további nehézségeket okoz a beszélgetés megkezdésében. Ha peer-to-peer kapcsolatot használnak , nehéz lesz azonosítani a másik felet. Például az üzemeltető fejleszti a B2BUA architektúrát , és az előfizetők kénytelenek nem közvetlenül, hanem IP-PBX- en keresztül csatlakozni . Ebben az esetben megnő a középen lévő Ember „jelenlétének” lehetősége , és nem beszélhetünk teljes biztonságról.