Názory k článku Podvržené jméno a změna PDF po podepsání? Pro většinu PDF čteček žádný problém

Ten, kdo pracuje s PDF s elektronickým podpisem, má v zásadě dvě možnosti práce.

První možností je nechat dokument převést do listinné podoby (na CzechPointu, u notáže, u advokáta). Při přecodu do listinné podoby se k dokumentu připojuje ověřovací doložka s obsahem praktick stejným, jako při ověření běžného podpisu. Stejně jako u ověření běžnéjho podpisu, není důležité to, co si kdo myslí že vidí ve vlastnoručním podpisu, ale to, co je na doložce. Tento postup je nejběžnější u jednotlivců, u malých firem.

Druhou možností je uchovávat dokument v elektronické podobě. Úskalí je v tom, že platnost ověření podpisu končí s platností ověření certifikátu ověřitele. Tedy několik málo let, obvykle značně méně, než je potřeba zachovávat právní dokument. V tom případě je nezbytné využívat službu, která elektronické písemnosti zachovává a stará se opravidelné přerazítkování, aby ověření certifikátem nevypršelo. V tomto případě opět obsluha vidí informace z certifikátu, nikoliv ty zobrazované v PDF.

Na okraj je ještě dobré připomenout, že u právních úkonů nemusí být podpis v PDF vůbec zobrazený. Např. dokumenty podepsané OVM (orgány veřejné moci) užívají podpis na dokumentu nezobrazený. Je to lepší praxe, protože je potřeba si uvědomit, že elektronický podpis funguje mírně odlišně než běžný vlastnoruční. Vlastnoruční podpis připojujeme do určitého místa, do rubriky pro to určené. Někdy se stává, že na dokumentu je více rubrik pro podpis - jednou se např. podepisuje smlouva, dalším podpisem se potvrzje přijetí zálohy, ..., a umístění podpisu určuje, jakou skutečnost stvrzujeme. To u elektronického dokumentu není možné. Ten je jedním podpisem podepsaný en bloc, a tak unmístění zobrazovaného podpisu je nejenom zbytečné, ale může být naopak i matoucí.

Problém s pozměněnými podpisy v PDF bych tedy považoval za poměrně okrajový. Ten, kdo ze zobrazené části vychází při ověření dokumentu, má v každém případě kriticky špatně nastavený pracovní postup a riskuje v mnohém.

Celkem souhlas, až na ten závěr.
To, že se "lidská" reprezentace podpisu může po zásahu bad guys lišit od elektronické je průšvih. Protože to slavné, jakkoliv podepsané PDF, se totiž vytiskne, účetní to opatří svým podpisem, naskenuje a vloží do šanonu (nebo třeba do spisové služby).
Ostatně, zeptejte se vašich účetních, jak postupují u elektronické faktury.

U faktury je to zhola jedno, podpis nepatří k náležitostem daňového dokladu. Proto poštou chodí faktury (plyn, elektřina, telefon, ...) bez jakéhokoliv podpisu.

