Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky

Za´padoˇceska´ univerzita v Plzni Fakulta aplikovanyćh vˇed Katedra informatiky a vy´poˇcetn´ı techniky

Diplomov´ a pr´ ace IP ch˚ uviˇ cka

Plzeˇ n 2014

Petra Kˇrivanová

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou práci vypracovala samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 9. kvˇetna 2014 Petra Kˇrivanová

Abstract IP Baby Monitor This thesis presents a development of a baby monitor (hereinafter ”monitor”) which can use a computer network. Many of the commonly used monitors have a considerable disadvantage - they do not work in a room where the WiFi is established. This problem is caused by the fact that respective devices use radio waves with the same frequency. In addition, monitors usually do not support any kind of protection for data transmission. This shortage does not only allow the intruder to watch the baby and the equipment yet he can even spy the people. The main goal is to create a baby monitor which can use the computer network (WiFi) for encrypted data transmission of audio and video streams. This IP baby monitor is a software application that is implemented for two operating systems (Windows, GNU/Linux). The monitor uses the server-client architecture. The server is a program running on a device with camera and microphone and it is placed in the baby’s room. The client is in the parent’s room and it can play the stream produced by the server. The server program can also analyze the stream from the camera and the sound from the microphone and it can find motion or volume changes. The clients are notified with a message if there is such a change. The parents have continual supervision of what happens in baby’s room.

Obsah ´ 1 Uvod 2 Existuj´ıc´ı ˇ reˇ sen´ı 2.1 Teoretick´ y základ . . . 2.1.1 Stávaj´ıc´ı ˇreˇsen´ı 2.1.2 Nová aplikace . 2.2 V´ yhody a nev´ yhody . 2.2.1 Stávaj´ıc´ı ˇreˇsen´ı 2.2.2 Nové ˇreˇsen´ı . . 2.2.3 Souhrn . . . . .

1

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

2 2 2 2 3 3 4 5

3 Anal´ yza probl´ emu 3.1 Architektura aplikace . . . . . . . . . . . . . 3.1.1 Sluˇzby serveru . . . . . . . . . . . . . 3.1.2 Moˇznosti klienta . . . . . . . . . . . 3.1.3 Komunikace . . . . . . . . . . . . . . 3.2 Zabezpeˇcen´ı . . . . . . . . . . . . . . . . . . 3.2.1 Registrace . . . . . . . . . . . . . . . 3.2.2 Pˇrihláˇsen´ı . . . . . . . . . . . . . . . 3.2.3 Komunikace . . . . . . . . . . . . . . 3.3 Stream . . . . . . . . . . . . . . . . . . . . . 3.3.1 Audio . . . . . . . . . . . . . . . . . 3.3.2 Video . . . . . . . . . . . . . . . . . 3.3.3 Knihovna pro práci s audiem/videem 3.3.4 Moˇznosti pˇrenosu streamu . . . . . . 3.3.5 Pˇrehráván´ı streamu . . . . . . . . . . 3.3.6 Detekce zmˇen . . . . . . . . . . . . . 3.4 Správa serveru . . . . . . . . . . . . . . . . . 3.4.1 Pˇridán´ı nov´ ych uˇzivatel˚ u . . . . . . . 3.4.2 Nastaven´ı serveru . . . . . . . . . . . 3.4.3 Nastaven´ı streamu . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8 8 8 9 9 10 11 14 19 26 26 27 30 31 35 36 37 37 38 40

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

OBSAH

OBSAH

4 Program´ atorsk´ a pˇ r´ıruˇ cka 4.1 Architektura aplikace . . . . . . 4.1.1 Server . . . . . . . . . . 4.1.2 Klient . . . . . . . . . . 4.2 Zabezpeˇcen´ı . . . . . . . . . . . 4.2.1 Pˇrihláˇsen´ı . . . . . . . . 4.2.2 Z´ıskán´ı ˇsifrovac´ıch kl´ıˇc˚ u 4.2.3 Multicast . . . . . . . . 4.2.4 Komunikace . . . . . . . 4.3 Stream . . . . . . . . . . . . . . 4.3.1 FFmpeg . . . . . . . . . 4.3.2 Pˇrenos streamu . . . . . 4.3.3 Pˇresmˇerován´ı logu . . . 4.3.4 Detekce zmˇen . . . . . . 4.3.5 Pˇrehráván´ı streamu . . . 4.3.6 Ukládán´ı streamu . . . . 4.4 Správa serveru . . . . . . . . . . 4.4.1 Registrace . . . . . . . . 4.4.2 Ukládán´ı hodnot . . . . 4.5 Grafické rozhran´ı . . . . . . . . 4.6 Konzolové rozhran´ı . . . . . . .

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

41 41 41 43 44 44 45 45 46 48 48 50 51 51 52 53 53 54 56 56 57

5 Namˇ eˇ ren´ e hodnoty 5.1 Vyuˇzit´ı ˇs´ıˇrky pásma . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Vyuˇzit´ı pamˇeti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Pˇrehráván´ı streamu . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59 59 59 60

6 Z´ avˇ er

63

Literatura

64

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pˇ r´ılohy 68 Uˇzivatelská pˇr´ıruˇcka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Obsah CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

III

Seznam obr´ azk˚ u 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14

Schématick´ y obrázek fungován´ı aplikace. . . . . . . . . . . . . . Autentizace serveru pomoc´ı SSL. [17] . . . . . . . . . . . . . . . Varován´ı pˇri pouˇzit´ı ned˚ uvˇeryhodného certifikátu. . . . . . . . Aplikace S-box na kaˇzd´ y byte u ˇsifry AES v SubBytes fázi [28]. . Posun ˇra´dk˚ u u ˇsifry AES v ShiftRow fázi [26]. . . . . . . . . . . Pseudokód ˇsifry AES [23] (obr. byl upraven). . . . . . . . . . . . ˇ Sifrov´ an´ı AES pomoc´ı metody CBC [30] (obr. byl upraven). . . ˇ Sifrov´ an´ı AES pomoc´ı metody CFB [31] (obr. byl upraven). . . Ukázka pouˇzit´ı ECB a CBC mód˚ u na obrázek [7]. . . . . . . . . Spojen´ı 2(4) pixel˚ u chrominanˇcn´ıho kanálu dohromady [8]. . . . Ukázka posloupnosti rámc˚ u v MPEGu [2]. . . . . . . . . . . . . Kop´ırován´ı jednoho vstupu na v´ıce v´ ystup˚ u u FFmpegu [35]. . . Kódován´ı vstupu pro kaˇzd´ y v´ ystup zvláˇst’ u FFmpegu [35]. . . . Pˇrehráván´ı ˇsifrovaného streamu pomoc´ı SRTP a UDP protokol˚ u.

4.1 4.2

UML diagram tˇr´ıd pro server. . . . . . . . . . . . . . . . . . . . . . . 42 UML diagram tˇr´ıd pro klienta. . . . . . . . . . . . . . . . . . . . . . . 43

5.1

Neˇzádouc´ı ruˇsen´ı obrazu. . . . . . . . . . . . . . . . . . . . . . . . . . 60

P P P P P P P P P P P

1 2 3 4 5

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

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

Pˇrihlaˇsovac´ı okno do aplikace klienta. . . . . . . . . . . . . . . . . . Klientsk´ y program - pˇrehrávaˇc. . . . . . . . . . . . . . . . . . . . . Ikona pˇrehrávaˇce. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zobrazen´ı zprávy u klienta pˇri zmˇenˇe. . . . . . . . . . . . . . . . . Zobrazen´ı posledn´ı obdrˇzené zprávy o zmˇenˇe v oznamovac´ı oblasti po stisku ikony pˇrehrávaˇce. . . . . . . . . . . . . . . . . . . . . . . . . 6 Stránka pro pˇridán´ı nov´ ych klient˚ u. . . . . . . . . . . . . . . . . . 7 Seznam registrovan´ ych uˇzivatel˚ u. . . . . . . . . . . . . . . . . . . . 8 Stránka pro nastaven´ı mez´ı pro detekce zmˇen. . . . . . . . . . . . . 9 Stránka pro nastaven´ı parametr˚ u streamu. . . . . . . . . . . . . . . 10 Stránka pro nastaven´ı serveru. . . . . . . . . . . . . . . . . . . . . 11 Nastaven´ı povolen´ı aplikace ve firewallu systému. . . . . . . . . . . IV

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

10 12 13 22 23 24 24 25 25 28 29 33 33 34

. . . .

72 73 73 73

. . . . . . .

74 75 76 76 77 78 79

´ ˚ SEZNAM OBRAZK U

´ ˚ SEZNAM OBRAZK U

P 12 Povolen´ı pˇr´ıchoz´ıho spojen´ı na klienta. . . . . . . . . . . . . . . . . . 80 P 13 Náhled na spuˇstˇen´ y pˇrehrávaˇc i s oknem se streamem. . . . . . . . . 84

V

Seznam tabulek 2.1

Souhrn nedostatk˚ u souˇcasn´ ych ch˚ uviˇcek. . . . . . . . . . . . . . . . .

3.1

Postup autentizace SRP protokolu [37]. . . . . . . . . . . . . . . . . . 17

4.1 4.2

Typy a v´ yznam komunikaˇcn´ıch zpráv. . . . . . . . . . . . . . . . . . . 47 Popis parametr˚ u FFmpegu [12]. . . . . . . . . . . . . . . . . . . . . . 50

5.1 5.2

Vyuˇzit´ı ˇs´ıˇrky pásma programy. . . . . . . . . . . . . . . . . . . . . . . 61 Vyuˇzit´ı pamˇeti program˚ u. . . . . . . . . . . . . . . . . . . . . . . . . 62

VI

4

´ 1 Uvod Dˇetské elektronické ch˚ uviˇcky (dále jen ch˚ uviˇcky) jiˇz dávno nejsou jen jednocestné vys´ılaˇcky pro pˇrenos zvuku. Dnes jsou k dostán´ı ch˚ uviˇcky, které kromˇe pˇrenosu zvuku zvládaj´ı i pˇrenos obrazu, hl´ıdán´ı teploty v m´ıstnosti, hl´ıdán´ı hladiny zvuku, detekuj´ı zmˇenu obrazu, hraj´ı dˇetem ukolébavky nebo maj´ı i noˇcn´ı vidˇen´ı. Hodnˇe dneˇsn´ıch ch˚ uviˇcek má vˇsak jednu zásadn´ı vadu, a sice ˇze vys´ılaj´ı ve stejném frekvenˇcn´ım pásmu, jako WiFi s´ıtˇe. V´ ysledek je takov´ y, ˇze ani jedno zaˇr´ızen´ı nefunguje tak, jak by mˇelo. V nˇekter´ ych pˇr´ıpadech dokáˇz´ı ch˚ uviˇcky dokonce i vyˇradit bezdrátovou s´ıt’ z provozu u ´plnˇe. C´ılem této práce je vytvoˇrit softwarovou aplikaci, která bude pouˇz´ıvat standardn´ı s´ıt’ové protokoly a bude m´ıt takové funkce, aby ji bylo moˇzné pouˇz´ıt jako náhradu stávaj´ıc´ıch ch˚ uviˇcek. Aplikace by tedy mˇela umˇet pˇrenáˇset zvuk, video, detekovat zmˇenu obrazu nebo zvuku a dát o tˇechto zmˇenách, nˇejak´ ym zp˚ usobem, vˇedˇet pˇr´ıjemci. Oproti bˇeˇzn´ ym ch˚ uviˇckám bude aplikace provádˇet ˇsifrován´ı veˇskerého datového pˇrenosu. D´ıky pouˇzit´ı standardn´ıch s´ıt’ov´ ych protokol˚ u je moˇzné vyuˇz´ıt existuj´ıc´ıch drátov´ ych i bezdrátov´ ych s´ıti k pˇrenosu jak videa tak zvuku. T´ım se eliminuje neˇza´douc´ı ruˇsen´ı, které se u bˇeˇzn´ ych ch˚ uviˇcek jinak objevuje.

1

2 Existuj´ıc´ı ˇreˇsen´ı 2.1 2.1.1

Teoretick´ y z´ aklad St´ avaj´ıc´ı ˇ reˇ sen´ı

Dˇetská ch˚ uviˇcka je malé elektronické zaˇr´ızen´ı, které se pouˇz´ıvá pro hl´ıdán´ı a monitorován´ı mal´ ych dˇet´ı. Obvykle se skládá ze dvou ˇca´st´ı - vys´ılac´ı a pˇrij´ımac´ı. Vys´ılac´ı ˇca´st je um´ıstˇena v pokoji d´ıtˇete, zachytává zvuk a odes´ılá ho na pˇrij´ımac´ı zaˇr´ızen´ı, které je v pokoji rodiˇc˚ u a oni d´ıky tomu slyˇs´ı, ˇze se nˇeco dˇeje. Na takovémto principu funguj´ı vˇsechny ch˚ uviˇcky. Dnes jsou k dostán´ı i ch˚ uviˇcky, které umoˇzn ˇuj´ı dvoucestnou komunikaci, tedy je moˇzné na d´ıtˇe pˇres pˇrij´ımac´ı zaˇr´ızen´ı mluvit. Mimo to existuj´ı i ch˚ uviˇcky s pˇrenosem obrazu nebo detekc´ı zmˇeny hladiny zvuku. Souˇcást´ı tˇech lepˇs´ıch je i infra sn´ımán´ı okol´ı a dalˇs´ı funkce. Objevily se uˇz i ch˚ uviˇcky, které dokáˇz´ı pro pˇrenos dat pouˇz´ıvat WiFi s´ıt’.

2.1.2

Nov´ a aplikace

Novˇe vytvoˇrená aplikace vycház´ı z konceptu fungován´ı stávaj´ıc´ıch ch˚ uviˇcek, ˇcili je taktéˇz rozdˇelena na ˇca´st pˇrij´ımac´ı (dále jen klient) a ˇcást vys´ılac´ı (dále jen server). Jedná se o softwarovou aplikaci, která byla vytvoˇrena pˇredevˇs´ım pro pouˇzit´ı v privátn´ıch s´ıt´ıch1 , a kde je nutné, aby na zaˇr´ızen´ı, na kterém bˇeˇz´ı server, byla um´ıstˇena kamera a mikrofon, na klientovi zobrazovac´ı zaˇr´ızen´ı a jak klient, tak server mˇeli pˇr´ıstup do poˇc´ıtaˇcové s´ıtˇe. Klient si m˚ uˇze nechat od serveru pos´ılat aktuálnˇe sn´ıman´ y zvuk a video (dále stream) ze vstupn´ıch zaˇr´ızen´ı a nechat si pos´ılat zprávy pˇri zv´ yˇsen´ı hladiny zvuku nebo pohybu pˇred kamerou. Dále je moˇzné pˇr´ıchoz´ı stream u klienta ukládat na disk. Aplikace neumoˇzn ˇuje obousmˇerné pos´ılán´ı streamu, tzn. na d´ıtˇe nen´ı moˇzné pˇres aplikaci mluvit. Server podporuje pˇripojen´ı v´ıce klient˚ u najednou a veˇskerá komunikace mezi serverem a klienty je ˇsifrovaná, vˇcetnˇe pˇrenosu streamu. 1

Aplikace funguje i pˇres internet, pokud má zaˇr´ızen´ı se serverem pˇridˇelenu veˇrejnou IPv4 adresu.

2

Existuj´ıc´ı ˇreˇsen´ı

2.2 2.2.1

Výhody a nevýhody

V´ yhody a nev´ yhody St´ avaj´ıc´ı ˇ reˇ sen´ı

Jak jiˇz bylo ˇreˇceno, hlavn´ı d˚ uvod, proˇc tato aplikace vznikla, je ten, ˇze digitáln´ı ch˚ uviˇcky vyuˇz´ıvaj´ı ke sv´ ym pˇrenos˚ um stejné frekvenˇcn´ı pásmo jako WiFi s´ıtˇe. Kv˚ uli tomu jsou obˇe zaˇr´ızen´ı navzájem ruˇsena nebo nefunguj´ı v˚ ubec. To pˇredstavuje obrovsk´ y problém hlavnˇe pro byty v panelákov´ ych domech, kde je na malém prostoru seskupeno velké mnoˇzstv´ı WiFi s´ıt´ı. Vˇetˇsina ch˚ uviˇcek má nav´ıc zabudovan´ y jen jeden kanál, na kterém vys´ılá a nen´ı moˇzné ho zmˇenit. Mezi dalˇs´ı nebezpeˇcné záleˇzitosti velkého poˇctu ch˚ uviˇcek patˇr´ı to, ˇze nevaruj´ı, pokud dojde ke ztrátˇe signálu.

U analogov´ ych ch˚ uviˇcek nedocház´ı sice k tomu, ˇze by se ruˇsily s WiFi s´ıt´ı, ale je tu jin´ y závaˇzn´ y problém a to naruˇsen´ı soukrom´ı, a t´ım i bezpeˇcnosti. U tˇechto typ˚ u ch˚ uviˇcek se ˇcasto stává, ˇze d´ıtˇe, které je slyˇset, nepatˇr´ı tˇem rodiˇc˚ um, kteˇr´ı ho slyˇs´ı. Kdokoliv na stejné frekvenci m˚ uˇze poslouchat.

Na trhu lze dostat i nˇekolik málo ch˚ uviˇcek, které vyuˇz´ıvaj´ı WiFi s´ıt’. Opˇet vˇsak nepodporuj´ı ˇsifrován´ı pˇrenosu a nˇekteré jsou nav´ıc ˇspatnˇe provedené. Video nebo zvuk nen´ı tak kvalitn´ı, jak je uvedeno ve specifikac´ıch, nebo ch˚ uviˇcky neposkytuj´ı pˇripojen´ı v´ıce odbˇeratel˚ u videa/zvuku. Zaˇr´ızen´ı bud’ v´ıce odbˇeratel˚ u najednou nepodporuj´ı v˚ ubec nebo podporuj´ı ˇspatnˇe. Vˇsichni uˇzivatelé maj´ı stejné nastaven´ı a vzájemnˇe si ho pod rukou mohou mˇenit2 .

Podle u ´hlu pohledu by bylo moˇzné za v´ yhodu prohlásit to, ˇze ch˚ uviˇcky nepotˇrebuj´ı ke svému fungován´ı WiFi. U vˇetˇsiny ch˚ uviˇcek se také uvád´ı vˇetˇs´ı dosah (v metrech), neˇz kter´ y nab´ız´ı WiFi. Na ch˚ uviˇcku pracuj´ıc´ı pˇres Internet je ale moˇzné se pˇripojit odkudkoliv, na rozd´ıl od bˇeˇzné ch˚ uviˇcky, jej´ıˇz dosah konˇc´ı cca kolem 200m. Bˇeˇzná ch˚ uviˇcka bude fungovat i pˇri vypnut´ı elektrického proudu, pokud je na baterky a ty jsou nabité. Souhrn nejˇcastˇejˇs´ıch nedostatk˚ u souˇcasn´ ych ch˚ uviˇcek je v tabulce 2.1.

2

V dobˇe, kdy jiˇz byla tato pr´ ace zadána, vzniklo nˇekolik nov´ ych ch˚ uviˇcek, které, kromˇe jiného, podporuj´ı jak ˇsifrov´ an´ı pˇrenosu, tak pouˇz´ıvaj´ı WiFi s´ıt’, a obraz se dá zobrazit na chytr´ ych telefonech.

3

Existuj´ıc´ı ˇreˇsen´ı # 1 2 3 4 5 6 7 8 9 10

Výhody a nevýhody Nedostatky stávaj´ıc´ıch ch˚ uviˇcek Nen´ı moˇzn´ y paraleln´ı provoz ch˚ uviˇcky s WiFi. Neˇsifrovan´ y pˇrenos. Ruˇsen´ı jin´ ymi ch˚ uviˇckami. Neupozornˇen´ı pˇri ztrátˇe signálu. Nemoˇznost v´ ymˇeny pouze kamery/mikrofonu. Nen´ı moˇznost pˇripojit v´ıce pˇrij´ımaˇc˚ u. Nelze mˇenit nastaven´ı pos´ılaného streamu. Omezen´ y dosah. Nen´ı moˇznost v´ ybˇeru, zda sledovat video nebo audio. Nelze ukládat obraz/zvuk do souboru. Tab. 2.1: Souhrn nedostatk˚ u souˇcasn´ ych ch˚ uviˇcek.

2.2.2

Nov´ eˇ reˇ sen´ı

T´ım, ˇze aplikace vyuˇz´ıvá jiˇz existuj´ıc´ı rozhran´ı pro komunikaci, kter´ ym jsou poˇc´ıtaˇcové s´ıtˇe, ˇreˇs´ı nejvˇetˇs´ı problém ch˚ uviˇcek. Dalˇs´ım velk´ y problémem, kter´ y je zde vyˇreˇsen, je bezpeˇcnost. Jednak v podobˇe ovˇeˇrován´ı pˇrihlaˇsovac´ıch u ´daj˚ u na stranˇe serveru, a pak také ˇsifrován´ım veˇskerého pˇrenosu vˇcetnˇe ˇsifrován´ı stream˚ u. Dalˇs´ı v´ yhodu pˇredstavuje i to, ˇze k serveru se najednou m˚ uˇze pˇripojit v´ıce klient˚ u, kteˇr´ı mohou sledovat stream a m´ıt svoje vlastn´ı nastaven´ı, co se t´ yˇce zas´ılán´ı upozornˇen´ı nebo i typu zas´ılaného streamu (audio/video). Obraz je moˇzné sledovat bud’ nepˇretrˇzitˇe nebo si ho nechat pustit vˇzdy v pˇr´ıpadˇe nˇejakého podnˇetu (ˇsum, pohyb).

Na rozd´ıl od ostatn´ıch ch˚ uviˇcek je moˇzné si vybrat, zda sledovat video se zvukem 3 nebo jen zvuk . Tato moˇznost je v´ yhodná v pˇr´ıpadˇe pomalého pˇripojen´ı, které by nemuselo velk´ y objem dat, kter´ y pˇredstavuje pˇrenos video streamu, propustit. Mezi dalˇs´ı vˇeci, které ch˚ uviˇcky neobsahuj´ı, patˇr´ı nastaven´ı kvality pˇrenáˇseného streamu. Upravit lze jak zvuk, tak video. Samozˇrejmˇe, toto nastaven´ı pak sd´ıl´ı vˇsichni klienti.

V pˇr´ıpadˇe, ˇze klient ztrat´ı spojen´ı se serverem, je o tom uˇzivatel ihned informován. Mezi nev´ yhody lze ˇradit to, ˇze aplikaci je nutné spustit na zaˇr´ızen´ı, které podporuje Windows/Linux a má funkˇcn´ı kameru a mikrofon. To plat´ı pro server, klient 3

Pokud nebude uvedeno jinak, budou pˇrenáˇsené streamy nadále oznaˇcovány jako video (video+audio) a audio.

4



mus´ı b´ yt naopak puˇstˇen na zaˇr´ızen´ı se zobrazovac´ım zaˇr´ızen´ım a reproduktory. V pˇr´ıpadˇe, ˇze rodiˇc pracuje z domova, m˚ uˇze m´ıt na poˇc´ıtaˇci puˇstˇeného klienta, a v pˇr´ıpadˇe, ˇze se nˇeco zaˇcne d´ıt, je upozornˇen zprávou. D´ıky tomu nemus´ı sledovat v´ıce zaˇr´ızen´ı najednou. Upozornˇen´ı je pouze vizuáln´ı, aplikace nepodporuje ˇza´dné audio alarmy ani vibrace. V souˇcasné dobˇe aplikace, ve v´ ychoz´ım nastaven´ı, poˇc´ıtá s pouˇzit´ım jedné kamery a jednoho mikrofonu. Pˇri pouˇzit´ı uˇzivatelského nastaven´ı by bylo moˇzné sn´ımat obraz ze dvou kamer. Omezen´ı je dáno t´ım, ˇze pouze na dvou portech poslouchaj´ı udp servery, které streamy ˇsifruj´ı a poskytuj´ı klient˚ um.

Aplikace neumoˇzn ˇuje obousmˇernou komunikaci. To znamená, ˇze na d´ıtˇe nen´ı moˇzné pomoc´ı aplikace mluvit. Zda se jedná o v´ yhodu, ˇci nev´ yhodu, je sporné. Pokud d´ıtˇe zaˇcne breˇcet, stejnˇe se na nˇej rodiˇc bude muset j´ıt pod´ıvat. Nav´ıc, d´ıtˇe by mohlo mást, ˇze na nˇej nˇekdo mluv´ı, ale nikoho nevid´ı.

2.2.3

Souhrn

Nyn´ı se pod´ıváme na shrnut´ı toho, jaké problémy m´ıvaj´ı souˇcasné ch˚ uviˇcky, a které z nich a jak ˇreˇs´ı nová aplikace. Hlavn´ı problém, jak uˇz bylo nˇekolikrát zm´ınˇeno, je nefunkˇcnost ch˚ uviˇcek spoleˇcnˇe s WiFi. Ch˚ uviˇcky, které vys´ılaj´ı ve stejném frekvenˇcn´ım pásmu jako WiFi s´ıtˇe, jsou ruˇseny a nefunguj´ı správnˇe nebo v˚ ubec. Hodnˇe ch˚ uviˇcek má nav´ıc pˇredvolen jen jeden kanál pro pˇrenos dat. Aplikace tento závaˇzn´ y problém ˇreˇs´ı tak, ˇze k pˇrenosu dat vyuˇz´ıvá poˇc´ıtaˇcové s´ıtˇe a standardn´ı s´ıt’ové protokoly. Je pak nutné, aby obˇe zaˇr´ızen´ı s aplikac´ı mˇela pˇripojen´ı do poˇc´ıtaˇcové s´ıtˇe.

Hodnˇe ch˚ uviˇcek stále nepodporuje ˇsifrován´ı pˇrenáˇsen´ ych dat. Data je moˇzné bez problém˚ u odposlouchávat a naruˇsovat tak soukrom´ı osob. Hlavn´ı nebezpeˇc´ı pak pˇredstavuj´ı video ch˚ uviˇcky, kde u ´toˇcn´ık m˚ uˇze sledovat napˇr. vybaven´ı bytu. Existuj´ı i ch˚ uviˇcky, které téˇz pˇrenáˇs´ı data pˇres poˇc´ıtaˇcovou s´ıt’ a jediné zabezpeˇcen´ı pˇredstavuje ovˇeˇren´ı uˇzivatele pomoc´ı jména a hesla. Data ˇsifrována nejsou. Aplikace proto ˇ ˇsifruje veˇsker´ y pˇrenos dat. Sifrov´ any jsou i pˇrenáˇsené streamy.

Ch˚ uviˇcky jsou vˇetˇsinou tvoˇreny z jednoho vys´ılaˇce a jednoho pˇrij´ımaˇce. Sledovat d´ıtˇe, tak m˚ uˇze vˇzdy jen jedna osoba. Aplikace podporuje pˇripojen´ı v´ıce klient˚ u, kteˇr´ı mohou odeb´ırat stream. D´ıtˇe tak m˚ uˇze kontrolovat kaˇzd´ y, kdo má pˇr´ıstup do aplikace.

5



Ch˚ uviˇcky vˇetˇsinou slouˇz´ı k tomu, aby pˇrepravily zaznamenan´ y vstup na pˇrij´ımac´ı zaˇr´ızen´ı a uˇz neˇreˇs´ı nastaven´ı vlastnost´ı pˇrenáˇsen´ ych dat. Nen´ı tak napˇr´ıklad moˇzné upravit velikost nebo kvalitu pˇrenáˇseného videa. U existuj´ıc´ıch video ch˚ uviˇcek, které pouˇz´ıvaj´ı poˇc´ıtaˇcové s´ıtˇe, to m˚ uˇze b´ yt problém napˇr. pˇri pˇret´ıˇzen´ı s´ıtˇe. Pˇrednastavená kvalita videa pˇredstavuje pˇr´ıliˇs velk´ y objem dat, kter´ y nen´ı moˇzné pˇrenést. Nová ch˚ uviˇcka umoˇzn ˇuje nastaven´ı parametr˚ u pˇrenáˇsen´ ych stream˚ u. Je tak moˇzné nastavit poˇcet audio kanál˚ u, velikost nebo kvalitu videa a audio frekvenci. D´ıky tomu lze hodnˇe redukovat objem pˇrenáˇsen´ ych dat.

Dalˇs´ı problém, kter´ y s t´ımto souvis´ı, je nemoˇznost vybrán´ı si sledovaného streamu. Pokud video ch˚ uviˇcka pˇrenáˇs´ı i zvuk, vˇetˇsinou zde nen´ı na v´ ybˇer, jestli bude uˇzivatel sledovat obraz se zvukem nebo jen zvuk. V pˇr´ıpadˇe vyt´ıˇzen´ı s´ıtˇe by se opˇet hodila moˇznost m´ıt na v´ ybˇer a sledovat jen audio, které je oproti videu podstatnˇe ménˇe nároˇcné na objem pˇrenesen´ ych dat. Aplikace tuto vlastnost má a poskytuje uˇzivatel˚ um 2 moˇznosti. Bud’ mohou sledovat video se zvukem, nebo samotn´ y zvuk.

