ZABEZPEČENÍ VOIP TELEFONIE VOIP SECURITY

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS

ZABEZPEČENÍ VOIP TELEFONIE VOIP SECURITY

BAKALÁŘSKÁ PRÁCE BACHELOR’S THESIS

AUTOR PRÁCE

MICHAL ČERNÝ

AUTHOR

VEDOUCÍ PRÁCE SUPERVISOR

BRNO 2008

ING. PETR KOVÁŘ

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ Fakulta elektrotechniky a komunikačních technologií Ústav telekomunikací

Bakalářská práce bakalářský studijní obor Teleinformatika Student: Ročník:

Černý Michal 3

ID: 83083 Akademický rok: 2007/2008

NÁZEV TÉMATU:

Zabezpečení VoIP telefonie POKYNY PRO VYPRACOVÁNÍ: Prostudujte Open Source ústřednu Asterisk, zabezpečení protokolu SIP, RTP a SRTP. Analyzujte možnosti využití Secure RTP a jeho podporu u klientských zařízení. Na základě poznatků z teoretické části práce realizujte systém, jehož základem bude Open Source ústředna Asterisk, který bude podporovat zabezpečené IP telefonii pomocí Secure RTP. Dosažené výsledky diskutujte s předpoklady získanými v teoretické části práce. Jako přílohu realizujte laboratorní úlohu, která bude prakticky demonstrovat poznatky a závěry dosažené v práci. DOPORUČENÁ LITERATURA: [1] ENDLER, D., COLLIER, M., Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions.McGraw-Hill Osborne Media, 2006. ISBN 978-0072263640 [2] PORTER, T., KANCLIRZ, J., Practical VoIP Security. Syngress, 2006. ISBN 978-1597490603 Termín zadání:

11.2.2008

Vedoucí práce:

Ing. Petr Kovář

Termín odevzdání:

4.6.2008

prof. Ing. Kamil Vrba, CSc. předseda oborové rady

UPOZORNĚNÍ: Autor bakalářské práce nesmí při vytváření bakalářské práce porušit autorská práve třetích osob, zejména nesmí zasahovat nedovoleným způsobem do cizích autorských práv osobnostních a musí si být plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb., včetně možných trestněprávních důsledků vyplývajících z ustanovení § 152 trestního zákona č. 140/1961 Sb.

LICENČNÍ SMLOUVA POSKYTOVANÁ K VÝKONU PRÁVA UŽÍT ŠKOLNÍ DÍLO uzavřená mezi smluvními stranami: 1. Pan/paní Jméno a příjmení:

Michal Černý

Bytem:

Žižkova 963, 53501, Přelouč

Narozen/a (datum a místo):

4.1.1985, Chlumec nad Cidlinou

(dále jen "autor") a 2. Vysoké učení technické v Brně Fakulta elektrotechniky a komunikačních technologií se sídlem Údolní 244/53, 60200 Brno 2 jejímž jménem jedná na základě písemného pověření děkanem fakulty: prof. Ing. Kamil Vrba, CSc. (dále jen "nabyvatel")

Článek 1 Specifikace školního díla 1. Předmětem této smlouvy je vysokoškolská kvalifikační práce (VŠKP): disertační práce diplomová práce bakalářská práce jiná práce, jejíž druh je specifikován jako ......................................................... (dále jen VŠKP nebo dílo) Název VŠKP:

Zabezpečení VoIP telefonie

Vedoucí/školitel VŠKP:

Ing. Petr Kovář

Ústav:

Ústav telekomunikací

Datum obhajoby VŠKP: ......................................................... VŠKP odevzdal autor nabyvateli v: tištěné formě

- počet exemplářů 1

elektronické formě

- počet exemplářů 1

2. Autor prohlašuje, že vytvořil samostatnou vlastní tvůrčí činností dílo shora popsané a specifikované. Autor dále prohlašuje, že při zpracovávání díla se sám nedostal do rozporu s autorským zákonem a předpisy souvisejícími a že je dílo dílem původním. 3. Dílo je chráněno jako dílo dle autorského zákona v platném znění. 4. Autor potvrzuje, že listinná a elektronická verze díla je identická.

Článek 2 Udělení licenčního oprávnění 1. Autor touto smlouvou poskytuje nabyvateli oprávnění (licenci) k výkonu práva uvedené dílo nevýdělečně užít, archivovat a zpřístupnit ke studijním, výukovým a výzkumným účelům včetně pořizovaní výpisů, opisů a rozmnoženin. 2. Licence je poskytována celosvětově, pro celou dobu trvání autorských a majetkových práv k dílu. 3. Autor souhlasí se zveřejněním díla v databázi přístupné v mezinárodní síti ihned po uzavření této smlouvy 1 rok po uzavření této smlouvy 3 roky po uzavření této smlouvy 5 let po uzavření této smlouvy 10 let po uzavření této smlouvy (z důvodu utajení v něm obsažených informací) 4. Nevýdělečné zveřejňování díla nabyvatelem v souladu s ustanovením § 47b zákona č. 111/1998 Sb., v platném znění, nevyžaduje licenci a nabyvatel je k němu povinen a oprávněn ze zákona.

Článek 3 Závěrečná ustanovení 1. Smlouva je sepsána ve třech vyhotoveních s platností originálu, přičemž po jednom vyhotovení obdrží autor a nabyvatel, další vyhotovení je vloženo do VŠKP. 2. Vztahy mezi smluvními stranami vzniklé a neupravené touto smlouvou se řídí autorským zákonem, občanským zákoníkem, vysokoškolským zákonem, zákonem o archivnictví, v platném znění a popř. dalšími právními předpisy. 3. Licenční smlouva byla uzavřena na základě svobodné a pravé vůle smluvních stran, s plným porozuměním jejímu textu i důsledkům, nikoliv v tísni a za nápadně nevýhodných podmínek. 4. Licenční smlouva nabývá platnosti a účinnosti dnem jejího podpisu oběma smluvními stranami.

V Brně dne: ............................................................

............................................................

............................................................

Nabyvatel

Autor

ABSTRAKT Internetová telefonie se dnes stává stále oblíbenější alternativou klasické telefonní služby. Důvodem může být její cena a také dostupnost. S oblíbeností rostou ale také rizika případného zneužití přenášených informací. Způsobů, jak zabezpečit VoIP komunikaci, se nabízí několik. Tato práce je věnována především jednomu, kterým je využití Secure RTP. Bude provedena jeho implementace do softwarové telefonní ústředny Asterisk a ověřena funkčnost zkušebními hovory i analýzou siťového provozu.

KLÍČOVÁ SLOVA VoIP, Asterisk, SIP, RTP, SRTP

ABSTRACT Internet telephony becomes still more popular option to common telephone service. Reason may be it’s price as well as availability. With growing popularity grows the risk of unauthorized use of transferred data too. There are several ways to secure VoIP communication. This bachelor’s thesis talk about one of many, which is use of Secure RTP. There will be made it’s implementation in the software telephone exchange Asterisk and tested functionality by trial talks and analysis of network traffic as well.

KEYWORDS VoIP, Asterisk, SIP, RTP, SRTP

PROHLÁŠENÍ Prohlašuji, že svou bakalářskou práci na téma „Zabezpečení VoIP telefonieÿ jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím odborné literatury a dalších informačních zdrojů, které jsou všechny citovány v práci a uvedeny v seznamu literatury na konci práce. Jako autor uvedené bakalářské práce dále prohlašuji, že v souvislosti s vytvořením této bakalářské práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb., včetně možných trestněprávních důsledků vyplývajících z ustanovení § 152 trestního zákona č. 140/1961 Sb.

V Brně dne

...............

.................................. (podpis autora)

Děkuji vedoucímu bakalářské práce Ing. Petru Kovářovi za velmi užitečnou pomoc a cenné rady při zpracování bakalářské práce.

OBSAH Úvod

11

1 VoIP obecně 12 1.1 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2 Současnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3 Budoucnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2 Princip VoIP

15

3 Protokoly 3.1 Session Initiation Protocol . . . . . . 3.1.1 Služby . . . . . . . . . . . . . 3.1.2 Architektura . . . . . . . . . . 3.1.3 Komunikace v SIP . . . . . . 3.1.4 Obsah hlavičky . . . . . . . . 3.1.5 Adresy . . . . . . . . . . . . . 3.1.6 Způsoby spojení . . . . . . . . 3.1.7 Signalizace . . . . . . . . . . . 3.1.8 Registrace uživatele . . . . . . 3.2 RTP (Real-time Transport Protocol) 3.2.1 Hlavička RTP . . . . . . . . .

. . . . . . . . . . .

16 16 16 17 18 19 19 20 21 23 24 25

. . . . . . .

26 26 26 26 26 27 27 27

. . . . . .

28 28 29 29 30 30 32

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

4 Zabezpečení VoIP 4.1 Důvody zabezpečení . . . . . . . . . . . . . . . . . . 4.2 Způsoby zabezpečení . . . . . . . . . . . . . . . . . . 4.2.1 Zfone . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Zabudované šifrování . . . . . . . . . . . . . . 4.2.3 Užití TLS a IPsec . . . . . . . . . . . . . . . . 4.2.4 VPN . . . . . . . . . . . . . . . . . . . . . . . 4.2.5 SRTP (Secure Real-time Transport Protocol) 5 SRTP (Secure RTP) 5.1 Hlavní rysy SRTP . . . . 5.2 Bezpečnostní rysy SRTP 5.3 SRTP paket . . . . . . . 5.4 SRTCP paket . . . . . . 5.5 Autentizace zpráv . . . . 5.6 Šifrování . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . .

5.7

5.8

Výměna klíčů . . . . . . 5.7.1 MIKEY . . . . . 5.7.2 ZRTP . . . . . . 5.7.3 SDP . . . . . . . Podpora a implementace

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

6 Asterisk 6.1 Požadavky . . . . . . . . . . . . . . 6.2 Rozšiřitelnost . . . . . . . . . . . . 6.2.1 Zapel . . . . . . . . . . . . . 6.2.2 Non-Zapel . . . . . . . . . . 6.2.3 Paketové sítě . . . . . . . . 6.3 Zvukové kodeky . . . . . . . . . . . 6.4 Instalace . . . . . . . . . . . . . . . 6.4.1 Potřebné komponenty . . . 6.4.2 Knihovna libSRTP . . . . . 6.4.3 Minisip libraries . . . . . . . 6.4.4 Instalace vlastní ústředny . 6.5 Konfigurace Asterisk PBX . . . . . 6.5.1 Globální nastavení SIP . . . 6.5.2 Statická deklarace uživatelů 6.5.3 Nastavení volacího plánu . . 6.6 Rtp.conf . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . .

. . . . .

32 33 33 33 34

. . . . . . . . . . . . . . . .

35 36 36 36 37 37 37 38 38 39 40 40 41 42 42 43 44

7 Softwarový telefonní klient 45 7.1 Konfigurace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8 Realizace spojení

47

9 Wireshak 9.1 Zachycení komunikace . . . 9.2 Analýza zachycených dat . . 9.2.1 Pakety SIP . . . . . 9.2.2 Pakety RTP a SRTP 9.3 Dekódování komunikace . .

49 49 50 51 52 53

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

10 Závěr

57

Literatura

58

Seznam příloh

60

SEZNAM OBRÁZKŮ 2.1 3.1 3.2 3.3 3.4 3.5 3.6 5.1 5.2 5.3 5.4 7.1 7.2 7.3 8.1 8.2 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 A.1 A.2 A.3 A.4 A.5

Přenos hlasu v technologii VoIP. . . . . . . . . . . . . Schéma spojení dvou UA . . . . . . . . . . . . . . . . Komunikace přes proxy . . . . . . . . . . . . . . . . . Příklad komunikace mezi dvěma UA . . . . . . . . . Příklad spojení přes proxy . . . . . . . . . . . . . . . Registrace SIP uživatele . . . . . . . . . . . . . . . . Hlavička RTP . . . . . . . . . . . . . . . . . . . . . . Uspořádání SRTP paketu. . . . . . . . . . . . . . . . Uspořádání SRTCP paketu. . . . . . . . . . . . . . . Princip výpočtu autentifikační hlavičky. . . . . . . . . Atributy SDP zprávy. . . . . . . . . . . . . . . . . . . Zadání adresy registrar serveru. . . . . . . . . . . . . Zadání údajů o uživateli. . . . . . . . . . . . . . . . . Výběr zvukového kodeku. . . . . . . . . . . . . . . . Schéma zapojení pro RTP komunikaci. . . . . . . . . Schéma zapojení pro SRTP komunikaci. . . . . . . . Zachycený SRTP paket. . . . . . . . . . . . . . . . . Komunikace RTP náhraná na straně klienta. . . . . . Zrekonstruovaná síťová RTP komunikace. . . . . . . . Komunikace SRTP náhraná na straně klienta Tomáš. Zrekonstruovaná síťová SRTP komunikace. . . . . . . Komunikace SRTP náhraná na straně klienta Petr. . Výřez SRTP komunikace na straně klienta. . . . . . . Výřez zrekonstruované SRTP komunikace. . . . . . . Uspořádání SRTP paketu. . . . . . . . . . . . . . . . Přihlášení pomocí ssh klienta. . . . . . . . . . . . . . Zadání adresy registrar serveru. . . . . . . . . . . . . Zadání údajů o uživateli. . . . . . . . . . . . . . . . . Výběr zvukového kodeku. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15 20 20 21 22 23 25 29 30 31 34 45 46 46 47 48 52 54 54 55 55 55 56 56 65 66 68 68 69

