3
votes

I secured a PDF using Adobe Acrobat and then signed it, but when I try to verify the signature using iText, it gives an error

Exception in thread "main" java.lang.IllegalArgumentException: can't decode PKCS7SignedData object
at com.itextpdf.text.pdf.security.PdfPKCS7.<init>(PdfPKCS7.java:214)
at com.itextpdf.text.pdf.AcroFields.verifySignature(AcroFields.java:2427)
at com.itextpdf.text.pdf.AcroFields.verifySignature(AcroFields.java:2373)
at C5_01_SignatureIntegrity.verifySignature(C5_01_SignatureIntegrity.java:19)
at C5_03_CertificateValidation.verifySignature(C5_03_CertificateValidation.java:42)
at C5_01_SignatureIntegrity.verifySignatures(C5_01_SignatureIntegrity.java:32)
at C5_03_CertificateValidation.main(C5_03_CertificateValidation.java:134)

I am using the sample code from https://developers.itextpdf.com/examples/security/digital-signatures-white-paper/digital-signatures-chapter-5#887-c5_03_certificatevalidation.java

I used a generic PDF, password protected from Adobe Acrobat and then self-signed it from Adobe Acrobat.

1
Please share (a link to) the PDF in question.mkl
Here is the link to both certificate and PDF file, both are protected with password - "password"(without quotes). drive.google.com/drive/folders/…Karan Kapoor

1 Answers

1
votes

The iText 5 security API indeed cannot verify signatures of encrypted documents.

The cause is a deficiency of the decryption code: Just like most other strings it also "decrypts" the values of the Contents key of signature dictionaries. As these are not encrypted to start with, though, this "decryption" actually scrambles them. Thus, the PdfPKCS7 class cannot parse them as signature containers and throws the observed exception.

In contrast to this the iText 7 security API can verify such signatures.

In distinction from the iText 5 situation explained above, decryption of PDF strings here is deferred until their contents actually are used. The signature API, before accessing the content, marks the Contents PDF strings as not encrypted. Thus, their original value can be accessed as is.

(This is a bit risky because some code may retrieve the contents of those strings beforehand and so cause "decryption". On the other hand this removes the necessity to parse the PDF AcroForm information in the PdfReader; as form parsing in general and signature parsing in particular are not part of the kernel module, such a necessity either would have resulted in duplication of code or merging of multiple modules.)

The issue is covered in more detail in this answer.