Bezpečná komunikace a důvěryhodnost v GISp[1]

 

Ondřej Šlapák

slapak@vse.cz

 

Katedra informačních technologií

Vysoká škola ekonomická v Praze

 

Abstrakt: Tento článek je souhrnem vybraných témat vztahujících se k problematice bezpečné komunikace a důvěryhodnosti v globální informační společnosti. Předpokládá, že běžné obchodní vztahy budou uzavírány elektronicky na dálku a řeší tak vybrané problémy. Rozšiřuje referenční model ISO/OSI o bezpečnostní vrstvu. Pojednává o neprolomitelné šifře na bázi jednoduché XOR logické funkce. Dále řeší uzavření smlouvy na dálku a jak zajistit důvěryhodnost v podmínkách, kdy se na nás obrátí dosud neznámý subjekt. Konečně podává řešení problému vypršení platnosti šifrovacích klíčů v souvislosti s uzavřenými smlouvami.

Klíčová slova: bezpečnost, certifikační autorita, důvěryhodnost, komunikace, OSI , šifrování

 

Pozn.: Takto barevně jsou označeny pasáže, které v tištěné verzi tohoto článku nejsou.

1. Prostředky GISp

Globální informační společnost je představována nekončící informační aktivitou po celém globu, kdy dochází k interaktivní výměně, zpracování a využívání informací mezi všemi centry lidské společnosti.

Za prostředky umožňující fungování GISp považuji z „tvrdého pohledu“ na problematiku technologii, kterou lze chápat jako globální informační infrastrukturu (GII) a tedy i jako kritické faktory úspěchu GISp. Jde o informační a komunikační technologii (ICT), protokoly a instituce (ve smyslu souhrnu vztahů mezi lidmi upraveném právními normami), pomocí kterých je možné provádět bezpečnou vzdálenou transakci s právně garantovaným důsledkem. Prostředky GISp (především ICT) jsou pochopitelně neustále ve vývoji, čímž mohou ovlivnit charakter společnosti (třeba tak, jak se děje v posledních několika letech). Proto je nutné vytvářet právní/pracovní rámec pokud možno na technologiích nezávislý. Zároveň je však potřeba určit standardy, které zajistí možnost globální komunikace. K vytvoření právního/pracovního rámce je bezesporu nutná spolupráce subjektů různých vrstev.

Technologie GISp musí zajistit flexibilní propojení, bezpečnost (utajení a zajištění obsahu, identifikace původce, uzavření smlouvy, garance kvality) a společný jazyk (trochu podrobněji o tom všem viz [SLAO01-01]). A právě bezpečnou komunikací a důvěryhodností se budu zabývat v tomto článku. Důvod, myslím, je zcela jasný a není potřeba jej hlouběji rozebírat. Pokud například není možné bez rizika (resp. s rizikem maximálně stejným jako při dosud klasickém způsobu) uzavřít smlouvu na dálku s partnerem, se kterým jsem se nikdy neviděl, plnohodnotný rozvoj GISp bude jen snem.

Tento článek je spíše souhrnem jednotlivých témat vážících se k bezpečné komunikaci a důvěryhodnosti v GISp. Proto jsou některé pasáže spíše koncepční, zatímco jiné řeší věc více do podrobnosti. Ponechávám přitom stranou požadavky na technickou bezpečnost ve smyslu kvality přenosu, tj. že spojení nebude přerušeno a že ve zprávě nedojde k „ropuchám“[2]. Jsem si vědom, že problematika bezpečné komunikace je velmi dobře popsána v mnoha publikacích[3]. Zde však zůstanu na uživatelské úrovni a odprezentuji praktické zajištění požadavků bezpečnosti. Dále pak se věnuji vyšší úrovni bezpečnosti, kterou je důvěryhodnost.

 

2. Rozšíření ISO/OSI modelu

Prvním zařazeným, koncepčním tématem je rozšíření ISO/OSI modelu. Hovořím-li o komunikaci pomocí ICT, nemohu tento referenční model nezmínit[4]. Návrh jeho rozšíření spočívá v přidání další vrstvy, vrstvy bezpečnostní (obrázek 1).

obrázek 1 – rozšířený model OSI

Bezpečnostní vrstvu jsem umístil nad vrstvu transportní, protože transportní vrstva již pracuje s celými zprávami, na které je možné aplikovat šifrovací postupy. Samozřejmě lze zašifrovávat i jednotlivé pakety (tzn. bezpečnostní vrstvu nad vrstvou síťovou), ale z hlediska např. nutnosti mít možnost uložit zašifrovanou zprávu na pevný disk vidím umístění bezpečnostní vrstvy nad vrstvu transportní jako vhodnější.

Při příjmu zprávy transportní vrstva bezpečnostní vrstvě předává celou zašifrovanou zprávu. Bezpečnostní vrstva zajišťuje dešifrování zprávy, kontrolu jejího původce, případně řídí uzavření smlouvy na dálku a také, je-li to v požadavcích uživatele, kontroluje připojené certifikáty kvality. Naopak při odesílání zprávy bezpečnostní vrstva otevřený text (tj. text čitelný člověkem, nezašifrovaná zpráva) zašifruje, elektronicky podepíše a případně připojí certifikáty kvality. Jde tedy o širší pojetí bezpečnostní vrstvy, než jakou předkládají autoři v [MILV02-01] na str. 94, kde do bezpečnostní vrstvy vkládají pouze protokol SSL (Secure Socket Layer). Stručný popis všech původních vrstev lze nalézt např. v [VORJ97-01].

3. Nerozluštitelná šifra

Druhým tématem je dokonalost šifrování. Šifrování zajišťuje jeden z požadavků na bezpečnost komunikace, kterým je utajení zprávy.

K řešení absolutně nerozluštitelné šifry jsem dospěl při pohledu na monitor. Uvědomil jsem si triviální fakt. Displej monitoru má v podstatě možnost zobrazit cokoliv, co jsme schopni zrakově běžně vnímat. Stejně tak posloupnost n bajtů představuje 256ⁿ možných zpráv, pokud bereme 1B = 8b. Většina z těchto datových zpráv není skutečnými zprávami, neboť jsou pro člověka nesrozumitelné. Avšak daná posloupnost obsahuje úplně všechny možné zprávy, jejichž délka je menší nebo rovna n.

Princip nerozluštitelné šifry spočívá ve zcela primitivním použití funkce XOR (exklusivní OR) na přenášené bity přes bity šifrovacího klíče. Je nutné ovšem zvolit délku klíče rovnu či větší než je n. Z hlediska symetrie šifrování nejde ani o symetrické, ani o asymetrické šifrování. Používá se totiž jeden klíč (jako u symetrického šifrování) a jedna funkce (jako u asymetrického šifrování).

Položíme-li n=3, pak zpráva může představovat například „ANO“, „NE“, „NE!“, „ASI“, „???“, „:-)“ atd. Zašifrování zprávy „ANO“ pomocí (libovolně) zvoleného klíče 01110010 11010110 10101100 (označme klíč 1) ukazuje tabulka 1[5].

 

tabulka 1 – šifrování přes XOR

