iText can not verify signed PDF document was edite

This question is an exact duplicate of:

PDF/A signed with iText7 allows changing attached documents without breaking a signature 1 answer

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?

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.