O varnosti telefonije smo na teh straneh že večkrat pisali, prav tako smo že tudi predstavili nekatere aplikacije za varno komuniciranje preko IM in SMS sporočil. V tokratnem prispevku pa si bomo pogledali kako pred prestrezanjem zaščititi svoje telefonske klice oziroma vsebino naših zvočnih komunikacij. Pri tem je potrebno poudariti, da v nadaljevanju opisan način onemogoči vsakršno prestrezanje telefonskih pogovorov (prisluškovanje) – tako nezakonito, kot tudi tim. zakonito, ki bi se ga skušalo izvajati s pomočjo operaterja.

Zgodovina šifriranja zvočnih komunikacij sega v obdobje 2. svetovne vojne, ko je (za današnje razmere) preprosto zvočnih šifriranje radijskih komunikacij pričela uporabljati ameriška vojska. V ta namen so uporabljali napravo SIGSALY, ki je tehtala 55 ton in je napolnila srednje veliko sobo. Za šifriranje telefonskih pogovorov so se kasneje uporabljali posebni telefonski aparati (z vgrajenim modulom za šifriranje in dešifriranje pogovorov), pogosto pa tudi tim. scramblerji – samostojne naprave, ki jih je bilo mogoče položiti na telefonsko slušalko, kjer so z vgrajenim mikrofonom “prebrale” vhodni (kodiran) signal, ga dekodirale in nato nekodiranega predvajale na zvočniku (in obratno za mikrofonski del slušalke). Scrambler je sicer naprava, ki omogoča spreminjanje (navadno analognih) signalov, izraz scrambler pa se uporablja tudi za naprave, ki omogočajo šifriranje analognih signalov. A pomemben pospešek šifriranju telefonskim pogovorom je prinesla digitalna tehnologija.

Eno prvih aplikacij, ki je omogočala šifriranje pogovorov preko navadne telefonske (modemske) povezave ali preko interneta je bila aplikacija PGPfone, ki jo je leta 1995 razvil legendarni Phillip Zimmermann. Za uporabo aplikacije smo na vsaki strani potrebovali računalnik z modemom ali dostopom do interneta. S pomočjo modema smo se nato povezali na modem drugega uporabnika (oziroma preko internetne povezave na drug, v internet povezan računalnik; ne pozabimo, da je bil v tistih časih internet še zelo slabo razširjen), obe aplikaciji pa sta si nato izmenjali šifrirne ključe in preko povezave začeli prenašati digitaliziran zvok. Seveda je vsak uporabnik potreboval zvočno kartico s slušalkami (kar v tistih časih ni bilo tako samoumevno kot danes), z nekaj malega spretnosti pa je bilo mogoče izdelati celo priključek, s katerim smo na računalnik namesto slušalk in zvočnika priključili kar telefonsko slušalko. O tem sem leta 1998 napisal celo kratek prispevek, ki je še vedno dosegljiv na internetu…

Šifriranje telefonskih pogovorov s PGPfone leta 1998.

Kljub temu, da je bila uporaba takšne naprave (računalnik z modemom in slušalkami) razmeroma nepraktična (ne pozabimo, da so bili tedanji računalniki precej večji in težji od današnjih), pa je napredek od druge svetovne vojne v tem primeru lepo viden. A razvoj je šel dalje in s pojavom pametnih telefonov sanje o vsem dosegljivem šifriranju telefonskih pogovorov postajajo realnost.

VoIP omrežje

Kot omenjeno, je ena možnost, da zvočne pogovore šifriramo na ravni (zvočnega) signala. Ta možnost v resnici danes ni preveč uporabna, saj praviloma zahteva namensko strojno opremo ali zajem in obdelavo zvočnega signala neposredno na mikrofonu (v ta namen za Android obstajajo celo nekatere aplikacije). Poleg tega je takšen način šifriranja praviloma precej občutljiv na motnje pri prenosu oziroma je tudi omejen z zmogljivostjo prenosnih poti (komunikacijske infrastrukture). Druga možnost pa je šifriranje digitalnih komunikacij oziroma digitaliziranega zvočnega pogovora. Ta možnost je še posebej privlačna zato, ker danes pravzaprav vse komunikacije postajajo digitalne oziroma kmalu ne bomo več govorili o prenosu zvočnih, SMS in drugih komunikacij, pač pa zgolj o prenosu podatkov. V nadaljevanju si bomo ogledali kateri so ključni gradniki infrastrukture, ki nam omogoča šifriranje telefonskih pogovorov.

Kot rečeno, v osnovi za prenos zvoka ne uporabljamo klasične telefonske povezave, pač pa podatkovni prenos. Gre torej za zvočno komunikacijo preko VoIP omrežja, za kar praviloma potrebujemo ustrezno infrastrukturo (nekatere rešitve delujejo tudi povsem samostojno, brez strežniškega dela).

