Proč DESFire nenaklonuješ, i když Mifare Classic jde

Magic karty s přepisovatelným UID udělají kopii obyčejné Mifare Classic za pár minut. DESFire stejný trik nedonese, a není to kvůli tajnému klíči, ale kvůli tomu, jak je karta postavená. Podrobný rozbor: jak DESFire funguje, jak ověřuje, čím se brání útokům a proč celé zabezpečení nakonec stojí a padá se systémem kolem něj.

Máš svůj vlastní klíč k DESFire kartě, chceš si ji zálohovat, a po ruce zrovna není prázdný DESFire. Jenom magic karta. Zní to jako banalita.

Přitom se právě na tomhle scénáři nejlíp ukáže, proč jde jedna karta zkopírovat za pár minut a druhá vůbec. Obkreslit UID je málo. Klon musí zreplikovat celé chování karty vůči čtečce, kryptografii nevyjímaje. Projdeme to od začátku: proč je Mifare Classic odsouzená ke klonování, jak je naproti tomu postavený DESFire, jak probíhá jeho ověřování krok za krokem, čím se brání útokům, kde ho jednou v historii zlomili a proč dnešní průšvihy nemají s čipem nic společného.

Magic karta a otevřený blok 0

U běžné Mifare Classic je blok 0 uzamčený z výroby. Sedí v něm UID, jednobajtový kontrolní součet BCC a výrobní data, a normální čtečka ho nepřepíše. Magic karty tenhle zámek obcházejí. Způsob obcházení dělí jednotlivé generace a není to jen akademické dělení, protože rozhoduje o tom, jestli tě klon prozradí.

Nejstarší „UID karty“ (Gen1a) poslouchají nestandardní backdoor příkazy. Karta se uspí a pak reaguje na dvojici příkazů (0x40 v sedmibitovém rámci jako buzení, následně 0x43), které odemknou čtení i zápis libovolného bloku včetně nultého, a to bez znalosti jakéhokoli klíče. Na Proxmarku to obsluhují příkazy csetblk, cgetblk a spol. Háček je v tom, že ta samá ochota reagovat na backdoor kartu odhalí: čtečka pošle odemykací sekvenci, karta odpoví, a je jasno.

Gen2 (CUID) backdoor nemá. UID se u ní mění přímým zápisem do bloku 0 jako do kteréhokoli jiného, přes standardní wrbl s vynuceným zápisem. Pozor na BCC: když ho spočítáš špatně, část čteček kartu odmítne nebo rovnou zablokuje. CUID má proti Gen1a výhodu, že na backdoor nereaguje, takže ji sken backdoorem neodhalí. Zrádný je ovšem přístup, kdy se čtečka sama pokusí přepsat blok 0, protože běžná Classic to nedovolí a CUID ano, čímž se prozradí. Na to je FUID, který se po prvním zápisu zamkne natvrdo a od té chvíle je k nerozeznání od pravé Classic. UFUID je mezistupeň: chová se jako CUID, dokud mu nepošleš zamykací sekvenci, a teprve pak ztuhne.

Špičkou je dnes Gen4, prodávaný jako „Ultimate Magic Card“. Funguje jako konfigurovatelná platforma, ne jako jedna pevná emulace. Umí se vydávat za libovolnou Classic (1K, 4K, Mini), za Ultralight i za NTAG, se čtyř-, sedmi- i desetibajtovým UID, a svou konfiguraci chrání heslem. Má takzvaný shadow mode, kdy se po přiložení jednou ukáže jako klon a pak jako zapsaná data, čímž umí obejít i otravnější anti-copy kontroly.

Generace	Jak mění UID	Detekce čtečkou
Gen1a	backdoor příkazy (0x40/0x43)	snadná, reaguje na backdoor
Gen2 / CUID	přímý zápis bloku 0	obtížná, ale pokusem o zápis bloku 0 se prozradí
FUID	zápis jednou, pak trvalý zámek	žádná, po zamčení jako běžná Classic
UFUID	jako CUID, pak volitelný zámek	žádná po zamčení
Gen4 / Ultimate	řízená konfigurace, shadow mode	náročná, novější firmware Proxmarku ji pozná

Všechny tyhle karty mají společné jedno. Emulují Mifare Classic, Ultralight nebo NTAG, tedy typy postavené na prolomené šifře Crypto1 nebo rovnou bez autentizace. A Classic je rozbitá na několika úrovních zároveň. Crypto1 padla akademicky už kolem roku 2008 (Nohl, Garcia a další), útoky Darkside, Nested a HardNested vytáhnou klíče z běžné karty v řádu sekund až minut. Loni to dostalo ještě jeden rozměr: Philippe Teuwen z Quarkslabu v srpnu 2024 popsal hardwarový backdoor ve Fudan FM11RF08S, tedy v „tvrzené“ variantě s šifrovaným statickým nonce, která měla nested útokům odolávat. Backdoor umožňuje autentizovat se neznámým klíčem společným všem těm kartám a vyčíst z karty během pár minut všechny klíče i bez jediného známého klíče. Nástroje skončily v Proxmarku. Jinými slovy: žádná karta z rodiny Classic není bezpečný nosič identity, ať je magic nebo ne.

