Vlákno názorů k článku Národní elektronický nástroj: tohle by se v oblasti bezpečnosti dělat nemělo od Filip Jirsák - To už tu bylo, a ne jednou :-)...
-
Jiří Kněz (neregistrovaný)
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 -
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. Aaliases()je jediná metoda, která umožňuje získat seznam certifikátů.
Pokud má uživatel dva stejně pojmenované certifikáty, budou valiasesdvě 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 zaliasess 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). -
Jiří Kněz (neregistrovaný)
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.
-
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.
-
P2010 (neregistrovaný)
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.
-
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ř. tagyscriptanoscript), 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... -
P2010 (neregistrovaný)
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.
-
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ů.
-
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í. -
nosmo (neregistrovaný)
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í..
-
xpckar (neregistrovaný)
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)!
-
Milan (neregistrovaný)
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 ).
ČLÁNKY DO MAILU