Say I want to create a cloud based private key storage for users, which they can use to sign documents.

On the server side I would use a HSM to make the key storage more secure.

One option is that the signing happens on the server side. But, this way the server knows the private key of the user, which is not what I would want.

Another option is to have the user's private key wrapped in an symmetric key (for example AES) only known by the user, and store it on the HSM.

This AES key would be derived from the user's password. There are mechanisms like PBKDF2 to create a key from password.

Then, when user requests to sign a document, the server would send that users's private key encrypted by the AES key only known to that user.

The client side(which could be an android app, or webapp based on javascript) is used to make a signature.

Also, there would need to be a password change mechanism which would function something like this:

  • client requests his private key from the server(encrypted by his AES key)
  • client decrypts the private key usign AES key derived from his password
  • client generates a new key using his new password
  • client encrypts his private key with his AES key and sends it to the server
  • server updates the wrapped user's private key with the new one

I don't know much about the HSM modules, but as I understand they have a similar functionality as a smart card( the key sould never leave the HSM and all the encryption should happen on it).

I read somewhere that some HSM's allow key extraction when PKCS#11 "CKA_EXTRACTABLE" is set at time of a key generation. But, wouldn't that, for the most part, defeat the sole purpose of the HSM.

Also, would I be able to implement the mechanism for password changing I described when using a HSM?

Another option would be that the signing happens on the HSM, and the private keys are wrapped by the AES key, generated from the user's password. HSM then unwraps the private key and sign the file, but the private key itself cannot be accessed by the cloud provider.

Would, in this case be possible to implement the password change mechanism I described?

Also, password-based key derivation mechanisms use salt to make rainbow table attacks more difficult.

How would salt be used in this case? Would it be stored on the server and then transferred to the client when using the service?

The requirement is that the user can use the service on any device(mobile, desktop) only knowing his username/password.

I would probably include 2FA by adding SMS verification when authenticating to the server.


Your scheme is workable, but it completely defeats the point of an HSM. You can do that with a plain database storage, too.

The point of a HSM (which is actually not much more than a huge and very fast smartcard) is that you can securely store (private) key material without anybody, including the administrator, being able to extract it.

  • 1
    So, the administrator wouldn't be able to sign a document using someone else's private key that is stored on the HSM? I know that he wouldn't be able to extract it. But, is there any HSM that provides some the kind of protection that only the user that have certain credentials(username/password, token, key or whatever) is able to use the key. I read some documentations for different HSMs and I often see mentioning of a "partition admin" who has full control of all the keys in the partition he manages. Is there a way to make one partition per user, so only that user have access to his key? Apr 5 '17 at 10:19
  • And, if it can be done like this. Could you please provide me with some kind of literature that explains that? Apr 5 '17 at 10:21
  • That's a question of how your HSM allows access to certain keys. What you need is an inidividual password (or C/R authentication) per private key. You'll have to be prepared to pay really lots of money for such a device.
    – mat
    Apr 5 '17 at 12:29
  • There is an interesting blog post by Matthew Green, about how Apple accomplished something similar: blog.cryptographyengineering.com/2016/08/13/…
    – mat
    Apr 5 '17 at 12:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.