Dokumentacja programu WatchDog

Transkrypt

1 Dokumentacja programu WatchDog Borowski Jarosªaw Chudy Kamil Koªda Šukasz Kowalewski Sªawomir Kunowski Sªawomir Šuksza Dariusz Piotrowicz Karol Pªonka Tomasz 22 czerwca

2 Spis tre±ci 1 Przeznaczenie systemu 3 2 Architektura systemu Zarys ogólny Klient Wymagania Ogólna konstrukcja Interfejs - wst p Narz dzia Okna Kamery Temperatura Czytniki Kart Serwer Wymagania Centrum certykacji Baza danych Instalacja Procedury klienta Procedury jednostki monitoruj cej Jednostka monitoruj ca Opis ogólny Konguracja systemu Š czno± Poª czenie jednostka monitoruj ca - serwer Poª czenie z jednostk monitoruj ca - komputer debuguj cy Komponenty jednostki monitoruj cej Czujnik temperatury Wykorzystany sprz t Wykorzystane oprogramowanie zewn trzne Sposób dziaªania moduªu Czytnik kart Wykorzystany sprz t Wykorzystane oprogramowanie Sposób dziaªania Moduª powiadamiania SMS Wykorzystany sprz t Wykorzystane oprogramowanie Sposób dziaªania Moduª rejestracji obrazu Wykorzystany sprz t Wykorzystane oprogramowanie zewn trzne Sposób dziaªania moduªu Moduª zamka elektromagnetycznego Wykorzystany sprz t Oprogramowanie zewn trzne Sposób dziaªania moduªu Scenariusze laboratoryjne Sceniariusz I: Certykaty SSL Scenariusz II : zmiana karty Cel wiczenia Wymagania Przebieg wiczenia

3 1 Przeznaczenie systemu Przeznaczeniem systemu jest kompleksowe monitorowanie pomieszcze«. Obejmuj ce kontrole dost pu, zapis temperatury oraz rejestracje wideo. System umo»liwia przegl danie zapisów archiwalnych z ka»dego z wy»ej wymienionych komponentów systemu. 2 Architektura systemu 2.1 Zarys ogólny System skªada si z trzech gªównych komponentów jednostki monitoruj cej, serwera oraz klienta. Jednostka monitoruj ca prowadzi ci gªy odczyt z podª czonych urz dze«peryferyjnych jakimi s : kamera wideo, czytnik kart chipowych, klawiatura numeryczna, czujnik temperatury a tak»e steruje ryglem blokuj cym drzwi do pomieszczenia. System pozwaªa na obsªug wielu kamer oraz czujników temperatury jednocze±nie. Jednostka monitoruj ca zapisuje pozyskane klatki wideo na serwer FTP oraz aktualn temperatur do bazy MySQL umieszonej na serwerze. Komunikacja pomi dzy jednostk monitoruj c a serwerem odbywa si drog bezprzewodow. Aplikacja kliencka pozwala na przegl danie historii oraz bie» cego zapisu z monitoringu oraz warto±ci z innych urz dze«peryferyjnych. 2.2 Klient Wymagania Poniewa» caªy system jest skonstruowany przy pomocy wielu ró»nych technologii, klient musiaª speªnia pewne wymagania aby mo»liwa byªa wspóªpraca mi dzy nim a reszt elementów systemu.pierwszym wa»nym wymaganiem stawianym przez reszt systemu byªa baza danych. Przy konstrukcji i testach u»ywana byªa baza MySql. Aplikacje pisane w Framework 2.0.NET nie maj gotowych sterowników do baz MySql, trzeba byªo ±ci gn sterownik z strony Aplikacja u»ywa sterownika w wersji 5.1. Dzi ki temu poª czenie z bazami MySql nie stanowiªo problemu. Drugim wymaganiem stawianym klientowi byªa obsªuga poª czenia SSL z baz danych. Sprowadzaªo si to do konstrukcji odpowiedniego connection string, w którym zawarte byªy ±cie»ki do odpowiednich plików zawieraj cych certykaty.kolejnym poª czenia SSL z baz danych, nale»aªo tak»e umo»liwi klientowi pobieranie danych z serwer FTP. Aby to osi gn, nale»aªo u»y odpowiedniej klasy z Frameworka.NET a tak»e odpowiedniego serwera FTP. Dobór serwera byª wa»ny, gdy» domy±lnie klasa odpowiedzialna za pobieranie plików z FTP, wysyªa z ka»dym zapytaniem swój login i hasªo. Niektóre serwery FTP raportowaªy takie zachowanie jako bª d. Oprócz powy»szych wymaga«, klient musiaª dawa mo»liwo± zarówno edycji jak i podgl du danych z serwera Ogólna konstrukcja Aplikacja korzysta z pliku przechowywanego lokalnie o nazwie App.cong oraz z danych przechowywanych na serwerze. Plik App.cong przechowuje dane w formie XML potrzebne klientowi do poª czenia si zarówno z serwerem FTP jak i baz danych. Sam program klienta podzielony jest na trzy moduªy. Dwa gªówne moduªy to Net oraz UI. Net zawiera klas DbComponent, który jest komponentem i byª specjalnie konstruowany do tej aplikacji. Znajduj si tutaj caªa logika aplikacji, komunikacja z baz oraz sterowanie interfejsem. W module UI znajduj si interfejs sterowany przez komponent z moduªu Net. Jedyne co tutaj si znajduj to obsªuga wygl du interfejsu gracznego. Trzecim moduªem, jest moduª pomocniczy. Sªu»y on mi do konstrukcji komponentu w module Net. Uªatwia on dost p asynchroniczny do interfejsu oraz bazy danych Interfejs - wst p Aby móc korzysta z programu, potrzebny jest serwer, z którego b d pobierane dane i u którego klient b dzie autoryzowany. Je±li logowanie nie powiedzie si, wtedy w status bar b dzie komunikat o bª dzie w poª czeniu z baz danych oraz menu górne: Kamery, Temperatura, Czytniki 3

