Názory k článku
Datové schránky po půl roce

V zákoně sice máme pojem časové razítko, ale vlastně nikde dál není řešeno, jak s ním správně naložit. Obdobně je to s expirací certifikátů, kdy se např. neřeší, zda jde použít certifikát pro podepsání těsně před expirací. Prohlížel jsem už datovou zprávu, jejíž PDF příloha měla expirovaný certifikát pár hodin po odeslání. Není také normální, když to právnické osoby řeší "plošně" konverzí všech došlých dokumentů do DS za nemalé své peníze. Těm potom můžeme něco povídat o moderním a levném e-úřadování.

No, je to levné e-úřadování, splňující přesně zadání - pro tu státní instituci, která dokument odeslala, i kdyby to stálo více , tak je to úspora, protože náklady na DS se pokud vím vykázují v rozpočtu v jiné kolonce, případně přeúčtovávají ministerstvu vnitra (přesnou metodiku neznám). Na rozdíl od dřívějška, kdy se účtovaly přimo jako náklady na poštovní služby.

Podle mne problém "C" ve skutečnosti neexistuje. Je to problém podobný tomu, že pro falzum papírového dokladu můžeme použít téměř stejný papír , téměř stejný inkoust a nakonec můžeme vytvořit téměř stejný podpis. Přesto jsem přesvědčen, ža falzifikáty nejsou překážkou běžného papírování.
Ono totiž vytvořit kolizní zprávu se stejným otiskem, s požadovaným obsahem ale zároveň tak aby měla obvyklou strukturu a formát je podle mého prakticky nemožné. Vždy bude potřeba zprávu někde "vycpat" použitím tzv "bílých" znaků tak aby obsahově odpovídala a zároveň měla stejný otisk.
Čili tento problém by měl připravovaný archív otisků zpráv zcela odstranit. Nám by pak stačilo archivovat celou zprávu a v případě potřeby by ji pošta na základě otisku v archivu ověřila. Pokud by někdo přispěchal s kolizní zprávou byla by to otázka pro soudní znalce a ti by na základě mnoha znaků(vložená prázdné znaky, syntaxe textu dokumentu a pod.) jistě dokázali uznačit tu správnou.
Otázkou je samotná technická implementace tohoto archivu, kdy já osobně bych se přimlouval spíše za použití několika odlišných metod otisku současně(MD5,SHA případně další) takže výpočet kolizní zprávy by byl ještě ztížen tím, že by zpráva musela odpovídat několika různým otiskům. To by spolu s údajem o počtu bytů datové zprávy IMHO zcela znemožnilo jakýmkoliv způsobem falšovat datovou zprávu.
Co se týče tzv. "soli"...mno k tomu jsem celkem skeptický, neb podle mne by se ke zlodějům "sůl" jiste dostala a zbytečně by to zkomlikovalo život pro odborníky, kteří by pro kvalifikované posouzení která zpráva je pravá potřebovali tuto sůl znát.

Aneb stačí si přečíst http://www.lupa.cz/clanky/isss-datove-schranky-budou-mit-archiv/nazory/
Nebylo by problém implementovat několik aktuálně kvalitních prověřených hashů, a i bez soli, připustíme-li, že pouze online ověřovací systém by byl nedostatečný (kromě toho i ten ostatně, souhlas, napadnutelný) + případné možné použití forenzní analýzy. Navíc se dá do budoucna rozsah i typy hashů bez problémů měnit s tím, že např. od 1.1.2015 bude jiná kombinace a jiný počet hashů, v té době bezpečných.
Nicméně to logicky předpokládá i omezení zásahu např. adminů daného systému, aby se ony zprávy a hashe nedaly žádným zásahem měnit (i to lze řešit).

Podle mých vědomostí je v datové zprávě uložené v ISDS víc než jeden hash (ten veřejný, zatím SHA-1, od léta SHA-256), tedy hledat kolizi vůči dvěma a více různým hashům, když ani nevíme, z čeho a jak jsou počítané, je čistá utopie.

