Návrh experimentálního systému

Kompletní diplomová práce (PDF formát) je zde (diplomka.pdf).

Jednotlivé programy se zdrojovými kódy pro DELPHI 4.0:
Peněženka
Banka
Obchodník
CGI
a potřebné komponenty THashManager, TCipherManager a TRSA

1.1 Požadavky na platební systém

Elektronický platební systém by měl splňovat tyto funkce:

Bezpečnost
Bezpečná komunikace mezi subjekty
Ověření protistrany
Prokazatelnost původu zpráv
Integrita dat

Přístupnost
24 hodin denně
Z jakéhokoliv počítače připojeného k Internetu
Pro jakéhokoliv zákazníka, obchodníka či banku
Žádné speciální hardwarové nároky (speciální čtecí a ověřovací zařízení)
Použití systému není vázáno na platební kartu, ale na číslo účtu v bance

Použitelnost
Nákup a prodej
Převody peněz z účtu na účet

Platební systém musí obsahovat kompletní sadu protokolů pro jednotlivé peněžní transakce. Součástí systému by mělo být i ošetření některých dalších jevů, ke kterým může docházet. Těmito jevy míním např. různé snahy o oklamání systému, apod.. Při konstrukci jednotlivých protokolů jsou vznášeny různé požadavky, které je možno obecně rozdělit na obchodní (marketingové) a technické. Přičemž samozřejmě obojí spolu úzce souvisí. Jestliže chci provozovat nějaký platební systém, tak mě kromě samotných protokolů musí zajímat mnohem větší okruh otázek. Tyto otázky se týkají např. přenosového média, které chci používat ke komunikaci, hardwarového vybavení (počítače, modemy a další) a jejich předpokládaného zatížení, ale třeba také ceny za napojení jednoho zákazníka a obchodníka, množství potenciálních uživatelů, vlastnosti použitelné pro propagaci, atd.

1.1.1 Obchodní požadavky

Jedním ze základních požadavků je to, aby byl systém akceptovatelný pro trh. Trhem zde myslím obchodníky a uživatele (zákazníky).

Při vzniku protokolu SET byly vzneseny tyto požadavky:
dosáhnutí celkové přijatelnosti snadnou realizovatelností a co nejmenším vlivem na obchodníky a koncové uživatele.
umožnit modulovou implementaci platebního protokolu do existujících zákaznických aplikací
minimalizovat změny ve vztazích zákazníci - poskytovatelé a nabyvatelé - obchodník
požadovat co nejmenší vliv na existující aplikace a infrastrukturu obchodníků, banky a platebního systému
poskytovat efektivní protokol z pohledu finanční instituce

Původ většiny požadavků je zřejmý a vychází z předpokladu (do značné míry oprávněného), že pokud chcete po lidech, aby se naučili používat něco nového a zároveň do toho měli sami investovat, tak se velkého vděku nedočkáte. Druhým z cílů uvedených požadavků je jediné - přesvědčit zákazníky (uživatele a obchodníky), že novou věc prostě potřebují a hlavně, že na tom vydělají. Jestliže se toto nepodaří, tak ani sebelépe technicky navržený platební systém v konkurenci neuspěje. Máme dva základní požadavky, které jdou do jisté míry proti sobě. Je otázkou, na který z nich dáme větší důraz.

1.1.2 Technické požadavky

Technické požadavky směřují k zajištění funkčnosti a bezpečnosti platebního systému. Hlavní požadavky na platební protokoly by mohly znít takto:
poskytovat důvěrnost platebních informací a zajistit důvěrnost informací z objednávek
zajistit integritu všech přenášených dat
poskytovat autentizaci uživatele (držitele karty), jak ve vztahu k bance (vlastnictví účtu), tak ve vztahu k obchodníkovi (peníze jsou v pořádku)
umožnit autentizaci obchodníka ve vztahu k uživateli (prodávám zboží, které nabízím), aby mohl přijímat elektronické peníze
dostatečné použití bezpečnostních postupů a technik při návrhu systému k ochraně všech legitimních účastníků platebního protokolu
zajistit, aby byl protokol nezávislý na bezpečnosti přenosových mechanismů
při pokusu o obelstění systému je možné jednoznačně určit viníka a na základě této identifikace ho příslušným způsobem postihnout

