SDES er et akronym for Session Description Protocol Security Descriptions, som kan oversættes til SDP Security Descriptors for Streaming, en af nøgleudvekslingsmetoderne til Secure Real-time Transport SRTP-protokollen . Det blev standardiseret af Internet Engineering Task Force ( IETF ) i juli 2006 som RFC 4568 Arkiveret 24. januar 2009 på Wayback Machine .
For at overføre nøgler bruges SDP -protokolvedhæftninger i SIP - Inviter beskeder. Dette forudsætter SIP-bærers privatliv , hvilket skulle sikre, at den vedhæftede fil ikke er tilgængelig for en sandsynlig mand i midten . Dette kan opnås ved hjælp af TLS- transport eller en anden metode, såsom S/MIME . Brugen af TLS forudsætter, at det næste hop i SIP -proxy-kæden kan stoles på, og dette vil opfylde sikkerhedskravene for invitationsanmodningen. Fordelen ved denne metode er, at den er ekstrem nem at implementere. Denne metode er allerede blevet implementeret af flere udviklere. Selvom nogle udviklere ikke bruger en tilstrækkelig sikker nøgleudvekslingsmekanisme, hjælper det virkelig at bruge denne metode som en de facto standard i de fleste applikationer.
Lad os illustrere dette princip med et eksempel, hvor telefonen sender en opkaldsanmodning til en SIP -proxyserver. Formatet på SIP Invite- anmodningen angiver eksplicit, at det efterfølgende opkald skal foretages som sikkert. Krypteringsnøglen er base-64- kodet som en SDP - vedhæftning :
INVITE sips:[email protected];user=phone SIP/2.0 Via: SIP/2.0/TLS 10.20.30.40:1055;branch=z9hG4bK-s5kcqq8jqjv3;rport Fra: "222" < sips:[email protected] >;tag=mogkxsrhm4 Til: < sips:[email protected];user=phone > Opkalds-id: 3c269247a122-f0ee6wcrvkcq@CSCO79XX-000129287FC1 CSeq: 1 INVITERING Max Forwards: 70 Kontakt: < sip:[email protected]:1055;transport=tls;line=demoline >;reg-id=1 Bruger-agent: CSCO79XX/8.3.2 Accepter: ansøgning/sdp Tillad: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, ABONNEER, PRACK, MESSAGE, INFO Tillad-begivenheder: snak, hold, henvis Understøttet: timer, 100rel, erstatter, callerid Session-udløber: 3600;refresher=uas Min SE: 90 Indholdstype: applikation/sdp Indholdslængde: 477 v=0 o=root 2071608643 2071608643 IN IP4 10.20.30.40 s=opkald c=IN IP4 10.20.30.40 t=0 0 m=lyd 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:valgfrit a=sendecvTelefonen modtager et svar fra proxyserveren, og ved hjælp af de modtagne data kan den således organisere en tovejs (Tx / Rx) krypteret forbindelse:
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 Fra: "222" < sips:[email protected] >;tag=mogkxsrhm4 Til: < sips:[email protected];user=phone >;tag=123456789 Opkalds-id: 3c269247a122-f0ee6wcrvkcq@CSCO79XX-000413230A07 CSeq: 1 INVITERING Kontakt: < sip:[email protected]:5061;transport=tls > Understøttet: 100rel, erstatter Tillad-begivenheder: se Tillad: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PRACK, INFO Accepter: ansøgning/sdp Brugeragent: Asterisk/1.4.21-1 Indholdstype: applikation/sdp Indholdslængde: 298 v=0 o=- 349587934875 349587934875 IN IP4 10.0.0.1 s=- c=IN IP4 10.0.0.1 t=0 0 m=lyd 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=sendecvDet generelle sikkerhedsproblem er, at nøgleudvekslingen skal finde sted før den første mediepakke ankommer for at kunne kryptere de samme mediepakker med nøglerne. For at undgå irriterende klik i begyndelsen, bør de første mediepakker ignoreres. Dette er normalt en meget kort periode (mindre end 100 millisekunder), så dette er ikke et problem.
SDES-metoden giver ikke ende-til-ende mediekryptering. Det kan dog diskuteres, hvor realistisk dette krav er. På den ene side ønsker lovlige retshåndhævende myndigheder at have adgang til indholdet af telefonsamtaler. På den anden side kan mange andre parametre - IP-adresser, portnumre, STUN -adgangskoder - kræve beskyttelse mod DoS-angreb .
Derudover skal du for fuldstændig mediesikkerhed fra-til-og-til først etablere et direkte tillidsforhold til den anden part (abonnenten). Hvis du bruger en nøgleudvekslingsinfrastruktur med en certifikatmyndighed som mellemled, så er der en forsinkelse hver gang en forbindelse etableres, hvor hver part skal autentificere sin nøgle i en sådan myndighed, hvilket skaber yderligere vanskeligheder for at starte en samtale. Hvis der bruges en peer-to-peer-forbindelse , bliver det svært at identificere den anden part. For eksempel udvikler operatøren B2BUA- arkitekturen , og abonnenter er tvunget til ikke at oprette forbindelse direkte, men via IP-PBX . I dette tilfælde øges muligheden for "tilstedeværelsen" af en mand i midten , og man kan ikke tale om fuldstændig sikkerhed.