4 Kard b d puste. W przeciwnym wypadku statu bar po informuje nas»e wszystko si udaªo i b dziemy mie dost p do czujników oraz kamer. Ka»de menu z Menu Strip przedstawia osobny zestaw mo»liwo±ci. Ni»ej zostaªy opisane wszelkie operacje które mo»e wykona u»ytkownik po prawidªowym zalogowaniu przy pomocy tego menu. Gªówne okno klienta wygl da jak zostaªo przedstawione ni»ej: Narz dzia Opcje Po wybraniu z menu Opcje uzyskujemy dost p do formularza z opcjami. Mo»emy tutaj wpisa dane potrzebne przy poª czeniu zarówno z baz danych jak i z serwerem FTP. Formularz do ustawiania tych opcji jest poni»ej: Do tego zostaªy tutaj zawarte opcje sªu» ce do konguracji wysyªania SMS, dzi ki której u»ytkownik mo»e by powiadamiany o konkretnych wydarzeniach wykrytych przez system. Sªu»y do tego poni»szy formularz: 4

5 Wida na zrzucie z programu dwie listy. Jedna z nich zawiera list numerów, na które b d wysyªane SMS z raportami. Natomiast lista po prawej stronie zawiera list zdarze«na które ma reagowa system. Oczywi±cie obie listy mo»emy edytowa po przez poszczególne guziki zawarte na kontrolce. Nast pna zakªadka zawiera u»ytkowników wraz z lista dost pnych dla nich pomieszcze«. Zakªadka wygl da tak jak zaprezentowano ni»ej: Po wybraniu u»ytkownika z lewej listy, w prawej li±cie pojawi si lista pomieszcze«do których wybrany u»ytkownik ma dost p. Mo»emy dodawa, edytowa i usuwa, zarówno u»ytkowników jak i pozwolenia które zostaªy im przydzielone Historia Tutaj mo»emy przegl da zapisane dane z monitoringu. Chodzi zarówno o dane z czujników, czytników jak i kamer. Sam formularz wygl da jak pokazano ni»ej: 5

6 Aby obejrze zapis z danego okresu nale»y kolejno: wybra z komboboksa 'Typ' urz dzenie (Temperatura, Kamera, Czytnik) wybra z komboboksa 'Urz dzenie' nazw urz dzenia dla którego chcemy obejrze zapis wybra zakres interesuj cych nas dat klikn guzik 'Poka»' W zale»no±ci o wybranego typu urz dzenia, po prawej stronie pojawi si albo obraz z kamery, albo odczyty z czujników czy czytników z danego okresu. Urz dzenia Formularz ten sªu»y edycji, usuwaniu oraz dodawaniu urz dze«do systemu. Wybór urz dzenia przebiega w taki sam sposób jak w historii, oczywi±cie z pomini ciem wybierania dat. Po wybraniu urz dzenia, wybieramy co mamy z nim zrobi. Je±li wybrali±my edycje lub dodawanie to uka» si nam ten formularz: Mo»e si on troch ró»ni w zale»no±ci typu wybranego urz dzenia. Je±li wybrano edycj, pola b d wypeªnione warto±ciami. Zmiany s zapisywane po klikni ciu 'Zatwierd¹'. Aby anulowa jakiekolwiek zmiany wystarczy zamkn okno, bez klikania guzika 'Zatwierd¹' Okna Te menu sªu»y tylko do ªatwego i szybkiego ukªadania pod okien w oknie gªównym aplikacji. Dost pne tutaj uªo»enia s raczej do± popularne (horyzontalne, kaskadowe itp), wi c nie b d tutaj opisywaª dziaªania ka»dego z nich. Dodatkow funkcj tego menu jest utrzymywanie listy otwartych okien w aplikacji. 6