První řádek tabulky představuje zprávu „ANO“, druhý pak tuto zprávu převedenou na posloupnost bitů podle ASCII v osmi bitech. Třetí řádek obsahuje zvolený klíč, čtvrtý konečně výslednou zašifrovanou zprávu. Tato zpráva nám nic neříká, pokud neznáme klíč 1.

Jestliže se třetí osoba zmocní zprávy a začne ji hrubou silou dešifrovat, může při zkoušení všech 2²⁴ variací s opakováním narazit na variaci, která je v následující tabulce (tabulka 2) označena jako klíč 2:

 

tabulka 2 – šifrování přes XOR – hledání klíče hrubou silou

První řádek tabulky obsahuje předávanou zašifrovanou zprávu, kterou jsem přenesl z předchozí tabulky. Druhý řádek obsahuje klíč, který třetí osobě dává po aplikaci XOR funkce na šifrovanou zprávu posloupnost bitů uvedenou ve třetím řádku tabulky, což je srozumitelný text zobrazený ve čtvrtém řádku tabulky. Jak je vidět, jde o zcela opačný význam oproti původní zprávě.

Výhodou tohoto způsobu šifrování oproti symetrickému šifrování je, že obě strany komunikace nemusí používat ten samý klíč, dokonce se vůbec nemusí na žádném klíči dohodnout. Jestliže autor zprávy tuto zašifruje přes XOR funkci svým klíčem, může ji poslat příjemci, který nezná autorův klíč. Místo dešifrování zprávy ji příjemce znovu zašifruje, a to svým klíčem. Výsledek pošle zpět autorovi, který na zprávu aplikuje opět XOR funkci s původním klíčem. Tento výsledek zašle příjemci, který na zprávu aplikuje XOR funkci se svým klíčem a dostane tak původní zprávu od autora. Jestliže si obě strany zvolí stejný klíč, pak příjemce po první aplikaci XOR funkce se svým klíčem rovnou získá původní zprávu. Protože však není zaručené, že je to ta pravá zpráva, pošle ji podle protokolu zpět autorovi. To je jeden z nedostatků tohoto způsobu šifrování.

Dalším nedostatkem je samozřejmě nutnost opakovaného posílání zprávy. S tím souvisí i nebezpečí, že se za pravého příjemce vydává třetí osoba. Jako autor zprávy nemám možnost zkontrolovat, kdo zprávu skutečně přijal a poslal mi ji zpět zašifrovanou svým klíčem. Konečně, i když se obě strany dohodnou na společném tajném klíči, třetí osobě se může podařit jako první nalézt správný klíč.

Problematika různých délek jednotlivých zpráv není příliš bolestivá. Je možné vygenerovat velmi dlouhý klíč společný pro všechny zprávy. Každou zprávu je potom možné doplnit náhodnými znaky do požadované délky. Toto řešení ale zabírá kapacitu sítě. Jiný způsob spočívá v použití jen části klíče – podle délky zprávy. Nicméně, pro každou zprávu je možné vygenerovat samostatný klíč, což problém délky klíče zcela odstraňuje.

Praktické použití tohoto šifrování je možné. Nejbezpečnější variantou je osobně dohodnout společný klíč, který je delší než zpráva, zprávu pak doplnit náhodnými znaky, zašifrovat a poslat. Nebezpečí, že třetí osoba najde jako první klíč ten správný stále existuje, avšak doplnění zprávy o náhodné znaky má psychologický efekt, který třetí osobě znesnadňuje uvěřit, že ona zpráva je ta pravá. Logicky uvažující člověk se dokonce o násilné dešifrování ani nepokouší, protože ví, že jeho úsilí je zbytečné. Jednak z časového hlediska, jednak z hlediska věcného. Nepomůže ani automatizované hlídání sémantiky na úrovni slov podle slovníku, protože posouzení, zda celá zpráva má smysl, zůstává na člověku[6]. Náhoda sice v historii sehrála své, nicméně existují oblasti, kde je možné toto riziko postoupit. V současné době ovšem hraje pro své praktické použití i bezpečnost hlavní úlohu na scéně šifrování asymetrie.

4. Uzavření smlouvy na dálku

Třetím tématem článku je uzavírání smlouvy elektronickou cestou na dálku, a to se subjektem, se kterým jsme se dosud třeba ještě neviděli. K tomu je nutné znát princip elektronického podpisu. Věřím, že je tento již notoricky znám, přesto raději velice stručně princip připomenu.

Elektronický podpis zajišťuje další požadavky bezpečné komunikace – zajištění obsahu a identifikace původce (autora) zprávy. Elektronickým podpisem zde rozumím zaručený elektronický podpis podle zákona[7]. Ten zajistí, že příjemce elektronicky podepsané zprávy může identifikovat, od koho zpráva přišla, a zároveň zjistí, zda zpráva je v původním znění (zda nebyla cestou modifikována). Současně autor zprávy nemůže odmítnout své autorství. Elektronické podepsání dokumentu (datové zprávy) probíhá tak, že nejdříve je standardizovaným algoritmem vygenerován kontrolní součet zprávy, což je v podstatě další datová zpráva. Na tento kontrolní součet je pak aplikována šifrovací funkce se soukromým klíčem autora. Příjemce zprávy pak obdrží tuto zprávu spolu se zašifrovaným kontrolním součtem. Příjemce stejným algoritmem zjistí kontrolní součet zprávy a pomocí veřejného klíče autora dešifruje zaslaný zašifrovaný kontrolní součet. Jestliže oba údaje souhlasí, pak příjemce zprávy může předpokládat, že jejím autorem je ta osoba, která zná párový klíč k použitému veřejnému klíči (určení autora) a že nebyla cestou modifikována (zaručení zprávy). Autor zprávy zároveň nemůže říci, že zprávu neodeslal, neboť kontrolní součet mohl svým soukromým klíčem zašifrovat pouze on.

Elektronický podpis je jen krůček vzdálený od uzavření smlouvy na dálku[8]. Uzavření smlouvy na dálku je nutné odlišit od provedení transakce na dálku. Transakci – například zadání platebního příkazu bance – lze provést jednosměrnou komunikací od příkazce k bance. Standardizovaná zpráva s elektronickým podpisem bance říká, co má udělat, a zároveň zaručuje, že příkazce nebude moci později prohlásit, že příkaz bance nezadal[9]. Smlouva naopak je oboustranný (či i vícestranný) akt, který všechny smluvní strany k něčemu zavazuje a k něčemu opravňuje.

Budeme-li uvažovat dvoustrannou smlouvu, pak při jejím vzdáleném podpisu je potřeba zajistit, aby jedna smluvní strana nemohla požadovat plnění od druhé, pokud ta se k tomu nezavázala. Toto samozřejmě musí platit pro obě strany. Dále je nutné znemožnit ukončení plnění podle smlouvy jednou stranou bez toho, aby pro ni nevyplývaly žádné sankce.

V [KLIV95-01] autor uvádí protokol „Simultaneous Contract Signing“ (SCS, současné podepsání smlouvy). Tento protokol má zajistit, že obě smluvní strany budou mít totožný text smlouvy podepsaný druhou smluvní stranou. Myšlenka je to samozřejmě správná, nicméně protokol není, domnívám se, bezpečný. Podívejme se, jak protokol vypadá. Nejdříve je ale nutné seznámit se s jiným protokolem, kterého se při SCS používá. Tím je tzv. zapomnětlivý protokol.

