BEZPEČNOST V OBLASTI VOIP

BEZPEČNOST V OBLASTI VOIP Tomáš VANĚK pracoviště: ČVUT FEL, Katedra telekomunikační techniky; mail: vanek1@fel.cvut.cz Abstrakt: Vznik a nasazení VoIP technologií představuje velký zlom v oblasti telekomunikací. VoIP protokoly slibují omezení nákladů na technické vybavení a provozní náklady podobně jako IPTV nebo IMS (IP Multimedia Subsystem). Současné hlasové služby realizované v PSTN (Public Switched Telephone Network) nabízejí vysokou kvalitu hlasových služeb a vysokou dostupnost a to vše s vysokou mírou bezpečnosti. Aby VoIP sítě mohly konkurovat klasickým telefonním sítím je nezbytné, aby byly schopné zajistit identickou nebo lepší úroveň kvality, spolehlivosti a zabezpečení, než jaké poskytují PSTN. Právě bezpečnost VoIP komunikace je jedna z velkých bariér bránících masovému rozšíření VoIP. Pro bezpečnou implementaci VoIP protokolů do sítě je nutné pochopit rozdíly mezi VoIP a klasickými datovými sítěmi. Tento dokument popisuje tyto odlišnosti, nové typy útoků, které se ve VoIP sítích mohou vyskytovat a způsoby obrany proti nim. 1 Úvod VoIP sítě nejsou jen další z mnoha aplikací využívající protokoly z rodiny IP. Charakteristickými rysy VoIP protokolů jsou vysoká citlivost na QoS parametry, komunikace v reálném čase, velké množství různých zařízení a aplikací tvořících infrastrukturu sítě a nutnost jejich vzájemné komunikace a interakce s existující klasickou telefonní sítí. Tyto charakteristiky vyžadují nové postupy a metody, které zajistí spolehlivost a bezpečnost odpovídající klasické PSTN. Například v datových sítích běžný útok odmítnutím služby (DoS) může vést k nedostupnosti nabízené služby i po dobu několika hodin. Abychom dosáhli dostupnosti dosahované v PSTN (typicky 99,999 %), pak musí být výpadek kratší než 5 minut za rok. To znamená, že k dosažení odpovídající míry spolehlivosti, musí být jakýkoliv útok odražen v řádu sekund. VoIP sítě musí mít mechanismy, které umožní automatickou reakci v reálném čase. Útok tak musí být zastaven, ještě než způsobí přerušení služby, nebo zhoršení jejích parametrů. Vysoká citlivost VoIP protokolů na QoS parametry, jako je zpoždění paketů, ztráta paketů nebo jiter je další překážkou pro implementaci klasických bezpečnostních opatření používaných v datových sítích. Většina firewallů a systémů pro detekci/prevenci síťových útoků (IDS/IPS) spoléhá na hloubkovou analýzu paketů, což může nepříznivě ovlivnit kvalitativní parametry spojení. Je potřeba najít rozumný kompromis mezi zabezpečením a kvalitou. Použitím šifrovacích algoritmů sice zvýšíme bezpečnost, ale na druhé straně opět zvyšujeme jiter a zpoždění. To platí zvlášť v případech, kdy se šifruje mezi jednotlivými Proxy servery (hop-by-hop encryption) a v každém bodu je potřeba přicházející tok dešifrovat, a následně zase zašifrovat. VoIP komunikace probíhá v reálném čase, a pokud dojde ke ztrátě nebo poškození paketu, není možné ho znovu získat. To má opět vliv na metody zabezpečování, které musí být vůči těmto eventualitám odolné. Z těchto faktů vyplývá, že problematice zabezpečení VoIP sítí je potřeba věnovat velkou pozornost a nelze pouze jednoduše přebírat zabezpečovací metody z klasických datových sítí. Vrstva VoIP aplikací (softpone, call manager, call centrum,...) Vrstva VoIP protokolů Signalizační protokoly (, H.323, IAX ) Transportní protokoly (RTP,UDP, ) Vrstva podpůrných protokolů a služeb pro VoIP (DHCP, TFTP,DNS,E.164,NAT,AAA...) Vrstva OS a síťová vrstva (Linux, Windows, MAC,IP,ARP ) HW vrstva (IP telefon, PC, PDA, ) Obr. 1: Vrstvy VoIP systému strana 129