7 2.2.6 Kamery Tutaj mamy list kamer dost pnych dla u»ytkownika. Po wybraniu kamery z tej listy, otworzy si nowe okno w którym b dzie wida obraz na»ywo z danej kamery. Na dole obrazu mo»emy zauwa»y dat oraz godzin Temperatura Lista czujników temperatury w systemie. Wybranie którego± z listy, powoduj otworzenie nowego okna, które co jedn sekund wy±wietla b dzie odczyt z czujnika wraz z czasem czujnika Czytniki Kart Lista czytników z systemu. Wybranie danego czytnika z listy, powoduje otworzenie okna z stanem czytnika. Mo»emy tutaj ±ledzi dwie kolumny takie. Jedna z nich wy±wietla status (czy zostaªa wªo»ona karta czy te» nie, jak przebiagaªa autoryzacja itd), drugia kolumna prezentuje czas w którym zdarzenie nast piªo. 2.3 Serwer Wymagania 1. Serwer MySql w wersji 5.1 lub wy»szej 2. Serwer VSFTP 3. Zainstalowany pakiet OpenSSL Centrum certykacji Na pªycie doª czonej do projektu znajduje si skrypt tworz cy CA wraz z certykatem dla serwera i przykªadowym certykatem dla klienta. Mo»na te» skorzysta z wygenerowanego juz centrum, które równie» znajduje si na pªycie. Interesuj ce nad pliki to: 1. cacert.pem, cakey.pem - certykat i klucz prywatny CA 2. client-cert.pem, client-key.pem - certykat i klucz prywatny klienta 3. server-cert.pem, server-key.pem - certykat i klucz prywatny serwera Na potrzeby poª czenia mi dzy serwerem (baz danych) a jednostk monitoruj c, które jest realizowane z poziomu j zyka Java certykat CA musiaª zosta zaimportowany do truststore. Korzysta z niego klasa odpowiedzialna za poª czenie. Do zaimportowania posªu»yªo narz dzie keytool dostarczane z JDK i umieszczone w katalogu /bin. Wykorzystano do tego polecenie: keytool -import -alias mysqlservercacert -le cacert.pem -keystore truststore 7

8 2.3.3 Baza danych Wykorzystana zostaªa baza danych MySQL w wersji 5.1. Wszystkie operacje na bazie danych wykonywane przez jednostk monitoruj c i klienta odbywaj si za po±rednictwem zdeniowanych procedur. Zapewnia to kontrole argumentów zapyta«, co utrudnia przeprowadzenie ataku SQL Injection. Dodatkowo procedury pozwalaj na lepsze zarz dzenie bezpiecze«stwem bazy danych. Wszystkie poª czenia z baz danych s szyfrowane za pomoc szyfru symetrycznego AES, mechanizmem wymiany kluczy i uwierzytelnienia na podstawie certykatów jest protokóª SSL. Na potrzeby bazy danych zostaªo utworzone Centrum Certykacji za pomoc którego generowane s wszystkie certykaty dla serwera oraz klientów. W zaª cznikach dost pne s skrypty do tworzenia bazy danych, procedur, przykªadowe centrum certykacji, skrypt do jego tworzenia razem z certykatem dla serwera oraz przykªadowym certykatem dla klienta Instalacja 1. Tworzenie bazy danych Wykorzystamy tutaj skrypty znajduj ce si si w folderze DB na pªycie instalacyjnej. cat createdb.sql client.sql atom.sql mysql -u root -p 2. Dodawanie certykatu CA, certykatu i klucza serwera do bazy danych (a) Otworzy plik /etc/my.cnf (b) Doda na jego koniec nast puj ce linie zast puj c zmienn $DIR ±cie»k do folderu w którym znajduj si certykaty i klucz prywatny. [mysqld] ssl-ca=/$dir/cacert.pem 8