Podle některých by tento systém (jak a z čeho) měl být zveřejněn. Tím by se mj. i předešlo možný interní i externí kompromitaci tohoto počítání, protože by na to šlo použít nespočet různých nástojů, včetně open source, paralelně to tedy srovnat mezi nimi, jestli výpočet souhlasí (v případě možné kompromitace kódu jednoho nástroje by šlo použít jakýkoliv jiný), a bylo by možné ho provádět kdykoliv a kdekoliv, čímkoliv k tomu určenému, i offline. S tím, jak už jsem psal, souvisí ale i nutnost zajištění nemožnosti interní kompromitace vlastních hashů, včetně cesty při načítání jejich hodnoty.

Takže jste jim ty hlouposti spolkl?

Ve skutečnosti tato aplikace "security by obscurity" znamená, že už falešnou zprávu nemůže vytvořit každý podvodník, ale jen bohatý a mocný podvodník.

Neboli člověk, který nějaký způsobem zjistí, jak to vlastně uvnitř funguje.

Což je snad ještě horší.

Běžný Franta z ulice je nyní vydaný na milost a nemilost instituci. A dokonce ztrácí kontrolu nad svými dokumenty. Představte si, že máte papír, který dokazuje nějaké vlastnictví. Tento dokument máte doma v trezoru a pokud chcete za 20 let toto vlastnictví prokázat, můžete tento dokument ukázat a podrobit znaleckému posudku.

Nově budete mít tento dokument v elektronické podobě a až za 20 let budete chtít prokázat jeho platnost, tak vám řeknou, že nesedí jakýsi hash. A máte smůlu.

A to je zásadní nevýhoda institucionálního archivu. Pokud ho někdo kompromituje a modifikuje tamní údaje, ztrácíte kontrolu nad svými dokumenty i když je máte doma v trezoru.

No a právě proto by tam neměla být žádná sůl, jen několik standardně vypočítaných "otisků". Tento archiv otisků ve tvaru IDZPRAVY - OTISK_MD5 - OTISK_SHA - OTISK_XYZ by měl být veřejně přístupný například jako pdf dokumenty obsahující zprávy odID - doID podepsané vždy aktuálním a platným elektronickým podpisem.
Automaticky by měl systém vygenerovat vždy danému subjektu jeho "knihu otisků" za určité období a doručit do systému jako zprávu. Tuto zprávu by si mohl subjekt nechat autorizovaně konvertovat do papírové podoby a tím by se stoprocentně pojistil proti zpětné změně otisku. Ochranou by bylo již samotné zaslání seznamu otisků do ISDS neb by bylo třeba falšovat vždy nejméně dvě zprávy.
Dále by se mohlo přistoupit k archivaci těchto seznamů v několika různých institucích, čímž by se možnost nějakého zpětného zásahu do systému prakticky úplně vyloučila.

Poslední odstavec je přesně to, co jsem myslel tím jedním z možných způsobů zabezpečení před zpětnou kompromitací již vytvořených hashů...

Na ostrém prostředí by certifikáty SHA-2 měly být nasazeny při odstávce 22. - 23. 5. Problémy u operačních systémů Windows XP a Windows 2003 by měl řešit hotfix KB968730. Tak uvidíme.

Dobry den, 25.4. byl uvolnen novy 602 XML Filler, který by mel SHA2 podporovat, viz. seznam novinek:

Nové vlastnosti

