ATACURI ŞI AMENINŢĂRI ASUPRA SERVICIULUI VoIP

Cuprins

1. INTRODUCERE ÎN REŢELELE DE COMUNICAŢII..................................................9

1.1 EVOLUŢIA.....................................................................................................................................................91.2 VOICE OVER INTERNET PROTOCOL (VOIP).................................................................................................10

2. ATACURI ŞI AMENINŢĂRI ASUPRA SERVICIULUI VOIP....................................11

2.1 AMENINŢĂRI ÎMPOTRIVA DISPONIBILITĂŢII.................................................................................................11

2.1.1 Supraîncărcarea cu apeluri (Call Flooding).............................................112.1.2 Mesaje corupte (Protocol Fuzzing)..........................................................142.1.3 MESAJE FALSIFICATE........................................................................162.1.4 Deturnarea apelului (Call Hijacking).......................................................172.1.5 Interceptarea înregistrărilor.....................................................................172.1.6 Interceptarea sesiunii media (Media session Hijacking).........................182.1.7 Preluarea identităţii serverului (server impersonating)............................192.1.8 Deteriorarea calităţii serviciilor (QoS Abuse ).......................................202.2 AMENINŢĂRI ÎMPOTRIVA CONFIDENŢIALITĂŢII...........................................................................................21

2.2.1 Interceptarea media (Eavesdropping Media)...........................................212.2.2 „Call Pattern Tracking”...........................................................................222.2.3 Exploatarea datelor (Data Mining)..........................................................242.2.4 Reconstrucţie...........................................................................................242.3 AMENINŢĂRI ÎMPOTRIVA INTEGRITĂŢII.......................................................................................................25

2.3.1Alterarea mesajului...................................................................................252.3.2 Modificarea media (media alteration).....................................................27

3. SCHIMBUL DE CHEI SDES, ZRTP ŞI MIKEY........................................................29

3.1 SDES..........................................................................................................................................................293.2 ZRTP..........................................................................................................................................................303.3 MULTIMEDIA INTERNET KEYING................................................................................................................323.4 SECURE REAL-TIME TRANSPORT PROTOCOL : SRTP....................................................................................32

3.4.1 Obţinerea cheii SRTP..............................................................................333.4.2 Algoritmul criptografic al SRTP.............................................................333.5 ATACURI ŞI VULNERABILITĂŢI ALE SDES, ZRTP ŞI MIKEY....................................................................35

3.5.1 Atacuri asupra SIP...................................................................................353.5.2 Atacuri asupra SDES/SRTP....................................................................363.5.3 Atacuri asupra ZRTP...............................................................................383.6 ANALIZE FORMALE (NEOFICIALE) A ZRTP ÎN AVISPA.............................................................................413.7 ANALIZA LUI MIKEY.................................................................................................................................42

4. ZRTP : UN NOU CONCEPT PENTRU SECURIZAREA VOIP..................................43

4.1ARHITECTURA ZRTP (ZIMMERMIN RTP)....................................................................................................434.1 PACHETUL ZRTP DE TIP “HELLO”...............................................................................................................444.2PACHET ZRTP COMMIT...............................................................................................................................454.3 PACHETUL ZRTP DHPART1........................................................................................................................454.4PACHETUL ZRTP DE CONFIRMARE..............................................................................................................464.5 RTP (REAL TIME TRANSPORT PROTOCOL )................................................................................................474.6 RTCP (REAL TIME CONTROL PROTOCOL)..................................................................................................47

5. BIBLIOGRAFIE.................................................................................................................48

1. INTRODUCERE ÎN REŢELELE DE COMUNICAŢII

1.1 Evoluţia

Evoluţia rapidă a staţiilor de lucru şi a calculatoarelor personale la platforme cu putere mare de calcul şi capacităţi multimedia, dezvoltarea tehnologiilor de reţea şi progresul din domeniul procesării de semnal şi al programării au dus la o explozie a aplicaţiilor multimedia de timp real. Mult timp s-a crezut că ATM va fi tehnologia de reţea care va integra toate serviciile, considerându-se reţelele deja existente de voce şi de date dedicate unui singur serviciu. S-a dovedit a fi un punct de vedere greşit.

Protocolul IP moşteneşte o mare parte din deficienţele sistemului dezvoltat în anii ‘70. Astfel, calitatea serviciului variază foarte mult. Sunt momente când ea este rezonabilă, dar şi momente când devine intolerabilă din punct de vedere al unei aplicaţii de timp real. Se întâmplă uneori să apară pierderi de pachete de 30-40%, făcând imposibilă o comunicaţie de voce sau o video-conferinţă. Noile reţele de date trebuie să asigure, pe lângă viteza de transmisie ridicată, banda largă, managementul resurselor, scalabilitate şi integrarea diverselor tehnologii de access (LAN, HDSL, ADSL, TDM etc.). De aceea au apărut noi cerinţe de performanţă şi de funcţionalitate pentru reţelele de date actuale. Datorită faptului că resursele reţelelor de date sunt limitate, acestea trebuie gestionate cu grijă pentru a obţine performanţe şi randamente ridicate.

Această împărţire pe nivele face mai uşoară gestionarea şi proiectarea arhitecturilor reţelelor de date, precum şi migrarea către noi tehnologii prin etape de integrare pe nivele funcţionale. Principalele caracteristici arhitecturale şi de funcţionalitate ale unei reţele moderne sunt:

Structurare pe nivele arhitecturale. Management centralizat. Ingineria traficului care se face prin managementul centralizat Integrarea a cât mai multe tehnologii de access. Conexiune cu reţeaua PSTN. Migrarea către o reţea de date universale (Date, voce, video.). Migrarea traficului de voce către reţelele NGN Scalabilitate, performanţă, disponibilitate totală (99%).

1.2 Voice over Internet Protocol (VoIP)

VoIP reprezintă o familie de tehnologii care ajută reţelele bazate pe IP să folosească aplicaţii de voce precum telefonia, comunicare în timp real,

teleconferintă. VoIP defineşte o modalitate de transport a vocii peste reţelele IP, incluzând de asemenea şi procesul de digitizare şi formare de pachete. Telefonia IP foloseşte standardele VoP pentru a creea un sistem telefonic care permite servicii de tipul rutare de apel,mesagerie vocală etc.

2. ATACURI ŞI AMENINŢĂRI ASUPRA SERVICIULUI VoIP

Atacatorii pot să deterioreze serviciul de media fie supraîncărcând cu trafic, fie colectând informaţii private prin interceptarea semnalului telefonic sau a celui de semnalizare. Deturnarea apelurile se face prin asumarea falsă a identităţii servelor sau impersonarea utilizatorilor. Acestea conduc la apeluri realizate în mod fraudulos din cauza identităţii falsificate şi asa mai departe. Utilizatorii nelegitimi (spammerii) pot utiliza reţelele VoIP pentru a livra apeluri spam, mesaje instante sau informaţii, fiind mult mai eficiente decât spamul pe email deoarece spamul VoIP este foarte dificil de filtrat.

Există numeroase moduri de a grupa ameninţările unei reţele VoIP. Voi trata următoarele categorii :

Ameninţări împotriva disponibilităţii Ameninţări împotriva confidenţialităţii Ameninţări împotriva integrităţii

2.1 Ameninţări împotriva disponibilităţii

Ameninţările impotriva disponibilităţii sunt de fapt un grup de ameninţări împotriva serviciul “de disponibilitate” care ar trebui să fie activ 24/7. Astfel, aceste ameninţări doresc întreruperea serviciului VoIP, de cele mai multe ori prin refuzul serviciului (denial of service – DoS). Ameninţările tipice împotriva disponibilităţii sunt următoarele:

Supraîncărcarea cu apeluri (Call flooding) Mesaje corupte (Malformed messages) Mesaje false (Spoofed messages) Interceptarea apelului (Call hijacking) Impersonarea serverului (Server impersoning)

2.1.1 Supraîncărcarea cu apeluri (Call Flooding)

Un exemplu des întâlnit al DoS intenţionat este supraîncarea apelului: un atacator supraîncarcă cu trafic util sau nu (trafic de voce sau semnale de

semnalizare ) spre o ţintă (exemplu, server VoIP, client sau o infrastructura de bază) şi astfel scade performanţa reţelei în mod semnificativ sau chiar cade conexiunea. Metodele specifice de call flooding sunt următoarele:

Valid or invalid registration flooding : un atacator foloseşte această metodă în mod frecvent deoarece majoritatea serverelor de înregistrare acceptă cereri de la orice staţie finală din internet, ca un prim pas de autentificare. Indiferent dacă mesajele sunt valide sau nu , numărul mare de mesaje cerere într-o perioadă scurtă de timp (de exemplu, 10 000 mesaje SIP REGISTER pe secundă) afectează sever performanţele serverului.

Valid or invalid call request flooding : cele mai multe servere VoIP au un element (caracteristică) de securitate care blochează apelurile de tip cerere floodate de la staţiile finale nelegitime (neînregistrate). Deci, un atacator mai întâi se înregistrează falsificând existenţa unui utilizator legitim şi apoi trimite cereri de apel floodate (call requests) într-o perioadă scurtă de timp (de exemplu, 10 000 mesaje SIP INVITE pe secundă ). Acest lucru având un impact asupra performanţei sau funcţionalităţii serverului indiferent dacă mesajul tip cerere este valid sau nu.

“Call control flooding” după configurarea apelului : - Un atacator poate inunda reţeaua cu mesaje de control ale apelului, valide sau nu (de exemplu : SIP INFO, NOTIFY, Re-INVITE) după stabilirea apelului. Majoritatea serverelor proxy sunt vulnerabile deoarece nu au o opţiune de securitate care să ignore şi aruncă aceste mesaje.

Ping flooding - protocoalele VoIP folosesc mesajele ping la nivelul aplicaţie ca să verifice disponibilitatea unui server sau să menţină o legătura cu serverul local de NAT (Network Address Translation), cum ar fi mesajele SIP OPTION. Majoritatea echipamentelor IP de reţea (de exemplu, un ruter sau un firewall) datorită configuraţiei pe care o aplicăm nu dă voie pingurilor ICMP în reţelele de producţie (exemplu,organizaţiile economice), din motive de securitate. Cu toate acestea, serverele VoIP ar trebui să nu restricţioneze pingul la nivelul aplicaţie pentru o funcţionare eficace. Totuşi rezultatul ar fi o mare breşă de securitate.