9 ssl-cert=/$dir/server-cert.pem ssl-key=/$dir/server-key.pem 3. Próbne poª czenie (a) Ustanawianie poª czenia mysql -u root -p ssl-ca=cacert.pem ssl-cert=server-cert.pem ssl-key=serverkey.pem (b) Sprawdzanie czy poª czenie jest szyfrowane Procedury klienta Picture SHOW STATUS LIKE 'Ssl_cipher'; getpicture(in ID INT) Zwraca ostatni obraz ID - identykator kamery path VARCHAR(80) - ±cie»ka do pliku time DATATIME - znacznik czasowy selectpicturebetween(in ID INT, IN FROMDATE DATETIME, IN TODATE DATE- TIME) Zwraca obrazki spomi dzy podanych dat ID id kamery FROMDATE - data pocz tkowa TODATE - data ko«cowa path VARCHAR(80) - ±cie»ka do pliku time DATATIME - znacznik czasowy Temperature gettemerature(in ID INT) ID - id sensora value - temperatura przechowywana w formacie DECIMAL(3,1) time - znacznik czasowy selecttemperaturebetween(in ID INT,IN FROMDATE DATETIME,IN TODATE DATE- TIME) 9

10 value DECIMAL(3,1) - warto± temperatury time DATATIME - znacznik czasowy Card state getcardstate(in ID INT) ID - id czytnika kart state VARCHAR(45) - stan czujnika time DATATIME - znacznik czasowy selectcardstatebetween(in ID INT,IN FROMDATE DATETIME,IN TODATE DATE- TIME) state VARCHAR(45) - stan czujnika time DATATIME - znacznik czasowy CardReader selectcardreader() ID INT identykator name VARCHAR(30) nazwa active TINYINT(1) - czytnik aktywny(1), nieaktywny(0) insertcardreader(in NAME VARCHAR(30),IN ACTIVE TINYINT(1)) NAME - nazwa ACTIVE - czytnik aktywny(1), nieaktywny(0) updatecardreader(in ID INT,IN NAME VARCHAR(30),IN ACTIVE TINYINT(1)) ID identykator czytnika, który chcemy uaktualni NAME nazwa ACTIVE czytnik aktywny(1), nieaktywny(0) deletecardreader(in ID INT) 10

11 ID identykator czytnika Camera selectcamera() ID - identykator name - nazwa active - kamera aktywna(1), nieaktywna(0) insertcamera(in NAME VARCHAR(30),IN DIR_PATH VARCHAR(40),IN ACTIVE TINYINT(1)) NAME nazwa DIR_PATH ±cie»ka do katalogu zawieraj cego pliki tej kamery (Zako«czony znakiem /) ACTIVE kamera aktywna(1), nieaktywna(0) updatecamera(in ID INT,IN NAME VARCHAR(30),IN DIR_PATH VARCHAR(40),IN ACTIVE TINYINT(1)) ID Identykator kamery, któr chcemy uaktualni NAME nazwa DIR_PATH ±cie»ka do katalogu zawieraj cego pliki tej kamery (Zako«czony znakiem /) ACTIVE kamera aktywna(1), nieaktywna(0) deletecamera(in ID INT) ID Identykator kamery Sensor selectsensor() id INT - identykator name VARCHAR(30) - nazwa active TINYINT(1) - czujnik aktywny(1), nieaktywny(0) insertsensor(in NAME VARCHAR(30),IN ACTIVE TINYINT(1)) NAME nazwa 11

12 ACTIVE sensor aktywny(1), nieaktywny(0) updatesensor(in ID INT,IN NAME VARCHAR(30),IN ACTIVE TINYINT(1)) ID identykator czujnika, który chcemy uaktualni NAME nazwa ACTIVE czujnik aktywny(1), nieaktywny(0) deletesensor(in ID INT) ID identykator czujnika Phone selectphone() id INT - identykator number DECIMAL(15,0) numer insertphone(in NUMBER DECIMAL(15,0)) NUMBER numer telefonu updatephone(in PHONE_ID INT,IN NUMBER DECIMAL(15,0)) PHONE_ID identykator telefonu NUMBER numer telefonu deletephone(in ID INT) ID - identykator Event selectevent() id INT id eventid INT typ zdarzenia zdarzenia arg VARCHAR(20) argument zdarzenia 12

13 message VARCHAR(160) wiadomo± insertevent((in EVENT_TYPE INT,IN ARG VARCHAR(20),IN MESSAGE VAR- CHAR(160))) EVENT_TYPE INT typ zdarzenia ARG VARCHAR(20) argument zdarzenia MESSAGE VARCHAR(160) wiadomo± SMS updateevent(in EVENT_ID INT, IN EVENT_TYPE INT,IN ARG VARCHAR(20),IN MESSAGE VARCHAR(160)) EVENT_ID INT identykator EVENT_TYPE INT typ zdarzenia ARG VARCHAR(20) argument zdarzenia MESSAGE VARCHAR(160) - wiadomo± securitydb.deleteevent(in EVENT_ID INT) EVENT_ID - identykator User selectuser() id INT - identykator name VARCHAR(30) - nazwa pesel VARCHAR(11) pesel pin VARCHAR(32) pin w MD5 insertuser(in NAME VARCHAR(30),IN PESEL VARCHAR(11),IN PIN VARCHAR(32)) NAME - nazwa securitydb. PESEL - pesel PIN pin w MD5 updateuser(in USER_ID INT,IN NAME VARCHAR(30),IN PESEL VARCHAR(11),IN PIN VARCHAR(32)) USER_ID identykator 13

