0

I'm developing a webserver that performs digital signatures of (xml, pdf and office) documents and then validates those signatures.

My idea is: an user puts its SmartCard and through a PIN, he gets his private key. Then, the private key must be sent to the server, so that the server may sign the document with that key.

Even if the private key is transmitted through a SSL channel (HTTPS), is it a good idea send the private key away from the user? What is your opinion? I'm trying to avoid to perform the signatures on client-side, so that the signature service may be accessed by every device.

Regards, William.

2
  • Please don't post both here and on SO, flag the question to be migrated instead.
    – Bruno
    Mar 12, 2014 at 16:31
  • Ok, sorry. I'm new in these forums, I didn't know of that possibility. Mar 12, 2014 at 16:41

3 Answers 3

3

(Just to summarise my answer to this duplicate question on SO and its comments...)

It's certainly bad practice, and it can also be a major legal problem.

Because both the user and your service will technically have had access to the private key, you can no longer guarantee who the actual signer was to a third party.

Do you know any javascript library that signs xml, pdf and office documents? This way, the private key would only be used on client-side.

Don't do JavaScript crypto. You won't be able to prove to the user what your code does (it could still send the key). As far as I'm aware, some of the WebCrypto project was trying to address some of these issues (e.g. by letting some JS code use the private key stored in the browser without letting it out), but it's not quite ready yet, and it doesn't solve all the problems (e.g. proving the the users what they're signing with that private key).

And of course, the technical show-stopper...

Most smartcard mechanisms don't let you get access to the private key itself (often by design), so you'd somehow have to interface with the signature API for the card anyway. That API will not actually give you the private key, it will only let you use it to sign something, the processing being done on the card itself. So, any plan to send the private key somewhere or have some code (that doesn't use this API) use it wouldn't work.

While certificate on smartcards can be used by the browser for client-certificate authentication, because browsers are implemented to support this as part of their own user interface (nothing to do with any webpage you can provide), I don't think there's anything obvious to have a script on your webpage access any of this. (This would also still leave the problem of trusting what your JS code actually signs.)

3
  • I did note your helpful comment on my answer (thank you), and your answer is better in any case, so I'm voting it up :) Mar 12, 2014 at 20:24
  • @suzzy-delta, ah, sorry, I deleted my comment because I thought I was nit-picking...
    – Bruno
    Mar 12, 2014 at 20:28
  • My personal opinion is that it isn't nit-picking if it's true :) Mar 12, 2014 at 22:15
0

Putting the private key on the server breaks the philosophy of public key infrastructure, even if you do transfer it securely.

With the private key now outside the users control, it will be possible for a 3rd party (the server) to impersonate the user. This is clearly a non-repudiation violation - the user could deny a contract on the grounds that he didn't agree to it, the server admin did.

"Every device" should not be able to sign a document as someone else (I am guessing here at your use case). Only the person whose private key it is should be able to sign with it.

What use case do you have that requires this unusual key distribution proposal?

0
0

The idea of pki is that your private key is the sine qua non of your identity. You don't send it anywhere.

Instead of sending it somewhere, put it in one place (a centralized appliance), and remotely request its use. See my answer to the related stackexchange question.

You must log in to answer this question.

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