Datové schránky: když ne s časovým razítkem, půjde to s arbitrem?

Tímto článkem bych rád navázal na několik svých předchozích článků publikovaných zde na Lupě, které se týkají problému dlouhodobé platnosti a průkaznosti elektronických dokumentů. Tedy problému, který není specifikem datových schránek a existovat ještě před jejich nástupem – ale který právě díky datovým schránkám výrazně eskaloval. A to ze dvou důvodů: právě datové schránky totiž přinutily velký počet subjektů (vlastně všechny právnické osoby i orgány veřejné moci) pracovat s elektronickými dokumenty a spoléhat se na ně. Což by samo o sobě bylo spíše pozitivní – nebýt toho, že současně s nástupem datových schránek nedošlo k vyřešení těch problémů, které kolem dlouhodobé platnosti elektronických dokumentů existují. Ba spíše naopak: došlo k mlžení, až k aktivnímu zastírání toho, že takovéto problémy existují a mohou mít nějaké reálné dopady.

Teprve v poslední době se zdá, že existence těchto problémů začíná být veřejně připouštěna, a objevují  se první pokusy ji řešit. Děje se tak skoro přesně po roce od spuštění datových schránek (k 1.7.2009) a v situaci, kdy jsou v oběhu již řádově miliony elektronických dokumentů, kterých se tyto problémy mohou týkat.

Pomoci má nová funkcionalita, kterou od včerejšího odpoledne nabízí informační systém datových schránek (ISDS): možnost ověřit pravost datové zprávy.

Časovaná bomba v eGovernmentu

To, že se existence problémů s dlouhodobou platností a průkazností začíná připouštět veřejně, mohu dokumentovat například na vystoupení ředitelů dvou společností, které aktivně implementují datové schránky (pro Telefóniku O2 CR jako integrátora, poštu jako provozovatele, a MV ČR jako zřizovatele a správce). Jde konkrétně o příspěvek pánů Aleše Kučery (Novell Professional Services) a Richarda  Kauckého (Software 602) na nedávné konferenci Business Internet Forum 2010, pořádanou vydavatelem Lupy.

Jejich příspěvek, s příznačným názvem „Rizika digitálních dokumentů aneb časovaná bomba v e-governmentu a co s ní“, si můžete prohlédnout zde. Dovolím si z něj převzít následující slide, naznačující podstatu problému:

Nechme stranou skutečnost, že ani po roce od spuštění datových schránek nedošlo ke sjednocení té nejzákladnější terminologie: jednou se hovoří o elektronických dokumentech, jindy (jako například zde) zase o digitálních dokumentech. Je to dáno zmatečnou terminologií už v legislativě (a zákon č. 300/2008 Sb., který do naší legislativy zavádí datové schránky, používá dokonce ještě třetí pojem, a to „dokument obsažený v datové zprávě“). Co si potom myslet o kvalitě zákonů, když se jejich autoři nedokáží sjednotit ani na základní terminologii?

Podstatnější je ale zmínka o časovém razítku, která pokračuje i na následujícím obrázku a která říká, že přidáním časového razítka „získávám čas“ – a to do doby platnosti razítka (přesněji: použitého certifikátu), nebo do doby kompromitace příslušných kryptografických algoritmů (podle jednoho z dalších výkladů).

Zdůrazněme si ale tu podstatnou skutečnost, že časové razítko, které na každou datovou zprávu přidává  informační systém datových schránek, neplní zde popisovanou roli „získání času“, resp. odkladu okamžiku, kdy se digitální (resp. elektronický dokument) ocitá v právním vakuu. Muselo by se jednat o jiné časové razítko. Například o takové, které by si ke zprávě dodatečně připojil (a již na své náklady) příjemce zprávy.

Problém je ve správném pořadí aplikace podpisu (značky) a časového razítka od ISDS: aby nastal efekt, popisovaný na obou slidech, musel by být dokument (či zpráva) nejprve opatřen elektronickým podpisem (či značkou), a teprve pak časovým razítkem. Aby toto časové razítko stvrzovalo, že podpis v daném časovém okamžiku (uvedeném na časovém razítku) již existoval.

