A hogyan: milyen szinten és az adatátvitel mely fázisában titkosítsunk?

Cikksorozatunk első részében már vázoltuk, hogy mely peremfeltételek szükségesek a biztonságos, a magánszférát megőrző kommunikáció megvalósításához; kitértünk az azonosítás, titkosítás és a hangminőség kérdéseire.

A második vizsgálati fázisban körüljártuk a két leggyakkrabban használt VoIP protokollt, elemeztük azok biztonsági kérdéseit, majd kiválasztásra került a megfelelő protokoll a biztonságos telefonáláshoz nyílt IP hálózatokon.

E cikkben részletesen megvizsgáljuk, hogy az átvitel mely fázisában, mely referencia ponton érdemes elvégezni a titkosítást? Módosítsuk a hangot kódolás előtt? Vagy csak a már kódolt hangot módosítsuk? Esetleg a teljes IP forgalmat?

A hangátvitel módja SIP hálózatok esetén

Valós idejű átviteli protokoll – Real Time Protocol (RTP)

A protokollt, mellyel valós idejű adatfolyamot küldünk egy hálózaton keresztül, egyszerűen valós idejű átviteli protokollnak, vagyis Real Time Protocol-nak (RTP) nevezik. Az RTP-t eredetileg az IETF definiálta az RFC1889-ben, míg a jelenleg érvényes definíciója az RFC3550.

Mikor az adatfolyamot sugározzuk, a protokollnak az alábbi feltételekkel kell megbirkóznia:

• A hálózaton a csomagok eltérő sorrendben érkezhetnek meg, így
• néhány csomag elveszhet.
• Jitter léphet fel (egyes csomagok jó sorrendben, de eltérő késleltetéssel érkezhetnek meg).

Ezen három közül az RTP csak két probléma megoldásával foglalkozik. A csomagvesztést illetően, a protokoll a “valósidejűséget” preferálja a megbízhatóság helyett. Ha néhány csomag nem érkezik meg időben, akkor gyakorlatilag elveszik, ugyanis ennél jóval fontosabb az adatfolyam valós idejű sugárzása. Ebből kifolyólag az RTP az UDP protokollt használja. A TCP nem alkalmas valós idejű adatátvitelhez, az újraküldési mechanizmusából kifolyólag.

Valósidejű szállítási és szabályozó protokoll – Real Time Control Protocol

Az RTCP kiegészíti az RTP protokollt és vezérlő információkat küld az RTP munkafázisáról. Az RTCP csomagok csak időről-időre kerülnek küldésre, mivel ajánlott, hogy az RTCP-forgalom a session sávszélességének 5%-nál kevesebbet fogyasszon.

A legfontosabb tartalomtípusok, melyet az RTCP szállít, a következőek:

• Információ a hívás résztvevőiről (pl. név és e-mailcím).
• Statisztika az átvitel minőségéről (pl. az elveszett csomagok száma). Azt a jelentést, amelyet a hívás azon résztvevője küld, aki egyaránt küld és fogad is adatokat, küldő/adó riportnak (sender report, SR) nevezik, míg azokat a jelentéseket, melyet az a résztvevő küld, aki csupán fogadja az RTP streameket, fogadó riportnak (receiver report, RR) hívják.

Létezik egy olyan szabály, hogy az RTP-nek páros UDP port számot kell használnia (pl. 5000), míg az RTCP a következő páratlan portot használja (pl. 5001).

A titkosítási lehetőségek

Mivel a különféle médiaadatok (audio/video) a legfontosabbak a biztonságos átvitel szempontjából, valamennyi ismertetésre kerülő szabvány titkosítja a media szintet

Az alábbi biztonsági techonlógiákat használják SIP/RTP-hez:

• Secure SIP + Secure RTP + S/MIME
• ZRTP + Secure RTP
• Psec és VPN kapcsolatok

Secure SIP

A Secure SIP egy olyan biztonsági mechanizmus, melyet a SIP RC 3261 definiál, s amely SIP üzeneteket küld egy úgynevezett TLS (Transport Layer Security) titkosítású csatornán keresztül. Bár eredetileg HTTP munkafázisok biztosítására használták, a TLS mégis képes rá, hogy megvédje a SIP munkafázisok kommunikációját is a lehallgatástól vagy külső befolyásolástól. Olyan SIP-alapú eszközök alkalmazásával, melyek támogatják a Secure SIP-et, a hálózati adminisztrátorok a VoIP hálózatukhoz egy magasabb szintű védelmet kapnak.

A vállalatok egyik fő aggálya, hogy külső károkozók lehallgathatják a SIP jelzésinformációkat középreállásos támadással („man in the middle attack”), mely megtéveszti a szervert vagy jogosulatlan hozzáférést biztosít a VoIP hálózatokhoz. Ezért a legalapvetőbb szintű biztonság, melyet minden egyes SIP-et használó végpontnak és proxy szervernek használnia kell, a Message Digest (MD5) azonosítás. Ez gondoskodik a legalapvetőbb azonosításról a SIP proxy szerver és a SIP-et használó végpont között. A SIP üzenetek titkosítására a S/MIME (Secure Multipurpose Internet Mail) szabvány is használható.

