Secure Real-time Transport Protocol (förkortning SRTP, Rus. Secure real-time data transfer protocol ) - definierar RTP - protokollets profil och är designad för kryptering, meddelandeautentisering, integritet, skydd mot RTP-dataförfalskning i enkelriktade och multicast mediaöverföringar och applikationer. SRTP utvecklades av ett litet team av IP- protokoll kryptoexperter från Cisco och Ericsson , David Oran, David McGrew, Mark Baugher, Mats Naslund, Elisabetta Carrara, Karl Norman och Rolf Blom. Första gången publicerad av IETF i mars 2004 som RFC 3711 .
Eftersom RTP är nära relaterat till RTCP (Real-Time Control Protocol), som kan användas för att hantera en RTP-session, har SRTP även ett systerprotokoll som heter Secure RTCP (eller SRTCP ). SRTCP tillhandahåller samma säkerhetsrelaterade funktionalitet i RTCP för samma SRTP-funktionalitet i RTP.
Användningen av SRTP eller SRTCP är valfri när du använder RTP eller RTCP, men även om SRTP/SRTCP används är alla ytterligare funktioner (som kryptering och autentisering) valfria och kan slås på eller av. Det enda undantaget är funktionen för meddelandeautentisering, som krävs när du använder SRTCP.
För att kryptera en mediaström (i syfte att konfidentiella en röstanslutning) standardiserar SRTP (tillsammans med SRTCP) användningen av endast ett enda chiffer, AES , som kan användas i två lägen, vilket gör det ursprungliga blockchifferet AES till ett stream chiffer:
Utöver AES-chifferet tillåter SRTP direkt kryptering med det så kallade "tomma chifferet", vilket kan tas som det andra chiffer som stöds (eller ett tredje krypteringsläge utöver de två som beskrivs ovan). I själva verket utför ett tomt chiffer ingen kryptering (d.v.s. funktioner hos krypteringsalgoritmen som om nyckelströmmen endast innehöll nollor, och kopierar ingångsströmmen till utströmmen oförändrad). Detta är obligatoriskt för denna krypteringsmetod, som måste tillhandahållas på alla SRTP-kompatibla system. Den kan också användas när den sekretess som garanteras av SRTP inte krävs, men de andra funktionerna i SRTP - autentisering och meddelandeintegritet - kan användas.
Även om det är tekniskt enkelt att bygga in nya krypteringsalgoritmer i SRTP, säger SRTP-standarden att nya krypteringsalgoritmer utöver de beskrivna inte bara kan läggas till i en implementering av SRTP-protokollet. Det enda lagliga sättet att lägga till en ny krypteringsalgoritm för att vara kompatibel med SRTP-standarden är att publicera en ny RFC, där användningen av den nya algoritmen bör vara tydligt definierad.
Ovanstående krypteringsalgoritmer säkerställer inte direkt meddelandets integritet, vilket gör det möjligt att utföra en Man-in-the-middle-attack och förfalska innehållet i meddelandet, eller åtminstone lyssna på tidigare överförda data. Därför måste SRTP-standarden också tillhandahålla dataintegritet och avlyssningsskydd.
För att autentisera meddelandet och skydda dess integritet används hashalgoritmen HMAC - SHA1 , definierad i RFC 2104 , för att erhålla en 160-bitars hash, som sedan trunkeras till 80 eller 32 bitar för att bli en pakettoken. HMAC beräknas från nyttolasttypen för paketet och data i pakethuvudet, inklusive paketets sekvensnummer. För att skydda mot inbäddning av Man -in-the-Middle-meddelanden underhåller mottagaren indexen för tidigare mottagna paket, jämför dem med indexet för varje nyligen mottagna paket och hoppar bara över ett nytt paket om det inte har spelat upp (dvs. ) innan. Detta tillvägagångssätt är starkt beroende av fullständigt integritetsskydd (för att göra det omöjligt att ändra paketsekvensindex till fusk).
Nyckelgenereringsfunktionen används för att härleda sessionsnycklarna som används för att kryptera sammanhanget (SRTP, SRTCP kontrollprotokoll krypteringsnycklar och sessionsnycklar, SRTP och SRTCP autentiseringsnycklar) från en enda huvudnyckel. Således tillåter nyckelutbytesprotokollet dig att endast utbyta huvudnycklar, resten av de nödvändiga sessionsnycklarna kommer att erhållas med denna funktion.
Periodiska förändringar av själva nyckelgenereringsfunktionen leder till ytterligare säkerhetsåtgärder. Vanligtvis förhindrar detta Man -in-the-Middle från att samla in en stor mängd krypterat material krypterat med en enda sessionsnyckel. Vissa hack är lättare att utföra när det finns en stor mängd krypterat material. Dessutom ger en ändring av nyckelgenereringsfunktionen flera gånger framåt och bakåt säkerhet i den meningen att den dekrypterade sessionsnyckeln inte äventyrar andra sessionsnycklar härledda från samma huvudnyckel. Detta innebär att även om en angripare har lyckats få en specifik sessionsnyckel, kan han inte dekryptera meddelanden som tillhandahålls med tidigare och senare sessionsnycklar härledda från samma huvudnyckel. (Även om den resulterande huvudnyckeln naturligtvis ger alla sessionsnycklar som härrör från den.)
SRTP förlitar sig på ett externt nyckelutbytesprotokoll för att upprätta en huvudfrönyckel. Två speciella protokoll har utvecklats för användning med SRTP, ZRTP och MIKEY .
Det finns andra metoder för att förhandla om SRTP-nycklar. Flera olika tillverkare erbjuder produkter som använder SDES- nyckelbytesmetoden .