Is it ok to send user's private key away, even if protected with a SSL channel?

Question

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.

Answer 1

(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.)

Answer 2

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?

Answer 3

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.