VoIP systémy využívají celé řady dalších protokolů, služeb a subsystémů, které lze rozdělit do logických vrstev, jak je znázorněno na obr.1. U protokolů jednotlivých na vrstvách, pak lze nalézt různé typy útoků a zranitelností. Příklady bezpečnostních rizik objevujících se na jednotlivých vrstvách: Vrstva OS Buffer overflow chyby Chyby při zpracování vstupních řetězců Lámání hesel pro konfiguraci zařízení Zahlcení zařízení (DoS,DDoS útok) ARP cache poisoning Prolomení WEP klíče (u WiFi IP telefonů) Vrstva signalizačních VoIP protokolů Přerušení spojení Únos relace Falšování identity Poškozování přenášených zpráv Zacyklení zpráv Zahlcení (DoS,DDoS) Vrstva podpůrných protokolů a služeb Útoky na protokoly a služby, které jsou VoIP systémy využívány: HTTP, SNMP, LDAP DHCP, DNS, TFTP, SQL Příkladem může být třeba SQL injection, DHCP/DNS spoofing,.. Vrstva signalizačních VoIP protokolů Přerušení spojení Únos relace Falšování identity Poškozování přenášených zpráv Zacyklení zpráv Zahlcení (DoS,DDoS) Vrstva aplikací a služeb Buffer overflow chyby Chyby při zpracování vstupních řetězců Chyby ve skriptech Lámání hesel pro konfiguraci zařízení Zahlcení zařízení (DoS,DDoS útok) Chyby v číslovacích plánech V rámci tohoto článku bude největší pozornost věnována problematice zabezpečení na úrovni vrstvy VoIP protokolů. 2 Odposlech hovoru realizovaného pomocí VoIP Přestože se následující možnosti zachycení a odposlechu týkají převážně protokolu, ostatní VoIP protokoly (IAX, MGCP, SCCP, H.323) trpí obdobnými chybami a zranitelnostmi. Bezpečnostní hrozby ve VoIP systémech lze rozdělit mnoha různými způsoby a obvykle je možné je zařadit do jedné ze čtyř kategorií: Útoky na dostupnost služby. Zlomyslné aktivity s cílem narušit integritu služeb (např. špatné účtování). SPIT (SPAM over IP Telephony). Odposlouchávání/záznam hovoru. Odposlouchávání je typ hrozby, které se běžný uživatel asi bojí nejvíce. Řada lidí při telefonování automaticky předpokládá, že hovor je do jisté míry chráněn proti odposlechu, a že odposlech vyžaduje nasazení složité techniky, kterou má k dispozici pouze policie nebo velcí telekomunikační operátoři. V porovnání s hovory probíhajícími v klasické PSTN je však riziko odposlechu a zaznamenání hovoru výrazně vyšší a k jeho realizaci stačí některý z řady volně dostupných nástrojů. Existuje celá řada volně dostupných nástrojů pro analýzu a zpětnou rekonstrukci zachycených paketů do souboru, který lze přehrát. strana 130

