Třetí díl série o klonování DESFiru. V prvních dvou jsme rozebrali teorii a praxi zálohy. Teď je na stole skutečný dump pravé Mifare DESFire karty z Flipper Zero a projdeme ho řádek po řádku: co z karty vypadlo, kde se čtečka zastavila a co o zabezpečení systému prozradí i to málo, co jde přečíst bez klíče. A protože Flipper umí DESFire i víc než jen přečíst obálku, přidávám detailní rozbor a návod k aplikaci DFC. UID v ukázce je anonymizovaný, změnil jsem jeho poslední bajt.

Teoretický rozbor je jedna věc, reálný výpis z karty druhá. Vzal jsem pravou DESFire kartu, ke které mám přístup, přiložil ji na Flipper Zero a nechal ji přečíst. Výsledkem je soubor .nfc, který se vejde na jednu obrazovku a který ilustruje obě předchozí části líp než jakýkoli diagram.

Ukazuje totiž přesně to rozhraní, o kterém byla celou dobu řeč: hranici mezi tím, co z DESFiru dostaneš zadarmo, a tím, co je zamčené za kryptografií.

Rozeberme ho.

Co máme na stole

Tady je celý dump. UID jsem anonymizoval změnou posledního bajtu, jinak je přesně takový, jak ho Flipper vyčetl.

Filetype: Flipper NFC device
Version: 4
# Device type can be ISO14443-3A, ISO14443-3B, ISO14443-4A, ISO14443-4B, ISO15693-3, FeliCa, NTAG/Ultralight, Mifare Classic, Mifare Plus, Mifare DESFire, SLIX, ST25TB, NTAG4xx, Type 4 Tag, EMV
Device type: Mifare DESFire
# UID is common for all formats
UID: 04 80 C4 1A 28 25 00
# ISO14443-3A specific data
ATQA: 03 44
SAK: 20
# ISO14443-4A specific data
T0: 75
TA(1): 77
TB(1): 81
TC(1): 02
T1...Tk: 80
# Mifare DESFire specific data
PICC Version: 04 01 01 33 00 1A 05 04 01 01 03 00 1A 05 04 80 C4 1A 28 25 00 21 52 59 30 30 91 26
PICC Free Memory: 8032
PICC Change Key ID: 00
PICC Config Changeable: true
PICC Free Create Delete: true
PICC Free Directory List: true
PICC Key Changeable: true
PICC Flags: 00
PICC Max Keys: 01
PICC Key 0 Version: 00
Application Count: 1
Application IDs: A1 70 F4
Application a170f4 Change Key ID: 00
Application a170f4 Config Changeable: false
Application a170f4 Free Create Delete: false
Application a170f4 Free Directory List: false
Application a170f4 Key Changeable: false
Application a170f4 Flags: 00
Application a170f4 Max Keys: 00

Na první pohled nic dramatického. Na druhý pohled učebnice.

Co karta prozradila o sobě

Než se dostaneme k tomu, co Flipper nepřečetl, projděme to, co přečetl. Už z hlaviček se dá karta přesně zařadit.

Device type: Mifare DESFire potvrzuje, že jde o pravou DESFire, ne o magic kartu, která by se za Classic jen vydávala. UID: 04 80 C4 1A 28 25 00 je sedmibajtové a začíná bajtem 04, což je výrobní kód NXP. UID je pevné a čitelné, takže Random ID tahle karta zapnuté nemá a je sledovatelná podle svého čísla.

SAK: 20 je drobnost, na které stojí půlka prvního článku. Hodnota 0x20 znamená, že karta podporuje ISO 14443-4, tedy že jede přes RATS a ATS do přenosového protokolu T=CL, a ne jen přes antikolizi jako Mifare Classic. Řádky ATS pod tím (T0: 75, TA(1): 77 a dál) jsou právě ta odpověď na RATS, kde se dohodne rámcování a rychlost. Tohle je ta vrstva -4 černé na bílém.

Z PICC Version se dá vyčíst generace a velikost. Bajt velikosti úložiště 1A odpovídá osmi kilobajtům, což sedí na PICC Free Memory: 8032. Hlavní verze hardwaru 33 ukazuje na generaci EV3 (0x01 je EV1, 0x12 EV2, 0x33 EV3); pro stoprocentní jistotu stačí kartu hodit do NXP TagInfo, ale vychází to na EV3. Konec řetězce Version nese UID znovu a za ním výrobní dávku a datum.

