Analýza čipových karet pomocí přípravku Proxmark III

Transkript

1 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA INFORMAČNÍCH TECHNOLOGIÍ KATEDRA POČÍTAČOVÝCH SYSTÉMŮ Diplomová práce Analýza čipových karet pomocí přípravku Proxmark III Bc. Tomáš Altman Vedoucí práce: Ing. Jiří Buček 1. května 2012 i

2 ii

3 Poděkování Děkuji velmi panu Ing. Jiřímu Bučkovi za jeho odborné konzultace, trpělivost, návrhy a připomínky, které mi umožnily dovést mou práci k úspěšnému zakončení. iii

4 iv

5 Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V Praze dne 1. května 2012 v

6 vi

7 České vysoké učení technické v Praze Fakulta informačních technologií 2012 Tomáš Altman. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Tomáš Altman. Analýza bezpečnosti čipových karet pomocí přípravku Proxmak3: Diplomová práce. Praha: ČVUT v Praze, Fakulta informačních technologií, vii

8 viii

9 Abstrakt Práce se zabývá problematikou bezpečnosti vybraných čipových karet. V první části je proveden základní popis zkoumaných typů bezkontaktních čipových karet a komunikačního protokolu užívaného při komunikaci mezi kartou a čtečkou. Dále je obsažen popis RFID zařízení Proxmark III, které bylo použito pro vyhodnocení bezpečnosti. Součástí práce je i rozšíření firmwaru a stávající funkčnosti přípravku. V poslední části jsou prezentovány závěry zkoumání čipových karet s možnými návrhy na zlepšení bezpečnosti i budoucího vývoje přípravku. Klíčová slova Proxmark III, RFID, bezkontaktní čipové karty, bezpečnost bezkontaktních čipových karet, ISO/IEC A, Mifare Classic, Mifare DESFire Abstract The work deals with the security of selected smart cards. The first part describes investigated types of contactless smart cards and the communication protocol used for communication between card and reader. Further included is a description of the RFID device Proxmark III, which was used to evaluate cards security. Part of the work is also the extension of the existing firmware and functionality of the device. The last section summarizes the examination of smart cards with possible suggestions for security improvement and future product development. Keywords Proxmark III, RFID, contactless smart cards, contactless smart cards security, ISO/IEC A, Mifare Classic, Mifare DESFire ix

10 x

11 Obsah SEZNAM OBRÁZKŮ... 3 SEZNAM TABULEK... 5 ÚVOD PRINCIPY KOMUNIKACE RFID Základy komunikace Inicializace karty a ošetření kolizí Transportní protokol Přenos dat Autentizace Bezpečný přenos dat ANALÝZA KARET MIFARE Mifare Classic Základní technické vlastnosti Organizace paměti Přístup k paměti Komunikace Zabezpečení komunikace Průkaz ČVUT Mifare DESFire Technické vlastnosti Organizace paměti Přístup k paměti Paměťové operace Zabezpečení komunikace Opencard ANALÝZA PŘÍPRAVKU PROXMARK III Hardware Firmware Klient NÁVRH A REALIZACE ÚPRAV FIRMWARU

12 4.1 Úpravy původního firmwaru Mód karty Mód čtečky Testování VYHODNOCENÍ BEZPEČNOSTI VYBRANÝCH ČIPOVÝCH KARET Odposlech komunikace Mifare Classic Získání dat z Mifare Classic Simulace Mifare Classic Odposlech komunikace Mifare DESFire Aplikace jízdného MHD Průkaz Městské knihovny Průkaz Národní technické knihovny Simulace Mifare DESFire ZÁVĚR LITERATURA

13 Seznam obrázků Obrázek 1 Schematické znázornění RFID systému [7]... 9 Obrázek 2 Ukázka vnitřní struktury čipové karty [2] Obrázek 3 Ukázka kódování Miller [2] Obrázek 4 Ukázka kódování Manchester [2] Obrázek 5 Schéma průběhu antikolizní procedury [8] Obrázek 6 Schéma přenosového protokolu karet Mifare [8] Obrázek 7 ISO/OSI model užívaný bezkontaktními čipovými kartami [1] Obrázek 8 Struktura TPDU [1] Obrázek 9 Typy C-APDU aplikační vrstvy [1] Obrázek 10 Struktura R-APDU aplikační vrstvy [1] Obrázek 11 Typy a dělení autentizace [1] Obrázek 12 Schéma autentizace výzva-odpověď [1] Obrázek 13 Struktura APDU se zajištěním autenticity [1] Obrázek 14 Struktura APDU se zašifrovaným obsahem [1] Obrázek 15 Organizace paměti karty Mifare Classic [2] Obrázek 16 Struktura výrobního bloku [2] Obrázek 17 Struktura value bloku [2] Obrázek 18 Struktura sector traileru [2] Obrázek 19 Charakteristika paměťových operaci Mifare Classic [2] Obrázek 20 Struktura bitů přístupových podmínek [2] Obrázek 21 Schéma komunikace Mifare Classic [2] Obrázek 22 Autentizace Mifare Classic [2] Obrázek 23 Studentský průkaz ČVUT Obrázek 24 Srovnání jednotlivých čipů karet Mifare DESFire [13] Obrázek 25 Odvození hodnot identifikátoru AID u Mifare DESFire [13] Obrázek 26 Rozložení přístupových práv Mifare DESFire [3] Obrázek 27 Schéma autentizace Mifare DESFire Obrázek 28 karta Opencard Obrázek 29 Rozmístění HW prvků Proxmarku Obrázek 30 Sekce příkazů přípravku Proxmark III, podsekce HF Obrázek 31Zachycený signál ATQA s chybným a opraveným firmwarem Obrázek 32 Seznam opravených funkcí původního firmwaru Obrázek 33 Čtečka Cardman Obrázek 34 Mobilní telefon Samsung Nexus S Obrázek 35 Záznam komunikace studentského průkazu Obrázek 36 Výstup útoku MFCUK Obrázek 37 Výstup útoku MFOC Obrázek 38 Průchod turnikety v budově ČVUT pomocí Proxmarku Obrázek 39 Záznam komunikace z aplikace jízdné MHD Obrázek 40 Záznam komunikace z Městské knihovny Obrázek 41 Knihovní terminál v Národní technické knihovně Obrázek 42 Validátor kupónů jízdného MHD Obrázek 43 Rozdíly v časování simulace Mifare DESFire Obrázek 44 Časové prodlení v modulaci signálu simulace Mifare DESFire

14 C 1 Průběh nahrávání nového firmwaru D 1 Schéma Stand-alone módu E 1 Authenticate E 2 Get Key Settings E 3 Get Key Version E 4 Get Application IDs E 5 Get Version E 6 Select Application E 7 Read Data E 8 Write Data

15 Seznam tabulek Tabulka 1 Oprávnění čtení a zápisu dle přístupových podmínek [2] Tabulka 2 Oprávnění paměťových operací dle přístupových podmínek [2]

16 6

17 Úvod Práce se zabývá studiem čipových karet pomocí přípravku Proxmark III se zaměřením na prvky z oblasti bezpečnosti. Proxmark III je přípravek umožňující analýzu bezkontaktních čipových karet, tj. karet, které přenáší data i energii bez přímého kontaktu se čtečkou. Tento typ karet má široké uplatnění při zprostředkování rychlých platebních transakcí například pomocí bezkontaktních platebních karet, dále je využíván při platbách za jízdné, prokazování totožnosti, autentizaci v systémech řízení přístupu ap. Denně většina lidí využívá služeb různých druhů těchto karet naprosto automaticky a považuje je za samozřejmou a rutinní záležitost, aniž by se zamysleli nad možnými bezpečnostními riziky. Jako student oboru Počítačová bezpečnost toto samozřejmě vnímám a logicky mě tak zajímá úroveň zabezpečení v této oblasti. Pro účely práce jsem proto zvolil dva z nejvíce rozšířených typů bezkontaktních karet Mifare Classic a DESFire, konkrétně pak zástupce, se kterými přicházím jako student do pravidelného kontaktu. Jedná se o studentský průkaz ČVUT a Opencard. Strukturu práce a její hlavní body jsem rozvrhl následovně: Seznámení s vybranými bezkontaktními čipovými kartami. Obecné základy komunikace bezkontaktních čipových karet, jejich charakteristika, popis struktury a použitých komunikačních protokolů jsou rozebrány v kapitole 1. Kapitola 2 se pak detailně zabývá popisem vybraných druhů bezkontaktních karet. Prozkoumání možností přípravku Proxmark III a jeho popisu se věnuje kapitola 3. Kapitola 4 pak popisuje provedené práce na firmwaru přípravku a jeho rozšíření o nové funkcionality, které lze využít pro vyhodnocení bezpečnosti vybraných bezkontaktních čipových karet. Analýza bezpečnosti vybraných čipových karet na základě měření pomocí přípravku Proxmark III je prezentována v kapitole 5. Vyhodnocení bezpečnostní analýzy, vyvození závěrů a případné prezentování návrhů na zlepšení bezpečnosti a dalšího rozvoje přípravku Proxmark III. 7

18 8

19 1 Principy komunikace RFID RFID komunikace má široké uplatnění v různých oblastech. Je proto nasnadě, že se v oblasti RFID bude vyskytovat celá řada standardů. Namátkou lze vyjmenovat standardy ISO 11784, a ISO 14223/1 sloužící k regulaci a specifikaci RFID použité při identifikaci zvířat, standardy ISO a pro bezkontaktní komunikaci (například oblast platebních karet ap.) nebo ISO 18000, který zahrnuje specifikace valné většiny frekvenčních pásem RFID (jednotlivé díly normy pokrývají frekvence od 125kHz až po 900MHz). Jedním z nejvíce využívaných standardů je v dnešní době standard ISO/IEC 14443, který se dělí na dvě vzájemně nekompatibilní odnože - typ A a typ B. Rozšířenějším a běžně používaným typem je typ A, kterým se zabývá text této práce. Texty kapitol 1.2 až 1.6 vychází z [1]. 1.1 Základy komunikace Obrázek 1 Schematické znázornění RFID systému [7] RFID systém se skládá ze dvou hlavních částí a to čtečky a tzv. tagu (v našem případě bezkontaktní karta) viz Obrázek 1. Čtečka obsahuje anténu, která ji umožňuje komunikovat na frekvenci MHz (±7 khz). Během komunikace generuje elektromagnetické pole, které lze použít pro napájení karty, často slouží také jako generátor hodinových pulzů. Druhá strana komunikace může být pasivní nebo aktivní, záleží na způsobu napájení. Pasivní přípravky (karty) nemají vlastní napájecí zdroj a jsou napájeny polem čtečky. K tomu je použita anténa, konstruovaná tak, aby umožnila jak odesílání odpovědí tak i napájení vnitřních obvodů karty pomocí přijímaného signálu. Ve svinuté anténě je přes magnetické pole indukováno napětí, které napájí vnitřní obvody a ty pak odesílají odpověď se zakódovanými daty. Nevýhodou tohoto způsobu napájení je omezený dosah čtení. Jedná se řádově o centimetry. Vnitřní strukturu karty lze vidět na Obrázku 2. 9

20 Obrázek 2 Ukázka vnitřní struktury čipové karty [2] Čip na kartě obsahuje údaje, které mohou být uloženy v ROM nebo RAM paměti a navíc musí mít schopnost kódovat a dekódovat informace vyměňované se čtečkou. Pro sofistikovanější aplikace jsou potom přidávány mikrokontrolery s operačními systémy pro přístup k uloženým datům společně s kryptografickými koprocesory, které obstarávají šifrování komunikace. Komunikační rozhraní ISO/IEC typu A využívá pro přenos dat od terminálu ke kartě 100% ASK modulace s tzv. modifikovaným Millerovým kódováním. V opačném směru, tedy od karty k terminálu, se používá typ amplitudové modulace, též zátěžové modulace. Ta je generována datovým signálem, který digitálně mění energetickou zátěž karty. Pro přenos dat je použita zátěžová modulace s pomocnou nosnou vlnou na frekvenci 847 khz (13,56 MHz/16) a k modulaci pomocné nosné se používá OOK (On Off Keying) řízené datovým tokem kódovaným pomocí Manchester kódu. Modifikované Millerovo kódování je ukázané na bitové sekvenci na Obrázku 3. Pro zakódování logické 0, pokud předchozí bit byl rovněž nulový, dojde na začátku bitového intervalu k poklesu pole po dobu 2.28 μs. Pokud byl předchozí bit logická 1, nedochází k žádné změně. Logická 1 je pak kódována poklesem pole uprostřed bitového intervalu. Obrázek 3 Ukázka kódování Miller [2] Obrázek 4 Ukázka kódování Manchester [2] V případě kódování Manchester (viz Obrázek 4) je bitový interval rozdělen na dvě části a logická 0 i logická 1 je kódována pevnou sekvencí bez ohledu na předcházející bit. 10