Za uporabo VoIP telefonije obstaja kar nekaj različnih protokolov (SIP, H.323,…). Za signalni protokol je najbolj smiselno uporabiti SIP (Session Initiation Protocol), ki je odprtokoden, ni obremenjen z lastniškimi licencami, zanj pa je na voljo precej različnih strežniških aplikacij in odjemalcev. Kar nekaj SIP strežniških aplikacij omogoča tudi TLS šifriranje povezave med strežnikom in SIP odjemalcem, vendar je za zagotovitev zares varnega komuniciranja pomembno, da je povezava šifrirana od enega odjemalca do drugega (tim. end-to-end šifriranje). Za šifriranje je ravno tako na voljo kar nekaj različnih metod, najbolj znan in pravzaprav de facto standard na tem področju pa je ZRTP protokol.

Na tem mestu naj omenimo, da izmenjava šifrirnih ključev in šifriranje s pomočjo ZRTP poteka med končnima napravama. SIP centrala zato služi zgolj kot posrednik pri prenosu podatkov. Iz tega razloga je za SIP centralo potrebno uporabiti takšno aplikacijo, ki ne posega v VoIP promet in torej ne ovira izmenjave ključev in šifriranja med dvema končnima komunikacijskima točkama.

Če torej na kratko povzamemo, za centralno infrastrukturo potrebujemo telefonsko centralo (ustrezno SIP aplikacijo, ki teče na strežniku), ki ne posega v VoIP promet in torej dopušča ZRTP ali drugo šifriranje. Zaradi čim bolj zanesljivega delovanja pa je pomembno, da je SIP centrala povezana v omrežje s čim bolj kvalitetno omrežno povezavo.

Šifriranje klicev z ZRTP protokolom

ZRTP – Zimmermann Real-time Transport Protocol je sistem, ki omogoča varno izmenjavo šifrirnih ključev med dvema komunikacijskima partnerjema (s pomočjo tim. Diffie-Hellmanove izmenjave šifrirnih ključev), povezava med njima pa je nato šifrirana z SRTP protokolom (Secure Real-time Transport Protocol). ZRTP je leta 2006 razvil Phil Zimmermann (skupaj z Bryceom Wilcox-O’Hearnom, Colinom Plumbom, Jonom Callasom in Alanom Johnstonom).

Pomemben del procesa šifriranja zvočnih komunikacij je preverjanje istovetnosti šifrirnih ključev. S preverjanjem šifrirnih ključev namreč preprečujemo napad s posrednikom (tim. man-in-the-middle napad), kjer bi se napadalec enemu in drugemu komunikacijskemu partnerju lažno predstavljal in na ta način izvajal prestrezanje njunih šifriranih komunikacij.

Načeloma preverjanje javnih ključev poteka tako, da komunikacijska partnetja primerjata zgoščene vrednosti (ang. hash) svojih ključev. Na ta način lahko posameznik preveri ali je šifrirni ključ, ki ga poseduje on res enak kot tisti, ki se nahaja v partnerjevem telefonu (torej, da ni bil zamenjan med prenosom). Težava pa je v tem, da je preverjanje “klasičnih” zgoščenih vrednosti zamudno opravilo.

Poglejmo si to na primeru. Recimo, da je MD5 zgoščena vrednost našega šifrirnega ključa naslednji niz: “047125717b59e25646c48f056fe101db“. Preverjanje bi potekalo tako, da bi najprej vsak komunikacijski partner izračunal MD5 zgoščeno vrednost svojega ključa, nato pa bi se obe vrednosti (vrednost pri nas in vrednost pri partnerju) primerjali, in če se vrednosti ujemata vemo, da šifrini ključ pri prenosu ni bil spremenjen.

Primerjanje takšnih dolgih in zapletenih nizov je zamudno in nehvaležno opravilo. Zato je Zimmermann s sodelavci razvil za človeška bitja precej bolj enostavno metodo, ki se imenuje tim. Short Authentication String (SAS). Metoda temelji na tem, da prej omenjene zgoščene vrednosti preslika v krajši niz (npr. “5nhd“) ali besede v človeškem jeziku (npr. “stagnate typewriter“). Tako namesto preverjanja niza znakov “047125717b59e25646c48f056fe101db” lahko izvedemo preverjanje dveh besed (npr. “stormy aftermath“), kar je precej bolj enostavno in razumljivo. Besedi namreč ravno tako kot prej navedena zgoščena vrednost predstavljata digitalni prstni odtis šifrirnega ključa. Če se digitalna prstna odtisa šifrirnega ključa na obeh straneh ujemata, smo lahko prepričani, da posedujeta oba komunikacijska partnerja isti šifrirni ključ oziroma, da se le-ta med prenosom ni spremenil (oziroma, da se vmes ni vrinil napadalec). Besede sicer izvirajo seznama PGP Word List, ki omogoča nedvoumen prenos podatkovnih zlogov prek zvočnega (telefonskega) kanala.

