Hlavní navigace

Vlákno názorů k článku Podvržené jméno a změna PDF po podepsání? Pro většinu PDF čteček žádný problém od anonym - Z původního článku jsem toho moc nepochopil a...

  • Článek je starý, nové názory již nelze přidávat.
  • 6. 5. 2019 22:32

    bez přezdívky

    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.

    Opravte mne, jestli se pletu:
    • 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...

  • 7. 5. 2019 9:18

    Filip Jirsák

    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ý.

  • 7. 5. 2019 10:50

    bez přezdívky

    "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é.

  • 7. 5. 2019 19:44

    Filip Jirsák

    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.

  • 7. 5. 2019 12:24

    Ravise

    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.

  • 7. 5. 2019 13:22

    null null (neregistrovaný) 167.98.22.---

    Tyhle chyby vznikají tak, že někdo prostě píše SW na omezeném vzorku nějakých mustrů, zde PDF a prostě ho nikdy nenapadne jestli není i jiná možnost jak do rozmanitosti vzorků, tak do nahlédnutí do specifikace ... naprosto normální, setkal jsem se s tím "stokrát". Někdy je za tím nedostatek zkušeností, někdy lenost, jindy zas hloupost ...

  • 7. 5. 2019 14:09

    Jarda Kuba

    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.

  • 7. 5. 2019 20:25

    Filip Jirsák

    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.

  • 7. 5. 2019 21:19

    Jarda Kuba

    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. :-).

  • 7. 5. 2019 21:40

    bez přezdívky

    Ehm,

    Nelze li získat danou informaci z certifikátu, může object /Sig obsahovat klíč /Name s patřičnou informací.

    Tedy i jinak: Obsahuje li object /Sig klíč /Name s hodnotou, pak tato informace není součástí ceritifkátu.

    Chyba není v PDF Readeru, ale v programu které dané PDF vygeneroval, protože vygeneroval něco, co neměl.

  • 7. 5. 2019 21:51

    Filip Jirsák

    Nelze li získat danou informaci z certifikátu, může object /Sig obsahovat klíč /Name s patřičnou informací.
    Nikoli, specifikace neříká, že existuje nějaká vazba mezi /Name a certifikátem.

    Tedy i jinak: Obsahuje li object /Sig klíč /Name s hodnotou, pak tato informace není součástí ceritifkátu.
    Ve specifikaci nic takového není.

    Chyba není v PDF Readeru, ale v programu které dané PDF vygeneroval, protože vygeneroval něco, co neměl.
    Na tom nezáleží. Když řešíte bezpečnost, vždy musíte počítat s tím, že útočník udělá něco, co by dělat neměl. To je jako kdybyste napsal, že žádné HTTPS není potřeba, protože nikdo nemá poslouchat cizí přenosy na síti. No, nemá. Ale to k zajištění bezpečnosti nestačí.

    Mimochodem, specifikace říká, že tam má být jméno osoby nebo orgánu podepisujícího dokument. Což může být jméno z certifikátu, ale v některých případech to může být i něco jiného. Například mohu mít vydaný certifikát jen na e-mailovou adresu (beze jména), v /Name by pak ale stejně mělo být mé jméno a ne e-mail.