21 1.2 Inicializace karty a ošetření kolizí V systémech, které využívají bezkontaktní karty, může dojít k situaci, kdy se v poli čtecího zařízení objeví více karet současně nebo kdy je karta přiložena ke čtečce, která již komunikuje s jinou kartou. Proto je potřeba zajistit, aby byly karty obslouženy postupně a nedocházelo k vzájemnému rušení. Když se dostane karta do dosahu pole terminálu, její čip se probudí k životu. Po skončení inicializačních rutin je karta uvedena do tzv. pohotovostního režimu. Během toho může terminál nerušeně komunikovat s jinou kartou (kartami) v dosahu. Z tohoto vyplývá, že karta v pohotovostním režimu nesmí nijak reagovat na probíhající komunikaci mezi terminálem a jinou kartou. Pokud v tuto chvíli (v pohotovostním režimu) karta obdrží od terminálu příkaz REQA (Request-A), odpoví pomocí ATQA (Answer to Request A) a tímto je připravena ke komunikaci. Nyní terminál ví, že je v dosahu alespoň jedna karta a spustí antikolizní proceduru, účelem které je zjištění identifikátoru UID karty (eventuelně karet). Antikolizní procedura funguje tak, že terminál vyšle povel SELECT s parametrem NVB (Number of Valid Bits) rovno 20h, což znamená, že všechny karty v dosahu odpoví celým svým UID. Za předpokladu, že každá karta má jedinečné UID, musí v případě odpovědi více karet nutně vzniknout kolize. Terminál dokáže rozeznat pozici prvního kolizního bitu, takže v dalším kroku vyšle povel SELECT a NVB nastaví na hodnotu pozice bitu předcházejícího kolizi. Dále karta (karty) porovná platnou část UID přijatou do terminálu s vlastním UID a najde-li shodu, odpoví terminálu zbytkem svého UID. Pokud antikolizní procedura detekuje jedinou odpověď, terminál vyšle povel SELECT s parametrem NVB rovno 70h (to znamená, že bude následovat kompletní UID karty), zmíněným UID a kontrolním součtem. Karta s tímto UID odpoví terminálu pomocí SAK (SELECT acknowledge) a přejde to aktivního režimu. V opačném případě, tedy pokud odpoví více než jedna karta a dojde k další kolizi, upraví terminál hodnotu NVB a platné části UID a opakuje výzvu, dokud nepřijde jediná odpověď. Maximální počet opakování je roven 32. Nutno zmínit, že ne všechny bezkontaktní čipové karty dle ISO/IEC mají 4bytové UID. Standard povoluje i 7bytová (dvojitá) a 10bytová (trojitá) UID. Pokud vybraná karta disponuje dvojitým UID, oznámí tuto skutečnost terminálu v SAK nastavením cascade bitu na hodnotu 1, což způsobí restart antikolizního algoritmu a umožní terminálu zjistit druhou část UID karty. V případě trojitého UID je nutné restartovat algoritmus ještě jednou. Průběh antikolizní procedury je zachycen na Obrázku 5. 11

22 Požadovanou část UID signalizuje terminál v povelu SELECT pomocí tzv. cascade level bytu (CL1, CL2, CL3). Aby se předešlo záměně fragmentu dlouhého ID s krátkým ID, vkládají se v případě dvojitých a trojitých ID do přenosových rámců na stanovená místa tzv. cascade tag byty. Ty mají jasně definovanou hodnotu (88h), jež se nesmí vyskytovat na odpovídající pozici žádného krátkého ID. Obrázek 5 Schéma průběhu antikolizní procedury [8] 12

23 1.3 Transportní protokol Před samotnou výměnou dat je nutné upřesnit jisté vlastnosti nadcházejícího přenosu. Obě strany komunikace musí znát podporované přenosové rychlosti, maximální velikosti datových bloků ap. Vybere-li terminál kartu příkazem SELECT s jejím UID, karta výběr potvrdí pomocí SAK. V odpovědi je obsažena i informace, zda karta implementuje klasický přenosový protokol dle ISO/IEC , či používá nějaký vlastní (např. Mifare) jak je zobrazeno na Obrázku 6. Obrázek 6 Schéma přenosového protokolu karet Mifare [8] Používá-li karta protokol ISO/IEC , vyžádá si terminál od karty ATS (Answer To Select) vysláním povelu RATS (Request for Answer To Select). Tento povel obsahuje dva parametry důležité pro další komunikaci FSDI a CID. FSDI (Frame Size Device Integer) definuje maximální velikost jednoho bloku dat (v bytech) ve směru od karty k terminálu. Možné hodnoty jsou 16 až 256 bytů (v mocninách 2). CID (Card identifier) je logický identifikátor karty vybraný terminálem. Terminál tento identifikátor používá k jednoduché adresaci dané karty v případě výskytu více karet (v aktivním režimu) v dosahu. ATS (v případě klasických kontaktních čipových karet se jedná o ATR) definuje důležité parametry operačního systému karty, na základě kterých se upravují parametry výměny dat. Dalšími volitelnými parametry ATS jsou např. maximální rychlosti přenosu dat (ke kartě i od ní) nebo maximální akceptovatelná velikost bloku dat. Chce-li terminál ještě upravit parametry, jež obdržel v ATS, může tak ještě učinit pomocí PPS (Protocol Parameter Selection). Tento krok je volitelný a záleží na terminálu, zda-li povel kartě pošle, či rovnou přejde k samotné výměně dat. 13

24 1.4 Přenos dat Samotný přenos dat mezi kartou a terminálem pracuje na principu polovičního duplexu a je založen na blokově orientovaném protokolu T=1 pro kontaktní čipové karty, v případě bezkontaktních karet se označuje jako T=CL (z anglického contact less). Stejně jako u kontaktních čipových karet se můžeme u ISO/IEC střetnout se dvěma zkratkami souvisejícími s přenosem dat. Těmi jsou tzv. TPDU (transport protocol data unit) datová jednotka transportní vrstvy a tzv. APDU (application protocol data unit) datová jednotka vrstvy aplikační. Uspořádání vrstev dle ISO/OSI modelu ukazuje následující Obrázek 7. Obrázek 7 ISO/OSI model užívaný bezkontaktními čipovými kartami [1] Základní struktura přenosového rámce transportní vrstvy je vyobrazena na Obrázku 8. Nejdůležitějším bytem je PCB (Protocol control byte). Ten určuje vlastnosti specifikovaného rámce. Kromě informačních rámců (information block, I block), jejichž posláním je přenos datových jednotek aplikační vrstvy, totiž existují ještě další dva typy - opravné (recovery block, R block) a kontrolní (supervisory block, S block) rámce. Z názvů je zřejmé, že opravné rámce mají za úkol vypořádávat se s přenosovými chybami, zatímco kontrolní rámce řídí samotnou komunikaci. Byty v hranatých závorkách jsou nepovinné, CID je použito pro adresaci konkrétní karty, NAD byte se přímo nevyužívá, byl zaveden pouze z důvodů kompatibility s ISO/IEC 7816 (T=1). Poslední dva byty TPDU pak tvoří kontrolní součet (16bitové CRC), jež slouží k detekci přenosových chyb. Obrázek 8 Struktura TPDU [1] APDU se rozděluje na tzv. C-APDU, jež reprezentují povely od terminálu a R-APDU, což jsou odpovědi karty na dané povely. C-APDU se skládá z hlavičky a těla. Tělo může mít různou délku, pokud je datová část prázdná, může se dokonce i vypustit. Hlavička se skládá ze čtyř bytů, které jdou po sobě takto: Třída (CLA), Instrukce (INS), Parametr 1 (P1) a 14

25 Parametr 2 (P2). Třída pak označuje použitou kategorii povelů. Instrukční byte definuje aktuální příkaz, který dále specifikují dva parametry P1 a P2. Tělo C-APDU může obsahovat nanejvýš tři prvky. První Lc (Length command) udává délku následující datové části (druhý prvek) a třetí Le (Length expected) specifikuje požadovanou délku dat v odpovědi karty. Pokud je hodnota tohoto prvku 00, znamená to, že terminál požaduje data maximální možné délky. Kombinací výše zmíněných částí mohou vzniknout 4 různé typy C-APDU. Možnosti ukazuje následující Obrázek 9. Obrázek 9 Typy C-APDU aplikační vrstvy [1] R-APDU, neboli odpověď karty terminálu, se také skládá ze dvou částí - z nepovinného těla a povinného dodatku. Tělo tvoří datová část, jejíž délku specifikoval terminál pomocí Le bytu. Nehledě na tuto hodnotu může však být délka datové části nulová, což nastane v případě výskytu chyby při výpočtu. O výsledku operace, ať již úspěšném či neúspěšném, informují dva byty (SW1 a SW2) v dodatku. Situaci znázorňuje následující Obrázek 10. Obrázek 10 Struktura R-APDU aplikační vrstvy [1] R-APDU obsahuje dodatek v podobě dvou bytů SW1 a SW2. Ty slouží jako návratový kód operace. Standard definuje více než 50 různých návratových kódů, mnoho aplikací však používá své, nestandardní kódy. Výjimkou je kód 9000 pro úspěšné ukončenou operaci. 15

26 1.5 Autentizace Smyslem autentizace je ověřit identitu a pravost komunikačního partnera. V případě bezkontaktních čipových karet jde o to, aby karta dokázala zjistit, že komunikuje s tím správným terminálem a obráceně. Při autentizaci je nutné, aby obě komunikující strany sdílely jisté tajemství, které lze ověřit. Tento proces ověření identity je mnohem bezpečnější a komplikovanější než pouhá identifikace např. pomocí PIN. V případě PIN je tento totiž odeslán kartě jako holý nešifrovaný text, a v případě odposlechu s ním již nemá útočník žádnou práci. V případě autentizace bezkontaktní čipové karty a terminálu není možné zjistit sdílené tajemství pouhým odposlechem komunikačního kanálu, jelikož toto není přenášeno v otevřené podobě. Existuje více možností a parametrů autentizace, dělení autentizace je zachyceno na Obrázku 11. Obrázek 11 Typy a dělení autentizace [1] Pro účely práce je zde popsána jednostranná autentizace využívající symetrické kryptografie. Jednostranná autentizace slouží jedné straně k ověření důvěryhodnosti strany druhé. K tomuto potřebují obě strany sdílené tajemství, jehož znalost je předmětem autentizace. Toto tajemství je šifrovací klíč a na něm závisí celá autentizační procedura. Pokud by klíč vstoupil ve známost, kdokoli by se mohl prokázat jako důvěryhodný komunikační partner. Při situaci, kdy terminál ověřuje důvěryhodnost bezkontaktní čipové karty pomocí symetrické šifry (Obrázek 12) vygeneruje náhodné číslo (nonce) a to pošle kartě jako výzvu (challenge). Karta číslo zašifruje tajným klíčem a pošle zpět terminálu. Toto je odpověď (response). Terminál použije opět tento klíč k rozšifrování přijaté zprávy, a pokud se toto dešifrované číslo rovná číslu původně vyslanému, je karta úspěšně autentizována. 16

27 Obrázek 12 Schéma autentizace výzva-odpověď [1] Na tento způsob autentizace nemůže být proveden útok přehráním výzvy nebo odpovědi z minulé relace, neboť terminál pokaždé vygeneruje jiné náhodné číslo. Jediný prakticky použitelný útok je hrubou silou, neboť máme k dispozici jak náhodné číslo, tak jeho šifru. V tomto případě již vše závisí na délce klíče. Pokud by všechny karty v daném systému používaly stejný klíč a tento by se podařilo úspěšným útokem rozluštit, celý systém by byl zdiskreditován. Právě z tohoto důvodu má každá karta svůj vlastní klíč odvozený z nějaké netajné vlastnosti karty. Tou může být např. výrobní číslo čipu nebo jakékoli jiné unikátní číslo. Hodnota tohoto klíče je šifrou unikátního čísla karty hlavním klíčem (tzv. master key), který zná pouze terminál. K zašifrování se nejčastěji používá šifra DES nebo 3DES. 17

28 1.6 Bezpečný přenos dat Obvykle nestačí pouze autentizovat obě komunikující strany, ale je zapotřebí zabezpečit i následný přenos dat, aby se předešlo možnosti odposlouchávání nebo manipulace s daty. Existují dvě možnosti buď lze k APDU pouze spočítat a přidat MAC nebo zašifrovat celé APDU. V prvním případě by se sice zabránilo manipulaci s daty, nicméně útočník by data mohl přečíst, neboť jsou posílána jako holý text. Proto se pro aplikace, kde je nutné skrýt obsah, používá druhá varianta. Při té je tělo APDU zašifrováno tajným klíčem a teprve poté odesláno. Vše je patrné na následujícím Obrázku 13. Obrázek 13 Struktura APDU se zajištěním autenticity [1] Pokud chceme pouze zajistit autenticitu APDU, můžeme nyní toto APDU odeslat (datová část je ve formě nešifrovaného textu). Jestliže však chceme utajit i samotný obsah APDU, tělo vyplníme, rozdělíme na 8bytové bloky a zašifrujeme tajným klíčem, což je znázorněno na dalším Obrázku 14. Obrázek 14 Struktura APDU se zašifrovaným obsahem [1] 18