VoIPong analýza H.323,, SCCP http://www.enderunix.org/voipong/ VOMIT analýza SCCP http://vomit.xtdnet.nl/ OREKA analýza a rekonstrukce RTP relací nezávislý na signalizačním protokolu, http://oreka.sourceforge.net Cain & Abel analýza, MGCP http://www.oxid.it/cain.html Rtpbreak analýza a rekonstrukce RTP relací nezávislý na signalizačním protokolu http://xenion.reactive-search.com/?page_id=7 Wireshark primárně určen k zachytávání a analýzu síťového provozu umí rekonstruovat RTP relace v případě použití kodeku G.711 i přehrávat podporuje, H.323, SCCP, MGCP www.wireshark.org Všechny zmíněné nástroje pracují na obdobném principu: 1) Zachycení IP paketů obsahujících hovor. 2) Rekonstrukce RTP relace. 3) Úprava hovoru do formátu, který může být přehrán v počítači. Aby útočník mohl zachytit paketů s hovorem, musí mít přístup k některému síťovému prvku na trase volání. Přestože tato podmínka se zdá na první pohled zřejmá, je dobré ji pro jistotu připomenout. Při zachytávání VoIP komunikace je potřeba myslet také na to, že zde existuje dvě nezávislá spojení signalizační a datové, přenášející vlastní hovor. Obě spojení se mohou v závislosti na topologii šířit různými cestami, proto je z hlediska útočníka ideální provádět odposlech v jednom z koncových bodů spojení. V reálném světě existují faktory, které znesnadňují odposlech VoIP hovoru. Jedná se zejména o omezení fyzického přístupu k síťovým prvkům, omezení přístupu k datovým tokům v síti, monitorování bezpečnosti v síti pomocí IDS/IPS, omezení daná topologií sítě, použitím šifrování apod. Zachytit nějaký VoIP provoz v síti není pro technicky zdatného uživatele obvykle velký problém. Problémem zůstává jak zachytit provoz v místě, kudy probíhají hovory, které útočníka zajímají. Aby to bylo možné, musí nejprve kompromitovat síťový prvek, kterým hovor prochází. To se může v mnoha případech podařit díky nějaké známé chybě zařízení, chybějícím záplatám, špatně zvoleným heslům, špatné konfiguraci apod. Útočník působící uvnitř sítě (insider) má obvykle větší možnost získat přístup než útočník útočící zvnějšku sítě (outsider), protože většina bezpečnostních mechanismů je zaměřena na průniky z vnějšku. V literatuře se obvykle uvádí, že převažující procento útoků pochází od vnitřních útočníků, ale ze závěrů podle posledních průzkumů [1] plyne opačný názor. Nicméně škoda způsobená v síti vnitřními útočníky je přes velký počet vnějších útočníků stále výrazně větší. To jsou další z faktů, které je nutné brát v potaz při zabezpečování sítě. 3 Zabezpečení VoIP sítě Doporučované kroky při zabezpečení lokální sítě s ohledem na zabezpečení hlasových služeb: 1) Řízení přístupu k síťovému médiu na úrovni portů. 2) Oddělení hlasových a nehlasových služeb. 3) Zabezpečení signalizačních spojení. 4) Zabezpečení RTP spojení. Těchto cílů lze dosáhnout pomocí následujících dostupných technologií: strana 131

3.1 Řízení přístupu k síťovému médiu Teorie a praxe IP telefonie - 3. dvoudenní odborný seminář Pro zajištění bezpečnosti na úrovni portů lze využít doporučení IEEE 802.1x, které definuje bezpečnostní rámec pro autentizaci v lokálních sítích. Základem architektury jsou tři vzájemně komunikující entity: Suplikant entita (PC, IP telefon), která se chce přihlásit do sítě. Autentizátor aktivní síťový prvek, který v průběhu autentizace plní roli zprostředkovatele. Se suplikanty autentizátor komunikuje protokolem EAPOL (EAP over LAN). Získané autentizační informace jsou předány autentizačnímu serveru, který povolí či zamítne přístup klienta do sítě. Autentizační server obsahuje informace umožňující ověřit identitu suplikanta. S autentizátorem komunikuje obvykle protokolem RADIUS. Suplikant Suplikant Autentizátor Autentizační server PC IP telefon Přepínač EAPoL EAPoL Radius Obrázek 1 - Bezpečná autentizace pomocí 802.1x Bezpečná autentizace představuje, pouze jeden z pilířů informační bezpečnosti. Mezi další patří utajení přenášených informací a zajištění jejich integrity. Spojení mezi koncovým zařízením (IP telefon) a síťovým prvkem (switch) není na úrovni spojové vrstvy z tohoto úhlu pohledu nijak zabezpečeno. Je tedy možné data jednoduše odposlechnout a/nebo modifikovat. Komplexní řešení přináší až doporučení IEEE 802.1AE-2006, které definuje šifrování rámců na spojové vrstvě. Využívá se zde algoritmus AES-128 v čítačovém režimu (CM Counter Mode), který kromě šifrování, dokáže také zajistit ochranu proti útokům opakovaným přehráváním zpráv (replay attack). S tímto doporučením úzce souvisí i návrh doporučení IEEE 802.1af (poslední verze je z února 2008), které opět na úrovni spojové vrstvy řeší problematiku bezpečné výměny šifrovacích klíčů. V praxi se zatím podpora doporučení 802.1AE a 802.1af nevyskytuje. 3.2 Oddělení hlasového a datového provozu Tohoto cíle lze dosáhnou pomocí mechanismu virtuálních sítí definovaných v doporučení IEEE 802.1q známých též jako VLAN (Virtual LAN). Hlasové VLAN se pak označují VVLAN (Voice VLAN). strana 132

