-2

I used nitro pro 10/11 to edit a signed PDF document.

Adobe reader can recognize the docs content has been modified, but integrity check is ok by iText (V5.5.6/V7.0.2).

How can i check whether the integrity is correct using iText?

Joris Schellekens
  • 8,483
  • 2
  • 23
  • 54
  • Itext only checks whether each signature signs its signed ranges properly (integrity check), not whether later changes are allowed by former signatures (additional checks). – mkl Mar 16 '17 at 07:20
  • Tks, but how can i check a docs just the same as Adobe Reader by itext? – babylove Mar 16 '17 at 08:20
  • When edit a pdf doc, its hash values changed. how to verify its hash value by itext. – babylove Mar 16 '17 at 08:29
  • *"When edit a pdf doc, its hash values changed."* - It's not that trivial with PDFs. Integrated PDF signatures also contain an entry stating which byte range they sign in the PDF. So, if someone edits a PDF using an incremental update, the changes are appended to the file and, therefore, don't change the hash of the byte range of existing signatures. Thus, the iText integrity check of the signature correctly says that the signatures correctly sign their respective byte ranges. – mkl Mar 16 '17 at 09:00
  • To help you more concretely, please share your iText integrity check code and a sample document for which that check returns success while you are sure it shouldn't. – mkl Mar 16 '17 at 09:02
  • You might want to read the stack overflow documentation area on [Integrated PDF signatures](http://stackoverflow.com/documentation/pdf/5161/integrated-pdf-signatures#t=201703160903502574891). – mkl Mar 16 '17 at 09:05
  • Hi,mkl. you can get a sample signed pdf : https://alimail.fadada.com/signed.pdf ; and modified by nitro editor: https://alimail.fadada.com/signed&modify_by_nitro.pdf – babylove Mar 16 '17 at 09:52
  • I'll look at that later this afternoon. – mkl Mar 16 '17 at 11:32
  • Does my answer post below answer your question? Or are there still aspects to clear? In the former case please accept the answer (click the tick at its upper left), in the latter case please name them. – mkl Mar 21 '17 at 07:31
  • @Makyen I re-edited the question – Joris Schellekens Jul 11 '18 at 08:59

1 Answers1

0

iText offers an API to validate each integrated signature and to check whether it covers the whole document. It does not check, though, whether changes in incremental updates are allowed changes.

Some backgrounds

PDFs can be changed by a mechanism called incremental updates. This mechanism only appends to the file leaving the original bytes unchanged. With each such incremental update a new revision of the file is added to the file.

Integrated PDF signatures sign the complete revision of the document in which they were added to the file with the obvious exception of the actual signature bytes.

Thus, a signature of a former revision still correctly signs its byte ranges even if a later revision completely changes how the PDF is displayed.

As in common signing use cases content someone signed should not be arbitrarily changed, the PDF specification only considers very few types of changes in incremental updates to signed revisions valid, cf. this answer on stack overflow and the documents referenced from there.

What iText's API offers

iText offers an API to validate each integrated signature, in particular this validation checks whether that integrated signature correctly signs the bytes it applies to.

iText furthermore determines whether a signature covers the whole file, i.e. the latest revision of the file.

iText does not offer simple API functions, though, that check whether the changes in incremental updates to signed revisions are all allowed.

This task actually is decidedly non-trivial as the allowed changes are not specified in deep detail; I am not aware of any proper open source implementation of it. Even Adobe Reader in its code for this check has many false negatives for PDFs in which the allowed changes are implemented differently than Adobe Reader would have done it itself, e.g. see this answer.

iText does offer the low-level tools to implement such tests, though, so anyone is welcome to implement them on top of iText.

iText checks in code

You can execute the checks with iText 5.5.10 like this:

PdfReader reader = new PdfReader(resource);
AcroFields acroFields = reader.getAcroFields();

List<String> names = acroFields.getSignatureNames();
for (String name : names) {
   System.out.println("Signature name: " + name);
   System.out.println("Signature covers whole document: " + acroFields.signatureCoversWholeDocument(name));
   System.out.println("Document revision: " + acroFields.getRevision(name) + " of " + acroFields.getTotalRevisions());
   PdfPKCS7 pk = acroFields.verifySignature(name);
   System.out.println("Subject: " + CertificateInfo.getSubjectFields(pk.getSigningCertificate()));
   System.out.println("Document verifies: " + pk.verify());
}

(VerifySignature test testVerifyBabyloveSigned)

The outputs for the OP's sample files are:

babylove_signed.pdf
===================
Signature name: Fadadaf1a333d3-d51a-4fbb-ad22-bbdcaddd7d8e
Signature covers whole document: true
Document revision: 1 of 1
Subject: {C=[CN], OU=[fabigbig, Individual-1], CN=[051@???@352229198405072013@2], O=[CFCA OCA1]}
Document verifies: true


babylove_signed&modify_by_nitro.pdf
===================
Signature name: Fadadaf1a333d3-d51a-4fbb-ad22-bbdcaddd7d8e
Signature covers whole document: false
Document revision: 1 of 2
Subject: {C=[CN], OU=[fabigbig, Individual-1], CN=[051@???@352229198405072013@2], O=[CFCA OCA1]}
Document verifies: true

As you see, signed.pdf has only one revision, its integrated signature is valid, and it covers the whole file. signed&modify_by_nitro.pdf has two revisions, its integrated signature is valid but it covers only revision one.

Thus, iText says that while the signature in the latter file does correctly sign its revision, there may be any amount of changes in the second revision.

Community
  • 1
  • 1
mkl
  • 90,588
  • 15
  • 125
  • 265
  • @Joris Your bot killed a link and un-beautified code by overly large code indents. I rollback. – mkl Jul 11 '18 at 11:07