NFC komunikace ve Windows Phone

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Ð Û Å«Æ ±²³ µ ¹º»¼½¾ Ý NFC komunikace ve Windows Phone BAKALÁŘSKÁ PRÁCE Adam Žvak Brno, podzim 2015

Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Adam Žvak Vedoucí práce: Ing. Mgr. et Mgr. Zdeněk Říha, Ph.D. i

Poděkování Rád bych na tomto místě poděkoval svému vedoucímu Ing. Mgr. et Mgr. Zdeněkovi Říhovi, Ph.D za cenné připomínky při psaní této práce, konzultantovi Mgr. Miroslavovi Sliackému za odbornou pomoc a zapůjčení čipových karet a mé přítelkyni Evě Doleželové za zapůjčení mobilního telefonu bez kterého bych nemohl testovat vytvořenou aplikaci. ii

Klíčová slova Windows Phone 8.1, NFC, NDEF, ISO/IEC 14443, APDU, bezkontaktní čipová karta, mobilní telefon iii

Shrnutí Cílem této práce bylo prozkoumat možnosti využití NFC v mobilním operačním systému Windows Phone 8.1 a zjistit, zdali systém umožňuje komunikovat s bezkontaktními čipovými kartami standardu ISO/IEC 14443 pomocí APDU. V prvních čtyřech kapitolách je stručný úvod do problematiky čipových karet, APDU a technologie NFC. Pátá kapitola rozebírá podporu NFC v operačním systému Windows Phone 8.1. Získané poznatky demonstruji na mobilní aplikaci umožňující komunikovat s čipovými kartami. V závěru shrnuji, jak lze systém Windows Phone 8.1 využít pro práci s NFC. iv

Obsah 1 Čipové karty............................... 3 1.1 Bezkontaktní čipové karty ISO/IEC 14443........... 4 1.1.1 Přenosový protokol ISO/IEC 14443-4......... 4 1.1.2 Karty FeliCa....................... 4 2 APDU.................................. 5 2.1 Command APDU......................... 5 2.2 Response APDU.......................... 6 3 Near Field Communication...................... 7 3.1 NFC standard........................... 7 3.2 Využití NFC............................ 8 3.3 NFC Data Exchange Format................... 9 3.3.1 Struktura NDEF zpráv................. 9 3.3.2 Zasílání záznamů neurčité velikosti.......... 11 4 NFC ve Windows Phone........................ 12 4.1 NFC ve verzi 8.1.......................... 13 4.2 API Windows.Networking.Proximity............. 13 4.2.1 Zasílání zpráv prostřednictvím objektu typu ProximityDevice........................ 14 4.2.2 Párování prostřednictvím třídy PeerFinder...... 16 4.3 API SmartCards.......................... 17 4.3.1 Třídy API SmartCards.................. 17 4.3.2 APDU komunikace s bezkontaktní čipovou kartou. 18 4.3.3 Emulace karet...................... 19 5 Aplikace komunikující s čipovou kartou.............. 23 5.1 Použití aplikace.......................... 23 5.2 Funkce aplikace.......................... 24 5.3 Provedení kryptografických algoritmů na kartě........ 24 5.3.1 RSA digitální podpis na kartě............. 24 5.3.2 3DES šifrování na kartě................. 26 5.3.3 Struktura aplikace.................... 26 6 Závěr................................... 28 v

Úvod Informační technologie se velmi rychle vyvíjejí. Počítače mají stále vyšší výkon, zmenšují se a snižují spotřebu elektrické energie. Díky tomuto pokroku můžeme výkonný počítač nalézt ve spoustě zařízení, se kterými se denně setkáváme. Od automobilů, přes kuchyňské spotřebiče až po mobilní zařízení jako jsou chytré hodinky nebo mobilní telefony. Mobilní telefony mohou být výkonnější než stolní počítače před několika lety. Mají pamět v řádu gigabytů a několika jádrové procesory. Dokáže je přitom napájet pouze malý akumulátor a pohodlně se vejdou do kapsy. Možnosti mobilních telefonů mohou být navíc rozšířeny o další funkce jako jsou digitální fotoaparát, čtečka otisků prstů, nebo GPS 1. Díky tomuto pokroku mají dnes mobilní telefony širokou míru uplatnění a mohou zastoupit funkci mnoha zařízení. Jednou z možných funkcí mobilních telefonů je technologie Near Field Communication (NFC). Ta si klade za cíl nahradit různé identifikační a autentizační objekty, nebo čipové karty a integrovat je do mobilního zařízení. Technologie NFC má však mnohem širší uplatnění než zastoupení těchto objektů. Umožňuje komunikovat přenos dat, zápis a čtení speciálních NFC štítků nebo komunikaci s procesorovými čipovými kartami. Cílem této bakalářské práce bylo prozkoumat možnosti práce s NFC v mobilním operačním systému Windows Phone verze 8.1 a zjistit, jestli systém dokáže komunikovat s čipovými kartami pomocí APDU. Práce je rozdělena na šest kapitol. První kapitola stručně popisuje co jsou to čipové karty, jak je rozdělujeme a jakým způsobem s nimi můžeme komunikovat. V druhé kapitole jsem podrobněji rozebral APDU příkazy sloužící ke komunikaci s čipovými kartami. Třetí kapitolu věnuji technologii NFC. Jakým způsobem ji lze využít, jaké jsou typy NFC zařízení a módy komunikace. Čtvrtá kapitola popisuje podporu NFC v samotnému systému Windows Phone 8.1. Kapitola začíná stručným popisem podpory NFC v předchozích verzích tohoto operačního systému. Následuje souhrn možností práce s NFC ve verzi 8.1, které ve zbytku kapitoly rozebírám podrobněji. Pátá kapitola se věnuje praktické části práce, ve které demonstruji zjištěné informace. K demonstraci jsem vytvořil mobilní aplikaci schopnou APDU komunikace s bezkontaktními čipovými kartami. 1. Global Positioning System - systém pro určení přesné pozice na mapě. 1

V poslední kapitole se pokusím shrnout nabyté poznatky a naznačit, kam se bude vyvíjet podpora NFC v dalších verzích systému Windows Phone. 2

1 Čipové karty Čipová karta je plastová karta s integrovaným obvodem, schopna zpracování dat [14, s.5]. Karta nemá vlastní napájení. K sériové komunikaci s kartou slouží terminál neboli čtečka, která kartu také napájí. Rozměr karty určuje standard ISO/IEC 7816. Nejrozšířenější je typ ID-1 o rozměrech 85,725 mm 53,975 mm, tedy velikost kreditní karty [1, s.15]. Z hlediska čipu dělíme karty na pamět ové a procesorové. Pamět ová karta obsahuje pamět, ze které lze data bud jenom číst, nebo také zapisovat. Pomocí sériového rozhraní a jednoduché logiky uvniř karty přistupujeme přímo k pamět ovým buňkám. Přístup může být chráněn heslem, míra zabezpečení se liší dle jednotlivých druhů pamět ových karet. Obecně lze však říct, že pamět ové karty jsou méně bezpečné než karty procesorové. Procesorové karty mají kromě paměti i vlastní mikroprocesor. Kartu řídí operační systém, který zajišt uje přístup do paměti a dělí ji na nezávislé sekce přiřazené jednotlivým aplikacím. Díky tomu může mít jedna karta více funkcí, přičemž každou funkci reprezentuje jedna aplikace. Do paměti procesorové karty nemůže terminál přistupovat přímo. Přístup do paměti je vždy zajištěn operačním systémem. To zaručuje vysokou míru bezpečnosti dat [14, s.11]. Nejrozšířenějšími čipovými kartami jsou SIM karty v mobilních telefonech nebo platební karty. Obrázek 1.1: Blokové schéma procesorové čipové karty [40] Podle způsobu komunikace dělíme karty na kontaktní a bezkontaktní. Kontaktní karty mají na povrchu plochu s osmi vyvedenými kontakty (používají se však jen čtyři), pomocí kterých ji můžeme spojit s terminálem[14, s.10]. Bezkontaktní karty komunikují bezdrátově na krátkou vzdálenost v řádech centimetrů. Jsou napájeny indukcí v elektromagnetickém poli termi- 3