Shrnuto: osmikilová DESFire EV3 od NXP, bez Random ID.

To všechno Flipper zjistil, aniž by znal jediný klíč.

Kde se Flipper zastavil

A tady přichází pointa.

Všimni si, kde výpis končí.

Application IDs: A1 70 F4
Application a170f4 Config Changeable: false
Application a170f4 Free Create Delete: false
Application a170f4 Free Directory List: false
Application a170f4 Key Changeable: false
Application a170f4 Max Keys: 00

Seznam aplikací Flipper dostal, je tam jedna s AID a170f4. Ale uvnitř té aplikace nevidíš nic. Žádné soubory, žádný obsah, žádné klíče. Max Keys: 00 neznamená, že aplikace nemá klíče, ale že se k nim Flipper nedostal. Narazil na hranici aplikace a bez autentizačního klíče neprošel.

Proč vůbec dostal ten seznam aplikací? Kvůli jednomu nastavení o pár řádků výš, PICC Free Directory List: true, které listing aplikací bez autentizace povoluje. Kdyby bylo false, neviděl by ani AID.

A přesně tohle je závěr druhého článku na živém vzorku. Stock NFC aplikace přečetla obálku, dovnitř dopisu se nepodívala. Soubor .nfc není klon a funkčním klonem se nestane. Kdybys to UID zapsal na sedmibajtovou magic kartu, projdeš jedině u systému, který věří pouhému UID a nic neověřuje. U skutečné DESFire autentizace magic karta mlčí, protože nemá čím odpovědět na výzvu.

Co z toho čte bezpečák

Teď to zajímavé, protože i ta neautentizovaná hlavička dokáže o nasazení hodně napovědět. Podívej na nastavení na úrovni celé karty.

PICC Key 0 Version:       00
PICC Config Changeable:   true
PICC Free Create Delete:  true
PICC Free Directory List: true
PICC Key Changeable:      true

Nejsilnější signál je verze master klíče. PICC Key 0 Version: 00 skoro vždy znamená, že master klíč nikdo nerotoval a sedí tam pořád výchozí hodnota, tedy samé nuly. K tomu Free Create Delete: true, což dovoluje zakládat a mazat aplikace bez autentizace master klíčem. Dohromady je úroveň PICC měkká: výchozí master klíč a volná správa aplikací. Kdo se autentizuje tím výchozím klíčem, může na kartě aplikace přidávat nebo rovnou mazat. Data v uzamčené aplikaci a170f4 sice nepřečte, na to potřebuje aplikační klíč, ale integrita a dostupnost celé karty na tom stojí vratce.

Kontrast se samotnou aplikací je přitom poučný. Aplikace a170f4 je zamčená slušně:

Application a170f4 Config Changeable:  false
Application a170f4 Free Create Delete:  false
Application a170f4 Free Directory List: false
Application a170f4 Key Changeable:      false

Config neměnný, klíče neměnné, listing i create/delete zakázané. Kdo tu aplikaci personalizoval, udělal na její úrovni hygienu správně. Jenže PICC kolem ní nechal rozvolněný. A to je přesně ten mismatch z prvního dílu: kryptografie čipu drží, slabina je v personalizaci, ne v křemíku.

DESFire tady nechybuje. Obrany, které karta nabízí, musí někdo zapnout a nastavit. Random ID je vypnuté, master klíč nerotovaný, správa aplikací volná. Žádná z těch věcí není porucha karty, všechny jsou rozhodnutím při nasazení.

Jenže Flipper umí DESFire i víc: aplikace DFC

Dump výš vylezl ze stock NFC aplikace, která se u DESFiru zastaví na obálce. To ale není poslední slovo Flipperu. V katalogu je komunitní aplikace DFC (DESFire-compatible) od autora cindersocket, fork seos_compatible od Erica Bettse, která mluví nativním DESFire command setem a jde dál. S jedním velkým ale, na které si dej pozor, než si z toho uděláš falešný obrázek.

