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..
Can u help me?
Regards,
William.
Disclosure: I work for CoSign.
The solution is to use a secure, hardware hardened digital signature appliance.
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:
- Send the entire PDF for signing. (Or just send the hash if the client can calculate it.)
- 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.