V nedávné dobˇe se objevila nová ch˚ uviˇcka, která podporuje sn´ımán´ı obrazu z v´ıce kamer najednou. Jedná se o uˇziteˇcnou vlastnost v pˇr´ıpadˇe, ˇze jsou v pokoji um´ıstˇeny napˇr. dvˇe dˇeti nebo d´ıtˇe je uˇz vˇetˇs´ı, a mohlo by se dostat ze zorného u ´hlu kamery, která nedokáˇze sn´ımat cel´ y pokoj. Jedná se o novou funkcionalitu a je pouze pár ch˚ uviˇcek, které j´ı poskytuj´ı. Naˇse aplikace poˇc´ıtá s pouˇzit´ım jedné kamery a jednoho mikrofonu. Má vˇsak i funkci pro zadán´ı vlastn´ıho pˇr´ıkazu, kter´ y z´ıskává vstupn´ı streamy. T´ım je umoˇznˇeno zkuˇsen´ ym uˇzivatel˚ um pouˇzit´ı i dvou kamer najednou.

Hodnˇe ch˚ uviˇcek obsahuje upozornˇen´ı v pˇr´ıpadˇe nˇejaké události. Upozornˇen´ı m˚ uˇze b´ yt bud’ zvukové, vizuáln´ı nebo vibraˇcn´ı. Mezi nejˇcastˇejˇs´ı události pak patˇr´ı pohyb pˇred kamerou nebo zv´ yˇsen´ı hlasitosti v pokoji d´ıtˇete. Naˇse aplikace vyuˇz´ıvá pouze vizuáln´ıch upozornˇen´ı v podobˇe zpráv v oznamovac´ı oblasti. ˇ ym a i nebezpeˇcn´ Cast´ ym problémem je, ˇze pokud se pˇrij´ımaˇc dostane mimo dosah vys´ılaˇce, nedá o tom ˇza´dn´ ym zp˚ usobem vˇedˇet uˇzivateli. Ten si pak mysl´ı, ˇze se u d´ıtˇete nic nedˇeje, ale skuteˇcnost m˚ uˇze b´ yt jiná. Nˇekteré ch˚ uviˇcky to ˇreˇs´ı napˇr. varovn´ ym signálem. Nová aplikace tento problém téˇz ˇreˇs´ı. Pokud dojde ke ztrátˇe spojen´ı mezi serverem a klientem, klient je upozornˇen zprávou a jeho program je ukonˇcen. Ke ztrátˇe spojen´ı m˚ uˇze doj´ıt bud’ d˚ usledkem chyby pˇri pˇrenosu dat nebo i tak, ˇze server byl odpojen.

6



Hodnˇe ch˚ uviˇcek poskytuje kameru s noˇcn´ım vidˇen´ım. D´ıtˇe je tak moˇzné bez problém˚ u sledovat i v noci. Ne vˇsechna zaˇr´ızen´ı jsou ale natolik kvalitn´ı, aby na nich bylo v noci nˇeco vidˇet. Naˇse aplikace pˇrenáˇs´ı stream bez ohledu na to, o jakou kameru se jedná. Pokud bude pˇripojena infra kamera, bude se pˇrenáˇset stream z infra kamery. T´ım pádem záleˇz´ı pouze na uˇzivateli, jakou kameru si poˇr´ıd´ı. V pˇr´ıpadˇe, ˇze kamera nebude kvalitn´ı nebo se rozbije, lze ji, na rozd´ıl od bˇeˇzn´ ych ch˚ uviˇcek, bez problém˚ u vymˇenit.

Ch˚ uviˇcky se vytváˇr´ı tak, aby byly mobiln´ı a tud´ıˇz jsou pˇreváˇznˇe napájené na baterie. U naˇs´ı aplikace záleˇz´ı na tom, na jak´ ych zaˇr´ızen´ıch jednotlivé programy pobˇeˇz´ı. Server je moˇzné spustit na malém zaˇr´ızen´ı s procesorem ARM, které je téˇz moˇzné napájet z baterie.

Jako pˇrednost nˇekteré ch˚ uviˇcky uvád´ı moˇznost mluven´ı na d´ıtˇe pˇres zaˇr´ızen´ı. Naˇse aplikace toto nepodporuje. D´ıtˇe by mohlo mást, pokud by na nˇej nˇekdo mluvil a ono by ho nevidˇelo. Pravdˇepodobnˇe by pak utˇeˇsován´ı skrz ch˚ uviˇcku ani nefungovalo. Lepˇs´ı vlastnost´ı nˇekter´ ych ch˚ uviˇcek je pˇrehráván´ı ukolébavek. Naˇse aplikace vˇsak nepodporuje ani tuto vlastnost.

Nˇekolik ch˚ uviˇcek podporuje ukládán´ı pˇrenáˇseného streamu do souboru. Vznikne tak video, které je moˇzné pˇrehrát v multimediáln´ım pˇrehrávaˇci. Takov´ y soubor m˚ uˇze b´ yt dobr´ y napˇr. pˇri zjiˇstˇen´ı, jak d´ıtˇe vylezlo z post´ ylky a do budoucna tomu zabránit. Aplikace téˇz umoˇzn ˇuje ukládán´ı streamu. Ten je ukládán do souboru vˇzdy na stranˇe klienta. Kaˇzd´ y pˇripojen´ y klient si m˚ uˇze vybrat, zda si bude stream ukládat, ˇci nikoliv.

7

3 Analýza problému V této kapitole se budeme zab´ yvat dostupn´ ymi technologiemi, jejich popisem a zároveˇ n i v´ ybˇerem tˇech nejvhodnˇejˇs´ıch, které budou dostaˇcuj´ıc´ı pro naˇse u ´ˇcely.

3.1

Architektura aplikace

Aplikace, která bude splˇ novat vlastnosti ch˚ uviˇcky, se mus´ı skládat ze dvou ˇca´st´ı. Jedna ˇcást bude m´ıt za u ´kol pˇrij´ımat obraz a zvuk v pokoji d´ıtˇete a druhá mus´ı b´ yt schopná dané streamy zobrazit. Mimo to, vys´ılac´ı ˇca´st aplikace mus´ı umˇet obsluhovat v´ıce pˇrij´ımac´ıch zaˇr´ızen´ı najednou, mus´ı je od sebe jednoznaˇcnˇe rozeznat, umˇet rozliˇsit ta, která jsou pˇrihláˇsená a registrovaná, a mus´ı b´ yt schopna drˇzet pro kaˇzdé zaˇr´ızen´ı jin´ y relaˇcn´ı kl´ıˇc urˇcen´ y k ˇsifrován´ı komunikace. Vys´ılac´ı zaˇr´ızen´ı tedy poskytuje sv´ ym pˇrij´ımaˇc˚ um urˇcité sluˇzby, ke kter´ ym, aby je mohly pouˇz´ıvat, se mus´ı nejdˇr´ıve registrovat, a pak pˇrihlásit. Proto byla zvolena architektura klient-server, která odpov´ıdá charakteru ch˚ uviˇcek.

Jako server bude dále oznaˇcován program, jenˇz je um´ıstˇen na zaˇr´ızen´ı s kamerou a mikrofonem, a má za u ´kol zaznamenávat zvuk a video a pˇrepos´ılat ho vˇsem registrovan´ ym klient˚ um, kteˇr´ı si o nˇej zaˇzádaj´ı (vys´ılac´ı zaˇr´ızen´ı). Naopak jako klient bude dále oznaˇcován program, kter´ y je um´ıstˇen na zaˇr´ızen´ı s monitorem a reproduktory, a zobrazuje pˇrij´ıman´ y stream od serveru (pˇrij´ımac´ı zaˇr´ızen´ı). Aplikac´ı pak rozum´ıme oba dva programy dohromady, ˇcili celou ch˚ uviˇcku.

3.1.1

Sluˇ zby serveru

Mezi sluˇzby, které bude server poskytovat, se ˇrad´ı: • Pos´ılán´ı streamu z´ıskaného z kamery a mikrofonu na vyˇza´dán´ı. Pos´ılat je moˇzné bud’ jen samotné audio nebo audio+video. • Pos´ılán´ı zpráv pˇri zmˇenˇe videa/audia. Zprávy chod´ı pouze na vyˇzádán´ı. • Registrace nov´ ych uˇzivatel˚ u, kteˇr´ı mohou aplikaci pouˇz´ıvat. • Správa serveru pˇres webové rozhran´ı. 8

Analýza problému

3.1.2


Moˇ znosti klienta

Klient m˚ uˇze vyuˇz´ıvat vˇsech v´ yˇse popsan´ ych sluˇzeb serveru. Funkce klienta tedy jsou: • Vyˇzádán´ı si a pˇrehráván´ı audia/videa+audia. • Zobrazen´ı pˇr´ıchoz´ıch zpráv o zmˇenˇe audia/videa. • Ukládán´ı pˇr´ıchoz´ıho streamu do souboru. • Registrace.

3.1.3

Komunikace

Na schématickém náhledu na obr. 3.1 budou struˇcnˇe popsány základn´ı prvky komunikace a toku dat v aplikaci. Klient a server jsou zde vyobrazeny jako dva poˇc´ıtaˇce, na kter´ ych aplikace bˇeˇz´ı. Na serveru bˇeˇz´ı program ffmpeg.exe (viz kap. 3.3.3), kter´ y dokáˇze z´ıskávat stream z webové kamery a mikrofonu. Tento stream pˇrekóduje na vhodn´ y formát (viz kap. 3.3.2) a na server pos´ılá dva na sobˇe nezávislé streamy na dva r˚ uzné porty. Prvn´ı stream je audio+video a druh´ y je jen audio. Server dále tyto streamy zaˇsifruje a pos´ılá klientovi. Je d˚ uleˇzité si uvˇedomit, ˇze klientovi pos´ılá vˇzdy maximálnˇe jeden stream.

Klient pˇrij´ımá stream na pˇredem známém portu. Tento stream deˇsifruje a pos´ılá ho na dalˇs´ı port, kde poslouchá program, kter´ y je urˇcen pro pˇrehráván´ı streamu ffplay.exe (viz kap. 4.3.5). Kromˇe zobrazován´ı streamu, m˚ uˇze klient pos´ılat deˇsifrovan´ y stream jeˇstˇe na jeden port, na kterém poslouchá ffmpeg.exe, kter´ y pˇrijat´ y stream dekóduje a ukládá do souboru.

Kromˇe této komunikace, kde server pos´ılá stream a která je jednosmˇerná (stream je pos´ılán pouze ze serveru klientovi), je zde jeˇstˇe obousmˇerná komunikace mezi serverem a klientem. Na obrázku je znázornˇena nejspodnˇejˇs´ı ˇca´rou, která má na obou konc´ıch ˇsipky. Tato komunikace je téˇz ˇsifrovaná a pouˇz´ıvá se k v´ ymˇenˇe komunikaˇcn´ıch zpráv mezi servererm a klientem. Tyto zprávy jsou napˇr´ıklad ˇzádosti o zas´ılán´ı streamu (klient ˇza´dá), pˇrihláˇsen´ı na server (pos´ılá klient) atd.

9


Zabezpeˇcen´ı

Obr. 3.1: Schématick´ y obrázek fungován´ı aplikace. Celá aplikace byla vytvoˇrena v programovac´ım jazyce C++. Pˇrestoˇze bude aplikace vyv´ıjena pod systémem Windows 7 s pˇrekladaˇcem GCC (MinGW), bude j´ı moˇzné pˇreloˇzit i pod systémy GNU/Linux.

3.2

Zabezpeˇ cen´ı

Jak bylo uvedeno v´ yˇse, jeden z hlavn´ıch problém˚ u dneˇsn´ıch ch˚ uviˇcek je to, ˇze pˇrenos dat mezi pˇrij´ımac´ım a vys´ılac´ım zaˇr´ızen´ım nen´ı nijak zabezpeˇcen´ y. Kromˇe toho, ˇze nˇekdo uslyˇs´ı breˇc´ıc´ı d´ıtˇe, jsou zde mnohem závaˇznˇejˇs´ı bezpeˇcnostn´ı rizika, která se objevila s nástupem video ch˚ uviˇcek. Pokud by se u ´toˇcn´ıkovi povedlo odchytávat obraz a zvuk z dˇetské ch˚ uviˇcky, tak se dostává k velice citliv´ ym informac´ım v podobˇe vybaven´ı domu, osobn´ıch informac´ı ˇclen˚ u domácnosti, ˇcasov´ ych rozvrh˚ u, kdy kdo bude doma atd. Netˇreba dodávat, jak by s takov´ ymi informacemi bylo moˇzné naloˇzit.

Abychom minimalizovali tato rizika, bude nutné zabezpeˇcit aplikaci na nˇekolika u ´rovn´ıch. Prvn´ım krokem by mˇelo b´ yt omezen´ı klient˚ u, kteˇr´ı se na server mohou 10


Zabezpeˇcen´ı

pˇripojit. To lze ˇreˇsit zaveden´ım registrace klient˚ u viz kap. 3.2.1. Dalˇs´ım krokem je ovˇeˇren´ı klient˚ u, kteˇr´ı se chtˇej´ı na server pˇrihlásit a vyuˇz´ıvat jeho sluˇzby. Bude tedy nutné provádˇet autentizaci klient˚ u viz kap. 3.2.2. Posledn´ım neménˇe d˚ uleˇzit´ ym krokem je samotné ˇsifrován´ı pˇrenáˇsen´ ych dat viz kap. 3.2.3 .

3.2.1

Registrace

Prvn´ı krok v sérii zabezpeˇcovac´ıch mechanism˚ u pˇredstavuje registrace. Odbˇer streamu klienty ze serveru mus´ı b´ yt hl´ıdán, aby nemohlo doj´ıt k tomu, ˇze stream bude odeb´ırat kdokoliv. Bude tedy nutné zavést ovˇeˇrovac´ı mechanismus (viz kap. 3.2.2), kter´ y klienta ovˇeˇr´ı a pokud bude klienta znát, tak mu zpˇr´ıstupn´ı dané sluˇzby. To znamená, ˇze na stranˇe serveru mus´ı existovat seznam registrovan´ ych klient˚ u, aby bylo proti ˇcemu ovˇeˇrovat. Moˇzné alternativy, co a proˇc (ne)ukládat na stranˇe serveru, budou popsány v kapitole 3.2.2. Nyn´ı se budeme zab´ yvat pouze t´ım, jak jednotlivé klienty na serveru registrovat.

Jednou z moˇznost´ı by bylo, implementovat registraci na stranˇe klienta. To znamená, ˇze klient, kterého by server neznal a kter´ y by se tud´ıˇz nemohl pˇrihlásit k odbˇeru ˇza´dného streamu, by se nejdˇr´ıve z programu registroval, a pak by se z toho samého programu jiˇz mohl pˇrihlásit. To by vˇsak umoˇzn ˇovalo registraci komukoliv, a to je právˇe to, ˇcemu se snaˇz´ıme vyhnout. Aby bylo moˇzné pouˇz´ıvat tento mechanismus, museli by klienti pˇri registraci prokazovat, ˇze to jsou legáln´ı uˇzivatelé aplikace. To by bylo moˇzné udˇelat napˇr´ıklad pomoc´ı certifikát˚ u. Klient by spoleˇcnˇe s poˇzadavkem registrace pos´ılal i sv˚ uj certifikát. Server by si pak mohl kontrolovat, jac´ı klienti ˇza´daj´ı o registraci.

Nab´ız´ı se i opaˇcná moˇznost, tedy soustˇredit veˇskeré registrace nov´ ych klient˚ u na server. Klientská aplikace by pak provedla jen pˇrihláˇsen´ı k serveru a následnˇe by uˇz mohla pˇrehrávat vyˇza´dan´ y stream. Pohodlné a pˇrehledné pˇridáván´ı nov´ ych klient˚ u by umoˇzn ˇovalo webové rozhran´ı serveru. Webové rozhran´ı by se dalo vyuˇz´ıt nejen k registraci nov´ ych klient˚ u, ale i ke správˇe serveru a nastaven´ı stream˚ u (viz 3.4). Kv˚ uli ˇsirˇs´ım moˇznostem vyuˇzit´ı bylo webové rozhran´ı zvoleno jako lepˇs´ı ˇreˇsen´ı pro registraci klient˚ u.

I u tohoto ˇreˇsen´ı mus´ı doj´ıt k autentizaci uˇzivatele, kter´ y se pˇres webov´ y prohl´ıˇzeˇc snaˇz´ı registrovat nové uˇzivatelské u ´daje. To je moˇzné udˇelat tak, ˇze webové rozhran´ı bude opatˇreno heslem. Nikdo jin´ y, neˇz ten, kdo heslo spolu s aplikac´ı vlastn´ı, nemá 11


Zabezpeˇcen´ı

pˇr´ıstup. Vzhledem k pˇrenosu citliv´ ych u ´daj˚ u v podobˇe nového uˇzivatelského jména a hesla je nutné komunikaci, která prob´ıhá mezi serverem a prohl´ıˇzeˇcem, ˇsifrovat. Toho lze dosáhnout pomoc´ı protokolu HTTPS.

Protokol HTTPS Protokol HTTPS (Hypertext Transfer Protocol Secure) je s´ıt’ov´ y protokol z aplikaˇcn´ı vrstvy modelu ISO/OSI. Vycház´ı z protokolu HTTP (Hypertext Transfer Protocol), kter´ y je urˇcen pro pˇrenos hypertextov´ ych dokument˚ u. Oproti nˇemu ale nav´ıc dokáˇze ovˇeˇrit komunikuj´ıc´ı protistrany a ˇsifrovat komunikaci pomoc´ı SSL nebo TLS protokolu (dále jen SSL). SSL k zajiˇstˇen´ı bezpeˇcnosti pouˇz´ıvá jak symetrickou, tak asymetrickou ˇsifru a certifikáty [17]. Neˇz je moˇzné samotné ˇsifrován´ı komunikace, je nejdˇr´ıve nutné provést takzvan´ y handshake.

Handshake je mnoˇzina u ´kon˚ u, které mus´ı server a klient podstoupit, neˇz si mohou pos´ılat zaˇsifrovaná data. C´ılem handshaku je domluva na hlavn´ım sd´ıleném tajemstv´ı, které je pouˇzito pro v´ ypoˇcet symetrick´ ych kl´ıˇc˚ u. Prvn´ı pos´ılané zprávy mezi klientem a serverem jsou hello zprávy. D´ıky tˇemto zprávám si komunikuj´ıc´ı protistrany vymˇen´ı informace o tom, kdo pouˇz´ıvá jakou verzi SSL, jaké ˇsifrovac´ı algoritmy atd. V této fázi pos´ılá server sv˚ uj certifikát, kter´ y si klient ovˇeˇr´ı. Dále pak, podle typu vybraného ˇsifrovac´ıho algoritmu, dojde k pˇreposlán´ı poˇca´teˇcn´ıho tajemstv´ı, které je ˇsifrované veˇrejn´ ym kl´ıˇcem serveru a pouˇz´ıvá se ke generován´ı hlavn´ıho tajemstv´ı. Na konci handshaku jsou z tohoto hlavn´ıho tajemstv´ı vygenerovány relaˇcn´ı kl´ıˇce pro ˇsifrován´ı komunikace. Proces autentizace serveru pomoc´ı SSL je vidˇet na obr. 3.2. [17]

Obr. 3.2: Autentizace serveru pomoc´ı SSL. [17] 12


Zabezpeˇcen´ı

Certifik´ at Aby bylo moˇzné pouˇz´ıt HTTPS, bude nutné z´ıskat certifikát pro server. Certifikát je dokument digitálnˇe podepsan´ y certifikaˇcn´ı autoritou. Certifikát obsahuje kromˇe u ´daj˚ u o svém drˇziteli a o dobˇe platnosti i veˇrejn´ y kl´ıˇc majitele [17]. Existuj´ı dva zp˚ usoby, jak z´ıskat certifikát. T´ım prvn´ım je zaˇza´dán´ı o certifikát pˇr´ısluˇsnou d˚ uvˇeryhodnou certifikaˇcn´ı autoritu, která certifikát za poplatek na urˇcitou dobu vydá. Druhá moˇznost spoˇc´ıvá ve vygenerován´ı takzvaného self-signed certifikátu. Jak uˇz název napov´ıdá, tento certifikát nen´ı podepsán d˚ uvˇeryhodnou autoritou, ale pouze t´ım, kdo ho vygeneroval.

Takto podepsan´ y certifikát samozˇrejmˇe nen´ı d˚ uvˇeryhodn´ y a je pouze na uˇzivateli, zda ho za nˇej oznaˇc´ı. Ned˚ uvˇeryhodnost se ve webov´ ych prohl´ıˇzeˇc´ıch projevuje varován´ım, které je podobné tomu na obr. 3.3.

Obr. 3.3: Varován´ı pˇri pouˇzit´ı ned˚ uvˇeryhodného certifikátu. Pro naˇse u ´ˇcely postaˇc´ı self-signed certifikát, jelikoˇz budeme vˇedˇet, co schvalujeme. Nav´ıc je i moˇznost dan´ y certifikát do poˇc´ıtaˇce nainstalovat, a t´ım se vyhnout varovnému hláˇsen´ı.

13


3.2.2

Zabezpeˇcen´ı

Pˇ rihl´ aˇ sen´ı

Dalˇs´ım krokem v zabezpeˇcen´ı je pˇrihlaˇsován´ı registrovan´ ych uˇzivatel˚ u z klientské aplikace. Aby uˇzivatel mohl sledovat stream, mus´ı nejdˇr´ıve prokázat, o koho se jedná. Toho uˇzivatel dosáhne zadán´ım sv´ ych pˇrihlaˇsovac´ıch u ´daj˚ u, které se na serveru ovˇeˇr´ı. Jedná se o u ´daje, které se ukládaj´ı pˇri registraci pˇres webové rozhran´ı. Pokud server dané u ´daje shledá správn´ ymi, umoˇzn´ı danému klientovi odeb´ırat stream. Dále si pop´ıˇseme moˇznosti ukládán´ı citliv´ ych u ´daj˚ u na serveru a vybranou metodu pro pˇrihlaˇsovac´ı proces.

Ukl´ ad´ an´ı pˇ rihlaˇ sovac´ıch u ´ daj˚ u na stranˇ e serveru Aby server vˇedˇel, komu m˚ uˇze a nem˚ uˇze stream pos´ılat, mus´ı m´ıt list nebo seznam uˇzivatel˚ u s jejich pˇrihlaˇsovac´ımi u ´daji. V principu existuj´ı 3 metody [17], jak lze uˇzivatele autentizovat: ˇ • Rekni, co v´ıˇs (heslo) • Ukaˇz, co máˇs (platebn´ı karta) • Ukaˇz, co jsi (otisk prstu) Prvn´ı metoda je jednoduchá a spoˇc´ıvá v ovˇeˇren´ı uˇzivatele na základˇe nˇejakého tajemstv´ı. U této metody se poˇc´ıtá s t´ım, ˇze tajemstv´ı nezná nikdo jin´ y neˇz uˇzivatel, a tud´ıˇz se za nˇej nem˚ uˇze nikdo jin´ y vydávat. Pˇredpokládá se, ˇze s´ıt’ mezi serverem a klientem je náchylná na odposlechy, a nen´ı zde ˇza´dná tˇret´ı d˚ uvˇeryhodná strana [37]. V´ yhodou této metody je jednoduchá implementace a nev´ yhoda je v tom, ˇze lidé si vol´ı pˇr´ıliˇs krátká a jednoduchá hesla, která neb´ yvá tˇeˇzké, pomoc´ı slovn´ıkov´ ych u ´tok˚ u, prolomit. [17]

Druhá metoda je zaloˇzená na ovˇeˇrován´ı podle toho, co uˇzivatel vlastn´ı. Nejˇcastˇeji to jsou r˚ uzné typy karet (OTP, Smart, platebn´ı karty). Nˇekteré generuj´ı nové heslo pokaˇzdé, kdyˇz se uˇzivatel chce pˇrihlásit (OTP karty), jiné zas umoˇzn ˇuj´ı zniˇcen´ı uloˇzen´ ych u ´daj˚ u v pˇr´ıpadˇe, ˇze se k nim nˇekdo snaˇz´ı dostat násilnou cestou (Smart karty). Tento zp˚ usob ovˇeˇrován´ı nen´ı pro naˇsi aplikaci pˇr´ıliˇs vhodn´ y. [17]

14


Zabezpeˇcen´ı

Posledn´ım a nejsloˇzitˇejˇs´ım typem, co se implementace t´ yˇce, je ovˇeˇrován´ı uˇzivatele na základˇe biometrick´ ych u ´daj˚ u. Pouˇz´ıvá otisk prstu nebo sken rohovky. Moˇzné je i uˇzit´ı podpisu uˇzivatele, kde se monitoruje tlak vyv´ıjen´ y pˇri psan´ı a ˇcasován´ı jednotliv´ ych smyˇcek. Nev´ yhodou b´ yvá ˇcasté odm´ıtnut´ı pravého uˇzivatele a pˇrijet´ı u ´toˇcn´ıka. Nev´ yhoda u biometrické autentizace je správa kl´ıˇc˚ u. Ty jsou generovány z u ´daj˚ u uˇzivatele (otisku prstu, skenu rohovky, atd.) a jsou pro daného uˇzivatel unikátn´ı. Pokud nˇekdo toto ukradne, zkop´ıruje nebo jinak z´ıská, p˚ uvodn´ı uˇzivatel si nem˚ uˇze nechat vygenerovat novou rohovku, jako by to bylo moˇzné v pˇr´ıpadˇe ztráty hesla. [17]

Z v´ yˇse uveden´ ych metod se pro naˇse u ´ˇcely jako nejlepˇs´ı jev´ı metoda prvn´ı, tedy ovˇeˇrován´ı uˇzivatele na základˇe toho, co zná. Tato metoda má nˇekolik u ´rovn´ı zabezpeˇcen´ı. Tou prvn´ı, dalo by se ˇr´ıci nulovou, je uloˇzen´ı páru uˇzivatelské jméno - heslo na stranˇe serveru v prostém textu. To pˇredstavuje obrovské bezpeˇcnost´ı riziko. V pˇr´ıpadˇe, ˇze by se na server nˇekdo dostal a ukradl takov´ y seznam uˇzivatel˚ u, má pˇr´ım´ y pˇr´ıstup ke vˇsem uˇzivatelsk´ ym u ´ˇct˚ um.

Lepˇs´ı ˇreˇsen´ı pˇredstavuje pouˇzit´ı hashovac´ı funkce, která se pouˇzije na hesla. Na stranˇe serveru pak nejsou uloˇzena hesla, ale jen jejich hashe. Hash je jednocestná funkce, tedy ze zahashovan´ ych hesel bychom nemˇeli b´ yt schopni z´ıskat p˚ uvodn´ı text. O tom, co je hashován´ı a jaké by se mˇely pouˇz´ıvat hashovac´ı funkce, si pov´ıme v kap. 3.2.2. Kdyˇz uˇzivatel zadá své pˇrihlaˇsovac´ı u ´daje, tak se z jeho hesla vytvoˇr´ı hash a porovná s t´ım, jenˇz je uloˇzen v databázi serveru. Pokud je stejn´ y, uˇzivatel je autentizován.

Pokud bychom chtˇeli u ´toˇcn´ıkovi napaden´ı zt´ıˇzit, je moˇzné pouˇz´ıt takzvané solen´ı (salting). Solen´ı je proces, kdy se do hashovaného hesla pˇridává dalˇs´ı informace [17]. Tato informace se naz´ yvá s˚ ul (salt) a jedná se o náhodné ˇc´ıslo, které mus´ı b´ yt uloˇzeno spolu s hashem hesla na stranˇe serveru. Aby u ´toˇcn´ık odhalil heslo pˇri pouˇzit´ı hash˚ u, musel by vytvoˇrit slovn´ık, ve kterém by byly vˇsechny moˇzné kombinace znak˚ u. Kaˇzdou jednotlivou kombinaci by musel hashovat a porovnávat se z´ıskan´ ym heslem. Pˇri velikosti slovn´ıku n slov by u ´toˇcn´ık musel provést n hashován´ı. Pokud se pˇri hashován´ı hesla pouˇzije jeˇstˇe s˚ ul, která je dlouhá k bit˚ u, pak uˇz u ´toˇcn´ık mus´ı provést 2k n hash˚ u [17]. Omezen´ı této metody je v tom, ˇze nen´ı stavˇená na offline slovn´ıkové u ´toky [17].

Posledn´ı u ´rovn´ı zabezpeˇcen´ı ukládan´ ych u ´daj˚ u by bylo pouˇzit´ı ˇsifrován´ı. Jak uˇzivatelská jména, tak hesla v jakémkoliv formátu, by byla ˇsifrována pouˇzit´ım napˇr´ıklad symetrické ˇsifry. 15


Zabezpeˇcen´ı