(§ 29 zákona o DPH: https://www.zakonyprolidi.cz/cs/2004-235#p29).

Podpis na vystavené faktuře není nutný (i když ho spousta účetních a firem vyžaduje). Přijatou fakturu ovšem typicky podepisuje osoba, která ji schválila k proplacení.

Ještě bych chtěl upozornit, že faktura v PDF není považována za "elektronickou fakturu". Faktura v PDF je listina zaslaná elektronicky.

Elektronickou fatkurou se rozumí kompletně datová výměna (XML). Takovou fakturu však nelze vytisknout (ledaže by někdo doplnil šablonu pro zobrazení / tisk). U těchto "opravdových" elektronických faktur naopak el. podepsání vyžadováno je. S tím ale jednotlivec / malá firma prakticky nepřijde do styku na straně vstupu (uplatnění). Malé firmy elektronické doklady vystavují nejvíc na výstupu (vyžadují to např. obchodní řetězce).

Představte si situaci, kdy útočníci získají databázi osobních údajů (anebo to “vysosají” z veřejných rejstříků) a všem rozešlou PDF, ve kterém je upozorní např. na povinnost uhradit rozhlasový poplatek a přidají k tomu své číslo účtu. A to PDF bude podepsané certifikátem a bude se tudíž tvářit důvěryhodně. Kolik oslovených bez reptání zaplatí? 20%? Máme v ČR více než milion živnostníků... Myslím si, že opatrnost autorů je na místě.

Myslím, že těm dvaceti procentům, kteří zaplatí, bude úplně jedno, zda tam bude nějaký podpis, a zaplatili by to, i kdyby tam byl podpis, který prohlížeč neodkáže ověřit a bude psát varování. A nepodepsané PDF, když platbu tak nějak očekávají, zaplatí 99,9 % lidí – a já jsem mezi nimi, protože když jsem takhle dostal nepodepsaným e-mailem nepodepsaný dokument s platebními údaji a stěžoval jsem si odesílateli, že to může poslat každý, a že by měl alespoň číslo účtu uvést na webu (dostupném přes HTTPS), dostal jsem odpověď, že jsem první, kdo na to upozorňuje, a že to možná v budoucnosti zváží.

My si na toto téma otestovali uživatele. Elektronicky podepsané PDF zvýší důvěryhodnost takového PDF v očích většiny uživatelů.

Úskalí je v tom, že platnost ověření podpisu končí s platností ověření certifikátu ověřitele.
To není pravda, u elektronického stejně jako u vlastnoručního podpisu platí, že je považován za pravý, pokud se neprokáže opak. To, že skončí platnost certifikátu podepisující osoby, tedy znamená akorát to, že může snáz dojít ke sporu. Platnost kvalifikovaných certifikátů je u českých CA jeden rok, myslím, že v zahraničí je to podobné. S tím „ověřitelem“ je to předpokládám jenom překlep – ověřitel žádný certifikát mít nemusí. Navíc veřejnoprávní instituce, od kterých ty právní dokumenty budete mít asi nejčastěji, mají povinnost přidávat k podpisu časové razítko.

To, že skončí platnost certifikátu podepisující osoby, tedy znamená akorát to, že může snáz dojít ke sporu.

A oprávněně. Platnost certifikátu je mimo jiné způsob jak říct, do kdy věříme, že se útočníkům nepodaří prolomit šifrovací klíče (nebo se jinak zmocnit soukromého klíče). Něco jako minimální trvanlivost na jogurtu. Po skončení této doby musím mít jistotu, že dokument opravdu pochází z doby ze které tvrdí, že pochází. Tedy například na konci období připodepsat, že s dokumentem nebylo manipulováno a opakovat když se bude blížit vypršení posledního podpisu.

A nebo vložit informaci do "blockchainu", nějaké kryptoměny o které budu věřit, že její historii nikdo nebude moct přepsat (čímž nepatrně zvýším poptávku po přepsání historie - kdyby to udělal každý, tak to ta měna nevydrží - najde se někdo komu se vyplatí rozbít její historii).

Vymýšlíte dávno vymyšlené – to „připodepsání“ se řeší časovými razítky.

S tím prolomením jste také vedle, certifikační autority používají stejné algoritmy, stejné velikosti klíčů, mají mnohem důležitější certifikáty, a přitom platnost jejich certifikátů je klidně 10 nebo 20 let. Únik soukromého klíče je něco jiného, nicméně i po skončení platnosti certifikátu je potřeba soukromý klíč držet v tajnosti – resp. ideální je klíč zničit (samozřejmě pokud se následný certifikát není vystaven ke stejné dvojici klíčů).

V právu nikdy nemáte jistotu. Pokud dojde ke sporu, řeší se, jaké jsou důkazy pro a jaké proti. Navíc těch případů, kdy budete potřebovat dokument po delší době, je minimum – a řešení je známé, časová razítka.

Je pravda, že "PDF signature field" nemusí být součástí PDF dokumentu, technicky jde defakto jen o takovou "třešničku pro uživatele". Nicméně pokud některé programy nevezmou informaci o autorovi podpisu z certifikátu a klidně si nechají vnutit podvrženou informaci, to považujeme za problém. Takové programy potřebují opravit a když už na to upozorníme autory, myslím, že je slušnost nám alespoň odpovědět. :-) Jinak osobně považuji za chybu i stav, kdy mohu do pole podpisu vnutit kohokoliv. Řešení v tomto případě je ale složité.

Minulý rok jsem si s tím celkem hrál, protože v ISKN máme také implementované ověřování podpisů a razítek. Ačkoli se to nezdá, tak je to hodně komplikovaná oblast. Nepoučeného uživatele je zmást, třeba byť jen "vhodným" poskládání více verzí s více podpisy uvnitř jednoho PDF atd.

Nebo jsme narazili na případ, kdy jsem vzal podepsané PDF, měnil test a vše se tvářilo OK. Problém byl v tom, že aplikace, která vytvářela podpis, vzala jen malý ByteRange, takže jakákoli změna za ním už nebyla signalizována a podpis se tvářil OK. On tedy OK byl, protože protože podepsaná byla jen malá část dokumentu, ale to uživatelé nevidí.