Figura 1.0 ilustrează exemplul supraîncărcării distribuite cu PCuri infectate. Un atacator infectează alte calculatoare cu “malware” (de exemplu, un virus) si le foloseşte ca intermediari floodând mesaje de înregistrare. Fiecare calculator infectat trimite 1000 de mesage SIP REGISTER pe secundă sub diferite legitimităţi care sunt generate aleator.

Figura 1.0 Atac de tip supraîncărcare distribuit

În figura de mai sus , mesajele floodate vor afecta serverul de înregistrare (SIP Registrar) în mod sever întrucât acesta procesează şi răspunde cu erori precum : “401 Unauthorized” , “404 Not Found”, “400 Bad Request” etc. Impactul poate provoca un consum mare al resurselor (de exemplu, procesor, memorie, bandă ), defecţiune a sistemului sau întreruperea serviciului. Indiferent dacă serverul răspunde sau nu, floodarea serverului SIP registrar cu suficiente mesaje de înregistrare va provoca degradarea serviciului de legitimare a staţiilor finale. (endpoints). Nu doar floodarea intenţionată menţionată, ci si floodarea neintenţionată există în reţele VoIP sub numele de auto-atac (self-attack), din cauza configurării incorecte a unor dispozitive sau a anumitor circumstanţe unice. Câteva exemple :

Pană de curent regională şi restaurare – Când tensiunea a revenit dupa o pană de curent, toate staţiile finale (de exemplu,10000 telefoane IP) vor porni si vor trimite mesaje de înregistrare serverului aproape in acelaşi timp, care neintenţionat sunt de fapt mesaje floodate. Deoarece aceste telefoane sunt legitime şi distribuite pe o arie mare, este greu de controlat traficul floodat proactiv.

Configurarea incoretă a unor dispositive – cea mai frecventă configurare incorectă e setarea staţiilor finale (de exemplu,

telefoane IP) să trimită prea multe mesaje care nu sunt necesare, cum ar fi : faptul că un intervalul de înregistrare este prea scurt.

“Misbehaving endpoints” : problemele software (firmware) sau hardware pot creea supraîncărcare neaşteptată, în special când există mai multe tipuri de staţii finale, unele chiar necunoscute, care fac parte din reţeaua VoIP.

Supraîncărcarea legitimă a apelului – există momente din zi sau zile în care multe apeluri legitime sunt făcute aproape în acelaşi timp. Un exemplu e “Ziua mamei” când o mulţime de apeluri sunt efectuate în toata lumea. Un alt exemplu îl reprezintă dezastrele naturale (de exemplu, cutremurele), când oamenii din împrejurimi fac foarte multe apeluri la serviciul de urgenţă (de exemplu, 112), iar familiile şi prietenii fac apeluri în aria afectată în acelaşi timp.

Aceste tipuri intenţionate, sau nu, de floodare a apelului sunt cele mai comune şi cele mai critice atacuri pentru furnizorii serviciului VoIP, care trebuie să asigure disponibilitate continuă. Următorul tip de atac este o altă formă de ameninţare împotriva serviciului de disponibilitate, cu ajutorul mesajelor corupte. (malformed messages)

2.1.2 Mesaje corupte (Protocol Fuzzing)

Un atacator poate creea şi trimite mesaje corupte spre serverul sau clientul vizat cu scopul întreruperii serviciului. Un mesaj corupt este un mesaj al protocolului cu sintaxă greşită. Exemplul din figura 1.1 arată un un mesaj de tip invitaţie SIP (SIP INVITE message).

Figura 1.1 Mesaj corupt de tip SIP INVITE

Comentariile (literele boldate) din exemplu nu sunt afişate în mesajul actual SIP INVITE. Putem găsi ceva in neregulă in exemplul mesajului de tip invitaţie. Trei antete SIP (Request-URI , From, Call-Id) şi o versiune în protocolul de descriere a sesiunii (Session Description Protocol – SDP) au format greşit. Serverul care primeşte acest tip de mesaj neaşteptat poate fi confuz (haotic) şi reacţionează în diferite moduri, depinde de implementare. Impacturile tipice sunt după cum urmează :

Bucle infinite de parsare Memoria tampon saturată, care poate permite execuţia unui cod

arbitrar Defectează maşina de stare Incapabilitatea de a procesa alte mesaje normale Căderea sistemului

Aceste vulnerabilităţi provin în general din următoarele surse :

1. Slăbiciunea specificaţiilor protocolului

Majoritatea protocoalelor VoIP pot fi accesate de oricine şi nu definesc strict fiecare linie de cod. Atacatorii pot găsi unde se află slăbiciunea unei sintaxe. În plus, exită multe câmpuri sau tag-uri care pot fi personalizate.

2. Uşurinţa creării mesajelor corupte

Crearea mesajelor ca cel in exemplul 2 este uşor de realizat pentru un programator. Chiar şi cei care nu sunt programatori au la dispoziţie destule unelte pentru a personaliza mesaje.

3. Lipsa tratării excepţiilor în implementare

Datorită restricţiilor de timp, majoritatatea celor care implementează se focalizează pe caracteristicile produsului si interfeţe mai degrabă, decât sa creeze excepţii de tratare a cazurilor nefavorabile.

4. Dificultatea testării tuturor cazurilor de mesaj corupt

Este foarte dificil să testezi toate cazurile negative, chiar dacă există instrumente de testare pe piaţă din ce in ce mai sofisticate care acoperă multe din cazurile de mesaje corupte.

Ameninţarea cu mesaje corupte ar trebui să fie prevenită atâta timp cât algoritmul de parsare le tratează cum trebuie.

Următoarea ameninţare o reprezintă mesajele falsificate (spoofed messages) care nu sunt o formă de mesaje corupte dar influenţează în mod negativ serviciul de disponibilitate.

2.1.3 MESAJE FALSIFICATE

Un atacator poate insera mesaje false într-o sesiune VoIP pentru a întrerupe serviciul, sau pentru a prelua el sesiunea. Exemplele elocvente sunt “call teardown” şi “toll fraud”.

2.1.3.a Call Teardown

Această metodă dăunătoare, call teardown, reprezintă capacitatea unui atacator de a monitoriza traficul, dialogul SIP ,pentru a obţine informaţii despre sesiune (Call-Id,From tag, To tag) şi de a trimite mesaj de terminare a apelului (de exemplu, SIP BYE) dispozitivului cu care comunică, în timp ce aceştia discută. Dispozitivul care primeşte mesajul de terminare a apelului va inchide sesiunea imediat. Figura 1.2 ilustrează exemplul cu mesaje SIP.

Figura 1.2 Call teardown

În Figura 1.2 se presupune că atacatorul deja a monitorizat semnalele de apel dintre utilizatorul A şi B şi cunoaşte informaţia din sesiune (SIP dialog). Atacatorul injectează informaţiile sesiunii într-un mesaj de tip BYE. Telefonul IP al utilizatorului A primeşte mesajul BYE şi deconectează canalul media. Altă

metodă de atac este aceea prin care un atacator trimite mesaje de terminare a apelului dispozitivelor, în mod aleator, (în special, serverelor proxy) fără să ştie informaţia sesiunii. Acestea pot afecta sesiunea de apel curentă. Comparativ cu ameninţările anterioare, “call teardown” nu este un atac întâlnit des deoarece atacatorul ar trebui să monitorizeze sesiunea de apel dorită, înaintea ca acesta să poată trimite mesaje de terminare a sesiunii (BYE).

Următorul tip de atac o reprezintă apelul taxat in mod fraudulos (“toll fraud”) . Acesta implică de asemenea informaţii preliminare precum acreditare înainte de a efectua apeluri frauduloase. Scest tip de atac e mai frecvent datorită beneficiilor financiare.

2.1.3.b Netaxarea apelului în mod fraudulos (Toll Fraud)

Un apel fraudulos este unul dintre cele mai frecvente probleme ale zilele noastre, în special pentru apeluri internaţionale sau la distanţe mari. Pentru ca majoritatea dispozitivelor intermediare (de exemplu, public switched telephone network - PSTN), media gateway, server proxy) necesită autenficari valide (de exemplu, ID şi parolă) înaintea stabiliri apelului taxabil, un atacator obtine acreditările(identificatorii) în diferite moduri. Tipic, un atacator creează mesaje false pentru atacarea parolei, pe server, prin forţă brută până ce acesta primeşte permisiune. Dacă clientul foloseşte parole standard sau simplu de ghicit atunci acestea sunt mult mai uşor de găsit; în special cazul când atacatorul foloseşte un dicţionar de parole. În anumite cazuri, serverul nu necesită autentificare, dar verifică IP-ul sursă sau subnetul clientului pentru a controla accesul. În special când “call trunking” (de exemplu, „SIP trunking”), este iniţiat între un furnizor de servicii VoIP şi o întreprindere client, controlul accesului cel mai des utilizat se bazează pe sursa IP sau subreţeaua de provenienţă. Un atacator poate să acceze serverul falsificând adresa IP sursă.

2.1.4 Deturnarea apelului (Call Hijacking)

„Hijacking”(deturnarea) apare când anumite negocieri între o staţie terminală VoIP si reţea sunt preluate de un atacator. Negocierea poate fi înregistrarea, configurarea apelului, trafic media, etc. Această detunare/sustragere/interceptare poate provoca întreruperea serviciului prin dezactivarea utilizatorilor legitimi de serviciu VoIP. Este similar cu “call teardown” în faza iniţială în care se fură informaţiile despre sesiune, dar forma atacului şi impactul sunt diferite. Cazurile tipice sunt interceptarea înregistrării, deturnarea sesiunii media şi însuşirea identităţii unui server. Umătorul paragraf descrie fiecare dintre aceste cazuri :

2.1.5 Interceptarea înregistrărilor

Procesul de înregistrare dă voie unei staţii finale să se identifice insăşi serverului (de exemplu, SIP Registrar) ca dispozitiv pentru că este localizat un utilizator. Un atacator monitorizează aceste negocieri şi trimite mesaje false serverului cu scopul de a deturna sesiunea. Când un utilizator legitim a fost compromis, acel utilizator nu mai poate primi apeluri. Figura ilustrează exemplul cu mesaje SIP.

Figura 1.3 Deturnarea înregistrării