1. ČIPOVÉ KARTY nálu a přenos probíhá pomocí rádiových vln. Jedna karta může implementovat oba způsoby komunikace (známe například z bezkontaktních platebních karet). Kontaktní čipové karty jsou popsány ve specifikaci ISO/IEC 7816, bezkontaktní karty ve specifikaci ISO/IEC 14443. Všechny karty a terminály splňující tyto normy mají standardizovanou sady příkazů umožňující komunikaci terminálu s procesorovými kartami. Tyto příkazy se nazývají Application Protocol Data Unit (APDU)[14, s.12]. 1.1 Bezkontaktní čipové karty ISO/IEC 14443 ISO/IEC 14443 je mezinárodní norma, která popisuje bezkontaktní čipové karty komunikující na krátkou vzdálenost do 10 cm. Přenos probíhá na frekvenci 13,56MHz. Karty nepotřebují vlastní napájení, proud se uvnitř karty indukuje pomocí cívky v elektromagnetickém poli terminálu. Tato norma je rozdělena na čtyři části. První popisuje fyzické charakteristiky karty (např. rozměry karty či sílu elektromagnetického pole). Druhá část definuje frekvenci rádiových vln, rozhraní signálu, přenosovou rychlost, detekci a opravu chyb. Inicializace komunikace a zamezení kolizí je popsáno v třetí části. Poslední část ISO/IEC 14443-4 se zabývá přenosovým protokolem. Čipové karty ISO/IEC 14443 se dělí na typy A a B, které se liší rozdílnou modulací a kódováním. Některé radiofrekvenční identifikační (RFID) štítky jsou také založeny na této technologii[1, s.297]. 1.1.1 Přenosový protokol ISO/IEC 14443-4 ISO/IEC 14443-4 popisuje poloduplexní, blokově orientovaný přenosový protokol, uzpůsobený bezkontaktním systémům. Stejně jako ve standardu ISO 7816-4[15] popisujícím kontaktní čipové karty, umožňuje protokol přenášet APDU příkazy pomocí kterých s kartou komunikujeme[1, s.329]. 1.1.2 Karty FeliCa FeliCa je systém bezkontaktních karet, vyvinutý společností Sony. Systém je široce rozšířený v Japonsku pro účely elektronických vstupenek a platebních systémů. Byl navrhnut jako typ C standardu ISO/IEC 14443, ale nakonec nebyl jako další typ do standardu přidán. Pracuje jako karty ISO/IEC 14443 na frekvenci 13,56 Mhz s přenosovou rychlostí 212 kb/s a kódováním Manchester. Je kompatibilní s ISO/IEC 18092 popisující NFC[1, s.348]. 4

2 APDU APDU je komunikační jednotka sloužící ke komunikaci s čipovou kartou. APDU je používána v kontaktních kartách ISO/IEC 7816 i bezkontaktních kartách ISO/IEC 14443. Komunikace pomocí APDU je poloduplexní a probíhá systémem dotaz - odpověd. Do karty pošle nejprve terminál APDU příkaz (Command APDU), karta terminálu vrátí odpověd APDU (Response APDU) [16]. 2.1 Command APDU Command APDU (C-APDU) je série bytů a má přesně danou strukturu - povinnou 4 bytovou hlavičku (CLA, INS, P1, P2) a volitelné tělo[3]. Hlavička Tělo (volitelně) CLA INS P1 P2 Lc Data Le 1 B 1 B 1 B 1 B 1 nebo 3 B 0~255 B 1 nebo 3 B Tabulka 2.1: Struktura C-APDU [3] CLA (Class) Značí třídu aplikace na kartě. INS (Instruction) Určuje aplikaci karty v třídě CLA. P1, P2 (Parameter) Těmito byty můžeme předat dodatečnou informaci zvolené instrukci. Význam se mění podle bytu CLA a INS. Lc (Length Command) Velikost pole Data (povinná, pokud není datová část prázdná). Data Data, která chceme kartě předat. Le (Length Expected) Očekávaná velikost datové části Response APDU. Pokud je Le byte 0x00, terminál očekává v odpovědi nejvyšší možnou délku datové části. Ačkoliv mají pole Lc a Le obvykle velikost 1B, mohou být také převedeny na pole o velikosti 3B. V takovém případě mohou poslední dva bajty reprezentovat až číslo 65536, přičemž první byte je 0x00. Vzhledem k volitelnosti jednotlivých částí těla C-APDU může být jeho struktura následující: 5

2. APDU Povinná hlavička Volitelné tělo CLA INS P1 P2 CLA INS P1 P2 Le CLA INS P1 P2 Lc Data CLA INS P1 P2 Lc Data Le Tabulka 2.2: Možný obsah C-APDU [3] 2.2 Response APDU Na odeslaný C-APDU karta reaguje odesláním Response APDU (R-APDU). R-APDU se od C-APDU liší strukturou [3]. Data (volitelně) SW1 SW2 0~Le B 1 B 1 B Tabulka 2.3: Struktura Response APDU[3] Data Data maximální velikosti Le, specifikované v C-APDU na který R- APDU reaguje. Datová část může být vynechána. SW1, SW2 (návratový kód) Stav karty po vykonání příkazu. Určují, jestli se příkaz zpracoval korektně, s varováním, nebo při něm nastaly chyby. Existuje více než 50 různých kódů[39]. Kód 0x90 0x00 značí, že vykonaná operace na kartě proběhla bez chyb. 6

3 Near Field Communication Near Field Communication (NFC) je soubor technologií vycházející z RFID (Radio Frequency IDentification)[17], umožňující bezdrátovou komunikaci dvou zařízení. Tři klíčové vlastnosti NFC jsou velmi malá spotřeba energie, komunikace na krátkou vzdálenost do 10 cm a kompatibilita s bezkontaktními čipovými kartami ISO/IEC 14443 a FeliCa. 3.1 NFC standard V roce 2004 společnosti Nokia, Philips a Sony založily neziskovou organizaci NFC fórum. Cílem bylo celosvětově propagovat používání NFC. V současné době má NFC Fórum přes 180 členů [4]. Ve stejném roce NFC Fórum vytvořilo specifikace částečně vycházející ze standardů ISO/IEC 14443 a FeliCa, které zahrnovaly architekturu NFC zařízení a protokoly pro výměnu dat. Tyto specifikace byly později schváleny jako standardy ISO/IEC 18092 (NFCIP-1) a ISO/IEC 21481(NFCIP-2). O dva roky později byly publikovány specifikace zahrnující standardy pro datové formáty NDEF (NFC Data Exchange Format) a v roce 2007 publikovalo fórum specifikace čtyřech druhů NFC štítků 1. Všechny čtyři vycházejí ze standardu ISO/IEC 14443 a FeliCa. Velké množství bezkontaktních karet do té doby používaných například jako identifikační karty či MHD jízdenky jsou tedy s NFC kompatibilní a již instalované ISO/IEC 14443 terminály mohou komunikovat s NFC zařízeními. Krátký popis každého ze čtyř typů štítků [1, s.348]: Typy 1 a 2 Jsou založeny na standardu ISO/IEC 14443, typ A. Jsou velmi levné, mají však omezenou kapacitu do 1~2 kb a přenosová rychlost je 106 kb/s. Typ 3 Vychází ze standardu FeliCa. Tagy mají 2kB paměti a rychlost přenosu je 212 kb/s. Typ 4 Je plně kompatibilní s typy A i B standardu ISO/IEC 14443 a vychází z bezkontaktních čipových karet. Pamět karet je typicky 64KB a více a rychlost může být různá od 106 kb/s do 424 kb/s. Tyto karty mají vlastní integrovaný mikroprocesor s pokročilou bezpečnostní logikou. To znamená také vyšší cenu oproti typům 1, 2 a 3. Používají se především tam, kde jsou kladeny vysoké nároky na bezpečnost, například jako bezkontaktní platební karty. 1. Pasivní NFC zařízení malých rozměrů. Typicky samolepka, klíčenka nebo karta. 7

