Cesta k emulátoru telefonní karty
Prohlášení
Tento článek je něco jako myšlenková hra, cosi jako šachy bez šachovnice. Při této hře se navrhují jednotlivé akce a protiakce, útoky a obrana, v diskuzi se probírá se co by se stalo kdyby ..
Pokud se kdokoliv rozhodne na základě tohoto článku páchat trestnou činnost, je to jen jeho rozhodnutí a autor tohoto článku s tím rozhodně odmítá mít cokoliv společného. Jinak řečeno; Autor na sebe nebere jakoukoliv zodpovědnost za způsob jakým čtenáři mohou naložit s informacemi, které jsou v článku uvedené. Pokud s tímto jakožto potenciální čtenář(ka) nesouhlasíte, plánujete porušit zákon nebo tušíte že by jste nabyté informace nedokázal(a) udržet v teoretické rovině, já jakožto autor vám neuděluji svolení článek dále číst. V opačném případě můžete pokračovat.
Úvod
Tento text jsem sepsal abych si utřídil myšlenky a zároveň shrnul na internetu volně dostupné informace o zabezpečení telefonních karet do krátkého článku v češtině. Článek dále předkládá teoretické možnosti jak toto zabezpečení zlomit, přičemž se (bohužel ;) nejedná o návod, ale pouze o informace, které by měly podnítit další diskuzi a posunout tak tuto myšlenkovou hru do dalšího kola.
Možná že někoho napadne proč se vlastně snažit, když má dnes v podstatě každý svůj vlastní mobil, popřípadě může volat přes VoIP? Obecnou odpověď na tuto otázku nemám, ale za sebe můžu říct, že je docela zábava snažit se proniknout do technologie o které se toho moc neví a která navíc zůstává po dlouhá léta nepokořená (alespoň nevím že by se někomu povedlo emulovat moderní karty).
Telefonní karta
Jak asi každý ví, telefonní karta je zařízení které umožňuje telefonovat, posílat SMS a emaily z tzv. telefonního automatu. Každá karta má v sobě nějakým způsobem uloženy informace o počtu jednotek. Pokud kartu vložíme do automatu, tak jako první proběhne ověření platnosti karty pomocí tzv challenge/response protokolu. Pokud prověrka proběhne správně, automat vám dovolí volat (posílat emaily, SMS, etc..) dokud bude na kartě dostatečný počet jakéhosi kreditu. Pokud ověření karty neproběhne korektně, nebo na kartě nejsou jednotky, automat vydá vysoký pískavý zvuk a na displeji se objeví výzva k vyjmutí karty.
Pokud jste pozorně četli předchozí odstavec, možná vás napadlo, jak jsou jednotky na kartě uloženy a jestli by je nešlo po provolání zase přidat. Bohužel, u moderních karet by něco podobného opravdu nešlo.
V dobách dávno minulých byly jednotky na kartě reprezentovány (EE)PROM pamětí, kterou automat po každém čtení dekrementoval o 1. Jak je asi každému jasné, brzo se našli lidé, kteří zjistili jak na EEPROM zapisovat a začali si karty dobíjet, popřípadě z EEPROM pamětí vytvořili emulátory PROM karet. Telefonní společnosti na to reagovaly tak, že k jednoduché paměti přidali mikroprocesor, který dovolil pouze odečítat jednotky. Aby kartu nebylo možné jednoduše emulovat, byl přidán i mechanismus, který umožnil ověřit jestli je karta pravá. Tento mechanismus se nazývá challenge/response a bude o něm řeč v další části článku.
Pokud někoho zajímají podrobnosti o hardware karty, dají se najít zde; http://gsho.thur.de/gsho/phonecard/bin/phonecards_204.txt, nebo v ISO normách.
Popis challenge/response protokolu
Dle článku na serveru hw.cz vypadá průběh ověřování přibližně takto:
Telefonní automat si po vložení karty vyžádá její obsah
Automat na obsah uplatní hash funkci, do které spolu s obsahem karty vstupuje i 48b náhodné číslo
Telefonní automat pošle kartě stejné náhodné číslo (challenge)
Telefonní karta pomocí stejné hash funkce spočítá odpověď (response) a odešle jí automatu
Pokud se obě čísla schodují, je karta uznána jako platná
Poněkud odlišný popis se dá najít zde;
Z výše popsaného postupu vyplývá, že jediné co brání stavbě emulátoru karty je znalost (resp. neznalost) hash algoritmu. Algoritmus se bohužel jen tak sehnat nedá, proto vidím jedinou možnost ho zjistit pomocí níže uvedených metod.
Možnosti prolomení c/r
MITM sniffer
Jedna z lehčích možností je postavit zařízení na odposlech komunikace mezi kartou a automatem. Po nashromáždění určitého počtu záznamů komunikace by pak mělo stačit sestavit bruteforce cracker (rozebráno dále) a pokusit se zlomit algoritmus.
Výhody
- Dost možná nízká cena
- Relativně nízká náročnost
Nevýhody
- Dlouhý čas sběru informací
- Při každém vložení karty proběhne autentizace
- Po odečtení jednotky (cca 1minuta) proběhne autentizace
- Po každém vytáhnutí karty potřebuje automat cca 5-10s na restart
- Nutnost připojit k sběrnému zařízení paměť (notebook?)
- Nutnost přítomnosti operátora, který bude kartu vytahovat a vkládat
Inspirace
Několik zajmavých fotek:
Reverzní inženýrství automatu
Jednalo by se o ukradení automatu a jeho pitvání a zkoumání, hledání dat v pamětech, zjišťování ochran a v konečném důsledku i o možnost provádět MITM odposlech mezi kartou a automatem doma.
Výhody
- Rychlost MITM
- MITM se zrychlí, pokud zde bude možnost provádět odposlouchávání nerušeně např. celou noc
- Možnost nalezení snadnějšího způsobu získávání dat
- V automatu může být čip, který provádí hashování dat - jeho zkoumáním by se možná dal algoritmus odhalit
- Pokud čip vyexportuji na vlastní desku, nebudu muset čekat na reset automatu - toto má vliv pouze při získávándat pomocí MITM útoku
- Možnost využívat šifrovací čip v emulátoru
- Z některých ruských stránek vyplývá, že šifrovací čip a paměť se dá používat jako emulátor
Nevýhody
- Nutnost ukrást automat
- Muže to byt špatně proveditelné
- Můžou Vás udat náhodní svědci
- Ukradeného automatu si každý všimne, doma ho jen tak neschováte
- Možnost zranění při krádeži (v automatu je 230V)
- V konečném důsledku to může být k ničemu
Reverzní inženýrství karty
Falešný automat
V podstatě se jedná o postavení přípravku, který se bude tvářit jako automat. Pokud bude kartě posílat náhodná čísla, může výsledky hash funkce ukládat pro pozdější bruteforce útok do počítače, čímž odpadne nutnost stavět MITM sniffer.
Výhody
- Velmi nízké náklady
- Vysoká rychlost získávání odpovědí (počítám že několik za sekundu)
- Nenápadnost (kartu a čtečku doma schováte spíš než rozpitvaný automat)
Nevýhody
- V podstatě žádné
Útok na hardware karty
-
Aktivní průzkum
- Jedná se o odleptání krycí vrstvy čipu a průzkum jeho struktury
- Při tomto postupu je možné přímo přečíst paměti typu (P)ROM
- Je možné zasahovat do chodu karty, popřípadě odposlouchávat jednotlivé části čipu
-
Pasivní průzkum
- V podstatě jde o snahu prozkoumat strukturu karty pomocí např. rentgenového záření, nebo terahertzové kamery, či nějakého podobného neinvazivního prostředku
- Za předpokladu že se program nachází v (P)ROM by neměl být problém ho přečíst
- Bohužel, zdá se že rentgenový mikroskop se moc nepoužívá (místo něj použít elektronový mikroskop?)
- Nestačil by místo mikroskopu (soustavy zaostřovacích čoček) pouze hodně citlivý film?
Výhody
- Získání algoritmu tak jak je na kartě uložen
- Možnost manipulace s čipem, získání zajímavých obrázku :)
Nevýhody
- Nutnost přístupu do pokročilé laboratoře
- Nutnost získat potřebné toxické látky, nebo rentgen
- Znalost práce s prudce jedovatými látkami
- Nutnost zkušeností s podobnou prací
Získání algoritmu z nasbíraných dat
Z jistých zdrojů vyplývá, že algoritmus je založen na hardwarových funkcích procesoru, přičemž by měl využívat 48b posuvný registr, XOR a NXOR. Procesor také obsahuje tři 9b, 6b a 5b čítače s neznámou funkcí. Dále existuje nezanedbatelná pravděpodobnost, že se algoritmus podobá výpočtu CRC.
Článek na hw.cz se zmiňuje, že pro získání jednoho bitu hashe je nutné poslat kartě 160x CLK pulz. Z toho vyplývá, že algoritmus probíhá sekvenčně pro každý bit zvlášť a je teoreticky tvořen max. 160 instrukcemi.
Z výše uvedeného vyplývá, že algoritmus by měl vypadat nějak takhle:
Možnosti rekonstrukce algoritmu
Podle mě v úvahu připadají pouze tyto dvě techniky:
- Matematická analýza
- K uskutečnění je zapotřebí kryptoanalytik s hlubokými znalostmi matematiky.
- Nevýhoda; schopní kryptoanalytici se poněkud těžko shánějí.
-
Hrubá síla
- Jelikož má mikročip velice malý výkon, troufám si předpokládat že algoritmus nebude moc dlouhý, protože i velikost paměti pro program bude relativně malá.
- Algoritmus potřebuje pro výpočet jednoho z 16b hashe 160 CLK pulzů, což znamená že program by měl obsahovat max. 160 instrukcí.
- Je ovšem nutné brát v úvahu že některé operace mohou potřebovat více CLK pulzů pro jeden výsledek, takže to v konečném důsledku může být i méně.
- Na druhou stranu některé operace (jako je třeba inkrementace čítače) mohou probíhat zároveň s ostatními instrukcemi, takže vlastně proběhne více primitivních operací než 160. Tento fakt bude nutné zohlednit při návrhu crackeru.
- K útoku je zapotřebí průměrný programátor a velký výkon, což by v dnešní době neměl být takový problém, obzvlášť pokud se využije paralelizace.
Jelikož první volba je poněkud mimo možnosti běžného geeka, myslím že útok hrubou silou bude muset stačit.
Bruteforce cracker
Útok hrubou silou by měl být značně zjednodušený, protože známe vstup, výstup, přibližný počet instrukcí a navíc víme které operace nejspíš algoritmus generování hashe využívá a které ne. Jediné co zbývá je napsat program, který se pokusí odhalit v jakém pořadí jsou operace aplikovány, čímž odhalí algoritmus a umožní stavbu emulátoru.
Cracker by měl dle mého názoru vypadat přibližně takto:
Popis crackeru
- Ze souboru se načte zachycený obsah karty, náhodné číslo a výsledný hash.
- Permutátor vygeneruje posloupnost instrukcí, kterou odešle interpreteru.
- Interpreter postupně vykonává instrukce, v registrech nebo paměti má uložen zachycený obsah karty a náhodné číslo.
- Výstupu z interpreteru je změřena velikost - pokud se nerovná 16b, postupuje se rovnou k další iteraci.
- Pokud hash prošel testem na velikost, porovná se s zaznamenaným hashem. Pokud jsou hashe stejné, aktuální posloupnost instrukcí se uloží do logu a načte se další zaznamenaný hash, obsah karty a náhodné číslo, na které se aplikuje stejná posloupnost instrukcí.
- Pokud hash vyhoví i nyní, můžeme předchozí krok opakovat, nebo instrukce zapsat do souboru a prohlásit že algoritmus byl prolomen.
- Pokud neprojde porovnáním se zaznamenaným hashem, pošleme permutátoru signál k vygenerování nové sekvence a celý postup se opakuje.
Do crackeru by možná bylo dobré zabudovat genetické algoritmy, ale jelikož se v nich moc nevyznám, netuším jak moc by jejich implementace byla v tomto případě vhodná.
Závěr
Nakonec bych chtěl ještě zdůraznit že tento článek není dokonalý, já nejsem dokonalý, dokonce nejsem ani odborník na mikroprocesory nebo zabezpečení karet a proto zde existuje poměrně slušná pravděpodobnost že článek obsahuje chyby nebo nepřesnosti. Je možné že některé metody a možnosti které jsem popsal jsou nesmyslné, nebo nefunkční.
Tento článek neměl a nemá sloužit jako návod, ale k podnícení diskuze nad popsanými metodami. Pokud někoho napadne nějaká připomínka nebo věcná kritika, budu rád když jí uvede v diskuzi k článku, nebo mi jí pošle jinou cestou.