Az S/MIME SIP-támogatása nem annyira széleskörű, mint a HTML esetében, mivel szükséges hozzá a nyilvános kulcs infrastruktúra-támogatás (PKI – Public Key Infrastructure) és a biztonsági tanúsítvány bonyolultsága. A Secure SIP, amely TLS alapú SIP kommunikációt jelent, a biztonság egy magasabb szintjét kínálja, mint az alap MD5 azonosítás, az S/MIME járulékos többletterhelése nélkül.

A kulccsere SIP szinten történik, nem az RTP csomagokban. A biztonságos RTP a generált kulcsot használja a további szimmetrikus titkosításhoz. Ennek előnyei és hátrányai láthatóak az egyes táblázatban.

1. Táblázat A Secure SIP előnyei és hátrányai

ZRTP

A ZRTP esetében a SIP szerverek nem vesznek részt a titkosítási kulcsok kicserélésében, ami teljes mértékben az RTP media streamen keresztül történik. Miután a kulcsok elfogadásra kerültek, az SRTP-t használja a media stream csomagjainak alacsony szintű titkosítására. Ez minden SIP szabványos telefon esetében működik, de alapból csak azokat a hívásokat titkosítja, melyek során egy ZRTP végpontot hívunk. A ZRTP protokollt az IETF egy Internet Draft-ként nyújtotta be, hogy különböző eladóktó származó SIP/ZRTP végpontokat együttműködő-képességét lehetővé tegye.

A ZRTP protokollnak van néhány remek titkosítási jellemzője, mely sok egyéb VoIP titkosításból hiányzik. Habár egy nyilvános kulcs-algoritmust használ, sikeresen elkerüli a PKI bonyolultságát. Valójában egyáltalán nem használ állandó nyilvános kulcsot, mivel egy rövid azonosítási jelsort mutat a felhasználónak, hogy az szóban, a telefonon keresztül összehasonlíthassa azt. Tökéletes jövőbeni titkossággal rendelkezik, ugyanis a kulcsok a hívást követően megsemmisülnek, meggátolva a hívás visszamenőleges felfejthetőségét a fontos anyagok jövőben történő közlésével. Még ha a felhasználó túl lusta is ahhoz, hogy a rövid hitelesítési jelsorral bajlódjon, akkor is egy használható azonosítást kapunk, amely védelmet nyújt a középreállásos támadás ellen, egy kulcs-folyamatosságon alapulva. A ZRT mindezt úgy éri el, hogy gyorsítótárba tölti a kulcsfontosságú anyagokat, amelyek a következő híváskor kerülnek felhasználásra. Emellett az eljárás egyáltalán nem függ a SIP jelzéscsatornától és valójában egyáltalán nem függ egyetlen szervertől sem. A kulcsok cseréjét és menedzsmentjét kizárólag az RTP adatfolyamban végzi, mégpedig úgy, hogy automatikusan érzékeli, hogy a túlvég támogatja-e a ZRTP titkosítást.

Ezen szabvány legfőbb előnyei az együttműködési-képessége és az egyszerű telepíthetősége. Nem függ a külső keretrendszerektől.

Hálózati szintű biztonság

IPSec

Az IPSec (Internet Protocol Security ) egy olyan protokoll-együttes, mely az internet protokoll (IP) kommunikációját biztosítja egy adatfolyam minden egyes IP csomagjának azonosításával és titkosításával. Az IPSec emellett tartalmaz olyan protokollokat is, melyek kölcsönös azonosítást biztosítanak a végpontok között egy munkafázis kezdetén, valamint egyezteti azon titkosítási kulcsokat, melyek a munkafolyamat során használatba kerülnek. Az IPSec jól használható arra, hogy védje az adatfolyamot két kiszolgáló között (pl. computer felhasználók, vagy szerverek), két biztonsági átjáró (gateway) között (pl. routerek vagy tűzfalak) vagy egy biztonsági átjáró és egy kiszolgáló között.

Az IPSec egy kettős működésű, végpontok közötti biztonsági keret, mely az IP szinten működik, nagyjából a 3-as OSI szinten. Néhány egyéb, széles körben használt internet biztonsági rendszer, mint például az SSL, a TLS és a SSH ezen modellek felső rétegében működik. Az IPSec rugalmasabb, ugyanis egy alsóbb szinten működik, ezért használható több különböző típusú forgalom védelmére - az alkalmazásoknak nem is kell tudniuk az IPSec alsóbb szinten létezéséről.

VPN

A VPN, vagyis a virtuális magánhálózat egy olyan számítógépes hálózat, melyben a csomópontok közötti kapcsolatok némelyike nyílt hálózaton valósul meg (pl. a nyilvános interneten), szemben a hagyományos magánhálózatokkal, melyek általában egy vállalat belső hálózatát jelentik. A a VPN hálózatok link-layer protokolljai a külső hálózaton keresztül kötődnek össze, gyarkolatilag titkosított formában beágyazásra kerülnek a nyílt hálózaton átvitt csomagok tartalmába.