3. NEAR FIELD COMMUNICATION Rozlišujeme mezi dvěma typy NFC zařízení - aktivní a pasivní. Pasivní zařízení nemá vlastní napájení a uchovává informace, které mohou být čteny aktivním zařízením. Příklad pasivního NFC zařízení je NFC štítek (NFC tag). Aktivní zařízení má vlastní napájení. Může číst informace z pasivního zařízení, zapisovat je do něj nebo může pasivní zařízení emulovat[18]. Při komunikaci rozlišujeme mezi iniciátorem komunikace, který má roli master a cílem, který má roli slave. Po započetí komunikace nemohou být role změněny. Na rozdíl od bezkontaktních karet ISO/IEC 14443, které mají role dané, je u NFC možná komunikace dvou aktivních zařízení a obě mohou mít roli master i slave, nikoliv však najednou. Při zahájení komunikace master zvolí inicializační rychlost, na které komunikace začne. Může to být bud 106, 212, nebo 424 kb/s[1, s.349]. Ačkoliv je rychlost 848kb/s podporována ve standardu ISO/IEC 14443, ve standardu NFCIP-1 tato rychlost popsána není. V závislosti na možnostech obou stran mohou být parametry komunikace v průběhu změněny. 3.2 Využití NFC Využití NFC technologií můžeme rozdělit na tři kategorie korespondující se třemi módy, které NFC podporuje[1, s.350]. Prvním módem je čtení/zápis. V tomto módu aktivní NFC zařízení komunikuje s pasivním NFC štítkem, nebo jiným aktivním zařízením emulujícím štítek. Zařízení, které začalo komunikaci, má roli master a dokáže zapisovat data na štítek nebo je číst. Vzhledem k relativně nízké přenosové rychlosti a malé kapacitě štítků se NFC hodí především k výměně malých objemů dat, jako jsou URL, vizitky a krátké textové zprávy. Dalším módem komunikace je párování (peer to peer), který spojuje dvě aktivní NFC zařízení. Mód párování se používá nejen k výměně dat mezi jednotlivými stranami komunikace, ale také zaslání informací potřebných k navázání spojení dvou Bluetooth 2 (BT), nebo WiFi zařízení. Díky tomu lze párovat například mobilní telefon s reproduktory, tiskárnou, nebo jiným telefonem pouhým přiložením k jejich NFC terminálu. Poslední je mód emulace karty, kdy se aktivní NFC zařízení chová jako pasivní NFC štítek, nebo čipová karta. Emulace čipové karty může probíhat dvěma způsoby. Prvním způsobem je softwarová emulace, kdy čipovou kartu softwarově simuluje procesor NFC zařízení. Další možností je umístění samostatného zabezpečeného čipu do NFC zařízení, podobného jako se 2. Standard pro bezdrátovou komunikaci dvou a více zařízení na krátkou vzdálenost do 100 metrů. 8

3. NEAR FIELD COMMUNICATION nachází v čipových kartách. NFC poté funguje pouze jako prostředník zajišt ující komunikaci čipu se čtečkou. Každý přístup má své výhody. Fyzický zabezpečený čip je bezpečnější, zatímco hlavní výhodou softwarové emulace je právě fakt absence nutnosti speciálního čipu. Hlavní využití módu emulace najdeme v mobilních telefonech při emulaci platebních karet, identifikačních karet, MHD jízdenek apod. 3.3 NFC Data Exchange Format NFC Data Exchange Format (NDEF)[19] je univerzální formát zapouzdření zpráv specifikován NFC fórem, který slouží k výměně dat pomocí NFC. NDEF definuje strukturu a pravidla pro konstrukci NDEF zpráv, ale také typy aplikačních dat zapouzdřených v NDEF zprávách. Specifikace předpokládá existenci spolehlivého transportního protokolu na nižších vrstvách. NDEF má jednoduchý formát, umožňující zapouzdření libovolných dat, jakékoliv velikosti. Toho se využívá při dynamickém generování obsahu větší velikosti, kdy jsou data rozdělena do několika bloků. NDEF zpráva může také slučovat několik datových typů, které spolu logicky souvisí. 3.3.1 Struktura NDEF zpráv Zprávy NDEF se mohou skládat z jednoho, nebo více NDEF záznamů. První obsahuje příznak MB (Message Begin) a poslední příznak ME (Message End). Obrázek 3.1: Struktura NDEF zprávy [41] Každý záznam nesoucí data aplikačního protokolu je identifikován typem, délkou a volitelným identifikátorem. Záznam může mít zkrácenou nebo klasickou strukturu. Kromě příznaků MB a ME jsou dále v záznamu příznaky CH, SR, a IL. CH (Chunk Flag) se používá, pokud jsou data rozdělena do více zpráv. SR (Short Record) označuje, jestli se jedná o klasický 9

3. NEAR FIELD COMMUNICATION nebo zkrácený záznam a příznak IL informuje o poli ID LENGTH. Důležitá je tříbitová hodnota TNF (Type Name Format) definující formát pole TYPE. Jeho hodnoty mohou být následující[27]: 0x00 prázdný typ, je-li nastaven, pole TYPE LENGTH, ID LENGTH a PAYLOAD LENGTH jsou nulové. TYPE, ID a PAYLOAD jsou ze záznamu vynechány. 0x01 NFC Fórum Well-known typ. 0x02 Typy médií MIME definované v RFC 2046. 0x03 Absolutní URI definované v RFC 3986. 0x04 Externí typ NFC fóra. 0x05 Neznámý typ. Pokud je nastaven, TYPE LENGTH musí být nulový a pole TYPE je ze záznamu vynecháno. 0x06 Nezměněný typ určený pouze prostědním záznamům rozdělené NDEF zprávy. Je-li nastaven, TYPE LENGTH musí být nulový a pole TYPE je ze záznamu vynecháno. 0x07 Rezervováno. Pole TYPE LENGTH a TYPE určují na základě pole TNF typ přenášeného záznamu. Důležitým TNF je NFC Forum Well Known type, se kterým by si mělo umět poradit každé NFC zařízení. Well-known type se dělí na čtyři typy [27, s.14]: Jednoduchý textový záznam, který může obsahovat libovolný textový řetězec. Může obsahovat také informace o použitém kódování a jazyku. URI obsahující sít ovou adresu. Od NFC zařízení, které tento typ přečte se očekává, že URI předá aplikaci, která je jej schopna přečíst, například internetovému prohlíźeči. Smart poster obsahuje data, která mohou být přidána k plakátu pro poskytnutí více informací. Může obsahovat URI, ale také další data jako příkaz k odeslání SMS zprávy. NFC zařízení, které tento typ přečte, by mělo v závislosti na obsahu otevřít internetový prohlížeč, SMS aplikaci, nebo emailového klienta. Digitální podpis zaručující důvěryhodnost dat uložených na štítku. 10