Tyto požadavky jsou zajištěny implementací čtyř základních principů. Všechny tyto principy jsou v navrženém systému použity. Jmenovitě jsou to:
důvěrnost - označuje vlastnost zprávy, kdy její obsah je znám pouze odesílateli a zjistit ho může pouze příjemce. Jakákoliv jiná strana, která zprávu získá není schopna obsah v rozumné době zjistit
integrita - zajištění integrity označuje stav, kdy obsah zprávy je při příjmu shodný s obsahem odeslaným. Porušení integrity musí být rozpoznatelné.
autentizace - je proces, kdy jedna strana dokazuje svou totožnost druhé straně. To platí jak o osobě, tak například o instituci, nebo počítači.
neodmítnutelnost odpovědnosti - úzce souvisí s autentizací, zajišťuje, že se nemohu zbavit odpovědnosti za akce, jichž jsem původcem.

1.1.2.1 Důvěrnost informací

Pro usnadnění a podporu elektronického obchodu je nutné ujistit uživatele, že citlivé informace, které používají při činnosti v rámci platebního systému jsou bezpečně uloženy a přístupné pouze tomu, komu jsou určeny. Proto musí být informace o platbách, objednávaném zboží, čísla účtů uživatelů zajištěny nejen při přenosu, ale i při archivaci. V opačném případě by samozřejmě mohlo dojít ke zneužití těchto citlivých informací neautorizovanou stranou. V současné době, kdy drtivá většina informací je přenášena přes otevřené sítě bez jakéhokoliv zabezpečení, je nutné používání kryptografie. Příkladem může být např. placení zadáním čísla kreditní karty. Je jen otázkou času, kdy se tyto důvěrné informace pokusí někdo zneužít. S pomocí počítačů je možno nadělat mnohem větší škody v mnohem kratší době. Jestliže se tato činnost zautomatizuje vytvořením speciálních programů, tak výsledná škoda bude nesrovnatelná s klasickými podvody bez použití výpočetní techniky.

1.1.2.2 Integrita dat

Specifikace musí zajistit zachování obsahu zpráv při přenosu mezi jednotlivými stranami protokolu, a případnou detekci neautorizovaných změn. Je jasné, že ve chvíli kdy tato vlastnost nebude zajištěna, je otevřena brána pro různá individua, která poté mohou s malou námahou páchat vysoké škody. Jestliže se změní některá z položek objednávky, osobní data, nebo platební instrukce (a nejen úmyslně, ale i chybou při přenosu), tak to může vést k chybám, nebo (a to je mnohem pravděpodobnější) k podvodům. Proto je nutné použít mechanismy, které zajistí, že obsah přenesené zprávy je přesný a že nedošlo k jeho změně. Jestliže bude zjištěn opak, musí být zpráva odmítnuta a případně vyžádat opakování zaslání zprávy.

1.1.2.3 Autentizace

Třetí princip v pořadí. Při použití algoritmu RSA má každý účastník systému dva klíče: veřejný a soukromý. Soukromý používá on sám a nikomu ho nesděluje. Veřejný klíč je naopak rozšiřován mezi všemi, kteří chtějí s tímto účastníkem komunikovat.V této fázi je nutno zajistit, že veřejný klíč účastníka XY skutečně patří účastníku XY a ne někomu, kdo se za něj vydává. Pro splnění tohoto požadavku se používají jiné mechanismy, jež budou popsány dále. Teprve takto zajištěný klíč už může sloužit k autorizaci tohoto účastníka kdykoliv dále.

1.1.2.4 Neodmítnutelnost odpovědnosti

Princip neodmítnutelnosti odpovědnosti slouží k jednoznačnému určení totožnosti původce ať už nějaké zprávy, nebo činnosti. Zásadní odlišnost od autentizace je v tom, že uřčení totožnosti původce se v tomto případě provádí až po uskutečnění sledované činnosti. Nemohu tedy zabránit provedení nežádoucích akcí, mohu pouze následně určit jejich původce. V platebním protokolu je tento princip nutný k tomu, aby bylo možné zjistit a následně postihovat účastníky systému, kteří se nechovají podle pravidel.

1.2 Teoretické řešení

1.2.1 Bezpečnostní požadavky