Egy ilyen módon kialakított VPN kapcsolaton keresztül létre hozott, egyébként nem titkosított adatátvitellel is biztonságos kapcsolatot lehet kialakítani. Az előnyők és hátrányok a következő táblázatban láthatóak.

2. Táblázat Az IPSec/VPN előnyei és hátrányai

A hang titkosítása codec előtt

Érdemes megvizsgálni azt a lehetőséget is, hogy a digitalizált beszédhangot, illetve video jelet még a codec felé történő továbbítás előtt titkosításnak vetjük alá!

Ennek a megoldásnak sajnos van egy óriási hátránya a korszerű VoIP adatátvitel esetén, mégpedig az, hogy a codec-ek többsége igen erősen optimalizált a beszédhangra, illetve a video jelekre. Ami annyit jelent, hogy a bejövő jelek esetében a codec emberi beszédhangot feltételez, és ezáltal tudja elérni a kívánt szintű, vissza nem nyerhetően veszteséges tömörítést. Ezen codec-ek esetén, ha a bemenetre egy titkosított adatfolyamot küldünk - a beszédhangtól jelentősen eltérő, fehér zaj-szerű jelsort - a hangátvitel lehetetlen lesz, ugyanis a codec képtelen lesz a beszédértés szempontjából elhanyagolható jeleket kiszűrni, és a titkosított adatfolyam módosításával teljesen visszaalakíthatatlanná teszi a csomagokat.

Ahogy az a leírtakból kiderül, ez a fajta megközelítés csak a veszteségmentes, nem optimalizált codec-ek esetén működhet, ez azonban nagyon erősen korlátozná a rendszer használhatóságát.

Codec szintű titkosítás

Szintén érdemes lehet megvizsgálni azt a lehetőségét, hogy egy aránylag népszerű, ingyenesen használható, forráskód szintjén elérhető codec implementációját módosítva, a beszédhang alapján már optimalizált csomagokra érdemes-e ráültetni egy titkosítási és azonosítási eljárást.

Bár a megoldás igen kézenfekvő, és akár szolgáltató-függetlenséget is tudna biztosítani, mégis hordoz néhány kellemetlenséget. Az implementációt gyakorlatilag minden használatban lévő codec esetén újonnan el kell végezni, ami jelentős többletmunkát eredményez. További problémát jelent a titkosítási kézfogás („handshake”) implementációja is, melyet úgy kell megoldani, hogy emiatt a titkosítást nem támogató végberendezéseknél ne lépjen fel hibás működés.

További nehézséget okoz, hogy bizonyos széles körben elterjedt codec-ek forráskódja nyilvánosan nem hozzáférhető, vagy nem módosítható.

Titkosítás az RTP szintjén

A legkézenfekvőbb lehetőség a ZRTP-hez hasonló, RTP szinten történő titkosítás felhasználása. Ez esetben a VoIP végpont a codec kimenetén előállt adatfolyamot titkosítaná akár tetszőleges titkosítási módszerrel és kulcshosszúsággal, a végpont számítási kapacitásának függvényében.

Ez lehetővé teszi gyakorlatilag bármilyen codec használatát, a titkosítás tetszőleges időpontban történő ki- és bekapcsolását, valamint szolgáltató-független működést az RTP adatfolyamban történő kulccsere és kézfogás protokolloknak megfelelően.

Összevetés és következtetés

A jelenleg létező biztonsági megoldások nagyjából ugyanazokon az algoritmusokon alapulnak. Ezek az algoritmusok különböző keretekben tevődnek össze. Ez igen különböző megoldásokat szavatol. Minden egyes megoldásnak meg vannak a maga előnyei és hátrányai.

3. Táblázat A létező biztonsági megoldások összehasonlítása

A Secure SIP és a különböző VPN felhasználások elsősorban a vállalati szektort célozzák meg, ahol a hálózati adminisztrátorok képesek beállítani ilyen rendszereket. A ZRTP felhasználások inkább a végfelhasználóknak szólnak.

Megjósolható, hogy a Secure IP és a VPN szabványok fontossága a vállalati VoIP szektorban csökkeni fog. Ezek helyett inkább a könnyen kezelhető megoldásokra (mint például a ZRTP) nő majd meg az igény.

Az összegzés alapján a legmegfelelőbb választásnak az RTP szintű, codec független titkosítás tekinthető.

Cikksorozatunk következő számában az alkalmazható titkosítási eljárások bemutatásával és a megfelelő eljárás kiválasztásával foglakozunk.

Jelen publikáció eredményei a GOP-1.1.1-08/1-2008-0015 számú, “Biometrikus azonosításon alapuló titkosított hangátvitelt megvalósító, szolgáltató-független, hordozható távközlési végberendezés prototípusának kifejlesztése” című projekt keretében került kidolgozásra.

Kapcsolat: zoltan.hegyes@bh-bess.com