ÚVOD Pojmem, se kterým se dnes stále častěji setkáváme je VoIP (Voice over Internet Protocol), česky nazývaný jako internetová telefonie či IP telefonie. Její historie sahá až do roku 1973, ale mnohem většího rozmachu se dočkala až v posledních letech. Příčinou je dnes již běžný přístup k širokopásmovému připojení k internetu, či jiným paketově orientovaným sítím. Ty byly původně určeny k přenosu dat, nicméně v dnešní době jsou stále více používány i pro volání, hlasové či videokonference. K tomuto účelu je nutné vužít nové protokoly, aby bylo možné poskytovat co nejširší spektrum služeb. Nejvíce novinek a změn nastalo v oblasti signalizačních protokolů. Jejich prioritním úkolem je sestavování,ukončování a řízení vlastního spojení. U IP telefonie lze, oproti klasickým telefonním sítím, efektivněji využít kapacitu přenosové linky a pro datové i hlasové služby využít pouze jedné přístupové sítě. Z tohoto důvodu, v některých případech, klesnout náklady za hovorné až řádově. V případě využití datových sití pro služby provozované v reálném čase je velmi důležitou vlastností zaručení kvality služeb (QoS – Quality of Service). V opačném případě může dojít k výpadku částí hovoru a nezanedbatelnému zpoždění, což není žádoucí. Signalizační protokoly nejsou schopny QoS zajistit. Toto je úkolem protokolů zajišťujících rezervaci síťových prostředků. V dnešní době se dále VoIP potýká s dalším velkým úskalím, kterým je bezpečnost. Přenášený hovor nemusí nutně obsahovat pouze obyčejnou konverzaci, ale mohou se v něm vyskytovat i citlivé údaje. Zabezpečení takto odesílaných informací začíná být nezbytně nutné. Možností, jak přenášené údaje ochránit, existuje velká řada. Zabývat se však budeme jen těmi významnějšími. Přiblížíme si také problematiku vybraných protokolů užívaných v IP telefonii. Vlastní hovor lze realizovat několika způsoby. Jedním z nich je i využití softwarové ústředny Asterisk, pomocí které bude provedeno spojení mezi dvěma účastníky.

11

1 1.1

VOIP OBECNĚ Historie

Asi největší převrat v mezilidské komunikaci nastal v roce 1875, když Alexander Graham Bell vynalezl telefon. Zrealizoval tak svou myšlenku, že dvě osoby spolu mohou hovořit na velké vzdálenosti pomoci nějakého zařízení. Po jeho brzkém zdokonalení byli lidé schopni předávat si vzájemně informace v dosud nezvykle krátkém čase. První hovor přes americký kontinent se podařilo uskutečnit 25. ledna 1915. K tomu bylo zapotřebí vybudovat pevnou telefonní sít, pomocí které by bylo možné tento hovor přenést a zároveň bylo nutné dále zdokonalit telefonní přístroj. Pevné telefonní sítě se ovšem, vzhledem k finančním nárokům, rozšiřovaly jen pomalu. Do každého místa, kde mělo být umožněno připojení, bylo nutné zavést kabelové vedení. To se sbíhá do pobočkové ústředny, propojené s meziměstskou telefonní ústřednou. Nejvýše stojí mezinárodní ústředna, která zajišťuje mezinárodní hovory. Obdobnou myšlenkou se v roce 1973 začala zabývat DRAPA (Defense Advanced Research Projects Agency). Byl to způsob, jak hlas přenést hlasovou komunikaci přes experimentálně spuštěnou paketově spínanou datovou sít APRANET. Tuto myšlenku nebylo ale možné v tuto dobu nijak masivně zavádět do praxe z důvodu velmi malého pokrytí a pomalých přenosových rychlostí. Původně tedy bylo využití spíše opačné. Data byla, pomocí modemů, přenášena v sítích, určených primárně pro přenos hlasu. Myšlenka VoIP se začala doopravdy rozvíjet až v roce 1995, kdy společnost Vocaltec přišla s prvním čistě softwarovým telefonem. Nadšenci si v zápětí začali uvědomovat vysokého potenciálu přenosu hlasu pomocí Internetu, oproti klasickým telefonním linkám. Hlavní myšlenka tohoto konceptu umožnila uživatelům zásadně snížit vysoké poplatky za hovory přes telefonní síť, které byly velice závislé na vzdálenosti mezi koncovými účastníky. Nebylo tehdy ještě možné volat pomocí VoIP za použití klasického telefonního přístroje, jako je tomu dnes. Hovory bylo možné realizovat pouze mezi počítači se zvukovou kartou, mikrofonem a stejným softwarovým klientem, což v začátcích spojení značně komplikovalo. Také kvalita přenášeného zvuku ani spolehlivost sítě nebyla zrovna vynikající.

12

V příštích letech se však začala vyvíjet nevídanou rychlostí. Důvodem bylo postupné rozšiřování širokopásmových sítí, s nižším zpožděním přenášených dat včetně hlasu. V roce 1998 se její vývoj dostal na takovou úroveň, kdy malé společnosti začali od klasického telefonního přístroje přecházet na VoIP. Telefon k IP telefonii na sebe nenechal dlouho čekat, ačkoliv v počátcích byl ještě k sestavení spojení nutný počítač. Stejně jako mnoho internetových aplikací na konci devadesátých let, tak i VoIP služby vsázely spíše na sponzorské dary k pokrytí nákladů, než na vlastní výdělky, kdy společnosti začínající s poskytováním služby VoIP nabízely volání do určitých oblastí zdarma. Příčinou byly především technické komplikace. Průlom nastal v okamžiku, kdy výrobci hardwaru jako Cisco Systems nebo Nortel začali vyrábět zařízení určená k VoIP komunikaci, jako například IP telefony nebo výchozí brány. Provozování této služby se tím stalo nezávislé na počítačích. Hardware pro VoIP se začal stávat mnohem dostupnější. Atraktivní se služba stává i pro středně velké společnosti, které potřebují komunikovat mezi svými značně vzdálenými pobočkami.V období přechodu firem na technologii VoIP, se začala tato služba dostávat také do domácností.

1.2

Současnost

Největší rozšíření VoIP probíhá od roku 2000. Období posledních několika let lze v oblasti komunikačních technologií charakterizovat jako masový nástup hlasových služeb do prostředí sítí založených na protokolu IP, a to jak v oblasti podnikových sítí, tak i v oblasti veřejných telefonních služeb. Bylo změněno několik standardů využívaných pro přenos paketů a jejich přepínání při průchodu sítěmi. „Vzniká také velké množství nových operátorů, ať už se jedná o velké a zavedené telekomunikační společnosti, které svou šíři služeb rozšiřují o VoIP nebo o společnosti lokálního významu které nabízejí připojení k síti Internet a hlasovou službu vidí spíše jako doplňkovouÿ [1]. IP telefonie je často preferována před klasickou telefonní sítí. Významným důvodem zavádění této technologie je beze sporu nižší cena za hovorné (místy až řádově) spolu s nízkou cenou hardwaru potřebného k telefonování. Dalším podpůrným faktorem rozvoje VoIP je rychlý růst kvality a rychlosti připojení k Internetu za relativně příznivé ceny. Přispívá k tomu i konkurenční prostředí na poli přístupu k Internetu.Během několika let se tato technologie stala oblíbenou alternativou klasické telefonní službě.

13

1.3

Budoucnost

Dynamický vývoj širokopásmového přístupu k Internetu způsobil, že skutečná IP telefonie již brzy bude zcela běžná i v našich domácnostech. Posun v tomto směru slibují někteří operátoři. Dnes ale této služby využívají především střední a malé podniky. I přes značné náklady na budování moderních sítí, které se mohou zdát zbytečně vysoké, jejich návratnost je velmi rychlá v důsledku nízkých provozních nákladů. Již nyní jsou za příznivé ceny v prodeji bezdrátové IP telefony s podporou SIP protokolu. Se svým okolím komunikují pomocí bezdrátové technologie jako například Wi-Fi, Bluetooth, WiMax apod. Podle dosavadních plánů si takovýto přístroj bude umět v dané lokalitě sám zvolit cenově nejméně nákladný způsob volání. Právě tuto a obdobné představy mají na mysli analytici ve vyspělých zemích, když očekávají obrovský nástup internetové telefonie. Postupem času předpokládají, její dominantní postavení na trhu a odsunutí pevných linek i GSM telefonie do ústraní. V blízké budoucnosti je možné očekávat nástup přístrojů podporujících také zabezpečení protokolem SRTP.

14

2

PRINCIP VOIP

Tato technologie je založena přenosu digitalizovaného obecného zvukového signálu, získaného nejčastěji mikrofonem, přes počítačovou či jinou síť prostupnou pro IP protokol. Před odesláním jsou data zpracována zvukovým kodekem a poté rozdělena na pakety. Odesílána jsou spolu s ostatní komunikací, vystupující z počítače. Po průchodu sítí je signál zpětně dekódován a převeden do původního analogového tvaru, který je možné reprodukovat, jak je naznačeno na obrázku 2.1.

Obr. 2.1: Přenos hlasu v technologii VoIP.

Výhodou přenosu takto digitálně zpracovaných dat je bezesporu možnost mnohonásobného kopírování dat bez ztráty kvality. Ke kopírování neboli regeneraci signálu dochází na každém prvku sítě. Stejný proces probíhal i ústřednách, které pracovaly s analogovým signálem. Ten však vždy obsahuje malé procento šumu, které se s každou regenerací signálu stále zvyšovalo a mohlo dojít úplnému znehodnocení vlastní informace. Zvukový signál je nejprve rozložen na jednotlivé části a postupně zapouzdřován protokoly RTP, UDP a IP, aby bylo možné jej doručit přes síť a na straně příjemce správně rozpoznat a zpracovat. Ke snížení množství přenášených dat, oproti bitové podobě jejich digitalizovaného signálu, se používají kodeky (např. G.726, G.729, . . . ), které dokáží snížit objem přenášených dat se zanedbatelnou ztrátou kvality původního signálu. Umožní se tím komunikace v sítích s nižší propustností.

15

3

PROTOKOLY

3.1

Session Initiation Protocol

Session Initiation Protocol (SIP) je jedním z několika otevřených signalizačních prokolů. Původně vyvíjený skupinou MMUSIC (Multiparty MUltimedia SessIon Control), pracující od roku 1999 pod názvem SIP. Poskytuje služby potřebné k sestavení spojení v rámci IP sítě. K přenosu může použít jak TCP i UDP, nejčastěji je však komunikuje přes UDP standardně na portu 5060. Patří do rodiny signalizačních protokolů, ve které vyniká svou flexibilitou a jednoduchostí. Je totiž založen na textové na bázi, obdobně jako HTTP nebo SMTP. Díky tomu je velice rychle pochopitelný a transparentí. Při zjišťování a odstraňování chyb v komunikaci nebo špatné konfíguraci zařízení není třeba žádného speciálního analyzátoru provzu. Pro kódování zpráv se nejčastěji využívá znaková sada UTF-8. Mezi jeho základní funkce patří sestavení, modifikace nebo ukončování spojení mezi koncovými účasníky. Lze pomocí něho také zjišťovat dostupnost jednotlivých účastníků. Nejčastěji je využíván pro telefonní spojení, ale lze ho využít i pro přenos videa, dat nebo textových zpráv.

3.1.1

Služby

poskytované služby • realizace spojení

–

sestavení spojení s konkrétními parametry

• umístění uživatele –

určení cesty ke vyzdálenému systému

• stav uživatele

informace o dostupnosti koncového účastníka

–

nepodporované služby • nezajišťuje služby kvalitu (QoS) na ceste od volaného k volajícímu. To mají na starost rezervační protokoly, jakým se nepříklad RSVP. Ty dokáží upřednostňovat určité typy provozu a rezervovat potřebné síťové prostředky. SIP je s těmito protokoly ale schopen spolupracovat, tím je možné docílit co nejkvalitnějšího spojení. • přenáší signály, které jsou nutné k realizaci spojení a zajištění ostatních okrajových služeb. Tyto signály jsou krátké a stručné. Je proto možné pomocí něho zasílat krátké textové zprávy, ale není určen k zasílání velkého množství dat, jako je třeba HTTP.

16

3.1.2

Architektura

Základními prvky architektury jsou servery a tzv. User agents (UA). UA je možné rozdělit na User agents clients (UAC) a User agents servers (UAS). Hlavním úkolem UAC je vysílat požadavky typu REQUEST. Ty jsou zpracovávány v UAS a zpět k UAC je odeslána odpověď. Protože většína zařízení pracuje jako UAC a UAS zároveň, nebudeme tuto skupinu dělit a budeme pro ní dále užívat označení UA. Druhým důležitým prvkem v SIP architektuře jsou servery. Zle je rozčlenit do tří hlavních skupin:

• Proxy server

–

přijímá požadavky na vytvoření nového spojení od okolních proxy serverů nebo UA a předává je ostaním proxy serverům, pokud volaného účastníka nemá ve své doméně.

• Redirect server

–

má obdobnou funkci jako proxy server s tím rozdílem, že požadavky neposílá dál, ale zpět volajícímu odešle infonformaci, kam má svou žádost zaslat, aby bylo možné ji doručit volanému. Je ale na volajícím, zdali se touto zprávou bude řídít.