* Přidána služba Updater pro lepší možnosti aktualizace. Pro aktualizace webových doplňků nejsou vyžadována povýšená práva uživatele.
* Změna výchozí hodnoty pro úroveň zabezpečení odesílacího profilu
* Zvýšení zabezpečení komunikace mezi aplikací a internetovým prohlížečem
* Vylepšení chybového hlášení při podepisování SHA2 certifikátem na OS Windows XP SP2 a nižších
* Zpracování a ověření časových razítek s algortimem certifikátu SHA2
* Přidána možnost odesílání vzdálených příloh na server metodou PUT
* Přidána podpora pro formuláře, které mají nastaveno ukládání dat z RichText pole jako prostý text
* Rozšířená paleta barev pro prezentaci jednotlivých podpisů ve formuláři pro velký počet podpisů
* Změna shortcutu pro zapnutí/vypnutí hlasové podpory
* Úprava analyzátoru PDF/A pro potřeby provádění autorizované konverze
* Rozšíření konverzních funkcí pro potřeby generování ověřovacích doložek
-----------
Dale se chystá uprava Czechpointu, viz násl. upozornění pro uživatele CP:
28/04/2010 UPOZORNĚNÍ - Autorizovaná konverze z elektronické do listinné podoby dokumentu (na žádost)
5. 5. 2010 večer dojde k implementaci dílčích úprav systému Czech POINT:
- nutnost aktualizace programu 602XML Filler na verzi 3.16.13.10.0421 z 25.4.2010 nebo novější
- úprava zobrazení ověřovacích doložek
- možnost konvertovat dokumenty PDF/A s verzí nižší než 1.3
Procesy z pohledu pracovníků kontaktních míst zůstávají beze změny. Uživatelská dokumentace "Autorizovaná konverze - z elektronické do listinné podoby (na žádost)" byla upravena.

Dokud jakýkoliv update u uživatelů končí přepnutím do jazyku angličtina a současně se zapne hlasový výstup (no logicky - tu češtinu tam snad ani nemaj, ale hlavně o kecání nikdo nestojí) tak raději povýšená práva uživatele NE. Stejně to pak vyžaduje manuální zásahy.

A bude ta věc už konečně vůbec fungovat a nevyžadovat pořád něco přeinstlaovávat a práva lokálního admina kvůli zobrazení obsahu datové zprávy? Tchýně na to už rezignovala a řeší tak, že když ji něco přijde, tak odesilatele obvolá, ať ji to pošle faxem/normálním mailem jako PDFko a podívá se na to. Zatím všichni vyhovují.

Poslední specifikace ISDS (z února 2010) už připouští přenos externího podpisu a razítka.

Jak je na tom Czech POINT? Dokáže mi zkonvertovat externě podepsané PDF? Jak se takový vícesouborový dokument vkládá do konverzní úschovny Czech POINTu?

Vyvinuli jsem u nás ve firmě ISDS2Mail, ISDS2MailGUI a eDokument. Osobně po celém tom čase vidím, že většina problémů není technického, ale spíše legislativního rázu.

Jelikož je to na Javě a na testovacím prostředí datových schránek už certifikáty se SHA2 jsou, tak vím, že to chodí. Nerozumím pořád dokola tomu, proč nějaký pluginy do prohlížeče atd., proč se tu řeší Windows XP apod.

Takže pokud máte zájem, stáhněte si to třeba ze Slunečnice nebo od nás (jistě dohledáte, ať se to nebere jako spam) a vyzkoušejte.

Problém je v tom, že existují jiné dokumenty stejného původu, které říkají opak. Třeba v dokumentu "Typový postup implementace zákona č. 300/2008 Sb. (občan)" se píše:

1.6 Elektronický podpis
Elektronický podpis obecně není potřeba. Jak bylo řečeno, úkon učiněný prostřednictvím datové schránky má stejné právní účinky jako úkon učiněný písemně a podepsaný.
Elektronický podpis je nutné použít tam, kde je vyžadován ověřený podpis nebo kde je nutné, aby dokument podepsalo více osob.

2.3 Získání kvalifikovaného certifikátu
Pro práci s datovou schránkou není ve většině případů nutné opatřovat odesílané dokumenty elektronickým podpisem. Jsou však případy, kdy zákon uznávaný elektronický podpis vyžaduje, obecně se jedná o typy podání, která v listinné podobě vyžadují ověřený podpis.