1

I would like to implement a process on our ERP for digital sign via web-browser documents that are stored on a server. The process should be:

  1. The user log in
  2. The user look the pdf files stored on the server that should be digital signed
  3. The user select the pdf files to digital sign
  4. The documents will be digital signed

The digital sign could be done with a smartcard, or with a server-side sign system. Any idea how it could be implemented?

Radim Köhler
  • 122,561
  • 47
  • 239
  • 335
user2468007
  • 11
  • 1
  • 2
  • possible duplicate of [Signing PDFs on a server document using a signature from the user](http://stackoverflow.com/questions/10656100/signing-pdfs-on-a-server-document-using-a-signature-from-the-user) – Eugene Mayevski 'Callback Jun 09 '13 at 10:53
  • Also see http://stackoverflow.com/questions/13228106/x-509-digital-signatures-encryption-workflow-library-recommendations and check my answers there. – Eugene Mayevski 'Callback Jun 09 '13 at 10:53
  • Are you talking about integrated PDF signatures? Or separate CMS or XML dsig signatures? Or still other ones? – mkl Jun 09 '13 at 15:56

3 Answers3

6

Please read chapter 4 of this book: http://itextpdf.com/book/digitalsignatures

Your main problem is that signing requires a private key. This private key is stored on a smart card and it can't be extracted from that card (let alone sent over the internet) for obvious reasons.

As you probably know, the actual signing is done on the chip of the smart card, not on the client's computer and even less on the server! This means that you'll need client-side software that uses PKCS#11 to create the the signature. (An alternative would be to use MS-CAPI, but that would only work on Windows.)

You have different options: you can create the hash of the PDF that needs to be signed on the server, and send that hash to the client application to get it signed. Or you can send the PDF to the client and do the complete signing on the client.

Note that my book about digital signatures is already a tad outdated. We've written a better way to implement so-called "deferred signing".

Nevertheless, the fact remains that saying you want server-side signing involving a smart card that physically resides on the client-side is a contradition. Any solution that meets that need would violate every security concern.

Bruno Lowagie
  • 75,994
  • 9
  • 109
  • 165
  • Electronic signing of anything anywhere is already insecure cause what the user sees and what is actually signed are different things (some hash, unknown to user, is signed, not the document). Then the certificate is *trusted*, which implies possible security violation. So your comment makes little sense. – Eugene Mayevski 'Callback Jun 09 '13 at 10:51
  • 1
    You're right when you say it's very insecure when you create a hash on the server-side and have it signed on the client-side: the end user has no idea what he's actually signing. I don't approve of this "solution", but I know that many developers implement it this way. Nevertheless: my remark that the OP is contradicting himself is correct. Asking a server-side signing solution to sign with a smart card on the client-side doesn't make sense. I have no idea why you 've spend a reputation point downvoting my answer. – Bruno Lowagie Jun 09 '13 at 16:29
  • You're wrong in the whole statement - distributing signing is as (in)secure as local one, no more no less. – Eugene Mayevski 'Callback Jun 09 '13 at 18:02
  • @Eugene There are differences. When you sign locally (and have a certain knowledge of what electronic signing is all about), you can easily check whether the signature is appropriate. In case of solutions where the document bytes are not as such present on your computer but merely on the server, you cannot do that. If you don't trust your locally created signature, you can delete it. A server side signature is already public. – mkl Jun 09 '13 at 20:26
  • @mkl from technical point of view there's no difference. If you don't trust something, you don't go ahead rather than do something silly and then try to revert it. When you have a PDF document locally, I have yet to see how you (or how many people in the world at all - maybe 200-300?) would calculate hashes by hand to ensure that signing is performed over the correct hash. And even then you would have to inspect the signing code to ensure that the signing of one hash is done and not of the hash of some other document in parallel. – Eugene Mayevski 'Callback Jun 10 '13 at 06:19
  • @Eugene from the technical point of view there *is* a difference: If I have the document and the signature local, I *can* technically check the signature and refrain from forwarding it to others; if I don't have them locally I technically can *not*. Of course, hardly anyone will ever check a hash manually; but if you trust another program to correctly calculate hashes etc, a check becomes feasible. If on the other hand one has a fundamental distrust concrning computers in general or one's own one, I admit, there is no difference... – mkl Jun 10 '13 at 07:48
5

[Disclosure: I work at CoSign]

What you're describing is done, securely, by our customers all the time (using open, standard, PKI digital signatures).

Digital Signature signing is usually done on a "Secure Signature Creation Device (SSCD)". This is often a smart card but does not have to be. One important alternative is a secure centralized system. That's what CoSign and some other companies sell.

How it works: software that you, CoSign or someone else writes takes the documents from the ERP system and computes the doc's digital signature hash. The hash is sent, with authentication information for the signer, to the centralized SSCD. The SSCD then computes the digital signature and the result is sent back to the requesting system. The signature is then added to the document per the standard (eg pdf). Result: a signed pdf file. (Or signed Word doc, or signed XML etc.)

Note that the signer's private key never leaves the SSCD. CoSign has a SSCD model that includes a FIPS certified tamper-proof case. If anyone opens the case, all of the private keys are immediately destroyed. See description.

For integrating with your ERP system, we have pre-built connectors and multiple APIs.

For more info, contact sales at arx.com. Tell them Larry sent you.

Larry K
  • 47,808
  • 15
  • 87
  • 140
  • "The signature is then added to the document per the standard (eg pdf)" I am stuck on this part. Is there any open source tool for this job? e.g. inserting cert, signature and timestamp into PDF file according to https://www.adobe.com/devnet-docs/acrobatetk/tools/DigSig/Acrobat_DigitalSignatures_in_PDF.pdf – Xi 张熹 Jun 24 '17 at 16:23
1

If the smartcard is physically on the client side, then something has to run on the client computer, regardless of whether there is a server component or not. This is because the signature is calculated on the smartcard itself, and only the computer that the smartcard is connected to can talk to it, so something has to run on the client.

The two options are:

  • Have the client software handle the entire signing process, from reading the PDF, feeding the required content to the smartcard, receiving the response signature from the smartcard, and inserting the signature into the PDF, or

  • Have the client software coordinate with the server to receive the PDF hash from the server, feed it to the smartcard, receive the response signature, send that back to the server, and then the server can insert the signature into the PDF (with variations of this scheme possible).

In either case, creating the signature has to happen on the client side, in the smartcard device.

Gerald Holmann
  • 302
  • 1
  • 8
  • We have implemented what is said above in sample .NET Project available for download with complete source code http://help.signer.digital/digital_signing_and_authentication_from_web_browser.htm – Bharat Vasant Jul 14 '21 at 13:08