Jízdní řád a jízdenky v mobilním telefonu. Jakub Trnavský

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Jízdní řád a jízdenky v mobilním telefonu Jakub Trnavský Vedoucí práce: Ing. Jiří Havlík Studijní program: Elektrotechnika a informatika, strukturovaný, Bakalářský Obor: Výpočetní technika 10. července 2009

2 iv

3 v Poděkování Chtěl bych tímto poděkovat vedoucímu své bakalářské práce Ing. Jiřímu Havlíkovi za cenné připomínky a rady při tvorbě této práce.

4 vi

5 vii Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne

6 viii

7 Abstract The aim of this work is to implement an electronic ticketing system for public transport. The system will utilize a mobile phone with NFC technology to buy and store a ticket in such way that a ticket inspection will be easy. There also will be an interface for searching timetables in mobile application. The system should show an application of NFC technology in common life. Abstrakt Předmětem této práce je implementace systému pro nákup elektronických jízdenek hromadné dopravy s využitím mobilního telefonu podporujícího technologii NFC. Telefon bude sloužit k zakoupení a také k uložení jízdenky tak, aby její kontrola revizorem byla jednoduchá. V mobilní aplikaci bude připraveno také rozhraní pro vyhledávání jízdních řádů. Systém by měl sloužit jako ukázka použití technologie NFC v systému s reálným uplatněním. ix

8 x

9 Obsah 1 Úvod Motivace Cíle Úvodní studie Odborný článek Případy užití a jejich scénáře Rešerše existujících implementací Systém Dopravního podniku hlavního města Praha Systém Dopravního podniku města České Budějovice Technologie NFC Základní informace Vize technologie Smart karty a tagy NFC v mobilních telefonech Bezpečnost Analýza a návrh řešení Ukládání jizdenky do telefonu Analýza možných řešení Ukládání jízdenek a NFC Návrh bezpečného uložení Základní třídy v systému Sekvenční diagramy Rozhraní pro jízdní řády Architektura systému Výběr implementačního prostředí a komunikačních protokolů Implementační prostředí Komunikační protokoly Návrh uživatelského rozhraní Mobilní rozhraní Webové rozhraní Desktopové rozhraní xi

10 xii OBSAH 5 Implementace Mobilní aplikace ISO14443ConnectionUtil Třída CekaciObrazovka Autentizace JavaCard applet Formát uložené jízdenky Bussines logika Použití JDBCRealm Optimistické zamykání Webová rozhraní a logika JSF stránky Webová logika XML-RPC rozhraní Desktopová aplikace SmartCardUtil Testování 31 7 Závěr 33 Zdroje 35 A Seznam použitých zkratek 37 B Instalační a uživatelská příručka 39 B.1 Příručka pro zákazníky - webové rozhraní B.1.1 Registrace B.1.2 Přihlášení k účtu B.1.3 Zakoupení jízdenky B.1.4 Editace osobních údajů B.1.5 Odhlášení B.2 Příručka pro zákazníky - mobilní aplikace B.2.1 Instalace B.2.2 Spuštění a zvolení operace B.2.3 Zakoupení jízdenky a její nahrání B.2.4 Zobrazení jízdenek B.3 Příručka pro prodejce B.3.1 Zobrazení účtu zákazníka B.3.2 Vložení peněz na účet zákazníka B.3.3 Prodat jízdenku B.4 Příručka pro administrátora B.5 Instalační příručka C Obsah přiloženého CD 45

11 Seznam obrázků 2.1 Diagram případů užití MIDlet a bezkontaktni komunikační API Diagram tříd Sekvenční diagram pro případ užití Registrovat se Sekvenční diagram pro případ užití Koupit jízdenku Rozhraní pro vyhledávání spojení Architektura systému Mobilní rozhraní - Menu a Přihlašovací formulář Mobilní rozhraní - Výběr typu a začátku platnosti jízdenky Webové uživatelské rozhraní - Historie jízdenek Webové uživatelské rozhraní - Zakoupení jízdenky Uživatelské rozhraní desktopové aplikace xiii

12 xiv SEZNAM OBRÁZKŮ

13 Seznam tabulek 3.1 Bezkontaktní komunikační API pro J2ME xv

14 xvi SEZNAM TABULEK

15 Kapitola 1 Úvod 1.1 Motivace S technologií NFC jsem se setkal při práci ve firmě IMA s.r.o. a nadchla mě natolik, že jsem se s ní chtěl seznámit blíže. Při studiu různých materiálů o této technologii jsem se rozhodl, že v rámci seznamování bych rád vytvořil projekt využívající NFC v systému, který by mohl mít reálné využití. Díky právě probíhajícímu zavádění karet Opencard, které slouží také jako průkazka Pražské integrované dopravy, mě napadlo vytvořit podobný systém, který však využívá technologie NFC v mobilním telefonu. Mnoho společností provozujících hromadnou dopravu totiž začíná kromě klasických papírových jízdenek a kupónů nabízet možnost nákupu jízdenek elektronických. Důvodů vedoucích k tomuto kroku může být několik. Jedním je určitě snaha zpříjemnit služby zákazníkům, kteří mohou jízdenky koupit buď přes internet nebo pomocí mobilního telefonu, čímž se vyhnou frontě u prodejce nebo vůbec cestě k němu. Další motivací může být větší efektivita, a tedy nižší výdaje na pracovníky. Odpadá totiž fyzická distribuce jízdenek, nebo případné zadávání dat do počítače, které může provést sám zákazník. Tyto důvody jsou asi nejdůležitější, ale jistě by se našly i další. Řešení jednotlivých systémů se liší, stejně tak jejich výhody a nevýhody. Myslím si, že použití technologie NFC má několik výhod a snažím se to ukázat touto prací. Úvod do NFC technologie viz. kapitola Cíle Implementovat systém pro nákup elektronických jízdenek hromadné dopravy. Umožnit nákup jízdenek pomocí mobilního telefonu. Vhodně použít technologii NFC pro kontrolu jízdenek a jejich ukládání do mobilního telefonu. Připravit mobilní telefon pro připojení systému vyhledávání spojů a využít ho při nákupu jízdenek. 1