V případě informačního systému datových schránek (ISDS) to bohužel funguje obráceně: datová zpráva je nejprve opatřena časovým razítkem (v okamžiku podání zprávy a s časem tohoto podání). Elektronický podpis (značka) je přidáván až později, konkrétně v okamžiku stahování datové zprávy z ISDS. Třeba až po mnoha dnech či dokonce týdnech. Takže časové razítko na datové zprávě nemůže stvrzovat existenci podpisu (značky) – když tento podpis v okamžiku vzniku razítka ještě neexistoval.

Navíc se u datových schránek liší i to, co je „pokryto“ (podepsáno) časovým razítkem a co podpisem (značkou): časové razítko je počítáno z té části datové zprávy, která ještě neobsahuje (mimo jiné) časové údaje o dodání a doručení zprávy. Ani nemůže, když tyto události v době vzniku časového razítka (přidávaného v okamžiku podání) ještě nenastaly. Naproti tomu elektronický podpis (značka), která se na zprávu přidává okamžiku stahování zprávy z ISDS, již „pokrývá“ i tyto údaje. 

Konkrétní způsob přidávání časových razítek a elektronických podpisů (značek) v ISDS také může vést k zajímavým paradoxům. Pokud si totiž stáhnete z ISDS (a uložíte na svůj disk, nejspíše ve formátu ZFO) stejnou zprávu ve dvou různých časových okamžicích, pak se může stát, že ISDS používal v obou okamžicích různé systémové certifikáty pro svůj podpis (značku) – a v důsledku toho dostanete dvě různé verze souboru, obsahujícího jednu a tutéž datovou zprávu. Navíc, nejspíše v důsledku průběžných změn (mj. i v použitých hashovacích funkcích), se oba soubory mohou lišit i svou velikostí.

Příklad vidíte na následujícím obrázku: jde o jednu a tutéž zprávu (a sice o systémovou datovou zprávu, informující o přechodu na SHA-2). Vlevo je verze zprávy stažená z ISDS v květnu a  opatřená ještě značkou, založenou na původním systémovém certifikátu ISDS (na SHA-1). Vpravo pak tatáž zpráva, stažená v červnu, s elektronickou značkou založenou již na novém systémovém certifikátu (na SHA-2).

Stejně tak se může lišit i hodnocení platnosti podpisu (elektronické značky) programem 602XML Filler, a to na jedné a téže zprávě – podle toho, kdy byla zpráva stažena a opatřena podpisem (značkou). Na následujícím obrázku vidíte stejné dva exempláře jedné a téže datové zprávy jako na předchozím obrázku: u jedné z nich Filler po pravdě sděluje, že platnost použitého certifikátu již skončila (vlevo, u staršího exempláře z května). Proto může celkově konstatovat jen to, že zpráva byla opatřena elektronickou značkou (bez uvedení toho, zda byla či nebyla platná – protože to již nedokáže posoudit).

Naopak na novějším exempláři zprávy (vpravo), stažené v červnu, XML Filler konstatuje, že certifikát stále platí – a tak může ověřit platnost elektronické značky. Proto může celkově konstatovat, že (v okamžiku stažení) datová zpráva byla opatřena platnou elektronickou značkou.

Co si ale má počít uživatel, který má k dispozici pouze  „starší“ verzi stažené zprávy (ve smyslu levé části obrázku), u které již není možné ověřit platnost podpisu, resp. elektronické značky ISDS? Jak prokáže, že jde o pravou a autentickou zprávu, pokud to někdo po něm bude požadovat?

Jaké řešení je navrhováno?

Vraťme se zpět k výše zmiňované prezentaci a druhému citovanému slidu. Ten obsahuje určitou představu o možnosti řešení celého problému, a to „přidáním dalšího prvku, který garantuje věrohodnost dokumentu v budoucnu po jeho expiraci“. V konkrétní podobě jakéhosi arbitra, resp. důvěryhodného správce.