Iz navedenih razlogov je zelo pomembno, da VoIP odjemalci omogočajo eno izmed metod preverjanja istovetnosti šifrirnih ključev. Odjemalci, ki podpirajo ZRTP, imajo preverjanje s SAS metodo že vgrajeno.

ZRTP podpira tim. oportunistično šifriranje, kar pomeni, da VoIP odjemalec sam ugotovi ali VoIP odjemalec na drugi strani podpira ZRTP šifriranje ali ne. Če šifriranje podpira, skuša vzpostaviti šifrirano povezavo, v nasprotnem primeru pa vzpostavi nešifrirano povezavo. To je sicer zelo koristno iz stališča zagotavljanja povezljivosti, problem pa je, če nam je osnovni cilj zagotavljanje varne povezave. V primeru motenj (naključnih ali namernih), bo namreč komunikacijski kanal vzpostavljen, vendar povezava ne bo šifrirana.

Kodeki

Pri prenosu zvok preko omrežja je smiselno zvok kompresirati, saj s tem prihranimo na pasovni širiti. Kompresijo zvoka izvajajo kodeki. Za kvaliteten prenos zvoka je torej potrebno uporabiti ustrezne kodeke. Kodeki namreč po eni strani v primeru slabše omrežne povezave (višja latenca, slabša prepustnost omrežja) omogočajo ustrezno kvaliteto zvoka in s tem boljšo uporabniško izkušnjo, izbira neustreznih kodekov pa lahko predstavlja tudi resno varnostno tveganje.

Uporaba napačnega kodeka namreč lahko povzroči tim. uhajanje informacij oziroma napadalcu omogoči prisluškovanje tudi v primeru, da uporabljamo šifrirane prenose podatkov. Problematični so VBR (variable bit-rate) kodeki, ki različno kompresirajo različne tipe zvokov. Težava ni v tem, če kodek spreminja bitno hitrost kodiranja (ang. bit rate) glede na razpoložljivo pasovno širino oz. prepustnost (ang. channel bandwidth); težava je, če spreminja bitno hitrost kodiranja glede na tip zvoka, ki ga kompresira (torej, da so določeni tipi zvoka različno kompresirani).

Raziskovalci iz Johns Hopkins University so namreč leta 2008 ugotovili, da je pri uporabi VBR kodekov mogoče z merjenjem velikosti kompresiranih in šifriranih podatkovnih z visoko zaneslivostjo identificirati dele besed ali celotne besede paketov brez dešifriranja. Raziskave so pokazale, da je na tak način mogoče v povprečju identificirati 50% besed v pogovoru, za nekatere besede, pa je verjetnost prepoznave kar 90%. To velja ne glede na uporabljeni šifrirni algoritem.

Iz tega razloga je se uporabi VBR kodekov pri šifriranih VoIP komunikacijah potrebno izogibati. Pri tem je potrebno vedeti, da nekateri kodeki uporabljajo VBR in ne-VBR način. Primeri nekaterih ne-VBR kodekov so GSM 6.10, iLBC, G.711 (A-LAW, u-LAW in PCMU), G.722 in G.726.

VBR kodeki, ki omogočajo opisano uhajanje informacij pa so med drugim iSAC, ki ga uporabljajo Skype, Google Talk in Gizmo ter Microsoftov RT Audio, ki se uporablja v aplikaciji Microsoft Office Communicator.

Problematična je tudi uporaba tehnologije zaznavanja aktivnosti glasu (ang. voice activity detection – VAD; gre za tehnologijo, ki zazna tišino in s tem zmanjša nepotrebno kodiranje oz. prenašanje “tišine” preko omrežja), vendar pa je uhajanje informacij tam bistveno manjše kot pri uporabi VBR kodekov. Kodeka, ki uporabljata VAD sta npr. AMR in G.722.2, je pa mogoče uhajanje informacij zmanjšati z nastavljanjem ustreznih parametrov v sami VoIP aplikaciji, vendar to praviloma ni nekaj, kar bi bilo v domeni končnega uporabnika.

Problem zakasnitve

Zakasnitev oz. latenca je po definiciji čas, ki preteče od uporabniške zahteve do odziva sistema, od katerega odziv pričakujemo. Za čim bolj nemoteno komunikacijo je seveda zaželjena čim manjša latenca oz. zakasnitev.

