Mi változott egy PDF-ben az aláírás után

Az aláírás egy PDF felett nem tiltja meg a későbbi változtatásokat. Bájtartományt rögzít, és az inkrementális frissítés új bájtokat fűz utána, tehát az aláírás matematikailag érvényes marad, miközben a dokumentum új tartalmat szerez. Az, hogy az a tartalom elfogadható-e, politikai kérdés, és a DocMDP az a hely, ahol a szerző kimondja a politikát: semmilyen változtatás nem, csak űrlapkitöltés és aláírás, vagy ezek plusz annotációk. Érvényesítése azt jelenti, hogy osztályozni kell, mi változott valójában, és ezt végzi az AnalyzeModifications. Irányítsa egy korábbi revízióra, majd olvassa a GetModificationLevel visszatéréséből az összesített ítéletet, és a találatonkénti elérőkből az egyes különbségek szintjét, objektumszámát és leírását

Ha ez megvan, a DocMDP érvényesítése egyetlen összehasonlításra zsugorodik: a kiszámított szint a politika által megengedett szinten vagy az alatt van-e

Miért számít rá, hogy egy aláírt PDF változik

Három jogos eset létezik, és ezek lefedik a legtöbbet abból, amit látni fog. Egy második aláíró hozzáteszi az aláírását. Egy címzett kitölti azokat az űrlapmezőket, amelyeket a szerző nyitva hagyott. És hosszú távú érvényesítési anyag csatlakozik: OCSP válaszok és CRL-ek kerülnek a dokumentumbiztonsági tárolóba, hogy az aláírás a válaszadók eltűnése után is ellenőrizhető maradjon. Ez az utolsó nem csupán megengedett, hanem az, amit egy jól kezelt archívum szándékosan tesz az aláírt dokumentumokkal

Tehát a „fájl növekedett az aláírás után” állítás nem hordoz információt. A kérdés mindig az, hogy mi került hozzáadásra, és a válasz a dokumentumállapotok összevetéséből kell jönnie, nem a bájtok figyeléséből. A hozzáfűzési mechanikát magát a inkrementális frissítési cikk tárgyalja

Osztályozzon az objektum alakja, ne az előállító út szerint

Az osztályozó arra néz, hogy az objektum mi a változás után, nem arra, melyik függvényhívás hozta létre. Ez szándékos, mert az elemzés más szoftverekkel előállított fájlokon fut, ahol nincs megvizsgálható hívási út

Négy alak ismerhető fel. A dokumentumbiztonsági tároló és az érvényesítéssel kapcsolatos információs szótárak, a kereszthivatkozási folyamobjektumok, a katalógus metaadat-bejegyzése és a bájtartományt hordozó aláírási szótárak hosszú távú archívum anyagai. Az az objektum, amely mezőtípust és mezőértéket egyaránt hordoz, űrlapkitöltés. Az az objektum, amelynek típusa annotáció, vagy amelynek altípusa szerepel az ISO 32000-2 168. táblázatában, annotációváltozás. Minden más osztályzatlan

Az eltávolítások szigorúbban kezelendők, mint a hozzáadások. Egy eltávolított objektum csak akkor kerül a fehérlistára, ha a régi oldali objektum maga is archív anyag volt, ami lefedi a biztonsági tároló újabbra cseréjének szokásos esetét. Minden más eltávolítás osztályzatlan, mert tartalom törlése egy aláírt dokumentumból nem az, amit engedélyszint megengedhet. A dokumentumszintű különbségek még szigorúbbak: az oldalszám változása egyenesen osztályzatlan, egyes objektumok megvizsgálása nélkül, mert egyetlen DocMDP szint sem enged meg oldalak hozzáadását vagy eltávolítását

A fehérlista az elutasítás felé hibázik

Ez a tervezési szabály, amely minden határesetet kormányoz. Egy tévesen megengedettnek osztályozott változtatás olyan aláírás, amely a szerző által soha nem engedélyezett tartalom felett validál. Egy tévesen az osztályzatlanok közé sorolt változtatás olyan dokumentum, amelyet megjelölnek, és ember néz meg. Ez a két hiba nem szimmetrikus, tehát a fehérlista szűk marad, és a fel nem ismert alakok az osztályzatlanba esnek, nem találgatás tárgyai

Ennek előre látható gyakorlati következménye van: a szokatlan termelőktől származó fájlok néha osztályzatlan változtatásokat jelentenek, amelyek megvizsgálva ártalmatlanok. A helyes válasz a találat részletének és az objektumszámnak a megnézése, nem a fehérlista szélesítése, mert az a fehérlista, amely egyes jelentések elhallgattatására nő, nem marad biztonsági ellenőrzésnek

uses
  PDFlibrary, PDFlibCompare;

var
  Pdf: TPDFlib;
  I, Level: Integer;