• Registrar server –

tento server příjímá žádosti s registrací od UA. Pomocí nich aktualizuje databázi koncových zařízení, která jsou připojena. Tato registrace probíhá v rámci domény.

Ačkoliv lze tyto servery takto rozdělit, v praxi bývají zastoupeny jedinou aplikací bežící na jednom serveru, která všechny jejich služby zajišťuje. Zle zde pozorovat jistou analogii s Gatekeeperem, kterého se využívá při komunikaci pomocí protokolu H.323.

17

3.1.3

Komunikace v SIP

Jak již bylo naznačeno, SIP zprávy jsou textového charakteru. Proto je snadné takovýto provoz sledovat bez nutnosti analyzátoru. Skládají se především z požadavku a hlavičky. Požadavek bývá také označován jako metoda. Pro komunikaci se užívá návěští REQUEST: a udání vlastního požadavku. Mezi nejvýznamnější patří: • INVITE

– žádost o spojení nebo změnu parametrů existující relace

• ACK

– odešle potvrzení o zahájení relace

• BYE

–

• REGISTER

– žádost o registraci účastníka na Registrar serveru

• CANCEL

– přerušení zahajovaní relace ještě před jejím navázáním

• OPTION

– zjišťuje funkce podporované druhým UA

žádost o ukončení relace

Způsob značení odpovědí SIP převzal od protokolu HTTP. Jde o takzvané „stovkové značeníÿ. Hlášení jsou dělena do skupin, kdy 100 až 399 jsou informace o komunikaci. Čísla 400 až 699 signalizují chybu. Její závažnost je přímo úměrná s velikostí čísla. Pří námi uskutečněném hovoru byly užity signály 180 (Ringing) a 200 (OK). Odpovědi se uvádejí s návestím „STATUSÿ: a číslem odpovědi. Podrobnější dělení odpovědí: • 1xx

–

průběh – značí právě probíhající stav

• 2xx

–

úspěch – operace byla úspěšně dokončena

• 3xx

–

přesměrování – požadavek je třeba zaslat jinam

• 4xx

–

chyba klienta – značí chybně zadaný požadavek klientem

• 5xx

–

chyba serveru – označení chyby, která vzníkla na straně serveru

• 6xx

–

globální selhání – žádost nemůže být provedena

Příkladem může být chybové hlášení 404 z protokolu HTTP, čímž informuje o nenalezení požadované stránky. U protokolu SIP značí nenalezení požadovaného koncového účastníka.

18

3.1.4

Obsah hlavičky

Halvička SIP paketu obsahuje důležité informace pro jeho průchod sítí. Obsahuje například adresu odesílatele, příjemce nebo pořadové číslo probíhajícího hovoru. • Call-ID

–

identické číslo hovoru, generované klientem

• Contact –

zde je uložena SIP adresa, pomocí které je možno kontaktovat druhou stranu bez nutnosti kontaktovat redirect server.

• CSeq

–

pořadové číslo žádosti v rámci jednoho hovoru. Při opakování žádosti je číslo stejné. Číslo se zvyšuje po zaslaní každého požadavku INVITE.

• From

–

obsahuje adresu odesílatele

• To

–

obsahuje adresu příjemce

• Via

–

do této hlavičky každý proxy server vkládá svou adresu. Při odesílání opačným směrem ji odebírá a zároveň kontroluje, zdali adresa, na kterou odesílá, není v této hlavičce obsažena. Zabraňuje se tím vzniku smyček.

3.1.5

Adresy

Standardní adresy užívané SIP protokolem velice připomínají emailovou adresu. Liší se prakticky jen návěštím „sipÿ, jak naznačují následující příklady:

• sip: Tomáš domain • sip: 12345 domain • sip: 12345192.168.0.100 • sip: Tomáš192.168.0.100

19

3.1.6

Způsoby spojení

• přímé spojení Na obrázku 3.1 je schématicky znázorněno toto spojení. V tomto konkrétním případě jde komunikaci IP telefonu s PC.

Obr. 3.1: Schéma spojení dvou UA

• spojení pomocí serveru Obrázek 3.2 demonstruje zapojení při komunikaci dvou UA přes dva servery. Z důvodu názornější demonstrace spojeni a nejvyšší četnosti toho typu spojení byly vybrány servery typu proxy.

Obr. 3.2: Komunikace přes proxy

20

3.1.7

Signalizace

Samotné spojení může probíhat několika způsoby. Posloupnost vysílaných signálů bude znázorněna na dvo demonstračních spojeních. První znázorňuje přímou komunikaci mezi dvěma klienty. V druhém případě jde o komunikaci dvou uživatelů přes proxy servery.

Obr. 3.3: Příklad komunikace mezi dvěma UA

První příklad znázorňuje přímé spojení dvou uživatelů. Tomáš nejprve odešle požadavek na spojení: „REQUEST: INVITEÿ. Na druhé straně začne vyzvánění. O této skutečnosti informuje druhou stranu. Po přijetí hovoru volající zprávou ACK potvrdí souhlas s vytvořením komunikačního toku nesousí vlastní hovor. Ukončení hovoru se provádí signálem BYE libovolným účastníkem. Protější strana přijetí tohoto signálu potvrzuje.

21

Obr. 3.4: Příklad spojení přes proxy

V druhém typu komunikace není požadavek odeslán přímo cílovému uživateli, ale serveru, u kterého je volající registrován. Ten pomocí lokalizační služby zjistí, kam má požadavek odeslat a zároveň do hlavičky „Viaÿ zadá svou adresu. O odeslání informuje volajícího. Požadavek nyní přijal druhý proxy server, který požadavek o spojení předá volajícímu, protože ho vyhledal v doméně spadající pod jeho správu. Zprávám jdoucím od volaného k volajícímu jsou na serverech, odebírány jejich adresy z hlavičky „Viaÿ. Sestavení, průběh i ukončení spojení je velice obdobný jako v prvním případě.

22

3.1.8

Registrace uživatele

Nejprve je nutné, aby měl klient přiřazenu svou adresu. Tu je možno zadat ručně (statická) nebo jí získá z DNS serveru. (dynamická). Aby bylo možné klienta vyhledat lokalizační službou, musí zaznamenán na některém registrar serveru. Registrace se provádí žádostí „REQUEST: REGISTERÿ na registrar server. Ten následně provede aktualizaci údajů na location serveru. Tuto databázi využívají proxy a redirect servery. Komunikace mezi location, registra a proxy serverem není nijak specifikována. I způsob realizace služby location je závislý spíše na konkrétní implementaci serveru. Doba, po kterou má být údaj v databázi uchován, je uvedena v hlavičce Expires. Zrušení registrace může provést i klient zadáním požadavku „REQUEST: REGISTERÿ s nulovou položkou Expires.

Obr. 3.5: Registrace SIP uživatele

23

3.2

RTP (Real-time Transport Protocol)

RTP (Real-time Transport Protocol) je nejvýznamnějším protokolem, definující formát paktů pro přenos dat real-time charakteru, jako je interaktivní zvuk a video za pomocí Internetu nebo datových sítí obecně. Původně byl vyvinut pro přenos zvuku a videa pouze v pracovních skupinách. Poprvé byl jako standard RFC 1889 zveřejněn v roce 1996, ale důsledkem dynamického vývoje síti začal rychle zastarávat a v roce 2003 byla vydána jeho nová verze pod označením RFC 3550. Původně byl navržen jako multicastový protokol, ale začal být hojně využíván v mnoha unicastových aplikacích. Nyní je hojně využíván i při spojení dvou účastníků. Z důvodu snadného sestavení signálu v koncovém zařízení jsou jednotlivé pakety číslovány. Je tím také umožněna detekce ztracených paketů. RTP paket dále obsahuje časovou známku (timestamp), která informuje o době vzniku. Ta umožnňuje snadnější bufferování na straně klienta a výpočet kolísání zpoždění na síti. Protože v jednom RTP přenosu může být přenášeno více samostat-ných proudů (streamů), připojuje se informaci o konkrétním proudu (streamu). RTP pro řenos nemá pevně definované porty pro komunikaci přes TCP ani UDP protokol. Obecně je doporučeno používat rozsah 16384–32767. Komunikace s takto dynamicky přidělovanými porty se však setkáva s problémy při průchodu přes firewall či NAT. Tento problém se dnes často řeší za pomocí STUN (Simple Traversal of UDP through NATs) serveru, který často bývá umístěn na stejném stroji, jako ústředna Asterisk. STUN je síťovým protokolem, který umožňuje klientovi zjistit typ NAT, jeho veřejnou adresu a číslo portu, který byl použit pro komunikaci klienta a STUN serveru. Server tyto údaje následně zašle klientovi, trerý po takto otevřené cestě je již schopen odesílat data. Přenos realizovaný pomocí RTP protokolu je citlivý na ztrátu paketů v sití, velikost zpoždění a jeho kolísání. Tuto ztátu lze částečně eliminovat snížením datového toku. To však ale není optimální řešení. Používá se tedy proto některý z rodiny rezervačních protokolů, mezi které patří i RSVP, který standardně ke své komunikaci užívá číslo portu o jedna výšší, než probíha komunikace RTP. Jeho hlavním úkolem je vyjedat se všemi prvky nacházejícími se na trase spojení rezervaci jejich prostředků. Pokud nějaký prvek tuto službu nepodporuje, je protokol „protunelovánÿ. Vhodné užití RTP tedy nastávává případě, kdy jsou data přenášená sití, se zajitěním kvalita služeb (QoS).

24

3.2.1

Hlavička RTP

• Identifikátor obsahu (Payload type) – udává typ přenášených dat • Pořadové číslo (Sequence number) – číslo daného paketu • Časové razítko (Timestamp) – využívá se pro synchronizaci a kolísání zpoždění • Identifikátor zdrojového streamu (Source identifier) - určuje zdrojový tok zat

Obr. 3.6: Hlavička RTP Aby bylo možné rozeznat typ přenášených dat, je součástí RTP hlavičky také payload type. Lze pomocí něho jednoznačně zjistit, jakým kodekem mají být data zpracovávána. Příklady některých zvukových kodeků a jejich identická čísla jsou naznačeny v 3.1 [4]

Identifikátor obsahu

Standard

0 3 4 5 6 7 8 9 10 11 12

PCMU GSM G723 DVI4 DVI4 LPC PCMA G722 L16 L16 QCELP

Vzorkovací Počet kanálů frekvence[Hz] 8000 8000 8000 8000 16000 8000 8000 8000 44100 44100 8000

1 1 1 1 2 1 1 1 1 2 1

Tab. 3.1: Typy kodeků s jejich identifikátorem.

25

4

ZABEZPEČENÍ VOIP

4.1

Důvody zabezpečení

Se stále se zvyšující popularitou internetové telefonie zároveň vzrůstá i nutnost jejího zabezpečení. Hovor nemusí být jen běžná konverzace dvou či více lidí. Může také obsahovat i řadu citlivých údajů, jako například údaje o platebních kartách, hesla k různým objektům, schránkám, interní údaje společností apod. Data jsou totiž přenášena bez jakéhokoliv zabezpečení, což je značné riziko! Pro útočníka není nijak obtížné pakety putující sítí zachytit a následně rekonstruovat. Znemožnění odchycení komunikace je v praxi dosti nákladné a velmi obtížně realizovatelné. Nebudeme se proto tímto způsobem dále zabývat. Druhou možností zabezpečení je zakódování přenášených dat tak, aby nemohla být útočníkem dekódována a následně zneužita.

4.2 4.2.1

Způsoby zabezpečení Zfone

Tento způsob pro zabezpečení telefonie je poměrně nový. Zfone není VoIP klientem, ale softwarem šifrujícím komunikaci odesílanou generovanou téměř všemi klienty. Mezi výjimky patří například velice oblíbený Skype, který užívá vlastní uzavřený protokol. Mezi jeho výhody patří snadná obsluha a dobrá ochrana proti různým typům útoků, jakými jsou například „man in the middleÿ, „hijackingÿ nebo „spoofingÿ. K jeho používání je nutné, aby byl spuštěn u obou volajících stran. Což je značnou nevýhodou spolu s nemožností jeho užití v mobilních zařízeních a ústřednách.

4.2.2

Zabudované šifrování

Týká se především softwarových klientů. Mezi dnes nejvýznamnější software s implementovaným šifrováním patří již výše zmiňovaný Skype. Koncový uživatel se v tomto případě již o zabezpečení hovoru či jiných doplňkových služeb starat nemusí. Otázkou však zůstává míra bezpečnosti tohoto uzavřeného protokolu. Na rozdíl od Zfone je dnes již k dostání řada mobilních zařízení, která jsou pro Skype určena. Stále je jeho použitelnost omezena na volání typu „peer-to-peerÿ nebo konferenční hovory, kdy každý uživatel musí k jejich realizaci užívat tento konkrétní software.

26

4.2.3

Užití TLS a IPsec

Transport Layer Security a IP security jsou dnes nejužívanějšími metodami, jak zabezpečit data zasílaná mezi dvěma aplikacemi. Setkat se s nimi můžeme například v internetovém bankovnictví nebo při přihlašování do vzdálených systémů. Každý z těchto způsobů je založena na jiném principu. Zatím co IPsec vytváří mezi dvojicí zařízení jakýsi zabezpečený kanál, po kterém mohou libovolné aplikace komunikovat, TLS kóduje data jednotlivých programů, které jsou následně posílány přes síť. Obdobný princip můžeme pozorovat i u jeho předchůdce, kterým je SSL. Takto vytvořená spojení jsou značně odolná proti odposlechu a obecně proti jakékoliv externí manipulaci s daty. Z hlediska IP telefonie zde však u IPsec nastává omezení z důvodu závislosti na typu sítě a spolu TLS není příliš vhodný pro přenos v reálném čase.