14 NAME - nazwa PESEL - pesel PIN pin w MD5 deleteuser(in ID INT) ID - identykator Access selectaccess(in USER_ID INT) USER_ID identykator u»ytkownika cardreader_id INT identykator czytnika kart access TINYINT(1) informacja o dost pie insertaccess(in USER_ID INT,IN CARD_READER_ID INT,IN ACCESS TINYINT(1)) USER_ID identykator u»ytkownika CARD_READER_ID identykator czytnika kart ACCESS informacja o dost pie updateaccess(in USER_ID INT,IN CARD_READER_ID INT,IN ACCESS TINYINT(1)) USER_ID identykator u»ytkownika CARD_READER_ID identykator czytnika kart ACCESS informacje o dost pie deleteaccess(in USER_ID INT,IN CARD_READER_ID INT) USER_ID identykator u»ytkownika CARD_READER_ID identykator czytnika kart 14

15 2.3.6 Procedury jednostki monitoruj cej inserttime(in TIME DATETIME) TIME - znacznik czasowy insertpicture(in TIME_ID INT, IN FILE_PATH VARCHAR(40), IN CAMERA_ID INT) TIME_ID identykator znacznika czasowego FILE_PATH wzgl dna ±cie»ka do pliku CAMERA_ID identykator kamery inserttemperature(in TIME_ID INT, IN VALUE DECIMAL(3,1), IN SENSOR_ID INT) TIME_ID - identykator znacznika czasowego VALUE warto± SENSOR_ID identykator sensora insertcardstate(in TIME_ID INT, IN STATE VARCHAR(45), IN CARDREADER_ID INT) TIME_ID identykator znacznika STATE status czytnika CARDREADER_ID identykator czytnika kart selectactivecamera() id INT name VARCHAR(30) dir_path VARCHAR(40) selectactivesensor() id INT name VARCHAR(30) selectactivecardreader() id INT 15

16 name VARCHAR(30) verifycard(in ID INT, IN PESEL VARCHAR(11), IN PIN VARCHAR(32)) ID identykator u»ytkownika PESEL pesel PIN pin w MD5 1 je±li karta i pin zostania zidentykowana isupdate() up INT wymagane uaktualnienie zdarze«i telefonów (1), brak uaktualnienia(0) 2.4 Jednostka monitoruj ca Opis ogólny Jednostk monitoruj c stanowi komputer klasy PC z procesorem wielordzeniowym Intel Atom, oraz oprogramowanie napisane gªównie w j zyku Java wykorzystuj ce mechanizmy wielow tkowe. Jego zadaniem jest kontrola nad wszystkimi komponentami systemu, oraz komunikacja z serwerem gªównym na którym znajduje si baza danych. Konguracja sprz towa jednostki monitoruj cej, to obudowa i pªyta gªówna w formacie iatx, dwu rdzeniowy procesor Intel Atom 1,6 GHz, 1 GB pami ci DDR2, dysk twardy 30 GB, karta WiFi na PCI. Pªyta gªówna na chipsecie i945. Do jednostki monitoruj cej podpi te s wszystkie peryferyjne urz dzenia takie jak czujnik temperatury ( port COM ), czytnik kart czy rygiel elektromagnetyczny. Dokªadniejszy opis ka»dego moduªu wchodz cego w skªad jednostki monitoruj cej znajduje si w sekcji Komponenty jednostki monitoruj cej Konguracja systemu Wszystkie pliki konguracji znajduj si w katalogu /etc/watchdog. Znajduje si tam gªówny plik konguracyjny aplikacji monitoring.properties w który to znajduj si ustawienia poª czenia do bazy danych, serwera ftp, certykatów SSL oraz denicja interwaªu zbierania danych. 2.5 Š czno± Poª czenie jednostka monitoruj ca - serwer Jednostka monitoruj ca ª czy si z serwerem poprzez sie bezprzewodow typu Ad-Hoc. Sie jest zabezpieczona przez niepowoªanym dost pem szesnastkowym kluczem WEP. W celu ustanowienia poª czenia nale»aªo na obu w zªach edytowa plik konguracyjny /etc/network/interfaces. Nale»aªo w nim ustawi interfejs bezprzewodowy wlan0 w nast puj cy sposób: 16