Udělat spolehlivé ověřování podpisů PDF včetně všech možných kombinací, verzí, včetně razítek apod., není vůbec žádná legrace a držel bych se obdobné poučky jako např. u řešení přihlašování - pokud to jde, tak nedělat vlastní řešení, kde se velmi pravděpodobně nasekají chyby a raději použít něco prověřeného. Problém je, že v této oblasti toho zatím extra moc k dispozici není.

Já malým zákazníkům doporučuju, pokud se rozhodnou elektronické dokumenty přijímat, aby čistě pro jednoduchost čas od času zašli na Czech Point a konvertovali je do listinné podoby. Je to jednodušší pro firmy, kde nemůže existovat vlastní oddělení pro compliance.

Málokdo si např. uvědomuje, že když odešle dokument datovou schránkou, je dodejka platná jen omezenou dobu, jinak se musí nechat přerazítkovat. Zatím jsem neslyšel o případu, že by stát popřel doručení, ale stát se to může. Ještě víc to hrozí u komerčních zpráv, např. při prokazování doručení předžalobní výzvy. Takové zapomenuté přerazítkování může stát spoustu peněz.

Naprosto souhlasím, že je lepší využívat už existující služby a nevymýšlet vlastní řešení.

Nejak jsem to cele nepochopil.
Asi bych potreboval tri obrazky vedle sebe, jak ma spravne vypadat v nejakem programu ze pdf je validni, jak to vypada u zmeneneho pdfka ve vadnem programu a to same v programu bez chyby.
Neco jako presny navod pro nas hloupejsi.

Obávám se, že chyba není na vaší straně.

PDF prohlížeč zobrazuje v samostatném panelu/okně/záložce informace o elektronickém podpisu dokumentu. Pro uživatele nejdůležitější informace jsou kdo to podepsal a zda je podpis platný (v závislosti na konfiguraci prohlížeče – seznamu důvěryhodných certifikačních autorit). Informaci o tom, kdo dokumentu podepsal, má PDF prohlížeč brát z podpisového certifikátu – to je jediná zaručená informace. Např. Adobe Acrobat Reader to zobrazuje správně a u toho dokumentu v článku zobrazí na panelu podpisu správně: „Rev. 1: Podepsal(a): Bc. Jaromír Kuba <kuba@….cz>“.

PDF formát umožňuje ještě tzv. vizualizaci elektronického podpisu, za kterou autoři té specifikace skončí v pekle. Znamená, že autor podpisu může do PDF přidat libovolný text nebo obrázek, který je s podpisem svázaný – lze na něj kliknout a v PDF prohlížeči se pak zobrazí panel podpisu. Ten text a obrázek má ale plně pod kontrolou podepisující osoba – takže jak je vidět na těch screenshotech, klidně tam můžete uvést třeba „Albert Einstein“, i když v certifikátu je uvedené Jaromír Kuba. Na tuhle vizualizaci podpisu se tedy nelze nijak spoléhat a je jenom matoucí.

Podle screenshotu v článku se zdá, že některé PDF prohlížeče berou jméno podepisující osoby z téhle vizualizace, což je mnohem pracnější a hlavně je to špatně. Je to ale jenom můj dohad, v čem ta chyba spočívá, v článku to napsané není a nehodlám zkoušet stahovat různé prohlížeče a hledat, ve kterém možná ta chyba je. Předpokládám, že to udělal už autor článku a třeba někdy vydá pokračování, kde už nějaké informace budou.

Aha, diky to mi hodne pomohlo.

Díky za vysvětlení.

Jo, nakopnut tímto článkem jsem zkusil vložit podpis (Adobe Reader) a to, že certifikát sem, certifikát tam, tam můžu napsat cokoliv je fakt na zabití.

Řešíte neproblém. Vizuální stránka PDF není důležitá.

Můžete vzít PDF, vložit do něj vlastní obsah, vlastní obrázek, vlastní text - cokoliv. A pak podepsat (bez vizualizovaného certifikátu). Takže můžete klidně i vložit obrázek, který se bude tvářit jako "elektronický podpis", nebo tam nakreslíte klikyhák, nebo tam vložíte třeba obrázek z clipartu.

Poté podepíšete dokument. Podpis NENÍ to, co je viditelné. Podpis se musí kontrolovat ve vlastnostech podpisů.

Podobně musíte kontrolovat, jestli druhá strana před podpisem neprovedla v dokumentu nějaké změny (případně revidovat, jestli jsou v pořádku). Pokud k podpisové vizualizaci připíše "Prof. Albert Einstein", je to důvod listinu odmítnout.

