}w !"#$%&'()+,-./012345
MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Čtení elektronického pasu na OS Android BAKALÁŘSKÁ PRÁCE
Adam Melkus
Brno, jaro 2013
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.
Vedoucí práce: Mgr. Ing. Zdeněk Říha, Phd. ii
Poděkování Rád bych poděkoval vedoucímu své práce Mgr. Ing. Zdeňku Říhovi, Phd. za jeho rady a připomínky.
iii
Shrnutí Cílem této bakalářské práce je vytvořit mobilní aplikaci pro platformu Android, která pomocí NFC čte data z elektronického pasu. Aplikace podporuje protokol BAC a je schopná snímat údaje ze strojově čitelné oblasti pasu pomocí kamery zařízení.
iv
Klíčová slova Android, OCR, Elektronický pas, NFC, BAC
v
Obsah 1 2
3
4
5
Úvod . . . . . . . . . . . . . . . . . . . . . . . Elektronický pas . . . . . . . . . . . . . . . . 2.1 Struktura dat . . . . . . . . . . . . . . . . 2.2 Zabezpečení . . . . . . . . . . . . . . . . . 2.2.1 Pasivní autentizace . . . . . . . . 2.2.2 Aktivní autentizace . . . . . . . . 2.2.3 Základní řízení přístupu (BAC) . 2.2.4 Rozšířené řízení přístupu (EAC) 2.3 Komunikace . . . . . . . . . . . . . . . . . 2.3.1 Proces čtení . . . . . . . . . . . . Android . . . . . . . . . . . . . . . . . . . . . 3.1 Architektura . . . . . . . . . . . . . . . . . 3.1.1 Aplikace . . . . . . . . . . . . . . 3.1.2 Aplikační rámec . . . . . . . . . 3.1.3 Běhové prostředí Android . . . . 3.1.4 Knihovny . . . . . . . . . . . . . 3.1.5 Linuxové jádro . . . . . . . . . . 3.2 Verze . . . . . . . . . . . . . . . . . . . . 3.2.1 Podpora starších verzí . . . . . . 3.2.2 Near Field Communication . . . 3.3 Nástroje pro vývoj . . . . . . . . . . . . . . 3.3.1 Android SDK . . . . . . . . . . . 3.3.2 Android NDK . . . . . . . . . . . Základ aplikace . . . . . . . . . . . . . . . . . 4.1 Struktura projektu . . . . . . . . . . . . . 4.1.1 Android Manifest . . . . . . . . . 4.2 Activity (Aktivita) . . . . . . . . . . . . . 4.2.1 Životní cyklus aktivity . . . . . . 4.2.2 Fragmenty . . . . . . . . . . . . . 4.3 Service (služba) . . . . . . . . . . . . . . . 4.4 Content Provider . . . . . . . . . . . . . . 4.5 Broadcast Receiver . . . . . . . . . . . . . Aplikace Čtečka pasů . . . . . . . . . . . . . 5.1 Funkce aplikace . . . . . . . . . . . . . . . 5.1.1 Rozpoznání strojově čitelné zóny
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 2 2 3 3 3 4 5 5 8 9 9 9 9 10 10 11 11 11 12 12 12 12 13 13 14 14 14 16 16 17 17 18 18 18 vi
6
5.1.2 Čtení a komunikace s pasem 5.1.3 Ověření pasu . . . . . . . . . 5.1.4 Použité knihovny . . . . . . . 5.2 Aktivity a GUI . . . . . . . . . . . . . 5.2.1 MainActivity . . . . . . . . . 5.2.2 CameraActivity . . . . . . . . 5.2.3 SetupActivity . . . . . . . . . 5.2.4 NFCActivity . . . . . . . . . . 5.2.5 PassportActivity . . . . . . . 5.2.6 FileDisplayActivity . . . . . . 5.2.7 CertificateActivity . . . . . . 5.3 Třídy a balíky . . . . . . . . . . . . . . 5.3.1 Balík common . . . . . . . . . 5.3.2 Balík fragment . . . . . . . . 5.3.3 Balík nfc . . . . . . . . . . . . 5.3.4 Balík passport . . . . . . . . . 5.3.5 Balík passport.files . . . . . . 5.3.6 Ostatní balíky . . . . . . . . . Závěr . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
19 19 20 20 20 21 21 21 22 23 23 24 24 25 25 26 27 27 28
vii
Kapitola 1
Úvod V dnešní hektické době je neustále vkládáno veliké úsilí do zrychlování, zjednodušování i automatizace všedních a často opakovaných úkonů. Příkladem jsou elektronické pasy vybavené čipem, který nese informace o držiteli. Byly zavedeny k urychlení pomalých kontrol na hranicích. Dříve se informace z pasu musely zdlouhavě ručně přepisovat (přičemž mohlo docházet k lidským chybám), případně opticky snímat strojově čitelnou zónu. Ta ale obsahuje prostor pouze pro velmi omezené množství informací a navíc je po vydání dokladu neměnná. Díky elektronickým pasům lze poměrně rychle a automaticky ověřit jejich pravost a díky biometrickým údajům provést verifikaci osoby a ověřit, zda cestovní dokument opravdu patří osobě, která jej předkládá. Do budoucna je v plánu do pasu ukládat víza či záznamy o cestování. Moderní mobilní telefony (nazývané též jako chytré) už dávno svým majitelů neslouží pouze k telefonátům a posílání SMS. Obsahují spousty senzorů, jako je GPS čip, magnetometr, gyroskop a podobné. Mají schopnost se připojit kdykoliv a odkudkoliv, kde je signál, k internetu a lze na nich třeba i hrát plnohodnotné 3D hry. V poslední době se do těchto multifunkčních zařízení dostává technologie zvaná NFC. To umožňuje bezdrátovou komunikaci mezi dvěma aktivními přístroji nebo jenom přístrojem a pasivním čipem a anténou. Hlavní důraz je kladen na jednoduchost použití, např. přiložení telefonu k plakátu s reklamou by mělo otevřít internetový prohlížeč s načtenou stránkou s informacemi o reklamě, aniž by uživatel musel dělat něco jiného. A právě díky této technologii dostává kdokoliv, kdo vlastní nějaké zařízení s NFC čipem možnost číst různé čipové karty, které se používají už dlouhá léta. Mohou to být karty na autobus, přístupové karty a mimo jiné mezi ně patří právě i elektronický pas. Cílem této bakalářské práce bylo vytvořit aplikaci, která všem takovýmto uživatelům umožní přečíst svůj elektronický pas. Aplikaci lze nastavit tak, aby ověřovala platnost pasu díky uživatelské konfiguraci certifikátů. A pro zjednodušení procesu zadávání informací z pasu je schopná z fotografie strojově čitelné zóny opticky rozeznat všechny potřebné údaje pro šifrovanou komunikaci.
1
Kapitola 2
Elektronický pas Elektronický pas je papírový cestovní pas se speciální stránkou obsahující čip a anténu pro bezdrátovou komunikaci. V čipu jsou uloženy informace o držiteli, včetně biometrických údajů, mezi které patří zobrazení obličeje, otisky prstů případně i snímek duhovky. Veškeré specifikace a vlastnosti elektronických pasů jsou popsány ve standardu Document 9303[1], který vytvořila Mezinárodní organizace pro civilní letectví (ICAO[2]). V Evropské unii se pasy s biometrickými údaji obličeje povinně používají od roku 2006. Od roku 2009 pasy musí obsahovat i otisky prstů.
2.1 Struktura dat Kvůli mezinárodní interoperabilitě je nutná ucelená a pro všechny pasy stejná logická datová struktura. Data se ukládají do několika souborů, které jsou označeny jako DG1 až DG16. Metadata jsou uložena v souborech COM a SOD . Každý pas musí povinně obsahovat 4 základní soubory a těmi jsou COM, SOD , DG1, DG2. V COM jsou uloženy tři údaje o pasu. Verze logické datové struktury, verze Unicode kódování použitého pro uložení dat a seznam všech přítomných souborů. SOD obsahuje informace o zabezpečení, jako jsou digitálně podepsané hashe všech souborů v pasu a volitelně i certifikát podpisu. V DG1 je kopie strojově čitelné zóny, která je vytištěna na stránce s čipem. DG2 obsahuje biometrické údaje obličeje, DG3 otisky prstu a DG4 duhovky. Ostatní obsahují dodatečné informace jak o držiteli či vydavateli pasu tak pasu samotném. DG14 obsahuje veřejný klíč potřebný pro rozšířené řízení přístupu a v DG15 je uložen veřejný klíč využívaný při aktivní autentizaci
Obrázek 2.1: Logo elektronického pasu [3] 2
2. ELEKTRONICKÝ PAS
2.2 Zabezpečení Kvůli citlivosti údajů v pase a možností jejich zneužití implementují pasy řadu bezpečnostních opatření. 2.2.1 Pasivní autentizace Při pasivní autentizaci se ověřuje, zda data nebyla neoprávněně upravena a jejich pravost. Toto ověřování nevyužívá výpočetního výkonu čipu, proto se nazývá pasivní. Každý terminál,který pasy čte, musí být schopný pasivní autentizaci provést. Průběh procesu: 1.
Soubor SOD je přečten z pasu.
2.
Ze souboru se získá DS1 certifikát.
3.
Podpis souboru SOD je ověřen pomocí veřejného klíče získaného certifikátu.
4.
DS certifikát je ověřen pomocí veřejného klíče kořenového certifikátu podepisující země.
5.
Jsou přečteny všechny v pasu přítomné soubory.
6.
Spočítají se hashe přečtených souborů.
7.
Porovnají se spočítané hashe a hashe uložené v souboru SOD .
Úspěšné provedení těchto kroků zajišťuje, že data v pasu jsou autentická a nezměněná. 2.2.2 Aktivní autentizace Aktivní autentizace zabraňuje pomocí asymetrické kryptografie kopírování pasu . V čipu je uložen soukromý klíč, který z něj nelze vyčíst, a v souboru DG15 je uložen odpovídající veřejný klíč. Terminál zašle pasu náhodné číslo, pas ho dále doplní o další náhodné číslo, zašifruje pomocí soukromého klíče a pošle zpět. Terminál pak veřejným klíčem dešifruje odpověď a ověří, zda hodnoty souhlasí. Tímto se terminál přesvědčí, zdali souhlasí veřejný klíč se soukromým klíčem. Pravost veřejného klíče ze souboru DG15 se již ověřila pasivní autentizací. 1. DS - Document signer.
3
2. ELEKTRONICKÝ PAS 2.2.3 Základní řízení přístupu (BAC) Základní řízení přístupu (BAC2 ) má za úkol zabránit neoprávněnému čtení dat a odposlechu komunikace mezi pasem a terminálem. Pas odmítne přístup k datům, pokud terminál neprokáže, že je autorizován data číst. To prokazuje pomocí protokolu výzvaodpověď a znalosti informací získaných ze strojově čitelné zóny. Jakmile je terminál úspěšně autentizován, musí být veškerá následující komunikace šifrována. Nejprve se opticky nebo manuálním zadáním do terminálu získají informace ze strojově čitelné zóny. Strojově čitelná zóna má dva řádky po 44 znacích. Na prvním řádku je uveden typ dokumentu, vydávající země a jméno držitele. Na druhém řádku je číslo pasu, národnost, pohlaví, datum narození a datum platnosti pasu. Na českých pasech je zde i rodné číslo, ale toto místo může každá země využít pro jinou informaci. Za některými údaji je i jejich kontrolní součet pro detekci chyby při strojovém čtení. Základní řízení přístupu používá číslo pasu, datum narození a datum platnosti z druhého řádku. Probíhá na straně terminálu: Tyto získané údaje se zřetězí za sebe včetně jejich kontrolních součtů a spočítá se hash algoritmem SHA-1. 16 nejvýznamnějších bajtů tvoří Kseed , ze kterého se odvozují dočasné klíče pro šifrování KEN C a výpočet kontrolních součtů KM AC . KEN C (KM AC ) se vytváří zřetězením Kseed a čtyř bajtů ’00000001’ (resp. ’00000002’ pro KM AC ) a další postup je stejný jako v případě výpočtu Kseed , tj. spočítá se SHA-1 hash a 16 nejvýznamnějších bajtů tvoří KEN C (KM AC ). Po ustavení dočasných klíčů přichází na řadu vzájemná autentizace a ustavení klíčů sezení. Terminál si od pasu vyžádá pomocí příkazu GET CHALLENGE 8 bajtů náhodných dat (RNDICC ), dále pak sám vygeneruje 8 (RNDIF D ) a 16 (KIF D ) bajtů náhodných dat. Tato náhodná data zřetězí a vznikne S = RN DIF D |RN DICC |KIF D . S se zašifruje pomocí klíče KEN C algoritmem 3DES v CBC módu s nulovým inicializačním vektorem. Takto zašifrované S se nazývá EIF D . Následně se pomocí KM AC (algoritmem ISO/IEC 9797-1 MAC algorithm 3) vytvoří kontrolní součet z EIF D , MIF D . Zřetězením získáme příkazová data cmd data = EIF D |MIF D , která se pošlou pasu s příkazem INTERNAL AUTHENITICATE. Probíhá na straně pasu: Ten je dešifruje a porovná RNDICC , které poslal při příkazu GET CHALLENGE s RNDICC z dešifrovaných dat. Poté vygeneruje dalších 16 bajtů dat KICC a spočítá XOR Kseed = KIF D ⊕ KICC . Z Kseed se stejným způsobem jako při dočasných klíčích, odvodí klíče sezení KSEN C a KM AC . Dále spočítá počítadlo sekvence posílání3 tak, že se zřetězí 4 nejméně významné bajty z RNDICC a RNDIF D . Zřetězením RNDICC , RNDIF D a KICC vznikne R, které se zašifruje pomocí dočasného klíče KEN C (EICC ). Z toho se pak spočítá kontrolní součet klíčem KM AC (MICC ) a zřetězí se dohromady. Tím vznikne odpověď 2. BAC – Basic Access Control. 3. SSC – Send Sequence Counter.
4
2. ELEKTRONICKÝ PAS pro terminál resp data = EICC |MICC . Probíhá na straně terminálu: Terminál dešifruje odpověď a provede XOR Kseed = KIF D ⊕ KICC . Z něj pak odvodí klíče sezení a spočítá SSC. V tento moment, pokud vše proběhlo úspěšně, jsou ustaveny klíče pro šifrovanou komunikaci pasu a terminálu přes secure messaging.
2.2.4 Rozšířené řízení přístupu (EAC) Pro přístup k citlivým biometrickým údajům, jako je otisk prstu a duhovka, je zapotřebí lepší zabezpečení. K tomu se používá rozšířené řízení přístupu (EAC4 ) podle specifikace německé BSI[4]. Proces má dvě části. Autentizace čipu Autentizace čipu nahrazuje klíče ustavené základním řízením přístupu za silnější. Navíc se při ní implicitně ověřuje pravost čipu podobně jako při aktivní autentizaci (viz 2.2.2). Vše je totiž založeno na statickém páru klíčů uloženém v čipu. Veřejný klíč je uložený v souboru DG14 spolu s používaným algoritmem pro ustavení klíčů a soukromý klíč je uložen v zvenku nepřístupném úložišti. Autentizace terminálu Tento protokol slouží k ověření, zdali má terminál práva číst citlivá data z pasu. Musí být proveden až po autentizaci čipu. Je založen na kartou ověřitelných certifikátech5 . Terminál může obsahovat více těchto certifikátů, typicky od zemí, které mu dovolují číst citlivá data. Tento certifikát získá inspekční systém od ověřovatele dokumentů6 , to je certifikát, který je poskytován certifikační autoritou viz 2.2.
2.3 Komunikace Komunikace probíhá podle standardu ISO 14443, o tuto část se v aplikaci bude starat samotný systém Android. Na vyšší úrovni se komunikuje podle standardu ISO/IEC 78164[5] předáváním zpráv pomocí APDU7 . APDU můžou být dvojího druhu, a to Command APDU pro příkazy zasílané pasu a Responce APDU jako odpovědi.
4. 5. 6. 7.
EAC – Extended Access Control. CV - Card-Verifiable Certificate. DV - Document Verifier. APDU - Application Protocol Data Unit.
5
2. ELEKTRONICKÝ PAS
IS
Stát A
Stát B
Stát C
CVCA
CVCA
CVCA
DV
DV
DV
IS
IS
IS
IS
IS
IS
IS
IS
Obrázek 2.2: Distribuce certifikátů [6]
Command APDU Pole
Délka
Význam
CLA
1
Třída instrukcí - může indikovat, zda je použit secure messaging pro komunikaci
INS
1
Kód instrukce
P1
1
První parametr instrukce
P2
1
Druhý parametr instrukce
Lc
1 nebo 3
Počet bajtů posílaných v části data
Data
Lc
Pole bajtů obsahující data k instrukci
Le
1 nebo 3
Maximální počet bajtů v datové části odpovědi 6
2. ELEKTRONICKÝ PAS Responce APDU Pole
Délka
Význam
Data
Lr
Pole bajtů obsahující odpověď pasu. Délka může být 0 až Le z Command APDU, případně jiná, pokud pole Le nebylo specifikováno.
SW1
1
Stav provedeného příkazu
SW2
1
Upřesnění stavu provedeného příkazu (např. důvod, proč příkaz selhal)
Při komunikaci s pasem využívá Čtečka pasů jenom některé instrukce. Konkrétně to jsou: GET CHALLENGE, EXTERNAL AUTHENTICATE, SELECT FILE, READ BINARY, INTERNAL AUTHENTICATE. GET CHALLENGE Instrukce pro vygenerování náhodných osmi bajtů dat. CLA
INS
P1
P2
Le
0x00
0x84
0x00
0x00
0x08
EXTERNAL AUTHENTICATE Instrukce používaná při základním řízení přístupu jako vzájemná autentizace. CLA
INS
P1
P2
Lc
data
Le
0x00
0x82
0x00
0x00
0x28
cmd data
0x28
SELECT FILE Výběr souboru pro čtení či zápis. Používá se i při výběru aplikace pasu a v tomto případě se liší první parametr instrukce, který je 0x04 místo 0x02. Pole data obsahuje dvoubajtový identifikátor souboru. CLA
INS
P1
P2
Lc
data
0x00
0xA4
0x02
0x0C
0x02
fid
READ BINARY Příkaz pro čtení zrovna vybraného souboru (instrukce SELECT FILE musí být provedena před čtením). Maximální počet bajtů souboru, který lze pomocí této instrukce 7
2. ELEKTRONICKÝ PAS přečíst, je 256, a proto je nutné u větších souborů provést čtení několikrát. Pomocí parametrů P1 a P2 se nastavuje odsazení začátku čtení. Do pole Le se udává počet bajtů, které mají být přečteny, a v případě, že to má být maximum, je pole Le 0x00. CLA
INS
P1
P2
Le
0x00
0xB0
0x00
0x00
0x00
INTERNAL AUTHENTICATE Tento příkaz se používá při aktivní autentizaci. RNDIF D obsahuje osmibajtovou náhodnou výzvu. CLA
INS
P1
P2
Lc
data
Le
0x00
0x88
0x00
0x00
0x08
RNDIF D
0x00
2.3.1 Proces čtení Celý proces čtení se dá shrnout do několika kroků: 1.
Po přiložení pasu pošle terminál příkaz SELECT FILE, kterým zvolí aplikaci pasu.
2.
Proběhne základní řízení přístupu a ustavení klíčů pro bezpečnou komunikaci.
3.
Přečte se soubor EF.COM a z něj se určí další soubory na čtení.
4.
Přečte se soubor EF.SOD .
5.
Provede se pasivní autentizace, při níž se přečtou všechny zbývající soubory pro ověření hashů.
6.
Provede se aktivní autentizace.
8
Kapitola 3
Android Android je operační systém vyvíjený jako open source1 , založený na linuxovém jádru a navržený zejména pro mobilní zařízení. Nápad na Android vznikl v roce 2003 ve společnosti Android, Inc., ale původně byl zamýšlen jako systém pro digitální fotoaparáty. Kvůli nízké poptávce po podobných přístrojích se vývojáři rozhodli zaměřit na tvorbu softwaru pro chytré telefony. V roce 2005 společnost Android, Inc. koupil Google, pod jehož vedením je od roku 2007 operační systém Android vyvíjen konsorciem Open Handset Alliance, které zahrnuje různé softwarové a hardwarové firmy, jako je například Samsung, HTC, Qualcomm a Texas Instruments. Od svého začátku prošel Android velkou řadou změn, dnes se používá nejen v mobilních telefonech, ale i v tabletech, navigacích nebo televizích.
3.1 Architektura Architektura systému je rozdělena na 5 klíčových částí, které jsou ukázány na obrázku 3.1. 3.1.1 Aplikace Android se dodává s několika základními aplikacemi, mezi ně patří webový prohlížeč, emailový klient, mapy a jiné. Všechny tyto aplikace jsou napsány v programovacím jazyce Java. 3.1.2 Aplikační rámec Aplikační rámec je vrstva, kterou využívají vývojáři při tvorbě aplikací. Obsahuje mnoho rozšiřitelných vizuálních komponent, kterými jsou tlačítka, seznamy, textová pole a podobné. Obsahuje také různé manažery zejména Activity Manager, který se stará o životní cyklus aplikace, nebo Notification Manager umožňující zobrazení vlastních upozornění. Díky tomuto aplikačnímu rámci mají všichni vývojáři k dispozici stejné nástroje, jaké byly použity při vývoji již vestavěných aplikací zmíněných v předchozím bodě. 1. Open source - software s otevřeným zdrojovým kódem.
9
3. ANDROID
Obrázek 3.1: Diagram architektury systému Android [7] 3.1.3 Běhové prostředí Android Běhové prostředí zahrnuje DVM2 a základní knihovny jazyku Java. DVM je, podobně jako JVM3 , virtuální stroj pro spouštění Java byte-kódu4 . Při použití v Androidu je tento byte-kód dále optimalizován pomocí nástroje ”dx” pro co nejmenší paměťovou náročnost. Jelikož je každá aplikace spouštěna ve vlastní instanci DVM, je na rozdíl od standardního JVM optimalizován pro použití na mobilních zařízeních s omezeným výkonem a výdrží. 3.1.4 Knihovny Součástí systému je několik nativních knihoven napsaných v jazycích C/C++. Jsou využívány v různých částech operačního systému a vývojář k nim přistupuje pomocí aplikačního rámce. Je to například knihovna pro vykreslování 2D/3D grafiky nebo mul2. DVM – Dalvik Virtual Machine. 3. JVM – Java Virtual Machine. 4. Java byte-kód - mezikód, který vzniká kompilací zdrojového kódu Javy nebo jiného programovacího jazyka.
10
3. ANDROID timediální knihovny pro přehrávání hudby a videa. 3.1.5 Linuxové jádro Android je postaven na linuxovém jádře verze 2.6. a používá ho pro síťovou komunikaci, správu paměti a procesů. Jádro obsahuje všechny nezbytné hardwarové ovladače a slouží jako abstraktní vrstva mezi hardwarem a softwarem.
3.2 Verze Kvůli velmi rychlému vývoji se od první verze vydané v roce 2008 objevilo velké množství aktualizací. S každou aktualizací přibývaly do systému nové funkce a opravy chyb. Všechny zásadní verze bývají pojmenovány po dezertech. V době psaní této práce byla nejrozšířenější verze Gingerbread(2.3.3-7). Eclair
Other
1.7%
0.1% Jelly Bean
Froyo
25%
4%
25%
Gingerbread 39.7%
39.7% Ice Cream Sandwich 29.3%
29.3%
Honeycomb 0.2%
Obrázek 3.2: Graf rozšíření jednotlivých verzí [8]
3.2.1 Podpora starších verzí Verze Gingerbread byla vydána již na začátku roku 2011 a kvůli podpoře co největšího množství zařízení vytváří různé skupiny vývojářů, včetně Google, podpůrné knihovny, které zpřístupňují funkce z novějších verzí systému. Za zmínku rozhodně stojí knihovna Support Library od Google. Přináší zejména nové komponenty používané v nových verzích pro usnadnění vývoje jako například fragmenty, ViewPager a jiné. 11
3. ANDROID 3.2.2 Near Field Communication NFC je sada technologií umožňující bezdrátovou komunikaci na krátké vzdálenosti. Typicky se jedná o vzdálenost do 4 centimetrů. Používá se pro výměnu malého množství informací mezi aktivním zařízením a pasivním, jako je například elektronický pas, nebo mezi dvěma aktivními zařízeními. Typickým případem užití jsou bezkontaktní transakce, kdy zákazník příloží telefon podporující NFC k platebnímu terminálu a zaplatí nákup. Používá se třeba i ke konfiguraci připojení mezi dvěma přístroji pro přenos dat. V Androidu se tato funkce nazývá Android Beam, jež pomocí NFC provádí nastavení připojení bluetooth, přes které se následně přenese požadovaný soubor. NFC a Android Podpora NFC se objevila poprvé právě v nejrozšířenější verzi 2.3.3. Aplikace Čtečka pasů bude podporovat všechna zařízení, která budou obsahovat NFC čip a anténu, od této verze výše. Android nabízí podporu několika bezdrátových technologií. Pro účely této práce bude použit standard ISO 14443-4 jako přenosový protokol používaný elektronickými pasy.
3.3 Nástroje pro vývoj 3.3.1 Android SDK Android SDK5 je kolekce nástrojů pro vývoj mobilních aplikací. Je složen hlavně z integrovaného vývojového prostředí Eclipse se zásuvným modulem, který přidává funkce specifické pro Android. Dále obsahuje program DDMS pro ladění a emulátor Android zařízení pro testovací provoz aplikace. S každou novou verzí Androidu vychází i nové SDK, které je aktualizováno o podporu nových funkcí. Součástí bývají i praktické ukázky použití přidaných vlastností systému. 3.3.2 Android NDK NDK6 slouží k implementaci některých částí aplikace pomocí jazyků C nebo C++. Jedná se hlavně o části, které potřebují co největší výkon procesoru, těmi jsou například složité výpočty (simulace fyziky). Čtečka pasů bude NDK využívat k překladu knihovny tesseract-ocr[11], která slouží pro rozpoznání textu z obrázků.
5. SDK – Software Development Kit. 6. NDK – Native Development Kit.
12
Kapitola 4
Základ aplikace Tato kapitola popisuje základ vývoje aplikací pro platformu Android.
4.1 Struktura projektu Při vytvoření nového projektu získá vývojář vygenerovanou adresářovou strukturu, která je vidět na obrázku 4.1.
Obrázek 4.1: Struktura nového projektu •
src - Adresář obsahující veškeré zdrojové kódy aplikace, které bývají rozděleny ještě do podsložek (balíků).
•
gen - Obsahuje vygenerované soubory, zejména R.java sloužící jako seznam všech zdrojů aplikace.
•
assets - Adresář se soubory, které jsou obsaženy ve výsledném apk balíku aplikace.
•
bin - Adresář obsahující přeložené třídy a zabalenou aplikaci ve formátu apk.
•
libs - Do tohoto adresáře se vkládají potřebné externí knihovny. 13
4. ZÁKLAD APLIKACE •
res - Zde se nachází všechny zdroje aplikace, patří mezi ně obrázky, rozvržení grafického rozhraní, lokalizační texty apod.
•
AndroidManifest.xml - XML soubor obsahující nastavení aplikace.
4.1.1 Android Manifest Tento soubor je pro aplikaci velice důležitý. Musí zde být uvedeny všechny komponenty (viz 4.2), které aplikace obsahuje, a jejich filtry záměrů (specifikace akcí, jež je aktivita schopna zpracovat). Další nutnou položkou v manifestu je základní konfigurace, tj. název kořenového balíku, v němž jsou zdrojové kódy, název a verze aplikace a jiné. Když bude program vyžadovat připojení k internetu nebo přístup k informacím o kontaktech, musí to být v manifestu zapsáno pomocí značky <uses-permission />. Volitelně lze použít i značku <uses-feature />, kam se zapisují speciální požadavky na hardware a software zařízení, na kterém by měla aplikace běžet. Zamezuje to případům, kdy je aplikace instalována a spouštěna na nekompatibilních přístrojích. Manifest může obsahovat pochopitelně více nastavení, jejich kompletní seznam lze najít třeba na oficiálních stránkách systému Android [10].
4.2 Activity (Aktivita) Android SKD obsahuje velké množství různých komponent, ze kterých se pak aplikace skládá. Za hlavní se dá považovat aktivita. Ta reprezentuje jednu obrazovku s uživatelským rozhraním. Aplikace musí obsahovat alespoň jednu aktivitu, ale většinou jich obsahuje více. Jsou na sobě navzájem nezávislé a to má za výsledek, že jedna aktivita může spustit jakoukoliv jinou. Myslí se tím i aktivity z jiných aplikací (pokud to daná aplikace dovoluje). Vlastní aktivity vývojář vytváří rozšířením třídy Activity a implementací metod, které systém volá v různých fázích životního cyklu aktivity. 4.2.1 Životní cyklus aktivity Aktivita se může nacházet ve třech stavech. Ty jsou následující: •
Spuštěná - Nachází se na popředí, uživatel se dívá právě na ni a může s ní pracovat.
•
Pozastavená - Částečně ji překrývá jiná aktivita. Nicméně je pořád plně načtená a udržovaná v paměti. Rozdíl mezi touto a spuštěnou aktivitou je ten, že uživatel zrovna interaguje se spuštěnou. Může být vypnuta systémem v případě, že má velmi málo paměti.
•
Zastavená - Tato aktivita je plně překryta jinou aktivitou, je pořád načtená v paměti, jen se už nezobrazuje, je tzv. na pozadí. Může být systémem vypnuta, pokud bude mít málo paměti. 14
4. ZÁKLAD APLIKACE Mezi jednotlivými stavy volá systém odpovídající metody (viz diagram 4.2), které dle vlastních požadavků implementuje vývojář. Všechny musí obsahovat volání odpovídající metody jejich nadřazené třídy.
Aktivita spuštěna
onCreate() Uživatel se vrací k aktivitě
onStart()
onRestart()
onResume()
Proces aplikace byl zrušen
Aktivita běží Jiná aktivita přešla do popředí Uživatel se vrátil k aktivitě
Aplikace s vyšší prioritou potřebují paměť
onPause() Aktivita už není zobrazena
Uživatel se vrací k aktivitě
onStop()
Aktivita končí nebo byla ukončena systémem onDestroy()
Aktivita vypnuta
Obrázek 4.2: Diagram životního cyklu aktivity [12] Při spuštění aktivity se jako první volá onCreate(). Zde by mělo být inicializováno grafické rozhraní aplikace, načítání dat a podobně náročné operace. Těsně před zobrazením aktivity uživateli je volána metoda onStart(). Dále následuje onResume(), ta se spouští v momentě, kdy už je aktivita zobrazena, ale ještě před tím, než s ní začne uživatel pracovat. Když do popředí přejde dialog nebo jiná aktivita a částečně překryje tu stávající, je zavolána funkce onPause(). Zde je vhodné vypnout probíhající animace, případně 15
4. ZÁKLAD APLIKACE uložit neuložená data. V případě, že stávající aktivitu kompletně překryje jiná, je spuštěna metoda onStop(). Před úplným ukončením aktivity se volá onDestroy(). Tato situace může nastat, když ji ukončuje systém pro uvolnění zdrojů, nebo v případě, že na ní byla zavolána metoda finish(). 4.2.2 Fragmenty Fragment je komponenta sloužící, podobně jako aktivita, k zobrazení a ovládání uživatelského rozhraní. Nicméně na fragment se lze dívat spíše jako na ”podaktivitu”. Aktivita v sobě může obsahovat více fragmentů, přičemž každý z nich zobrazuje jinou část rozhraní a dat. Dobře je to ilustrováno na obrázku 4.3. Podpora fragmentů byla přidána ve verzi 3.0, která byla koncipována k použití na tabletech a zařízeních s větší plochou obrazovky. Fragmenty poskytují větší flexibilitu při návrhu uživatelského rozhraní. Umožňují zobrazit stejný obsah v různých formách bez zbytečných redundancí ve zdrojových kódech. Vzhledem k velmi dobré použitelnosti a k tomu, že Google považuje fragmenty za budoucnost vývoje aplikací pro Android, se Google rozhodl k podpoře všech starších verzí systému (viz 3.2.1).
Obrázek 4.3: Ilustrace použití fragmentů [9]
4.3 Service (služba) Služba se velmi podobá aktivitě. Na rozdíl od ní však celou dobu běží na pozadí a nemá uživatelské rozhraní. Používá se k provádění dlouhotrvajících operací, které nevyžadují 16
4. ZÁKLAD APLIKACE interakci od uživatele, například přehrávání hudby nebo stahování nových dat z internetu. Službu může spustit třeba aktivita a ta následně běží nezávisle, nebo s aktivitou komunikuje.
4.4 Content Provider Content provider slouží k přístupu k informacím uložených v zařízení. Může to být například lokální SQL databáze, kam si aplikace ukládá svoje data, nebo třeba sdílená data jiných aplikací. Aplikace může číst informace o kontaktech, výpisy hovorů nebo SMS zprávy. Pochopitelně pouze v případě, že tyto požadavky jsou uvedeny v manifestu.
4.5 Broadcast Receiver Úkolem komponenty Broadcast Receiver je zaznamenávat a zpracovávat hlášení. Hlášení mohou být posílána buď systémem nebo aplikací. Typickou ukázkou hlášení je příchozí SMS zpráva. Pokud si aplikace zaregistruje Broadcast Receiver na zpracování hlášení o nové SMS zprávě, je implementace této třídy spuštěna vždy, když přijde nová zpráva. Vzhledem k tomu, že na jedno hlášení může být registrováno více různých komponent Broadcast Receiver, musí být zpracování co nejjednodušší a nejrychlejší, ať se nezpomaluje systém. Pokud by zpracování vyžadovalo více času, může být spuštěna například služba, která provede potřebné operace.
17
Kapitola 5
Aplikace Čtečka pasů Čtečka pasů je aplikace pro čtení, verifikaci a zobrazení informací z elektronických pasů. Je schopná po zadání několika údajů z pasu, ať už manuálně nebo fotoaparátem zařízení, pomocí bezdrátových technologií NFC vyčíst téměř všechny uložené informace, včetně fotografie držitele pasu.
5.1 Funkce aplikace Funkcionalita se skládá z několika základních částí: •
5.1.1 Rozpoznání strojově čitelné zóny
•
5.1.2 Čtení a komunikace s pasem
•
5.1.3 Ověření pasu
5.1.1 Rozpoznání strojově čitelné zóny Pro získání údajů z pasu nutných pro základní řízení přístupu a komunikaci s pasem (viz 2.2.3) může uživatel použít fotoaparát svého zařízení. Potřebné údaje se nachází ve strojově čitelné zóně, která je vyznačená na obrázku 5.1. Pro snadnější optické rozpoznání je text v této oblasti psán speciálním fontem vyvinutým právě k těmto účelům. Funkci extrakce informací aplikaci poskytuje open source OCR1 knihovna tesseract-ocr. V letech 1994 a 1995 byla vytvořena společností Hewlett Pacard jako software do skenerů, nicméně ji nikdy nepoužili v žádném ze svých produktů a v roce 2005 byly zdrojové kódy otevřeny veřejnosti. Knihovna je schopná rozpoznat velké množství jazyků a fontů a lze ji naučit i další. Vzhledem k omezenému počtu znaků, které může strojově čitelná zóna obsahovat, by bylo zbytečné používat již existující balíky určené pro rozeznávání celého jazyka včetně speciálních znaků. V rámci této bakalářské práce byl vytvořen balík k rozpoznání znaků strojově čitelné zóny. Na rozdíl od původního anglického balíku, který má velikost okolo 12MB, je velikost nově vytvořeného balíku pouze něco přes 315KB. 1. OCR - optical character recognition.
18
5. APLIKACE ČTEČKA PASŮ
Obrázek 5.1: Strojově čitelná zóna [13] 5.1.2 Čtení a komunikace s pasem Další funkcí aplikace je komunikace s pasem. Ta probíhá bezdrátově pomocí NFC. Při jednom čtení se vždy přečte kompletně celý pas nebo alespoň ty části, které jsou čitelné. Aplikace s pasem prvně ustaví klíče sezení podle protokolu BAC, pomocí kterých je šifrována veškerá následná komunikace. Dále z pasu vyčte soubor EF.COM, který obsahuje seznam všech ostatních souborů, které se v pasu nachází. Poté postupně načítá zbývající soubory. O postupu komunikace aplikace informuje indikátorem a textovým popisem zrovna probíhající operace. Některé soubory dokáže aplikace převést a zobrazit v lidsky čitelné formě, jiné pak ukáže pouze zakódované. 5.1.3 Ověření pasu Po vyčtení veškerých informací následuje ověření pasu. Jako první se provádí pasivní autentizace, kdy se ověřuje certifikát v pasu vůči kořenovému certifikátu vydávající země. Následně se ověřuje, jestli jsou hashe souborů stejné jako hashe uložené v souboru EF.SOD s bezpečnostními informacemi (viz 2.2.1). Aplikace umožňuje uživateli importovat vlastní soubory s kořenovými certifikáty vydávajících autorit. Pokud je uživatel nenačte, aplikace bude fungovat normálně, jenom nebude schopná ověřit platnost dat v pasu a bude to indikovat graficky při zobrazení obsahu pasu. Po provedení pasivní autentizace následuje ověření, zdali se nejedná o klon pasu pomocí aktivní autentizace (popsáno viz 2.2.2), při které probíhá další komunikace mezi zařízením a pasem, proto musí být stále v blízkém kontaktu. 19
5. APLIKACE ČTEČKA PASŮ 5.1.4 Použité knihovny Aplikace využívá několika externích knihoven. Nejdůležitější pro správnou funkčnost je knihovna Spongy Castle[14], která je modifikací původního projektu Bouncy Castle[15] pro správné fungovaní v systému Android. Jedná se o soubor kryptografických tříd a funkcí, které Čtečka pasů potřebuje pro komunikaci s pasem a ověřování certifikátů. Další důležitou součástí je JMRTD[16], volně přístupná knihovna pro komunikaci se strojově čitelnými cestovními dokumenty. Je použita pro dekódování souboru EF.SOD a částečně pro dekódování bitmap uložených v pasu. O to se hlavně stará knihovna jj2000[17], ale pouze v případě, že je bitmapa ve formátu JPEG 2000, jinak se provádí pomocí vestavěných funkcí systému Android. Vzhledem k podpoře velkého množství různých verzí operačního systému a jejich často velmi rozdílným vzhledům, byl zvolen projekt HoloEverywhere[18] jako základ stylu grafického rozhraní aplikace. Použitím této knihovny bude mít aplikace ucelený vzhled na všech zařízeních. Holo je název pro styl rozhraní aplikace, který Google začal prosazovat od verze 3.0 a pokračuje ve vývoji až do dnes. Tímto získala platforma ucelený vzhled, nicméně verze starší než 3.0 oficiálně nejsou podporovány. To byl důvod vzniku projektu HoloEverywhere, díky kterému je nyní možné využívat těchto stylů i tam, kde nejsou oficiálně dostupné. Kvůli funkcionalitě importu certifikátu využívá aplikace knihovny aFileChooser[19]. V případě, že uživatel nemá nainstalovanou žádnou aplikaci pro správu souborů, lze pro výběr použít právě této komponenty. Její použití proto není pro uživatele povinné.
5.2 Aktivity a GUI Jak bylo již zmíněno, aktivita je základní stavební částí aplikace pro Android. Čtečka pasů se skládá z 8 aktivit, z toho jedna je abstraktní. Všechny ostatní aktivity jsou podtřídy právě této aktivity. Sama proto nemá žádné uživatelské rozhraní. Nazývá BaseActivity a obsahuje nastavení NFC modulu a detekce přiložení pasu k zařízení. 5.2.1 MainActivity Při spuštění aplikace se uživateli jako první zobrazí MainActivity. Zde má na výběr z několika možností (obrázek 5.2). Může načíst nový pas, zkusit přečíst již uložený (funguje pouze v případě, že je již nějaký uložený, jinak se zobrazí upozornění o absenci informací) nebo spravovat certifikáty. Dále je tu funkce vymazání uložených dat aplikace pro uživatele, kteří si nepřejí, aby byly uchovány jakékoliv informace o pasu. Ihned po startu této aktivity se vytvoří úkol, který začne na pozadí načítat všechny certifikáty ze složky ”PassportReader/certificates” na externím úložišti zařízení. 20
5. APLIKACE ČTEČKA PASŮ
Obrázek 5.2: Úvodní obrazovka
Obrázek 5.3: Přidání nového pasu
5.2.2 CameraActivity Při prvním naběhnutí této aktivity se ukáže jednoduchý návod na použití fotoaparátu pro zadání základních informací z pasu. Po přečtení návodu se uživatel rozhodne, zda chce využít možnosti použití fotoaparátu nebo zda základní informace z pasu zadá raději ručně (obrázek 5.3). Pokud zvolí ”Spustit fotoaparát”, otevře se aplikace kamery. Po vyfocení pasu se spustí aplikace Galerie, kde uživatel ořízne strojově čitelnou zónu. Po následném rozpoznání znaků je provedeno přesměrování na aktivitu pro kontrolu údajů, kam se dá dostat přímo zvolením možnosti ”Vložit informace ručně”. 5.2.3 SetupActivity Obrazovka na obrázku 5.4 slouží k zadání údajů z pasu. Uživatel zde musí vyplnit číslo pasu, datum narození a datum platnosti. V případě, že jsou již nějaké informace uloženy z předchozích čtení, předvyplní se do formuláře automaticky. Totéž platí v momentě, kdy bylo použito rozpoznání z fotografie. Neprobíhá zde žádná validace zadaných údajů. Pokud by byly chybné, uživatel na to bude upozorněn při čtení pasu. Opravit je pak může návratem do této aktivity. 5.2.4 NFCActivity V této aktivitě se po přiložení pasu spustí nové vlákno, které jej začne postupně číst. Po dobu vykonávání procesu se zobrazují aktuální informace o zrovna prováděné akci na indikátoru průběhu. Úkon čtení se dělí na tři rozlišitelné části. Při první (”Probíhá komunikace s pasem...”) probíhá základní řízení přístupu a ustavení klíčů sezení. Druhá část (”Načítání souboru”) popisuje průběh načítání jednotlivých souborů. V poslední části (”Ověřování pasu”) pak probíhá aktivní a pasivní autentizace. 21
5. APLIKACE ČTEČKA PASŮ
Obrázek 5.4: Nastavení údajů z pasu
Obrázek 5.5: Čtení pasu
Obrázek 5.6: Zobrazení pasu horní část
Obrázek 5.7: Zobrazení pasu spodní část
5.2.5 PassportActivity Jakmile proběhne přečtení a ověření pasu, aplikace automaticky přesměruje uživatele na stránku s vyčtenými informacemi (obrázky 5.6 a 5.7). Jako první uvidí portrét držitele a několik základních údajů o něm. Všechny byly získány ze souboru EF.DG1, který má stejný obsah jako strojově čitelná zóna na stránce s čipem. Dále se pod nimi nachází indikátory platnosti dat (pole ”Podpis platný” je relevantní pouze v případě, že uživatel importoval odpovídající kořenový certifikát) a seznam souborů. Ten je tvořen několika (počet závisí na obsahu pasu) tlačítky s názvem souboru. Každé z těchto tlačítek otevře aktivitu FileDisplayActivity. V případě, že se nějaký soubor nenačetl, objeví se vedle názvu ještě nápis ”nečten”, aby uživatel neočekával otevření souboru. 22
5. APLIKACE ČTEČKA PASŮ
5.2.6 FileDisplayActivity Aktivita je určená pro vypsání obsahu souboru. Jako jediná v celé aplikaci využívá fragmenty (viz 4.2.2). Je díky tomu schopná relativně jednoduše zobrazovat různě formátované informace. Podle souboru, který má ukázat vybere odpovídající fragment. Implementovány jsou momentálně fragmenty pro následující soubory: COM, DG1, DG2, SOD . Pro jakýkoliv jiný soubor je použit fragment GeneralFragment a ten ukáže jenom značku a zakódovaný obsah. 5.2.7 CertificateActivity
Obrázek 5.8: Ukázka souboru COM
Obrazovka na obrázku 5.9 slouží pro správu certifikátů používaných pro verifikaci pasu. Uživatel má možnost pomocí svého oblíbeného prohlížeče souborů vybrat certifikáty, které chce importovat do aplikace. V případě, že nemá nainstalovaný žádný podobný program, poskytuje Čtečka pasů vlastní vestavěný prohlížeč (obrázek 5.10). Certifikátu se při jeho výběru zkopíruje z původního umístění do úložiště aplikace, do složky ”PassportReader/certificates”, odkud už se automaticky načítají všechny přítomné certifikáty. Ty lze i mazat. Při označení jedné a více položek se tlačítko v pravém horním rohu změní z ”importovat certifikát” na ”smazat”. Záznamy jsou organizovány pomocí komponenty ListView a textový popis má tvar: ”vydávající země”, ”začátek platnosti”.
Obrázek 5.9: Seznam certifikátů
Obrázek 5.10: Vestavěný prohlížeč souborů
23
5. APLIKACE ČTEČKA PASŮ
5.3 Třídy a balíky Zdrojový kód je rozdělen do následujících balíků: •
cz.muni.fi.android.passportreader.activity všechny aktivity (obsah toho balíku byl již popsán v 5.2, proto v této sekci bude přeskočen)
•
cz.muni.fi.android.passportreader.common pomocné třídy, konstanty a třídy pro nastavení aplikace
•
cz.muni.fi.android.passportreader.fragment třídy fragmentů pro zobrazení souborů
•
cz.muni.fi.android.passportreader.nfc třídy obstarávající komunikaci s pasem
•
cz.muni.fi.android.passportreader.passport entitní třída pasu a pomocné třídy pro čtení a ověření pasu
•
cz.muni.fi.android.passportreader.passport.files třídy pro dekódování souborů z pasu
5.3.1 Balík common Tento balík obsahuje převážně třídy s pomocnými metodami nebo uchovávající nějaká statická data. AppSettings.java Poskytuje několik metod pro ukládání a čtení nastavení aplikace. Jako úložiště používá SharedPreferences[20]. Ostatní metody slouží pro získávání cest k úložišti dat a certifikátů. MRZParser.java Třída na parsování řetězce ze strojově čitelné zóny. Pokud dostane na vstupu nepřesný formát MRZ, pokusí se jej částečně opravit. OCRTask.java Třída provádějící rozpoznání textu z obrázku na vedlejším vlákně. ReadingProgressListener.java Rozhraní pro upozornění na změnu stavu při čtení souborů. CountryCode.java Převod kódů zemí do formátů podle jiných standardů. Využívá ji PassportActivity 24
5. APLIKACE ČTEČKA PASŮ pro lokalizované zobrazení jména země. CryptoHelper.java Obsahuje pomocné funkce k získání klíčů sezení a jiných hodnot potřebných při komunikování a ověřování pasu. Ostatní třídy Ostatní třídy obsahují často užívané statické metody nebo konstanty. 5.3.2 Balík fragment Obsahem jsou implementace fragmentů jednotlivých souborů. Každý z nich obsahuje různé informace a tyto fragmenty umožní zobrazení různě formátovaných dat v jedné aktivitě. Úkolem je vyplnění obsahu souboru do uživatelského rozhraní. Jsou zde 4 třídy DG1Fragment, DG2Fragment, EFCOMFragment a EFSODFragment. Pro všechny ostatní soubory se použije třída GeneralFragment. 5.3.3 Balík nfc Zde se nachází veškeré třídy nezbytné pro bezdrátovou komunikaci s pasem. CommandAPDU.java Jedná se o entitní třídu obalující několik bajtových hodnot, její význam je hlavně ve zjednodušení manipulace s příkazovým APDU (viz 2.3). Hlavní metodou je getBytes(), která vrací pole bajtů se zakódovaným příkazem. ResponceAPDU.java Tato třída, podobně jako předchozí, zjednodušuje manipulaci s APDU. Na rozdíl od CommandAPDU však slouží k práci s odpovědí pasu, která je jednodušší (viz 2.3). Třída ResponceAPDU má metody pro získání odpovědního kódu a přijatých dat, který vrací jako pole bajtů. SecureMessaging.java Třída SecureMessaging se inicializuje po provedení základního řízení přístupu pomocí klíčů sezení počítadla sekvence posílání. Poté má za úkol šifrovat příkazové APDU a dešifrovat APDU odpovědí. To provádí pomocí metod wrap() a unwrap(). NfcService.java Tato třída obstarává veškerou komunikaci, co s pasem probíhá. Přenos dat do a z pasu provádí metodou transceive(), která na vstupu dostane objekt třídy CommandAPDU. Ten, pokud už byl inicializován objekt SecureMessaging, je zašifrován a odeslán do pasu. Pro samotné posílání zpráv je využita třída z Android SDK, konkrétně IsoDep a její metoda transceive(). Jako odpověď se vrátí pole bajtů, z kterého se vytvoří objekt 25
5. APLIKACE ČTEČKA PASŮ třídy ResponceAPDU a, stejně jako v případě příkazu, se nyní dešifruje. Při chybě se vytvoří odpovídající výjimka, která je zpracována ve vyšších vrstvách programu. CommunicationException.java CommunicationException je pomocná výjimková třída pro identifikaci důvodu selhání komunikace. Je vytvořena, když návratový kód z pasu neodpovídá úspěšně provedené operaci (tj. 9000).
5.3.4 Balík passport Balík obsahuje třídy pro práci s certifikáty a pasem a dále taky třídu pro řízení procesu čtení a verifikace pasu. CertificateFile.java a CertificateLoader.java Hned při startu aplikace se spustí načítání certifikátů z úložiště zařízení. Probíhá na vedlejším vlákně, aby neblokovala uživatelské rozhraní. O administraci vlákna a aktualizace certifikátů se stará singleton2 CertificateLoader. Prohledává předem určenou složku a z nalezených souborů s certifikáty vytváří instance třídy CertificateFile. Ta zapouzdřuje objekt certifikátu a souboru, ze kterého byl vytvořen. Třída existuje kvůli zjednodušení organizace a zobrazení certifikátů. Implementuje metodu toString(), kterou využívá ListView pro zobrazování názvů objektů ve svém adaptéru. PassportManager.java Zastřešuje čtení pasu. Využívá rozhraní třídy NfcService. Nejprve se provede BAC, následně se přečte soubor COM, ze kterého se získá seznam přítomných souborů. Dále se přečte SOD , a poté postupně všechny ostatní ze získaného seznamu. Pak přichází na řadu ověřování pravosti pasu. Ze souboru SOD se získá certifikát a jeho podpis se následně ověřuje vůči kořenovým certifikátům načteným třídou CertificateLoader. Pak se ze stejného souboru získají hashe ostatních souborů v pasu a ty se porovnají s aktuálně spočítanými hashi. Pokud je certifikát platný a hashe si odpovídají, tak byla úspěšně provedena pasivní autentizace. Další ověření se nazývá aktivní autentizace 2.2.2, při té probíhá další komunikace s pasem. Jestli se v celém procesu nevyskytla žádná chyba, je vytvořena instance třídy Passport a ta je předána do aktivity zobrazující pas. Passport.java Jedná se o jednoduchou entitní třídu, která v sobě pouze nese všechny načtené soubory. Taktéž nese svou vlastní instanci ve statické proměnné pro udržení dat při přepínání aktivit.
2. Singleton - návrhový vzor, používá se když je v celém programu potřeba jenom jedna instance dané třídy.
26
5. APLIKACE ČTEČKA PASŮ 5.3.5 Balík passport.files Tento balík obsahuje entitní třídy pro jednotlivé soubory. Dalším jejich úkolem je přečíst vstupní proud souboru a získat z něj lidsky čitelné informace. Pokud není implementována třída pro nějaký soubor, je použita obecná třída DataGroup. DataGroup.java Z této třídy dědí všechny ostatní souborové třídy. Při své inicializaci dostává na vstup instanci InputStream, ze které získá značku souboru a jeho délku. O zbytek čtení se starají podtřídy. FileTag.java FileTag je výčtový typ obsahující konstantní údaje o souborech. Každá položka si uchovává značku, id, číslo a jméno. Číslo a jméno je odvozeno z id. 5.3.6 Ostatní balíky Ostatní balíky byly vybrány a překopírovány z projektu JMRTD. Jde o třídu SODFile pro parsování souboru EF.SOD , ostatní jsou jen třídy, které potřebuje ke správnému fungování.
27
Kapitola 6
Závěr Cílem této bakalářské práce bylo vytvořit mobilní aplikaci pro platformu Android. Tato aplikace měla umožnit uživateli přečíst elektronický pas pomocí technologie NFC. Pasivní a aktivní autentizací pak ověřit, zda se nejedná o falešný dokument. Dále měla být schopná opticky snímat strojově čitelnou zónu pasu a rozpoznat z ní informace potřebné pro základní řízení přístupu. Výsledkem je aplikace podporující systém Android od verze 2.3.10, která poskytuje požadovanou funkcionalitu. Verifikaci pasu provádí na základě certifikátů, které si uživatel sám opatří a importuje. Rozpoznání strojově čitelné zóny provádí pomocí externí knihovny tesseract-ocr, nabízí však i manuální zadávání. Na rozdíl od některých již dostupných aplikací funguje i na novějších pasech. Byla testována na pasech typu A10, A12 vydaných v letech 2011 a 2012. Do budoucna by bylo vhodné rozšířit aplikaci o podporu protokolu rozšířeného řízení přístupu, jehož implementace v zadání byla uvedena jako volitelná, zkompletovat třídy pro dekódování a zobrazování jednotlivých souborů z pasu namísto použití tříd GeneralFragment a DataGroup.
28
Literatura [1] Doc 903 Machine Readable Travel Documents. ICAO [online]. 2006 [cit. 2013-05-11]. Dostupné z:
[2] International Civil Aviation Organization. ICAO [online]. 2013 [cit. 2013-05-11]. Dostupné z: [3] International symbol for biometric passports. Wikimedia Commons [online]. 2013 [cit. 2013-05-18]. Dostupné z: [4] Advanced Security Mechanisms for Machine Readable Travel Documents – Extended Access Control (EAC). Bundesamtes für Sicherheit in der Informationstechnik [online]. 2012 [cit. 2013-05-12]. Dostupné z: [5] ISO/IEC 7816-4 (first edition 1995-09-01). [online]. 1995 [cit. 2013-05-12]. Dostupné z: [6] Basic Access Control and Extended Access Control in ePassports. KINNEGING, Tom. ICAO [online]. [cit. 2013-05-18]. Dostupné z: [7] App Framework — Android Developers ANDROID DEVELOPERS. Android developers [online]. 2013 [cit. 2013-05-05]. Dostupné z: [8] Dashboards — Android Developers ANDROID DEVELOPERS. Android developers [online]. 2013 [cit. 2013-04-30]. Dostupné z: [9] Fragments — Android Developers ANDROID DEVELOPERS. Android developers [online]. 2013 [cit. 2013-05-05]. Dostupné z: [10] The AndroidManifest.xml File — Android Developers ANDROID DEVELOPERS. Android developers [online]. 2013 [cit. 2013-05-06]. Dostupné z: 29
[11] tesseract-ocr An OCR Engine that was developed at HP Labs between 1985 and 1995. 2013 [cit. 2013-05-05]. Dostupné z: [12] Managing the Activity Lifecycle — Activities ANDROID DEVELOPERS. Android developers [online]. 2013 [cit. 2013-05-05]. Dostupné z: [13] Date page of Czech passport in 2006 Wikimedia Commons [online]. 2013 [cit. 201305-18.] Dostupné z: [14] Spongy Castle by rtyley. [online]. 2013 [cit. 2013-05-07]. Dostupné z: [15] The Legion Of The Bouncy Castle Java Cryptography APIs. The Legion Of The Bouncy Castle [online]. 2013 [cit. 2013-05-07]. Dostupné z: [16] JMRTD: An Open Source Java Implementation of Machine Readable Travel Documents. [online]. 2013 [cit. 2013-05-07]. Dostupné z: [17] jj2000 - A pure Java JPEG 2000 image codec [online]. 2013 [cit. 2013-05-07]. Dostupné z: [18] HoloEverywhere [online]. 2013 [cit. 2013-05-07]. Dostupné z: [19] aFileChooser - Android File Chooser [online]. 2013 [cit. 2013-05-07]. Dostupné z: [20] Storage Options — ANDROID DEVELOPERS. Android developers [online]. 2013 [cit. 2013-05-08]. Dostupné z:
30
Příloha K práci je přiloženo CD se spustitelnou verzí aplikace. Obsahuje také zdrojové kódy včetně všech potřebných knihoven.
31