16 2 KAPITOLA 1. ÚVOD

17 Kapitola 2 Úvodní studie 2.1 Odborný článek Systém bude umožňovat nákup jízdenek pro hromadnou dopravu. Typy jízdenek budou podle platnosti jednorázové (30 a 60 minut) a časové (30, 90 a 365 dní). Cestující, který bude chtít nakupovat jízdenky se bude muset registrovat pomocí webové aplikace. Jeho účet bude obsahovat unikátní login a heslo pro přihlašování do systému, a dále jméno, příjmení, adresu a telefonní číslo. Tyto údaje, kromě loginu, bude možno změnit. Registrovaný cestující si bude moci vložit peníze na svůj účet a z něj nakupovat jízdenky, jak pomocí mobilního telefonu tak webové aplikace. Po zakoupení budou jízdenky uloženy do mobilního telefonu. Cestující si bude moci zobrazit jednak všechny zakoupené jízdenky ve webové aplikaci a také poslední jízdenky uložené v mobilním telefonu. Revizor bude kontrolovat platnost jízdenek, a to bez nutnosti připojení k internetu. Systém budou používat také dvě skupiny pracovníků: prodejci a administrátoři. Prodejci 1 budou prodávat a nahrávat jízdenky do mobilních telefonů a také vkládat peníze na účty cestujících. Administrátor bude vkládat a případně měnit účty pracovníků, ty budou obsahovat pouze přihlašovací údaje, jméno a příjmení. Také budou měnit parametry jízdenek: cenu a maximální počet dní, který může být mezi aktuálním časem a začátkem platnosti požadované jízdenky. Systém také umožní nalezení spoje pomocí mobilního telefonu a doporučí zakoupení vhodné jízdenky. Systém však nebude implementovat samotné vyhledávání, pouze stanoví rozhraní pro externí systém. Systém musí zabezpečit, aby k jednotlivým službám mohl přistupovat pouze oprávněný uživatel (kontrola loginu a hesla). Informace přenášené přes síť musí být šifrované. Také jízdenky ukládané do telefonu musí být zabezpečeny proti padělání nebo duplikaci. Pro ukládání a kontrolu jízdenek bude systém používat technologii NFC. 1 Prodejcem je v tomto případě myšlen zaměstanec pracující na pobočce dopravního podniku. Nikoliv tedy externí pracovník, jako například trafikant. 3

18 4 KAPITOLA 2. ÚVODNÍ STUDIE 2.2 Případy užití a jejich scénáře V této sekci jsou rozebrány scenáře případů úžití systému zobrazených na diagramu 2.1. Přihlásit se 1. Případ užití začíná ve chvíli, kdy uživatel chce provést akci, která je povolena jen určité skupině, a není přihlášen. 2. Uživatel zadá jméno a heslo. 3. Systém zkontroluje přihlašovací údaje. 4. Systém vytvoří relaci pro uživatele. Alternativní scénář: Pokud přihlašovací údaje nejsou správné, systém relaci nevytvoří a zobrazí varovnou hlášku. Odhlásit se 1. Uživatel vybere volbu Odhlásit se. 2. Systém zruší uživatelovu relaci. Registrovat se 1. Uživatel vybere volbu Registrovat se. 2. Systém zobrazí registrační formulář. 3. Uživatel vyplní údaje. 4. Systém zkontroluje vyplněné údaje. 5. Systém vytvoří uživateli účet patřící do skupiny Cestující. Alternativní scénář: Pokud ve čtvrtém kroku systém zjistí špatně vyplněné údaje, přejde na krok dvě a zobrazí popis chyb. Vyhledat spojení 1. Uživatel vybere volbu Vyhledat spojení. 2. Systém zobrazí formulář s detaily spojení. 3. Uživatel vyplní detaily spojení. 4. Systém vyhledá spojení a zobrazí ho.

19 2.2. PŘÍPADY UŽITÍ A JEJICH SCÉNÁŘE 5 Přihlásit se Uživatel Odhlásit se Registrovat se Neregistrovaný cestující Vyhledat spojení Koupit jízdenku Registrovaný cestující Zobrazit jízdenky Nahrát jízdenky Zobrazit účet cestujícího Prodejce Vložit peníze Prodat jízdenku Vytvořit uživatelský účet Zobrazit uživatelské účty Administrátor Upravit uživatelský účet Upravit parametry jízdenek Obrázek 2.1: Diagram případů užití Koupit jízdenku 1. Uživatel vybere volbu Koupit jízdenku.