Zapomnětlivý protokol

Protokol umožňuje, aby odesílatel poslal příjemci dvě šifrované zprávy, přičemž odesílatel požaduje, aby příjemce přijal pouze jednu z nich. Naopak příjemce chce, aby odesílatel nemohl zjistit, kterou zprávu přijal.

Odesílatel daných dvou zpráv vygeneruje dva své veřejné klíče (klíč 1 a klíč 2), které odešle příjemci zprávy. Pochopitelně si nechá jim odpovídající soukromé klíče. Příjemce náhodně vybere jeden z klíčů a zašifruje jím svůj náhodně zvolený klíč určený pro symetrický systém. Výsledek šifrování pošle odesílateli. Ten přijatou zprávu dešifruje jednou pomocí párového klíče ke klíči 1, jednou pomocí párového klíče ke klíči 2. Dešifrování provádí pro oba klíče (1 a 2), protože neví, který z klíčů si příjemce vybral. Odesílatel tak v jednom případě obdrží symetrický klíč zaslaný příjemcem, v druhém nějaká data. Přitom nedokáže rozhodnout, co je co, neboť oboje vypadá stejně náhodně. Má tedy dvě posloupnosti bitů (X, Y), z nichž jedna je symetrickým klíčem, který přišel od příjemce. Odesílatel zašifruje obě zamýšlené zprávy pro příjemce za použití X a Y (jednu zprávu pomocí X, druhou zprávu pomocí Y). A odešle je příjemci. Ten aplikuje zvolený symetrický klíč na obě došlé zprávy, ale pouze jedna zpráva pro něj bude čitelná, přičemž odesílatel neví, která to je.

Protokol pro současné podepsání smlouvy

Nyní je již možné vyložit protokol pro současné podepsání smlouvy. Označme strany smlouvy jako A a B. Pokud obě strany neformálně odsouhlasí obsah smlouvy, potřebují si dále vyměnit digitální podpisy této smlouvy (samozřejmě na dálku). Podle protokolu SCS nemůže strana A poslat straně B svůj podpis smlouvy a očekávat, že strana B jí pošle naopak svůj podpis smlouvy. Autor v [KLIV95-01] uvádí, že nelze ani posílat střídavě jeden bit podpisu stranou A a stranou B. Příjemce nemá totiž jistotu, že mu odesílatel posílá správné bity. Proto obě strany podle protokolu SCS vygenerují např. 100 elektronických podpisů smlouvy. Smlouva je považována za podepsanou, pokud strana předloží alespoň jeden její elektronický podpis protistrany. Posílání podpisů začne rozdělením všech podpisů na levou a pravou polovinu. Každý tento pár si vzájemně pošlou zapomnětlivým protokolem (polovina je označena jako levá, nebo pravá). Strana A tedy bude mít několik levých a několik pravých polovin elektronického podpisu smlouvy od strany B (nikdy celý podpis), přičemž strana B neví, které poloviny si strana A vybrala. Analogicky má strana B vybrané poloviny podpisů strany A. Dále může strana A poslat straně B popořádku všechny první bity levých poloviček a první bity pravých poloviček svých podpisů. Strana B si tak může kontrolovat, zda strana A neposílá špatné bity. Protože strana A neví, které poloviny strana B má, posílá správné bity všech levých i pravých polovin svých podpisů, neboť strana B si u každého páru zaslaného bitu a u každého podpisu zkontroluje, zda bit dané poloviny souhlasí. Druhý bit dosadí do druhé poloviny příslušného podpisu. Takto se strany střídají, dokud si nevymění všechny bity elektronických podpisů. Při posílání bitů je druhá strana pozadu jen o jeden bit, neboť k podepsání stačí pouze jeden podpis smlouvy.

Chyba v protokolu současného podepsání smlouvy

Vše vypadá přijatelně. Zádrhel je ovšem již v posílání levých a pravých polovin elektronických podpisů. Strana A může vygenerovat snad cokoliv kromě sta elektronických podpisů smlouvy. Protože strana B díky posílání zapomnětlivým protokolem získá vždy jen polovinu každého podpisu, nemůže posoudit, zda má polovinu elektronického podpisu, nebo prostě nesmyslná data. Další postup SCS je již správný. Nicméně neřeší výše uvedený problém.

Jak uzavřít smlouvu na dálku

Uvedl jsem, že obě smluvní strany vlastně vyžadují jen to, aby po nich druhá strana nepožadovala plnění smlouvy, pokud sama smlouvu neplní. Zároveň chtějí ošetřit, aby jedna strana nemohla přestat plnit smlouvu, aniž by pro ni z toho neplynuly sankce.

Pokud tuto problematiku nevyřeší legislativa, smlouva sama musí obsahovat dvě ustanovení věcně shodná s těmito:

1.         Každá smluvní strana je povinna druhé straně poskytnout svůj digitální podpis smlouvy, a to i opakovaně, pokud o to druhá strana požádá.

2.         Užije-li jedna strana smlouvu s digitálním podpisem druhé strany k vymáhání jejích závazků ze smlouvy plynoucích, automaticky souhlasí se svými závazky uvedenými v téže smlouvě.

Prostudujme možné situace.

Mějme opět smluvní strany A a B. Strana A pošle zcela běžnou elektronickou poštou digitální podpis smlouvy, na které se dohodla se stranou B. Strana B si ověří, že je to skutečně digitální podpis strany A dané smlouvy (viz výše digitální podpis). Jestliže strana B nepošle straně A digitální podpis, nebo jí pošle podpis něčeho jiného či špatný podpis, strana A nezačne plnit smlouvu. Strana B může po straně A plnění ze smlouvy, ale díky ustanovení 2 uvedenému výše se tímto automaticky sama zavazuje k plnění smlouvy, což kromě jiného znamená i povinnost poskytnout straně A podpis smlouvy, jak vyplývá z ustanovení 1. Strana B může tvrdit, že straně A podpis poslala. Protože ale je celý vztah na začátku, je bezdůvodné, aby strana A podepsala smlouvu a zároveň by předstírala, že od strany B nedostala podpis smlouvy. Nepředpokládám samozřejmě žádné sankce za neodeslání podpisu smlouvy. Celá dohoda musí být tedy uzavřena před započetím jakéhokoliv dalšího plnění smlouvy.

Jestliže strana A začne plnit smlouvu, i když od strany B neobdržela její podpis, riskuje, že po čase strana B vypoví smlouvu, přičemž jí z tohoto úkonu nevyplynou žádné sankce ve prospěch strany A, protože ta nemá v ruce dokument, který by ji opravňoval k vymáhání těchto sankcí.

Pokud dojde k bezchybné oboustranné výměně podpisů smlouvy, mohou obě strany začít plnit smlouvu. Kdyby například strana B přestala plnit smlouvu s tím, že od strany A nedostala podpis smlouvy (ať už je to pravda nebo ne), toto tvrzení by jí nebylo nic platné. Ve smlouvě, kterou má strana A s podpisem strany B se strana B zavazuje k plnění. Strana A má stále zájem smlouvu dodržet, takže také plní podle smlouvy. Navíc je strana A povinna straně B kdykoliv svůj podpis smlouvy poslat. Jestliže se domáhá strana A na základě smlouvy plnění od strany B, zároveň musí vyhovět i ustanovení 1, což jistě udělá.