Je to úplně stejné jako úkon "uznání vlastního podpisu" u notáře (§ 74 zákona o notářích: https://www.zakonyprolidi.cz/cs/1992-358#p74: "nebo podpis na listině se již nacházející před ním uznala za vlastní"). V takovém případě notář nehledí na to, co čte v podpisu - může to být nečitelný klikyhák, může ten podpis vypadat všelijak podobně. Notář ale vystaví doložku, že podpis je uznán za vlastní. Příjemce listiny pak nestuduje jak podpis vypadá, příjemce listiny zajímá ověřovací doložka.

To není žádný „neproblém“. Pro většinu lidí je podstatná právě ta vizuální stránka, ostatně proto vůbec něco takového jako „vizualizace podpisu“ vzniklo. Bohužel to vzniklo v době, kdy panovala představa, že „jsou to počítače, lidé tomu nebudou rozumět aby tomu rozuměli, uděláme to jako ve fyzickém světě“. (Kalkulačka ve Windows určitě pochází z té samé doby.) Vizualizace podpisu viditelná na první pohled je správná věc, akorát ji musí mít plně pod kontrolou prohlížeč PDF a nesmí být součástí zobrazení dokumentu, právě naopak, musí být viditelně od dokumentu oddělená tak, aby nebylo možné ji v dokumentu napodobit.

Vizuální stránka PDF je důležitá. Ještě důležitější než podpis, který můžeme studovat strukturovaně ve vlastnostech certifikátu, je přeci samotný obsah PDF. Tedy to co podpis pokrývá. V tom je situace mnohem horší a nelze to prostudovat strukturovaně. Lze se jen spolehnout na "vizuální stránku PDF". Ani PDF/A to moc nezlepšuje.

Článek je bohužel taková hodně nafouknutá zprávička. Vlastně celý jeho obsah se dá shrnout do jedné věty: „Některé PDF prohlížeče (neřekneme které) možná chybně zobrazují údaje o elektronickém podpisu, a pak možná mají ještě jinou, ještě tajnější chybu.“

• Seznam prohlížečů, které jste zkoumali, s uvedením, který prohlížeč má kterou chybu.
• Popis problému, alespoň toho, který chcete zveřejnit. První problém není v textu popsán vůbec (resp. po přečtení textu jsem si myslel, že autor vůbec netuší, jak funguje elektronický podpis – teprve po shlédnutí screenshotu jsem pochopil, v čem je problém, a že to autor akorát špatně píše), teprve ze screenshotu se to dá uhodnout. Chtělo by to na tom screenshotu zobrazit přímo i ten certifikát, kterým je dokument podepsán, aby byl vidět ten rozdíl. A hlavně by v textu mělo být popsáno, odkud tedy ty chybující prohlížeče berou údaje o podepisující osobě, když ne z certifikátu.
• Osobně si myslím, že by bylo správné popsat i ten druhý problém. Objevitelé mívají tendenci závažnost přeceňovat. A hlavně současný text článku vede spíš k tomu myslet si, že chyba je na straně autora článku. Popisem té chyby by byla šance ukázat, že problematice rozumí a chyba není na jeho straně.

Na tu druhou chybu s dodatečnou manipulací s obsahem dokumentu jsem zvědavý. Snad to opět bude jen nezkušeností při formulování textu, ale z článku to zatím vypadá, že autor neví o tom, že jeden PDF dokument může obsahovat několik verzí a podepisuje se vždy konkrétní verze. Takže můžete mít jednu podepsanou verzi dokumentu, pak v novější verzi uděláte nějakou změnu, která nejprve není podepsaná, a pak ji může podepsat někdo jiný.

Běžně ty vícenásobné podpisy používáme. Když uživatel vyplní nějaká data, vytvoříme z toho PDF a data přiložíme jako XML přílohu a celé to podepíšeme technickým podpisem, který zaručuje, že ta vložená XML data jsou ekvivalentní s tím, co je v PDF zobrazené. Následně to celé ještě podepíše uživatel svým podpisem jako standardní elektronické podání. Nebo je rozhodnutí elektronicky podepsané úředníkem, a když je rozhodnutí pravomocné, přidá se k dokumentu druhá vrstva s vyznačením data výpravy a data nabytí právní moci, a opět se to celé elektronicky podepíše. Zkontrolovat si pak můžete podpisy obou verzí dokumentu.

Článek působí trochu jako snaha o bombastické odhalení, autor si stěžuje na to, že autoři programů nekomunikují – ovšem jestli komunikace s nimi byla stejně zmatená, jako článek, tak se autorům aplikací vůbec nedivím. Takových hlášení autoři software dostávají spoustu, a je obtížné zjišťovat, zda se za tím zmateným popisem neskrývá nějaká opravdová chyba.

Programátor není spisovatel. Popsané je to podle mě dobře, a to včetně zveřejnění vzorového dokumentu s ukázkou jedné chyby. A důvodů, proč to není tak podrobné a proč nechat výrobcům software časový prostor pro možnou nápravu, je IMHO poměrně dost.

Věc jsme začali řešit v rámci vývoje vlastního software. Určitě tak víme, co jsou revize a také víme, co jsou časová razítka. Software půjde na Github, informací tak bude dost. Jen na to ještě neuzrála ta správná doba, jde částečně o 0-day věc. Pokud jde o detailní technické informace, tak ty uvedeme v dalším článku. Přiložíme i detailní analýzu, s popisem testovaných programů. Je již napsána, elektronicky podepsána a časové razítko od Postsigna má březnové datum. Teď opravdu není cílem dávat někomu návod. Prosím o strpení. Článek neměl být detailním a vyčerpávajícím přehledem. Za mě je článek srozumitelný, nejde o vědecké pojednání. Máme na něj velmi dobré odezvy a také se nám plní e-mailová schránka požadavky na zaslání souborů k analýze. Nicméně děkuji za připomínky, ten začátek jsme skutečně mohli více rozvést.

Určitě tak víme, co jsou revize a také víme, co jsou časová razítka.
Já v to doufám – je ale škoda, že po přečtení článku o tom čtenář pochybuje.

Software půjde na Github, informací tak bude dost. Jen na to ještě neuzrála ta správná doba, jde částečně o 0-day věc.
Ty zranitelnosti přece s vaším softwarem nijak nesouvisí. To podstatné, co teď chybí, jsou úplně jiné informace. To nejdůležitější je, které PDF klienty jste testovali, které jsou zranitelné a které nejsou. Tajením téhle informace uživatelům určitě nepomůžete, maximálně tak útočníkům. Pokud by chtěl té chyby se zobrazením údajů o podepisující osobě někdo zneužít, už teď od vás má návod, jak takové PDF vyrobit. Pokud to bude zkoušet plošně, je mu úplně jedno, že tu chybu má jen některý PDF klient. A pokud bude útočit na někoho konkrétního, buď to zkusí, nebo si zjistí, jaký PDF prohlížeč dotyčný používá, a vyzkouší si to v něm. Takže tajení seznamu postižených programů rozhodně ničemu nepomáhá, spíš naopak. Alespoň v případě té první chyby.

Teď opravdu není cílem dávat někomu návod.
V případě té první chyby už jste ten návod ale dali.

Článek neměl být detailním a vyčerpávajícím přehledem.
Za mne je otázka, čemu měl článek vlastně sloužit. Pokud by měl sloužit jako varování uživatelů před tím, než dojde k nápravě, musel by obsahovat jasnou informaci, že některé prohlížeče (a seznam těch, u kterých jste to zjistili) nezobrazují u podpisu informaci z certifikátu, ale informaci, kterou může útočník zfalšovat. (Tahle nejpodstatnější informace se dá vyčíst mezi řádky a ze screenshotu, ale explicitně uvedená v článku vlastně není!) Pak seznam prohlížečů, o kterých víte, že touto chybou netrpí, a upozornění, že v těch postižených prohlížečích je potřeba se proklikat až ke konkrétnímu certifikátu.

Zatím je ten článek nejužitečnější pro potenciální útočníky, kterým dává informací dost.

Za mě je článek srozumitelný, nejde o vědecké pojednání.
Kdyby nebyl článek srozumitelný ani pro autora, bylo by to na pováženou… Ne každý má na psaní talent – kdyby měl, tak vyjde na Rootu každý den desítky článků. Ale dá se tomu pomoci třeba tím, že přizvete k editaci někoho, kdo dané problematice nerozumí.

Problém je v tom, že článek je nevyvážený co do zaměření na cílové publikum. Místy psaný úplně pro laiky, jde v zjednodušování tak daleko, že jsou v něm nepravdivá tvrzení – např. „Že nemůže být PDF elektronicky podepsáno Albertem Einsteinem, protože jmenovaný nežije?“ Tady musí zbystřit každý, kdo alespoň tuší něco o PKI a ví, že důvěryhodnost certifikátům dodává až certifikační autorita – ale nedůvěryhodný certifikát na jméno Albert Einstein si může vyrobit každý a když jím podepíše PDF, bude to PDF zcela správně podepsáno Albertem Einsteinem. Po přečtení citované věty čtenář zbystří a dumá nad tím, jestli autor opravdu chce řešit bezpečnost podpisů PDF a neví, co je certifikát – a dál už se to čte jako detektivka, kdy je účelem zjistit, co o problematice vlastně ví autor. A autor toho může vědět spoustu – ale nešťastné formulace v článku to shazují.

Hned po té výše citované větě se článek překlápí do opačného extrému, kdy píše o tom, jakým certifikátem je PDF podepsané, na screenshotu přitom ukazuje informační panel z chybného PDF prohlížeče a nechává na čtenáři-expertovi, aby si uvědomil, že PDF prohlížeče zobrazují zvlášť informace o podpisu a zvlášť o certifikátu, že v těchto informacích může být rozpor, a že rozpor mezi screenshotem a textem článku je daný právě tou chybou v PDF prohlížeči. V dalším textu jsou indicie, které této interpretaci nasvědčují, ale explicitně to není napsáno nikde. Laik už se dávno ztratil, odborník se diví, proč podstatu sdělení článku musí rekonstruovat sám.

Já na vás nechci nijak útočit, jenom mi připadá, že forma úplně neodpovídá obsahu – z čehož plyne riziko, že se tím skutečným problémem nikdo vážně zabývat nebude.

Většina Vašich připomínek je již zohledněna v textu s technickými detaily, myslím, že budete spokojen. :-) Jinak tento článek jsem psal tak, aby mu rozumělo i široké publikum a mohu Vás ujistit, že rozhodně je „testován na lidech“. Předpokládám, že čtenáři Rootu dojde, že nepůjde o „openssl ca“ certifikát a běžného čtenáře nemá smysl zatěžovat s informací, že certifikát lze generovat i svépomocí, protože takovým certifikátem si PDF pro podatelnu obce nepodepíše. Ten článek byl psán tímto stylem celý – možná trochu uvolněně, ale za jeho formou si stojím. Dvojka již bude o poznání odborněji zaměřená, na své si přijde i čtenář, který se rozhodne napsat aplikaci pro elektronický podpis PDF souborů. Samozřejmě s podporou časových razítek od českých kvalifikovaných CA. Hezký večer.