20 6 KAPITOLA 2. ÚVODNÍ STUDIE 2. Systém zobrazí dostupné jízdenky. 3. Uživatel vybere požadovanou jízdenku a zadá začátek platnosti. 4. Systém zkontroluje jestli je začátek platnosti v povoleném intervalu a zda má uživatel dostatečný zůstatek na účtu. 5. Systém odečte cenu jízdenky ze zůstatku a uloží ji jako připravenou k nahrání. Nahrát jízdenky 1. Tento případ užití začíná v případě, že uživatel vybere volbu Nahrát jízdenky, nebo pokud byl právě ukončen případ užití Koupit jízdenku aktivovaný z mobilního telefonu. 2. Systém nahraje zakoupené jízdenky připravené k nahrání do mobilního telefonu. Zobrazit jízdenky 1. Uživatel vybere volbu Zobrazit jízdenky. 2. Systém zobrazí všechny zakoupené jízdenky uživatele. Alternativní scénář: Pokud je tato volba aktivována z mobilního telefonu, systém zobrazí pouze jízdenky nahrané v telefonu. Zobrazit účet cestujícího 1. Tento případ užití začíná pokud uživatel zadá login nebo příjmení cestujícího, nebo přiloží telefon ke čtečce. 2. Systém zobrazí zakoupené jízdenky uživatele a jeho zůstatek na účtu. Vložit peníze 1. Tento případ užití začíná po případu užití Zobrazit účet cestujícího, pokud uživatel vybere volbu Vložit peníze. 2. Uživatel zadá částku, která se má vložit. 3. Systém přidá částku na účet cestujícího. Prodat jízdenku 1. Tento případ užití začíná po případu užití Zobrazit účet cestujícího, pokud uživatel vybere volbu Prodat jízdenku. 2. Systém zobrazí dostupné jízdenky. 3. Uživatel vybere požadovanou jízdenku, zadá začátek platnosti. 4. Systém uloží jízdenku. Pokud je telefon u čtečky, nahraje ji do telefonu, jinak ji označí jako připravenou k nahrání.

21 2.3. REŠERŠE EXISTUJÍCÍCH IMPLEMENTACÍ 7 Vytvořit uživatelský účet 1. Uživatel vybere volbu Vytvořit uživatelský účet. 2. Systém zobrazí formulář pro uživatelský účet. 3. Uživatel zadá údaje účtu. 4. Systém zkontroluje vyplněné údaje. 5. Systém vytvoří uživatelský účet. Alternativní scénář: Pokud ve čtvrtém kroku systém zjistí špatně vyplněné údaje, přejde na krok dvě a zobrazí popis chyb. Zobrazit uživatelské účty 1. Případ užití nastává pokud uživatel přejde na administraci nebo zvolí volbu Zobrazit uživatele. 2. Systém zobrazí seznam uživatelských účtu s jejich příslušnostmi ve skupinách. Upravit uživatelský účet 1. Uživatel vybere uživatelský účet k editaci. 2. Systém zobrazí formulář s uživatelským účtem. 3. Uživatel změní údaje. 4. Systém zkontroluje vyplněné údaje. 5. Systém aktualizuje uživatelský účet. Upravit parametry jízdenek 1. Uživatel vybere volbu Upravit parametry jízdenek. 2. Systém zobrazí formulář se seznamem typů jízdenek. 3. Uživatel upraví parametry. 4. Systém aktualizuje typy jízdenek. 2.3 Rešerše existujících implementací Systémů pro elektronické jízdné, které se v České republice i v ostatních zemích zavádějí, je více. Principy se však opakují, vybral jsem proto asi dva nejznámější systémy v České republice.

22 8 KAPITOLA 2. ÚVODNÍ STUDIE Systém Dopravního podniku hlavního města Praha Tento systém obsahuje dva oddělené typy elektronických jízdenek. První je SMS-jízdenka, tu je možno zakoupit odesláním SMS zprávy na dané telefonní číslo. Systém poté pošle zpět SMS zprávu (jízdenku), která obsahuje rozsah platnosti a unikátní posloupnost znaků (zřejmě nějaký hash), podle kterého je možné zkontrolovat pravost jízdenky. Zaplacení jízdenky probíhá tím, že odeslání prvotní zprávy je zpoplatněno operátorem podle ceny jízdenky. Tento způsob nákupu jízdenek je podle mého názoru velmi povedený, nevyžaduje totiž instalaci softwaru nebo speciální nastavení mobilního telefonu, dokonce ani nevyužívá připojení k internetu, placení je také velmi pohodlné. Na druhou stranu není vhodný pro jízdenky s delší platností (v Praze je možno zakoupit pouze klasickou jízdenku na 60 minut). Jednak uchovávat SMS zprávu v telefonu týdny nebo měsíce není úplně uživatelsky přívětivé hlavně pro ty, kterým chodí desítky zpráv denně. Navíc zpráva ne vždy dojde, což by bylo nepříjemné v případě jízdenky v řádu stovek korun. A v neposlední řadě, řádná kontrola těchto jízdenek je zdlouhavá, jelikož je zřejmě nutné on-line porovnat dlouhý řetězec znaků s tím uloženým v systému. 2 Druhý typ elektronických jízdenek je určen pro jízdenky s delší platností (tedy nahrazuje tzv. tramvajenku). Jízdenky je možno zakoupit v internetovém obchodě 3 a poté je pomocí tzv. validátorů nahrát na smart kartu Opencard. Kontrola jízdenek pak probíhá přiložením karty ke čtečce revizora, která mu ukáže nahrané jízdenky. Kontrola jízdenek tedy probíhá zřejmě off-line. 4 Asi jediná nevýhoda tohoto systému je nutnost nahrání jízdenky pomocí validátoru, které se nalézají pouze na několika místech Systém Dopravního podniku města České Budějovice Tento systém umožňuje také nákup SMS-jízdenek podobně jako předchozí. Druhým typem jízdenky je Datová jízdenka, ta se také nakupuje pomocí mobilního telefonu. Systém funguje tak, že uživatel si u dopravní společnosti vytvoří účet a na něj vloží peníze. Poté si nahraje do mobilního telefonu aplikaci, která při nákupu komunikuje se serverem přes internet. Jízdenka se nahrává do paměti telefonu a je přístupná z aplikace. Pravost jízdenky se ověřuje opět unikátní posloupností znaků. Výhodami tohoto přístupu oproti SMS-jízdence jsou jednak nižší náklady pro dopravní společnost (neplatí operátorovi za výběr poplatku), a pro uživatele, že jízdenky nejsou uloženy mezi zprávami SMS. Nevýhodou je opět složitější kontrola jízdenek a také nutnost instalace aplikace, atd. 2 Byl jsem osobně několikrát kontrolován s SMS-jízdenkou, ale nikdy revizor pravost jízdenky podle zmíněné posloupnosti znaků nekontroloval. V případě absence této kontroly, jde vcelku jednoduše vytvořit padělek. 3 Samozřejmě je možné zakoupit jízdenky pro Opencard také klasicky u přepážky. 4 Je to pouze můj předpoklad, ale nevidím důvod, proč by tomu mělo být jinak.