Podrobnější představu o arbitrovi a jeho fungování ukazuje následující obrázek:

Jde vlastně o stejnou představu, jaká byla již dříve prezentována ze strany MV ČR, jen pod jiným jménem: místo o „arbitrovi“ hovořilo MV ČR o „institucionálním archivu“. Jako o něčem, co si bude pamatovat otisky (hashe) datových zpráv, které kdy prošly skrze ISDS (Informační systém datových schránek), a podle tohoto hashe potvrdí, zda jde o původní zprávu či nikoli.

Sám jsem vůči této představě již dříve vznášel zásadní námitku: že to může fungovat jen do doby, než bude možné vypočítat kolizní zprávu, neboli takovou zprávu, která má stejný otisk (hash) ale jiný obsah. Pak by se celý  institucionální archiv rázem změnil na nástroj umožňující legalizaci podvodů: tomu, kdo by si vypočítal kolizní zprávu, by jen formálně potvrdil její autentičnost. Připomeňme si, že už kvůli explicitnímu požadavku v zákoně ISDS nemůže dlouhodobě uchovávat samotný obsah datových zpráv jako takových. Jinak by mohl celý problém řešit jednoduchým porovnáním obsahu originálu s předkládanou zprávou, a nemusel by se spoléhat na pouhé otisky.

Zde je ale  tato představa institucionálního archivu modifikována v tom smyslu, že se počet otisků (hash-ů) zdvojí: jeden hash bude veřejný a druhý bude neveřejný a jeho konkrétní hodnotu i způsob výpočtu by měl znát jen ISDS.

Z mého pohledu je systém dvou hashů určitě bezpečnější než systém jediného hashe, protože výrazně ztěžuje výpočet kolizní zprávy k původní datové zprávě. Ta je navíc strukturovaná, což tento výpočet dále ztěžuje. Nicméně ani toto opatření neřeší problém principiálně, protože stále nevylučuje existenci kolizních zpráv. Reálnou možnost zneužití tak skrze ztížení výpočtu pouze odsouvá na ještě pozdější dobu. Navíc má toto řešení slabinu v tom, že obsahuje významný prvek „security through obscurity“, neboli snaží se zvýšit bezpečnost skrze utajování použitých postupů. Což jednak motivuje k jejich odhalení, a v okamžiku odhalení se naopak stává slabinou, která možnost zneužití naopak v čase přibližuje.

Praktická implementace na úrovni rozhraní webových služeb

To, že popisované řešení – ať už ho budeme označovat jako řešení s arbitrem či jako institucionální archiv – bude skutečně implementováno, avizoval již před časem (konkrétně od 23.5.2010) aktualizovaný Provozní řád ISDS. Ten totiž zmiňuje službu (v rámci rozhraní webových služeb), která by měla fakticky realizovat popisovanou funkčnost arbitra: dostane datovou zprávu a řekne, zda je autentická či nikoli. Přesněji: zda prošla skrze ISDS či nikoli.

Jde konkrétně o funkci (službu) AuthenticateMes­sage, která je v příloze Provozního řádu popsána takto:

Služba očekává na vstupu staženou datovou zprávu, podepsanou značkou MV, ve formátu, který vrací webové služby Signed[Sent]Mes­sageDownload nebo ukládá Portál ISDS. Jakožto binární formát je nutné datovou zprávu předávat do WS konvertovanou do base64.

U předané zprávy se zkontroluje vnější podpis, je-li v pořádku, odstraní se. Poté se spočítá veřejný hash (z elementu <dmDm>) algoritmem použitým ve zprávě a porovná se s hashem originálním. Jsou-li oba hashe shodné (plus další neveřejné kontroly), vrátí WS v elementu dmAuthResult hodnotu TRUE (zpráva je platná), jinak vrátí FALSE, a stav operace 0000.

Zde se tedy hovoří o „dalších neveřejných kontrolách“, které by zřejmě měly odpovídat druhému (neveřejnému) otisku (hash), který je zmiňován ve výše citovaném příspěvku.

