Verze textu:
1.0.special_soom_ASCII_editon (08.12.2009) (obrazky vkladat nejdou a ASCII se sem nevejde - fakt netusim co lepsiho udelat..)
Licence:
CC by-nc-sa (http://creativecommons.org/licenses/by-nc-sa/3.0/cz/)
V praxi to znamená, že dílo může být NEKOMERČNĚ šířeno a upravováno, ale pouze se zachováním jména původního autora a stejné licence.
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.
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).
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.
Dle článku na serveru hw.cz vypadá průběh ověřování přibližně takto:
_______________________ _____________________ | | | | | Telefonní automat | <=== Obsah karty ==== | Telefonní karta | |_______________________| |_____________________|
_______________________ ________________________ _______________________
| | | | | |
| Náhodné 48b číslo | ===> | Hashovací algoritmus | <=== | Obsah telefonní karty |
|_______________________| |________________________| |_______________________|
_||_
\ /
________\/_______
| |
| 16b výsledek |
|_________________|
_______________________ _____________________ | | | | | Telefonní automat | ==== Náhodné číslo ===> | Telefonní karta | |_______________________| |_____________________|
_______________________ _____________________ | | | | | Telefonní automat | <=== Výsledné číslo === | Telefonní karta | |_______________________| |_____________________|
Poněkud odlišný popis se dá najít zde; http://www.ciscom.ru/hackersrussia/Cards/Syncro/Eurochip.txt
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.
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.
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 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.
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:
___________________________ ________________
| | | |
| Generátor náhodných čísel | | Obsah karty |
| čísel (48b) | | (nejspíš 128b) |
|___________________________| |________________|
_||_ _||_
\ / \ /
________________ _____________\/______________________\/________ _._._._._._._._.
| | | | | |
| Určitě použité | | | . Možná použité .
| _________ | | | | ____________ |
| | | | | | . | | .
| | XOR | | | | | | 9b čítač | |
| |_________| | | | . |____________| .
| _________ | | | | | | |
| | | | | | . | 6b čítač | .
| | NXOR | | <==> | Výpočet hashe | <--> | |____________| |
| |_________| | | | . | | .
| _________ | | | | | 5b čítač | |
| | | | | | . |____________| .
| | 48b | | | | | ____________ |
| | posuvný | | | | . | | .
| | registr | | | | | | Aritmetika | |
| |_________| | | | . | (+,-,*,/) | .
|________________| |_______________________________________________| | |____________| |
_||_ ._.__._._._._._._.
\ /
______________________\/_______________________
|| ||
|| 16b hash ||
||_____________________________________________||
Podle mě v úvahu připadají pouze tyto dvě techniky:
Jelikož první volba je poněkud mimo možnosti běžného geeka, myslím že útok hrubou silou bude muset stačit.
Ú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:
_____________________________________________________________________ | | | | ____________________ | | | | | | | | | Prvky algoritmu | ______V________ _____________V_____________ |------>| (čítače, registry, | | | | | | | aritmetika) | | Obsah karty | | Zaznamenané náhodné číslo | | |____________________| |_______________| |___________________________| | _||_ _||_ _||_ | \ / \ / \ / | _________\/_________ _____\/_______\/_____ | | | | | |------>| Permutátor |= instrukce =>| Interpret instrukcí | | |____________________| |_____________________| | _||_ | \ / | _________\/__________ | || || | || Hash || | ||___________________|| | _||_ | \ / | False - další iterace _________\/__________ |<-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.| | | ____________ | Test velikost | | / | | |_____________________| | /___| | _||_ | | Zaznamenaná | \ / | | komunikace, | _________\/__________ __________________ |<----------| nastavení, | True | | | | | | výsledek | <= Instrukce == | Porovnání hashe | <=== | Zaznamenaný hash | | |_____________| |_____________________| |__________________| | False | další iterace ^ |______________________________________________________|__________________________|
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á.
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.