Smlouva dále může být podepsána za účasti třetí strany – elektronického notáře, obecně certifikační autority (viz dále).

5. Důvěryhodnost a certifikační autority

Elektronický podpis jako aplikace asymetrické kryptografie je bezpečný, ale není obecně důvěryhodný, pokud začneme vzdáleně komunikovat s cizí osobou. Tato cizí osoba nám může poslat svůj veřejný klíč, který skutečně odpovídá jejímu soukromému klíči. Naše komunikace s ní bude bezpečná, ale nemůžeme si být jisti, kdo tato osoba ve skutečnosti je. Někdo, kdo by chtěl zneužít našeho vztahu s někým jiným, by se za tuto osobu mohl vydávat. U osob známých mohu jiným komunikačním kanálem ověřit, zda mi opravdu poslala svůj veřejný klíč. U osob neznámých nám tato možnost ovšem není nic platná. Obecně lze využít služeb třetího subjektu, kterým je tzv. certifikační autorita. V naší legislativě[10] již tato instituce spolu se zaručeným elektronickým podpisem existuje, dokonce už máme možnost v legislativním rámci služeb certifikačních autorit díky takovým existujícím subjektům využívat.

Je nutné mít možnost běžně vystopovat, kdo fyzicky (z důvodu možného trestního postihu) je druhým subjektem v komunikaci, pokud se tento jako někdo představí. Představí-li se pod pseudonymem a tento fakt nezatajuje, potom naopak musí být zaručeno, že není možné jeho identitu vystopovat. Je na zvážení každého, zda s osobou vystupující pod pseudonymem, například uzavře obchod. Jestliže se někdo představí pod pseudonymem, ale tento fakt neoznámí, pak musí být snadno zjistitelné, že jde o pseudonym, nebo dokonce pokus o podvod. Z důvodu celkové bezpečnosti však vystopovatelnost anonymních subjektů nesmí být znemožněna úplně. Je potřeba zaručit, že ten, kdo na síti nepáchá nic zlého, se na ní může cítit bezpečně, že nebude porušeno jeho soukromí a vice versa.

Certifikační autorita, certifikovaný elektronický podpis

Podle zmíněné české legislativy je certifikační autoritou (poskytovatelem certifikačních služeb) takový subjekt, „který vydává certifikáty a vede jejich evidenci, případně poskytuje další služby spojené s elektronickými podpisy“. Hlavním požadavkem, kterému certifikační autorita musí vyhovět, je důvěryhodnost. Důvěryhodnost subjekt mohl nabýt svou dosavadní úspěšnou existencí a korektním jednáním. Důvěryhodnost zvyšuje i sám uvedený zákon, jakož i možnost akreditace poskytovatelů certifikačních služeb podle tohoto zákona. Certifikační autorita (CA) je tedy takový subjekt, který si zvolíme jako ručitele naší identity v elektronickém světě. Je snadné nahlédnout, že jde o naprosto fundamentální službu, která musí být bez diskuse bezpečná v tom smyslu, že naším jménem bez našeho svolení nemůže jednat nikdo jiný a že právní úkony učiněné elektronickými prostředky nemohou být bez dohledatelného původce. Tyto dva požadavky na služby CA odpovídají požadavkům na bezpečnost komunikace identifikace původce zprávy. CA nám ručí nejen za bezpečnost naší identity, ale také za to, že jiná osoba, která se za někoho vydává, je skutečně tím, za koho se vydává.

Jak je v praxi tato záruka realizována? Jde o využití certifikovaného veřejného klíče (dle ZOEP certifikát, resp. kvalifikovaný certifikát). Certifikovaný veřejný klíč je utvořen tak, že ke svému veřejnému klíči subjekt připojí data popisující jeho totožnost v reálném světě. Vše samozřejmě podle používaných standardů. CA pak důvěryhodným[11] způsobem ověří tyto údaje se skutečností a celou datovou zprávu sestávající z veřejného klíče a identifikačních dat podepíše svým soukromým klíčem. Protože veřejný klíč CA je všeobecně znám[12], každý může tento veřejný klíč CA s vědomím, že jde skutečně o VK dané CA, použít k dešifrování certifikovaného veřejného klíče. Pokud mi tedy e‑mailem přijde nabídka na uzavření obchodu spolu s certifikovaným veřejným klíčem obchodního partnera, použiji k dešifrování tohoto certifikovaného veřejného klíče veřejný klíč uvedené certifikační autority. Jestliže jsou identifikační data čitelná, zjistím, že jde skutečně o certifikovaný veřejný klíč a zároveň zjistím samotnou identifikaci druhého subjektu, za kterou ručí daná CA.

Systém certifikačních autorit

Protože nelze přinejmenším z důvodu bezpečnosti a kapacity počítat pouze s jedním subjektem v roli certifikační autority, je nutné uvažovat systém certifikačních autorit. Ten musí umožnit komukoliv zjistit pravdivost údajů poskytnutých další osobou a zároveň poskytnout komukoliv pozadí, které mu usnadní důvěryhodně působit v prostředí Internetu.

Pro tyto účely je vhodné vybudovat takový systém, který bude funkční i při výpadku několika center. Jistě je zde triviální nalézt paralelu se základní myšlenkou Internetu jako sítí schopné spojovat vzdálená místa i při totální destrukci některých komunikačních uzlů. Problém však nespočívá pouze v komunikaci, ale v pravdivosti komunikovaných údajů. Systém CA lze realizovat podle přinejmenším tří konceptů.

Hierarchie certifikačních autorit

Koncept hierarchie certifikačních autorit spočívá ve vytvoření takového systému CA, ve kterém jsou certifikační autority sdružovány podle předmětu, kterého se jejich zajištění důvěryhodnosti týká. Nad nimi je v hierarchii umístěna další certifikační autorita, která slouží jako CA pro CA na nižší úrovni. Postupně bychom se takto dostali až k nejvyšší (kořenové) certifikační autoritě. Hierarchii CA prezentuje obrázek 2. Vyhledávání konkrétních CA se podobá vyhledávání IP adres v DNS[13] (viz např. [BREP94-01]).

Uvedený příklad hierarchie vychází spíše z postupu analýzy top-down. Při postupu bottom‑up by zřejmě vůbec nedošlo ke vzniku státních CA jako centrálních CA pro dané území: Jestliže by například banka (jako certifikační autorita) potřebovala ověřit důvěryhodnost jiné banky, kterou dosud nezná, obrátila by se na svou centrální banku, která by se dále obrátila na celosvětovou centrální autoritu určenou pro bankovní subjekty. Tato úroveň už odpovídá státním centrálním CA. Banky však nepotřebují ověřovat důvěryhodnost pouze jiných bank, ale i fyzických a právnických osob nebankovních. Kdybychom uvažovali striktní hierarchii, kdy se subjekt může odkázat pouze na přímo „nadřízený“ (resp. „podřízený“) subjekt, potom by banka dala dotaz na centrální banku, která by musela dát dotaz na státní centrální autoritu (v případě přístupu top-down), a ta by dále dala dotaz např. na obchodní rejstřík či katastrální úřad. Odtud by odešly požadované certifikované údaje opačnou cestou, kterou šel dotaz. Při volnější formě hierarchie banka může vznést dotaz přímo např. na centrální katastrální úřad. Pokud by volnost hierarchie byla značná, celý systém CA by spíše připomínal již další koncept (viz níže).