În figura 1.3 un atacator îşi însuşeşte identitatea unui utilizator modificând antetul “From” şi adăugând adresa atacatorului în antetul “To” când trimite un mesaj de înregistrare, care actualizează adresa de înregistrare a ţintei vizate. Toate apelurile spre utilizatorul A vor fi direcţionate spre atacator. Acest atac se întamplă când serverul de SIP (Registrar) se bazează doar pe antetele SIP pentru a identifica utilizatorul.

2.1.6 Interceptarea sesiunii media (Media session Hijacking)

Când o sesiune media este negociată între două staţii finale VoIP, un atacator poate trimite mesaje false oricăruia dintre ele pentru a redirecţiona media spre o altă staţie finală precum telefonul atacatorului sau căsuţa vocală a acestuia. Victima va fi capabilă să vorbească doar cu staţia finală a atacatorului. Figura 1.4 ilustrează exemplul cu mesaje SIP.

Figura 4.4 Interceptarea sesiunii

În figura 1.4 utilizatorul A apelezează utilizatorul B. Telefonul IP al utilizatorului B sună. Prin monitorizarea cererilor de apel ale utilizatorului B, un atacator detectează apelul şi trimite mesaje “200 OK” utilizatorului A cu adresa IP şi portul, corespunzătoare serverului său de mesagerie vocală. Utilizatorul A lasă un mesaj de voce pentru utilizatorul B în căsuţa vocală a atacatorului. Acestă deturnare are loc înainte ca sesiunea media să fie stabilită între utilizatorul A şi cel dorit, utilizatorul B. Chiar şi după ce s-a stabilitat canalul de comunicaţie între A şi B, un atacator poate să deturneze o sesiune activă prin trimiterea unui mesaj de tip reinvitaţie (“re-invite”)utilizatorului A.

2.1.7 Preluarea identităţii serverului (server impersonating)

Un client VoIP trimite un mesaj de cerere unui server în domeniul vizat pentru înregistrare, configurare apel sau rutare etc. Este posibil ca un atacator să-şi asume identitatea serverului şi să primească mesajul cerere , iar apoi să îl manipuleze/modifice în scopuri dăunătoare. Metoda tipică de impersonare a serverului este realizată prin atacarea serverului TFTP sau serverului de DNS în primă fază. Un atacator poate accesa neautorizat serverul de TFTP şi înlocuieşte un fişier de configuraţie pentru telefoanele IP cu fişierul său care are o adresă IP a unui server (de exemplu, SIP Registrar) fals, infectat. Telefoanele IP care descarcă fişierul corupt/dăunător vor trimite un mesaj de cerere unui server nepotrivit/fals. Un atacator poate de asemenea să compromită un server DNS şi

să înlocuiască înregistrarea serverului VoIP curent cu o adresă IP a unui server corupt. Telefoanele IP care caută IP-ul serverului vor primi unul greşit. Figura de mai jos ilustrează un exemplu bazat pe o tranzacţie SIP cu un server Redirect.

Figura 1.5 Preluarea identităţii serverului

În figura 1.5 atacatorul a compromis/corupt serverul de DNS local prin înlocuirea adresei IP (10.1.1.10) a original.redirect.com cu 10.10.10.10 care e serverul redirect a atacatorului. Când utilizatorul A încearcă să iniţieze un apel spre utilizatorul B, telefonul IP caută adresa IP a serverului redirect (original.redirect.com) şi primeşte IP-ul 10.10.10.10 a serverului nelegitim. Mesajul INVITE este trimis serverului corupt/fals/nelegitim, iar acesta returnează “302 Moved Temporarily” cu informaţii de contact false ce ar putea fi o adresă fictivă sau serverul proxy al atacatorului folosit pentru ameninţări viitoare. Serverul original redirect (10.1.1.10) nu poate primi nicio cerere de apel în această situaţie.

2.1.8 Deteriorarea calităţii serviciilor (QoS Abuse )

Componentele unei sesiuni media sunt negociate între staţiile finale VoIP în timpul configurării apelului. Acestea sunt: tipul de media, rata codorului-decodorului (codecului), tipul sarcinii utile (de payload). De exemplu, ar putea fi necesar sau de dorit să folosim codecul de voce G.729 atunci când creăm o reţea (pentru a folosi minimul de bandă). Folosim G.711 când apelurile sunt efectuate în interiorul reţelei (pentru a păstra o calitate ridicată a apelului). Un atacator poate interveni în această negociere şi să abuzeze de calitatea serviciilor prin înlocuirea, ştergerea, modificarea codecurilor sau tipul sarcinii utile. O altă

metodă de deteriorare a calităţii serviciilor este suprasaturarea capacităţii canalului (care e limitat) cu ajutorul unui instrument în aşa fel încât utilizatorii legitmi nu pot utiliza banda pentru serviciul lor. Unii furnizori de servicii VoIP sau companii de hosting limitează banda pentru anumite grupuri de hosturi cu scopul de a proteja reţeaua. Un atacator poate şti rata limită şi poate genera trafic excesiv pe canal, astfel calitatea vocii între cei care comunică va fi degradată.

2.2 Ameninţări împotriva confidenţialităţii

O altă categorie de ameninţare VoIP este aceea împotriva confidenţialităţii. Spre deosebire de întreruperea serviciului pe care am prezentat-o, ameninţările împotriva confidenţialităţii nu au un impact asupra comunicaţiilor curente în general, dar asigură mijloace neautorizate de a captura trafic de voce, identităţi, modele şi credenţiale care sunt folosite pentru conexiunile neautorizate ulterioare sau alte practici înşelătoare. Negocierile VoIP sunt cele mai expuse ameninţărilor de confidenţialitate deoarece majoritatea serviciilor VoIP nu asigură confidenţialitate pe deplin (ambele: semnal şi media) punct-la-punct. De fapt, criptarea totală a antetelor mesajelor este imposibilă deoarece serverele intermediare (de exemplu, serverul proxy de SIP) trebuie să vadă informaţia din antet pentru a putea ruta un apel. În unele cazuri, serverele trebuie să insereze informaţia în antet (de exemplu, antetul Via în SIP), în funcţie de cum e proiectat protocolul.

Această secţiune introduce cele mai populare tipuri de atacuri asupra confidenţialităţii :

eavesdropping media call pattern tracking data minig reconstruction

2.2.1 Interceptarea media (Eavesdropping Media)

Interceptarea conversaţiei unei persoane e o ameninţare cunoscută de când a apărut serviciul de telecomunicaţii; chiar dacă metodele de ascultare sunt diferite între sistemele de telefonie clasică şi sistemele VoIP. În VoIP, un atacator foloseşte 2 metode în mod normal. Una este aceea de a asculta pachetele media din acelaşi domeniu de broadcast cu ţinta, sau pe aceiaşi cale cu media. Cealaltă metodă este realizată prin compromiterea unui dispozitiv de acces (de exemplu, switch de nivel 2) şi redirecţionarea (prin duplicare) spre

dispozitivul atacatorului.Media poate fi doar voce sau integrată cu video,text,fax, sau imagine. Figura 1.6 ilustrează aceste cazuri.

Figura 4.6 Interceptarea semnalelor de pe mediul de transmisie

În figura 1.6, dispozitivul atacatorului care e în acelaşi domeniu de broadcast cu telefonul IP al utilizatorului A poate captura toate semnalele şi media care trec prin hubul respectiv. Această figură arată de asemenea posibilitatea ca atacatorul să pătrundă ilegal într-un switch sau ruter şi să configureze un port de monitorizare pentru VLANul de voce. Mai apoi va redirecţiona (dubluri) media dispozitivului de captura al atacatorului.

O altă posibilitate de interceptare este aceea prin care atacatorul se interpune pe aceeaşi cale cu însăşi media, care e similară cu tehnica de interceptare telefonică folosită în PSTN. De exemplu, atacatorul are acces la T1 şi desparte fizic T1 în două semnale.

2.2.2 „Call Pattern Tracking”

„Call pattern tracking” reprezintă analiza neautorizată a traficului VoIP al unui nod specific sau a unei reţele astfel încât un atacator poate găsi: fie un potenţial dispozitiv ţintă, de acces (IP/port), protocol sau vulnerabilitatea reţelei. Poate de asemenea să fie folositor în monitorizarea apelurilor. Pentru a demonstra un exemplu de analiză neautorizată, mesajele de test/probă pe care un atacator le poate captura dintr-o reţea sunt ilustrate în exemplul de mai jos. E prezentată o cerere SIP simplă (INVITE) şi mesaje răspuns (200 OK). Un atacator poate extrage informaţie concludentă din ele analizând protocolul. (câmpurile cheie sunt îngroşate).

Figura 1.7 Mesaj SIP INVITE

În paragraful de mai jos este descris un exemplu de informaţii pe care un atacator le-ar putea extrage din figura 1.7

Adresa IP a serverului proxy de SIP este 192.168.10.10, iar portul corespunzător 5060.

Se folosec pachete UDP pentru semnalizare fără criptare, cum ar fi TLS (Transport Layer Security) sau Secure Multipurpouse Internet Mail Extension (S/MIME)

Serverul proxy nu necesită autentificare pentru cererea de apel. Iniţiatorul (Alice) care are un număr de telefon 4085251111, îl

apelează pe Bob la 9252226543. Adresa IP a telefonului lui Alice este 10.10.10.10, iar gateway-ul de

voce este 172.26.10.10 (presupunând că apelul merge pe PSTN)

Gateway-ul de voce deschide un port UDP, 2000, pentru a primi flux RTP de la telefonul lui Alice.

Gatewayul acceptă doar codecul de voce G.729 (telefonului lui Alice oferise G.711a,G.711u şi G.729a iniţial)

Informaţiile prezentate pot fi folosite pentru atacuri viitoare, precum atac DoS asupra serverului proxy sau a gateway-ului de voce.

2.2.3 Exploatarea datelor (Data Mining)

Aşa cum utilizatorii nelegitmi de e-mail care colectează adrese de email din diferite surse precum pagini web sau agende, utilizatorii nelegitmi de VoIP pot, de asemenea, strânge informaţii cu numere de telefon din mesajele interceptate. Acesta e un exemplu de “data mining”. Sensul general al exploatării de date o reprezintă colecţia de identificatori neautorizaţi care pot fi un nume, număr de telefon, parolă, URL,adresă de email, sau alţi identificatori care au legătură cu telefoane,noduri de server, părţi comunicante, sau organizaţii din reţea. În exemplul 2.7 se poate observa acest tip de informaţii din mesaje.