4.2.4

VPN

Jedná se o pomyslný tunel vedoucí reálnou sítí, který umožňuje spojení dvou vzdálených lokalit. Data přenášená tímto kanálem jsou pro útočníka velice obtížně dešifrovatelná. Tento způsob je vhodný pro velké podniky, kdy je zapotřebí zabezpečené spojení mezi jejich pobočkami. Jednotliví uživatelé mohou navzájem komunikovat jako v síti LAN. Nemusí tedy zabývat problémy vznikajícími při používání Firewallu. Značnou nevýhodou při IP telefonování zde ale i nadále zůstává výskyt nezabezpečených dat na lokální síti.

4.2.5

SRTP (Secure Real-time Transport Protocol)

SRTP poskytuje datovému toku nesenému RTP/RTCP protokoly šifrování, zajišťuje autentizaci paketů a kontrolu jejich integrity. Jeho implementace je zvláště vhodná pro přenos dat v reálném čase z důvodu jeho malému vlivu na kvalitu přenášených dat z pohledu zpoždění a jeho kolísání a také nezávislost na typu použité sítě. Implementace je vhodná také u mobilních zařízení z důvodu nížké výpočetní náročnosti. Zdá se být nejvhodnějším způsobem ochrany dat přenášených v reálném čase, tedy i pro VoIP. Budeme se tedy dále zabývat právě jím.

27

5

SRTP (SECURE RTP)

Z důvodu absence jakékoliv ochrany proti útoku na data přenášená v reálném čase protkolem RTP byl vyvinut SRTP. Definuje formát přenášených dat, zajišťuje kódování vlastních zpráv, kterým poskytuje integritu a důvěryhodnost. Mimo zabezpečení samotného RTP, poskytuje ochranu také kontrolnímu protokolu RTCP. Jeho zprávy jsou přenášeny odděleně přes různé porty. Proto je potřeba chránit oba protokoly během daného spojení. Od jeho zveřejnění v roce 2004 je považován za jeden ze standardních mechanismů pro ochranu dat přenášených v reálném čase v multimediálních aplikacích. Havním důvodem je malý přírůstek objemu dat potřebného k zašifrování komunikace a také velmi malý vliv na QoS. Jeho užití je vhodné při IP telefonii s užitím kodeku s nízkým výstupním datovým tokem nebo pro přenos videa. Implementací SRTP velice ztížíme útoky, jako je snifování, nahrazení paketů nebo DoS (Denial of Service), na realizovanou komunikaci. SRTP chrání data na úrovni aplikační vrstvy, na které sám pracuje. Proto je nezávislý na transportní i síťové vrstvě, které nebývají nijak nezabezpečeny. Ochranné mechanismy společně s algoritmy pro výměnu klíču jsou implementovány na úrovni aplikační vrsty, což je činí nezávislé na užitém operačním systému.[6]

5.1

Hlavní rysy SRTP

• Možnost použití různých k výměně klíčů šifrujících komunikaci • Minimální vliv na QoS • Zabezpečení integrity obsahu RTP/RTCP paketů • Nízká výpočetní náročnost • Nezávislost na typu síťové vrstvy • Nízký přírůstek objemu šifrovaných dat Poslední tři zmiňované vlastnosti dovolují implementaci na mobilní zařízení s omezenou pamětí a výpočetním výkonem. Při použití některého algoritmu pro předávání klíčů společně s SRTP pro ochranu přenášených dat, dostaneme potřebnou úroveň zabezpečení internetové multimediální aplikace, jakými mohou být například hlasové či video-konference.

28

5.2

Bezpečnostní rysy SRTP

• Šifrování síťové komunikace (ochrana proti sniffování1 ) • Authentifikace odesílatele (ochrana proti krádeži identity) • Kontrola integrity dat(ochrana proti modifikaci a manipulaci s daty) • Ochrana proti opakování (neautorizovanému přístupu ke koncovému účastníkovi)2

5.3

SRTP paket

Uspořádání SRTP paktu je velice obdobné, jako u RTP. Hlavička RTP, jež je zapouzdřována protokolem SRTP z důvodu kontroly její neporušenosti na straně příjemce, zůstává po celou dobu neměnná.

Obr. 5.1: Uspořádání SRTP paketu. Protokol SRTP zajišťuje šifrování nesených dat a může dojít k přidání dvou volitelných položek na konec paketu. • MKI (Master Key Identifier) • Autentifikační tag

1

Postup sloužící k zachycení dat, zpravidla patřících jiným uživatlů , odesílaných přes síť. Při tomto typu útoku útočník opakovaně odesílá RTP nebo RTCP data, což může spůsobit DoS. Pouze ochrana integrity prováděná pomocí authentifikace zpráv dokáže ochránit před tímto typem útoku. SRTP touto schopností disponuje. 2

29

MKI Je definován, řízen a používán správou klíčů. Slouží k určení užitého hlavního klíče, ze kterého jsou následně generovány klíče daného spojení, spoužící k autentizaci nebo šifrování přenášených dat. Užití tohoto hlavního klíče je dle specifikace SRTP nepovinné.

5.4

SRTCP paket

Uspořádání SRTCP paketu je obdobné jako u SRTP. Může volitelně nést také dva tagy přidávané na konec paketu. Obsahuje navíc jednobitovou informaci „Eÿ, signalizující přenos šifrovaného obsahu SRTCP a také 31bitový registr pro ukládání pořadového čísla paketu.

Obr. 5.2: Uspořádání SRTCP paketu. Slouží také jako paramtr při dekódování paketu metodou Advanced Encryption Standard-Counter Mode (AES-CM). Tato rozšíření jsou součástí kontroly integrity při výpočtu autentifikačního tagu na straně odesílatele a jeho kontroly na straně příjemce.

5.5

Autentizace zpráv

Autentizace slouží k ověření identity účastníků spojení. Odesílatel a příjemce používají klíče daného spojení pro šifrování, dešifrování a autentizaci zprávy. Pro SRTCP je autentizace zprávy nutná, doporučená pouze pro SRTP. Pro kontrolu integrity je určena jednocestná funkce, Hash-based Message Authentication Code s Secure Hashing Algorithm 1 (HMAC-SHA1), která hlavičku i nesená data zašifruje zabezpečeným klíčem.

30

Pořadové číslo z hlavičky je přidáno do 32bitového SRTP obnovitelného čítače ROC (RollOver Ccounter)3 , který je uložen do šifrovacího kontextu k získání 48bitového pořadového čísla, které je indexem každého jednotlivého SRTP paketu. Index paketu je zašifrován společně s dalšími parametry vygenerovaným klíčem segmentu komunikace. Tento čítač je nulován pouze při začátku spojení. Pokud dojde ke změně klíčů užitých pro šifrování spojení, mění se také obsah tohoto registuru.[7]

Obr. 5.3: Princip výpočtu autentifikační hlavičky. Odesílatel zapíše HMAC-SHA-1 hash do autentizačního tagu a příjemce spustí shodný výpočet, jehož výsledek porovná s přijatým tagem. V případě jejich neshody je paket prohlážen za chybný a dojde k jeho vyřazení z přijaté komunikace. Délka tohoto tagu se může pohybovat mezi čtyřmi a deseti bajty. Autentifikační přípona umístěná na koneci SRTP paketu je užívána k ověřování učastníků spojení, kontrole neporušenosti dat společně se zjišťováním, zda daný pakt nebyl útočníkem zaměněn. Je sice jeho volitelnou součástí, ale ve specifikaci SRTP zároveň také důrazně doporučenou. Toto platí také pro všechy aplikace, které používají zabezpečenou komunikaci. V opačném případě je prováděno pouze šifrování přenášených dat, což je jistou formou ochrany, která je však nedostatečná.

3

Čítač, jehož počáteční hodnota je po dosažení maxima nastavena na počáteční hodnotu

31

5.6

Šifrování

Výchozím algoritmem pro symetrické kódování dat u SRTP je AES (Advanced Encryption Standard), který lze využít ve dvou modech: • AES-CM • f8 Obě možnosti standardně využívají 128 bitovou délku šifrovacího klíče. Liší se pouze užitím v různých typech šití, kdy f8 je vhodný pro bezdrátový přenos. Důvodem snižování důvěryhodnosti hlavního klíče s přibývajícím časem je doporučená jeho změna. Roste tedy podezření, že byl hlavní klíč v některém směru odchycen dešifrován. Z tohoto důvodu je vhodné po určitých intervalech generovat nový klíč. Existuje všat také limit udávající množství paketů, které mohou být zašifrovány stejným hlavním klíčem. Periodický výpočet nových HMAC-SHA1 klíčů je ve specifikaci tohoto algoritmu doporučen, ale není určena ani doporučená doba platnosti klíčů. Nicméně pokud se hodnota pořadového čítače SRTCP překlopí na nulu, nastává příležitist útočníka zaměnit staré pakty. Z tohoto důvodu je životnost hlavního klíče AES-CM 248 SRTP nebo 231 SRTCP paketů. Ke změně klíčů dojde k při dosažení maxima kterékoliv z hodnot. Klíč HMAC-SHA1 je odvozen z hlavního klíče SRTP komunikace.

5.7

Výměna klíčů

SRTP neobsahuje vlastní mechanismus pro vytváření a správu hlavního klíče (Master key). Popisuje pouze způsob, jakým odvozovat z hlavního klíče ostatní, učené pro autentifikaci a šifrování dat komunikace. Z absence tohoto mechanismu vyplývá další výhoda užití SRTP, kterou je možnost volby užitého algoritmu. K výběru se jich nabízí hned několik: • MIKEY (Multimedia Internet KEY) • ZRTP • SDP (Session Description Protocol)

32

5.7.1

MIKEY

MIKEY patří mezi protokoly, vyvinuté pro užití v aplikacích přenášející data v reálném čase, popisující správu a umožňující výměnu klíčů. Je nezávislý na použitém typu protokolu, například SIP nebo H.323. Zabezpečená komunikace tedy může být sestavena mezi dvěma koncovými klienty, z nichž jeden užívá signalizační protokol SIP a druhý H.323. Podporuje také zabezpečení i více paralelně realizovaných spojení, přičemž každé je zabezpečené samostaně.[8]Jednou z možných metod přenosu hlavního klíče komunikace je užití hodnoty „kÿ SDP protokolu.

5.7.2

ZRTP

ZRTP je protokolem zajišťujícím výměnu klíčů během hovoru sestaveného pomocí některého signalizačního protokolu, jako například SIP, H.323, Jingle nebo peerto-peer SIP. Jeho výhodou je bezesporu způsob jeho komunikace. Ta probíhá na stejném portu, jako data RTP/SRTP protokolu. Dochází tedy prokládání techto dvou komunikací. Velkou výhodou je bezproblémový průchod firewalem a také nevyžaduje jakoukoliv podporu ze strany signalizačního protokolu. Slouží ke generování veřejného hesla (shared secret), který je následně použit pro generování hlavního klíče komunikace a „omáčkyÿ (salt), potřebné pro SRTP. Výměna klíču je založena na algoritmu Diffie-Hellmana, chránící komunikaci před útokem MitM(man in the midle). Je podporován pouze malou částí sofwarových klientů, jako například X-Lite, Twinkle nebo nejvýznamnější Zphone. Autorem je Phil Zimmermann, spoluautor projektu ZRTP. U programu Ekiga je implementace plánována ve verzi 3.0.[9] Velkou jeho velkou nevýhodou může být nemožnost implementace při užití protokolu IAX [10]

5.7.3

SDP

Mezi další metody patří SDP (Session Description Protocol), který je protokolem určným k přenosu inicializačních parametrů sestavovaného spojení. Zvláště vhodné je jeho užití v případě, kdy potřebujeme stávající signalizační protokol, jako například SIP, MGCP nebo Megaco rozšířit o zabezpečení.

33

Klíč hlavní komunikace je možné přenášet volitelným parametrem „aÿ, který se skládá ze dvou částí. První „Cryptoÿ nese informaci o typu užité kryptovací a hashovací funkce. Druhý „Inlineÿ jehlavním klíčem komunikace. Příklad výměny techto parametrů je naznačen na obrázku 5.4.

Obr. 5.4: Atributy SDP zprávy. Velkou nevýhodou této metody pro výměnu klíčů je absence možnosti změny klíčů během spojení. Tato vlastnost se také projevila během realizovaného hovoru, kdy nebylo možné datový tok SRTP přesmětovat mimo ústřednu.

5.8

Podpora a implementace

Protokol SRTP je podporován stále větším množstvím softwarových telefonních klientů. K dostání jsou však také hardwarové IP telefony, zabezpečující hovor pomocí tohoto protokolu. Často bývá užíván v kombinaci s dalším, například TLS, určeným k šifrování dat signalizačního protokolu. V opačném případě při použití pouze SRTP, dochází k zašifrování vlastního hovoru, ale velkou slabinou je absence zabepečení signalizačních údajů. Cena těchto zařízení není nijak dramaticky rozdílná od modelů nepodporujících tuto funkci. Díky nízké výpočetní náročnosti je její implementace vhodná také do přenosných zařízení. Na českém trhu se mi v prodeji bohužel nepodařilo nalézt žádný takový výrobek, založený na Wi-Fi či Bluetooth technologi.