29 Posílání zpráv zabezpečených touto metodou eliminujeme možnost odposlouchávání. Nevýhodou této metody je v tomto případě snížená maximální přenosová rychlost, která se odvíjí od použité šifry. Je tedy na provozovateli, zda-li pro danou aplikaci stačí pouze zajistit autenticitu zpráv a přenášet rychleji, či je nutné šifrovat jejich obsah za cenu pomalejšího přenosu. 19

30 20

31 2 Analýza karet Mifare Označení Mifare je ochrannou známkou společnosti NXP Semiconductors a vztahuje se ke světově nejrozšířenější rodině bezkontaktních čipových karet a jejich čteček. Pod tímto pojmem se skrývají proprietární technologie založené na standardu ISO/IEC typu A pro 13,56 MHz bezkontaktní čipové karty. 2.1 Mifare Classic První a základní karta z rodiny Mifare. Namísto standardu ISO/IEC 14443A-4 používá vlastní bezpečnostní protokol a proto není plně kompatibilní se standardem ISO/IEC typ A. Karta využívá proprietární proudovou šifru CRYPTO-1 a existuje ve variantě s 1 KB nebo 4 KB paměti. Mifare Classic byla uvedena na trh v roce 1994 firmou Mikron, která byla začleněna do společnosti Philips. Tato společnost v průběhu let založila společnost NXP Semiconductors, pod kterou byla výroba převedena. Podle výrobce bylo prodáno více než 3,5 miliard integrovaných obvodů z rodiny Mifare, přičemž většina z této produkce jsou právě karty Mifare Classic. Tím se řadí mezi nejrozšířenější na trhu. Bezkontaktní čipové karty Mifare Classic jsou používány po celém světě v řadě implementací. V městské hromadné dopravě jsou často používány jako elektronické jízdenky - např. v Bratislavě, Londýně, Košicích, Varšavě, Krakově, Sofii, Bukurešti, Malmö či v Lucemburku. Řada soukromých i veřejných subjektů používá tyto karty pro řízení přístupu do budov. České vysoké učení technické v Praze využívá Mifare Classic pro studentské karty. Karty jsou také používány v řadě měst jako parkovací karty namátkou v Plzni, Bratislavě, Varšavě či Krakově. Texty kapitoly 2.1 vychází z [2], [4]. 21

32 2.1.1 Základní technické vlastnosti Základem karty je čip malých rozměrů, který je napájen elektromagnetickým polem čtečky karty prostřednictvím antény, která slouží zároveň jako komunikační anténa. Díky rozměrům čipu je produkt dostupný nejen v podobě plastikové karty běžných rozměrů podle ISO 7810, ale také například v podobě přívěsku na klíče a v podobných provedeních. Proto často dochází k obecnějšímu označení produktu jako tag namísto výrazu karta. Specifikace Mifare Classic v bodech Bezkontaktní čipová karta (smart card) částečně kompatibilní s ISO/IEC typ A. Bezkontaktní přenos dat a zajištění napájení (bez potřeby baterie). Pracovní vzdálenost: až 100 mm. Pracovní frekvence: 13,56 MHz. Přenosová rychlost: 106 kbit/s. Integrita dat: 16bitové CRC, parita, kódování bitů a další. Paměť EEPROM o velikosti 1 KB nebo 4 KB organizována do sektorů a v jejich rámci do bloků. Bezpečnost: třífázová autentizace, individuální páry klíčů pro každý sektor, unikátní sériové číslo karty (UID). Poznámka: V květnu 2010 výrobce NXP oznámil, že z důvodu blížícího se vyčerpání rozsahu 4bytových UID jsou nové karty vyráběny se 7bytovým UID. Ve specifikaci uváděné v tomto textu se omezím na karty se 4bytovým UID Organizace paměti Paměť EEPROM o velikosti 1 KB nebo 4 KB je organizována do sektorů a v jejich rámci do bloků. Základní paměťovou jednotkou je 16bytový datový blok. Datové bloky jsou seskupovány do sektorů. 1 KB karta je rozdělena rovnoměrně, obsahuje 16 sektorů po 4 blocích. Rozdělení paměti 4 KB karty není rovnoměrné, karta obsahuje 40 sektorů. Prvních 32 sektorů obsahuje po 4 blocích, každý z dalších 8 sektorů obsahuje 16 bloků. 22

33 Poslední blok každého ze sektorů je nazýván sector trailer a obsahuje přístupové klíče a nastavení přístupových podmínek k danému sektoru. Sektory i bloky jsou číslovány od 0, viz Obrázek 15. Obrázek 15 Organizace paměti karty Mifare Classic [2] Výrobní blok První datový blok (sektor 0, blok 0) se nazývá výrobní (manufacturer block) a obsahuje data, která byla nastavena při výrobě karty. Po zápisu tohoto bloku, ještě během výroby karty, dojde k jeho uzamčení proti zápisu, tento blok tudíž není možno modifikovat. První 4 byty obsahují unikátní identifikátor karty, tzv. UID. Pátý byte obsahuje kontrolní součet UID a zbylé byty obsahují informace o výrobci karty. Schéma bloku je na Obrázku 16. Obrázek 16 Struktura výrobního bloku [2] 23

34 Value blok Veškeré bloky, kromě výrobního bloku a bloků s označením sector trailer (viz dále) slouží pro uchovávání dat. Tyto bloky mohou sloužit ke čtení/zápisu dat a jejich konfigurace se provádí pomocí nastavení přístupových podmínek ke každému ze sektorů. Bloky mají přesně daný datový formát, který umožňuje detekci a korekci chyb. S hodnotami uloženými v těchto blocích je možno provádět paměťové operace typu čtení, zápis, inkrementace, dekrementace, obnovení a přenos. Value blok je možno vytvořit pouze operací zápis. Hodnota uložená v tomto typu bloku je 4bytové znaménkové číslo. Nejméně významný byte je uložen na nejnižší adrese. Negované hodnoty jsou uloženy v podobě dvojkového doplňku. Z důvodu zachování integrity a bezpečnosti je hodnota uložena celkem třikrát, dvakrát v přímé podobě a jedenkrát jako invertovaná hodnota. V posledních 4 bytech value bloku je uložena 1 bytová adresa. Ta je uložena celkem čtyřikrát, dvakrát v přímé hodnotě a dvakrát jako invertovaná hodnota, viz Obrázek č. 17. Tento byte je použit k uložení adresy bloku v zálohovacím managementu systému. Obrázek 17 Struktura value bloku [2] Sector trailer Posledním datovým blokem každého sektoru je sector trailer. Tento speciální datový blok obsahuje 6bytové (48bitové) tajné klíče A a B (volitelný) a přístupové podmínky pro datové bloky sektoru, které jsou uloženy ve 4 bytech, viz Obrázek 18. Pokud není klíč B použit, lze posledních 6 bytů sector traileru použít pro uložení dat. Klíč A nelze nikdy číst, možnost čtení klíče B lze nastavit pomocí přístupových podmínek. Obrázek 18 Struktura sector traileru [2] 24

35 2.1.3 Přístup k paměti Pro práci s pamětí karty Mifare Classic slouží 6 paměťových operací: čtení, zápis, inkrementace, dekrementace, obnovení a přenos. Popis jednotlivých operací je uveden na Obrázku 19. Obrázek 19 Charakteristika paměťových operaci Mifare Classic [2] Přístupové podmínky ke každému z datových bloků vč. sector traileru lze nastavit pomocí 3 bitů. V případě 4 KB karty se u posledních 8 sektorů po 16 datových blocích nastavují přístupové podmínky vždy pro pětici datových bloků. Bity přístupových podmínek jsou uloženy vždy jednou v přímé podobě a jedenkrát jako invertované hodnoty, viz. Obrázek 20. Pomocí těchto bitů lze požadovaným způsobem nastavit přístupové podmínky pro provádění paměťových operací na základě autentizace pomocí tajných klíčů A a B. Integrita 4 bytů přístupových podmínek je kontrolována interní logikou karty při každé paměťové operaci, a pokud je detekována chyba, celý sektor je nevratně zablokován. Obrázek 20 Struktura bitů přístupových podmínek [2] 25

36 Přístupové podmínky se liší podle toho, zda slouží pro přístup k datovému bloku nebo k sector traileru. Možné varianty nastavení těchto podmínek jsou uvedeny v Tabulce 1 a 2. Tabulka 1 Oprávnění čtení a zápisu dle přístupových podmínek [2] Tabulka 2 Oprávnění paměťových operací dle přístupových podmínek [2] 26

37 2.1.4 Komunikace Komunikace Mifare Classic se řídí podle standardu ISO A, která již byla popsána v sekci 1. Na Obrázku 21 je vidět schéma komunikace se stavy Power On Reset (POR), Request Standard/Request All, Antikolizní procedura a Select card. Obrázek 21 Schéma komunikace Mifare Classic [2] Po antikolizi následuje třífázová autentizace. Po výběru karty čtečka specifikuje paměťový blok, ke kterému chce přistupovat. K přístupu používá odpovídající klíč pro třífázovou autentizaci. Autentizace je schematicky znázorněna na Obrázku 22 a vychází z principu výzva-odpověď využívající nonce, který byl již popsán v kapitole 1.5. Odpověď je výstupem z transformační funkce, která vezme výzvu jako vstup, je zašifrována tajným klíčem a odeslána. Klíč tak není vůbec přenášen. Vzájemnou výměnou jednotlivých výzev a ověřením odpovědí je potvrzeno, že obě komunikující strany mají správné klíče. 27

38 Po úspěšné autentizaci jsou veškeré paměťové operace šifrovány. Paměťové operace, které je možno v rámci daného bloku provést, jsou následující: čtení bloku, zápis bloku, dekrementace, inkrementace, obnovení dat do datového registru, přenos dat z datového registru do bloku. Obrázek 22 Autentizace Mifare Classic [2] Zabezpečení komunikace Mifare Classic využívá proudovou šifru CRYPTO-1, vyvinutou firmou NXP speciálně pro tento typ karet. Detaily komunikačního protokolu a algoritmu používané šifry nejsou výrobcem publikovány. V letech 2007 až 2008 proběhla řada zkoumání čipu karty a jeho komunikace s okolím, na jejichž základě byl pomocí reverzního inženýrství přesně identifikován komunikační protokol i algoritmus použité šifry [9] [10]. Díky identifikaci šifry bylo následně odhaleno několik bezpečnostních slabin. Mezi zásadní slabiny patří například: Generátor pseudonáhodných čísel použitý v šifře CRYPTO-1 má pouze 16bitovou entropii a jím generovaná čísla tak nejsou příliš náhodná, perioda generátoru činí pouze hodnot. Další výraznou slabinou je, že pokud je požadavek vyslán vždy ve stejném čase od zahájení napájení karty, řetězec generovaný tímto generátorem je vždy stejný. Standard ISO typ A definuje potřebu po každém přeneseném bytu přenést paritní bit. Karta Mifare Classic provádí výpočet paritních bitů na základě otevřeného textu, místo toho aby tyto bity byly počítány až na základě přenášeného šifrového textu. Navíc, 28

