ATACURI I AMENINRI ASUPRA SERVICIULUI VoIP

Cuprins
1. INTRODUCERE N REELELE DE COMUNICAII ................................................ 10
1.1 EVOLUIA ..................................................................................................................................................... 10 1.2 VOICE OVER INTERNET PROTOCOL (VOIP) ................................................................................................... 11

2. ATACURI I AMENINRI ASUPRA SERVICIULUI VOIP ................................... 11

2.1 AMENINRI MPOTRIVA DISPONIBILITII .................................................................................................. 11

2.1.1 Suprancrcarea cu apeluri (Call Flooding) ............................................ 12 2.1.2 Mesaje corupte (Protocol Fuzzing) ......................................................... 14 2.1.3 MESAJE FALSIFICATE........................................................................ 16 2.1.4 Deturnarea apelului (Call Hijacking) ...................................................... 18 2.1.5 Interceptarea nregistrrilor ..................................................................... 18 2.1.6 Interceptarea sesiunii media (Media session Hijacking) ........................ 19 2.1.7 Preluarea identitii serverului (server impersonating) ........................... 20 2.1.8 Deteriorarea calitii serviciilor (QoS Abuse ) ...................................... 21
2.2 AMENINRI MPOTRIVA CONFIDENIALITII ............................................................................................. 22

2.2.1 Interceptarea media (Eavesdropping Media) .......................................... 22 2.2.2 Call Pattern Tracking ........................................................................... 23 2.2.3 Exploatarea datelor (Data Mining) ......................................................... 25 2.2.4 Reconstrucie ........................................................................................... 25
2.3 AMENINRI MPOTRIVA INTEGRITII ........................................................................................................ 26

2.3.1Alterarea mesajului .................................................................................. 26 2.3.2 Modificarea media (media alteration) ..................................................... 28

3. SCHIMBUL DE CHEI SDES, ZRTP I MIKEY ....................................................... 30
3.1 SDES............................................................................................................................................................ 30 3.2 ZRTP............................................................................................................................................................ 31 3.3 MULTIMEDIA INTERNET KEYING .................................................................................................................. 33 3.4 SECURE REAL-TIME TRANSPORT PROTOCOL : SRTP ..................................................................................... 33

3.4.1 Obinerea cheii SRTP .............................................................................. 34 3.4.2 Algoritmul criptografic al SRTP ............................................................. 34
3.5 ATACURI I VULNERABILITI ALE SDES, ZRTP I MIKEY ...................................................................... 36

3.5.1 Atacuri asupra SIP................................................................................... 36 3.5.2 Atacuri asupra SDES/SRTP .................................................................... 37 3.5.3 Atacuri asupra ZRTP............................................................................... 39
3.6 ANALIZE FORMALE (NEOFICIALE) A ZRTP N AVISPA ............................................................................... 42 3.7 ANALIZA LUI MIKEY ................................................................................................................................... 43

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

4.1ARHITECTURA ZRTP (ZIMMERMIN RTP) ...................................................................................................... 44 4.1 PACHETUL ZRTP DE TIP HELLO ................................................................................................................ 45 4.2PACHET ZRTP COMMIT ................................................................................................................................ 46 4.3 PACHETUL ZRTP DHPART1 .......................................................................................................................... 46 4.4PACHETUL ZRTP DE CONFIRMARE ................................................................................................................ 47 4.5 RTP (REAL TIME TRANSPORT PROTOCOL ) .................................................................................................. 48 4.6 RTCP (REAL TIME CONTROL PROTOCOL) .................................................................................................... 48

5. BIBLIOGRAFIE ................................................................................................................ 49

1. INTRODUCERE N REELELE DE COMUNICAII

1.1 Evoluia

Evoluia rapid a staiilor de lucru i a calculatoarelor personale la platforme cu putere mare de calcul i capaciti mul timedia, dezvoltarea tehnologiilor de reea i progresul din domeniul procesrii de semnal i al programrii au dus la o explozie a aplicaiilor multimedia de timp real. Mult timp s-a crezut c ATM va fi tehnologia de reea care va integra toate serviciile , considerndu-se reelele deja existente de voce i de date dedicate unui singur serviciu. S-a dovedit a fi un punct de vedere greit. Protocolul IP motenete o mare parte din deficienele sistemului dezvoltat n anii 70. Astfel, calitatea serviciului variaz foarte mult. Sunt momente cnd ea este rezonabil, dar i momente cnd devine intolerabil din punct de vedere al unei aplicaii de timp real. Se ntmpl uneori s apar pierderi de pachete de 30-40%, fcnd imposibil o comunicaie de voce sau o video-conferin. Noile reele de date trebuie s asigure, pe lng viteza de transmisie ridicat, banda larg, managementul resurselor, scalabilitate i integrarea diverselor tehnologii de access (LAN, HDSL, ADSL, TDM etc.). De aceea au aprut noi cerine de performan i de funcionalitate pentru reelele de date actuale. Datorit faptului c resursele reelelor de date sunt limitate, acestea trebuie gestionate cu grij pentru a obine performane i randa mente ridicate. Aceast mprire pe nivele face mai uoar gestionarea i proiectarea arhitecturilor reelelor de date, precum i migrarea ctre noi tehnologii prin etape de integrare pe nivele funcionale. Principalele caracteristici arhitecturale i de funcionalitate ale unei reele moderne sunt: Structurare pe nivele arhitecturale. Management centralizat. Ingineria traficului care se face prin managementul centralizat Integrarea a ct mai multe tehnologii de access. Conexiune cu reeaua PSTN. Migrarea ctre o reea de date universale (Date, voce, video.). Migrarea traficului de voce ctre reelele NGN Scalabilitate, performan, disponibilitate total (99%).

1.2 Voice over Internet Protocol (VoIP)

VoIP reprezint o familie de tehnologii care ajut reelele bazate pe IP s foloseasc aplicaii de voce precum telefonia, comunicare n timp real, teleconferint. VoIP definete o modalitate de transport a vocii peste reelele IP, incluznd de asemenea i procesul de digitizare i formare de pachete. Telefonia IP folosete standardele VoP pentru a creea un sistem telefonic care permite servicii de tipul rutare de apel,mesagerie vocal etc.

2. ATACURI I AMENINRI ASUPRA SERVICIULUI VoIP

Atacatorii pot s deterioreze serviciul de media fie suprancrcnd cu trafic, fie colectnd informaii private prin interceptarea semnalului telefonic sau a celui de semnalizare. Deturnarea apelurile se face prin asuma rea fals a identitii servelor sau impersonarea utilizatorilor. Acestea conduc la apeluri realizate n mod fraudulos din cauza identitii falsificate i asa mai departe. Utilizatorii nelegitimi (spammerii) pot utiliza reelele VoIP pentru a livra apeluri spam, mesaje instante sau informaii, fiind mult mai eficiente dect spamul pe email deoarece spamul VoIP este foarte dificil de filtrat. Exist numeroase moduri de a grupa ameninrile unei reele VoIP. Voi trata urmtoarele categorii : Ameninri mpotriva disponibilitii Ameninri mpotriva confidenialitii Ameninri mpotriva integritii
2.1 Ameninri mpotriva disponibilitii