Vzhledem k tomu, ˇze poˇcet potenciáln´ıch uˇzivatel˚ u, kteˇr´ı by se na server pˇripojovali, je velice mal´ y (do 10), nebyla pro ukládán´ı uˇzivatelsk´ ych u ´daj˚ u zvolena databáze, ale pouze soubor. Databáze by nenaˇsla uplatnˇen´ı ani v jiné ˇca´sti aplikace. Podle v´ yˇse uveden´ ych u ´rovn´ı ukládán´ı hesla, byly zvoleny posledn´ı dvˇe, tzn. do souboru budou ukládány uˇzivatelská jména spolu s hashem a sol´ı a soubor bude ˇsifrován symetrickou ˇsifrou AES (viz kap. 3.2.3), kde kl´ıˇc pro tuto ˇsifru je nadefinován jako promˇenná.

Autentizaˇ cn´ı protokol [37] Jedna vˇec je, jak uloˇzit a porovnávat u ´daje od klienta na stranˇe serveru, a druhá, jak je tam dostat. Za t´ımto u ´ˇcelem vznikl jiˇz v roce 1997 protokol SRP (Secure remote password ptotocol), kter´ y slouˇz´ı k autentizaci pomoc´ı hesla a k v´ ymˇenˇe kl´ıˇc˚ u. Tento protokol patˇr´ı do skupiny AKE (Asymmetric key exchange) a jeho hlavn´ı funkc´ı je v´ ymˇena kl´ıˇc˚ u a jejich vyuˇzit´ı k ovˇeˇren´ı, ˇze obˇe strany znaj´ı heslo. Na rozd´ıl od EKE (Encrypted key exchange) neˇsifruje pˇrenáˇsené zprávy, ale m´ısto toho pouˇz´ıvá pˇreddefinované matematické vztahy ke slouˇcen´ı náhodn´ ych hodnot a hesla. Dalˇs´ı rozd´ıl od EKE pˇredstavuje to, ˇze se nepos´ılá pˇr´ımo heslo, ale pouze jeho hash (v p˚ uvodn´ım textu oznaˇcovan´ y jako verifier ). Klientovo heslo tak nikdy neopust´ı systém a nedostane se do s´ıtˇe. Samotn´ y hash hesla vˇsak k imitován´ı uˇzivatele nestaˇc´ı, p˚ uvodn´ı heslo je stále tˇreba.

Veˇskeré poˇcetn´ı operace jsou provádˇeny v koneˇcné mnoˇzinˇe GF (n). Tzn. velké prvoˇc´ıslo n je vybráno pˇredem a veˇskeré sˇc´ıtán´ı, násoben´ı a umocˇ nován´ı je modifikováno modulo n. Vˇsechny vstupn´ı i v´ ystupn´ı parametry jsou tak ˇc´ısla na intervalu <0, n-1>. Dále bude na pˇr´ıkladu popsán autentizaˇcn´ı proces. ˇ Reknˇ eme, ˇze máme dvˇe osoby, Alici a Boba, a budeme cht´ıt Alici pˇrihlásit u Boba. Nejdˇr´ıve mus´ıme k Bobovi uloˇzit hash Alicina hesla (verifier ) a náhodnˇe vybranou s˚ ul. Hash v se spoˇc´ıtá jako: x = H(s, P ) v = gx x je zahozeno, jelikoˇz odpov´ıdá otevˇrené formˇe hesla P. U AKE protokol˚ u se obvykle pouˇz´ıvá i heslo a veˇrejn´ y kl´ıˇc na stranˇe Boba, kter´ y by schraˇ novala Alice. U protokolu SRP dojde ke vzájemnému ovˇeˇren´ı uˇz jen t´ım, ˇze Bob bezpeˇcnˇe uchovává 16


Zabezpeˇcen´ı

Alicin verifier. To zjednoduˇsuje cel´ y protokol, protoˇze Alice si nemus´ı pamatovat Bob˚ uv kl´ıˇc. V tabulce 3.1 je uveden postup vzájemné autentizace Boba a Alice krok za krokem. Alice 1. 2. 3.

Bob C

x = H(s, P) A = ga

4. 5. S = (B − g x )a+ux 6. K = H(S) 7. M1 = (A, B, K) 8. ovˇeˇren´ı M2

− → s ← − A − →

(lookup s,v )

B, u

B = v + gb S = (Av u )b K = H(S) ovˇeˇren´ı M1 M2 = H(A, M1 , K)

←−−

M

1 −−→ M2 ←−−

Tab. 3.1: Postup autentizace SRP protokolu [37].

1. Alice poˇsle Bobovi svoje uˇzivatelské jméno (napˇr. alice). 2. Bob vyhledá vstupn´ı u ´daje o Alici a stáhne si jej´ı verifier a s˚ ul. S˚ ul s poˇsle Alici a ta si z jej´ı pomoc´ı a skuteˇcného hesla spoˇc´ıtá privátn´ı kl´ıˇc x. 3. Alice náhodnˇe vygeneruje ˇc´ıslo a, pro nˇejˇz plat´ı: 1 < a < n. Pak spoˇc´ıtá doˇcasn´ y veˇrejn´ y kl´ıˇc A = g a a poˇsle ho Bobovi. 4. Bob vygeneruje náhodné ˇc´ıslo b, kde plat´ı 1 < b < n a spoˇc´ıtá sv˚ uj doˇcasn´ y veˇrejn´ y kl´ıˇc B = v + g b . Tento kl´ıˇc poˇsle zpˇet Alici spolu s náhodnˇe vygenerovan´ ym parametrem u. 5. Oba si nyn´ı spoˇc´ıtaj´ı S = g ab+bux pomoc´ı hodnot, které má kaˇzd´ y dostupné. Pokud Alicino heslo, které zadala v kroku 2, je shodné s origináln´ım heslem, které se pouˇzilo na generován´ı hashe, pak se obˇe hodnoty S shoduj´ı. 6. Obˇe strany si pomoc´ı S spoˇc´ıtaj´ı relaˇcn´ı kl´ıˇc (session). 7. Alice poˇsle Bobovi M1 jako d˚ ukaz, ˇze má správn´ y relaˇcn´ı kl´ıˇc. Bob si sám spoˇc´ıtá M1 a porovná je. 8. Bob poˇsle Alici M2 jako d˚ ukaz, ˇze má správn´ y relaˇcn´ı kl´ıˇc. Alice také ovˇeˇr´ı M2 a pˇrijme ho jen, pokud se shoduje s jej´ım v´ ypoˇctem.

17


Zabezpeˇcen´ı

V´ ysledn´ y relaˇcn´ı kl´ıˇc je pˇri kaˇzdém pˇrihláˇsen´ı jin´ y. Dalˇs´ı podrobnosti, jako napˇr. jakou roli hraje parametr u, se lze doˇc´ıst v [37].

V roce 2002 vyˇsla nová verze protokolu SRP-6. V této verzi protokolu, kter´ y odolává jak aktivn´ım, tak pasivn´ım s´ıt’ov´ ym u ´tok˚ um i pˇres pouˇzit´ı krátk´ ych dobˇre zapamatovateln´ ych hesel, byly odstranˇeny nˇekteré menˇs´ı bezpeˇcnost´ı nedostatky, která p˚ uvodn´ı verze skr´ yvala. Jeden takov´ y nedostatek u ´toˇcn´ık˚ um umoˇzn ˇoval uskuteˇcnit a ovˇeˇrit 2 pokusy o uhádnut´ı hesla pˇri napodoben´ı pˇrihláˇsen´ı [36]. Tato vlastnost nepˇredstavuje závaˇznou bezpeˇcnost´ı hrozbu, jelikoˇz kaˇzd´ y pokus o uhádnut´ı má za následek detekovatelné selhán´ı na obou stranách a stále by bylo potˇreba nereálného poˇctu on-line pokus˚ u, a to i v pˇr´ıpadˇe, ˇze by se toto ˇc´ıslo sn´ıˇzilo na polovinu [36]. Jednoduchou zmˇenou protokolu popsanou v [36] se u ´toku Two-for-one, jak je v originálu naz´ yván, dá zabránit.

Tento protokol se jev´ı jako velice u ´ˇcinn´ y nástroj urˇcen´ y pro bezpeˇcnou autentizaci bez moˇznosti napadan´ı u ´toˇcn´ıkem nebo odposlechu hesla. Jedinou vadu pˇredstavuje to, ˇze jiˇz poˇc´ıtá s t´ım, ˇze na stranˇe serveru jsou pˇrihlaˇsovac´ı u ´daje uloˇzeny, a nezab´ yvá se jejich bezpeˇcn´ ym pˇrenesen´ım od klienta na server. Naˇstˇest´ı pro nás je tento problém je uˇz vyˇreˇsen v kapitole 3.2.1, a tak je moˇzné protokol SRP-6 bez problému pouˇz´ıt.

Hashovac´ı funkce Hashovac´ı funkce mapuje dlouh´ y ˇretˇezec na kratˇs´ı a bˇeˇznˇe se pouˇz´ıvá v hashovac´ıch tabulkách, kde má za u ´kol urychlit pˇr´ıstup k jednotliv´ ym poloˇzkám. Bezpeˇcná ˇsifrovac´ı funkce má, oproti té bˇeˇznˇe pouˇz´ıvané, jej´ımˇz hlavn´ım u ´kolem je rovnomˇerné rozdˇelen´ı dat, nˇekolik vlastnost´ı nav´ıc [17]: • Nemˇela by spotˇrebovávat pˇr´ıliˇs mnoho v´ ypoˇcetn´ıho ˇcasu pro v´ ypoˇcet hashe ani pro relativnˇe dlouhé ˇretˇezce - efektivnost. • Z hashe by nemˇelo b´ yt v´ ypoˇcetnˇe moˇzné z´ıskat p˚ uvodn´ı ˇretˇezec - jednocestná funkce. • Pro kaˇzdé dvˇe rozd´ılné zprávy neexistuje stejn´ y hash - bezkolizn´ı funkce. Dˇr´ıve se pouˇz´ıvala hashovac´ı funkce MD5. Tato funkce je vˇsak náchylná na kolizn´ı u ´toky. Prvn´ı takov´ y byl popsán jiˇz v roce 2004 (viz [34]). Od té doby doˇslo k 18


Zabezpeˇcen´ı

vylepˇs´ı MD5, ale zároveˇ n i pˇribyly dalˇs´ı algoritmy (viz [27]) na vyhledáván´ı koliz´ı a MD5 se jiˇz nepovaˇzuje za bezpeˇcnou hashovac´ı funkci.

M´ısto MD5 se dnes pouˇz´ıvá SHA-256 nebo SHA-512. Které vycház´ı ze svého pˇredch˚ udce, SHA-1, ale produkuj´ı delˇs´ı v´ ystupn´ı hashe (256 a 512 bit˚ u). [17]

Multicast [16] Aby se klient dokázal pˇripojit na server, tak mus´ı znát IP adresu serveru a jeho port. Pro snadnˇejˇs´ı pouˇzit´ı je moˇznost implementovat vyhledáván´ı serveru pomoc´ı doménového jména. Jména si lidé zapamatuj´ı snáze neˇz IP adresy. Toho je moˇzné dosáhnout pomoc´ı sluˇzby, která se jmenuje Multicast DNS (dále mDNS).

mDNS se pouˇz´ıvá k vytvoˇren´ı DNS záznam˚ u v s´ıti (privátn´ı), kde ˇza´dn´ y DNS server nen´ı. Pouˇz´ıvá k tomu dobˇre známé funkce a operace z DNS (Domain Name System) rozhran´ı. M´ısto unicastu se vˇsak pouˇz´ıvá multicast. Kaˇzd´ y poˇc´ıtaˇc v s´ıti má svoj´ı tabulku záznam˚ u a mus´ı b´ yt pˇripojen do mDNS skupiny. Tato skupina pouˇz´ıvá IP adresu 224.0.0.251 a port 5353. Pokud potˇrebuje klient znát IP adresu stroje, poˇsle této skupinˇe zprávu se jménem. Zpátky mu odpov´ı pouze ten, kdo toto jméno zná, a ve zprávˇe poˇsle i pˇr´ısluˇsnou IP adresu.

Formát jmen, kter´ y se pro mDNS pouˇz´ıvá, je ve tvaru vlastni-nazev-domeny.local. Kde sufix .local. urˇcuje lokalizaci jména na lokáln´ı s´ıt’.

3.2.3

Komunikace

Posledn´ım krokem v sérii zabezpeˇcen´ı je ˇsifrován´ı navázaného spojen´ı. Nejdˇr´ıve ale mus´ıme urˇcit, jaké typy komunikace budou v naˇs´ı aplikaci prob´ıhat. Tradiˇcn´ı pojet´ı architektury klient - server, kdy server pouze poslouchá, a aˇz k nˇemu doraz´ı zpráva, tak na n´ı odpov´ı, je pro naˇse u ´ˇcely nedostaˇcuj´ıc´ı. Je to z toho d˚ uvodu, ˇze i server bude potˇrebovat pos´ılat zprávy nezávisle na tom, jestli zrovna nˇekomu odpov´ıdá ˇci nikoliv. Mezi tyto zprávy patˇr´ı upozornˇen´ı, zda se zmˇenil obraz nebo hlasitost. Komunikace mezi serverem a klientem bude tedy obousmˇerná ve smyslu, ˇze jak jeden, tak druh´ y budou moct poslat zprávu kdykoliv. S t´ım, ˇze na zprávy od klienta bude server odpov´ıdat, ale obrácenˇe nikoliv. 19


Zabezpeˇcen´ı

Vedle této obousmˇerné komunikaˇcn´ı linky bude mezi serverem a klientem existovat jeˇstˇe jedna jednocestná linka. Touto linkou se budou pos´ılat multimediáln´ı data ze serveru klientovi. Klient bude tato data jen pˇrij´ımat a ˇza´dn´ ym zp˚ usobem je nebude potvrzovat.

Na realizaci tˇechto komunikaˇcn´ıch linek máme 2 moˇznosti, co se t´ yˇce pouˇzit´ı transportn´ıch protokol˚ u (TCP, UDP).

Komunikaˇ cn´ı protokoly Protokol TCP (Transmision Control Protocol) poskytuje spojované sluˇzby. To znamená, ˇze mezi obˇema konci spojen´ı vytváˇr´ı na ˇcas virtuáln´ı okruh, kter´ y je plnˇe duplexn´ı. Pokud se data ztrat´ı nebo poˇskod´ı, jsou vyˇzádána znovu a jejich integrita je zabezpeˇcena kontroln´ım souˇctem. Aplikace se tedy jiˇz nemus´ı starat o to, jestli se nˇejaká data ztratila. Protokol TCP neobsahuje ˇzádnou ochranu proti modifikac´ım zpráv a jejich kontroln´ıch souˇct˚ u. [9]

Aplikace vyuˇz´ıvaj´ıc´ı TCP protokol pro komunikaci má tu vlastnost, ˇze pokud se spojen´ı pˇreruˇs´ı, tak funkce, která slouˇz´ı pro pˇr´ıjem dat (napˇr. recv, read...), skonˇc´ı chybou. T´ımto se dá detekovat, ˇze se klient/server odpojil nebo nastalo pˇreruˇsen´ı spojen´ı. Této vlastnosti a dalˇs´ıch jmenovan´ ych, které protokol TCP poskytuje, lze vyuˇz´ıt pˇri vytváˇren´ı prvn´ıho komunikaˇcn´ıho kanálu, kter´ y slouˇz´ı pro pˇrenos zpráv mezi serverem a klientem. V pˇr´ıpadˇe, ˇze se klient neoˇcekávanˇe odpoj´ı, server to zjist´ı a m˚ uˇze se podle toho zachovat (vymazán´ı klientov´ ych u ´daj˚ u jako jeho id nebo uloˇzeného nastaven´ı ohlednˇe zas´ılán´ı zpráv o detekci zmˇen atd.). To samé plat´ı i pro klienta, kter´ y d´ıky tomu nebude do nekoneˇcna ˇcekat na odpovˇed’ serveru. V pˇr´ıpadˇe, ˇze by TCP protokol touto vlastnost´ı nedisponoval, pak by bylo nutné implementovat cyklické dotazován´ı, jestli aplikace jeˇstˇe ˇzije.

Protokol UDP (User Datagram Protocol) poskytuje, na rozd´ıl od TCP, nespojované sluˇzby. To znamená, ˇze nenavazuje spojen´ı a nestará se o to, jestli odeslan´ y datagram pˇr´ıjemci dojde nebo ne [9]. UDP protokol je moˇzné pouˇz´ıt pro pˇrenos streamu, jednak proto, ˇze pokud se ztrat´ı jeden datagram s video rámcem, tak na v´ ysledném obrazu to vˇetˇsinou nen´ı pozorovatelné, a také proto, ˇze právˇe neobsahuje potvrzovac´ı mechanismus. Video rámec, kter´ y obsahuje jeden obrázek a kter´ y pˇrijde

20


Zabezpeˇcen´ı

mimo své poˇrad´ı (pozdˇe) je stejnˇe zahozen, a proto nemá smysl ho za kaˇzdou cenu vyˇzadovat.

Vzhledem k tomu, ˇze ze serveru je potˇreba pˇrenáˇset stream klient˚ um, tak i protokol UDP zde najde své uplatnˇen´ı. Dalˇs´ı moˇznosti pˇrenáˇsen´ı stream˚ u budou popsány v kap. 3.3.4.

Nyn´ı se dostáváme k moˇznostem ˇsifrován´ı pˇrenosu. Pop´ıˇseme nˇekolik blokov´ ych ˇsifer, které je moˇzné pro ˇsifrován´ı komunikace pouˇz´ıt. Pro ˇsifrován´ı obou kanál˚ u bude vybrána stejná ˇsifra. Vzhledem k velkému mnoˇzstv´ı dat, která se pˇrenáˇs´ı po streamovac´ım kanálu, je lepˇs´ı volbou symetrická ˇsifra. Asymetrické ˇsifry se v praxi nedaj´ı pouˇz´ıt pro velké mnoˇzstv´ı dat, nebot’ jsou pˇr´ıliˇs pomalé.

DES [17] Prvn´ı ˇsifra, kterou zm´ın´ıme, je ˇsifra DES (Data Encryption Standard). Data jsou ˇsifrována po 64 bitov´ ych bloc´ıch pomoc´ı 64 bitového kl´ıˇce. Respektive se pouˇz´ıvá 56 bitov´ y kl´ıˇc, jelikoˇz 8 bit˚ u se pouˇz´ıvá pro detekci poˇskozen´ı kl´ıˇce. Dˇr´ıv se DES pouˇz´ıval ve vˇsech moˇzn´ ych odvˇetv´ıch vˇcetnˇe finanˇcn´ıho. Pak se ji ale podaˇrilo prolomit pomoc´ı hrubé s´ıly, kde u ´toˇcn´ık na zaˇsifrovan´ y text zkouˇsel jeden kl´ıˇc za druh´ ym 56 (existuje ”jen”c moˇznost´ı).

Po prolomen´ı ˇsifry DES byla vytvoˇrena nová ˇsifra, Triple DES. Jak uˇz název napov´ıdá, jedná se o bezpeˇcnˇejˇs´ı verzi p˚ uvodn´ı ˇsifry DES. U této ˇsifry docház´ı k zaˇsifrován´ı dat tˇrikrát a pokaˇzdé lze pouˇz´ıt jin´ y kl´ıˇc. Zpráva se nejdˇr´ıve zaˇsifruje prvn´ım kl´ıˇcem, pak se druh´ ym provede deˇsifrován´ı a tˇret´ım se opˇet zaˇsifruje. Tento zvláˇstn´ı postup se dˇelá kv˚ uli zpˇetné kompatibilitˇe a jednoduˇsˇs´ı moˇznosti pˇrechodu z DES na Triple DES. Oproti p˚ uvodn´ı verzi je tato prakticky tˇrikrát pomalejˇs´ı a i od jej´ıho pouˇz´ıván´ı se ustupuje.

AES ˇ Sifra AES (Advance Encryption Standard) byla vytvoˇrena jako náhrada za prolomenou ˇsifru DES. Oproti dvˇema v´ yˇse zmiˇ novan´ ym je bezpeˇcnˇejˇs´ı a rychlejˇs´ı. Zat´ım nebyla prolomena a uvád´ı se, ˇze super poˇc´ıtaˇc s v´ ypoˇcetn´ım v´ ykonem 10,51 * 1015

21


Zabezpeˇcen´ı

FLOPS1 by pomoc´ı hrubé s´ıly potˇreboval 1,02 * 1018 let na prolomen´ı (na DES by mu staˇcilo 399 sekund) [5]. AES je symetrická ˇsifra, která ˇsifruje data po pevnˇe dan´ ych délkách, a taktéˇz pracuje s délkami kl´ıˇc˚ u 128, 192, 256 bit˚ u [17]. Jiné délky standard nedovoluje.

AES vnitˇrnˇe pracuje s matic´ı, která se naz´ yvá stav (state). Délka vstupn´ıho bloku, v´ ystupn´ıho bloku i stavu je 128 bit˚ u. Stav je pak tvoˇren matic´ı o rozmˇerech 4x4. Na zaˇca´tku ˇsifrován´ı jsou vstupn´ı byty nakop´ırovány do stavové matice. Následnˇe jsou na ni aplikovány ˇsifrovac´ı operace a v´ ysledek je pak zkop´ırován na v´ ystup. Poˇcet cykl˚ u, které se vykonaj´ı bˇehem algoritmu, je dán délkou kl´ıˇce, 128b = 10 kol, 192b = 12 a 256b = 14 kol. Bˇehem kaˇzdého kola se vykonaj´ı následuj´ıc´ı operace [4]: • SubBytes - Jedná se o nelineárn´ı substituci byt˚ u, která se aplikuje na kaˇzd´ y byte zvláˇst’ za pouˇzit´ı substituˇcn´ı tabulky (S-box ) (viz obr. 3.4). • ShiftRow - Spodn´ı 3 ˇra´dky stavové matice jsou posunovány o urˇcit´ y d´ıl doleva. • MixColumn - Lineárn´ı transformace sloupeˇck˚ u stavu. • AddRoundKey - Kaˇzd´ y byte stavu je slouˇcen s kl´ıˇcem cyklu, kter´ y je kaˇzdé kolo jin´ y a kter´ y se derivuje z ˇsifrovac´ıho kl´ıˇce.

Obr. 3.4: Aplikace S-box na kaˇzd´ y byte u ˇsifry AES v SubBytes fázi [28]. V posledn´ım kole se MixColumn vynechává. Pseudokód k pr˚ ubˇehu ˇsifry je na obr. 3.6 [4]. 1

Floating-point Operations per Second - poˇcet operac´ı v plovouc´ı ˇrádové ˇcárce za sekundu

22


Zabezpeˇcen´ı

Obr. 3.5: Posun ˇra´dk˚ u u ˇsifry AES v ShiftRow fázi [26]. M´ıra bezpeˇcnosti AES závis´ı nejen na tom, ˇze ˇsifrovac´ı kl´ıˇc mus´ı b´ yt dostateˇcnˇe náhodn´ y, ale i na tom, jak´ y ˇsifrovac´ı mód se pouˇzije. Módy, které lze pouˇz´ıt, jsou ECB, CBC, CFB a OFB [10].

ECB (Electronic Codebook Mode) mód aplikuje ˇsifru na bloky dat tak, jak jdou za sebou. V tomto módu je moˇzné (de)ˇsifrovat v´ıce blok˚ u paralelnˇe. Problém ale pˇredstavuje to, ˇze urˇcit´ y blok textu bude ˇsifrován pokaˇzdé stejnˇe. To m˚ uˇze zp˚ usobovat opakuj´ıc´ı se sekvence a urˇcitou ˇcitelnost kódu, jako je vidˇet na obr. 3.9 (b).

Bezpeˇcnˇejˇs´ı metoda je CBC (Cipher Block Chaining Mode), která nejdˇr´ıve text XORuje s pˇredchoz´ım zaˇsifrovan´ ym blokem, a aˇz pak ho také zaˇsifruje. D´ıky tomu jsou na sobˇe jednotlivé bloky závislé. Pro u ´plnˇe prvn´ı blok jeˇstˇe neexistuje blok pˇredchoz´ı, a tak se pouˇz´ıvá inicializaˇcn´ı vektor (IV). Tento vektor nemus´ı b´ yt tajn´ y, ale mus´ı b´ yt nepˇredv´ıdateln´ y. Postup ˇsifrován´ı je ukázán na obr. 3.7. Vzhledem k tomu, ˇze bloky jsou na sobˇe závislé, nen´ı moˇzné jejich paraleln´ı (de)ˇsifrován´ı [10]. Metoda CBC je oproti ECB mnohem bezpeˇcnˇejˇs´ı, coˇz je vidˇet i na zaˇsifrován´ı obrázku 3.9 (c). [10]

Metoda CFB (Cipher Feedback Mode) je podobná metodˇe CBC. K ˇsifrován´ı bloku také vyuˇz´ıvá blok pˇredchoz´ı. Metoda pracuje tak, ˇze na zaˇca´tku se vezme 23


Zabezpeˇcen´ı

Obr. 3.6: Pseudokód ˇsifry AES [23] (obr. byl upraven).

ˇ Obr. 3.7: Sifrov´ an´ı AES pomoc´ı metody CBC [30] (obr. byl upraven). inicializaˇcn´ı vektor a ten se zaˇsifruje. Z tohoto zaˇsifrovaného bloku se vezme s nejv´ yznamnˇejˇs´ıch bit˚ u a ty jsou XORovány s origináln´ım textem k zaˇsifrován´ı, t´ım vznikne prvn´ı zaˇsifrovan´ y segment. Z IV se následnˇe vezme b-s nejménˇe v´ yznamn´ ych bit˚ u, spoj´ı se s s prvn´ıho zaˇsifrovaného segmentu a vytvoˇr´ı tak dalˇs´ı vstupn´ı blok. Stejnˇe jako u CBC metody, ani zde nen´ı moˇzné pouˇz´ıt paraleln´ı ˇsifrován´ı, jelikoˇz bloky na sobˇe závis´ı. [10]

Metoda OFB (Output Feedback Mode) pouˇz´ıvá následuj´ıc´ı postup pˇri ˇsifrován´ı: vektor IV je zaˇsifrován a vznikne prvn´ı v´ ystupn´ı blok, kter´ y je XORován s textem k ˇ zaˇsifrován´ı, a t´ım vznikne prvn´ı zaˇsifrovan´ y blok. Sifra je dále aplikována na prvn´ı v´ ystupn´ı blok, a t´ım vznikne druh´ y v´ ystupn´ı blok.

24


Zabezpeˇcen´ı

ˇ Obr. 3.8: Sifrov´ an´ı AES pomoc´ı metody CFB [31] (obr. byl upraven). Druh´ y v´ ystupn´ı blok je XORován s druh´ ym textem k zaˇsifrován´ı atd. Vektor IV mus´ı b´ yt jedineˇcn´ y pro kaˇzd´ y bˇeh (kaˇzdou zprávu) s dan´ ym kl´ıˇcem. [10]

(a) Origin´ aln´ı obr´ azek

(b) Metoda ECB

(c) Metoda CBC

Obr. 3.9: Ukázka pouˇzit´ı ECB a CBC mód˚ u na obrázek [7]. P˚ uvodn´ım zámˇerem bylo pouˇzit´ı kl´ıˇce o délce 512 bit˚ u kv˚ uli vyˇsˇs´ı bezpeˇcnosti. Standard AES vˇsak stále umoˇzn ˇuje pouˇzit´ı maximálnˇe 256 bitového kl´ıˇce. Nakonec byl tedy zvolen kl´ıˇc o délce 256 bit˚ u a metoda CBC, kterou budou ˇsifrována data v obou komunikaˇcn´ıch kanálech. Problém s distribuc´ı symetrick´ ych kl´ıˇc˚ u zde odpadá, jelikoˇz v´ ysledkem autentizaˇcn´ıho procesu protokolu SRP je relaˇcn´ı kl´ıˇc, kter´ y je moˇzné dále pouˇz´ıt k ˇsifrován´ı pomoc´ı AES (viz kap. 4.2.2).

25


3.3

Stream

Stream

Jak uˇz bylo zm´ınˇeno v´ yˇse, server mus´ı umˇet poskytnout dva streamy k odbˇeru. T´ım prvn´ım je audio+video stream, a t´ım druh´ ym pak pouze audio stream. V této kapitole si pˇribl´ıˇz´ıme stream, jeho moˇznosti, co se t´ yˇce formát˚ u audia/videa, a také se pod´ıváme na zp˚ usoby, jak je moˇzné dopravit stream ze serveru klientovi. D˚ uleˇzitou ˇca´st tvoˇr´ı i kapitola o moˇznostech detekce zmˇeny obrazu nebo hlasitosti.