23 Kapitola 3 Technologie NFC 3.1 Základní informace NFC technologie umožnující bezdrátový datový přenos na velmi krátkou vzdálenost (do 10 cm) je standardem definovaným konsorciem NFC forum. NFC operuje na frekvenci MHz a podporuje několik již zavedených ISO standardů jako ISO typu A a B nebo Felica. Ty jsou definovány pro bezdotykové Smart karty a tagy používané např jako platební karty (běžné např. v USA nebo Japonsku) nebo přístupové karty. To umožňuje použít NFC i v systémech, které jsou již zavedené. Součástí specifikace jsou také komunikační módy a formát přenášených dat NDEF pro URI, Chytré plakáty (Smart Posters) a další, viz. [8]. Při komunikaci dvou NFC zařízení je většinou jedno zařízení aktivní a druhé pasivní. Aktivní je čtečka, která má vlastní napájení, a pasivní je karta nebo tag, který většinou vlastní napájení nemá a využívá energii z radiových vln vysílaných aktivním zařízením. Přitom aktivní zařízení vysílá požadavky a pasivní odpovědi. V tomto přístupu je velkou výhodou právě to, že pasivní prvek nepotřebuje vlastní zdroj energie. 3.2 Vize technologie Velký potenciál této technologie spočívá v předpokladu, že bude podporována v mobilních zařízeních, přesněji v mobilních telefonech. V tuto chvíli je implementována pouze v pár modelech, ale do budoucna se počítá s rozmachem. NFC forum specifikuje tři komunikační mody: peer-to-peer, čtení/zápis a NFC emulace karet. Z posledního modu vyplývá, že může nahradit a seskupit do jednoho telefonu již existující platební, přístupové a další karty. Druhý mód otevírá plno nových možností, mobilní telefon může sloužit jako čtečka karet např. na kontrolu jízdenek. Současné ceny a velikosti některých karet jako třeba Mifare Ultralight, která může mít podobu nálepky o velikosti několika čtverečních centimetrů, umožnují vytvořit třeba plakáty na koncert, v kterých bude uložen hypertextový odkaz, a pomocí kterého si objednáme lístky pouhým přiložením mobilního telefonu k plakátu. Podobné možnosti má například bluetooth, ale velkou výhodou NFC je, že tagy mohou být pasivní, a navíc je můžeme jednoduše aktivovat právě pouhým přiložením telefonu. Ve světě probíhá řada pilotních programů s touto technologií, od menších, kde telefon slouží jako alternativa k bezkontaktním kartám, až k inteligentním městům, kde je možno telefonem platit v obchodě, 9

24 10 KAPITOLA 3. TECHNOLOGIE NFC dopravních prostředcích, v automatu na kávu nebo třeba získat slevový kupón na zboží přiložením telefonu k reklamě na ulici. 3.3 Smart karty a tagy Smart karty 1 jsou karty s integrovanými obvody, které mohou zpracovávat data. U nás jsou zatím běžnější kontaktní, klasické platební nebo telefonní karty, bezkontaktní se v tuto chvíli používají nejčastěji jako přístupové karty (např. ČVUT - karty Mifare), ale začínají se využívat například i v dopravních prostředcích (Opencard - Desfire). Technologie NFC využívá, jak je zřejmé, ty bezkontaktní. Smart karty se dají také rozdělit na pouze paměťové, které slouží pro ukládání dat maximálně s možností stanovení přístupových práv, a na karty s mikroprocesorem. Ty umožňují tvorbu komplexnějších aplikací a šifrování. Některé mají celou funkcionalitu vytvořenou výrobcem, jako již zmíněné karty Desfire, do jiných je možno ji vložit přesně podle potřeb systému. To je možné například pomocí appletů využívajících Java Card API, jehož specifikace byla vytvořena firmou SUN právě pro tyto karty. Rozhraní používá malou podmnožinu jazyka Java a je zaměřeno na jednoduché výpočty a podporu šifrovacích algoritmů. Paměť na smart kartách vyhrazená pro tyto applety je v řádek desítek KB. Pro komunikaci mezi čtečkou a smart kartou se používá APDU protokol specifikovaný v ISO Čtečka vysílá příkazy, které se skládají z povinné hlavičky (5B) obsahující jako druhý byte číslo instrukce (další parametry nejsou v tuto chvíli podstatné) a nepovinné datové části (0-255B). Karta vrátí odpověď skládající se z povinného statusu úspěšnosti (2B) a nepovinných dat (0-256B). Čísla instrukcí jsou dána jednak specifikací, výrobcem karty, a také tvůrcem appletu. Tagem je v tomto kontextu myšlen nějaký integrovaný obvod, v kterém jsou uložena malá data. Většinou není třeba, aby měl nějaká přístupová práva nebo šifrování, někdy jsou data dokonce zadrátována přímo při výrobě a jsou jen pro čtení. Může to být RFID tag, ale samozřejmě i smart karta, (což je samozřejmě plýtvání prostředky pokud například uchovává pouze hypertextový odkaz). 3.4 NFC v mobilních telefonech Hlavním průkopníkem NFC na poli mobilních telefonů je firma Nokia. Ta implementovala tuto technologii zatím do dvou telefonů, které jsou v prodeji. Tato firma je také vedoucí v tvorbě specifikace pro bezkontaktní komunikační API pro J2ME, které je vytvořeno také pro potřeby NFC. Ta je definována pod Java Community Process jako JSR-257 a v tuto chvíli obsahuje balíčky uvedené v tabulce 3.4. MIDlet běžící v prostředí Java s implementovaným rozhraním JSR-257 může komunikovat s externími nebo interními Secure elementy, což jsou různé typu Smart karet, a to pomocí ISO14443Connection a APDU příkazů nebo jinými externími tagy, které většinou úchovávají informace v NDEF formátu. Naopak externí čtečky můžou komunikovat s interním Secure elementem, jenž emuluje buď Smart kartu nebo tag. Komunikace mezi jednotlivými rozhraními je zobrazena na obrázku Pro smart karty se v češtině používá také výraz čipové karty.