Na mě působí ten článek jako celek dost zmateně, trochu naivně, zavádějící je i příklad s Einsteinem. Myslím, že se stačilo podívat na obvyklý způsob, jakým se zveřejňuji zranitelnosti. Na druhou stranu je nutno ocenit ochotu se o zjištěný problém podělit a snaha přispět k řešení je také pozitivní.

"Nafouknutá" zprávička to úplně není, protože např. Chrome 74.0.3729.131 (a tedy všechny od něj odvozené prohlížeče) nejenže zobrazuje podpis jako platný, ale ani neumožňuje jeho rozklepnutím zobrazit podrobnosti, takže to ani nezkontroluješ. Aktuální FoxIT sice detaily zobrazí, takže to zkontroluješ, ale zobrazuje to taky jako platné. Acrobata jsem nezkoušel, anžto ho nemám a instalovat nehodlám.
A ověřit, že se za tím skrývá chyba, je snadné; stačí si ty odkázané soubory zobrazit a hned vidíš, v čem je problém.

Ta první chyba je spíš vlastnost. Do viditelného podpisu si podepisující může dát co chce, směrodatné je jméno na certifikátu.
To druhé bych viděl podobně- dokument lze i po podpisu změnit inkrementální úpravou a úpravu eventuálně znovu podepsat. Pro tyhle případy má třeba AdobeReader funkci "zobrazit podepsanou verzi", kdy se zobrazí pouze to, co bylo podepsáno. Pokud toto prohlížeč nepozná, je to samozřejmě chyba.