34

6

ASTERISK

Asterisk je kompletním softwarovým open-source řešením pobočkové ústředny s podporou řady komunikačních protokolů a velkého množství fyzických zařízení, se kterými je schopen komunikovat. Ať se jedná o přímé připojení fyzických telefonů analogového či digitálního charakteru, tak komunikace s jinými digitálními ústřednami či připojení na klasickou analogovou ústřednu. Poskytuje také široké spektrum služeb, jakými jsou například: • Znemožnění odchycení zpráv • Šifrování dat • Pobočková ústředna (PBX) • Softwarová ústředna • Výchozí brána pro protokoly SIP, IAX2, H.323 a MGCP • Hlasová schránka • Fronta volajících • Interaktivní hlasový průvodce (IVR) • Konferenční server • Fronty volajících • Informace o volajícím Objem služeb, které dokáže zastat je mnohem vyšší. „Neoficiálně jde možná o jedno z „nejsilnějšíchÿ, flexibilních a rozšířitelných řešení v oblasti integrovaného telekomunikačního softwaru.ÿ[15] Mezi jeho další výhody bezesporu patří i jeho cena oproti komerčně nasazovaným systémům. Pokud nevyžadujeme technickou podporu, je tento program volně přístupný při dodržení licence GPL (General Public License). Projekt Asterisk se stává stále více středem pozornosti. Důvodem není jen jeho cena, ale hlavně podpora širokého spektra hardware a komunikačních protokolů společně s velkým množstvím dostupných materiálů, které se této problematice věnují. V některých oblastech je již dnes konkurence schopnou alternativou komerčních systémů.

35

6.1

Požadavky

Asterisk je určen primárně pro Linux. Mezi zástupce patří například RedHat, SuSe, Debian, Fedora, Gentoo a mnoho dalších. Jeho provozování je možné však i na více či méně odlišných platformách typu UNIX, MAC OS X nebo Solaris. Zde však může nastat problém při použití rozšiřujícího hardware, pro který nemusí být dostupné ovladače. Doporučená konfigurace pro volání patnácti účastníku je 3,0GHz CPU a 512MB paměť. Tato konfigurace je volena tak, aby docházelo nejvýše k zanedbatelným zpožděním z důvodu vytížení serveru.

6.2

Rozšiřitelnost

Systém je koncipován takovým způsobem, aby umožňoval připojovat nová zařízení a implementovat nové technologie. Jedním z hlavních cílů toho open-source projektu je podpora co nejširšího spektra současných i přicházejících protokolů a typů hardware. Současná zařízení lze rozdělit do tří hlavních skupin:

• Non-zaptel • Zaptel • Paketové sítě

6.2.1

Zapel

Je označení pro hardware produkovaný společností Zapata Telephony. Mezi jeho hlavní výhody patří podpora pseudo TDM rozhraní. TDM (Time-Division Multiplexing) je technologie užívaná při komunikaci na klasických analogových linkách umožňuje kapacitu linky je sdílet několika hovory. Je však patentována a tudíž zařízení podporující tento standard jsou i značně nákladná. Pseudo rozhraní je jeho obdobou, které disponuje téměř shodnými parametry pro přenos v reálném čase a mnohem vyšší flexibilitou, než klasický TDM hardware. Náklady na jeho pořízení jsou také nepoměrně nižší. Příkladem připojitelných síťových rozhraní mohou být T1, E1, PRI, PSTN, POTS a řada dalších.

36

6.2.2

Non-Zapel

Hardware poskytuje také možnost připojení směrem ke klasickým telefonním sítím, ale bez podpory pseudo DTM. Absence této technologie značně snižuje efektivitu při využití linky. Mezi zástupce tohoto typu rozhraní patří například:

• LTI (Linux Telephony Interface) • ISDN4Linux • ALSA/OSS • Linejack/Phonejack

6.2.3

Paketové sítě

Zatímco předešlé dva způsoby se orientují na možnost připojení ke klasické telefonní síti, bylo také nutné umožnit komunikaci za pomocí maketových sítí (IP a Frame Relay). Patří mezi standardní protokoly využívající tento typ sítí bez užití specializovaného hardware. K realizaci jsou použity protokoly jako například: SIP, H.323, MGCP nebo IAX2. Poslední zmiňovaný je původně navržen autorem Asterisku a užívá se především při komunikaci mezi jednotlivými ústřednami, ale jeho užití je možné i při komunikaci s klientem, pokud tento protokol podporuje.

6.3

Zvukové kodeky

Zvukových kodeků podporovaných Asteriskem je velká řada. Mezi nejčastěji užívané patří: • G.711 a–law • G.711 µ–law • GSM • iLBC (internet Low Bitrate Codec) • G.723.1 • G.726 • G.729 • ADPCM

37

6.4

Instalace

K provedení úspěšné instalace ústředny bude nutná kompilace potřebných knihoven a následné vlastní ústředny. Také bude požito stahování dat z pracovních stromů (subversion). Provádění takovýchto operací vyžaduje přítomnost potřebných kompilačních programů a podpůrných knihoven v systému. Asterisk byl instalován na operační systém Linux/Fedora8 i386. V průběhu instalace systému je sice možné zvolit podpůrné současti pro takovouto práci, jako napříkad: • Vývojové nástroje • Knihovny pro vývoj Ani poté však systém neobsahuje plnou programovou podporu pro kompilaci a instalaci ústředny Asterisk a potřebných knihoven. V opačném případě by se velikost zdrojových dat i potřebného místa pro instalaci celého systému mnohonásobně navýšila a nově nainstalovaný systém by obsahoval celou řadu komponent, které by nemusely být nikdy využity. Pořadí jednotlivých kroků prováděných během instalace není možné měnit. Kompilace jednotlivých knihoven je zpravidla závislá na předchozích krocích.

6.4.1

Potřebné komponenty

Jak již bylo nastíněno výše, prvním nezbytým krokem při instalaci je doplnění operačního systému o konkrétní komponenty, jakými jsou programy, knihovny a některé soubory se drojovými kódy, potřebné k provádění jednotlivých kroků. Pro instalaci těchto komponet je v systémech RedHat/Fedora výhodné užití instalátoru yum, který zároveň řeší závislosti mezi jednotlivými balíčky a vyhledává také knihovny potřebné pro daný program. Z důvodu absence jakéhokoliv zdroje se seznamem všech potřebných komponet, byl tento vypracováván na základě chyb hlášených během překladu jednotlivých součástí, což je metoda značně časově náročná.

Programy: autoconf, automake*, gcc*, glibc-utils, pkgconfig libedit, libtool, pbzip2, pkgconfig, subversion

38

Balíčky pro vývoj: libedit-devel, ncurses-devel, zlib-devel, openssl-devel, pth-devel, openldap-devel, libglademm24-devel Systém dolněný o veškeré tyto nutné součásti je nyní shopen vykonávat operace potřebné při získávání zdorjových souborů a kompilaci knihoven následně využívaných ústřendnou.

6.4.2

Knihovna libSRTP

Další potřebou součástí je knihovna libSRTP, která poskytuje zabezpečení protokolu RTP. Rozšiřuje ho utajení obsahu zprávy, kontrolu správnosti doručených dat a značně ztěžuje rekonstrukci zachycených dat Tato knihovna je je volně ke stažení na adrese: http://srtp.sourceforge.net/download.html Následující postup provede k jejímu rozbalení z archivu a následné kompilaci společně s ověřením správné funkčnosti. tar -xf srtp-1.4.2.tgz cd srtp autoconf && ./configure && make make runtest make install cd .. Tento je zpravidla bezproblémovým z důvodu malé náročnosti na množství potřebných programů externích a externích balíčků.

39

6.4.3

Minisip libraries

Instalace a kompilace knihoven potřebných k sestavení zabezpečeného spojení. • Stažení instalačních souborů z vývojového stromu. mkdir /usr/src/minisip cd /usr/src/ svn co -r3412 svn://svn.minisip.org/minisip/trunk minisip cd minisip • Následná instalace čtyř potřebných knihoven v následujícím pořadí: libmutil, libmnetutil, libmcrypto, libmikey cd lib name $ lib name ./bootstrap $ lib name ./configure --prefix=/usr $ lib name make $ lib name make install

6.4.4

Instalace vlastní ústředny

• Stažení instalačních souborů z vývojového stromu. mkdir /usr/src/asterisk-trunk cd /usr/src/ svn co -r81432 http://svn.digium.com/svn/asterisk/ /trunk asterisk-trunk cd asterisk-trunk • Stažení a aplikace patche pro podporu SRTP. wget http://bugs.digium.com/file download.php? file id=15384&type=bug -O ast srtp r81432 mikey r3412.patch patch -p1 < ast srtp r81432 mikey r3412.patch

40

• Závěr instalace ústředny a šablon konfiguračních souborů. Ve složce s rozbalenými instalačními soubory byl spuštěn skript: ./bootstrap && ./configure && make Ten zajišťuje ověření platformy systému, funkčnost kompilátoru, přítomnost potřebných knihoven a hlavičkových souborů. Následně proběhne generování skriptu pro překlad programu ze zdrojového kódu. Instalace však obsahuje řadu součástí, které v komunikaci pomocí SIPu bez nutnosti využití fyzického hardware nejsou zapotřebí. Provedeme tedy jejich odebrání, aby nedocházelo ke zbytečným chybovým hlášením o nenalezeném hardware. Komponenty určené k instalaci lze volit v textovém menu vyvolaném: make menuselect Odebereme tedy komponenty pbx ael, pbx dundi, res adsi. Úpravu instalačního skriptu a následnou instalaci programu provedeme zadáním příkazu make && make install Nyní je možné tento program spustit a pomocí konzole ho konfigurovat. To je však metoda dosti náročná a značně neefektivní.

6.5

Konfigurace Asterisk PBX

Při nastavování Asterisku je možné využít vzorových konfiguračních souborů, což je zvláště vhodné, pokud tímto open-source řešením spíše seznamujeme. Nyní provedeme Jejich instalaci do adresáře /etc/asterisk: make samples Nejdůležitějšími soubory pro konfiguraci sytému bez přídavného hardware, který k realizaci využívá SIP protokolu: • sip.conf • extension.conf

41

6.5.1

Globální nastavení SIP

Pomocí souboru sip.conf lze nastavit parametry Asterisku při komunikaci protokolem SIP. Obsah souboru je pro přehlednost dělen na několik částí, mezi které patří vlastní nastavení serveru, podporované kodeky nebo statické záznamy jednotlivých uživatelů. Pro názornost bylo vyjmuto několik významných položek: [general] context=default bindport=5060 bindaddr=192.168.1.100 allow=alaw tos sip=cs3 tos audio=ef canreinvite=yes V Sekci general se nastavuje IP adresa a port, na kterém Asterisk komunikuje spolu s jeho jmenným názvem, typem použitého kodeku a parametry pro zajištění kvality služeb QoS. Dále byla provedena statická definice uživatelů.

6.5.2

Statická deklarace uživatelů

[Tomas] type=friend context=default host=dynamic username=tomas callerid=Tomas <100> language=cz [Petr] type=friend context=default host=dynamic username=petr callerid=Petr <200> language=cz

42

Při staticé deklaraci uživatů je nutné zadání položek „typeÿ a „usernameÿ, kdy první položka určuje, o jaký typ spojení se jedná. Jde-li o klienta nebo spojení s jinou pobočkovou ústřednou. Položka „usernameÿ definuje textový řetězec, jehož správné vyplnění závisí na úspěšnosti při registraci uživatele k dané ústředně. Položkou „hostÿ je možné nastavit jednotlivému uživateli konktrétní síťovou adresu, ze které bude úspěšně provedena jeho registrace. Takovéto nastavení může určitým způsobem zvýšit stupeň bezpečnosti. Pokud však takovéto striktní přidělení není vyžadováno, je vhodné nastavit tuto hodnotu této položky na „dynamicÿ, aby bylo možné přihlášení uživatele z libovolné adresy.

6.5.3

Nastavení volacího plánu

Jádrem softwarové ústředny Asterisk je konfigurační soubor extensions.conf, který obsahuje „volací plánÿ. Lze zde určovat pravidla, podle kterých bude zacházeno s příchozími i odchozími hovory. Možnosti nastavení pomocí tohoto volacího plánu jsou značně obsáhlé a na první pohled se mohou zdát dosti komplikované. Na druhé straně realizaci zkušebního hovoru mezi dvěma klienty postačuje opravdu jen málo, jak naznačuje výpis z extension.conf: [default] exten ⇒ 100,1,Set( SIP SRTP SDES=1) exten ⇒ 100,n,Set( SIPSRTP=otional) exten ⇒ 100,n,Set( SIPSRTP CRYPTO=enable) exten ⇒ 100,n,Dial(SIP/Tomas) exten exten exten exten

⇒ ⇒ ⇒ ⇒

200,1,Set( SIP SRTP SDES=1) 200,n,Set( SIPSRTP=optional) 200,n,Set( SIPSRTP CRYPTO=enable) 200,n,Dial(SIP/Petr)

