Nemrég Psenák Péter kollégám hívta fel a figyelmemet egy érdekes szövegre a PDF-aláírások kapcsán. A szöveg az Adobe Reader aláírás-ellenőrző ablakában, a "Revocation" fül alatt szerepelt egy kísérleti aláírás állománynál. A furcsaságot pedig az "embedded in the signature" félmondat jelentette a korábban már megszokott "embedded in the document" helyett. Az eltérést megvizsgáltuk közelebbről is, és kiderült, hogy ilyen elvileg nem fordulhatna elő a PKI világban...
Az átlagos felhasználó már annak is örül, ha látszólag nincs probléma, ha a "Signed and all signatures are valid." feliraton túlmenően még esetleg a hosszú távú archiválhatóságot jelző "Signature is LTV enabled" szöveget is látja. Az átlagos felhasználó nem gondol bele, hogy az "embedded in the signature" vajon mit jelenthet.
Nézzük is meg közelebbről! Az aláírás ebben az esetben egy CMS adatstruktúra (a PDF-aláírásoknál a legtöbb piaci megoldás CMS/PKCS#7 típusú adatot pakol be). Ebben lehetnek aláírással védett (signedAttrs) és nem védett (unsignedAttrs) elemek. Az előbbiek - ahogy a nevük is jelzi - még a CMS aláírás létrehozásához szükséges lenyomatképzésben részt vesznek, le vannak fedve az aláírás által (maga az aláírandó adat jelenik itt meg), az utóbbiak viszont már az aláírás létrehozása után kerülnek be (jellemzően IETF RFC 3161 időbélyegeket, illetve a visszavonási adatokat szokták így utólag beágyazni). A visszavonási adatok viszont - ebben az esetben - az aláírással védett részekbe (signedAttrs) kerültek bele, ahogy azt az alábbi ASN.1 kép is mutatja.
Az alábbi jegyzet alapján látható, hogy melyik érték mihez tartozik.
Gondoljuk végig az aláírás létrehozásának folyamatát ennél az esetnél! Az aláírással védett részbe (signedAttrs: 05814 és 10427 offset között) még az aláírás létrehozása előtt bekerül a visszavonási adat (jelen esetben OCSP válasz). Ennek időpontját (producedAt) az 05985 offset jelzi, értéke 2015-01-28, 08:44:51. Az OCSP válasz állapotának (certStatus) értéke "good" a 06071 offset-nél. Ezután készül el az aláírás (signature), amelynek értéke a 10442 offset-nél található, majd lekérésre kerül egy időbélyeg, amely már az aláírással nem védett részbe kerül (unsignedAttrs). Az időbélyeg dátuma (genTime) a 10875 offset-nél található, értéke 2015-01-28, 08:44:57. Szeretném hangsúlyozni, hogy bár ennél a példánál csak 7 másodperccel későbbi az időbélyeg, mint a visszavonási adat, ez a különbség lehetne sokkal több is (vannak olyan folyamatok, ahol pl. napokkal később, az ellenőrző szerver kéri csak le batch feldolgozás során az időbélyegeket). Amit látni kell, az a feje tetejére állított PKI-logika: a visszavonási adatok vizsgálata ugyanis az aláírás létrehozásának hiteles időadata alapján kell, hogy történjen, ezen hiteles időadatot pedig az időbélyeg szolgáltatja. Az OCSP válasznak az időbélyeg után kellene lekérdezésre kerülnie, nem pedig előtte! A sorrend megfordítása megtévesztő lehet, illetve nem is tekinthető szabványosnak (ld. alábbi ábra a folyamat lépéseiről az ETSI dokumentumából).
Ez az eset nem jelenti azt, hogy az összes PDF-aláírás rossz (értsd: szabványba ütköző, alapvető PKI logikát sértő) lenne. Azt viszont jelenti, hogy engedi rosszul használni a PKI logikát, és erre nem is figyelmeztet az Adobe Reader, ezáltal a felhasználó könnyen megtéveszthetővé válik. Kérdés, hogy egy átlagos felhasználó erre mennyire tud figyelni, illetve van-e olyan folyamat, ahol megéri egy ilyen hibán alapuló támadást véghezvinni...
Kapcsolódó anyagok:
|