3. NEAR FIELD COMMUNICATION Obrázek 3.2: Vlevo klasická a vpravo zkrácená struktura NDEF záznamu [41] Pole PAYLOAD, PAYLOAD LENGTH a PAYLOAD ID nesou samotná přenášená data, jejich délku a volitelný identifikátor. 3.3.2 Zasílání záznamů neurčité velikosti Zprávu můžeme začít vysílat už ve chvíli, kdy ještě neznáme její konečnou velikost. Zpráva se rozdělí na kusy, tzv. Record Chunks (RC). Každý RC je poté odeslán v jednom NDEF záznamu. Každý záznam je z hlediska umístění v celkové zprávě bud počáteční, koncový, nebo střední. Počáteční záznam má nastaven příznak CF (Chunk Flag). Pole PAYLOAD TYPE reprezentuje typ užitečných dat celé zprávy a PAYLOAD LENGTH reprezentuje délku PAYLOAD pole v aktuálním zasílaném záznamu. Střední části mají také nastavený CF příznak. TNF pole je nastaveno na 0x06 (nezměněno). Ukončující záznam má prázdný příznak CF. Tak indikujeme poslední záznam stejného typu, jako byl typ počáteční. Data takto můžeme rozdělit pouze v rámci jedné NDEF zprávy[2]. 11

4 NFC ve Windows Phone NFC aplikakce v mobilních telefonech můžeme rozdělit na dvě kategorie[28, s.287]. První kategorie využívá bezpečnostního prvku (Secure Element) a aplikace v této kategorii pracují v režimu emulace karty. Druhým typem jsou aplikace pracující s daty, která nepovažujeme za citlivá. Tyto aplikace pracují v režimu čtení/zápis nebo párování. Další možné rozdělení je na NFC funkce vestavěné přímo do systému a NFC funkce dostupné vývojářům aplikací. Pro vývoj aplikací pro platformu WP 8 potřeba vývojové prostředí Visual Studio a WP SDK 1 (Software Development Kit). K funkcím operačního systému programátoři přistupují pomocí API 2 (Application Programming Interface). Windows Phone (WP) je operační systém pro mobilní telefony vyvíjený společností Microsoft. Je na trhu od roku 2010, kdy vyšla verze 7. Následovaly aktualizace na verze 7.5 a 7.8 (7.X). Verze 7.X byly založeny na jádru Windows Embedded CE, které používal i jeho předchůdce Windows Mobile[22]. Žádná z verzí 7.X nepodporovala NFC[20, 21]. V roce 2012 společnost Microsoft vydala systém WP 8, který obsahoval nové jádro Windows NT (New Technology). To znamená že používá stejný souborový systém (NTFS), stejný grafický engine (DirectX) a stejný systém pro práci s ovladači jako počítačová verze Windows (v té době ve verzi 8). Aktualizace z WP 7.X na WP 8 nebyla z důvodu rozdílného jádra možná [23]. Spolu s jádrem Windows NT přinesla verze 8 také základní podporu NFC. Systém WP 8 umožňoval NFC platby pomocí aplikace Peněženka [24]. Ke správné funkci však byla nutná speciální SIM karta s bezpečnostním prvkem. Ten zastupoval čip platební karty. Další funkcí zabudovanou v systému bylo sdílení dat s jiným WP 8 telefonem. Vývojáři měli ve WP 8 SDK pro práci s NFC k dispozici pouze API Windows.Networking.Proximity, které umožňovalo práci s NDEF zprávami a párování. Možnost práce s NDEF zprávami byla však značně omezena. Nešlo například zapisovat zprávy na nenaformátovaný NFC štítek, nebo nešlo NFC štítek uzamknout k zamezení další manipulace[9]. 1. Balík nástrojů určených pro vývoj aplikací pro platformu Windows Phone[26] 2. Soubor příkazů, funkcí a protokolů, které mohou programátoři použít při vývoji aplikací[25]. 12

4. NFC VE WINDOWS PHONE 4.1 NFC ve verzi 8.1 V roce 2014 vydal Microsoft aktualizaci WP 8.1, která mimo jiné rozšířila možnosti využití NFC. Prostřednictvím NFC v této verzi můžeme sdílet kontakty, odkazy a multimédia s jiným NFC zařízením. Malé objemy dat (odkazy a kontakty) jsou přeneseny přímo prostřednictvím NFC ve formě NDEF zprávy. Multimédia jsou vzhledem k velkému objemu dat přenášena prostřednictvím BT a NFC zajistí pouze bezobslužné navázání BT spojení. Pro přenos multimédií je tedy nutné, aby měly obě zařízení zapnuto BT. Pomocí NFC můžeme telefon také párovat s jiným BT zařízením podporujícím NFC, například reproduktory. Podpora párování s WiFi Direct zařízením není ve WP 8.1 možná, ale je v plánu pro Windows 10 Mobile 3 [5]. Emulaci karet Windows 8.1 podporuje prostřednictvím aplikace Peněženka, je však nutná SIM karta se zabezpečeným prvkem stejně jako ve verzi 8. Možnost NFC plateb jde povolit, nebo zakázat v nastavení telefonu. Lze také nastavit, v jakých situacích jsou platby aktivní. Některé telefony podporují platby i vypnutým telefonem v pasivním NFC režimu. Jsou-li NFC platby aktivní, stačí telefon přiblížit k terminálu stejně jako bezkontaktní platební kartu a platba se provede. Speciální aplikace není nutná, můžeme ale pomocí ní rozšířit funkcionalitu například o prohlížení historie plateb. Vývojářům je ve verzi 8.1 k dispozici vylepšené API Proximity pro párování a výměnu NDEF zpráv a nově API SmartCards umožňující komunikaci s čipovými kartami pomocí APDU. 4.2 API Windows.Networking.Proximity Možnosti tohoto API jsou omezené pouze na výměnu NDEF zpráv a párování. Nově toto API umí zápis zpráv i na nenaformátované NFC štítky 4, což ve verzi 8 nebylo možné[29]. Pokud se pokusíme na takovýto NFC štítek zprávu zapsat, API Proximity se před zápisem automaticky postará o naformátování štítku a poté zprávu zapíše. Práce s API Proximity je jednoduchá. Nejprve získáme přístup k NFC prostřednictvím instance třídy ProximityDevice. Instanci získáme voláním statické metody ProximityDevice.GetDefault. Pokud žádné NFC zařízení není k dispozici (to znamená, že telefon NFC nemá), vrací metoda hodnotu 3. Další aktualizace systému WP 8.1. 4. Nenaformátovaný NFC štítek je kompletně prázdný a nemá vnitřní strukturu pro ukládání NDEF zpráv. 13