Un atacator utilizează informaţia pentru conexiuni neautorizate ulterioare precum :

Apel efectuat fraudulos (Toll fraud calls) Apeluri spam (de exemplu, voce, mesagerie instantă) Întreruperea serviciului (de exemplu, supraîncărcarea apelului cu trafic,

deturnarea apelului, căderea conexiunii apelului) Înşelătoria/phishing ( identitate frauduloasă) Cu identităţi valide, atacatorii pot avea o sanşă mai mare să întrerupă

serviciul prin trimiterea diferitelor tipuri de mesaje corupte. Majoritatea serverelor resping toate mesajele, excepţie făcând mesajele de înregistrare, dacă staţia finală nu este înregistrată.

2.2.4 Reconstrucţie

Reconstrucţia înseamnă orice reconstrucţie neautorizată a vocii, video, fax, text sau a informaţiei prezente după capturarea semnalelor sau a traficului de voce dintre părţile comunicante. Reconstrucţia include monitorizarea, înregistrarea, interpretarea, recunoaşterea şi extragerea a oricărui tip de comunicaţii fără consimţământul părţilor. Câteva exemple sunt, după cum urmează:

Acreditări de decodificare criptate de un protocol specific. Extragerea “dual tone multifrequency” (DTMF) tonuri dintr-o

conversaţie.

Extragerea imaginilor fax dintr-o comunicaţie (voce şi fax). Interpretarea mecanismelor de atribuire a cheilor de sesiune dintre

părţi.

Aceste reconstrucţii nu afectează comunicaţia curentă, dar sunt utilizate pentru atacuri viitoare sau alte practice înşelătoare.

2.3 Ameninţări împotriva integrităţii

O altă categorie de ameninţare VoIP o reprezintă ameninţarea împotriva integrităţii, care are, în cele mai multe cazuri, un impact sever asupra serviciului curent. Metoda de bază a ameninţării împotriva integrităţii este alterarea mesajelor (semnalelor) sau a traficului de voce după ce le-am interceptat pe reţea. Adică un atacator poate vedea toată semnalizarea şi fluxurile media dintre două staţii finale ca un intermediar. Alterarea poate consta în ştergerea, injectarea sau înlocuirea informaţiilor importante din mesajele sau media VoIP.

Ameninţările se impart în două mari categorii :

Ameninţări împotriva integrităţii mesajului (message alteration) Ameninţări împotriva integrităţii media (media alteration)

2.3.1Alterarea mesajului

Alterarea mesajului înseamnă că un atacator interceptează mesajele în timpul unei comunicaţii şi alterează informaţia pentru a reruta apelul; schimbă informaţia pentru a întrerupe serviciul şi asa mai departe. Exemplele specifice sunt rerutarea apelului şi “black holing”.

2.3.1.1Rerutarea apelului

Rerutarea apelului înseamnă schimbarea, în mod neautorizat, a direcţiei apelului prin alterarea informaţiei de rutare din mesajul protocolului. Rezultatul rerutării apelului este fie pentru a exclude entităţile legitime sau pentru a include entităţi nelegitime pe calea apelului sau pe mediul de transmisie. Figura 4.8 ilustrează exemplul includerii unei entităţi dăunătoare în timpul configurării apelului .

Figura 1.8 Rerutarea apelului

În figura 1.8 un atacator monitorizează mesajele de cerere apel (de exemplu, SIP INVITE) de la utilizatorul A spre un server de redicţionare (redirect server). Când utilizatorul A iniţiază un apel, telefonul IP trimite un mesaj INVITE serverului de redirecţionare precum în figura 1.9:

Figura 1.9 Mesaj SIP INVITE

Atacatorul detectează mesajul INVITE şi interceptează mesajul răspuns (care este, “302 Moved Temporarly”) de la serverul de redirecţionare, precum e ilustrat în continuare exemplul din figura 1.10.

Figura 1.10

Atacatorul înlocuieşte adresa IP a serverului proxy (10.1.1.10) din antetul Contact cu adresa serverului său proxy (172.26.1.10) şi trimite telefonului IP ceea ce e prezentat în figura 1.11 :

Figura 1.11

Telefonul IP trimite, de fapt, un nou mesaj INVITE serverului proxy al atacatorului în loc să trimită serverului legitim, iar serverul telefonului se bazează pe mesajul din figură. De acum înainte , atacatorul (situat la “mijlocul”comunicaţiei) poate vedea toate semnalele între două staţii finale şi le poate modifica în scopuri dăunatoare.

2.3.1.2 Apel fără destinaţie (Call black holing)

Apelul “spre nicăieri”, fără destinaţie, înseamnă orice metodă de ştergere sau refuzul de a trece mai departe orice elemente ale mesajelor dintr-o comunicaţie. Consecinţele a „call black holing” sunt : întârzierea stabilirii apelului, refuzul mesajelor ulterioare, erori ale unor aplicaţii, închiderea unor apeluri conectate şi asa mai departe.

Un atacator, ca intermediar, aruncă doar mesajele de confirmare (ACK) dintre entităţile apelului astfel încât dialogul SIP nu se poate realiza, chiar dacă ar putea deja exista trafic de voce prelimar între ele.

Un atacator ca intermediar şterge informaţia de sesiune media (SDP) din mesajul INVITE, care are ca rezultat: doar una dintre părţi poate să audă vocea sau deconectarea apelului.

Un atacator ca intermediar refuză să dea voie trecerii mai departe tuturor mesajelor spre un utilizator (victima) în aşa fel încât utilizatorul nu mai poate primi apeluri.

2.3.2 Modificarea media (media alteration)

Modificarea semnalelor de pe mediul de transmisie este ameninţarea prin care un atacator interceptează media în mijlocul unei comunicaţii dintre entităţi şi alterează informaţia media pentru a: injecta trafic neautorizat, degrada calitatea serviciilor, şterge informaţii importante, etc. Media poate fi doar voce

sau video,text,fax,imagine. Exemplul tipic îl reprezintă injectarea media sau degradarea ei.

2.3.2.1 Injectarea media (Media injection)

E metoda nelegitimă prin care un atacator injectează media nouă într-un canal activ sau înlocuieşte media din canalul respectiv. Consecinţa injectării de media este aceea că victima e posibil să audă zgomot, ,sau să nu audă nimic în receptor în timpul conversaţiei. Figura 1.12 ilustrează exemplul cu flux de voce.

Figura 1.12 Injectarea cu semnale

În figura 1.12 , utilizatorul A cu telefonul IP, apelează utilizatorul B care are un telefon PSTN conectat printr-un media gateway. După stabilirea apelului, telefonul IP trimite pachete de voce (RTP) la media gateway. Un atacator aflat “la mijloc” monitorizează secvenţa de numere RTP a pachetelor de voce şi ajustează secvenţa de numere a pachetelor nelegitime şi le injectează pe canalul de voce astfel încât vor ajunge înaintea pachetelor legitime. Utilizatorul B din PSTN aude vocea injectată.

2.3.2.2 Degradarea media (Media Degrading)

Este o metodă nelegitimă în care atacatorul manipulează media sau pachetele de control ale media (de exemplu RTCP) şi reduce calitatea serviciilor al oricărei comunicaţii. Câteva exemple sunt după cum urmează:

1. Un atacator interceptează pachetele RTCP ale comunicaţiei şi modifică (sau şterge) valorile statistice ale traficului media

(pierderea pachetelor, jiterul ) astfel încât un dispozitiv final nu poate controla media în mod eficient.

2. Un atacator interceptează pachete RTCP şi schimbă secvenţa de numere ale pachetelor astfel încât dispozitivul final va rula media cu secvenţa de numere greşită, ceea ce va degrada calitatea.

3. SCHIMBUL DE CHEI SDES, ZRTP şi MIKEY

Faţă de iniţierea şi descrierea sesiunii, schimbul de chei este un mecanism de securitate fundamental. Aşadar, voi descrie, în mod mai detaliat, protocoalele care schimbă chei specifice VoIP. Este esenţial de înţeles ce garanţie a securităţii oferă, pentru că, după cum voi demonstra mai jos, o nepotrivire între ceea ce aşteaptă protocolul la nivel transport şi proprietăţile de securitate asigurate de protocolul care face schimbul de chei creează o vulnerabilitate mare.

3.1 SDES

SDES este extensia cheii de transport a protocolului SDP. Asigură o cale de semnalizare şi negociază cheia(cheile) criptografică şi alţi parametrii ai sesiunii pentru fluxurile media în general , dar în mod special pentru SRTP. Atributul crypto pentru SRTP este definit ca a = crypto: <tag><crypto – suite ><key – params >[<session – params >]. Cea mai importantă componentă este key – params , care specifică una sau mai multe chei criptografice ca <key – method > : <key – info >. Singura metodă suportată pentru schimbul de chei este “inline” : care specifică ca însăşi cheia trebuie inclusă în textul în clar (plaintext). Cu alte cuvinte, cheia e integrată direct în ataşamentul SDP a unui mesaj SIP. Protecţia la nivel transport în SIP se poate face folosind fie TLS (daca protocolul de nivel transport este TCP), sau S/MIME . Utilizarea TLS e depreciată pentru ca TLS nu asigură protecţie punct-la-punct peste un lanţ de servere proxy. Mai mult, acesta presupune că următorul hop din lanţul de servere proxy SIP este de încredere. În schimb , S/MIME, asigură confidenţialitate punct-la-punct şi autentificare pentru „payload” codificate ca MIME.

Menţionez că S/MIME nu asigură „replay protection”. Prin urmare, dacă S/MIME este folosit pentru protecţia „payload” (care include cheia în plaintext), atunci aplicaţia trebuie să asigure o defensivă separată împotriva „replay attacks”. În general, majoritatea aplicaţiilor au o protecţie “replay” limitată pentru că necesită menţinerea stării, iar acest lucru duce la pierderea sincronizarea ceasului. În secţiunea 3.2, voi arată cum un atacator se poate folosi

de lipsa protecţiei “replay” în S/<MIME protejată SDES prin spargerea întregii securităţi a unei sesiuni SRTP.

3.2 ZRTP