obrázek 2 – ilustrace hierarchie certifikačních autorit

Výhodou hierarchického uspořádání je přehlednost. Na vyšších úrovních působí především státní instituce, což přináší navíc záruku „státního razítka“. Nicméně, jde o státní sektor. K institucím certifikačních autorit je bezpodmínečně nutné přistupovat s absolutní obezřetností (vlastně nejen ve státním sektoru). Je otázkou, zda stát dokáže ochránit citlivá data a zabránit jejich zneužití lépe, než to dokáže sektor soukromý. Ale to není téma pro tento článek. Nevýhodou hierarchického uspořádání je nepružnost, složitost komunikace a slabá místa v uzlech. Při nefunkčnosti jednoho uzlu při striktním hierarchickém uspořádání je nemožné dostat se do jiné větve hierarchie. Nefunkčnost CA na hierarchicky nízké úrovni ohrožuje především jí podřízené subjekty, zatímco nefunkčnost CA na vyšší úrovni znemožňuje ověřit důvěryhodnost mezi jednotlivými oblastmi. Fungování systému jako celku závisí na jednotlivých uzlech (podobně jako nosnost řetězu na nejslabším článku). Oslabení principu hierarchie napomáhá snížit závislost na nadřízeném uzlu a tedy zvyšuje spolehlivost celého systému.

Bilaterální vztahy certifikačních autorit

Tato koncepce je podle mého názoru docela triviální. Certifikační autorita jako suverénní subjekt, podléhající však ve svém působení zákonu upravujícímu její postavení, povinnosti a odpovědnost (stejně jako v předchozím případě), poskytuje záruky za pravdivost údajů. Původce údaje, který je někde zveřejněn, spolu s údajem zveřejní i jednoznačnou identifikaci certifikační autority, která ručí za pravdivost tohoto údaje. Jestliže si budu chtít ověřit pravdivost daného údaje a nedůvěřuji přímo uvedené certifikační autoritě, požádám CA, které důvěřuji (např. si u ní nechávám certifikovat svůj elektronický podpis), aby mi zjistila, zda CA uvedená u ověřované zprávy je skutečně důvěryhodná. Když má CA nenajde identifikátor prověřované CA ve své databázi, zašle požadavek na zjištění důvěryhodnosti všem CA, které zná a považuje za důvěryhodné. Požadavek se tímto v celém systému CA distribuuje, dokud někde není daná identifikace nalezena a odeslána zpět. Čím delší je cesta vyhledávání, tím slabší je ovšem pomyslná míra důvěryhodnosti.

V systému bilaterálních vztahů neexistuje slabé místo v cestě. Cesta ke hledané CA většinou není jediná. Stejně jako v Internetu je možné dospět k cíli, i když je síť částečně poškozená. Nevýhodou může být menší zdání záruky (není zde nutně „státní razítko“) oproti hierarchickému konceptu, které je způsobeno právě nastíněným P2P (peer to peer) konceptem. Jak jsem již zmínil, delší cesta vyhledávání indikuje větší riziko nespolehlivosti hledaného subjektu.

Askemos

Systém Askemos (www.askemos.org, [WITJ02-01]) je autonomní, distribuovaný operační systém nad P2P sítěmi. Definuje virtuální stroj na úrovni dokumentů (dat v různých formátech). To znamená, že neexistuje jediný stroj, který by celý systém řídil. Neexistuje ani žádný superuživatel ani jedinečné adresy. Atakování jedné součásti nemá vliv na funkci celého systému ani na pravdivost poskytovaných informací.

Askemos vychází z myšlenky unikátnosti informace (rovnice 1).

rovnice 1:                       

Informací zde autor rozumí to, co lidé dokáží z dat vnímat. Jako příklad uvádí obrázek, který v elektronické podobě může být uložen na několika místech v různých formátech. Ve skutečnosti jde však stále o jednu a tu samou informaci. Informace je v systému Askemos záměrně distribuována na více míst (fyzické servery). V systému Askemos je pro získání informací využíván tzv. Byzantine Agreement Protocol (BAP). Při vznesení dotazu Askemos zajistí vyhledání všech míst, kde je informace uložena. Aplikací BAP pak může vrátit informaci v podobě, ve které ji do Askemosu uložil oprávněný uživatel. Distribuce informace na více míst a BAP zajistí to, že je informace dostupná a správná, i když je několik fyzických úložišť vyřazeno z provozu, nebo je někde informace neoprávněně změněna[14].

Je tudíž nutné si uvědomit, že systém Askemos nemůže zajistit objektivní pravdivost uložených informací. Tak, jak je dosud vystavěn, zaručuje pouze to, že oprávnění uživatelé z něho mají zaručený přístup k informaci v takovém „znění“, ve kterém ji uložil její původce. Pokud chceme zveřejnit svůj veřejný klíč, můžeme to učinit pomocí systému Askemos. Ten nám zajistí, že bude každému zpřístupněn a nikým nezměněn. To je jistě pozitivní. Nicméně, při pohledu z druhé strany problém důvěryhodnosti není vyřešen. Fakt, že je veřejný klíč uložen v systému Askemos, ještě nezaručuje, že ho tam nemohl uložit někdo, kdo se vydává za někoho jiného.

Po diskusi s autorem systému Askemos (J.F. Wittenberger) jsme dospěli k názoru, že uložení nepravdivého údaje do systému Askemos nedegraduje tento systém pod realitu. V reálném životě také nekontrolujeme, zda to, co někdo řekne, je zaručeno nějakou třetí, důvěryhodnou osobou, ale zkoušíme o subjektu nalézt různé údaje, na základě kterých usoudíme, zda je důvěryhodný. Uživatelé Askemosu jsou autentizováni podobně jako uživatelé jiné sítě. Majitelé serverů, které tvoří Askemos, odpovídají za to, že za uživatelským jménem je určitá osoba. Tímto vlastně jsou certifikačními autoritami (ručí za identitu v Askemosu). Protože v Askemosu je každý údaj označen i jeho původcem, původci údajů jsou tak dohledatelní. Ručí tedy sami za pravdivost údaje. Pokud se nepravdivým údajem nikdo nezabývá, nic se nestane. Jestliže údaj někomu způsobí škodu, pak tento se může domáhat nápravy jako v reálném životě.

Takové prostředí však přináší jen malou přidanou hodnotu např. pro vznik obchodních vztahů mezi dosud neznámými subjekty. Proto osobně dávám přednost existenci certifikačních autorit, které pomohu znatelně zvýšit důvěryhodnost v síti. Jak lze certifikační autority zapojit do systému Askemos?

K řešení tohoto problému navrhuji dva způsoby. První z nich je svázaný se systémem Askemos. Jak jsem zmínil, přístup lidí k Askemosu řídí vlastníci fyzických serverů. Proto mohou svým postavením i majetkem (upraví-li to zákon, resp. stačí snad i jen smluvní ujednání) ručit za solidnost uživatelů a jimi zveřejňovaných informací. Jak ale ukazuje současná situace Internetu, v jehož prostředí Askemos funguje a ve kterém majitelům serverů systému Askemos odpovídají ISP, tito běžně nijak nezasahují do obsahu, který na jejich serverech zveřejňují uživatelé. Diskuse nad jejich povinností zabránit šíření např. materiálů s nacistickým obsahem se objevily, ale odpovědným vždy zůstane autor. Tím neříkám, že by majitelé serverů v Askemosu nemohly poskytovat služby certifikačních autorit ručících za kvalitu údajů. Automaticky to od nich očekávat však nelze. Pokud by majitelé serverů systému Askemos byli automaticky i certifikačními autoritami, pak by každý uživatel měl jistotu, že údaje, které z Askemosu získává, jsou i objektivně[15] pravdivé.

Druhý způsob spočívá v poskytování záruky za pravdivost informace nezávislými subjekty (certifikačními autoritami). Jakmile si původce informace nechá informaci ověřit, může ji spolu s certifikátem vpustit do systému Askemos. Jednak má jistotu, že jeho informace bude vždy dostupná, jednak že nebude modifikovaná. Ostatní uživatelé pak mají jistotu, že nalezená informace je pravdivá, tehdy když důvěřují uvedené certifikační autoritě. Pokud ne, pak opět musí postupovat, jak jsem uvedl výše. Evidentně tento přístup neřeší zajištění důvěryhodnosti novou, dosud neprobranou cestou.

Pokud by se podařilo do systému Askemos uložit cesty vyhledávání mezi certifikačními autoritami, potom by oddělení subjektů certifikačních autorit od systému Askemos bylo přemostěno. Uvažujeme‑li hierarchický systém certifikačních autorit, potom by kořenové certifikační autority do sytému Askemos distribuovaly certifikáty svých přímých „podřízených“ certifikačních autorit. Tyto certifikační autority by dále distribuovaly certifikáty jim „podřízených“ CA atd. Uživatel, který by chtěl ověřit důvěryhodnost nějakého zveřejněného údaje, jenž je certifikován jako pravdivý certifikační autoritou, o níž daný uživatel mnoho neví, by musel v rámci zveřejněné hierarchie certifikátů dopátrat, zda je uvedená certifikační autorita certifikovaná některou z jemu vyhovujících CA. Protože je hierarchie certifikátů podepsána vždy kořenovou CA (které uživatel věří) a protože je celá uložena v systému Askemos, má uživatel jistotu, že se pohybuje v důvěryhodném prostředí. Distribuce v systému Askemos odstraňuje závislost na jednom uzlu a zvyšuje bezpečnost zveřejněných informací. Prohledávání hierarchie certifikátů pochopitelně nebude provádět sám uživatel, ale programové vybavení založené na standardizovaných protokolech, které bych zařadil do bezpečnostní vrstvy rozšířeného OSI modelu (obrázek 1). Analogicky lze uvažovat distribuci certifikátů v pojetí bilaterálních vztahů CA.

Systém Askemos tedy dává možnost propojit kladné prvky systému bilaterálních vztahů CA a hierarchie CA („státní razítko“ a přehlednost spolu s dostupností).

Alternativa k Byzantine Agreement Protocol

Byzantine Agreement Protocol značně zatěžuje síť. Problém může být také s rychlostí. Oba problémy jsou sice otázkou úrovně použité technologie a časem mohou díky pokroku vymizet, nicméně věci by měly být řešeny nejjednodušší cestou. Zde uvádím alternativu k BAP.

Jde o využití principu RAID – Redundant Array of Independent Discs – a distribuovaných databází. Podle této myšlenky by každý údaj byl rozdělen na několik částí, které by byly distribuovány (v intencích distribuovaných databází) po síti. Rozdělení částí musí být provedeno tak, aby při výpadku jednoho až několika serverů bylo možné ze zbývajících utvořit zpětně celý údaj. Každá takto distribuovaná část údaje dále musí být digitálně podepsána jeho tvůrcem. Digitální podpis nám umožní detekovat, jestli s danou částí údaje nebylo neoprávněně manipulováno. Nejjednodušší případ (který ovšem nelze považovat za zcela bezpečný) ukazuje obrázek 3

obrázek 3 – nejjednodušší případ distribuce údaje po síti

Při vyhledávání údaje systém Askemos zajistí přístup k serverům, na které byl údaj distribuován. Protože některé mohou být mimo provoz nebo věcně nespolehlivé, je nutné přikročit ke skládání údaje. Jestliže například není v provozu server A, údaj je nutné složit z částí uložených na serverech B a C. Jestliže server A sice je v provozu, ale na něm uložená část údaje má nevyhovující digitální podpis (ať už neodpovídá VK jeho původce, nebo data byla modifikována), je opět potřeba údaj složit z částí na serverech B a C. Rozdělení údaje na tři části však není dostatečně bezpečné. Představme si ne zcela nemožnou situaci, kdy server A je mimo provoz a server B není důvěryhodný (o čemž se předem neví, resp. původně byl důvěryhodný, ale později byl napaden). Potom bychom nemohli složit původní údaj. Rozdělení údaje proto musí vycházet z reálné úrovně sítě a stanovení pravděpodobností výpadků a věcné nespolehlivosti jejich uzlů. Svou úlohu samozřejmě sehraje i důležitost údaje, charakterizovaná požadavkem minimální doby přístupnosti za určité období.

6. Zaručení kvality

V předchozích pasážích jsem se dotkl problematiky pravdivosti údajů přístupných přes veřejnou síť. Konkrétně jsem diskutoval zaručení se certifikační autority za identitu subjektů využívajících síť. Přiblížil jsem se také pravdivosti údajů v síti obecně. Jak tedy možná již vyplynulo z předchozího textu, certifikační autority nemusí ručit za pravdivost pouze veřejného klíče a jeho vlastnictví konkrétním subjektem, čili za identifikaci ve virtuálním světě. Certifikační autority mohou ručit i za pravdivost různých prohlášení. Například firmy o sobě prohlašují, že svým zákazníkům vyjdou ve všem vstříc, že mají kvalitní systém pro péči o zákazníka apod. Jejich potenciální zákazníci jim to samozřejmě nemusí věřit. Chtěli by mít jistotu, že je daná firma nezahrnuje prázdnými slovy. Firma tedy požádá vybranou certifikační autoritu, která ve firmě provede (nebo nechá provést) audit dané oblasti. Pokud vše dopadne, jak firma deklaruje, certifikační autorita elektronicky podepíše prohlášení dané firmy a případně připojí své hodnocení (certifikát, rating). Firma pak může toto prohlášení i s elektronickým podpisem CA zveřejnit na svých webových stránkách[16]. Uživatel si může ověřit, že daný text byl skutečně podepsán uvedenou certifikační autoritou.

Tímto způsobem specializované certifikační autority mohou ručit za kvalitu. Je tak zajištěn další požadavek bezpečnosti komunikace v GISp – kvalita. Této certifikace budou využívat především malé, dosud nepříliš známé firmy, neboť jim zajistí větší kredit.