4. NFC VE WINDOWS PHONE null. S objektem typu ProximityDevice můžeme následně odesílat a přijímat NDEF zprávy a využívat událostí DeviceArrived a DeviceDeparted. DeviceArrived nastane, pokud do NFC pole telefonu přiblížíme jiné NFC zařízení, DeviceDeparted, pokud zařízení z pole odebereme[8]. 4.2.1 Zasílání zpráv prostřednictvím objektu typu ProximityDevice API Proximity umí několik typů NDEF zpráv zpracovat automaticky a umožňuje také manipulovat přímo s bytovou strukturou zpráv. K zasílání NDEF zpráv slouží metoda PublishBinaryMessage. Jako argumenty předáváme typ zprávy, obsah zprávy a handler volaný po přenesení zprávy. Návratová hodnota odeslané zprávy je její unikátní ID. Pokud vyšleme několik zpráv se stejným obsahem, bude mít každá z nich své unikátní ID. Zařízení se pokouší zprávu vysílat dokud odstraněn objekt ProximityDevice, nebo dokud není na tomto objektu zavolána metoda StopPublishingMessage s parametrem ID vysílané zprávy. Argument typ zprávy je textový řetězec obsahující dvě části - protokol a podtyp. Protokol je na prvním místě, podtyp je od něj oddělen tečkou. Jsou to řetězce alfanumerických a jakýchkoliv validních URI znaků 5. Podtyp nesmí překročit délku 25 znaků a jsou rozlišována velká a malá písmena. Uvádím některé druhy podporovaných zpráv[8]: Windows Obecná NDEF zpráva obsahující binární data WindowsUri Zpráva obsahující řetězec kódován UTF-16LE, představující URI. WP zpracuje příchozí zprávy tohoto typu vždy prostřednictvím implicitní aplikace přiřazené k danému URI protokolu. Tedy například URI začínající http:// se otevře ve webovém prohlížeči. Namísto volání metody PublishBinaryMessage s typem WindowsUri se doporučuje použít přímo metodu PublishUriMessage. Je-li aktivní čtení WindowsUri zpráv a přijde podporovaná NDEF zpráva, obsahem příchozí zprávy bude pouze samotné URI. WindowsMime* Zpráva je MIME typem specifikovaným v podtypu. Například pokud ve zprávě posíláme jpeg obrázek, typ zprávy bude "WindowsMime.image/jpeg". Nepřijímá-li vysílanou zprávu zařízení Windows, je automaticky naformátována jako NDEF:MIME záznam. Příchozí zprávy formátované jako NDEF:MIME Windows přečte a vrátí obsah určeného MIME typu jako obsah zprávy. V odchozích 5. Definováno v RFC 3986: -.~:/?#[]@!$& ()*+,;=% 14

4. NFC VE WINDOWS PHONE zprávách musíme vždy specifikovat MIME typ. Pokud chceme přijímat MIME zprávy a nespecifikujeme jejich typ, budou přijímány všechny typy MIME zpráv. V takovém případě bude prvních 256 bytů zprávy řetězec popisující typ zprávy. Windows:WriteTag Stejné jako protokol Windows. Očekává se však, že obsah zprávy bude zapsán na NFC štítek. Není-li cílové zařízení NFC štítek, zpráva se neodešle. WindowsUri:WriteTag Jako protokol WindowsUri. Očekává se, že obsah zprávy bude zapsán na NFC štítek. Není-li cílové zařízení NFC štítek, zpráva se neodešle. WindowsMime:WriteTag Jako protokol WindowsMime. Očekává se, že obsah zprávy bude zapsán na NFC štítek. Není-li cílové zařízení NFC štítek, zpráva se neodešle. LaunchApp:WriteTag Zapisuje do NFC štítku příkaz ke spuštění aplikace. Zpráva musí být kódována jako UTF-16LE řetězec, ve kterém jsou hodnoty odděleny tabulátory nebo hodnotami null. Formát zprávy je následující: <argumenty spuštění>[tab]<platforma 1>[tab]<aplikace 1>...[tab]< platforma N>[tab]<aplikace N> Specifikována musí být alespoň jedna platforma s názvem aplikace. Ve Windows Phone aplikaci specifikujeme řetězcem tvaru: <package family name>!<app Id> WriteableTag Tento protokol slouží pouze k přijímání zpráv. Pokud je zapisovatelný NFC štítek přiblížen k zařízení, obdržíme maximální možnou velikost, kterou lze na štítek zapsat. NDEF Obsah zprávy je NDEF záznam, jehož typ je specifikován uvnitř samotného NDEF záznamu. NDEF:MIME* NDEF Mime zpráva. Např. "NDEF:MIME.image/jpeg". NDEF:WriteTag* Zpráva v NDEF formátu, která je určena pro zápis na NFC štítek. NDEF:Unknown* Zpráva NDEF s neznámým typem. 15

4. NFC VE WINDOWS PHONE * Protkoly určené pouze k příjmání zpráv. Pro publikaci těchto zpráv je nutné použít typ NDEF. Algoritmus 4.1 Příklad užití PublishBinaryMessage pro zápis URL na pasivní štítek [8] using Windows.Networking.Proximity; using Windows.Security.Cryptography; public void trywriteuritonfctag() { var device = ProximityDevice.GetDefault(); if (device!= null) { string uri = "http://fi.muni.cz/" var id = device.publishbinarymessage ("WindowsUri:WriteTag",CryptographicBuffer.ConvertStringToBinary (uri,binarystringencoding.utf16le)); } } Příjem zpráv provádíme voláním SubscribeForMessage metody objektu typu ProximityDevice. Parametry jsou obdobné jako při odesílání zpráv. Zrušení příjmu zpráv se provádí předáním id metodě StopSubscribingForMessage, nebo odstraněním objektu ProximityDevice[8, 10]. 4.2.2 Párování prostřednictvím třídy PeerFinder Pomocí třídy PeerFinder z API Proximity lze bezobslužně propojit dvě spuštěné Windows (Phone) aplikace. Spojení je navázáno přiblížením NFC zařízení, tzv. gestem dotyku, nebo prozkoumáním bezdrátových sítí v dosahu a je realizováno pomocí Bluetooth, nebo existující sít ové infrastruktury. Samotné propojení zařízení je realizováno objektem StreamSocket, ve kterém jsou důležité vlastnosti InputStream a OutputStream prostřednictvím kterých spolu aplikace mohou komunikovat[8]. Při pokusu o spojení pomocí gesta dotyku je uživatel, který nemá spuštěnou požadovanou aplikaci vyzván k jejímu spuštění. Pokud nemá aplikaci v zařízení nainstalovanou, je mu nabídnuto stažení z Windows Store 6. Důležité metody třídy PeerFinder jsou Start a Stop, pomocí kterých můžeme aplikaci zviditelnit, nebo skrýt pro ostatní zařízení. Ostatní zařízení v dosahu sít ové infrastruktury je možné vyhledat pomocí metod FindAll- PeersAsync. Je-li nějaké zařízení nalezeno, můžeme se k němu připojit me- 6. Služba pro elektronickou distribucí aplikací pro platformu Windows Phone. 16

4. NFC VE WINDOWS PHONE todou ConnectAsync. V zařízení, ke kterému se chce jiné zařízení připojit je vyvolána událost ConnectionRequested. Události TriggeredConnection- StateChanged nastane, pokud jsme zařízení přiblížili do NFC pole jiného zařízení. 4.3 API SmartCards Toto API je ve WP přítomno od verze 8.1 a obsahuje třídy pro komunikaci s čipovými kartami prostřednictvím APDU příkazů. Komunikovat lze s bezkontaktní kartou ISO/IEC 14443, nebo se SIM kartou s bezpečnostním elementem. API také umožňuje vytvářet platební aplikace nezávislé na aplikaci Peněženka. Pro použití API SmartCards je v telefonu vyžadován NFC čip podporující APDU. V době psaní této BP takový čip mají telefony Nokia (Microsoft) 830, 735 a 730. Všechny tři používají čip NXP PN547. Zařízení s tímto čipem podporují NFC karty MIFARE Classic/Ultralight/DESfire. Omezenou podporu mají také karty ISO 15693 a FeliCa. Dá se očekávat, že nové modely telefonů budou mít také NFC čip podporující toto API[11, 12]. 4.3.1 Třídy API SmartCards API nabízí několik tříd, pomocí kterých můžeme s kartami komunikovat. Uvádím nejdůležitější z nich[7]: SmartCardReader Představuje informace o NFC čtečce v telefonu. Může představovat jak terminál pro SIM kartu s bezpečnostním elementem, tak NFC čtečku. Události: Metody: CardAdded Nastane když se v NFC poli objeví karta. CardRemoved Nastane když je karta z NFC pole vyjmuta. FindAllCardsAsync Pomocí této metody je možno získat objekty představující všechny karty připojené ke čtečce. GetDeviceSelector Vrací Advanced Query Syntax (AQS). AQS je řetězec reprezentující všechny čtečky nacházející se v zařízení. SmartCard Objekt tohoto typu reprezentuje samotnou čipovou kartu připojenou k terminálu 17