ZRTP descrie extensia antentului a RTP pentru stabilirea unei chei de sesiune a SRTP folosind schimb de cheie autentificată Diffie-Hellman. O implementare a ZRTP există ca Zfone. Cea mai deosebită caracteristică a ZRTP este că nu necesită secrete partajate înainte sau existenţa unui infrastructuri de cheie publică separată (PKI). Acesta este un lucru important deoarece elimină nevoia unui server de încredere. Deoarece schimbul de chei Diffie –Hellman (DH) este adaptabil şi nu asigură protecţie împotriva atacurilor de tip “man-in-the-middle”, ZRTP foloseşte un SAS (Short Authentication String), care este de fapt un hash criptografic, format din două valori Diffie-Hellman pentru confirmarea cheii. Părţile comunicante confirmă verbal la telefon cheia stabilită, uitându-se la ecranul telefonului şi citindu-şi unul altuia valorile SAS afişate. După aceea se bazează pe înlănţuirea de chei : secretele partajate Diffie-Hellman ce au fost capturate în sesiunea anterioară sunt folosite pentru a autentifica sesiunea curentă.

Figura 2.0 Stabilire cheie de sesiune SRTP folosind ZRTP

Figura 2.0 ilustrează un schimb de chei ZRTP între utilizatorii Alice şi Bob. Mesajul HELLO conţine opţiunile de configurare SRTP şi ZID unic, care e generat o singură dată la instalare. Acest ZID va fi folosit de destinar pentru a recupera secretele partajate ce au fost stocate. Mesajele de tip “hello” şi “helloACK” sunt opţionale, iar o staţie finală poate iniţia direct o sesiune ZRTP prin trimiterea unui mesaj “COMMIT”. Expeditorul mesajului “commit” (Bob din exemplul nostru) este numit iniţiator, iar Alice receptor sau destinatar.

Mai jos se descrie schimbul Diffie-Hellman în detaliu punând accent pe câmpurile relevante ale mesajului, pe restul omiţându-le. În mesajul COMMIT, hash,cipher şi pkt se descrie hashul, criptarea şi algoritmii de cheie publică, aleşi de Bob din intersecţia algoritmilor din mesajele HELLO trimise şi primite. Bob alege un exponent aleator SVI şi calculează valoarea pvi=gSVImod p, unde g (generatorul grupului G Diffie-Hellman) iar p este determinat din valoarea pkt.hvi , numit „hash commitment”. Acesta este hashul valorii Diffie-Hellman generat de Bob, concatenat cu hash,cipher,pkt şi sas din mesajul de “hello” a lui Alice. De la primirea mesajului COMMIT, destinatarul, Alice, generează propriul secret Diffie-Hellman şi calculează valoarea publică corespunzătoare pvr. Fiecare secret deja partajat între Alice şi Bob are un ID, care este HMAC al stringului “Responder” calculat folosind acest secret ca şi cheie. Alice foloseşte ZID ul lui Bob pentru a recupera secretele partajate rs1 şi rs2. Bob răspunde mesajului DHPART1 a lui Alice în mod similar. La primirea mesajului DHPART2, Alice verifică dacă valoarea publică DH a lui Bob nu este egală cu 1 sau cu p-1. (RFC specifică că această verificare îngreunează atacul “man-in-the-middle). În secţiunea 3 se descrie cum un atacator poate executa cu succes un atac man-in-the-middle în ciuda protocolului folosit fără ca participanţii să îl detecteze ). Dacă verificarea valorii publice DH reuseşte , Alice calculează hashul valorii primite şi controlează dacă se potriveşte cu hvi primit în mesajul COMMIT. Dacă nu, Alice închide protocolul. Altfel, stochează IDurile secretelor partajate ce au fost primite din mesajul DHPART2 ca un set A.

Prin urmare Alice calculează setul de IDuri ale secretelor partajate care se aşteaptă să le primească de la Bob. Pentru fiecare secret, fiecare ID este calculat ca HMAC al stringului “Initiator”, criptat cu secretul însăşi. Fie B setul de IDuri aşteptate să fie primite. Alice apoi calculează intersecţia seturilor A şi B. Secretele corespunzătoare IDurilor în intersecţie sunt stocate ca setul D, sortate în ordine crescătoare. Specificaţiile dau voie în mod explicit acestui set de secrete partajate să fie gol. Cheia de sesiune finală este calculată ca hashul secretului Diffie-Hellman concatenat cu setul D de secrete partajate. În final, secretele partajate ce au fost capturate rs1 şi rs2 sunt actualizate ca rs2 = rs1 şi rs1 = HMAC (cheia de sesiune, “cunoscut şi ca textul în clar”) la ambele capete ale legăturii. Cheia principală (master key) şi cheia “salt” pentru sesiunea SRTP

sunt calculate ca HMAC al textelor în clar cunoscute folosind noua cheie de sesiune.

3.3 Multimedia Internet Keying

Mikey este un alt protocol de schimb al cheilor pentru SRTP. Poate opera în trei moduri diferite : cheie pre-partajată cu transportul cheii, cheie publică cu transportul cheii, cheie publică cu schimb de cheie Diffie-Hellman autentificată. O extensie ulterioară asigură schimbul DH în modul de cheie prepartajată. Un avantaj al protocolului MIKEY este acela că dă voie cheii să fie negociată ca parte a sarcinii utile a SDP în timpul configurării sesiunii SIP. În acest fel, nu apare supraîncărcare (overhead). Un dezavantaj evident este acela că necesită secrete partajate prealabil, sau PKI separat, însoţite de probleme precum alocarea certificatelor, anularea lor , etc.

3.4 Secure real-time transport protocol : SRTP

Datagramele VoIP sunt de obicei transportate folosind protocolul RTP(Real-time Transport Protocol). SRTP e un profil al RTP care doreşte să asigure confidenţialitate, autenficarea mesajului, şi protecţie “replay” traficului de voce şi a celui de semnalizare. SRTP foloseşte o singură cheie principală pentru a obţine material de criptare, prin intermediul unei funcţii hash. În SRTP, un context criptografic se referă la informaţia de stare criptografică menţinută de expeditor şi destinatar pentru fluxurile de voce si semnalizare. Acestea includ cheia principală,cheile de sesiune, identificatorii pentru criptare, algoritmii de autentificare, durata de viaţă a cheilor de sesiune şi un numărător „rollover”. (ROC). Fiecare pachet RTP constă într-o secvenţă de numere pe 16 biţi care creşte monoton. Counterul „rollover” este păstrat de receptor şi este incrementat cu 1 de fiecare dată când secvenţa de numere se incadrează în valoare. Pentru un flux multicast cu expeditori multipli, un identificator de sincronizare al sursei (SSRC-synchronization source identifier) identifică unic un expeditor dintr-o sesiune. Un context criptografic pentru SRTP este identificat de cele trei: SSRC, adresa reţea destinaţie, portul destinaţie.

Pentru criptarea datelor, SRTP foloseşte un singur cifru, Advanced Encryption Standard (AES), în următoarele două moduri: (a) Segmented Integer Counter mode, sau (b) modul f-8. Parametrii de intrare ai AES-ului o reprezintă tripla (cheie,SSRC,SEQ), unde “cheie” este cheia de criptare (explicată în continuare), SSRC este identificatorul de sincronizare al sursei şi SEQ – secvenţa de numere a pachetului. În loc să folosească AES ca un cifru bloc, SRTP îl foloseşte precum ar fi un cifru flux şi criptează datagramele. Acestea sunt făcute XOR cu ieşirea lui AES aplicată (cheie, SSRC, SEQ).

3.4.1 Obţinerea cheii SRTP

SRTP foloseşte o funcţie criptografică, securizată, pseudo-aleatoare (PRF) pentru a genera chei de sesiune pentru autentificare şi criptare din cheia principală, „master salt” şi secvenţa de numere. Secvenţa de numere al unui pachet este aleasă de expeditor. Ambele, cheia principală şi master salt sunt derivate în mod determinist folosind HMAC, criptat cu „materialul” ce a rezultat în timpul protocolului de schimbare a cheii, asupra unui text în clar ştiut.

Derivarea cheii de sesiune implică o etichetă pe 8 biţi, master salt ms , rata cheii obţinute (derivate), determinată de contextul criptografic şi indexul (ROC||SEQ pe 48 de biţi). || înseamnă concatenarea stringurilor. Fie x = (<etichetă>|| r) XOR ms, unde r este cîtul întreg obţinut prin împărţirea indexului la rata de derivare a cheii. Fie mk notată cheia principală şi PRF (k,x) o familie de funcţii pseudoaleatoare, precum cea pentru cheia secretă aleatoare k ; x dat de m-biţi, ieşirea este un string pe n-biţi. Cheile de sesiune sunt generate ca PRF(mk

, x) utilizând diferite etichete pentru criptare, autentificare şi respectiv pentru cheile „salt”. Este important de notat că numerele aleatoare nu sunt generate la receptor (receiver-generated randomness) în procesul de derivare a cheii de sesiune. Acest lucru ne va permite să întrerupem funcţionarea protocolului pentru că securitatea cifrului stream folosit la criptare în SRTP depinde în mod critic de unicitatea cheii flux. Acest lucru e accentuat de multe ori în specificaţiile SRTP, care avertizează despre pericolele “two-time pad” (un alt termen folosit pentru cheia flux).

Condiţia: cheia flux (stream) să nu se repete niciodată e reprezentată de faptul că ieşirea PRF(folosită ca intrare pentru AES) trebuie să nu se repete niciodată, pentru că celelalte intrări în AES – SSRC şi SEQ nu trebuie să fie unice global şi se pot repeta de la sesiune la sesiune. (SSRC trebuie să fie unic în sesiune, dar poate şi se va repeta de la o sesiune la alta dacă este implicat acelaşi destinatar). Mai mult, ambele valori sunt publice şi pot fi interceptate de atacator. Asta inseamnă că intrarea PRF trebuie să fie unică pentru fiecare sesiune. Prin urmare, cheia principală şi „master salt” trebuie să fie unice în fiecare sesiune. Într-adevăr, conform cu specificaţiile SRTP, “o cheie principală nu trebuie să fie partajată între sesiuni RTP diferite”. Amintim că atât cheia principală, cât şi master salt sunt derivate (obţinute) în mod determinist din materialul de cheie recepţionat în timpul schimbului de chei. Dacă un atacator reuseşte vreodată să pacălească sesiunea prin refolosirea materialul de cheie utilizat anterior, cheia principală se va repeta.

