I am building a basic workflow in ColdFusion 2016 where the user has to collect signatures/approval for a project.
For various reasons, the user wants to be able to send out a PDF and collect back the digitally signed file for upload.
I am probably overthinking the process, but I am wanting to check the returned document against the internal record of who was supposed to be signing the document (it would also make it easier on the end-user since I can automatically mark the signature as received).
Using CFPDF I can validate that the document is signed and that the signature is valid, but I would like to be able to extract who signed it if possible (to test that the person who signed it was the person who was supposed to sign for it).
Any ideas??
You have not shared any code so I have no idea what you have tried but according to the documentation ColdFusion 11 added support for reading signatures from PDF files.
CFPDF Documentation
Introduced in ColdFusion 11: Use the action ="sign", "unsign", "validatesignature", "readsignaturefields" for creating a digital signature, removing the digital signature, validating the signatures of a document, and for reading the signature fields respectively.
Further down at the bottom of the documentation:
For action ="readsignaturefields":
Reads all the signature fields and returns a query object in the variable indicated by attribute name. This query object will have five columns. The five columns are:
a) Signed - fully qualified name of the signature field.
b) Authored - indicates if this field can contain an author signature or not.
c) Can_Be_Signed - whether this field can be signed.
d) Can_Be_Authored - tells if this field is already signed or not
e) Visible - tells if the field is visible.
<!--- Read info about signature fields in a input pdf in a variable and dump it --->
<cfpdf action="readsignaturefields"
source="#filepath##inputfilename#" name="signinfo"
password="owner" />
<cfdump var="#signinfo#"/>
Related
I am trying to use Apache PdfBox to sign pdf and verify signature. I use examples: https://svn.apache.org/viewvc/pdfbox/trunk/examples/src/main/java/org/apache/pdfbox/examples/signature/
If I add, for example, new page to document, then Acrobat Reader says, that signature is incorrect (ofcourse, because document was changed). But, when I verify signature via pdfbox methods - signature is correct (because ByteRange of signed data does not cover incremental updates).
How I can check disallowed incremental updates (changed data, pages, locked forms, etc)? And skip check allowed updates, such as new signatures or unlocked fields.
I want to implement "parallel" signing process of PDF, so that users can digitally sign document not "one by one", but simultaniously. To implement this, I decided to create separate copies of initial document for all users and get signatures on them. Eventually, all signatures should be concatenated into single PDF.
Let's assume, that PDF is not changing during signing process, except signature field creation (all acroForms, signatureContainers, visual signatures, etc. are created before and similar for all).
.. during futher investigation, I readed this article and understood, that each previous digital signature (even detached) is included into SignedContent of the next signature. So there is no way to put digital signature which will be completely separated from the contents. This leads to a problem, that next signature, can't be calculated, before previous is finished.
Please tell if there is any option to get around this? Or putting signatures "one by one" is the only solution?
P.S. I'm using Apache PDFBox to work with PDF.
Please tell if there is any option to get around this?
If you want your signatures to be interoperable, there is no way around that.
I readed this article and understood, that each previous digital signature (even detached) is included into SignedContent of the next signature
That answer still represents the current situation. If anything, it has been confirmed by newer specifications, e.g. the PAdES specifications referenced in that answer merely were 'technical specifications' (ETSI TS 102 778) and there now are actual norms (ETSI EN 319 142) which also require a pdf signature to sign everything in its revision except its own signature container. Also ISO 32000-2 has been published, still having that requirement for its interoperable signatures and additionally including a shortened copy of the PAdES specification.
You stress "even detached" here. The "detached" in the context at hand only refers to the structure of the CMS container which is embedded in the PDF; it in particular does not refer to the signature being more separated from the PDF or anything like that.
If you don't need to be interoperable, though, there are some options, here two of them which still are quite near to the interoperable signatures:
You can ignore the requirement that a pdf signature must sign everything in its revision except its own signature container.
For example you can prepare multiple signature fields and dictionaries in a single new revision of the document and set each signature's signed byte range to exclude the placeholders of all these signatures.
you can ignore the requirement that there is only a single SignerInfo in the CMS signature container and put SignerInfos from different signing parties into a single signature container in a single signature field.
Common PDF signature validators will,
in case of signatures created as described in the former option, not positively validate, at least most of them,
either because their code is programmed for only two ranges of signed bytes (i.e. a single gap) and so only uses the first two ranges resulting in a wrong document hash;
or because they explicitly require that a signature covers its whole revision minus the single placeholder for the signature container of the signature field being validated; the number of validators of this kind surely has risen since the publication of the "Security of PDF Signatures" master thesis by Karsten Meyer zu Selhausen at the Ruhr-Universität Bochum, see this question.
in case of signatures created as described in the latter option, appear to positively validate, at least many of them, until you look at the validation result in detail and realize that they have validated only one of the SignerInfos and ignored the others.
For example in case of two SignerInfos Adobe Reader validates the second one (I assume it always validates the last one) and eSig DSS validates the first one, and neither one of them currently indicates in the validation result that there may be another SignerInfo present.
A large Swedish security company, for example, implements the second option in its software; in its home brew format PDF/CAdES-A it inserts CAdES-A containers as CMS container in PDFs and allows multiple SignerInfos therein. Obviously, therefore, its own software will recognize and validate all SignerInfos. Nonetheless, this is a home brew solution and not interoperable.
You could use existing software that supports signature workflows - like e.g. we offer at https://www.esignanywhere.net - this software allows to define signature workflows (via API or web user interface). Input can be a PDF document with signature fields as acro form fields, or text placeholders within the PDF. The meta informations defined in eSignAnyWhere allow to assign it to a specific signer. The workflow capabilities allow to define sequential, parallel, or mixed sequential+parallel, signing workflows.
Given a digitally signed PDF with a certificate I do not have the private key to, is it possible to alter the document, sign it with my certificate and keep the previous signature as 'history', that is, the old signature should not verify the integrity of the document, rather the user should just be able to see that it was once signed with this other certificate?
If it's your intention to remove the old signature (created with someone else's private key), alter the document, and add a new signature (using your own private key), then yes, that's possible.
If it's your intention to keep the old signature, and add a second (a so-called approval) signature (using your own private key), then it depends on the nature of the first signature (if that signature "locks" the document, it's not possible) whether or not you can alter the document in-between.
Moreover, altering the document will almost always invalidate the original signature. See Which operations are allowed on a digitally signed PDF? to find out which changes are possible (e.g. filling out a form field) and which changes are impossible (e.g. adding an extra page).
A not so elegant workaround that is used to tackle this by at least one of our customers, is to wrap the signed PDF in a PDF portfolio, and to add a cover page with additional info. A PDF portfolio is like a ZIP file that can be opened in Adobe Reader (and some other PDF viewers). That ZIP file can contain all kinds of other documents, including unaltered signed PDF's in which the signatures are kept intact.
Maybe this one would fit better on so security? I'm not sure...
These are the facts:
We have a web app where users download a PDF document with a form, they fullfill this form, sign it with their electronic certificate and upload it back to our environment.
We've shown cases where the uploaded document is signed, but it show some fields that have been altered after the signature. If we check the integrity of PDF signatures, it shows that have been data alteration after the signature, but the signature it's fine and valid.
If we right-click on the signature and select "See signed version" we see the real data loaded on the moment of the signature.
Now, this goes against my general perception of electronic signature functionality. If any change is made to the document (or the data loaded into it) after I make a signature, this signature should become invalid, as the document has been altered.
The behaviour of the PDF seems to be different, as not only the signature still is valid, also the "default version" that you see when you open the document is the last one, not the signed one.
Now I'm wondering
Is this some kind of bug or is a expected behaviour?
There is any place where info on the matter can be found? (google keeps redirecting me once and again to "how to sign a PDF" articles).
If this is a defined behaviour, how do you deal with it?
Now, this goes against my general perception of electronic signature functionality. If any change is made to the document (or the data loaded into it) after I make a signature, this signature should become invalid, as the document has been altered.
The behaviour of the PDF seems to be different, as not only the signature still is valid, also the "default version" that you see when you open the document is the last one, not the signed one.
Is this some kind of bug or is a expected behaviour?
It is expected behavior.
You have to be aware of two special factors here:
A PDF signature field contains the information of the byte ranges signed. Obviously not the whole file can be signed as the signature itself is embedded and cannot be part of the signed bytes. Thus, the signed bytes ranges need to be recorded somewhere. Cf. this answer on Information Security Stack Exchange:
Additions to a PDF can be made by appending to the existing document, a process called an incremental update. These updates can again be signed etc., also cf. the answer referenced above:
Thus, making changes to a PDF by means of an incremental update, the existing integrated signatures in the document still correctly sign their respective signed by range. They still are mathematically valid in spite of the added changes.
Furthermore the current contents of a PDF are defined in particular by the newest incremental update, so when you open the document it shows the content including the last changes, not the signed one.
Now, while this sounds like PDF signatures have no meaning, this is not the case. The specification ISO 32000-1 clearly defines which changes are allowed to be made in an incremental update to a certified (= signed with some special flags) base version of a document, and Adobe in their Acrobat and Reader software have extrapolated restrictions from this for signed but not certified documents, cf. this answer on stack overflow.
In particular at most the following changes are allowed:
Adding signature fields
Adding or editing annotations
Supplying form field values
Digitally signing
If this is a defined behaviour, how do you deal with it?
As the documents originate from you, you can start by applying a certificate signature to the document which only allows as little changes as possible in your use case.
Then you can define signature lock information for the signature fields your users are to sign. In these lock information you can e.g. prescribe that after signing the given signature field, a number of form fields shall be read-only.
Finally you only accept back PDFs which still contain your certification signature and to which no disallowed changes were added.
There actually are numerous PDFs which are certified and contain a number of fields for additional approval signatures, and each of the approval signature fields is coupled with some form fields which will not be editable anymore after signing. After all the signature fields are signed, all fields are read-only.
There is any place where info on the matter can be found? (google keeps redirecting me once and again to "how to sign a PDF" articles).
You should in particular look at the PDF specification ISO 32000-1 and some Adobe documents on the behavior of their software. You'll find links at the bottom of the stack overflow documentation page the above mentioned links point to.
I am developing an archiving system that stores documents in a database and provides various functionalities to the user. I have added a part to sign and verify any document in the database. However, I am stuck with the logic and wondering where should I place the signing function.
Hints about my aims:
No document should be uploaded on the database without a signatureIf a document is not changed it should retain its signatureIf the document does not own a signature .. it should be signed with uploader's signatureThe signature will not encrypt the file so it will still be readable after the signing process is applied
The initial solution I have used is to place the signing procedure in in the form that is called by the Upload button and store the signature of the file in a separate column in the Documents table in the database. However, that solution turned out to be invalid for my scenario as if an employee downloaded a file and then uploaded it again, then it will be signed by him and thus, the original signature will be lost. Also, the signature will be with no significance out side the system.
My main question:
Is there a way to store the signature inside the documents?
Hint: My system will deal only with PDF, JPEG, Tiff, MS Office and TXT Documents.
Subsidiary Request: It would be awesome if there's a way to store the signature in any type of files!
Is there a way to store the signature inside the documents?
A digital signature must be built using a hash of the document that is being signed. Since adding a signature to a document modifies the document (which invalidates the hash), there is no general solution to storing a digital signature inside a document.
Some document formats allow for digital signing and define what portion is to be excluded from the hash, but those formats that were listed—as far as I know—are not among them. (Though PGP could be used on TXT documents.)
Since signatures sign the hash of a document, you could simply create a table mapping hashes to signatures. Thus, downloading and re-uploading a document will not remove existing signatures, since the hash will remain the same. The usefulness of this approach depends, of course, on the semantic meaning of a signature in your system.