Ameninrile impotriva disponibilitii sunt de fapt un grup de ameninri mpotriva serviciul de disponibilitate care ar trebui s fie activ 24/7. Astfel, aceste ameninri doresc ntreruperea serviciului VoIP, de cele mai multe ori prin refuzul serviciului (denial of service DoS). Ameninrile tipice mpotriva disponibilitii sunt urmtoarele: Suprancrcarea cu apeluri (Call flooding) Mesaje corupte (Malformed messages) Mesaje false (Spoofed messages) Interceptarea apelului (Call hijacking) Impersonarea serverului (Server impersoning)

2.1.1 Suprancrcarea cu apeluri (Call Flooding)

Un exemplu des ntlnit al DoS intenionat este suprancarea apelului: un atacator suprancarc 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 performana reelei n mod semnificativ sau chiar cade conexiunea. Metodele specifice de call flooding sunt urmtoarele: Valid or invalid registration flooding : un atacator folosete aceast metod n mod frecvent deoarece majoritatea serverelor de nregistrare accept cereri de la orice staie final din internet, ca un prim pas de autentificare. Indiferent dac mesajele sunt valide sau nu , numrul mare de mesaje cerere ntr-o perioad scurt de timp (de exemplu, 10 000 mesaje SIP REGISTER pe secund) afecteaz sever performanele 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 staiile finale nelegitime (nenregistrate). Deci, un atacator mai nti se nregistreaz falsificnd existena 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 avnd un impact asupra performanei sau funcionalitii serverului indiferent dac mesajul tip cerere este valid sau nu. Call control flooding dup configurarea apelului : - Un atacator poate inunda reeaua 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 opiune de securitate care s ignore i arunc aceste mesaje. Ping flooding - protocoalele VoIP folosesc mesajele ping la nivelul aplicaie ca s verifice disponibilitatea unui server sau s menin o legtura cu serverul local de NAT (Network Address Translation), cum ar fi mesajele SIP OPTION. Majoritatea echipamentelor IP de reea (de exemplu, un ruter sau un firewall) datorit configuraiei pe care o aplicm nu d voie pingurilor ICMP n reelele de producie (exemplu,organizaiile economice), din motive de securitate. Cu toate acestea, serverele VoIP ar trebui s nu restricioneze pingul la nivelul aplicaie pentru o funcionare eficace. Totui rezultatul ar fi o mare bre de securitate. Figura 1.0 ilustreaz exemplul suprancrcrii distribuite cu PCuri infectate. Un atacator infecteaz alte calculatoare cu malware (de exemplu, un virus) si le folosete ca intermediari floodnd mesaje de nregistrare. Fiecare

calculator infectat trimite 1000 de mesage SIP REGISTER pe secund sub diferite legitimiti care sunt generate aleator.
Server SIP Registrar

Calculatoare infectate

R sp u

are str e i g d re e n trafic e d r e saj e ca rca Me rimis anca t upr s

IP
ns

Serviciu ntrerupt

IP

IP

Utilizatori legitimi

Proces de infectare

Atacator

Figura 1.0 Atac de tip suprancrcare distribuit n figura de mai sus , mesajele floodate vor afecta serverul de nregistrare (SIP Registrar) n mod sever ntruct acesta proceseaz i rspunde 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 ), defeciune a sistemului sau ntreruperea serviciului. Indiferent dac serverul rspunde sau nu, floodarea serverului SIP registrar cu suficiente mesaje de nregistrare va provoca degradarea serviciului de legitimare a staiilor finale. (endpoints). Nu doar floodarea intenionat menionat, ci si floodarea neintenionat exist n reele VoIP sub numele de auto-atac (self-attack), din cauza configurrii incorecte a unor dispozitive sau a anumitor circumstane unice. Cteva exemple : Pan de curent regional i restaurare Cnd tensiunea a revenit dupa o pan de curent, toate staiile finale (de exemplu,10000 telefoane IP) vor porni si vor trimite mesaje de nregistrare serverului aproape in acelai timp, care neintenionat 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 staiilor 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 suprancrcare neateptat, n special cnd exist mai multe tipuri de staii finale, unele chiar necunoscute, care fac parte din reeaua VoIP. Suprancrcarea legitim a apelului exist momente din zi sau zile n care multe apeluri legitime sunt fcute aproape n acelai timp. Un exemplu e Ziua mamei cnd o mulime de apeluri sunt efectuate n toata lumea. Un alt exemplu l reprezint dezastrele naturale (de exemplu, cutremurele), cnd oamenii din mprejurimi fac foarte multe apeluri la serviciul de urgen (de exemplu, 112), iar familiile i prietenii fac apeluri n aria afectat n acelai timp. Aceste tipuri intenionate, 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. Urmtorul tip de atac este o alt form de ameninare 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 greit. Exemplul din fig ura 1.1 arat un un mesaj de tip invitaie SIP (SIP INVITE message).

Figura 1.1 Mesaj corupt de tip SIP INVITE Comentariile (literele boldate) din exemplu nu sunt afiate n mesajul actual SIP INVITE. Putem gsi ceva in neregul in exemplul mesajului de tip invitaie. Trei antete SIP (Request-URI , From, Call-Id) i o versiune n protocolul de descriere a sesiunii (Session Description Protocol SDP) au format greit. Serverul care primete acest tip de mesaj neateptat poate fi confuz (haotic) i reacioneaz n diferite moduri, depinde de implementare. Impacturile tipice sunt dup cum urmeaz : Bucle infinite de parsare Memoria tampon saturat, care poate permite execuia unui cod arbitrar Defecteaz maina de stare Incapabilitatea de a procesa alte mesaje normale Cderea sistemului Aceste vulnerabiliti provin n general din urmtoarele surse : 1. Slbiciunea specificaiilor protocolului Majoritatea protocoalelor VoIP pot fi accesate de oricine i nu definesc strict fiecare linie de cod. Atacatorii pot gsi unde se afl slbiciunea unei sintaxe. n plus, exit multe cmpuri sau tag-uri care pot fi personalizate. 2. Uurina crerii mesajelor corupte

Crearea mesajelor ca cel in exemplul 2 este uor de realizat pentru un programator. Chiar i cei care nu sunt programatori au la dispoziie destule unelte pentru a personaliza mesaje. 3. Lipsa tratrii excepiilor n implementare Datorit restriciilor de timp, majoritatatea celor care implementeaz se focalizeaz pe caracteristicile produsului si interfee mai degrab, dect sa creeze excepii de tratare a cazurilor nefavorabile. 4. Dificultatea testrii 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. Ameninarea cu mesaje corupte ar trebui s fie prevenit atta timp ct algoritmul de parsare le trateaz cum trebuie. Urmtoarea ameninare o reprezint mesajele falsificate (spoofed messages) care nu sunt o form de mesaje corupte dar influeneaz 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 duntoare, call teardown, reprezint capacitatea unui atacator de a monitoriza traficul, dialogul SIP ,pentru a obine informaii 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 acetia discut. Dispozitivul care primete mesajul de terminare a apelului va inchide sesiunea imediat. Figura 1.2 ilustreaz exemplul cu mesaje SIP.

