2

I have the need to store private keys for multiple users, so that my server application can sign files on their behalf. I want to store these keys securely, but couldn't find much information on this matter.

I also need to support the classic "I lost my password" feature - if a user loses their password, we need to be able to generate a new one for them and for the private key not to be lost.

What are the best practices in these scenario?

P.S. A very similar question has been asked on SO 3 years ago.

Anders
  • 64,406
  • 24
  • 178
  • 215
Taro
  • 133
  • 1
  • 5
  • 1
    HSM device can help. – Krishna Pandey Oct 27 '17 at 09:33
  • Agreed, an HSM can greatly simplify this sort of thing. For example, with the HSMs I'm familiar with (Thales) you can protect a key using a passphrase, so the user must enter their passphrase to use the key, but you can also authorise 'recovery' of the key using a quorum of administrator cards if the user has forgotten their passphrase. – Sean Burton Oct 27 '17 at 13:02

3 Answers3

7

IMHO you have a questionable design here. When I read

my server application can sign files on their [my users] behalf

all lights suddenly flash red. If your application can sign something on behalf of a user, you sign it. It may be fine in your use case, but you should carefully review the responsability chain. If in addition you need to be able to recover the private key if the users lose their password, that means that you have a full access to that key even without the users being notified of it (or without their explicit consent). That also means that anobody with admin privileges on the server can sign anything on behalf on any user. IMHO, the keys no longer belong the users but they are just personal information that you need to protect from unwanted disclosure. The common protection is then in layers:

  • physical security to protect the machine
  • internal security rules to identify who has privileges on what
  • network security to protect the system from remote accesses
  • multiple software layers so that an attacker would have to break at least two security points to access the information: for example, sensitive data must be stored in encrypted form, so that the attacker needs to gain access to both the encrypted data and the decryption key
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • Thank you for the response! Indeed the design seems questionable, but it responds to a business need and is part of a bigger design. It makes more sense as part of the bigger picture, which I haven't provided to avoid confusion. All your points are valid and are of help. – Taro Nov 01 '17 at 18:12
2

I would NEVER store this type of information without the assistance of a HSM.

As for your needs, vault form hashicorp can do this (with the aid of a HSM).

However your application should not directly get the keys but you should ask vault to do the encryption for you.

Also implement safeguards and other security barriers to limit abuse since you are transferring 'data' with the attached 'users trust' once it is signed by your system.

LvB
  • 8,217
  • 1
  • 26
  • 43
1

There are a couple of use issues here.

  • Do your users really need to re-gain access to that private key if they forget their password? I.e. could you instead not generate a new keypair and tell them they need to distribute a new public key?
  • Does the application need access to the keys without the user being present?

If the answer to both of those is no then you can just encrypt with their password. This is secure as you can get - if a malicious actor has their password (ignoring two factor) they can just sign into the service as them anyway.

If either answer is yes the best you can do is encrypt all user-keys with the same key. You also want to consider architectural security structure. I.e. you should keep the database on a separate machine to the application, firewall it off of the internet (ideally only accept connections fron the webserver machine IP) and firewall it to only have the DB port open.

Hector
  • 10,893
  • 3
  • 41
  • 44