Autentizace spočívá v ověření totožnosti protistrany. Zákazník zadá svoje iniciály (jméno, příjmení, rodné číslo, atd..) a heslo. Z bezpečnostních důvodů není dobré posílat tyto privátní údaje přes veřejnou síť jakou Internet je. A proto se z těchto údajů vypočte hashovacím algoritmem kód, který je posílán přes Internet k protistraně. Hashovací algoritmus je samozřejmě jednocestná funkce, takže z výsledného kódu nelze zpětně určit vstupní data.
Pro zabezpečení přenášených dat je použita metoda šifrování a digitálního podpisu. Je použita kombinace symetrického a asymetrického šifrování.

1.2.1.1 Vstupní hashovací algoritmus

Jako vstupní hashovací algoritmus je použit Secure Hash Algorithm (SHA). Výstupem tohoto algoritmu je 160-ti bitový digest.

1.2.1.2 Symetrické kódování

Pro symetrické kódování je použit algoritmus TRIPLE DES (3DES) s délkou symetrického klíče 192 bitů. Tento klíč je vždy náhodně generovaný. Při aktivaci spojení mezi dvěma subjekty se vygeneruje pokaždé jiný náhodný klíč.

1.2.1.3 Asymetrické kódování

Pro asymetrické kódování je použita metoda RSA, tj. metoda privátního a veřejného klíče. Délka klíče je 512 bitů. Metoda RSA spočívá v tom, že co se zakóduje pomocí veřejného klíče, to se musí dekódovat pomocí privátního a veřejného klíče.
Pozn.: Možné modifikování vzhledem k bezpečnosti:
Délka klíče může být až 2048 bitů. Na počátku spojení, mezi dvěma subjekty, mohou být privátní a veřejné klíče nově vygenerovány a tím by se značně zvýšila bezpečnost platebního systému.

1.2.1.4 Digitální podpis

Digitální podpis je výstupní kód z hashovacího algoritmu, který je zakódován veřejným klíčem protější strany. Zde je, jako hashovací algoritmus, použit standardní Message Digest 5 (MD5).

1.3 Programové řešení

Platební systém jsem naprogramoval v DELPHI 4.0 pro Windows 95/98. Skládá se ze čtyř samostatných programů - Peněženka, Obchodník, Banka a CGI. Každý z těchto programů je samostatně spustitelný na jakémkoli počítači s operačním systémem Windows 95 nebo vyšší a samozřejmě připojených na Internet. Pro symetrické kódování a hashovací algoritmy jsem použil komponenty TCipherManager a THashManager. Pro asymetrické kódování jsem použil komponentu TRSA.

1.3.1.1 Peněženka

Program je navržen tak, aby byl přístupný pro jakéhokoliv uživatele, tzn. může být nainstalován na veřejně přístupných počítačích. Na počítač, kde je tato peněženka nainstalována, se neukládají žádné privátní údaje o uživatelích, takže nemůže dojít k jejich zneužití. Funkci peněženky by mohl obstarávat i web server banky, ale z hlediska větší bezpečnosti a rychlosti zpracování je lepší mít program na lokálním disku. Program má dvě funkce. První je, že peněženka je použita k vyvolání platební transakce (program je spuštěn automaticky WWW prohlížečem) a druhá, že peněženka si vyžádá od banky zákazníka výpis všech provedených plateb (program si spustí uživatel sám z příkazové řádky).

1.3.1.2 Obchodník

Je to program, který vlastně spolu s programem CGI zajišťuje zázemí obchodníka.

1.3.1.3 Banka

Tento program je složen ze tří částí - Banka zákazníka, Banka obchodníka a Platební brána.

Pro správnou funkci tohoto systému musí být spuštěny všechny tři části. Každá z těchto částí se dá vypnout, ale je nutné tento program spustit na jiném počítači. Poté je ale zapotřebí správně nakonfigurovat URL adresy všech subjektů. Banka zákazníka reprezentuje banku, kde má každý zákazník svůj účet. V bance se zadávají noví zákazníci. Dále se mohou editovat nebo rušit. Banka ověřuje solventnost zákazníků a zaznamenává všechny jejich platební transakce.
Banka obchodníka reprezentuje banku, kde má každý obchodník svůj účet. V bance se zadávají nebo mažou noví obchodníci. Banka zaznamenává všechny platební transakce obchodníků.
Platební brána je program, který dává příkazy bance zákazníka a bance obchodníka k převodu peněz z účtu zákazníka na účet obchodníka.