Server Proxy SIP

INVITE

IP
200 OK

Media
IP IP

Utilizator A BYE

Utilizator B

Atacator

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 cunoate informaia din sesiune (SIP dialog). Atacatorul injecteaz informaiile sesiunii ntr-un mesaj de tip BYE. Telefonul IP al utilizatorului A primete 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) fr s tie informaia sesiunii. Acestea pot afecta sesiunea de apel curent. Comparativ cu ameninrile anterioare, call teardown nu este un atac ntlnit des deoarece atacatorul ar trebui s monitorizeze sesiunea de apel dorit, naintea ca acesta s poat trimite mesaje de terminare a sesiunii (BYE). Urmtorul tip de atac o reprezint apelul taxat in mod fraudulos (toll fraud) . Acesta implic de asemenea informaii 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 internaionale sau la distane 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

acreditrile(identificatorii) n diferite moduri. Tipic, un atacator creeaz mesaje false pentru atacarea parolei, pe server, prin for brut pn ce acesta primete permisiune. Dac clientul folosete parole standard sau simplu de ghicit atunci acestea sunt mult mai uor de gsit; n special cazul cnd atacatorul folosete un dicionar de parole. n anumite cazuri, serverul nu necesit autentificare, dar verific IP-ul surs sau subnetul clientului pentru a controla accesul. n special cnd call trunking (de exemplu, SIP trunking), este iniiat ntre un furnizor de servicii VoIP i o ntreprindere client, controlul accesului cel mai des utilizat se bazeaz pe sursa IP sau subreeaua de provenien. Un atacator poate s acceze serverul falsificnd adresa IP surs.
2.1.4 Deturnarea apelului (Call Hijacking)

Hijacking(deturnarea) apare cnd anumite negocieri ntre o staie terminal VoIP si reea 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 iniial n care se fur informaiile despre sesiune , dar forma atacului i impactul sunt diferite. Cazurile tipice sunt interceptarea nregistrrii, deturnarea sesiunii media i nsuirea identitii unui server. Umtorul paragraf descrie fiecare dintre aceste cazuri :
2.1.5 Interceptarea nregistrrilor

Procesul de nregistrare d voie unei staii finale s se identifice insi 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. Cnd un utilizator legitim a fost compromis, acel utilizator nu mai poate primi apeluri. Figura ilustreaz exemplul cu mesaje SIP.

Server Registrar SIP

Server Proxy SIP Apel de intrare pentru utilizatorul A

IP
nregistrare de la: utilizatorul A la: utilizatorul A OK nregistrare : De la:utilizatorul A La : atacator

IP
OK

IP

Utilizator A

Atacator

Figura 1.3 Deturnarea nregistrrii n figura 1.3 un atacator i nsuete identitatea unui utilizator modificnd antetul From i adugnd adresa atacatorului n antetul To cnd trimite un mesaj de nregistrare, care actualizeaz adresa de nregistrare a intei vizate. Toate apelurile spre utilizatorul A vor fi direcionate spre atacator. Acest atac se ntampl cnd serverul de SIP (Registrar) se bazeaz doar pe antetele SIP pentru a identifica utilizatorul.

2.1.6 Interceptarea sesiunii media (Media session Hijacking)

Cnd o sesiune media este negociat ntre dou staii finale VoIP, un atacator poate trimite mesaje false oricruia dintre ele pentru a redireciona media spre o alt staie final precum telefonul atacatorului sau csua vocal a acestuia. Victima va fi capabil s vorbeasc doar cu staia final a atacatorului. Figura 1.4 ilustreaz exemplul cu mesaje SIP.

INVITE

IP
Server Proxy SIP Sun

IP

IP

Utilizator A

Utilizator B

Media

200 OK

Csu de mesagerie vocal

Atacator

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, corespunztoare serverului su de mesagerie vocal. Utilizatorul A las un mesaj de voce pentru utilizatorul B n csua 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 comunicaie ntre A i B, un atacator poate s deturneze o sesiune activ prin trimiterea unui mesaj de tip reinvitaie (re-invite)utilizatorului A.
2.1.7 Preluarea identitii 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 si asume identitatea serverului i s primeasc mesajul cerere , iar apoi s l manipuleze/modifice n scopuri duntoare. 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 nlocuiete un fiier de configuraie pentru telefoanele IP cu fiierul su care are o adres IP a unui server (de exemplu, SIP Registrar) fals, infectat. Telefoanele IP care descarc fiierul corupt/duntor 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 greit. Figura de mai jos ilustreaz un exemplu bazat pe o tranzacie SIP cu un server Redirect.
Server DNS Compromis Server de redirecionare atacator 10.10.10.10

original.redirect.com

E INVIT ly orari temp d e v o 302 M

IP: 10.10.10.10

IP

Utilizator A

Server de redirecionare original

Original.redirect.com IP: 10.1.1.10

Figura 1.5 Preluarea identitii 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. Cnd utilizatorul A ncearc s iniieze un apel spre utilizatorul B, telefonul IP caut adresa IP a serverului redirect (original.redirect.com) i primete IP-ul 10.10.10.10 a serverului nelegitim. Mesajul INVITE este trimis serverului corupt/fals/nelegitim, iar acesta returneaz 302 Moved Temporarily cu informaii de cont act false ce ar putea fi o adres fictiv sau serverul proxy al atacatorului folosit pentru ameninri viitoare. Serverul original redirect (10.1.1.10) nu poate primi nicio cerere de apel n aceast situaie.
2.1.8 Deteriorarea calitii serviciilor (QoS Abuse )

Componentele unei sesiuni media sunt negociate ntre staiile finale VoIP n timpul configurrii apelului. Acestea sunt: tipul de media, rata codoruluidecodorului (codecului), tipul sarcinii utile (de payload). De exemplu, ar putea fi necesar sau de dorit s folosim codecul de voce G.729 atunci cnd crem o reea (pentru a folosi minimul de band). Folosim G.711 cnd apelurile sunt efectuate n interiorul reelei (pentru a pstra 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 calitii serviciilor este suprasaturarea capacitii canalului (care e limitat) cu ajutorul unui instrument n aa fel nct 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 reeaua. 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 Ameninri mpotriva confidenialitii O alt categorie de ameninare VoIP este aceea mpotriva confidenialitii. Spre deosebire de ntreruperea serviciului pe care am prezentat-o, ameninrile mpotriva confidenialitii nu au un impact asupra comunicaiilor curente n general, dar asigur mijloace neautorizate de a captura trafic de voce, identiti, modele i credeniale care sunt folosite pentru conexiunile neautorizate ulterioare sau alte practici neltoare. Negocierile VoIP sunt cele mai expuse ameninrilor de confidenialitate deoarece majoritatea serviciilor VoIP nu asigur confidenialitate 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 informaia din antet pentru a putea ruta un apel. n unele cazuri, serverele trebuie s insereze informaia n antet (de exemplu, antetul Via n SIP), n funcie de cum e proiectat protocolul. Aceast seciune introduce cele mai populare tipuri de atacuri asupra confidenialitii : eavesdropping media call pattern tracking data minig reconstruction

2.2.1 Interceptarea media (Eavesdropping Media)

Interceptarea conversaiei unei persoane e o ameninare cunoscut de cnd a aprut serviciul de telecomunicaii; chiar dac metodele de ascultare sunt diferite ntre sistemele de telefonie clasic i sistemele VoIP. n VoIP, un atacator folosete 2 metode n mod normal. Una este aceea de a asculta pachetele media din acelai domeniu de broadcast cu inta, sau pe aceiai cale cu media. Cealalt metod este realizat prin compromiterea unui dispozitiv de acces (de exemplu, switch de nivel 2) i redirecionarea (prin duplicare) spre

dispozitivul atacatorului.Media poate fi doar voce sau integrat cu video,text,fax, sau imagine. Figura 1.6 ilustreaz aceste cazuri.
L3 Ruter duplicare L2 Switch Port de monitorizare atacator

Hub

IP

atacator

Utilizator A Domeniu de broadcast

Figura 4.6 Interceptarea semnalelor de pe mediul de transmisie n figura 1.6, dispozitivul atacatorului care e n acelai 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 ptrund ilegal ntr-un switch sau ruter i s configureze un port de monitorizare pentru VLANul de voce. Mai apoi va redireciona (dubluri) media dispozitivului de captura al atacatorului. O alt posibilitate de interceptare este aceea prin care atacatorul se interpune pe aceeai cale cu nsi 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 reele astfel nct un atacator poate gsi: fie un potenial dispozitiv int, de acces (IP/port), protocol sau vulnerabilitatea reelei. 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 reea sunt ilustrate n exemplul de mai jos. E prezentat o cerere SIP simpl (INVITE) i mesaje rspuns (200 OK). Un atacator poate extrage informaie concludent din ele analiznd protocolul. (cmpurile cheie sunt ngroate).

Figura 1.7 Mesaj SIP INVITE n paragraful de mai jos este descris un exemplu de informaii 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 corespunztor 5060. Se folosec pachete UDP pentru semnalizare fr 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. Iniiatorul (Alice) care are un numr 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 (presupunnd 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 iniial) Informaiile 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)

Aa 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, strnge informaii cu numere de telefon din mesajele interceptate. Acesta e un exemplu de data mining. Sensul general al exploatrii de date o reprezint colecia de identificatori ne autorizai care pot fi un nume, numr de telefon, parol, URL,adres de email, sau ali identificatori care au legtur cu telefoane,noduri de server, pri comunicante, sau organizaii din reea. n exemplul 2.7 se poate observa acest tip de informaii din mesaje. Un atacator utilizeaz informaia pentru conexiuni neautorizate ulterioare precum : Apel efectuat fraudulos (Toll fraud calls) Apeluri spam (de exemplu, voce, mesagerie instant) ntreruperea serviciului (de exemplu, suprancrcarea apelului cu trafic, deturnarea apelului, cderea conexiunii apelului) neltoria/phishing ( identitate frauduloas) Cu identiti valide, atacatorii pot avea o san mai mare s ntrerup serviciul prin trimiterea diferitelor tipuri de mesaje corupte. Majoritatea serverelor resping toate mesajele, excepie fcnd mesajele de nregistrare, dac staia final nu este nregistrat.
2.2.4 Reconstrucie

Reconstrucia nseamn orice reconstrucie neautorizat a vocii, video, fax, text sau a informaiei prezente dup capturarea semnalelor sau a traficului de voce dintre prile comunicante. Reconstrucia include monitorizarea, nregistrarea, interpretarea, recunoaterea i extragerea a oricrui tip de comunicaii fr consimmntul prilor. Cteva exemple sunt , dup cum urmeaz: Acreditri de decodificare criptate de un protocol specific. Extragerea dual tone multifrequency (DTMF) tonuri dintr-o conversaie.

 Extragerea imaginilor fax dintr-o comunicaie (voce i fax). Interpretarea mecanismelor de atribuire a cheilor de sesiune dintre pri. Aceste reconstrucii nu afecteaz comunicaia curent, dar sunt utilizate pentru atacuri viitoare sau alte practice neltoare.
2.3 Ameninri mpotriva integritii

O alt categorie de ameninare VoIP o reprezint ameninarea mpotriva integritii, care are, n cele mai multe cazuri, un impact sever asupra serviciului curent. Metoda de baz a ameninrii mpotriva integritii este alterarea mesajelor (semnalelor) sau a traficului de voce dup ce le-am interceptat pe reea. Adic un atacator poate vedea toat semnalizarea i fluxurile media dintre dou staii finale ca un intermediar. Alterarea poate consta n tergerea, injectarea sau nlocuirea informaiilor importante din mesajele sau media VoIP. Ameninrile se impart n dou mari categorii : Ameninri mpotriva integritii mesajului (message alteration) Ameninri mpotriva integritii media (media alteration)
2.3.1Alterarea mesajului

Alterarea mesajului nseamn c un atacator intercepteaz mesajele n timpul unei comunicaii i altereaz informaia pentru a reruta apelul; schimb informaia 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 direciei apelului prin alterarea informaiei de rutare din mesajul protocolului. Rezultatul rerutrii apelului este fie pentru a exclude entitile legitime sau pentru a include entiti nelegitime pe calea apelului sau pe mediul de transmisie. Figura 4.8 ilustreaz exemplul includerii unei entiti duntoare n timpul configurrii apelului .

Server SIP de redirecionare Server Proxy SIP IP: 192.168.10.10

IP
302 Moved Temp Contacteaz: 10.1.1.10

IP

atacator

atacator Invite

302 Moved Temp Contacteaz: 172.26.10

Invite

Invite Server Proxy SIP

IP

Utilizator A

IP
IP:10.1.1.10

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 redicionare (redirect server). Cnd utilizatorul A iniiaz un apel, telefonul IP trimite un mesaj INVITE serverului de redirecionare precum n figura 1.9:

Figura 1.9 Mesaj SIP INVITE Atacatorul detecteaz mesajul INVITE i intercepteaz mesajul rspuns (care este, 302 Moved Temporarly) de la serverul de redirecionare, precum e ilustrat n continuare exemplul din figura 1.10.

Figura 1.10

Atacatorul nlocuiete adresa IP a serverului proxy (10.1.1.10) din antetul Contact cu adresa serverului su 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 mijloculcomunicaiei) poate vedea toate semnalele ntre dou staii finale i le poate modifica n scopuri dunatoare.
2.3.1.2 Apel fr destinaie (Call black holing)

Apelul spre nicieri, fr destinaie, nseamn orice metod de tergere sau refuzul de a trece mai departe orice elemente ale mesajelor dintr-o comunicaie. Consecinele a call black holing sunt : ntrzierea stabilirii apelului, refuzul mesajelor ulterioare, erori ale unor aplicaii, nchiderea unor apeluri conectate i asa mai departe. Un atacator, ca intermediar, arunc doar mesajele de confirmare (ACK) dintre entitile apelului astfel nct dialogul SIP nu se poate realiza, chiar dac ar putea deja exista trafic de voce prelimar ntre ele. Un atacator ca intermediar terge informaia de sesiune media (SDP) din mesajul INVITE, care are ca rezultat: doar una dintre pri 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 aa fel nct utilizatorul nu mai poate primi apeluri.
2.3.2 Modificarea media (media alteration)

Modificarea semnalelor de pe mediul de transmisie este ameninarea prin care un atacator intercepteaz media n mijlocul unei comunicaii dintre entiti i altereaz informaia media pentru a: injecta trafic neautorizat, degrada calitatea serviciilor, terge informaii 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 nlocuiete media din canalul respectiv. Consecina injectrii de media este aceea c victima e posibil s aud zgomot, ,sau s nu aud nimic n receptor n timpul conversaiei. Figura 1.12 ilustreaz exemplul cu flux de voce.

Media Gateway

PSTN Media Injectare media

IP

Utilizator B atacator

Utilizator A

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 secvena de numere RTP a pachetelor de voce i ajusteaz secvena de numere a pachetelor nelegitime i le injecteaz pe canalul de voce astfel nct 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 oricrei comunicaii. Cteva exemple sunt dup cum urmeaz: 1. Un atacator intercepteaz pachetele RTCP ale comunicaiei i modific (sau terge) valorile statistice ale traficului media

(pierderea pachetelor, jiterul ) astfel nct un dispozitiv final nu poate controla media n mod eficient. 2. Un atacator intercepteaz pachete RTCP i schimb secvena de numere ale pachetelor astfel nct dispozitivul final va rula media cu secvena de numere greit, ceea ce va degrada calitatea.

3. SCHIMBUL DE CHEI SDES, ZRTP i MIKEY

Fa de iniierea i descrierea sesiunii, schimbul de chei este un mecanism de securitate fundamental. Aadar, voi descrie, n mod mai detaliat, protocoalele care schimb chei specifice VoIP. Este esenial de neles ce garanie a securitii ofer, pentru c, dup cum voi demonstra mai jos, o nepotrivire ntre ceea ce ateapt protocolul la nivel transport i proprietile 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 ali 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 nsi cheia trebuie inclus n textul n clar (plaintext). Cu alte cuvinte, cheia e integrat direct n ataamentul SDP a unui mesaj SIP. Protecia 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 protecie punct-la-punct peste un lan de servere proxy. Mai mult, acesta presupune c urmtorul hop din lanul de servere proxy SIP este de ncredere. n schimb , S/MIME, asigur confidenialitate punct-la-punct i autentificare pentru payload codificate ca MIME. Menionez c S/MIME nu asigur replay protection. Prin urmare, dac S/MIME este folosit pentru protecia payload (care include cheia n plaintext), atunci aplicaia trebuie s asigure o defensiv separat mpotriva replay attacks. n general, majoritatea aplicaiilor au o protecie repl ay limitat pentru c necesit meninerea strii, iar acest lucru duce la pierderea sincronizarea ceasului. n seciunea 3.2, voi arat cum un atacator se poate folosi

de lipsa proteciei replay n S/<MIME protejat SDES prin spargerea ntregii securiti 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 existena 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 protecie mpotriva atacurilor de tip man-inthe-middle, ZRTP folosete un SAS (Short Authentication String), care este de fapt un hash criptografic, format din dou valori Diffie-Hellman pentru confirmarea cheii. Prile comunicante confirm verbal la telefon cheia stabilit, uitndu-se la ecranul telefonului i citindu-i unul altuia valorile SAS afiate. Dup aceea se bazeaz pe nlnuirea de chei : secretele partajate Diffie-Hellman ce au fost capturate n sesiunea anterioar sunt folosite pentru a autentifica sesiunea curent.
Alice Sesiune RTP HELLO(ver,cid,hash,cipher,pkt,sas,ZIDul lui Alice) Confirmare HELLO HELLO(ver,cid,hash,cipher,pkt,sas,ZIDul lui Bob) Confirmare HELLO Bob acioneaz ca iniiator COMMIT(ZIDul lui Bob,hash,cipher,pkt,hvi) DHPART1(pvr,rs1IDr,rs2IDr,sigsIDr,srtsIDr, orther_IDr) DHPART2(pvr,rs1IDi,rs2IDi,sigsIDi,srtsIDi, orther_IDi) Alice si Bob genereaZ cheile de sesiune SRTP i salt Procesul SRTP ncepe CONFIRM1(text n clar,steag sas,hmac) CONFIRM1(text n clar,steag sas,hmac) Confirmare CONFIRM2 Bob

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 conine opiunile de configurare SRTP i ZID unic, care e generat o singur dat la instalare. Acest ZID v a fi folosit de destinar pentru a recupera secretele partajate ce au fost stocate. Mesajele de tip hello i helloACK sunt opionale, iar o staie final poate iniia direct o sesiune ZRTP prin trimiterea unui mesaj COMMIT. Expeditorul mesajului commit (Bob din exemplul nostru) este numit iniiator, iar Alice receptor sau destinatar. Mai jos se descrie schimbul Diffie-Hellman n detaliu punnd accent pe cmpurile relevante ale mesajului, pe restul omindu-le. n mesajul COMMIT, hash,cipher i pkt se descrie hashul, criptarea i algoritmii de cheie public, alei de Bob din intersecia 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 corespunztoare 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 folosete ZID ul lui Bob pentru a recupera secretele partajate rs1 i rs2. Bob rspunde 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-themiddle). n seciunea 3 se descrie cum un atacator poate executa cu succes un atac man-in-the-middle n ciuda protocolului folosit fr ca participanii s l detecteze ). Dac verificarea valorii publice DH reusete , Alice calculeaz hashul valorii primite i controleaz dac se potrivete 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 ateapt s le primeasc de la Bob. Pentru fiecare secret, fiecare ID este calculat ca HMAC al stringului Initiator, criptat cu secretul nsi. Fie B setul de I Duri ateptate s fie primite. Alice apoi calculeaz intersecia seturilor A i B. Secretele corespunztoare IDurilor n intersecie sunt stocate ca setul D, sortate n ordine cresctoare. Specificaiile 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 legturii. 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 configurrii sesiunii SIP. n acest fel, nu apare suprancrcare (overhead). Un dezavantaj evident este acela c necesit secrete partajate prealabil, sau PKI separat, nsoite 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 dorete s asigure confidenialitate, autenficarea mesajului, i protecie replay traficului de voce i a celui de semnalizare. SRTP folosete o singur cheie principal pentru a obine material de criptare, prin intermediul unei funcii hash. n SRTP, un context criptografic se refer la informaia de stare criptografic meninut 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 numrtor rollover. (ROC). Fiecare pachet RTP const ntr-o secven de numere pe 16 bii care crete monoton. Counterul rollover este pstrat de receptor i este incrementat cu 1 de fiecare dat cnd secvena 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 reea destinaie, portul destinaie. Pentru criptarea datelor, SRTP folosete un singur cifru, Advanced Encryption Standard (AES), n urmtoarele 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 secvena de numere a pachetului. n loc s foloseasc AES ca un cifru bloc, SRTP l folosete precum ar fi un cifru flux i cripteaz datagramele. Acestea sunt fcute XOR cu ieirea lui AES aplicat (cheie, SSRC, SEQ).

3.4.1 Obinerea cheii SRTP

