3

I'm trying to develop a website that performs digital signatures on client-side and then sent the signed document to the server-side. I want to do the signatures on client, due to the fact of not sending away the user's private key. This key (in theory) must be always with the user and it must not be sent to the web (even if protected with SSL, for example).

I want that every platform may be able to sign the documents. I've already developed a Java Applet with the signing algorithms, but Java is not supported in iOS or Android.. In .NET is impossible too. So I think I'm restricted to JavaScript, but I'm not aware of any javascript library that signs XML, PDF and Office documents.. What should I do? Only with Javascript every platform works..

Improve this question

2 Answers 2

Reset to default
3

Disclosure: I work for CoSign.

You're raising the common question of digitally signing data at the network "edge."

Good luck on the idea of signing at the client/edge, for the reasons that you discuss. And forget Javascript, it is completely insecure from the cryptography point of view.

You're right that the signers' private key shouldn't be sent anywhere.

Good news: there is an alternative architecture that will:

  • Not require that the private keys be sent anywhere
  • Protect the private keys
  • Enable signing from clients of all types including mobile, Android, .Net, iOS, etc.
  • Decrease administrative costs by centralizing the keys and key management

The answer: use a centralized signing appliance. The appliance is hardened at the hardware level: if you try to open the box, the keys are destroyed. Signing appliances are made by my company and some others.

In this system, the document (or better, just its hash) is sent from the edge device to the centralized signing appliance. The user also authenticates with the appliance (using any one of a number of techniques). The appliance holds the private keys. It signs the hash, and returns the digital signature to the edge client.

Depending on the capabilities of the client, it can:

Assemble the signed document itself (combining the digital signature with the source document). Benefit: less data needs to be sent between the edge client and the signing appliance. Issue: requires more sw on the client. Or:

The appliance can return the complete signed document. Benefit simpler implementation on the client but requires that the document be sent to the signing appliance from the edge client.

Note that an entire PDF document doesn't have to be sent back--the PDF digital signature is simply appended to the source document. So the flow can be:

  1. Send the entire PDF for signing. (Or just send the hash if the client can calculate it.)
  2. Receive back either the entire PDF (signed), or just a "tail" that, when appended to the source PDF creates the signed document.

Multiple data types My company supports signing of PDF, Word, Excel, XML and other document types out of the box. Eg Word documents are signed using the Word "standard" -- a digitally signed Word document can be verified by a recipient (relying party) without installing anything beyond Word. No plugins, etc.

Signer Authentication Signers need to authenticate themselves with the centralized appliance. My company supports multiple types of authentication including OTP and 2FA.

Improve this answer
2
  • 1
    It's an interesting appliance, but isn't it a bit at odds with what you said in this other answer ("[..] your private key is the sine qua non of your identity. You don't send it anywhere)? The problem here is that your private key isn't in your hands. Unlike smartcards, you're effectively delegating the authentication to whatever mechanism was used with this box, not necessarily providing as good a (legal) level of assurance as smartcards and private keys. This being said, it's all about trade-offs, and your approach doesn't sound bad at all.
    – Bruno
    Mar 14, 2014 at 13:29
  • Hi Bruno, the appliance acts on your behalf, so, if you trust it, then your keys are your own and they're being held for you and are only being used when you want, by your "valet," the appliance. Thank you for your positive comment.
    – Larry K
    Mar 15, 2014 at 19:56
0

For low to moderate security requirements the delegation is more economical, and there are many solutions for signature services, such as the appliance mentioned in the answer above. However, whatever trustworthiness the signature service provides, it will always rely on the client's capability to authenticate the service. Using default vendor-supplied PKI + vendor-supplied cipher suited there is no defense against a targeted attack.

Java might be a reasonable choice for client-side signatures, except iOS. Not as a java applet, but as java application, something like portablesigner (sourceforge). In principle it should be possible to derive an android app from such a project. iOS will need a separate obj-C app. Considering that you need to manage client keys anyway, the installation of Java seems to be a lesser problem.

Browsers will have the Web Crypto API accessible from Javascript, and it might be worth looking into it once W3C is goin to release it. If one finds a method to bootstrap the Javascript code in a secure way it ca be useful client-side signatures.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .