Digitální podpis ve webovém prohlížeči BAKALÁŘSKÁ PRÁCE
Jiří Harazim
Brno, jaro 2010
Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj v kapitole Literatura. V Brně dne:
Vedoucí práce: RNDr. Martin Kuba
2
Poděkování Děkuji RNDr. Martinu Kubovi, vedoucímu této práce, za možnost pracovat na tak zajímavém tématu, jeho cenné rady, zkušenosti a mnohé konzultace. Za kritiku a odborné rady v technologiích firmy Microsoft děkuji panu Michalu Valáškovi. Dále děkuji mým rodičům za přečtení a konstruktivní kritiku.
Acknowledgment is due to the following people for information they provided me with. I would like to thank Mr. Anders Rundgren for providing information about WASP and websigning. Acknowledgment to Mr. Matteo Slaviero for the advice he provided me with about current solutions. Last but not least, thanks to Mr. Priit Vinkel and Mr. Kasper Teglgaard for information about internet elections and OpenOCES respectively.
3
Shrnutí Účelem této práce bylo prozkoumání aktuálního stavu a možností webového podepisování (web-signing). Vytváření digitálního podpisu ve webových prohlížečích je dnes vlivem absence standardu nejednotné a mnohdy neproveditelné bez instalace dodatečného doplňku prohlížeče či aplikace. Uživatelům je nabízen komfort práce s osobním certifikátem X.509 v elektronické poště formou standardu S/MIME, a tak se nabízí otázka, jak by šlo stejně jednoduše vytvořit digitální podpis ve webovém prohlížeči. V práci jsou na jedné straně diskutovány příčiny a omezení na straně webového prohlížeče a na druhé straně možnosti řešící tuto situaci podle jejich zastoupení u uživatelů s ohledem na různé druhy používaných prohlížečů. Konkrétně se předkládaná práce zabývá těmito technologiemi: JavaScript, ActiveX, Flash/AIR, Silverlight, Java Applets a distribučními technologiemi Java Web Start a .NET ClickOnce. Z řady prohlížečů byli vybráni Internet Explorer, Mozilla Firefox, Google Chrome a Opera, což pokrývá přibližně 95% uživatelů. Z citovaných informačních zdrojů a na základě vlastního ověření shrnujeme, že současné řešení vytváření digitálního podpisu ve webovém prohlížeči spočívá ve využívání dostupných technologií (ActiveX, JavaScript), které jsou však omezené na jednotlivé prohlížeče, případně platformy. Výjimkou je řešení postavené na platformě Java, které se zdá navzdory své malé rozšířenosti nejlepším řešením pro dnešní stav. Závěrem uvádíme, že práce zohledňuje nejenom obecnou problematiku v oblasti digitálního podpisu, ale snaží se rovněž nabídnout východisko z dnešní neuspokojivé situace, a to nově představeným protokolem pro webové podepisování, nazvaným WASP.
4
Klíčová slova Webové podepisování, Web-signing, Digitální podpis, Webový prohlížeč, X.509, Certifikát, CAPICOM, crypto.signText(), Java Applets, internetbanking, WASP
5
Obsah Prohlášení..............................................................................................................................2 Poděkování............................................................................................................................3 Shrnutí...................................................................................................................................4 Klíčová slova.........................................................................................................................5 Obsah ....................................................................................................................................6 1 Úvod a představení základních pojmů.............................................................................8 1.1 Úvodní slovo................................................................................................................8 1.2 Rozvoj internetu...........................................................................................................8 1.3 Web..............................................................................................................................9 1.4 Webový prohlížeč.........................................................................................................9 1.5 Zásuvný modul, plugin a rozšíření................................................................................9 1.6 Digitální podpis............................................................................................................9 1.7 X.509..........................................................................................................................11 1.8 Otisk (hash)................................................................................................................13 1.9 PKI.............................................................................................................................14 1.10 Nástroje webového prohlížeče..................................................................................15 1.11 Vybrané webové prohlížeče......................................................................................17 2 Webové prohlížeče a dostupné technologie....................................................................18 2.1 Internet Explorer.........................................................................................................18 2.2 Mozilla Firefox...........................................................................................................19 2.3 Google Chrome..........................................................................................................19 2.4 Opera..........................................................................................................................19 2.5 Techniky vytváření digitálního podpisu......................................................................19 3 JavaScript........................................................................................................................21 3.1 Internet Explorer.........................................................................................................22 3.2 Mozilla Firefox...........................................................................................................22 3.3 Google Chrome..........................................................................................................23 3.4 Opera..........................................................................................................................24 4 ActiveX.............................................................................................................................25 4.1 Internet Explorer.........................................................................................................25 4.2 Mozilla Firefox...........................................................................................................26 4.3 Google Chrome..........................................................................................................26 4.4 Opera..........................................................................................................................27 5 Adobe Flash Player/AIR.................................................................................................28 5.1 Adobe Flash Player/AIR v prohlížečích.....................................................................28 6 Microsoft Silverlight........................................................................................................31 7 Java...................................................................................................................................33 7.1 Java Applets v prohlížečích........................................................................................33 7.2 Co Java Applety mohou a nemohou...........................................................................34 7.3 OpenOCES.................................................................................................................35 7.4 Java Web Start............................................................................................................35
6
8 .NET ClickOnce...............................................................................................................36 8.1 Internet Explorer.........................................................................................................36 8.2 Mozilla Firefox...........................................................................................................36 8.3 Ostatní prohlížeče.......................................................................................................37 9 Internetové bankovnictví................................................................................................38 10 WASP.............................................................................................................................41 11 Závěr...............................................................................................................................43 Literatura............................................................................................................................45 Přílohy.................................................................................................................................50
7
Kapitola 1
Úvod a představení základních pojmů
1.1
Úvodní slovo
Cílem této práce je zhodnocení dnešní situace digitálního podepisování pomocí webového prohlížeče. První kapitola se zabývá popisem základních pojmů používaných v této práci a představením některých vybraných webových prohlížečů. Podrobnější informace o zvolených prohlížečích jsou uvedeny v druhé kapitole. Třetí až osmá kapitola se věnuje konkrétním technologiím, a to podle možnosti tvorby a účelnosti digitálního podpisu ve webovém prohlížeči. Stav v internetovém bankovnictví, kde je digitální podpis používán pro schvalování transakcí, je popsán v deváté kapitole. Desátá kapitola pojednává o stavu současného digitálního podpisu a o možném řešení situace prostřednictvím protokolu WASP.
1.2
Rozvoj internetu
Je tomu již téměř půl století, co se začala psát historie internetu. Z experimentálního projektu agentury amerického ministerstva obrany USA DARPA (U.S. Department of Defense Advanced Research Project Agency) vznikla síť ARPANET. Tato síť se striktně decentralizovanou strukturou se ukázala jako perspektivní a další rozvoj na sebe nenechal dlouho čekat. Ačkoli byla síť navrhnuta pro vojenské účely, tak již v polovině osmdesátých let se k ní začaly připojovat americké univerzity a název sítě se změnil na Internet. Nárůst počtu uživatelů Internetu byl a je enormní. Pro představu, v roce 1984 bylo k Internetu připojeno tisíc počítačů, zatímco o osm let později již počet připojených počítačů přesáhl jeden milión [LUPA1]. Popularita a potenciál Internetu pro rozvoj společnosti vedly k jeho uvolnění ze státních institucí a akademické půdy do komerční sféry. To bylo zásadním mezníkem v dalším rozvoji Internetu. Od té doby se používá dnes zažitý pojem internet a v roce 2008 společnost ComStore oznámila, že počet uživatelů překročil jednu miliardu [TECHCRUNCH]. V České republice se historie internetu datuje od devadesátých let (MU získala připojení na internet roku 1992 [UVT]). Také v naší republice probíhal rychlý rozvoj tohoto komunikačního média a v dnešní době je k internetu připojeno téměř 60% domácností, což je dvojnásobný nárůst oproti roku 2003 [CSU]. V ČR se internet začíná rovněž používat v masovém měřítku např. při komunikaci se státními úřady (e-goverment a datové schránky). Internet, který je dostupný každému člověku proniká do našich každodenních životů. Jako zajímavost můžeme zmínit Estonskou ústavu, ve které je od roku 2000 zakotveno, že každý občan Estonska má zaručené právo na přístup na internet [INET].
8
1.3
Web
Interaktivní obsah dostupný na internetu se nazývá World Wide Web, neboli web. Web je soustava dokumentů v elektronické podobě navzájem propojených odkazy. Využívá protokol HTTP pro přenos dat a značkovací jazyk HTML pro grafickou prezentaci dokumentů. První pokusy s propojováním elektronických dokumentů se objevily během šedesátých let, avšak zásadní byl rok 1980, kdy Tim Berners-Lee v CERNu představil program - prohlížeč, umožňující přecházení mezi dokumenty pomocí odkazů [W3C1]. Šlo o předchůdce dnešních internetových prohlížečů. Dnes se již v přeneseném slova smyslu pojmem web označují internetové či webové aplikace všeobecně.
1.4
Webový prohlížeč
„Přístup k webovým aplikacím probíhá pomocí webového prohlížeče. Ten je úzce spojen s architekturou typu klient/server, která je založena na faktu, že na jednom místě (nemusí to být splněno doslovně) existuje server, poskytující nějaký obsah nebo služby a k němu je možné se připojit paralelně pomocí sítě z více míst pomocí jednoduchého přístupového prostředku (prohlížeče). Klientská část v tomto rozvržení většinou působí jako prezentační vrstva (vykresluje obsah) a server jako aplikační a datová vrstva. Podle toho v jaké míře je obsah zpracováván na straně klienta se pak část aplikace na této straně označuje jako „tenký“ (prohlížeč pouze prezentuje obsah) nebo „tlustý klient“ (prohlížeč zajišťuje také funkcionalitu aplikační vrstvy)“ [RIA]. Webový prohlížeč pro vykreslení obsahu na straně klienta využívá jazyk HTML, CSS a JavaScript, což můžeme považovat za standard, kterým je vybaven každý prohlížeč. Jednotlivé prohlížeče pak umožňují volitelně nainstalovat zásuvné moduly (pluginy), jež rozšiřují prohlížeči funkcionalitu a umožňují zobrazovat např. multimediální obsah. V kontextu této práce je volně zaměňován pojem "webový a internetový prohlížeč", a to bez újmy na obecnosti.
1.5
Zásuvný modul, plugin a rozšíření
Zásuvné moduly neboli pluginy představují softwarovou komponentu, kterou je možné doinstalovat do webového prohlížeče za účelem rozšíření jeho funkcionality tak, aby porozuměl obsahu webové stránky, kterému by jinak nerozuměl (multimediální obsah, komunikace s externími programy) [MOZ1]. Mezi nejznámější zásuvný modul patří Flash Player od společnosti Adobe, který umožňuje přehrávat animace a videa. Rozšíření (extension) webového prohlížeče se oproti pluginu liší v tom, že modifikuje samotný kód aplikace (prohlížeče) [MOZ2].
1.6
Digitální podpis
Digitální podpis (v české legislativě zakotven pod pojmem zaručený elektronický podpis) je obdobou ručního podpisu, který jsme zvyklí používat třeba při uzavírání smluv na pobočkách bank či pošt.
9
Klasický ruční podpis nám zaručuje pravost, nepopiratelnost a autenticitu podepsaného tiskopisu a je předmětem zkoumání znaleckého oboru písmoznalectví. Tento obor zkoumá vlastnosti podpisu, které jsou charakteristické pro každého jedince. Unikátní vlastnosti ručního podpisu byly přeneseny do světa počítačů v podobě digitálního podpisu. O úspěchu této migrace svědčí fakt, že v současnosti je nasazení digitálního podpisu velice rozšířené. Masivní využití digitálního podpisu můžeme nalézt zejména v internetovém bankovnictví, komunikaci s úřady a v elektronické poště. Digitální podpis nám ve všech těchto případech zaručuje, že platební příkaz či dokument byly opravdu odeslány onou osobou, která je u něj podepsána, a že data nebyla během přenosu sítí nijak změněna. Jako důkaz spolehlivosti a rozšířenosti této technologie svědčí skutečnost, že „v lednu 2002 byly v Estonsku zavedeny nové identifikační průkazy tzv. ID karty (obdoba našich občanských průkazů). Kromě řady pokročilých bezpečnostních prvků obsahují ID karty strojově čitelný kód a mikročip, který obsahuje údaje vytištěné na kartě s výjimkou fotografie a podpisu. Na čipu jsou též uloženy dva digitální certifikáty a související privátní klíče chráněné PIN kódy. Jeden z certifikátů slouží k autentizaci, druhý k elektronickému podpisu. Používání certifikátů není nijak omezeno, což znamená, že mohou držiteli sloužit ke komunikaci s osobami, organizacemi i státem.“ [INET]. Tyto ID karty umožňující vytvářet digitální podpis již byly několikrát použity v komunálních volbách. Naposled tomu bylo v roce 2009, kdy přes internet volilo téměř 10% voličů [ENEC]. Obrázek 1: ID karta (elektronický občanský průkaz) používaná v Estonsku [INET]
Právě tyto karty obsahují podpisový certifikát umožňující vytvořit digitální podpis. Ten je unikátní pro každý certifikát a tedy i osobu.
1.7
X.509
V předchozí kapitole je uvedeno, že na ID kartě se nachází certifikát s klíči. Samotný certifikát je datová struktura s dvojicí klíčů, která unikátně reprezentuje každého jedince. První návrh certifikátu se spojuje se standardem X.500 vydaným roku 1988. Byl to první pokus o souhrn
10
doporučení a metod pro PKI a adresářové služby [UVT2]. Dnes používaným standardem pro certifikáty je X.509. V současnosti je aktuální jeho třetí verze nesoucí označení X.509 (X.509 v3) a definovaná standardem X.509, resp. doporučením RFC 32801. Toto doporučení specifikuje formát certifikátů, seznam odvolaných certifikátů (CRL, Certificate revocation list), doplňkové atributy certifikátů a metody ověřování certifikátů. V doplňkových atributech, konkrétně v atributu KeyUsage lze vyčíst, zda-li daný certifikát můžeme použít pro digitální podepisování [IETF1]. Obsah takového certifikátu je uveden na obrázku č. 2: Obrázek 2: Dekódovaný certifikát X.509 Certificate: Data: Version: 3 (0x2) Serial Number: 1119060487 (0x42b38207) Signature Algorithm: sha1WithRSAEncryption Issuer: domainComponent = cz domainComponent = cesnet-ca commonName = CESNET CA Validity Not Before: Dec 10 13:14:21 2009 GMT Not After : Jan 10 13:44:21 2011 GMT Subject: domainComponent = cz domainComponent = cesnet-ca organizationName = Masaryk University commonName = Jiri Harazim Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:d9:06:80 <> a5:95 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment, Data Encipherment X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.8057.1.2.2.2.0 X509v3 Subject Alternative Name: email:[email protected] X509v3 CRL Distribution Points: DirName:/DC=cz/DC=cesnet-ca/CN=CESNET CA/CN=CRL5
1
RFC3280 dostupný online na URL: [kontrolováno 10.5.2010]
Takový certifikát umožňuje vytvářet digitální podpis. Pokud jej uživatel vlastní a má k dispozici potřebné nástroje pro provedení digitálního podpisu (kryptografický software a případný hardware jako je čtečka karet), může tímto podpisem z pohodlí svého domova potvrdit platební příkaz či podat daňové přiznání. Certifikát se používá i pro autentizaci uživatelů, zejména při komunikaci protokolem SSL. Velmi důležitá je skutečnost, že digitální podpis (v české legislativě se nazývá zaručený elektronický podpis) je v řadě států zakotven v legislativě. V členských zemích EU je digitální podpis řešen pomocí SMĚRNICE EVROPSKÉHO PARLAMENTU A RADY 1999/93/ES ze dne 13. prosince 1999, která byla do českého práva zapracována Zákonem č. 227/2000 Sb., o elektronickém podpisu, ve znění pozdějších předpisů.[DOST] Certifikát X.509 lze získat od certifikační autority (CA). CA je instituce, jež uživateli vystaví po jeho legitimaci a uhrazení poplatku certifikát. Identita jednotlivých uživatelů se váže k jejich certifikátu (veřejnému podepisovacímu klíči). Existuje vícero druhů certifikátů, např. certifikát podpisového klíče, šifrovací certifikát, atributový certifikát a autorizační certifikát sloužící pro různé účely. Samotný certifikát obsahuje informace o identitě vlastníka (jméno), veřejný klíč (ten je obdobou čísla občanského průkazu), dobu platnosti veřejného klíče (pro osobní certifikát je zpravidla jeden rok, po kterém je třeba si zažádat o prodloužení) a podpis vystavitele (CA). Digitální podpis důvěryhodné certifikační autority na uživatelském certifikátu poskytuje záruku, že takto vydanému certifikátu můžeme věřit. Vzniká tím hierarchie, kde na samotném vrcholu stojí certifikační autority. Ty podepisují svým podpisem vydávané certifikáty, čímž stvrzují důvěryhodnost vlastníka certifikátu. Je proto stěžejní, aby si certifikační autority úzkostlivě střežily své soukromé klíče, pomocí kterých se digitální podpis vytváří. Certifikát může obsahovat také doplňkové informace uvedené v RFC3280. Dnes je běžné, že veřejný klíč certifikátu je distribuován v souboru PEM a Cert. Chráněný privátní klíč sloužící k vytváření digitálního podpisu je uchováván (šifrovaně) v souboru PFX a P12.
12
1.8
Otisk (hash)
Otisk (hash) je krátký řetězec znaků unikátně reprezentující libovolná data. Otisk je prováděn nástrojem nazvaným "hashovací funkce", který se používá při vytváření digitálního podpisu. Hashovací funkce vrátí (spočte) na libovolně dlouhém vstupu krátký výsledek konstantní délky, který co nejpřesněji vystihuje vstupní data. V reálném světě podobnou funkci plní třeba otisk prstů, který je pro každého člověka unikátní. Zajímavá je skutečnost, že už při velmi malé změně vstupu, se výstup podstatně liší. Viz. obrázek 3:
Obrázek 3: Ukázka hashovací funkce
Pro stejný vstup dostaneme opakovaně tentýž otisk - toho lze s úspěchem využít v kryptografii, případně pro detekci chyb při přenosu dat (kontrolní součet, checksum) aj. Naopak dojde-li ke změně dat, výsledný otisk již nebude souhlasit s původním. Právě této skutečnosti se využívá v digitálním podpisu, kde se dělá otisk (fingerprint) zprávy. Hashovací funkce je totiž jednocestná, tzn. obecně k ní neexistuje reverzní funkce, která by k otisku vrátila odpovídající vstup. Při jednocestné funkci se užívají výpočetní operace nízké úrovně (bitové operace a posuny), operace hashování je tedy velmi rychlá. Naopak úloha nalezení původních dat je výpočetně velmi náročná. „Jelikož se otisk počítá z libovolně dlouhého textu, tak ke konkrétnímu otisku je teoreticky možné najít nekonečně mnoho původních textů. U některých algoritmů (např. MD5) se již daří nacházet texty se stejným otiskem. Výsledkem je pak opouštění těchto algoritmů a jejich nahrazení jinými (algoritmy třídy SHA-2, FIPS PUB 180-2; algoritmus WHIRLPOOL – ISO/IEC 10118-3:2003)“ [DOST]. Při digitálním podepisování je nutné podepsaná data zašifrovat kryptografickým algoritmem (RSA), který pro šifrování používá privátní klíč certifikátu. Tato operace je výpočetně náročná a podepsání většího množství dat by mohlo trvat poměrně dlouhou dobu. Proto se z dat nejprve rychle spočte jejich unikátní reprezentace ve formě otisku (hashe) a ten se teprve šifruje soukromým klíčem. Výsledkem je digitální podpis.
13
1.9
PKI
Pod představou milionů uživatelů webových služeb docházíme k faktu, že je třeba, aby se každý uživatel uměl věrohodně identifikovat. Pokud někdo zadá např. bankovní příkaz (internetové bankovnictví podle statistik Českého statistického úřadu využívá asi 30 % uživatelů internetu), pak pro účely identifikace je třeba ověřit, že platební příkaz zadala skutečně ona osoba, která může s účtem pracovat. K identifikaci slouží certifikát X.509 a technologie PKI z asymetrické kryptografie. Zkratka PKI (Public Key Infrastructure) je překládána jako "Infrastruktura veřejného klíče". Celý tento systém je založen na tom, že každý uživatel vlastní certifikát a dvojici klíčů. Jeden klíč se nazývá veřejný a může se volně distribuovat mezi další uživatele. Druhý klíč se nazývá soukromý (privátní) a ten si naopak vlastník certifikátu musí pečlivě střežit a předejít jeho zneužití. Asymetrická kryptografie zde hraje tu roli, že pro šifrování se používá privátní klíč a pro dešifrování veřejný. Zprávu tedy uživatel podepisuje svým tajným klíčem a tuto zprávu (digitální podpis) může za pomoci veřejného (dešifrovacího) klíče ověřit kdokoli. Vzhledem k tomu, že každý uživatel má certifikát od své certifikační autority, která je uvedena na jeho certifikátu, vyvstává problém, jak si důvěřovat mezi jednotlivými CA. Problém je řešen formou kotev, což jsou nezpochybnitelné distribuce certifikátu CA. PKI je tedy v podstatě struktura několika důvěryhodných stran (certifikačních autorit, CA) ověřujících a dosvědčujících identitu uživatelů. V této práci se zajímáme o použití certifikátu v kontextu digitálního podepsání dat, které je postaveno na bázi PKI. Bližší pohled na technickou stránku digitálního podpisu je možné demonstrovat na poslání podepsané zprávy (e-mailu) vlastníkem certifikátu X.509 a ověřením zprávy u příjemce. Za předpokladu, že posíláme libovolný text (dokument), pak celá procedura „Digitálního podpisu (u odesílatele) se vytváří ve dvou krocích: 1. Spočte se otisk (hash) podepisovaného textu. 2. Otisk dokumentu se za pomocí soukromého (privátního) klíče podepisujícího zašifruje. Výsledkem druhého kroku je digitální podpis. Ten se pošle spolu s podepisovaným textem příjemci. Jeho ověřování (verifikace) se na straně příjemce provádí ve třech krocích: 1. Příjemce samostatně spočte otisk z přijaté zprávy. 2. Příjemce dešifruje přijatý digitální podpis veřejným klíčem odesílatele. 3. Příjemce porovná výsledek získaný z bodu 1 s výsledkem získaným z bodu 2. Pokud jsou stejné, pak mohl digitální podpis vytvořit pouze ten, kdo vlastní soukromý klíč odesílatele – tedy odesílatel. A navíc tato skutečnost prokazuje, že zpráva nebyla během přenosu pozměněna, tj. zajišťuje i integritu zprávy. Digitální podpis provádí důkaz pravosti na základě vlastnictví soukromého klíče. Je tedy nutné, abychom si své soukromé klíče dobře střežili. Ztráta soukromého klíče je pak obdobná výměně podobizny v občanském průkazu. Neopatrnost ochrany soukromého klíče lze přirovnat k podepsání bianco šeků“ [DOST]. Je nezbytné ještě zmínit, že šifrování/dešifrování je výpočetně náročnou a složitou kryptografickou operací. Dnes patrně nejrozšířenější algoritmus používaný pro tento účel je asymetrický šifrovací algoritmus RSA1. Bezpečnost tohoto algoritmu spočívá v matematickém vztahu veřejného a soukromého klíče a předpokladu, že faktorizace (rozklad 1
Specifikace RSA dostupná online na URL: [kontrolováno 10.5.2010]
14
velkého celého čísla na prvočísla, pomocí kterých vytváříme veřejný a soukromý klíč) je výpočetně velmi náročný úkol, pro něž není znám algoritmus s polynomiální složitostí1. Je známo, že existuje více algoritmů pro tento účel (např. DSA 2) i hashovacích funkcí, nicméně celá tato problematika je velmi složitá a sahá za rámec této práce, a proto uvedené informace jsou úměrné rozsahu předkládané práce.
1.10 Nástroje webového prohlížeče Uživatel, pokud chce možnosti PKI využít (ať již jde o digitální podpis či šifrování) musí kromě certifikátu vlastnit i příslušné vybavení, které mu to umožňuje. Nejrozšířenějším hardwarovým zařízením je čipová karta s čtečkou a usb token. Certifikát, resp. soukromý klíč toto zařízení nikdy neopouští.
Obrázek 4: Čtečka karet [INET]
Tato zařízení se připojují k počítači a operační systém či specializovaný software (např. CryptoPlus) umožňuje s těmito zařízeními pracovat. Operační systém zpravidla poskytuje aplikacím rozhraní, jak s tímto zařízením komunikovat. V systému Windows jde o Crypto API, které tvoří vrstvu (middleware) mezi aplikací žádající o kryptografické služby a mezi Cryptographic Service Provider (CSP), což jsou kryptografické knihovny zaregistrované v systému, které jsou zodpovědné za implementaci příslušných algoritmů a funkcí. Softwarový modul pro práci s čtečkou karet je označován standardem PKCS#11 (Public Key Cryptography Standard3).
1
Bezpečnost šifrovacího algoritmu RSA se odvíjí od délky klíče. Dnes jsou nejčastěji používany klíče s délkou 2048 bitů, neboť kratší klíče již nejsou bezpečné. Dokument o faktorizaci 768 bitového klíče dostupný online na URL: [kontrolováno 10.5.2010] 2 Digital Signature Algorithm 3 Jde o celou sérii kryptografických standardů. Více informací o řadě PKCS lze najít online na URL [kontrolováno 10.5.2010]
15
Osobní certifikát ovšem nemusí být omezen pouze na čipovou kartu či usb disk. Stejně tak dobře může být ve formátu PKCS#12 (*.p12, *.pfx) uložen na pevném disku počítače (či jinde, avšak vždy by to mělo být v souladu s bezpečnostní politikou). Běžně se s podporou certifikátů můžeme setkat v poštovních (e-mailových) klientech jako např. Mozilla Thunderbird či Microsoft Office Outlook, které uživatelům ulehčují práci s certifikáty na pouhé kliknutí myši pro digitální podepsání či zašifrování emailu. Nicméně při práci s elektronickou poštou ve webovém prostředí certifiikáty využít nelze. Poskytovatelé elektronické pošty nepodporují vymoženosti certifikátů X.509, resp. S/MIME. Při posílání e-mailu přes webové rozhraní tedy není možnost e-mail digitálně podepsat či zašifrovat osobním certifikátem X.509. V současné době je možné naimportovat certifikát do prohlížečů, který takto úspěšně slouží při použití protokolu SSL jako autentizační nástroj. Nicméně tímto způsobem nelze certifikát využít k webovému podepisování. Ačkoli je velký zájem o přidání této funkcionality do webového prohlížeče, vývojáři těchto systémů tak doposud ve většině neučinili. Je přitom jasné, že mnoho institucí včetně bank, státních úřadů i soukromých firem by to velmi uvítalo a tato přidaná podpora by vedla k růstu ochrany informačního soukromí a rozvoji spolehlivé komunikace. Podle zjištění této práce se jako vysvětlení tohoto stavu nabízí, že v současné době prakticky neexistuje standard, kterého by se mohli jednotliví výrobci webových prohlížečů při implementaci webového podepisování držet. Cílem práce je zjištění současných způsobů řešení digitálního podpisu v prohlížeči, pohled na nové technologie, které by je mohly nahradit a v neposlední řadě i na možný budoucí vývoj a snahy o sjednocení celé problematiky standardem. Z možných řešitelských technologií, které jsou nejvíce rozšířeny mezi uživateli byly vybrány technologie JavaScript, ActiveX, platforma Flash, Silverlight, Java a .NET.
1.11 Vybrané webové prohlížeče V této práci se zabýváme podporou digitálního podpisu některých webových prohlížečů. Do zkoumané množiny prohlížečů jsou zahrnuty prohlížeče zejména podle jejich rozšířenosti, mimo prohlížeče Safari, neboť tento produkt není pro studenty FI MU volně k dostání, a přestože existuje Safari pro platformu Windows, tak k práci s uživatelskými certifikáty je nutné použít nástroj Keychain dostupný pouze v placeném systému Mac OS. [CACERT1]. Na serveru Prohlizece.info je náhled na statistiku českého serveru toplist.cz z března 2010,, která je uvedena v tabulce č. 1. Tabulka 1: Prohlížeče a jejich zastoupení mezi uživateli.[PROHL]
Prohlížeč
Podíl v %
Internet Explorer
43,1
Mozilla Firefox
40,3
Google Chrome + Safari
9,2
Opera
6,9
16
Kapitola 2
Webové prohlížeče a dostupné technologie V této práci se zabýváme nejrozšířenějšími prohlížeči mezi uživateli, od různých výrobců. A to jak čistě proprietárními prohlížeči, tak i open-source řešeními.
2.1
Internet Explorer
Historie prohlížeče Internet Explorer (IE) začala roku 1995, kdy vznikla první verze. Ta vycházela z prohlížeče Mosaic a obsahovala i část jeho licencovaných zdrojových kódů. O pár měsíců později byla vydána druhá verze tohoto prohlížeče, která přinesla podporu SSL (jež využívá klientské certifikáty pro autentizaci). Tato verze byla poslední, ve které byly použity licencované zdrojové kódy. O rok později, tedy roku 1996, byla vydána třetí řada Internet Exploreru, která byla zabudována do systému Windows 95. Tato verze přinesla novinky jako podporu CSS, technologie ActiveX a podporu Java apletů. Vzhledem k popularitě Windows 95 a díky přítomnosti v standardní instalaci v tomto operačním systému se Internet Explorer 3.0 stal prvním široce rozšířeným prohlížečem. V roce 1997 a 1998 byla uvedena do oběhu verze 4.0, resp. 5.0. Verze 5.5 SP1 byla poslední série, jež podporovala rozhraní NPAPI1, které je důležité pro rozšiřování funkcionalit prohlížečů formou zásuvných modulů a místo NPAPI se od řady Internet Explorer 5.5 SP2 a výše objevují objekty ActiveX, které mají poskytovat stejné možnosti [MS1]. Za zmínku stojí to, že Internet Explorer (a prohlížeče vycházející z něj, jako třeba Avant) jsou jedinou skupinou, která ActiveX komponenty podporuje a ostatní prohlížeče (Firefox, Chrome, Opera, Safari a spousta dalších) podporují jednotné rozhraní NPAPI. Důležitým mezníkem je rok 2001, kdy se na trhu objevuje nový operační systém Windows XP, se společně vydaným Internet Explorerem 6.0 [MS2]. Ten se svezl na vlně úspěchu Windows XP a jeho rozšíření mezi uživateli v následujících letech kulminovalo nad 90 % [WIKI1]. Po tomto vydání však následovala několikaletá odmlka ve vydání další verze, což mělo za následek rozšíření webových prohlížečů jiných výrobců. Od té doby podíl uživatelů Internet Exploreru mezi uživateli stále klesá. Nic na tomto trendu nezměnila ani sedmá a osmá verze tohoto prohlížeče. V současnosti jsou rozšířeny zejména tři nejnovější verze Internetu Exploreru, tedy verze 6.0, 7.0 a 8.0. Všechny tyto verze podporují ActiveX objekty a nepodporují NPAPI. Internet Explorer je proprietárním prohlížečem a firma Microsoft se jej snažila distribuovat jako součást instalace operačních systémů. Od nových verzí systému Windows již uživatelé budou mít na výběr si po instalaci sami zvolit, jaký prohlížeč by chtěli používat, a to bez nutnosti mít nainstalovaný Internet Explorer. Pro úplnost ještě uvádíme, že Internet Explorer není vydáván pro operační systém Linux. 1
Netscape Plugin Application Programming Interface (NPAPI) je rozhraní pro tvorbu zásuvných modulů, v roce 2004 bylo většinou výrobců přijato jeho rozšíření NPRuntime. Více informací online na URL [kontrolováno 10.5.2010]
17
2.2
Mozilla Firefox
Mozilla Firefox je internetový prohlížeč vyvíjený organizací Mozilla Foundation (vznikla roku 2003). Prohlížeč má své počátky v projektu Mozilla Project iniciovaný společnosti Netscape. [MOZ3] Tato veřejně prospěšná, nezisková organizace, sdružující lidi z celého světa (čítajících více než 1000 dobrovolníků a 300 zaměstnanců), kteří se podílí na vývoji Firefoxu a poštovního klienta Thunderbirdu. První verze prohlížeče Mozilla Firefox byla uvolněna 9. listopadu roku 2004. Následovaly další verze (verze 3.0 vydává v roce 2008, 3.5 z roku 2009 a 3.6 z ledna 2010). Tyto série reprezentují většinu dnes používaných verzí Firefoxu. K dnešnímu dni Firefox používá více než 360 miliónu lidí po celém světě na nejrůznějších platformách. Firefox je velmi přístupný rozšířením formou pluginů s využitím NPAPI, je open-source a do jeho vývoje se tedy může zapojit každý vývojář. Uživatelské prostředí užívá jazyk XUL, díky kterému je snadné pro něj napsat rozšíření (extension) či styl (theme). [MOZ4]
2.3
Google Chrome
Softwarový gigant Google se prosadil na poli prohlížečů během roku 2008, když vydal svůj vlastní multiplatformní webový prohlížeč nazvaný Google Chrome. Jedná se o nejmladší produkt, kterým se v této práci zabýváme a jehož nejnovější verze nese označení 4.1. Tento prohlížeč se díky podpoře Googlu a své kvalitě mezi uživateli rychle rozšířil a dnes mu patří, co se rozšířenosti mezi uživateli týče, pomyslné třetí místo. Google Chrome vychází z opensource prohlížeče Chromium a open-source renderovacího jádra Webkit. Pro možné rozšíření je možné použít rozhraní NPAPI. [GOO1]
2.4
Opera
Dlouhou historii má za sebou prohlížeč z dílny Opera ASA. Počátky Opery sahají do roku 1994, kdy na jejím vývoji začali pracovat lidé (Jon S. von Tetzchner a Geir Ivarsøy) z norské telekomunikační firmy Telenor, která po vydání první verze nechala tento projekt pokračovat v nově založené firmě Opera ASA. Opera ASA soustavně pracuje na Opeře až do současnosti, kdy je dostupná aktuální verze 10.52. Za tuto dobu si Opera získala řadu příznivců a postavení prohlížeče, jenž je znám svou snahou pečlivě dodržovat standardy (W3C). Opera sice nemá zveřejněné zdrojové kódy, ale její užívání je zdarma a je dostupná pro širokou paletu platforem (Windows, Linux, MacOS, Solaris a FreeBSD).[OP1]
2.5
Techniky vytváření digitálního podpisu
V této kapitole byly probrány testované prohlížeče, pomocí kterých se budeme snažit vytvořit digitální podpis. Digitální podepisování vyžaduje spuštění programového kódu, je tedy třeba
18
uvažovat na straně uživatele (vlastníka certifikátu) tlustého klienta. Od následující kapitoly se zaměřujeme na typ tlustého klienta, který by byl schopný vytvořit digitální podpis. Klient může být vystavěn na celé řadě dostupných technologií. Pro účely této práce jich bylo vybráno šest, přičemž každá z nich byla vybrána tak, aby pokrývala co nejširší uživatelskou základnu. Pro přehlednost je zde uveden stručný výčet technologií tak, jak jsou chronologicky uvedeny v následujících kapitolách, a to: JavaScript, ActiveX, Flash/AIR, Silverlight, Java a .NET ClickOnce. Pro úplnost ještě uvádíme, že v kapitolách tři až osm jsou uvedeny informace k jednotlivým technologiím, zatímco kapitola devět se věnuje praktickému řešení tohoto problému v internetovém bankovnictví.
19
Kapitola 3
JavaScript JavaScript je skriptovací jazyk, který je dostupný ve většině prohlížečů. Jeho vznik ohlásily roku 1995 společně firmy Netscape a Sun (Sun Microsystems Inc., dnes Oracle). Za vznikem stál Brendan Eich a původně se tento jazyk jmenoval LiveScript, což mělo vystihovat živost a dynamičnost tohoto jazyka. Ovšem ještě během vývoje prohlížeče Netscape Navigator verze 2.0 se LiveScript přejmenoval na JavaScript. Toto přejmenování bylo způsobeno tím, že LiveScript byl původně vyvíjen, aby zaplnil mezeru mezi statickými HTML stránkami a Java aplety. Velký potenciál JavaScriptu z důvodu nepotřebnosti kompilátoru, syntaxí velmi podobnou rozšířené Javě (ačkoli se samotnou Javou nemá nic společného) a relativní jednoduchost, byl příčinou jeho rychlého rozšíření v prohlížečích a zaujmutí výsadního postavení v skriptování na straně klienta (client-side scripting). Na příchod nové technologie zareagoval i Microsoft, který vydal vlastní skriptovací jazyk VBScript a dodatečně v červenci 1996 vydal vlastní implementaci JavaScriptu pojmenovanou JScript. Odlišná implementace JavaScriptu v prohlížeči Internet Explorer 3.0 vedla k problémům s nekompatibilitou. To byl důvod, proč Netscape společně s firmou Sun vyvinuly snahu o vytvoření standardu pro JavaScript. Společnosti se obrátily se na organizaci ECMA (International European association for standardizing information and communication systems) a vznikl standard ECMAScript Language Specification (označovaný jen ECMAScript, či ECMA-262), podle kterého si výrobci prohlížečů vytvořili své vlastní dialekty i s jejich JavaScriptovou implementací. Se vzrůstající snahou dodržovat DOM (Document Object Model) vydaný konsorciem W3C (World Wide Web Consorcium) se dnešní JavaScript značně sjednotil podle normy ECMAScript (ECMA2621). Stále však existují rozdíly v implementacích jednotlivých dialektů ve webových prohlížečích. [OREILLY1] Příčinou této rozdílnosti je fakt, že ECMAScript je standard a existuje spousta jeho dialektů, které jsou jednotlivými výrobci prohlížečů implementovány. [WIKI2] ECMAScript tedy můžeme považovat za minimální standard, který nám zaručuje kompatibilitu mezi jednotlivými implementacemi JavaScriptu v různých prohlížečích. Není nic neobvyklého, že si vývojáři webového prohlížeče přidají do své implementace čistě proprietární funkcionalitu, která však není podporována v jiných prohlížečích. Důvod, proč byl JavaScript vybrán jako vedoucí reprezentant technologií webového prohlížeče je ten, že je velmi rozšířen (můžeme s ním počítat u 99 % uživatelů). Lze ho sice v prohlížeči vypnout, nicméně naprostá většina uživatelů jej má zapnutý. Je důležité rovněž poznamenat stěžejní fakt, že v normě ECMA-262 není žádná zmínka o podpoře certifikátů X.509 a tím pádem v JavaScriptu není možné na základě standardu vytvořit digitální podpis, kterým by se mohli řídit jednotliví výrobci prohlížečů.
1
standard ECMA-262 ECMAScript Language Specification, dostupný online na URL: [kontrolováno 10.5.2010]
20
3.1
Internet Explorer
Microsoft si vytvořil vlastní implementaci standardu ECMA-262 pojmenovanou JScript. Tato implementace se momentálně nachází v páté verzi. Z referenční příručky (JScript Language Reference) bylo zjištěno, že JScript nenabízí žádnou podporu certifikátů [MS3]. Ze všech jeho proprietárních knihoven se tato práce zabývá pouze možností instanciovat objekty ActiveX z JScriptu.
3.2
Mozilla Firefox
Organizace Mozilla Foundation vyvíjející prohlížeč Firefox vychází z původní implementace JavaScriptu od firmy Netscape. Tuto původní implementaci vytvořil Brendan Eich pod kódovým jménem SpiderMonkey v programovacím jazyce C a je součástí vykreslovacího jádra Gecko užívaného ve Firefoxu. [WIKI3] JavaScript Mozilly vyhovuje otevřenému standardu ECMA-262 a obsahuje navíc proprietární knihovny. Poskytuje proprietární knihovnu (objekt) crypto, jež poskytuje služby spojené s kryptografií. Na oficiálních webových stránkách Mozilly výslovně upozorňují, že tato knihovna není dostupná v žádném jiném prohlížeči. V prostředí JavaScriptu ve Firefoxu se k službám této knihovny dostaneme pomocí kódu <script type="text/javascript"> ... [window.]crypto.[...]; ...
a volání metod (tečkovou notací) na objektu crypto nám poskytuje tyto služby: vygenerování žádosti o certifikát, načtení PKCS#11 modulu a digitální podepsání textu uživatelským certifikátem. Syntaxe této podpisové funkce vypadá takto: resultString= [window.]crypto.signText(stringToSign, caOption,[ caNameString1, [ caNameString2, . . . ]]);
Po jejím zavolání se uživateli na obrazovce zobrazí dialog (viz kapitola Přílohy, příloha č. 6), požadující podepsání textu předaného parametrem stringToSign. Tento text je zobrazen v okně dialogu, uživatel tedy vidí co podepisuje. Na místo parametru caOption je možné uvést buď možnost „auto“, která se pokusí vybrat ze seznamů uživatelských certifikátu ten, který je uveden v parametru caNameString1, caNameString2 atd. Pokud na místo parametru uvedeme druhou možnou volbu, parametr „ask“, pak je uživateli zobrazen dialog, ve kterém si může vybrat certifikát, kterým chce text podepsat. Po zadání hesla k certifikátu prohlížeč Firefox podepíše text a výstup vrátí do proměnné resultString ve formátu PKCS#7 a kódování Base64.[MOZ5] [SUN1]
21
Formát PKCS#7 představuje standard specifikující formát digitálně podepsaných nebo zašifrovaných zpráv. Jde o rozšíření CMS (Cryptography Message Syntax). Tento formát tvoří základ S/MIME, což je norma pro digitální podepisování/šifrování elektronické pošty. Funkce crypto.signText() nám v podstatě vrací část elektronicky podepsané e-mailové zprávy, kterou stačí doplnit o příslušné náležitosti a zprávu je možné odeslat z webové stránky. Ověření takové zprávy nebo výsledného řetězce vráceného crypto.signText() v e-mailových klientech, resp. ve volně dostupném nástroji OpenSSL je již pak velmi snadné. Pro programové ověření lze s úspěchem využít volně dostupné kryptografické knihovny Bouncy Castle, která je dostupná jak pro Javu, tak pro C++. Dalším specifikem řetězce vráceného funkcí crypto.signText() je skutečnost, že data se kódují v Base64. Jelikož počítač podpis zpracovává na úrovni bitů (data sestávající ze samých jedniček a nul), je vhodné najít takovou reprezentaci binárních dat, se kterou by se dalo lépe pracovat. K tomuto slouží kódování Base64, kdy dojde k rozdělení podepisovaného bloku dat (bitů) na menší části po šesti bitech a tyto šestice se pak nahradí znaky z tabulky znaků Base64, což jsou znaky velké a malé abecedy, + a / (je jich dohromady 64). Pokud poslední rozdělený blok má délku kratší šesti bitů, je na konec výsledného řetězce podle potřeby připojen jeden až dva znaky „=“. Takto z binárních dat obdržíme jejich textovou reprezentaci. Velikost dat se po zakódování zpravidla zvýší o 33 %. Za malou výhodu můžeme považovat fakt, že pokud se nám po přenosu v přijatém řetězci objeví jiný znak než některý ze znaků vyhrazených pro reprezentaci Base64, může to indikovat, že při přenosu dat došlo k chybě. Za zmínku také stojí, že pokud je certifikát uložen v souboru s koncovkou PEM, pak je zakódován právě v Base64. Z výše uvedeného vyplývá, že digitální podpis lze vytvořit pomocí proprietární knihovny Crypto obsažené ve Firefoxu. Předpokladem je, že uživatel vlastní certifikát a má jej v aplikaci Firefox naimportovaný nebo využívá modul PKCS#11. [MOZ6] Ačkoli knihovna Crypto existuje již řadu let a je velmi atraktivním nástrojem pro vytváření webového podpisu, je Mozilla jediný výrobce, který tuto knihovnu udržuje a lze se pouze domýšlet, zda-li se alespoň některé její části časem dočkáme v standardu ECMA-262, který by tuto funkcionalitu mohl rozšířit do ostatních prohlížečů jako dosud chybějící standard.
3.3
Google Chrome
Když se společnost Google rozhodla pro vývoj vlastního prohlížeče, stála před otázkou, jaké knihovny při jeho vývoji použít. Rozhodla se pro využití vykreslovací knihovny (render/layout engine) WebKit, vyvíjené a používané firmou Apple (Chrome ukazuje znovupoužití kódu a na internetu se zmiňuje o použití přinejmenším 25 knihoven [CAT1]). Nicméně pro prohlížeč Chrome se Google rozhodl vytvořit vlastní implementaci JavaScriptu, protože původní JavaScriptová implemenace JavaScriptCore přestala vyhovovat. Výsledkem byl JavaScriptový engine V8 [ROOT1]. Za povšimnutí stojí fakt, že při vlastní implementaci bylo použito knihovny NSS od Mozilly, která je i součástí Firefoxu. Po spuštění Chrome a vyhledání správy certifikátů (v jeho nabídce), se zobrazí seznam certifikátů načtených z úložiště systému Windows s tím, že okno s certifikáty je vizuálně shodné s oknem v Internet Exploreru. Z toho je možné usoudit na použití systémového rozhraní CryptoAPI. I když tato kombinace je velice výhodná, protože by mohla umožnit použít knihovnu Crypto od Mozilly a zároveň úložiště certifikátu systému Windows
22
(Mozilla používá své vlastní úložiště), tak při experimentálním ověření této knihovny se zdá, že není funkční. Volání javascriptového kódu: var resultString = windows.crypto.signText('FooBar',”ask”);
vracelo chybovou hodnotu Undefined. Z toho je možné usoudit, že kryptografická knihovna Crypto není v Chrome zahrnuta. Problémy s praktickým použitím certifikátu hlásí i další uživatelé přímo na stránkách Chrome, bohužel zatím bez odpovědi ze strany Googlu [GOO2]. Informace o problémech při inicializaci (handshaku) SSL3 s vyžádáním klientského certifikátu jsou hlášeny i na stránkách Chromia [GOO3], což je jádro Google Chrome. Vzhledem k tomu, že certifikáty jsou do prohlížeče zapracovány a Chrome je mladý prohlížeč, lze očekávat, že se tato funkcionalita časem objeví, avšak pravděpodobně pouze pod podmínkou, že půjde o otevřenou a rozšířenou technologii.
3.4
Opera
V Opeře se setkáváme se striktní implementací JavaScriptu podle normy ECMA-262. Základní portfolium je rozšířeno dalšími funkcemi, které pocházejí z JScriptu používaného Internetem Explorerem (většinou jde o funkce pro práci s řetězcem) [OP2]. Po tomto zjištění konstatujeme, že použití JavaScriptu v Opeře pro vytvoření digitálního podpisu není možné.
23
Kapitola 4
ActiveX ActiveX komponenta je jiné jméno pro OLE objekt či Component Object Model (COM) implementující IUnknown rozhraní. Kontejner, ve kterém jsou tyto komponenty spuštěny, s nimi komunikuje přes QueryInterface [MS4]. Tento kontejner může být jak operační systém, tak i jiná aplikace, například webový prohlížeč. Technologie ActiveX tedy není vázána přímo na operační systém Windows, avšak na jiných platformách oficiálně podporována není. Komponenty ActiveX lze napsat v libovolném jazyku firmy Microsoft a slouží k rozšíření funkcionality programu. Prohlížeče všeobecně, kromě Internet Exploreru, tuto technologii nepodporují, neboť jak argumentuje na svých stránkách Mozilla, jedná se o technologii dostupnou pouze pro platformu Windows a její integrace do systému Windows z ní udělala významný cíl pro škodlivý software. [MOZ7] Obdobný postoj k této technologii mají i ostatní výrobci prohlížečů a Google otevřeně přiznává, že jediná možnost, jak zprovoznit ActiveX komponenty v ostatních prohlížečích vede přes rozšíření s použitím NPAPI [GOO4]. Oproti všeobecně podporovanému JavaScriptu by se mohlo zdát, že se touto izolovanou technologií nemá smysl zabývat, když se na ní můžeme spolehnout pouze v jediném prohlížeči. Nicméně uživatelská základna Internetu Exploreru je nezanedbatelná a komponenta ActiveX umožňuje přistupovat k CryptoAPI systému Windows, což je velmi mocný nástroj, se kterým lze dále pracovat. Je však třeba počítat s tím, že tato komponenta není vždy v systému Windows dostupná a je třeba ji případně doinstalovat (zdarma) ze stránek firmy Microsoft. CryptoAPI, neboli Cryptographic Application Programming Interface je rozhraní systému Windows, které má přístup k systémovému úložišti certifikátů a také poskytuje rozhraní pro volání kryptografických metod, resp. zprostředkovává přístup k CSP. Zejména umožňuje digitální podepisování dat.
4.1
Internet Explorer
Internet Explorer je z našich prohlížečů jediným, který podporuje komponenty ActiveX, protože jak prohlížeč, tak i komponenta ActiveX pocházejí od stejného výrobce. Důsledkem je možnost volat komponentu ActiveX i ze všech programovacích jazyků od firmy Microsoft. V prostředí webového prohlížeče to je VBScript a JavaScript, přesněji řečeno Jscript. Implementace tohoto skriptu pro zavolání CryptoAPI je veřejně známá a používaná. Komponenta ActiveX používaná pro práci s CryptoAPI se nazývá CAPICOM (Crypto API Component Object model). Vytvoření ActiveX komponenty se v JScriptu se provádí kódem: var SignedData = new ActiveXObject("CAPICOM.SignedData");
Celou tuto implementaci je možné najít na internetu. Upozorňujeme, že možnost použití ActiveX jde v prohlížeči zakázat a při vyskytnutí objektu ActiveX zpravidla uživatel obdrží varování, zda-li chce opravdu komponentu ActiveX povolit, neboť tyto komponenty jsou často zneužívány k provádění útoků na počítač uživatele.
24
Zdůraznit je třeba i to, že komponenta CAPICOM není na každém stroji se systémem Windows automaticky instalována, lze ji však volně stáhnout ze stránek Microsoftu. Oficiálně je CAPICOM podporován na operačních systémech Windows od verze Windows 95 až Windows Vista. [MSDN1] Nyní je již tato komponenta označována jako zastaralá (deprecated) a je doporučeno ji nepoužívat. Místo toho je doporučováno spolehnout se na podporu kryptografických služeb z prostředí .NET. V referenční příručce ke CAPICOM rozhraní se píše: „CAPICOM je pouze 32bitová komponenta, která je dostupná pro použití v následujících operačních systémech: Windows Server 2008, Windows Vista, Windows XP a Windows 2000. Místo této komponenty použijte .NET Framework k implementaci bezpečnostních funkcí.“ [MS5]. Pro Windows 7 tedy nejspíše dosud neexistuje ActiveX uvolněná Microsoftem k volnému použití. Volné a lukrativní místo na trhu v této oblasti již využily některé firmy pro vytvoření a komerčnímu využití vlastních komponent [LIZ1]. Pozn.: CAPICOM jsem úspěšně otestoval a přestože jsem komponentu svévolně neinstaloval, v testovaném systému Windows XP s nejnovějšími aktualizacemi byla k dispozici (viz příloha č. 8).
4.2
Mozilla Firefox
Prohlížeč Firefox komponenty ActiveX oficiálně nepodporuje. Místo toho využívá zásuvných modulů (pluginů) a rozšíření (extensions) pro přidání nové funkcionality [MOZ7]. Avšak existují rozšíření pro Firefox, které přidávají podporu ActiveX, a které lze nalézt i na oficiálních stránkách doplňků pro Firefox. Ovšem ani ty nejlépe hodnocené z nich podle ohlasu uživatelů zdaleka nepracují bez chyb [MOZ8]. Zpravidla jde o doplňky, které se snaží objekt ActiveX zapouzdřit do sebe a pak řízení předat jinému pluginu. Bohužel podle informací uživatelů se často stane, že se poškodí i flashové aplikace, které v prostředí Internet Exploreru pracují jako ActiveX komponenta. Toto řešení je tedy nespolehlivé a není de-facto důvod jej používat, pokud Firefox nabízí zabudovanou funkci pro digitální podepisování dat v podobě javascriptové funkce crypto.signText().
4.3
Google Chrome
Google Chrome objekty ActiveX nepodporuje. I zde se ovšem najde klička. Na oficiálních stránkách Chrome je zveřejněno rozšíření, které umožňuje v tabulce prohlížeče Google Chrome spustit prostředí Internet Exploreru. Rozšíření je dostupné pouze pro platformu Windows (Linux a Mac OS objekty ActiveX nepodporují). Vzhledem k tomu, že v tabulce lze spustit aplikace Internet Explorer, je funkcionalita stejná, jako kdybychom použili samotný Internet Explorer. Uživatel je vystaven stejným hrozbám, ale má možnost využít i stejných funkcí. Projekt věnující se vývoji tohoto rozšíření se jmenuje IE Tab. Zajímavé je, že toto rozšíření existuje i pro prohlížeč Firefox, nicméně pouze do verze 3.5, jelikož IE Tab je postaven na technologii zásuvných modulů, které Firefox již v nejnovější verzi 3.6 nepodporuje. IE Tab je open-source projekt, takže můžeme očekávat, že se později objeví portace do novějších verzí Firefoxu.
25
4.4
Opera
Jak prohlížeče Firefox a Chrome, tak i Opera oficiálně nepodporuje ActiveX objekty ani skriptovací jazyk VBScript. Příčinou jsou stejné důvody, které na svých stránkách mají uvedeny Firefox a Chrome. Přestože společnosti uvádějí, že objekty ActiveX nepodporují, zmiňují plugin Neptune, který je obdobou již zmíněného rozšíření IE Tab. V podstatě se jedná o spuštění jádra Internetu Exploreru v Opeře [OP3]. Nejde o open-source rozšíření, nicméně pokud se uvede odkaz na stránku autorů, kde si lze rozšíření stáhnout, pak je zdarma. V jiném případě je nabízen za úplatu. Příklad použití s uvedením výrobce v HTML vypadá takto: <embed type="application/x-meadco-neptune-ax" pluginspage="http://www.meadroid.com/neptune/download/" width="100%" height="75%" param-location="your-entry-page.htm">
Následně dochází k automatickému spuštění zobrazovacího režimu Internet Exploreru. Pokud bychom jej chtěli spustit jako novou tabulku v Opeře, pak lze lehce na panelu nástrojů vytvořit nové tlačítko, které tuto akci umožní. Požadovaná minimální konfigurace je Windows 2000/NT 4.0 a Internet Explorer 4.0. Závěrem uvádíme, že toto užitečné rozšíření je dostupné nejen pro Operu, ale i pro prohlížeče s vykreslovacím jádrem WebKit, jako třeba Google Chrome a Safari (pro Windows), stejně jako pro prohlížeče založené na vykreslovacím jádru Gecko, což je třeba Firefox. [NEPT1]
26
Kapitola 5
Adobe Flash Player/AIR Adobe Flash Player je doplněk pro prohlížeče vyvíjený společnosti Adobe a je určen pro tvorbu vektorové grafiky. Rozšířenost pluginu Flash Player mezi uživateli se pohybuje na 99 % [ADOBE1]. Ačkoli by se mohlo zdát, že tato technologie, určená především pro animace na internetových stránkách je pouze multimediální nástroj, není tomu tak. Alespoň již ne dnes. Adobe Flash totiž dospěl do své desáté verze a od vydání jeho první verze firmou Macromedia uplynulo již přes deset let. Po tuto dobu procházel vývojem a neustálým zlepšováním. Jelikož nabídl uživatelům to, co dosud žádná jiná technologie na internetu, stal se velmi rychle oblíbený. Nejznámější reprezentant serverů, které jsou na Flashi založené, je nejspíš server Youtube.com, kde si uživatelé pomocí svého Flash pluginu mohou přehrávat videa. Nabízí se otázka, proč se zajímat o multimediální plugin Adobe Flash v práci, která se zabývá digitálním podpisem. Důvodem jsou dvě skutečnosti. První je, že tento plugin je rozšířen mezi 99 % uživateli (což žádný jiný zdaleka není). Druhá skutečnost je ta, že za dobu své existence se Flash vyvinul v novou platformu v rámci webového prohlížeče s vlastním programovacím jazykem ActionScript. I když pro jeho spuštění v prohlížeči je třeba mít nainstalovaný plugin Flash Player plnící funkci Flash kontejneru, máme možnost si do systému doinstalovat běhové prostředí AIR (obdoba běhového prostředí Javy nebo .NET Frameworku), které funkcionalitu Flashe ještě více rozšiřuje. Máme tak možnost vytvářet RIA aplikace (Rich Internet Application – bohatá internetová aplikace). Platforma Flash nám poskytuje programovací jazyk ActionScript v jeho nejnovější třetí verzi. Jde o objektový kompilovaný jazyk vycházející z normy ECMAScript. Třetí verze ActionScriptu poskytuje poměrně bohaté API a v případě běhového prostředí AIR se ještě dále rozšiřuje. Programy postavené na technologii Flash si můžeme pustit v prohlížeči pomocí zásuvného modulu (pluginu Flash Player). Jedinou výjimkou je Internet Explorer, ten používá pro podporu Flashe komponenty ActiveX, což není překážkou, protože funkcionalita je totiž ve všech prohlížečích, včetně Internet Exploreru, stejná.
5.1
Adobe Flash Player/AIR v prohlížečích
Flashový element je ve stránce zabalen pomocí HTML značky (tagu) OBJECT, kde v parametru TYPE je specifikován MIME typ, resp. Internet Media Type, který má prohlížeč pro zpracování elementu použít. Stojí za povšimnutí, že prohlížeč se nesnaží se souborem nakládat podle jeho přípony, ale jeho rozhodnutí je vázáno právě s typem MIME a aplikací, kterou má pro
27
něj zaregistrovanou.1 2 Původní kořeny má MIME v elektronické poště. [WIKI4] Samotný kód, který nám zajistí, že prohlížeč pro interpretaci obsahu zavolá Flash Player vypadá takto:
Po zavolání plugin Flash Player se můžeme podívat, jaké jsou možnosti pro elektronické podepisování. Při zkoumání této oblasti jsme využili Referenční příručky jazyka ActionScript 3.0 a jeho komponent, což je dokumentace API pro aplikace Adobe Flash Player a Adobe AIR. Co vše Flash nabízí? Zajímáme se především o způsob, jak se dostat k uživatelskému certifikátu. V podstatě není na výběr, neboť žádné rozhraní umožňující přístup do úložiště certifikátu není k dispozici a nabízí se možnost buď pracovat s objektem ActiveX, tedy objektem CAPICOM, nebo nechat uživatele, aby komponentě Flash certifikát poskytl sám. První možnost s využitím objektu ActiveX je možná přes rozhraní flash.external.ExternalInterface. To dovoluje komunikovat s komponentou CAPICOM za předpokladu, že webový prohlížeč uživatele podporuje technologii ActiveX, tj. pokud používáme Internet Explorer, kde plugin Flash je samotná ActiveX komponenta, pak můžeme komunikovat třeba i s desktopovou aplikací využívající ActiveX [ADOBE2] [PEARLS1]. Otázkou je, proč to dělat takto složitě, neboť je jasné, že používáme Internet Explorer (nebo jej máme spuštěn pomocí jiného prohlížeče) a můžeme tedy využít rovnou přístupu k ActiveX objektům pomocí JScriptu nebo VBScriptu. Referenční přířučka nám k tomuto účelu poskytuje rozhraní ExternalInterface, což umožňuje komunikovat ActionScriptu přes Flash Player kontejner např. s JavaScriptem. Ukázka této schopnosti s funkcí jscommand, předchůdcem ExternalInterface je demonstrována na internetu3. Ještě lze doplnit, že možnost komunikace ActionScriptu s JavaScriptem je dostupná i v prohlížečích implementujících rozhraní NPRuntime. V prohlížečích, které nevyužívají jádra Internet Exploreru (Firefox, Chrome a Opera), není CAPICOM přes Flash dostupný. Nezbývá tedy, než nechat uživatele, aby certifikát poskytl sám. K tomuto může sloužit třída FileReference z balíku flash.net a její metoda browse(), která uživateli zobrazí systémový dialog Otevřít soubor. Z bezpečnostních důvodů jde o jediný způsob, jak se dostat na souborový systém uživatele. Ovšem i v této fází, kdy jsme schopni aplikaci Flash předat certifikát je uživatel bezradný, neboť z tohoto souboru nemůžeme číst ani do něj zapisovat. K dispozici má jen vlastnosti jako velikost souboru, jeho název, typ, data vytvoření a změny [ADOBE3]. Jediný způsob, jak si přečíst data je na straně serveru po zavolání metody upload() či po round-tripu (odeslání dat na server a jejich přijetí zpět). To je ovšem naprosto nereálné řešení, 1
Zajímavá stránka pojednávající o MIME type a content-type s možností ozkoušení na URL: [kontrolováno 10.5.2010] 2 Toto chování je charakteristické pro NPAPI/NPRuntime pluginy, které zavolají zaregistrovanou aplikaci a data odkazovaného elementu do ní nastreamují. 3 Interaction with JavaScript, dostupné z URL: [kontrolováno 10.5.2010]
28
neboť žádný rozumný uživatel by nedal certifikát s privátním klíčem (vědomě) z ruky. Další odstavec je tedy spíše teoretická spekulace. I kdybychom věřili, že uživatel poskytne svůj certifikát s privátním klíčem flashovému pluginu (který jej může odeslat na server!), stejně bychom čelili absenci kryptografie ve Flashi. Neobsahuje totiž knihovnu, jak vytvořit digitální podpis. Pokud se v tomto v budoucnu něco změní, což je kvůli otázce bezpečnosti nepravděpodobné (není důvod), pak by mohlo být výhodné použít knihovnu AS3Crypto, jež pod licencí BSD poskytuje kryptografické služby včetně podpory X.509 a vytváření digitálního podpisu. [GOO5] Další možností je použít běhové prostředí AIR, které nám oproti funkcím zmíněným výše nabízí plnohodnotný přístup na souborový systém přes balík flash.filesystem. Ten umožňuje přistupovat na souborový systém, zejména číst soubory bez nutnosti jejich odesílání na server. Ovšem absence plnohodnotné kryptografie přetrvává a zejména si musíme uvědomit, že i když je teoreticky možné implementovat digitální podpis jako AIR aplikaci (za pomocí knihovny AS3Crypto), tak se tím stírá výhoda Flashe, kterou je jeho velké rozšíření mezi uživatele (99 %), neboť běhové prostředí AIR takto rozšířené zdaleka není. Dalším faktem je ten, že nutnost instalace běhového prostředí AIR se blíží úrovni řešení v Javě či .NET, které také vyžadují běhové prostředí, ale zato nabízí mnohem propracovanější a sofistikovanější nástroje potřebné k vytvoření digitálního podpisu. Pod zjištěnými fakty nezbývá než konstatovat, že platforma Flash se pro účely elektronického podpisu nehodí. A to i přesto, že se za dlouhou dobu své existence vyvinula v mocnou RIA technologii s plnohodnotným programovacím jazykem.
29
Kapitola 6
Microsoft Silverlight Další plugin, který můžeme u uživatelů očekávat, je zásuvný modul Silverlight od společnosti Microsoft. Silverlight byl vydán ve verzi 1 v roce 2007, čímž představuje poměrně mladou technologii, která však plánovala vydání čtvrté verze v době vzniku této práce. Silverlight byl vyvinut za účelem přímého konkurování multimediálnímu pluginu Flash Player od firmy Adobe. Z toho vyplývá, že doménou Silverlightu bude zejména grafika a uživatelské rozhraní. Aby mohl konkurovat Flashi, musel poskytnout podporu pro různé prohlížeče i systémy, takže dnes na něj můžeme narazit asi u 60 % uživatelů na platformách Windows, Mac OS a Linux.[SILV1] Pro multi-platformní podporu se muselo zvolit odpovídající běhové prostředí. Microsoft pro něj použil svůj .NET Framework a celý Silverlight běží na platformě .NET, což znamená, že pro vývoj této aplikace můžeme použít různorodý programovací jazyk (jako je C#, Visual Basic .NET či Delphi). Velmi výhodné také je, že Silverlight nevyžaduje na klientském počítači instalaci .NET Framework. Silverlight obsahuje "ořezané" běhové prostředí .NET. Díky tomu lze vyvinout aplikaci, a aby si ji uživatel pustil, je zapotřebí pouze mít nainstalován plugin Silverlight. Pro operační systém Linux je určen plugin Moonlight, vyvíjený firmou Novel a podporovaný Microsoftem. Jelikož platforma .NET obsahuje velmi rozsáhlé API s podporou kryptografie a X.509, mohli bychom jej využít pro vytvoření digitálního podpisu. Nedostatkem ale je, že v "ořezaném" prostředí .NET, dostupném v Silverlightu, absentuje právě podpora asymetrické kryptografie a možnost přistupování k systémovému úložišti certifikátu. Nahlédnutím do dostupného API, lze zjistit, že je zde podpora pouze pro hashování a symetrickou kryptografii. Chybějící třídy, jako je RSACryptoServiceProvider z balíku (namespace) System. Security.Provider umožňující vytvořit digitální podpis, jsou totiž označeny jako SECURITY CRITICAL, a tudíž je nemůžeme použít. Nemůžeme ani volat nativní kód či použít COM komponenty (ActiveX), jako třeba CAPICOM [MS6]. Z bezpečnostních důvodů také chybí přístup na souborový systém klienta. Toto omezení lze sice obejít podobně jako ve Flashi, a to vyvoláním dialogu Otevřít soubor pomocí třídy OpenFileDialog z jmenného prostoru System.Windows.Controls, po kterém je možné pracovat se souborem jako s datovým proudem (streamem). Nicméně toto řešení je nepraktické a pro uživatele krajně nepohodlné. Ani v nové čtvrté verzi Silverlightu nově přidaná možnost přistupovat k disku ve vybraných složkách jako My Documents, My Pictures či obdobných na jiných operačních systémech tuto situaci neřeší. Prakticky to totiž znamená pouze distribuovat aplikaci Silverlight jako OOB (Out of Browser, mimo prohlížeč) aplikaci s oprávněními důvěryhodné aplikace, což však stále neumožňuje vytvořit digitální podpis. [MSDN2] Situace je tedy velmi podobná jako při řešení téhož problému na platformě Flash. Na straně klienta je k dispozici robustní programovací jazyk umožňující spouštět komplexní kód, nicméně podpora PKI a přistupování k úložišti certifikátů či souborovému systému chybí. Digitální podpis tedy za pomocí Silverlightu nelze vytvořit. Pokud bychom hodnotili možnosti, které nám nabízí Silverlight oproti Flashi, tak bychom mohli vyzdvihnout možnost přečtení souborů z disku uživatele přímo v aplikaci Silverlight. Je
30
zřejmé, že pluginy Flash i Silverlight jsou určeny pro vytváření uživatelského rozhraní či práci s multimédii a ne pro komplexní aplikace, což vytváření digitálního podpisu bezesporu je.
31
Kapitola 7
Java Je zřejmé, že je možné stáhnout spustitelný program napsaný a zkompilovaný pro danou platformu v kterémkoli programovacím jazyce, avšak entropie hostitelských operačních systémů vyselektovala pro tento účel pouze dva jazyky: platformu Java a .NET Framework. Programy vyvinuté na těchto platformách lze spouštět na rozmanitých operačních systémech a architekturách, kde je nainstalováno jejich běhové prostředí. V této kapitole se zabýváme technologií Java. Při studiu jsme se snažili obejít velmi limitující omezení webového prohlížeče, protože webové aplikace běžící v prohlížeči jsou drženy v jeho sandboxu1, který jim nedovolí z bezpečnostních důvodů přistupovat k systémovým zdrojům. To se vztahuje na všechny již zmíněné technologie JavaScriptem začínaje a pluginy Flash a Silverlight konče, a proto se objevily pokusy tato limitující pravidla obejít, ale dostupné varianty umožňují použít prohlížeč pouze jako spouštěč komplexních programů, tedy použít jej pouze jako distribuční médium, kterým se spustitelný kód dostane do systému uživatele. Pokud prohlížeč podporuje Java Plug-in, potom se nemusíme zabývat otázkou druhu prohlížeče, neboť režie programu se dostane ven z pomyslné klece prohlížeče. Java je programovací jazyk založený na myšlence „write once, run anywhere“, čili "napiš jednou, spusť kdekoli". Program napsaný v Javě lze spustit na kterékoli platformě vybavené JVM (Java Virtual Machine, virtuální stroj jazyka Java), ať už jde o Windows, Linux či Mac OS. Java Virtual Machine pomáhá odstínit napsaný programový kód od cílové platformy/architektury. Jde o běhové prostředí pro programy napsané v Javě, tzv. JRE (Java Runtime Enviroment). Základní podmínkou je instalace JVM (JRE) na klientské stanici. Pokud tomu tak je, což je asi u tří čtvrtin všech uživatelů [RIASTATS1], tak jsou k dispozici nástroje pro vytvoření digitálního podpisu založené na této platformě. Jedná se o Java Applets a Java Web Start.
7.1
Java Applets v prohlížečích
Java Applets (applety, aplety) jsou javovské programy, které lze přidat do webových stránek jako součást webové aplikace. Jsou to třídy rozšiřující třídu java.applet.Applet či její swingovou podtřídu java.swing.JApplet. Jejich spuštění umožňuje Java Plug-in technologie, která představuje most mezi webovým prohlížečem, kde jsou applety načteny a JRE (JVM). Java Plug-in také umožňuje pracovat s klasickými COM/ActiveX komponentami používané na platformě Windows. [SUN2] Prohlížeče Internet Explorer, Mozilla Firefox, Google Chrome i Opera Javu podporují, což bylo úspěšně ve všech případech ověřeno2. Podpora Javy se dá měnit v nastavení těchto prohlížečů a případně i v nastavení Java Plug-in ovládacím panelu. V případě, že výše uvedené podmínky jsou korektně splněny, můžeme v prohlížeči používat applety. Dřívější HTML syntaxe pro volání appletu mohla vypadat takto: 1
Sandbox je způsob provozování aplikace, kdy program nemá přístup ke kritickým systémovým zdrojům a je držen v „izolaci“ od systému a ostatních aplikací za účelem ochrany systému a uživatele. 2 Použit test JVM na URL: [kontrolováno 10.5.2010]
32
<APPLET code="Bubbles.class" width="500" height="500"> Java applet that draws animated bubbles.
Tato verze s tagem APPLET je již dnes zastaralá, neboť novější verze HTML využívá pro spouštění appletů HTML tag OBJECT, který poskytuje mnohem více pružnosti i pro využití jiných aplikací, než jen appletů. V HTML specifikaci verze 4.1 (aktuální verze, ale v současné době se usilovně pracuje na verzi 5), kterou vydává konsorcium W3C, se již v roce 1999 objevila náhrada tagu APPLET tagem OBJECT. Výše uvedený kód by dnes měl správně vypadat takto:
A případné argumenty lze předat elementem PARAM. [W3C2] Poté dojde ke spuštění appletu, což má na starost technologie Java Plug-in, která vytvoří pro každý applet pracovní vlákno v instanci JRE. Applet se tedy spustí v již běžící instanci JRE, pokud nežádá např. jinou verzi JRE či jiné parametry JRE. [SUN3]
7.2
Co Java Applety mohou a nemohou
Otázka bezpečnosti je základní otázkou, na kterou je třeba najít odpověď. Jelikož applet se může nacházet na libovolné HTML stránce a po načtení stránky se automaticky spustí, mohlo by dojít ke spuštění škodlivého kódu. Proto se i na applety vztahují bezpečnostní omezení, které proti hrozbám škodlivého softwaru uživatele chrání (sandbox). V zásadě se dá rozdělit pravomoc appletů do dvou skupin podle toho, zda-li jsou applety digitálně podepsány nebo ne. Můžeme mít tedy applety, které nejsou digitálně podepsané vydavatelem. Ty mají značně omezenou množinu funkcí a tyto limity jsou podobné omezením v JavaScriptu, Flashi a Silverlightu. Důsledkem je tedy zejména limitovaná schopnost přístupu na souborový systém (k úložišti certifikátu) a běh v sandboxu, což je pro studované téma digitálního podpisu limitujícím faktorem. Mnohem působivější jsou podepsané applety. Pokud se totiž uživatel rozhodne vydavateli appletu důvěřovat, potom spuštěný applet běží bez jakýchkoli omezení, které platí pro nepodepsané applety a dokonce běží i mimo sandbox. [SUN4] Podepsané applety tedy umožňují spustit v prohlížeči kód, který nemá prakticky žádné omezení a applet může přistupovat k systémovým zdrojům jako je souborový systém, úložiště certifikátů a také může využít plnou sílu svého API a kryptografických knihoven jako je BouncyCastle čítající podporu X.509 a asymetrické kryptografie. [BC1]
33
7.3
OpenOCES
Java Applety jsou velmi silnými hráči na poli webových aplikací a z tohoto důvodu se našly firmy i organizace, které se rozhodly svá řešení (internetbanking, e-goverment) realizovat pomocí této technologie. Jedno z těchto řešení je projekt OpenOCES (OCES je dánská zkratka s českým ekvivalentem "Veřejné certifikáty pro elektronické služby") snažící se o vytvoření komponent pro podporu PKI v Dánsku. Jde o projekt vyvíjený dánskou certifikační autoritou TDC na základě smlouvy s dánským ministerstvem vědy, technologie a inovace (Danish Ministry of Science, Technology and Innovation) z roku 2003. Tato smlouva zavazuje projekt OpenOCES k realizaci tohoto cíle v co nejotevřenějším prostředí, pod open-source licencemi a v souladu s národním i mezinárodním právem a také uznávanými standardy. [OOCES1] Na základě této smlouvy vznikly dílčí projekty z nichž je patrně nejzajímavější OpenSign. OpenSign je kolekce open-source java appletů, jež umožňují digitálně podepsat text a jsou dostupné pod licencí GNU GPL. Na stanicích s nainstalovaným systémem Windows používají Microsoft Crypto API a taktéž umožňují načíst certifikát uživatele přímo ze souboru. Výsledný podpis je ve formátu XMLSignature, což je W3C doporučení pro digitální podpis v značkovacím jazyce XML. To nám zaručuje interoperabilitu mezi různými programy i platformami. Na stránkách OpenOCES je ke stáhnutí nejnovější verze appletu 1.7, avšak doporučuje se používat poslední stabilní verzi 1.6.7. Poslední update stránek byl 21.1.2009, takže by se mohlo zdát, že tento projekt již není příliš aktivní. Pravdou ovšem je, že podle e-mailového sdělení pana Kasper Teglgaard ze dne 14. 4. 2010 ve věci OpenOCES se situace má tak, že projekt je stále naživu a brzy se plánuje vydání další verze. Z programu OpenSign se dá velmi dobře vycházet a lze jej s úspěchem použít pro vytvoření digitálního podpisu. Na oficiálních stránkách OpenOCES je k vyzkoušení funkční konfigurovatelné demo a je jím možno podepsat čistý (ASCII) text. Tato funkcionalita byla bez problému odzkoušena ve všech testovaných prohlížečích1 (i v Safari pro Windows) a lze ji považovat za velice zdařilou, neboť je vizuálně integrovaná s HTML stránkou a v operačním systému Windows bez problémů načte osobní certifikáty z centrálního úložiště (viz příloha č. 7).
7.4
Java Web Start
Jak bylo zmíněno na začátku této kapitoly, platforma Java nabízí mnoho využitelných možností a jednou z nich je Java Web Start (Java WS). Této technologii nebudeme věnovat tolik prostoru jako appletům, protože Java WS poskytuje přinejmenším stejné možnosti jako digitálně podepsaný applet s tím rozdílem, že jde o technologii určenou pro distribuci klasických desktopových aplikací. Hlavní výhoda Javy WS spočívá v tom, že k jejímu spuštění dochází přes internet prakticky z libovolného prohlížeče a systému. Podmínkou je pouze mít nainstalované JRE a prohlížeč umožňující spustit aplikaci v Javě WS. Režie Javy WS se dokonce stará i o vyhledávání novějších verzí programů, takže odpadá složitá aktualizace nainstalovaných programů v počítači. Toto řešení poskytuje robustní základy pro vývoj komplexní podepisovací desktopové aplikace, nicméně s přihlédnutím ke kontextu této práce jde jen o obcházení nedostatečné podpory webového podepisování v prohlížečích. 1
Testovací applet je dostupný na URL: [kontrola 10.5.2010]
34
Kapitola 8
.NET ClickOnce Poslední kapitolou z probíraných řešení je distribuční technologie ClickOnce od firmy Microsoft. ClickOnce má přímo konkurovat řešení Java Web Start od firmy Sun (dnes již Oracle). Schopnosti jsou taktéž velmi podobné, neboť ClickOnce je svázána s platformou .NET, která je podobná Javě. Něco málo o této platformě již bylo zmíněno v kapitole o Silverlightu, který je na technologii .NET postaven. Technologie .NET se váže na .NET Framework, jež tvoří její jádro s širokou paletou knihoven. První verze .NET se objevila ve Visual Studiu .NET 2002. Od operačního systému Windows Vista je .NET Framework součástí systému a i v starších verzích se bez instalace .NET Frameworku neobejdeme, protože mnoho aplikací jej vyžaduje pro svůj chod. Již v roce 2004 byl .NET Framework instalován na zhruba 85 % nově prodaných PC stanicích a do března roku 2005 bylo staženo více než 120 miliónů kopií .NET Framework. Z tohoto můžeme usuzovat, že dnešní pokrytí touto technologií bude na stanicích se systémem Windows nad 50 %. [MSDN3] Nejnovější verze je .NET Framework 4. Při vývoji .NET aplikace můžeme použít kteroukoli z knihoven .NET Frameworku, přičemž nejsme vázáni bezpečnostními omezeními, jelikož jde v podstatě o desktopovou aplikaci. Můžeme proto využít tříd, které jsme v Silverlightu použít nemohli a to zejména třídu System.Security.Cryptography.RSACryptoServiceProvider, která poskytuje metody pro vytvoření digitálního podpisu. Je možné přistupovat k centrálnímu úložišti certifikátu systému Windows. Otázkou, kterou je třeba zodpovědět je, jak velká část uživatelů si bude schopna pomocí svého prohlížeče nainstalovat .NET aplikaci pomocí distribuční technologie ClickOnce. Vyvolání instalačního procesu má na starost plugin webového prohlížeče.
8.1
Internet Explorer
Bylo ověřeno, že Internet Explorer korektně spustil .NET aplikaci distribuovanou technologií ClickOnce (IE verze 6 s .NET Framework 3.5 a IE 8 s instalovaným .NET Framework 4, viz příloha č. 9). Aplikace se nainstalovala úspěšně na stanici a lze ji používat jako klasickou desktopovou aplikaci. Při každém spuštění se kontroluje, zda-li nebyla vydána nová verze a pokud ano, dojde k aktualizaci. Tím, že Internet Explorer je z produkce stejné firmy jako technologie .NET Framework a ClickOnce, byla potvrzena hypotéza o bezproblémové instalaci a používání této aplikace.
8.2
Mozilla Firefox
Microsoft otevřeně proklamuje, že ClickOnce se spustí pouze pokud je otevírán přes prohlížeč Internet Explorer anebo pokud se použije prohlížeč Mozilla Firefox s pluginem Microsoft .NET Framework Assistant. [MS7] Ten je značně rozšířen na Windows instalacích Firefoxu, neboť
35
aktualizace .NET Framework 3.5 SP 1 automaticky (bez vědomí živatele) tento doplněk nainstalovala do Firefoxu. Tento kontroverzní krok měl za následek vlnu znechucení uživatelů Windows a Firefoxu, nicméně účel to splnilo.[WASHP1] Funkčnost doplňku Microsoft .NET Framework Assistant (1.1 a 1.2.1) byla během psaní této bakalářské práce ověřena
8.3
Ostatní prohlížeče
Podle informací Microsoftu a praktického ověřování během vzniku této práce bylo zjištěno, že ostatní prohlížeče dosud nepodporují ClickOnce. Rozšíření pro ostatní prohlížeče ale může být považováno za natolik lukrativní, že jej lze v budoucnu s největší pravděpodobností očekávat.
36
Kapitola 9
Internetové bankovnictví Internetové bankovnictví je jednou z oblastí, kde je velmi důležitá bezpečnost přenášených dat jak na úrovni komunikačního kanálu, tak i na koncové straně. Komunikační kanál na internetu je zpravidla zabezpečen šifrovacím protokolem SSL (Secure Socket Layer), který tak zajišťuje důvěrnost přenášených dat proti čtení třetí strany a umožňuje se autentizovat certifikátem. Nicméně vyvstává otázka, jak zajistit důvěrnost operací na straně klienta. Tím je myšleno, jak se uživatel přihlásí do systému a jaké jsou bezpečnostní mechanismy, které uživateli dovolí provádět (autorizovat) transakce. Přihlášení může být založeno na vícero způsobech. Od jednoduchého přihlášení pomocí uživatelského jména a hesla, přes autentizační kalkulátor až po identifikaci klientským certifikátem. Právě ona třetí zmíněná možnost předpokládá klienta vlastnícího certifikát a zpravidla je tohoto certifikátu později používáno pro schvalování transakcí digitálním podpisem. Jak toto řešení vypadá? V podstatě jsou tři rozšířené způsoby. První z nich spoléhá na Javu, ať již formou appletu (viz příloha č. 1), či Java Web Start (www.fio.cz), druhý vyžaduje mít nainstalovanou desktopovou aplikaci přímo na klientské stanici, v tomto případě je řeč o programech MultiCash či Eltrans, které mají v požadavcích uvedeno pro svůj chod systém Windows a Internet Explorer. Tyto aplikace již nepracují v rámci prohlížeče, neboť se jedná o klasické desktopové aplikace umožňující vzdáleně komunikovat s bankou a spravovat účet. A nakonec třetí skupina sází na kombinací dvou předešlých. Konkrétně jde o dodatečné zásuvné moduly či rozšíření pro internetový prohlížeč, které tvoří most mezi desktopovou aplikací vybavenou také odpovídajícím modulem a webovým prohlížečem. Uživatel si tedy nainstaluje do webového prohlížeče doplněk (MultiCash@Sign), který mu umožní podepisovat platební transakce přímo z něj. Na firemním serveru se nainstaluje do instalace MultiCash plugin MultiCash@Sign a od této chvíle je možné z prohlížeče vybaveným speciálním pluginem digitálně podepisovat (autorizovat) transakce i bez nutnosti mít na klientské stanici nainstalovanou aplikaci MultiCash. Oproti tomu Eltrans@Sign je založen na platformě Java a používá Java Applets, což umožňuje jeho použití v širším spektru prohlížečů (Firefox, Opera) i operačních systémů (Linux, Mac OS). [UNICREDIT1] V práci již byly diskutovány používané technologie. V další části této kapitoly se zaměříme na způsob, jak podepisovací rozšíření fungují. Při použití appletu dojde k jeho spuštění tak, jak bylo uvedeno v kapitole Java Applets, proto tuto kategorii zde nebudeme opětovně rozebírat. Při použití řešení bez Javy však musí být způsob, jak uvnitř HTML stránky spustit a hostit podepisovací aplikaci. K tomuto řešení je použit HTML tag OBJECT, který umožňuje předat řízení aplikaci, která je pro jeho zpracování určena (příloha č. 2, 3 a 4). Například na stránkách České spořitelny a.s. vypadá kód určený pro zásuvný modul MultiCash@Sign webového prohlížeče takto:
Ze syntaxe je zřejmé, že tag OBJECT v souladu s doporučením W3C obsahuje konfigurovatelné parametry a zvýrazněný parametr „type“ vytváří handler, aby prohlížeč předal zpracování tohoto objektu pluginu MultiCash@Sign (viz příloha č. 5). Práce pluginu je tedy založena na shodném principu jako v případě pluginu Flash. Toto rozšíření je schopné digitálně podepisovat transakce, což dále vyžaduje mít na serveru nainstalovaný modul MultiCash@Sign. Obrázek 6: Architektura bankovního systému MultiCash@Sign [OMIKRON1]
38
Kapitola 10
WASP Z předchozích kapitol vyplývá, že vytvoření digitálního podpisu za pomoci webového prohlížeče je náročná operace, která dnes postrádá jednotný standard. Pro řešení tohoto problému je možné využít několik odlišných implementací založených na různém přístupu. Každá implementace je jiná, velký rozdíl (pokud pomineme applety) je konkrétně ve vytváření digitálního podpisu v majoritních prohlížečích Internet Exploreru a Firefoxu. Jednak každý z nich používá jiné úložiště certifikátů a poté i samotné podepisování se liší na úrovni prezentace dat uživateli. S tím je spojená otázka bezpečnosti. Mozilla Firefox totiž uživateli ukáže text, jež uživatel podepisuje. Naproti tomu při digitálním podepisování v Internet Exploreru pomocí CAPICOMu uživatel podepisovaná data nevidí, což je nepříjemné, neboť existuje hrozba, že stránku někdo modifikuje a dá uživateli podepsat záměrně upravená data, např. platební transakci. Tato nejednotná situace existuje prakticky po celou dobu existence webových prohlížečů. Je tedy nasnadě, že existují snahy o sjednocení a standardizaci v této oblasti. Jednou z nich je WASP. WASP (Web Activated Signature Protocol) je návrh, který tuto situaci řeší na úrovni komunikace server – klient. Pracuje tak, že server pošle požadavek na vytvoření digitálního podpisu pomocí XML požadavku (request) a prohlížeč implementující tento protokol zobrazí uživateli dialog s žádostí o podpis. Pro vyvolání této funkcionality bylo rozhodnuto použít handler prohlížeče na úrovní http požadavku a odpovědi, kde se počítá s novým MIME typem (content-type) „application/xbpp+xml“, který prohlížeč příslušně zpracuje. Http požadavek (http request) prohlížeče podporujícího tento protokol vypadá takto: GET /index HTTP/1.1 Host: contract.example.com Accept: text/html; application/xbpp+xml //podporované MIME/content-type
V případě WASP má klient v hlavičce Accept i nový MIME typ „application/xbpp+xml“, aby indikoval, že toto rozšíření podporuje. Xbpp+xml je návrh Xml Browser Protocol Plugin, který by umožňoval využívat širší paletu aplikací. Pokud má klient vyhovující podporu pro zmíněný MIME typ, prohlížeč by mu poslal odpověď (http response) s hlavičkou „content-type“ pro tento nový MIME typ. Toto sestavení odpovědi sestává z vytvoření hashe podepisovaných dat a jejich uložení do sezení (session) na serveru. Poté se odešle XML požadavek s nově představeným MIME typem prohlížeči a ten na danou odpověď serveru reaguje vyvoláním dialogu uživateli. Zobrazený dialog obsahuje informace o tom, co uživatel podepisuje a také o tom, kdo si podpis vyžádal. Prohlížeč podle tohoto návrhu obsahuje rozšíření, které se stará o zpracování tohoto požadavku a odeslání zpět. Celá koncepce se tedy oprošťuje od volání podpisu ze strany klienta, např. z JavaScriptu a předává tuto režii serveru. Výhod, které tento přístup přináší je hned několik. Patrně největší výhoda tohoto přístupu je v tom, že odpadává nutnost mít na straně uživatele nainstalovanou podepisovací aplikaci, různá běhová prostředí s tlustými klienty a používat určitý
39
druh prohlížeče a operační systém (za předpokladu, že prohlížeč by měl přístup k certifikátu, nicméně problematika úložišť certifikátů široce přesahuje rámec této práce, avšak na stránkách webpki.org je řešena i tato problematika pod projektem KeyGen2). Tato potřebná funkcionalita, kterou dnes mají na starost nejrůznější aplikace by byla delegována na prohlížeč za využití dnešních uznávaných a rozšířených standardů, jako je X.509, XML, XML Signature1 a MIME, což je důležité pro univerzálnost a multiplatformní užití.. To uživateli poskytuje značný komfort v podobě mobility, neboť mu stačí mít s sebou (usb) token či kartu pro vytvoření digitálního podpisu. Uživatel tak nepotřebuje více aplikací pro různé instituce, jak je tomu v současné době (které někdy nemohou na jednom počítači pracovat korektně, viz Fio-podpis(java) a MojeBanka od Komerční banky [FIO1]). Tento fakt je velmi významný i pro samotné instituce, neboť ušetří výdaje na vývoj, podporu a údržbu jejich aplikací, přičemž tyto náklady na klasickou desktopovou aplikaci oproti webovému řešení mohou být 3 až 10 krát vyšší. V neposlední řadě bude také splněn požadavek, aby uživatel viděl, co podepisuje. Důvěryhodnost komunikace (šifrování dat) mezi klientem a serverem může spolehlivě zajistit již používaný protokol SSL, další užité technologie jsou dnes užívané standardy. Případná implementace WASP by přinesla do oblasti webového podepisování standard, jako dnes poskytuje S/MIME v e-mailové komunikaci. Přes všechny výše zmíněné výhody zatím neexistuje jediný prohlížeč, který by se rozhodl toto schéma implementovat, ačkoli by implementace WASP zvětšila velikost distribuovaného prohlížeče jen o cca 200 KB. Podle e-mailového sdělení Anderse Rundgrena ze dne 9. 4. 2010, který výrobce webových prohlížečů s touto výzvou oslovil, zde není žádný pokrok. Lze tedy jen velmi těžko usuzovat, zda-li se vůbec dočkáme tohoto, nebo obdobného řešení, které by pomohlo vyřešit problémy digitálního podepisování, resp. webového podepisování a přineslo všechny výše zmíněné výhody.[WEBPKI1] [WEBPKI2] [WEBPKI3]
1
Doporučení konsorcia W3C pro práci s digitálními podpisy ve formátu XML, specifikace tohoto dokumentu je dostupná online na URL: [kontrolováno 10.5.2010]
40
Kapitola 11
Závěr Přes vyspělost dnešních webových technologií neexistuje žádný standard, který by problematiku webových prohlížečů v oblasti webového podepisování řešil tak, jak to S/MIME řeší v elektronické poště. Proto se používají dnes takové dostupné nástroje, které byly předmětem studia předkládané práce. Na základě prvotního prozkoumání problematiky byla vyslovena hypotéza, že řešení digitálního podpisu vystavěné na CAPICOMu pro uživatele Internet Exploreru a funkce crypto.signText() pro uživatele Firefoxu by mohlo situaci s úspěchem pro většinu uživatelů řešit. Tato hypotéza se ukazuje jako pravdivá, neboť řešení postavené na CAPICOMu jsou opravdu velmi rozšířené (např. e-volby v Estonsku) a funkce crypto.signText() je u uživatelů Firefoxu spolehlivá. Další, v pořadí druhou hypotézou bylo, že pro univerzálnější a robustnější aplikace by byla nejvhodnější technologie založená na platformě Java, resp. Java Applets. Applety jsou prakticky používány po dlouhou dobu, za kterou si našly své místo na webu. Je však s podivem, jak málo jsou dnes rozšířené oproti pluginu Flash, jež je však stvořen primárně pro práci s multimediálním obsahem. Oproti Flashi applety poskytují mnohem více pružnosti pro vytváření webových aplikací srovnatelných s desktopovými, to se týče zejména složitějších programů, což podepisovací (kryptografické) aplikace bezesporu jsou. Nasazení appletů, především v internetbankingu, opět potvrzuje pravdivost druhé hypotézy. Jako příklad veřejně dostupného (open-source) řešení postaveného na Java Applets a aplikovatelného na náš konkrétní případ užití bychom mohli uvést iniciativu OpenOCES, která je funkční a v práci se podařilo prokázat, že jako jediná ze všech zkoumaných technologií byla úspěšně otestována na všech diskutovaných prohlížečích. Na tuto technologii se tedy můžeme spolehnout u širokého procenta uživatelů, napříč všech dnes dostupných prohlížečů i operačních systémů, kteří mají nainstalovanou Java Virtual Machine. Jde však o složitější aplikaci oproti jednoduchému skriptovému řešení CAPICOMu a crypto.signText(), které je navíc velmi jednoduše implementovatelné za extrémně krátkou dobu. Co se týče technologií Flash a Silverlight, ty jsou primárně určeny pro práci s grafikou a tudíž jsou pro účel vytvoření digitálního podpisu obtížně použitelné. Jako řešení současné situace, které pokryje nějvětší část uživatelů, lze doporučit kombinaci těchto tří technologií: ActiveX (CAPICOM a případná nová verze postavená na platformě .NET), JavaScript (crypto.signText()) a Java Applets. Distribuční technologie ClickOnce či JavaWebStart jsou pro tento účel také použitelné, avšak je nutné si uvědomit, že jde o pouhé obcházení chybějící funkcionality prohlížeče. Obdobně se snaží toto slabé místo webu řešit internetové bankovnictví se svými proprietárními pluginy a monoplatformními aplikacemi. Z uvedených důvodů Anders Rundgren vyvíjí ambiciózní projekt WASP, který přináší řadu dobrých nápadů postavených na současně dostupných a standardizovaných technologiích. Tento projekt má pevné formální základy a nastiňuje komplexní řešení webového podepisování, které můžeme použít. Po studiu a praktickém ověřování problematiky webového podepisování se iniciativa WASP jeví (za předpokladu jejího prosazení) jako nejlepší, neboť představuje skutečné
41
řešení dnešního stavu. Je proto jistě užitečné zasadit se o propagaci projektu WASP, přinejmenším formou této práce. Je ovšem otázkou, jak se bude problematika digitálního podpisu vyvíjet v budoucnu. Je známo, že v Estonsku, které je známo svým vyspělým e-govermentem, se již několikrát konaly volby, kde mohli občané hlasovat přes internet. Z osobního sdělení Poradce estonského Národního volebního výboru pana Priita Vinkela (26.4.2010) vyplývá, že role prohlížeče je zatím minimální, a to právě kvůli neuspokojivé podpoře digitálního podepisování. Současně bylo sděleno, že p. Vinkel očekává v budoucnu zánik současných řešení (CAPICOM) ve prospěch jednoúčelové podepisovací desktopové aplikace. Na základě řešené problematiky, z literárních údajů a z osobních zkušeností se přikláním k iniciativě pana Anderse Rundgrena, která se jeví natolik promyšlená, že důvěřuji reálnému úspěchu jím představeném protokolu WASP.
42
Literatura [LUPA1] PATRICK, Z., Historie českého internetu. [online], Lupa.cz , 2003, URL: ,[kontrolováno 10.5.2010]. [TECHCRUNCH] SCHONFELD, E., ComScore: Internet Population Passes One Billion; Top 15 Countries. [online], TechCrunch.com , 21. 3. 2009, URL: ,[kontrolováno 10.5.2010]. [UVT] BARTOŠEK, M., Historie ÚVT a výpočetní techniky na Masarykově univerzitě v Brně. [online], Ústav výpočetní techniky , květen 2004, URL: ,[kontrolováno 10.5.2010]. [CSU] SPILKOVÁ, J. A KOLEKTIV, Využívání informačních a komunikačních technologií v domácnostech a mezi jednotlivci v roce 2009. [online], Český statistický úřad , 2009, URL: , [kontrolováno 10.5.2010]. [INET] RADA, V., Internet v praxi: Komunální volby v Estonsku, dočkáme se i u nás?. [online], Internet pro všechny , 13.1.2006, URL: , [kontrolováno 10.5.2010]. [W3C1] CONOLLY, D - CAILLIAU R., A Little History of the World Wide Web. [online], World Wide Web Consortium , 1995, revize 2000, 2006, URL: , [kontrolováno 10.5.2010]. [RIA] VÁVRA, J., Rámce pro vývoj webových aplikací. [online], 2008, URL: ,[kontrolováno 10.5.2010]. [MOZ1] PŘISPĚVATELÉ MOZZILA.CZ, Zásuvné moduly (pluginy). [online], Mozilla.cz , URL: ,[kontrolováno 10.5.2010]. [MOZ2] PŘISPĚVATELÉ MOZILLA.ORG, Doplňky Firefoxu. [online], Mozilla.org , URL: ,[kontrolováno 10.5.2010]. [ENEC] PŘÍSPĚVATELÉ VVK.EE, Internet Voting in Estonia. [online], Estonian National Electoral Committee , URL: ,[kontrolováno 10.5.2010]. [UVT2] KOUŘIL, D., Certifikáty veřejných klíčů. [online], Ústav výpočetní techniky MU , poslední změna 22.4.2010, URL: , [kontrolováno 10.5.2010]. [IETF1] HOUSLEY, R. A KOLEKTIV, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. [online], The Internet Engineering Task Force (IETF) , duben 2002, URL: ,[kontrolováno 10.5.2010]. [DOST] DOSTÁLEK, L. - VOHNOUTOVÁ, M., Velký průvodce infrastrukturou PKI a technologií elektronického podpisu. Brno,Computer Press, 2006, 528, ISBN 80-251-0828-7, strana 21, 27,30. [CACERT1] HILDEBRAND, R. A PŘISPĚVATELÉ WIKI.CACERT.ORG, HowTo: Import the CAcert Root Certificate into Client Software. [online], cacert.org , poslední změna 26.12.2009, URL: ,[kontrolováno 10.5.2010].
43
[PROHL] MIKULA, J., Statistiky prohlížečů - ČR březen 2010: Internet Explorer ztratil přes procento. [online], Prohlizece.info , 14.4.2010, URL: ,[kontrolováno 10.5.2010]. [MS1] PŘISPĚVATELÉ MICROSOFT.COM, Description of Internet Explorer Support for Netscape-Style Plug-ins. [online], microsoft.com , poslední změna 31.1.2007, URL: ,[kontrolováno 10.5.2010]. [MS2] PŘISPĚVATELÉ MICROSOFT.COM, Windows History Internet Explorer History. [online], Microsoft , 30.6.2003, URL: , [kontrolováno 10.5.2010]. [WIKI1] PŘISPĚVATELÉ WIKIPEDIE, Internet Explorer. [online], Wikipedia, The Free Encyclopedia , poslední změna 8.5.2010, URL: , [kontrolováno 10.5.2010]. [MOZ3] PŘISPĚVATELÉ MOZILLA.ORG, History of the Mozilla Project. [online], Mozilla Project , URL: ,[kontrolováno 10,5,2010]. [MOZ4] PŘISPĚVATELÉ MOZILLA.COM, Mozilla at a Glance. [online], Mozilla Project , URL: ,[kontrolováno 10.5.2010]. [GOO1] PŘISPĚVATELÉ GOOGLE CHROME, NPAPI Plugins. [online], Google , URL: ,[kontrolováno 10.5.2010]. [OP1] PŘISPĚVATELÉ WIKI.OPERACESKY.NET, Historie prohlížeče Opera. [online], Opera česky , URL: ,[kontrolováno 10.5.2010]. [OREILLY1] CHAMPEON, S., JavaScript: How Did We Get Here?. [online], 4.6.2010, URL: ,[kontrolováno 10.5.2010]. [WIKI2] PŘISPĚVATELÉ WIKIPEDIE, ECMAScript. [online], Wikipedia, The Free Encyclopedia , poslední změna 9.3.2010, URL: , [kontrolováno 10.5.2010]. [MS3] MICROSOFT, JScript Language Reference (Windows Scripting - JScript). [online], Microsoft , URL: , [kontrolováno 10.5.2010]. [WIKI3] PŘISPĚVATELÉ WIKIPEDIE, Mozilla Firefox. [online], Wikipedia, The Free Encyclopedia , poslední změna 10.5.2010, URL: , [kontrolováno 10.5.2010]. [MOZ5] PŘISPĚVATELÉ MOZILLA.ORG, MS2GER, JavaScript crypto. [online], Mozilla.org , poslední změna 23.4.2010, URL: , [kontrolováno 10.5.2010]. [SUN1] PŘISPĚVATELÉ DOCS.SUN.COM, Signing Text from JavaScript. [online], Sun , poslední změna 7.9.1998, URL: , [kontrolováno 10.5.2010]. [MOZ6] PŘISPĚVATELÉ MOZILLA.ORG, RELYEA, PKCS11 FAQ. [online], Mozilla , poslední změna 13.7.2007, URL: ,[kontrolováno 10.5.2010]. [CAT1] PETERIS KRUMINS, Code Reuse in Google Chrome Browser. [online], 5.9.2008, URL: ,[kontrolováno 10.5.2010].
44
[ROOT1] DAVID MAJDA, V8: JavaScript uvnitř Google Chrome. [online], root.cz , 22.1.2009, URL: ,[kontrolováno 10.5.2010]. [GOO2] UŽIVATELÉ GOOGLE CHROME, Support for x.509 digital certificates?. [online], 29.11.2009, URL: ,[kontrolováno 10.5.2010]. [GOO3] UŽIVATELÉ CHROMIA, SLUSHPUPIE, Client SSL Certificate Support. [online], 2.9.2008, URL: , [kontrolováno 10.5.2010]. [OP2] OPERA SOFTWARE ASA, ECMAScript support in Opera. [online], URL: ,[kontrolováno 10.5.2010]. [MS4] PŘISPĚVATELÉ MSDN.MICROSOFT.COM, Introduction to ActiveX Controls. [online], URL: ,[kontrolováno 10.5.2010]. [MOZ7] PŘISPĚVATELÉ MOZILLA.COM, ADMIN A KOLEKTIV, ActiveX. [online], poslední změna 10.2.2010, URL: ,[kontrolováno 10.5.2010]. [GOO4] , FAQ for web developers. [online], Google , URL: ,[kontrolováno 10.5.2010]. [MSDN1] ALEJANDRO CAMPOS MAGENCIO, CAPICOM support on Windows Vista. [online], 19.10.2009, URL: ,[kontrolováno 10.5.2010]. [MS5] MICROSOFT, CAPICOM Reference. [online], 22.4.2010, URL: ,[kontrolováno ]. [LIZ1] DIMCE KUZMANOV, XSign & XEnc ActiveX XML Signature and Encryption Components. [online], URL: ,[kontrolováno 10.5.2010]. [MOZ8] MOZILLA, Doplňky Firefoxu. [online], URL: ,[kontrolováno 10.5.2010]. [OP3] OPERA SOFTWARE ASA, ActiveX and VBScript support in Opera. [online], URL: ,[kontrolováno 10.5.2010]. [NEPT1] PŘISPĚVATELÉ NEPTUN, NEPTUN. [online], URL: ,[kontrolováno 10.5.2010]. [ADOBE1] PŘISPĚVATELÉ ADOBE, Flash content reaches 99% of Internet viewers. [online], URL: ,[kontrolováno 10.5.2010]. [WIKI4] PŘISPĚVATELÉ WIKIPEDIA, Internet media type. [online], Wikipedia, The Free Encyclopedia , poslední změna 8.5.2010, URL: , [kontrolováno 10.5.2010]. [ADOBE2] PŘISPĚVATELÉ ADOBE, Example: Using the external API with an ActiveX container. [online], URL: ,[kontrolováno 10.5.2010]. [PEARLS1] SREENIVAS, Flex talking to a ActiveX (using ExternalInterface). [online], 22.1.2008, URL: , [kontrolováno 10.5.2010].
45
[ADOBE3] PŘISPĚVATELÉ ADOBE, FileReference. [online], 16.2.2009, URL: ,[kontrolováno 10.5.2010]. [GOO5] PŘISPĚVATELÉ AS3CRYPTO, HENRIT A KOLEKTIV, as3crypto. [online], URL: ,[kontrolováno 5.10.2010]. [SILV1] SILVERLIGHT TEAM, Microsoft Silverlight Recap at NAB 2010. [online], 8.4.2010, URL: , [kontrolováno 10.5.2010]. [MS6] MICROSOFT, Silverlight Application Security Model. [online], URL: ,[kontrolováno 10.5.2010]. [MSDN2] PAPA, J. - KINNEY, A., Silverlight 4 Overview. [online], 15.4.2010, URL: ,[kontrolováno 10.5.2010]. [RIASTATS1] PŘISPĚVATELÉ RIASTATS.COM, Rich Internet Application Statistics. [online], URL: ,[kontrolováno 10.5.2010]. [SUN2] PŘISPĚVATELÉ JAVA.SUN.COM, Java Plug-in Technology. [online], URL: ,[kontrolováno 10.5.2010]. [W3C2] RAGGETT, D. A KOLEKTIV, HTML 4.01 Specification, Objects, Images, and Applets. [online], 24.12.1999, URL: , [kontrolováno 10.5.2010]. [SUN3] PŘISPĚVATELÉ JAVA.SUN.COM, Applet's Execution Environment. [online], URL: , [kontrolováno 10.5.2010]. [SUN4] PŘISPĚVATELÉ JAVA.SUN.COM, What Applets Can and Cannot Do. [online], URL: ,[kontrolováno 10.5.2010]. [BC1] PŘÍSPĚVATELÉ BOUNCY CASTLE, The Legion of the Bouncy Castle. [online], URL: ,[kontrolováno 10.5.2010]. [OOCES1] PŘISPĚVATELÉ OPENOCES, About the OpenOCES Project. [online], URL: ,[kontrolováno 10.5.2010]. [MSDN3] WILTAMUTH, S., .NET Framework penetration. [online], URL: ,[kontrolováno 10.5.2010]. [MS7] MICROSOFT, Server and Client Configuration Issues in ClickOnce Deployments. [online], URL: ,[kontrolováno 10.5.2010]. [WASHP1] KREBS, B., Microsoft Update Quietly Installs Firefox Extension. [online], 29.5.2009, URL: , [kontrolováno ]. [UNICREDIT1] UNICREDIT BANK CZECH REPUBLIC, A.S., Typy alternativních prohlížečů. [online], URL: ,[kontrolováno 10.5.2010].
46
[OMIKRON1] OMIKRON SYSTEMHAUS GMBH & CO. KG, MultiCash@Sign. [online], URL: ,[kontrolováno 10.5.2010]. [FIO1] FIO, Manuál k používání a ovládání aplikace Fio-podpis(JWS). [online], 23.10.2009, strana 5, URL: ,[kontrolováno 10.5.2010]. [WEBPKI1] RUNDGREN, A., WASP - Web Activated Signature Protocol. [online], URL: ,[kontrolováno 10.5.2010]. [WEBPKI2] RUNDGREN, A., Invoking Browser-based Application Extensions. [online], WebPKI.org , 10.8.2008, URL: ,[kontrolováno 10.5.2010]. [WEBPKI3] RUNDGREN, A., WASP Mini Tutorial. [online], WebPKI.org , 2007, URL: ,[kontrolováno 10.5.2010].
47
Přílohy Příloha 1: Java Applet v internetovém bankovnictví
48
Příloha 2: Hlášení chybějícího pluginu pro práci se systémem MultiCash@Sign v prohlížeči Mozilla Firefox
Příloha 3: Instalace pluginu MultiCash@Sign do prohlížeče Opera
49
Příloha 4: Použití pluginu MultiCash@Sign
50
Příloha 5: Nastavení zpracování typu MIME v prohlížeči Opera
Příloha 6: Volání funkce crypto.signText() ve Firefoxu
51
Příloha 7: OpenOCES applet
Příloha 8: CAPICOM v Internet Exploreru
52
Příloha 9: Ukázka spouštění aplikace přes distribuční technologii ClickOnce v Internet Exploreru
