Hlavní navigace

XML, odpovědnost

Připojuji se k prosbě pana Poslušného co se týká odpovědi na můj původní dotaz. Domnívám se, že zde dochází k nepochopení základních principů asymetrické kryptografie. Ve své odpovědi píšete, že banka zodpovídá za použité bezpečnostní řešení. OK, banka nabizí elektronické bankovnictví zabezpečené asymetrickou kryptografií zřejmě X.509, ale bez jakékoli dokumentace. Klient je nucen používat software banky (JavaApplety), které však pro klienta bezpečné nejsou, protože nad nimi nemá kontrolu. Klient neví, co tyto JavaApplety dělají. Pokud banka prohlásí, že pouze podepisují dispozice, které si klient přeje podepsat, je to tvrzení, které není doložitelné. Klient tomu může věřit, ale nemusí. Pokud se rozhodne tomu věřit, nastává situace prakticky ekvivalentní tomu napodepisování bianco dispozic, o kterém se zmiňuji. Klient se totiž nemůže přesvědčit, že ony JavaApplety dělají opravdu jen to co mají. Třeba z důvodu "ochrany klienta" odesílají soukromý klíč klienta do "bezpečného uložiště" v Redmondu nebo do banky. Nevím, pravděpodobně tomu tak není, ale to je právě ono - můžeme se o tom jen dohadovat, nemůžeme se o tom přesvědčit. Naproti tomu kdyby existovala dokumentace jak provést třeba příkaz k úhradě, mohl by se klient rozhodnout, zda využije software nabízený bankou (JavaApplet), nebo zda nabízenému software věřit nebude, napíše si příkaz k úhradě ve svém oblíbeném textovém editoru, podepíše jej svým oblíbeným kryptografickým softwarem a odešle do banky svým oblíbeným prohlížečem, e-mail klientem apod. Tak jak to má např. udělané Ministerstvo financí pro daňová přiznání k DPH. Vytvoří se XML soubor (s daňovým přiznáním, s příkazem k úhradě), dále se podepíše (programem dle volby klienta) a postne webovým prohlížečem na určitou adresu (https://netbanka.cz/input), třeba.

Asi namítnete, že o toto klienti nemají zájem, je to pro ně příliš složité a nikdo by to nepoužíval. To však není pravda a můžete si dovodit z této diskuse, že by to používal minimálně pan Poslušný a já, jistě i další. Dokonce si troufám tvrdit, že by kvůli tomu Živnostenská banka získala další klienty z řad těch více technicky zaměřených či těch, kterým opravdu na zabezpečení záleží. A přitom by to nikterak neomezilo ty klienty, kteří bance zcela důvěřují a chtějí použít JavaApplety banky, které by udělaly naprosto totéž. Stačilo by to jen zdokumentovat.

Dále píšete, že klient má výraznou možnost ovlivnit bezpečnost správou přístupových kódů a zabezpečením počítače. Je zcela zjevné, že klient si musí svůj soukromý klíč chránit. Sám si své klíče samozřejmě chráním. Dokonce si je chráním natolik, že je odmítám svěřit JavaAppletu, o kterém nic nevím a z tohoto důvodu také Netbanku nepoužívám. Pokud banka obdrží dispozici podepsanou soukromým klíčem klienta, pochopitelně nebude už dále nic zkoumat, považuje dispozici za ověřenou. Je to opravdu věcí klienta, jak si zabezpečí svůj počítač a jak si bude chránit svůj klíč. Banka s tím nemůže nic dělat.

Pokusím se to ještě jednou trochu shrnout (budu v tomto příkladu používat program OpenSSL, neboť sám tomuto programu zcela důvěřuji a je k dispozici se zdrojovými kódy a každý si tedy může ověřit, co ten program skutečně dělá):

1 - Banka specifikuje, jak má vypadat žádost o certifikát. Klient si pomocí OpenSSL či čehokoli jinéhu vygeneruje žádost o certifikát a předloží ho bance k podepsání. NEBO udělá totéž za použití JavaAppletů klikáním v prohlížeči.

2 - Klient si napíše v textovém editoru příkaz k úhradě, podepíše ho pomocí OpenSSL, vytvoří PKCS7 strukturu a tuto postne na https://netbanka.cz/input NEBO udělá totéž za použití JavaAppletů klikáním v prohlížeči.

3 - Klient si chce prohlédnout svůj vypis z účtu - stahne si wgetem čí čímkoli jiným z adresy https://netbanka.cz/vypisy/cislo_klienta/vypis.pem, pomocí OpenSSL ho dešifruje a prohlédne si ho. NEBO udělá totéž za použití JavaAppletů klikáním v prohlížeči.

atd.

Přičemž - bezpečnost celého systému není pro banku ani pro klienta nikterak snížena.

Omlouvám se za poněkud delší formulaci, ale snažím se to vysvětlit co nejvíce polopaticky, aby byl základní princip pochopen. Nikde v České republice jsem se zatím nesetkal s tím (až na velmi málo výjímek, které se bohužel netýkají bank), že by byl systém komunikace popsán a že by klient věděl co vlastně dělá. Nezlobte se na mě, ale jestliže soukromý klíč klienta si čtou JavaApplety, byť třeba 3x podepsané VeriSignem a spol., klient si nemůže být jist, co se s jeho soukromým klíčem děje.

Velice si vážím toho, že zde odpovídáte na dotazy nevyhýbavě a cítím, že je zde jakási šance pochopení situace a že se ŽB stane první bankou s opravdu bezpečnou komunikací.
26. 3. 2004 8:49

Odpověď

Vážený pane Vejsado,
děkuji Vám za detailní rozpracování Vašeho dotazu. Vámi popsaný koncept, založený na zabezpečené datové výměně ve formátu XML je zřejmý, vč. možných výhod, které toto řešení přináší, nicméně v této chvíli je zcela odlišný od směru, kterým Živnostenská banka internetové bankovnictví vyvíjí. NetBanka je zabezpečena pro komunikaci použitím šifrování SSL s délkou klíče 128 bitů (serverový certifikát od firmy VeriSign), pro autentizaci jsou použity certifikáty v souladu se standardem PKCS#12 a dále je uplatněn princip user/password. Veškeré platební operace jsou zabezpečeny použitím digitálního podpisu. Vše v souladu se standardem X509, verze 3.
Java Applety jsou podepsané, uživatel si sám může stanovit, zda bude důvěřovat pouze podepsaným nebo všem.
Jistě máte pravdu, že obsahu věřit můžete, ale také nemusíte. Platí ale také obecný předpoklad, že vztah klienta a banky by měl být založen na vzájemné důvěře; banka si v žádném případě nemůže dovolit poskytnout nějaké nedůvěryhodné či neověřené řešení služeb (a nemusí se jednat pouze o internetové bankovnictví, ale např. také o hotovostní operace, ochranu osobních údajů, apod.). Pokud bychom zvažovali odlišné řešení zabezpečení jako alternativu ke stávajícímu způsobu, nezávislé na Java Appletech, bude se pravděpodobně jednat o nějaké formě jednorázových hesel.
Jednou z variant, kterou budeme pro ochranu certifikátů a privátních klíčů moci v blízké době nabídnout, je použití USB tokenů či čipových karet.
Jan Smítek (Poradce pro přímé bankovnictví)
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).