4. NFC VE WINDOWS PHONE Metody: ConnectAsync Pomocí této metody se lze ke kartě připojit a následně s kartou pracovat. GetAnswerToResetAsync Vrací Answer To Reset 7 (ATR). SmartCardConnection Objekt představující spojení s čipovou kartou. Pomocí tohoto objektu můžeme do kartu posílat C-APDU. Metody TransmitAsync Odešle C-APDU do karty a vrátí R-APDU. 4.3.2 APDU komunikace s bezkontaktní čipovou kartou Použití API pro komunikaci s bezkontaktní kartou lze rozdělit na tři kroky [11]. Jako první je nutné pomocí metody SmartCardReader.FromIdAsync získat objekt typu SmartCardReader představující NFC čtečku. Argumentem je identifikátor NFC čtečky, který lze získat pomocí metody DeviceInformation.FindAllAsync s argumentem AQS (tedy řetězcem představujícím všechny čtečky zařízení). Metoda vrátí kolekci objektů. V telefonu je ale typicky pouze jedna NFC čtečka, takže vybereme první z nich a jeho vlastnost Id je požadovaný identifikátor čtečky. Pokud je kolekce prázdná, v telefonu není podporovaná NFC čtečka. Třída DeviceInformation nepatří do API SmartCards, ale do API Windows.Devices.Enumeration a reprezentuje obecné zařízení telefonu. var dvcs = await DeviceInformation.FindAllAsync(SmartCardReader.GetDeviceSelector( SmartcardReaderKind.Nfc)); var nfcreader = await SmartCardReader.FromIdAsync(dvcs.First().Id) ; Po získání objektu reprezentující čtečku je možné reagovat na její události CardAdded a CardRemoved. Metody přiřazené události CardAdded se začnou vykonávat, pokud je ke čtečce přiložena karta. Metody události CardRemoved jsou spuštěny při odebrání karty. Po vyvolání události CardAdded se ke kartě lze připojit a komunikovat s ní pomocí objektu Card- Connection. 7. Série bytů obsahující informace o charakteristikách čipové karty, jejím chování a stavu. 18