Uvažujete správným směrem. Jde o následnou úpravu, kterou prohlížeč zobrazí jako součást původní revize. Žádná následná revize se v Acrobatu nezobrazí. Jinak k chybě jedna: Tam je největší problém to, že některé prohlížeče si nevezmou jméno z certifikátu a jako autora podpisu zobrazí podstrčenou informaci a ta se objeví i ve vlastnostech podpisu. Hezký den.

Z původního článku jsem toho moc nepochopil a odborné komentáře v diskuzi tomu nasadily korunu. Asi jsem příliš široké publikum - jinými slovy, připadám si jako idiot.

• PDF = Portable Document Format původně vycházel z PostScriptu (podmnožina či zjednodušení?) a sloužil k přesnému popisu toho, co se má vytisknout na papír. Byl to výstup, který se posílal do tiskárny.
• Postupně se z PDF stal kontejnerový formát, který může obsahovat prakticky libovolná data.
• Některá z obsažených dat jsou běžně "vidět", neboť pořád ještě popisují to, co se má vytisknout.
• Jiná data běžně vidět nejsou, ale různé prohlížeče dokážou různé části dat uživateli nějak zobrazit.
• Některé části dat se dají digitálně podepsat (privátní klíč/veřejný klíč, čáry máry -- certifikáty), ale je obtížné zjistit, která část je či není podepsaná a kým vlastně.
• Podpisy jsou taky data a taky se dají podepsat...
• ... a tady už si nemůžu pomoct, připadá mi, že je v tom děsný bordel.

