Kormányablak, Ügyfélkapu, magyarorszag.hu, kormany.hu
KORMÁNYABLAK, ÜGYFÉLKAPU - A ZÁRT AJTÓK MÖGÖTT...
(nem hivatalos e-kormányzati témájú oldal)
  
BEMUTATKOZÁS 
E-KÖZIGAZGATÁS 
IT BIZTONSÁG 
  
































  Mottó:
Egy tömegmészárlásról
semmi egyebet nem lehet
mondani, csak olyasmit, hogy:
csip-csirip!
/Kurt Vonnegut:
Az ötös számú vágóhíd/
2012. február 7.  
 "Chip-csirip" 
   
A chipkártyák, vagy intelligens kártyák (smart card) története a 60-as évek végéig, 70-es évek elejéig nyúlik vissza. Az akkori nagy nevek ma is ismerősen hangzanak: Giesecke&Devriant, (Honeywell) Bull, Motorola, Schlumberger, Oberthur, Axalto, Gemplus (majd 2006-os házasságuk révén Gemalto).

A chipkártya, SIM kártya fizikai tulajdonságaival, adatstruktúráival, protokolljaival az ISO/IEC 7816-os szabvány foglalkozik (a többi azonosító kártyáról az ISO/IEC 7810-es szabványsorozat más részei szólnak, illetve az érintkezés nélküli, közelítőkártyák szabványairól a Google Wallet, a pénz-álca bejegyzésemben már írtam). Ezeket a mikroprocesszoros kártyákat különböző területeken különböző módon lehet használni: mindenféle PIN kódos védelem nélküli memóriakártyaként, PIN kódos memóriakártyaként (amolyan jelszavas pendrive-ként), kriptográfiai kulcsokat használó, PIN kódos védelemmel ellátott kártyaként. Léteznek különböző alkalmazások feltöltésére és futtatására képes JavaCard kártyák is (SIM kártyáknál pl. a "Secure Element" rész), azonban a chip kriptográfiai funkcióival ez is az ISO/IEC 7816 szabványban leírt üzeneteken keresztül kommunikál (a JavaCard emulálja az ISO/IEC 7816 interfészt). Az ilyen JavaCard eszközökre lehet feltölteni többek közt az eID keretalkalmazásokat, amelyek bizonyos országokban (pl. Finnország - FINEID, Észtország - EstEID) a nemzeti azonosító kártyák alapjául szolgálnak. Az eID keretrendszer az eredeti struktúra hiányosságait is orvosolja, pl. így már nem léteznek olyan pontok a kommunikációs csatornában, ahol rejtjelezés nélkül lehetne látni az adatokat és közbe lehetne ékelődni. A jelen bejegyzésben pontosan azt mutatom be, hogy mire lehet képes egy rosszindulatú támadó, ha egy eID-védelem nélküli, hagyományos chipkártyával (pl. olyannal, amit egy hitelesítés-szolgáltatótól kap) találja magát szemben.

A gyártók súlyos összegeket (kb. $250.000 - $350.000) fizetnek azért, hogy független IT biztonsági auditorokat bízzanak meg azzal, hogy termékeiket átvizsgálják. A vizsgálatok alapját a FIPS (Federal Information Processing Standards) vagy a CC (Common Criteria) módszertan adja. Az utóbbi esetében az "EAL 3" értékelési garanciaszint még éppen a "fekete dobozos" szintet jelzi, azonban "EAL 4" esetében már a forráskód bizonyos részeit ("subset of the implementation") is megvizsgálják. A chipkártyák maguk tehát elvileg bevehetetlen erődítménynek bizonyulnak, nem is a főkapun, hanem inkább a vár alatti barlangrendszeren keresztül érdemes támadni. Egy kiválasztott, a piacon jelenleg is kapható, hitelesítés-szolgáltatóktól beszerezhető chipkártya kommunikációjának IT biztonsági vizsgálatához az E-Group saját forensic tool-ját használtuk (Psenák Péter kollégám keze munkája). Hogy mire jó, ha egy chipkártyás aláírás-létrehozási folyamat teljes dump-ja nyílt szövegként a kezünkbe kerül? Nos, egy OpenSC segítségével visszajátszhatók az APDU-k (Application Protocol Data Unit), innentől kezdve pedig mindenkinek a saját fantáziájára bízom, hogy végiggondolja, ez hova vezethet...

Az APDU-k értelmezéséhez az ISO/IEC 7816 szabványsorozatot kell elővennünk, a visszajátszáshoz pedig az OpenSC-t. A teljes kommunikációból most csak a lényegre koncentrálok.

Az OpenSC-vel az alábbi parancsokat visszajátszva lehet végrehajtatni egy PIN kódos engedélyezést és digitális aláírás létrehozását a kísérletben szereplő chipkártyán:

A "SELECT FILE" (0xA4) - nevéből adódóan - egy állományt (pl. tanúsítványt a kulcsazonosításhoz) jelöl ki a kártyán, a kijelölés mindaddig érvényben marad, amíg másik "SELECT FILE" kiadásra nem kerül. Ennek megfelelően a "READ BINARY" (0xB0) is az utoljára kijelölt állományon hajtódik végre. A "VERIFY" (0x20) a PIN kód vagy jelszó ellenőrzését jelenti. Az alábbi példában látszik, hogy 64 byte hosszú lehet a bemenő jelszó, ebből csak 8 byte-ot használ ki a felhasználó (jelszó: 11111111, ahogy azt a sok 0x31 is jelzi), a többi padding. A "PERFORM SECURITY OPERATION" (0x2A) adja meg a feldolgozandó lenyomatot (a jelen esetben két részletben), majd hajtatja végre a digitális aláírás kiszámolását, azaz a bemenő lenyomat kódolását a titkos kulccsal. A "GET RESPONSE" (0xC0) utasítással lehet lekérdezni a kiszámított digitális aláírás értékét.

Hol is lehet trükközni? Nos, ha valaki (pl. háttérben futó trójai) esetleg mást szeretne aláírásra beküldeni a chipen tárolt titkos kulcsnak, akkor más lenyomatot kell megadnia a bemeneten. Az adatok módosításánál arra azért figyelni kell, hogy ASN.1 struktúrával van dolgunk, azaz binárisan ASN.1-valid adathalmaznak kell lennie a beküldendő byte-tömbnek!

A félreértések elkerülése érdekében hangsúlyoznám, hogy maguk a kártyák az elvártaknak megfelelően működnek, a hitelesítés-szolgáltatókkal sincsen baj, a problémát a környezet jelenti - jelen esetben Windows - azaz a javítást is a Microsoft-tól kell várni. A másik lehetőség a trükközések ellen a már emlegetett eID keretrendszer alkalmazása, amely rendes challenge-response alapján rejtjelezett csatornát tud kiépíteni a kártya és a terminál, a hívó alkalmazás között, ennek megfelelően a kommunikáció (pl. jelszó) megfigyelése sem olyan egyszerű már.

(A további részletekről és demo anyagokból valószínűleg egy komolyabb előadás is fog születni, a jelen bejegyzés csak ízelítőül szolgált.)

Kapcsolódó anyagok:
 vissza 
   
  info@kormanyablak.org
info@ugyfelkapu.info