Zakasnitev je problematična zlasti zato, ker zakasnitev pri prenosu glasu med sogovornikoma močno upočasni komunikacijo oz. jo oteži, saj si sogovornika med pogovorom “skačeta v besedo”, zakasnitev povzoča odmev (tim. echo efekt), v primeru uporabe videokonferenčne povezave pa slika in zvok nista sinhronizirana, kar je ravno tako moteče za komunikacijo. Odmev postane problem, kadar je povratna zakasnitev med komunikacijskima partnerjema dolga več kot 50 milisekund, do prekrivanja sogovornikov oz. skakanja v besedo pa pride pri zamikih večjih od 250 milisekund.

VoIP komunikacije sicer poleg čim nižje zakasnitve potrebujejo tudi ustrezno prepustnost. Posamezen govorni kanal namreč za nemoteno delovanje potrebuje določeno omrežno prepustnost (ang. bandwith). A to je ob današnjemu razvoju tehnologije, zlasti pa z uporabo ustreznih kodekov (takih, ki imajo čim višjo stopnjo kompresije podatkov) precej bolj obvladljiv problem kot problem zakasnitve. Omeniti velja še problem izgube podatkovnih paketkov (v paketnih, torej IP omrežjih) – načeloma velja, da je za VoIP komunikacije sprejemljivih do 3% oziroma največ 5% izgube podatkovnih paketkov (idealno je do največ 1%).

Obstajajo tri vrste zakasnitve:

• zakasnitev razširjanja (ang. propagation delay), gre za čas, ki je potreben za prenos signala v omrežju;
• serializacijska zakasnitev (ang. serialization delay), ki je čas, potreben, da se posamezen bit pošlje (omrežnemu) vmesniku; ta zakasnitev je minimalna in za področje VoIP komunikacij v splošnem ni relevantna;
• zakasnitev procesiranja (ang. handling delay, processing delay) – to zakasnitev povzročajo naprave, ki omrežni paketek pošiljajo po omrežju. V to zakasnitev se šteje tudi kompresija podatkov ter paketno preklapljanje oz. paketna komutacija (ang. packet switching). Različni kodeki tako lahko k zamiku prispevajo do nekaj milisekund (oziroma največ nekaj deset milisekund).

Na nekatere vrste zakasnitev lahko vplivamo z ustrezno infrastrukturo omrežja, nekatere vrste zakasnitev pa so fiksne in jih ne moremo zmanjšati. Več o problematiki zakasnitve si je mogoče prebrati v članku Understanding Delay in Packet Voice Networks objavljenem na spletni strani podjetja Cisco.

Načeloma velja, da čim manjše so zakasnitve, boljša je komunikacija. Glede na smernice ITU-T G.114 so sprejemljive zakasnitve do 150 ms (ob uporabi preprečevanja odmeva (ang. echo cancellation)). Pogojno so sprejemljive tudi zakasnitve med 150 in 300 ms, zakasnitve večje od 300 oziroma 400 ms pa že onemogočajo sočasno dvosmerno komunikacijo. Idealne zakasnitve pa naj bi bile največ do 100 ms.

Pomemben del zakasnitev je tim. ping čas (ang. ping time, čas potreben za potovanje podatkovnih paketov od izvornega do ciljnega strežnika in nazaj) in seveda naj bi bil ta čim krajši (na to lahko vplivamo z zasnovo omrežne infrastrukture oziroma izbiro lokacije strežnika na katerem teče SIP centrala). A kot rečeno ping čas ni edini izvor zakasnitve. Po nekaterih ocenah naj bi bil ping največ 90 do 100 ms.

Trepetanje sporočil (ang. jitter)

Trepetanje sporočil je spreminjanje časovnega razmika med podatkovnimi paketi sporočila (ang. jitter). Gre za časovno spreminjanje (variabilnost) latence pri prenosu podatkovnih paketkov preko omrežja. Problem trepetanja obstaja samo v paketnih omrežjih, do njega pa prihaja zato, ker podatkovni paketki ne potujejo vedno po isti poti od pošiljatelja do prejemnika, oziroma se omrežni pogoji v času trajanja komunikacije spreminjajo (latenca ni stalna, v omrežju prihaja do občasnih zastojev). Omrežje s kontantno latenco torej nima trepetanja sporočil.

Za VoIP komunikacije je pomembno, da je trepetanja čim manj, torej da zaporedni VoIP podatkovni paketki prihajajo na cilj v rednih časovnih intervalih. Zakasnitev trepetanja pri VoIP komunikacijah naj bi bila načeloma največ 75 milisekund, optimalna vrednost pa je pod 30 oziroma 40 milisekund. Posledica trepetanja je v praksi “zatikanje” pogovora in nerazločna komunikacija, včasih so določeni glasovi ali celo zlogi besed pomešani.