Hlasová VLAN VLAN ID=200 IP telefon UTP kabel Datový provoz Hlasový provoz Datová VLAN VLAN ID=100 PC Obrázek 2 - Oddělení datového a hlasového provozu pomocí VLAN Řada výrobců doporučuje zcela oddělit VoIP provoz od datových přenosů umístěním VoIP zařízení do speciálních hlasových VLAN (VVLAN - Voice VLAN). Tento přístup má řadu výhod. Jednou z výhod je skutečnost, že v některých situacích, lze zavedením hlasových VLAN zjednodušit konfiguraci sítě. Konkrétně to znamená ulehčení při značení paketů pro QoS, kdy stačí prioritizovat všechny pakety z hlasové VLANy. Díky seskupení všech IP telefonů do jedné sítě je jednoduší i konfigurace TFTP DHCP serverů. Neposlední výhoda využití hlasových VLAN je v tom, že VoIP zařízení se nemusí zabývat všemi broadcasty v síti, ale pouze těmi, které jsou generovány v rámci hlasové VLAN. 3.3 Zabezpečení signalizačních spojení Rozšířená HTTP autentizace V praxi nejčastěji používaný způsob autentizace. Funguje na principu výzva-odpověď. Heslo a náhodný řetězec označovaný jako výzva (challenge) jsou přivedeny na vstup hashovací funkce MD-5 nebo SHA-1 a výsledek je poté odeslán. Tato varianta autentizace je bezpečnější než základní HTTP autentizace, protože zde nedochází k přenosu hesla v otevřeném tvaru. V případě volby slabého hesla je tato metoda náchylná na slovníkový útok. Další nevýhodou je fakt, že žádným způsobem není zajištěno utajení a integrita vyměňovaných zpráv. nekde.org jinde.org proxy proxy RTP prvni@nekde.org druhy@jinde.org Obrázek 3 - Klasické sestavení nezbezpečeného spojení S Použití URI (Uniform Ressource Identifier) ve tvaru sips:volany@nejakadomena.cz místo sip:volany@nejakadomena.cz. ve zprávě INVITE indikuje požadavek na zabezpečení celé cesty pomocí protokolu TLS. TLS je mírně inovovaný protokol SSL. Protože každý proxy server na cestě mezi zdrojem a strana 133

cílem přidává do záhlaví své směrovací informace, musí se zabezpečení pomocí TLS realizovat mezi každými dvěma zařízeními v cestě. Další podmínkou je použití TCP jakožto protokolu transportní vrstvy a existence PKI pro správu certifikátů resp. klíčů. TLS tunel nekde.org TLS tunel jinde.org TLS tunel SRTP prvni@nekde.org druhy@jinde.org Obrázek 4 - Zabezpečení signalizace pomocí S S/MIME Doporučení MIME (Multipurpose Internet Mail Extensions) bylo původně definováno pro potřeby e-mailové komunikaci. Definuje formát zpráv, tak aby mohly být vyměňovány mezi různými poštovními servery. Těla MIME zpráv mohou obsahovat text, obrázky, ale i video a zvuk, což je činí použitelnými také pro IP telefonii. Standard S/MIME rozšiřuje MIME o metody umožňující zabezpečení komunikace a to pomocí kontroly integrity a šifrováním. K identifikaci koncového uživatele a jeho veřejného klíče jsou používány certifikáty podle doporučení X.509. Zprávy S/MIME tedy obsahují MIME tělo, které je šifrováno symetrickou šifrou, a dále symetrický klíč k jejímu dešifrování. Autentizace uživatelů probíhá pomocí certifikátů X.509. Určitý problém představuje šifrování zpráv MIME (např. obsah paketů), protože k šifrování se používá veřejný klíč příjemce, který je potřeba nejprve získat z příslušného certifikátu X.509 a ověřit jejich platnost. Proto se musí tyto klíče získat a ověřit ještě před vlastním přenosem z nějakého veřejného zdroje nebo pomocí speciální zprávy. Dalším problémem je, že certifikační autorita (CA) vydávající certifikáty musí být důvěryhodná pro všechny účastníky komunikace. Protože self-signed certifikáty (tj. certifikáty, které si může vygenerovat každý uživatel) nezaručují dostatečnou míru bezpečí, je nutné použít certifikáty vydané některou renomovanou komerční CA (např.verisign, Thawte, ), což zvyšuje celkové náklady na implementaci. nekde.org v TLS jinde.org v S/MIME SRTP prvni@nekde.org Obrázek 5 - Zabezpečení signalizace pomocí S+S/MIME druhy@jinde.org strana 134