Streamován´ı je technika pouˇz´ıvaj´ıc´ı se pˇredevˇs´ım pro pˇrenos multimediáln´ı informace pˇres internet. Pˇri streamován´ı je moˇzné dan´ y video soubor spustit jiˇz bˇehem stahován´ı. Coˇz je v´ yhodné, ale na druhou stranu to klade vˇetˇs´ı nároky na klienta, kter´ y stream odeb´ırá. Typy streamu jsou obecnˇe dva, prvn´ı je on demand, tedy stream na vyˇza´dán´ı (napˇr. Youtube), a t´ım druh´ ym jsou pˇrenosy v reálném ˇcase, které se budou t´ ykat i naˇs´ı aplikace.

Datové prvky obsaˇzené ve streamu se oznaˇcuj´ı jako rámce (frame). Kaˇzd´ y rámec je dekódován jin´ ym typem CODECu, podle toho, o jak´ y typ rámce se jedná (audio, video). CODEC (coder-decoder) urˇcuje, jak´ ym zp˚ usobem jsou data komprimována a uloˇzena. Komprimovaná data neobsahuj´ı vˇsechny informace jako data p˚ uvodn´ı, kapacitnˇe zab´ıraj´ı mnohem ménˇe m´ısta a jsou d´ıky tomu vhodnˇejˇs´ı pro pˇrenos po s´ıti.

3.3.1

Audio

Audiem budeme dále oznaˇcovat digitáln´ı audio, které se dá z´ıskat pomoc´ı A/D pˇrevodu. A/D pˇrevodem rozum´ıme pˇrevod analogového signálu na digitáln´ı. Audio se skládá z velkého poˇctu vzork˚ u, které pˇredstavuj´ı hodnotu p˚ uvodn´ıho signálu v urˇcitém ˇcase. Audia jsou nahrávána s r˚ uznou vzorkovac´ı frekvenc´ı, která udává, jak rychle se má kaˇzd´ y vzorek pˇrehrávat, a je dána poˇctem vzork˚ u za sekundu. Nejˇcastˇeji pouˇz´ıvané frekvence jsou 44 100Hz a 22050Hz.

Intenzitu zvuku je moˇzné urˇcit pomoc´ı decibel˚ u - dB. Jedná se o veliˇcinu, která je vyjádˇrena jako logaritmus pod´ılu dvou hodnot. Padesáti decibely se dá oznaˇcit bˇeˇzná konverzace a 120 decibel˚ u pˇredstavuje práh bolesti. [33]

26


Stream

MP3 Pro pˇrenos audia byla zvolena komprimace pomoc´ı MP3 (MPEG Layer III Audio Encoding). MP3 komprese pouˇz´ıvá percepˇcn´ı kódován´ı (metoda zaloˇzená na vn´ımán´ı zvuku ˇclovˇekem - psychoacoustic). Tato metoda dovoluje odstranit nebo redukovat pˇresnost takov´ ych ˇca´st´ı audia, které jsou pro lidsk´ y sluch ménˇe slyˇsitelné. MP3 soubor, jehoˇz pˇrenosová rychlost je 128 kbit/s, tvoˇr´ı asi 1/11 p˚ uvodn´ıho nekomprimovaného LPCM (Linear pulse-code modulation) souboru, kter´ y má kvalitu kompaktn´ıho disku (44 100 Hz, 16 bit˚ u hloubku). [20]

3.3.2

Video

Jako digitáln´ı video se dá oznaˇcit sekvence rámc˚ u, kde kaˇzd´ y rámec se skládá z obdéln´ıkové mˇr´ıˇzky obrazov´ ych element˚ u - pixel˚ u. Kaˇzd´ y pixel m˚ uˇze b´ yt bud’ jeden bit (pouze ˇcernob´ıl´ y obraz) nebo 8 bit˚ u (256 odst´ın˚ u ˇsedi). Pro dosaˇzen´ı barevného obrazu se vˇetˇsinou pouˇz´ıvá 8 bit˚ u pro kaˇzdou barevnou sloˇzku z RGB (red - green - blue). To pˇredstavuje 24 bit˚ u na pixel, a tedy okolo 16 milion˚ u barev (v´ıce, neˇz lidské oko m˚ uˇze rozliˇsit). Obvyklé sn´ımkovac´ı frekvence (frame rate) se pohybuj´ı od 24 do 30 sn´ımk˚ u/s. [33]

Pˇrenos videa po s´ıti je nároˇcn´ y na pˇrenosovou kapacitu, nen´ı-li pouˇzita komprese. 2 Pro pˇredstavu : • Video, které má velikost 640x480, 24 bit˚ u barevné informace na pixel a 30 sn´ımk˚ u/s, potˇrebuje ke svému pˇrenosu 421 Mb/s [33]. • Video velikosti 720x576, s 8 bitovou barevnou hloubkou a 25 sn´ımky/s, potˇrebuje ˇs´ıˇrku pásma 158 Mb/s [19]. • HDTV (High Definition Television) uˇz potˇrebuje 1,85 Gb/s [19].

MPEG MPEG standard (Moving Picture Coding Exports Group) patˇr´ı mezi nejznámˇejˇs´ı a asi i nejpouˇz´ıvanˇejˇs´ı kódován´ı videa (um´ı komprimovat ale i audio [33]). 2

Vˇsechny v´ ypoˇcty poˇc´ıtaj´ı s barevn´ ym modelem YUV 4:2:2 a byly ovˇeˇreny pomoc´ı [13].

27


Stream

Tento standard zahrnuje kompresn´ı metody: MPEG-1, MPEG-2, MPEG-4. MPEG4 je nejmladˇs´ı a byl konstruován na pouˇzit´ı v multimediáln´ıch aplikac´ıch a pro video komunikace [19].

Základn´ım stavebn´ım kamenem MPEG streamu jsou komponenty naz´ yvaj´ıc´ı se elementárn´ı stream (Elementary Stream) (dále ES). Kaˇzdé video m˚ uˇze obsahovat nˇekolik typ˚ u ES: audio, video, titulky atd. Jednotlivé ES jsou ukládány do vˇetˇs´ıch celk˚ u, kter´ ym se ˇr´ıká PES pakety (Packetised Elementary Stream). Kaˇzd´ y PES paket má 6 bytovou hlaviˇcku, která mimo jiné udává i typ pˇrenáˇsen´ ych dat (stream ID je ve ˇctvrtém bytu hlaviˇcky a má tvar: 110x xxxx - audio, 1110 yyyy - video). [11]

MPEG komprimuje data v 5 kroc´ıch: redukce rozliˇsen´ı, nahrazen´ı pohybu, diskrétn´ı kosinová transformace (DCT), kvantizace a kódován´ı entropie [19]. Dále si bl´ıˇze pˇribl´ıˇz´ıme prvn´ı dva kroky.

Redukce rozliˇsen´ı vyuˇz´ıvá toho, ˇze lidské oko je ménˇe citlivé na barevnou informaci neˇz na kontrasty tmavé a svˇetlé a ˇze provád´ı pˇrevod z prostoru RGB na YUV komponenty. Barevné sloˇzky U a V mohou b´ yt redukovány (pˇrevzorkovány) na polovinu pixel˚ u v horizontáln´ı u ´rovni (YUV 4:2:2) nebo zároveˇ n i ve vertikáln´ı (YUV 4:2:0). Toto pˇrevzorkován´ı má za následek sn´ıˇzen´ı objemu dat o 50% a 33%. [19]

Obr. 3.10: Spojen´ı 2(4) pixel˚ u chrominanˇcn´ıho kanálu dohromady [8]. V druhém kroku, nahrazen´ı pohybu, se vyuˇz´ıvá redundance, která se ve videu objevuje. Tato redundance spoˇc´ıvá v tom, ˇze dva po sobˇe jdouc´ı rámce, jsou ˇcasto témˇeˇr identické. To plat´ı hlavnˇe pro scény, kde se kamera neh´ ybe, a osoby se pohybuj´ı velice pomalu. MPEG tak rozliˇsuje 3 typy rámc˚ u [33]:

28


Stream

• I rámce (Intracoded): obsahuj´ı cel´ y obrázek. • P rámce (Predictive): obsahuj´ı rozd´ıl oproti pˇredchoz´ımu rámci (P nebo I ). Bez referenˇcn´ıho rámce je nejde zrekonstruovat. • B rámce (Bidirectional): obsahuj´ı rozd´ıl, jako P rámce, ale na obˇe strany (vzhledem k pˇredchoz´ımu a následuj´ıc´ımu rámci). Podle poˇctu pouˇzit´ ych typ˚ u rámc˚ u se odv´ıj´ı i v´ ysledná kvalita a velikost videa. ˇ C´ım v´ıce I rámc˚ u, t´ım vˇetˇs´ı kvalita a velikost, a naopak, ˇc´ım v´ıce B rámc˚ u, t´ım je kvalita horˇs´ı a velikost menˇs´ı [19]. Moˇzn´ y sled rámc˚ u videa je vidˇet na obr. 3.11. B rámce se, kv˚ uli sv´ ym nárok˚ um na buffer a vˇetˇs´ı sloˇzitosti, ne vˇzdy pouˇz´ıvaj´ı [33]. Vztah (pohybov´ y) mezi dvˇema rámci se urˇcuje pomoc´ı pohybového vektoru. Jaké jsou v´ ypoˇcetn´ı moˇznosti toho algoritmu se lze doˇc´ıst v [3], [19] a [33].

Obr. 3.11: Ukázka posloupnosti rámc˚ u v MPEGu [2].

MPEG-TS [11] MPEG-TS (MPEG transport stream) je kontejner pouˇz´ıvaj´ıc´ı se na pˇrenos dat (audio, video atd.) po nespolehlivé s´ıti. Oproti programovému streamu obsahuje robustn´ı mechanismus na opravu chyb a synchronizaci. Transportn´ı stream se skládá 29


Stream

z TS paket˚ u, které maj´ı pevnˇe danou délku - 188B (4B tvoˇr´ı hlaviˇcka). Jeden PES paket b´ yvá rozdˇelen do nˇekolika TS paket˚ u a nacház´ı se v ˇca´sti pro data. V hlaviˇcce TS paketu je pak jeden bit nastaven na indikaci zaˇca´tku PES paketu. Vzhledem k tomu, ˇze PES paket m˚ uˇze m´ıt r˚ uznou délku, mus´ı se pˇr´ıpadné zb´ yvaj´ıc´ı m´ısto v TS paketu doplnit 0xFF, aby dalˇs´ı PES paket zaˇc´ınal na zaˇcátku nového TS paketu. V kaˇzdém TS paketu sm´ı b´ yt zaˇca´tek jen jednoho PES paketu. Vzhledem ke tˇemto vlastnostem byl tento kontejner vybrán pro pˇrenos obou stream˚ u, které se v aplikaci pˇrenáˇsej´ı.

3.3.3

Knihovna pro pr´ aci s audiem/videem

Pro z´ıskáván´ı audia a videa ze vstupn´ıch zaˇr´ızen´ı je nutné vybrat vhodn´ y nástroj a dále s´ıt’ové protokoly, pomoc´ı kter´ ych bude stream dopraven k pˇr´ıjemci (viz kap. 3.3.4). Pro z´ıskán´ı i pos´ılán´ı audia/videa se nab´ız´ı pouˇzit´ı jiˇz existuj´ıc´ıch nástroj˚ u jako je napˇr. Skype. Tyto nástroje vˇsak nejsou dostupné na u ´rovni zdrojového kódu, a nav´ıc u nich nen´ı moˇznost dostat se k pos´ılan´ ym dat˚ um, aby je bylo moˇzné zkoumat kv˚ uli detekci zmˇen. Proto byla vybrána jiná varianta v podobˇe multiplatformn´ı opensourcové knihovny - FFmpeg.

FFmpeg pˇredstavuje kompletn´ı ˇreˇsen´ı pro nahráván´ı, pˇrevod a streamován´ı audia/videa [12]. FFmpeg poskytuje knihovny napsané v programovac´ım jazyce C, kter´ y um´ı provádˇet v´ yˇse zm´ınˇené (napˇr. avcodec, avdevice, avutil atd.) nebo poskytuje jiˇz hotové nástroje (pˇreloˇzené nebo zdrojové kódy) na téˇz v´ yˇse zm´ınˇené aktivity (ffmpeg.exe, ffprobe.exe, ffserver.exe, ffplay.exe).

• ffmpeg.exe - Nástroj pro konverzi audia/videa, kter´ y dokáˇze z´ıskávat vstup(y) z pˇripojen´ ych zaˇr´ızen´ı (soubor, internetov´ y stream, pipe, multimediáln´ı zaˇr´ızen´ı) a pos´ılat je na v´ ystupy (soubor, internet atd.). • ffprobe.exe - Slouˇz´ı k z´ıskáván´ı informac´ı o daném streamu. • ffserver.exe - Jedná se o streamovac´ı server, kter´ y podporuje audio i video. • ffplay.exe - Nástroj urˇcen´ y pro pˇrehráván´ı multimédi´ı bud’ ze souboru nebo internetu. Pouˇz´ıvá knihovnu SDL. Máme tedy dvˇe moˇznosti, jak FFmpeg pouˇz´ıt. Jedna je rovnou pomoc´ı knihoven a druhá pomoc´ı jiˇz vytvoˇren´ ych nástroj˚ u. FFmpeg poskytuje rozsáhlou, ˇcitelnou a 30


Stream

srozumitelnou dokumentaci k tomu, jak pouˇz´ıvat v´ yˇse zm´ınˇené nástroje. Popisuje zde, jaké parametry se na co pouˇz´ıvaj´ı, jaké maj´ı pˇr´ıpustné hodnoty atd. Dokumentace, kde by bylo popsáno, jak pouˇz´ıvat knihovny a jejich funkce ve zdrojovém kódu, aˇz na cca 6 vzorov´ ych pˇr´ıklad˚ u poskytovan´ ych FFmpegem, neexistuje. Dalˇs´ı nev´ yhoda pouˇzit´ı knihoven je ta, ˇze jednotlivé updaty nejsou zpˇetnˇe kompatibiln´ı. Pokud se tedy vydá update, pak se mus´ı cel´ y napsan´ y kód proj´ıt a opravit. V nˇekter´ ych pˇr´ıpadech jde o malé zmˇeny typu: pˇridán´ı za název funkce o jedniˇcku vˇetˇs´ı ˇc´ıslo. Pokud jsou ale zmˇeny velké, m˚ uˇze j´ıt o zmˇenu celé logiky provádˇeného u ´konu, a pak jsou zásahy do kódu mnohem vˇetˇs´ı. Pˇresnˇe takové jsou rozd´ıly mezi verzemi 1.2 a 2.0 knihovny SDL (Simple DirectMedia Layer). Tato knihovna byla uvaˇzována pro pˇrehráván´ı doruˇceného streamu a nástroj ffplay.exe ji k tomuto u ´ˇcelu téˇz pouˇz´ıvá. Knihovna SDL verze 2.0 je na tom s dokumentac´ı podobnˇe jako FFmpeg pro své knihovny.

Po zhodnocen´ı v´ yˇse uveden´ ych d˚ uvod˚ u, bylo jako lepˇs´ı ˇreˇsen´ı vybráno pouˇzit´ı jiˇz hotov´ ych nástroj˚ u, konkrétnˇe pak ffmpeg.exe pro z´ıskán´ı vstupu z kamery a mikrofonu a ffplay.exe pro pˇrehráván´ı streamu na stranˇe klienta. Tato varianta umoˇzn ˇuje jednoduché vymˇenˇen´ı nástroj˚ u v pˇr´ıpadˇe updatu bez zásahu do zdrojového kódu vlastn´ı aplikace.

3.3.4

Moˇ znosti pˇ renosu streamu

Data, která z´ıskáme pomoc´ı FFmpegu, je nutné nˇejak´ ym zp˚ usobem doruˇcit klient˚ um a jeˇstˇe je zaˇsifrovat. Nab´ız´ı se nˇekolik moˇznost´ı popsan´ ych n´ıˇze.

ffserver.exe Jak jiˇz bylo zm´ınˇeno v´ yˇse, jedn´ım z nástroj˚ u, které FFmpeg nab´ız´ı, je i streamovac´ı server ffserver.exe. Streamovac´ı server slouˇz´ı k distribuci streamu na v´ıce klient˚ u, kteˇr´ı se k nˇemu pˇripoj´ı. ffserver.exe um´ı z jednoho vstupu vytvoˇrit v´ıce r˚ uzn´ ych v´ ystup˚ u. To znamená, ˇze pokud se na nˇej poˇsle napˇr. MPEG soubor, tak ffserver.exe ho m˚ uˇze pˇrekonvertovat a klient˚ um nab´ızet jako tˇreba AVI a MOV soubory najednou. ffserver.c obsahuje platformˇe (Linux) závislé komponenty a nen´ı ho proto moˇzné pˇreloˇzit a pouˇz´ıvat pod systémem Windows. Nav´ıc se i uvád´ı, ˇze je zastaral´ y, a nedoporuˇcuje se ho jiˇz jako streamovac´ı server pouˇz´ıvat.

31


Stream

Streamovac´ı servery Dalˇs´ı alternativu pro distribuci streamu pˇredstavuj´ı jiné streamovac´ı servery. Pro naˇse u ´ˇcely pˇripadaj´ı v u ´vahu ty, které je moˇzné pouˇz´ıvat zdarma nebo patˇr´ı do kategorie opensource. Mezi takové patˇr´ı Darwin Streaming Server (dále Darwin) a C++ RTMP Server (dále crtmp). Oba servery maj´ı vcelku jednoduché ovládán´ı a Darwin disponuje i webov´ ym rozhran´ım, kde je moˇzné server nastavovat a ovládat.

Na Darwinu nen´ı problém streamovat soubory, které jsou uloˇzené na disku, ale zdá se b´ yt problém streamován´ı live streamu. To naopak nen´ı problém u druhého serveru - crtmp. Tento server pouˇz´ıvá primárnˇe pro pˇrenos streamu protokol RTMP (Real Time Messaging Protocol), ale podporuje i UDP, TCP nebo HTTP. Server crtmp podporuje ˇsifrován´ı streamu v podobˇe implementovan´ ych protokol˚ u RTMPE (vnitˇrn´ı bezpeˇcnostn´ı mechanismus) nebo RTMPS (pouˇz´ıvá SSL/TLS). Aby vˇsak tyto protokoly fungovaly, je zapotˇreb´ı certifikát vydan´ y certifikaˇcn´ı autoritou. Nestaˇc´ı pouˇz´ıt self signed certifikát.

Jako moˇzné ˇreˇsen´ı je tedy pouˇzit´ı streamovac´ıch server˚ u tˇret´ıch stran zavrˇzeno.

ffmpeg.exe FFmpeg um´ı nejen z´ıskat data z pˇripojené kamery a mikrofonu, ale dokáˇze je i pos´ılat (ukládat) na c´ılovou adresu, která je ve formátu [protokol]://[ip adresa]:[port] (závis´ı na typu protokolu). Nen´ı to dlouho, co byla do FFmpegu pˇridána dalˇs´ı funkcionalita v podobˇe v´ıcenásobného v´ ystupu. Bud’ je moˇzné jeden pˇrekódovan´ y vstup poslat na v´ıce v´ ystup˚ u (viz obr. 3.12) nebo je moˇzné jeden vstup kódovat r˚ uzn´ ymi zp˚ usoby pro kaˇzd´ y v´ ystup zvláˇst’ (viz obr. 3.13), coˇz je v´ ypoˇcetnˇe nároˇcnˇejˇs´ı [35].

FFmpeg sice um´ı pos´ılat vstup na v´ıce klient˚ u, ale pro naˇse u ´ˇcely, alespoˇ n co se t´ yˇce rozes´ılán´ı streamu klient˚ um, je tento zp˚ usob nedostaˇcuj´ıc´ı. Je to proto, ˇze se bude pouˇz´ıvat vytvoˇren´ y nástroj (ffmpeg.exe), kde se jiˇz pˇri jeho spuˇstˇen´ı mus´ı zadat, co se kam bude pos´ılat, a nelze pak za bˇehu pˇridávat nové klienty. Jednou moˇznost´ı by bylo pouˇstˇet pˇr´ıkaz pro ffmpeg.exe pokaˇzdé, kdyˇz se pˇri(od)poj´ı nˇejak´ y klient. T´ım by se ale naruˇsila nezávislost jednotliv´ ych klient˚ u, kteˇr´ı by na obdrˇzeném streamu mohli zaznamenávat malé v´ ypadky pokaˇzdé, kdyˇz se nˇekdo jin´ y odpoj´ı nebo pˇripoj´ı.

32


Stream

Obr. 3.12: Kop´ırován´ı jednoho vstupu na v´ıce v´ ystup˚ u u FFmpegu [35].

Obr. 3.13: Kódován´ı vstupu pro kaˇzd´ y v´ ystup zvláˇst’ u FFmpegu [35]. Popsané funkcionality proto vyuˇzijeme t´ım zp˚ usobem, ˇze sice nebudeme pos´ılat stream pomoc´ı pˇr´ıkazu pˇr´ımo klient˚ um, ale z´ıskan´ y vstup z kamery (mikrofonu) se bude pos´ılat na lokáln´ı porty, kde bude poslouchat server. Z tˇechto port˚ u bude stream odchytáván a pˇrepos´ılán na vˇsechny klienty, kteˇr´ı si o stream zaˇza´dali. V pˇr´ıpadˇe, ˇze ˇza´dn´ y klient neodeb´ırá stream, nebude se ani z´ıskávat vstup z kamery (mikrofonu), a t´ım se uˇsetˇr´ı v´ ypoˇcetn´ı ˇcas procesoru. Vzhledem k tomu, ˇze server bude poskytovat 2 streamy (audio+video, audio), budou na serveru existovat 2 lokáln´ı porty, na kter´ ych bude server poslouchat a doruˇcen´ y stream pˇrepos´ılat. Pomoc´ı pˇr´ıkazu pro ffmpeg.exe pak budou vytvoˇreny 2 streamy, kde jeden bude obsahovat jak video tak audio a bude se pos´ılat na lokáln´ı port xxxxx, a druh´ y bude obsahovat pouze audio a bude se téˇz pos´ılat na (jin´ y) lokáln´ı port yyyyy. Jak vypadá pˇr´ıkaz pro z´ıskán´ı streamu bude popsáno v kap. 4.3.1. Pro pˇrenos streamu byl vybrán protokol UDP, jak jiˇz bylo popsáno v´ yˇse.

33


Stream

ˇ Sifrov´ an´ı Jako jeden ze základn´ıch poˇzadavk˚ u na aplikaci je ˇsifrován´ı pˇrenosu kv˚ uli bezpeˇcnosti. Dále se budeme zab´ yvat vytvoˇren´ım ˇsifrovaného streamu, kter´ y budeme z´ıskávat v´ yˇse uveden´ ym zp˚ usobem. FFmpeg podporuje mnoho s´ıt’ov´ ych protokol˚ u, mimo jiné i ty, co umoˇzn ˇuj´ı ˇsifrován´ı pˇrenosu. Pomoc´ı protokolu SRTP (Secure Real-time Transport Protocol) m˚ uˇzeme pos´ılat stream napˇr. takto:

ffmpeg -re -i "output.mpg"-vcodec libx264 -f flv srtp://192.168.0.100:7777?srtp_out_suite=AES_CM_128_HMAC_SHA1_80& srtp_out_params=NmcxMmQ2ZjVnYjEyNmRmMTV2czY1YWR2ZjFhc2Rm (3.1) ystupn´ıho ˇsifrován´ı a srtp out params je ˇsifrovac´ı Kde srtp out suite urˇcuje typ v´ blok (kódován´ı base64), kde prvn´ıch 16 byt˚ u se pouˇzije jako kl´ıˇc a zbyl´ ych 14 jako s˚ ul. Na stranˇe klienta se pak pouˇzije stejn´ y ˇsifrovac´ı blok i typ ˇsifrován´ı. Na obrázku 3.14 (a) je ukázka streamu, kter´ y byl pˇrenesen pomoc´ı protokolu SRTP a deˇsifrován stejn´ ym kl´ıˇcem jako je v ukázce 3.1. Na obrázku 3.14 (b) je pak záznam z toho samého streamu, tentokrát ale pˇrij´ımaného protokolem UDP, kter´ y ˇzádné ˇsifrován´ı nepodporuje.

(a) SRTP protokol

(b) UDP protokol

Obr. 3.14: Pˇrehráván´ı ˇsifrovaného streamu pomoc´ı SRTP a UDP protokol˚ u. 34


Stream

Z obrázk˚ u je jasnˇe patrné, ˇze protokol SRTP, kter´ y je v FFmpegu implementován, ˇza´dné ˇsifrován´ı neprovád´ı. Kdyby ano, zaˇsifrovan´ y stream nep˚ ujde spustit pomoc´ı protokolu UDP, pˇr´ıpadnˇe nebude doruˇcen´ y stream ˇciteln´ y. Parametry byly nastaveny podle dokumentace. Je moˇzné, ˇze se tato chyba vyskytuje pouze na nˇekter´ ych buildech a do budoucna bude opravena. Pro ˇsifrován´ı bylo tedy zvoleno jiné ˇreˇsen´ı, které vyuˇz´ıvá fakt, ˇze stream, pˇred odeslán´ım klientovi procház´ı pˇres server.

Stream, kter´ y je pomoc´ı ffmpeg.exe pos´ılán na server, je moˇzné jeˇstˇe pˇred jeho odeslán´ım klientovi zaˇsifrovat. K tomu se pouˇzije symetrická ˇsifra AES (viz kap. 3.2.3), kde ˇsifrovac´ı kl´ıˇc je vygenerován na serveru, a pomoc´ı ˇsifrovaného spojen´ı, které je tou dobou jiˇz navázané, doruˇcen klientovi. Kl´ıˇc je klientovi doruˇcen jeˇstˇe dˇr´ıv, neˇz se zaˇcne pos´ılat stream, aby klient mohl bez problém˚ u stream deˇsifrovat. ˇ Pro kaˇzd´ y stream bude existovat jeden ˇsifrovac´ı kl´ıˇc. Sifrovac´ ı kl´ıˇce budou m´ıt omezenou ˇzivotnost v tom smyslu, ˇze pˇri kaˇzdém zapnut´ı pˇr´ıkazu pro odeb´ırán´ı streamu budou kl´ıˇce vygenerovány znovu. To znamená, ˇze pokud bude stream odeb´ırat jeden klient, kter´ y se po nˇejaké dobˇe odhlás´ı, bude pro ˇsifrován´ı streamu pouˇz´ıvat jiné kl´ıˇce, neˇz ten klient, kter´ y se pˇrihlás´ı napˇr. aˇz 5 minut po nˇem. V pˇr´ıpadˇe, ˇze je najednou pˇrihláˇseno v´ıce klient˚ u, budou vˇsichni pouˇz´ıvat stejné ˇsifrovac´ı kl´ıˇce pro ˇsifrován´ı streamu (ale kaˇzd´ y klient má jin´ y kl´ıˇc pro obousmˇernou komunikaci se serverem). Jak se ˇsifrovac´ı kl´ıˇc pro stream dostane ke klientovi je popsáno v kap. 4.2.2.

3.3.5

Pˇ rehr´ av´ an´ı streamu

Pro pˇrehráván´ı streamu na stranˇe klienta byl vybrán nástroj ffplay.exe od FFmpegu. Tento nástroj zastupuje multimediáln´ı pˇrehrávaˇc a je schopn´ y pˇrehrávat stream jak ze souboru, tak ze s´ıtˇe. Vzhledem k tomu, ˇze stream, kter´ y bude klientovi pos´ılán, bude ˇsifrovan´ y, nen´ı moˇzné ho rovnou smˇerovat do pˇrehrávaˇce. Na stranˇe klienta se mus´ı vytvoˇrit stejn´ y mechanismus na ˇsifrován´ı streamu jako na serveru. To znamená, ˇze klient bude m´ıt vyhrazen´ y port, na kterém bude pˇrij´ımat stream. Tento stream projde deˇsifrovac´ım procesem, a aˇz pak bude smˇerován do pˇrehrávaˇce, kter´ y ho bude zobrazovat.

35


3.3.6

Stream

Detekce zmˇ en

Server mus´ı b´ yt schopn´ y analyzovat procházej´ıc´ı stream a urˇcit, zda nedoˇslo ke zmˇenˇe obrazu (pohyb) nebo zvuku (zv´ yˇsen´ı hlasitosti). D´ıky v´ yˇse popsanému zp˚ usobu pos´ılán´ı streamu to je moˇzné. Algoritmy na detekci zmˇeny obrazu b´ yvaj´ı zaloˇzené na porovnáván´ı dvou po sobˇe jdouc´ıch rámc˚ u. Neporovnávaj´ı je pixel po pixelu, ale vˇzdy po vˇetˇs´ıch ˇca´stech, a na základˇe v´ ysledku se pak rozhoduj´ı, zda doˇslo ke zmˇenˇe. FFmpeg má zakomponovánu jak detekci hlasitosti, tak detekci pohybu.