CA tedy mohou ručit za to, že určití výrobci dodávají kvalitní zboží, že plní své závazky vyplývající z poskytované záruky. Mohou ručit za to, že dopravci podle zveřejněných podmínek přepraví zboží. Školy budou ručit za to, že jejich absolventi u nich skutečně studovali a s jakým výsledkem. Ministerstvo školství bude ručit, že daná škola splňuje určité požadavky. Banky zaručí, že klient skutečně disponuje určitým jměním. Centrální banka zaručí, že banka je stále oprávněna poskytovat služby.

Samozřejmě tato osvědčení nebudou poskytována třetí osobě, ale jen tomu subjektu, kterého se týkají. Tento subjekt osvědčení (certifikované prohlášení) zašifruje veřejným klíčem partnera v komunikaci (kterému chce doložit své kvality). Ten si zprávu dešifruje svým soukromým klíčem a přiložený certifikát (digitální podpis) dešifruje veřejným klíčem CA, jejíž identifikace je rovněž přiložena. Partner nemusí mít důvěru přímo v uvedenou CA, neboť může být doslova z druhého konce světa. Přes fungující systém certifikačních autorit (viz výše) se může dopátrat, jestli lze uvedené CA důvěřovat.

7. Zneužití pravomoci

Certifikační autority musí splňovat určitá kriteria stanovená zákonem, přičemž za pochybení ji hrozí majetkový postih (lépe i postih odnětí svobody osob, které se pochybení či zneužití postavení dopustily). Lze si spočítat, že v některých případech může být pokuta či hrozba trestu vzhledem k prospěchu ze zneužití postavení CA malá. Certifikační autorita má prostředky na to, aby vytvořila virtuální identitu skutečných osob, aniž by tyto o tom věděly. Jménem těchto osob pak může vystupovat a provádět obchodní transakce, převody nemovitostí apod. V některých případech, jako právě u převodu nemovitostí, by takovému počínání zabránila nutnost existence speciálního páru klíčů, který by se používal pouze pro vymezené účely a za jehož pravost by ručila instituce, která dohlíží na danou oblast zájmu, v našem případě katastrální úřad. V jiných případech však lze podvodné jednání vystopovat až zpětně. Pokud se skutečná osoba, jejíž identity bylo nějakou certifikační autoritou zneužito, dozví, že jejím jménem byla uskutečněna určitá transakce, lze velmi snadno dohledat, která certifikační autorita certifikovala smyšlenou virtuální identitu dané osoby. Je to právě ta podvodná CA. Pokud nemůže dokázat, že skutečná osoba si u ní nechala daný veřejný klíč certifikovat, je jasné, že CA zneužila svého postavení. Legislativou musí být zabráněno zrušit CA bez dostatečné „výpovědní“ lhůty jejím klientům. Ta umožní jednak dohledat případná podvodná jednání, jednak je nutná pro přechod klientů k jiné CA[17].

Dostávám se již do oblasti právní úpravy, kterou ovšem rád přenechám příslušným specialistům.

8. Vypršení doby platnosti klíčů

V této části článku se zabývám problematikou platnosti právních úkonů v souvislosti s vypršením doby platnosti šifrovacích klíčů. Doba platnosti je požadována z důvodu vyloučení napadení zašifrované či podepsané zprávy třetí osobou (útočníkem) hrubou silou.

Jaká jsou možná rizika? Uvažujme smlouvu mezi smluvními stranami A a B. Smlouva je podepsána certifikovanými elektronickými podpisy (certifikační autority svou certifikací ručí za příslušnost daného veřejného klíče k určitému fyzickému subjektu). Předpokládejme, že strana B není schopna nalézt hrubou silou soukromý klíč strany A, dokud je její pár klíčů platný. Po skončení platnosti páru klíčů strany A tedy může dojít k tomu, že se straně B podaří minulý soukromý klíč strany A nalézt.

Co s původní smlouvou, jejíž plnění pokračuje i po skončení doby platnosti veřejného klíče strany A (pro jednoduchost nechť klíč strany B platí dále)? Strana A má stále smlouvu podepsanou stranou B. Může tedy od ní požadovat plnění a strana B jej nemůže bez sankcí odmítnout. Strana B má smlouvu podepsanou stranou A, ale doba platnosti jejího podpisu již vypršela. Může strana A odmítnout plnění s odvoláním na to, že její podpis je již neplatný? Co znamená, že doba platnosti podpisu již vypršela? Smlouva byla podepsána soukromými klíči, jejichž párové veřejné klíče byly certifikovány. Jestliže tedy strana B má smlouvu podepsanou stranou A, přičemž její veřejný klíč byl certifikován, strana B díky této certifikaci má v rukou dostatečný důkaz k tomu, že to byla strana A, kdo se k plnění smlouvy zavázal. Smlouvy skutečně uzavřené v minulosti tedy nejsou dotčeny vypršením doby platnosti klíčů.

Rizika vyplývají z možného podvodného jednání strany B, které se podařilo nalézt soukromý klíč strany A. Strana B nyní může vytvořit zcela novou smlouvu, která je pro stranu A nevýhodná. Vytvoření smlouvy s datem po skončení platnosti klíče strany A je bezpředmětné – taková smlouva je zjevně neplatná. Strana B může modifikovat stávající smlouvu, nebo jednoduše vytvořit novou smlouvu, ale s datem, dřívějším. Strana A pak nemůže nijak dokázat, že smlouvu sama nepodepsala. Proto je nutné do procesu uzavření smlouvy zapojit třetí subjekt.

Třetí subjekt (obecně uvažujme opět certifikační autoritu) může hrát roli uschovatele platného znění smlouvy, případně poskytovatele certifikátu smlouvě. V prvním případě certifikační autorita fyzicky „vlastní“ smlouvu podepsanou oběma subjekty (pokud každý subjekt nemá svou CA). Strana B sama smlouvu nemůže změnit. Ve druhém případě CA smlouvu elektronicky podepíše. CA může smlouvu podepsat před podpisem smluvních stran, nebo po podpisu. Ať už je smlouva certifikovaná před podpisem smluvních stran či po, strana B nemůže změnit smlouvu tak, aby byla v konečném chápání pojata jako certifikovaná. (Strana B stávající smlouvu nemůže změnit, pokud nezná soukromý klíč certifikační autority.)

Co se ale stane, když strana B vytvoří zcela novou smlouvu (s datem z doby platnosti klíče strany A), která zavazuje stranu A? Text smlouvy musí nechat uložen u CA, nebo ho nechat jí podepsat. Při uložení smlouvy u CA tato kontroluje platnost obou podpisů (veřejných klíčů, kterými se podpisy ověří). Jestliže je podpis strany A již neplatný, pak CA odmítne smlouvu uložit. Při druhém přístupu – poskytnutí certifikátu smlouvě (tedy podepsání smlouvy z titulu CA) – nemá CA žádnou kontrolu, pokud je smlouva nejdříve certifikovaná, a teprve pak podepsaná smluvními stranami. V druhém případě postupuje podobně jako při úschově smlouvy. Certifikační autorita také může kontrolovat datum uzavření smlouvy, resp. začátek její platnosti. V nejjednodušším případě musí CA odmítnout ručit za znění smlouvy tehdy, když je předkládána po vypršení doby platnosti některého jejího podpisu. Ve skutečnosti ale obě strany mohou zcela dobrovolně chtít uzavřít smlouvu zpětně (abstrahujme od toho, zda je to legislativa dovoluje). V tomto případě by samozřejmě strana A ke smlouvě použila dnes již neplatný podpis. Aby byla průkazná spoluúčast strany A, certifikační autorita musí autentizovat obě strany podle dnes platných a certifikovaných podpisů. Smlouva sama pak může být (zpětně) podepsána již neplatným podpisem. Požadavek záruky certifikační autority za znění smlouvy by měl být ze zákona.