3.4.2 Algoritmul criptografic al SRTP

Figura 2.1 Algoritmul SRTP

3.5 Atacuri şi vulnerabilităţi ale SDES, ZRTP şi MIKEY

3.5.1 Atacuri asupra SIP

Denial of service: un astfel de atac se rezumă la aducerea reţelei în stadiul în care serviciul este indisponibil, de obicei prin redirecţionarea unui volum mare de trafic serviciului respectiv. Astfel acesta nu poate fi accesat de clienţii legitimi. Un DoS distribuit dă voie unui singur utilizator de reţea să provoace mai multe hosturi de reţea să supraîncarce cu trafic o ţintă. Un atac distribuit Dos e uşor de lansat pe o arhitectura SIP. Un atacator poate pune adresa IP a victimei într-un “Router header request” falsificat şi o trimite mai multor proxy-uri, care vor amplifica cu mult numărul de mesaje returnate victimei.

Reflection este un alt mod de a organiza un atac DoS. Un atacator poate trimite cereri falsificate unui număr mare de elemente SIP şi servere proxy, punând adresa victimei în câmpul sursă. Fiecare destinatar va genera un răspuns, supraîncărcând victima cu trafic. O protecţie, limitată, împotriva cererilor SIP falsificate poate fi asigurată de IPsec, dar IPsec punct-la-punct este greu de implementat într-un mediu tipic VoIP deoarece staţiile finale (telefoanele IP sau softphone-urile) sunt dinamice ca locaţie. Un alt inconvenient este că nu e foarte clar din specificaţii cum SIP interoperează cu IPsec.

O altă vulnerabilitate importantă în SIP o reprezintă faptul că cererile BYE pentru terminarea sesiunilor nu sunt autentificate din moment ce nu sunt recunoscute (ACK). În schimb, o cerere BYE este autentificată implicit dacă este primită de la acelaşi dispozitiv din reţea (pe aceeaşi cale) ca INVITE precedent. O a treia parte, un atacator, poate vedea parametrii unui mesaj INVITE, ce pot fi interceptati, iar apoi să insereze o cerere BYE în sesiune. Odată ce cererea BYE este recepţionată de ţintă, sesiunea va fi distrusă permanent. Atacuri similare pot fi lansate pe mesaje de tip re-INVITE utilizate la schimbarea parametrilor unei sesiuni. O varietate largă de atacuri DoS devin posibile dacă cererile de înregistrare nu sunt autentificate cum trebuie de către serverele ‘registrar’. Dacă un utilizator rău intenţionat este capabil să înlăture înregistrarile unora sau a tuturor utilizatorilor din reţea şi să-şi înregistreze dispozitivul lui în numele lor, poate foarte uşor să interzică accesul acestor utilizatori/servicii. Atacatorii pot de asemenea să încerce să epuizeze resursele de stocare sau serverul registrar prin crearea unui număr mare de legături. Înregistrarea SIP nu necesită ca ceea ce conţine câmpul From dintr-un mesaj să fie identic cu antetul To al cererii, astfel dând libertatea unei a treia părţi să modifice adresa-de-înregistrare a legăturilor în numele altui utilizator. Dacă atacatorul îşi însuşeşte, cu succes, o parte autorizată care să modifice contactele în numele unui utilizator, el poate arbitrar să modifice adresa-de-înregistrare a legăturilor pentru adresa asociată To. Din moment ce autentificarea SIP se

bazează implicit pe autenficarea serverului şi a proxy-urilor intermediare, atacatorul care e în stare să îşi însuşească pe deplin un server sau un proxy poate crea daune, inclusiv DoS clientului sau lansarea unui atac DoS distribuit. Aceasta necesită existenţa unei metodologii a clientului de a autentifica serverul şi/sau proxy-ul. Din nefericire, nu există un astfel de mecanism specificat în RFC al SIP.

3.5.2 Atacuri asupra SDES/SRTP

Figura 5.2 descrie un atac asupra SRTP când e folosit în combinaţie cu schimbul de cheie SDES. Presuspunem 2 utilizatori legitimi, Alice şi Bob, care anterior au efectuat cu succes o sesiune VoIP pe care atacatorul a interceptat-o pasiv; fără să înveţe cheia de sesiune şi fără să fie în stare să decripteze fluxurile de date. Considerăm că Bob a iniţiat sesiunea şi că SDES a fost utilizat pentru transportul „SRTP key material”. Pentru a asigura confidenţialitate mesajului SDES, S/MIME a fost folosit pentru a cripta „payload”. S/MIME, în general, este preferat peste TLS pentru protecţia mesajelor SDP deoarece: a) S/MIME conferă integritate şi confidenţialitate punct-la-punct, iar b) S/MIME nu necesită ca proxy-urile intermediare să fie de încredere.

S/MIME nu oferă protecţie “anti-replay”. După ce sesiunea originală a fost coruptă, atacatorul poate să redea mesajul original INVITE a lui Bob spre Alice, conţinând un ataşament SDP criptat S/MIME cu mesajul de transfer a cheii SDES. (figura 5.2 arată cum sesiunea rulează în mod concurent, atacul nu trebuie să fie unul adaptiv; o sesiune se poate executa după cealaltă.). Din moment ce Alice nu menţine nicio stare a SDP, ea nu va fi în stare să detecteze reluarea mesajului. Folosind „key material” (fragmente/porţiuni) a vechii sesiuni precum cheia ei HMAC, va deriva exact aceeaşi cheie principală şi „master salt” ca în sesiunea originală. Din moment ce SSRC şi SEQ sunt la fel, cheia de criptare a sesiunii ce a rezultat va fi la fel ca în sesiunea anterioară. De asemenea cheia flux generată prin aplicarea AES la triplul (cheie, SSRC, SEQ) va fi identică cu cea din sesiunea originală.

Criptarea în SRTP o reprezintă simplul XOR al fluxului de date cu cheia flux. Dacă Alice trimite acum o datagramă în noua sesiune pe care crede că a stabilit-o cu Bob, atacatorul poate face XOR cu fluxul de date criptate pe care le interceptează în sesiunea originală. Cheia flux va fi neutralizată, iar rezultatul va fi XOR-ul a două fluxuri de date. Dacă fluxul de date rezultat conţine suficientă redundanţă sau atacatorul poate ghici părţi din flux, va fi capabil să reconstruiască complet sau parţial datele ambelor fluxuri.

Figura 2.2 Atac asupra SRTP folosind schimbul de cheie SDES

În orice caz, criptarea a fost eliminată şi atacatorul obţine un xor pe biţi a două payloduri. Din moment ce datagramele VoIP au o redundanţă crescută, şi payloadurile sunt cel puţin la fel de predictibile ca datagramele iniţiale (exemplu, majoritatea conversaţiilor încep cu un “Hello”, a cărui codare digitală e predictibilă, chiar dacă luăm în considerare variaţiile de accent şi pronunţie) trebuie avut în vedere că este o breşă mare de securitate. Acest atac este similar ca existenţă faimosului atac pe 802.11 WEP, care dădea voie atacatorului să obţină un XOR al pachetelor wireless. În cazul WEP, cheia flux era refolosită din cauza epuizării vectorilor de iniţializare pentru cifrul flux. Cea mai importantă observaţie bazată pe atacul nostrum este aceea că SRTP nu foloseşte niciun fel de aleatorism la recepţie când destinatarul derivează cheile de sesiune, chiar dacă designerii SRTP au fost avertizaţi de pericolul refolosirii cheii principale. Specificaţiile SRTP subliniază nevoia unui mecanism de management automat al cheii, din moment ce managementul manual al cheii este mai predispus la refolosirea acesteia. Printre protocoalele de management automat al cheii compatibil cu SRTP se numără MIKEY, SDES şi ZRTP.

Chiar dacă MIKEY a fost făcut special ca protocolul de schimb al cheii pentru SRTP, multe implementări VoIP folosesc în schimb SDES. Din aprilie 2007, produsele care se bazează pe combinaţia SDES/SRTP includ: softul PBX(Private Branch Exchange) din pbxnsip, controlere de frontieră a sesiunii VoIP şi firewalls SIP de la Convergence şi Ingate Systems, iar softul pentru

telefon eyeBeam de la CounterPath. În timp ce MIKEY conţine protecţie built-in şi anti-replay şi astfel pare potrivit pentru stabilirea cheilor SRTP, analiza de mai sus demonstrează ca SDES nu este. Unele implementări SRTP pot conferi măsuri adiţionale pentru prevenirea refolosirii cheii, dar implementarea libsrtp se bazează complet pe protocolul de schimbare a cheii pentru a asigura un nou key material. Pentru a preveni refolosirea cheii flux, destinatarul SRTP ar trebui să folosească propriul nou aleatorism ca parte a procesului de derivare. Exemplu, ca intrare la HMAC folosit în procesul de derivare a cheii. Acest aleatorism nu trebuie să fie secret. Poate să fie comunicat public emiţătorului ca parte a sesiunii SRTP stabilită, pentru a asigura că acesta derivă acelaşi set de chei de sesiune.

În ansamblu, SRTP este un protocol bine proiectat, dar există motive practice de ce a fost ales AES în “counter mode” ca generator de cheie flux în SRTP. Precum autorii SRTP repetă de multe ori în specificaţiile protocolului: este critic ca numărătorul (counter) să nu se repete niciodată. Pentru ca protocolul să fie securizat (protejat), combinaţia cheie AES /salt trebuie să fie unică chiar peste sesiuni multiple. În SRTP, această responsabilitate este implicit delegată protocolului de schimbare a cheii. Chiar şi FAQ al SRTP spune că doar cheile “pot fi furnizate prin intermediul semnalizării şi pot fi exprimate folosind descrieri de securitate SDP (dacă semnalizarea este protejată criptografic) sau MIKEY […]”. Din păcate, protecţia criptografică în absenţa protecţiei „replay” nu este suficientă pentru a garanta unicitatea cheilor peste sesiuni multiple, rezultând combinaţia: schimb de cheie şi cifru flux potenţial vulnerabilă.

3.5.3 Atacuri asupra ZRTP

