Jak na digitální kontinuitu (12): Proč mají elektronické podpisy různé profily, formáty a úrovně?
Elektronické podpisy i pečeti mohou mít různé formáty (např. PAdES, XAdES, CAdES) a mohou být jak interní, tak i externí. Možnost jejich ověření v čase můžeme prodloužit tím, že k nim přidáváme časová razítka a nezbytné revokační informace. Podle toho pak mají různé úrovně (B, T, LT, LTA).
V předchozích dvou dílech seriálu Jak na digitální kontinuitu jsme se zabývali tím, jak digitální kontinuitu elektronických dokumentů a jejich podpisů ovlivňuje možnost revokace certifikátů a jak volit rozhodný okamžik, ke kterému má být posuzováno splnění podmínek pro ověření platnosti elektronických podpisů, ale i pečetí a časových razítek.
Dnes si povíme o dalších faktorech, které se týkají elektronických podpisů (i pečetí) a také mají vliv na udržování jejich (aktuální) digitální kontinuity.
Co všechno se dá podepsat?
Elektronicky podepsat se dá všechno, co se dá „uchopit“ (a udělat z toho otisk alias hash). Jediné, co nejde podepsat, je to, co právě „teče“. Tedy nějaký „živý“ datový proud (stream), což jsou data, která teprve průběžně vznikají a průběžně „přitékají“, jako například u nějakého video- či audiopřenosu. I zde se ale dá postupovat per partes: počkat vždy na nějaký „kus“ (vhodně velký blok dat), který je již celý k dispozici, a ten podepsat.
Nicméně ne všechna data se dají elektronicky podepisovat stejně, jako jsme běžně zvyklí u PDF dokumentů (resp. u souborů formátu PDF). Tedy způsobem, který se (neformálně) označuje jako interní (elektronický) podpis. To proto, že zde nevzniká nějaký další objekt (vedle samotného podepisovaného PDF dokumentu/souboru), ale elektronický podpis (i s jeho dalšími obvyklými náležitostmi, hlavně certifikáty a revokačními informacemi) je začleněn (vnořen) přímo do souboru s dokumentem a tvoří s ním jeden celek.
Na takovýto interní podpis ale musí být příslušný formát souborů připraven a musí s ním dopředu počítat. Kromě formátu PDF s interními podpisy počítají i další formáty: například „náš“ formát ZFO pro zprávy z datových schránek či „kancelářské“ formáty DOC(X), XLS(X) i PPT(X) nebo formát XML.
Řada jiných souborových formátů ale s interními podpisy nepočítá a lze je podepsat pouze pomocí externích (elektronických) podpisů. Což znamená, že elektronický podpis (i s jeho náležitostmi) již netvoří jeden celek s tím, co je podepsáno, ale jde o samostatný objekt, resp. samostatný soubor (určitého konkrétního typu a formátu). To samé přitom platí i pro pečeti a časová razítka: i ty mohou být externí.
V tomto seriálu jsme se s externím elektronickým podpisem již jednou setkali. A to v 8. dílu, kdy jsme si ukazovali, jak jeden a tentýž (externí) elektronický podpis „pasuje“ ke dvěma různým, ale vzájemně kolizním PDF dokumentům (se stejným otiskem dle SHA-1). Jiný příklad externího podpisu můžete najít zde a vyzkoušet si práci s ním.
Mimochodem, i tyto příklady dokládají, že podepsat pomocí externího podpisu lze i takové formáty, které podporují interní podpisy. Takže třeba u PDF dokumentu (resp. souboru ve formátu PDF) si podepisující může vybrat, zda vytvoří interní, či externí elektronický podpis. Obdobně pro časová razítka.
V praxi (alespoň v ČR) ale významně dominují interní varianty. Přitom i u externích elektronických podpisů (a pečetí i časových razítek) lze udržovat jejich aktuální digitální kontinuitu, skrze jejich „povyšování“ (viz dále).
Formáty elektronických podpisů: CAdES, XAdES a PAdES
Pokud chceme podepisovat nějaký dokument pomocí interního podpisu, je nutné respektovat interní strukturu toho souboru, ve kterém je dokument obsažen. Jinými slovy, když budeme podepisovat PDF dokument (vytvářet interní podpis), musí výsledný podpis (i jeho „náležitosti“, jako jsou certifikáty, revokační informace a další věci) mít takovou vlastní strukturu a takový formát, aby jej bylo možné začlenit (vnořit) do PDF souboru.
Zjednodušeně: když podepisujeme (interním podpisem) PDF dokument, mělo by jít o elektronický podpis ve formátu, který je označován jako PAdES (od PDF Advanced Electronic Signature). Obdobně pro pečeti.
Pokud bychom podepisovali nějaký XML dokument, mělo by jít o podpis ve formátu XAdES (od XML Advanced Electronic Signature).
No a pokud bychom chtěli podepsat (či opatřit pečetí) něco jiného, můžeme k tomu použít podpis (či pečeť) v ještě jiném formátu: CAdES (CMS Advanced Electronic Signature). Ten má výhodu v tom, že jím lze podepsat – coby externím podpisem – cokoli (obecně jakákoli binární data) a není nutné respektovat strukturu a formát toho, co je podepisováno. Současně je to ale nevýhoda: takovýto podpis pak obvykle nejde vnořit přímo do podepisovaného objektu jako jeho interní podpis (pokud s tím dopředu nepočítá). Ale může s ním být např. společně „zabalen“ do nějakého většího celku (kontejneru). Například tzv. ASiC kontejneru (viz dále).
Pro úplnost si ještě dodejme, že relativně nedávno byl standardizován ještě další formát elektronických podpisů (a pečetí), a to JAdES (JSON Advanced Electronic Signatures), určený hlavně pro elektronické online transakce (například v bankovním sektoru).
Způsoby zapouzdření: odpojené, obalující a obalené podpisy
Když už se bavíme o různých formátech podpisů (tj. nejenom PAdES, ale i XAdES a CAdES), je dobré si říci, že rozdělování podpisů na interní a externí je zjednodušené a spíše neformální.
Ve skutečnosti je škála možností toho, co je označováno jako „zapouzdření“ (packaging), přeci jen bohatší a zahrnuje podpisy „odpojené“ (detached), „obalující“ (enveloping) a „zabalené“ (enveloped).
Naše dosavadní představa externího elektronického podpisu odpovídá „odpojeným“ (detached) podpisům. Tedy takovým, které jsou samostatným objektem, resp. souborem (vůči tomu obsahu/souboru, ke kterému se vztahují a který podepisují). Tato možnost připadá v úvahu pro formáty XAdES a CAdES. Přitom to, co jsme až dosud považovali za externí podpis PDF dokumentu, je ve skutečnosti „odpojený“ (detached) podpis ve formátu CAdES.
To „obalující“ (enveloping) způsob zapouzdření je jakoby opakem vnoření podpisu do podepisovaného objektu: zde je naopak to, co je podepisováno, vnořeno do elektronického podpisu. Tato možnost připadá v úvahu pro formáty XAdES a CAdES, ale nikoli pro formát PAdES.
Varianta „zabalených“ (enveloped) podpisů zase nejlépe odpovídá dosavadní zjednodušené představě interních podpisů: podpis je zde „zabalen“ (vnořen) do toho, co je podepisováno. Tato varianta připadá v úvahu pro formáty PAdES a XAdES, ale nikoli pro formát CAdES.
Pokud se na to podíváme z opačného pohledu, pak:
- pro formát PAdES připadají v úvahu jen podpisy „zabalené“ (enveloped), což zjednodušeně odpovídá dosavadní představě interních podpisů (zatímco externí podpisy PDF dokumentů jsou řešeny jako „odpojené“ CAdES podpisy),
- pro formát CAdES připadají v úvahu podpisy „obalující“ (enveloping) a „odpojené“ (detached),
- pro formát XAdES připadají v úvahu všechny tři varianty: „zabalené“ (enveloped), „obalující“ (enveloping) i „odpojené“ (detached).
Příklad nabídky různých variant zapouzdření pro jednotlivé formáty podpisů v konkrétním nástroji pro podepisování ukazuje následující obrázek. Jde o program Signer, který pro podepisování PDF souborů nabízí podpisy PAdES jen v jejich interní variantě (tj. „zabalené“), zatímco ty externí jsou dostupné jako „odpojené“ CAdES podpisy.
U XAdES podpisů se někdy uvádí jako další možnost tzv. „vnitřně odpojené“ (internally detached) podpisy, kdy v jednom výsledném objektu (souboru) jsou jak podepsaná data, tak i samotné podpisy a mohou zde být i další nepodepsaná data.
ASiC kontejnery
Nevýhodou externích („oddělených“, detached) elektronických podpisů je už jejich samotný „externí“ charakter: jelikož netvoří jeden celek s tím, k čemu se vztahují (co podepisují), lze například ztratit jen externí podpis, ale nikoli samotný dokument, resp. soubor.
Problémem může být také vzájemná logická vazba: co patří k čemu. Tedy který podpis podepisuje který soubor. Zvláště když podpisů na jednom dokumentu (souboru) je více: v případě interních podpisů jsou tyto řazeny „za sebe“ (tzv. do série). Díky tomu je jasné jak jejich pořadí, tak i to, kolik jich vlastně je. To v případě externích podpisů, které jsou jakoby „skládány vedle sebe“ (paralelně), existují jako samostatné objekty (soubory) a mohou být vytvářeny nezávisle na sobě, to jasné být nemusí.
Řešením, se kterým počítá i nařízení eIDAS, jsou tzv. ASiC kontejnery (Associated Signature Container). Jde o standardizovaný způsob, jak „poskládat“ jeden či více souborů a jejich externí podpisy a/nebo časová razítka (ve formátech XAdES či CAdES) do jednoho celku (na bázi ZIPu) a současně (skrze tzv. manifest) popsat, který podpis (a/nebo razítko) se vztahuje ke kterému souboru (či souborům). Pamatováno je také na možnost udržování aktuální digitální kontinuity těchto kontejnerů. Představu ASiC kontejneru ukazuje následující obrázek.
Jen u nás (v ČR) jsou ASiC kontejnery v nemilosti. Možná proto, že nejsou mezi výstupními datovými formáty dle vyhlášky o podrobnostech výkonu spisové služby. Datovými schránkami tyto kontejnery aktuálně nepřenesete (a termín pro zavedení této možnosti byl podle posledních informací znovu posunut, na začátek příštího roku). Ani spisové služby a elektronické podatelny si s nimi vesměs neporadí.
Nicméně třeba notáři již ASiC kontejnery používají, a to pro legalizaci elektronických podpisů (jak jim ostatně ukládá i příslušné nařízení vlády). A ve 3. dílu tohoto seriálu jsme si jeden takový kontejner ukazovali.
Byte range a podepisované a nepodepisované atributy
Vraťme se ale zpět k PDF dokumentům, které nás zajímají asi nejvíce, a k jejich interním („zabaleným“, enveloped) podpisům. U nich je dobré vědět, že skutečně podepsána – a to ve smyslu vytvoření otisku a možnosti následně detekovat jakoukoli změnu – je jen část výsledného celku (souboru ve formátu PDF). Naopak určitá (menší) část je z vytváření otisku vyjmuta, a není tudíž chráněna proti změně (resp. není u ní detekována změna, i kdyby k ní došlo). Tato část tak vlastně není podepisována.
Důvodem je to, že obsah této „vyjmuté“ části bude teprve stanoven (vložením již vytvořeného podpisu), a bude tedy jiný, než jaký je v okamžiku vytváření otisku. Proto se otisk dělá jen ze zbývající části, která by ale měla obsahovat veškerý „dokumentový“ obsah (to, co tvoří věcný obsah PDF dokumentu). Této části se v případě PDF souborů říká byte range (doslova: bajtový rozsah) a její představu na konkrétním příkladu ukazuje následující obrázek.
S tím souvisí i to, že některé „náležitosti“ elektronického podpisu (formálně atributy) jsou součástí onoho byte range, a jsou tedy podepisovány (ve smyslu, že otisk je sestavován i z jejich hodnoty, a jsou tak chráněny proti změně), zatímco jiné atributy v tomto smyslu podepisovány nejsou. Pomyslná dělící čára přitom vede přes to, co je známo již v době vytváření otisku (a může tedy být zahrnuto do jeho výpočtu a tím i „být podepsáno“), a tím, co bude známo až později (co může být jen nepodepsaným atributem).
Zatímco tedy podepisované atributy (jako jsou například certifikáty podepisující osoby i vydávajících certifikačních autorit) mohou být skrze otisk „fixovány“ a pak se již nemohou měnit (protože jinak by došlo k porušení integrity podepsaného obsahu a výsledný podpis by byl neplatný), nepodepsané atributy (kterými jsou zejména podpisová časová razítka a revokační informace) se mohou přidávat i dodatečně.
Případná změna těchto nepodepsaných atributů ale nemusí být detekována – pokud nejsou dodatečně „zafixovány“ nějak jinak, například dalším podpisem či dokumentovým časovým razítkem. Protože při přidávání dokumentového časového razítka (nebo dalšího podpisu či pečeti) se celá situace opakuje, jak ukazuje následující obrázek – je vytvořen nový byte range zahrnující i původně vyjmutou část, a nový otisk se tak počítá i z dosud nepodepsaných atributů. Vyloučena z tvorby nového otisku je jen nově vyjmutá část, do které se vkládá nově přidávané dokumentové časové razítko a jeho nepodepsané atributy. Představu ilustruje následující obrázek.
Díky právě naznačenému postupu mohou být PDF soubory „nafukovací“, či spíše „prodlužovací“: lze k nim postupně („sériově“) přidávat další a další (interní) elektronické podpisy a pečeti (ve formátu PAdES) i dokumentová časová razítka, čímž dochází ke zvětšení jejich velikosti („prodloužení“).
Jednotlivé podpisy, pečeti (ale i dokumentová časová razítka) ve formátu PAdES přitom fungují v jistém smyslu i jako kontejnery, do kterých lze (a to i dodatečně) „přisypávat“ další informace, a to jako jejich nepodepsané atributy. Znovu si zdůrazněme, že jde o časová razítka (obvykle připojovaná souběžně se vznikem podpisu či pečeti), a hlavně o validační informace nutné pro pozdější ověření podpisu, pečeti či časového razítka. Reálně jde hlavně o revokační informace a spíše výjimečně o „chybějící“ certifikáty (protože ty jsou obvykle již připojeny, a to jako podepsané atributy). Znovu si zdůrazněme, že takto přidávané nepodepsané atributy mohou být následně „zafixovány“ přidáním dalšího podpisu, pečeti či dokumentového časového razítka a stát se tak fakticky podepsanými atributy.
Konkrétnější popis způsobu „prodlužování“ PDF souborů i uspořádání „přisypávaných“ údajů v PDF souborech (kde se vyskytují např. slovníky DSS a VRI) je již nad možnosti a zaměření tohoto článku. Pro nás je zde podstatná samotná možnost přidávání („přisypávání“) dalších informací k již existujícím podpisů či pečetím a také možnost připojování dokumentových časových razítek k celým souborům, resp. podepisovaným objektům. Díky tomu je možné „povyšovat“ již existující (či právě vytvářené) podpisy do vyšších úrovní (viz dále). Protože to je právě to, co potřebujeme pro udržování aktuální digitální kontinuity a čím toho dosahujeme.
Úrovně podpisů: B, T, LT a LTA
S možností přidávání („přisypávání“) dalších informací a dalších časových razítek se nesetkáme jen u interních podpisů (a pečetí) ve formátu PAdES, ale i u ostatních podpisových formátů (XAdES, CAdES i JAdES) a ASiC kontejnerů. U všech existuje více jejich úrovní, lišících se tím, co všechno je k nim přidáno:
- úroveň B (od Basic Signature) tvoří jen samotný elektronický podpis či pečeť,
- úroveň T (od Signature with Time) tvoří úroveň B doplněná o (podpisové či dokumentové) časové razítko (poskytují důkaz o existenci podpisu či pečeti v čase),
- úroveň LT (od Signature with Long-Term Validation Material) tvoří úroveň T doplněná o nezbytné validační informace nutné pro pozdější ověření podpisu i časového razítka,
- úroveň LTA (od Signature providing Long Term Availability and Integrity of Validation Material) tvoří úroveň LT doplněná o jedno (či více) dokumentových časových razítek, která „fixují“ všechny již dříve vložené validační informace a poskytují důkaz o jejich existenci v čase. Případně i další validační informace nutné pro pozdější ověření předchozích razítek, podpisů a validačních informací.
Znovu si zdůrazněme, že tato hierarchie je dnes společná pro všechny výše popisované formáty elektronických podpisů (i pečetí), tedy PAdES, XAdES a CAdES (i JAdES), a stejně tak pro ASiC kontejnery.
Baseline profily
Dříve to ale tak jednotné a relativně jednoduché nebylo. Starší hierarchie byly „košatější“, měly více úrovní, které se pro různé formáty jmenovaly jinak (např. XL místo dnešní LT a LTV či A místo dnešní LTA) a připouštěly přidávání ještě dalších věcí než jen časových razítek a validačních informací (například identifikátorů podpisových politik u úrovně EPES).
Tím vznikalo větší množství vzájemně nepříliš slučitelných kombinací (formátů a úrovní), společně označovaných jako (podpisové) profily.
Časem naštěstí došlo na zjednodušení a sjednocení popisované výše. Výsledkem tohoto zjednodušení jsou tzv. „základní profily“ (anglicky Baseline Profiles) a pro snazší rozlišení jsou jejich jednotlivé úrovně nyní označovány jako Baseline-B, Baseline-T, Baseline-LT a Baseline-LTA, zkratkami B-B, B-T, B-LT a B-LTA. V kombinaci s příslušnými formáty pak jde o profily, jako např. PAdES Baseline-T či jen zkratkou PAdES B-T. To je také to, co svým uživatelům říkají nejrůznější nástroje a služby pro práci s elektronickými podpisy, viz následující obrázek.
Referenční a nereferenční formáty
To, že jde o tyto „baseline“ profily, současně znamená, že jde o podpisy či pečeti v tzv. referenčních formátech, jak je definuje Prováděcí rozhodnutí Komise (EU) 2015/1506. Byť toto rozhodnutí se stále ještě odkazuje na první verzi Baseline profilů od organizace ETSI, dnes již nahrazenou novější verzí.
Faktický rozdíl mezi novějšími referenčními formáty a staršími nereferenčními je v tom, že u těch referenčních je více atributů podepisovaných, a tím i chráněných proti případné změně (bez potřeby dalšího „zafixování“).
Starší (nereferenční) formáty přitom vychází ze standardu jménem PKCS#7, který původně připravila ještě společnost RSA a který pod názvem CMS (Cryptographic Message Syntax) následně upravila organizace IETF pečující o internetové standardy. Proto jsou tyto formáty často označovány jako CMS/PKCS#7. Setkat se lze i s jejich označením PAdES Basic, podle standardu ETSI řady TS 102 778, část 2. z roku 2009.
Příklady toho, jak nereferenční formáty indikují služby DSS a SecuSign a jak Adobe Reader, ukazuje následující obrázek.
Jak jsme si již naznačili v předchozích dílech, některé nástroje a služby již nereferenční formáty odmítají ověřovat. Nebo alespoň na jejich zastaralost upozorňují (jako služba SecuSign na předchozím obrázku). Jiným, jako třeba podatelnám soudů či Czech POINTům, naopak nijak nevadí.
Řada nástrojů a služeb pro elektronické podepisování dnes už ani neumožňuje vytváření podpisů či pečetí v nereferenčních formátech. Výjimkou je v tomto ohledu hojně používaný Adobe Acrobat Reader, který je naopak defaultně (od výrobce) nastaven tak, aby vytvářel podpisy právě v nereferenčním formátu. Potřebnou změnu nastavení ukazuje následující obrázek.
Místo defaultního „PKCS#7 – Odpojeno“ (což odpovídá nereferenčnímu formátu PKCS#7) je třeba nastavit „Ekvivalent rozšíření CAdES“. A mimochodem, k nezvyklé terminologii, kterou jsou pojmenovány obě varianty: ačkoli v obou případech je výsledkem „zabalený“ (enveloped) podpis, vnořený do struktury PDF souboru do části vynechané z tvorby otisku, nejprve je samotný podpis vytvářen jako samostatný („odpojený“, resp. detached), a teprve pak je umístěn (vnořen) do PDF souboru.
Co bude příště
V dalším, snad již posledním dílu tohoto seriálu, si rozebereme konkrétní příklady elektronických podpisů v různých úrovních (B, T, LT a LTA) a hlavně to, jaké to má důsledky pro jejich aktuální digitální kontinuitu. Také si konečně ukážeme, jak se starat o udržování aktuální digitální kontinuity „v malém“, pro jednotlivé dokumenty. A to „ručně“, pomocí běžně dostupných nástrojů (Adobe Readeru) a online služeb.