Obsah tohoto konfiguračního souboru je dělen do jednotlivých sekcí, jako například „generalÿ nebo „globalsÿ. Jména těchto proměných mohou být měněna pouze systémovým administrátorem. Speciální sekcí tohoto souboru mohou být makra. Bývají uváděna s návěštím „macro-ÿ. Vytvářejí se z obdobného důvodu, jako v programovacích jazycích a to z důvodu opakovaného použití nejčastěji dané sekvence příkazů.[11]

43

6.6

Rtp.conf

Za jistých podmínek se můžeme setkat se stavem, kdy je možné přihlášení softwarového klienta k ústředně, úspěšně probíhá i vytáčení vzdálené strany, ale při spojení hovoru signalizačním protokolem nedojde k vytvoření RTP kanálu. To může být způsobeno snahou klienta nebo ústředny navázat spojení na portu, který je ve Firewallu zakázán. Jednou možností je povolení tohoto portu. Toto řešení však není příliš vhodné, protože číslo portu nemusí být vždy stejné. Vhodnější je proto vymezení možných portů pro RTP komunikaci a jejich následné povolení ve Firewallu. Změnu rozsahu portů je možné měnit editací položek rtpstart a rtpend umístěných v souboru rtp.conf v konfiguračním adresáři ústředny /etc/asterisk. Příkladem může být: rtpstart=8000 rtpend=8010

;číslo počátečního portu ;číslo koncového portu

44

7

SOFTWAROVÝ TELEFONNÍ KLIENT

Posledním krokem před uskutečněním vlastního hovoru je nutné nastavit klienta pro přihlášení na server. Ze široké skály softwarových klientů je třeba vybírat mezi těmi, kteří podporují SIP protokol a obsahují podporu zabezpečeného tefenování pomocí SRTP. Většina dnešních klientů nepodporuje pouze jeden signalizační protokol, ale i některé další. Příkladem může být H.323, který je také velmi užívaným protokolem. Počet klientů s implementovanou podporou SRTP a zároveň vyhovující podmínce možnosti připojení na volitelný registar server je velice omezený. Jako nejlépe hodící se byl zvolen softwarový klient Phoner lite, který plně vyhovuje výše uvedeným požadavkům. Verze lite obsahuje podporu jednoho signalizačního protokolu, kterým je SIP, což je pro tento účel plně dostačující. Plná verze phoneru obsahuje dále podporu telefonního TAPI a ISDN CAPI rozhraní, systém automatického odpovídání a podporu TTS. [3].

7.1

Konfigurace

Po spuštění klienta z prostředí Windows přejdeme do záložky „Configurationÿ. V podzáložce „Serverÿ je nutné vyplnit položku „Proxy/Registrarÿ, jak znázorňuje obrázek 7.1. Zde zapíšeme síťovou adresu Asterisk serveru, na který se chceme prihlásit.

Obr. 7.1: Zadání adresy registrar serveru. V záložce „Usersÿ obsahuje přihlašovací údaje daného uživatele, které je potřeba vyplnit v závislosti na nastavení SIP konfiguračního souboru ústředny. Položka „User Nameÿ je shodná s názvem hlavičky uživatele, definované v SIP konfiguračním souboru ústředny.

45

Obr. 7.2: Zadání údajů o uživateli. Záložku network není nutné měnit, pokud jsme ponechali standardní port (5060) pro SIP komunikaci. Pro přenos bude využit transportní protokol UDP. V záložce „Codecsÿ provedeme změnu nastavení zvukového kodeku na A–law, jak znázorňuje obrázek 7.3. Jeho algoritmus je otimalizovaný především pro užití v Evpropě. Zatržítko „SRTPÿ určuje, zda-li má být odchozí komunikace zabezbečená či nikoliv.

Obr. 7.3: Výběr zvukového kodeku.

46

8

REALIZACE SPOJENÍ

Po úspěšné instalaci a konfiguraci ústředny i telefonního klienta je nyní možné ověření teoretických poznatků získaných v teoretické části na konkrétním síťovém zapojení. Vlastní zapojení je v obou případech totožné. Odlišnost nastává pouze ve změně trasy dat, která přenásějí vlastní hovor. Tuto trasu lze ovlivnit nastavením položky SIP protokolu. canreinvite yes | no Pokud je zvolena volba „yesÿ, je možná změna trasy i po sestavení spojení. Mezi hlavní výhody této funkce patří snaha o volbu nejvhodnější cesty pro pakety přenášející hovor. Zároveň tím dochází k odklonu dat tekoucích přes síťové rozhraní ústředny a úspoře jejích síťových i výpočetních prostředků. Takovéto spojení demonstruje obrázek 8.1.

Obr. 8.1: Schéma zapojení pro RTP komunikaci.

47

Aktuálně dostupná verze ústředny Asterisk však podporuje volbu „yesÿ pouze při užití RTP protokolu. Přesměrování komunikace zabezpečené SRTP protokolem neproběhne úspěšně, ale skončí varováním, které poukazuje na neprovedení této funkce. Trasa přenášených dat SIP i SRTP protokolu je tedy shodná, jak je naznaceno na obrázku 8.2.

Obr. 8.2: Schéma zapojení pro SRTP komunikaci. Zkušební hovory jak nezabezpečené, tak i s využitím SRTP byly realizovány s vypnutou volbou přesměrování. Částečně se tím sníží velké množství úkonů nutných při realizaci a následném zachytávání dat. Sledování síťové komunice bylo prováděno programem Wireshark spuštěným na obou klientských počítačích společně s náhráváním odesílaného zvuku, který bude použit jako vzor při porovnávání se zvukovou stopou zrekonstruovanou z dat ochycených ze sitě.

48

9

WIRESHAK

Wireshark patří v kategorii volně šiřitelného software při dodržení licence GNU GPL mezi nejlepší analyzátory síťových protokolů. Díky multiplatormnosti, širokému spektru funkcí a bezesporu jeho ceně se stal standardem v mnoha průmyslových odvětvích i školských institucích. Spouží především k odchytávání dat za účelem analýzy, odhalování síťových problémů, vývojí programů a protokolů, ale také při vdělávání. Nejčastějším způsobem užití je zachytávání dat v reálném čase a jejich následné analýze v režimu „offlineÿ[2]. V jeho vývoji, probíhajícím od roku 1998, se daří pokračovat za přispění síťových expertů z celého světa. Tím je umožněna podpora nových rozhraní a protokolů společně se stále přesnější a hlubší analýzou zachycených dat.

9.1

Zachycení komunikace

Před uskutečněním vlastního hovoru je vhodné spustit zachytávání dat, aby bylo možné sledovat kompletní komunikaci včetně SIP zpráv, které obsahují údaje o registrování jednotlivých klientů na ústřednu či průběh sestavování a ukončování spojení. Spuštěním zachytávání předchází volba použitého síťového rozhraní. Vyvolání dialogu se seznamem dostupných adaptérů provedeme vyvoláním položky v menu Capture/Interfaces Stiskem tlačítka „Startÿ spustíme zachytávání komunikace na zvoleném rozhraní. Po uskutečnění hovoru ukončíme odchytývání síťové komunikace příkazem Capture/Stop Zachycená data uložíme do souboru k jejich pozdější analýze. Tento postup byl použit pro běžný i zabezpečený hovor. Je však obecným způsobem pro získání informací o blíže nespecifikovaných spojeních. Při tomto postupu ukládáme veškerá zachycená data, která mohou vzlástě v rozsáhlých síťích nabývat velkých objemů. V takovém případě je vhodné užití filtru zaznamenávaných dat, kterým lze výrazně snížit množství zpracovávaných dat.

49

9.2

Analýza zachycených dat

Zachycená síťová komunikace obsahuje nejen námi uskutečněný hovor, ale také datové toky ostatních běžících aplikací či služeb spuštěných na místním nebo vzdáleném počítači. Jednotlivé pakety je možné rychle třídit podle zdrojové či cílové adresy, typu protokolu, pořadového čísla nebo nejčastěji času. Práce s kompletním objemem informací je značně neefektivní, protože jednotlivé datové toky se prolínají. Sledovaná komunikace se v některých případech doslova zrácí mezi ostatní. Wireshark disponuje účinnými nástroji, pomocí kterých lze účinně zobrazit pouze jeden datový tok nebo jeho část, jež je předmětem bližšího sledování. V našem konkrétním případě pro zobrazení informací, týkajících se hovoru, plně postačí zadání filtrační podmínky SIP || RTP do panelu filter a tlačítkem „Applyÿ provedeme její porvzení. Výběr by měl nyní být natolik omezený, že je snadné pozorovat sled SIP zpráv následových RTP nebo SRTP pakety, jak naznačuje obrázek 3.3. Pokud požadujeme zobrazení především komunikace sugnalizačního protokolu a pakety přenášející vlastní hovor nás zajímají pouze okrajově, nabízí se další elegantní řešní. Volbou položky v paletovém menu Statistics/VoIP calls dojde k vyvolání dialogového okna, obsahující seznam rozpoznaných telefonních spojení, nezávislých na užitém signalizačním protokolu. Zvolením jednoho konkrétního a stiskem tlačítka „Prepare Filterÿ provedeme vložení podmínky do panelu filter. Jejím potvrzením dojde k zobrazení pouze paketů týkajících tohoto hovoru. Množsví paketů nesoucích vlastí hovor je zredukováno pouze na jeden a to pro každý směr. Užití tohoto filtru je vhodné především při sledování hovoru tvajícího delší čas.

50

9.2.1

Pakety SIP

Vlastním inicializátorem pokusu o telefonní spojení, jak je patrné z obrázku 3.3, je první paket signalizačního protokolu, nesoucí požadavek INVITE společně s dalšímí údaji, potřebnými pro úspěšné sestavení spojení. Příkladem muže být identifikace strany žádající o spojení, seznam preferovaných kodeků nebo časový inteval užitý pro segmentaci analogového signálu, jak je patrné z výňatku takovéto zprávy. v=0 o=root 1876685783 1876685783 IN IP4 192.168.1.100 s=session c=IN IP4 192.168.1.100 t=0 0 m=audio 8010 RTP/AVP 8 3 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off a=ptime:20 a=sendrecv Obsah paketu při zabezpečené komunikaci nezůstává beze změny. Volbou šifrovaného hovoru nastává odlišnost v údaji popisující typ datového média změnou z „AVPÿ na „SAVPÿ. Především ale přidáním nového atributu „cryptoÿ, nesoucí údaje o typu použitého šifrování a sekvenci znaků, dále použitou pro autehtifikaci. a=crypto:1 AES CM 128 HMAC SHA1 80 inline:rFaNW2pRbvjrZEtgp9AxbfF4iXdRs7ci9oX0qXGU

51

9.2.2

Pakety RTP a SRTP

Po bližším zkoumání rozdílů mezi pakety RTP a SRTP nalezneme pouze malý rozdíl, který spočívá ve velikosti přenášených dat. To plně koresponduje s filozofií SRTP, založené na myšlence transparentnosti paketů. Běžné zařízení proto ani nepozná rozdíl od RTP komunikace. S touto vlastností se můžeme setkat i při analýze paketů programem Wireshark. Rozpoznání SRTP paktů od RTP komunikace není ani v nejaktuálnější dostupné verzi naprosto spolehlivé. Při použití zabezpečení byl datový tok chybně detekován jako RTP. Hlubším zkoumáním bylo jištěno, že se jedná pouze o nedokonalost programu, jak bude dokázáno dále při dekódování zachycené komunikace. Hlavním, ale na první pohled snadno přehlédnutelným, rozdílem mezi pakety, nesoucími zabezpečený hovor, je rozdílná velikost přenášených dat. V našem případě jde o rodíl 10 Bajtů, který je zapříčiněn přidáním autentifikačního tagu na konec paktu. Struktura SRTP paketu je naznačena na obrázku 9.1

Obr. 9.1: Zachycený SRTP paket.

52

9.3

Dekódování komunikace

Pokud se útočníkovi podaří zachytit nezabezpečenou komunikaci, není pro něj nijak obtížné z ní získat informace, se kterými může naložit podle svého uvážení. Toto neplatí pouze pro přenášný zvukový signál. Pomoci programu Wireshark se podařilo zachytit také nezabezpečený datový tok přenášející video ve formátu mpeg. Jeho zpětnou rekonstrukci by podle krátkého návodu zvládl i uživatel se základními znalostmi v užívání PC. Ke zpětnému sestavení signálu vedou nejméně dvě cesty, které zde budou popsány. První z nich je uživatelsky přívětivější. Umožňuje však pouze přehrání sestaveného proudu dat pomocí „RTP Playeruÿ integrovaném do Wiresharku. Nevhodnou se tato medoda stává zpravidla tedy, pokud je zapotřebí sestavená data uložit do souboru. Již známým postupem vyvoláme dialogové okno se seznamem nalezených hovorů: Statistics/VoIP calls Po zvolením požadovaného hovoru dojde k aktivaci tlačítka „Playerÿ, umožňují spuštění výše uvedeného přehrávače. Stiskem tlačítka „Decodeÿ k pokusu o zpětnou rekonstrukci komunikace. Pomocí intuitivního ovládání je nyní možne přehrání libovolného směru hovoru. Pouhým poslechem jsme schopni určit, zda se jedná o nezabezpečené spojení či nikoliv. Jsou li přenášená data šifrována, uslyšíme pouze silně nepříjemný šum. V opačném případě je možné vyslechnout vlastní hovor. Druhého, uživalsky méně přívětivého, postupu využijeme tedy v případě, kdy sestavené spojení potřebuje uložit do souboru pro archivaci či další zpracování. Označním paketu sledovaného proudu dat v hlavním okně programu a volbou položky v menu Statistics/ RTP/Stream Analysis vyvoláme dialogové okno, nabízející celou ředu operací. Využijeme však pouze funkci „Save Payloadÿ. Zrekonstruovaná data byla uložena ve formátu „auÿ. Dále stačí zvolit umístění a název výsledného souboru společně se směrem komunikace, kterou chceme uložit. Tento výběr vychází z podmínek každého konkrétního úkolu. Nejčastěji jsou však do souboru ukládány oba směry najednou. Pro každý je tedy vyhrazen jeden zvukový kanál ve formátu stereo.