17 auto wlan0 iface wlan0 inet static address netmask wireless-channel 1 wireless-essid atomek wireless-mode ad-hoc wireless-key 5ba323bf25 Dla drugiego w zªa plik konguracyjny ró»ni si tylko adresem i ma warto± : address Poª czenie jest ustanawiane poprzez wpisanie w konsoli na ka»dym z w zªów: iwcong wlan0 essid atomek key 5ba323bf25 ifcong wlan X netmask Poª czenie z jednostk monitoruj ca - komputer debuguj cy W jednostce monitoruj cej zostaª na staªe zostaª przypisany adres /24 do interfejsu sieci ethernet, umo»liwia to poª czenie z systemem operacyjnym za pomoc protokoªu SSH oraz podgl d pracy systemu monitoringu. Mo»liwe jest zalogowanie si na konto u»ytkownika root (hasªo: root). 3 Komponenty jednostki monitoruj cej 3.1 Czujnik temperatury Wykorzystany sprz t Do budowy czujnika wykorzystano: DallasSemiconductor DS1820 temperature sensor; 2 diody schottky BAT 85; dioda zenera 6.2V 1N5234; dioda zenera 3.9V 1N5228; rezystor 1,5KOhm; zª cze RS232C»e«skie. Schemat ukªadu: 17

18 Projekt czujnika daje mo»liwo± podª czania do niego szeregowo dodatkowych sensorów DS1820 jak na schemacie poni»ej (dªugo± przewodu to maksymalnie ok. 30 metrów): Wykorzystane oprogramowanie zewn trzne Do obsªugi czujnika wykorzystano oprogramowanie DigiTemp w wersji Oprogramowanie to jest dost pne na licencji GNU General Public License. DigiTemp umo»liwia odczyt danych z urz dze«typu 1-Wire. Wi cej informacji odno±nie tego projektu mo»na uzyska pod adresem: Sposób dziaªania moduªu Czujnik podª czony jest do portu RS232C komputera. Odpytywany jest przy pomocy magistrali 1-Wire. Mo»liwy jest pomiar w zakresie temperatur od - 55 C do C z dokªadno±ci 0,5 stopnia. Za obsªug czujnika odpowiada klasa Sensor. Do jej konstruktora przekazywane s 2 parametry: nazwa interfejsu (dla RS232 to ttys0); indeks czujnika (w przypadku podª czania wi cej jak jednego, numeracja zaczyna si od 0). Klasa zawiera metod gettemperature(), która zwraca warto± pomiaru w stopniach Celsjusza jako typ oat. 3.2 Czytnik kart Wykorzystany sprz t W tym module wykorzystywany sprz t to dowolny czytnik kart chipowych zgodny ze standardami PC/SC. Czytnik musi obsªugiwa karty utworzone w oparciu o standard ISO-7816 ( dost pny pod adresem ). W naszym projekcie jako wykorzystany sprz t nale»y jeszcze zaliczy legitymacje studenckie Zachodniopomorskiego Uniwersytetu Szczeci«skiego. 18

19 3.2.2 Wykorzystane oprogramowanie Przy korzystaniu z czytnika u»ywane s klasy wbudowane w j zyk Java od wersji 1.6, klasy z pakietu javax.smartcardio. Pozwalaj one na peªn komunikacj ze wszystkimi czytnikami w systemie, jak i oczywi±cie wygodne dla programisty wysyªanie zapyta«i odbieranie odpowiedzi APDU. Dokumentacja package-summary.html. Wszystkie wykorzystywane komendy s do znalezienia w cz ±ci 4 specykacji ISO-7816 http: // Sposób dziaªania System zaprogramowany jest do obsªugi Elektronicznych Legitymacji Studenckich, których dokªadna struktura i zawarto± opisane s w Rozporz dzenie Ministra Nauki i Szkolnictwa Wy»szego z dnia 2 listopada 2006 r. w sprawie dokumentacji przebiegu studiów Search?todo=open&id=WDU System reaguje na takie zdarzenia jak wªo»enie i wyci gni cie karty do/z czytnika. Po wªo»eniu karty nast puje sekwencja komend APDU, takich jak wybranie MF, wybranie folderu SELS za pomoc jego nazwy oraz wybranie konkretnego pliku ELS z danymi studenta. Z karty wyci gany jest numer PESEL studenta ( poniewa» jest jest to unikalny numer identykacyjny ) po czym w bazie danych sprawdzane jest czy dany u»ytkownik systemu ma wystarczaj ce uprawnienia aby dosta si do danego pomieszczenia. Je»eli ma takie uprawnienia musi dodatków wpisa numer PIN który zapisany jest w bazie danych. Dzi ki takiemu zabezpieczeniu mo»na unikn sytuacji gdy po kradzie»y karty niepowoªana osoba mo»e dosta si do chronionego pomieszczenia. 3.3 Moduª powiadamiania SMS Wykorzystany sprz t Dla poprawnego dziaªania moduªu wymagany jest telefon komórkowy 1 z kart sim oraz kabel usb pozwalaj cy na komunikacje pomi dzy komputerem a telefonem komórkowym. Po» dane byªo by tak»e aby aparat telefoniczny miaª mo»liwo± ªadowania baterii podczas poª czenia z komputerem Wykorzystane oprogramowanie Do implementacji moduªu wykorzystane zostaªo oprogramowanie gammu w wersji (strona projektu pozwalaj ce na na komunikacje z komputerem. Do stworzenie pliku konguracyjnego mo»na tak»e wykorzysta aplikacje wammu ( strona projektu b d c nakªadk graczn dla gammu Sposób dziaªania Klasa Phone pozwala, poprzez przekazanie do jej konstruktora odpowiedniego indexu z pliku kon- guracyjnego.gammurc, na utworzenie instancji klasy symbolizuj cej wybrany model telefonu, a nast pnie poprzez metod sendmessage, wymagaj c podania numeru odbiorcy oraz tre±ci wiadomo±ci wysªanie SMS. Przed utworzeniem instancji klasy nale»y nada u»ytkownikowi prawo do zapisu i odczytu z interfejsu z którego korzysta telefon, poprzez dodanie u»ytkownika do grupy dialout. Tworzenie pliku konguracyjnego dla gammu mo»liwe jest w prosty sposób poprzez nakªadk graczn wammu. 3.4 Moduª rejestracji obrazu Wykorzystany sprz t Kamery wideo - moduª rejestracji obrazu jest w stanie obsªu»y dowolna liczb kamer. Podª czane kamery musz by zgodne z interfejsem video4linux w wersji pierwszej. 1 obsªugiwany przez oprogramowanie Gammu