25 3.4. NFC V MOBILNÍCH TELEFONECH 11 Java balíčky Rozhraní Třídy javax.microedition.contactless TagConnection DiscoveryManager Povinný balíček obsahující nástroje pro na- TargetListener TargetType lezení cílových zařízení a nástroje společné TargetProperties pro všechny cíle. TransactionListener javax.microedition.contactless.ndef NDEFRecordListener NDEFMessage Volitelný balíček pro práci s tagy obsahující NDEFTagConnection NDEFRecord data v NDEF formátu. NDEFRecordType javax.microedition.contactless.rf PlainTagConnection Volitelný balíček pro komunikace s RFID tagy, které nemají data v NDEF formátu. javax.microedition.contactless.sc ISO14443Connection Volitelný balíček definovaný pro komunikaci se Smart kartami. javax.microedition.contactless.visual ImageProperties SymbologyManager Volitelný balíček pro čtení a vytváření VisualTagConnection vizuálních tagů. TargetProperties Tabulka 3.1: Bezkontaktní komunikační API pro J2ME MIDlet Externí čtečka JSR 257 APDU SIM karta APDU Smart karta RFID, NFC, Řadič, Anténa Externí Secure element Externí tag Obrázek 3.1: MIDlet a bezkontaktni komunikační API

26 12 KAPITOLA 3. TECHNOLOGIE NFC 3.5 Bezpečnost Členy NFC fóra jsou jak společnosti zabývající se technologiemi platebních karet, tak i banky. Počítají s použitím této technologie na platební transakce, a proto je bezpečnost jednou z priorit. Přesto, že komunikace probíhá na velmi krátké vzdálenosti, pole, v kterém lze odchytit komunikaci (nebo dokonce, v některých případech i změnit znění zprávy), je větší. Tato vzdálenost samozřejmě závisí na mnoha faktorech od parametrů konkrétního zařízení až po vlastnosti prostředí, nicméně pro základní představu je pro aktivní zařízení kolem 10 metrů a pro pasivní 1m. Kódování použitá pro komunikaci (Millerovo nebo Manchesterské) jsou obecně známá, hrozba odposlouchávání a následného rozkódování zpráv na úrovni radiových vln je tudíž reálná a v případě, že jsou posílána citlivá data, je nutno zajistit jejich šifrování na vyšší vrstvě. V případě smart karet je možno použít různé obecně známe šifrovací algoritmy a autentizaci čtecího zařízení. Výhodou NFC je, že není prakticky možné použít útok man in the middle, který je hrozbou u asymetrického šifrování, jak je dokázáno v [1]. Co se týče secure elementu v podobě smart karty v mobilním telefonu, je zde několik bezpečnostních opatření garantovaných výrobcem. Applety do něj může nahrávat pouze důvěryhodná třetí strana, které výrobce telefonu poskytne klíče k secure elementu. Výrobce appletu (potažmo aplikace, která ho využívá,) ho předá třetí straně, která ho po kontrole na požádání distribuuje do mobilních telefonů (pomocí šifrovaného kanálu přes internet). Tím je jednak zaručena nezávadnost appletu a také to, že se applet nedostane do rukou útočníka, který by mohl zjistit jeho funkcionalitu, případně nějaké klíče. Další opatření je, že MIDlet se k internímu secure elementu může připojit jen v případě, že je podepsán certifikátem důvěryhodných certifikačních autorit, jako je např. Verisign nebo Thawte.