1.3.1.4 CGI

Tento program generuje WWW stránky Virtuálního Obchodního Domu a posílá MIME zprávu s objednaným zbožím internetovému prohlížeči, který po přijetí této zprávy zaktivuje peněženku.
MIME zpráva zaslaná ze serveru obchodníka WWW prohlížeči zákazníka, který po jejím přijetí aktivuje elektronickou peněženku a ta ji zpracuje:

Mime version: 1.0
Content-Type: text/plain
Content-Length: 0
Content-Transfer-Encoding: binary
SET-Initiation-Type: Payment
SET-Version: 0.0
SET-SET-URL: http://200.0.0.2/cgi-bin/DiplomkaCGI.exe/PlatitSETem
SET-Success-URL: http://200.0.0.2/cgi-bin/DiplomkaCGI.exe/Uspech
SET-Failure-URL: http://200.0.0.2/cgi-bin/DiplomkaCGI.exe/Chyba

Gun Coolant Mk IV;10;480000
Gun Coolant Mk II;5;60000
BSE Mk II;10;180000

1.4 Popis funkce a toku dat

1.4.1 Popis funkce

Po klepnutí na tlačítko "Zaplatit" se zaktivuje Peněženka. Nejprve je nutné zadat jméno, příjmení, rodné číslo a heslo. Do políčka URL banky se musí zadat URL adresa banky zákazníka.
Po klepnutí na tlačítko OK se spustí vlastní platební transakce. Z uvedených údajů se vypočte hashovací kód, který je později použit pro identifikaci zákazníka. Vymění si s bankou zákazníka veřejné klíče a pošle bance symetrický klíč. Poté u banky zákazníka zjistí zůstatek na účtu daného zákazníka a URL platební brány. Dále zjistí z objednaného zboží celkovou cenu a porovná jí se zůstatkem na účtu. Je-li dostatečný zůstatek na účtu, tak se pokračuje dále, jinak se transakce přeruší. Spojí se s platební bránou a vymění si veřejné klíče a pošle platební bráně symetrický klíč. Dále se spojí s obchodníkem a také si vymění veřejné klíče a pošle obchodníkovi symetrický klíč. Poté vygeneruje dvojitou zprávu. Jedna část je zakódována veřejným klíčem platební brány a druhá část veřejným klíčem obchodníka. V první části je hashovací kód zákazníka a v druhé části je objednané zboží od obchodníka.
Obchodník dvojitou zprávu přijme dekóduje svojí část, určí celkovou cenu objednávky a objednané zboží. Vymění si s bankou obchodníka veřejné klíče a pošle bance symetrický klíč. Od banky obchodníka zjistí URL platební brány. Vymění si s platební bránou veřejné klíče a pošle jí symetrický klíč. Vloží do dvojité zprávy svůj hashovací kód zakódovaný veřejným klíčem platební brány. Pošle platební bráně dvojitou zprávu a poté ještě celkovou cenu objednaného zboží. Platební brána přijme dvojitou zprávu a dekóduje obě části zprávy a tak dostane identifikační kódy zákazníka a obchodníka. S bankou zákazníka si vymění veřejné klíče a pošle bance zákazníka symetrický klíč. Dále pošle bance identifikační kód zákazníka a obratem dostane číslo účtu zákazníka. Poté pošle bance zákazníka částku k převedení z účtu zákazníka na účet obchodníka. S bankou obchodníka si vymění veřejné klíče a pošle bance obchodníka symetrický klíč. Poté pošle bance obchodníka identifikační kód obchodníka a obratem dostane číslo účtu obchodníka. Dále pošle bance obchodníka částku, kterou má připsat na konto obchodníka. Bance zákazníka pošle číslo účtu obchodníka.Jestliže nedošlo k žádné chybě během přenosů zpráv a jejich zpracování, tak platební brána všem účastníkům transakce rozešle zprávu o úspěšném ukončení transakce.
Jestliže ale během zpracování došlo k nějaké chybě, tak subjekt u kterého došlo k chybě, rozešle zprávu s chybovým hlášením všem do té doby zúčastněným subjektům a transakce se ukončí.

