1

I have created a PDF/A document using iText7. The created document has an attachment (). The attachment is a .csv file. Then the whole PDF/A has been signed. I have opened the attached .csv file and changed it after I have signed it. I have used following code to verify the signature:

  public PdfPKCS7 verifySignature(SignatureUtil util, String name) throws GeneralSecurityException, IOException {
    System.out.println("Signature covers whole document: " + util.signatureCoversWholeDocument(name));
    System.out.println("Document revision: " + util.getRevision(name) + " of " + util.getTotalRevisions());
    PdfPKCS7 pkcs7 = util.verifySignature(name);
    System.out.println("Integrity check OK? " + pkcs7.verify());
    return pkcs7;
}

I would have expected that integrity check returned error, but I got:

 Signature covers whole document: false
 Document revision: 1 of 2
 Integrity check OK? true

Is this intended iText behavior and did I misunderstand the intention of a signature? I would expect the WHOLE document to be locked for changes (apart from filling forms or annotations if those are allowed).

What would be the best way to go about signing PDF with attachments in case I want to prohibit attachment changes?

inat57
  • 19
  • 5
  • Please share the PDF, both in its state right after signing and in its state after your manipulation. I ask because the output you got should indeed indicate (unless there is an issue somewhere) that nothing has changed. – mkl Sep 20 '18 at 14:01
  • I could not reproduce the exact output: I must have done something silly like edited the file while in debug mode. I have edited the output. It makes some sense now: it says that signature doesn't cover the whole document and the document revision got higher. I would still expect the attachments to be 'covered' by signature. It is obviously not the case. The original and tempered files are in: [link text] https://www.dropbox.com/sh/jxllhox7ck1owff/AAAD4gerVs6qAqncVV-3T3yGa?dl=0 The tempered file has attachment where the first column name has been altered. – inat57 Sep 21 '18 at 08:16
  • Ah: tempered=>tampered – inat57 Sep 21 '18 at 08:49
  • Ok, see my answer. Essentially this is a duplicate of [this answer](https://stackoverflow.com/a/42856102/1729265), but as that answer has been neither accepted nor upvoted, your question cannot be closed as duplicate of it. – mkl Sep 21 '18 at 09:42

1 Answers1

0

To understand what happens here you have to know that there are multiple ways to save changes to a PDF:

  • You can simply save the manipulated PDF like a whole new document. Doing so will usually change the signed bytes making the Integrity check you ran fail.

  • Or you can add the changes as a so-called incremental update, i.e. append them to the PDF. Doing so will not change the signed byte range making the integrity check you ran succeed.

In your case the edit has been saved using an incremental update. This does not change the signed bytes; thus, the integrity check will succeed because it only checks whether the signature still correctly signs the originally signed byte ranges.

The coverage check (your signatureCoversWholeDocument call) on the other hand informs you that the signature in question does not cover the whole document anymore. Thus, you know that changes have been appended as incremental updates.

Unfortunately iText does not yet offer a high level API to determine the nature of the changes introduced by an incremental update (the iText low level APIs can be used as a base upon which to implement such an API, though).

For some backgrounds on integrated PDF signatures you may want to read this answer and the documents referenced from there.

I would expect the WHOLE document to be locked for changes (apart from filling forms or annotations if those are allowed).

Technically you can add any kind of changes in an incremental update. Incremental updates are not only for use in storing allowed changes to signed documents, they can be used without signatures, too, e.g. to keep a revision history in the PDF or (saved separately) to allow resource efficient storage of PDF edits on WORM devices.

Thus, to determine whether changes to a PDF are allowed or not, the validator has to analyze the additions in the incremental updates.

mkl
  • 90,588
  • 15
  • 125
  • 265