27 Kapitola 4 Analýza a návrh řešení 4.1 Ukládání jizdenky do telefonu Analýza možných řešení Systémy uvedené v řešerši 2.3 používají pro uložení jízdenky do mobilního telefonu dva způsoby. Jednak uložení jako SMS nebo uložení v mobilní aplikaci, tedy nejspíš pomocí Record management store. Jízdenky je tedy možné zobrazit pouze v telefonu, kde jsou uložené. Aby nebylo možné tyto jízdenky podvrhnout, vytvořením stejně vypadající SMS nebo mobilní aplikace, jsou jízdenky opatřeny otiskem. Ten je buď možné zkontrolovat dotazem na server, který jízdenky generuje, zda otisk náleží platné jízdence, nebo zadáním parametrů jízdenky do hashovací funkce v nějakém mobilním zařízení, které otisky generuje. Nevím, který z těchto způsobů se opravdu používá, ale oba jsou vcelku náročné a zdlouhavé. Což může způsobit, jak bylo již zmíněno v rešerši, že revizor otisk nebude vůbec kontrolovat. Navíc je tu možnost zakoupit jednu jízdenku a vytvořit podvrhy v jiných telefonech zkopírováním údajů. To by se dalo vyřešit zahrnutím údaje jednoznačně identifikující mobilní telefon do otisku. Tím by mohlo být třeba telefonní číslo, ale sdělovat takovýto údaj revizorovi by bylo pro cestující zřejmě nepříjemné, možná i nezákonné. Systémy však tyto způsoby používají pro prodej jízdenek s platností maximálně na několik hodin. V takovém případě je tento způsob padělání velmi neefektivní, nícméně u jízdenek s platností v řádu měsíců, jako v navrhovaném systému, by mohl být problémem. Systém Opencard využívá k uložení jízdenek čipovou kartu. Tento způsob by měl být bezpečný, jelikož pro přístup k datům jsou potřeba klíče a komunikaci je možné šifrovat. Kontrola jízdenek uložených na kartě je velmi pohodlná, spočívá v pouhém přiložení karty ke čtečce. Nepříjemností však je nahrávání jízdenek na kartu, které je možné jenom pomocí speciálních zařízení. V případě, že by tento systém měl být využit pro jízdenky z krátkou dobou platností, bylo by nutné použít jinou strategii. Například by se uživatel při vstupu a výstupu z dopravního prostředku identifikoval u čtečky. Čtečky by posílaly informace po síti do systému, který by následně vyhodnotil délku cesty a podle ní odečetl jízdné z uživatelova účtu 1. To by však znamenalo nutnou instalaci čtecích zařízení do všech dopravních prostředků. 1 Podobný systém se zavádí pro vlakovou dopravu v Německu. 13

28 14 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Ukládání jízdenek a NFC Systém Opencard byl zmíněn, přestože mobilní telefon nepoužívá. Technologie NFC totiž vkládá do telefonu funkcionalitu čipových karet. Proto její využití bude mít výhody obou předešlých řešení. V telefonech s technologií NFC jsou většinou emulovány různé typy čipových karet, jako například karta Mifare v telefonu Nokia 6131 NFC[7]. Karta Mifare by byla použitelná pro ukládání jízdenek a implentace by byla jednodušší, protože přístup k ní je možný z vyšší úrovně než jen APDU příkazy. Nicméňe standardizované ovládání je pouze pomocí APDU příkazů. Vzhledem k povaze systému, který by měl fungovat na co nejvíce mobilních telefonech, je tedy žádoucí použít standardizované rozhraní. S tím je spojena implementace vlastního appletu pro platformu JavaCard, který bude nainstalován v secure elementu Návrh bezpečného uložení Z principu secure elementu vyplývá, že pokud je spravován důvěryhodnou třetí stranou, data v něm uložená jsou v bezpečí. V případě uložení jízdenek jsou zde dva kritické momenty: nahrávání a kontrola jízdenky. Při nahrávání jízdenek musí applet ověřit, zda byla jízdenka opravdu vygenerována systémem. To je možné vyřešit připojením otisku z dat jízdenky. Klíč, který bude tento otisk vytvářet, bude uložen na serveru a v secure elementu. Aby nebylo možné takto vygenerovanou jízdenku použít pro jiný telefon, klíč bude unikátní pro každý applet resp. telefon. Při žádosti o nahrání jízdenky bude na server odesláno identifikační číslo secure elementu, podle kterého bude vybrán příslušný klíč. Vzhledem k požadavku kontroly jízdenky bez připojení k síti a faktu, že ke kontrole bude používán také mobilní telefon s technologií NFC, není možné použít podobný postup jako v případě nahrávání. Telefon revizora by totiž musel mít přístup k databázi klíčů. To vyžaduje buď přístup k serveru nebo lokální uložení databáze, což vzhledem k omezené kapacitě mobilního telefonu není možné. Nicméně lze využít faktu, že jízdenka uložená v telefonu je pravá, díky postupu popsanému výše. Zbývá tedy ověřit pravost appletu v secure elementu. To proběhne tak, že telefon revizora pošle náhodné číslo. Secure element z něj vytvoří otisk a pošle ho zpátky k ověření. Klíč použitý pro tento otisk bude stejný pro všechny applety. Aby se zamezilo snaze vygenerovat všechny otisky, před touto kontrolou proběhne stejný proces identifikace telefonu revizora. Klíče budou do secure elementu nahrány při instalaci appletu. Klíče v telefonu revizora budou uloženy v aplikaci. Přestože by nemělo být možné dostat se ke kódu, již nainstalované aplikace v mobilním telefonu, není to vždy zaručeno. Proto by bylo lepší klíče v telefonu revizora uložit do secure elementu a zabezpečit je pinem. Toto bude však ponecháno pro budoucí vývoj. 4.2 Základní třídy v systému Analýzou požadavků na systém vzniklo několik tříd, ty jsou zobrazeny na diagramu 4.1. Jsou zde vidět základní vlastnosti tříd a jejich vztahy. Většina vlastností je zřejmá z diagramu, přesto je uveden jednoduchý slovní popis tříd s případným upřesněním atributů, jejichž jména by mohla být zavádějící.