Z popisu službu také vyplývá, že se kontroluje pouze to, co je „pokryto“ prvním (veřejným) otiskem – a kam například nepatří údaje o čase dodání a doručení, či stavu zprávy. Tyto údaje by ale měly být „pokryty“ alespoň elektronickou značkou, připojovanou v okamžiku stažení datové zprávy z ISDS.

Ověření pravosti datové zprávy přes webové rozhraní

Tak jak bylo dopředu avizováno, funkce arbitra (či institucionálního archivu) nebude omezena jen na rozhraní webových služeb, které využívají nejrůznější spisové služby a podobné aplikace, ale bude dostupná i přes webový portál pro „běžné“ uživatele datových schránek. To se stalo skutečností včera (v neděli 27.6.2010), kdy byl ISDS znovu zpřístupněn po odstávce.

V hlavním menu se nyní nově objevila další ikonka, nabízející právě možnost „ověření pravosti datové zprávy“.

Pokud si ji navolíte, dostanete se na jednoduchou nabídku, která vám umožní vybrat místní soubor s datovou zprávou.

Ten musí být ve formátu ZFO, jiný typ souboru není akceptován:

Pokud zadáte správný typ souboru a systém provede své kontroly (ověření hashe plus další neveřejné kontroly), může dojít k závěru, že předložená datová zpráva prošla skrze ISDS (informační systém datových schránek). Nebo naopak že neprošla.

Více se toho ale nedozvíte: jen ANO („Obsah předložené datové zprávy se shoduje se záznamy Informačního systému datových schránek. Tato datová zpráva byla systémem přenesena“), nebo NE („Obsah předložené datové zprávy se neshoduje se záznamy Informačního systému datových schránek. Tato datová zpráva nebyla systémem přenesena“). Nejde tedy o hodnocení platnosti či neplatnosti podpisu (el. značky) na datové zprávě, natož pak o výrok týkající se podpisů na dokumentech uvnitř datové zprávy –  ale jen o to, zda datová zpráva „prošla“ skrze systém datových schránek a její integrita nebylo porušena (viz „obsah se shoduje“). Nedozvíte se například ani údaj o čase, kdy posuzovaná datová zpráva prošla skrze systém datových schránek.

Výhodou je naopak to, že tímto způsobem si můžete ověřit i cizí zprávy. Nemusíte být ani jejich odesilatelem, ani příjemcem. Jediné, co musíte, je mít přístup k (nějaké) datové schránce, abyste tuto funkčnost mohli využít.

Dalším zajímavým momentem je to, že popisované ověření funguje skutečně jen pro datové zprávy a nikoli pro doručenky. Ty popisovaný mechanismus odmítne, a stejným způsobem reaguje i na další „jiné“ objekty, uložené v souboru s příponou .zfo. Dělá to ale způsobem, který mi nepřijde příliš korektní: místo toho, aby konstatoval něco ve smyslu „nejde o datovou zprávu“ a o další hodnocení se již nepokoušel, stále se snaží interpretovat předložený soubor ve formátu .zfo jako datovou zprávu. A jelikož jde o něco jiného než o datovou zprávu, nebude se shodovat s žádnou (skutečnou) datovou zprávou, která kdy systémem prošla – a tak služba zahlásí, že „Tato datová zpráva nebyla systémem přenesena“. Zůstává tak na uživateli, aby se tím nenechal zmást a mohl i nadále věřit tomu, že jeho doručenka (nikoli datová zpráva) přeci jen prošla systémem datových schránek.

To nemohli páni programátoři přidělat samostatnou hlášku o tom, že předložený obsah není datovou zprávou, a tudíž není dále zkoumán a hodnocen?

Právní aspekty

Z čistě praktického pohledu mi také přijde dost nešikovné to, že verdikt neobsahuje žádnou identifikaci toho, vůči čemu se vztahuje. Například nějaké jméno souboru, který byl ověřován, nebo identifikátor (číslo) datové zprávy, či další údaje. Z předchozí dvojice obrázků (v tabulce vedle sebe) například nijak nepoznáte, k čemu se vztahují. Pokud bych tedy potřeboval tímto způsobem někomu prokázat autenticitu nějaké zprávy, vlastně by to ani nešlo. Mohl bych mu předložit  jen dva samostatné obrázky: na jednom by byl výběr konkrétního souboru, a na druhém jakási zelená fajfka (a ne červený křížek). Ale jak bych prokázal, že se tyto dva obrázky vztahují k sobě, a ne každý k něčemu jinému?

