Bankovní institut vysoká škola Katedra Informatiky a kvantitativních metod
NFC technologie a její využití Bakalářská práce
Autor:
Michal Kraus Informační technologie, Správce informačních systémů
Vedoucí práce:
Praha
Ing. Bc. Jiří Rezler
červen 2015
Prohlášení: Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Praze dne Michal Kraus
Anotace Bakalářská práce je zaměřena na podrobný popis NFC technologie a zároveň nabízí moţnosti vyuţití této technologie. Cílem práce je navrhnou aplikaci vyuţívající NFC technologii, která usnadní ţivot efektivním pojetím kaţdodenních situací. Klíčová slova: NFC (Near Field Communication), RFID (Radio Frequency Identification), NDEF (NFC Data Exchange Format), Android Annotation The Bachelor thesis is being focused on detailed description of NFC technology and it also shows opportunities of use of this technology. Goal of the thesis is to design an application that uses NFC technology, which makes life easier using effective access to everyday situations. Keywords:
NFC
(Near
Field
Communication),
RFID
Identification), NDEF (NFC Data Exchange Format), Android
(Radio
Frequency
Obsah Úvod ............................................................................................................................... 8 1. NFC technologie ......................................................................................................... 9 1.1. Představení NFC .................................................................................................. 9 1.2. Porovnání NFC a RFID ....................................................................................... 9 1.2.1. RFID ............................................................................................................. 9 1.2.2. NFC............................................................................................................... 9 1.2.3. RFID podrobněji ......................................................................................... 10 1.2.4. RFID standardy ........................................................................................... 11 1.2.5. NFC podrobněji .......................................................................................... 11 1.3. NFC Data Exchange Format (NDEF)................................................................ 11 1.3.1. Typologie NDEF záznamů ......................................................................... 12 1.3.1.1. Jednoduchý textový záznam (Simple text record) ................................ 12 1.3.1.2. Uniform Resource Identifier (URI) ....................................................... 12 1.3.1.3. Chytrý obrázek (Smart poster) .............................................................. 12 1.3.1.4. Podpis (Signature)................................................................................. 12 1.3.2. NDEF podrobněji........................................................................................ 12 1.3.2.1. Struktura NDEF .................................................................................... 12 1.3.2.2. Type Name Format (TNF) .................................................................... 14 1.3.2.3. Typ payloadu......................................................................................... 14 1.3.2.4. URI jako součást NDEF zprávy ............................................................ 15 1.3.2.5. Payload ID............................................................................................. 16 1.3.2.6. Payload .................................................................................................. 16 1.3.2.7. Struktura záznamu................................................................................. 16 1.3.2.8. Hlavička záznamu ................................................................................. 17 1.3.3. Velikost NDEF zprávy ............................................................................... 18 4
1.3.3.1. Omezení velikosti ................................................................................. 18 1.3.3.2. Velikost z hlediska výměny dat ............................................................ 18 1.3.3.3. Zřetězení záznamů ................................................................................ 19 1.4. Architektura NFC .............................................................................................. 19 1.5. Peer-to-peer výměna .......................................................................................... 21 1.5.1. Handover (předání) ..................................................................................... 23 1.5.2. Static Handover (statické předání).............................................................. 24 1.6. Card Emulation (emulace karet) ........................................................................ 25 1.7. Typy NFC tagů .................................................................................................. 26 1.7.1. Typ 1 ........................................................................................................... 26 1.7.2. Typ 2 ........................................................................................................... 26 1.7.3. Typ 3 ........................................................................................................... 27 1.7.4. Typ 4 ........................................................................................................... 27 1.7.5. Mifare Classic tag (ISO–14443A) .............................................................. 27 1.8. Kompatibilita typů tagů a zařízení ..................................................................... 27 1.9. Zpracování NFC v Androidu ............................................................................. 28 1.9.1. Pouţití intent filtru ...................................................................................... 28 1.9.2. Android Application Record....................................................................... 30 1.9.3. Android Beam ............................................................................................. 31 1.10. Moţnosti vyuţití NFC ..................................................................................... 31 2. Vyuţití NFC v praxi ................................................................................................. 31 2.1. NFC v souvislosti s platebními operacemi ........................................................ 31 2.1.1. Platební karty .............................................................................................. 31 2.1.1.1. PayPass a payWave ............................................................................... 31 2.1.2. Klíčenky, náramky, hodiny, nálepky .......................................................... 32 2.1.3. Mobilní zařízení s NFC .............................................................................. 32 2.1.4. Současné trendy a moţnosti........................................................................ 33 5
2.1.4.1. Vyuţití ve světě ..................................................................................... 33 2.1.4.2. Situace v ČR.......................................................................................... 33 2.2. Další moţnosti vyuţití NFC .............................................................................. 34 2.2.1. Identifikační karty ....................................................................................... 34 2.2.2. Nastavení profilu doma/auto....................................................................... 35 2.2.3. Domácí zařízení audio/TV .......................................................................... 35 2.2.4. Ovládání světel ........................................................................................... 35 2.2.5. Správa majetku ........................................................................................... 36 2.2.6. Sledování zásilek ........................................................................................ 36 3. Návrh řešení NFC aplikace ....................................................................................... 36 3.1. První myšlenka .................................................................................................. 37 3.2. Architektura ....................................................................................................... 37 3.3. Koncept .............................................................................................................. 37 3.4. Modul pro cestující ............................................................................................ 38 3.4.1. Úvodní popis ............................................................................................... 38 3.4.2. Dlouhodobé kupóny.................................................................................... 38 3.4.3. Krátkodobé jízdenky ................................................................................... 38 3.4.4. Elektronická peněţenka .............................................................................. 38 3.4.5. Historie ....................................................................................................... 39 3.4.6. Uţivatelské nastavení ................................................................................. 39 3.5. Modul pro revizory ............................................................................................ 40 3.5.1. Úvodní popis ............................................................................................... 40 3.5.2. Dlouhodobé kupóny.................................................................................... 40 3.5.3. Krátkodobé jízdenky ................................................................................... 40 3.5.4. Elektronická peněţenka .............................................................................. 40 3.5.5. Historie ....................................................................................................... 40 3.5.6. Uţivatelské nastavení ................................................................................. 41 6
3.6. Modul pro pokladní systémy ............................................................................. 41 3.6.1. Úvod ........................................................................................................... 41 3.6.2. Dlouhodobé a krátkodobé jízdenky ............................................................ 41 3.6.3. Elektronická peněţenka .............................................................................. 41 3.6.4. Historie ....................................................................................................... 42 3.6.5. Uţivatelské nastavení ................................................................................. 42 3.7. Moţná rozšíření aplikace ................................................................................... 42 3.7.1. Příměstská doprava ..................................................................................... 42 3.7.2. Pokuty ......................................................................................................... 43 3.7.3. Přenosné jízdenky ....................................................................................... 43 3.7.4. Jízda více lidí na jednu jízdenku ................................................................. 44 3.7.5. Prodejní automaty ....................................................................................... 44 3.7.6. Zabezpečení aplikace .................................................................................. 45 4. Předpokládané přínosy navrhovaného řešení ........................................................... 45 4.1. Odpadá nutnost karet a průkazů jednotlivých dopravců.................................... 45 4.2. Přihlašování do aplikace nevyţaduje zadání hesla ............................................ 46 4.3. Veškeré transakce online a okamţitě ................................................................. 46 4.4. Detailní přehled všech provedených transakcí .................................................. 46 4.5. Moţnost prokázání platného dokladu i bez zařízení.......................................... 46 Závěr ............................................................................................................................. 47 Pouţité zdroje ............................................................................................................... 48 Seznam obrázků ............................................................................................................ 49 Seznam zkratek ............................................................................................................. 49
7
Úvod V rámci neustálé modernizace současného svět musíme počítat s nástupem nových technologií i v oblasti datové komunikace. NFC technologie přináší na rozdíl od WiFi nebo Bluetooth přenos dat na mnohem kratší vzdálenost. Jelikoţ je nutný minimální odstup zařízení účastnících se komunikace, povaţuje se spojení za velice důvěrné. Pro vytvoření spojení tak proto odpadá nutnost ověřování. Díky této výhodě se NFC pouţívá například jako iniciátor spojení dvou zařízení právě pomocí WiFi nebo Bluetooth, čímţ se obejde nutnost párování. Další vyuţití NFC je v oblasti bezkontaktního placení. NFC zařízení se dokáţe chovat jako bezkontaktní platební karta, tudíţ pomocí této technologie lze pouţít pro platbu na bezkontaktním terminálu telefon místo klasické platební karty. V takovém případě jsou údaje o kartě uloţeny na zabezpečeném umístnění v telefonu a přenos dat je šifrován. Jelikoţ má NFC technologie spoustu zajímavých moţností vyuţití, kladu si v práci za cíl seznámit čtenáře podrobněji s tím, jak technologie funguje. Podrobným popisem jednotlivých způsobů komunikace a struktur přenášených dat buduji poţadovanou znalost, díky které se dá lépe pochopit současné vyuţití a fungování technologie. Na základě zjištěných poznatků se pokusím navrhnout nové vyuţití NFC technologie, které by přineslo určité vylepšení situací kaţdodenního ţivota. Na závěr se shrnuji očekávané přínosy navrhovaného řešení.
8
1. NFC technologie 1.1. Představení NFC Near Field Communication neboli NFC je technologie slouţící pro bezdrátovou komunikaci mezi zařízeními na velmi krátkou vzdálenost. Je to vlastně jen soubor standardů obsahujících komunikační protokoly. Tato technologie je jakousi odnoţí technologie RFID (Radio Frequency Identification), která zahrnuje komunikaci s veškerými typy čipů pouţívané na evidenci majetku, ochranu zboţí, docházkové systémy, atd.
1.2. Porovnání NFC a RFID Pojďme to vzít ale od začátku. Co vůbec je RFID? Tuto technologii pouţíváme pravděpodobně kaţdý den, ačkoliv si to moţná ani neuvědomujeme. Vezmeme-li situace od placení platebními kartami, přes projetí mýtné brány na dálnicích, aţ po běţný příchod do práce a průchod turniketem po přiloţení identifikační karty. To vše má souvislost s RFID. A jaký je rozdíl mezi RFID a NFC? NFC je v podstatě rozšířením RFID, vyuţívá některé RFID standardy pro získání více moţností vyuţití této technologie a moţnosti výměny sloţitějších datových struktur.
1.2.1. RFID Vezměme si situaci, kdy sedíte doma večer na pohovce a rozsvítíte si lampičku. Najednou uvidíte za oknem souseda, který jde okolo, a poznáte jeho obličej. To je princip pasivního RFID. Vysláním signálu ze zdroje vybudíte identifikaci tagu. Přesněji řečeno, tag absorbuje energii ze zdroje a vyšle identifikační signál zpět. Nyní si představte, ţe jako reakci na rozsvícení vaší lampičky, rozsvítí soused lampičku ve svém domě. Oba na sebe vidíte a můţete se pozdravit. To je aktivní RFID. Signál můţe překonat větší vzdálenost, jelikoţ druhý prvek nečerpá energii vyslanou ze zdroje, ale má svůj zdroj energie. RFID komunikace je obdobná těmto dvěma lampičkám. Se sousedem na sebe vidíte, ale příliš si nepopovídáte. RFID není ke komunikaci, slouţí pouze pro identifikaci. RFID tagy mohou nést pouze omezené mnoţství dat (zpravidla maximálně tisíce bytů) a zprávy, které mohou sdělovat, jsou velice triviální.
1.2.2. NFC Nyní si představte, ţe rozsvícením své lampičky upoutáte pozornost souseda a pozvete ho dále, přičemţ s ním prohodíte pár slov. To je NFC. NFC je postaveno na RFID přičemţ podporuje rozsáhlejší výměnu dat mezi účastníky komunikace. I pomocí NFC můţete číst a zapisovat na RFID tagy, ale stále jen data standardního formátu nezávislého na typu tagu. Můţete ale navíc komunikovat s druhým NFC zařízením obousměrnou výměnou dat. Kromě
9
výměny záznamů můţete navíc např. zahájit déle trvající komunikaci zprostředkovanou jinou technologií. Chcete třeba pomocí NFC přehrát hudbu ze svého telefonu na svém audio zařízení (podporující NFC). Na základě NFC komunikace se navzájem zařízení dozví, ţe mají k dispozici WiFi a vymění si přístupové údaje pro tuto komunikaci. Jakmile spustíte přehrávání, telefon začne vysílat audio stream přes WiFi do audio zařízení. Proč není k přenosu pouţito stále NFC? K tomu existují dva důvody. Zaprvé, NFC spojení je dostupné pouze na krátké vzdálenosti, obvykle do 10cm. To dovoluje spotřebu menšího mnoţství energie neţ u ostatních typů přenosu a zároveň omezuje narušení spojení interferencí ostatních radiových technologií zařízení. Zadruhé, ve srovnání s WiFi, Bluetooth a ostatními komunikačními protokoly je NFC poměrně pomalé. NFC není navrţeno pro vysokorychlostní přenos dat. Jeho podstatou je přenos krátkých zpráv, výměna přístupových údajů a spárování zařízení. NFC navíc přináší ještě mnohem dokonalejší moţnosti. Podporuje totiţ určité mnoţství předdefinovaných instrukcí bez nutnosti zadávání hesla, párování přístrojů, apod. Pokud budete chtít přenést třeba fotografii z jednoho zařízení na druhé, stačí pouze zařízení přiloţit k sobě a NFC jiţ vše zařídí, aby se fotografie zobrazila i na druhém zařízení. Stejně tak je moţné přenášet kontakty, URL webových stránek, odkazy na aplikace, atd. Pokud jste navíc opravdový fanoušek NFC a zařídíte si vše potřebné, můţete přiloţením svého zařízení platit na bezkontaktních terminálech stejně jako by to byla vaše platební karta.
1.2.3. RFID podrobněji Pokud bychom chtěli více informací o RFID, neţ jen to, ţe je to analogie k lampičce, díky které poznáme identitu souseda, je potřeba zjistit, jak RFID ve skutečnosti funguje. RFID výměna dat zahrnuje dva účastníky, a sice cíl a původce. Původce, ať uţ se jedná o čtecí, nebo čtecí i zapisovací zařízení, zahajuje výměnu dat vytvořením radiového pole a následně čeká na odpověď od kteréhokoliv cíle v tomto poli. Cíl, zpravidla RFID tag, odpovídá, jakmile je zasaţen signálem původce. Jako odpověď odesílá svoje UID (unique identifier number). Jak bylo zmíněno dříve, jsou dva způsoby komunikace. Aktivní a pasivní. Pasivní RFID vyvolává čtecí zařízení, zatímco tag nemá ţádný zdroj energie. Pro odeslání odpovědi vyuţívá tag energii právě z radiového pole vytvořeného původcem. Obvykle se jedná pouze o malé mnoţství energie, právě takové, aby bylo moţné vyslat signál s odpovědí. Při aktivním RFID má jak původce, tak cíl svůj zdroj energie. Identifikace pak můţe proběhnout na mnohem větší vzdálenost. Aktivní RFID se pouţívá např. v mýtných branách na dálnicích.
10
1.2.4. RFID standardy Navzdory všeobecnému přesvědčení, RFID nezahrnuje pouze jeden standard popisující protokol nebo technologii. Standardů jsou desítky. Standardy jsou vydávány mezinárodní organizací ISO (International Standards Organization) ve spolupráci s předními účastníky na trhu RFID. ISO zde vystupuje jako mediální faktor, který pomáhá jednotlivým společnostem v různých odvětvích průmyslu tak, aby jejich technologie mohly vzájemně komunikovat. Několik standardů popisuje povolené radiové frekvence pro komunikaci, rychlost datového přenosu, datové formáty, atd. Některé z těchto standardů popisují jednotlivé vrstvy zásobníku pro výměnu dat, který je vyuţíván i v NFC. Další standardy pak popisují kompletní různé třídy aplikací. Na příklad standard ISO-11784 byl původně vyvinut pro stopování zvířat. Pouţívá frekvence mezi 129 a 139.4kHz a formát datových polí pro popsání sledovaného zvířete. Standard ISO-14443 byl vyvinut pro pouţití s platebními systémy a smart kartami. Vyuţívá frekvence 13.56MHz1.
1.2.5. NFC podrobněji NFC jsme si představili jako rozšíření RFID. NFC také zahrnuje cíl a původce, stejně jako RFID. Nicméně, NFC umí více neţ jen výměnu UID a čtení a zápis na cíl. Největší rozdíl spočívá v tom, ţe NFC cíle jsou často naprogramovatelná zařízení. To znamená, ţe na místo statických dat můţe cíl generovat unikátní odpověď pro kaţdou výměnu a tu následně odeslat původci. V praxi to můţe znamenat, ţe například podmíníte rozsah informací předávaného kontaktu, pokud dojde k interakci s doposud neznámým původcem. NFC má stejně jako RFID dva způsoby komunikace. Pokud cíl vyuţívá radiofrekvenční energie původce, pak se jedná o pasivní způsob. V případě, ţe oba účastníci komunikace mají svůj zdroj energie, jedná se o aktivní způsob. NFC zařízení má ale tři módy provozu. Zaprvé, můţe fungovat jako čtecí a zapisovací zařízení. Dále můţe fungovat jako karetní emulátor, ve smyslu stejné role jako RFID tag. Nebo můţe být v módu peer-to-peer, kdy dochází k výměně dat oběma směry.
1.3. NFC Data Exchange Format (NDEF) Posílaná data mezi NFC zařízeními a tagy jsou formátována pomocí NFC formátu pro výměnu dat (NFC Data Exchange Format). NDEF je klíčovou výhodou NFC oproti RFID. Je to jednotný datový formát, který funguje napříč všemi NFC zařízeními. Ačkoliv RFID i NFC protokoly fungují na stejné frekvenci (13.56 MHz), rozdíl v komunikaci je právě ve formátování dat. RFID neformátují data do NDEF formátu. Rozličné RFID protokoly nesdílí ţádný jednotný formát. 1
Jednotlivé standardy brány ze zdroje: IGOE TOM, Beginning NFC, str. 14
11
Kaţdý NDEF záznam má definován typ záznamu, unikátní ID, délku a samotná data, která nese. Existuje několik běţně pouţívaných typů NDEF záznamů. S těmito typy by si měla NFC zařízení intuitivně automaticky poradit. Jednotlivé typy NDEF záznamů můţete míchat v rámci NDEF zprávy, nebo poslat zprávu pouze o jediném záznamu. Zpráva se ale obvykle skládá z více záznamů, stejně jako odstavec se skládá z jednotlivých vět.
1.3.1. Typologie NDEF záznamů 1.3.1.1. Jednoduchý textový záznam (Simple text record) Tento typ nese libovolný textový řetězec, který si přejete poslat. Textové zprávy zpravidla neobsahují instrukce pro cílové zařízení, jak s nimi naloţit. Mohou obsahovat metadata, jako je znaková sada, jazyk, kódování, atd.
1.3.1.2. Uniform Resource Identifier (URI) Tento typ obsahuje webovou adresu. NFC zařízení, které dostane NDEF záznam typu URI, by mělo předat tuto informaci aplikaci, která můţe danou adresu zobrazit, zpravidla webový prohlíţeč.
1.3.1.3. Chytrý obrázek (Smart poster) U tohoto typu je překlad do češtiny skoro aţ nevhodný. Jedná se jiţ o komplexnější typ. Bývá to standardně reálný obrázek třeba jako reklama v dopravním prostředku. Tento obrázek můţe mít přiloţená další data, ať uţ URI nebo textovou zprávu. Zařízení, které obdrţí takovýto NDEF záznam by mělo spustit aplikaci právě dle typu přiloţených dat. Můţe to být opět webový prohlíţeč, ale klidně i SMS nebo emailový klient. Do aplikace se pak promítne obsah NDEF záznamu, tak aby smart poster splnil svůj účel.
1.3.1.4. Podpis (Signature) Tento typ, jak uţ název napovídá, by měl obsahovat důvěrné informace o původu dat obsaţených v NDEF záznamu.
1.3.2. NDEF podrobněji 1.3.2.1. Struktura NDEF NDEF je binární formát strukturovaný do zpráv, z nichţ kaţdá můţe obsahovat několik záznamů. Kaţdý záznam se skládá z hlavičky, která obsahuje metadata o záznamu (jako je typ záznamu, délka, atd.), a dále nese samotná data tzv. payload. Na NDEF zprávu se dá nahlíţet stejně jako na odstavec sloţený z jednotlivých vět. Správný paragraf by měl obsahovat věty týkající se jednoho tématu. Stejně tak NDEF zpráva by se měla skládat ze záznamů popisující jeden společný předmět, např. adresu. 12
NFC transakce jsou obvykle krátké. Kaţdá výměna dat zpravidla obsahuje jen jednu zprávu a kaţdý tag nese většinou také pouze jedinou zprávu. Je potřeba mít na paměti fyzické okolnosti NFC výměny dat. Celá výměna dat musí proběhnout v době přiloţení zařízení k tagu nebo k jinému zařízení, coţ je jak známo na velmi krátkou vzdálenost. Není ţádoucí pomocí NFC posílat celou knihu, přenos slouţí opravdu pouze pro odstavec. Takto je nutno nahlíţet na NDEF zprávy. Samozřejmě je k dispozici náhradní řešení, jak pomocí NFC lze přenášet velké soubory. Zatím ale budeme brát NFC výměnu dat jako přenos jedné NDEF zprávy o několika málo NDEF záznamech. NDEF záznam nese samotná přenášená data (payload2) a metadata popisující, jak nesená data interpretovat. Payload kaţdého záznamu můţe být jedním z několika datových typů. Hlavička kaţdého záznamu obsahuje metadata popisující záznam a jeho pozici v celé zprávě, následované jeho typem a ID. Za hlavičkou je umístěn samotný payload. Na
Obrázek 1: Struktura NDEF, zdroj: IGOE TOM, Beginning NFC, str. 50
následujícím obrázku je vše podrobně rozkresleno. Na obrázku je vidět, ţe NFC záznam se skládá z názvu typu formátu (type name format), typu payloadu, ID payloadu a samotného payloadu. Payload je nejdůleţitější část NDEF záznamu, jedná se o samotná data, která jsou přenášena. TNF určuje, jak interpretovat typ payloadu. Typ payloadu je buď konkrétní NFC typ, MIME media typ, nebo URI, které popisuje jak interpretovat payload. Zjednodušeně řečeno TNF je metadato ohledně payload typu, zatímco payload typ je metadato samotného payloadu. Payload ID je nepovinné metadato, které slouţí k odkazům na payload.
2
Definice payloadu ze zdroje: IGOE TOM, Beginning NFC, str. 50
13
1.3.2.2. Type Name Format (TNF)
NDEF záznam počíná názvem typu formátu (TNF3). TNF definuje strukturu hodnoty v poli typu payloadu. TNF určuje, jak interpretovat pole typu payloadu. Existuje sedm moţných hodnot TNF: 0 Empty Prázdný záznam jak bez typu tak payloadu. 1 Well-Known Jeden z několika předdefinovaných typů specifikovaných NFC fórem v RTD (Record Type Definition) specifikaci. 2 MIME media-type Typ media definovaný v RFC 2046. 3 Absolute URI URI definováno v RFC 3986. 4 External Uţivatelsky definovaná hodnota zaloţená na pravidlech NFC fóra pro RTD. 5 Unknown Typ je neznámý. Délka typu musí být 0. 6 Unchanged Pouze pro prostřední nebo koncové záznamy zřetězených payloadů. Délka typu musí být 0. 7 Reserved Reservováno NFC fórem pro budoucí vyuţití. Ve většině aplikacích se můţeme setkat s TNF 01 (Well-Known) nebo TNF 02 (MIME). Ještě poměrně časté je TNF 04 (External) v Android aplikacích, jelikoţ tento typ (nazýván Android Application Record) je vyuţíván jako spouštěč Android aplikací.
1.3.2.3. Typ payloadu Typ payloadu, nebo také někdy nazýván typ záznamu, popisuje konkrétněji samotný obsah payloadu. Formát typu payloadu je určen TNF záznamu. Typ payloadu můţe být specifický NDEF typ, MIME, URI, nebo externí typ. Pravidla pro vytvoření vlastního externího typu jsou specifikována v NDEF Record Type Definition (RTD4). Navíc je v RTD i specifikace Well-Known typů. Ostatní typy jsou specifikovány v MIME RFC respektive URI RFC. 3 4
Jednotlivé typy TNF brány ze zdroje: IGOE TOM, Beginning NFC, str. 51 Zdroj: NFC Forum: Technical Specifications
14
Například záznam s TNF 01 (Well-Known) můţe mít typ záznamu "T" jako textová zpráva, "U" jako URI nebo "Sp" jako smart poster. Záznam s TNF 02 (MIME) můţe mít typ záznamu třeba "text/html", "text/json" nebo "image/gif". Záznam s TNF 03 (URI) obsahuje v poli typu payloadu absolutní URI dle RFC 3986. Záznam s TNF 04 (External) můţe mít opět více typů payloadu, zmiňovaný AAR (Android Application Record) je ve tvaru "android.com:pkg". NDEF zpráva můţe obsahovat více záznamů s rozdílnými typy payloadu, nicméně dle konvence typ prvního payloadu určuje, jak se s NDEF zprávou bude nakládat. Například Android intent filtr NDEF zpráv se dívá pouze na první záznam.
1.3.2.4. URI jako součást NDEF zprávy Pro pořádek je potřeba nastínit rozdíl mezi URI, URL a URN. URI (Uniform Resource Identifier) je řetězec znaků určující webový zdroj. URN (Uniform Resource Name) definuje jméno URI. Zatímco URL (Uniform Resource Locator) definuje typ transportního protokolu, který je potřeba pouţít k dosaţení webového zdroje. V přeneseném významu URN je moje jméno, URI je moje adresa a URL definuje, ţe ke mně domů je potřeba jet autobusem. V praxi se můţe jednat o tyto hodnoty: URN mojeAplikace URI cz.bivs.mojeAplikace (v reverzním formátu domén) URL http://bivs.cz/mojeAplikace Oproti zmíněným informacím, NDEF záznamy typu TNF 03 (URI) jsou trochu zavádějící. TNF popisuje tvar hodnoty typu payloadu, nikoliv tvar samotného payload. TNF 03 tedy určuje, ţe NDEF záznam má URI obsaţeno v poli typu payloadu. URI v poli typu payloadu následně popisuje payload stejně jako MIME popisuje payload v případě TNF 02. Například Windows a Windows Phone pouţívají TNF 03 jako spouštěcí záznamy pro spuštění aplikací stejně jako Android vyuţívá externího typu Android Application Record. Pokud patřičná aplikace, která má být spuštěna, není nainstalována, otevře se okno pro její staţení z obchodu. Android má odlišný přístup k NDEF záznamům TNF 03. Ačkoliv dle NDEF specifikace typ záznamu popisuje payload, Android po načtení TNF 03 záznamu otevře
15
webový prohlíţeč, do kterého zobrazí hodnotu URI v payload typu jako by se jednalo o payload. BlackBerry a Windows Phone při načtení TNF 03 prohlíţeč standardně neotevírají5. V případě, ţe chceme poslat URI nebo URL v rámci payloadu, neměli bychom pouţít TNF 03 (URI). Měli bychom pouţít TNF 01 (Well-Known) záznamového typu "U" (URI). NDEF specifikace poskytuje RTD URI specifikaci s identifikačními kódy pro účinnější kódování URI. Například 0x01 je kód pro http://www, zatímco 0x02 je kód pro https://www. URI v rámci payloadu můţeme rovněţ kódovat pomocí TNF 01 (Well-Known) záznamového typu "Sp" (Smart poster). Pouţití Smart poster dovoluje připojit doplňující informace k URI, jako je popisný text ve více jazycích, ikony a volitelné procesní instrukce.
1.3.2.5. Payload ID Identifikátor payloadu, coţ je volitelné pole, by měl obsahovat platné URI. Samozřejmě se můţe jednat o relativní URI, takţe platné je v podstatě cokoliv. Pouţívá se aplikacemi pro identifikaci payloadu v rámci záznamu pomocí ID, nebo pro moţnost ostatních payloadů odkazovat na jiné payloady.
1.3.2.6. Payload Payload je vlastní nesený obsah záznamu. Můţe to být, cokoliv chceme, v případě, ţe se to vejde do vymezeného pole bytů. Řádně vybudovaná NDEF knihovna se neohlíţí na to, co je v payloadu, jen to zkrátka pošle. Payload můţeme šifrovat, nebo poslat v podobě prostého textu. Můţeme také poslat blob (binary large object) nebo cokoliv jiného, co nás napadne. Vše závisí pouze na odesílací a přijímací aplikaci, aby se shodly na tom, co payload vyjadřuje a jaký má formát. Na obrázku byl vidět podrobnější binární rozbor hlavičky NDEF záznamu. Tyto informace pravděpodobně nebudeme nikdy potřebovat v rámci implementace v případě, ţe budeme pouţívat dobře napsanou NDEF knihovnu. Binární formátování by měla obstarat místo nás.
1.3.2.7. Struktura záznamu Prvních pět bitů NDEF záznamu jsou příznaky, které říkají jak se záznamem nakládat a kde ve zprávě se záznam nachází. Bitové příznaky prvního bytu hlavičky záznamu jsou následující6: MB (Message Begin) Pravda, pokud je tento záznam první ve zprávě. ME (Message End) 5 6
Tvrzení bráno ze zdroje: IGOE TOM, Beginning NFC, str. 52 Struktura prvního bytu dle zdroje: IGOE TOM, Beginning NFC, str. 53
16
Je pravda, pokud je tento záznam poslední ve zprávě. CF (Chunk Flag) Je pravda, pokud se jedná o zřetězený záznam. SR (Short Record) Je pravda, pokud je pro délku payloadu pouţit krátký formát. IL (ID Length is present) Je pravda, pokud záznam obsahuje pole s délkou ID. Je potřeba podotknout, ţe IL bit není délka pole ID, ale pouze informuje, zda se pole pro délku v záznamu nachází. Pokud IL je 0, pak záznam neobsahuje ani pole pro ID, ani pole pro délku ID. Bitové příznaky Message Begin a Message End jsou vyuţívány pří zpracování záznamů v rámci zprávy. Díky tomu, ţe NDEF zpráva je pouze pole obsahující jeden nebo více NDEF záznamů, neexistuje pro NDEF zprávu ţádný binární formát. Bitové příznaky MB a ME nám pomáhají určit, kde zpráva začíná a kde končí. První záznam ve zprávě bude mít nastaven MB příznak na pravdu, prostřední záznam budou mít oba příznaky nastaveny na nepravdu a poslední záznam bude mít ME nastaven na pravdu. Pokud bude zpráva obsahovat pouze jeden záznam, bude oba příznaky MB i ME nastaveny na pravdu. Jelikoţ jsme si v předchozích kapitolách představili osm moţných názvů typů formátu (TNF), potřebujeme 3 bity na jeho zakódování do záznamu. TNF tedy zabírá poslední 3 bity v prvním bytu rezervovaném pro bitové příznaky záznamu.
1.3.2.8. Hlavička záznamu NDEF záznamy jsou datové struktury s proměnlivou délkou. Hlavička záznamu proto obsahuje informace poţadované pro správnou interpretaci dat obsaţených v záznamu. NDEF záznam začíná TNF bytem, který obsahuje i bitové příznaky. Dále je v hlavičce záznamu pole délky typu. Toto pole má velikost také jeden byte a určuje délku typu payloadu v bytech. Pole délky typu je povinné, ale můţe být nula. Následuje délka payloadu. Toto pole závisí na bitovém příznaku SR (short record) z prvního bytu hlavičky. Pokud je SR nastaveno na pravdu, pak pole délky payloadu má jeden byte, jinak má čtyři byty. Délka payloadu je povinná, ale můţe být 0. Pokud je bitový operátor IL (ID Length) nastaven na pravdu, pak další byte hlavičky je délka ID. V opačném případě následuje rovnou pole typu záznamu. Pole délky typu záznamu (druhý byte hlavičky) určuje, kolik bytů se načte (jako typ záznamu). Pokud je obsaţeno ID záznamu, následuje po poli typu záznamu. Délka pole ID záznamu je určena bytem pro délku ID. Tímto končí hlavička záznamu a následuje payload. 17
1.3.3. Velikost NDEF zprávy 1.3.3.1. Omezení velikosti
Payload NDEF záznamu je omezen délkou 232-1 bytů, coţ vychází z čtyřbytového
pole hlavičky pro délku payloadu (v případě, ţe se nejedná o short record). Nicméně, záznamy mohou být zřetězeny do zpráv, aby mohly přenášet delší payload. Teoreticky neexistuje limit délky NDEF zprávy. V praxi je však délka omezena moţností daného zařízení, které se účastní komunikace. V případě, ţe probíhá peer-to-peer výměna dat mezi dvěma zařízeními (nikoliv zařízením a tagem), NDEF zprávy jsou limitovány pouze výpočetní kapacitou daných zařízení a pozorností člověka, který drţí zařízení fyzicky u sebe tak, aby nedošlo k přerušení spojení. Pokud probíhá výměna dat mezi zařízením a tagem, pak je zpráva omezena velikostí paměti tagu. V případě pouţití NFC tagů, velikost záznamů je také omezena 232-1 byty. Typy NFC tagů jsou zaloţeny na různých RFID standardech. Většina typů NFC tagů je zaloţena na standardu ISO-14443A. Tyto typy mají velikost paměti od 96 bytů aţ po 4MB v závislosti na typu tagu. Rodina tagů Philips/MXP Mifare je kompatibilní s NFC, zahrnující tagy Mifare Ultralight, Mifare Classic 1K a 4K a Classic Mini. Existuje jeden typ tagů zaloţen na japonském průmyslovém standardu (Japanese Industrial Standard) JIS X 6319-4. Tyto tagy paměť velikou aţ 1MB. Zpravidla se jedná o tagy Sony FeliCa7.
1.3.3.2. Velikost z hlediska výměny dat Obecně NFC výměna dat je krátká. Osoba přidrţí své zařízení v blízkosti tagu nebo jiného zařízení, proběhne krátká výměna dat a tím přenos končí. Samozřejmě v případě, ţe přijatá data mají vyvolat nějakou reakci, pak se jedná rovnou i o začátek něčeho dalšího. Nicméně, nejedná se o protokol navrţený pro déletrvající výměny dat, neboť obě zařízení musejí být fyzicky opravdu téměř v kontaktu. V případě posílání delších zpráv, uţivatel musí drţet zařízení u druhého tak dlouho, dokud se celá zpráva nepřenese, coţ můţe být zdlouhavé. Proto lidé obecně preferují pomocí NFC pouze vyměnit nutné údaje a následně pro přenos dat přejít na WiFi nebo Bluetooth. Nastíním typický příklad, jak mohou NFC a WiFi efektivně spolupracovat. Dejme tomu, ţe mám doma audio zařízení, které dokáţe synchronizovat seznam hudby s mým telefonem prostřednictvím WiFi a domácího souborového serveru. Poslouchám album na audio zařízení, ale musím odejít do práce. Přiloţím telefon k audio zařízení a to sdělí telefonu pomocí NFC jakou skladbu zrovna přehrává a jaká doba ještě zbývá přehrát. Jako reakce na tuto zprávu si telefon ověří, zda má danou skladbu v paměti a pokud ne, stáhne si ji ze 7
Parametry typů tagů dle zdroje: IGOE TOM, Beginning NFC, str. 55
18
souborového serveru pomocí WiFi. Jakmile odcházím z bytu, nasazuji sluchátka a pokračuji v poslechu skladby tam, kde audio zařízení skončilo.
1.3.3.3. Zřetězení záznamů
V případě, ţe chceme poslat obsah větší neţ 232-1 bytů, můţeme payload rozdělit do jednotlivých kusů a poslat jej na několik částí. Jakmile toto uděláme, musíme nastavit bitový příznak Chunk Flag na pravdu v prvním a všech následujících zřetězených záznamech kromě posledního. Nelze zřetězit záznamy napříč NDEF zprávami. TNF záznamu je určeno v prvním zřetězeném záznamu, ostatní zřetězené záznamy musí mít nastaven TNF 06 (Unchanged). Všechny zřetězené záznamy kromě prvního musí mít nastavenu délku typu záznamu na 0. Délka payloadu kaţdého záznamu určuje payload daného zřetězeného kusu. Zřetězení záznamů se na první pohled nepouţívá moc často, jelikoţ to znamená mít zprávu delší neţ 500MB (coţ odpovídá 232 bytům). Nicméně, zřetězení záznamů se dá pouţít i na dynamické generování obsahu, zvláště tam, kde můţeme vyuţít skutečnosti, ţe délka payloadu není dopředu známá. Obecně se však zřetězení pouţívá spíše zřídkakdy. Některé knihovny zřetězení ani neimplementují.
1.4. Architektura NFC Jestliţe chceme porozumět NFC více do hloubky, je dobré se podívat na celkový model architektury. Musíme však vzít v potaz několik vrstev. Nejniţší vrstva je fyzická, zahrnuje CPU a radiové zařízení vykonávající komunikaci. Uprostřed jsou datové pakety a transportní vrstva. Následují vrstvy datových formátů a nakonec zdrojový kód aplikace. Následující obrázek vše podrobně vykresluje.
19
Obrázek 2: NFC stack, zdroj: IGOE TOM, Beginning NFC, str. 16
Ve fyzické vrstvě NFC pracuje na základě RFID specifikací. Jde o ISO-14443-2, které popisuje nízkoenergetické radiové vlny, které pouţívají frekvenci 13.56MHz. Následuje vrstva, která popisuje rozdělení datových bytů do rámců, odesílaných radiovými vlnami. Jedná se o ISO-14443-3. Jakákoliv radiová zařízení, která jsou pouţita, jsou samostatné hardwarové prvky, ať uţ uvnitř telefonu nebo tabletu, nebo se jedná o přídavné komponenty osobního počítače. Tyto prvky komunikují s hlavním procesorem zařízení pomocí jednoho nebo více standardních protokolů: universal asynchronous receive-transmit (UART), serial peripheral interface (SPI), interintegrated circuit communication (I2C), nebo universal serial bus (USB)8. Na obrázku je následně vidět několik RFID protokolů zaloţených na dvou specifikacích. Původní RFID specifikace, kterou vyuţívá i NFC pro čtení a zápis na tagy je postavena na ISO-14443A. Protokoly Philips/NXP Semiconductors Mifare Classic a Mifare Ultralight a NXP DESFire protokoly jsou kompatibilní s ISO-14443A. NFC peer-to-peer výměna dat je postavena na protokolu ISO-18092. RFID karty a tagy Sony FeliCa, které jsou převáţně dostupné v Japonsku, jsou rovněţ postaveny na tomto standardu. Můţete číst a zapisovat na tagy pomocí těchto standardů, nicméně stále nebudete vyuţívat NFC. 8
Protokoly brány dle zdroje: IGOE TOM, Beginning NFC, str. 16
20
Prvním hlavním rozdílem mezi RFID a NFC je komunikace peer-to-peer, která je implementována pomocí standardu ISO-18092. Existují dva protokoly, které zajišťují peer-topeer výměnu dat. Jedná se o logical link control protocol (LLCP) a simple NDEF exchange protocol (SNEP)9. Druhým hlavním rozdílem mezi RFID a NFC je NFC formát výměny dat (NDEF) umístěný nad těmito protokoly. NDEF specifikuje výměnu dat ve zprávách, které jsou sloţeny z NDEF záznamů. NDEF umoţňuje, aby aplikace mohla pohodlně zpracovat přijatá data ať uţ z NFC tagu při čtení nebo zápisu, peer-to-peer výměně dat nebo emulaci karet.
1.5. Peer-to-peer výměna Výměna dat typu peer-to-peer probíhá mezi dvěma zařízeními NFC. Jedná se pouze o moţnost NFC technologie, nikoliv RFID. V kaţdé výměně dat peer-to-peer máme také cíl a původce. V tomto případě jsou oba účastníci aktivní NFC zařízení, coţ znamená, ţe cíl obdrţí NDEF zprávu pomocí peer-to-peer, data přijaté v této zprávě si můţe cíl nějakým způsobem zpracovat a následně sestaví odpověď, kterou odešle zpět původci. Můţeme také v zařízení uloţit informaci z přiloţeného tagu a přeposlat ji do jiného zařízení nebo tagu. Peer-to-peer výměna dat nabízí více takových zajímavých moţností. Peer-to-peer výměna dat je postavena na NFC protokolu Simple NDEF Exchange Protocol (SNEP). SNEP je protokol popisující komunikaci typu ţádost-odpověď. Původce odesílá ţádost s popisem dat, které by chtěl získat, a cíl vrací odpověď s poţadovanými daty. SNEP je postaven na protokolu NFC fóra Logical Link Control Protocol (LLCP). Samozřejmě s protokoly SNEP a LLCP nepřijdeme přímo do styku, nicméně je dobré vědět, jaké místo mají v architektuře NFC, jelikoţ to pomůţe vysvětlit rozdíl mezi peer-to-peer výměnou dat a klasickým načtením a zapisováním tagu. SNEP a LLCP neurčují, jak by měla být peer-to-peer komunikace zajištěna na straně operačního systému ani jak by měla být presentována uţivateli. Kaţdý operační systém implementuje SNEP a LLCP vlastním způsobem. Aktuální Android implementace se nazývá Android Beam (před verzí Android 4.0 měl Android implementaci nazývanou NDEF Push Protocol). Při pouţití Beamu stačí dvě Android zařízení přiloţit zadní stranou k sobě a objeví se rozhraní "Touch to beam". Jakmile se klepne na obrazovku zařízení, které má odeslat data, spustí se tím peer-to-peer komunikace s cílovým zařízením a data jsou odeslána jako NDEF zpráva nebo jako sada několika NDEF zpráv. Beam je navrţen tak, ţe nám dovoluje působit v horních vrstvách zásobníku dle obrázku architektury NFC. Beam odstiňuje peer-to-peer
9
Protokoly převzaty ze zdroje: IGOE TOM, Beginning NFC, str. 16
21
komunikaci a jím přijaté NDEF zprávy od standardního rozhodování, jak se má zařízení zachovat v případě, ţe dojde k přiloţení obyčejného tagu (a tato událost je odchycena pomocí intent filtru). Jakmile máme povoleno NFC na zařízení, Beam udrţuje NFC radiový modul aktivní a vyhledává spojení s jinými zařízeními nebo tagy. V případě, ţe dojde ke spojení, Beam spustí rozhraní "Touch to beam", ať uţ aktuálně běţí jakákoliv aplikace. V případě, ţe aktuálně běţící aplikace má naimplementovánu funkčnost sdílení informací na základě peer-to-peer komunikace, pak data určená k přenosu jsou odeslána do cílového zařízení. V opačném případě Android odešle NDEF zprávu s URI dané aplikace. Pokud cílové zařízení má tuto aplikaci nainstalovanou, pak dojde k jejímu spuštění. Pokud aplikace na zařízení dostupná není, otevře se Google Play obchod s odkazem na ni.
Obrázek 3: Android Beam UI, zdroj: IGOE TOM, Beginning NFC, str. 175
22
Tímto se Android Beam odlišuje od předchozích implementací peer-to-peer komunikace na Androidu a implementací na ostatních operačních systémech. Toto předdefinované chování můţe být někdy neţádoucí, ale dá se zakázat v souboru AndroidManifest.xml, který je stěţejním konfiguračním souborem Android aplikace.
Obrázek 4: AndroidManifest.xml edit, zdroj: IGOE TOM, Beginning NFC, str. 175
1.5.1. Handover (předání) Peer-to-peer komunikace pracuje perfektně s krátkými zprávami, ale jakmile je potřeba poslat nějaký větší soubor ať uţ třeba audio nebo fotografii, tento typ komunikace uţ není tak výhodný. Během doby, co výměna probíhá, je nutno drţet zařízení u sebe, takţe v případě posílání velkých souborů by mohlo dojít k nutnosti drţet zařízení v kontaktu poměrně dlouhou dobu, coţ není ţádoucí. Pro tuto situaci je navrţena specifikace NFC Connection Handover Specification10. Jakmile je přijata zpráva typu handover, NFC knihovna ověří, zda na operačním systému, na kterém běţí, není lepší nástroj pro přenos větších souborů jako Bluetooth nebo WiFi, a pokusí se přenést data tímto způsobem. Handover vypadá asi takto. Původce odešle NDEF zprávu, která začíná záznamem typu Handover Request Record (TNF: Well-Known typ, RTD: Handover Request ("Hr")). Následuje několik záznamů typu Alternative Carrier Records (TNF: Well-Known typ, RTD: Alternative Carrier ("ac")). Tyto záznamy jsou iniciátory pro zahájení přenosu pomocí ostatních způsobů, které jsou dostupné na původci, jako je Bluetooth nebo WiFi. Payload těchto záznamů je vţdy MAC adresa alternativy přenosu. Jakmile cíl obdrţí takovou zprávu, odpovídá typem Handover Selector Record (TNF: Well-Known typ, RTD: ("Hs")) a svojí sadou záznamů alternativ přenosu. Tyto záznamy jsou zpravidla setříděny dle preference cílového zařízení. Následně si původce vybere alternativu přenosu a odešle zprávu typu Handover Carrier (TNF: Well-Known typ, RTD: ("Hc")) společně se záznamem zvolené alternativy. Cílové zařízení následně odpoví také zprávou typu Handover Carrier obsahující konfigurační data a přístupové údaje tak, aby poţadovaná data
10
Specifikace dle zdroje: IGOE TOM, Beginning NFC, str. 185
23
mohla být přenesena bez nutnosti Bluetooth párování, WiFi přihlášení nebo jiného ověřování11. Je zřejmé, ţe pro nastavení alternativního přenosu je potřeba vyměnit několik zpráv. Samozřejmě i zde platí, ţe je potřeba drţet zařízení u sebe dokud neproběhne kompletní nastavení, jinak se navázání spojení nepodaří. Kaţdopádně se ale jedná o mnohem kratší domu neţ, kdyby se pomocí NFC přenášely celé soubory. Pokud funguje handover správně, jedná se o velice efektivní způsob komunikace. Není potřeba provádět ţádné párování, ani sdělovat si nějaká hesla. Dokonce v případě, ţe Bluetooth nebo WiFi je vypnuté, NFC poţádá zařízení o zapnutí příslušného kanálu, aby přenos mohl proběhnout. Navíc součástí handover protokolu je moţnost uvádět potřebnou energii pro přenos jednotlivými alternativami přenosu z důvodu, aby alternativní přenos příliš neubral z výdrţe baterie. Existují určité nesnáze, se kterými se můţeme setkat v případě pouţití handoveru. Pokud je alternativní způsob zrovna pouţíván, přenos dat můţe selhat. Například pokud budu streamovat audio pomocí Bluetooth a zároveň budu chtít odeslat soubor v rámci handover, rychlost přenosu se rapidně sníţí, nebo přenos úplně selţe. Samozřejmě také v případě, kdy se zařízení od sebe vzdálí natolik, ţe alternativní způsob přenosu ztratí spojení, dojde rovněţ k selhání.
1.5.2. Static Handover (statické předání) Nabízí se otázka, zda jde handover pouţít i se zařízením, které nemá NFC. Přece jenom navázání spojení přiloţením zařízení k sobě bez nutnosti ověřování je velice efektivní. Řešení je NFC tag, který bude obsahovat záznam typu Handover Selector Record společně se zprávou s uloţenou konfigurací alternativního přenosu daného zařízení bez NFC. Pokud se NFC zařízení pokusí navázat spojení s takovýmto tagem, výsledkem bude pokus o navázání spojení alternativní cestou se zařízením bez NFC dle konfigurace obsaţené ve zprávě. V praxi si lze představit příklad, ţe chceme vytvořit spojení mezi Android zařízením s NFC a iPhone bez NFC. K iPhone zařízení přilepíme pasivní NFC tag s informacemi o Bluetooth nebo WiFi konfiguraci v rámci zprávy typu Handover Selector Message. Pokud se Android zařízení přiblíţí k přilepenému tagu na iPhonu, pokusí se navázat spojení s iPhonem na základě poskytnutých konfiguračních dat ve zprávě. Jelikoţ navázání spojení není řízeno handover protokolem, není nijak ověřováno, zda zařízení bez NFC má daný alternativní způsob přenosu povolen a připraven k pouţití. V případě, ţe tomu tak není, spojení selţe, nebo uţivatel iPhonu musí explicitně povolit daný 11
Zmíněné pouţité TNF a RTD převzaty ze zdroje: IGOE TOM, Beginning NFC, str. 185
24
způsob přenosu. Pokud však uţivatel dokáţe bez potíţí nastavit ručně spojení mezi zařízeními, můţe to být snazší cesta, neţ konfigurovat připojení pomocí NFC nálepky a řešit static handover.
1.6. Card Emulation (emulace karet) Vedle standardního čtení a zapisování na tagy a peer-to-peer komunikace je moţné NFC zařízení pouţít v módu karetního emulátoru. NFC zařízení v tomto módu figuruje vůči ostatním zařízením jako by se jednalo o NFC tag. Coţ znamená, ţe se zařízení můţe chovat jako bezkontaktní čipová karta. Takový fakt můţe mít spoustu vyuţití. V případě, ţe se zařízení chová jako čipová karta, čtecí zařízení ověřuje data na kartě nejen pomocí přihlašovacích údajů, ale také jestli ID přiloţené karty odpovídá datům na kartě. Například pokud na je na platební kartě uloţeno číslo bankovního účtu a karta (potaţmo zařízení emulující danou kartu) má stejné UID jako karta vydaná bankou, pak můţe bankomat nebo platební terminál provést transakci stejně tak jako kdyby člověk přiloţil pravou platební kartu. Emulace karet je právě navrţena pro finanční operace, jako je tato. Na této technologii je postavena Google Wallet12 a další systémy, kdy se zařízení tváří jako platební nebo kreditní karta. V případě takového vyuţití však musí být daná aplikace zabezpečená. Banky a ostatní účastníci si musí být jisti, ţe systém je bezpečný. Proto NFC fórum přišlo se specifikací, kde NFC čtecí zařízení obsahují bezpečnostní prvky součástí hardwaru (obecně nazýváno jako secure element). Zpravidla se jedná o jednoduchý procesor, který je přidruţen k NFC modulu. Tento bezpečnostní prvek můţe být naprogramovaný tak, aby ověřoval, ţe odeslaný kód pouţívá šifrování a dešifrování pomocí veřejného klíče. Jelikoţ bezpečnostní prvek čtecích a zapisovacích zařízení je schopný sám obhospodařit běh malých programů (nazývány applety nebo taglety), můţe dokonce generovat nové hashe za běhu. V případě, ţe má člověk plnou kontrolu nad bezpečnostním prvkem, můţe jeho chování nastavit tak, jak potřebuje. Jelikoţ můţe NFC zařízení emulovat čipové karty, dalo by se navrhnout, aby veškeré karty, které nosíme v peněţence (platební karty, přístupové a identifikační karty) byly emulovány v zařízení. Toto je teoreticky moţné, ale v praxi téměř nerealizovatelné. Znamenalo by to, ţe by více poskytovatelů karet muselo spolupracovat s výrobcem zařízení a mobilním operátorem, který poskytuje základní software do zařízení. Pro emulaci všech karet by do bezpečnostního prvku musela mít přístup moje banka, výrobce bezpečnostního systému zaměstnanců v práci, dopravce poskytující přepravu dopravními prostředky, kterými jezdím
12
Dle zdroje: IGOE TOM, Beginning NFC, str. 193
25
do práce, atd. Ačkoliv je to technologicky moţné, z politického hlediska není realizace příliš pravděpodobná. Přístup do bezpečnostního prvku je zpravidla omezena výrobcem zařízení ve smlouvě s výrobcem softwaru a firmwaru. Standardní distribuce Androidu neobsahuje ţádné API pro přístup do bezpečnostního prvku na NFC zařízeních, na kterých má Google licenci pro běh Androidu. Samozřejmě je moţné získat přístup do bezpečnostního prvku na základě vytvoření smlouvy s určitými poskytovateli a výrobci. V případě, ţe velká bankovní společnost bude chtít implementovat telefonní platby pomocí NFC, určitě se domluví jak s Googlem (jakoţto výrobcem softwaru), tak i s předním výrobcem zařízení na spolupráci. Pokud by však nějaká malá firma o pár lidech chtěla implementovat svůj systém do bezpečnostního prvku, asi by se kladné odezvy nedočkala.
1.7. Typy NFC tagů
Existují čtyři typy specifikované NFC fórem13, všechny zaloţené na RFID protokolech
popsaných výše. Navíc existuje pátý typ, který je kompatibilní, ale není striktně součástí NFC specifikace. Typy 1, 2 a 4 jsou zaloţeny na ISO-14443A, zatímco typ 3 je zaloţen na ISO18092.
1.7.1. Typ 1 •
Zaloţen na specifikaci ISO-14443A.
•
Můţe být pouze ke čtení, nebo pro čtení a zápis.
•
Velikost paměti od 96 bytů po 2 kilobyty.
•
Komunikační rychlost 106Kbps.
•
Ţádná prevence datové kolize.
•
Příklady: Innovision Topaz, Broadcom BCM20203.
1.7.2. Typ 2 •
Podobně jako tagy typu 1 jsou i tagy typu 2 zaloţeny na NXP/Philips Mifare Ultralight (ISO-14443A) specifikaci tagu.
•
Můţe být pouze ke čtení, nebo pro čtení a zápis.
•
Velikost paměti od 96 bytů po 2 kilobyty.
•
Komunikační rychlost 106Kbps.
•
Podpora předcházení kolizím.
•
Příklad: NXP Mifare Ultralight.
13
Zdroj NFC Fórum: Technical specifications Parametry a příklady typů dle zdroje: IGOE TOM, Beginning NFC, str. 17
26
1.7.3. Typ 3 •
Tyto tagy jsou zaloţeny na Sony FeliCa tazích (ISO-18092 and JIS-X-6319-4), bez podpory šifrování a autentizace, kterou FeliCa nabízí.
•
Jiţ z výroby určeno, zda je tak pouze ke čtení, nebo pro čtení a zápis.
•
Proměnlivá velikost paměti aţ 1MB pro výměnu dat.
•
Dvě komunikační rychlosti - 212 nebo 424Kbps.
•
Podpora předcházení kolizím.
•
Příklad: Sony FeliCa.
1.7.4. Typ 4 •
Podobně jako tagy typu 1, jsou tagy typu 4 zaloţeny na NXP DESFire (ISO14443A) specifikaci tagu.
•
Jiţ z výroby určeno, zda je tak pouze ke čtení, nebo pro čtení a zápis.
•
Proměnlivá velikost paměti aţ 32KB pro výměnu dat.
•
Tři komunikační rychlosti: 106, 212, nebo 424Kbps.
•
Podpora předcházení kolizím.
•
Příklady: NXP DESFire, SmartMX-JCOP.
1.7.5. Mifare Classic tag (ISO–14443A) Tento typ je v současné době nejčastěji pouţíván. •
Moţnosti paměti: 192, 768, nebo 3,584 bytů.
•
Komunikační rychlost 106Kbps
•
Podpora předcházení kolizím.
•
Příklady: NXP Mifare Classic 1K, Mifare Classic 4K, Mifare Classic Mini.
1.8. Kompatibilita typů tagů a zařízení Bohuţel ne všechny typy NFC tagů komunikují se všemi NFC zařízeními. Následující tabulka ukazuje kombinace vyzkoušených zařízení s jednotlivými typy tagů14. Nejčastější problém v současné době spočívá v tom, ţe některá zařízení nepřečtou tagy typu Mifare Classic, coţ je v dnešní době nejpouţívanější typ. Mifare Classic není v současné době standardním typem tagu dle NFC fóra a nedávno velcí výrobci hardwaru jako Broadcom a Samsung přestaly s podporou tohoto typu na svých zařízeních. Díky tomu můţete získat neočekávané výsledky při práci s Mifare Classic, některá zařízení mohou tento typ přečíst, zatímco ostatní zahlásí chybu. Z tohoto důvodu se doporučuje pouţívat některý ze standardních typů tagů dle NFC fóra.
14
Informace dle zdroje: IGOE TOM, Beginning NFC, str. 19
27
Obrázek 5: NFC Devices vs. Types, zdroj: IGOE TOM, Beginning NFC, str. 20
1.9. Zpracování NFC v Androidu Nyní bych se rád ještě trochu věnoval implementaci NFC technologie na platformě Android. Knihovna pro obhospodaření NFC je součástí standardní distribuce Android. Samozřejmě ze zřejmých důvodu není k dispozici API pro emulaci karet, čímţ pádem rozlišujeme pouze dvě různé situace pouţití NFC technologie v Android zařízení. Čtení NDEF zprávy z NFC tagu Výměna NDEF zpráv s jiným zařízením prostřednictvím Android Beam
1.9.1. Použití intent filtru Načtení NDEF zprávy z NFC tagu je podřízeno systému rozhodování zpracování tagu, který analyzuje nalezený tag, zjistí, o jaký typ dat se jedná a následně spustí aplikaci, která tento typ dat zpracovává. Aplikace, která chce nakládat s naskenovaným tagem, můţe vyuţít tzv. intent filtru, který odchytává události v systému, a poţádat o zpracování načteného tagu. Jakmile systém rozhodování vytvoří intent na základě načtení NFC tagu, předává intent aplikaci, která o něj má zájem a má nastaven filtr na jeho odchycení. Pokud má o tento typ intentu zájem více aplikací, pak se objeví nabídka aplikací ke spuštění a uţivatel vybere, kterou aplikaci chce spustit. Systém rozhodování definuje tři typy intentů, které jsou setříděny od nejvyšší po nejniţší prioritu15. ACTION_NDEF_DISCOVERED – Tento intent se pouţívá pro spuštění aplikace v případě rozpoznání typu payloadu v rámci přijaté NDEF zprávy. 15
Seznam intentů převzat ze zdroje: Android Developers: NFC Basics
28
Jedná se o intent nejvyšší priority, coţ znamená, ţe se vytvoří jako první a v případě, ţe existuje aplikace, která tento intent filtruje, pak je spuštěna. ACTION_TECH_DISCOVERED – Pokud ţádná aplikace neodchytává intent typu ACTION_NDEF_DISCOVERED, pak je na řadě tento intent. Tento intent je také přímo spouštěn v případě, ţe NDEF záznam načteného tagu neodpovídá ani MIME ani URI typu nebo tag neobsahuje NDEF data, ale stále je typem známé technologie. ACTION_TAG_DISCOVERED – Tento intent je vytvořen a zpracován v případě,
ţe
ţádná
aplikace
neodchytí
intent
typu
ACTION_NDEF_DISCOVERED ani ACTION_TECH_DISCOVERED. Pokud to lze, je samozřejmě nejvýhodnější pouţít v aplikaci intent filtr na ACTION_NDEF_DISCOVERED. Pak máme zajištěno, ţe naše aplikace bude spuštěna dříve, neţ se systém rozhodování pokusí vytvořit další intenty a navíc víme, ţe byl tag rozpoznán korektně.
29
Obrázek 6: Android Tag Dispatch System, zdroj: Android Developers: NFC Basics
1.9.2. Android Application Record Jak bylo zmíněno jiţ dříve, Android (od verze 4.0) nabízí pouţití pro spuštění aplikace záznam externího typu Android Application Record (AAR). Dle dokumentace se doporučuje pouţití AAR pro větší jistotu, ţe bude aplikace spuštěna na základě načtení příslušného tagu. Záznam typu AAR obsahuje název balíčku aplikace v rámci NDEF záznamu. AAR je moţné přidat do jakékoli NDEF zprávy, jelikoţ Android hledá AAR uvnitř NDEF zpráv. Nemusí se tedy jednat o první záznam ve zprávě. Pokud je AAR nalezeno, spustí se na zařízení poţadovaná aplikace. V případě, ţe aplikace není nainstalována, otevře se Google play pro moţnost jejího staţení. AAR je uţitečné v případě, kdy chcete předejít spuštění jiných aplikací na základě odchycení stejného intentu. AAR je však řízeno pouze na aplikační úrovni, jelikoţ se spouští aplikace dle balíčku, nikoliv na úrovni aktivit jako je tomu v případě odchytávání intentů. Pokud tag obsahuje AAR, je ve výsledku vţdy spuštěna aplikace balíčku definovaného AAR, ačkoliv aplikace nemusí být nainstalována a můţe být k dispozici jiná aplikace, která odchytává jeden z intentů po načtení tagu. Navíc AAR je dostupné aţ od Android verze 4.0 a pokud tvoříme aplikaci, která by měla být i pro starší verze Androidu, nebo pokud chceme, aby si s našimi tagy poradila i zařízení postavená na jiných platformách, pak AAR není nejvhodnější řešení. I přesto, ţe AAR zajišťuje spuštění nebo staţení konkrétní aplikace, je doporučeno pouţívat intent filtr. Díky intent filtru totiţ můţeme ošetřit, která aktivita je spuštěna místo toho, aby byla spuštěna vţdy hlavní aktivita balíčku určeného v rámci AAR. Samozřejmě v ideálním případě by měla 30
aplikace umět zpracovat jak tagy obsahující AAR tak i ostatní, u kterých by zas měla dávat pozor na typ prvního NDEF záznamu a správně tak zpracovat načtený tag.
1.9.3. Android Beam Android Beam je jednoduchý způsob peer-to-peer komunikace mezi dvěma Android zařízeními. Aplikace, která chce přenést data druhému zařízení, musí být spuštěna v popředí. Druhé zařízení nesmí být uzamčeno. Jakmile se obě zařízení dostatečně přiblíţí, na obrazovce zařízení, které zahajuje přenos, se objeví rozhraní "Touch to beam". Následně záleţí na uţivateli, zda se rozhodne data poslat cílovému zařízení či nikoliv.
1.10. Možnosti využití NFC Více se moţnostem vyuţití budu věnovat v následující kapitole, nicméně vězte, ţe je mnoho aplikací s vyuţitím NFC. Funkce emulace tagů nebo karet umoţňuje vyuţití při peněţních operacích jako Google Wallet, nebo platebních operacích v obchodech či dopravních prostředcích. Existuje spoustu mobilních aplikací, díky kterým si můţete do tagu uloţit nastavení vašeho zařízení. Následně pak přiloţením zařízení k tagu jednoduše upravíte patřičná nastavení. Např. v okamţiku, kdy jdete spát, přiloţíte telefon k tagu na nočním stolku a telefon ztlumí zvuk a vypne WiFi. Další moţnosti vyuţití je ve spojení s domácími audio zařízeními. Přiloţením NFC zařízení dojde ke spárování a spustí se audio stream do přehrávače. Stejně tak je moţné pouţít NFC zařízení jako dálkový ovladač k televizoru. Některé společnosti navíc pouţívají NFC technologii pro správu majetku, nebo pro sledování zásilek.
2. Využití NFC v praxi 2.1. NFC v souvislosti s platebními operacemi 2.1.1. Platební karty Nejčastějším nástrojem pro bezkontaktní placení, se kterým se můţe člověk setkat, je platební karta. Pochopitelně ne všechny karty jsou vybavené technologií umoţňující bezkontaktní platbu. To poznáme podle přítomnosti malého loga na vrchní straně. Bezkontaktní karty jsou vydávány více karetními společnostmi, mezi nejznámější produkty patří ExpressPay od American Express®, Discover® Network Zip, MasterCard® PayPass™ a Visa payWave™. Od vydavatele karty se odvíjí i licence pouţitá na softwarové řešení přenosu informací o platbě.
2.1.1.1. PayPass a payWave PayPass a payWave jsou softwarové licence na pouţívání snímačů nebo terminálů. Tyto technologie vyuţívají komunikační kanál vytvořený pomocí NFC technologie. Jakmile se komunikace naváţe, stačí jiţ jen vyměnit informace o platbě mezi kartou a terminálem. 31
Tyto technologie zajišťují několikanásobné zrychlení platby. Nejen, ţe nemusíte kartu fyzicky vloţit do terminálu, ale hlavní výhodou je, ţe není nezbytné zadávat PIN při platbě menších částek. To je umoţněno zabezpečenou komunikací. Limit pro platby bez PINu bývá volitelný, avšak z hlediska bezpečnosti je maximum poměrně nízké. V ČR se v současnosti dá platit bezkontaktně bez zadání PINu do 500 Kč16.
Obrázek 7: Logos of paypass, payWave and Contactless payment, zdroj: MasterCard, Visa a Wikipedia: Universal Contactless Card Symbol
2.1.2. Klíčenky, náramky, hodiny, nálepky Dalšími nástroji pro bezkontaktní platby jsou vlastně jakékoliv předměty s integrovaným čipem. Tyto předměty jsou opatřeny buď logem, nebo alespoň klíčovým slovem CONTACTLESS. Ve většině případů je předmět označen i logem karetní společnosti, kterou byl vydán. Příkladem takovýchto předmětů jsou NFC přívěsky vydávané bankami pro bezkontaktní platby.
2.1.3. Mobilní zařízení s NFC Poměrně velká část práce pojednává o mobilních telefonech, avšak nyní jiţ existují i další zařízení, které disponují technologií NFC. Také je otázka, co vlastně je a co uţ není mobilní telefon. Nicméně nestačí mít pouze zařízení vybavené NFC technologií. Pro provedení bezkontaktní platby je potřeba mít v telefonu speciální aplikaci, SIMkartu s nahranými údaji o platební kartě a telefon garantovaný karetní společností. Existují totiţ dvě moţnosti o uloţení údajů o platební kartě. Buď je to bezpečnostní prvek NFC, který vyuţívá např. Google Wallet. Nebo jsou údaje o kartě uloţeny na speciálním místě na SIMkartě (tak je tomu třeba nyní v případě platební karty od GE). V obou případech je nutné, aby výrobce telefonu umoţnil komunikaci s tímto úloţištěm tak, aby byly platební transakce bezpečné. To ostatně posuzuje vydavatel platebních karet, který pak aktualizuje seznam zařízení, které povaţuje za garantované a na kterých by měly platební operace fungovat. Samozřejmě ani garantovaný model telefonu se speciální SIM a bankovní aplikací není vţdy 100% záruka, ţe se platba pomocí telefonu podaří.
16
Limit dle zdroje: Měšec: Bezpečnost bezkontaktních plateb
32
2.1.4. Současné trendy a možnosti Nyní bych se pokusil zmapovat současné vyuţívání bezkontaktních plateb a moţnosti vyuţití ve světě a v České republice. Jako vţdy zaostáváme s nástupem těchto technologií o několik let za západem, ale aktuálně se bezkontaktní platby uţ i u nás těší velké oblibě.
2.1.4.1. Využití ve světě Zavedení bezkontaktních plateb bylo zamýšleno hlavně tam, kde by to přineslo nějaké výhody. Zaprvé zrychlení platby a zadruhé nenutnost hledat drobné. Není tedy divu, ţe tento způsob placení se uchytil u městské hromadné dopravy. Velká města jako New York, nebo Londýn jiţ bezkontaktní platby v MHD vyuţívají a bezkontaktně můţete platit i v autobusech v Číně17. Dalším vyuţitím bylo zavedení terminálů do stánků s novinami a občerstvením, kde rychlá nenáročná platba je ceněným luxusem. Pochopitelně ani supermarkety nezůstaly pozadu, avšak vzhledem k relativně nízkému limitu se zde nečeká velké vyuţití bezkontaktního způsobu placení.
2.1.4.2. Situace v ČR Bezkontaktní platby byly v České republice zavedeny na podzim v roce 2011. Mezi prvními bankami, které vydávaly bezkontaktní karty, byla Citibank a Česká spořitelna. Do pilotního projektu zavedení plateb pomocí mobilního telefonu s NFC se zapojila Komerční banka. V současné době uţ bezkontaktní karty vydávají všechny větší banky a platby pomocí telefonu zavedla uţ i např. GE Money Bank. Na druhou stranu, zatím jediným operátorem, který vydává SIMkarty pro bezkontaktní placení, je společnost O2. Právě ta ve spolupráci s Komerční bankou a s firmou Samsung zahájila v roce 2012 jako první pilotní projekt pro pouţívání mobilního telefon pro bezkontaktní platby18. Tento pilotní projekt byl koncem roku 2013 ukončen19 a nyní mohou zákazníci vyuţívat pouze spolupráce O2 s GE Money Bank20. Operátor vydá zákazníkovi speciální SIMkartu, na kterou mu banka nahraje jeho platební kartu. Následně pomocí aplikace O2 peněţenka můţe zákazník platit obdobně jako bezkontaktní kartou. Musí mít však SIMkartu vloţenou v podporovaném mobilním telefonu. Podporované telefony musí garantovat karetní společnost (v tomto případě MasterCard®), která do této doby dala zelenou pouze několika modelům právě od Samsungu a Sony. Bylo avizováno, ţe do budoucna se mohou těšit i majitelé telefonů od firem HTC, LG, apod. Zatím však ţádné oficiální zprávy o podpoře telefonů těchto značek nejsou. 17
Vyuţití v zahraničí dle zdroje: Wikipedie: Near Field Communication Pilotní projekt KB dle zdroje: Near Field: Je to tady, mobilní platby v ČR pro všechny! 19 Pilotní projekt ukončen dle zdroje: Mobilmania.cz: O2 končí distribuci NFC SIM karty pro platby s Komerční bankou 20 Projekt O2 a GE dle zdroje: Near Field: NFC platby v ČR naostro: od ledna s O2 a GE Money Bank 18
33
Svůj pilotní projekt plánoval rozjet koncem roku 2013 i další mobilní operátor, a sice T-Mobile21. Ten ve spolupráci s ČSOB potaţmo Era bank chtěl zahájit testování vlastní mobilní aplikace zpravidla pouze vlastními zaměstnanci, přičemţ projekt měl končit v květnu 2014. Nakonec se nasazení trochu zpozdilo a pilotní projekt běţel ve druhé polovině roku 201422. Účastnilo se jej okolo 500 lidí a byl otevřen i pro lidi mimo banku. Zájemci museli na přepáţce v bance vyplnit registrační formulář a následně čekali, aţ jim přijde telefon (Samsung S4 nebo S4 Mini) se speciální SIMkartou. Nakonec se jen přes mobilní data stáhla platební aplikace, údaje o platební kartě a šlo se na nákupy. Oproti pilotnímu projektu Komerční banky a O2 byla jak platební aplikace, tak celý proces registrace velmi kladně hodnocen a nebyly zjištěny ani chyby při samotném procesu placení. Jelikoţ pilotní projekt nakonec končil aţ koncem loňského roku, je pravděpodobně ještě předčasné čekat nějaké závěry ať uţ od operátora nebo banky. Kaţdopádně se ale těšíme a doufáme, ţe i T-Mobile nakonec nasadí svou aplikaci do ostrého provozu a NFC platby budou dostupné širšímu okruhu lidí. Dostupnost bezkontaktních platebních terminálů je nyní u nás jiţ velice dobrá. Disponují jimi jiţ téměř všechny potravinové řetězce, benzinové pumpy a samozřejmě i další obchodníci především v obchodních centrech. Na rozdíl od světa se zatím u nás příliš neuchytil trend bezkontaktního placení v novinových stáncích a stáncích s občerstvením, naopak placení bezkontaktní kartou v supermarketu nebo obchodních centrech je takřka běţnou záleţitostí.
2.2. Další možnosti využití NFC 2.2.1. Identifikační karty Je spoustu firem, kde zaměstnanci ráno přijdou do práce, k turniketu u vchodu přiloţí kartu a jsou vpuštěni dovnitř. Aniţ by to většinu z těchto zaměstnanců napadlo, i oni vyuţívají NFC technologii. Přiloţením karty dojde ke spojení mezi čtecím zařízením a čipem v kartě. Nejen, ţe se díky tomuto přenosu otevře turniket a zaměstnanec můţe jít dál, zároveň se do systému zapisuje čas průchodu zaměstnance. Z nasbíraných dat tedy můţe pohodlně čerpat docházkový systém. Navíc pomocí identifikačních karet lze řídit přístup zaměstnanců do konkrétních částí budovy, zaměstnanci mohou pomocí této karty třeba i platit za oběd v kantýně nebo tisknout na tiskárně právě dokumenty, které předtím poslali do fronty.
21 22
Pilotní projekt dle zdroje: ČSOB: ČSOB, T-Mobile a MasterCard spouští pilotní provoz NFC plateb Poznatky z pilotního projektu dle zdroje: Near Field: Jak se platí mobilem u ČSOB a T-Mobilu?
34
2.2.2. Nastavení profilu doma/auto V dnešní době jiţ většina lidí má doma WiFi a je zvyklá se vţdy po příchodu domů připojit na svůj přístupový bod. Jelikoţ zapnutá WiFi poměrně dost vyčerpává baterii telefonu, je dobré při odchodu z domova opět WiFi vypnout. Co takhle si tuto práci ulehčit? Přijít domů, přiloţit telefon k NFC tagu a rázem být online. Stejně tak při odchodu pouhým přiloţením k tagu se WiFi vypne. Samozřejmě jeden tag můţe ovlivnit celou řadu nastavení a nemusí se jednat jen pouze o WiFi. Člověk si můţe vytvořit kompletní profil, který pouţívá doma, a přiloţením telefonu po příhodu se mu aktivují všechny patřičná nastavení. Obdobně se dá tato technologie vyuţít například i v autě. Stejně tak, jako se doma připojujeme k WiFi, tak se většina řidičů (nebo by aspoň měla) po nástupu do vozidla připojuje k handsfree pomocí Bluetooth. Opět lze pro takovouto akci vyuţít naprogramovaný NFC tag. Po nástupu do vozidla přiloţením telefonu k NFC tagu zapnu Bluetooth a jsem připojen k handsfree. Při výstupu z vozidla opět přiloţením k tagu Bluetooth vypínám, abych šetřil baterii telefonu.
2.2.3. Domácí zařízení audio/TV O synchronizaci NFC zařízení s domácím audio systémem nebo TV jsem se uţ několikrát v práci zmínil. Pro úplnost to ale zde ještě shrnu. NFC můţe mít i takové vyuţití, ţe při poslechu hudby v telefonu můţete své zařízení přiloţit k audio systému a ten bude v přehrávání pokračovat pomocí streamovaného přenosu z telefonu pomocí WiFi. Určitě si kaţdý uţ dovtípí sám, ţe se neváţe NFC spojení typu peer-to-peer a dojde k pouţití handoveru. Pokud má člověk k dispozici televizor s moţností NFC komunikace, pak lze podobným způsobem přehrávat na televizi video nebo prohlíţet fotky. Samozřejmě pokud bychom to vzali z dlouhodobého hlediska, pak se pro podobné účely vyplatí spíše nějaký media server umístěný na domácí WiFi, který bude sdílet soubory místo telefonu.
2.2.4. Ovládání světel Kdo by si nepřál při odchodu z domova jedním dotykem vypnout všechna světla? Je řada lidí, kteří se od domovních dveří vrací zpět do kuchyně, a kontroluje vypnuté spotřebiče. Takovýmto lidem by mohla brzy odpadnout starost. Společnost uţ před nějakou dobou představila světelný systém nazvaný Philips Hue. Jedná se zpravidla o LED ţárovky, které jsou pomocí speciálního řídícího prvku připojené na domácí WiFi. Člověku pak stačí jednoduchá aplikace v telefonu nebo tabletu a můţe určovat, která ţárovka se rozsvítí a kdy.
35 Obrázek 8: Philips hue logo, zdroj: Philips Hue
Zároveň se dá nastavit i barva světla ţárovky. Pokud bychom chtěli tuto technologii jen vyzkoušet a nekupovat rovnou celou sadu včetně řídícího prvku, existuje i varianta, kdy ţárovka komunikuje se zařízením přímo pomocí Bluetooth. Kde se ale v této technologii uplatní NFC? Odpověď je podobná jako u nastavení profilu telefonu. Pouţijeme speciálně naprogramovaný NFC tag, který vyvolá akci v telefonu, která zajistí vypnutí nebo jakékoliv jiné nastavení konkrétních ţárovek. Pomocí webové aplikace a poměrně jednoduchého javascriptu, kterým se naprogramuje chování telefonu po načtení tagu, se vývojářům z NinjaBlocks podařil kýţený efekt23. Pomocí načtení NFC tagů pak lze efektivně rozsvěcet a zhasínat například lampička na nočním stolku.
2.2.5. Správa majetku Komu by se zdálo, ţe evidence majetku pomocí čárových EAN kódů je uţ přeţitek a QR kódy jsou stále jen papírové, můţe i on najít řešení v NFC technologii. Pomocí NFC čipů získám více neţ nějaký identifikátor. V NDEF zprávě mohu mít uloţeno více informací od data zakoupení, výrobce, klidně aţ po aktuálně přiřazeného zaměstnance, který je za majetek zodpovědný. Samozřejmě oproti papírovým identifikátorům jsou NFC tagy mnohem nákladnější záleţitost, nicméně důvody pro jejich vyuţití alespoň u nějakého majetku by se určitě našly. Další variantou je pouţití RFID tagů, jejichţ načtení můţe probíhat na větší vzdálenosti neţ NFC díky moţnosti pouţití jiné vlnové délky. Omezení RFID však spočívá opět v pouze jednoduchém řetězci znaků, který mohou pasivní tagy nést.
2.2.6. Sledování zásilek Obdobně jako ve správě majetku můţe NFC technologie najít uplatnění i při sledování zásilek. NFC tagy lze umístit jak na samotné zboţí, tak třeba i na vozidla, jimiţ je zboţí přepravováno. Samozřejmě, i zde je potřeba se zamyslet nad finanční stránkou věci, a zda by vůbec NFC technologie mohla přinést nějaké efektivní zlepšení.
3. Návrh řešení NFC aplikace V této kapitole nastíním návrh aplikace, která by mohla být v praxi vyuţitelná. Nebude to návrh řešení v pravém slova smyslu, nebudu se opírat o ţádné konkrétní vývojové prostředí, programovací jazyk ani platformu. Smyslem této kapitoly je předloţit detailnější příklad toho, jak můţe být NFC uţitečné v dnešním moderním světě vyuţívajícím mobilní technologie. 23
Informace dle zdroje: Svět Androida: Android hacking: Ovládání světel přes NFC
36
3.1. První myšlenka Aplikaci, kterou zde budu představovat, jsem vymyslel pro efektivnější, příjemnější a transparentní provádění plateb za jízdenky, kupony a pokuty v oblasti přepravy osob prostředky hromadné dopravy. Model aplikace by měl být pouţitelný jak v městské hromadné dopravě, tak i v meziměstské ţelezniční nebo autobusové přepravě osob.
3.2. Architektura NFC aplikace, kterou zde budu představovat, bude mít klasický třívrstvý model architektury. Bude mít jak presentační vrstvu (front-end), tak databázovou vrstvu (back-end). Komunikaci mezi těmito vrstvami bude zprostředkovat middleware, zpravidla aplikační server, na kterém bude moţno provádět administrátorské zásahy. Jak aplikačním serverem, tak databázovou vrstvou se nebudu příliš zabývat, pouţitá technologie není podstatná. Z důvodů, které byly zmíněny v teoretické části práce, samozřejmě nepředpokládám, ţe by navrhovaná aplikace měla zasahovat nebo vyuţívat bezpečnostní prvek NFC. Co se týče módu komunikace, tak většina přenosů bude ve stylu peer-to-peer. Nicméně většina přenosů bude obsahovat hlavně identifikátor cestujícího. V rámci návrhu je počítáno s tím, ţe zařízení bude mít dostupné připojení k internetu a řada informací bude dotaţena právě ze sítě. Pochopitelně pro odlehčení potřeby mobilních dat by se dala aplikace dále modifikovat, aby běţní uţivatelé v roli cestujících potřebovali mobilní připojení jen minimálně.
3.3. Koncept Abych lépe představil, jak aplikace bude fungovat, stručně popíšu její funkce. Prezentační vrstva aplikace bude mít několik modulů. Bude to modul pro cestující, modul pro revizory a modul pro pokladní systémy řidičů autobusů a průvodčích ve vlaku. Vezmeme-li např. případ, kdy cestující je zvyklý pouţívat měsíční časovou jízdenku, pouţití aplikace by bylo následující. Cestující si nejprve musí stáhnout a nainstalovat aplikaci. Následně si v aplikaci vybere dobu platnosti kupónu, počet pásem a kupón zaplatí stále v rámci aplikace, a sice pomocí platební karty přes internet, nebo prostřednictvím poskytovatelů třetích stran, jako je Google Wallet, PayPal, apod. Cestující následně uvidí zakoupený kupón ve svém zařízení. Následně při kontrole revizorem cestující vybudí na svém zařízení NFC signál, který sejme aplikace na straně zařízení revizora. Tomu se zobrazí detaily o zakoupeném aktuálním platném kupónu, čímţ se prověří oprávnění cestujícího vyuţívat dopravní prostředek. V případě, ţe cestující pouţije příměstskou autobusovou linku, kde je potřeba se prokázat platným jízdním dokladem u řidiče. Cestující opět vybudí NFC signál na svém zařízení a pokladním systém u řidiče potvrdí platnost dokladu. 37
3.4. Modul pro cestující 3.4.1. Úvodní popis Modul pro cestující bude volně staţitelná aplikace z obchodu aplikací, nebo ze stránek dopravce. Modul bude zahrnovat veškeré funkce pro potřeby cestujícího. Počítá se s moţností dlouhodobých časových kupónů, krátkodobých jízdenek a tzv. elektronické peněţenky.
3.4.2. Dlouhodobé kupóny Dlouhodobé časové kupóny jsem nastínil jiţ v předchozí kapitole. S touto variantou se počítá především pro vyuţití v městské hromadné dopravě. Cestující zvolí pořízení dlouhodobého časového kupónu. Následně si zvolí dobu platnosti a vybraná pásma, ve kterých bude kupón platit. Povolené kombinace předchozích údajů budou záviset na aktuálním tarifu dopravní společnosti. Cestující ještě bude muset vybrat způsob platby a následně kupón zaplatí. Při kontrole revizorem bude mít cestující moţnost prokázat se jízdním dokladem pomocí NFC technologie.
3.4.3. Krátkodobé jízdenky Pro krátkodobé jízdenky jsme uţ zvyklí, ţe se vyuţívá systému SMS. Tato varianta zůstává v podstatě nezměněná. Výhodou navrhované aplikace je však to, ţe cestující má jiţ předvolené šablony pro SMS jízdné. Cestující zvolí pořízení krátkodobé jízdenky a vybere typ (cenu) jízdenky opět dle tarifu. Po potvrzení výběru jízdenky se cestujícímu otevře klientská aplikace, kterou pouţívá na SMS zprávy jiţ s předvyplněným číslem i textem zprávy. Cestující tak pouze jedním kliknutím odešle SMS zprávu a pořízení jízdenky má vyřízené.
3.4.4. Elektronická peněženka Vyuţití elektronické peněţenky je nejvhodnější pro dálkovou autobusovou, nebo ţelezniční přepravu osob. Princip elektronické peněţenky vychází z faktu, ţe cestující dopředu většinou neví (pokud necestuje pravidelně), kolik za jízdné zaplatí. Z tohoto důvodu odpadá moţnost placení jízdného aţ při nástupu do dopravního prostředku, a sice jak pomocí platební karty, tak pomocí SMS. Cestující by v takovém případě nepřiměřeně zdrţoval celou frontu, pokud by u řidiče musel vyplňovat údaje o platbě přes internet, nebo by čekal, neţ mu přijde potvrzovací SMS. Řešením je tedy elektronická peněţenka, kdy se částka za jízdné bude odečítat z virtuálního konta cestujícího. Cestující si v předstihu v aplikaci zvolí vklad do elektronické peněţenky. Nákup těchto virtuálních peněz bude probíhat standardně platbou přes internet. Následně se mu v elektronické peněţence objeví připsaná částka. Pokud pak bude chtít vyuţít dopravní prostředek, řidič autobusu nebo průvodčí ve svém pokladním systému zadá poţadavek na 38
strţení hodnoty jízdenky z virtuálního konta cestujícího a pomocí NFC technologie se provede zaplacení jízdního dokladu. Pokud na virtuálním kontu nebude mít cestující dostatek prostředků, bude muset cestující zaplatit v hotovosti. Vzhledem k faktu, ţe ve vlacích není průvodčí primárním prodejcem jízdenek, ale cestující by si měl zakoupit jízdenku jiţ před nástupem v pokladně (je-li to moţné), nabízí se rozšíření aplikace o předprodej jízdenek také rovnou v aplikaci. Nutno dodat, ţe pouţití elektronické peněţenky vţdy vyţaduje úzkou spolupráci s dopravcem pro zahrnutí jeho tarifů a moţností koupi jízdenek, pro implementaci modulu pokladních systémů, pro zavedení plateb za jízdné do účetnictví, atd.
3.4.5. Historie Další výhodou aplikace bude zobrazení historie transakcí. Historii nebude vedena u krátkodobých jízdenek, jelikoţ aplikace nedostává zpětnou vazbu, zda byla SMS jízdenka skutečně pořízena. Určitě ale bude historie vedena u elektronické peněţenky. Cestující uvidí svoje platby, tj. částky připisované na konto cestujícího. Dále však také bude mít moţnost vidět historii strţených částek z konta. Cestující si bude moci zobrazit za dané časové období jednotlivé jízdné. U konkrétních jízdenek uvidí částku, čas zakoupení (strţení z konta) a dále také počáteční místo a cíl cesty, případně nějaký popis jednalo-li se např. o poplatek za přepravu kola nebo kočárku. Zároveň bude mít cestující k dispozici i náhled na své pořízené dlouhodobé kupóny. Tato funkce bude uţitečná jak při prokazování platnosti aktuálního kupónu, tak i z hlediska samotných informací. Cestující tak okamţitě uvidí, kdy mu končí platnost aktuálního kupónu a můţe si tak dopředu naplánovat pořízení navazujícího kupónu.
3.4.6. Uživatelské nastavení Moţnosti uţivatelského nastavení budou záviset na konkrétním pouţití a moţnostech aplikace.
Uţivatelské
nastavení
můţe
obsahovat
výchozí
nastavení
kupovaných
dlouhodobých jízdenek, přednastavenou částku k připsání do elektronické peněţenky. Z bezpečnostních důvodů by zde neměly být uloţeny údaje o platebních kartách. Mohou zde být nějaké osobní údaje, ale to také záleţí na nastavení zabezpečení celé aplikace. V kaţdém případě by v této sekci mohla být různá nastavení týkající se vzhledu uţivatelského prostředí.
39
3.5. Modul pro revizory 3.5.1. Úvodní popis Modul pro revizory nebude veřejný. Bude instalován pouze revizorům dopravního podniku do jejich zařízení. Tento modul bude slouţit pouze pro kontrolu platnosti jízdních dokladů cestujících.
3.5.2. Dlouhodobé kupóny Revizor bude moci zkontrolovat platnost dlouhodobého kupónu cestujícího. Komunikace mezi zařízeními revizora a cestujícího bude probíhat pomocí NFC technologie. Po interakci se revizorovi zobrazí údaje o kupónu a v případě prokázání platnosti (aktuální datum a pásmo) bude cestující propuštěn z kontroly. Pro snazší rozpoznání kupónu si bude moci revizor nastavit aktuální pásmo, ve kterém zrovna provádí kontrolu. V případě, ţe interakce bude neúspěšná, nebo bude mít např. cestující vybité zařízení, bude moţné dohledat cestujícího v databázi. Revizor bude mít moţnost pomocí formuláře najít kontrolovaného cestujícího např. podle občanského průkazu. V databázi revizor zjistí, zda má cestující aktuálně platný kupón. Tato varianta je ovšem časově náročnější a vyţaduje mobilní připojení revizora, aby mohl čerpat data z databáze.
3.5.3. Krátkodobé jízdenky Ověření krátkodobých jízdenek bude probíhat obdobně, jak probíhá doposud. Cestující předloţí kód z příchozí SMS jízdenky, revizor zadá daný kód do aplikace a revizorovi přijde odpověď, zda je SMS jízdenka platná. Při tomto ověření nebude pouţita NFC technologie. Pokud bychom toho chtěli docílit, museli bychom přinutit cestující, aby přijaté kódy nějakým způsobem zapisovali do aplikace. To patrně nepřichází v úvahu.
3.5.4. Elektronická peněženka Revizoři rozhodně nebudou kontrolovat stav konta v elektronických peněţenkách cestujících. Revizor by ale měl být schopen ověřit, ţe jízdenka byla při vstupu do dopravního vozidla skutečně zakoupena a částka strţena z konta cestujícího. Revizor na svém zařízení zadá, mezi jakými zastávkami se nachází, a čas jízdy. Samozřejmě v případě zpoţdění dopravního prostředku nemusí hrát čas roli. Po interakci se zařízením cestujícího se revizorovi objeví relevantní jízdenky (např. pořízené v den kontroly platné pro daný úsek jízdy).
3.5.5. Historie Historie revizora není aţ tolik podstatná z hlediska jeho kontrolování, jako spíše z hlediska statistik a kontroly zabezpečení. Statistiky se dají zkoumat z různých úhlů pohledu – kolik SMS jízdenek denně revizor zkontroluje, kolik zkontroluje dlouhodobých kupónů, jaké je procento úspěšnosti kontrol, atd. Co se týče zabezpečení, je dobré kontrolovat platnost 40
jízdenek z obou stran. Mám na mysli, ţe v dnešní době se dá nasimulovat ledacos a dříve nebo později by někdo přišel se způsobem, jak vyslat NFC signál s platným jízdním dokladem, přičemţ ale nedošlo k jeho řádnému pořízení. Ověření platnosti by se tedy mělo zkoumat i z hlediska databáze plateb (za dlouhodobé kupóny) a databáze pokladních systémů. Toto ověření se ale bude vykonávat asynchronně nezávisle na kontrolách cestujících. Systém toto ověřování bude provádět automaticky na pozadí a pomocí dat z historie revizorů se získá vypovídající hodnota o tom, kolik kontrol bylo zfalšovaných. V případě většího procenta zjištěných falešných jízdních dokladů by se přistoupilo ke zvýšení bezpečnosti aplikace.
3.5.6. Uživatelské nastavení Zde opět velmi záleţí na konkrétním nasazení aplikace. Při kontrolách na dálkových spojích by zde bylo moţno vybrat trasu, aby revizor při dané kontrole vybíral jiţ pouze zastávky na trase, kterou zrovna projíţdí. Stejně tak při kontrolách v městské hromadné dopravě by si zde revizor vybral město, ve kterém provádí kontrolu a při kontrole by měl jiţ na výběr pouze z pásem daného města.
3.6. Modul pro pokladní systémy 3.6.1. Úvod Tento modul bude instalován do pokladních systémů řidičů autobusů a průvodčích ve vlaku. Bude přímo zabudován do zařízení a integrován s výdejem jízdních dokladů. Modul bude evidovat prodané jízdné konkrétním cestujícím vyuţívajících aplikaci.
3.6.2. Dlouhodobé a krátkodobé jízdenky Vydávání dlouhodobých a krátkodobých jízdenek u řidičů dálkových autobusů a ve vlacích je irelevantní nejedná-li se o příměstskou dopravu. V návrhu aplikace s tím tedy prozatím nebudeme počítat.
3.6.3. Elektronická peněženka Modul pro pokladní systémy by měl být primárním vydavatelem jízdenek zakoupených pomocí elektronické peněţenky. Jde o protipól klientské aplikace, kterou má cestující ve svém zařízení a kde eviduje stav svého účtu elektronické peněţenky. V okamţiku nástupu do vozidla, případně při kontrole průvodčím ve vlaku zadá osoba obsluhující pokladní systém počáteční a cílovou stanici do systému pro vygenerování jízdenky. Cestující následně přiloţí své zařízení k pokladnímu systému, ten načte stav konta elektronické peněţenky. V případě, ţe je na kontě dostatek prostředků na zakoupení jízdenky, je cestujícímu strţena z konta odpovídající hodnota jízdného a do historie zapsána zakoupená jízdenka. Pokud cestující nemá na kontě dostatečný obnos, musí za jízdenku zaplatit v hotovosti. 41
3.6.4. Historie Historie pokladních systémů je nesmírně důleţitá. V kaţdém případě nemůţeme opomenout integraci s generováním jízdenek za hotovost, díky čemuţ musíme v systému oddělit historii elektronických jízdenek od zbytku. Pokud budeme brát v úvahu pouze jízdenky zakoupené pomocí aplikace, historie pokladních systémů by měla dokazovat odečty částek na klientských účtech elektronické peněţenky. Pokladní systémy by měly pravidelně odesílat historii na centrální server, kde bude probíhat párování plateb evidovaných v klientských zařízeních s platbami evidovanými v pokladních systémech. V neposlední řadě má historie význam i z hlediska statistiky. Můţe ukázat, jaké procento cestujících si pořizuje jízdenky pomocí elektronické peněţenky, jaké jsou nejčastější trasy cestujících a obecně veškeré moţné indexy dostupné z evidence konkrétních jízdenek. Jelikoţ jsem u minulého modulu zmínil zabezpečení, vrátím se k němu i zde. Asi není důvod simulovat kupování falešných jízdenek a strhávat si tak částky z konta elektronické peněţenky. Problém by nastal v případě, ţe by se někomu povedl opak, a sice generovat jízdenky se zápornou hodnotou a tím tak navyšovat klientské účty. Pokud by se tak stalo, dříve nebo později by se to odrazilo v historii na serveru a muselo by se přistoupit ke zvýšení zabezpečení aplikace.
3.6.5. Uživatelské nastavení V pokladních systémech se nedá s uţivatelským rozhraním příliš manipulovat. Navíc vezmeme-li v potaz, ţe naši aplikaci budeme integrovat se stávajícím systémem, prioritou bude funkčnost před uţivatelskou přívětivostí. Vše by záleţelo na primárním softwaru v zařízení a moţnosti integrace.
3.7. Možná rozšíření aplikace 3.7.1. Příměstská doprava Příměstská doprava je trochu specifický okruh přepravy. Jde v podstatě o něco mezi městskou a dálkovou dopravou. Je poměrně časté, ţe cestující v příměstské dopravě vyuţívají kombinaci dlouhodobých kuponů s jednorázovými jízdenkami pro pokrytí platby za cestu mimo město. Z toho vyplývá nutná kombinace moţností aplikace jak pro cestující, tak pro dopravce. V případě, ţe cestující jede mimo město a má pořízen dlouhodobý kupon, měl by zároveň mít i nabité konto elektronické peněţenky, ze kterého se mu strhne platba za cestu mimo město v okamţiku nástupu do příměstského autobusu. V případě vlaku by si měl cestující dopředu zajistit jízdenku na úsek cesty, který mu nepokrývá dlouhodobý kupon. Zároveň by aplikace měla umoţnit cestujícímu koupit si k dlouhodobému kuponu i 42
krátkodobé jízdenky pro cestu ve vnějších pásmech v případě, ţe příměstská doprava spadá do integrované dopravy se zavedenými tarifními zónami či pásmy.
3.7.2. Pokuty Jelikoţ je celý systém vysoce transparentní, lze poměrně snadno zjistit, zda cestující má nebo nemá platný doklad. Pokud se prokáţe, ţe cestující jede tzv. "na černo", je mu udělena pokuta. Pokud má cestující u sebe smartphone s nahranou aplikací, můţe si revizor přiloţením svého zařízení načíst údaje o cestujícím a zapsat pokutu do systému. V případě, ţe cestující nedisponuje zařízením s aplikací, revizor si musí opsat údaje z občanského průkazu. Jakmile je cestujícímu udělena pokuta, uvidí ji v seznamu pokut ve své klientské aplikaci. Pokuty bude moci, lze ji samozřejmě rovnou bezhotovostně zaplatit, a sice buď prostřednictvím kreditní karty, nebo mu bude výše pokuty strţena z konta elektronické peněţenky. V opačném případě zůstane k dispozici varianta platby v hotovosti na přepáţce dopravce. Systém udělování pokut musí pamatovat i na situace, kdy cestující má zakoupenu platnou jízdenku, ale nemá smartphone s aplikací u sebe. V takovém případě by měla aplikace revizorovi zahlásit, ţe daný cestující (dle údajů z občanského průkazu) má jízdenku zakoupenou a revizor pak udělí pokutu pouze ve sníţené sazbě, pokud vůbec. To samozřejmě závisí na tarifních podmínkách dopravce.
3.7.3. Přenosné jízdenky Další moţností rozšíření aplikace jsou přenosné jízdenky. Takovýto způsob přepravy je jiţ v některých městech moţný. Jedná se o dlouhodobé kupony zpravidla na městskou hromadnou dopravu, které nemají ţádného cestujícího přiřazeného na stálo. Kupon pak můţe vyuţívat více lidí (ale ne více zároveň) samozřejmě v různém časovém období. Implementace takových kuponů do aplikace by neměla být sloţitá. Kupon by si pořídil jeden z cestujících, který jej chce vyuţívat (ačkoliv ani on jej nemusí vyuţít v podstatě vůbec), a ten by se mu objevil mezi jeho platnými kupony. V případě, ţe by chtěl kupon poskytnout jinému cestujícímu, mohl by toto na kuponu nastavit. A sice zadal by datum začátku, datum konce a nějaké id cestujícího, kterému kupon "propůjčuje". Je uţ pak jen otázkou, zda následné přiřazení kuponu by mohl provádět stále pouze původní pořizovatel, nebo aktuální "majitel". Také by se dalo zavést omezení na počet předání v rámci časové jednotky, aby se kupon nepředával zrovna a pouze tehdy, potká-li cestující revizora, nebo dokonce aby si skupina cestujících nepředala jeden kupon v rámci jedné kontroly.
43
3.7.4. Jízda více lidí na jednu jízdenku V dopravních prostředcích dálkové dopravy je poměrně běţné, ţe více cestujících ve skupině jede na jednu jízdenku (pro patřičný počet osob). Taková varianta by mohla být rovněţ dostupná i v aplikaci. Cestující, který by měl moţnost pořídit jízdenku pro více osob, by tak učinil a při kontrole např. průvodčím ve vlaku by pak kontrolor zjistil, ţe jízdenka je pro více osob, které jedou dohromady. Často se ale stává, ţe je vlak třeba plný a skupina nesedí zrovna pohromadě, nebo by část cestujících chtělo jet část trasy pozdějším vlakem a jízdenka uţ byla koupená. V takovém případě by měl cestující, který jízdenku pořídil, moţnost jízdenku rozdělit. Podobně jako v případě přenosných kuponů by cestující zadal počet osob, které pojedou samostatně a přeposlal by jízdenku jinému cestujícímu dle zadaného identifikátoru. Taková moţnost by se dala vyuţít i v případě, kdy dopravce vyţaduje, aby kaţdá jízdenka, nebo místenka byla přiřazena konkrétní osobě, lépe řečeno cestujícímu, který je schopný prokázat se určitým průkazem. Aby si pak nemusel kaţdý cestující pořizovat jízdenku zvlášť, můţe vedoucí skupiny pořídit jízdenku najednou (samozřejmě s případnou skupinovou slevou) a následně ji pak rozdistribuovat členům skupiny pomocí aplikace.
3.7.5. Prodejní automaty Je otázka, zda by se vůbec do architektury a fungování aplikace měly započítat prodejní automaty. Jejich význam podstatně upadá s přihlédnutím k faktu, ţe cestující si téměř vše můţe zařídit v aplikaci sám. Lze ale přijít na situace, kdy by se prodejní automaty mohli hodit. Přece jenom i v této moderní době, zatím stále bezhotovostní platby nejsou dominantním způsobem placení. Navíc i v České republice je nemalé procento lidí, kteří nemají bankovní účet, natoţ platební kartu, se kterou se dá platit na internetu. Pokud vezmeme předpoklad, ţe před pořízením jednorázové jízdenky je potřeba mít dostatečný kredit na kontě elektronické peněţenky, je potřeba toto konto udrţovat stále v kondici. Pokud by však cestující před jízdou neměl na kontě dostatečný obnos a nemá po ruce platební kartu, musel by za jízdenku zaplatit klasickým způsobem u přepáţky. Tyto situace by mohly řešit právě prodejní automaty. Přiloţením zařízení ke čtecí ploše na automatu by došlo k identifikaci cestujícího. Ten by si pak na automatu zvolil dobití konta elektronické peněţenky a po vloţení hotovosti do automatu by se mu vloţená částka připsala na konto. Rovněţ by automaty mohly poskytovat prodej jiţ předvolených jízdenek (např. jiţ vybrané zastávky na trati příslušného nádraţí, nebo nejbliţší odjezdy vlaků), aby měl cestující 44
jednodušší přístup ke koupi jízdenky. Takovéto zjednodušení by však nebylo aţ tak přínosné, aby to vyrovnalo ekonomickou stránku automatu.
3.7.6. Zabezpečení aplikace Jelikoţ ceny jízdenek a pokut dosahují někdy nemalých částek a pokud bereme v potaz, ţe třeba cena jízdného za rok se můţe pohybovat v řádu tisíců korun, najdou se jistě podvodníci, kteří by chtěli za jízdné ušetřit a zneuţít aplikaci tak, aby nemuseli platit vůbec, nebo aby se třeba více lidí dělilo o stejnou jízdenku či účet cestujícího. Proti takovýmto plánům musí být aplikace zabezpečena. Kaţdý cestující, který by chtěl vyuţívat aplikaci, by se musel osobně dostavit a registrovat si aplikaci na přepáţce dopravce nebo v místě, kde by daná sluţba byla poskytována. Kromě standardních záleţitostí, jako je poskytnutí osobních údajů, by registrace spočívala také v poskytnutí IMEI24 a případně i sériového čísla zařízení, na které bude cestující aplikaci vyuţívat. IMEI zařízení bude následně uloţeno u uţivatele v databázi aplikačních dat na serveru a jakmile cestující spustí aplikaci na svém zařízení, bude automaticky přihlášen. Právě spárováním uţivatelů aplikace s IMEI jejich zařízení zabrání více lidem pouţívat stejný účet. Je pravda, ţe jsou způsoby, jak IMEI zařízení změnit, ale taková věc je ve spoustě zemích nelegální. Nicméně pokud by vzniklo podezření, ţe k takovýmto situacím dochází, dalo by se i tak jistými metodami odhalit pachatele. Mohli bychom porovnávat místa zakoupení jednotlivých jízdenek, nebo kontrolu revizorem v blízkých časech – pokud by například byla zakoupena jízdenka při nástupu do autobusu z Prahy do Brna a o půlhodiny později by někdo pouţil aplikaci se stejným IMEI opět v Praze, indikovalo by to stejné IMEI na více zařízeních. Určitě by se daly vymyslet i algoritmy na zjištění, zda cesty pořizovaných jízdenek dávají smysl a zda jsou reálné absolvovat jedním cestujícím.
4. Předpokládané přínosy navrhovaného řešení 4.1. Odpadá nutnost karet a průkazů jednotlivých dopravců Cestující potřebuje pro přepravu dopravním prostředkem pouze svůj telefon. Není nutné pořizovat si nějaké karty, mít je stále při sobě, hlídat jejich platnost, atd. V mobilním telefonu má cestující vše, co potřebuje.
24
IMEI (International Mobile Equipment Identity) je unikátní mezinárodní identifikátor zařízení
45
4.2. Přihlašování do aplikace nevyžaduje zadání hesla Cestující si nemusí pamatovat ţádné heslo, ani identifikační číslo svého účtu. Aplikace se přihlásí automaticky na základě IMEI zařízení. Aplikace je tak zabezpečená a zároveň je to příjemnější pro uţivatele.
4.3. Veškeré transakce online a okamžitě Pokud bychom vzali ke srovnání praţský dopravní podnik a moţnost nákupu dlouhodobých kuponů přes internet, tak tady narazíme na drobná úskalí. I v případě, ţe za kupon zaplatíte platební kartou (nebo okamţitým online převodem) a přijde vám potvrzení o platbě, dostanete zprávu, ţe kupon bude doručen do validátoru v několika desítkách minut. Z toho plyne, ţe pokud se dostanete k validátoru (např. ve stanici metra) a nejsou zde pokladny, můţete si kupon koupit online, ale budete čekat zhruba půl hodiny, neţ si jej budete moci dobít na kartu. Ještě více ideální je situace okolo 23:30 a vy potřebujete odjet ještě daný den. Nejen, ţe kupon nebude ve validátoru do půlnoci, ale nebude dostupný ani pak, jelikoţ kupon si musíte vyzvednout nejpozději v první den platnosti. Proto aplikace poskytuje veškeré transakce online a všechny zakoupené jízdenky se vám okamţitě v aplikaci objeví. Navíc pro nákup jízdenek pomocí elektronické peněţenky není nutné ani aktuální připojení k internetu. Zakoupení jízdenky můţe proběhnout i offline, pokud má cestující dostatečný kredit na kontě. Strţení částky z konta se můţe do centrálního systému přenést později, jakmile se k internetu opět připojí.
4.4. Detailní přehled všech provedených transakcí Cestující má okamţitý přehled o všech uskutečněných nákupech, platnostech svých zakoupených kuponů a jízdenek. Nemusí se logovat nikam na internet a hledat historii pořízených kuponů, ani nemusí vyhledat validátor, aby zjistil, kdy mu končí aktuálně platný kupon. Nabízí se samozřejmě i moţnost zasílání upomínky pro nákup dalšího kuponu v případě, ţe se blíţí konec platnosti současného kuponu a cestující stále nemá pořízen další kupon.
4.5. Možnost prokázání platného dokladu i bez zařízení Cestující má moţnost dokázat revizorovi, ţe má zakoupen platný doklad i v případě, ţe nemá mobilní telefon u sebe, nebo má jeho mobilní telefon vybitou baterii. Revizor můţe jednoduše online zjistit v centrální databázi, zda cestující má platný doklad, či nikoliv.
46
Závěr Cílem této práce bylo podrobně prostudovat fungování NFC technologie a vytvořit si tak základ pro návrh vlastní aplikace vyuţívající NFC. V první kapitole jsem detailně popsal všechny tři způsoby NFC komunikace a rozebral architekturu, kde jsem se dotknul i jednotlivých standardů, na kterých je NFC zaloţeno. Zároveň jsem pečlivě prozkoumal strukturu předávaných zpráv a zmapoval moţnosti navázání spojení i pomocí alternativních technologií. V druhé části jsem se věnoval aktuálnímu vyuţití NFC převáţně v oblasti bezkontaktních plateb a aktuální situaci v ČR. Dále jsem předloţil další moţná vyuţití, kde nasazení NFC technologie můţe být efektivní. V rámci návrhu aplikace jsem popsal nové vyuţití NFC technologie, které poskytuje jednodušší a příjemnější moţnost placení za jízdné v prostředcích hromadné dopravy. Na závěr jsem popsal očekávaná vylepšení při pouţití této aplikace. Navrhovaný systém je natolik robustní, ţe by neměl mít problém zahrnout libovolné mnoţství dopravců, avšak vývoj a nasazení takového jednotného systému by byl velice nákladný a vyţadoval by úzkou spolupráci více společností dohromady. Z tohoto důvodu je daný systém v podstatě nerealizovatelný, coţ je podobné jako u problematiky emulace karet pomocí NFC technologie. I zde by se dalo najít mnohem větší vyuţití, ale z politického hlediska se dá očekávat, ţe tato výsada zůstane pouze v rukou velkých společností. Tímto jsem se dostal zpět k NFC technologii, o které jsem se toho spoustu dozvěděl v rámci tvorby této práce. Věřím, ţe tato technologie má do budoucna veliký potenciál a budeme se s jejími aplikacemi setkávat čím dál častěji.
47
Použité zdroje [1.] IGOE, Tom, Don Coleman a Brian Jepson. Beginning NFC: Near Field Communication with Arduino, Android, and PhoneGap. Sebastopol: O'Reilly Media, Inc. © 2014. ISBN 978-1-449-37206-4. [2.] Technical Specifications. NFC Forum [online] [cit. 2015-06-26]. Dostupné z: http://nfc-forum.org/our-work/specifications-and-applicationdocuments/specifications/nfc-forum-technical-specifications/ [3.] KORB Kryštof. Je to tady, mobilní platby v ČR pro všechny! Near Field [online] 23. 08. 2012 [cit. 2015-06-28]. Dostupné z: http://nearfield.cz/clanky/je-to-tady-mobilni-nfc-platby-pro-vsechny-56 [4.] PULTZNER Martin. NFC platby v ČR naostro: od ledna s O2 a GE Money Bank. Near Field [online] 05. 12. 2012 [cit. 2015-06-28]. Dostupné z: http://nearfield.cz/clanky/nfc-platby-v-cr-naostro-od-ledna-s-o2-a-ge-moneybank-87 [5.] KORB Kryštof. Jak se platí mobilem u ČSOB a T-Mobilu? Near Field [online] 14. 07. 2014 [cit. 2015-06-28]. Dostupné z: http://nearfield.cz/clanky/jak-seplati-mobilem-u-csob-a-t-mobilu-145 [6.] ČSOB, T-Mobile a MasterCard spouští pilotní provoz NFC plateb. ČSOB [online] 22. 10. 2013 [cit. 2015-06-28]. Dostupné z: http://www.csob.cz/cz/Csob/Servis-pro-media/Tiskovezpravy/Stranky/TZ131022.aspx [7.] LÁSKA Jan. O2 končí distribuci NFC SIM karty pro platby s Komerční bankou. Mobilmania.cz [online] 19. 12. 2013 [cit. 2015-06-28]. Dostupné z: http://www.mobilmania.cz/bleskovky/o2-konci-distribuci-nfc-sim-karty-proplatby-s-komercni-bankou/sc-4-a-1325669/default.aspx [8.] NFC Basics. Android Developers [online] [cit. 2015-06-29]. Dostupné z: https://developer.android.com/guide/topics/connectivity/nfc/nfc.html#tech-disc [9.] OLEJNÍK Jan. Android hacking: Ovládání světel přes NFC. Svět Androida [online] 01. 03. 2013 [cit. 2015-06-29]. Dostupné z: http://www.svetandroida.cz/android-hacking-ovladani-svetel-pres-nfc-201303 [10.] Bezpečnost bezkontaktních plateb. Měšec.cz [online] © 1998 – 2015 [cit. 2015-06-26]. Dostupné z: http://www.mesec.cz/bankovni-ucty/platebnikarty/bezkontaktni-platby/pruvodce/bezpecnost-bezkontaktnich-plateb/
48
[11.] Near Field Communication. In: Wikipedia: the free encyclopedia [online]. St. Petersburg (Florida): Wikipedia Foundation, 29. 04. 2009, last modified on 10. 04. 2015 [cit. 2015-06-29]. Dostupné z: https://cs.wikipedia.org/wiki/Near_Field_Communication
Seznam obrázků Obrázek 1: Struktura NDEF, zdroj: IGOE TOM, Beginning NFC, str. 50 .................. 13 Obrázek 2: NFC stack, zdroj: IGOE TOM, Beginning NFC, str. 16 ........................... 20 Obrázek 3: Android Beam UI, zdroj: IGOE TOM, Beginning NFC, str. 175.............. 22 Obrázek 4: AndroidManifest.xml edit, zdroj: IGOE TOM, Beginning NFC, str. 175 . 23 Obrázek 5: NFC Devices vs. Types, zdroj: IGOE TOM, Beginning NFC, str. 20 ...... 28 Obrázek 6: Android Tag Dispatch System, zdroj: Android Developers: NFC Basics . 30 Obrázek 7: Logos of paypass, payWave and Contactless payment, zdroj:MasterCard, Visa a Wikipedia:Universal Contactless Card Symbol ......................................... 32 Obrázek 8: Philips hue logo, zdroj: Philips Hue........................................................... 35
Seznam zkratek RFID
Radio Frequency Identification
NFC
Near Field Communication
NDEF
NFC Data Exchange Format
TNF
Type Name Format
URI
Uniform Resource Identifier
URN
Uniform Resource Name
URL
Uniform Resource Locator
RFC
Request for Comments
RTD
Record Type Definition
UART
universal asynchronous receive-transmit
SPI
serial peripheral interface
I2C
interintegrated circuit communication
USB
universal serial bus
LLCP
logical link control protocol
SNEP
simple NDEF exchange protocol
49