20 3.4.2 Wykorzystane oprogramowanie zewn trzne webcam - program sªu»y do przechwytywania obrazu z kamery i wysyªania go na serwer www za pomoc protokoªu ftp lub ssh w niesko«czonej p tli. Program jest cz ±ci pakietu xavtw. Pakiet ten jest zbiorem aplikacji zawi zanych z interfejsem video4linux. Strona domowa projektu vsftp - to oparty o licencj GPL serwer FTP dla systemów UNIX. Cechuje si du» szybko±ci, bezpiecze«stwem i stabilno±ci. Strona domowa projektu Sposób dziaªania moduªu Program odpalany wraz z jednostk monitoruj c posiada klas odpowiedzialn za inicjalizacj kamer. Klasa nazywa si CameraService. Dla ka»dej kamery inicjalizuje ona specjalny plik konguracyjny zawieraj cy dane zwi zane z rozdzielczo±ci, formatem, ±cie»kami do plików docelowych i tymczasowych, metod kompresji. Klasa ta równie» inicjalizuje obraz z kamery, który jest przechwytywany za pomoc programu webcam i zapisywany na dysku lokalnym jednostki monitoruj cej. Nast pnie ta sama klasa odpowiada za przesªanie wygenerowanego obrazu na serwer ftp, w tym wypadku jest to serwer vsftp. 3.5 Moduª zamka elektromagnetycznego Wykorzystany sprz t Sprz towa realizacja tego moduªu skªada si z dwóch zasadniczych cz ±ci. Pierwsza cz ± jest to urz dzenie rmy Propox o nazwie mmusb245, zbudowane w oparciu o chip rmy FTDI, model FT245BM. Dokªadna dokumentacja urz dzenia dost pna pod adresem download/docs/mmusb245_pl.pdf. Urz dzenie to ma dwa tryby pracy, jeden to wirtualny port COM, drugi to tryb pracy z wykorzystaniem dedykowanych bibliotek programistycznych producenta D2XX. Do naszych celów u»yli±my biblioteki JD2XX która jest portem oryginalnej biblioteki do ±rodowiska Java ( strona projektu ). Druga cz ± sprz towej realizacji to ukªad z zamkiem elektromagnetycznym, skªadaj cy si z takich elementów jak: - dioda typu dioda ±wiec ca - przeka¹nik 5 V - rezystor 10 kohm - elektrozaczep Poª czonych ze sob wg schematu: 20

