pozor na to, že (viz příručka, verze 1.1., str. 4):
"Práce s úložištěm certifikátů na MacOS není dostupná, protože tento operační systém nedisponuje potřebným rozhraním".
Nejde o design jednoho okna, ale o celkový přístup k práci s certifikáty a hlavně soukromými klíči, v samotné aplikaci i v celé dokumentaci. Dovolím si to trochu zrekapitulovat:
5.8.2014 je NEN spuštěn do zkušebního provozu a veškerá jeho dokumentace, včetně všech příkladů v příručkách, hovoří jen o variantě načtení soukromého klíče (a certifikátu) ze souboru. O možnosti využít systémové úložiště je malá poznámka v jedné z příruček (že by to v principu mělo jít, viz předposlední obrázek v článku) - ale žádné informace o tom, co je třeba udělat, aby to skutečně šlo. Ani žádné informace o bezpečnosti, riziku atd.
7.8.2014 posílám dotaz do NENu, proč propagují pouze řešení "se souborem" a zda si uvědomují jeho bezpečnostní aspekty, jak je to s podporou ostatních variant uložení soukromého klíče atd.
12.8.2014 vychází nová verze příručky o práci s certifikáty, která již podrobněji mluví o možnosti využít systémové úložiště a (odkazem na nový návod) popisuje, co je třeba udělat, aby to šlo. Stále však prezentuje variantu "se souborem" jako výchozí. Původní verze příručky o práci s certifikáty se stává nedostupnou. Ostatní přiručky zůstávají beze změny a stále propagují pouze variantu "ze souboru".
14.8.2014 dostávám odpověď na svůj dotaz, ze které z článku cituji.
Postavit aplikaci pro veřejné zakázky na této technologii a v nereálně krátkém (na celý vývoj) termínu bude jen další průšvih, ovšem tak drahý, že se to bude muset protlačit silou. Vymyslíme problém a hledáme firmu, která dodá řešení, cena je jediné relevantní kritérium.
Kdyby takhle mělo vzniknout kladivo, tak by stát vypsal výběrko na "nástroj pro zatloukání hřebíků", přičemž by nebylo jasné, jak velkých, ani jakého tvaru (ani jestli to nejsou náhodou šrouby), rozhodovalo by se podle ceny a účastnit by se směly jen certifikované firmy s berňákem doložitelnými dostatečnými zkušenostmi se zatloukáním.
Promiňte mi to, ale nemůžu s vámi souhlasit. Asymetrická kryptografie má poměrně jasná pravidla. Máte soukromou část, která má zůstat vždy a za všech okolností soukromá. A pak máte veřejnou část, kterou si troubíte do světa dle libosti. Pokud by možnost podepisování ze souboru uživatel, tedy spíš správce, musel explicitně povolit předtím, než bude vůbec nabídnuta jako nouzová možnost z upozorněním na možné důsledky, neřeknu. Tohle ale očividně není ta varianta. Místo, aby učili svoje uživatele bezpečnému zacházení, usnadňují si práci podobnými postupy. Primární přístup musí být vždy přes token a autor software by si toho měl být náležitě vědom a v produktu to propagovat. Ostatní obstojí jako nouzové varianty. Ale potom patří někam do bočního poradce při potížích, ne do hlavní nabídky na první pozici. To je prostě naprosto špatně.
Jak já jsem se těšil na to, až bude centrální místo pro všechny veřejné zakázky. A ono se to má spouštět v takovéto podobě?
Kdo dělal zadávací projekt, že si nevymínil základní požadavky? Například ve státech kolem nás a občas i v některých českých úřadech či městech je snaha přejít na Linux. Tímto je definitivně rozhodnuto, že ne?
Já jsem jednatel pidi s.r.o., jež shodou okolností má mezi zákazníky i příspěvkové organizace vypisující výběrová řízení. A Windows vůbec nepoužívám, na jednom jediném notebooku jsem měl jakési OEM a přeinstaloval. Zase konečná?
Moonlight jsem několikrát v minulosti zkusil nainstalovat a nikdy jsem přes to nespustil ani primitivní webové aplikace. Nevěřím, že v tom lze cokoliv multiplatformně vyvíjet, v současnosti je to naštěstí mrtvá technologie. Jak mohl kdokoliv něco takového použít na blbost jako frontend aplikace, jež zásadně ovlivní nároky na sw u desítek tisíc organizací? To snad ani nemůže být lidská blbost, ale záměr.
Pokud byste nepovolil použití klíče ze souboru, nepodepíšete nic například na Linuxu, protože tam prostě systémové úložiště certifikátů neexistuje. A z Java Appletů byste v takovém případě dlouho nic nepodepsal ani na 64bitových Windows, protože v Javě od Sunu/Oracle prostě dlouho chyběla 64bitová komponenta pro přístup do systémového úložiště certifikátů.
On je to v současné době dost zamotaný problém. Pro uživatele je nejjednodušší, když se jedná o webovou aplikaci – zvlášť když s tím pracují třeba jednou za rok. Zároveň webová aplikace nejlíp splňuje požadavky na přístupnost a nezávislost na konkrétním prostředí. Jenže s technologií, která je přímo dostupná v dnešních webových prohlížečích, nejde elektronický podpis ze systémového úložiště udělat.
Proto se používají pluginy do prohlížečů. Dříve to byly Active.X pouze pro MSIE, to už naštěstí máme za sebou. Dnes se k tomu používá Java, nebo jak je vidět, někde také Silverlight. Přičemž i s tou Javou je to čím dál horší, podíl prohlížečů, kde je dostupná Java, se pravděpodobně zmenšuje – kvůli neustálým změnám ze strany Oraclu, kvůli dříve nalezeným bezpečnostním chybám, i kvůli změnám v prohlížečích. A i z té Javy se dostanete do systémového úložiště jen na Windows a Mac, a např. když má uživatel víc stejně pojmenovaných certifikátů, vidíte jen jeden náhodně vybraný (protože se v Javě certifikáty vybírají podle jména). Takže i tohle je na hraně použitelnosti pro produkční nasazení. A i když umíte přistupovat k systémovému úložišti, potřebujete spolupráci i na druhé straně, tj. aby ovladač čtečky čipových karet nebo USB tokenu uměl certifikáty zpřístupnit pomocí systémového úložiště. Když si dáte všechny tyhle podmínky dohromady, vyjde vám z toho, že pokud chcete umožnit podepsat co nejširšímu okruhu lidí, je nutné povolit použití i privátního klíče ze souboru.
Samozřejmě by bylo hezké, kdyby komponenta pro elektronický podpis byla rovnou běžnou součástí prohlížečů a autoři webových aplikací to nemuseli řešit pomocí pluginů. Ale tak to prostě dneska není.
Pan Peterka sice upozornuje, ze reseni je technicky zavisle na technologii Silverlight ktera ma byt udajne nepodporovana od roku 2021 (coz je porad slusny vyhled), ale to se jeste muze zmenit. V dnesni dobe lze tezko o necem rict, ze to prezije dele nez par let. Stejne tak muze prestat existovat i Adobe Reader.
Tento priklad ukazuje, ze na vsechno jen prohlizec nestaci. Pouziti pluginovych technologii jako Silverlight nebo Flash je k tomuto ucelu take nevhodne, takze zbyva jen klasicka desktopova aplikace. Tu snad dnes napsat tak aby fungovala na vice platformach (Qt, Mono/.NET) nemuze byt takovy problem, kdyz to dokazali i ruzne open source projekty. A tady to pry stalo pres 200 mega. Javu na klientu nepocitam, protoze ta je z hlediska bezpecnosti uz proverena na neschopnost dodat alespon trochu kvalitni produkt.
Je správný předpoklad, že když stát tohle může dělat i přes příslušné paragrafy v TZ, projde takové sbírání kvalifikovaných certifikátů i soukromůmu subjektu? Zrovna včera jsem v hospodě slyšel chlapíka, co se kasal, že stačilo o na e-shopu změnil přihlašovací jména na e-maily a hned má nový příjem z prodeje přístupových údajů k freemailovým účtům mafii a "bezpečnostním" složkám. S kvalifikovanýma certfikátama by to mohl být fakt solidní vývar ;)
Možná proto, že poptávka ani specifikace podobného produktu žádný z ouřadů ještě nevyplodil, i když by jej očividně téměř jakákoliv agenda pracující s elektornickým podpisem potřebovala. Prostě plugin, který dostane dokument a k němu instrukci, že to chci podepsat. A kam má poslat výsledek. Místo jednoho důvěryhodného programu tu budeme mít plugin pro každou aplikaci zvlášť, do které vždycky nalijeme to nejcitlivější, co v počítači najdeme. Geniální. I když chápu, že pro izolovaný projekt s přiklepnutým rozpočtem je to rozumnější varianta. Ptám se jen, proč eGoverment nepožaduje bezpečné nástroje pro stavbu dalších systému na ní? To ještě nikoho z vlády nenapadlo, že ten nástroj by sám o sobě žádnou agendu neřešil, ale ostatní agendy by ho potom mohly přepoužívat? S trochou štěstí by mohl certifikovat i víc dodavatelů.
Jenze jde o tak okrajovy problem, ze to dodavatele prohlizecu nezajima.
Podivejte se na slavne HTML5, tam uz je ted jasne ze napriklad nedojde ke shode v podporovanych formatech videa. Jak uz tu psal nekdo jinde, HTML5 je strasny paskvil, ktery stejne nikdy nedojde do finalni podoby.
Problem je, ze z prohlizece se stava jakasi "modla" vseho. Pritom staci napsat aplikaci k tomu ucelu zhotovenou.
Navíc to, co dodavatele prohlížečů zajímá, a co jsou reálné problémy webu, nejsou úplně ty samé množiny.
S HTML5 se hlavně zvolil ten úplně nejhorší způsob implementace - místo aby to byl modulární systém a bylo možné poskytnout kód pro prohlížeč, který danou funkci podporuje, i zástupný kód pro ostatní (jako např. tagy script
a noscript
), je všechno namatlané v jednom standardu, který nikdo neimplementuje celý a ani se s tím nepočítá. Takže jsme se obloukem vrátili do doby NN 4 a MSIE 4, resp. MSIE 5.5. Akorát už se weby neoptimalizují pro MSIE, ale pro svatou trojice MSIE+FF+Chrome.
Napsat aplikaci, která půjde z webu spustit co největšímu množství uživatelů, to dnes znamená jedině Javu. Jenže proti použitelnosti Java Pluginu bojují bok po boku tvůrci prohlížečů i Oracle. Google postupně do Chrome tlačí své Active.X 2.0, totiž Pepper...
Ta aplikace nemá běhat na několika vybraných platformách, ale kdekoli, kde je to technicky možné. Dále ta aplikace musí být spustitelná z webového prohlížeče, s uživatelskými právy a bez instalace. Mobilním aplikacím musí uživatel schválit oprávnění, pluginy v prohlížeči mají aspoň nějaký snadbox (i když by mohl být lepší), což je další plus - není důvod, aby nějaká aplikace spuštěná z webu si mohla na mém PC dělat cokoli, k čemu mám já práva.
Jen si dovolím trochu opravit to, že Java umožňuje z více certifikátů stejného jména vybírat náhodně pouze jeden. Není problém zobrazit ani vybrat konkrétní certifikát i když budete mít v systémovém uložišti x certifikátů se stejným jménem. Ve většině případů certifikáty ze čtečky čipových karet nebo tokenu se stejné nahrají do systémového uložiště, takže není problém pomocí Appletu realizovat elektronický podpis. Java applet pro elektronický podpis jsem psal a bez problémů to funguje.
Jak se to tedy udělá? Já znám tenhle kód:
KeyStore ks = KeyStore.getInstance("Windows-MY"); Enumeration<String> aliases = ks.aliases(); ... Certificate cert = ks.getCertificate(alias); KeyStore.Entry entry = ks.getEntry(alias, null); Key key = ks.getKey(alias, new char[0]);
I všechny ostatní metody, které načítají jednotlivé položky, mají jako parametr jen alias
. A aliases()
je jediná metoda, která umožňuje získat seznam certifikátů.
Pokud má uživatel dva stejně pojmenované certifikáty, budou v aliases
dvě stejné položky. Jak můžu získat oba dva certifikáty (resp. handlery pro privátní klíče)? Pokud si dobře pamatuju, když jsem se díval na implementaci od Sunu, zda to nejde nějak obejít, ten kód takhle s certifikáty pracuje až na úrovni C++ kódu, tj. v Javovských objektech není žádný další informace, která by se dala použít, a ten stringový je jediný parametr, který propadne až do C++ kódu.
Ale opravdu mne zajímá, zda se to dá vyřešit jinak - rád bych odstranil ten kód z podepisovacího appletu, který porovnává počet položek z aliases
s počtem unikátních položek, a pokud nesouhlasí, vypíše uživateli varování, že některé certifikáty nejsou dostupné (s odkazem na nápovědu, kde je popsané, jak certifikáty ve Windows přejmenovat, aby měly unikátní názvy).
Takovou možnost jsem tam neviděl. Ale je možné, že applet je tak uživatelsky přívětivý, že ji nabídne, pouze když v úložišti něco je. Nedávno se mi podařilo začlenit PKCS#11 modul OpenSC do jre/lib/security/java.security a úspěšně jej vyzkoušet v JSignPDF, tak doufám, že něco uvidím příště.
Certifikáty si načtete ze systémového uložiště, tak jak uvádíte a pak pomocí této metody si předěláte názvy - za každým názvem bude ID certifikátu.
private static void fixAliases(KeyStore keyStore) {
Field field;
KeyStoreSpi keyStoreVeritable;
try {
field = keyStore.getClass().getDeclaredField("keyStoreSpi");
field.setAccessible(true);
keyStoreVeritable = (KeyStoreSpi) field.get(keyStore);
if ("sun.security.mscapi.KeyStore$MY".equals(keyStoreVeritable.getClass().getName())) {
Collection entries;
String alias, hashCode;
X509Certificate[] certificates;
field = keyStoreVeritable.getClass().getEnclosingClass().getDeclaredField("entries");
field.setAccessible(true);
entries = (Collection) field.get(keyStoreVeritable);
for (Object entry : entries) {
field = entry.getClass().getDeclaredField("certChain");
field.setAccessible(true);
certificates = (X509Certificate[]) field.get(entry);
hashCode = Integer.toString(certificates[0].hashCode());
field = entry.getClass().getDeclaredField("alias");
field.setAccessible(true);
alias = (String) field.get(entry);
if (!alias.equals(hashCode)) {
field.set(entry, alias.concat(" - ").concat(hashCode));
} // if
} // for
} // if
} catch (Exception exception) {
System.err.println(exception);
exception.printStackTrace();
} // catch
} // _fixAliases
Rád bych měl doplnění k dlouhému polemizování autora o bezpečnosti certifikátů v systémovém úložišti certifikátů a tomu, že aplikace zatím nepodporuje čipové karty a tokeny. Pokud vím, tak to, že vidím nějaký certifikát s privátním klíčem v systémovém úložišti certifikátů, neznamená přece, že soukromí klíč je uložen někde v systému. Ten může být na čipové kartě, nebo tokenu (při vložení některých tokenů do USB portu se certifikát automaticky zobrazí v osobních certifikátech). Takže pokud aplikace NEN, vybírá certifikáty ze složky osobních certifikátu, tak ty můžou být klidně uloženy na externím hardware a ne někde v systému. Tím pádem je už dnes možné v aplikaci NEN používat i čipové karty a tokeny.
Mimochodem, když se nad tím tak zamyslím, tak pokud by autoři NENu dali výběr certifikátu ze souboru jen jako druhou alternativní možnost a ještě třeba s poznámkou, že je to jen na vlastní nebezpečí, tak by bylo asi vše v pořádku.
Tak mi to nějak připomíná novinařinu polední doby. Šíleně dlouhý článek o bezpečnosti/nebezpečnosti nějaké aplikace a přitom jde jen o design jednoho okna ;-)
Právě proto bych možnost podpisu certifikátem v souboru úplně nezavrhoval, hlavně pokud je to jen jedna z možností. Uživatel aspoň není nucen mít nějaký konkrétní SW a HW. Pokud má Windows použije úložiště certifikátu, pokud má Mac OS, tak použije soubor. Není to ideální, ale můžu se aspoň svobodně rozhodnout. Nemám prostě z principu rád, pokud se někdo snaží rozhodovat, že dané konkrétní řešení je pro mě nejlepší.
jako uživatel Mac OS jsem pravé rád, že je tu více možnosti výběru odkud načíst certifikát. Je sice hezké mít jen bezpečnou variantu, ale absolutně nesnáším řešení: běží jen ve Windows jen v IE s určitým ActiveX plug-inem :-/
osobně nechápu proč autor věnuje půlku článku jedné z možností, že není bezpečná, když je to jen jedna z možností a odmítá nechat možnost výběru na uživateli
Rovnakých možností môže aplikácia v Silverlight 5 dosiahnuť i keď beží v prehliadači. Za predpokladu, že je podpísaná dôveryhodným vydavateľom. Potom má možnosť pristupovať k všetkým kryptografickým možnostiam Windows (čipové karty, tokeny, …). Myslím, že je to jedna z variant, ktorú NEN používa a autor spomenul, len okrajovo (asi zámerne, lebo by nebolo o čom písať J ).
Ano, mohl napsat rovnou, že přistupovat jakoukoliv aplikací přímo k soukromému klíči (tedy nikoliv alespoň přes nativního prostředníka OS) je čuňárna, ale že vzniknul tenhle podrobnej článek je dobře už jenom proto, aby se tahle neschopnost a idiocie dávala na odiv zase zpětně tomu parodickýmu výkvětu IT bezpečnosti.
Neboli, zmíněná (výchozí) "možnost" tam vůbec nemá co dělat/existovat (je to jako bianko směnka, a ta aplikace si pak může podepsat a podepisovat co jí napadne - a samozřejmě neiformovanej majitel danýho soukromýho klíče by pak u soudu mohl pěkně zaplakat)!
Proc stale ty prohlizece a pluginy ?
Dnesni doba mobilnich "aplikaci", kde to co byla drive jedna webova stranka je ted "aplikace" naopak preje reseni, vyrobit k tomu ucelu taktez aplikaci. Kdyz dokazi udelat na vice platforem napriklad VLC Player, Open Office a dalsi, dokaze to snad i firma za nekolik stovek milionu Kc.
Však byl také HTML 4 za to velmi kritizován a oprávněně. A proto také bylo tolik prosazováno CSS. Že to reálně nefunguje, je zase jiná věc. XHTML je úkrok stranou, který by býval mohl fungovat, kdyby to nakonec nedopadlo jako cokoli od W3C - zbastlit všechno dohromady jako dort od pejska a kočičky.
A ohledně té rychlosti - HTML5 vs. Flash není jen otázka videa. To je asi tak promile funkčnosti, kterou Flash poskytuje. Tam navíc není obecně zásadní problém. Flash řešil video víceméně proto, že v dané době nebylo lepší řešení a v momentě, kdy konečně po mnoha letech na video lepší řešení je, tak není problém video přehrávat vhodnější cestou.
Průser jsou složitější grafiky, skripty, aplikační logika. Na to je prostě JS naprostá tragédie. Pomalé, ukecané, obrovské - zatěžuje to hw, přenosové pásmo, úložný prostor. To, co dostanu ve flashi do pár desítek kilobajtů a bude to běhat jako z praku i na deset let starém střepu, to zabere v HTML5 stovky kilobajtů až megabajty a vytíží to i současné procesory na 100 %. Tedy aby nedošlo k omylu - pokud bude aplikaci programovat čuně, tak to dopadne tragicky s téměř libovolnou technologií (flashové reklamní banery jsou tipockou ukázkou). Nicméně flash lze velmi slušně optimalizovat (mnohem lépe než co nabízí současná kombinace html + JS), má mnohem více možností, propracovanější vývojové prostředí atd.
Bohužel flash padl ze dvou důvodů - jednak ho potopila sama firma Adobe tím, že dlouhé roky kašlala na bezpečnost a optimalizaci (obojí je teď na dobré úrovni, ale trvalo to příliš dlouho), jednak padl kvůli frikulínskému módnímu nadšení pro novou zkratku HTML5. A vlastně by se nemělo zapomínat ani na lví podíl firmy Apple, která flash nepodporovala na iPhonu...
Ale co, není to poprvé ani zdaleka naposledy, co se prosazuje nejhorší možná technologie na úkor těch lepších. Třeba opravdu za nějakých 20, 30 let bude HTML5 + CSS3 opravdu dodělané a zavládne klid na práci. Sice už bude doba někde jinde a bude zapotřebí úplně jiných technologií, ale snít klidně můžeme.
Zato předchůdce HTML4.01 je v oddělení kódu a obsahu dokonalost sama, že. Nedodělky XHTML 1.0, natož zcela mimo XHTML 2.0 (prakticky ani neexistující) nepočítaje.
HTML5 se jednou dodělá, stejně jako CSS3, a bude zase na nějakej čas pro vývojáře klid na práci.
Navíc, na starších HW je ve zpracování např. videa HTML5 (nativně v prohlížečích) pořád rychlejší než Flash (a i se to ještě zlepšuje, při hw akceleraci - Flash sice hw akceleraci má taky, ale často to moc rychlost - a nesekání - neřeší).
Co to? Silverlight že byl náhražkou HTML5? To je nějaká časová smyčka, ne?
Silverlight je tady od roku 2007 (preview v polovině roku 2006), zatímco první "working draft" HTML5 přišel až v roce 2008 (jistě, W3C mluvilo o potřebě už od roku 2004, ale prázdné mlácení slámy se jaksi nedá počítat). Silverlight byl konkurencí Flashe, nikoli HTML5.
HTML5 je hlavně příšerný paskvil, který nikdy neměl vzniknout. Tahle splácanina html + JS + SVG totálně zabíjí myšlenku oddělení obsahu a prezentace. Navíc to příšerně vytěžuje hardware (prý že je Flash náročný - proti HTML5 je to přímo bleskově rychlý a nenáročný kód). Vývoj je jako obvykle u W3C příšerně pomalý a nerespektuje rychlost vývoje všech ostatních technologií, ale ani potřeby uživatelů i vývojářů. Kéž by celé HTML5 zmizelo a nikdy nevzniklo.
Ale to není nic nového. Webová aplikace (javový aplet) pro podávání daňového přiznání z příjmů fyzických osob taky chce soubor PKCS#12 a heslo.
Nebo naše elektronické občanky si také neužijete bez proprietárního softwaru.
Je to založené na Mono, které je samo o sobě strašlivý moloch. Linuxáci ho obecně nemají moc rádi, do Linuxu ho tlačil Miguel de Icaza a když ten se z linuxového světa vytratil, nikdo nemá motivaci v tom pokračovat. Mono sice nějak žije dál, ale ochota na něm něco budovat moc velká není.
Pokud je to opravdu takto (neznám SilverLight) pak je ale HRUBOU CHYBOU ze strany NEN, že toto není jediná bezpečná a oficiálně podporovaná varianta..
problém tak možná není ani tak technologický (ve smyslu SilverLight to neumí), ale procesní, kdy je uživatel NAVÁDĚN k umělému snížení bezpečnosti celého řešení exportem soukromého klíče do souboru a následnou manipulací..