39 pro šifrování paritních bitů je použit stejný bit proudového klíče jako k zašifrování následně přenášeného bitu. Tím uniká informace o otevřeném textu. V případě chybné odpovědi čtečky na úvodní výzvu ze strany karty, kdy tato chybná odpověď má správnou paritu, karta generuje 4bitový chybový kód 0x5, který ale zasílá v zašifrované podobě. A to i přes to, že dosud neproběhla celá autentizace. Jelikož je generovaný kód znám, unikají tak 4 bity informace o proudovém klíči generovaném šifrou CRYPTO-1. Při úspěšné autentizaci k jednomu datovému bloku v rámci sektoru a následném přístupu k jinému bloku v jiném sektoru není náhodný řetězec generovaný kartou přenášen v otevřené podobě, jako je tomu při první autentizaci, ale je přenášen šifrovaně s použitím klíče příslušného k nově přistupovanému bloku. Díky tomu, že tento řetězec není příliš náhodný a díky správnému časování komunikace můžeme dosáhnout toho, že řetězec bude stále stejný a známý. Uniká tím plných 32 bitů informace o proudovém klíči generovaném šifrou CRYPTO-1. Na základě zjištěných bezpečnostních slabin a na základě znalosti algoritmu proudové šifry CRYPTO-1 byla publikována řada útoků na kartu Mifare Classic, spočívajících ve zjištění přístupových klíčů k jednotlivým sektorům a na jejich základě k získání uložených dat. Díky tomu je možné obsah karty zcela zkopírovat na prázdnou kartu. Jsou popsány i útoky založené na komunikaci výhradně s kartou, tedy bez účasti legitimní čtečky. Díky tomuto typu útoků je možné zcizit obsah karty komukoli i zcela bezkontaktně, např. v dopravním prostředku, kde se s čtečkou posadíme vedle cestujícího, jehož kartu chceme zkopírovat. Pro účely práce zde uvedu jako příklad Mifare Classic Offline Cracker (MFOC) a Mifare Classic Universal toolkit (MFCUK). MFOC je knihovna pod licencí GNU GPL, implementující Offline Nested útok [11], který dokáže získat klíče, pokud známe alespoň jeden platný klíč typu A/B, nebo pokud jsou na kartě použity defaultní klíče. Využívá chybu autentizace při přístupu k sektoru po předchozí úspěšné autentizaci k sektoru jinému. Takovýto způsob provedení útoku lze u řady implementací karty využít, neboť mnoho implementací je založeno na zabezpečení jen určitých sektorů karty a u dalších sektorů bývají ponechány výchozí klíče, které jsou obecně známé. Do těchto sektorů je tak možno se úspěšně autentizovat a útoku využít pro přístup k dalším sektorům, jejichž klíče neznáme. MFCUK je rovněž knihovna pod licencí GNU GPL a implementuje Dark Side attack Nicolase T. Courtoise [12]. Využívá se zde knihoven LIBNFC a Crapto1 k prozkoumání a 29

40 útoku na známé slabiny Mifare Classic. Implementace bezpečnosti totiž může být provedena tak, že na kartě nejsou použity v žádném sektoru defaultní klíče. V takovém případě nelze využít útok MFOC a využije se útok MFCUK. Nejčastěji se však používají oba útoky v kombinaci podle následujícího scénáře: Pokus o autentizaci do každého sektoru karty s použitím výchozích šifrovacích klíčů, případně s použitím klíče získaného jinou cestou. Pokud byl v bodu 1) přístup do alespoň jednoho sektoru úspěšně autentizován, pokračovat na bod 4. Získání jednoho z šifrovacích klíčů k jednomu ze sektorů karty pomocí útoku MFCUK Autentizace do sektoru se znalostí šifrovacího klíče a následné využití útoku MFOC pro získání všech zbylých klíčů. Při postupu podle uvedeného scénáře je možno získat kompletní obsah paměti karty, je potřeba si však uvědomit, že každá karta má jednoznačně přidělené sériové číslo, které není možné změnit. Na prázdnou kartu tak můžeme přenést obsah kopírované karty, ale ne její sériové číslo. Pokud chceme mít identickou kopii karty včetně sériového čísla, musíme pro klon místo prázdné karty použít emulátor karty, což může být hardware např. o velikosti čtečky karet. 30

41 2.1.6 Průkaz ČVUT Držitelem ČVUT průkazu je každý student i zaměstnanec ČVUT. Karta obsahuje údaje o vlastníkovi - je na ní zaznamenáno jméno vlastníka, datum narození, vztah ke škole či fakultě, osobní číslo studenta (zaměstnance) a datum expirace karty. Karta umožňuje dva základní způsoby identifikace. Je opatřena magnetickým pruhem pro kontaktní čtečky, druhým způsobem je RFID (bezkontaktní). Karta je vybavena čipem Mifare Classic 1K, na kterém jsou uložena data vlastníka karty. Ten se pomocí karty prokazuje při vstupu do budovy, učeben a laboratoří. Dále je karta využívána pro platby v menzách, v copycentru a pro výpůjčky v Národní technické knihovně. Vydavatelství průkazů ČVUT nabízí i možnost, že je průkaz spojen s kartou ISIC. V tomto případě je možné ve spojení s kartou nakupovat i kupony pro MHD. Nově je též s kartou spjat placený parkovací systém v garážích v Nové budově ČVUT. Obrázek 23 Studentský průkaz ČVUT 31

42 2.2 Mifare DESFire Mifare DESFire je bezkontaktní čipová karta vyhovující standardu ISO/IEC 14443A-4, jedná se o typ karet s větší podporou kryptografických a bezpečnostních funkcí než Mifare Classic. Karta je nabízena ve více variantách, s různou podporou kryptografických funkcí a různou velikosti paměti. Čip používá operační systém DESFire operating system. Mifare DESFire je využívána zejména v hromadné dopravě jako elektronické jízdenky. Příkladem může být například In-karta Českých drah nebo Opencard. Ve veřejné dopravě v zahraničí se využívá například v Melbourne, Oslu, Nanjingu, Seattlu, Sydney nebo Madridu. Tento typ karet umožňuje rychlejší komunikaci, lepší výkonnost karty, podporu více aplikací a silnou kryptografii. Z těchto důvodů je DESFire ideálním řešením pro nové instalace nebo migrace ze starších typů karet. Texty kapitoly 2.2 vychází z [1], [3] Technické vlastnosti Základem karty je opět čip malých rozměrů, který je napájen elektromagnetickým polem čtečky karty prostřednictvím antény, která slouží zároveň jako komunikační anténa. Konkrétní vlastnosti jako velikost paměti, počet aplikací ap. se liší na základě verze použitého čipu. Srovnání těchto vlastností je vyobrazeno na Obrázku 24. Obrázek 24 Srovnání jednotlivých čipů karet Mifare DESFire [13] 32

43 Specifikace Mifare DESFire v bodech Bezkontaktní čipová karta (smart card) vyhovující standardu ISO/IEC typ A. Pracovní vzdálenost: až 100 mm. Pracovní frekvence: 13,56 MHz. Podporované přenosové rychlosti: 106 kbit/s až 848 kbit/s. Paměť: bytů EEPROM. Životnost zapisovacích cyklů. Doba zápisu do paměti: 2 ms (1 ms vymazání, 1 ms samotný zápis). Trvanlivost dat 10 let. Flexibilní souborový systém (různé velikosti paměťových bloků). Podpora až 28 zcela nezávislých aplikací na kartě. Každá aplikace může využívat až 32 souborů, prvních 8 je zálohovaných. Bezpečnost: Unikátní 7bytové číslo karty. Generátor opravdu náhodných čísel. Hardwarová podpora šifrovacích algoritmů DES & 3DES popř. AES. Zajištění integrity dat pomocí 4bytového MAC. Podpora až 14 kryptografických klíčů pro každou aplikaci Organizace paměti Ve srovnání s Mifare Classic, která používá dělení na sektory a bloky, DESFire disponuje 4 KB nevolatilní paměti, která je organizována pomocí flexibilního systému souborů. Tento souborový systém umožňuje maximálně 28 různých aplikací na jedné kartě a každá aplikace nabízí až 32 souborů. Aplikace jsou pak reprezentovány 3bytovými identifikátory aplikace AID. Ty jsou odvozeny od AID identifikátorů Mifare Classic (hodnoty 4011h, 4012h a 4013h). Odvození je znázorněno na Obrázku 25. Obrázek 25 Odvození hodnot identifikátoru AID u Mifare DESFire [13] 33

44 Karta je též vybavena zálohovacím systémem pro dostupné soubory. Příkazy, které mají vliv na strukturu souborů (například vytvoření nebo odstranění aplikací, změna klíče ap.) aktivují automatický mechanismus obnovy, který chrání strukturu souborů před poškozením. Jestliže se karta ocitne v nekonzistentním stavu, provede se obnovení bez zásahu uživatele před vykonáním dalšího příkazu. Tato situace může nastat například odstraněním karty z pole čtečky za provozu Přístup k paměti Existují 4 typy přístupových práv, které jsou definovány a uloženy ve 2 bytech pro každý soubor všech aplikací: čtení, zápis, čtení & zápis, změna přístupových práv. Každé přístupové právo je kódováno pomocí 4 bitů (1 nibble). Nibble potom představuje odkaz na vybraný klíč dané aplikace. Nibble může nabývat 16 různých hodnot. Rozmezí 0 až 13 určuje, že se jedná o platný klíč (maximum je 14), hodnota 14 (0xE) značí neomezený přístup bez autentizace. Hodnota 15 pak značí odmítnutí přístupu. Nejvýznamnější nibble 2bytového parametru představuje odkaz na klíč pro čtení, druhý nibble je odkazem na klíč pro zápis, třetí odkazuje na klíč pro právo čtení i zápisu a poslední nibble slouží k identifikaci klíče, pomocí kterého probíhá autentizace při změnách přístupových práv. Rozložení přístupových práv je znázorněno na Obrázku 26. Obrázek 26 Rozložení přístupových práv Mifare DESFire [3] Čtení je pak možné, pokud je nastaven první nebo třetí nibble, zápis je umožněn nastavením druhého nebo třetího nibblu. Pokud se k souboru přistupuje bez autentizace a volný přístup (0xE) je umožněn díky alespoň jednomu přístupovému právu probíhá komunikace nešifrovaně. Pokud je alespoň jedno z přístupových práv čtení nebo čtení & zápis nastaveno na 0xE, pro komunikaci je využito šifrování nebo MAC. 34

45 2.2.4 Paměťové operace Mifare DESFire využívá paměťové operace, které lze dělit do několika skupin. Výčet operací s jejich hexadecimálním kódem a stručným popisem je uveden níže. Příkazy spjaté s bezpečností: 0x0A Authenticate příkaz sloužící pro autentizaci a ověření, 0x54 Change Key Settings - změní nastavení hlavního klíče karty, 0x45 Get Key Settings vrátí informaci o vybraném klíči a max. počet klíčů aplikace, 0xC4 Change Key slouží ke změně vybraného klíče, 0x64 Get KeyVersion vrátí informace o verzi zadaného klíče. Příkazy pro práci s aplikacemi: 0xCA Create Application - vytvoření nové aplikace na kartě, 0xDA Delete Application - odstranění aplikace z karty, 0x6A Get Applications IDs vrátí identifikátor všech aplikací karty, 0x5A Select Application slouží k výběru aplikace, ke které se bude přistupovat, 0xFC FormatPICC uvolnění paměti karty, 0x60 Get Version poskytne výrobní informace. Příkazy aplikační vrstvy: 0x6F Get File IDs vrátí identifikátory všech souborů vybrané aplikace, 0xF5 Get File Settings vrátí informaci o vlastnostech vybraného souboru, 0x5F Change File Settings změní přístupové podmínky k souboru, 0xCC Create Value File v rámci aplikace vytvoří soubor pro ukládání hodnot o velikosti 32 bitového integeru, 0xDF Delete File odstranění vybraného souboru. Příkazy pro manipulaci s daty: 0xBD Read Data čtení dat, 0x3D Write Data zápis dat, 0x6C Get Value čtení hodnoty ze souboru. 35

46 2.2.5 Zabezpečení komunikace Každá karta disponuje jedinečným 7bytovým identifikátorem UID, který je do ní nahrán při výrobě, a který nelze již následně měnit. UID samo o sobě však lze replikovat, proto karta využívá další mechanismy zabezpečení. Před každým přenosem dat lze provést třífázovou autentizaci s využitím šifer DES, 3DES nebo AES (záleží na verzi čipu karty) a příslušného klíče. Autentizace začíná tím, že čtečka vyšle kartě autentizační požadavek spolu s číslem klíče, který má být pro autentizaci použit. Karta vygeneruje náhodné 8bytové číslo RndB a zašifruje ho příslušným klíčem a vzniklé ek(rndb) odešle čtečce. Ta ek(rndb) dešifruje, provede jeho rotaci o 1 byte vlevo a spojí s vlastním náhodně vygenerovaným číslem RndA. Vznikne tak 16bytový řetězec RndA+RndB, který je opět dešifrován a jako dk(rnda+rndb ) předán kartě. Ta po zašifrování a rotaci ověří správnost RndB a následně provede rotaci obdrženého RndA a zašifrované ek(rnda ) odešle ke kontrole čtečce. Autentizace tak ověří, že obě strany sdílejí stejné tajemství resp. klíč. Náhodně vygenerované hodnoty RndA a RndB pak slouží k vytvoření tzv. session klíče, který je použit pro šifrování dat při přenosu po autentizaci. Session klíč vznikne zřetězením nejprve prvních polovin náhodných čísel a následně jejich druhých částí. Schéma autentizace je zachyceno na Obrázku 27. Obecné principy autentizace jsou rozepsány v kapitole 1.5. Obrázek 27 Schéma autentizace Mifare DESFire 36

