John created PDFBOX-6289:
----------------------------
Summary: Incremental signing of an encrypted PDF leaves non-zero
(encrypted) bytes in the /Contents padding
Key: PDFBOX-6289
URL: https://issues.apache.org/jira/browse/PDFBOX-6289
Project: PDFBox
Issue Type: Bug
Components: Signing
Affects Versions: 3.0.8 PDFBox
Environment: MacOs: 27.0.1 (26A434)
Java: openjdk 17.0.20.1
BouncyCastle: 1.70
pdfsig: 26.10.0
pyHanko: 0.31.0 (CLI 0.2.0)
Reporter: John
Attachments: TestSign.java, bentopdf-pdfbox.png, bentopdf-pyhanko.png,
check-contents.sh, document-enc-signed-pdfbox.pdf,
document-enc-signed-pyhanko.pdf, document-enc.pdf, sign_pyhanko.py
When I sign a AES-encrypted pdf with addSignature() and saveIncremental(),the
resulting pdf's signature itself is valid and even tools like pdfsig and
pyhanko reports it as valid with the whole document covered. The CMS is parsed
as proper DER with openssl asn1parse.
But the issue is with the bytes after the CMS inside the `/Contents` are not
zeros. When pdfbox is used the `/Contents` string is 32 bytes longer than the
reserved size, which matches an AES-CBC IV plus one padding block, and the tail
looks random. So it appears that the placeholder is encrypted when written, and
my CMS only overwrites the first part of it. As far as I know, /Contents should
not be encrypted.
This would not be a issue with most readers but some strict validators reject
this as `Invalid Signature`. One of which is BentoPDF which reports the
signature as invalid and says "Signature /Contents is not a single DER object
followed by zero padding" for the encrypted pdf signed with PDFBox (screenshot
attached) but when the same encrypted pdf signed by pyhanko it accepts it and
shows the signature details(BentoPDF does not need password to validate
signatures).
Comparison (shell check attached, output below):
{code}
(test_env) ➜ pdfbox-test sh check-contents.sh document-enc-signed-pdfbox.pdf
document-enc-signed-pyhanko.pdf
document-enc-signed-pdfbox.pdf: /Contents=16416 bytes, CMS=1827 bytes,
tail=14589 bytes, non-zero hex chars in tail=27295
document-enc-signed-pyhanko.pdf: /Contents=8192 bytes, CMS=1972 bytes,
tail=6220 bytes, non-zero hex chars in tail=0
(test_env) ➜ pdfbox-test
{code}
Related: PDFBOX-2729 (encrypted signing support). Also asked on Stack Overflow:
https://stackoverflow.com/questions/80012295/incremental-signature-on-an-aes-encrypted-pdf-leaves-encrypted-bytes-in-the-con
Reproducer attached (TestSign.java): it loads document-enc.pdf (password 1234),
signs it and saves incrementally. Any RSA PKCS12 works for the key.
Is there a supported way to keep the placeholder unencrypted, or is this a bug?
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