53

Pro sestavení zachycených dat užijeme druhého postupu, uložení do souboru, aby bylo možné jejich snadné porovnání se zvukem nahraným na straně klienta před vstupem do kodeku. Jednotlivé časové průběhy nezabezpečené komunikace se téměř shodují. Jejich rozdíl je patrný především při poslechu a je způsobený průchodem signálu kodekem. Část zvuku na obráku 9.2 s vyšší amplitudou tedy vystihuje vstupní signál na straně jedné. Odpovídající část na obrázku 9.3 odpovídá časovému průběhu výstupního signálu na straně druhé. Ta je však shodná se zrekonstruovaným signálem, zachyceným ze sítě.

Obr. 9.2: Komunikace RTP náhraná na straně klienta.

Obr. 9.3: Zrekonstruovaná síťová RTP komunikace. Stejný postup byl aplikován na zabezpečenou komunikaci s využitím SRTP. Jak zachycuje obrázek 9.4 a 9.6, časové spektrum vstupního a výstupního signálu na straně obou klientů je téměř totožné. Značný rozdíl nastává v případě, kdy provedeme sestavení hovoru z dat zachycených ze sítě. Nedostaneme snadno odposlechnutelný zvuk, jako v případě užití RTP, ale při pokusu o přehrání dostáváme pouze nepříjemný hluk. Časové spektrum delšího záznamu v celé jeho délce zle vykreslit pouze jako obdélník, jak naznačuje obrázek 9.5.

54

Obr. 9.4: Komunikace SRTP náhraná na straně klienta Tomáš.

Obr. 9.5: Zrekonstruovaná síťová SRTP komunikace.

Obr. 9.6: Komunikace SRTP náhraná na straně klienta Petr.

55

Z důvodu porovnání je nutné zaměřit se pouze na malý časový úsek, kdy obrázek 9.7 zachycuje časové spektrum signálu odesílaného do sitě. Obrázek 9.8 zachycuje totožný záznam, který byl zachycen a sestaven ze sítě. Je proto v šifrované podobě a je zcela nesrozumitelný.

Obr. 9.7: Výřez SRTP komunikace na straně klienta.

Obr. 9.8: Výřez zrekonstruované SRTP komunikace.

56

10

ZÁVĚR

V období několika posledních let rapidně narůstá využití IP telefonie, která je alternativou analogovému telefonnímu spojení. Hlavním důvodem je snadnější dostupnost širokopásmového připojení. Velký zájem o VoIP projevují především střední a malé podniky, kterým se mohou snížit náklady na volání až řádově, oproti volání přes pevnou linku nebo mobilní telefon. Stále oblíbenější se však stává i u domácností, díky zkvalitňování jejich internetového připojení. Masivní nástup s sebou však přináší stále vyšší riziko způsobené především absencí ochrany přenášených dat.Více než luxusem se proto zabezpečení stává spíše nutností. Způsobů, jak přenášená data ochránit proti zneužití, bylo zmíněno několik. Mezi nejvhodnější ochrany dat přenášené v reálném čase bezesporu patří zabezpečení pomocí SRTP protokolu. Důvodem je jeho nízká výpočení i datová náročnost, malý vliv na QoS společně s nezávislostí na použitém přenosovém médiu. Díky těmto vlastnostem je jeho využití možné také mobilních mobilních zařízení s omezenými výpočetními prostředky. Z důvodu absence zabezpečení přenášeného hesla lze touto metodou ochránit data pouze před útokem v reálném čase. K dosažení vyššího stupně zabezpečení je nutná implementace některé z metod šifrující také části signalizace, jejichž nezabezpečený přenos jinak předsavuje další bezpečnostní hrozbu. Vhodnou možností může být užití TLS nebo metod obdobných S/MINE. V praktické části byla provedena úspěšná implementace podpory protokolu SRTP do softwarové ústředny Asterisk. K ověření funkčnosti byla realizována řada hovorů za užití telefonního klienta PhonerLite. K ověření přenosu šifrovaných dat a jejich anlýze dostatečně posloužil síťový a protokolový analyzátor Wireshark. Pomocí něho podle výše pospaných postupů byla ověřena a dokázána schopnost ústředny realizovat hovory pomocí SRTP.

57

LITERATURA [1] KOVÁŘ, P.; MOLNÁR, K.; NOVOTNÝ, V. Současnost a budoucnost VoIP sítí., [online]. 2007, č. 10 [cit. 2008-05-07], s. 1-2. Dostupný z WWW: . ISSN: 1213-1539. [2] Wireshark [online]. 1999 [cit. 2008-05-20]. Dostupný z WWW: . [3] PhonerLite [online]. 2005 [cit. 2008-05-20]. Dostupný z WWW: . [4] RTP, Real-time Transport Protocol [online]. 2008 [cit. 2008-05-20]. Dostupný z WWW: . [5] Real-time Transport Protocol [online]. 2008 [cit. 2008-05-20]. Dostupný z WWW: . [6] ORRBLAD, J. Alternatives to MIKEY/SRTP to secure VoIP [online]. 2005, [cit. 2008-05-20], s. 65. Dostupný z WWW: <www.minisip.org/publications/Thesis Orrblad 050330.pdf>. [7] KULTTI, J. Secure Text in SIP Based VoIP [online]. 2005, [cit. 2008-05-20], s. 74. Dostupný z WWW: http://epubl.luth.se/1402-1617/2005/183/LTU-EX-05183-SE.pdf . [8] Eren, E.; Detken, O. Voice-over-IP Security Mechanisms [online]. 2007, [cit. 2008-05-20], s. 11. Dostupný z WWW: <www.decoit.de/cms/upload/pdf/IW06 eren detken VoIP final.pdf>. [9] ZRTP [online]. 2008 [cit. 2008-05-20]. Dostupný z WWW: . [10] ZRTP support in the Asterisk PBX [online]. 2008 [cit. 2008-05-20]. Dostupný z WWW: . [11] Asterisk config extensions.conf [online]. c2003 [cit. 2008-05-20]. Dostupný z WWW: .

58

[12] How to: Encrypt Your VoIP [online]. c2004 [cit. 2008-05-20]. Dostupný z WWW: . [13] VALOUŠEK, O Asterisk: VoIP ústředna - 2 (konfigurace) [online]. 2006 , [cit. 2007-12-12]. Dostupný z WWW: . [14] Session Initiation Protocol [online]. 2007 ,[cit. 2007-12-12]. Dostupný z WWW: . [15] WIJA, T.; ZUKAL, D.; VOZŇÁK, M. Asterisk a jeho použití [online]. 2005 [cit. 2007-12-12]. Dostupný z WWW: . [16] Andreasen, F.; Baugher, M.; Wing, D. Session Description Protocol (SDP) [online]. 2006, [cit. 2008-05-20], Dostupný z WWW: . [17] Cisco Securing Internet Telephony Media with SRTP and SDP [online]. [cit. 2008-05-20]. Dostupný z WWW: . [18] cervajs Asterisk SRTP [online]. 2005 [cit. 2008-05-20]. Dostupný z WWW: . [19] [patch] Secure RTP [online]. 2005 [cit. 2008-05-20]. Dostupný z WWW: . [20] For developers [online]. c2004 [cit. 2008-05-20]. Dostupný z WWW: .

59

SEZNAM PŘÍLOH A Laboratorní úloha A.1 Cíl . . . . . . . . . . . . . . . . . . A.2 Zadání . . . . . . . . . . . . . . . . A.3 Požadavky na pracoviště . . . . . . A.4 Teoretický úvod . . . . . . . . . . . A.5 Pracovní postup . . . . . . . . . . . A.5.1 Nastavení ústředny . . . . . A.5.2 Nastavení klienta . . . . . . A.5.3 Zachycení komunikace . . . A.5.4 Dekódování komunikace . . A.6 Otázky a úkoly . . . . . . . . . . . A.7 Postup instalace ústředny . . . . . A.7.1 Doplnění systému . . . . . . A.7.2 Instalace libSRTP . . . . . . A.7.3 Instalace knihoven Mimisip A.7.4 Instalace ústředny . . . . .

60

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

61 61 61 62 62 66 66 68 69 70 70 71 71 71 72 72

A

LABORATORNÍ ÚLOHA

Zabezpečení VoIP telefonie VoIP security

A.1

Cíl

Cílem této úlohy je seznámení se základními principy internetové telefonie. Signalizačním protokolem SIP a možnostmi rozšíření open-source telefonní ústředny Asterisk o další protokoly. V tomto případě o SRTP (Secure RTP), který umožňuje přenášený hovor mezi koncovými účastníky zabezpečit. K uskutečnění hovoru bude nutné seznámení s nastavením programů sloužících jako „softwarový telefonní klientÿ, ale také potřebných modulů ústředny. Tyto znalosti budou později využity při vlastním hovoru a následném dekódování zachycených dat.

A.2

Zadání

• Seznamte se signalizačním protokolem SIP aSRTP. • Za pomocí návodu se seznamte se základy konfigurace ústředny Asterisk za užití SIP protokolu a konfiguraci proveďte. • Seznamte se s funkcemi telefonního klienta a proveďte jeho nastavení. • Uskutečněte nejprve nezabezpečený hovor a poté hovor realizovaného s využitím SRTP. • Pomocí programu Wireshark odchyťte komunikaci obou hovorů. • Zachycené telefonáty se pokuste dle návodu dekódovat.

61

A.3

Požadavky na pracoviště

HW požadavky • Ústředna

–

CPU 1 GHz, 512 MB RAM, 1GB volného místa na disku.

• Klientské PC

–

2 x PC, CPU 1 GHz, 512 MB RAM, 50 MB volného místa na disku, zvukovou kartu a multimediální výbavu (mikrofon, sluchátka).

• Ústředna

–

OS Linux s nainstalovanou ústřednou Asterisk včetně podpory SRTP.

• Klientské PC

–

OS Windows 2000/XP, Softwarový klient pro volání PhonerLite, program pro zachytávání paketů Wireshark a ssh klienta (např. Putty).

SW požadavky

A.4

Teoretický úvod

SIP (Session Initiation Protocol) SIP je jedním z několika otevřených signalizačních protokolů. Poskytuje služby potřebné k sestavení spojení v rámci IP sítě. K přenosu může použít jak TCP i UDP, nejčastěji je však komunikuje přes UDP na portu 5060. Patří do rodiny signalizačních protokolů, ve které vyniká svou flexibilitou a jednoduchostí. Je totiž založen na textové na bázi, obdobně jako HTTP nebo SMTP. Díky tomu je velice rychle pochopitelný a transparentní. Při zjišťování a odstraňování chyb v komunikaci nebo špatné konfiguraci zařízení není třeba žádného speciálního analyzátoru provozu. Pro kódování zpráv se nejčastěji využívá znaková sada UTF-8. Mezi jeho základní funkce patří sestavení, modifikace nebo ukončování spojení mezi koncovými účastníky. Nejčastěji je využíván pro telefonní spojení, ale lze ho využít i pro přenos videa, dat nebo textových zpráv.

62

Obsah hlavičky Halvička SIP paketu obsahuje důležité informace pro jeho průchod sítí. Obsahuje například adresu odesílatele, příjemce nebo pořadové číslo probíhajícího hovoru. • Call-ID

–

identické číslo hovoru, generované klientem

• Contact –

zde je uložena SIP adresa, pomocí které je možno kontaktovat druhou stranu bez nutnosti kontaktovat redirect server.

• CSeq

–

pořadové číslo žádosti v rámci jednoho hovoru. Při opakování žádosti je číslo stejné. Číslo se zvyšuje po zaslaní každého požadavku INVITE.

• From

–

obsahuje adresu odesílatele

• To

–

obsahuje adresu příjemce

• Via

–

do této hlavičky každý proxy server vkládá svou adresu. Při odesílání opačným směrem ji odebírá a zároveň kontroluje, zda-li adresa, na kterou odesílá, není v této hlavičce obsažena. Zabraňuje se tím vzniku smyček.

Komunikace v SIP Jak již bylo naznačeno, SIP zprávy jsou textového charakteru. Proto je snadné takovýto provoz sledovat bez nutnosti analyzátoru. Skládají se především z požadavku a hlavičky. Požadavek bývá také označován jako metoda. Pro komunikaci se užívá návěští REQUEST: a udání vlastního požadavku. Mezi nejvýznamnější patří: • INVITE

– žádost o spojení nebo změnu parametrů existující relace

• ACK

– odešle potvrzení o zahájení relace

• BYE

–

• REGISTER

– žádost o registraci účastníka na Registrar serveru

• CANCEL

– přerušení zahajovaní relace ještě před jejím navázáním

• OPTION

– zjišťuje funkce podporované druhým UA

žádost o ukončení relace

