NFC technologie a její využití

Transkript

1 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: Ing. Bc. Jiří Rezler Praha červen 2015

2 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

3 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 (Radio Frequency Identification), NDEF (NFC Data Exchange Format), Android

4 Obsah Úvod NFC technologie Představení NFC Porovnání NFC a RFID RFID NFC RFID podrobněji RFID standardy NFC podrobněji NFC Data Exchange Format (NDEF) Typologie NDEF záznamů Jednoduchý textový záznam (Simple text record) Uniform Resource Identifier (URI) Chytrý obrázek (Smart poster) Podpis (Signature) NDEF podrobněji Struktura NDEF Type Name Format (TNF) Typ payloadu URI jako součást NDEF zprávy Payload ID Payload Struktura záznamu Hlavička záznamu Velikost NDEF zprávy

5 Omezení velikosti Velikost z hlediska výměny dat Zřetězení záznamů Architektura NFC Peer-to-peer výměna Handover (předání) Static Handover (statické předání) Card Emulation (emulace karet) Typy NFC tagů Typ Typ Typ Typ Mifare Classic tag (ISO 14443A) Kompatibilita typů tagů a zařízení Zpracování NFC v Androidu Pouţití intent filtru Android Application Record Android Beam Moţnosti vyuţití NFC Vyuţití NFC v praxi NFC v souvislosti s platebními operacemi Platební karty PayPass a paywave Klíčenky, náramky, hodiny, nálepky Mobilní zařízení s NFC Současné trendy a moţnosti

6 Vyuţití ve světě Situace v ČR Další moţnosti vyuţití NFC Identifikační karty Nastavení profilu doma/auto Domácí zařízení audio/tv Ovládání světel Správa majetku Sledování zásilek Návrh řešení NFC aplikace První myšlenka Architektura Koncept Modul pro cestující Úvodní popis Dlouhodobé kupóny Krátkodobé jízdenky Elektronická peněţenka Historie Uţivatelské nastavení Modul pro revizory Úvodní popis Dlouhodobé kupóny Krátkodobé jízdenky Elektronická peněţenka Historie Uţivatelské nastavení

7 3.6. Modul pro pokladní systémy Úvod Dlouhodobé a krátkodobé jízdenky Elektronická peněţenka Historie Uţivatelské nastavení Moţná rozšíření aplikace Příměstská doprava Pokuty Přenosné jízdenky Jízda více lidí na jednu jízdenku Prodejní automaty Zabezpečení aplikace Předpokládané přínosy navrhovaného řešení Odpadá nutnost karet a průkazů jednotlivých dopravců Přihlašování do aplikace nevyţaduje zadání hesla Veškeré transakce online a okamţitě Detailní přehled všech provedených transakcí Moţnost prokázání platného dokladu i bez zařízení Závěr Pouţité zdroje Seznam obrázků Seznam zkratek

8 Ú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

9 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 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 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í 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

10 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 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

11 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 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 byl vyvinut pro pouţití s platebními systémy a smart kartami. Vyuţívá frekvence 13.56MHz 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 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

12 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 Typologie NDEF záznamů 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 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č 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 ový klient. Do aplikace se pak promítne obsah NDEF záznamu, tak aby smart poster splnil svůj účel 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 NDEF podrobněji 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

13 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 (payload 2 ) 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

14 Type Name Format (TNF) NDEF záznam počíná názvem typu formátu (TNF 3 ). 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 Absolute URI URI definováno v RFC 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í 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 (RTD 4 ). Navíc je v RTD i specifikace Well-Known typů. Ostatní typy jsou specifikovány v MIME RFC respektive URI RFC. 3 Jednotlivé typy TNF brány ze zdroje: IGOE TOM, Beginning NFC, str Zdroj: NFC Forum: Technical Specifications 14

15 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 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 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 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

16 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 zatímco 0x02 je kód pro 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 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 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 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 Tvrzení bráno ze zdroje: IGOE TOM, Beginning NFC, str Struktura prvního bytu dle zdroje: IGOE TOM, Beginning NFC, str

17 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 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

18 Velikost NDEF zprávy Omezení velikosti Payload NDEF záznamu je omezen délkou 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 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 Tyto tagy paměť velikou aţ 1MB. Zpravidla se jedná o tagy Sony FeliCa 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

19 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 Zřetězení záznamů V případě, ţe chceme poslat obsah větší neţ 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á 2 32 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í 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

20 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 , 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 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 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

21 Prvním hlavním rozdílem mezi RFID a NFC je komunikace peer-to-peer, která je implementována pomocí standardu ISO 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 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

22 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

23 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 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 Specification 10. 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

24 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í 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

25 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 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 Wallet 12 systémy, kdy se zařízení tváří jako platební nebo kreditní karta. a další 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

26 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 Typy NFC tagů Existují čtyři typy specifikované NFC fórem 13, 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 ISO 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 BCM 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

27 Typ 3 Tyto tagy jsou zaloţeny na Sony FeliCa tazích (ISO and JIS-X ), 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 nebo 424Kbps. Podpora předcházení kolizím. Příklad: Sony FeliCa Typ 4 Podobně jako tagy typu 1, jsou tagy typu 4 zaloţeny na NXP DESFire (ISO A) 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 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 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

28 Obrázek 5: NFC Devices vs. Types, zdroj: IGOE TOM, Beginning NFC, str 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 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ţší prioritu 15. 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

29 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

30 Obrázek 6: Android Tag Dispatch System, zdroj: Android Developers: NFC Basics 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