Detekce zmˇeny hlasitosti prob´ıhá následovnˇe: 1. Na zaˇca´tku sn´ımán´ı se do logu zaznamená silence start. 2. Pokud se zv´ yˇs´ı hladina zvuku nad mez danou pomoc´ı dB, tak se zaznamená silence end a doba trván´ı ticha. 3. Po ubˇehnut´ı urˇcité doby se opˇet zap´ıˇse silence start a zaˇcne se mˇeˇrit ˇcas trván´ı ticha. Nás budou zaj´ımat ty u ´seky logu, kde se vyskytuje silence end, protoˇze to znaˇc´ı, ˇze hladina zvuku se zv´ yˇsila nad námi danou tolerovanou mez. Pokud je zapnuté sledován´ı zmˇen scény, pak se do logu zapisuj´ı ˇrádky obsahuj´ıc´ı informaci o tom, jak moc se dan´ y rámec liˇs´ı od toho pˇredchoz´ıho: scene:0.750000. Hodnota 0.750000 udává, ˇze aktuáln´ı rámec se od toho pˇredcházej´ıc´ıho liˇs´ı o 75% (pˇred kamerou tedy doˇslo k vˇetˇs´ımu pohybu).

D´ıky moˇznostem, které FFmpeg nab´ız´ı, dokáˇzeme jednoduch´ ym zp˚ usobem z´ıskat informaci o tom, zda se zmˇenila scéna nebo hladina zvuku. Veˇskeré tyto informace jsou logovány do konzole, kde ffmpeg.exe bˇeˇz´ı. Naˇstˇest´ı pro nás, vˇsechny v´ ypisy provád´ı FFmpeg na standardn´ı chybov´ y v´ ystup, a tak po pˇresmˇerován´ı toho v´ ystupu do souboru se lehce dostaneme k obsaˇzen´ ym informac´ım. Problém zde ale pˇredstavuje to, ˇze velikost souboru s logem bude pˇri nepˇretrˇzitém provozu serveru neustále nar˚ ustat. FFmpeg nepodporuje nastaven´ı pevné délky logovac´ıho souboru, kde by se záznamy po dosaˇzen´ı urˇcité velikosti souboru opˇet zapisovaly od zaˇcátku souboru. Z tohoto d˚ uvodu musela b´ yt zvolena jiná technika pro z´ıskán´ı dat, neˇz jen pouhé ˇcten´ı logovac´ıho souboru.

Pro z´ıskán´ı informac´ı z logu je moˇzné pouˇz´ıt roury (dále pipe). Logovac´ı soubor tedy v˚ ubec nebude vytváˇren a v´ ystup ze spuˇstˇeného ffmpeg.exe bude pomoc´ı pipe 36


Správa serveru

pˇresmˇerován ke zpracován´ı rovnou na server. Podrobnˇejˇs´ı informace jsou obsaˇzené v implementaci v kap. 4.3.3.

3.4

Spr´ ava serveru

Pro správu serveru, streamu a pˇridáván´ı nov´ ych uˇzivatel˚ u bylo, na stranˇe serveru, zvoleno webové rozhran´ı. Tato varianta je pro bˇeˇzné uˇzivatele mnohem pˇr´ıjemnˇejˇs´ı neˇz bˇeˇzná pˇr´ıkazová ˇra´dka, ze které je server spouˇstˇen. Toto webové rozhran´ı je pˇr´ıstupné pˇres bˇeˇzn´ y webov´ y prohl´ıˇzeˇc po zadán´ı IP adresy serveru a portu 9443. Vzhledem k tomu, ˇze se mezi prohl´ıˇzeˇcem a serverem budou pˇrenáˇset citlivé informace v podobˇe uˇzivatelsk´ ych u ´daj˚ u, je pro komunikaci zvolen protokol HTTPS (viz kap. 3.2.1). Pˇr´ıstupnost webového rozhran´ı mus´ı b´ yt omezena, aby se nemohl kdokoliv registrovat, a pak i sledovat stream. Vstup do administrace je tedy omezen zadán´ım hesla a uˇzivatelského jména.

3.4.1

Pˇ rid´ an´ı nov´ ych uˇ zivatel˚ u

Hlavn´ım d˚ uvodem vzniku webového rozhran´ı bylo pˇridáván´ı nov´ ych klient˚ u. Je to kv˚ uli tomu, ˇze protokol SRP (viz kap. 3.2.2) zajiˇst’uje pouze bezpeˇcnou autentizaci, ale uˇz neˇreˇs´ı dopravu citliv´ ych u ´daj˚ u od klienta na server bˇehem registrace, která je pˇred samotnou autentizac´ı nutná. Po pˇrihláˇsen´ı do rozhran´ı bude tedy moˇzné pˇridat nového uˇzivatele zadán´ım jeho uˇzivatelského jména a hesla. Tyto u ´daje jsou pak uloˇzeny na serveru zp˚ usobem, kter´ y byl diskutován v´ yˇse (viz 3.2.2). Uloˇzené u ´daje pak poslouˇz´ı k pˇrihlaˇsován´ı klient˚ u na server.

Pˇri zadáván´ı nov´ ych u ´daj˚ u bude nutné ohl´ıdat duplicitu uˇzivatelsk´ ych jmen a také jejich délku. Nen´ı moˇzné, aby uˇzivatelsk´ ym jménem nebo heslem byl prázdn´ y ˇretˇezec nebo naopak ˇretˇezec pˇresahuj´ıc´ı 300 znak˚ u. Stejnˇe tak je nutné omezit znaky, které je moˇzné pro uˇzivatelské u ´daje pouˇz´ıt. Ne vˇsechny znaky se pˇrenesou tak, jak je uˇzivatel zadá, u nˇekter´ ych docház´ı k pˇreveden´ı do hexadecimáln´ıho kódu (napˇr. znak ! se pˇrenese jako %21 ). Tomu je nutné zabránit, uˇzivatel by se pak nikdy nemohl pod registrovan´ ymi u ´daji pˇrihlásit, protoˇze by zadával u ´plnˇe jiné u ´daje, neˇz jaké jsou ve skuteˇcnosti uloˇzeny.

37


3.4.2

Správa serveru

Nastaven´ı serveru

Webové rozhran´ı se dá vyuˇz´ıt, kromˇe registrace nov´ ych uˇzivatel˚ u, i k základn´ı správˇe serveru, kterou m˚ uˇze provádˇet uˇzivatel. Mezi tyto u ´kony patˇr´ı zmˇena port˚ u, na kter´ ych bˇeˇz´ı jednotlivé ˇcásti serveru, zmˇena hlavn´ıho hesla do rozhran´ı a omezen´ı pˇr´ıstupu do rozhran´ı. U port˚ u je nutné ohl´ıdat, aby se jejich hodnota nacházela mezi ˇc´ısly 1025 a 65535 a aby nebyly duplicitn´ı.

Zmˇena hesla do administrátorské ˇca´sti serveru má stejná pravidla jako vˇetˇsina takov´ ych zmˇen stejného typu. Pro zmˇenu hesla je nutné zadat i to staré, aby bylo ovˇeˇreno, ˇze ho uˇzivatel zná. Délku hesla je opˇet nutné omezit, aby uˇzivatel nezadával pˇr´ıliˇs krátká/dlouhá hesla. Omezen´ı se t´ yká i skupiny pouˇzit´ ych znak˚ u, která je stejná jako v´ yˇse (viz kap. 3.4.1). Nové heslo se pak uloˇz´ı jen v pˇr´ıpadˇe, ˇze to staré se bude shodovat s aktuálnˇe uloˇzen´ ym. Pˇr´ıstupové u ´daje do administrátorské ˇcásti webového rozhran´ı jsou na server uloˇzeny jako hashe. ˇ ım ménˇe bude webové rozhran´ı pˇr´ıstupné, t´ım menˇs´ı je ˇsance, ˇze se do nˇej C´ u ´toˇcn´ık dostane. Pˇr´ıstup do rozhran´ı je moˇzné omezit tak, ˇze budou pˇrij´ımáni pouze webov´ı klienti ze stejné pods´ıtˇe, ve které je sám server. Toho lze dosáhnout pomoc´ı masky pods´ıtˇe.

Maska s´ıtˇ e S´ıt’ová maska se pouˇz´ıvá pro urˇcen´ı adresy s´ıtˇe (bit˚ u, které j´ı pˇr´ısluˇs´ı), která je souˇcást´ı IP adresy [9]. Jedná se o ˇctyˇrbytové ˇc´ıslo, které má (ve dvojkové soustavˇe) zleva v m´ıstech s´ıt’ové adresy samé 1, jinak 0 [9]. IP adresa klienta do pods´ıtˇe patˇr´ı, pokud logick´ y souˇcin masky pods´ıtˇe a IP adresy klienta je roven IP adrese pods´ıtˇe. V ukázce 3.2 je uveden pˇr´ıklad, kde se podle IP adresy serveru nejdˇr´ıve urˇc´ı IP adresa pods´ıtˇe a následnˇe se podle n´ı posoud´ı, zda IP adresa klienta je vyhovuj´ıc´ı.

maska s´ ıtˇ e: 255.255.254.010 = 1111 1111.1111 1111.1111 1110.0000 00002 IP serveru: 147.228.187.7210 = 1001 0011.1110 0100.1011 1011.0100 10002 IP klienta: 147.228.67.10910 = 1001 0011.1110 0100.0100 0011.0110 11012 Provedeme logick´ y souˇ cin masky a IP adresy serveru a z´ ısk´ ame IP ad38


Správa serveru

resu pods´ ıtˇ e:

∧

11111111.11111111.11111110.00000000 10010011.11100100.10111011.01001000 10010011.11100100.10111010.00000000 = 147.228.186.010

Druh´ y logick´ y souˇ cin provedeme s maskou a IP adresou klienta:

∧

11111111.11111111.11111110.00000000 10010011.11100100.01000011.01101101 10010011.11100100.01000010.00000000 = 147.228.66.010

Nyn´ ı porovn´ ame prvn´ ıch 23 bit˚ u (poˇ cet v´ yskyt˚ u 1 v masce zleva) (oddˇ eleny |) obou v´ ysledk˚ u, kter´ e n´ as zaj´ ımaj´ ı: 10010011.11100100.1011101|0.00000000 10010011.11100100.0100001|0.00000000 Jak je vidˇ et, IP adresy pods´ ıt´ ı se liˇ sı ´, a t´ ım p´ adem IP adresa klienta nepatˇ r´ ı do dan´ e pods´ ıtˇ e. (3.2) Pokud bude IP adresa klienta po odmaskován´ı patˇrit do stejné s´ıtˇe jako IP adresa serveru pak se klient bude moci na server pˇrihlásit. Tuto moˇznost je lepˇs´ı nechat volitelnou, aby si uˇzivatel mohl sám vybrat, zda se do webového rozhran´ı dá dostat pouze ze stejné pods´ıtˇe ˇci odkudkoliv.

Zmˇena nastaven´ ych port˚ u se projev´ı aˇz po restartován´ı serveru, nen´ı moˇzné zmˇenit porty za bˇehu. Zmˇenu hesla administrace a nastaven´ı pods´ıt´ı je moˇzné aplikovat okamˇzitˇe. V pˇr´ıpadˇe, ˇze uˇzivatel bude pˇristupovat napˇr. z IP adresy jako ve v´ yˇse zm´ınˇeném pˇr´ıkladu a zakáˇze pˇr´ıstup z jiné pods´ıtˇe, pak se mu po uloˇzen´ı zmˇen stane, ˇze se jiˇz do webového rozhran´ı nepˇrihlás´ı.

39


3.4.3

Správa serveru

Nastaven´ı streamu

Dalˇs´ı funkcionalitu, kterou m˚ uˇze webové rozhran´ı nab´ızet, je nastaven´ı pˇrenáˇseného streamu a nastaven´ı parametr˚ u pro detekci zmˇen. Toto nastaven´ı je pro vˇsechny uˇzivatele, kteˇr´ı budou pˇrij´ımat stream, stejné. V pˇr´ıpadˇe nastaven´ı pˇrenáˇseného streamu se uˇzivateli m˚ uˇze zpˇr´ıstupnit nastaven´ı kvality jako napˇr. rozliˇsen´ı, poˇcet zvukov´ ych kanál˚ u (mono, stereo), kvalita videa nebo audio frekvence. Vzhledem k tomu, ˇze na tˇechto hodnotách závis´ı i u ´spˇeˇsné spuˇstˇen´ı pˇr´ıkazu pomoc´ı ffmpeg.exe, nebude si je moci uˇzivatel zadávat libovolnˇe. M´ısto toho bude m´ıt na v´ ybˇer z nˇekolika pˇrednastaven´ ych hodnot, napˇr. v podobˇe v´ ybˇerového pole (select box ). Dalˇs´ım d˚ usledkem, kter´ y z toho plyne je, ˇze zmˇena nastaven´ ych hodnot se zmˇen´ı aˇz po tom, co dojde k znovu spuˇstˇen´ı pˇr´ıkazu pomoc´ı ffmpeg.exe (tzn. po vypnut´ı vˇsech odeb´ıran´ ych stream˚ u).

Pos´ılán´ı zpráv o zmˇenách hlasitosti (zmˇeny obrazu) klient˚ um se ˇr´ıd´ı na základˇe zadan´ ych mez´ı. Pokud jsou tyto meze pˇrekroˇceny, je poslána zpráva o zmˇenˇe. Ve webovém rozhran´ı je tedy moˇzné zpˇr´ıstupnit nastaven´ı tˇechto mez´ı. Jedna mez se t´ yká hlasitosti zvuku a je udávána v dB. Krajn´ı hodnoty budou nastaveny na 0dB (práh slyˇsitelnosti) a 120dB (start tryskového letadla [18]). V´ ychoz´ı hodnota pak bude nastavena na 40dB, coˇz odpov´ıdá tiché knihovnˇe [18] (Záleˇz´ı i na nastaven´ı citlivosti mikrofonu).

Druhou nastavitelnou mez´ı je m´ıra zmˇeny scény vlivem pohybu. Tato hodnota je udávána v procentech a jej´ı hranice tak jsou od 0% (detekce pohybu pˇri zmˇenˇe 0% scény) do 100% (detekce pohybu pˇri zmˇenˇe 100% scény). V´ ychoz´ı hodnota, která staˇc´ı pro detekován´ı zmˇeny, je pak nastavena na 10%.

Zmˇena meze pro hladinu zvuku je vnitˇrnˇe vyuˇz´ıvána pˇr´ımo ffmpeg.exe. Pro uˇzivatele to znamená, ˇze zmˇeny meze se projev´ı aˇz po tom, co vˇsichni pˇrihláˇsen´ı klienti vypnou bˇeˇz´ıc´ı streamy. Pˇri dalˇs´ım spuˇstˇen´ı streamu dojde k novému zapnut´ı ffmpeg.exe s jiˇz novˇe nastavenou hodnotou. Toto vˇsak neplat´ı pro mez detekce pohybu, jelikoˇz log z ffmpeg.exe obsahuje pouze informaci o tom, jak moc se scéna zmˇenila (viz kap. 3.3.6). T´ım pádem se o pos´ılán´ı zpráv o zmˇenˇe scény mus´ı rozhodnout aˇz vnitˇrnˇe na serveru a ten má k dispozici vˇzdy aktuáln´ı hodnotu, s kterou z´ıskaná data porovnává. Uloˇzen´ı nové meze pro detekci pohybu se tedy projev´ı hned i bez vyp´ınán´ı stream˚ u.

40

4 Programátorská pˇr´ıruˇcka V této kapitole se budeme vˇenovat implementaci jednotliv´ ych ˇca´st´ı serveru a klienta.

4.1