Rešitev za problem trepetanja je uporaba posebnega predpomnilnika (ang. jitter buffer), kjer hitrejši paketki počakajo počasnejše, seveda pa taka rešitev še poveča že opisani splošni problem zakasnitve. Indikator, da pri VoIP komunikaciji prihaja do trepetanja je nihanje ping-a oz. nekonsistentni rezultati v ping časih. Več o problematiki trepetanja si je mogoče prerati v članku Quality of Service for Voice over IP na spletni strani podjetja Cisco ter na spletni strani VoIP trobleshooter.

VoIP odjemalci

Na strani uporabnikov je za povezovanje na SIP centralo potrebno uporabljati ustreznega SIP odjemalca. Ta aplikacija mora podpirati ZRTP protokol, saj želimo uporabiti šifriranje pogovora med dvema končnima komunikacijskima točkama, hkrati pa mora podpirati tudi ustrezne kodeke, z predpomnilnikom skrbeti za čim bolj gladek prenos zvoka, itd. Iz tega razloga je VoIP odjemalec pravzaprav ključni del (varnega) telefonskega omrežja. V nadaljevanju si bomo zato pogledali nekaj odjemalcev za mobilne telefone (SIP odjemalci z ZRTP podporo so na voljo tudi za osebne računalnike), pri čemer pa so nekateri odjemalci pravzaprav tesno povezani z namensko infrastrukturo za šifriranje VoIP komunikacij in jih ne moremo uporabiti kot splošno namenske SIP odjemalce.

V nadaljevanju predstavljeni VoIP odjemalci so sicer brezplačni, kljub temu pa njihova uporaba za posameznika ni brezplačna. V nekaterih primerih je potrebno plačati za uporabo VoIP infrastrukture, v vsakem primeru pa za prenos podatkov (razen če za prenos podatkov uporabljamo brezplačno Wi-fi povezavo), saj VoIP komunikacije potekajo preko podatkovne povezave.

CSipSimple

Ena izmed bolj znanih SIP aplikacij za Android, ki podpirajo ZRTP šifriranje je CSipSimple. Aplikacija je odprtokodna in brezplačna, omogoča pa številne zmožnosti (SIP preko TLS, ZRTP in SRTP šifriranje, uporabo številnih kodekov – dodatne kodeke lahko namestimo s pomočjo aplikacije CSipSimple Codecs Pack), uporaba STUN (Session Traversal Utilities for NAT), ICE (Interactive Connectivity Establishment) in TURN (Traversal Using Relays around NAT) strežnikov, itd.

Šifriran klic v Ostel omrežju.

CSipSimple ima toliko funkcij, da bi bilo ročno nastavljanje SIP računa in varnostnih nastavitev za povprečnega uporabnika lahko precej zapleteno opravilo, vendar pa aplikacija vsebuje tudi zmogljivega čarovnika za nastavljanje računov, ki vsebuje prednastavitve za številne VoIP ponudnike, med drugim tudi za OSTN – Open Secure Telephone Network, o čemer nekoliko več kasneje. Zato je nastavljanje VoIP računa pravzaprav zelo enostavno opravilo.

Preverjanje SAS v CSipSimple.

Po drugi strani pa aplikaciji lahko očitamo to, da je aplikacija nekoliko slabo oblikovana – tako je na primer SAS avtentikacijski napis premalo jasno prikazan, prav tako je premalo jasno razvidno ali se je vzpostavila šifrirana ali nešifrirana povezava. Iz stališča varnosti pa pogrešamo možnost izklopa tim. oportunističnega šifriranja, torej možnost, da aplikacija v primeru motenj pri izmenjavi šifrirnih ključev omogoča vzpostavitev nešifrirane povezave.

Dohodni klic v CSipSimple.

CryptoCall

Nekoliko drugačen pristop je ubrala aplikacija CryptoCall. Gre za predelan klon CSipSimple (obeh aplikacij na telefonu ne moremo zaganjati hkrati), ki za šifriranje uporablja OpenPGP. Aplikacija za prenos pogovora sicer ne uporablja klasičnih VoIP ponudnikov, pač pa omogoča neposredne (ang. peer-to-peer) povezave. Odjemalca si svoja javna IP naslova (in komunikacijska vrata) izmenjata preko SMS sporočil, zato ni potrebna nikakršna registracija pri VoIP ponudniku. (Če je eden izmed odjemalcev za NAT-om, izvede klic na javni IP drugega odjemalca tisti odjemalec, ki ni neposredno dostopen).

CryptoCall

Nastavljanje aplikacije CryptoCall.