DFC neláme. Nerecovruje klíče, nekrákuje AES, žádný nested útok jako u Classic. Klíč si musíš přinést. Buď ho máš, protože čteš svou kartu, nebo credential napíšeš ručně ze známých klíčů. Emulace jede výhradně s klíči, které do credentialu vložíš. Je to nástroj pro práci s vlastními kartami, ne bypass cizích, a na kartu bez klíče se nedostane o nic víc než stock appka. Na náš uzamčený a170f4 by si DFC bez jeho klíče taky vylámal zuby.

Co tedy DFC s klíči umí:

• Čte DESFire karty. Autentizuje se v režimech legacy DES, ISO 3DES, AES i EV2 a na straně čtečky sáhne klíčem 0 do primární aplikace a přečte její nakonfigurované soubory.
• Emuluje uloženou credential, takže se Flipper vydává za DESFire kartu. K emulaci použije jen klíče uložené přímo v té credentialu.
• Emuluje prázdný DESFire (režim Blank Card). Když do něj čtečka při zápisu něco pošle, po odchodu z emulace tě to vyzve uložit zachycená data jako credential.

Credential je textový soubor .dfc (nebo předkompilovaný binární .dfcb) a nese UID, AID, key settings, autentizační mód a klíče i soubory po slotech. To je přesně ta logická struktura z druhého dílu, jen v jiném kabátě: místo abys obsah zapsal zpět na prázdnou kartu, necháš ho emulovat Flipper.

Tím se zpřesňuje jedna věta z celé série. Psal jsem ve smyslu „Flipper DESFire nedá“. Teď přesněji: Flipper DESFire nenaláme, ale s aplikací DFC a se znalostí klíčů ho přečte i emuluje. Hranice se neposunula o kousek dál k prolomení, posunula se jen o to, co dovede handheld, když klíče už máš v ruce. Jedno upozornění k aktuálnosti: DFC staví na EV1 a EV2 příkazech, pokrytí EV2 a EV3 hardwaru se teprve ověřuje na fyzických čtečkách a radiová kompatibilita není zaručená. Není to oficiální nástroj NXP a autor sám nedává záruku funkčnosti.

DFC krok za krokem

Takhle s tím zacházíš, když chceš číst nebo emulovat vlastní kartu.

Instalace. Nejjednodušší je nainstalovat DFC přímo z katalogu přes Flipper Lab (lab.flipper.net/apps/dfc). Kdo chce stavět ze zdrojáku, naklonuje repozitář, dotáhne submoduly a sestaví přes ufbt:

git submodule sync --recursive
git submodule update --init --recursive
ufbt

Čtení vlastní karty. Přilož kartu na Flipper a nech DFC přečíst primární aplikaci. Aplikace se autentizuje klíčem 0 a stáhne nakonfigurované soubory. Přečtená karta se uloží jako credential i se svým AID, key settings, autentizačním módem a klíči a soubory po slotech. Soubory credentialů patří na kartu do SD Card/apps_data/dfc/.

Emulace. Vyber uloženou credential a Flipper se začne vydávat za tu kartu. K autentizaci vůči čtečce použije jen klíče, které credential obsahuje; žádné jiné nemá odkud vzít. Tohle je ten „funkční klon“, který na magic kartě z principu nejde, ale na emulátoru se správnými klíči ano.

Blank Card. Když chceš vidět, co ti do karty zapíše cizí čtečka, zvol Blank Card. Flipper bude emulovat zapisovatelný prázdný DESFire (ve výchozím stavu s nulovým DES klíčem na úrovni PICC, AID 00 00 00). Pokud čtečka během emulace zapíše data, po odchodu z emulačního okna tě to vyzve uložit je jako .dfc.

Formát a limity credentialu. Textový .dfc se při načtení zkompiluje do binárního tvaru, případně rovnou podáš .dfcb. UID musí mít 7 bajtů a začínat 04. Jedna credential pojme nejvýš 4 aplikace, 16 souborů, 3 KiB dat celkem, 2 KiB v jednom souboru a 512 bajtů na klíče; samotný soubor .dfc nebo .dfcb nesmí přesáhnout 16 KiB. U velkých textových credentialů hrozí, že kompilace na zařízení vyčerpá heap, takže je zkompiluj radši na počítači:

python3 tests/compile_dfcb.py path/to/card.dfc path/to/card.dfcb

Ověření na hostu. Repozitář má k tomu dva testovací skripty. probe_dfcb.py pustí .dfcb proti virtuální kartě jádra přímo na počítači, nahlásí nepodporované credentials a vypíše APDU odpovědi; netestuje UI, NFC listener ani radiové časování, jen logiku. Výchozí APDU přečtou verzi a seznam aplikací, další hex APDU můžeš doplnit a proběhnou v pořadí v jedné relaci:

python3 tests/probe_dfcb.py path/to/card.dfcb
python3 tests/probe_dfcb.py path/to/card.dfcb 9060000000 90AF000000

Druhý skript, probe_pcsc_mac_read.py, je manuální hardwarová zkouška na macOS s PC/SC čtečkou a vyžaduje pythoní knihovnu cryptography. Nejdřív na Flipperu rozjeď emulaci credentialu, pak probe vybere aplikaci 0, autentizuje se ISO 2K3DES klíčem 1, přečte celý soubor 0 a ověří data i MAC v odpovědi. Aplikaci, soubor, klíč a čtečku přepíšeš přepínači --application, --file, --key a --reader:

python3 tests/probe_pcsc_mac_read.py path/to/card.dfc

Ber to jako experimentální nástroj. U EV2 a EV3 karet si funkčnost ověř na své konkrétní čtečce, protože hardwarové pokrytí se teprve dolaďuje.

Co si z toho vzít

Tenhle jeden výpis uzavírá celou sérii, protože v něm je vidět obojí najednou. Pevná část i měkká část DESFiru v jednom souboru.

Pevná část: stock NFC aplikace se k ničemu zabezpečenému nedostala a bez klíčů by aplikaci a170f4 neotevřel ani DFC. AES a tříprůchodová autentizace odvedly svoje, zamčená aplikace zůstala zamčená, naklonovat obsah na magic kartu nejde. Pokud systém kontroluje víc než UID, tahle karta je proti nástrojům bez klíčů tichá.

Měkká část: i tak výpis prozradil, že nasazení není dotažené. Verze master klíče 00 a volné create/delete jsou věci, které si v auditu přístupového systému přečteš jako první, a ani k tomu nepotřebuješ klíče. Útočník je čte stejně snadno jako ty.

A DFC do toho vnáší třetí rovinu. Se svými klíči Flipper DESFire přečte i emuluje, takže patří do výbavy na práci s vlastními kartami vedle Proxmarku a hostových knihoven z druhého dílu. Co nedokáže ani on, je dostat se do karty bez klíče. Přesně v tom je celá pointa série.

Flipper tu kartu nenaklonoval a bez klíčů ji nenaklonuje ani s DFC. Ale přečetl dost na to, aby ukázal, kde by se v nasazení dalo zatlačit, a s DFC zase dost na to, aby se tvoje vlastní karty daly emulovat. Kde končí jedno a začíná druhé, rozhoduje jediná věc: jestli ten klíč máš.

The post Rozbor reálného DESFire dumpu: co Flipper vyčte a co ne first appeared on Hard Wired.

Navazující díl k rozboru klonování DESFiru. V minulém článku padlo, že funkční kopii dostaneš jedině na prázdnou DESFire kartu, kterou si znovu napersonalizuješ. Tady je přesně ten postup: logický dump přes Proxmark3 a python-desfire, bezpečné odložení klíčů a obnova struktury i dat na čistý čip. Včetně toho, co tahle záloha není a kdy ti nepomůže.

Rovnou na úvod: je to runbook na zálohu a obnovu karty, ke které máš klíče, protože je tvoje. Žádné klonování cizích karet. Počítej s hodinou práce u první karty, pak už to jde rychleji. Co budeš na konci umět: přečíst celou strukturu DESFiru, uložit ji i s daty do souboru, založit ji znovu na prázdném čipu a nastavit zpět klíče.

Než se do toho pustíš, přečti si sekci o hranicích. Ušetří ti to zklamání, že „záloha“ nefunguje tam, kde fungovat ani nemůže.

Co budeš potřebovat