SRTP folosete o funcie criptografic, securizat, pseudo-aleatoare (PRF) pentru a genera chei de sesiune pentru autentificare i criptare din cheia principal, master salt i secvena de numere. Secvena 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 bii, master salt ms , rata cheii obinute (derivate), determinat de contextul criptografic i indexul (ROC||SEQ pe 48 de bii). || nseamn concatenarea stringurilor. Fie x = (<etichet>|| r) XOR ms, unde r este ctul ntreg obinut prin mprirea indexului la rata de derivare a cheii. Fie mk notat cheia principal i PRF (k,x) o familie de funcii pseudoaleatoare, precum cea pentru cheia secret aleatoare k ; x dat de m-bii, ieirea este un string pe n-bii. Cheile de sesiune sunt generate ca PRF(mk , x) utiliznd 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 funcionarea 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 specificaiile SRTP, care avertizeaz despre pericolele two -time pad (un alt termen folosit pentru cheia flux). Condiia: cheia flux (stream) s nu se repete niciodat e reprezentat de faptul c ieirea PRF(folosit ca intrare pentru AES) trebuie s nu se repete niciodat, pentru c celelalte intrri 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 acelai 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-adevr, conform cu specificaiile SRTP, o cheie principal nu trebuie s fie partajat ntre sesiuni RTP diferite. Amintim c att cheia principal, ct i master salt sunt derivate (obinute) n mod determinist din materialul de cheie recepionat n timpul schimbului de chei. Dac un atacator reusete vreodat s pacleasc sesiunea prin refolosirea materialul de cheie utilizat anterior, cheia principal se va repeta.
3.4.2 Algoritmul criptografic al SRTP

Softphone SIP handshake Descrierea Sesiunii RTP

Schimbul de cheie cu Mikey: Diffie Hellman / PKI

Cheia principala

Cheia Salt

P e n t r u f i e c a r e p a c h e t

Numrtor rollover pe 32 bii Secvena de numere Algoritmi de criptare i modul Replay list MKI + diffusion bit (y/n) Numrtor cheie principal Lungimea cheii de sesiune Rata de derivare a cheii

Context criptografic

I N I I A L I Z A R E

Derivarea cheii

Packet index 2^16 x ROC + SEQ

Session key

Session Salt

Session Auth

Derivarea cheii flux

Payload-ul unui pachet RTP

Segmentul cheii flux SHA -1 (algoritmul hash produce amprente de 168 biii)

AES (algoritm de criptare cu chei de 128 bii)

RTP payload criptat

Pachetul final SRTP

Figura 2.1 Algoritmul SRTP

3.5 Atacuri i vulnerabiliti ale SDES, ZRTP i MIKEY

3.5.1 Atacuri asupra SIP

Denial of service: un astfel de atac se rezum la aducerea reelei n stadiul n care serviciul este indisponibil, de obicei prin redirecionarea unui volum mare de trafic serviciului respectiv. Astfel acesta nu poate fi accesat de clienii legitimi. Un DoS distribuit d voie unui singur utilizator de reea s provoace mai multe hosturi de reea s suprancarce cu trafic o int. Un atac distribuit Dos e uor 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 numrul de mesaje returnate victimei. Reflection este un alt mod de a organiza un atac DoS. Un atacator poate trimite cereri falsificate unui numr mare de elemente SIP i servere proxy, punnd adresa victimei n cmpul surs. Fiecare destinatar va genera un rspuns, suprancrcnd victima cu trafic. O protecie, 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 staiile finale (telefoanele IP sau softphone-urile) sunt dinamice ca locaie. Un alt inconvenient este c nu e foarte clar din specificaii 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 acelai dispozitiv din reea (pe aceeai 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 recepionat 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 ctre serverele registrar. Dac un utilizator ru intenionat este capabil s nlture nregistrarile unora sau a tuturor utilizatorilor din reea i s-i nregistreze dispozitivul lui n numele lor, poate foarte uor s interzic accesul acestor utilizatori/servicii. Atacatorii pot de asemenea s ncerce s epuizeze resursele de stocare sau serverul registrar prin crearea unui numr mare de legturi. nregistrarea SIP nu necesit ca ceea ce conine cmpul From dintr-un mesaj s fie identic cu antetul To al cererii, astfel dnd libertatea unei a treia pri s modifice adresa-de-nregistrare a legturilor n numele altui utilizator. Dac atacatorul i nsuete, cu succes, o parte autorizat care s modifice contactele n numele unui utilizator, el poate arbitrar s modifice adresa-de-nregistrare a legturilor 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 nsueasc pe deplin un server sau un proxy poate crea daune, inclusiv DoS clientului sau lansarea unui atac DoS distribuit. Aceasta necesit existena 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 cnd e folosit n combinaie 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; fr s nvee cheia de sesiune i fr s fie n stare s decripteze fluxurile de date. Considerm c Bob a iniiat sesiunea i c SDES a fost utilizat pentru transportul SRTP key material. Pentru a asigura confidenialitate mesajului SDES, S/MIME a fost folosit pentru a cripta payload. S/MIME, n general, este preferat peste TLS pentru protecia mesajelor SDP deoarece: a) S/MIME confer integritate i confidenialitate punct-la-punct, iar b) S/MIME nu necesit ca proxy-urile intermediare s fie de ncredere. S/MIME nu ofer protecie anti-replay. Dup ce sesiunea original a fost corupt, atacatorul poate s redea mesajul original INVITE a lui Bob spre Alice, coninnd un ataament 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 menine nicio stare a SDP, ea nu va fi n stare s detecteze reluarea mesajului. Folosind key material (fragmente/poriuni) a vechii sesiuni precum cheia ei HMAC, va deriva exact aceeai 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 conine suficient redundan sau atacatorul poate ghici pri din flux, va fi capabil s reconstruiasc complet sau parial datele ambelor fluxuri.

Bob INVITE Alice@domain1.com cu ataament SDP (cu cheie) OK de la Alice

Alice

Atacatorul (preluarea identitii lui Bob) SDES cu protecie S/MIME

Copie a invitaiei de la Bob Confirmare Alice OK de la Alice Confirmare Alice Flux SRTP Flux SRTP BYE BYE Cheia flux se rept

