SRTP

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 31. marts 2022; verifikation kræver 1 redigering .

Secure Real-time Transport Protocol (forkortet SRTP, Rus. Secure real-time data transfer protocol ) - definerer RTP -protokolprofilen og er designet til kryptering, meddelelsesgodkendelse, integritet, beskyttelse mod RTP-dataforfalskning i envejs- og multicast-medieoverførsler og applikationer. SRTP blev udviklet af et lille team af IP -protokol krypto-eksperter fra Cisco og Ericsson , David Oran, David McGrew, Mark Baugher, Mats Naslund, Elisabetta Carrara, Karl Norman og Rolf Blom. Først udgivet af IETF i marts 2004 som RFC 3711 .

Beskrivelse

Da RTP er tæt knyttet til RTCP (Real-Time Control Protocol), som kan bruges til at administrere en RTP-session, har SRTP også en søsterprotokol kaldet Secure RTCP (eller SRTCP ). SRTCP giver den samme sikkerhedsrelaterede funktionalitet i RTCP for den samme SRTP-funktionalitet i RTP.

Brugen af ​​SRTP eller SRTCP er valgfri, når du bruger RTP eller RTCP, men selvom SRTP/SRTCP bruges, er alle ekstra funktioner (såsom kryptering og godkendelse) valgfri og kan slås til eller fra. Den eneste undtagelse er meddelelsesgodkendelsesfunktionen, som er påkrævet ved brug af SRTCP.

For at kryptere en mediestrøm (med henblik på fortroligheden af ​​en stemmeforbindelse), standardiserer SRTP (sammen med SRTCP) brugen af ​​kun en enkelt ciffer, AES , som kan bruges i to tilstande, hvilket gør den oprindelige blokciffer AES til en stream chiffer:

Ud over AES-kryptering tillader SRTP direkte kryptering ved hjælp af den såkaldte "tomme kryptering", som kan tages som den anden understøttede chiffer (eller en tredje krypteringstilstand ud over de to beskrevet ovenfor). Faktisk udfører en tom kryptering ingen kryptering (dvs. funktioner af krypteringsalgoritmen, som om nøglestrømmen kun indeholdt nuller, og kopierer inputstrømmen til outputstrømmen uændret). Dette er obligatorisk for denne krypteringsmetode, som skal leveres på ethvert SRTP-kompatibelt system. Det kan også bruges, når fortroligheden garanteret af SRTP ikke er påkrævet, men de andre funktioner i SRTP - autentificering og meddelelsesintegritet - kan bruges.

Selvom det er teknisk nemt at bygge nye krypteringsalgoritmer ind i SRTP, siger SRTP-standarden, at nye krypteringsalgoritmer ud over de beskrevne ikke blot kan tilføjes til en implementering af SRTP-protokollen. Den eneste lovlige måde at tilføje en ny krypteringsalgoritme for at være kompatibel med SRTP-standarden er at udgive en ny RFC, hvor brugen af ​​den nye algoritme bør være klart defineret.

Autentificering, integritet og aflytning

Ovenstående krypteringsalgoritmer sikrer ikke direkte beskedens integritet, hvilket gør det muligt at udføre et Man-in-the-middle-angreb og forfalske indholdet af beskeden, eller i det mindste lytte til de tidligere transmitterede data. Derfor skal SRTP-standarden også give dataintegritet og aflytningsbeskyttelse.

For at autentificere meddelelsen og beskytte dens integritet, bruges HMAC - SHA1 hashing-algoritmen , defineret i RFC 2104 , til at opnå en 160-bit hash, som derefter afkortes til 80 eller 32 bit for at blive et pakketoken. HMAC beregnes ud fra pakkens nyttelasttype og dataene i pakkehovedet, inklusive pakkens sekvensnummer. For at beskytte mod indlejring af Man -in-the-Middle-meddelelser vedligeholder modtageren indekserne for tidligere modtagne pakker, sammenligner dem med indekset for hver nyligt modtaget pakke og springer kun en ny pakke over, hvis den ikke er blevet afspillet (dvs. ) Før. Denne tilgang er stærkt afhængig af fuld integritetsbeskyttelse (for at gøre det umuligt at ændre pakkesekvensindekser til snyde).

Nøglegenerering

Nøglegenereringsfunktionen bruges til at udlede de sessionsnøgler, der bruges til at kryptere konteksten (SRTP, SRTCP -kontrolprotokolkrypteringsnøgler og sessionsnøgler , SRTP- og SRTCP-godkendelsesnøgler) fra en enkelt hovednøgle. Således giver nøgleudvekslingsprotokollen dig kun mulighed for at udveksle hovednøgler, resten af ​​de nødvendige sessionsnøgler vil blive hentet ved hjælp af denne funktion.

Periodiske ændringer i selve nøglegenereringsfunktionen fører til yderligere sikkerhedsforanstaltninger. Typisk forhindrer dette Man -in-the-Middle i at indsamle en stor mængde krypteret materiale krypteret med en enkelt sessionsnøgle. Nogle hacks er nemmere at udføre, når der er en stor mængde krypteret materiale. Derudover giver ændring af nøglegenereringsfunktionen flere gange fremad- og baglæns sikkerhed i den forstand, at den dekrypterede sessionsnøgle ikke kompromitterer andre sessionsnøgler afledt af den samme hovednøgle. Dette betyder, at selvom en angriber har formået at få en specifik sessionsnøgle, er han ikke i stand til at dekryptere meddelelser, der er leveret med tidligere og senere sessionsnøgler, der er afledt af den samme hovednøgle. (Selvom den resulterende hovednøgle selvfølgelig vil give alle sessionsnøgler afledt af den.)

SRTP er afhængig af en ekstern nøgleudvekslingsprotokol til at etablere en master-seed-nøgle. To specielle protokoller er udviklet til brug med SRTP, ZRTP og MIKEY .

Der er andre metoder til at forhandle SRTP-nøgler. Flere forskellige producenter tilbyder produkter, der bruger SDES- nøgleudvekslingsmetoden .

Links