Razvrstavanje promena u PDF-u nakon potpisivanja

Potpis preko PDF-a ne zabranjuje kasnije izmene. On fiksira opseg bajtova, i inkrementalno ažuriranje dodaje nove bajtove posle njega, pa potpis ostaje matematički valjan dok dokument stiče novi sadržaj. Da li je taj sadržaj prihvatljiv pitanje je politike, i DocMDP je mesto gde autor izjavljuje politiku: nikakve izmene, samo popunjavanje obrasca i potpisivanje, ili to plus anotacije. Sprovođenje nje znači razvrstavanje onoga što se stvarno promenilo, što je ono što AnalyzeModifications radi. Uperite je na raniju reviziju, pa pročitajte GetModificationLevel za sveukupnu presudu i pristupnike po nalazu za nivo, broj objekta i opis svake razlike

Kada je to na mestu, sprovođenje DocMDP-a svodi se na poređenje: da li je izračunati nivo na ili ispod nivoa koji politika dopušta

Zašto se od potpisanog PDF-a očekuje da se menja

Tri legitimna slučaja, i pokrivaju većinu onoga što ćete videti. Drugi potpisnik dodaje svoj potpis. Primalac popunjava polja obrasca koja je autor ostavio otvorenim. I dugoročni materijal validacije se dodaje: OCSP odgovori i CRL-ovi upisani u document security store dokumenta da potpis ostane proverljiv i posle nestanka respondenata. Taj poslednji nije samo dopušten, to je ono što dobro vođena arhiva namerno radi sa potpisanim dokumentima

Pa "datoteka je narasla posle potpisivanja" ne nosi informaciju. Pitanje je uvek šta je dodato, i odgovor mora doći iz poređenja stanja dokumenta, a ne iz posmatranja bajtova. Mehanika dodavanja sama pokrivena je u članku o inkrementalnom ažuriranju

Razvrstajte po obliku objekta, ne po putu koji ga je proizveo

Razvrstač gleda šta objekat jest posle izmene, a ne koji poziv biblioteke ga je stvorio. To je namerno, jer analiza radi nad datotekama proizvedenim drugim softverom, gde nema dostupnog puta poziva za ispitivanje

Četiri oblika prepoznaju se. Rečnici document security store i informacija vezanih za validaciju, objekti cross-reference toka, unos katalog metapodataka, i rečnici potpisa koji nose opseg bajtova materijal su dugoročne arhive. Objekat koji nosi i tip polja i vrednost polja jeste popunjavanje obrasca. Objekat čiji je tip anotacija, ili čiji je podtip jedan od navedenih u ISO 32000-2 tabeli 168, jeste izmena anotacije. Sve ostalo nerazvrstano je

Uklanjanja tretiraju se strože od dodavanja. Uklonjeni objekat je na beloj listi samo kada je objekat na staroj strani bio sam arhivski materijal, što pokriva normalan slučaj security store-a zamenjenog novijim. Svako drugo uklanjanje nerazvrstano je, jer brisanje sadržaja iz potpisanog dokumenta nije nešto što nivo dozvole ovlašćuje. Razlike na nivou dokumenta strože su još: promena broja stranica ide pravo na nerazvrstano bez ispitivanja pojedinačnih objekata, jer nijedan DocMDP nivo ne dopušta dodavanje ili uklanjanje stranica

Bela lista greši u pravcu odbijanja

Ovo je pravilo dizajna koje upravlja svakom graničnom odlukom. Izmena pogrešno razvrstana kao dopuštena jeste potpis koji validira preko sadržaja koji autor nikad nije ovlastio. Izmena pogrešno razvrstana kao nerazvrstana jeste dokument koji bude označen i pregledan od strane osobe. Te dve greške nisu simetrične, pa bela lista ostaje uska i neprepoznati oblici padaju na nerazvrstano umesto da se pogađa o njima