Vyvstává otázka, jak lze řešit vypršelou dobu platnosti veřejného klíče certifikační autority. Pokud by CA uschovávala platné znění smlouvy, problém mizí. Pokud by pouze poskytovala certifikát platnému znění smlouvy, pak by některá ze stran mohla vytvořit novou certifikovanou smlouvu datovanou do minulosti. K tomu by ale potřebovala znát jak soukromý klíč druhé strany, tak certifikační autority. O úspěchu takové činnosti lze při používání současných délek klíčů podle odborníků s úspěchem pochybovat. Ovšem jak dlouho? Je tato doba dostatečná pro všechny smlouvy?

Každopádně lze do smlouvy zařadit pojistku. Tato pojistka by ve smlouvě musela existovat ze zákona. Je představována usnesením obou stran na tom, že jedním z důvodů ukončení platnosti smlouvy je existence takové technologie, která umožňuje nalezení soukromého klíče druhé strany i před běžným skončením platnosti smlouvy. Smlouvy bez tohoto usnesení by nesměly být ze zákona platné (jinak by si kdokoliv mohl smlouvu bez této pojistky vytvořit a podepsat nalezeným soukromým klíčem někoho jiného). Pokud se jedné smluvní straně podaří nalézt soukromý klíč strany druhé, je to důkaz, že taková technologie existuje a tedy že smlouva přestává platit. Pak je nutné podepsat smlouvu s delším klíčem. Riziko je pochopitelně v možném utajení takové technologie. O velikosti tohoto rizika mohu pouze spekulovat – nedomnívám se, že by bylo velké[18].

Askemos jako prostředí pro uzavírání smluv

Problematiku vypršení doby platnosti klíčů lze řešit i využitím systému Askemos. Smlouva jako dokument by byla vytvořena právě v systému Askemos. Uživatelská práva systému zaručí, že k tomuto dokumentu mohou přistupovat pouze smluvní strany (případně pak i soud apod.). V systému Askemos by došlo i k podepsání smlouvy oběma stranami. Také v tomto případě text smlouvy musí obsahovat prohlášení uvedená výše. Přístupové jméno a heslo k dokumentu smlouvy v systému Askemos se může měnit, podpis smlouvy může zůstat stále stejný. Systém Askemos zajistí, že smlouvu nikdo nebude moci změnit. I přesto však je nutné, aby platnost klíčů používaných pro podepisování smluv časem vypršela. Strana B by totiž mohla zjistit soukromý klíč strany A a vytvořit zcela novou, pro stranu A nevýhodnou smlouvu, kterou by podepsala jejím soukromým klíčem. Systém Askemos však nedovolí samotnému subjektu B založit smlouvu, která je podepsána jednak neplatným klíčem jiného subjektu, jednak bez znalosti stávajícího platného klíče strany A. Pokud by obě strany chtěly uzavřít smlouvu s datem platnosti v minulosti, systém Askemos to umožní. Strana A může použít pro podpis smlouvy již neplatný podpis, protože se vůči Askemosu autentizuje novým, platným podpisem.

9. Závěr

V článku o bezpečné komunikaci a důvěryhodnosti GISp jsem ukázal, jakými způsoby lze řešit otázky spojené se vzdálenou komunikací neznámých subjektů. V současné době tedy lze zajistit, aby spolu mohli komunikovat lidé, kteří se dosud vůbec neznali a kteří bydlí každý na jiné polokouli, a přitom měli jistotu, že si mohou vyměňovat důvěrná data, aniž by je někdo odposlouchával. Dále mohou mít jistotu, že právní úkony provedené druhou stranou jsou pro ni závazné a že se na informace poskytnuté druhou stranou mohou spolehnout.

Samozřejmě bude trvat několik let, než bude takto možné celosvětově komunikovat. Dosud probíhaly či probíhají jednání a projekty týkající se certifikačních autorit a jejich služeb (Trusted Thrid Parties Services). Jde o otázky odpovědnosti CA při škodách z poskytovaných služeb[19], mezinárodní harmonizace CA, která je bezesporu nutná, a dále o jiné otázky z oblasti práva a soudnictví. Je vyvinuto několik standardů certifikačních metod, a to jak ze strany státních institucí, tak ze strany soukromého sektoru. Všechny tyto oblasti jsou projednávány a některé z výsledků jsou zveřejněny (viz seznam literatury).

Summary

This article is an aggregation of several topics concerning safe and trusty communication in the global information society. First, an improvement of ISO/OSI (Open Systems Interconnection – Basic Reference Model, ISO/TC97/SC16) was presented. The improvement lies in adding a new layer – safety layer. Next topic describes an easy implementation of XOR logic function for getting an unbreakable encryption. Following topics are about relations between subjects. The article solves remote contract signing, discusses possible ways of assuring trust and quality via several systems of certification authorities. Finally, a solution of the problem that arises from cryptographic keys’ limited validity is proposed.

 

Seznam zdrojů:

 

[BREP94-01]	Břehovský, P.: „Praktický úvod TCP/IP“, Nakladatelství Kopp, České Budějovice, 1994, ISBN 80-85828-18-9
[CHIP95-02]	Seriál „Utajené komunikace“ v časopisu CHIP 2/95 – 12/95, Vogel Publishing, s.r.o., Praha, 1995, ISSN 1210-0684
[JANJ95-01]	Jandoš, J.: „Komunikační systémy a služby“, VŠE, Praha, 1995, ISBN 80-7079-282-5
[KLIV95-01]	Klíma, V.: „Moderní aplikace šifer“, čas. CHIP, srpen 1995, Vogel Publishing, s.r.o., Praha, 1995, ISSN 1210-0684
[MILV02-01]	Milutinovic, V., Patricelli, F. (editors): „E-Business and E-Challenges“, IOS Press, Amsterdam, 2002, ISBN 1-58603-2763
[SBZA00-01]	Zákon o elektronickém podpisu, Sbírka zákonů č. 227/2000, ČR
[SLAO01-01]	Šlapák, O.: „Model globální informační společnosti“, Systémová integrace 1/2001, ČSSI, Praha, 2001, ISSN 1210‑9479
[SLAO99-01]	Šlapák, O., Voříšek, J.: „Integrace v globální informační společnosti“, příspěvek do sborníku konference Systémová integrace 1999, Praha, 1999, ISBN 80-7079-059-8
[VORJ97-01]	Voříšek, J: „Strategické řízení informačních systémů a systémová integrace, Management Press, Praha, 1997, ISBN 80-85943-40-9
[WITJ02-01]	Wittenberger, J.: „Askemos – a distributed settlement“, SSGRR2002s international conference proceedings, Telecom Italia Learning Services, 2002, ISBN 88-85280-63-3