IP Security (IPsec) IPsec je zcela obecný nástroj k realizaci bezpečných šifrovaných spojení. Pracuje na síťové vrstvě a je tvořen třemi základními protokoly AH, ESP a IKE. Pro zabezpečení u lze použít protokoly AH nebo ESP v transportním režimu. Potřebné bezpečnostní asociace (SA) mohou být sestaveny trvale a nezávisle na ových UA nebo mohou být vytvářeny podle potřeby samotnými UA nebo proxy servery. Protokol IKE slouží k nastavení bezpečnostních asociací a podporuje jak autentizaci pomocí PSK (předsdílených klíčů), tak i na základě PKI. Varianta s PSK se nehodí pro sítě s velkou fluktuací klientů. Tam se hodí spíše verze s certifikáty X.509 a PKI. Tato varianta je ale náročná nejen z finančního hlediska ale i vyšší obtížnosti konfigurace (v porovnání s PSK). 3.4 Zabezpečení datových spojení Hlasové streamy se v IP sítích přenášejí pomocí protokolu RTP (Real-Time Protocol), který jako transportní protokol používá UDP. Existují dva standardizované kryptografické protokoly, které vyhovují tomuto zadání a jsou k dispozici a dva, který jsou zatím ve stádiu draftu (návrhu). Jedná se o protokoly IPsec, SRTP, zrtp a DTLS. IPsec IPsec umožňuje zabezpečit datový proud na úrovni síťové vrstvy. Je zde možné využít stejných bezpečnostních asociací, jaké byly použity při zabezpečení signalizačního kanálu. Hlavní nevýhodou je velká režie IPsecu (37B na RTP paket v případě šifrování pomocí 3DES a 53B na RTP paket v případě použití algoritmu AES-128) a špatná schopnost průchodu IPsec paketů skrz NAT. Secure RTP (SRTP) Secure Real-time Transport Protocol (SRTP) představuje rozšíření RTP. Základním cílem je pro RTP a RTCP pakety zajistit utajení, autentizace a ochranu proti replay útokům (útok opakovaným přehraním zpráv). O utajení se stará moderní algoritmus AES v režimu CTR, který nijak nezvětšuje velikost přenášených dat. Data jsou na druhé straně zvětšena o autentizační hlavičku, která každý paket navýší o 10B. ZRTP ZRTP je rozšíření standardního RTP. Popisuje implemtaci Diffie-Hellmanova algoritmu pro výměnu klíčů, který umožňuje vygenerovat sdílenou tajnou informaci, kterou lze poté použít k sestavení zabezpečeného spojení pomocí SRTP. V současné době je protokol ve stádiu IETF draftu. Jednou z výhod ZRTP je skutečnost, že k sestavení zabezpečeného spojení nepotřebuje PKI nebo předsdílené klíče (PSK). ZRTP dále používá mechanismus SAS (Short Authencication String), který řeší náchylnost na man-in-the-middle útok. Ten spočívá ve výpočtu hashe dvou Diffie-Hellmanových hodnot. Každá strana si spočítá hodnotu SAS na své straně komunikačního řetězce. Jiným kanálem (např. telefonním) si sdělí vypočtenou hodnotu SAS. Pokud jsou stejné, pak s velkou pravděpodobností není kanál předmětem útoku.. Útočník může pouze odhadovat jaké SAS má odeslat a již při malých velikostech SAS je jen málo pravděpodobné, že jeho útok nebude odhalen. Pro SAS délky 16 bitů je pravděpodobnost odhalení více než 99,9985% (1:65535). Dalším prvkem zvyšujícím odolnost proti MitM útokům je kontinuita klíčů, kdy si obě strany uchovávají hashe z klíčů použitých v daném hovoru, aby je v příštím hovoru smíchaly se sdílenou tajnou informací vyměněnou pomocí Diffie-Hellmanova algoritmu. Tento postup zajistí, že pokud nebyl MitM útok vedený v prvním hovoru, nemůže být úspěšný ani v žádném dalším. strana 135