To ima praktičnu posledicu vrednu predviđanja: datoteke od neobičnih proizvođača će ponekad izveštavati nerazvrstane izmene koje su, pri ispitivanju, bezopasne. Ispravan odgovor je pogledati detalj nalaza i broj objekta umesto da se proširi bela lista, jer bela lista koja raste da utiša pojedinačne izveštaje prestaje biti bezbednosna kontrola

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 redosled mlNone, mlLTAUpdates, mlFormFilling,
    // mlAnnotations, mlUnclassified; getter vraća svoj redni broj
    Level := Pdf.GetModificationLevel;
    // Sprovođenje DocMDP-a sada je jedno poređenje sa politikom
    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;

Sveukupni nivo je maksimum preko svih nalaza, što je jedina branjiva agregacija: dokument koji sadrži devedeset i devet arhivskih dodavanja i jednu nerazvrstanu izmenu jeste nerazvrstana izmena

Ispod: otisci, ne kriptografski heševi

Motor poređenja koji CompareWith izlaže, i na kojem je analiza izmena izgrađena, identifikuje objekte otiskom njihovog normalizovanog tela koristeći nekriptografski 64-bitni heš umesto SHA-256. To je promišljen izbor. Ono što strukturno poređenje traži jeste determinizam: isto telo objekta mora uvek proizvesti isti otisak unutar jednog izvršavanja. Ne traži otpornost na sudare, jer napadač koji kontroliše obe strane poređenja već je pobedio drugim sredstvima, a plaćanje punog kriptografskog heša nad svakim objektom u dokumentu od milion objekata stvaran je trošak bez koristi

Dva pravila normalizacije važnija su od izbora heša. Indirektne reference sklapaju se u token rezervisanog mesta umesto da se rašire u referencirani sadržaj: širenje bi kopiralo telo deljenog objekta u svakog referrera, pa bi jedna mala izmena deljenog font deskriptora poništila otisak svakog objekta koji do njega dopire, i izveštaj bi bio nečitljiv. A sami brojevi objekata isključeni su iz otiska, jer prepisivanje može prenumerisati objekte ne menjajući ništa semantički

Upoređivanje zatim radi u dva prolaza, poravnavajući po otisku prvo i sparivajući ostatak po broju objekta da identifikuje izmene umesto dodavanja plus uklanjanja. Jeftine provere dolaze prvo kroz sve: razlika u broju stranica izveštava se pre nego što bilo kakav obilazak objekata počne

Zamka: samopoređenje nije zajamčeno da bude identično

Prirodan prvi test za diff motor jeste uporediti datoteku sa samom sobom i tvrditi da je rezultat identičan. To tvrđenje ovde ne važi, i razlog je poučan. Javni put učitavanja i niži put učitavanja dokumenta ne konfigurišu dekodiranje identično, pa ista datoteka učitana kroz dve rute može proizvesti otiske koji se razlikuju za neke objekte. Motor nije pogrešan; dva učitavanja iskreno su proizvela različita stanja u memoriji

Umesto da se dva puta prisile zajedno, semantika poređenja izjavljena je usko: analiza upoređuje trenutno stanje dokumenta sa ranijom revizijom, i izveštava identično samo kada se dva skupa otisaka poklope tačno. To je pitanje koje korisnici stvarno postavljaju, i ne traži da dva učitavača budu zamenljivi. Kada dizajnirate funkciju poređenja, definisanje šta "isto" znači više je posla nego njegovo računanje

Gde ga koristiti

Dva mesta. U izveštaju validacije, uz proveru potpisa, pa recenzent vidi ne samo da li je potpis kriptografski netaknut nego i šta se dokumentu desilo posle; strana potpisa pokrivena je u PAdES potpisivanju i validaciji. I u ulaznoj kapiji, gde se dokument koji stiže spolja proverava u odnosu na kopiju koju ste poslali, pa vraćen ugovor sa dodatom anotacijom tretira se drugačije od onog sa uređenom stranicom

Jedna napomena o obuhvatu. Ova analiza vam govori šta se promenilo između dve revizije istog porekla dokumenta. Ne govori vam da li je vidljivi sadržaj obmanjujući, da li appearance tok polja obrasca odgovara svojoj vrednosti, ili da li je tekst sakriven ispod prevlake i dalje prisutan u toku sadržaja. To traži odvojeno tretiranje, i strana uklanjanja sadržaja pokrivena je u članku o pravoj redakciji. Ulazne tačke analize i poređenja dokumentovane su na stranici proizvoda losLab PDF Developer Library