47 2.2.6 Opencard Opencard je multifunkční čipová karta, která má obyvatelům a návštěvníkům hlavního města sloužit jako nástroj pro čerpání služeb poskytovaných Magistrátem hl. m. Prahy, institucemi zřizovanými hl.m. Prahou a dalšími partnery projektu. Karta Opencard má sloužit také jako prostředek pro podporu komunikace s městem a jeho úřady. Obrázek 28 karta Opencard Primární účel Opencard je náhrada za papírové kupóny v Pražské integrované dopravě, ale lze jí využít i dalšími způsoby: prostředek pro bezhotovostní úhradu parkování v zónách placeného stání, bezpečná identifikace pro vybrané on-line služby na Portálu hl. m. Prahy, prokazování nároku na slevy v rámci Městského a Komerčního slevového programu, aplikace Vím, jak řídím umožňuje nepodnikajícím fyzickým osobám zjistit jejich nevyřešené dopravní přestupky na území hl. m. Prahy. K projektu Opencard se přidávají i další instituce a kartu tak lze používat například i jako průkazku do Městské knihovny v Praze nebo do Národní technické knihovny. Karta je nabízena ve více variantách, s různou podporou kryptografických funkcí a různou velikosti paměti. Čip používá operační systém DESFire operating system. Karta se starším čipem MF3 IC D40 využívá blokovou šifru 3DES, nový typ s čipem EV1 poskytuje podporu 128bitové blokové šifry AES a je vybaven bezpečnostní certifikací Common Criteria EAL 4+. Pro účely práce byla použita karta se starším čipem MF3 IC D40. 37

48 38

49 3 Analýza přípravku Proxmark III Proxmark je speciální open-source RFID testovací zařízení původně sestrojené Jonathanem Westhuesem, které umožňuje odposlech RFID komunikace, čtení a klonování RFID tagů pracujících jak na nízké frekvenci 125kHz tak i na vysokofrekvenčních 13,56MHz. Jak napovídá název Proxmark III, jedná se již o třetí řadu přípravku s původním jménem Prox, odvozeného z anglického spojení proximity cards, které označuje bezkontaktní karty. Přípravek je k možno zakoupit na [15] nebo jej lze sestavit podle open-source plánu z [16]. Texty kapitoly 3 vychází z [5], [6]. 3.1 Hardware Díky své konstrukci je Proxmark univerzálním nástrojem, který může zvládat veškeré potřebné operace s čipovými kartami komunikujícími na nízkých frekvencích 125kHz a 134kHz, ale i na vysokofrekvenčních 13,56MHz. K zachycení a vysílání signálů jsou určeny dva paralelní anténní obvody, které pracují nezávisle. Oba obvody jsou vyvedeny na 4pinový konektor Hirose, který slouží k připojení externí antény k přípravku. Anténa zachycuje analogový signál, který je následně přenášen do 8bitového analogově-digitálního převodníku (ADC). Signál je zpracován a na výstup je předáno paralelně 8 bitů, které reprezentují úroveň napětí získanou z pole. Ty jsou následně vedeny do programovatelného hradlového pole FPGA. FPGA zde umožňuje simulaci libovolného hardwaru na základě nahraného firmwaru a zároveň zaručuje také rychlejší zpracování základních operací. Provádí demodulaci signálu z ADC a přeposílá ho jako digitální kódovaný signál mikroprocesoru ARM, má na starost i následnou modulaci v opačném směru. V závislosti na typu komunikace, která probíhá, se jedná buď o tzv. Amplitude Shift Keying signálu od čtečky nebo o zátěžovou modulaci karty. V prvním případě se používá modifikované Millerovo kódování signálu, v druhém případě se aplikuje kódování Manchester. 39

50 Obrázek 29 Rozmístění HW prvků Proxmarku Mikroprocesor ARM pak získané vzorky signálu z FPGA dekóduje. Vzorky jsou binární sekvence, reprezentující nízkou resp. vysokou úroveň signálu a jsou uloženy v DMA zásobníku. Když některá z obslužných procedur, která vzorky dekóduje, vrátí validní zprávu, je zpráva uložena do pole nazvaného BigBuf. Odtud je pak pomocí dalšího příkazu z klientské části dále zpracovávána. Pro měření jsem využil sadu, která obsahovala hotový Proxmark III a LF anténu, HF anténa jsem vyrobil svépomocí podle instrukcí z [17]. Přípravek je standardně napájen skrz USB rozhraní a je ovládán skrze klienta na připojeném počítači. Tato varianta se pro provádění měření ukázala jako značně nepraktická z hlediska mobility, kdy je třeba spoléhat na počítači jako zdroji napájení, proto jsem při měřeních přípravek napájel pomocí baterie a využíval omezenou sadu zabudovaných příkazů (mód Stand-alone). Získaná data jsem pak do počítače přenesl pomocí USB kabelu s rozdvojkou pro posílené napájení. Nevýhodou Standalone módu je absence displeje, tudíž průběh jednotlivých operací lze sledovat pouze pomocí kontrolních LED. 40

51 3.2 Firmware Firmware Proxmarku se skládá ze tří částí: zavaděč (bootloader), konfigurační soubor pro FPGA (FPGA image) a přeložený zdrojový kód programu pro mikroprocesor ARM (OS image). Tyto základní komponenty jsou do přípravku primárně nahrávány pomocí USB rozhraní nezávisle na sobě. Bootloader obstarává nahrávání ostatních částí a celkově umožňuje zápis pomocí USB. Pokud je bootloader poškozen, musí se pro nahrávání použít rozhraní JTAG k jeho obnovení. Postup nahrávání a aktualizace firmwaru je popsán v příloze C. FPGA image je ve své podstatě konfigurací hardwaru, který je v přípravku vyžadován. OS image je pak hlavní součástí firmwaru a jeho verze určuje rozsah funkcí celého přípravku. Zařízení je dodáváno jen se základní neaktualizovanou verzí firmwaru, který je ale možno veřejně stáhnout z Internetu i se zdrojovými kódy [18]. Firmware lze tedy libovolně modifikovat a záleží jen uživateli, jak si firmware upraví a jaké konkrétní vlastnosti do přípravku doimplementuje. FPGA image je psán v jazyce Verilog, zbylé části firmwaru pak v jazyce C. Popis úprav a rozšíření firmwaru provedených pro účel této práce je dále popsán v kapitole Klient Klientská část se k Proxmarku připojuje pomocí protokolu HID a slouží pro zadávání příkazů z počítače a zpracovávání odpovědí. Operační systém na mikroprocesoru ARM nepředstavuje řádný real-time operační systém v tom smyslu, že stále čeká na příjem příkazů skrze USB pakety. Tímto způsobem není možné vysílat načtená data v reálném čase zpět klientovi. Když ARM obdrží příkaz od klienta, začne tento příkaz vykonávat a průběžně ukládá veškerá data ve své vyrovnávací paměti. Po dokončení příkazu musí klient zaslat nový příkaz, kterým data z vyrovnávací paměti získá. Starší verze firmwaru disponovaly grafickým rozhraním, ale díky faktu, že komunita Proxmark uživatelů je zcela otevřená, firmware podléhá neustálým aktualizacím a velmi rychle zastarává. Synchronizace s grafickým rozhraním by tak byla velmi obtížná, a proto většina uživatelů používá pouze konzolové rozhraní. To je spouštěno z příkazové řádky a 41

52 umožňuje vybrat příkazy z několika základních sekcí a podsekcí (viz Obrázek 30, pro účely práce jsou detailněji znázorněny jen podsekce týkající se ISO/IEC A). Základní sekce v klientské části: HW obslužné příkazy, nastavení hardwaru přípravku, LF příkazy pro nízkofrekvenční karty (125 a 134 khz) HF příkazy pro vysokofrekvenční karty (13,56 MHz) Struktura celého příkazu je pak složena z postupně zřetězených názvů sekcí, k nimž příkaz náleží. Obrázek 30 Sekce příkazů přípravku Proxmark III, podsekce HF Mezi základní a nejčastěji používané příkazy patří: hw tune z antény je odečtena úroveň napětí, hodnota je vypsána jak pro LF 125/134 khz tak pro HF 13,56MHz, hf 14a reader - Proxmark se v tomto módu chová jako čtečka a zaznamenává komunikaci s tagem, uloženou komunikaci je možné zobrazit pomocí příkazu hf 14a list, hf 14a snoop - Proxmark je využit jako sniffer, který zaznamenává komunikaci probíhající mezi čtečkou a kartou, hf 14a list - příkaz, pomocí kterého Proxmark vypíše obsah zaznamenané komunikace, hf 14a sim - Proxmark provede emulaci karty Mifare Classic se zadaným UID. Kompletní seznam příkazů a jejich stručný popis je uveden na [19]. 42

53 4 Návrh a realizace úprav firmwaru Jak jsem již zmínil, projekt Proxmark má poměrně velké množství členů, kteří k projektu přispívají. Bohužel, projekt zjevně postrádá důslednější koordinaci a pravidelnější revize kódu, neboť již při jeho zběžné prohlídce bylo zřejmé, že se zde vyskytuje velké množství problémů. Tyto problémy byly všeobecného charakteru, od chybějících nebo neúplných hlavičkových souborů, přes problémy s kompatibilitou napříč testovanými verzemi firmwaru až po problémy, kdy například část obslužných funkcí byla nahrazena novými verzemi, ale část projektu používala stále funkce staré a obě verze byly zachovány. V první řadě mě tedy čekala alespoň částečná revize a odstranění zmíněných nedostatků. Jako referenční jsem zvolil svn verzi 486 (firmware je dostupný z [18] ) a zaměřil jsem se především na úpravy a následné rozšiřování funkcionalit programu pro mikroprocesor ARM a klientské části, které se týkají karet pracujících na frekvenci 13,56MHz. Jelikož Proxmark kromě Mifare Classic neposkytoval pro karty na této frekvenci žádnou podporu, rozhodl jsem se, že implementuji mód, kdy Proxmark bude vystupovat jako falešná čtečka. V tomto módu by Proxmark umožňoval odesílání libovolných příkazů kartě, která komunikuje skrze protokoly ISO A a ISO Pomocí těchto příkazů by bylo možné kartu blíže prozkoumat a zjistit detailnější informace o jejím obsahu. Dále jsem se zaměřil na konkrétní typ karet - Mifare DESFire, pro který jsem se rozhodl na základě falešné čtečky vytvořit automatizovaný mód pro rychlé prozkoumání obsahu tohoto typu karet a také simulátor, aby byl Proxmark schopen jako tento typ karet i vystupovat. 43

54 4.1 Úpravy původního firmwaru Původní klientská sekce hf, týkající se 13,56MHz byla v průběhu vývoje rozdělena na dvě podsekce 14a a mf. První podsekce obsahovala obecné příkazy pro zjištění typu karty, pořízení záznamu komunikace mezi kartou a čtečkou a jeho výpis, druhá sekce vznikla později odloučením příkazů specifických pouze pro Mifare Classic. V kódu určeném pro OS image bohužel k podobnému rozdělení nedošlo a všechny funkce byly uloženy v jednom velmi nepřehledném souboru, jehož délka se pohybovala v řádech tisících řádků kódu. Po odstranění dalších nedostatků jako byly neúplné nebo chybějící hlavičkové soubory, množství mrtvého kódu a další popsané případy v předchozí kapitole jsem se proto zaměřil na separaci jednotlivých funkcí do příslušných souborů, aby struktura byla čitelnější a korespondovala s klientskou částí. Zároveň s úpravami jsem prováděl testování (viz kapitola 4.4) se zaměřením na ověření funkčnosti jednotlivých příkazů. V sekci 14a byl od počátku zřejmý problém s kombinací příkazů snoop a list, kdy zachycená komunikace byla vypisována nekompletní. Jako příčinu jsem identifikoval jednak staticky nastavenou velikost přijímacího zásobníku na velmi malou hodnotu (pouze 1920 bytů), která byla pro praktická měření naprosto nepoužitelná. Druhotně zde docházelo k přetečení zásobníku, kdy v modulačních a demodulačních procedurách kompletně chyběly kontroly, zda cílový zásobník ještě obsahuje volné místo. Po odstranění těchto nedostatků jsem byl schopen podstatně zvětšit kapacitu záznamu komunikace. V případě potřeby je možné kapacitu zásobníku upravit skrze konstanty v hlavičkovém souboru iso14443a.h. V sekci mf jsem narazil na problémy se simulací karty Mifare Classic, kdy klientská část tvrdila, že je prováděna simulace karty se zadaným UID, nicméně Proxmark simuloval UID nulové. Inspekcí kódu jsem zjistil, že uživatelem zadané UID není klientem vůbec odesíláno, a že se Proxmark pokouší o simulaci UID, které bylo staticky nastavené v kódu OS image. U tohoto UID navíc neodpovídala jeho délka v bytech, proto docházelo ke kolizi a bylo simulováno UID nulové. Poté, co jsem doplnil odesílání zadaného UID a jeho navazující zpracování, měl být Proxmark schopen simulace libovolné karty Mifare Classic, nicméně v části případů se při simulaci vyskytl problém, kdy čtečka nebyla schopna simulovanou kartu přečíst. Po prozkoumání vysílaného signálu pomocí osciloskopu jsem objevil chybu v modulaci signálu, která představovala zásadní překážku v simulaci některých typů karet. Podle normy ISO/IEC se nesmí v případě, kdy nejsou přenášeny žádné informace 44