DESFire mezi nimi nenajdeš.

A to je jádro věci.

Jak DESFire funguje

DESFire a Classic spojuje leda ta frekvence 13,56 MHz. Jinak to jsou dva odlišné světy, a začíná to už u komunikační vrstvy. Norma ISO/IEC 14443 má čtyři části: fyziku karty, rádiové rozhraní, inicializaci s antikolizí (část -3, kde se řeší ATQA, SAK a výběr UID) a konečně přenosový protokol (část -4). Mifare Classic končí u části -3 a dál jede proprietární Crypto1, žádný standardní protokol nad tím není. Právě proto „čtení“ Classic znamená jen antikolizi plus Crypto1 a právě proto ji magic karta tak snadno napodobí.

DESFire jede až po vrstvu -4. Po antikolizi pošle čtečka příkaz RATS, karta odpoví svým ATS a tím se dohodne half-duplexní protokol T=CL s datovými rychlostmi od 106 až po 848 kbit/s. Nad ním se posílají APDU podle ISO/IEC 7816-4, stejné stavební kameny jako u kontaktních čipových karet a pasů. Nativní příkazy DESFiru se dají balit do ISO 7816 APDU (wrapped mode, s hlavičkou 0x90), takže s kartou umí mluvit i obyčejná PC/SC čtečka přes standardní rozhraní.

Paměť je hierarchická, jako malý šifrovaný souborový systém. Na nejvyšší úrovni je PICC, tedy celá karta, s master klíčem a globální konfigurací. Pod ním sedí aplikace, každá se svým tříbajtovým identifikátorem AID a vlastní sadou až čtrnácti klíčů. V každé aplikaci je až 32 souborů, a souborů je šest druhů: Standard Data pro statická data, Backup Data s transakční ochranou, Value pro čítače a peněženky, Linear Record a Cyclic Record pro záznamové logy a konečně Transaction MAC, který přibyl v EV3 a podepisuje transakce. Každý soubor má vlastní přístupová práva navázaná na konkrétní klíče, takže čtení může vyžadovat jiný klíč než zápis.

Klíče jsou AES-128, nebo starší DES, 2K3DES a 3K3DES, vždy s verzí klíče. Generace jdou za sebou a drží zpětnou kompatibilitu. D40 je původní z roku 2002, dnes dožilá. EV1 přišel v roce 2008 s certifikací Common Criteria EAL4+ a pamětí 2, 4 nebo 8 kB. EV2 z roku 2016 zvedl laťku na EAL5+, zrušil limit počtu aplikací, přidal rolling keys a sadu obranných mechanismů, ke kterým se dostaneme. EV3 z roku 2020 drží EAL5+, přidává Secure Dynamic Messaging i konfigurovatelné ATS a nabízí paměť až 32 kB. V defaultním stavu se EV3 chová jako EV2 nebo EV1, nové funkce se aktivují až při personalizaci, takže integrátor musí vědomě zapnout, co chce používat.

Jak DESFire ověřuje

Tohle je srdce celé věci, a proto se u toho zastavíme podrobně. DESFire používá tříprůchodovou vzájemnou autentizaci (three-pass mutual authentication). Jde o to, že si karta i čtečka navzájem dokážou znalost sdíleného klíče, aniž by klíč nebo jeho prostá podoba kdy proletěly éterem. Zjednodušeně to běží takhle:

Čtečka řekne, kterým klíčem se chce autentizovat. Karta vygeneruje náhodné číslo RndB, zašifruje ho klíčem a pošle zpět. Útočník odposlechem dostane jen šifrovaný balast.
Čtečka balast dešifruje, získá RndB, vygeneruje vlastní náhodné RndA, číslo RndB cyklicky posune o bajt (RndB') a dvojici RndA a RndB' zašifruje zpět kartě. Posunutím dokazuje, že RndB rozluštila, tedy že klíč zná.
Karta dešifruje, zkontroluje, že její RndB' sedí, čímž má ověřenou čtečku. Pak posune RndA, zašifruje a pošle zpět. Čtečka ověří, že sedí její RndA, a tím má ověřenou kartu.

Z úlomků obou náhodných čísel se nakonec na obou stranách odvodí stejný dočasný session klíč, kterým se šifruje zbytek relace. Odposlech celé výměny útočníkovi nedá nic použitelného, protože náhodná čísla jsou pokaždé jiná a klíč sám se nikdy neposílá.

Varianty se liší kryptem a detaily. Legacy autentizace běží na DES a 3DES, ISO varianta přidává delší náhodná čísla, AES autentizace jede na AES-128. EV2 to posunul k příkazu AuthenticateEV2First: při navázání relace se dohodne transakční identifikátor (TI) a čítač příkazů (CmdCtr), vzniknou oddělené session klíče pro šifrování a pro MAC a každý další příkaz nese narůstající čítač. Tím padá možnost přehrát odposlechnutou výměnu i proskládat cizí příkazy do běžící relace.

Nad samotnou autentizací stojí tři komunikační režimy souborů. V režimu Plain jdou data nechráněně. V režimu MACed se ke každé zprávě připojí CMAC, který hlídá integritu a původ. V plně šifrovaném režimu je obsah zašifrovaný a navíc podepsaný CMAC. Který režim platí, se nastavuje u každého souboru zvlášť, takže veřejný údaj může jet Plain a citlivý plně šifrovaně na stejné kartě.

A právě tady je pointa k tvé záloze. Magic karta nemá kryptoengine. Nemá čím RndB vygenerovat, zašifrovat ani posunout. Ve chvíli, kdy čtečka zahájí tříprůchodovou výměnu, karta mlčí, a tvůj legitimní klíč na tom nic nezmění, protože klíč je klíč k DESFiru, ne něco, čím rozchodíš cizí křemík. Zazálohovat umíš data a strukturu (logický dump po autentizaci), ale funkční kopii dostaneš jedině na prázdnou DESFire kartu, kterou si znovu napersonalizuješ.

Čím se DESFire brání útokům

Samotná šifra je jen začátek. DESFire od EV1 výš nese vrstvu obran, které cílí přesně na způsoby, jakými se contactless karty reálně napadají.

Proti postranním útokům stojí hardwarové protiopatření certifikované na úrovni EAL4+ u EV1 a EAL5+ u EV2 a EV3. Common Criteria na téhle úrovni znamená, že se čip musel ubránit i neinvazivnímu měření spotřeby a vyzařování, tedy přesně tomu, co zabilo původní D40. EV2 a EV3 k tomu přidávají LRP (Leakage Resilient Primitive), alternativní režim AES navržený tak, aby z každé operace unikalo do spotřeby co nejméně informace. Útok měřením stop je proti LRP mnohem dražší.

Soukromí řeší Random ID spolu s architekturou virtuální karty (VCA). Se zapnutým Random ID hlásí karta při každém přiložení jiné náhodné číslo místo pevného UID, takže ji nelze sledovat napříč čtečkami. Skutečné UID vydá teprve po úspěšné autentizaci. VCA pak umožňuje, aby se správná aplikace vybrala a identifikovala, aniž by se to zvenčí dalo zneužít ke sledování nositele.

Proti relay útokům, kdy útočník natáhne komunikaci mezi vzdálenou kartou a čtečkou přes dvojici zařízení, stojí Proximity Check. Čtečka pošle kartě sérii výzev a měří, za jak dlouho přijde odpověď. Když je zpoždění větší, než dovoluje rychlost světla na krátkou vzdálenost, relay se prozradí a kontrola selže. Má to jeden háček, ke kterému se vrátím: funguje jen tehdy, když ho někdo v systému zapne.

Transaction MAC dává kartě schopnost podepsat každou transakci kryptografickým otiskem, takže se zpětně pozná neoprávněný zápis, třeba dobití peněženky mimo oficiální terminál. Rolling keys, tedy až šestnáct sad klíčů na aplikaci s rychlým přepínáním, zase dovolují vyměnit klíče v celém systému bez výměny karet. Když se jedna sada zkompromituje, přepne se na další, aniž by lidé museli odevzdat kartičky.

Žádná z těch obran ale neběží sama od sebe. To je přesně ten důvod, proč DESFire padá častěji na nasazení než na matematiku.

Jediné reálné prolomení za dvacet let

DESFire padl v historii jednou, a ne přes šifru. Původní MF3ICD40 byl uvnitř asynchronní osmibitový procesor řady 8051 s 3DES jádrem a takzvanou glue logikou, uvedený Philipsem kolem roku 2002, tedy v době, kdy se postranní útoky na čipy ještě nebraly jako běžná hrozba. V říjnu 2011 předvedli David Oswald a Christof Paar z Porúrské univerzity v Bochumi na konferenci CHES, co to znamená. Nešli po matematice 3DES, šli po fyzice čipu: měřili spotřebu a elektromagnetické vyzařování během šifrování (differential power analysis a šablonové útoky). Z řádově 250 tisíc naměřených stop zrekonstruovali tajný klíč, celé asi za sedm hodin, s vybavením za pár tisíc eur.

NXP útok uznal a připomněl, že MF3ICD40 stejně plánoval ukončit ke konci roku 2011. EV1, uvedený už o tři roky dřív, byl proti stejnému postrannímu útoku odolný, a právě proto ta certifikace EAL. Od té doby se žádné veřejné prolomení kryptografie EV1, EV2 ani EV3 neobjevilo. Těžiště se nepřesunulo na kartu.

Přesunulo se na systém kolem ní.

Co musí umět čtečka

Častý omyl zní: „přečetl jsem kartu“ u DESFiru neznamená skoro nic. Vyčíst náhodné UID zvládne každá čtečka podle ISO 14443-3. Dostat se k zabezpečenému obsahu je úplně jiná operace a čtečka k ní potřebuje tři věci.

Zaprvé protokol. Musí umět ISO/IEC 14443-4, tedy projít přes RATS a ATS do režimu T=CL, a posílat APDU, ne jen řešit antikolizi. Zadruhé kryptografii. Buď má bezpečnostní modul SAM, kde leží klíče v hardwaru a který provede autentizaci za čtečku, nebo kryptografii dělá host či backend softwarově a klíče jsou uložené v key store řadiče. NXP k tomu dodává moduly MIFARE SAM AV2 a AV3; AV3 pojme až 128 položek pro symetrické klíče, umí offline diverzifikaci klíčů, chráněný kanál mezi hostem a SAM a v takzvaném X-módu i výkonovou spolupráci s čtecím čipem. Zatřetí samotné klíče, bez nich čtečka k šifrovaným souborům prostě nepustí.

V praxi to vypadá takhle. PC/SC čtečky jako ACR122U, postavená na čipu PN532, zvládají APDU passthrough a autentizaci k DESFiru jde dělat softwarově, například přes knihovny python-desfire, libfreefare, TapLinx nebo projekty AndroidCrypto. Novější ACR1252U a ACR1255U nebo čtečky Omnikey míří na DESFire EV1 a EV2 přímo. Proxmark3 má celou rodinu příkazů hf mfdes. V přístupových systémech se klíče často drží v řadiči a čtečka běží v transparentním režimu, typicky přes OSDP. Co nikde nekoupíš, je magic DESFire. Prázdnou kartu k personalizaci ano, ale „otevřenou“ DESFire s přepisovatelnou identitou ne.

A ještě jedna věc, protože se na ní láme většina reálného zabezpečení. Pokud přístupový systém DESFire kartu jen přečte podle UID a dál se spokojí, že se karta ozvala, celá kryptografie je k ničemu. Takový systém pak podvede i obyčejná sedmibajtová magic karta se stejným UID. DESFire reader a UID čtečka jsou dvě různé věci, i když se navenek tváří stejně.

Kde DESFire přesto padá

Neprůstřelná karta ještě není neprůstřelný systém. Většina reálných průšvihů s DESFirem se šifrou vůbec nesouvisí.

Nejčastější je výchozí klíč. Čerstvá DESFire aplikace má všechny klíče nastavené na samé nuly. Když je integrátor nezmění, útočník se autentizuje výchozím klíčem a má vystaráno, přečte i přepíše obsah. Druhá klasika je chybějící diverzifikace klíčů. NXP v aplikační nótě AN10922 popisuje, jak z jednoho site klíče odvodit jedinečný klíč pro každou kartu, pomocí AES-CMAC nad UID, AID a číslem klíče. Když to systém neudělá a sype do všech karet stejný klíč, stačí vytáhnout klíč z jediné karty nebo z jediné čtečky a padne celá instalace naráz. A přesně tím směrem dnešní útoky jdou, po extrakci klíčů ze čtečky nebo po kompromitaci site klíče, ne po prolomení čipu.

Nad tím vším visí lidský faktor nasazení. Proximity Check proti relay útokům je skvělá obrana, pokud ji někdo zapne. Random ID chrání soukromí, pokud se aktivuje. Rolling keys umožní rotaci, pokud má systém proceduru, jak ji provést. NXP to sepsal do systémové nóty AN10969, kde kromě diverzifikace doporučuje i detekci podvodných karet, černé a bílé listiny a stínové účty, tedy obranu, která nestojí na kartě, ale na backendu. Školní příklad z praxe: londýnská Oyster přešla na DESFire, zatímco řada jiných dopravních karet zůstala na prolomené Classic, a rozdíl v bezpečnosti nedělá jen čip, ale celý návrh systému.

Bezpečnost DESFire nebydlí v kartě. Bydlí v tom, jak je nasazená.

A proto ti magic karta zálohu neudělá, ne proto, že by byl klíč tak tajný, ale proto, že na magic kartě není co s tím klíčem provést.