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
  • This question appears to be off-topic and would probably be better on Security.SE.
    – Bruno
    Commented Mar 12, 2014 at 15:51
  • 1
    My idea is - No, you get a PrivateKey object, not the private key. That private key object only represents the key on the card and communicates with the card when signing.
    – mkl
    Commented Mar 12, 2014 at 17:04

4 Answers 4

3

Nope. It is never, ever OK to send the client's key to somebody else. It's called a "private" key for a reason.

5
  • Yeah, it's true but let's face it. Our passwords are always sent to the server.. If the server isn't compromised everything works fine.. And the private key is only used momentarily to sign the document.. If the code is obfuscated there is such a big difference between a private key being sent? I don't like the idea, but as I said all passwords, that are like our private keys, are sent away.. Commented Mar 12, 2014 at 15:49
  • @user3411342, you're not talking of a password to access a resource (which in some cases may not be sent to the resource you're trying to access, by the way, including here on SO), you're talking about signing here. The purpose is completely different.
    – Bruno
    Commented Mar 12, 2014 at 15:53
  • Yes, it's true. I agree with you totally! Thanks for your oppinion. 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.. Commented Mar 12, 2014 at 15:56
  • user3411342: You should probably ask a new question, along the lines of "Is it possible to sign documents (XML, PDF, Office formats) in the browser using JavaScript?" I'm afraid the answer will probably be "no", though -- since "signing" tends to be a proprietary extension that differs for each file format.
    – Coderer
    Commented Mar 12, 2014 at 16:00
  • Yes, but my idea was to sign xml, pdf and office separately.. not only 1 algorithm to every extensions, but 3 in this case. But all with javascript.. Commented Mar 12, 2014 at 16:22
3

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.

10
  • Yes, it's true. I agree with you totally! Thanks for your oppinion. 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.. Commented Mar 12, 2014 at 15:56
  • Don't do JS 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).
    – Bruno
    Commented Mar 12, 2014 at 16:03
  • Yes, but technically it is safe, right? Commented Mar 12, 2014 at 16:06
  • 1
    Not really. And again, half of this problem isn't technical.
    – Bruno
    Commented Mar 12, 2014 at 16:08
  • By the way, most Smartcard mechanisms don't let you get access to the private key itself, so you'd somehow have to interface with the signature API for the card anyway.
    – Bruno
    Commented Mar 12, 2014 at 16:09
0

I agree with the sentiments here, that it is very bad practice to send the private key and it would actually be almost impossible to do what you want.

Why?

Because you generate the private key on a smartcard. It is very difficult to mark private keys as exportable on smart card devices. It requires specific low-level knowledge of the smart card API, which are called via application protocol data units. The way most crypto is executed on devices is through either CAPI on windows or PKCS#11 on all platforms. In most CAPI device implementations the ability to export private keys is disabled by the API. PKCS#11 is more low-level and may support this, but it will depend from device to device.

Your question also prompts another question. Why would the server want to sign the document? Surely the user wants to sign the document. So just send the document to the user over HTTPS, the user can sign with the smartcard and the upload the signature back to the server (the document is already on the server). Indeed, to increase efficiency just send the hash of the document to the user over HTTPS. This is actually what will be encrypted with the private key.

-1

@mki is correct. It is in fact the card that does the signing. Your project is therefore not only insecure in concept and legally void but utterly infeasible in practice.

2
  • The "card" can be inside a secure, centralized appliance. That architecture solves all of these problems.
    – Larry K
    Commented Mar 13, 2014 at 8:02
  • @LarryK Of course it does, and it also eliminates the problem of sending your private key away, which is what my answer is actually about, and the question
    – user207421
    Commented Mar 23, 2017 at 10:43

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