nfcreader.cardadded += NfcCardAdded; nfcreader.cardremoved += NfcCardRemoved; 4. NFC VE WINDOWS PHONE public async void NfcCardAdded(SmartCardReader sender, CardAddedEventArgs args) { // Pripojeni ke karte a nasledne operace s kartou } public async void NfcCardRemoved(SmartCardReader sender, CardAddedEventArgs args) { // Operace po odpojeni karty } Argument typu CardAddedEventArgs události CardAdded obsahuje objekt reprezentující kartu ve vlastnosti SmartCard. Pomocí jeho asynchronní metody ConnectAsync je možné se s kartou spojit a získat objekt Card- Connection. Pomocí spojení je možné odesílat C-APDU metodou TransmitAsync. C-APDU je metodě předán jako argument, vrácená hodnota je R- APDU. C-APDU i R-APDU reprezentují objekty typu IBuffer. public async void NfcCardAdded(SmartCardReader sender, CardAddedEventArgs args) { using (var nfccon = await args.smartcard.connectasync()) { var rapdubuf = await nfccon.transmitasync(capdubuf); } } API neprovádí žádnou kontrolu APDU. Může se proto stát že odešleme C-APDU s nesprávnou strukturou. Pokud na takto špatně strukturovaný dotaz karta odpoví, je vrácen R-APDU obvykle s byty SW1 a SW2 označující chybu. Pokud na špatně strukturovaný APDU nedokáže karta odpovědět je vyvolána výjimka. Toto se stane například odesláním C-APDU o délce menší než 4 bajty. 4.3.3 Emulace karet V módu emulace karty NFC zajišt uje přenos dat mezi telefonem a čtečkou. Aby se telefon choval jako čipová karta, je nutné nahradit bezpečnostní prvek simulované karty. Ten může být ve formě čipu napevno připájeného na desku telefonu, součástí speciální zabezpečené SIM karty, nebo může být součástí pamět ové karty (tato možnost se však téměř nepoužívá). Terminál poté komunikuje přímo s bezpečnostním prvkem a NFC slouží pouze jako prostředník přenášející data. Zabezpečený čip na základní desce využívá například společnost Apple u svých telefonů pro platební systém Apple Pay[31]. 19

4. NFC VE WINDOWS PHONE Obrázek 4.1: Schéma emulace karty pomocí hardwarového bezpečnostního prvku [42] Další možností je emulovat bezpečnostní prvek softwarově. Tento přístup se nazývá Host-based Card Emulation (HCE). NFC řadič v tomto případě komunikuje s procesorem telefonu, který se chová jako zabezpečený čip. HCE využívá například platforma Android u svého platebního systému Wallet[31]. Obrázek 4.2: Schéma emulace karty pomocí HCE [42] Windows 8.1 umožňuje softwarovou emulaci karet pouze pomocí zabezpečené SIM karty. Oproti WP 8 je v oblasti emulace karet několik novinek [11]. První z nich je zrušení API Microsoft.Phone.SecureElement jehož funkce jsou nahrazeny v API SmartCards. Vývoj aplikací emulující karty se zjednodušil a nadále nejsou vyžadovány žádné speciální nástroje ani povolení ze strany Microsoftu. Nejsou potřeba ani speciální ovladače pro konkrétní zařízení, aplikace by měla fungovat na všech zařízeních s NFC a WP 8.1 bez rozdílu. 20

4. NFC VE WINDOWS PHONE Komunikace se zabezpečenou SIM kartou je podobná jako v v případě bezkontaktních čipových karet. Aplikační kód může reagovat na pozadí na událost přiblížení telefonu terminálu bez toho, aby měl uživatel aplikaci spuštěnou. S přiděleným oprávněním ze strany Microsoftu může být aplikační kód spuštěn i při zamknuté obrazovce telefonu. Nemá-li toto oprávnění, uživatel je nejprve vyzván, aby zadal PIN. Uživatelé si sami v nastavení telefonu vyberou, kdy bude emulace karty aktivní. Na výběr jsou možnosti: vždy, při zapnutém telefonu, při zapnutém displeji, nebo při odemčeném telefonu. Emulaci karet při vypnutém telefonu podporují pouze některé telefony (například HTC 8X)[6]. Toto nastavení lze zjistit z kódu aplikace a případně uživatele přesměrovat do nastavení telefonu přímo z aplikace[13]. Užití API SmartCards pro emulaci karet Aplikace může s applety na zabezpečené SIM kartě komunikovat pomocí APDU příkazů. Postup je téměř stejný jako v případě komunikace s bezkontaktními kartami. Objekty čtečky SmartCardReader dostaneme stejným postupem, typ čtečky je ale SmartCardReaderKind.Uicc. SIM kartu nemůžeme z telefonu odbírat a přidávat za běhu, události CardAdded a Card- Removed proto nedávají smysl. Místo toho se k objektu SmartCard dostaneme zavoláním metody FindAllCardsAsync. Následně s objektem pracujeme stejně jako v případě bezkontaktní čipové karty. var cards = await reader.findallcardsasync(); if (cards == null cards.length == 0) { // v telefonu neni pritomna UICC karta } SmartCard uicc = cards.first(); Pokud aplikace emulující kartu není spuštěna na popředí a uživatel telefon přiloží k terminálu, aplikace by se měla o této události dozvědět (například kvůli zobrazení informace o platbě, nebo vyžádání PIN kódu). Třemi hlavními systémovými událostmi, ke kterým můžeme naši aplikaci přiřadit jsou Transaction, FieldEntry a FieldExit. FieldEntry a FieldExit jsou události přiložení telefonu ke čtečce a jeho odebrání. Transaction nastává, pokud je provedena transakce[13]. Pro zpracování těchto událostí je potřeba vytvořit třídu implementující rozhraní IBackgroundTask. Tuto třídu je nutné potom zaregistrovat ze spuštěné aplikace za použití třídy BackgroundTaskBuilder. Pokud dojde k vyvolání některé z událostí, můžeme spustit aplikaci. Aplikace, která na událost zareagovala na pozadí však může spustit pouze sama sebe. Emulace karet pomocí zabezpečené SIM karty není příliš rozšířená a ani 21

4. NFC VE WINDOWS PHONE s ní nelze příliš počítat v budoucnosti. Hlavním důvodem je nutnost speciální SIM karty, která vyžaduje spolupráci mobilních operátorů. Změnit by to mohla podpora HCE ve Windows Mobile 10[5]. 22

5 Aplikace komunikující s čipovou kartou V rámci praktické části bylo mým úkolem vytvořit aplikaci schopnou komunikovat s NFC kartou pomocí APDU, která na kartě provede základní kryptografické operace. Aplikace, kterou jsem pro tuto demonstraci vytvořil, je terminál pro APDU komunikaci s čipovou kartou. Aplikaci jsem umístil do Windows Phone Store pod názvem NFC APDU Tool a je dostupná na adrese: http://bit.ly/1o7jft7. Obrázek 5.1: Snímky obrazovky 5.1 Použití aplikace Scénář použití aplikace je následující: 1. Uživatel zadá do vstupního textového pole jeden, nebo více C-APDU. 2. Po přiložení karty se aktivuje tlačítko odeslat příkaz, uživatel pomocí tlačítka odešle C-APDU do karty. 3. Před odesláním je zkontrolována struktura všech APDU příkazů a v případě chyby je uživatel upozorněn. 4. První C-APDU je odeslán do karty a je zobrazen R-APDU. Pokud uživatel zadal více C-APDU, opakuje se tento bod, dokud se neprovedou všechny příkazy. 23

5. APLIKACE KOMUNIKUJÍCÍ S ČIPOVOU KARTOU 5. Historie všech operací se postupně zobrazuje na displeji. Jednotlivé C-APDU byty se zapisují jako dvojice alfanumerických znaků. Každá dvojice znaků reprezentuje jeden bajt C-APDU a jednotlivé bajty mohou být odděleny mezerami. Jeden řádek reprezentuje jeden C-APDU. Pokud řádek začíná znakem #, je považován za poznámku a ignoruje se. Pokud uživatel zadal C-APDU s chybnou strukturou, nebo jej zapsal ve špatném formátu, je odkázán na řádek, ve kterém se chyba vyskytuje. 5.2 Funkce aplikace Zobrazená historie příkazů barevně rozlišuje význam jednotlivých bytů APDU příkazů i odpovědí. V menu aplikace lze ovládat tři položky nastavení. První z nich je zobrazení informace o délce provádění příkazů. Zobrazený časový údaj je interval mezi odesláním C-APDU a příjmem R-APDU. Další je možností je zapnutí automatického odeslání C-APDU jakmile je karta přiložena. Poslední možností je automatické vyžádání dat dostupných na kartě. Pokud je R- APDU příliš dlouhý a nevleze se do jedné odpovědi, byte SW1 je nastaven na hodnotu 61 a SW2 říká, kolik bajtů zbývá přijmout. Automatické vyžádání dat zašle C-APDU požadující zbylé byty z karty. Tento automaticky vytvořený C-APDU je zobrazen v historii příkazů také. Aplikace si po vypnutí uchovává nastavení, včetně C-APDU příkazů. Historie příkazů se po vypnutí aplikace maže. Může se stát, že při přenosu nastane chyba, například když v průběhu komunikace odstraníme kartu z NFC pole. Na chyby v komunikaci je uživatel upozorněn. 5.3 Provedení kryptografických algoritmů na kartě Pro demonstraci funkčnosti jsem měl k dispozici tři čipové karty. První karta obsahovala aplikaci pro symetrické šifrování pomocí Trpiple DES (3DES) [32] algoritmu. Další dvě obsahovaly aplikaci pro vytvoření RSA[33] digitálního podpisu. Testování bylo provedeno na mobilním telefonu Nokia 830. 5.3.1 RSA digitální podpis na kartě Obě čipové karty pro RSA podpis byly totožné včetně klíčů. Samotný podpis dat se provede odesláním tří APDU. Prvním vybereme, jaký klíč a al- 24

5. APLIKACE KOMUNIKUJÍCÍ S ČIPOVOU KARTOU goritmus má karta použít. Druhý kartě pošle 32 bytů reprezentující hash SHA256[34]. Jako poslední vyvolá samotný podpis dat na kartě a podepsaný hash je vrácen v R-APDU. Podepsaný hash obsahuje hlavičku, tudíž se nevleze do jednoho R-APDU. Je tedy nutné vyžádat zbylé 3 bajty pomocí dalšího C-APDU. Pro testovací účely jsem hash nahradil řadou bytů od 0x01 do 0x20. Vstupu aplikace: 1 #výběr algoritmu a klíče 2 80522AA0 3 #odeslání dat 4 80580400200102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F20 5 #podpis dat 6 805A000000 Výstupu aplikace: 1 <<<<<<<< Card added <<<<<<<< 2 >> 80 52 2A A0 3 << 90 00 4 ^^ 22 ms 5 >> 80 58 04 00 20 01 02 03 04 05 06 07 08 09 0a 0b 6 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 7 1d 1e 1f 20 8 << 90 00 9 ^^ 484 ms 10 >> 80 5A 00 00 00 11 << e0 01 00 20 85 7a 57 5a b6 ed 0d 69 40 23 44 1b 12 13 e5 8b a7 55 66 4d 9c bf d1 2c 79 ac 00 fa 57 0c 13 fa e7 bc 8f 6c cc 81 fa f4 e2 a1 d6 7f 80 dd c5 f9 14 25 58 d0 56 de 7e 2a fe a9 3c 46 2f b0 41 ef f5 7e 15 97 64 05 ed 6d 5e ff 1d b9 c8 75 da 32 af bc 8f ed 16 d1 e8 dc 2d 1e 0b 3d cd 93 56 15 19 2e 0f 7a e8 ea 17 ff c8 c4 0f c1 18 27 3e 11 ca 8c df 2c 1d 37 6a b0 18 50 63 89 b4 61 3a d6 c7 24 e8 d2 d3 67 db 7b ad 44 19 63 ba 11 ea 86 eb 26 49 5b e4 9b a6 af 05 bc 94 b4 20 b9 03 87 3b f6 91 b3 31 42 f2 76 1b e5 46 f9 d0 90 21 0e f5 2c d9 eb 5c 28 4a 35 e1 1f 54 d5 c8 4a 53 96 22 eb 3d 53 f0 97 43 92 29 91 5d 29 07 6e fc 95 e7 50 23 c9 b3 20 40 88 80 3c 49 03 d5 e5 dd 8b 7a 59 a9 8d 24 00 ac ed 9d b1 93 80 7d 7d 36 a0 3e 90 48 ca f3 d9 25 45 5e 4d 8a 85 48 a3 9e ce 7d da b7 f7 d9 b3 44 f9 26 64 0a 61 03 27 ^^ 458 ms 28 >> 00 C0 00 00 03 29 << 9a 51 a7 90 00 30 ^^ 454 ms 31 >>>>>>> Card removed >>>>>>> Správnost elektronického podpisu jsem ověřil pomocí veřejného klíče a online nástroje RSA Encryptor/Decryptor[35]. Zkoumal jsem také fyzické aspekty komunikace. Nejvyšší vzdálenost, kdy ještě telefon s kartami dokázal komunikovat byla přibližně 2 až 3cm. Karty jsem musel umístit přesně do místa, kde je v telefonu umístěna NFC 25

5. APLIKACE KOMUNIKUJÍCÍ S ČIPOVOU KARTOU anténa, jinak nebyly zaznamenány. Dále jsem se zaměřil na rychlost odezvy karet. S kartami jsem provedl celkem 40 měření, dvacet měření s každou. Rychlosti obou karet byly podobné a tak jsem je vzájemně neporovnával. Z naměřených hodnot vyplývá, že nejrychlejší operací je výběr algoritmu. Samotná kryptografie na kartě je naopak nejpomalejší. Doba odezvy (ms) Výběr algoritmu Odeslání dat Podpis dat Příjem zbylých 3B Průměrná 78 216 370 218 Medián 62 196 320 205 Nejnižší 23 24 283 43 Nejvyšší 242 428 674 396 Tabulka 5.1: Rychlost karty při podpisu dat 5.3.2 3DES šifrování na kartě Karta pro 3DES šifrování, kterou jsem měl k dispozici, fungovala od počátku problematicky. Na začátku testování operační systém často zobrazoval chybové hlášky týkající se komunikace s kartou. Postupně karta přestala fungovat úplně. Z toho důvodu jsem neprovedl testy rychlosti a výpis komunikace mám pouze z debugování programu. Šifrování na kartě se provádí dvěma C-APDU. Prvním vybereme aplikaci pro šifrování, druhým data na kartu pošleme. Karta data ihned vrátí v zašifrované podobě. Zde je výstup komunikace s kartou. K šifrování sloužila řada 32 bytů od 0x01 do 0x20. 1 > 00 A4 04 0C 08 A0 00 00 00 28 FF E0 01 2 < 5A 08 A1 A2 A3 A4 A5 A6 A7 A8 90 00 3 > 80 88 00 00 20 01 02 03 04 05 06 07 08 09 10 11 4 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 5 29 30 31 32 6 < 0B CA 62 2E 84 50 AE 72 B3 48 6E C9 D9 D1 F7 56 7 AA C7 03 FA A8 8E AE 03 48 B2 CF AA 7A EA 8F B6 90 8 00 5.3.3 Struktura aplikace K vývoji aplikace jsem použil nástroje Microsoft Visual Studio 2015 a Microsoft Blend For Visual Studio 2015. Aplikace je napsaná v programovacím jazyce jazyce C# 6.0, grafické uživatelské prostředí (GUI) aplikace je definováno značkovacím jazykem XAML 1. Testování probíhalo na telefonech 1. XML značkovací jazyk, který Microsoft používá u svých produktů k definici GUI [36] 26

5. APLIKACE KOMUNIKUJÍCÍ S ČIPOVOU KARTOU Nokia 830 a Nokia 925 s operačním systémem WP 8.1. GUI je definováno v souboru MainPage.xaml pomocí XAML značek. V souboru MainPage.xaml.cs je logika reagující na interakce uživatele. Důležitá je metoda SendCommandsFromInput, která kontroluje správnost C- APDU na vstupu a příkazy pošle kartě. Logika pro komunikaci s kartou se nachází ve třídě NfcViewModel. Metoda SendCommandApduAsync odesílá C-APDU do karty a vrací R- APDU. V této třídě jsou dále vlastnosti navázané na grafické prvky aplikace využitím přístupu data binding 2. Texty použité v GUI jsou uloženy v samostatném souboru Resources.resw, umístěném v adresáři Strings. Třídy CommandApdu a ResponseApdu implementující rozhraní IApdu představují APDU příkazy s byty rozdělenými podle významu. Konstruktory těchto tříd vyžadují jako argument pole bytů představující APDU. Při konstrukci objektu je APDU zkontrolován a v případě chybné struktury je vyvolána výjimka ResponseApduFormatException, nebo CommandApduFormatException. Obrázek 5.2: Struktura tříd programu 2. Způsob svázání vlastnosti objektu s ovládacím prvkem GUI. Vlastnost obsahuje data, které GUI zobrazuje[38] 27

6 Závěr Cílem mé práce bylo ověřit možnosti využití NFC v mobilním operačním systému Windows Phone 8.1 a zjistit, jestli je možné komunikovat s čipovými kartami pomocí APDU. V praktické části jsem měl vytvořit mobilní aplikaci, pomocí které zjištěné poznatky ověřím. Při psaní práce jsem čerpal především z technický článků na webových stránkách a technické literatury. WP verze 8 podporoval NFC jen velice omezeně. Jeho funkcionalita byla v podstatě pouze o práci s NDEF formátem. Navíc neuměl například zapisovat NDEF zprávy na nenaformátovaný štítek. WP 8.1 některá omezení odstraňuje a přidává navíc nové API pro práci s čipovými kartami. První novinkou je vylepšená podpora emulace karet. Ta už není vázána na vestavěnou aplikaci Peněženka a proces vývoje aplikací pro emulaci se zjednodušil. Nevýhodou ale zůstává nutnost přítomnosti speciální SIM karty. To je hlavním důvodem toho, že se emulace karet na této platformě v praxi využívá jen velmi málo, hlavně k mobilním platbám. Situaci by mohla zlepšit softwarová emulace karet HCE, kterou přinese aktualizace na Windows 10 Mobile. Ve WP 8.1 lze pomocí NDEF zpráv zapisovat, nebo číst informace z NFC štítků. Pomocí NDEF zpráv lze také komunikovat s jiným aktivním zařízením. U dat většího objemu, jako jsou multimédia, je NFC použito pouze pro bezobslužné spojení zařízení pomocí BT, kterým jsou následně data přenesena. Podpora zasílání NDEF zpráv se oproti minulé verzi zlepšila. API Proximity nyní umožňuje uzamknout štítky a zapisovat NDEF zprávy i na nenaformátované štítky. Největším přínosem oproti minulé verzi v oblasti NFC vidím v podpoře komunikace s čipovými kartami pomocí APDU příkazů. Telefon se může chovat jako karetní terminál a komunikovat s jakoukoliv bezkontaktní čipovou kartou ISO/IEC 14443, se kterou je NFC ovladač telefonu kompatibilní. Vývojářům je k dispozici API SmartCard, které umožňuje jednoduché zasílání APDU příkazů. Pomocí tohoto API se také provádí komunikace se zabezpečenou SIM kartou v případě módu emulace karty. Jediné omezení v použití tohoto API je potřeba NFC ovladače, který APDU podporuje. V době psaní této práce mají takový ovladač telefony Nokia 830, 730 a 735. Použití API SmartCard jsem demonstroval v praktické části vytvořením aplikace, představující APDU terminál. Funkčnost aplikace jsem ověřoval pomocí čipových karet provádějící kryptografické operace šifrování a digitální podpis. Ačkoliv jedna karta v průběhu testování přestala fungovat, 28