On je ale celý problém poněkud hlubší, a uvedený nedostatek je možná i záměrný. I kdyby totiž výsledný verdikt obsahoval nějakou indikaci toho, k čemu se vztahuje, stejně by bylo otázkou, jak závazný by tento verdikt byl.

Podle mého názoru to vlastně ani otázka není: podle mne verdikt závazný není, protože nemá žádnou oporu v zákoně (ani v prováděcích vyhláškách). Takže by mělo jít pouze o nezávaznou informaci, kterou se někdo řídit může, ale také nemusí – podle svého uvážení. I když jsem se ale setkal i s názorem, že popisovaný verdikt by mohl být závazný díky legislativnímu výkladu (tj. někdo by vyložil, že jeho závaznost vyplývá z toho, co zákony již obsahují). To už mi ale přijde dosti odvážné a krkolomné.

Stejně tak jsem se setkal i se zajímavým názorem na to, jak by se popisovaný arbitr měl používat: jeho služeb by vyžíval ten, kdo se potřebuje ubezpečit o pravosti nějakého dokumentu. Tedy jeho příjemce. Místo samotného dokumentu by mu byla předložena celá datová zpráva, a on by se sám aktivně přihlásil do ISDS (do nějaké „své“ datové schránky) a zde si nechal od arbitra posoudit pravost této zprávy jako celku – a teprve pak pracoval se samotným dokumentem uvnitř datové zprávy. Praktické, že. A použitelné jen někým, kdo má přístup k nějaké datové schránce.

Podobně by prý měla do budoucna existovat možnost „protáhnout“ konkrétní dokument skrze systém datových schránek: předložit ho ISDS, který by si ho „obalil“ datovou zprávou (jakoby přeposlal sám sobě) a tím i uchoval – a následně by se dala využít funkce arbitra na ověření takovéto datové zprávy. Tím by se celý ISDS vlastně stal jakýmsi elektronickým archivem. Jenže bez právní závaznosti by to moc smysl nemělo.

Aspekt právní závaznosti si určitě uvědomili i oba autoři výše popisovaného příspěvku z konference Business Internet Forum 2010. Na jednom ze svých slidů totiž hovoří o zavedení arbitra v podobě Centrální evidence elektronických dokumentů (CEED), který fungoval obdobně jako ISDS (a tedy asi paralelně vedle něj, jako něco samostatného). A hlavně: byl by ukotven v zákoně, konkrétně v zákoně o elektronickém podpisu, tak aby jeho verdikt o pravosti mohl mít nějakou právní relevanci.

No, uvidíme. Jsem zvědav, jak bude nová funkčnost/služba ISDS pro ověřování datových zpráv oficiálně prezentována. Zatím jsou o ní stopy jen v nápovědě k ISDS, kde se o ní píše toto:

Portál pro práci s datovými schránkami nabízí funkci umožňující ověřit autenticitu a neporušenost datové zprávy, která byla prostřednictvím Informačního systému datových schránek zaslána z jedné datové schránky do jiné. Máte-li k dispozici nějakou datovou zprávu a jste-li vlastníkem datové schránky, můžete tímto způsobem věrohodně prokázat, zda se jedná o pravou datovou zprávu v nezměněné podobě bez ohledu na platnost časového razítka a značky, kterou byla v době jejího uložení na disk počítače označena.

A jakpak asi bude potřebnost nové služby vysvětlována v kontextu dosavadního oficiálního dogmatu, že datové zprávy stačí ukládat jako celek (ve formátu ZFO), a už jsou na věky průkazné. Proč by pak byla právě popisovaná novinka s ověřováním pravosti datových zpráv vůbec zapotřebí?