nekde.org jinde.org SRTP prvni@nekde.org DTLS Datagram TLS Výměna klíčů pro SRTP v datovém kanálu Obrázek 6 - Zabezpečení pomocí ZRTP druhy@jinde.org DTLS představuje implementaci protokolu TLS v kombinaci s transportním protokolem UDP. Protokol je popsán v RFC 4347. Podobného cíle se snažil dosáhnout již dříve protokol WTSL, ale díky velké odlišnosti od TLS se nikdy nerozšířil. Naproti tomu DTLS maximálně využívá elementy TLS s minimálními možnými modifikacemi, které umožňují funkčnost s protokolem UDP. Protokol DTLS by mohl v některých případech sloužit jako náhrada SRTP k zabezpečení RTP datových streamů. 4 Zabezpečení VoIP sítí u českých operátorů V rámci zjišťování, jak jsou na tom z hlediska zabezpečení čeští VoIP operátoři, jsem pomocí vyhledávače Google hledal různá klíčová slova vztahující se k problematice zabezpečení. Hledání bylo vždy omezeno na doménu jednoho provozovatele VoIP sítě. Vyhledávací fráze: hledane_slovo site:domena.operatora.cz Hledaná slova: S, SRTP, ZRTP, S/MIME, IPsec, AES, DES, bezpečnost, zabezpečení, šifrování K otestování jsem vybral 10 firem nabízejících telefonování přes VoIP. Seznam byl získán ze stránek diskusního fóra telefonujeme.cz, které se problematice VoIP komunikace dlouhodobě věnuje. Operátoři, které jsem testoval, jsou uvedeni v abecedním pořadí: 802.VOX, České Radiokomunikace, EriVoIP, FAYN, GTS Novera, ha-loo, IPVOX, VoIPEX, Viphone, XPhone. Na žádný takto položený dotaz jsem u žádného operátora nedostal relevantní odpověď, která by obsahovala informace o možnosti zabezpečení hovorů v dané síti. Jedinými pozitivními výsledky hledání bylo několik odkazů na manuály k bezdrátovým přístupovým bodům (podpora protokolů WEP, WPA nesouvisí s VoIP), a návod na telefon Linksys SPA941 (podpora protokolu SRTP). Oproti roku 2006, kdy jsem provedl obdobný průzkum, tak nedošlo u českých operátorů bohužel k žádné změně. 5 Závěr Bezpečnost je ta část VoIP systémů, o které se zatím příliš nemluví a ani neuvažuje. Nutnost chránit informace přenášené VoIP systémy zatím řadě uživatelů buďto nedochází, nebo dochází, ale neřeší ji. Samotní výrobci VoIP zařízení a operátoři neradi slyší, že IP telefonie je obecně náchylná na všechny typy útoků, které sužují klasické datové sítě včetně virů, trójských koní, DoS útoků, SPAMu, phishingu, tarifikačních podvodů a odposlouchávání. Možnost se účinně vypořádat s VoIP hrozbami vyžaduje kromě nasazení nejrůznějších technických prostředků, které jsou k dispozici, v nespolední řadě také existenci zodpovědných a poučených uživatelů. A to může být větší problém než implementace nejsilnějších šifrovacích algoritmů a nejlepších kryptografických protokolů. strana 136

Literatura [1] Schneier, B.: IT Attacks: Insiders vs. Outsiders, [online, cit. 2008-10-26]. Dostupné z: <http://www.schneier.com/blog/archives/2008/06/it_attacks_insi.html> [2] J. Arkko et al.: RFC 3329 - Security Mechanism Agreement for the Session Initiation Protocol (), IETF, [online cit. 2008-10-18]. Dostupné z: <http://www.ietf.org/rfc/rfc3329.txt> [3] Baugher M., et al.,the Secure Real-time Transport Protocol, IETF, [online cit. 2008-10-18]. Dostupné z: http://www.ietf.org/rfc/rfc3711.txt> [4] Audet F., The use of the S URI Scheme in the Session Initiation Protocol (), IETF draft, [online, cit. 2008-10-28]. Dostupné z: <http://tools.ietf.org/html/draft-ietf-sip-sips-08#section-3.1.3> [5] D. Richard Kuhn, Thomas J. Walsh, Steffen Fries.: Security Considerations for Voice Over IP Systéme, NIST Special Publication 800-58, [online, cit. 2008-10-25]. Dostupné z: <http://csrc.nist.gov/publications/nistpubs/800-58/sp800-58-final.pdf> [6] Dočkal J., Malina R., Markl J.,Vaněk T.: Bezpečnost internetové telefonie, DSM - Data Security Management, ročník X., č. 6/2006, str. 36-42, ISSN 1211-8737 [7] Zimmerman P. et al - ZRTP: Media Path Key Agreement for Secure RTP, IETF draft, [online, cit. 2008-10- 28]. Dostupné z: <http://tools.ietf.org/html/draft-zimmermann-avt-zrtp-10> [8] Materna B. et al: A Proactive approach to VoIP security, VoIPshield Systems, [online, cit. 2008-10-27]. Dostupný z: <www.voipshield.com/resources/whitepapers-proactive.php> strana 137

strana 138