Způsob značení odpovědí SIP převzal od protokolu HTTP. Jde o takzvané „stovkové značeníÿ. Hlášení jsou dělena do skupin, kdy 100 až 399 jsou informace o komunikaci. Čísla 400 až 699 signalizují chybu. Její závažnost je přímo úměrná s velikostí čísla.

63

Pří námi uskutečněném hovoru byly užity signály 180 (Ringing) a 200 (OK). Odpovědi se uvádejí s návestím STATUS: a číslo odpovědi. Podrobnější dělení odpovědí: • 1xx

–

průběh – značí právě probíhající stav

• 2xx

–

úspěch – operace byla úspěšně dokončena

• 3xx

–

přesměrování – požadavek je třeba zaslat jinam

• 4xx

–

chyba klienta – značí chybně zadaný požadavek klientem

• 5xx

–

chyba serveru – označení chyby, která vzníkla na straně serveru

• 6xx

–

globální selhání – žádost nemůže být provedena

SRTP (Secure RTP) Z důvodu absence jakékoliv ochrany proti útoku na data přenášených v reálném čase protkolem RTP byl vyvinut SRTP. Definuje formát přenášených dat, zajišťuje kódování vlastních zpráv, kterým poskytuje integritu a důvěryhodnost. Mimo zabezpečení samotného RTP, poskytuje ochranu také kontrolnímu protokolu RTCP. Jeho zprávy jsou přenášeny odděleně přes různé porty. Proto je potřeba chránit oba protokoly během daného spojení. Implementací SRTP velice ztížíme útoky, jak snifování, nahrazení paketů nebo DoS (Denial of Service), na realizovanou komunikaci. SRTP chrání data na úrovni aplikační vrstvy, na které sám pracuje. Proto je nezávislý na transportní i síťové vrstvě, které nebývají nijak nezabezpečeny. Ochranné mechanismy společně s algoritmy pro výměnu klíču jsou implementovány na úrovni aplikační vrsty, což je činí nezávislé na užitém operačním systému

Hlavní rysy SRTP • Možnost použití různých k výměně klíčů šifrujících komunikaci • Minimální vliv na QoS • Zabezpečení obsahu integrity RTP/RTCP paketů • Nízká výpočetní náročnost • Nezávislost na typu sítové vrstvy • Nízký přírůstek objemu šifrovaných dat

64

Poslední tři zmiňované vlastnosti dovolují implementaci na mobilní zařízení s omezenou pamětí a výpočetním výkonem. Při použití některého algoritmu pro předávání klíčů společně s SRTP pro ochranu přenášených dat, dostaneme potřebnou úroveň zabezpečení internetové multimediální aplikace, jakými mohou být například hlasové či video-konference.

Bezpečnostní rysy SRTP • Šifrování síťové komunikace (ochrana proti snifování1 ) • Authentifikace odesílatele (ochrana proti krádeži identity) • Kontrola integrity dat(ochrana proti modifikaci a manipulaci s daty) • Ochrana proti opakování (neautorizovanému přístupu ke koncovému účastníkovi)2

SRTP paket Uspořádání SRTP paktu je velice obdobné, jako u RTP. Hlavička RTP, jež je zapouzdřována protokolem SRTP z důvodu kontroly její neporušenosti na straně příjemce, zůstává po celou dobu neměnná.

Obr. A.1: Uspořádání SRTP paketu. 1

Postup sloužící k zachycení dat, zpravidla patřících jiným uživatlů , odesílaných přes síť. Při tomto typu útoku útočník opakovaně odesílá RTP nebo RTCP data, což může spůsobit DoS. Pouze ochrana integrity prováděná pomocí authentifikace zpráv dokáže ochránit před tímto typem útoku. SRTP touto schopností disponuje. 2

65

Protokol SRTP zajišťuje šifrování nesených dat a může dojít k přidání dvou volitelných položek na konec paketu. • MKI (Master Key Identifier) • Autentifikační tag MKI Je definován, řízen a používán správou klíčů. Slouží k určení užitého hlavního klíče, ze kterého jsou následně generovány klíče daného spojení, spoužící k autentizaci nebo šifrování přenášených dat. Užití tohoto hlavního klíče je dle specifikace SRTP nepovinné.

A.5

Pracovní postup

A.5.1

Nastavení ústředny

K nastavení ústředny je třeba vdáleného přihlášení a následná editace jejich konfiguračních souborů. Pro konfiguraci bude nutné editovat soubory sip.conf, pomocí kterého jsou nastavovány parametry SIP protokolu, a extension.conf, který se chová obdobně jako propojovací pole klasických ústředen. a) Pomocí ikony na pracovní ploše spusťte ssh klienta Putty. Po vyplnění položky „Host Nameÿ a stisknutí tlačítka „Openÿ, budete vyzváni k vyplnění uživatelského jména a hesla, nutného k přihlášení k serveru. Tyto údaje dostanete zadány od cvičícího.

Obr. A.2: Přihlášení pomocí ssh klienta.

66

b) Nastavení SIP protokolu Nastavení modulů používaných ústřednou jsou uložena v příslušných souborech. Ty se nacházejí ve složce /etc/asterisk. K realizaci hovoru budeme využívat SIP protokol. Jeho nastavení jsou uložena v souboru sip.conf. Provedeme tedy vzdáleně jeho otevření pomocí textového editoru „nanoÿ, zadáním příkazu: nano /etc/asterisk/sip.conf Provedeme editaci globálních údajů v sekci [general], mezi které patří nastavení IP adresy a portu, na kterém asterisk naslouchá SIP komunikaci a nastavíme zvukový kodek používaný pro Evropu, kterým je A–law. Povolením položky canreinvite umožníme přesměrování RTP komunikace mimo ústřednu. Sníží se tím pořebná kapacita síťových prostředků a také výpočetní nároky. [general] bindport=asterisk port bindaddr=asterisk IP allow=alaw canreinvite=no

;default 5060 ;zadá vyučující ;zvukový kodek ;povolení přesměrování RTP

Součástí konfiguračního souboru pro SIP protokol může být také statická deklarace uživatelů. Mezi její základní údaje patří jméno přidávaného uživatele, přihlašovací heslo nebo odchozí identifikaci volajícího. Z důvodu přehlednosti provedeme deklaraci na konec souboru a to nejméně pro dva uživatele, kde XX udává jejich pořadové číslo. Údaj v ostrých závorkách by poté mě korespondovat s volacím číslem daného uživatele. [userXX] Type Username Secret Callerid Host

= = = = =

friend přihlašovací jméno heslo jméno <číslo> dynamic

;typ definovaného prvku ;přihlašovací jméno ;heslo v nešiftrované podobě ;identifikace volajícího ;typ adresy

c) Nastavení „Volacího plánuÿ Po nadefinování uživatelů v konfiguračním souboru SIP protokolu je nyní možné přihlášení jednotlivých klientů k dané ústředně. Stále však nejsou určena žádná pravidla, podle kterých by bylo možné realizovat hovor. Ty je třeba nadefinovat v souboru extension.conf. Otevření provedeme příkazem: nano /etc/asterisk/extension.conf

67

Nastavení volacího plánu provedeme přidáním následujících příkazů do sekce general Tento volací plán je nutné nastavit pro každého jednotlivého uživatele. Pro nezabezpečený hovor exten ⇒ číslo,n,Dial(SIP/userXX) Pro volání s využitím SRTP exten exten exten exten

A.5.2

⇒ ⇒ ⇒ ⇒

číslo,1,Set( SIP SRTP SDES=1) číslo,n,Set( SIPSRTP=optional) číslo,n,Set( SIPSRTP CRYPTO=enable) číslo,n,Dial(SIP/userXX)

Nastavení klienta

a) Klienta spustíme pomocí ikony na pracovní ploše. Po otevření programu přejdeme do záložky „Configurationÿ. Zde je nutné vyplnit síťovou adresu Asterisk serveru a přihlašovací údaje daného uživatele.

Obr. A.3: Zadání adresy registrar serveru.

Obr. A.4: Zadání údajů o uživateli.

68

Záložku network není nutné měnit, pokud jsme ponechali standardní port pro SIP komunikaci (5060) a. Pro přenos bude využit protokol transportní UDP. b) V záložce „Codecsÿ provedeme nastavení zvukového kodeku na A-law a necháme volné zatžítko „SRTPÿ.

Obr. A.5: Výběr zvukového kodeku.

A.5.3

Zachycení komunikace

Nezabezpečené Z pracovní plochy spustíme program na odchytávání síťových paketů Wireshark. Pro zachytávání zvolíme v menu položku: Capture/Interfaces Po zvolení správného síťového adaptéru spustíme odchytávání dat tlačítkem „Startÿ. Uložení údajů zadaných do telefonního klienta provedeme až nyní, aby zachycená komunikace obsahovala i registraci k ústředně. Nyní provedeme nezabezpečený hovor mezi dvěma účastníky vytočením jejich osobního čísla. Úspěšnost spojení ověříme. Po úspěšném ukončení hovoru zastavíme odchytávání paketů a síťovou komunikaci uložíme do souboru pro jejich pozdější dekódování.

Zabezpečené Postup je stejný jako v předchozím bodě s tím rozdílem, kdy v záložce „Codecsÿ u softwarového klienta zaškrtneme políčko „SRTPÿ. Tuto změnu uložíme tlačítkem „Saveÿ.

69

A.5.4

Dekódování komunikace

a) Pomocí programu Wireshark otevřete soubor s odchycenou síťovou komunikací, která není zabezpečená. V menu volbou položky Statistics/ VoIP Calls Wireshark vyhledá a zobrazí nalezená spojení. Po označení hovoru a stisku tlačítka „Playerÿ se otevře RTP přehrávač. V okně přehrávače se tiskem dalšího tlačítka „Decodeÿ pokusí o zpětné zrekonstruování zachycených zvukových dat. Tento zpětně sestavený signál lze přehrát stiskem tlačítka „Playÿ. b) Postupujte stejně jako v předchozím bodě, ale nyní postup aplikujte na soubor se zabezpečenou komunikací.

A.6

Otázky a úkoly

• Uveďte rozdíly mezi SIP požadavky INVITE při komunikaci pomocí RTP a SRTP protokolem. • Porovnejte pakety RTP a SRTP. V čem je možné pozorovat jejich odlišnost?

Literatura [1] http://cs.wikipedia.org/wiki/Session_Initiation_Protocol [2] http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol [3] http://www.linuxbsd.com.br/guias_livros/AsteriskTFOT.pdf [4] http://en.wikipedia.org/wiki/Asterisk_(PBX)

70

A.7

Postup instalace ústředny

K provedení úspěšné instalace ústředny bude nutná kompilace potřebných knihoven a následné vlastní ústředny. Také bude požito stahování dat z pracovních stromů (subversion). Systém však vždy nemusí obsahovat potřebné knihovny a programy pro provádění takovýchto operací.

A.7.1

Doplnění systému

Nejprve doinstalujeme programy a knihovny nutných k provádění operací potřebných při instalaci dalších komponent. gcc*, autoconf, automake*, subversion, pkgconfig, pbzip2, libtool, libedit, glibc-utils, libedit-devel, zlib-devel, openldap-devel, ncurses-devel, pth-devel, openssl-devel, openldap-devel, libglademm24-devel,

A.7.2

Instalace libSRTP

Tato knihovna je volně dostupná na adrese: http://srtp.sourceforge.net/download.html Následující postup provede její rozbalení z archivu a následnou kompilaci společně s ověřením funkčnosti. tar -xf srtp-1.4.2.tgz cd srtp autoconf && ./configure && make make runtest make install cd ..

71

A.7.3

Instalace knihoven Mimisip

Stažení instalačních souborů z vývojového stromu. mkdir /usr/src/minisip cd /usr/src/ svn co -r3412 svn://svn.minisip.org/minisip/trunk minisip cd minisip Následná instalace čtyř potřebných knihoven v následujícím pořadí. libmutil, libmnetutil, libmcrypto, libmikey cd lib name $ lib name ./bootstrap $ lib name ./configure --prefix=/usr $ lib name make $ lib name make install

A.7.4

Instalace ústředny

Stažení instalačních souborů z vývojového stromu. mkdir /usr/src/asterisk-trunk cd /usr/src/ svn co -r81432 http://svn.digium.com/svn/asterisk/ /trunk asterisk-trunk cd asterisk-trunk

Stažení a aplikace patche pro podporu SRTP. wget http://bugs.digium.com/file download.php? file id=15384&type=bug -O ast srtp r81432 mikey r3412.patch patch -p1 < ast srtp r81432 mikey r3412.patch

72

Vlastní kompilace a instalace Závěr instalace ústředny a následné doplnění o šablony konfiguračních souborů. Příkazem make menuselect se otevře textové menu, ve které lze přidávat nebo odebírat některé nepotřebné služby či podporu neužitých rozhraní. ./bootstrap ./configure make make menuselect make install make samples Pomocí make samles lze vygenerovat šalony s ukázkami nastavení útředny, které lze následně pouze upravovat, což je výhodné zvláště při začátcích.

Poznámky: • Instalační proces byl testován na systému Fedora 8 i386. • Povolit ve Firewallu porty (UDP porty: 5060 a 8000) pro SIP a RTP komunikaci. • Firewall může být také příčinou nezdaření sestavení hovoru. V tomto případě je nutné nastavení rozsahu portů pro RTP komunikaci v souboru rtp.conf, uloženém ve složce /etc/asterisk.

73