55 vyskytnout žádná modulace po dobu trvání jednoho bitu. Ve funkci EmSendCmd14443aRaw, která zpracovává signál a odesílá ho, však byla do stavového registru špatně přiřazována hodnota a následkem toho mohla proběhnout detekce ukončení vyslané zprávy na straně čtečky špatně a celá komunikace se ukončila nekorektně. Tato chyba tak představovala problém, který prakticky znemožňoval simulaci, zejména u čteček citlivějších na časování. Na Obrázku 31 je zachyceno pomocí osciloskopu odesílání signálu ATQA karty Mifare Classic s chybou a následně po jejím odstranění. Obrázek 31Zachycený signál ATQA s chybným a opraveným firmwarem Pomocí kontrolních výpisů příkazem list jsem narazil na další chybu. Jednalo se o špatné generování a zacházení s paritními bity. Sekce čtečky generovala paritní bity v převráceném pořadí než sekce simulace a výsledkem tak bylo, že při kontrole parity byly některé byty označovány jako neplatné. Obrázek 32 Seznam opravených funkcí původního firmwaru Pro lepší využitelnost přípravku při analýze bezpečnosti jsem dále v původní verzi firmwaru modifikoval příkaz reader a tzv. Standalone mód, kdy je Proxmark schopen pracovat nezávisle na klientské části a je napájen pomocí baterie, což značně zjednoduší měření v reálném provozu. Do Standalone módu jsem zabudoval funkce, jak z původního firmwaru tak i posléze nově doplněné. Popis Standalone módu a začleněných funkcí je uveden v příloze D. Příkaz reader jsem doplnil o identifikaci nových druhů karet na základě kombinace získaných údajů SAK a ATQA. 45

56 4.2 Mód karty Mód karty představuje rozšíření původního firmwaru o simulátor karet Mifare DESFire tak, aby byl Proxmark schopen jako tato karta vystupovat. Pro realizaci simulátoru jsem určil jako nezbytné tyto body: vytvořit repliku nastavitelného souborového systému, umět odesílat a zpracovávat TPDU bloky, umět zpracovávat APDU bloky, umět reagovat na vybrané příkazy z instrukční sady. Repliku souborového systému karty jsem vytvořil v paměti Proxmarku pomocí pole struktur, které odpovídají reálnému systému karty Mifare DESFire. Souborový systém uchovává informace o identifikátorech aplikací, jejich klíče, soubory, respektive data souborů a verze souborů a klíčů. Podkladové informace jsem převzal z [3]. Pro účely demonstrace a také z důvodů kapacity paměti přípravku jsem omezil počet klíčů pouze na jeden, jinak je souborový systém kopií systému na skutečné kartě. K obsluze souborového systému jsem dále vytvořil několik podpůrných příkazů, pomocí nichž lze manipulovat s obsahem systému. Jedná se o příkazy: initfs, setdesmem, setdesmasterkey, setdesappkey. Po spuštění klienta je souborový systém automaticky inicializován pomocí příkazu initfs na nulové hodnoty a je možné skrze ostatní pomocné příkazy nastavit a modifikovat jeho obsah. Příkaz setdesmem umožňuje nastavit AID identifikátory virtuálních aplikací a obsahy případných souborů těchto aplikací, zbylé dva příkazy pak slouží k nastavení klíčů použitých při šifrování. Pro odesílání APDU bloků jsem chtěl původně využít již zabudovanou funkci iso14_apdu. Ukázalo se však, že původní funkce neobsahovala podporu identifikátorů CID ani NAD a tím pádem byla pro univerzální simulátor nepoužitelná. Byl jsem tedy nucen kompletně přepsat její strukturu a provedl jsem její přejmenování na iso14_wrapped_apdu. Zavedl jsem také nové globální boolean proměnné CIDpresent a NADpresent, které jsou nastaveny podle obdrženého RATS jak je popsáno v normě ISO a určují, zda jsou dané identifikátory při komunikaci použity či nikoliv. Pomocí těchto proměnných je pak 46

57 řízena jak tvorba vlastního TPDU, kdy se v jeho rámci určí pozice APDU, tak i parsování zachyceného příchozího příkazu od čtečky a následná extrakce APDU. Při zkoumání odposlechnuté komunikace jsem zjistil, že v případě APDU se používají dva typy, které se vzájemně liší strukturou. Od APDU popsaného v kapitole 1.4 se druhý typ liší tím, že obsahuje pouze parametry INS a DATA, kterou jsou pak umístěny do TPDU na pozici informačního pole. Proto jsem vytvořil i metodu, která slouží pro tvorbu tohoto typu APDU. Vlastní simulátor jsem situoval do sekce 14a pod příkaz simdes. Základní architekturu jsem převzal ze simulátoru karet Mifare Classic a přepracoval ho pro typ DESFire. Simulátor je založen na jednoduchém principu, kdy jsou v cyklu while přijímány jednotlivé příkazy obdržené od čtečky a následný parsing určuje příslušné zpětné odezvy. Pro zpracování datových bloků jsem vytvořil tři funkce TestIblock, TestRblock a TestSblock, které urychlují zpracování daného typu bloků a tím i rychlejší určení odezvy. Ty jsou členěny do několika skupin, které odpovídají stavům, ve kterých se může karta při komunikaci vyskytnout a jsou definovány v normě ISO/IEC Jako příklad lze uvést stavy select, authenticate, idle, halt ap. Struktura tak zároveň umožňuje maximální urychlení komunikace i rychlejší orientaci v kódu a tím pádem i případné snadné rozšíření o další příkazy. Implementace simulátoru zahrnuje příkazy z instrukční sady Mifare DESFire a příkazy, které byly zachyceny při komunikaci karet s reálnou čtečkou pomocí příkazu snoop. Jedná se o základní množinu příkazů, které jsou vyžadovány pro úspěšnou simulaci karty. Podporovány jsou příkazy: Get Version Info, Select Application, Get Application IDs, Authenticate, Read Data, Write Data, Get Key Settings, Get Key Version. Dále jsem implementoval pravidla číslování bloků z kapitol a normy ISO , které se týkají potvrzování a R bloků. Pro potřeby autentizace byl firmware rozšířen o šifru 3DES [20], kterou jsem modifikoval podle informací z [3]. Seznam a struktura jednotlivých příkazů je uvedena v příloze E. 47

58 4.3 Mód čtečky Mód čtečky představuje rozšíření firmwaru o možnost, kdy Proxmark vystupuje jako falešná čtečka a umožňuje odesílání libovolných příkazů kartě, která komunikuje pomocí protokolu ISO A a ISO Z důvodu návaznosti a způsobu zpracování vstupních dat ve zbytku projektu jsem navrhl a příkaz sendcmd, tak, že umožňuje odeslat kartě v podstatě libovolné množství příkazů vzájemně oddělených středníkem, případně lze odesílat též příkazy jednotlivě. Příkazem je v tomto kontextu chápáno APDU a to jak nativní struktura podle ISO tak i APDU podle ISO Předávání příkazů jsem se rozhodl realizovat tak, že je v klientské části postupně zpracovávám a průběžně odesílám mikroprocesoru. Na straně mikroprocesoru jsou pak příkazy ukládány do pomocného zásobníku, odkud jsou pak postupně odesílány až při simulaci, která je spuštěna s obdržením posledního příkazu. K tomuto řešení jsem se přiklonil zejména vzhledem k tomu, že struktura USBCommand, která slouží pro výměnu dat mezi klientem a Proxmarkem, má v sobě přesně určenou maximální délku dat, která stačí pro přenos pouze jednoho příkazu. Pokud by byly příkazy odeslány do simulace ihned, hrozilo by, že následující příkaz potřebný v simulaci nebude zpracován a doručen včas. Karta by přešla do stavu nečinnosti a bylo by třeba provádět znovu antikolizní proceduru, a tím pádem by nebylo možné simulovat příkazy, které vyžadují odesílání více rámců. Ve vlastní implementaci tedy klient provádí parsing zadaného vstupu a odesílá jednotlivé příkazy, které jsou ukládány na straně mikroprocesoru do nově vytvořeného zásobníku CmdBuf, který je alokován z hlavního zásobníku BigBuf. Velikost zásobníku a tím i množství příkazů, které lze odeslat je opět snadno modifikovatelné skrze konstantu offsetu v hlavičkovém souboru iso14443a.h. Jakmile Proxmark obdrží poslední příkaz, u kterého je nastaven konečný příznak, provede simulaci antikolizní procedury a postupně ze zásobníku odešle všechny obdržené příkazy s využitím metody iso_14apdu. Odezvu karty na jednotlivé příkazy je poté možné zobrazit pomocí příkazu list. Na principu příkazu sendcmd jsem dále implementoval příkaz probedes, po vzoru utility NFC TagInfo z mobilního telefonu Samsung Google Nexus S, který byl použit při testování (princip aplikace byl rekonstruován na základě zaznamenané komunikace pomocí příkazu snoop). Příkaz provede průzkum přiložené karty a pokouší se z ní zjistit co nejvíce informací pomocí příkazů Get Version, Get Application IDs, Get Key a File Settings, Get Key a File Version a následně provádí čtení z možných uložených souborů. Kromě údajů 48

59 získaných při antikolizi je tak jedním příkazem možné zjistit, jaké aplikace jsou na kartě uloženy, počet a typ uložených klíčů a zda jsou např. data na kartě chráněna šifrováním nebo zda je k jejich čtení vyžadována autentizace. 49

60 4.4 Testování Pro testování původního firmwaru a nově implementovaných funkcí jsem zvolil čtečku OMNIKEY CardMan Jedná se o čtečku s duálním rozhraním, která umožňuje čtení i zápis jak pro bezkontaktní, tak i pro kontaktní čipové karty operující na frekvenci 13,56 MHz. Čtečka je kompatibilní se specifikací norem ISO A i B a a umožňuje komunikaci na rychlosti až 848 kbps. V kombinaci se čtečkou jsem využíval utilitu OMNIKEY diagnostic tool pro určení UID karet a program gscriptor [21], který umožňuje pomocí připojené čtečky odesílat kartě libovolné množství příkazů pomocí skriptu. Obrázek 33 Čtečka Cardman 5321 Dalším testovacím zařízením byl mobilní telefon Samsung Nexus S s podporou NFC komunikace a operačním systémem Android Gingerbread 2.4. Tento mobilní telefon v sobě obsahuje čip PN65N od společnosti NXP, jedná se o kombinací PN544 NFC kontroléru a vestavěného bezpečnostního prvku SmartMX secure element, který využívá stejné osvědčené bezpečnostní řešení jako platební karty, elektornické doklady, nebo jiné bezkontaktní aplikace založené na řešeních od firmy NXP. K testování byla využita aplikace NFC TagInfo. Obrázek 34 Mobilní telefon Samsung Nexus S 50

61 Při testování firmwaru jsem se zaměřil pouze na funkcionality týkající se standardu ISO/IEC A. Testování jsem prováděl ve třech fázích. Před započetím prací na modifikaci firmwaru jsem nejprve otestoval funkčnost původního firmwaru, abych odhalil jeho případné nedostatky a mohl je odladit. V druhé fázi jsem pak průběžně testoval vyvíjená a implementovaná rozšíření firmwaru. Třetí fází testování pak bylo vlastní vyhodnocení bezpečnosti zvolených karet, při kterém hrál Proxmark klíčovou roli, a které je popsáno v kapitole 5. V první fázi jsem se nejprve zaměřil na testování uživatelského rozhraní a klientské části, kde jsem pomocí kontrolních výpisů provedl ověření: korektního zobrazení manuálu k jednotlivým příkazům, odolnosti vůči špatným nebo nestandardním vstupům, zpracování a předání parametrů pomocí USB rozhraní. Dále jsem se zaměřil na testování jednotlivých příkazů ze sekce hf. Při testování jsem využíval čtečku Cardman, program OMNIKEY diagnostic tool a několik různých druhů karet kompatibilních se standardem ISO/IEC A. V této fázi jsem narazil na několik pochybení a závad, jednalo se zejména o příkazy: hf 14a snoop, hf 14a list, hf 14a sim1k. Nalezené závady a jejich odstranění jsem již popsal v kapitole 4.1. Druhá fáze se skládala z otestování módu karty a módu falešné čtečky. Mód karty, tedy příkaz simdes, kdy Proxmark vystupuje jako simulátor karty Mifare DESFire jsem testoval pomocí čtečky Cardman a programu gscriptor. Odesílal jsem Proxmarku jednotlivé příkazy z instrukční sady, které byly implementovány do simulátoru (viz příloha E) a ověřil autenticitu odpovědí oproti reálné zaznamenané komunikaci z příkazu snoop. Simulátor jsem otestoval i s nastaveným fiktivním obsahem paměti pomocí příkazu setdesmem. U simulátoru jsem prověřil následující případy: korektnost komunikace při přítomných/chybějících identifikátorech CID a NAD, komunikaci pomocí datových bloků pro nativní i zabalené APDU, možné chybové scénáře u jednotlivých příkazů, o přijetí neznámého příkazu, o špatná délka přijaté odpovědi, o použití neexistujícího klíče, o výběr neexistující aplikace, 51