Hardware: čtečku, která umí ISO 14443-4 a autentizaci k DESFiru, a dvě karty. Zdrojovou DESFire kartu se svými klíči a prázdnou (blank) DESFire kartu stejné nebo vyšší generace a aspoň stejné paměti. Blank znamená kartu ve výrobním stavu, kde jsou všechny klíče na samých nulách; prodávají se jako „DESFire EV1/EV2/EV3 blank“.

Software podle toho, co preferuješ. Buď Proxmark3 s firmwarem Iceman (fork RfidResearchGroup), kde je celá rodina příkazů hf mfdes. Nebo PC/SC čtečku (ACR122U, ACR1252U, Omnikey) a Python s knihovnou python-desfire. Obojí umí jak čtení, tak personalizaci, takže si vyber podle toho, co máš po ruce.

A hlavně klíče. Bez klíčů s právem číst se k obsahu nedostaneš a žádný z dále popsaných kroků nemá smysl. To je vlastnost, ne chyba.

Hranice, které musíš znát předem

Záloha DESFiru má tři tvrdá omezení a je lepší je vědět teď než po hodině práce.

UID se nepřenese. Pravá DESFire karta má sedmibajtové UID zapečené z výroby a nejde přepsat. Prázdná karta má svoje vlastní. Obnovená karta tedy ponese jiné UID než originál, a to nezměníš. Magic DESFire s přepisovatelnou identitou neexistuje, jak padlo v minulém díle.

Systém s diverzifikací klíčů ti obnovenou kartu nevezme. Pokud přístupový systém odvozuje klíče z UID (diverzifikace podle AN10922), čtečka si pro nové UID spočítá jiný klíč, než jaký má tvoje obnovená karta. Autentizace selže. Obejít to jde jedině tak, že vlastníš site klíč celého systému a dopočítáš diverzifikované klíče pro nové UID, což dává smysl jen u systému, který sám provozuješ. Pro cizí přístupový systém tohle není cesta.

Přečteš jen to, na co máš právo. Každý soubor má přístupová práva navázaná na konkrétní klíče. Když tvůj klíč smí číst jen některé soubory, zbytek zůstane skrytý, i když kartu „otevřeš“.

Z toho plyne, k čemu záloha reálně slouží: k archivaci obsahu tvé vlastní karty, k migraci nebo havarijní obnově v systému, který si personalizuješ sám, a k laboratorní práci. Ber ji jako zálohu dat a struktury, ne jako výrobu náhradní přístupové karty do cizí budovy.

Jedna věc k bezpečnosti ještě předtím, než začneš sypat příkazy. Klíče drž mimo dump. Data a struktura můžou do obyčejného souboru, klíče patří do šifrovaného trezoru. Dump s klíči v plaintextu je ta nejhorší možná poznámka pod čarou.

Krok 1: Inventura karty

Napřed si kartu zmapuj, ať víš, co vůbec zálohuješ. Přilož zdrojovou kartu na Proxmark a projdi ji shora dolů.

hf mfdes info
hf mfdes getuid

info vypíše generaci, velikost paměti a volné místo, getuid skutečné UID (u karty se zapnutým Random ID ho vydá až po autentizaci, takže případně přidej secure channel a klíč). Dál si nech vypsat aplikace a soubory:

hf mfdes lsapp --files
hf mfdes lsfiles --aid 123456 -t aes

lsapp --files ukáže všechny aplikace podle jejich tříbajtového AID i s jejich soubory. Pokud jsou klíče nestandardní, autentizuj se jimi; --no-auth zkusí listing bez autentizace, pokud to karta v nastavení dovolí. U každého souboru si zjisti jeho nastavení, protože bez něj kartu věrně neobnovíš:

hf mfdes getfilesettings --aid 123456 --fid 01

Zapiš si typ souboru (Standard, Backup, Value, Linear Record, Cyclic Record), komunikační režim (Plain, MACed, plně šifrovaný), přístupová práva a velikost. Tohle je kostra, kterou budeš na prázdné kartě stavět znovu. U Value souboru si navíc poznamenej dolní a horní limit a aktuální hodnotu, u záznamových souborů počet a velikost záznamů.

Když klíče neznáš celé a chceš je dohledat ze slovníku, pomůže detekce, ale u vlastní karty bys klíče měl mít:

hf mfdes detect --save --dict mfdes_default_keys

Krok 2: Logický dump

Teď vyčteš obsah. Nejjednodušší je dump po aplikaci:

hf mfdes dump --aid 123456

dump projde soubory v aplikaci a vypíše jejich obsah. Pro jednotlivý soubor nebo pro přesnou kontrolu použij read s typem souboru:

hf mfdes read --aid 123456 --fid 01
hf mfdes read --aid 123456 --fid 02 --type record
hf mfdes read --aid 123456 --fid 03 --type value

read bez typu se pokusí typ odhadnout, u záznamových a hodnotových souborů ale radši typ uveď. Výstup si ulož do strukturovaného souboru, ideálně JSON, kde každý soubor nese svoje AID, FID, typ, komunikační režim, práva, velikost a surová data v hexu. Klíče do tohohle souboru nepatří, ty jdou zvlášť.

Takhle vznikne tvoje záloha: popis struktury plus obsah. Co s ní uděláš dál, je obnova na prázdný čip.

Krok 3: Příprava prázdné karty

Prázdnou kartu uveď do známého stavu. Pokud v ní něco je, naformátuj ji, a pamatuj, že k formátu potřebuješ PICC master klíč (u čisté karty samé nuly):

hf mfdes auth -n 0 -t aes -k 00000000000000000000000000000000
hf mfdes formatpicc

Po formátu máš čistý PICC s jednou prázdnou kořenovou aplikací a výchozími klíči. Na téhle základně postavíš kopii struktury.

Krok 4: Obnova struktury a dat

Teď znovu založíš aplikace a soubory podle toho, cos zapsal v kroku 1, a naliješ do nich data z kroku 2. Konkrétní vlajky příkazů createapp a createfile se mezi verzemi firmwaru liší, takže si u své verze vždy ověř přesný tvar přes hf mfdes createapp -h a hf mfdes createfile -h. Orientačně to vypadá takhle:

hf mfdes createapp --aid 123456 --dfname hesse --ks1 0B --ks2 AE
hf mfdes createfile --aid 123456 --fid 01 --amode encrypt --size 000020

--ks1 a --ks2 kódují nastavení klíčů aplikace, tedy počet klíčů, jejich typ a oprávnění; --amode je komunikační režim souboru, --size velikost v bajtech. Hodnoty musí sedět na to, cos vyčetl z originálu, jinak nedostaneš věrnou kopii. Value a záznamové soubory se zakládají vlastními příkazy s limity a počtem záznamů.

Když struktura stojí, zapiš data:

hf mfdes write --aid 123456 --fid 01 -d 0102030405060708...
hf mfdes write --aid 123456 --fid 02 --type record -d 0102030405 --updaterec 0
hf mfdes write --aid 123456 --fid 01 --type data -d 01020304 --commit

U Backup souborů nezapomeň na --commit, bez něj zůstane zápis jen v dočasném bufferu a po odpojení karty se ztratí. U Value souborů se hodnota nenastavuje přímo, ale přes počáteční hodnotu při založení, případně přes credit a debit.

Krok 5: Nastavení klíčů

Tohle je nejchoulostivější krok celé obnovy, protože tady si můžeš kartu zamknout. Dokud jsi pracoval s výchozími nulovými klíči, šlo všechno hladce. Teď je vyměníš za ty původní.

hf mfdes changekey --aid 123456 -n 1 -t aes -k 00000000000000000000000000000000 --newkey 00112233445566778899AABBCCDDEEFF --newver 01

Drž se tří pravidel. Klíče měň odspodu, aplikační klíče před aplikačním master klíčem, a aplikační master klíč před PICC master klíčem; jakmile změníš klíč, kterým ses autentizoval, musíš se autentizovat znovu tím novým. Verzi klíče (--newver) nastav na stejnou hodnotu jako na originálu, jinak ti pozdější autentizace nemusí projít. A než přepíšeš poslední master klíč, dvakrát si ověř, že ho máš zapsaný správně, protože špatně zadaný master klíč znamená kartu, do které se už nedostaneš.

Jemnější nuance: změna klíče číslo 0 (master klíč aplikace) používá jiné krypto než změna ostatních klíčů a může zároveň měnit nastavení aplikace. Proto ji nech až úplně nakonec a odděleně.