Aplikacija je sicer namenjena zgolj kot prikaz, da je takšen pristop k šifriranju zvočnih komunikacij mogoč (aplikacija je sicer delo  nemških študentov Sergeja Dechanda in Dominika Schürmanna), v praksi zaenkrat ni širše uporabna, zlasti zato, ker pametni telefoni pogosto nimajo javnega IP naslova (so skriti za NAT-om) in neposredna peer-to-peer komunikacija pogosto ni mogoča. A avtorja v prihodnosti načrtujeta uporabo mehanizmov za prehod NAT sistemov, zato se bo pristop v prihodnosti morda izkazal kot učinkovit.

CryptoCall.

Red Phone

Druga razmeroma znana aplikacija, ki omogoča šifriranje telefonskih pogovorov je Red Phone, avtorja Moxieja Marlinspikeja (njegovo pravo ime je Mike Benham), ki je sicer tudi razvijalec odlične brezplačne in odprtokodne aplikacije za šifriranje SMS sporočil, TextSecure. Aplikacija je bila sicer razvita z namenom zagotavljanja varnih komunikacij ljudem v represivnih režimih, prvenstveno kot pomoč protestnikom v Egiptu.

Aplikacija je ravno tako odprtkodna in brezplačna, na voljo samo za Android in zelo preprosta za uporabo. Vendar pa je ne moremo uporabljati samostojno (s katerimkoli VoIP ponudnikom), pač pa samo v Red Phone omrežju. Gre za omrežje strežnikov, ki zagotavljajo delovanje VoIP omrežja. Arhitektura omrežja je nekoliko bolj zapletena, saj Red Phone sistem za posredovanje zvočne komunikacije uporablja tim. glavne in tim. relacijske strežnike (ang. master server, relay server), prav tako je nekoliko bolj zapletena signalizacija klicev, saj se zahteve za vzpostavitev klica posredujejo preko SMS sporočil oziroma Google Cloud Messaging (GCM) ter Android Cloud to Device Messaging (C2DM) sistema.

Red Phone jasno prikaže status povezave. Na sliki poteka izmenjava šifrirnih ključev.

V praksi to pomeni, da je na začetek zvonenja Red Phone telefona na drugi strani včasih potrebno počakati nekoliko dlje (v ekstremnih primerih to lahko traja tudi več deset sekund). Med pomanjkljivosti lahko štejemo tudi dejstvo, da Red Phone avtentikacijo šifrirnih ključev zahteva za vsak klic posebej (ne uporablja algoritma za zagotavljanje kontinuitete šifrirnega ključa – ang. key continuity algorithm), kar pomeni, da morata sogovornika ob vsakem klicu na začetku prebrati in preveriti SAS niz. Zato lahko utemeljeno pričakujemo, da bodo po določenem obdobju sogovorniki preprosto pozabili na verifikacijo ključev, njihovo nepozornost pa bo lahko izkoristil napadalec.

Aplikacija je sicer zelo enostavna za uporabo, zasnovana je minimalistično, SAS nizi so jasno razvidni, uporabnik je jasno obveščen o vseh korakih vzpostavljanja zveze (tudi z zvočnimi signali), kvaliteta zvoka v Red Phone omrežju pa je povsem zadovoljiva. Uporabnost aplikacije se v zadnjem času še izboljšuje (zelo verjetno so se Red Phone strežniki namnožili tudi v Evropi).

RedPhone prikaže ljudem razumljiv SAS niz.

Aplikacijo Red Phone je avtor najprej razvijal v okviru svojega podjetja Whisper Systems. 28. novembra 2011 pa je podjetje oziroma njegovega lastnika in avtorja Red Phone aplikacije prevzel Twitter in Red Phone omrežje ugasnil (aplikaciji Red Phone in Text Secure do takrat nista bili odprtokodni). To je sprožilo val protestov in kasneje so storitev ponovno vključili, omenjeni aplikaciji sta postali odprtokodni, podjetje Whisper Systems pa se je sedaj preimenovalo v Open Whisper Systems. Kljub temu, da je Red Phone odlična aplikacija pa dogodek jasno kaže, da ne smemo biti preveč oziroma življenjsko odvisni od enega samega ponudnika.

Silent Phone

Tretja znana aplikacija oziroma kar celovita storitev za zagotavljanje varnosti elektronskih komunikacij pa je Silent Circle v okviru katere deluje aplikacija Silent Phone. Gre za komercialno storitev podjetja katerega ustanovitelj in predsednik je Philip Zimmermann.

Silent Phone je na voljo za Android in iPhone za VoIP pa se uporablja infrastruktura podjetja (aplikacije ni mogoče uporabiti z drugimi ponudniki). Sama aplikacija je sicer brezplačna, mesečna naročnina na storitev pa stane 20 USD (storitev vključuje šifriranje telefonskih klicev, šifrirane video komunikacije, pošiljanje šifriranih SMS sporočil in šifrirane e-pošte).

