22
Replies
Please share an example PDF before and after signing for analysis.
By MikelKlink
Best is not to share a document with confidential or personal information in. I would create a dummy PDF file and a dummy signature!
I have seen some posts from 2017 about SHA1 and SHA256 and if I change the windows registry so that Adobe will use SHA1, I will not get the error that the document has been changed.So what is it that makes Adobe think the document has changed if I use SHA256?
Considering this observation it might be relevant which kind of signing device you use. In particular is it some smart card or USB token? There had been smart cards a number of years ago that could not correctly sign SHA256 hashes because these hash values didn't fit in a single data packet and chaining of packets was not supported.
The first signature in a document should never be an incremental save. Acrobat and Reader should consolidate all non-signature sections into a single section that is signed.
They consolidate incremental updates, but they consolidate into a linearized PDF. At least the current Reader did so in a testrun I just made.
There actually is nothing in the format or in the specification that requires the first signature to be in the first document revision. Many PDF signing solutions explicitly apply also the first signature in an incremental update.
But indeed, it would be surprising if Adobe Acrobat (Reader) would not consolidate incremental updates from an unsigned original PDF and store the whole file in its own way (which currently appears to be linearized) for signing.
What you write seems logical and I think I found where I turned off the embedding of validation information and the document became very much smaller.
Yes, your new example indeed is without the validation information, without the embedded giant CRL.
But unfortunately the signature is still invalid with the same error message.
Indeed. The signed hash again is incorrect. So while this simplified the use case, it didn't fix the error.
I'm afraid I cannot analyze the issue further without having a similar setup myself, and as I don't have such a Swedish card, that's not possible.
I would propose some tests that would allow you to narrow down the possible cause of the issue. But that would be narrowing down only, not solving the issue:
- Create a self-signed soft-token (using "Create a new Digital ID") with a 2048-bit RSA key and use it to test signing with SHA256. If this doesn't work, something is broken in your Adobe Reader (or operation system crypto routines it may use).
- Install Adobe Reader and smart card drivers on a different computer and test with your card.
- If you have a different card (by a different manufacturer with a different driver), try signing with that card, too, on both test computers.
Well, exploits usually don't need incremental updates, at least not before signing. But rewriting the file indeed gets rid of the dangers by many possible exploits.
Nonetheless, rewriting is not required by the specifications in question, so validators must be good enough to detect all the exploits. Which they aren't yet. But they've gotten much better since https://www.pdf-insecurity.org/ started.
And YES to
unless you have an evil signing program.
The biggest danger most likely is in trusting unknown programs, in particular unknown remote services, to sign documents using your local smartcard or other sscd.
Are there any special Reader settings I should check? I found a page on Adobe where a lot of Registry keys were described but it is difficult to control something when you do not really know what to control.
Unfortunately I've no specific idea as I've not yet had such an issue with the Reader myself. I'd start with a fresh installation on a second computer (or a virtual machine or at least a sandbox), test to sign, and compare settings.
I also do not think I use an "evil signing program" as I use the feature found in Reader, and in Pro. It's probably Adobe itself that created that function, so they should do it in a way that they themselves think is okay.
Yes, the signing feature of Adobe Acrobat (Reader) should not count as evil.
Theoretically there could be some virus / trojan docked in between your Adobe Reader and your smart card driver replacing your signature requests with signature requests for some fraught documents. But that's not very likely.
Acrobat, in addition, performs "Document Modification Analysis" to detect changes to content or field values that may cause the signature to be declared invalid due to "document has been altered or corrupted since it has been signed".
Yes. Their intial implementation thereof was not really usable outside of Adobe-only software use cases as it required not merely that changes were allowed but also that they were done similar to how Adobe software would have done them (e.g. there apparently was a test checking whether the size of the compressed content stream of an instantiated page template was the same as it would be if Adobe Reader had created it). Meanwhile they appear to have made the checks less Adobe Reader specific. In some cases this led to vulnerabilities, though, some of which have been made public on https://www.pdf-insecurity.org/ and elsewhere.
Adobe has not, to my knowledge, documented the internal checks that Acrobat and Reader make to reach that determination.
No, not publicly. And these checks anyways have been changing considerably over time.
In this context the work on ETSI TS 119 102-3 might result in a common, standardized rule set.
It's more complicated than you might think.
Don't worry, I've done some experiments in that regard and come across a number of pitfalls, so I have a pretty good idea of the complications... 😉
AdChoices