Co třeba se vrátit k čistému textu, verzovat v gitu, podepisovat SHA256 (nebo jiné) otisky -- a každý by do toho viděl bez použití složitých prohlížečů?

Já vím, jsem idiot...

Na PDF se pořád můžete dívat jako na formát pro popis zobrazení dokumentu. Ta data navíc, která se nezobrazují, jsou v kontextu tohoto článku nezajímavá. Digitálně se vždy podepisuje celý aktuální dokument. Další změny v takovém dokumentu se dají dělat jedině tak, že vezmete celý ten podepsaný dokument a k němu se přilepí něco jako patch – ten původní dokument ale zůstává beze změny, dá se zobrazit a jeho podpis ověřit. Teda samozřejmě můžete změnit i ten původní dokument, ale pak selže ověření podpisu.

K čistému textu se nelze „vrátit“, čistý text samotný se nikdy nepoužíval. Lidé vnímají vizuálně, nejprve se používaly jen obrázky, pak se k tomu přidal i text, ale pořád byl důležitý celkový vzhled. To, že se počítače v určité době daly používat jenom pro práci s čistým textem a zobrazení se pak řešilo jinde a jinak bylo omezení počítačů.

S podepisováním PDF nejsou žádné zásadní problémy. Z článku teď víme o jedné chybě, že některé méně používané PDF prohlížeče zobrazují v informacích o podpisu, které mají být věrohodné, údaje z PDF dokumentu, které má plně pod kontrolou autor, místo aby zobrazily údaje z certifikátu. Mně navíc ta chyba připadá nepochopitelná, protože ty chybné prohlížeče čtou data, která nemají pevně danou strukturu a v PDF ani být nemusí, místo aby načetly jednoznačné údaje z certifikátu. Nebo-li ten chybný kód musí být podstatně složitější a nejspíš jako fallback obsahuje ten správný kód.

Mimochodem, SHA-256 není podpis, je to otisk – poznáte podle něj, že se dokument nezměnil, ale o osobě nevíte vůbec nic. Jeden dokument má jeden SHA-256 otisk, pak ho může podepsat třeba deset různých lidí, a ten otisk původního dokumentu bude pořád stejný.

"Mimochodem, SHA-256 není podpis, je to otisk"

Pokud si přečtete příspěvek, na který reagujete, pozorně, uvidíte, že je v něm to samé.

Pokud si příspěvek, na který reagujete, přečtete ještě pozorněji, uvidíte, že v něm jde něco jiného. Otisk (hash) dokumentu se podepisuje i v PDF. František Grebeníček se proti tomu ale vymezoval, chtěl něco jiného, jednoduššího. Jeho komentář jsem tedy pochopil tak, že chce podepisovat – kým, čím – SHA-256 otisky. Váš výklad samotného spojení jako „podepisovat – koho, co – SHA-256 otisky“ by sice byl možný takto o samotě, ale nedává smysl v kontextu celé věty, která je o změně oproti současnému stavu.

Tak teď tě tvoje grafomanie konečně doběhla: František Grebeníček výslovně mluví o podpisu otisku (podepisovat SHA256 (nebo jiné) otisky), ne o tom, že otisk má nahradit podpis.

Citát: Z článku teď víme o jedné chybě, že některé méně používané PDF prohlížeče zobrazují v informacích o podpisu, které mají být věrohodné, údaje z PDF dokumentu, které má plně pod kontrolou autor, místo aby zobrazily údaje z certifikátu.

Napsal jste to naprosto přesně!

Citát: ...ty chybné prohlížeče čtou data, která nemají pevně danou strukturu a v PDF ani být nemusí...

Toto nesouvisí s obsahem pole podpisu. Podvrženou informaci do souboru dostáváme podobně, jako když chcete do dokumentu nastavit důvod podpisu (jsem autor dokumentu). Některé prohlížeče a nejen ony to prostě vezmou a zobrazí jako informaci o autorovi podpisu, přičemž informaci z certifikátu v danou chvíli ignorují - podvržená informace dostane přednost. Opravdu nechápu, proč to tak je. Zbytek informací viz článek 2.

Zkrátka některé prohlížeče z mapy /Sig zobrazují klíč /Name, o kterém specifikace říká následující:

(Optional) The name of the person or authority signing the document. This value should be used only when it is not possible to extract the name from the signature; for example, from the certificate of the signer.