begin
  Pdf := TPDFlib.Create(nil);
  try
    Pdf.LoadFromFile('contract-countersigned.pdf', '');
    if Pdf.AnalyzeModifications('contract-as-signed.pdf', '') < 0 then
      raise Exception.Create('the earlier revision could not be loaded');

    // TPLModificationLevel sorrendje mlNone, mlLTAUpdates, mlFormFilling,
    // mlAnnotations, mlUnclassified; a getter a sorszámát adja vissza
    Level := Pdf.GetModificationLevel;
    // A DocMDP érvényesítés mostantól egyetlen összevetés a politikával
    if Level > Ord(mlFormFilling) then
      for I := 0 to Pdf.GetModificationFindingCount - 1 do
        Report.Add(Format('object %d, level %d: %s',
          [Pdf.GetModificationFindingObjNum(I),
           Pdf.GetModificationFindingLevel(I),
           Pdf.GetModificationFindingDetail(I)]));
  finally
    Pdf.Free;
  end;
end;

Az összesített szint a maximum minden találat fölött, ami az egyetlen védhető aggregáció: egy dokumentum, amely kilencvenkilenc archív hozzáadást és egy osztályzatlan változtatást tartalmaz, egy osztályzatlan változtatás

A felszín alatt: ujjlenyomatok, nem titkosítási hashek

Az az összehasonlító motor, amelyet a CompareWith tesz ki, és amelyre a módosításelemzés épül, az objektumokat normalizált testük ujjlenyomatával azonosítja, egy nem kriptográfiai 64 bites hash használatával, SHA-256 helyett. Ez átgondolt választás. Amire a strukturális összehasonlításnak szüksége van, az determinizmus: ugyanazon objektumtestnek mindig ugyanazt az ujjlenyomatot kell előállítania egy futáson belül. Ütközésállóságra nincs szüksége, mert az a támadó, amely az összehasonlítás mindkét oldalát uralja, más úton már nyert, és a teljes titkosítási hash fizetése minden objektum fölött egy egymillió objektumos dokumentumban valós költség haszon nélkül

Két normalizációs szabály fontosabb, mint a hashválasztás. A közvetett hivatkozások helyőrző tokenné hajlanak össze a hivatkozott tartalom kifejtése helyett: a kifejtés egy megosztott objektum testét minden hivatkozóba másolná, tehát egy megosztott betűleíró kis szerkesztése érvénytelenítené minden, ahhoz elérő objektum ujjlenyomatát, és a jelentés olvashatatlan lenne. És maguk az objektumszámok kimaradnak az ujjlenyomatból, mert egy átírás újraszámozhatja az objektumokat anélkül, hogy bármi szemantikai változna

Az illesztés ezután két menetben fut, előbb ujjlenyomat szerint igazítva, majd a maradékot objektumszám alapján párosítva, hogy változtatásokat azonosítson hozzáadás plusz eltávolítás helyett. Az olcsó ellenőrzések végig első helyen járnak: az oldalszámkülönbség még bármilyen objektumbejárás előtt jelentésre kerül

Egy csapda: az önmagával való összehasonlítás nem garantáltan azonos

A diff-motor természetes első tesztje az, hogy egy fájlt önmagával hasonlít össze, és kijelenti, hogy az eredmény azonos. Ez az állítás itt nem áll fenn, és az ok tanulságos. A publikus betöltési út és az alsóbb szintű dokumentumbetöltési út nem azonos módon konfigurálja a dekódolást, tehát ugyanaz a fájl a két útvonalon betöltve olyan ujjlenyomatokat állíthat elő, amelyek egyes objektumokra eltérnek. A motor nem téves; a két betöltés valóban különböző memóriabeli állapotokat állított elő

A két út egymásra erőltetése helyett az összehasonlítási szemantika szűken van kimondva: az elemzés az aktuális dokumentumállapotot veti össze egy korábbi revízióval, és csak akkor jelent azonosat, amikor a két ujjlenyomat-halmaz pontosan egybeesik. Ez az a kérdés, amelyet a felhasználók ténylegesen feltesznek, és nem követeli meg a két betöltő felcserélhetőségét. Amikor összehasonlítási funkciót tervez, az „azonos” jelentésének meghatározása több munka, mint annak kiszámítása

Hol használja

Két helyen. Érvényesítési jelentésben, az aláírásellenőrzés mellett, hogy a véleményező ne csak azt lássa, hogy az aláírás titkosítási szempontból ép-e, hanem azt is, mi történt a dokumentummal utána; az aláírás oldalt a PAdES aláírás és érvényesítés tárgyalja. És beérkezési kapuban, ahol a kívülről érkező dokumentumot az elküldött példánnyal vetik össze, hogy egy hozzáadott annotációval visszaküldött szerződést másképp kezeljenek, mint egy szerkesztett oldallal érkezőt

Egy megjegyzés a hatókörhöz. Ez az elemzés azt mondja meg, mi változott ugyanazon dokumentumvonal két revíziója között. Nem mondja meg, hogy a látható tartalom félrevezető-e, hogy egy űrlapmező megjelenési folyamata egyezik-e az értékével, vagy hogy a takaró alatt rejtett szöveg még jelen van-e a tartalomfolyamban. Ezek külön kezelést igényelnek, és a tartalomeltávolítás oldalát a valódi szerkesztési cikk tárgyalja. Az elemzési és összehasonlítási belépési pontok a losLab PDF Developer Library terméklapon vannak dokumentálva