29 4.2. ZÁKLADNÍ TŘÍDY V SYSTÉMU 15 <<controller>> UzivatelController <<controller>> CestujiciController <<controller>> JizdenkyController existujelogin() : boolean vytvorituzivatele() : void smazatuzivatele() : void getuzivatele() : Uzivatel getcolluzivatele() : Collection upravituzivatele() : void vytvorcestujiciho() : void getcestujiciho() : Cestujici getcolljizdenky() : Collection getjizdenkyknahrani() : Collection vlozitjizdenku() : void vlozitpenize() : void upravitcestujiciho() : void vyhledatcestujiciho() : void getdostupnejizdenky() : Collection upravittypyjizdenek() : void gettypyjizdenek() : void <<entity>> Skupina jmeno : String 1..* 0..* <<entity>> Uzivatel login : String password : String jmeno : String prijmeni : String <<entity>> TypJizdenky nazev : String cena : int id : byte pocetdnipredplatnosti : int 1 0..* <<entity>> Adresa ulice : String psc : String mesto : String 1 1 <<entity>> Cestujici stavuctu : long cislokarty : long telefonicislo : String 1 0..* <<entity>> Jizdenka zacatekplatnosti : Date nakupnicena : int nahrana : boolean Obrázek 4.1: Diagram tříd Uzivatel a Skupiny Tyto třídy slouží k uložení dat pro identifikaci uživatele systému a zjištění jeho práv. Skupiny vyplývají z požadavků: administrátoři, prodejci a cestující. Budou tedy zavedeny při instalaci systému a nebude je možné měnit. Cestujici a Adresa Tyto třídy slouží k uložení informací o uživatelích, kteří patří do skupiny cestující. Atribut cislokarty je identifikační číslo appletu v secure elementu mobilního telefonu. Adresa je modelována jako samostatná entita pro případ, že by bylo nutno v budoucnu k cestujícímu přiřadit více adres. TypJizdenky Třída reprezentuje typy jízdenek, které je možno nakupovat. Ty jsou dány zadáním, proto budou zavedeny při instalaci systému, ale bude možno u nich měnit atributy cena a pocetdnipredplatnosti, který reprezentuje povolenou dobu mezi začátkem platnosti jízdenky a časem, kdy je kupována.

30 16 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Jizdenka Tato třída reprezentuje zakoupenou jízdenku. Atribut cena je zde proto, že cena jednotlivých typů jízdenek se může měnit a je tedy třeba zachovat cenu, která byla za konkrétní jízdenky reálně zaplacena. Atribut nahrana slouží k indikaci, zda byla již jízdenka nahrána do telefonu. UzivatelController Tato třída zajišťuje funkcionalitu spojenou se správou uživatelských účtů, bude tedy využívána převážně administrátorem. CestujiciController Třída zajišťuje funkcionalitu spojenou s účty cestujících a nákupem jízdenek. Bude tedy využívána cestujícím a prodejcem. JizdenkyController Tato třída zajišťuje funkcionalitu spojenou s typy jízdenek. Bude tedy využívána především administrátorem, ale také dalšími uživateli při nákupu jízdenek. 4.3 Sekvenční diagramy Sekvenční diagramy byly vytvořeny pro složitější případy užití. Uvedeny jsou pouze dva, aby nebyla snížena čitelnost textu. Obrázek 4.2: Sekvenční diagram pro případ užití Registrovat se

31 4.4. ROZHRANÍ PRO JÍZDNÍ ŘÁDY 17 Obrázek 4.3: Sekvenční diagram pro případ užití Koupit jízdenku 4.4 Rozhraní pro jízdní řády Systém bude používat jízdní řády pouze k doporučení vhodné jízdenky. Není tedy třeba, aby zpracovával ostatní informace o nalezeném spoji, pouze je vypíše v textovém formátu uživateli. Proto vytvoření textového výpisu bude přenecháno externímu systému. Rozhraní je zobrazeno na obrázku 4.4. Toto rozhraní bude v mobilní aplikaci a při jeho implementaci <<interface>> vyhledavacspojeni vyhledatspojen() : boolean vyhledatdalsi() : boolean setpocatecnistanice() : void setcilovastanice() : void setdatumcas() : void getminutyspoje() : int getpopisspoje() : String getpopischyby() : String Obrázek 4.4: Rozhraní pro vyhledávání spojení

32 18 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ bude nutné vložit modul externího systému do instalačního balíčku. Externí systém však, vzhledem k jeho povaze, bude ve většině případů služba dostupná přes internet. Proto bude toto rozhraní implementováno s využitím XML-RPC a pomocí tohoto protokolu vytvořeno další podobné rozhraní. V tomto případě by k externímu systému byla pouze vytvořena webová služba komunikující pomocí stejného protokolu. 4.5 Architektura systému Systém bude mít tři uživatelská rozhraní: webové - pro cestující a administrátora desktopová aplikace - pro prodejce mobilní aplikace - také pro cestující Použití webového rozhraní jednak vyplývá ze zadání a navíc je vhodné, protože uživatel může aplikaci obsluhovat odkudkoli z osobního počítače, který je připojen na internet. Důvodem pro zvolení desktopové aplikace pro prodejce byla potřeba přístupu ke čtečce při nahrávání jízdenek do telefonu. Přístup z webové aplikace k periferiím je sice možný, ale bývá poměrně problematický. Prodejci budou navíc aplikaci používat stále ze stejného místa a nebudou tedy omezováni instalací aplikace na určitém počítači. Pro přístup k systému z mobilního telefonu byla zvolena mobilní aplikace. Přístup k technologii NFC je totiž zatím možný pouze z Java aplikace. Právě použití více uživatelských rozhraní je jedním z důvodů proč systém bude implementován pomocí n-vrstvé architektury, zobrazené na diagramu 4.5. Bussines logika, která bude komunikovat s databází, bude nasazena v samostatném kontejneru. Další komponenty budou volat její funkce a přímo je zobrazovat, jako desktopová aplikace, nebo je dále použijí ve svých funkcích, jako webová logika. Tímto přístupem se zamezí opakování kódu v různých komponentách. Tato architektura má i další výhody, např. zjednodušení dalšího vývoj systému nebo jeho lepší škálovatelnost. 4.6 Výběr implementačního prostředí a komunikačních protokolů Implementační prostředí Pro serverovou část systému je zvolena platforma J2EE viz.[4] a to konkrétně technologie EJB 3.0, JPA a JSF. Důvodem je, že tato platforma má velmi dobrou podporu pro vývoj vícevrstvých aplikací a zjednodušuje vývoj díky podpoře častých úkonů. Těmi jsou např. autentizace a řízení přístupu, řízení transakcí nebo persistence dat. Většinu těchto úkonů je možno řídit deklarativně pomocí anotací. Technologie EJB slouží k tvorbě bussines logiky. JPA obsluhuje entity, tedy perzistenci dat. JSF je nadstavba JSP a slouží k tvorbě webového rozhraní. K JSF existují alternativy, které jsou mnohem pokročilejší. Tato technologie je použita, protože webové rozhraní tohoto systému nepotřebuje žádné speciální funkce a práce