21 3.5.2 Oprogramowanie zewn trzne Jedyne wykorzystane przez nas oprogramowanie zewn trzne to biblioteka JD2XX, która jest portem oryginalnej biblioteki D2XX pod j zyk Java Sposób dziaªania moduªu Za obsªug rygla odpowiada klasa Rygiel, która posiada metod Open() - otwieraj c zamek. Przy tworzeniu obiektu tej klasy do konstruktora podajemy czas w milisekundach przez jaki ma by otwarty zamek. Je»eli nie podamy parametru zamek b dzie otwierany na domy±ln warto± 5 sekund. Po utworzeniu obiektu tej klasy zamek w systemie ( istnieje mo»liwo± podª czenia wi kszej ilo±ci zamków ) s zamykane. Funkcja do otwierania/zamykania rygla uruchamiana jest w oddzielnym w tku. Otwarcie zamka nast puje po pozytywnej werykacji karty w czytniku oraz powi zanego z ni numeru PIN zapisanego w bazie danych. 4 Scenariusze laboratoryjne 4.1 Sceniariusz I: Certykaty SSL Przebieg wiczenia: 1. Za pomoc pakietu OpenSSL nale»y wygenerowa klucz prywatny razem z plikiem zawieraj cym zgªoszenie certykacji: openssl req -new -keyout new-client-key.pem -out request01.req -cong openssl.cnf 2. Aby móc wykorzysta klucz prywatny do poª czenia mi dzy klientem a serwerem nale»y usun hasªo chroni ce klucz: openssl rsa -in new-client-key.pem -out new-client-key.pem -cong openssl.cnf 3. Wygenerowane zgªoszenie certykacji nale»y wykorzysta do utworzenia certykatu przez CA: openssl ca -in request01.req -cong openssl.cnf 4. Nale»y ustanowi poª czenie mi dzy serwerem a klientem z u»yciem nowo wygenerowanego certykatu klienta podpisanego przez CA. Aby tego dokona nale»y wpisa ±cie»ki do certy- katu CA, certykatu klienta oraz klucza prywatnego klienta w opcjach programu klienckiego: 5. Nast pnie nale»y zbada inne opcje poª czenia podwy»szaj ce bezpiecze«stwo: 21

22 (a) REQUIRE X509 - tryb w, którym od klienta wymaga si posiadania wa»nego certykatu, jednak nazwa podmiotu i wystawcy nie maj znaczenia. (b) REQUIRE ISSUER - tryb w, którym od klienta wymaga si posiadania wa»nego certykatu oraz aby nazwa podmiotu i wystawcy byªa zgodna z tymi wprowadzonymi do bazy. Wi cej informacji o w/w opcjach mo»na uzyska pod adresem refman/5.1/en/grant.html 4.2 Scenariusz II : zmiana karty Cel wiczenia Celem wiczenia jest przeprogramowanie moduªu odpowiedzialnego za odczyt danych z karty Wymagania Karta o znanej strukturze plików, np. ta doª czona do zestawu. Jej specykacja powinna by dost pna w zaª czonym pliku Przebieg wiczenia 1. Najpierw nale»y zaprogramowa kart, w tym celu nale»y wykona nast puj ce polecenia (a) Wybór pliku gªównego karty - select MF ( 00 A4 00 0C 02 3F 00 ) (b) Wybór folderu w którym znajduje si plik do którego b dziemy pisa select DF ( 00 A4 00 0C 02 3F 02 ) (c) Wybór konkretnego pliku do którego b dziemy pisa - select EF ( 00 A4 01 0C ) (d) Operacja zapisu binarnego do pliku, zapisuj c numer odpowiadaj cy peselowi np wykonamy polecenie Update Binary ( 00 B D4 32 DB ), zapisujemy do tego pliku 5 bajtów z danymi. 2. Maj c zaprogramowan kart, aktualizujemy oprogramowanie znajduj ce si na serwerze a konkretnie klas CardService, w taki sposób aby czytaªo wªa±nie zaprogramowane 5 bajtów. Wykomentowujemy kod odpowiedzialny za czytanie i parsowanie danych z Elektronicznych Legitymacji Studenckich i piszemy swój kod odpowiedzialny za czytanie danych z karty. Komendy które musimy wykona aby odczyta nasz numer z karty ró»ni jedynie ostatni komend, któr b dzie Read Binary o postaci : 00 B Komenda zwraca odczytane z karty 5 bajtów. 3. Nale»y doda numer z naszej karty do bazy danych, tak aby byªa ona akceptowana przez system. 4. Je»eli wszystkie polecenia zostaªy wykonane poprawnie, to po wªo»eniu karty do czytnika system powinien wykry odpowiedniego u»ytkownika i umo»liwi dost p do pomieszczenia. 5. Zanim zabierzemy si do programowania, warto sprawdzi skonstruowane komendy programem umo»liwiaj cym odpytywanie karty dowolnymi zapytaniami APDU. Nale»y pami ta,»e jezeli komenda wykonana jest poprawnie zwracany jest kod 90 00, w innym przypadku przyczyny bª dów nale»y szuka w specykacji polece«pod adresem smartcards/smartcard_standard_iso7816-4_6_basic_interindustry_commands.aspx 22