Česká pobočka Symantecu vydala tlačovú správu o nimi zamýšľanom napredovaní antivírusových riešení. V nej je spomenutých hneď niekoľko zaujímavých štatistických čísel (okrem iného z nich aj vyplýva, že cena za ukradnuté World of Warcraft konto je niekoľkonásobne vyššia ako cena ukradnutých informácií o kreditnej karte) – podľa Symantec-u bolo na konci roku 2007 viac ako 1 200 000 variánt malware. V ich štúdii je tiež spomenuté, že v roku 2007 bolo 65% všetkého uvoľneného unikátneho software charakterizovaného ako nebezpečný kód.

A tieto alarmujúce čísla napovedajú, že bude v budúcnosti jednoduchšie identifikovať neškodný software ako identifikovať malware. Tu ale správnemu paranoikovi vhupne do hlavy ďaľšie spiknutie. Buď bude používať antivírus, alebo bude neustále atakovaný malware-om. Antivírus ale bude musieť na základe rôznych algoritmov / databáz identifikovať spúštaný (resp príchodzí) software (teda bude mať dokonalý prehľad nie o infikáciách počítača, ale o jeho regulérnom software) a navyše bude rozhodovať o tom, či ho dovolí na počítači spustiť (resp vôbec uložiť). Toto môžu byť dosť citlivé informácie/schopnosti a nechcel by som, aby nimi nejaký program disponoval (a čo si ešte paranoik môže myslieť o zasielaní týchto informácií na “anonymné štatistiky” )

V tomto článku by som chcel ozrejmiť, ako fungujú internetové platby cez i-banking. Prednedávnom som niektoré platobné systémy implementoval a preddávnom ma veľmi zaujímalo, ako asi tieto platby fungujú (a preto sa s vami, o mnou nadobudnuté informácie, delím). Na príklade budem opisovať komunikáciu medzi aplikáciou e-shopu a aplikáciou internetbankingu.

Opisovaná situácia: zákazník si na e-shope vyberie tovar, potvrdí objednávku a chce zaplatiť cez i-banking svojej banky.

Priebeh platby

Po objednávke musí zákazník zvoliť, aký druh platby použije na zaplatenie, pretože aj keď majú slovenské banky (aspoň tie, s ktorými mám skúsenosť) veľmi podobné protokoly na platby, nie sú rovnaké a napríklad Tatra banka má dokonca 2 druhy platieb (TatraPay a CardPay). E-shop následne má všetky informácie, aby vygeneroval payment request (na obrázku krok 1). V payment requeste je okrem iného uvedená suma, identifikácia obchodníka (e-shopu), identifikátor platby (variabilný symbol, niekedy aj špecifický symbol a konštantný symbol) a návratová url na stránku obchodníka. Payment request bude zaslaný banke prostredníctvom zákazníkovho browsra – teda potenciálne nebezpečným kanálom. Preto treba dodatočne zabezpečiť integritu a autenticitu dát uvedených v payment requeste.

Používaným spôsobom zabezpečenia payment requestu je podpis prenášaných dát. Podpísané musia byť všetky dôležité atribúty uvedené vyššie. Tieto sú skombinované do základu podpisu, z ktorého sa spraví hash. Hash sa následne zakryptuje symetrickou šifrou (používanými sú DES a 3DES) kľúčom, ktorý je známy iba obchodníkovi a banke (kľúče samozrejme rozdeľuje banka a každému obchodníkovi by mala prideliť iný kľúč), a vypadne podpis. Podpis je pridaný ako ďaľší atribút payment requestu.

E-shop teda má už kompletné údaje o payment requeste. Väčšinou sú to dvojice názov-hodnota, ktoré sa podľa špecifikácie príslušného protokolu zapracujú do HTML formu alebo URL a zobrazené v zákazníkovom prehliadači. Zákazníkov browser potom opustí obchodníkov web odoslaním payment requestu na server banky (podľa typu platby GET alebo POST HTTP requestom) (na obrázku kroky 2,3).

Banka následne autentifikuje zákazníka (prihlasovacími údajmi do i-bankingu, grid kartou, “kalkulačkou”…) a ten môže potvrdiť platbu (na obrázku krok 4). Ešte pred potvrdením platby ale musí banka samozrejme overiť digitálny podpis payment requestu a ten aj validovať (či sú správne zadané údaje etc.). Po potvrdení platby banka spracuje transakciu a vygeneruje payment response, ktorý obsahuje minimálne identifikátor platby (variabilný symbol) a výsledok transakcie. Prirodzene aj payment response je chránený digitálnym podpisom, ktorý sa spravidla generuje rovnakým postupom ako v payment requeste. Výsledky platby môžu byť OK (transakcia prebehla/prebehne), fail (transakcia neprebehne) a pri niektorých typoch e-platieb tiež timeout (platba zatiaľ neprebehla). Keď už banka vygenerovala payment response, zákazníkov browser je s payment response-om presmerovaný naspäť na stránku obchodníka (na obrázku kroky 5,6) (stránka obchodníka, kam má byť zákazník presmerovaný po spracovaní transakcie, bola uvedená v payment requeste – väčšinou sa používa HTTP GET).

Obchodník musí overiť podpis a validnosť payment response-u a ak sa to podarí, môže spracovať výsledok platby (na obrázku krok 7). Najprv musí spárovať platbu, ktorej sa payment response týkal, s objednávkou, ktorú zákazník odoslal. Na toto slúži identifikátor platby. Ďalej môže pokračovať v spracúvaní objednávky.

Zabezpečenie

Ako ste možno postihli, o celé zabezpečenie doteraz opísaného protokolu sa starajú podpisy správ vymieňaných medzi bankou a obchodníkom. Potencionálnemu útočníkovi (zákazník) by teda stačilo vedieť vygenerovať želaný payment response a dobre ho podpísať, aby mohol obchodníka presvedčiť o tom, že za objednané produkt(y) už zaplatil. Preto je veľmi dôležité zabezpečenie tajného symetrického kľúča, ktorý nesmie uniknúť ani z banky, ani od obchodníka.

Toto môže byť celkom riskantné, preto banky obchodníkovi väčšinou posielajú zabezpečeným mailom sumáre platieb realizovaných cez i-banking. Obchodník tak môže zistiť, ktorá objednávka v skutočnosti zaplatená nebola.

Záverom

Opisoval som spoločné vlastnosti fungovania internetových platieb. Samozrejme, že niesú všetky rovnaké. Niektoré protokoly môžu mať podporu na session dáta obchodníka, niektoré používajú okrem variabilného symbolu aj ďaľšie vlastnosti na identifikáciu platby, niektoré majú podporu na zadanie jazyka zobrazeného i-bankingového systému v payment requeste a podobne.