62 o čtení a zápis bez vybrané aplikace, o čtení a zápis ze souboru se špatnými parametry, o čtení z neexistujícího souboru, o vyžadování autentizace pro čtení a zápis, o zneplatnění autentizace při výběru jiné aplikace. K testování zabalených apdu jsem využil mobilní telefon Nexus S utilitou NFC TagInfo, neboť ta využívá pro komunikaci právě APDU podle normy ISO Všechny zmíněné testy proběhly u módu karty korektně a bez problémů. Mód čtečky a příkaz sendcmd, kdy Proxmark představuje falešnou čtečku jsem zkoušel na kartách Mifare DESFire, a to jak běžně používané kartě (Opencard) tak i nově zakoupené, kde jsem mohl vyzkoušet kompletní průběh autentizace díky známému defaultnímu klíči. Kartě jsem poté z počítače pomocí konzolového rozhraní přes Proxmark odesílal příkazy instrukční sady a to jak jednotlivě, tak i po skupinách. Testovány byly opět oba druhy APDU. Karta ve všech případech odpovídala korektně a nevyskytly se žádné problémy. 52

63 5 Vyhodnocení bezpečnosti vybraných čipových karet Analýzu bezpečnosti jsem prováděl pro dva zvolené typy bezkontaktních karet Mifare Classic a Mifare DESFire, konkrétně se jednalo o studentský průkaz ČVUT a Opencard. Analýzu obou druhů karet jsem rozdělil na několik částí. Jako první jsem se rozhodl provést odposlech komunikace karet s reálnou čtečkou. Odposlech komunikace jsem prováděl současně s úpravami původního firmwaru, neboť jsem tak mohl funkce původního firmwaru řádně otestovat a zároveň využít cenné informace z reálného provozu pro vývoj a implementaci nových funkcionalit. V případě studentského průkazu jsem se poté zaměřil na prozkoumání možnosti prolomení ochrany karty, získání uložených dat a následného vytvoření klonu karty. U Opencard jsem se zaměřil zejména na průzkum jejího využití jako průkazu identity při logování do různých systémů nebo přístupových systémů budov. 5.1 Odposlech komunikace Mifare Classic Odposlech komunikace jsem prováděl mezi studentským průkazem ČVUT a čtečkou na dveřích laboratoří v Nové budově ČVUT. Po zadání příkazu hf 14a snoop a přiložení karty s anténou ke čtečce zaznamená Proxmark komunikaci a tu lze následně zobrazit příkazem hf 14a list. Z výpisu zachycené komunikace je mj. možné podle položek ATQA a SAK ověřit, že se skutečně jedná o čip Mifare Classic 1K. Z výpisu je rovněž okamžitě patrný UID identifikátor a schéma celé komunikace (viz Obrázek 35). Čtečka provede s kartou pouze antikolizní proceduru a po výběru karty je komunikace ukončena. To v praxi znamená, že na ověření identity je použito jen UID karty a nejsou vyžadovány žádné datové bloky z karty ani jiná ověření. Tato varianta, kdy je oproti databázi porovnáno jen získané UID se jeví jako zásadní bezpečnostní trhlina, neboť UID lze snadno simulovat. Tento nedostatek bude zmíněn dále i v kapitole 5.3 Simulace Mifare Classic. 53

64 Obrázek 35 Záznam komunikace studentského průkazu 54

65 5.2 Získání dat z Mifare Classic Pro získání dat z paměti Mifare Classic jsem musel nejdříve získat příslušné klíče. Ty jsem získal pomocí MFCUK útoku příkazem hf mf mifare. Výstupem je ve většině případů validní klíč (viz Obrázek 36). Pokud by byl nalezený klíč neplatný, tak lze příkaz opakovat s parametrem Nt z předchozího běhu příkazu. Obrázek 36 Výstup útoku MFCUK Platný klíč jsem během měření několika různých průkazů nalezl vždy nejdéle do pěti minut. Při měření jsem zjistil, že všechny vydávané průkazy mají v paměťových blocích které již neobsahují žádná data ponechány defaultní šifrovací klíče od výrobce. Tato skutečnost představuje bezpečnostní trhlinu umožňující aplikaci útoku MFOC. Útok MFOC tak může odhalit zbylé klíče k jednotlivým sektorům paměti. Použitý příkaz má strukturu hf mf nested 1 0 a <key>, kde 1 určuje velikost paměti karty, 0 symbolizuje číslo bloku paměti, key je klíč získaný MFCUK útokem a a značí typ použitého klíče (typ A/typ B). 55

66 Obrázek 37 Výstup útoku MFOC Po obdržení tabulky se všemi klíči (typ A i B, viz obr 37) lze používat příkazy hf mf rdbl pro čtení vybraného bloku, hf mf rdsc pro čtení vybraného sektoru nebo hf mf wrbl pro zápis do vybraného sektoru. Všechny tři příkazy mají stejnou syntaxi, jako tři parametry se uvádějí číslo bloku/sektoru, typ klíče a příslušný klíč daného bloku/sektoru. Získaná data je rovněž možno uložit pomocí příkazu hf mf dump1k do binárního souboru, odkud mohou být později znovu načtena k dalšímu použití. Struktura získaných dat: blok 0: UID karty, údaje o výrobci, blok 1: číslo studenta, blok 2: číselná reprezentace čárového kódu na kartě, blok 4: jméno, blok 5: příjmení, blok 8: datum vydání, blok 13: rodné číslo. Porovnáním výpisů klíčů ze studentských i zaměstnaneckých karet jsem zjistil, že všechny karty bez rozdílu využívají stejné šifrovací klíče. Potencionálnímu útočníkovi by tak stačilo provést útok na jedné kartě a získané klíče pak může dle libosti použít na kteroukoliv kartu a doba potřebná pro získání otisku kompletní paměti karty se tak rapidně snižuje na řádově jednotky až desítky sekund. 56

67 5.3 Simulace Mifare Classic Simulaci je možné spustit dvěma způsoby. První možností je příkaz hf mf sim1k <4B UID>, kdy probíhá nepřetržitě simulace antikolize se zadaným UID až do okamžiku, než je ukončena stiskem tlačítka na přípravku. Druhou možností je uložení klíčů při extrakci do binárního souboru pomocí příkazu mifare a z něj tyto data poté načíst do simulátoru a provést simulaci kompletní plnohodnotné karty. V kapitole 5.1 bylo uvedeno, že ověření identity průkazem ČVUT využívá pouze kontrolu UID, takže stačilo využít první způsob. Tuto slabinu jsem ověřil úspěšnou simulací studentského i učitelského průkazu na čtečkách v přístupových místech v Nové budově a FSv ČVUT (Obrázek 38). Obrázek 38 Průchod turnikety v budově ČVUT pomocí Proxmarku Dále jsem prováděl simulaci karty u vjezdového terminálu do garáží v Nové budově ČVUT. Zde jsem zjistil, že systém je opět založen pouze na kontrole UID karty a bez problémů jsem tak projel vozem na simulovanou kartu. Tato skutečnost se při již nezanedbatelných částkách parkovného jeví jako zásadní bezpečnostní pochybení. Dalším měřením jsem zjistil, že tento bezpečnostní nedostatek je kompenzován faktem, že systém je navržen tak, aby nepovolil vjezd dvou vozidel prokazujících se na stejnou kartu. Případné zneužití by tak šlo zřejmě odhalit pomocí kamerových záběrů a vzniklou škodu vymáhat zpět. 57

68 5.4 Odposlech komunikace Mifare DESFire Aplikace jízdného MHD V případě této nativní aplikace jsem chtěl ověřit zejména to, zda karta komunikuje podle pravidel předepsaných v normě ISO A. Odposlech jsem prováděl ve validátorech kupónů pro čerstvě zřízenou Opencard i používanou Opencard. Pro obě karty jsem také zaznamenal nahrávání nového kupónu ve validátoru. Ukázka zaznamenané komunikace je na Obrázku 39. Obrázek 39 Záznam komunikace z aplikace jízdné MHD Zajímavostí je skutečnost, že použitý protokol se neřídí striktně normou, neboť používá odlišné číslování datových bloků při komunikaci. Nicméně ze záznamu komunikace pořízené Proxmarkem lze v případě aplikace jízdného konstatovat, že zabezpečení je dostačující. Prolomení šifry 3DES použité pro autentizaci a následné šifrování komunikace je hrubou silou takřka nemožné. Jediný známý útok na Mifare DESFire využívá analýzy postranních kanálů a publikovali ho Dr.-Ing. Timo Kasper, Dipl.-Ing. David Oswald a Prof. Dr.-Ing Christof Paar z Ruhr Universität v Bochumi [22]. Tento útok je však velmi časově náročný a navíc vyžaduje nepřetržitý fyzický přístup ke kartě. 58

69 5.4.2 Průkaz Městské knihovny Využití Opencard jako průkazu do Městské knihovny provázel bezpečnostní incident, kdy přihlášení k systému knihovny probíhalo pouze na základě identifikátoru UID a pokud uživatel neměl nastavené heslo, bylo možné získat veškeré jeho osobní informace. Proto byl zaveden ochranný prvek v podobě zadání posledních čtyř čísel z čísla Opencard. I tuto ochranu se podařilo útočníkům obejít s využitím tzv. knihomatů. Zde mohl útočník získat pomocí simulovaného UID karty výpis informací o uživateli, včetně čísla Opencard a s ním se opět do systému přihlásit. Při analýze průkazu jsem se zajímal zejména o prozkoumání stávající situace zda nezabezpečený stav nadále trvá, případně jaké kroky byly podniknuty pro nápravu systému. Nápravná opatření byla patrná již při samotné registraci - nový čtenář si musí zvolit přístupové heslo nezávislé na Opencard. Z měření u knihovních terminálů jsem vyvodil, že přihlášení se děje stále pouze na základě identifikátoru UID (viz. Obrázek 40), ale poté musí uživatel zadat příslušné heslo a teprve poté je vpuštěn do systému. Zanesením tohoto nezávislého prvku se tak eliminovala možnost simulace karty a případný útočník se nedostane k citlivým informacím. Obrázek 40 Záznam komunikace z Městské knihovny 59

70 5.4.3 Průkaz Národní technické knihovny Opencard má v prostorách Národní technické knihovny několikanásobné využití. Jednak je používána jako identifikátor pro vstup, dále je pomocí ní možné se přihlásit k místní tiskárně a v neposlední řadě slouží jako průkaz pro výpůjčky publikací. Analýza knihovního terminálu pro výpůjčky knih (Obrázek 41) se ukázala jako složitější. Ze způsobu registrace nového čtenáře, kdy lze jako průkazku využít buď Opencard nebo platný studentský průkaz/isic je zřejmé, že na kartu není nahrána žádná další aplikace a jedná se o lokální systém pracující opět pouze s identifikátorem UID. Při pokusech o odposlech karty u výpůjčního terminálu jsem však zjistil, že terminály zřejmě používají vyšší přenosovou rychlost, než kterou Proxmark v současnosti podporuje a tím pádem není možné komunikaci zachytit. Nicméně průběh registrace nasvědčuje tomu, že případná následná emulace karty by zde byla úspěšná, neboť systém nevyužívá žádné dodatečné heslo a bylo by tak možné se do něj úspěšně přihlásit. Obrázek 41 Knihovní terminál v Národní technické knihovně 60

71 5.5 Simulace Mifare DESFire Simulace Mifare DESFire byla limitována z důvodů neznámých šifrovacích klíčů a nemohla tak být ozkoušena simulace kompletní reálné karty včetně autentizace. Zaměřil jsem se proto tedy alespoň na simulaci případů, kdy jsem na základě odposlechu zjistil použití pouze identifikátoru UID, zejména na simulaci karty při vstupu do Národní technické knihovny a alespoň částečnou simulaci ve validátorech kupónů jízdného MHD (Obrázek 42). Obrázek 42 Validátor kupónů jízdného MHD Tento záměr se vydařil jen z části. I přesto, že při testech oproti čtečce Cardman a mobilnímu telefonu Nexus byla simulace vždy úspěšná, a to i v případě autentizace karty s výchozími klíči, při pokusech o simulaci ve čtečkách v běžném provozu simulace selhala. Porovnal jsem tedy proto záznamy komunikace Opencard a simulované karty (Obrázek 43), které obsahují zaznamenané časové údaje o době odesílání jednotlivých příkazů. Ze záznamu je patrné, že doba odesílání příkazů je u simulované karty několikanásobně delší. Obrázek 43 Rozdíly v časování simulace Mifare DESFire Při následném detailním prozkoumání simulované komunikace pomocí osciloskopu jsem zjistil, že doba od přijetí posledního bitu komunikace ze strany čtečky do začátku vysílání 61