Holt zde autoři některých PDF prohlížečů porušili staré známé pravidlo, že pokud specifikace říká „should“, můžete něco jiného udělat jedině tehdy, pokud velice dobře víte, co děláte, a problematice rozumíte aspoň stejně dobře, jako autor specifikace.

Stejně ale nechápu, proč to ty programy čtou z tohohle klíče, když je volitelný a tedy stejně musí umět podepisujícího přečíst z certifikátu.

Přesně nad tím také kroutíme hlavou. Programy někdy používají obrácenou logiku - nejdřív údaje z /Sig a až potom z certifikátu. Přitom když se rozkliknou vlastnosti podpisu, objeví se správné jméno - programy tak evidentně zvládnou zavolat X509_NAME_get_en­try, nebo variaci na téma. Jen se divím, že je tento neduh tak rozšířený. Asi CTRL+C a V, Stack Overflow je na tyhle věci prevít. :-).

Děkuji všem za zpětnou vazbu, která je pro nás velmi důležitá. Technické detaily budou ve "dvojce" a v článku jsme to uvedli. Připomínky z diskuse do článku 2 rozhodně zapracujeme, pokud tam již nejsou. Jinak samozřejmě jsme obdrželi i několik podrážděných reakcí (jeden hodně rozčilený pán dokonce volal), nevím, na kolik se projevily i zde v diskusi. Tímto žádám zástupce/zaměs­tnance organizací, které prodávají/dodá­vají/vyvíjejí software, co pracuje s elektronickým podpisem PDF dokumentů, aby to v rámci vyváženosti diskuse u svých příspěvků uváděli. Chápeme, že se někdomu nelíbí, že v dobré víře varujeme uživatele před možnými riziky a že to může kazit "kšeft", nicméně je ve veřejném zájmu informovat o potencionálních zranitelnostech. Čtenáři by měli vědět, kdo argumentuje z pozice nestranného čtenáře článku a kdo nikoliv. Zároveň tímto děkujeme všem zástupcům organizací, kteří nás oslovili s požadavkem na více informací. Zároveň se omlouvám, že jsme dosud nestihli všem odpovědět, napravíme během dnešního dne.

PDF Reference sixth edition
Adobe Portable Document Format
Version 1.7
November 2006

8.7 Digital Signatures

Name text string (Optional)
The name of the person or authority signing the document. This value should be used only when it is not possible to extract the name from the signature; for example, from the certificate of the signer.

39 0 obj<</Type/sig/By­teRange[ 0 233795 249797 590 ]/Contents<3082...
0000>/Filter/A­dobe.PPKLite/M(D:20190­302122502+01'00')/Na­me(ţ˙ A l b e r t E i n s t e i n D r . h . c .)/SubFilter/ad­be.pkcs7.detached>>

Tak kdepak soudruzi z NDR udělali chybu?!?

Zdá se , že už to někdo řešil obecně: https://dspace.cvut.cz/bitstream/handle/10467/61229/F3-BP-2015-Suchy-Ondrej-Analyza_vizualni_integrity_pdf.pdf

Sorryjako:

[niki@lieselotte pdf 10:57:43 0 ]$ pdfsig albert-einstein-1.pdf
Digital Signature Info of: albert-einstein-1.pdf

Signature #1

Signer Certificate Common Name: Bc. Jaromír Kuba

Signer full Distinguished Name: serialNumber=P31675,g­ivenName=Jaro­mír,SN=Kuba,CN=Bc. Jaromír Kuba,OU=1,O=Jaromír Kuba [IČ 72903643],OID­.2.5.4.97=NTRCZ-72903643,C=CZ

Signing Time: Mar 02 2019 11:25:02

Signing Hash Algorithm: SHA1

Signature Type: adbe.pkcs7.detached

Signed Ranges: [0 - 233795], [249797 - 250387]

Total document signed

Signature Validation: Signature is Valid.

Certificate Validation: Certificate issuer is unknown.

[niki@lieselotte pdf 10:58:02 0 ]$

Takže ČEHO jste s tím podpisem dosáhli? Alberta Einsteina asi ne, když ten podpis nese jméno Jaromír Kuba ?? Tady je totiž zásadní otázka, čím (a jak) ty podpisy ověřujete. Protože na linuxu to umí afaik pouze pdfsig a jinak nic. Tedy z normálního softwaru. Když si někdo z netu postahuje kdoví co, tak se pak nemůže divit. A ano, vím, že to mám nedokonfigurované, protože to absolutně k ničemu nepotřebuji.

Dosáhli jsme správné reakce zodpovědných správců a programátorů. Článek splnil svůj účel, i když ne stoprocentně, nicméně i dílčí úspěch (reakce) je úspěch. Zbylé informace viz článek 2. :-)