Jak pro server, tak pro klienta, bylo zvoleno objektové programován´ı pomoc´ı tˇr´ıd a programovac´ıho jazyka C++. Tˇr´ıdy, které provádˇej´ı urˇcit´ y typ ˇcinnosti, jsou sdruˇzovány do soubor˚ u. Aplikace mus´ı b´ yt platformnˇe nezávislá1 . Za t´ımto u ´ˇcelem byl v obou ˇca´stech vytvoˇren soubor platform.h, kter´ y obsahuje mapován´ı funkc´ı, které jsou pro oba operaˇcn´ı systémy rozd´ılné. Mimo to se v kódu objevuj´ı i logické celky ohraniˇcené pomoc´ı direktiv (#ifdef, #endif ), které jsou pro oba systémy odliˇsné. Dalˇs´ı soubor, kter´ y maj´ı obˇe ˇcásti aplikace, je config.h, kter´ y obsahuje veˇskeré globáln´ı promˇenné.

Jak server, tak klient, obsluhuj´ı v´ıce bˇeˇz´ıc´ıch vláken najednou. Za u ´ˇcelem usnadnˇen´ı a sjednocen´ı práce s vlákny pod obˇema systémy bylo pouˇzito rozhran´ı pro psan´ı v´ıcevláknov´ ych program˚ u pro systémy Windows - POSIX Threads for Win32 (pthreads) [22]. D´ıky tomuto rozhran´ı je moˇzné pracovat s vlákny stejnˇe pod obˇema systémy, bez nutnosti pouˇzit´ı direktiv #ifdef, #endif atd.

4.1.1

Server

Funkcionalita serveru byla rozdˇelena do nˇekolika logick´ ych celk˚ u (client, ffmpeg, log, multicast, udp, web interface, hlavn´ı). Ten hlavn´ı obsahuje vytvoˇren´ı serveru, sledován´ı vstupu z klávesnice, konfiguraˇcn´ı soubor a soubor s funkc´ı main. Celek client obsahuje veˇskerou logiku, co se t´ yˇce pˇrihláˇsen´ı, komunikace a obsluhy klienta. Jsou zde i n´ıˇze popsané tˇr´ıdy pro práci se zprávami. Dále je zde uloˇzen i zaˇsifrovan´ y soubor s registrovan´ ymi uˇzivateli.

1

Aplikace mus´ı b´ yt pˇreloˇzena pod systémy Windows i GNU/Linux

41

Programátorská pˇr´ıruˇcka


ffmpeg obsahuje veˇskerou logiku, co se t´ yˇce práce se streamem a detekce zmˇen. log obsahuje logovac´ı tˇr´ıdu, která se pouˇz´ıvá ve vˇsech ostatn´ıch tˇr´ıdách a umoˇzn ˇuje jednotn´ y zápis logu do souboru. web interface obsahuje tˇr´ıdy, které pracuj´ı s webov´ ym rozhran´ım, certifikáty a textové soubory s nastaven´ım (serveru, FFmpegu, zmˇen).

Detailnˇejˇs´ı provázanost jednotliv´ ych tˇr´ıd je moˇzné vidˇet v UML diagramu tˇr´ıd na obr. 4.1. Tento diagram je zjednoduˇsen´ y, tedy neobsahuje u ´plné popisy tˇr´ıd v podobˇe atribut˚ u a metod. Dále je zde, kv˚ uli pˇrehlednosti, vynechána vazba vˇsech tˇr´ıd na tˇr´ıdu Log, kterou vyuˇz´ıvaj´ı k logován´ı, a v´ ypis tˇr´ıd, které se pouˇz´ıvaj´ı na zpracován´ı zpráv, je zkrácen pomoc´ı znaˇcky · · · .

Obr. 4.1: UML diagram tˇr´ıd pro server.

42


4.1.2


Klient

Tˇr´ıdy v programu klienta byly rozdˇeleny stejn´ ym zp˚ usobem jako na serveru, podle funkˇcn´ıch celk˚ u. Ty jsou témˇeˇr shodné, nav´ıc se zde objevuje gui, které obsahuje tˇr´ıdy pro práci s grafick´ ym rozhran´ım, a m´ısto ffmpeg tu je ffplay, kde je soustˇredˇeno pˇrehráván´ı streamu. UML diagram je znázornˇen na obr. 4.2, kde doˇslo ke stejnému zjednoduˇsen´ı, jako u diagramu tˇr´ıd serveru.

Obr. 4.2: UML diagram tˇr´ıd pro klienta.

43


4.2

Zabezpeˇcen´ı

Zabezpeˇ cen´ı

Implementace registrace nov´ ych klient˚ u bude popsána v kap. 4.4.1.

4.2.1

Pˇ rihl´ aˇ sen´ı

Pro pˇrihláˇsen´ı klient˚ u na server byl zvolen protokol SRP, kter´ y je popsán v´ yˇse (viz kap. 3.2.2), a jehoˇz implementace byla pˇrevzata z [29] a následnˇe nepatrnˇe upravena podle poˇzadavk˚ u aplikace. Tento protokol mus´ı b´ yt implementován na obou komunikuj´ıc´ıch stranách, jinak by pˇrihláˇsen´ı nebylo moˇzné. Dále si pˇribl´ıˇz´ıme proces pˇrihláˇsen´ı na obou stranách.

Klient Po vyplnˇen´ı u ´daj˚ u do pˇrihlaˇsovac´ıho okna dojde nejdˇr´ıve k jejich zkontrolovan´ı, zda nejsou nˇejaká pole prázdná nebo zadané hodnoty nejsou nesmyslné. Následnˇe se provede pokus o navázán´ı spojen´ı se serverem podle zadané IP a portu. Pokud se spojen´ı naváˇze, spust´ı se autentizaˇcn´ı proces se zadan´ ym uˇzivatelsk´ ym jménem a heslem. V´ ysledkem u ´spˇeˇsné autentizace je relaˇcn´ı kl´ıˇc, kter´ y bude dále pouˇzit (viz kap. 4.2.2), a zapnut´ı okna s pˇrehrávaˇcem. V pˇr´ıpadˇe, ˇze se spojen´ı nenaváˇze nebo jsou zadány ˇspatné u ´daje, pˇrihlaˇsovac´ı okno se otevˇre znovu a vyp´ıˇse, jaká nastala chyba.

Server U novˇe pˇr´ıchoz´ıho klienta se nejdˇr´ıve rozhodne, zda se jedná o normáln´ıho klienta nebo o webového klienta. V pˇr´ıpadˇe normáln´ıho klienta server vytvoˇr´ı v novém vláknu instanci tˇr´ıdy Client, ve kterém bude klient obsluhován. V tomto vláknu je nejdˇr´ıve spuˇstˇen autentizaˇcn´ı proces. Server si po spuˇstˇen´ı naˇcte vˇsechny registrované uˇzivatele s jejich u ´daji (hash, s˚ ul, jméno) do pamˇeti. V tˇechto u ´daj´ıch pak hledá uˇzivatelské jméno, které obdrˇz´ı od klienta, a s˚ ul a hash pak pouˇz´ıvá v pr˚ ubˇehu autentizaˇcn´ıho procesu. Pokud proces skonˇc´ı ne´ uspˇechem, vlákno je ukonˇceno. V pˇr´ıpadˇe u ´spˇechu je spuˇstˇen cyklus, ve kterém se vyˇckává na zprávy od klienta, a dále je vytvoˇreno vlákno, které bude klientovi zprávy pos´ılat. Stejnˇe jako u klienta, i zde vznikne relaˇcn´ı kl´ıˇc.

44


4.2.2

Zabezpeˇcen´ı

Z´ısk´ an´ı ˇ sifrovac´ıch kl´ıˇ c˚ u

V´ ysledkem u ´spˇeˇsného autentizaˇcn´ıho procesu, u klienta i serveru, jsou relaˇcn´ı kl´ıˇce, s nimiˇz je moˇzné ˇsifrován´ı komunikace. My je vˇsak nepouˇzijeme k ˇsifrován´ı, ale pouze k vygenerován´ı nov´ ych ˇsifrovac´ıch kl´ıˇc˚ u pomoc´ı knihovny OpenSSL (viz [21]). Tato knihovna obsahuje funkci, která generuje ˇsifrovac´ı kl´ıˇce ze zadaného základu. Kl´ıˇce, generované ze stejného základu, jsou pokaˇzdé stejné, a to je i d˚ uvod, proˇc nás nemus´ı trápit distribuce kl´ıˇce u symetrické ˇsifry AES (viz kap. 3.2.3). Na obou komunikuj´ıc´ıch stranách máme d´ıky u ´spˇeˇsnému autentizaˇcn´ımu procesu stejné relaˇcn´ı kl´ıˇce, které mohou b´ yt pouˇzity jako základy pro vygenerován´ı nov´ ych kl´ıˇc˚ u (256 bit˚ u).

Knihovna poskytuje pro AES dvˇe ˇsifrovac´ı metody, CBC a ECB. Kv˚ uli v´ yˇse diskutovan´ ym d˚ uvod˚ um (viz kap. 3.2.3) byla pouˇzita metoda CBC pro veˇskeré ˇsifrován´ı pˇrenosu. Je d˚ uleˇzité zd˚ uraznit, ˇze kaˇzd´ y klient má jiné ˇsifrovac´ı kl´ıˇce pro komunikaci se serverem, a stejnˇe tak jsou kl´ıˇce jiné pˇri kaˇzdém novém pˇrihláˇsen´ı. Kromˇe tˇechto kl´ıˇc˚ u existuj´ı jeˇstˇe dalˇs´ı dva kl´ıˇce, které ale maj´ı vˇsichni klienti spoleˇcné, sd´ıl´ı je. Jedná se o kl´ıˇce urˇcené k ˇsifrován´ı videa a audia. Tyto kl´ıˇce vznikaj´ı vˇzdy aˇz v okamˇziku, kdyˇz je zapnut odbˇer streamu. Pokud si klient vyˇzádá stream, jsou mu tyto kl´ıˇce poslány pomoc´ı ˇsifrovaného spojen´ı, které je jiˇz navázané. ˇ Zivotnost tˇechto kl´ıˇc˚ u se váˇze na odbˇer streamu. Kl´ıˇce se vytváˇr´ı nové vˇzdy, kdyˇz je spuˇstˇen pˇr´ıkaz na odbˇer streamu. Prakticky to znamená, ˇze pokud se pˇrihlás´ı klient k odbˇeru streamu, jsou vygenerovány nové kl´ıˇce. Kaˇzd´ y dalˇs´ı klient, kter´ y se pˇrihlás´ı, dostane téˇz tyto kl´ıˇce. Pokud se vˇsichni odhlás´ı, a následnˇe se jeden znovu pˇrihlás´ı k odbˇeru streamu, pak uˇz bude m´ıt kl´ıˇce nové.

4.2.3

Multicast

Pro vytvoˇren´ı mDNS sluˇzeb byla, s mal´ ymi u ´pravami, pouˇzita implementace podle [32], kde bylo nutné dopsat pos´ılán´ı odpovˇed´ı zpˇet klientovi. Tento program funguje tak, ˇze se nejdˇr´ıve do záznamu uloˇz´ı pár IP adresa-název stroje, a pak se uˇz jen pˇrij´ımaj´ı poˇzadavky od klient˚ u. Pokud se název stroje, obsaˇzen´ y ve zprávˇe od klienta, shoduje s t´ım, co je uloˇzen v záznamech, poˇsle se klientovi odpovˇed’, která obsahuje IP poˇzadovaného stroje, jinak se nepos´ılá nic.

45


Zabezpeˇcen´ı

Implementace je napsána v programovac´ım jazyce C, je pˇreloˇzitelná pod systémy Windows i GNU/Linux a byla pouˇzita jako pˇreloˇzen´ y program, kter´ y je spouˇstˇen jako extern´ı proces z programu server. V tomto programu je naprogramována nekoneˇcná smyˇcka, která ˇcte vstupy z klávesnice, a pokud se zadá p´ısmeno q, pak je program ukonˇcen. V pˇr´ıpadˇe, ˇze by tento zp˚ usob z nˇejakého d˚ uvodu nefungoval, pak je jeˇstˇe implementován pˇr´ıkaz kill, kter´ y tento extern´ı proces vyhledá mezi spuˇstˇen´ ymi procesy a ukonˇc´ı ho.

mDNS funguje pouze, pokud jsou server i klient ve stejné pods´ıti. Jinak je nutné pouˇz´ıt IP adresu serveru pro pˇripojen´ı z klienta na server.

4.2.4

Komunikace

Jak uˇz bylo zm´ınˇeno v´ yˇse (viz kap. 3.2.3), pro komunikaci mezi serverem a klientem byl pouˇzit protokol TCP a pro pos´ılán´ı streamu pak protokol UDP. Nyn´ı se budeme vˇenovat obousmˇerné komunikace klient-server.

Poˇzadavky, které má klient na server (ale i opaˇcnˇe, server m˚ uˇze cht´ıt informovat klienta o zmˇenˇe) jsou ˇreˇseny pomoc´ı zas´ılán´ı zpráv ve formátu ###type#state#data, kde type je typ zprávy (viz tabulka 4.1), state indikuje u ´spˇeˇsnost proveden´ı poˇzadavku (0 - selhán´ı, 1 - u ´spˇech) a data obsahuje dodateˇcná data, která je tˇreba pˇr´ıpadnˇe poslat (pouˇz´ıvá se pro pˇrenos ˇsifrovac´ıho kl´ıˇce streamu). Pro kaˇzd´ y typ existuje samostatná tˇr´ıda, která dan´ yu ´kol provád´ı. Vˇsechny tyto tˇr´ıdy dˇed´ı od jedné spoleˇcné a pˇrekr´ yvaj´ı funkci pro zpracován´ı zprávy.

Vˇsechny zprávy jsou pˇred sv´ ym odeslán´ım ˇsifrovány pomoc´ı AES, kde délka bloku je 16 byt˚ u. Moˇzné délky zpráv po zaˇsifrován´ı tedy odpov´ıdaj´ı násobk˚ um 16. Od klienta na server se nikdy nepos´ılá zpráva delˇs´ı neˇz 16 byt˚ u. Typy zpráv a jejich v´ yznam je popsán v tabulce 4.1. Pokud klient poˇsle zprávu na server, tak ten zachová typ zprávy a mˇen´ı pouze pole state a pˇr´ıpadnˇe data.

46

Programátorská pˇr´ıruˇcka #

Název (typ)

0

VIDEO

1

AUDIO FRAME CHANGE SUBSCRIBE SOUND CHANGE SUBSCRIBE

2

3

Zabezpeˇcen´ı

Popis funkce Klient poˇsle v okamˇziku, kdy si chce nechat zaˇc´ıt pos´ılat video stream. V ˇca´sti pro data pos´ılá sv˚ uj UDP port, kde bude poslouchat. Server naopak odpov´ıdá se sv´ ym portem, odkud bude data pos´ılat. Nyn´ı je moˇzné pos´ılat stream klientovi, kter´ y je uloˇzen v seznamu odbˇeratel˚ u. To samé jako VIDEO, ale pro audio. Klient chce dostávat zprávy o zmˇenách obrazu. Vˇzdy, kdyˇz se zmˇen´ı obraz, bude mu poslána zpráva. Stejné jako FRAME CHANGE SUBSCRIBE, ale pro zmˇenu hlasitosti.

4

CANCEL VIDEO

Tato zpráva je poslána, pokud vyprˇs´ı ˇcas urˇcen´ y k doˇcasnému pˇrehrán´ı videa. Pˇrenos streamu na daného klienta je ukonˇcen.

5

CANCEL AUDIO

Stejné jako CANCEL VIDEO, ale pro audio.

6

KEY VIDEO

7

KEY AUDIO

8

FRAME CHANGE

9 10

11

SOUND CHANGE QUIT SERVER MESSAGE STOP CLIENT

Klient pos´ılá ˇza´dost o zaslán´ı ˇsifrovac´ıho kl´ıˇce pro video stream. Server odpov´ıdá stejnou zprávou s vloˇzen´ ym kl´ıˇcem v ˇca´sti pro data. Klient je zaˇrazen do seznamu, kterému je pos´ılán stream, ale zat´ım se mu nic nepos´ılá (nen´ı znám port, kam se má stream pos´ılat). Analogie ke KEY VIDEO. Tuto zprávu pos´ılá server klientovi v pˇr´ıpadˇe, ˇze nastala zmˇena obrazu. Klient na n´ı neodpov´ıdá, pouze provede pˇr´ısluˇsné kroky k zobrazen´ı zprávy. Stejné jako FRAME CHANGE. V pˇr´ıpadˇe, ˇze bude server ukonˇcen, poˇsle jeˇstˇe pˇredt´ım zprávu, aby se klienti mohli taktéˇz ˇra´dnˇe ukonˇcit. Zpráva pˇrijde od klienta, kter´ y zastavil pˇrehráván´ı streamu pomoc´ı tlaˇc´ıtka Stop. Na serveru se klient odstran´ı ze vˇsech seznam˚ u, které souvis´ı s pos´ılán´ım streamu a zpráv o zmˇenách.

Tab. 4.1: Typy a v´ yznam komunikaˇcn´ıch zpráv.

47


4.3

Stream

4.3.1

FFmpeg

Stream

Nástroj ffmpeg.exe byl bl´ıˇze pˇribl´ıˇzen v kap. 3.3.4. Na moˇznosti zaˇclenˇen´ı do aplikace se pod´ıváme nyn´ı. ffmpeg.exe je spouˇstˇen jako extern´ı program v novém vláknu, kter´ y je vˇsak moˇzné z programu serveru ovládat. Toho je u obou platforem doc´ıleno pomoc´ı pipe. D´ıky tomu je moˇzné ffmpeg.exe ukonˇcit legáln´ım zp˚ usobem, a to tak, ˇze je mu zasláno p´ısmeno q.

Pˇredt´ım, neˇz je moˇzné pˇr´ıkaz spustit, je nutné znát jeho parametry a hlavnˇe vstupn´ı zaˇr´ızen´ı, ze kter´ ych se bude odeb´ırat audio/video. V pˇr´ıpadˇe systému Windows se poˇc´ıtá s pouˇzit´ım vstupn´ıch zaˇr´ızen´ı pomoc´ı formát˚ u DirectShow (multimediáln´ı framework). Tato zaˇr´ızen´ı je ale nejdˇr´ıve nutné naj´ıt. To se provede spuˇstˇen´ım pˇr´ıkazu 4.1, kde jeho zkrácen´ y v´ ystup je uveden v ukázce 4.2. Tento v´ ystup je smˇerován do souboru, odkud se pak zaˇr´ızen´ı z´ıskaj´ı. Tato zaˇr´ızen´ı se pak pouˇzij´ı jako vstupn´ı zdroje streamu. Pro systém GNU/Linux se pouˇz´ıvá vstupn´ı formát video4linux2 a zaˇr´ızen´ı /dev/video0 pro z´ıskán´ı videa a formát alsa a zaˇr´ızen´ı default pro zisk audia. Zde nen´ı tˇreba zaˇr´ızen´ı vyhledávat.

ffmpeg.exe -list_devices true -f dshow -i dummy (4.1)

[dshow [dshow [dshow [dshow dummym:

02509800] DirectShow video devices 02509800] "1.3M HD WebCam" 02509800] DirectShow audio devices 02509800] "Mikrofon (Conexant High Definit" Immediate exit requested (4.2)

Nˇekdy se m˚ uˇze stát, ˇze zaˇr´ızen´ı obsahuje ˇceské znaky a to je problém. FFmpeg spuˇstˇen´ y pod Windows je m˚ uˇze ˇspatnˇe dekódovat a t´ım pádem zaˇr´ızen´ı nenajde a 48


Stream

v˚ ubec se nespust´ı. Kv˚ uli tomu je nutné pˇr´ıkaz pro spuˇstˇen´ı nejdˇr´ıve pˇrekódovat z UTF-8 na Windows ANSI a aˇz pak ho je moˇzné spustit.

Nyn´ı je moˇzné pomoc´ı nástroje ffmpeg.exe, spustit pˇr´ıkaz, kter´ y zapne z´ıskáván´ı videa a audia z dostupn´ ych zaˇr´ızen´ı. Dále pak z´ıskan´ y stream kóduje do formátu MPEG-TS a kop´ıruje ho na dva v´ ystupy, které jsou pos´ılány na lokáln´ı porty serveru, kde jeden v´ ystupn´ı stream obsahuje jak video, tak audio stopu, a druh´ y pouze audio stopu. Kromˇe toho je spuˇstˇena i detekce pˇrekroˇcen´ı limitu hladiny zvuku a detekce pohybu. V´ ystupn´ı log je pˇresmˇerován do pipy, aby ho bylo moˇzné analyzovat (viz kap. 4.3.3). Cel´ y pˇr´ıkaz (pro Windows) je znázornˇen v ukázce 4.3 (spolu s ˇc´ıslován´ım ˇra´dk˚ u) a v tabulce 4.2 jsou pak vysvˇetleny jeho jednotlivé parametry.

1: ffmpeg.exe -loglevel debug 2: -f dshow 3: -i video="1.3M HD WebCam":audio="Mikrofon (Conexant High Definit" 4: -vcodec libx264 -pix_fmt yuv420p 5: -acodec libmp3lame 6: -b:v 282000 -ar 16000 -ac 1 -r 30 -s 800x600 -q:v 1 7: -f mpegts "udp://127.0.0.1:9002" 8: -af silencedetect=noise=-40dB -f null 9: -vf "select=’gt(scene 0.1)’"-f null 10: -vn -f mpegts "udp://127.0.0.1:9004" 11: 2>\\.\\pipe\\ffmpegOutputPipe (4.3) ˇ adek 7 pˇredstavuje audio+video Na ˇra´dc´ıch 7 - 10 jsou vidˇet paraleln´ı v´ ystupy. R´ ˇ adek 10 stream, kter´ y je ve formátu MPEG-TS pos´ılán na lokáln´ı port serveru. R´ ukazuje to samé, jen je pos´ılán pouze audio stream a na jin´ y port. Na ˇra´dc´ıch 8 a 9 jsou nastaveny filtry pro detekci hlasitosti a pohybu. Za normáln´ıch okolnost´ı poskytuj´ı v´ ystup (dalˇs´ı stream nebo napˇr. obrázky pˇri kaˇzdé detekci pohybu), ten vˇsak my k niˇcemu nepotˇrebujeme, a proto je zde m´ısto v´ ystupn´ıho formátu pouze null -. ˇ adky 2 a 3 závis´ı na pouˇzitém operaˇcn´ım systému. Posledn´ı ˇra´dek je pˇresmˇerován´ı R´ chybového v´ ystupu do pojmenované pipy. D´ıky tomu je moˇzné analyzovat veˇsker´ y log, kter´ y je generován.

49


Stream

Parametr V´ yznam loglevel Urˇcen´ı u ´rovnˇe logován´ı. debug je nejpodrobnˇejˇs´ı v´ ypis. Vynucen´ı urˇcitého v(´ y)stupn´ıho formátu. dshow znaˇc´ı pouˇzit´ı f zaˇr´ızen´ı DirectShow. mpegts je formát v´ ystupn´ıho streamu. Formát vstupu. Zde je uveden bud’ vstupn´ı soubor, s´ıt’ová i adresa nebo zaˇr´ızen´ı, jako v´ yˇse v ukázce 4.3. Kodek pro video. libx264 je knihovna a znaˇc´ı pouˇzit´ı komprese vcodec H.264. pix fmt Formát rámc˚ u. Konkrétnˇe pouˇzit´ y je yuv420p (viz obr. 3.10). Kodek pro audio. libmp3lame je knihovna a znaˇc´ı pouˇzit´ı acodec komprese MP3. Video bit rate. Jedná se o poˇcet pˇrepraven´ ych bit˚ u za jednotku b:v ˇcasu. Vzorkovac´ı frekvence audia. Nejpouˇz´ıvanˇejˇs´ı hodnoty jsou ar 44 100 Hz a 22 050 Hz. ac Poˇcet audio kanál˚ u (mono = 1, stereo = 2). r Poˇcet rámc˚ u za sekundu. s Rozliˇsen´ı videa. Urˇcuje m´ıru komprese - kvalitu videa. Rozpˇet´ı má od 1 do 31, q:v kde 1 je nejkvalitnˇejˇs´ı. Audio filtr. silencedetect=noise=-40dB udává sledován´ı hlaaf diny zvuku s toleranc´ı 40 dB. Video filtr. select=’gt(scene 0.1)’ porovnává dvˇe po sobˇe vf jdouc´ı scény a zaznamená, o kolik procent se liˇs´ı. Tab. 4.2: Popis parametr˚ u FFmpegu [12]. Spuˇstˇen´ı ffmpeg.exe se provád´ı stejnˇe jako u spuˇstˇen´ı mDNS programu, pomoc´ı pipe. Pˇr´ıkaz pro z´ıskáván´ı a anal´ yzu streamu nebˇeˇz´ı celou dobu, co je spuˇstˇen server. Kv˚ uli ˇsetˇren´ı operaˇcn´ı pamˇeti je tento pˇr´ıkaz spuˇstˇen jen tehdy, kdyˇz si nˇejak´ y klient vyˇza´dá stream (po stisku tlaˇc´ıtka Play na pˇrehrávaˇci). Po odpojen´ı je vykonáván´ı pˇr´ıkazu pˇreruˇseno a s novˇe pˇr´ıchoz´ım klientem se znovu spouˇst´ı.

4.3.2

Pˇ renos streamu

ffmpeg.exe pos´ılá na server 2 streamy pomoc´ı protokolu UDP na dva r˚ uzné porty (oba streamy jsou pos´ılány pokaˇzdé, bez ohledu na to, zda si klient vyˇzádal pouze audio nebo audio+video). Na tˇechto portech server poslouchá. Respektive na nich 50


Stream

poslouchaj´ı instance tˇr´ıdy Udp server, které bˇeˇz´ı v samostatn´ ych vláknech. Tyto instance maj´ı za u ´kol pˇrij´ımat stream, ˇsifrovat ho a pos´ılat na vˇsechny klienty, kteˇr´ı jsou uloˇzeni v pˇr´ısluˇsn´ ych seznamech (zaˇza´dali si o stream). V tˇechto seznamech se uchovávaj´ı IP adresy a porty klient˚ u, kde poslouchá jejich UDP server. Pokud jsou seznamy prázdné, pak nen´ı spuˇstˇen ani ffmpeg.exe ani vlákna UDP server˚ u.

Na stranˇe klienta je vˇzdy pouze jedna instance UDP serveru, jelikoˇz klient m˚ uˇze pˇrij´ımat vˇzdy maximálnˇe jeden stream. Zde má UDP server opaˇcnou roli neˇz na serveru. Pˇrij´ıman´ y stream deˇsifruje a pos´ılá ho na lokáln´ı port klienta, kde poslouchá pˇrehrávaˇc ffplay.exe, kter´ y pˇrijat´ y stream zobrazuje.

4.3.3

Pˇ resmˇ erov´ an´ı logu

Aby bylo moˇzné dále pracovat s detekovan´ ymi zmˇenami hlasitosti a obrazu, které jsou logovány, je nutné z´ıskat k tomuto logu pˇr´ıstup. Toho bylo dosaˇzeno pomoc´ı pipe, kde pro systém Windows byly pouˇzity pojmenované pipy (viz 12. ˇrádek v ukázce 4.3) a pro systém GNU/Linux obyˇcejné. D´ıky pipám je moˇzné log pˇresmˇerovat z v´ ystupu na konzoli ke zpracován´ı na server. Na serveru je pak pomoc´ı instance tˇr´ıdy Analysis, která bˇeˇz´ı v samostatném vláknu, nepˇretrˇzitˇe ˇcten a analyzován v´ ystup pipe (veˇsker´ y log, kter´ y ffmpeg.exe produkuje).

4.3.4

Detekce zmˇ en

Veˇskerá detekce zmˇen prob´ıhá na základˇe anal´ yzy pˇresmˇerovaného logu. Pro detekci zmˇeny hlasitosti jsou kl´ıˇcové ty ˇra´dky logu, kde se vyskytuje spojen´ı silence end, a pro detekci pohybu pak ˇrádky se slovem scene (viz kap. 3.3.6). V pˇr´ıpadˇe, ˇze je nalezen ˇra´dek se zmˇenou, jsou pomoc´ı signál˚ u uvˇedomˇeni vˇsichni klienti (vlákna na serveru spravuj´ıc´ı pˇripojené klienty). Pokud má dané vlákno, obsluhuj´ıc´ı klienta, zaznamenáno, ˇze klient (druhá ˇca´st aplikace) chce odeb´ırat zprávy o zmˇenách, pak mu poˇsle zprávu (viz kap. 4.2.4), jinak oznámen´ı ignoruje. Pro zas´ılán´ı signál˚ u informuj´ıc´ıch o detekci zvuku byl pouˇzit návrhov´ y vzor Observer.

Detekované zmˇeny pomoc´ı ffmpeg.exe jsou bez dalˇs´ıch zkoumán´ı pouˇzity jen v pˇr´ıpadˇe hlasitosti. Co se t´ yˇce detekce pohybu, z logu jsou vyextrahovány informace 51


Stream

o procentuáln´ı zmˇenˇe scény. Aˇz na serveru se pak urˇcuje, zda je tato zmˇena menˇs´ı (vˇetˇs´ı) neˇz zadaná mez. D´ıky tomu je také moˇzné mˇenit tuto mez pˇres webové rozhran´ı a zmˇena se hned projev´ı. To neplat´ı o zmˇenˇe meze pro hlasitost. Tu detekuje pˇr´ımo ffmpeg.exe, a proto je po jej´ı zmˇenˇe ve webovém rozhran´ı nutné nástroj ffmpeg.exe vypnout a znovu zapnout.

4.3.5


Pro pˇrehráván´ı streamu na stranˇe klienta byl zvolen nástroj ffplay.exe. Tento program se pod Windows spouˇst´ı v konzoli pomoc´ı ShellExecute, kde se nastaven´ım pˇr´ısluˇsného parametru zamez´ı zobrazen´ı konzolového okna. Pod systémy GNU/Linux se provede vytvoˇren´ı nového procesu (pomoc´ı fork ), a v tom je spuˇstˇen pˇrehrávaˇc (exec). Pˇrehrávaˇc pˇrij´ımá jiˇz deˇsifrovan´ y stream z lokáln´ıho portu klienta, kam je tento deˇsifrovan´ y stream pos´ılán.

Pˇrehráván´ı streamu nezaˇcne hned po zapnut´ı pˇrehrávaˇce. Je zde urˇcitá prodleva (cca 10 sekund), protoˇze pˇrehrávaˇci chv´ıli trvá, neˇz v pˇr´ıchoz´ım streamu nalezne potˇrebné informace pro pˇrehráván´ı. V pˇr´ıpadˇe velkého vyt´ıˇzen´ı procesoru se ztrác´ı i v´ıce UDP paket˚ u, a pak je nalezen´ı informac´ı o to obt´ıˇznˇejˇs´ı. Pokud do urˇcité doby informaci nenajde, pˇrehrávaˇc se ukonˇc´ı. Tato funkcionalita je zabudována pˇr´ımo v pˇrehrávaˇci. Stejnˇe tak se m˚ uˇze stát, ˇze je vypnut kv˚ uli nˇejaké chybˇe, která pˇri anal´ yze streamu nastala.

Pˇrehrávaˇc otev´ırá okno se streamem vˇzdy, i v pˇr´ıpadˇe, ˇze pˇrehrávan´ y stream je pouze audio. V tomto oknˇe se pak zobrazuje pr˚ ubˇeh zvukov´ ych vln. Existuje zde parametr nodisp, kter´ y zamez´ı otevˇren´ı okna, a doruˇcen´ y audio stream je pak moˇzné pouze poslouchat.

ffplay.exe obsahuje nˇekolik vnitˇrn´ıch pˇr´ıkaz˚ u pro ovládán´ı streamu, které jsou nezávislé na naˇs´ı aplikaci. Z tˇech, které funguj´ı, to jsou klávesy: • q, ESC - vypnut´ı pˇrehrávaˇce • f - pˇrepnut´ı na celou obrazovku • p, mezern´ık - pauza 52


Správa serveru

• s - procházen´ı videa rámec po rámci, pˇredt´ım se mus´ı zmáˇcknout pauza • ˇsipka doprava - posunut´ı na aktuáln´ı pozici v live streamu • w - pˇrepnut´ı na zobrazen´ı zvukov´ ych vln Pokud se ffplay.exe vypne pouˇzit´ım v´ yˇse uveden´ ych kláves, pˇrehrávaˇc se to nedozv´ı, a je nutné ho zastavit jeˇstˇe pˇr´ısluˇsn´ ym tlaˇc´ıtkem Stop. Pokud se pˇrehrávaˇc vyp´ıná pˇres tlaˇc´ıtko Stop, pak je proces ffplay.exe ukonˇcen pomoc´ı pˇr´ıkazu kill.

4.3.6

Ukl´ ad´ an´ı streamu

Jako rozˇs´ıˇren´ı aplikace bylo naprogramováno ukládán´ı pˇrehrávaného streamu do souboru na stranˇe klienta. Stream bylo moˇzné ukládat tak, jak pˇricházel na UDP server. Tato moˇznost se ale projevila jako nevyhovuj´ıc´ı, jelikoˇz soubor pak nebylo moˇzné pˇrehrát. Byla tedy zvolena jiná moˇznost a to pouˇzit´ı nástroje ffmpeg.exe . V pˇr´ıpadˇe, ˇze uˇzivatel zaˇskrtl ukládán´ı streamu do souboru, pak je deˇsifrovan´ y stream z UDP serveru pos´ılán jednak do ffplay.exe a jednak i na port, kde poslouchá ffmy ffmpeg.exe. (viz obr. 3.1) peg save file.exe, coˇz je pˇrejmenovan´

ffmpeg.exe pˇrevede stream z MPEG-TS na MPEG a uloˇz´ı ho do souboru s jedineˇcn´ ym jménem ve tvaru streamFile YYYY-mm-dd HH-MM-SS.mpg (napˇr. streamFile 2014-04-24 10-52-59.mpg). ffmpeg.exe je vypnut po stisku tlaˇc´ıtka Stop. Stream je moˇzné ukládat jen v pˇr´ıpadˇe, ˇze je zapnuté souvislé pˇrehráván´ı, ne pˇri zmˇenách.

4.4

Spr´ ava serveru

Správa serveru prob´ıhá pˇres webové rozhran´ı, které je pˇr´ıstupné pˇres IP adresu serveru a port 9443. Na tomto portu poslouchá instance tˇr´ıdy Web interface, která má za u ´kol pˇrij´ımat nové klienty pomoc´ı protokolu HTTPS, k jehoˇz implementaci pouˇz´ıvá knihovnu OpenSSL (viz [21]). Tato instance um´ı téˇz filtrovat pˇr´ıchoz´ı klienty podle toho, zda patˇr´ı do stejné pods´ıtˇe, jako server. Toto se dˇeje na základˇe odmaskován´ı klientovi IP adresy a porovnán´ı v´ ysledku s IP pods´ıtˇe serveru (viz pˇr´ıklad 3.2) [6].

53


Správa serveru

Kaˇzd´ y pˇr´ıchoz´ı klient dostává pˇridˇeleno vlákno, ve kterém se obslouˇz´ı jeho jeden poˇzadavek a vlákno poté zaniká. Vzhledem k tomu, ˇze klienti se do webového rozhran´ı mus´ı pˇrihlásit, je d˚ uleˇzité si nˇejak´ ym zp˚ usobem zaznamenávat, kteˇr´ı jiˇz maj´ı schválen´ y pˇr´ıstup a kteˇr´ı nikoliv. Toho bylo dosaˇzeno pomoc´ı coockie. Pˇri prvn´ım poˇzadavku klienta (webového prohl´ıˇzeˇce) na stránku rozhran´ı se vygeneruje jedineˇcné identifikaˇcn´ı ˇc´ıslo, které je vloˇzeno do HTTPS hlaviˇcky, která se spolu s HTML kódem stránky pos´ılá zpˇet klientovi. Klient si toto ˇc´ıslo uloˇz´ı a pˇri kaˇzdém dalˇs´ım poˇzadavku se prokazuje t´ımto ˇc´ıslem.

Pokud se klient u ´spˇeˇsnˇe pˇrihlás´ı do rozhran´ı (pro pˇr´ıstup je jen jedno spoleˇcné heslo), pak je jeho ˇc´ıslo zaˇrazeno do seznamu pˇrihláˇsen´ ych (ovˇeˇren´ ych). Pˇri kaˇzdém dalˇs´ım poˇzadavku na stránku se mus´ı kontrolovat, zda je uˇzivatel jiˇz pˇrihláˇsen a má tedy právo na zobrazen´ı dané stránky. Po odhláˇsen´ı se identifikátor smaˇze ze seznamu pˇrihláˇsen´ ych.

HTML kód, kter´ y se pˇrenáˇs´ı na klienta, je pˇredpˇripraven a uloˇzen v promˇenn´ ych v redukované podobˇe. T´ım je dosaˇzeno zmenˇsen´ı objemu pˇrenáˇsen´ ych dat na u ´kor pˇrehlednosti kódu. HTML kód totiˇz d´ıky kompresi neobsahuje ˇzádné pˇrebyteˇcné mezery nebo odˇrádkován´ı.

4.4.1

Registrace

Pokud se klient u ´spˇeˇsnˇe pˇrihlás´ı do webového rozhran´ı, má moˇznost pˇridat nového uˇzivatele. Za t´ımto u ´ˇcelem existuje na stránce https://:9443/user.html formuláˇr. Tento formuláˇr obsahuje dvˇe textová pole, jedno pro uˇzivatelské jméno a druhé pro heslo. Obˇe dvˇe pole maj´ı omezen´ y poˇcet znak˚ u na 6-50 vˇcetnˇe a omezenou mnoˇzinu pouˇziteln´ ych symbol˚ u (a-z A-Z 0-9 * .-).

Vyplnˇené u ´daje jsou poslány na server, kde se kontroluje, zda uˇz takové uˇzivatelské jméno existuje, pokud ano, uˇzivatel se nepˇridá. Pokud se jedná o nového uˇzivatele, pak je uloˇzen jednak do seznamu registrovan´ ych uˇzivatel˚ u, kter´ y je pˇr´ıstupn´ y po celou dobu bˇehu serveru, a je tedy moˇzné novˇe registrované u ´daje hned pouˇz´ıt k pˇrihláˇsen´ı, a jednak do souboru, kde jsou uloˇzeni vˇsichni registrovan´ı uˇzivatelé.

54


Správa serveru

Soubor s registrovan´ ymi uˇzivateli obsahuje trojice jméno-s˚ ul-verifier. Po pˇridán´ı nového uˇzivatele se obsah souboru smaˇze. Následnˇe se vytvoˇr´ı z registrovan´ ych uˇzivatel˚ u, uloˇzen´ ych v seznamu, zaˇsifrovan´ y obsah, kter´ y je pak uloˇzen do souboru. Obsah souboru je vˇzdy pˇri startu serveru naˇcten do pamˇeti (do seznamu), aby byl umoˇznˇen rychl´ y pˇr´ıstup v pˇr´ıpadˇe pˇrihlaˇsován´ı klienta k odbˇeru streamu.

Na stránce, kde je formuláˇr pro pˇridán´ı klient˚ u, je i tlaˇc´ıtko na jejich smazán´ı. Soubor s klienty pak po stisknut´ı tlaˇc´ıtka bude prázdn´ y. Dále je zde pro vˇetˇs´ı pˇrehlednost uveden i seznam registrovan´ ych klient˚ u (pouze jména).

Certifik´ at Aby bylo moˇzné pouˇz´ıvat HTTPS protokol, mus´ı m´ıt server vlastn´ı certifikát. Pro naˇse u ´ˇcely byl zvolen pouze self-signed certifikát (viz kap. 3.2.1). Tento certifikát je moˇzné vygenerovat pomoc´ı knihovny OpenSSL podle ukázky 4.4. V ukázce byl certifikát vytvoˇren pod systémem Windows, ale stejn´ y postup by se aplikoval i pod systémy GNU/Linux.

1: genrsa -out private.pem 2048 2: req -config C:\path-to\openssl.cnf -x509 -days 3650 -new -key private.pem -out public.pem 3: pkcs12 -export -in public.pem -inkey private.pem -out mycert.pfx (4.4) Na prvn´ım ˇra´dku je vygenerován RSA privátn´ı kl´ıˇc o délce 2048 bit˚ u. Na druhém ˇra´dku je vytvoˇren certifikát public.pem ve formátu x509 s expiraˇcn´ı dobou 10 let od data vytvoˇren´ı. Tento certifikát se bude webov´ ym prohl´ıˇzeˇc˚ um jevit jako ned˚ uvˇeryhodn´ y. Tomu se lze vyhnout instalac´ı certifikátu do systému nebo prohl´ıˇzeˇc˚ u. Instalaˇcn´ı certifikát se v pˇr´ısluˇsném formátu vytvoˇr´ı pomoc´ı tˇret´ıho ˇrádku. Server pak pouˇz´ıvá soubory public.pem a private.pem.

55


4.4.2

Grafické rozhran´ı

Ukl´ ad´ an´ı hodnot

Ve webovém rozhran´ı je i kromˇe pˇridáván´ı klient˚ u moˇzné mˇenit i nastaven´ı serveru, parametr˚ u streamu a parametr˚ u pro detekci zmˇen. Vˇsechny tyto hodnoty jsou uchovávány v souborech (avoption, avset, server ). Tyto soubory nejsou nijak ˇsifrovány. Kromˇe tˇechto soubor˚ u jsou na serveru jeˇstˇe ty samé soubory s pˇr´ıponou o, které uchovávaj´ı origináln´ı nastaven´ı vˇsech nastaviteln´ ych hodnot. Tyto hodnoty je moˇzné opˇet nastavit pomoc´ı tlaˇc´ıtka Original settings u pˇr´ısluˇsn´ ych formuláˇr˚ u pro zmˇenu hodnot parametr˚ u. Po stisku se hodnoty z origináln´ıho souboru pˇrekop´ıruj´ı do pˇr´ısluˇsného souboru s nastaven´ım.

Na stránce pro zmˇenu parametr˚ u streamu je textové pole, do kterého je moˇzné zadat cel´ y pˇr´ıkaz pro FFmpeg, kter´ y se pak beze zmˇen spust´ı pˇri dalˇs´ım vyˇza´dán´ı streamu. Tato funkcionalita byla vytvoˇrena pro zkuˇsené uˇzivatele, kteˇr´ı vˇed´ı, co dˇelaj´ı. Uloˇzen´ y pˇr´ıkaz se bude zap´ınat do té doby, neˇz dojde k restartován´ı serveru. Pokud se uloˇz´ı prázdné pole m´ısto pˇr´ıkazu, bude se pro z´ıskáván´ı streamu opˇet pouˇz´ıvat ten napevno zadan´ y.

Zmˇena nastaven´ı port˚ u serveru je dostupná aˇz po restartu serveru. Stejnˇe tak zmˇeny parametr˚ u streamu jsou aplikovány aˇz na dalˇs´ı spuˇstˇen´ı nástroje ffmpeg.exe, jak bylo jiˇz nˇekolikrát zmiˇ nováno.

4.5

Grafick´ e rozhran´ı

Kv˚ uli jednoduˇsˇs´ımu ovládán´ı pro uˇzivatele bylo na stranˇe klienta vytvoˇreno grafické rozhran´ı. Pro grafick´ y vzhled pˇrehrávaˇce byly pouˇzity Qt knihovny (v´ıce [24]). Uˇzivateli se nejdˇr´ıve zobraz´ı pˇrihlaˇsovac´ı okno (viz kap. 4.2.1 a obr. P 1), a pak okno pˇrehrávaˇce (viz obr. P 2) obsluhované tˇr´ıdou Main window. Jednotlivá tlaˇc´ıtka pˇrehrávaˇce jsou mezi sebou svázána pomoc´ı signál˚ u, které poskytuje Qt. D´ıky tomu je moˇzné znepˇr´ıstupnit uˇzivateli nˇekteré nesmyslné kombinace, které by mohl zadat (napˇr. nechat si pos´ılat stream jen pˇri zmˇenách, ale uˇz se nepˇrihlásit k ˇza´dnému odbˇeru zmˇen). Stejnˇe tak je po stisku zablokováno tlaˇc´ıtko Play a odblokováno je aˇz po tom, co se stiskne Stop. Tato funkcionalita zabraˇ nuje uˇzivateli vyˇza´dán´ı dalˇs´ıho streamu, dokud ten pˇredchoz´ı neukonˇc´ı.

56


Konzolové rozhran´ı

Podle toho, co uˇzivatel zaˇskrtá na panelu pˇrehrávaˇce, se pak spust´ı stream. Pokud se má stream zaˇc´ıt pˇrehrávat hned, na server se poˇsle jak zpráva s ˇzádost´ı o ˇsifrovac´ı kl´ıˇc, tak zpráva se zaˇrazen´ım klienta do seznamu, kterému je stream pos´ılán. V pˇr´ıpadˇe zap´ınán´ı streamu aˇz pˇri zmˇenˇe, se poˇsle pouze zpráva s ˇzádost´ı o kl´ıˇc a zpráva s portem, kde poslouchá klientsk´ y UDP server, se poˇsle aˇz kdyˇz klient obdrˇz´ı zprávu o zmˇenˇe obrazu/hlasitosti. V pˇr´ıpadˇe zap´ınán´ı pˇrehráván´ı streamu aˇz pˇri zmˇenˇe je spuˇstˇen odpoˇcet (v samostatném vláknˇe) a pokud nepˇrijde dalˇs´ı zpráva indikuj´ıc´ı zmˇenu, neˇz odpoˇcet skonˇc´ı, okno se streamem se zavˇre. Jinak se odpoˇcet nastaven´ı opˇet na v´ ychoz´ı hodnotu a zaˇc´ıná se odpoˇc´ıtávat znovu.

Pˇrehrávaˇc umoˇzn ˇuje zobrazován´ı zpráv o zmˇenách v oznamovac´ı oblasti (system tray) u své ikony (viz obr. P 4). Aby se tˇr´ıda Main window dozvˇedˇela, ˇze byla pˇrijata zpráva indikuj´ıc´ı zmˇenu, mus´ı b´ yt zaregistrována k odbˇeru oznámen´ı pomoc´ı signál˚ u. Signály jsou generovány tˇr´ıdou Communication, která spravuje pˇr´ıjem zpráv od serveru. Stejnˇe jako na serveru, i zde byl pouˇzit návrhov´ y vzor Observer.

Kromˇe signál˚ u o zmˇenách se zde pos´ılaj´ı i signály indikuj´ıc´ı ukonˇcen´ı serveru (nebo chybu pˇrenosu). Pokud je server ukonˇcen, je potˇreba vypnout pˇrehrávaˇc, aby klient zbyteˇcnˇe neˇcekal na nˇeco, co nenastane. V pˇr´ıpadˇe selhán´ı funkce, která pˇrij´ımá zprávy od serveru, nebo obdrˇzen´ı ukonˇcovac´ı zprávy serveru, se nejdˇr´ıve provede ukonˇcen´ı vˇsech bˇeˇz´ıc´ıch vláken, a nakonec se zobraz´ı dialogové okno, které informuje o ukonˇcen´ı serveru a ukonˇcen´ı aplikace. Po objeven´ı tohoto okna jiˇz nen´ı moˇzné cokoliv na pˇrehrávaˇci zadat a je moˇzné ho pouze ukonˇcit.

4.6

Konzolov´ e rozhran´ı

Server byl vytvoˇren jako konzolová aplikace. Nastaven´ı serveru je moˇzné spravovat pˇres webové rozhran´ı, a pˇres konzoli je moˇzné ho, zadán´ım pˇr´ıkazu quit, legálnˇe ukonˇcit. Toto ukonˇcen´ı bylo implementováno proto, aby vˇsechna bˇeˇz´ıc´ı vlákna mohla b´ yt regulérnˇe ukonˇcena. Kv˚ uli pouˇzit´ ym timeout˚ um na funkc´ıch select(), nen´ı ukonˇcen´ı serveru okamˇzité, ale trvá pár sekund. Kromˇe vláken obsluhuj´ıc´ıch klienty a UDP servery se mus´ı ukonˇcit i extern´ı programy ffmpeg.exe a mdns server.exe.

Do konzole, kde bˇeˇz´ı server, je vypisován log. Tento log je urˇcen sp´ıˇse programátor˚ um neˇz bˇeˇzn´ ym uˇzivatel˚ um aplikace. Log se kromˇe konzole ukládá i do souboru

57


Konzolové rozhran´ı

LOG SERVER, kam je stále pˇridáván. Logován´ı je moˇzné programovˇe vypnout ve tˇr´ıdˇe Log, kde staˇc´ı zmˇenit direktivu #define na #undef u definovan´ ych maker LOG FILE a LOG TERMINAL.

Stejn´ y princip logován´ı je vytvoˇren i v programu klienta s t´ım rozd´ılem, ˇze log se zapisuje pouze do souboru.

58

5 Namˇeˇrené hodnoty V této kapitole budou uvedeny hodnoty, které byly zmˇeˇreny bˇehem testován´ı aplikace. Webové rozhran´ı bylo otestováno v prohl´ıˇzeˇc´ıch Opera 12.16, Mozilla Firefox 28.0, Internet Explorer 11 a Google Chrome 33.0.1750.154 m.

5.1

Vyuˇ zit´ı ˇ s´ıˇ rky p´ asma

D˚ uleˇzit´ ym faktorem je vyuˇzit´ı ˇs´ıˇrky pásma. Aplikace byla spuˇstˇena nˇekolika zp˚ usoby, a vˇzdy byly zaznamenány hodnoty odes´ılan´ ych a pˇrij´ıman´ ych dat v B/s u jednotliv´ ych ˇcást´ı aplikace. V´ ysledky jsou uvedeny v tabulce 5.1. Pro nastaven´ı streamu byly pouˇzity v´ ychoz´ı hodnoty (rozliˇsen´ı = 800x600, bit rate = 282 000 b/s, mono, audio frekvence = 16 000Hz, poˇcet rámc˚ u/s = 25, kvalita = 9) a nebylo vyˇzádáno pos´ılán´ı zpráv pˇri zmˇenˇe. DP-server.exe je program serveru a DP-client.exe je program klienta.

Z namˇeˇren´ ych hodnot je vidˇet, ˇze typ pˇrenáˇseného streamu nemá ˇzádn´ y vliv na mnoˇzstv´ı pˇrenesen´ ych dat z ffmpeg.exe, jelikoˇz se spouˇst´ı stále stejn´ y pˇr´ıkaz, ve kterém jsou 2 v´ ystupn´ı streamy. Dále je vidˇet pokles mnoˇzstv´ı pˇrenáˇsen´ ych dat, pokud se m´ısto audia+videa pˇrenáˇs´ı pouze audio. Zaj´ımavé srovnán´ı poskytuj´ı ˇrádky 5 a 6, kde na ˇra´dku 5 byl puˇstˇen stream s nejvyˇsˇs´ı kvalitou a na ˇra´dku 6 naopak s nejniˇzˇs´ı. Objem odeslan´ ych dat je u vˇsech program˚ u o v´ıce neˇz polovinu menˇs´ı. Kromˇe ffmpeg.exe, zde doˇslo pouze k cca tˇretinovému sn´ıˇzen´ı.

5.2

Vyuˇ zit´ı pamˇ eti

Dalˇs´ım faktorem, kter´ y je mˇeˇriteln´ y, je vyuˇzit´ı operaˇcn´ı pamˇeti jednotliv´ ymi ˇcástmi aplikace (viz tabulka 5.2). Tato mˇeˇren´ı prob´ıhala ve stejnou dobu jako v´ yˇse zm´ınˇe mˇeˇren´ı pˇrenáˇsen´ ych dat. Z namˇeˇren´ ych hodnot jsou vidˇet vˇetˇs´ı poˇzadavky na pamˇet’ v pˇr´ıpadˇe pˇrehráván´ı audia+videa pomoc´ı ffplay.exe. Na ˇrádc´ıch 5 a 6 jsou obrovské rozd´ıly, co se t´ yˇce vyuˇzit´ı pamˇeti nástrojem ffmpeg.exe, kter´ y pˇri nastaven´ı nejvyˇsˇs´ı kvality videa spotˇrebovává 6x v´ıce pamˇeti neˇz pˇri nejniˇzˇs´ı kvalitˇe. Stejnˇe tak program ffplay.exe potˇrebuje pro kvalitnˇejˇs´ı stream mnohem v´ıce pamˇeti.

59

Namˇeˇrené hodnoty

5.3

Pˇrehráván´ı streamu


Stream, kter´ y je na stranˇe klienta zobrazován, je asi o 3 vteˇriny pozadu oproti realitˇe. Menˇs´ı prodlevy se podaˇrilo dosáhnout pouˇzit´ım parametru -tune zerolatency u z´ıskáván´ı streamu, ale pak docházelo k neˇza´douc´ımu ruˇsen´ı obrazu v podobˇe barevn´ ych prouˇzk˚ u v doln´ı ˇca´sti obrazovky (viz obr. 5.1) nebo k u ´plnému rozhozen´ı obrazu, ˇze pak nebylo v˚ ubec poznat, co se sn´ımá. Na stranˇe klienta se pˇr´ıchoz´ı data nebufferuj´ı, coˇz sn´ıˇzilo prodlevu oproti realitˇe o asi 10 sekund.

Pˇresto, ˇze docház´ı k obˇcasnému malému ruˇsen´ı v doln´ı ˇca´sti obrazu, je jeho kvalita dobrá. Ruˇsen´ı zmiz´ı, pokud se pˇred kamerou mávne (dojde t´ım k velké zmˇenˇe a FFmpeg poˇsle cel´ y nov´ y I-rámec). Bylo zjiˇstˇeno, ˇze ruˇsen´ı obrazu je menˇs´ı pˇri pouˇzit´ı 30 sn´ımk˚ u/s m´ısto 25, které jsou nastaveny jako v´ ychoz´ı hodnota. Zvuk s obrazem je synchronizován.

Pˇri testován´ı aplikace doˇslo k tomu, ˇze nˇekterá zaˇr´ızen´ı (Windows 7 Professional, 64 b) nepropustila pˇres sv˚ uj Firewall data streamu. Nepomohlo ani zapnut´ı pˇrenosu pouze audio streamu. Po vypnut´ı Firewallu aplikace normálnˇe fungovala. Firewall byl pouze systémov´ y.

Obr. 5.1: Neˇzádouc´ı ruˇsen´ı obrazu. 60



Spuˇstˇen´ı

1

Klient si vyˇzádal souvislé pˇrehráván´ı streamu (video + audio).

2

Klient si vyˇzádal souvislé pˇrehráván´ı streamu (audio).

3

Klient si vyˇzádal souvislé pˇrehráván´ı streamu (video + audio) a ukládán´ı streamu do souboru.

4

Klient si vyˇzádal souvislé pˇrehráván´ı streamu (audio) a ukládán´ı streamu do souboru.

5

6

Pˇr´ıjem [B/s] DP-server.exe 51 196 DP-client.exe 36 771 ffmpeg.exe 0 ffplay.exe 48 316 mdns server.exe 5 DP-server.exe 59 164 DP-client.exe 17 681 ffmpeg.exe 0 ffplay.exe 18 749 mdns server.exe 5 DP-server.exe 60 260 DP-client.exe 42 911 ffmpeg.exe 0 ffplay.exe 44 795 mdns server.exe 5 ffmpeg save file.exe 44 778 DP-server.exe 48 577 DP-client.exe 14 785 ffmpeg.exe 0 ffplay.exe 19 273 mdns server.exe 5 ffmpeg save file.exe 19 273 DP-server.exe 30 809 DP-client.exe 38 319 ffmpeg.exe 0 ffplay.exe 50 047 DP-server.exe 10 890 DP-client.exe 16 204 ffmpeg.exe 0 ffplay.exe 23 939 Program

#

Klient si vyˇzádal souvislé pˇrehráván´ı streamu (video + audio) v nejvyˇsˇs´ı kvalitˇe. Klient si vyˇzádal souvislé pˇrehráván´ı streamu (video + audio) v nejniˇzˇs´ı kvalitˇe.

Tab. 5.1: Vyuˇzit´ı ˇs´ıˇrky pásma programy.

61

Odeslán´ı [B/s] 36 771 36 237 66 777 0 5 17 681 17 460 64 125 0 5 42 911 84 703 62 533 0 5 0 14 785 29 211 63 762 0 5 0 22 449 37 187 68 390 0 6 219 15 978 41 837 0



Spuˇstˇen´ı

1

Klient si vyˇzádal souvislé pˇrehráván´ı streamu (video + audio).

2

Klient si vyˇzádal souvislé pˇrehráván´ı streamu (audio).

3

Klient si vyˇzádal souvislé pˇrehráván´ı streamu (video + audio) a ukládán´ı streamu do souboru.

4

Klient si vyˇzádal souvislé pˇrehráván´ı streamu (audio) a ukládán´ı streamu do souboru.

5

6

Vyuˇzit´ı pamˇeti [kB ] DP-server.exe 2 132 DP-client.exe 8 100 ffmpeg.exe 147 516 ffplay.exe 35 616 mdns server.exe 1 412 DP-server.exe 7 832 DP-client.exe 2 196 ffmpeg.exe 146 489 ffplay.exe 8 196 mdns server.exe 1 352 DP-server.exe 2 200 DP-client.exe 7 680 ffmpeg.exe 145 500 ffplay.exe 31 576 mdns server.exe 1 352 ffmpeg save file.exe 38 064 DP-server.exe 2 172 DP-client.exe 7 668 ffmpeg.exe 141 952 ffplay.exe 7 188 mdns server.exe 1 448 ffmpeg save file.exe 3 620 DP-server.exe 2 376 DP-client.exe 7 620 ffmpeg.exe 440 384 ffplay.exe 122 568 DP-server.exe 2 544 DP-client.exe 7 684 ffmpeg.exe 70 328 ffplay.exe 17 164 Program

#

Klient si vyˇzádal souvislé pˇrehráván´ı streamu (video + audio) v nejvyˇsˇs´ı kvalitˇe. Klient si vyˇzádal souvislé pˇrehráván´ı streamu (video + audio) v nejniˇzˇs´ı kvalitˇe.

Tab. 5.2: Vyuˇzit´ı pamˇeti program˚ u.

62

6 Závˇer Pˇrestoˇze je v dneˇsn´ı dobˇe na trhu dostupné nepˇreberné mnoˇzstv´ı dˇetsk´ ych ch˚ uviˇcek, ne vˇsechny jsou pouˇzitelné, at’ uˇz proto, ˇze se ruˇs´ı s WiFi s´ıt´ı nebo proto, ˇze neposkytuj´ı ˇsifrovan´ y pˇrenos dat, kter´ y je d˚ uleˇzit´ y pro bezpeˇcnost a ochranu soukrom´ı jejich uˇzivatel˚ u. Tato práce se tedy zab´ yvá anal´ yzou souˇcasn´ ych ˇreˇsen´ı ch˚ uviˇcek, jejich nedostatk˚ u i pˇrednost´ı. Na základˇe této anal´ yze jsou pak stanoveny poˇzadavky na novou ch˚ uviˇcku, která má za u ´kol odstranit 2 hlavn´ı nedostatky, a to ruˇsen´ı s WiFi s´ıt´ı a ˇsifrován´ı pˇrenosu (audia, videa).

Byly tak vytvoˇreny dva programy, které ke své vzájemné komunikaci vyuˇz´ıvaj´ı jiˇz zavedené internetové spojen´ı. Jedn´ım z tˇechto program˚ u je server, kter´ y mus´ı bˇeˇzet na zaˇr´ızen´ı, které obsahuje kameru a mikrofon, a je tedy urˇcen ke sledován´ı d´ıtˇete. Naopak druh´ y program - klient mus´ı b´ yt spuˇstˇen na zaˇr´ızen´ı s monitorem a reproduktory a slouˇz´ı jako druhá ˇca´st ch˚ uviˇcky, kterou u sebe maj´ı rodiˇce.

Na klientovi je tedy moˇzné sledovat bud’ audio nebo audio+video stream, kter´ y je odchytáván v pokoji d´ıtˇete. Kromˇe toho je moˇzné zapnout i detekci pohybu a hlasitosti. Kdyˇz zaˇcne d´ıtˇe breˇcet nebo se probud´ı a zaˇcne se snaˇzit dostat z post´ ylky, rodiˇc o tom dostane zprávu, která se po urˇcitou dobu zobrazuje v oznamovac´ı oblasti. Pokud se stane, ˇze se po dobu zobrazen´ı zprávy rodiˇc zrovna nesledoval monitor, pak je moˇzné si nechat posledn´ı událost zobrazit kliknut´ım na ikonu klienta. Pˇrehrávan´ y stream je moˇzné ukládat do souboru.

Oba programy (klient, server) spolu komunikuj´ı pomoc´ı ˇsifrovaného spojen´ı, a téˇz stream, kter´ y je pos´ılán ze serveru klientovi, je zaˇsifrovan´ y. Pro snadnˇejˇs´ı nastaven´ı serveru bylo implementováno webové rozhran´ı, kde je moˇzné nastavit jak parametry serveru (porty), tak i parametry pˇrenáˇseného streamu (rozliˇsen´ı, kvalita videa atd.). Toto nastaven´ı je spoleˇcné pro vˇsechny klienty, kteˇr´ı se na server pˇripoj´ı a odeb´ıraj´ı stream. Kaˇzd´ y klient zvláˇst’ si ale m˚ uˇze vybrat, zda chce sledovat audio, audio+video, o jak´ ych zmˇenách bude informován, a zda se bude stream pˇrehrávat hned od zaˇca´tku nebo jen po urˇcitou dobu pˇri kaˇzdé detekci zmˇeny.

Práce splˇ nuje vˇsechny body zadán´ı, které byly stanoveny. Kromˇe jiˇz implementovan´ ych souˇcást´ı by bylo moˇzné práci rozˇs´ıˇrit o dalˇs´ı funkcionality, které by server/klient nab´ızel (napˇr. zobrazován´ı streamu z v´ıce kamer najednou). 63

Literatura [1] A forum dedicated to FFmpeg on Windows. In: Zeranoe FFmpeg [online]. 2013 [cit. 2014-04-26]. Dostupné z : . [2] An MPEG frame sequence with two possible references: a P-frame referring to a I-frame and a B-frame referring to two P-frames. Video Compression [online]. MITROVIC, Djordje.. 2006 [cit. 2014-04-15]. Dostupné z : . [3] ANDERS, Jörg. MPEG video compression technique [online]. 2007 [cit. 2014-04-18]. Dostupné z : . [4] Announcing the ADVANCED ENCRYPTION STANDARD. In: Federal Information Processing Standards Publication 197 [online]. 2001 [cit. 201404-15]. Dostupné z : . [5] ARORA, Mohit. How secure is AES against brute force attacks?. In: Design How-To [online]. 2012 [cit. 2014-04-17]. Dostupné z : . [6] C++ - Check an IP Address is in a IP/Mask range. In: Random Stuff from a software developer [online]. 2012 [cit. 2014-04-21]. Dostupné z : . [7] Demonstration of visual cryptanalysis of the Data Encryption Standard’s ECB mode. Security data visualization. CONTI, Greg. San Francisco: Starch Press, Inc. 2007. ISBN-13: 978-1-59327-143-5.

64

Literatura [8] Depending on the subsampling, 2 or 4 pixel values of the chrominance channel can be grouped together. Video Compression [online]. MITROVIC, Djordje.. 2006 [cit. 2014-04-15]. Dostupné z : . ´ ´ Velký pr˚ [9] DOSTALEK, Libor a Alena KABELOVA. uvodce protokoly TCP/IP a systémem DNS Praha: Computer Press, 2000. ISBN 80-7226-323-4. [10] DWORKIN, Morris. Recommendation for Block Cipher Modes of Operation. In: NIST Special Publication 800-38A [online]. 2001 [cit. 2014-04-15]. Dostupné z : . [11] FAIRHURST, Gorz. MPEG-2 Transmission. In: MPEG-2 Digital Video [online]. 2001 [cit. 2014-04-17]. Dostupné z : . [12] FFmpeg [online]. 2014 [cit. 2014-04-17]. Dostupné z : . [13] FORRET, Peter. Video bitrate calculator. In: Web.forret.com [online]. 2014 [cit. 2014-04-18]. Dostupné z : . [14] FREIER, A. a P. KARLTON. The Secure Sockets Layer (SSL) Protocol Version 3.0. In: IETF Documents [online]. 2011 [cit. 2014-04-13]. ISSN 20701721. Dostupné z : . [15] CHANDRA, Pravir, Matt MESSIER a John VIEGA. Network Security with OpenSSL. O’Reilly, 2002. ISBN 0-596-00270-X. [16] CHESHIRE, S. KROCHMAL, M. Multicast DNS. In: Internet Engineering Task Force (IETF) [online]. 2013 [cit. 2014-04-15]. Dostupné z : . [17] KERN, Christoph, Anita KESAVAN a Neil DASWANI. Foundations of Security: What Every Programmer Needs to Know. New York: SpringerVerlag New York, 2007. ISBN 978-1590597842. [18] Levels of Noise In decibels (dB). In: American Academy of Audiology [online]. 2009 [cit. 2014-04-15]. Dostupné z : .

65

Literatura [19] MITROVIC, Djordje. Video Compression [online]. 2006 [cit. 2014-04-15]. Dostupné z : . [20] MP3 (MPEG Layer III Audio Encoding). Sustainability of Digital Formats [online]. 2012 [cit. 2014-04-18]. Dostupné z : . [21] OpenSSL: The Open Source toolkit for SSL/TLS [online]. 2014 [cit. 201404-18]. Dostupné z : . [22] POSIX Threads for Win32. In: Pthreads w32 [online]. 2012 [cit. 2014-04-15]. Dostupné z : . [23] Pseudo Code for Key Expansion. In: Announcing the ADVANCED ENCRYPTION STANDARD [online]. Federal Information Processing Standards Publications . 2001 [cit. 2014-04-15]. Dostupné z : . [24] Qt Project [online]. 2014 [cit. 2014-04-24]. Dostupné z : project.org/>.

[25] RESCORLA, E. HTTP Over TLS. IETF Documents [online]. 2000 [cit. 2014-04-13]. Dostupné z : . [26] ShiftRows() cyclically shifts the last three rows in the State. In: Announcing the ADVANCED ENCRYPTION STANDARD [online]. Federal Information Processing Standards Publications . 2001 [cit. 2014-04-15]. Dostupné z : . [27] STEVENS, Marc. Single-block collision attack on MD5. In: Cryptology Group, CWI [online]. 2011 [cit. 2014-04-15]. Dostupné z : . [28] SubBytes() applies the S-box to each byte of the State. In: Announcing the ADVANCED ENCRYPTION STANDARD [online]. Federal Information Processing Standards Publications . 2001 [cit. 2014-04-15]. Dostupné z : . ˇ [29] SLECHTA, Pavel. C++ library implementing The Stanford Secure Remote Password Protocol - SRP (SRP6a) [online]. 2012 [cit. 2014-04-21]. Dostupné z : .

66

Literatura [30] The CBC Mode. In: NIST Special Publication 800-38A [online]. DWORKIN, Morris. 2001 [cit. 2014-04-15]. Dostupné z : . [31] The CFB Mode. In: NIST Special Publication 800-38A [online]. DWORKIN, Morris. 2001 [cit. 2014-04-15]. Dostupné z : . [32] TAN, Darell. Publishing Services over mDNS in C In: Adventures of an electronics & software guy [online]. 1997 [cit. 2014-04-15]. Dostupné z : . [33] TANENBAUM, ANDREW S. a DAVID J. WETHERALL. Computer Networks. 5. vyd. New Jersey: Prentice Hall, 2010. ISBN 978-0132126953. [34] WANG, Xiaoyun. YU, Hongbo. How to break MD5 and other hash functions. Advances in Cryptology [online]. 2005 [cit. 2014-04-15]. Dostupné z : . [35] wiki: Creating multiple outputs. In: FFmpeg [online]. 2014 [cit. 2014-04-19]. Dostupné z : . [36] WU, Thomas. SRP-6: Improvements and Refinements to the Secure Remote Password Protocol. In: Submission to the IEEE P1363 Working Group [online]. 2002 [cit. 2014-04-15]. Dostupné z : . [37] WU, Thomas. The secure remote password protocol. In: Internet Society Network and Distributed System Security Symposium [online]. 1997 [cit. 201404-15]. Dostupné z : .

67

Pˇ r´ılohy

68

Uˇ zivatelsk´ a pˇ r´ıruˇ cka Aplikace se skládá ze dvou ˇca´st´ı, serveru a klienta. Server mus´ı b´ yt spuˇstˇen na zaˇr´ızen´ı, na kterém je kamera a mikrofon (u d´ıtˇete), a klient na zaˇr´ızen´ı s monitorem a reproduktory (u rodiˇc˚ u). Aplikace byla primárnˇe vytvoˇrena pod systémem Windows 7, ale je ji moˇzné pˇreloˇzit i pod systémem Debian (pokud je na nˇem nainstalováno Qt a OpenSSL). Pod Windows je nutné m´ıt nainstalován DirectShow (pro pˇreklad aplikace i Qt a OpenSSL).

Instalace Pod systémy Windows je moˇzné pouˇz´ıt instalaˇcn´ı bal´ıˇcek, kter´ y provede nainstalován´ı programu. Pˇri instalaci jsou pˇrekop´ırovány vˇsechny potˇrebné soubory do sloˇzky, kterou si uˇzivatel vybere. Po nainstalován´ı je jeˇstˇe moˇzné vytvoˇrit zástupce, a toho um´ıstit napˇr. na plochu. Pro server a klienta je tento postup trochu odliˇsn´ y. Instalaˇcn´ı soubory se nacház´ı ve sloˇzkách install pro server i klienta. Pokud se nedodrˇz´ı pokyny n´ıˇze, programy sice p˚ ujdou spustit, ale nebudou fungovat vˇsechny jejich souˇcásti.

Server Postup pro nainstalován´ı serveru je následuj´ıc´ı: 1. Spustit soubor server/install/server setup.exe. 2. Postupovat podle pokyn˚ u na obrazovce. 69

Pˇr´ılohy 3. Po dokonˇcen´ı instalace je moˇzné vytvoˇrit zástupce na ploˇse. 4. Pˇrem´ıstˇete se do sloˇzky, kam se program nainstaloval, a prav´ ym tlaˇc´ıtkem kliknˇete na soubor DP-server.exe a zvolte Odeslat → Plocha(vytvoˇrit zástupce). 5. Pokud byl program nainstalován do Program Files, pak je nutné spouˇstˇet tohoto zástupce vˇzdy jako administrátor. 6. Pokud byl program nainstalován jinam, je moˇzné ho spouˇstˇet normálnˇe.

Klient Postup pro nainstalován´ı klienta je následuj´ıc´ı: 1. Spustit soubor klient/install/client setup.exe. 2. Postupovat podle pokyn˚ u na obrazovce. 3. Po dokonˇcen´ı instalace je moˇzné vytvoˇrit zástupce na ploˇse. 4. Pˇrem´ıstˇete se do sloˇzky, kam se program nainstaloval, a prav´ ym tlaˇc´ıtkem kliknˇete na soubor DP-server.exe a zvolte Odeslat → Plocha(vytvoˇrit zástupce). 5. Nen´ı nutné spouˇstˇet tento program jako administrátor.

Spuˇ stˇ en´ı Programy lze spustit bud’ pˇr´ımo ze sloˇzky, kde jsou nainstalované DP-server.exe a DP-client.exe, nebo pomoc´ı zástupce, kter´ y byl vytvoˇren podle návodu v pˇredeˇslé kapitole. Po spuˇstˇen´ı (serveru nebo klienta) budete vyzváni k povolen´ı vyuˇz´ıván´ı s´ıt’ového pˇripojen´ı. S´ıt’ové pˇripojen´ı je pro chod obou program˚ u nezbytné.

Server Po kliknut´ı na ikonu serveru se otevˇre konzole, a v n´ı by se mˇel objevit v´ ypis podobn´ y ukázce 6.1. To, co se bude liˇsit, je 2. a 3. ˇrádek, protoˇze zde se vypisuj´ı

70

Pˇr´ılohy dostupná zaˇr´ızen´ı pro sn´ımán´ı obrazu (1.3M HD WebCam) a zvuku (Mikrofon (Conexant High Definit).

16:04:35-25.04.2014 16:04:36-25.04.2014 16:04:36-25.04.2014 High Definit" 16:04:36-25.04.2014 16:04:36-25.04.2014 16:04:36-25.04.2014 16:04:36-25.04.2014

Multicast server has started on port 9999 FFmpeg: Found video device: "1.3M HD WebCam" FFmpeg: Found audio device: "Mikrofon (Conexant HTTPS Server has started on port 9443 File src/client/files/clients was decrypted. Users have been loaded from file. Server has started on port 9001

(6.1) To, co se bude dále v konzoli zobrazovat, nen´ı d˚ uleˇzité, jedná se o logovac´ı v´ ypis událost´ı na serveru. Server je moˇzné ukonˇcit zavˇren´ım konzole. Mnohem lepˇs´ı je ale do konzole napsat slovo quit. T´ımto dojde k bezpeˇcnému ukonˇcen´ı serveru. Server se ukonˇc´ı v okamˇziku, kdy se konzole zavˇre. Pokud je stále otevˇrená, mohlo se stát, ˇze se jednu souˇcást serveru nepodaˇrilo vypnout, jedná se o program mdns server.exe a je nutné ho ukonˇcit ruˇcnˇe pˇres Správce u ´loh systému Windows.

Klient Klient se spouˇst´ı aˇz po tom, co server bˇeˇz´ı. Po spuˇstˇen´ı se objev´ı pˇrihlaˇsovac´ı okno (viz obr. P 1). V tomto oknˇe se vyplˇ nuje IP adresa serveru nebo název serveru, kter´ y je nastaven na ip.baby.monitor. Druhé pole obsahuje port, na kterém server bˇeˇz´ı, a pokud se nemˇenilo nastaven´ı, mˇel by odpov´ıdat ˇc´ıslu 9001. Posledn´ı dvˇe pole jsou uˇzivatelské jméno a heslo. Tyto u ´daje je nejdˇr´ıve nutné registrovat pomoc´ı webového rozhran´ı (viz kap. 6).

Po stisku tlaˇc´ıtka Login se spust´ı pˇrihlaˇsovac´ı proces, kter´ y m˚ uˇze skonˇcit hned nˇekolika chybami:

71

Pˇr´ılohy

Obr. P 1: Pˇrihlaˇsovac´ı okno do aplikace klienta. • Connection to server failed. - Spojen´ı se serverem nebylo navázáno. Bud’ je ˇspatnˇe IP adresa, port nebo server v˚ ubec nen´ı zapnut´ y. • Authentication failed. Username or password is incorrect. - Pokud je zadáno ˇspatné uˇzivatelské jméno nebo heslo. • Username can not be empty. - Pokud se nezadá uˇzivatelské jméno. • Password can not be empty. - Pokud se nezadá heslo. ˇ ıslo portu neodpov´ıdá povo• Server port is not valid (9000-65535). - C´ lenému rozsahu. Pokud vˇse probˇehne tak, jak má, otevˇre se okno pˇrehrávaˇce (viz obr. P 2) a v oznamovac´ı oblasti se vytvoˇr´ı ikona (malá web kamera) pro tento pˇrehrávaˇc (viz obr. P 3 (a)). Po u ´spˇeˇsném spojen´ı se serverem se IP adresa uloˇz´ı do souboru. Po stisku ikony prav´ ym tlaˇc´ıtkem myˇsi se objev´ı menu (viz P 3 (b)), které umoˇzn ˇuje zvˇetˇsen´ı/zmenˇsen´ı a ukonˇcen´ı pˇrehrávaˇce. Okno pˇrehrávaˇce je rozdˇeleno mezerou na dvˇe ˇca´sti, kde levá slouˇz´ı pro nastaven´ı streamu a pravá pro jeho spuˇstˇen´ı/ukonˇcen´ı/ukládán´ı. Pokud chce uˇzivatel sledovat video+audio nebo jen audio, vˇzdy mus´ı stisknout tlaˇc´ıtko Play. Pokud chce zmˇenit nastaven´ı a sledovat napˇr. m´ısto videa jen audio, pak je vˇzdy nutné pˇrehráván´ı nejdˇr´ıve ukonˇcit pomoc´ı Stop, zmˇenit nastaven´ı a znovu zapnout.

Levá ˇcást je rozdˇelena do menˇs´ıch sekc´ı. Prvn´ı s názvem Stream umoˇzn ˇuje vybrat, zda se bude pˇrehrávat video+audio nebo jen audio. Pokud se zaˇskrtne samotné audio, pak je moˇzné zruˇsit zobrazován´ı okno (Display window ), ve kterém se, za jin´ ych okolnost´ı, zobrazuje video. V pˇr´ıpadˇe audia v tomto oknˇe bˇeˇz´ı zvuková vlna. 72

Pˇr´ılohy

Obr. P 2: Klientsk´ y program - pˇrehrávaˇc.

(a) Ikona

(b) Menu

Obr. P 3: Ikona pˇrehrávaˇce. Vypnut´ı zobrazovac´ıho okna má vliv pouze na audio stream, u video streamu vypnout nelze.

Druhá sekce s názvem Change monitoring dává vybrat, zda chce b´ yt uˇzivatel upozornˇen, pokud nastane zv´ yˇsen´ı hlasitosti (Audio change) nebo pohyb pˇred kamerou (Video change). Pokud je nˇeco zaˇskrtnuto, pak pokaˇzdé, kdyˇz pˇr´ısluˇsná zmˇena nastane, obdrˇz´ı uˇzivatel varován´ı v podobˇe zobrazen´ı zprávy v oznamovac´ı oblasti (viz obr. P 4). Kromˇe toho se zmˇen´ı i ikona pˇrehrávaˇce, pˇribude u n´ı mal´ y ˇzlut´ y vykˇriˇcn´ık. Pokud se na ikonu pˇrehrávaˇce klikne, kdyˇz je u n´ı tento vykˇriˇcn´ık, pak se zobraz´ı posledn´ı zmˇena, která nastala (viz obr. P 5).

Obr. P 4: Zobrazen´ı zprávy u klienta pˇri zmˇenˇe.

73

Pˇr´ılohy

Obr. P 5: Zobrazen´ı posledn´ı obdrˇzené zprávy o zmˇenˇe v oznamovac´ı oblasti po stisku ikony pˇrehrávaˇce. Posledn´ı sekce má název Turn on a dává uˇzivateli na v´ ybˇer, zda chce zapnout pˇrehráván´ı hned nebo aˇz pˇri zmˇenˇe. Pokud se vybere pˇrehráván´ı streamu hned (Play now ), pak je po stisku tlaˇc´ıtka Play, asi po 10 sekundách, spuˇstˇeno okno, ve kterém bˇeˇz´ı stream odchytávan´ y kamerou na serveru. Pˇri v´ ybˇeru Play on change se zobrazovac´ı okno zapne aˇz v okamˇziku(opˇet po 10 sekundách), kdy se objev´ı v oznamovac´ı oblasti zpráva o zmˇenˇe. Okno pak z˚ ustane otevˇrené 15 sekund, a pak se zavˇre. Doba, jak dlouho má b´ yt okno otevˇrené, se dá nastavit v konfiguraˇcn´ım souboru (viz 6).

Pokud je zaˇskrtnuté pˇrehráván´ı hned (Play now ), pak je moˇzné ukládat pˇrehrávan´ y stream do souboru. Pˇri pˇrehráván´ı pˇri zmˇenˇe to moˇzné nen´ı. Pro ukládán´ı do souboru mus´ı b´ yt zaˇskrtnuté pol´ıˇcko s nápisem (Save to file). Pomoc´ı tlaˇc´ıtka (Browse) je moˇzné si vybrat, kam se soubor uloˇz´ı. Název souboru je dán napevno a obsahuje datum a ˇcas, kdy se soubor zaˇcal ukládat.

Pokud na obou zaˇr´ızen´ıch bˇeˇz´ı programy ffmpeg.exe i ffplay.exe a pˇresto se ˇza´dn´ y stream nepˇrehrává, m˚ uˇze to b´ yt zp˚ usobeno t´ım, ˇze pˇr´ıchoz´ı data streamu blokuje firewall.

Webov´ e rozhran´ı Nastaven´ı serveru je pˇr´ıstupné pˇres webové rozhran´ı. Toto rozhran´ı se dá otevˇr´ıt v bˇeˇzném webovém prohl´ıˇzeˇci na adrese https://:9443/. IP adresa serveru je stejná, jako se vyplˇ nuje pro pˇrihláˇsen´ı do klientské aplikace. Na této adrese se nacház´ı pˇrihlaˇsovac´ı formuláˇr do rozhran´ı. Uˇzivatelské jméno je nastaveno na admin a heslo na 111111. Heslo se doporuˇcuje zmˇenit. Veˇskeré hodnoty, které se ve webovém rozhran´ı nastavuj´ı, se t´ ykaj´ı vˇsech klient˚ u. 74

Pˇr´ılohy

Po u ´spˇeˇsném pˇrihláˇsen´ı se zobraz´ı stránka s menu, kde jsou poloˇzky: • Add user - Pˇridáván´ı nov´ ych uˇzivatel˚ u, kteˇr´ı se pak pod tˇemito u ´daji mohou pˇrihlásit do klientské aplikace. • Audio/Video options - Nastaven´ı mez´ı pro detekci zmˇen hlasitosti a pohybu. • FFmpeg options - Nastaven´ı parametr˚ u streamu. • Server settings - Nastaven´ı serveru. Na kaˇzdé stránce se opakuj´ı dva odkazy, jeden je Back to menu, kter´ y vrac´ı stránku s hlavn´ım menu, a Log out, kter´ y provede odhláˇsen´ı z webového rozhran´ı.

Pˇ rid´ an´ı nov´ ych uˇ zivatel˚ u Stránka obsahuje formuláˇr, kde se vypln´ı uˇzivatelské jméno a heslo. Jméno i heslo maj´ı stejná pravidla. Oboje m˚ uˇze b´ yt maximálnˇe 50 a minimálnˇe 6 znak˚ u dlouhé a sm´ı obsahovat pouze znaky: velká a malá p´ısmena bez diakritiky, ˇc´ıslice, teˇcku, hvˇezdiˇcku, podtrˇz´ıtko a pomlˇcku. Pokud bude jméno nebo heslo obsahovat nepovolené znaky nebo bude m´ıt ˇspatnou délku, neuloˇz´ı se. Uˇzivatel je o u ´spˇechu uloˇzen´ı informován vˇetou, která se objev´ı nad formuláˇrem po vloˇzen´ı u ´daj˚ u. Pokud se u ´daje uloˇz´ı, pod formuláˇrem bude vypsáno jméno novˇe pˇridaného uˇzivatele (viz obr. P 7).

Obr. P 6: Stránka pro pˇridán´ı nov´ ych klient˚ u.

75

Pˇr´ılohy

Obr. P 7: Seznam registrovan´ ych uˇzivatel˚ u. Kromˇe pˇridán´ı nov´ ych klient˚ u je zde i tlaˇc´ıtko Delete all users, které provede smazán´ı vˇsech uˇzivatel˚ u v zobrazeném seznamu. Po této akci se jiˇz nen´ı moˇzné pod p˚ uvodnˇe zadan´ ymi u ´daji pˇrihlásit.

Nastaven´ı detekce zmˇ en Na této stránce je moˇzné nastavit tolerance pro detekci zmˇen. Prvn´ı pole je pro hlasitost a udává hladinu zvuku v decibelech. Pokud je tato hladina pˇrekroˇcena, je poslána zpráva klientovi, která se zobraz´ı v oznamovac´ı oblasti (viz obr. P 5). V´ ychoz´ı hodnota je 40dB, coˇz odpov´ıdá tiché knihovnˇe. Minimáln´ı hodnotu lze nastavit na 0dB a maximáln´ı na 120dB (start tryskového letadla). Druhé pole je pro detekci pohybu a hodnoty zobrazuje v procentech. Udává, o kolik procent se mus´ı zmˇenit jeden sn´ımek oproti pˇredchoz´ımu. V´ ychoz´ı hodnota je 10%.

Obr. P 8: Stránka pro nastaven´ı mez´ı pro detekce zmˇen. Dále je na této stránce k dispozici tlaˇc´ıtko Original settings, které zp˚ usob´ı nastaven´ı v´ yˇse zm´ınˇen´ ych parametr˚ u do v´ ychoz´ıch hodnot (40dB a 10% ). Zmˇena parametru pro detekci pohybu se projev´ı ihned i pˇri jiˇz zapnutém sledován´ı streamu. Aby se projevila zmˇena tolerance hlasitosti, je nejdˇr´ıve nutné ukonˇcit pˇrehráván´ı streamu na vˇsech pˇripojen´ ych klientech (nen´ı nutné program klienta vypnout u ´plnˇe). Pˇri dalˇs´ım zapnut´ı se jiˇz pouˇzije novˇe nastavená hodnota.

76

Pˇr´ılohy Nastaven´ı streamu Na této stránce je moˇzné upravovat vlastnosti pˇrehrávaného streamu (viz obr. P 9). Veˇskeré zmˇeny se, stejnˇe jako u zmˇeny hlasitosti, projev´ı aˇz po tom, co vˇsichni klienti ukonˇc´ı pˇrehráván´ı streamu. Uˇzivatel zde má na v´ ybˇer vˇzdy z nˇekolika hodnot. Parametry, které je moˇzné nastavovat, jsou: rozliˇsen´ı obrazu, bit rate, poˇcet audio kanál˚ u, audio frekvence, poˇcet sn´ımk˚ u za sekundu, kvalita videa. ˇ ım vyˇsˇs´ı hodnoty Kvalita videa je od 1 do 11, kde 1 je nejlepˇs´ı a 11 nejhorˇs´ı. C´ se nastav´ı (kromˇe kvality), t´ım bude stream lepˇs´ı, ale zároveˇ n se mus´ı pˇrenáˇset vˇetˇs´ı objem dat a pomalejˇs´ı pˇripojen´ı by to nemusela zvládat. V´ ychoz´ı hodnoty jsou uvedeny na obrázku P 9. I zde je moˇzné vrátit zmˇenˇené hodnoty do p˚ uvodn´ıho nastaven´ı tlaˇc´ıtkem Original settings.

Obr. P 9: Stránka pro nastaven´ı parametr˚ u streamu.

77

Pˇr´ılohy Pole FFmpeg command umoˇzn ˇuji zkuˇsen´ ym uˇzivatel˚ um, zadat si sv˚ uj vlastn´ı pˇr´ıkaz k z´ıskán´ı streamu ze zaˇr´ızen´ı. Takto uloˇzen´ y pˇr´ıkaz je spouˇstˇen do té doby, neˇz dojde k restartu serveru. Nastaven´ı p˚ uvodn´ıho pˇr´ıkazu je moˇzné po uloˇzen´ı prázdného pole FFmpeg command .

Nastaven´ı serveru Na posledn´ı stránce je moˇzné zmˇenit nastaven´ı serveru (viz obr P 10). Toto nastaven´ı se doporuˇcuje nemˇenit, pokud to nen´ı opravdu nutné, tj. porty pouˇz´ıvané serverem uˇz pouˇz´ıvá jiná aplikace. Zmˇena port˚ u se samozˇrejmˇe projev´ı aˇz po restartu serveru. Kromˇe port˚ u je jeˇstˇe moˇzné mˇenit heslo do administrátorské ˇca´sti. Pro u ´spˇeˇsnou zmˇenu je nejdˇr´ıve nutné zadat staré heslo. Nové heslo se ˇr´ıd´ı stejn´ ymi pravidly jako hesla pˇri registraci uˇzivatel˚ u (tj. mus´ı b´ yt v rozmez´ı 6-50 znak˚ u a má omezenou mnoˇzinu pouˇziteln´ ych symbol˚ u). Pokud nechcete mˇenit heslo, necháte obˇe pole prázdná.

Obr. P 10: Stránka pro nastaven´ı serveru. Posledn´ım nastaviteln´ ym parametrem je Private addsesses. Pokud je tento parametr zaˇskrtnut´ y, znamená to, ˇze do webového rozhran´ı se dostanou pouze webov´ı klienti, kteˇr´ı jsou na stejné pods´ıti jako server. Pokud tomu tak nebude, zobraz´ı se varovná hláˇska (Connection Error!!! You can not connect to the server from different subnet than server is located.) a klient se nem˚ uˇze do rozhran´ı pˇrihlásit.

78

Pˇr´ılohy I zde je moˇzné vrátit p˚ uvodn´ı nastaven´ı. To se vˇsak nevztahuje na vrácen´ı p˚ uvodn´ıho hesla.

Probl´ emy Pˇri spouˇstˇen´ı aplikace se m˚ uˇze vyskytnou problém administrátorsk´ ymi právy. Proto je nunté postupovat pˇresnˇe podle návodu pro instalaci. Kromˇe to je moˇzné, ˇze systémov´ y firewall nepropust´ı pˇr´ıchoz´ı stream. To se dá odstranit tak, ˇze se spust´ı Start, nap´ıˇse se firewall a vybere se odkza Brána Windows Firewall. Stejného efektu se dá dosáhnout spuˇstˇen´ım odkazu Ovládac´ı panely\Systém a zabezpeˇcen´ı\Brána Windows Firewall v pr˚ uzkumn´ıku. V otevˇreném oknˇe se v levém panelu klikne na Upˇresnit nastaven´ı. Otevˇre se nové okno (viz obr. P 11) a zde v levém panelu vybere záloˇzka Pˇr´ıchoz´ı pravidla. Zobraz´ı se seznam aplikac´ı a v nˇem najdˇete DPclient, kliknˇete na n´ı prav´ ym tlaˇc´ıtkem a vyberte vlastnosti. V otevˇreném oknˇe, v záloˇzce Obecné, pˇrekliknˇete z Blokovat pˇripojen´ı na Povolit pˇripojen´ı (viz obr. P 12).

Obr. P 11: Nastaven´ı povolen´ı aplikace ve firewallu systému.

79

Pˇr´ılohy

Obr. P 12: Povolen´ı pˇr´ıchoz´ıho spojen´ı na klienta.

Konfiguraˇ cn´ı soubory ˇ adky zaˇc´ınaj´ıc´ı Oba programy maj´ı konfiguraˇcn´ı soubory, které je moˇzné mˇenit. R´ # jsou komentáˇre a programy je pˇri naˇc´ıtán´ı souboru ignoruj´ı.

Server Server má veˇskeré nastaven´ı pˇr´ıstupné pˇres webové rozhran´ı. Pokud by se do nˇej z nˇejakého d˚ uvodu nedalo dostat, je jeˇstˇe moˇzné hodnoty upravit pˇr´ımo v konfiguraˇcn´ıch souborech. Tyto soubory se nacház´ı ve sloˇzce IP baby monitor\server\src\server\web interface\setting. Upravovat se smˇej´ı pouze soubory bez pˇr´ıpony o, tedy avoption, avset, server. Soubory s touto pˇr´ıponou obsahuj´ı v´ ychoz´ı nastaven´ı a nesm´ı se ani upravovat ani mazat. 80

Pˇr´ılohy

• avoption - Obsahuje nastaven´ı limit˚ u pro detekce zmˇen (viz ukázka 6.2). noise je hladina zvuku a frame je zmˇena obrazu. • avset - Obsahuje nastaven´ı parametr˚ u streamu (viz ukázka 6.3). resol je rozliˇsen´ı obrazu, bitra je bit rate, chann je poˇcet audio kanál˚ u, frekv je frekvence audia, frame je poˇcet rámc˚ u za sekundu a quali je kvalita videa. • server - Obsahuje nastaven´ı serveru (viz ukázka 6.4). mport je port, kde server pˇrij´ımá klienty (pˇrehrávaˇc), sport je port pro pˇr´ıjem klient˚ u pˇres HTTPS, avport je port udp serveru, kam je pos´ılán audio+video stream, aport je to samé jako avport, ale jen pro audio, private false znamená, ˇze se do webového rozhran´ı mohou pˇrihlásit i klienti z jiné pods´ıtˇe a name je jméno serveru, pod kter´ ym ho lze na pods´ıti naj´ıt.

noise=40 frame=10 (6.2)

resol=800x600 bitra=282000 chann=1 frekv=16000 frame=30 quali=9 (6.3)

mport=9001 sport=9443 avport=9002 81

Pˇr´ılohy aport=9004 private=false name=ip.baby.monitor (6.4)

Klient Klient má k dispozici jeden konfiguraˇcn´ı soubor, kter´ y se nedá nastavit jinak, neˇz otevˇren´ım v nˇejakém poznámkovém bloku. Jeho obsah je zobrazen v ukázce 6.5. SERVER NAME je název serveru, DEFAULT SERVER IP je IP adresa serveru, SERVER UDP AV SEND PORT je port, na kterém server vys´ılá audio+video stream, STREAM SAVE PORT je port, kam klient pˇrepos´ılá stream, pokud se má ukládat do souboru, MESSAGE SHOW DURATION ke poˇcet sekund, jak dlouho se bude zobrazovat zpráva v oznamovac´ı oblasti, WINDOW SHOW DURATION je poˇcet sekund, jak dlouho se bude zobrazovat okno se streamem, pokud se objevuje jen pˇri zmˇenách1 .

# Server name. SERVER_NAME=ip.baby.monitor # Server default IP address. DEFAULT_SERVER_IP=127.0.0.1 # Udp port where audio/video stream is sent. SERVER_UDP_AV_SEND_PORT=9002 # Udp port where audio stream is sent. SERVER_UDP_AUDIO_SEND_PORT=9004 # Udp port where stream is sent and save to file. STREAM_SAVE_PORT=9006 # How long the tray message will bo shown [s]. MESSAGE_SHOW_DURATION=10 # How long the stream player will play. [s]. WINDOW_SHOW_DURATION=25 (6.5) 1

Tato doba je vˇcetnˇe 10 sekund, po které trvá, neˇz se okno otevˇre. Pokud se tedy nastav´ı doba na ménˇe neˇz 11 sekund, okno se pravdˇepodobnˇe v˚ ubec nestihne otevˇr´ıt.

82

Pˇr´ılohy

Certifik´ at Certifikát, kter´ y server pouˇz´ıvá pro vytváˇren´ı spojen´ı pomoc´ı HTTPS, nen´ı ovˇeˇren ˇzádnou certifikaˇcn´ı autoritou, a tak se pˇri kaˇzdém pˇrihláˇsen´ı, bude webov´ y prohl´ıˇzeˇc ptát, jestli má pokraˇcovat i pˇres ned˚ uvˇeryhodnost certifikátu. Toto se dá odstranit t´ım, ˇze se dan´ y certifikát, kter´ y je ve sloˇzce IP baby monitor\certifikat\ip baby monitor cert.pfx, nainstaluje do poˇc´ıtaˇce mezi D˚ uvˇeryhodné koˇrenové certifikaˇcn´ı autority, a také se pˇridá do prohl´ıˇzeˇce, se kter´ ym se bude do rozhran´ı pˇristupovat. Pˇri instalaci bude vyˇzadováno heslo, které je nastaveno na 1a8G.h6. Pro prohl´ıˇzeˇc Opera je moˇzné certifikát pˇridat takto: Nástroje − > Nastaven´ı... − > Pokroˇcilé volby − > Zabezpeˇcen´ı − > Správce certifikát˚ u − > Importovat. Pro prohl´ıˇzeˇc Mozilla Firefox je moˇzné certifikát pˇridat takto: Nástroje − > Moˇznosti − > Rozˇs´ıˇren´ı − > Certifikáty − > Certifikáty − > Osobn´ı − > Importovat. Pro prohl´ıˇzeˇc Chrome je moˇzné certifikát pˇridat takto: Nástroje − > Rozˇs´ıˇren´ı − > Nastaven´ı − > Spravovat certifikáty − > Importovat... . Pro prohl´ıˇzeˇc Internet Explorer je moˇzné certifikát pˇridat takto: Nastaven´ı − > Moˇznosti internetu − > Obsah − > Certifikáty − > Importovat... .

Zobrazovac´ı okno pro stream Spuˇstˇen´ y stream je pˇrehráván v samostatném oknˇe, které je nezávislé na pˇrehrávaˇci, kter´ y je na obr. P 4. To znamená, ˇze pokud se toto okno vypne, pˇrehrávaˇc se to nedozv´ı, a je nutné ho samostatnˇe ukonˇcit tlaˇc´ıtkem Stop. Pˇrehrávaˇc i se spuˇstˇen´ ym oknem pro stream je na obr. P 13. Pokud se ale ukonˇc´ı pˇrehrávaˇc, pak by se mˇelo ukonˇcit i toto okno. Jelikoˇz se jedná o samostatn´ y program, má v sobˇe implementováno vlastn´ı ovládán´ı. Na toto okno je tedy moˇzné uplatnit následuj´ıc´ı klávesy: • q, ESC - vypnut´ı okna • f - pˇrepnut´ı na celou obrazovku

83

Pˇr´ılohy • p, mezern´ık - pauza • s - procházen´ı videa rámec po rámci, pˇredt´ım se mus´ı zmáˇcknout pauza • ˇsipka doprava - posunut´ı na aktuáln´ı pozici v live streamu • w - pˇrepnut´ı náhledu na zvukové vlny

Obr. P 13: Náhled na spuˇstˇen´ y pˇrehrávaˇc i s oknem se streamem.

84

Obsah CD Na pˇriloˇzeném CD jsou ve sloˇzce IP baby monitor adresáˇre: • certifikat - Obsahuje instalaˇcn´ı certifikát ip baby monitor cert.pfx. • dokumentace - Obsahuje text k diplomové práci ve formátu pdf. • klient - Obsahuje veˇskeré souˇcásti klientského programu jako pˇreloˇzené soubory, instalaˇcn´ı soubor, zdrojové soubory a adresáˇr se spustiteln´ ym programem. • opswi - Obsahuje oborov´ y projekt, kter´ y se nad rámec zadán´ı diplomové práce zab´ yvá implementac´ı serveru na zaˇr´ızen´ı BeagleBone Black s procesorem ARM a pˇrehráván´ım streamu v XBMC. • scripty pro instalaci - Obsahuje scripty (Inno Setup), které generuj´ı instalaˇcn´ı .exe soubory. • server - Obsahuje veˇskeré souˇca´sti programu serveru jako pˇreloˇzené soubory, instalaˇcn´ı soubor, zdrojové soubory a adresáˇr se spustiteln´ ym programem. Server i klient obsahuj´ı stejné podadresáˇre: • bin - Obsahuje pˇreloˇzené soubory vˇsech souˇca´st´ı daného programu (pod Windows). • install - Obsahuje instalaˇcn´ı program. • run - Obsahuje spustitelnou verzi programu. (To samé je pak ve sloˇzce, kam se program nainstaluje.) • src - Obsahuje zdrojové kódy vˇsech souˇca´st´ı spolu s MAKEFILE a knihovnami. 85

Pˇr´ılohy Aby bylo moˇzné pˇreloˇzit jak server, tak klienta, mus´ı b´ yt na systému Windows nainstalována knihovna pro práci s Posix vlákny (viz [22]). Dále je pro oba systémy nutná instalce knihovny OpenSSL a pro klienta pak jeˇstˇe Qt. Zdrojové kódy ve sloˇzce server/src/server se pˇrekládáj´ı pomoc´ı MAKEFILE pro dan´ y operaˇcn´ı systém (Makefile.Linux nebo Makefile.Windows). Zdrojov´ y kód klienta um´ıstˇen´ yv klient/src/klient se pˇrekládá pomoc´ı Windows run.bat a nebo Makefile.Linux.

FFmpeg Na CD jsou k dispozici i zdrojové soubory pro nástroje ffmpeg.exe a ffplay.exe. Jejich pˇreloˇzen´ı pod systémem Windows je realizovatelné a je popsané na fóru, které FFmpeg spravuje [1].

86

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky

Recommend Documents