33 4.6. VÝBĚR IMPLEMENTAČNÍHO PROSTŘEDÍ A KOMUNIKAČNÍCH PROTOKOLŮ19 PC Webový prohlížeč <<https>> 0..* 1 Webový kontejner Webová logika <<https>> 0..* 1 Webová služba Mobilní telefon Mobilní aplikace 1 1 PC Desktopová aplikace <<rmi>> 0..* 1 Bussines kontejner Bussines logika Entity 1 <<SQL>> 1 Databáze Tabulky Obrázek 4.5: Architektura systému s JSF je příjemná. K volbě platformy J2EE, také přispěl fakt, že software potřebný k tvorbě a běhu jejích aplikací je dostupný zdarma. Vzhledem k volbě serverové části systému je vhodné k implementaci desktopové aplikace pro prodejce použít opět jazyk Java, konkrétně platformu J2SE viz.[5]. Ta umožňuje jednoduché volání bussines logiky pomocí Java RMI. Navíc v součinosti z J2EE je možné vytvořit tzv. aplikačního klienta, který odsťiňuje prográmátora i od RMI, tím že při nasazení enterprise aplikace je vytvořen lightweight kontjner, který se následně nainstaluje spolu s aplikačním klientem. Pro mobilní aplikaci musí být použita platforma J2ME, jelikož v tuto chvíli není možné používat NFC technologii v mobilním telefonu z jiného prostředí. Nicméně J2ME poskytuje všechny potřebné prostředky jako komunikaci přes https nebo jednoduchou tvorbu GUI. Dalším kladem je jednoduchá přenositelnost MIDletů, která je však zatím limitována nízkým počtem telefonů podporujících NFC. Pro tvorbu uživatelského rozhraní budou použity standardní komponenty, jejichž vzhled není striktně určen normou a závysí na výrobci telefonu. Tento způsob je vhodný z pohledu výkonnosti a přenositelnosti, nicméně rozhraní

34 20 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ bude vypadat na různých telefonech odlišně Komunikační protokoly Komunikaci mezi jednotlivými komponentami systému bude většinou probíhat přes veřejnou síť internet. Je proto nutné, aby informace byly při přenosu šifrovány a nemohly být zneužity nepovolanou osobou. Komunikace bude probíhat přes protokol SSL, který poskytuje bezpečné šifrování. Volba protokolů http (webové rozhraní) a RMI (desktopová aplikace) byla jednoduchá. Http je klasický a rozšířený protokol pro přístup k webovým stránkám a není důvod používat jiný. Použití protokolu RMI je implementačně jednoduché a výkonnostně efektivní. Má pouze nevýhodu, že je spjat s určitou technologií (v tomto případě Java) a že je někdy třeba upravit nastavení firewallů, aby nebyla komunikace blokována. Nicméně desktopová aplikace bude instalována pouze u prodejců, kde je možno prostředí počítačů a sítě upravit. Tím jsou zmíněné problémy nepodstatné. Pro komunikaci mezi mobilní aplikací a serverem bude použit protokol XML-RPC. Další možné varianty by byly: RMI, SOAP, vlastní protokol. První alternativa není vhodná, protože v budoucnu vyrobené telefony podporující NFC nemusí podporovat J2ME. Proto v případě tvorby mobilní aplikace pro jinou platformu by bylo nutné vytvořit další rozhraní na straně serveru. Tento problém by vyřešilo použití dalších dvou zmíněných alternativ. Tvorba vlastního protokolu nad protokolem TCP by bylo zbytečně náročné. SOAP je podobný protokolu XML-RPC a má větší možnosti. Nicméně jeho nároky na přenášená data jsou větší, což je při komunikaci přes mobilní síť podstatný nedostatek. XML-RPC je kompromisem mezi těmito variantami z pohledu přenositelnosti, náročnosti implementace a velikosti přenášených dat.

35 4.7. NÁVRH UŽIVATELSKÉHO ROZHRANÍ Návrh uživatelského rozhraní Mobilní rozhraní Vzhledem k volbe implementacního prostredí pro uživatelské rozhraní mobilní aplikace, a tedy k faktu, že bude vypadat odlišne na ruzných telefonech, rozhraní neobsahuje specialní grafické prvky a je strukturováno do jednoduchých obrazovek. Náhledy vybraných obrazovek jsou na obrázku 4.6 a 4.7. Obrázek 4.6: Mobilní rozhraní - Menu a Přihlašovací formulář Obrázek 4.7: Mobilní rozhraní - Výběr typu a začátku platnosti jízdenky

36 22 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Webové rozhraní Webové rozhraní má jednoduchý přehledný design podobný běžným webovým stránkám, aby se uživatel mohl rychle zorientovat. V levé části je umístěno menu a vpravo obsah dané stránky. Ukázkové stránky jsou na obrázku 4.8 a 4.9. Obrázek 4.8: Webové uživatelské rozhraní - Historie jízdenek Obrázek 4.9: Webové uživatelské rozhraní - Zakoupení jízdenky