Figura 2.2 Atac asupra SRTP folosind schimbul de cheie SDES n orice caz, criptarea a fost eliminat i atacatorul obine un xor pe bii a dou payloduri. Din moment ce datagramele VoIP au o redundan crescut, i payloadurile sunt cel puin la fel de predictibile ca datagramele iniiale (exemplu, majoritatea conversaiilor ncep cu un Hello, a crui codare digital e predictibil, chiar dac lum n considerare variaiile de accent i pronunie) trebuie avut n vedere c este o bre mare de securitate. Acest atac este similar ca existen faimosului atac pe 802.11 WEP, care ddea voie atacatorului s obin un XOR al pachetelor wireless. n cazul WEP, cheia flux era refolosit din cauza epuizrii vectorilor de iniializare pentru cifrul flux. Cea mai important observaie bazat pe atacul nostrum este aceea c SRTP nu folosete niciun fel de aleatorism la recepie cnd destinatarul deriveaz cheile de sesiune, chiar dac designerii SRTP au fost avertizai de pericolul refolosirii cheii principale. Specificaiile 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 numr MIKEY, SDES i ZRTP. Chiar dac MIKEY a fost fcut special ca protocolul de schimb al cheii pentru SRTP, multe implementri VoIP folosesc n schimb SDES. Din aprilie 2007, produsele care se bazeaz pe combinaia 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 conine protecie built-in i anti-replay i astfel pare potrivit pentru stabilirea cheilor SRTP, analiza de mai sus demonstreaz ca SDES nu este. Unele implementri SRTP pot conferi msuri adiionale 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 emitorul ui ca parte a sesiunii SRTP stabilit, pentru a asigura c acesta deriv acelai 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 specificaiile protocolului: este critic ca numrtorul (counter) s nu se repete niciodat. Pentru ca protocolul s fie securizat (protejat), combinaia 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 semnalizrii i pot fi exprimate folosind descrieri de securitate SDP (dac semnalizarea este protejat criptografic) sau MIKEY []. Din pcate, protecia criptografic n absena proteciei replay nu este suficient pentru a garanta unicitatea cheilor peste sesiuni multiple, rezultnd combinaia: schimb de cheie i cifru flux potenial vulnerabil.

3.5.3 Atacuri asupra ZRTP

Denial of service. ZRTP este potenial vulnerabil la atacuri de tip DoS cauzate de atacatori care trimit mesaje HELLO false terminalelor. Ca rspuns fiecrui HELLO, o staie final ZRTP creeaz o conexiune parial deschis i pstreaz parametrii n memorie. n cele din urm, va rmne fr spaiu de stocare, iar cererile ulterioare de la clieni 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 esenial 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 seciunea 5 i inute de ctre participani pentru autentificare n urmtoarea sesiune. Pentru a autentifica participantul de la cellalt capt al unei sesiuni

VoIP, valoarea SAS este citit cu voce tare pe conexiunea de voce. Totui, 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 reea VoIP printr-un proxy local, care nu are ecran. Prin urmare, analiza ZRTP se concentreaz n situaia 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 participani care deja au efectuat multe sesiuni, atacatorul trebuie s fie prezent n fiecare sesiune, chiar ncepnd cu prima. Raionamentul este dup cum urmeaz. Fiecare utilizator ZRTP reine secretele partajate rs1 i rs2 (vezi seciunea 3) pentru utilizatorii cu care comunicase anterior. Cnd iniiaz o nou sesiune, utilizatorul trimite ZID-ul lui, care este folosit de destinatar pentru a obine 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 ncepnd chiar cu prima n care nu exist secrete partajate. Din nefericire, acest raionament este eronat. Principala problem n legtur cu protocolul sunt ZID-urile, care sunt folosite de destinatari pentru a cuta secretele partajate. Acestea sunt autentificate destul de devreme n protocolul de schimbare a cheii. Considerm un atacator pasiv care ntercepteaz sesiunea dintre Alice i Bob i inva ZID-ul lui Bob. Atunci lanseaz un atac man-inthe-middle precum n figura 5.3 Atacatorul alege exponeni 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 alei de Bob pentru sesiunea ZRTP. De asemenea, atacatorul nlocuiete toate ID-urile secretelor partajate cu numere aleatoare. Cnd Alice primete mesajul DHPART2 de la Bob, ea preia setul de secrete care le partajeaz cu Bob i calculeaz setul de ID-uri ateptat. Din moment ce atacatorul a nlocuit toate IDurile cu numere aleatoare, acestea nu vor corespunde. Specificaiile 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 iniiator i receptor.

Alice COMMIT(ZIDul lui Bob,hash,cipher,pkt,z)

Atacator COMMIT(ZIDul lui Bob,hash,cipher,pkt,hvi)

Bob

DHPART1(pvr,rs1IDr,rs2IDr,...)

DHPART1(x,r1,r2,...) DHPART2(pvi,rs1IDi,rs2IDi,...)

DHPART2(y,r1',r2',...)

Figura 2.3 Atac asupra ZRTP de tip man in the middle Specificaiile 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 obinut 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 discuie neoficial din specificaiile 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 u n nou secret partajat stocat. n primul rnd, acest lucru este incompatibil cu specificaiile actuale, care permit setului de secrete partajate s fie gol n timpul derivrii cheii. n al doilea rnd, nu este deloc clar se implementeaz, din moment ce specificaiile spun c SAS este mai uor de implementat cnd un GUI sau un mic ecran este disponibil, care ridic intrebarea ce s facem cnd nu avem ecran. Ne imaginm nite produse care implementeaz VoIP securizat printr-un proxy local, dar care nu dispun de ecran n cele mai multe cazuri . Chiar dac Alice se oprete din a comunica cu Bob cnd setul de secrete partajate este gol (subliniem din nou c nu e ceea ce specificaiile prevd), acest atac devine un atac DoS foarte eficace, care d voie atacatorului s sparg orice sesiune efectuat ntre dispozitive VoIP far ecran. n general, afirmaia din specificaii c atacatorul este forat s rezolve multiple probleme ( precum furtul secretului partajat ale uneia dintre pri, s fie prezent chiar de la prima sesiune i apoi la toate sesiunile ulterioare pentru a putea executa un atac manin-the-middle, s rezolve problemele nregistrrilor separate), nu pare s fie confirmat. Nu este clar dac problema poate fi rezolvat. n absena fie a PKI sau a secretelor pre-partajate, fie a opiunii dispozitivului pentru confirmarea

