2008-07-15

JavaCard Classic

Volt egy projekt egy-két hónapja, amiben JavaCard technológiát használtunk. Most már teljes a skála, JavaCard-tól MIDP-n és Standard Edition-on keresztül a J2EE-ig mindent programoztam Java-ban. Igaz, a JavaCard-nak éppenhogy csak karcoltam a felszínét, de arra ez is elég hogy rálátás legyen. Most csak konyhanyelven írom le hogy megy ez a dolog:

Gyakorlatilag java-t kell programozni, de az osztálykönyvtár irdatlanul le van csupaszítva és csak 2 bytes-os adatszerkezetek vannak, tehát tele van az egész kód short kasztolásokkal és tömbműveletekkel. Úgynevezett javacard appleteket kell programozni, amiknek saját primitív tranzakciókezelésük és belső security managementjük van, lényegében perzisztens szerkezetűek és byte alapú módon kell kommunikálni velük. A kártyában pár kilobájt EEPROM áll rendelkezésünkre a programhoz és az eltárolt adatokhoz. Egy kártyára több appletet is installálhatunk. Sok firkálás után a kártya szépen tönkremegy.

A kártya valójában nem igazi bájtkódot futtat, hanem speckó eszközzel kell lefordítani a java forrást egy jobban megemésztett formátumra. Például a standard java-val ellentétben a linkelési információk nem kerülnek be a lefordított bináris állományba, hanem azokat egy másik állományban tárolják kb. név, index párokként. Az eszköz és a doksik letölthetőek a netről, van valami plugin Eclipse-hez (JCOP) ami szimulálni tudja a kártyát és kommunikálni tud magasabb szinten a géphez csatlakoztatott kártyaolvasókkal.

Az appletnek van egy belépési metódusa, ami egy az egyben megkapja azokat a bájtokat, amiket a kártya vett a külvilágtól akár a felületre integrált csatlakozási pontok, akár egyéb átviteli módszerrel. Pl. vannak RFID-vel vagy NFC-vel kommunikáló kártyák. Az RFID egyébként hasonlóan működik mint egy trafó. Váltakozó áram indukálódik a kártyában, ami egyben magát az adatot is jelenti, emellett a kártya áramellátását is megoldja arra az időre amíg az adatok feldolgozódnak. vicces nem?

Visszatérve a bájt tömbre: van egy viszonylag kötött formátumú fejléce, amit a kártya mini oprendszere kiértékel. Ez az első körben max kb 256 byte hosszú bájtsorozat használható az authentikációra, új applet telepítésére, törlésére, kiválasztására, befixálására. Megfelelő számú partizán kísérlet után a kártyát jól le lehet tiltani örökre. Ugyanezt a bájtsorozatot használhatjuk az appletben a saját protokoll kialakításához. Hosszabb bájtsorozatokra van valami összeillesztős mechanizmus.

A konvencionális java SE programokkal ellentétben a javacard applet mezőváltozói perzisztensek, azaz ha valamit beállítok az úgy is marad magától. Tehát mezőváltozóban lehet tárolni ilyeneket, hogy hányszor használták a kártyát. Ha jól emlékszem van valami commit-szerű művelet is, amivel gondoskodni lehet (kell?) róla, hogy a beírt értékek valóban perzisztálódjanak, és ezt ráadásul egyszerre tegyék. A változtatásokat a javacard egy kb 256 byte-os RAM pufferben gyűjti és a commit-nál beírja az EEPROM-ba. Ha túl sok változtatást akarunk csinálni, a puffer túlcsordul és hibát kapunk.

A kimenet szintén egy bájtsorozat. Össze kell rakni és elküldeni. PC oldalon vannak driverek, amikkel meg lehet hajtani mindenféle csatlakoztatott kártyaolvasókat, de most hirtelen nem is tudom milyen interfész van hozzájuk.

Ahogy a Sun Java Cafés postban írtam, a 3-as JavaCard verzióban bevezetnek egy új programozási módot, amiben magasabb szinten, szervletekkel (ezek sem igazi szervletek) lehet programozni a kártyákat. Ezt nevezik Connected Edition-nek.

Amiről én írtam az még a régebbi spec, amit meghagytak és Classic Edition-nek hívják.

3 megjegyzés:

]-[appy írta...

Tok jo osszefoglalo volt. Ha nem indiszkret, milyen projektben hasznaltatok a JavaCardot?

pcjuzer írta...

Köszi! Sajnos komolyabb részletekről nem írhatok, de egyébként csak a szokásos funkciók szerepeltek a projektben: személyi authentikáció, beléptetés, kisebb címletű fizetés.

]-[appy írta...

:) Megertem.