Pri SilentPhone uporabnik dobi ameriško številko kamor ga nato pokličemo.

SilentPhone je v osnovi zelo enostaven za uporabo, uporablja izboljšano različico SAS preverjanja (izgovorljive besede namesto znakov), obvestila o statusu povezave (izmenjava ključev, šifrirana povezava, itd.) so zelo jasna. Kvaliteta zvoka je zelo dobra, tudi na slabših podatkovnih povezavah (npr. EDGE), kvaliteta zvoka na iPhone napravah pa je naravnost odlična (VoIP strežnike imajo v Kanadi in Švici), zagotavljajo tudi kontinuiteto šifrirnega ključa. Pred kratkim je aplikacija postala odprtokodna.

SilentPhone jasno pokaže status povezave in SAS.

Aplikacija je naravnost odlična, edini očitek je, da je cena 20 USD mesečno za običajne posameznike nekoliko previsok strošek, zlasti še zato, ker je treba upoštevati dejstvo, da nakup samo ene naročnine ni uporaben, pač pa mora storitev uporabljati tudi posameznikov socialni krog (prijatelji, sodelavci,…).

Pogled v prihodnost – uporaba VoIP komunikacij preko omrežja Tor

Z ZRTP šifriranjem VoIP prometa dobimo zaščito pred prestrezanjem vsebine naših zvočnih komunikacij, a napadalec še vedno lahko beleži prometne podatke (kdo je klical koga in kdaj). Temu se je načeloma mogoče izogniti z anonimizacijo, torej z uporabo Tor omrežja. Vendar pa je zasnova Tor omrežja taka, da v zameno za anonimizacijo dobimo visoko latenco omrežja. Visoka latenca Tor omrežja v praksi onemogoča kvalitetne VoIP komunikacije. Hkrati pa VoIP komunikacije praviloma potekajo s pomočjo UDP protokola, Tor omrežje pa trenutno podpira samo TCP protokol.

Naj poudarimo, da popolnoma uporabnih rešitev za zagotavljanje varne, zanesljive in anonimne VoIP komunikacije trenutno še ni, zato si bomo na hitro ogledali le v katero smer trenutno poteka ravoj na tem področju. Na tem mestu lahko omenimo, da je testiranje Skype komunikacije preko Tor omrežja dalo razmeroma zadovoljive rezultate, saj Skype uporablja kvalitetno kompresijo podatkov, vendar se uporabe Skypa preko Tor omrežja ne priporoča, saj Skype uporablja ranljive VBR kodeke.

Varnostni raziskovalci se namreč v zadnjem času ukvarjajo z različnimi pristopi k reševanju anonimizacije VoIP komunikacij. Prvi ukrep, ki ga je potrebno zagotoviti je, da zagotovimo, da VoIP promet poteka samo preko TCP povezave. To je mogoče storiti z ustrezno konfiguracijo VoIP infrastrukture ali pa s tuneliranjem VoIP povezav (npr. s pomočjo VPN ali OnionCat).

Naslednji problem, ki se ga trenutno zelo intenzivno raziskuje pa je problem visoke latence Tor omrežja. Vsak korak anonimizacije (prehod TCP paketokov preko različnih anonimizacijskih točk) namreč že po definiciji poveča latenco v omrežju, poleg tega zaradi razmeroma nizke zmogljivosti Tor omrežja v njem prihaja do zastojev. Nekatera testiranja so pokazala, ima pri prehodu čez tri anonimizacijske točke sprejemljivo kvaliteto le 21 od 100 testnih klicev, pri uporabi samo dveh anonimizacijskih točk pa število zadovoljivih klicev naraste na 36.

Eden izmed pristopov k reševanju tega problema je uporaba tim. polovične hkratne komunikacije (ang. half-duplex). Za razliko od običajne telefonije, ki uporablja polno hkratno komunikacijo (ang. full-duplex), se tim. polovično hkratno komunikacijo uporablja pri klasični radijski komunikaciji (UKV, CB, PMR oz. tim. “walkie-talkie” radijske postaje). Pri tem gre za to, da sogovornika ne govorita hkrati, pač pa komunikacija poteka izmenično, s prekinitvami.