Denial of service. ZRTP este potenţial vulnerabil la atacuri de tip DoS cauzate de atacatori care trimit mesaje HELLO false terminalelor. Ca răspuns fiecărui HELLO, o staţie finală ZRTP creează o conexiune parţial deschisă şi păstrează parametrii în memorie. În cele din urmă, va rămâne fără spaţiu de stocare, iar cererile ulterioare de la clienţi legitimi vor fi refuzate.

Autentificare. Principalul avantaj al ZRTP este acela că evită necesitatea unui “trust” global care să fie asociat cu infrastructura de cheie publică. ZRTP îşi propune să realizeze acest lucru cu ajutorul SAS (Short Authentication String), care este esenţial un hash criptografic (o cheie) de valori Diffie Hellman împreună cu alte secrete pre-partajate. După ce secretele partajate au fost folosite pentru autentificare într-o sesiune, sunt actualizate cum e descris în secţiunea 5 şi ţinute de către participanţi pentru autentificare în următoarea sesiune. Pentru a autentifica participantul de la celălalt capăt al unei sesiuni VoIP, valoarea SAS este citită cu voce tare pe conexiunea de voce. Totuşi,

autentificarea bazată pe SAS necesită o mică interfaţă grafică sau un display disponibil utilizatorului. Aceasta este o problemă pentru multe dispozitive VoIP securizate. Exemplu, terminalele dintr-o reţea VoIP printr-un proxy local, care nu are ecran. Prin urmare, analiza ZRTP se concentrează în situaţia în care utilizatorul nu poate verifica SAS cu ajutorul conexiunii de voce.

Autentificarea în ZRTP este bazată pe ipoteza că, pentru a lansa cu succes un atac de tip “man-in-the-middle” asupra unei perechi de participanţi care deja au efectuat multe sesiuni, atacatorul trebuie să fie prezent în fiecare sesiune, chiar începând cu prima. Raţionamentul este după cum urmează. Fiecare utilizator ZRTP reţine secretele partajate rs1 şi rs2 (vezi secţiunea 3) pentru utilizatorii cu care comunicase anterior. Când iniţiază o nouă sesiune, utilizatorul trimite ZID-ul lui, care este folosit de destinatar pentru a obţine setul de secrete partajate asociate acestui ZID. Cheia de sesiune este calculată prin hashingul valorii comune Diffie-Hellman concatenat cu secretele partajate. Prin urmare, chiar dacă schimbul de chei DH este compromis, atacatorul tot nu poate calcula cheia de sesiune deoarece nu ştie secretele partajate. Pentru că secretele partajate sunt recalculate după fiecare sesiune, atacatorul trebuie să fie prezent în fiecare sesiune începând chiar cu prima în care nu există secrete partajate. Din nefericire, acest raţionament este eronat. Principala problemă în legătură cu protocolul sunt ZID-urile, care sunt folosite de destinatari pentru a căuta secretele partajate. Acestea sunt autentificate destul de devreme în protocolul de schimbare a cheii. Considerăm un atacator pasiv care înterceptează sesiunea dintre Alice şi Bob şi invaţă ZID-ul lui Bob. Atunci lansează un atac „man-in-the-middle” precum în figura 5.3

Atacatorul alege exponenţi aleatori x’ , y’ şi calculează x=gx’ mod p şi respectiv y = g y’ mod p. Z este hashul lui x concatenat cu setul de algoritmi aleşi de Bob pentru sesiunea ZRTP. De asemenea, atacatorul înlocuieşte toate ID-urile secretelor partajate cu numere aleatoare. Când Alice primeşte mesajul DHPART2 de la Bob, ea preia setul de secrete care le partajează cu Bob şi calculează setul de ID-uri aşteptat. Din moment ce atacatorul a înlocuit toate ID-urile cu numere aleatoare, acestea nu vor corespunde. Specificaţiile protocolului dau voie în mod special ca setul de secrete partajate să fie gol : “secretul partajat final, s0, este calculat prin hashurirea secretelor partajate DH concatenate (DHSS), urmate de setul de secrete partajate (posibil goale) care sunt de fapt partajate între iniţiator şi receptor”.

Figura 2.3 Atac asupra ZRTP de tip „man in the middle”

Specificaţiile nu impun ca Alice să oprească protocolul, dar în schimb o instruiesc să calculeze valoarea comună Diffie Hellamn ca ysvr mod p (= g y’ * svr

mod p). Cheia de sesiune este acum calculată ca hash obţinut doar din valorea comună DH, deoarece Alice crede că nu mai are secrete partajate cu Bob. Similar, Bob calculează cheia de sesiune ca hash a valorii Diffie-Hellman gx’ * svi

mod p. Atacatorul ştiind ambele valori poate calcula cheia principală SRTP şi “master salt”. Astfel poate sparge complet criptarea SRTP. O discuţie neoficială din specificaţiile protocolului spune că “dacă pierdem vreodată acest secret partajat ce a fost stocat, nu mai este valabil pentru autentificarea schimbului DH, deci va trebui să facem o nouă procedură SAS şi va trebui să începem cu un nou secret partajat stocat”. În primul rând, acest lucru este incompatibil cu specificaţiile actuale, care permit setului de secrete partajate să fie gol în timpul derivării cheii. În al doilea rând, nu este deloc clar se implementează, din moment ce specificaţiile spun că “SAS este mai uşor de implementat când un GUI sau un mic ecran este disponibil, care ridică intrebarea ce să facem când nu avem ecran. Ne imaginăm nişte produse care implementează VoIP securizat printr-un proxy local, dar care nu dispun de ecran în cele mai multe cazuri” .

Chiar dacă Alice se opreşte din a comunica cu Bob când setul de secrete partajate este gol (subliniem din nou că nu e ceea ce specificaţiile prevăd), acest atac devine un atac DoS foarte eficace, care dă voie atacatorului să spargă orice sesiune efectuată între dispozitive VoIP fară ecran. În general, afirmaţia din specificaţii că atacatorul este forţat să rezolve multiple probleme ( precum “ furtul secretului partajat ale uneia dintre părţi, să fie prezent chiar de la prima sesiune şi apoi la toate sesiunile ulterioare pentru a putea executa un atac “man-in-the-middle”, să rezolve problemele înregistrărilor separate), nu pare să fie confirmată. Nu este clar dacă problema poate fi rezolvată. În absenţa fie a PKI sau a secretelor pre-partajate, fie a opţiunii dispozitivului pentru confirmarea “out-of-band” a cheii prin citirea hashurilor cheie între ei, este greu de văzut cum părţile pot efectua un schimb de cheie autentificat.

3.6 Analize formale (neoficiale) a ZRTP în AVISPA

Pentru a suporta analiza ZRTP, s-a construit un model formal al protocolui în High Level Protocol Specification Language (HLPSL) şi e folosit modelul automat de verificare AVISPA. Verificările formale a ZRTP cu AVISPA prezintă o provocare interesantă deoarece modelul trebuie capturată natura “multi-session” a autentificării în ZRTP. Autenficarea în sesiunea ZRTP depinde de informaţia schimbată în sesiunile anterioare. HLPSL, totuşi, nu permite ca starea să fie păstrată peste mai multe sesiuni.

Pentru ca modelul de analizat să funcţioneze, trebuie să presupunem că pentru o sesiune dată, iniţiatorul şi receptorul convin asupra valorii secretelor partajate la începutul sesiunii. Aceasta ne permite să modificăm protocolul prin trecerea secretelor partajate ca argumente folositoare specificaţiilor, în cadrul secţiunii: rolurile iniţiatorului şi receptorului. De asemenea, presupunem că nu există alte secrete partajate între participanţi. Se modifică doar câmpurile relevante din corpul mesajelor. Pentru a simplifica prezentarea, arătăm specificaţiile în notaţia „Alice-Bob”

Figura 2.4 Negocierea dintre Alice şi Bob

În figura 2.4 K reprezintă cheia de sesiune partajată, care e calculată precum e descris în secţiunea 5. H() este o funcţie hash, iar MAC(k, text) este un cod de autentificare criptat, calculat în text folosind cheia de autentificare k. rs1Idi, rs2Idi (rs1IDr, rs2IDr) sunt HMACurile criptate ale stringurilor “iniţiator” şi “receptor” ce sunt calculate folosind secretele partajate rs1 şi respectiv rs2. C1 şi C2 sunt constante publice. Intuitiv, autentificarea rezistă pentru o sesiune particulară între Alice şi Bob dacă următoarele condiţii sunt îndeplinite: la finalul unei sesiuni încheiate cu succes, dacă Alice crede că vorbeşte cu Bob, atunci ea într-adevăr vorbeşte cu acesta dacă mesajele de înregistrare respective, trimise şi primite în timpul execuţiei protocolului se potrivesc. Condiţia pentru Bob este similară.

3.7 Analiza lui MIKEY

Secretizare. Scopul protocolului de schimbare a cheii securizate din punct de vedere criptografic este să stabilească o cheie de sesiune care e imposibil de distins de un şir de biţi aleator de către oricine altcineva decăt cei participanţi. Este uşor de observat că MIKEY nu satisface această cerinţă când e executat în modul Diffie-Hellman. Cheia partajată este derivată ca gx1*xr . Valoarea comună Diffie-Hellman este folosită direct ca şi cheie. În multe grupuri Diffie-Hellman, exemplu în grupul de pătrate modulo - un număr mare prim, testarea apartenenţei la grup nu e o problemă greu de calculat: este suficient să calculăm simbolul Jacobian. De aceea, este uşor să identificăm diferenţa dintre şirul de biţi aleator şi cheia.

Schemele de criptare în care cheia derivată este destinată folosirii în mod tipic necesită îndeplinirea condiţiei: cheia să fie imperceptibilă de o valoare aleatoare. Acesta este un alt exemplu în care ipotezele făcute la un nivel al stivei de protocoale VoIP (nivelul transport în acest caz ) nu sunt îndeplinite de un alt nivel (nivelul de schimb al cheii). Dar valoare comună Diffie-Hellman derivată în MIKEY nu ar trebui să fie trunchiată(hashed) oricum înainte ca de fapt să fie folosită ca şi cheie ? Ba da, dar acest lucru nu este de ajuns. O aplicare simplă a unei funcţii hash deterministe asupra valorii comune Diffie Hellman nu demonstrează producerea unui rezultat care să fie imposibil de distins de unul aleator. În schimb, în protocoale ca TLS şi IKE, cheia e derivată prin aplicarea hash valorii Diffie-Hellman împreună cu nişte valori aleatoare (de autentificare) generate de unul sau ambii participanţi. Există o soluţie standard simplă. Pentru a deriva o cheie din valoarea comună Diffie-Hellman, participanţii MIKEY ar trebui să urmeze abordarea utilizată în TLS şi IKE şi să folosească un extractor de aleatorism; exemplu, funcţia universală hash cu aleatorism public generat de unul sau ambii participanţi. În cele din urmă, se observă că MIKEY în modul de cheie pre-partajată, evident că nu satisface perfect redirecţionarea secretizării deoarece compromiterea secretului pre-partajat conduce la compromiterea tuturor sesiunilor anterioare.