1.4.2 Tok dat

Na následujícím obrázku je zobrazen tok dat při platbě v platebním systému. Šipka znázorňuje směr toku dat. Na začátku každé šipky je číslo, které je identifikačním číslem zprávy. Nad šipkou je vždy informace o datech. V následující tabulce je seznam všech identifikačních čísel zpráv. ID označuje číslo zprávy, odpověď A resp. N značí, že zpráva vyžaduje resp. nevyžaduje odpověď.

Pozn.:
* - Dvojitá zpráva obsahuje v první části hash kód zákazníka a v druhé soupis objednávaného zboží.
** - Dvojitá zpráva obsahuje v první části hash kód zákazníka a v druhé části hash kód obchodníka.
*** - Při výpisu provedených plateb se ve zprávě žádosti posílá hash kód zákazníka a obratem se dostává zpráva ve které je seznam provedených plateb.

Na následujícím obrázku je zobrazen tok dat při výpisu plateb.

4.4.3 Formáty zpráv

Každá zpráva má tuto strukturu:
ID zprávy - hexadecimální číslo (2 bajty)
Délka zprávy - hexadecimální číslo (4 bajty)
Zpráva - řetězec hexadecimálních čísel (proměnná délka)

1.4.3.1 Veřejný klíč

Při odeslání se veřejný klíč převede na řetězec dvojic znaků, přičemž každá dvojice znaků odpovídá hexadecimálnímu číslu jednoho ASCII znaku veřejného klíče. Tzn., že se posílá zpráva s dvojnásobnou délkou než je délka samotného veřejného klíče. Po tomto převodu se přidá hlavička zprávy, tj. ID zprávy a délka zprávy. Po přijmutí zprávy s takto převedeným veřejným klíčem se musí odpovídajícím způsobem veřejný klíč rekonstruovat.

1.4.3.2 Symetrický klíč

Před odesláním symetrického klíče se symetrický klíč zakóduje pomocí veřejného klíče příjemce a převede se na hexadecimální formát. Poté se přidá hlavička zprávy a zpráva se odešle. Po přijmutí zprávy se zakódovaným symetrickým klíčem se zpráva převede z hexadecimálního formátu na ASCII formát a dekóduje se pomocí privátního a veřejného klíče příjemce.

1.4.3.3 Jednoduchá zpráva

Nejdříve se vypočte message digest (MD5) ze zprávy a poté se tento digest zakóduje veřejným klíčem příjemce. Tímto je vytvořen digitální podpis. Vytvoří se obálka, která obsahuje délku zprávy (4 bajty), samotnou zprávu, délku digitálního podpisu (4 bajty) a digitální podpis. Tato obálka se poté zakóduje symetrickým klíčem (metoda Triple DES) a převede se na hexadecimální formát. Nakonec se připojí hlavička a zpráva se odešle. Po přijmutí zakódované zprávy se obálka převede z hexadecimálního formátu na ASCII a dekóduje se symetrickým klíčem. Z obálky se vyjme zpráva a digitální podpis, který se následně převede na ASCII formát. Digitální podpis se dekóduje pomocí privátního a veřejného klíče příjemce. Ze zprávy se vypočte nový message digest a porovná se s dekódovaným message digestem ze zprávy. Jestliže si tyto hodnoty odpovídají, pak je vše v pořádku. Jestliže si ale neodpovídají, pak je zpráva nahrazena zprávou s chybovým hlášením.

1.4.3.4 Dvojitá zpráva

Vytvoření dvojité zprávy je analogické jako vytvoření jednoduché zprávy, ale s tím rozdílem, že odesílaná zpráva je složená ze dvou jednoduchých zpráv. Dekódování dvojité zprávy je trochu složitější, protože se nedekódují obě zprávy najednou, ale pouze jedna a druhá se pouze oddělí od první. Dekódování první zprávy je analogické jako dekódování jednoduché zprávy. Druhá zpráva se musí dekódovat zvlášť, protože se musí zajistit to, aby některý příjemce mohl dekódovat pouze jednu zprávu a některý mohl dekódovat obě zprávy. Na dekódování druhé zprávy je použita funkce k dekódování jednoduché zprávy.