Mobil Fizetési Protokollok Kustos Bálint B7KHSX 2010. November
Az elektronikus fizetési módszereknek több előnyük is van a hagyományos készpénzzel szemben. A készpénz előállítást, szállítást és tárolást igényel, ezzel szemben az elektronikus pénz kényelmet jelent a felhasználók számára és jóval olcsóbb a kezelése. A mobil eszközök elterjedése megfelelő platformot nyújthat egy elektronikus jellegű fizetési rendszer kialakítására, azonban, mint minden pénzzel kapcsolatos tevékenység esetében, a biztonság elsőrangú prioritást igényel. Egy mobil fizetési rendszer elsősorban öt főbb résztvevőt tartalmaz: • Financial Service Provider, ami általában bankot jelent, • Payment Service Provider, ő az aki a tranzakciókhoz szükséges hardvert és szoftvert biztosítja • Mobile Network Operator, aki a kommunikációs infrastruktúrát nyújtja • Fizető fél • Fizetendő fél Egy ilyen rendszer tervezése során a biztonságot minden rétegben ellenőrizni kell, egy mobiltelefon hálózatra épített esetén például a mobil készülékek és a hálózat biztonságát is biztosítani kell. Egy tranzakció lépései Két különböző rendszert különböztetünk meg: távoli és helyi rendszer. Távoli rendszer esetén az alap architektúra a következő:
1. A vásárló egy Payment Requestet küld a PSP felé, mely tartalmazza az eladó adatait, a fizetendő mennyiséget, stb. 2. A PSP leellenőrzi a két fél jogosultságait, regisztráltak-e már a rendszerbe? A PSP felszólíthatja a vásárlót, hogy autentikálja magát. 3. A PSP megerősítést kér az eladó féltől 4. Az eladó megerősíti a tranzakcióról szóló információkat 5. A PSP elvégzi a banki tranzakciókat az FSP-k segítségével 6. A vásárló számára küldött nyugtázással záródik a tranzakció Egy helyi rendszer esetén a különbség annyi, hogy a vásárló a Requestet az eladó félnek küldi, majd az továbbítja a PSP felé valamilyen infrastrukturán.
Osztályozni más szempont szerint is lehet: Micro-Macro payment, Prepaid-Postpaid.
Egy M-payment rendszer-t támogató technologiák réteges szerkezete:
A legfelső szinten a mobil fizetési protokoll van, alatta pedig valamilyen szoftverfejlesztői platform és egy kommunikációs infrastruktúra. Ezekből többféle is lehet, így a biztonsági analízis során figyelembe kell venni az aktuális rétegek biztonsági réseit és hibáit. Mivel az m-payment alkalmazás is olyan, mint bármely más szoftver, egy operációs rendszeren fut, azt pedig egy mobil hardver támogatja. Az előbbire veszélyt jelenthetnek különféle férgek vagy vírusok, az utóbbi pedig fontos kriptográfiai titkokat tartalmazhat. A fentiek alapján osztályozhatjuk a rendszer sérülékenységeit.
Az alábbiakban egy konkrét protokollt vizsgálunk meg, mely a Modified Secure Electronic Transaction névre hallgat. A protokoll az amúgy nem feltétlen mobil környezetbe szánt SET protokollon alapszik, melynek főleg a számításigényét próbálja lecsökkenteni, miközben a biztonságra vonatkozó előnyeit megtartja.
A SET protokoll A protokollnak három résztvevője van: A vásárló digitális tárcája (W), az eladó (M), és a payment gateway (PG). Először a vásárló és az eladó közt zajlik egy inicializálás, ami kihívás-válasz alapú üzenetváltást jelent. Az inicializálás során továbbá a két fél tanusítványokat cserél, a vásárló közli az eladóval a bankkártya típusát illetve a bank azonosító számát. Ezek után W egy kétszeresen aláírt üzenetet küld M-nek, azonban M az üzenetet felét tudja csak dekódolni, a másik felét továbbitja PG-nek, ezzel biztosítva azt, hogy M nem fér hozzá a bankkártya számhoz és egyéb fizetési információhoz, PG pedig nem fér hozzá a rendelésről szóló információkhoz. Elegendő információ ismeretében a PG végrehajtja a bankok közti transzfert, majd értesíti M-et az eredményről. A protokollt egy M-től W-nek küldött nyugta üzenet zárja. A protokoll részletekben: PinitRequest W által kezdeményezett üzenet M-nek, amihez W a közetkező lépéseket teszi: 1. H(PinitRequest) 2. EAPrivW(H(PinitRequest)) 3. ESSK(PinitRequest|EAPrivW(H(PinitRequest))|DCW) 4. EAPubM(SK) A PinitRequest tartalmazza a véletlen generált kihívást, a bankkártya típusát, a bank azonosítóját. Ennek az üzenetnek vesszük a hashét, majd W privát kulcsával kódoljuk. W frissen generál egy ideiglenes szimmetrikus kulcsot SK-t, majd ezt felhasználva kódolja a 3. lépésben látható üzenetet, ahol DCW a digitális tanusítvány, mely tartalmazza W publikus kulcsát. SK-t bekódolja az eladó publikus kulcsával, majd a 3. és 4. lépés üzeneteit átküldi M-nek. Összességében kétszer használtunk aszimmetrikus kulcsolást és egyszer szimmetrikust. Miután M megkapta az üzenetet, elsőnek a saját privát kulcsával kiszedi SK-t, majd azzal dekódolja a másik üzenetet. Az integritás ellenőrzése végett M is végrehajtja a hashelést, megszerzi W publikus kulcsát, amivel dekódolja EAPrivW(H(PinitRequest))-t, majd összehasonlítja a kapott lenyomatot a sajátjával. W aláírása biztosítja a letagadhatatlanságot is. PinitResponse Az elővel megegyező módon M küld egy ESSK(PinitResponse|EAPrivM(H(PinitResponse))| DCM) üzenetet, ahol a PinitResponse tartalmazza a kihívó stringet és egy egyedi tranzakciós azonosítót. W a dekódolás és ellenőrzés során egy-egyszer használja a kétféle kulcsolást. PRequest
Ez a W által küldött duplán aláírt üzenet lesz, mely a következőkből áll: 1. ESSK1(OM|EAPrivW(H(OM))|DCW)|EAPubM(SK1) 2. ESSK2(PM|EAPrivW(H(PM))|DCW)|EAPubPG(SK2) 3. EAPrivW(H(H(OM)|H(PM))) 4. EAPrivW(H(OM)) 5. EAPrivW(H(PM)) Az 1, 3, és 5ös üzenetdarabka M számára, a 2, 3, 4es pedig PG számára tartalmaz információt. OM tartalmazza a rendelés adatait, PM pedig a bankkártyaszámot, lejárati dátumot, stb. Az ellenőrzéshez M saját maga lehasheli az OM-t, mellérakja a kapott H(PM)-t, mindkettőt ujra lehasheli, majd összehasonlítja a kapott duplahash-sel. AuthRequest M továbbküldi PG felé a PRequest neki szánt darabkáit, PG szintén végrehajtja az ellenőrzést, majd ha minden stimmel, akkor megkezdi W és M bankjai közti tranzakciót. AuthResponse PG visszajelez M felé a tranzakció eredményéről. PResponse M nyugtát küld W felé, ezzel befejezve a protokollt. A Módosított SET protokoll Az MSET protokollban a legtöbb aszimmetrikus kulcsolást szimmetrikussal helyettesítünk. A SET protokoll 6 üzenetét egy kulcscsere fázis előzi meg: W, M és PG digitális tanusítványokat cserélnek, majd M és PG létrehoz három szimmetrikus kulcsot: 1. M generál egy Sw,m kulcsot, majd W publikus kulcsával kódolva elküldi W-nek. 2. PG generál egy Sm,pg kulcsot, majd M publikus kulcsával kódolva elküldi M-nek. 3. PG generál egy Sw,pg kulcsot, majd W publikus kulcsával kódolva elküldi W-nek. A SEThez hasonlóan itt is 6 üzenetváltás megy végbe: PinitRequest A PinitRequest ugyanazt az információt tartalmazza, mint a SET esetében, és itt is a hashével párosítva küldjük el: 1. H(PinitRequest) 2. ESSw,pg(PinitRequest|H(PinitRequest)) Az üzenet létrehozása során egyszer alkalmaztunk szimmetrikus kulcsolást.
M az integritás ellenőrzéshez kiszámolja a PinitRequest hashét, majd összehasonlítja a kapott hash-sel. A hitelesség is biztosított, mivel a kulcsot csak a két fél ismerheti. PinitResponse Visszafelé hasonló módon történik az inicializáció, W az ellenőrzés során egyszer dekódol szimmetrikus kulcs segítségével. PRequest
W 4-4 üzenetdarabkát készít, M és PG számára: 1. ESSw,m(OM) 2. ESSw,m(H(OM)) 3. ESSw,pg(H(OM)) 4. ESSw,pg(PM) 5. ESSw,pg(H(PM)) 6. ESSw,m(H(PM)) 7. ESSw,m(H(H(OM)|H(PM))) 8. ESSw,pg(H(H(OM)|H(PM))) M dekódolja a neki szánt részeket, ellenőrzi OM integritását, majd az egész üzenetét is.
AuthRequest PG is megkapja M-től a PRequest üzenetet, ellenőrzi az integritásokat, majd a kapott információt felhasználva megkezdi a tranzakciót a bankok közt. Az AuthResponse és PResponse üzenetek a SETnek megfelelő információt tartalmaznak, W-nek egy szimmetrikus kulcsú dekódolásra van szüksége a protokoll végén. A két protokoll összehasonlítása A W oldali aszimmetrikus kulcsolások lecsökkentése jelentős teljesítménybeli javulást okozott, de biztonság szempontjából ugyanazok a jellemzői mindkettőnek. Az üzenet kódolás/dekódolások száma a következőképp alakul:
PinitRequest PinitResponse PRequest PResponse
SET 2xEA, 1xES 1xDA, 1xDS 5xEA, 2xES 1xDA, 1xDS
MSET 1xES 1xDS 8xES 1xDS
Tehát összességében SET esetén 7 EA, 2 DA és 5 ES/DS, MSET esetén viszont csak 11 ES/DS + 2 DA (a szimmetrikus kulcsok dekódolásából adódik) lépés hajtódik végre. A következő táblázat az egyes lépések időigényét mutatja, melyeket egy IPAQ – H3630 PocketPC-n mértek:
Művelet DES SHA 1024 bites RSA aláírás 1024 bites RSA ellenőrzés
Idő 0,07345 ms 0,19111 ms 78,2593 ms 5,0125 ms
1024es RSA és DES feltételezése esetén a táblázatokat felhasználva egy SET tranzakcio számítási időigénye W oldalon: 7x78,2593 ms + 2x5,0125 ms + 5x0,07345 ms = 558,20735 ms Ugyanez MSET esetén: 11x0,07345 ms + 2x5,0125 = 10,83295 ms, ami azt jelenti, hogy 98%-át lefaragtuk a számolásoknak.