72 odpovědi simulovanou kartou přesahuje časová omezení normy ISO 14443A-3. V té je definována tzv. doba zpoždění rámce komunikace. V případě, že poslední bit komunikace byla logická nula, je doba zpoždění rámce přibližně rovna hodnotě 86,43 mikrosekund, v případě logické jedničky se pak jedná o hodnotu 91,15 mikrosekund. Proxmark tyto hodnoty však přesahuje v průměru o 10 mikrosekund (ukázka prodlení komunikace mezi přijetím příkazu čtečky a vysláním odpovědi je na Obrázku 44), čtečka díky tomu danou komunikaci vyhodnotí jako neplatnou a komunikace je ukončena. Obrázek 44 Časové prodlení v modulaci signálu simulace Mifare DESFire Jako příčinu zpoždění jsem identifikoval nedokonale navrženou původní architekturu, kdy žádná část odesílaných příkazů nebyla napočtena dopředu a modulace jednotlivých příkazů byla prováděna až za běhu vlastní simulace. Simulace díky tomu nebyla schopna splnit striktní požadavky, které čtečky v oblasti časování v reálném provozu kladou. Upravil jsem proto simulátor tak, aby se výpočet kontrolních součtů CRC a následná modulace signálů antikolize prováděly před zahájením simulace, což vede k urychlení komunikace. Následně jsem v příkazu ATS pomocí parametru SFGI, který určuje ochrannou dobu pro kartu, než je připravena pro příjem dalšího rámce, prodloužil dobu nutnou ke zpracování a přípravě jednotlivých signálů. S touto modifikací se mi podařilo úspěšně simulovat Mifare DESFire u vstupních turniketů v NTK. V případě validátoru Opencard se však simulace nezdařila, neboť z informací plynoucích z [3] jsou požadavky na časování ve fázi antikolize u Mifare DESFire ještě striktnější než je definuje norma ISO 14443A-3 a potřebné úpravy by tak vyústily v kompletní změnu architektury obslužných procedur. Tento zásah by byl velmi komplikovaný, neboť inkriminované funkce jsou využívány i v sekcích pro jiné typy karet a vyústil by tak v přepracování základních principů zacházení se signály v celém projektu. 62

73 6 Závěr Průzkum studentského průkazu ČVUT pomocí přípravku Proxmark odhalil několik závažných bezpečnostních trhlin a potvrdil tak fakt, že karty Mifare Classic jsou již dnes z bezpečnostního hlediska přežitkem. Útočník i s minimálními znalostmi o problematice může bezpečnostních nedostatků karty snadno využít a např. se volně pohybovat v prostorách s omezeným přístupem ap. Řešení situace je možné několika způsoby. Nahrazení karty Mifare Classic jiným typem. Bezpečnostním doporučením, které řeší publikované slabiny čipu Mifare Classic zcela, je výměna této karty za jiný, bezpečnější typ, např. Mifare DESFire. Náklady s tímto spojené - nový systém, nákup karet a dalšího vybavení by byly ale zřejmě neúnosně vysoké, nehledě na organizační problémy se změnou spojené. Další možností by tak mohla být úprava stávajícího systému, díky čemuž by se provedení útoků ztížilo nebo omezilo. Nelze je však zcela vyloučit. Pro autentizaci osob používat dodatečný prvek. Při implementaci karty pro jakékoli účely by nikdy nemělo docházet k autentizaci karty jen na základě UID. UID je sice jedinečný identifikátor, který není možné u vyrobené karty změnit, existují ale přípravky typu Proxmark, které UID umí simulovat. Autentizace by proto měla být vždy svázána jak s UID, tak i s dalším prvkem, který je obsažen v paměti karty a je přístupný po znalosti odpovídajícího přístupového klíče. Diverzifikace klíčů. Diverzifikace klíčů spočívá v přidělení zvláštního klíče každé kartě. Díky tomu nedochází k prolomení celého systému při získání jednoho klíče z jedné karty. Klíče by ideálně měly být unikátní, ale není to podmínkou. Pokud je některý z klíčů použit opakovaně jen v několika případech, jedná se o malé ohrožení. Pokud by byly tyto změny implementovány do stávajícího systému, tak by se výsledná bezpečnost karet a tím i bezpečnost celého systému rapidně zvýšila. Z analýzy získaných dat odposlechu Opencard vyplývá, že nativní aplikace na kartě jsou dostatečně zabezpečeny proti útokům na použitou šifru. Předmětem dalšího výzkumu by tak mohl být například tzv. přepojovaný útok neboli relay attack, kdy dochází pouze k umělému prodloužení komunikace na větší vzdálenost a otázky šifrování tak nejsou vůbec řešeny. 63

74 Přímé bezpečnostní slabiny vedoucí ke ztrátě osobních dat však mohou představovat instituce, které se k projektu Opencard budou přidávat, neboť funkcionality typu průkazů do knihoven ap. jsou jen přidanou funkčností nad rámec karty, nejsou do ní integrovány a nevyužívají její protokol. Zde pak závisí na konkrétním řešení bezpečnosti dané instituce. Bylo by proto vhodné vypracovat alespoň rámcovou metodiku, která by stanovovala základy bezpečného systému a použití karty. Dodatečnými obecnými opatřeními pro zlepšení bezpečnosti mohou být např. i použití kovového pouzdra na kartu nebo vedení blacklistu karet. V případě kovového obalu ke kartě nepronikne elektromagnetické pole a díky tomu s ní není možno navázat komunikaci. Tím lze zabránit card only útokům např. v MHD a dalších prostorách, kde by jinak bylo možno nepozorovaně s kartou komunikovat a získat tak data potřebná pro vytvoření jejího klonu. Jako stínění postačí hliníková fólie, která může být vložena v peněžence nebo jiném obalu, kde je karta uložena. Někteří výrobci již nabízejí průmyslově vyráběné RFID stíněné peněženky. V případě zřízení blacklistu by se karta na blacklist měla dostat při podezření na manipulaci s jejím obsahem nebo v případě výskytu jejího klonu, což se může projevit nekorektní komunikací s legitimní čtečkou nebo pokud karta neobsahuje správná data. Je také vhodné ověřovat použití karty na různých místech v krátkých časových intervalech, kde je zřejmé, že nemohlo dojít k fyzickému přesunu karty v daném čase. Co se týče dalšího vývoje firmwaru přípravku Proxmark, bylo by vhodné přepracovat spojení s klientskou částí a navrhnout novou strukturu pro operační systém mikroprocesoru. To by umožnilo rychlejší komunikaci s dodržením přísnějších časových požadavků a tím i praktické využití Proxmarku pro výzkum bezkontaktních čipových karet do budoucna. Dále bych také vzhledem k obsazenosti paměti přípravku doporučil přechod ze statické alokace na dynamickou. Zde by bylo potřeba prozkoumat možnost začlenění potřebných knihoven do kompilačního prostředí. Dynamická alokace by umožnila hospodárněji využít paměť a umožnila tak další rozvoj projektu. 64

75 7 Literatura [1] Vomáčka, Jiří. Autentizační systémy na bázi bezkontaktních čipových karet. Brno, Bakalářská práce na Fakultě informatiky na Masarykově univerzitě. Vedoucí práce doc. RNDr. Václav Matyáš, M.Sc., Ph.D. [2] Wee Hon Tan. Practical Attacks on the MIFARE Classic. Diploma thesis, Imperial College, London. [online]. [cit ]. [3] MIFARE DESFire MF3 IC D40 datasheet [online]. [cit ]. [4] NXP Semiconductors. Mifare Classic 1K datasheet [online] [cit ]. [5] Verdult, R., de Koning Gans, G. Promark.org [online]. [cit ]. [6] de Koning Gans, Gerhard. Analysis of the MIFARE Classic used in the OV Chipkaart project Diploma thesis, Radboud University, Nijmegen. [online]. [cit ]. Chipkaart-project.html# [7] Kasper, Timo. Embedded Security Analysis of RFID devices. Diploma thesis, Ruhr- University, Bochum. [online]. [cit ]. embedd ed_security_analysis_of_rfid_devices.pdf [8] NXP Semiconductors. MIFARE Type identification procedure [online]. [cit ]. [9] Nohl, K., Plötz, H., Mifare, little security, despite obscurity. In Presentation on the 24th Congress of the Chaos Computer Club, Berlin, 2007 [online] [10] de Koning Gans, G., Hoepman, J.-H., and Garcia, F. D. A Practical Attack on the MIFARE Classic. In Procedings of the 8th Smart Card Research and Advanced Applications, CARDIS 2008, LNCS. [11] Garcia, F. D., van Rossum, P., Verdult, R., Wichers Schreur, R. Wirelessly Pickpocketing a Mifare Classic Card. In Security and Privacy, IEEE Symposium on, pp. 3-15, th IEEE Symposium on Security and Privacy. [online] 65

76 [12] Courtois, N. T., The dark side of security by obscurity and cloning mifare classic rail and building passes anywhere, anytime. In Cryptology eprint Archive, Report 2009/137. [online] [13] SmartCard Networking Forum. MIFARE DESFire Specification [online] [cit ]. %200.pdf [14] RFID Handbook [online]. [cit ]. ftp:// /books/dvd031/finkenzeller_k._rfid_handbook%5bc%5d_funda mentals_and_applications_in_contactless_smart_cards_and_identification_%282003%2 9%282-nd%29%28en%29%28446s%29.pdf [15] Proxmark III e-shop [online] [16] Jonathan Westhues. Proxmark3[online] [17] Proxmark Antennas [online] [18] Repositář projektu Proxmark na google.com [online] [19] Proxmark reference manual [online] [20] 3DES Source Code [online]. [cit ]. [21] Webové stránky výrobce čteček Spring Card [online] [22] Kasper,T., Oswald, D., Paar, Ch. Side-Channel Analysis of Cryptographic RFIDs with Analog Demodulation. Lecture Notes in Computer Science, 2012, Volume 7055/2012 [online] [23] ISO/IEC Part 3 First Commitee Draft [online]. [cit ]. [24] ISO/IEC Part 4 First Commitee Draft [online]. [cit ]. 66

77 Příloha A - Obsah přiloženého CD /Install/ instalační balíčky vývojového prostředí /Proxmark/ zdrojové kódy práce /Work/ texty Diplomové práce ve formátech doc a pdf 67

78 68

79 Příloha B - Postup instalace vývojového prostředí Instalace proběhla na 32b verzi Windows 7: instalace QT SDK pro Windows [1], instalace MSYS [2] během instalace je potřeba zadat cestu k MinGW:C:/... /QT/mingw, instalace Readline bin [3] následně je třeba z tohoto archivu překopírovat následující soubory: bin/* => C:\... \QT\mingw\bin include/* => C:\... \QT\mingw\include lib/*.a => C:\... \QT\mingw\lib, instalace libusb-win32-device-bin [4] opět je třeba zkopírovat příslušné soubory include/usb.h => C:\...\QT\mingw\include lib/gcc/libusb.a => C:\...\QT\mingw\lib, instalace DevkitPro [5], instalace Strawberry Perl [6], instalace Pthreads [7], nastavení systémových proměnných export QTDIR=/c/QT/qt export PATH=$PATH:$QTDIR/bin export DEVKITARM=/c/.../devkitPro/devkitARM export PATH=$PATH:$DEVKITARM/bin, modifikace Makefile a Makefile.common chybně ukončené větve if-else, case ap, určující nastavení kompilace v závislosti na platformě => nutno zakomentovat větve ostatních OS, popř. využít přiložený makefile. 69

80 Odkazy ke stažení: [1] [2] [3] bin.zip/download [4] [5] exe/download [6] [7] 70

81 Příloha C - Postup nahrávání nového firmwaru Nahrávání nového firmwaru se provádí skrz program flasher.exe, kde se jako parametr uvádí část firmwaru vybraná k aktualizaci. Firmware se skládá ze tří částí: -bootloader /bootrom/obj/bootrom.elf -fpga image /armsrc/obj/fpgaimage.elf -os image /armsrc/obj/osimage.elf Flasher.exe je kompilací vytvořen ve složce client. Před spuštěním se doporučuje mít přípravek odpojený a připojit ho teprve po spuštění flasheru. C 1 Průběh nahrávání nového firmwaru 71