Interestingly, Adobe has created a cottage industry of certificate providers and has strict security requirements like use of HSMs to prevent private keys from being exposed. As you can imagine, these certificates are stupidly expensive for what they do.
I don’t know that I’d say that. Seems like it'd be useful behaviour to be able to make post-signature modifications so long as it’s clear what they are.
As a concrete example, it’s the obvious way to implement a documented contractual negotiation: party A drafts a contract & signs it, then party B makes modifications & signs the bundle of (original contract, signature, modifications), then party A countersigns party B’s modifications & signature, indicating acceptance.
Or maybe I’m missing something?
The original text was there, and hadn't been modified so the signature was still valid, but the superficial appearance of the document was misleading even if it was possible to identify the tampering if you knew what to do (which I suspect 99.9% of people reading PDFs would never bother doing).
If modifications aren’t clearly called out, then that’s a (bad) bug in the viewer.
To learn more google about "DocMDP" and "FieldMDP"
What you want is to sign the whole file. It looks like the design here is a hack using the existing PDF format instead of adding a container to the PDF. If you want multiple parties signing the same document, you should have a container that allows you to append additional signatures to the container. The idea that you need to have a squiggly line inside the PDF to show that it's valid is really dumb in this context anyways. Instead the PDF reader should show you that "@raul signed this document on 2019-03-06 at 11:47:55 EST, here is his GPG signature", and that's it. No squiggly lines needed.
Edit: As an aside, it is amazing the number of people who think that PDFs can't be edited (and are amazed when even MS Word can do it these days).
Not everywhere, in my country you can get them for free, from institutional CAs included in the EU Trusted Lists that Adobe trusts: https://ec.europa.eu/digital-single-market/en/eu-trusted-lis...
That said, having worked on PDF signature generation in the past, the spec is very complicated, partially due to the structure of PDF documents and how they can be appended, including signed additions.
Violating the TCSDP doesn't mean that your scheme is technically wrong, but it does mean that implementations will often be wrong in funny ways.
It's so important it requires two articles.
As far as I could determine (I've done it and acrobat is happy), it requires fetching and embedding the necessary CRLs for the TSA (timestamp authority) cert chain before getting the signature, but you don't have the certs with the CRL urls until after you get the signature. And the URLs can change over time (our TSA just switched its cert chain, but they did notify us ahead of time).
For US based certificate looking at -
$2000~ for 10k signing via entrust trusted adobe cert.
Not cheap correct
Am I the only one bothered by the fact that there's a bug in that procedure? Before he signed the act, digitally signing wasn't legal, and the act doesn't become law until it's signed, so... I understand why they did this, but as an engineer, I find this problematic XD
Probably not the case, and just a PR gimmick, but still. I like to dream. :)
Are you sure? I don't think there is!
> Before he signed the act, digitally signing wasn't legal,
Is that true? I think this is the source of error here. In your quote citation (the full extent of my knowledge on this topic), it says that the bill being signed is to facilitate the use of those signatures, and to ensure the validity. It doesn't state that it is making e-signatures legal for the first time ever, it's stating that it is clarifying that they are for-sure good-to-go.
I don't think there is a bug in the procedure.
1. PDF file format doesn't support a "whole document signature" as a concept. Instead, it only supports signing arbitrary fragments of the document.
2. PDF tooling/software doesn't warn the user when a PDF contains some signed and some unsigned fragments. Or where fragments have been signed with different certificates.
I think that is the gist of it?
To be backwards compatible, the signature is one of these objects.
1. It's a whole document signature, but you can't sign the signature because you don't have it yet. So you have to leave a hole for the signature data.
2. The specification for where this hole is (/ByteRange) should be in the signed data, some viewers do not appear to be verifying this.
So they're sticking a fake byte range on the signature, extending the hole enough to cover said fake byte range and additional objects (modified pages) and a fake table of contents (at the original offset from beginning of the file).
I'm describing one of the exploits as I understand it.
To further complicate things, you can modify pdf files by appending more objects and a new TOC at the end. Think of this as append-only versioning.
Historically this is used for editing (giving you a revision history) or form filling (adding the text you typed in), but it also is used to add additional signatures. (You have to add to the already signed document if you want a second person to sign it.)
A signature on Version 2 of a file would encompass the entire file including the embedded Version 1 and its signature.
Readers like acrobat can show you each version of file. And they can show you the version of the file as a given person signed it.
If you can spoof the signatures, well, now we can have people saying they got 4.0 GPAs from Stanford with legitimate signatures and all...
And most of the readers you mention don't support signature verification - so they're perfectly secure from this attack ;-)
edit: mutool sign is also vulnerable to SWA.
So, please don't think it's just a problem of incompetent implementations. Yes, these newly-found vulnerabilities are embarrassing and shouldn't have happened, regardless how terrible the standard is, but just implementing the standard correctly (as far as that is even possible, given how vague it is in many regards, lacking a formal grammar and all that) won't result in cryptographically sound signatures.
One user found that a few of the documents he added conflicted with the signature of other PDFs.
I knew that the PDF signature wasn't strong but didn't think we would actually have real world conflicts.
We're already moving to SHA256 of the raw binary data instead of the fingerprint for newer documents added to your repository.
We're going to use the actual strong hashcode to enable "distributed" annotations so that two people annotating the same document can easily discover each other and share comments, highlights, flashcards, etc.
I'm pretty damn excited about this feature actually.
The article ("How to Spoof PDF Signatures") doesn't find any collisions or similar cryptographic weakness. Instead, as you'd expect, what they found was that software doesn't actually implement the cryptography very well. So what is in principle a perfectly good secure signature system can be "spoofed". If you use fixed software, the problem goes away.
NaCL/Libsodium is a very highly regarded crypto library.
So, If I copy your digital signature and attach with my message, the receiver (relying party) would be able to (instantly) determine (through a PKI enabled Application) that I have not signed the message.