To pa je mogoče implementirati v Tor omrežju. Pri tem so raziskovalci testno uporabili aplikacijo Mumble. Mumble je VoIP aplikacija, ki omogoča konferenčne pogovore po sistemu “pritisni in govori” (ang. push-to-talk, PTT). Večinoma jo za komunikacijo uporabljajo igralci on-line iger, aplikacija pa slovi po dobri kvaliteti glasu, nizkih zakasnitvah, VoIP komunikacije pa so tudi šifrirane (od odjemalca do strežnika). Poleg tega Mumble uporablja samo TCP protokol, strežniška aplikacija je odprtokodna in brezplačna, na voljo pa so številni odjemalci za različne operacijske sisteme in tudi pametne telefone. Testiranje, ki so ga izvedli v okviru The Guardian Projecta je pokazalo, da je tovrstna komunikacija preko Tor omrežja mogoča, je pa potrebno rešiti še določene druge probleme povezane s šifriranjem med več končnimi točkami hkrati (ang. multiple end-to-end encryption).

Drugi pristop pa se osredotoča k podvojevanju komunikacijskih povezav med VoIP odjemalcem in strežnikom. Tako naj bi se odjemalec na strežnik povezal preko dveh ali treh podatkovnih vrat (ang. port), vsaka povezava pa bi potekala preko druge Tor poti. Strežnik bi uporabil prvi prejeti podatkovni paketek (ostale pa bi zavrgel), aplikacija v ozadju pa bi najpočasnejšo povezavo po nekaj minutah samodejno zaprla in jo ponovno vzpostavila po drugi (hitrejši) poti (gre v bistvu za samodejno iskanje najhitrejše in najzanesljiveljše poti). Ta pristop sicer v osnovi rešuje zlasti problem izgubljenih podatkovnih paketkov in problem trepetanja, po predvidevanjih pa naj bi se s tem precej izboljšala povprečna latenca. Ob uporabi nepotratnih kodekov, kot je npr. Codec2, ki “porabi” zgolj 1200 oziroma 2400 bitov na sekundo ob zadovoljivi kvaliteti zvoka, se ideja zdi izvedljiva.

Zaključek

V tokratnem prispevku smo predstavili teoretične temelje zagotavljanja varnih telefonskih komunikacij. Kot je bilo prikazano, je pri zagotavljanju varnih in uporabnih VoIP komunikacij potrebno upoštevati številne dejavnike – od izbire ustrezne in dovolj kvalitetne strežniške infrastrukture, do kodekov in metod za zmanjšanje negativnih vplivov zakasnitev pri komunikaciji pa tudi reševanju problema posredne dostopnosti mobilnega odjemalca (če se nahaja za NAT-om ali agresivno nastavljenim požarnim zidom). Hkrati mora biti VoIP odjemalec za končnega uporabnika dovolj enostaven za uporabo ter zasnovan tako, da uporabniku jasno sporoča kdaj je povezava varna in kdaj ne, oziroma po možnosti kar najbolj zmanjša možnost uporabe ne-varnih komunikacij.

Na srečo o večini teh težav uporabniku ni potrebno kaj dosti vedeti, saj so nekatere (komercialne) rešitve zasnovane tako, da uporabnik vidi samo končno aplikacijo, ki sama skrbi za vse ustrezne nastavitve, uporabnika pa obremenjujejo minimalno (preveriti mora le SAS avtentikacijski niz). Ob dobrih podatkovnih povezavah take rešitve danes delujejo presenetljivo dobro in zanesljivo, s tem pa varne telefonske komunikacije postajajo dostopne širokemu krogu navadnih posameznikov.

Še več, sodobna odprtokodna tehnologija že danes omogoča vzpostavitev povsem lastne infrastrukture za zagotavljanje varnih VoIP komunikacij. V enem naslednjih prispevkov si bomo zato podrobneje pogledali odprtokodni projekt OSTN – Open Secure Telephone Network, ki nam omogoča, da z uveljavljenimi tehnologijami zgradimo lastno telefonsko omrežje, v katerega se je mogoče povezovati tako iz Linux, Windows in Mac osebnih računalnikov kot tudi iz Android, iPhone in BlackBerry pametnih mobilnikov.

V osnovi strežniške infrastrukture je odprtokodna SIP centrala Freeswitch, na strani Android odjemalcev CSipSimple (odjemalci za ostale sisteme so nekateri brezplačni, nekateri pa plačljivi). Trenutno skupina razvijalcev zbranih okrog The Guardian Projecta upravlja OSTN storitev ostel.me, ki pa je iz Slovenije nekoliko slabše dostopna (strežnik se nahaja v Amazon oblaku na vzhodni obali ZDA in ima občasno kar velike zamike), kvaliteta telefonske povezave pa zato nizka. Predstavili pa bomo tudi svojo lastno rešitev, ki je trenutno še v fazi začetnega testiranja. A kot rečeno, o tem nekoliko podrobneje v enem prihodnjih prispevkov, kjer si bomo tudi pogledali kako enostavno je prestrezanje nešifriranih VoIP komunikacij.