Celý cyklus v Pythonu

Kdo nechce ťukat do Proxmarku ručně, zvládne totéž skriptem přes python-desfire na PC/SC čtečce. Knihovna umí čtení i personalizaci, takže pokryje obě fáze. Čtecí část vypadá v jádru takhle:

from desfire import DESFire, PCSCDevice
from smartcard.System import readers

conn = readers()[0].createConnection()
conn.connect()
card = DESFire(PCSCDevice(conn.component))

card.authenticate(0x000000, picc_master_key)   # PICC master
dump = {"uid": card.get_real_uid(), "apps": []}

for aid in card.get_application_ids():
    card.select_application(aid)
    card.authenticate(aid, app_keys[aid])
    app = {"aid": aid, "files": []}
    for fid in card.get_file_ids():
        settings = card.get_file_settings(fid)
        data = card.read_file_data(fid)
        app["files"].append({"fid": fid, "settings": settings, "data": data})
    dump["apps"].append(app)
# dump ulož do JSON; klíče (app_keys) drž mimo tenhle soubor

Obnova na prázdnou kartu je zrcadlový postup. Autentizuješ se výchozím nulovým klíčem, založíš aplikaci, přepneš se do ní, vytvoříš soubory podle uložených nastavení, zapíšeš data a nakonec vyměníš klíče:

blank.authenticate(0x000000, default_key)
blank.create_application(aid, key_settings, num_keys, DESFireKeyType.DF_KEY_AES)
blank.select_application(aid)
blank.authenticate(aid, default_app_key)
blank.create_standard_file(fid, comm_mode, access_rights, file_size)
blank.write_file_data(fid, 0, comm_mode, data)
blank.change_key(key_no, new_key, old_key, key_version)

Přesné signatury metod se mezi verzemi knihovny trochu liší, takže si je ověř v její dokumentaci; logika kroků ale zůstává stejná jako u Proxmarku. Knihovna staví na EV1, pro specifické funkce EV2 a EV3 počítej s tím, že je nemusí pokrývat.

Když něco nefunguje

Nejčastější zádrhel je selhání autentizace. Zkontroluj tři věci: správný typ klíče (-t des, 2tdea, 3tdea nebo aes), správné číslo klíče (-n) a správný secure channel (-s d40, ev1, ev2). Když nesedí byť jen jedno, karta tě odmítne, i když máš klíč správně.

Když čtení projde, ale vrátí nesmysl, nejspíš čteš ve špatném komunikačním režimu. Plně šifrovaný soubor čtený jako Plain vrátí šifrovaný balast, ne data. Ověř si režim z nastavení souboru.

Když se obnovená karta tváří hotově, ale originální systém ji nevezme, vrať se k sekci o hranicích. Buď systém diverzifikuje klíče podle UID, které se změnilo, nebo kontroluje jen UID a tvoje nové mu nesedí. Ani jedno nespravíš na straně karty.

A nejbolestivější případ: autentizace k aplikaci najednou nejde ani tobě. Nejspíš sedí špatná verze klíče nebo ses při změně master klíče přepsal. U vlastní testovací karty z toho ven vede jen formát přes PICC master klíč, pokud ho ještě znáš. Pokud ne, karta je pro tebe ztracená. Proto se master klíče mění jako poslední a s rozmyslem.

Co sis vlastně zazálohoval

Na konci máš dvě věci. Soubor s popisem struktury a daty, který přežije kartu, a schopnost tu kartu znovu postavit na čistém čipu. Co nemáš, je identický klon s původním UID, protože ten na pravém DESFiru neexistuje.

A přesně v tom je ta záloha užitečná i poctivá zároveň. Archivuje obsah, umožní migraci ve tvém vlastním systému a zachrání tě, když fyzická karta doslouží. Jen si pamatuj, čím tenhle postup je a čím není, a nebudeš čekat zázrak tam, kde ho DESFire z principu neslíbil.

The post Jak si zálohovat DESFire kartu a obnovit ji na prázdnou first appeared on Hard Wired.

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.

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:

1. Č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.
2. Č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á.
3. 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.

The post Proč DESFire nenaklonuješ, i když Mifare Classic jde first appeared on Hard Wired.