Denial of service. MIKEY oferă o protecţie limitată împotriva atacaturilor de tip DoS. În modul de cheie publică DH, destinatarul efectuzează operaţii “CPU-intensive modular exponentiation” după verificarea rezumatului mesajului (digest) al iniţiatorului. Atacatorul poate încă supraîncărca cu trafic receptorul cu multiple copii ale aceluiaşi mesaj sau cu mesaje conţinând „digest” incorect. Acest lucru va provoca destinatarul să execute un număr mare de verificări digest şi va suprasatura resursele memoriei.

4. ZRTP : UN NOU CONCEPT PENTRU SECURIZAREA VOIP

În acest capitol se prezintă un protocol nou ZRTP (Zimmerman Real Time Transport Protocol) util pentru securizarea apelurile VoIP. Un sistem VoIP transmite voce peste reţele cu comutaţie de pachete precum internetul. Când securitatea este adăugată unui sistem VoIP, calitatea apelului VoIP este afectată. Paragraful explică arhitectura protocolului ZRTP în detaliu şi evaluează de asemenea performanţa unui sistem VoIP după ce a fost implementată securitatea. Studiul este făcut în laborator folosind un server SIP bazat pe asterisk, telefoane client X-Lite Soft, aplicaţie Zfone şi un analizor de trafic : Wireshark. Aplicaţia Zfone este folosită pentru implementarea ZRTP pe staţiile finale. Rezultatele obţinute au fost analizate şi comparate cu cele realizate pentru apeluri nesecurizate. Observăm că ZRTP a indus un jiter mediu de 2.28 ms. Valoarea jiterului calculată pentru ZRTP este apoi comparată cu valoarea pentru apel nesecurizat care este 2.17 ms.

Rezultatul arată că valoarea jiterului este puţin mărită după implementarea protocolului ZRTP.Acesta este un protocol la nivel aplicaţie care nu este dependent de dispozitivele intermediare şi de asemenea nu este limitat la un număr de apeluri. Aşadar ZRTP reprezintă o metodă de securitate mai potrivită pentru securizarea fluxurilor media de VoIP datorată utilizării eficiente a lărgimii de bandă.

4.1Arhitectura ZRTP (Zimmermin RTP)

ZRTP dezvoltat de către Phil Zimmermin asigură confidenţialitate, autentificare şi integritate între două staţii finale VoIP care comunică. ZRTP utilizează mecanismul de schimbare a cheilor Diffie-Hellman pentru a dobândi o cheie comună între cele două părţi participante la comunicaţie. Schimbul de chei apare după ce semnalizarea a avut loc (SIP şi SDP). Mesajele ZRTP sunt încorporate în pachete RTP ca o extensie. Aceste extensii sunt ignorate de către staţiile finale până când acestea suportă ZRTP. In ambele staţii finale aparţinând sesiunii suportă ZRTP, are loc un schimb de chei Diffie – Hellman pentru a se hotărî cheia de sesiune. După un proces de „handshake” efectuat cu succes între cele două staţii finale, fluxurile de pachete RTP sunt criptate ca RTP securizat. (SRTP – Secure RTP).

Figura 3.0 Schimb de pachete ZRTP

4.1 Pachetul ZRTP de tip “hello”

În primul rând pachetul Hello este trimis de către cel care iniţiază apelul spre apelatul participant. Formatul pachetului ZRTP Hello este ilustrat în figura 3.1 Versiunea protocolului este 1.10 şi pentru integritate este folosită funcţia hash SHA-256. Pentru criptare este folosit algoritmul AES-CM cu cheie pe 128 de biţi (Advanced Encryption Standard-Counter Mode). Cele două chei SAS (“short authentication string”) sunt folosite pentru verificare, între cel care trimite şi cel care recepţionează.

Figura 3.1 Pachet ZRTP de tip HELLO

4.2Pachet ZRTP Commit

Fie expeditorul sau receptorul pot iniţia schimbul de chei prin intermediul unui mesaj COMMIT. Figura 3.2 ilustrează formatul pachetului ZRTP commit. E folosită cheie pe 128 de biţi pentru AES-CM si autentificare SAS pe 256 biţi.

Figura 3.2 Pachet ZRTP de tip COMMIT

4.3 Pachetul ZRTP Dhpart1

Când pachetul COMMIT este recepţionat, solicitantul trimite mesajul Dhpart1 iniţiatorului. Formatul pachetului ZRTP Dhpart1 este prezentat în figura 3.3 Valoarea criptată a funcţiei hash este ilustrată şi sunt folosite două rs ID pentru acest pachet. Ultima valoare din figură arată că valoarea sumă de control (checksum) este corectă. Secvenţa de numere utilizată pentru acest pachet este 57440.

Figura 3.3 Pachet ZRTP de tip DHPart1

4.4Pachetul ZRTP de confirmare

Figura 3.5 ilustrează un pachet de confirmare ZRTP. Secvenţa de numere folosită în acest pachet este 57450. Când pachetul de confirmare este recepţionat, traficul de voce este criptat înainte să fie trimis destinatarului. Cercul roşu indică faptul ca datele sunt criptate înainte să fie trimise.

Figura 3.5 Pachet ZRTP de tip Confirm1

O librărie libZRTP a fost dezvoltată şi implementată într-un utilitar numit Zfone. Zfone este dezvoltat de Phil Zimmermann şi este o soluţie de securitate pentru comunicaţia VoIP. Zfone se bazează pe un protocol nou, Z Real-Time Transport Protocol (ZRTP). Zfone este un serviciu de securitate nou care se află în vârful stivei TCP/IP. Oricând un nou apel VoIP este negociat, Zfone preia controlul fluxului VoIP negociind o nouă cheie de criptare între părţile comunicante şi apoi criptează pachetele VoIP. Zfone foloseşte o metodă inovatoare de autentificare : un SAS (short authentication string) este generat în timpul schimbului de chei Diffie-Hellman. Dacă stringul generat la fiecare capăt este diferit, părţile care comunică pot presupune că schimbul de chei Diffie-Hellman a fost modificat. Figura 3.6 ilustrează comunicaţia între două staţii finale cu ZRTP.

Reţea

VoIPProxy

Arhitectura ZRTP

zfone zfone

SIPSIP

Utilizator A local Utilizator B la distanţă

Figura 3.6 Arhitectura ZRTP

4.5 RTP (Real Time Transport Protocol )

RTP specificat de IETF în RFC 3550&3551 este un protocol de transport media foarte simplu şi este folosit aproape în toate sistemele VoIP. RTP este implementat peste UDP; acesta fiind un protocol de tip “best-effort” nu garantează livrarea pachetelor la destinaţie. În comunicaţia în timp real este mai bine să pierzi pachete decât să le retransmiţi ulterior. Partea utilă a mesajelor RTP conţine codecul traficului de voce care descrie calitatea şi eroarea admisă a fluxului. Sunt folosiţi diverşi algoritmi de corecţie pentru scăderea numărului de pachete pierdute. Cerinţele benzii depind de calitatea codecului şi rata de compresie. Unele codecuri şi aplicaţii creează fluxuri RTP cu pachete mari, iar altele cu pachete mici sau medii. RTP foloseşte temporar porturile UDP care sunt negociate de procotolul de semnalizare apel. De exemplu porturile RTP sunt transportate în „message bodies” SDP (Session Description Protocol) alături de SIP, iar porturile UDP sunt transportate pe canalul de control apel H.245 cu H.323.

4.6 RTCP (Real Time Control Protocol)

RTCP este un canal de comunicaţie secundar care este folosit cu RTP, dar nu este esenţial pentru ca fluxurile RTP să funcţioneze. RTCP este folosit pentru a schimba informaţii de sesiune RTP. Când apelul e pus în aşteptare sau nu vorbeşte nimeni nu va fi trafic RTP, dar traficul RTCP se va transmite continuu între cei care comunică. Mesajele RTCP folosesc aceeaşi rută dar nu sunt de încredere (trusted) pentru că sunt provenite de la terminal. Dacă RTCP e folosit corect atunci ajută la colectarea datelor despre calitatea conexiunii. RTCP asigură informaţii despre jiter, întârziere şi pierderea de pachete.

5. BIBLIOGRAFIE

[1]S. Tanenbaum, Reţele de calculatoare, Editura Computer Press Agora, Târgu-Mureş, 2004

[2]T. Rădulescu, Reţele de telecomunicaţii, Ed. Thalia, Bucureşti, 2002

[3]Fred Halsall, Computer Networking and the Internet, Addison-Wesley, 2005

[4]Anders Olsson, Understanding Changing Telecommunications, Wiley, 2004

[5]Muhammad Tayyab Ashraf, ZRTP: A New Approach to Secure VoIP calls, Canadian Journal on Network and Information Security Vol.1 , No.6, August 2010.

[6]Matthew Ruck, Top Ten Security Issues with Voice over IP, designDATA, 2010

[7]Cisco Systems, Cisco IP Phone Authentication and Encryption for Cisco CallManager 4.0(1), San Jose, 2003

[8]Cisco Systems, Configuring Security, San Jose, November 2011.[9]Cisco Systems, Configuring SIP Support for SRTP, San Jose,

September 2012[10] Cisco Systems, Media Authentication and Encryption Using

Secure RTP on Cisco Multiservice and Integrated Services Routers, CiscoPress, 2005

[11] Akhil Behl,Securing Cisco IP Tehephony Networks, Indianapolis-Indiana, CiscoPress, 2013

[12] Kevin Wallace, CCVP CIPT, Indianapolis-IN , 2007[13] Jeremy Cioara, Michael Valentine, CCNA Voice 640-461 Official

Certification Guide Second Edition, Indianapolis – Indiana, 2012