out-of-band a cheii prin citirea hashurilor cheie ntre ei, este greu de vzut cum prile 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. Verificrile formale a ZRTP cu AVISPA prezint o provocare interesant deoarece modelul trebuie capturat natura multi-session a autentificrii n ZRTP. Autenficarea n sesiunea ZRTP depinde de informaia schimbat n sesiunile anterioare. HLPSL, totui, nu permite ca starea s fie pstrat peste mai multe sesiuni. Pentru ca modelul de analizat s funcioneze, trebuie s presupunem c pentru o sesiune dat, iniiatorul i receptorul convin asupra valorii secretelor partajate la nceputul sesiunii. Aceasta ne permite s modificm protocolul prin trecerea secretelor partajate ca argumente folositoare specificaiilor, n cadrul seciunii: rolurile iniiatorului i receptorului. De asemenea, presupunem c nu exist alte secrete partajate ntre participani. Se modific doar cmpurile relevante din corpul mesajelor. Pentru a simplifica prezentarea, artm specificaiile n notaia 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 seciunea 5. H() este o funcie 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 iniiator 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 urmtoarele condiii sunt ndeplinite: la finalul unei sesiuni ncheiate cu succes, dac Alice crede c vorbete cu Bob, atunci ea ntr-adevr vorbete cu acesta dac mesajele de nregistrare respective, trimise i primite n timpul execuiei protocolului se potrivesc. Condiia 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 bii aleator de ctre oricine altcineva dect cei participani . Este uor de observat c MIKEY nu satisface aceast cerin cnd 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 ptrate modulo - un numr mare prim, testarea apartenenei la grup nu e o problem greu de calculat: este suficient s calculm simbolul Jacobian. De aceea, este uor s identificm diferena dintre irul de bii aleator i cheia. Schemele de criptare n care cheia derivat este destinat folosirii n mod tipic necesit ndeplinirea condiiei: cheia s fie imperceptibil de o valoare aleatoare. Acesta este un alt exemplu n care ipotezele fcute 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 funcii 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 nite valori aleatoare (de autentificare) generate de unul sau ambii participani. Exist o soluie standard simpl. Pentru a deriva o cheie din valoarea comun Diffie-Hellman, participanii MIKEY ar trebui s urmeze abordarea utilizat n TLS i IKE i s foloseasc un extractor de aleatorism; exemplu, funcia universal hash cu aleatorism public generat de unul sau ambii participani. n cele din urm, se observ c MIKEY n modul de cheie pre-partajat, evident c nu satisface perfect redirecionarea secretizrii deoarece compromiterea secretului pre-partajat conduce la compromiterea tuturor sesiunilor anterioare. Denial of service. MIKEY ofer o protecie limitat mpotriva atacaturilor de tip DoS. n modul de cheie public DH, destinatarul efectuzeaz operaii CPU-intensive modular exponentiation dup verificarea rezumatului mesajului (digest) al iniiatorului. Atacatorul poate nc suprancrca cu trafic receptorul cu multiple copii ale aceluiai mesaj sau cu mesaje coninnd digest incorect. Acest lucru va provoca destinatarul s execute un numr mare de verificri 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 reele cu comutaie de pachete precum internetul. Cnd securitatea este adugat unui sistem VoIP, calitatea apelului VoIP este afectat. Paragraful explic arhitectura protocolului ZRTP n detaliu i evalueaz de asemenea performana unui sistem VoIP dup ce a fost implementat securitatea. Studiul este fcut n laborator folosind un server SIP bazat pe asterisk, telefoane client X-Lite Soft, aplicaie Zfone i un analizor de trafic : Wireshark. Aplicaia Zfone este folosit pentru implementarea ZRTP pe staiile finale. Rezultatele obinute au fost analizate i comparate cu cele realizate pentru apeluri nesecurizate. Observm 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 puin mrit dup implementarea protocolului ZRTP.Acesta este un protocol la nivel aplicaie care nu este dependent de dispozitivele intermediare i de asemenea nu este limitat la un numr de apeluri. Aadar ZRTP reprezint o metod de securitate mai potrivit pentru securizarea fluxurilor media de VoIP datorat utilizrii eficiente a lrgimii de band.
4.1Arhitectura ZRTP (Zimmermin RTP)

ZRTP dezvoltat de ctre Phil Zimmermin asigur confidenialitate, autentificare i integritate ntre dou staii finale VoIP care comunic. ZRTP utilizeaz mecanismul de schimbare a cheilor Diffie-Hellman pentru a dobndi o cheie comun ntre cele dou pri participante la comunicaie. 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 ctre staiile finale pn cnd acestea suport ZRTP. In ambele staii finale aparinnd sesiunii suport ZRTP, are loc un schimb de chei Diffie Hellman pentru a se hotr cheia de sesiune. Dup un proces de handshake efectuat cu succes ntre cele dou staii 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 rnd pachetul Hello este trimis de ctre cel care iniiaz apelul spre apelatul participant. Formatul pachetului ZRTP Hello este ilustrat n figura 3.1 Versiunea protocolului este 1.10 i pentru integritate este folosit funcia hash SHA-256. Pentru criptare este folosit algoritmul AES-CM cu cheie pe 128 de bii (Advanced Encryption Standard-Counter Mode). Cele dou chei SAS (short authentication string) sunt folosite pentru verificare, ntre cel care trimite i cel care recepioneaz.

Figura 3.1 Pachet ZRTP de tip HELLO

4.2Pachet ZRTP Commit

Fie expeditorul sau receptorul pot iniia schimbul de chei prin interme diul unui mesaj COMMIT. Figura 3.2 ilustreaz formatul pachetului ZRTP commit. E folosit cheie pe 128 de bii pentru AES-CM si autentificare SAS pe 256 bii.

Figura 3.2 Pachet ZRTP de tip COMMIT

4.3 Pachetul ZRTP Dhpart1

Cnd pachetul COMMIT este recepionat, solicitantul trimite mesajul Dhpart1 iniiatorului. Formatul pachetului ZRTP Dhpart1 este prezentat n figura 3.3 Valoarea criptat a funciei 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. Secvena 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. Secvena de numere folosit n acest pachet este 57450. Cnd pachetul de confirmare este recepionat, traficul de voce este criptat nainte s fie trimis destinatarului. Cercul rou indic faptul ca datele sunt criptate nainte s fie trimise.

Figura 3.5 Pachet ZRTP de tip Confirm1

O librrie libZRTP a fost dezvoltat i implementat ntr-un utilitar numit Zfone. Zfone este dezvoltat de Phil Zimmermann i este o soluie de securitate pentru comunicaia 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 vrful stivei TCP/IP. Oricnd un nou apel VoIP este negociat, Zfone preia controlul fluxului VoIP negociind o nou cheie de criptare ntre prile comunicante i apoi cripteaz pachetele VoIP. Zfone folosete o metod inovatoare de autentificare : un SAS (short authentication string) este generat n timpul schimbului de chei Diffie-Hellman. Dac stringul generat la fiecare capt este diferit, prile care comunic pot presupune c schimbul de chei Diffie Hellman a fost modificat. Figura 3.6 ilustreaz comunicaia ntre dou staii finale cu ZRTP.

Arhitectura ZRTP

zfone Utilizator A local

Reea

zfone Utilizator B la distan SIP

SIP
VoIP Proxy

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 destinaie. n comunicaia n timp real este mai bine s pierzi pachete dect s le retransmii ulterior. Partea util a mesajelor RTP conine codecul traficului de voce care descrie calitatea i eroarea admis a fluxului. Sunt folosii diveri algoritmi de corecie pentru scderea numrului de pachete pierdute. Cerinele benzii depind de calitatea codecului i rata de compresie. Unele codecuri i aplicaii creeaz fluxuri RTP cu pachete mari, iar altele cu pachete mici sau medii. RTP folosete temporar porturile UDP care sunt negociate de procotolul de semnalizare apel. De exemplu porturile RTP sunt transportate n message bodies SDP (Session Description Protocol) alturi 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 comunicaie secundar care este folosit cu RTP, dar nu este esenial pentru ca fluxurile RTP s funcioneze. RTCP este folosit pentru a schimba informaii de sesiune RTP. Cnd apelul e pus n ate ptare sau nu vorbete nimeni nu va fi trafic RTP, dar traficul RTCP se va transmite continuu ntre cei care comunic. Mesajele RTCP folosesc aceeai 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 informaii despre jiter, ntrziere i pierderea de pachete.

5. BIBLIOGRAFIE
[1] S. Tanenbaum, Reele de calculatoare, Editura Computer Press Agora, Trgu-Mure, 2004 [2] T. Rdulescu, Reele de telecomunicaii, Ed. Thalia, Bucureti, 2002 [3] Fred Halsall, Computer Networking and the Internet, AddisonWesley, 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, IndianapolisIndiana, 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