Storing RSA private key

Question

Currently I'm developing an application where users generate their own pair RSA keys in order to achieve a secure communication with my server. Also clients are able to communicate directly, sending signatures (proving authentication, as PGP does), therefore I cannot use Diffie-Hellman for this scheme.

Indeed, I'm aware of some techniques of storage of private keys. I thought on enciphering them with AES-256 asking the user an alternative password since using their personal/client password could be a risk if my server gets compromised and the attacker counts with clients private key's ciphertext somehow.

I was thinking about https://en.wikipedia.org/wiki/Zeroisation. Just decipher the ciphered private key and delete it from memory when not needed. Also I read some info about TPM, but I'm afraid this only concerns cryptographically secure hardware equipment and other devices based on vendor's signature verification before booting (maybe I'm not right with it).

I would want to know which is the "best way" for storing private keys in the clients computer, because I cannot store them in my server.

Answer 1

I am currently hoping to find an answer to a similar problem, but maybe I can share some ideas. I would say that your problem is more standard than mine, and therefore it has the benefit that the existent options are relatively standard. However, my own question made me realize that key storage is an information security problem, as opposed to a cryptographic problem. With this, I mean that there is no provable best approach, but there are techniques and good practices that could help to mitigate risks, given some threat model.

Said threat model is, in fact, the most critical aspect to determine what is relevant. There are some approaches in terms of good practices, but they should be considered more as suggestions than as a checklist or a perfect answer.

One aspect that seems to be relatively agreed upon is that the encryption should happen within an environment separated from the normal processor (i.e. TPM, HSM, smart cards). I haven't looked into TPMs, but the other two seem to be the standard way to go.

Now, if additional hardware is out of the table, I can see that your approach makes sense in general. I would worry for the way in which each copy of the key is handled (encrypted and unencrypted, in RAM and in disk, in active usage and in backup), and the way in which the password is used for encryption. In particular, the less the key exists in plaintext, the better.

But mind the threat model. Knowing what you are concerned about is key to know whether your defenses are actually defending you.

Answer 2

The users don't need a RSA key. Get each user to pick a random number. Encrypt that number using the servers public key and send it to the server. The server uses its private key to decrypt it. You can then use symmetric key encryption.

Answer 3

One of the most standard and least bad thing cryptography has to offer using software-only technique for storage of a private key, is enciphering it when at rest, using a symmetric algorithm (e.g. AES-256) which key is is derived from a user-supplied password/passphrase thru a well-parametrized password-based hash (also known as entropy-streching key derivation function). GPG, (and practically every serious program around) uses this, or/and security hardware.

The entropy-streching and its parametrization are critical. Skipping it makes the system vulnerable to brute-force password search (an example). State of the art password hashes are Argon2 (winner of the Password Hashing Competition) and Balloon. Previous algorithms are scrypt, Bcrypt.. PBKDF2 is still very much used, sometime with parametrization appropriate for an earlier century.

However, nothing in this can be secure unless the platform running it i secure. Sad but true, pure cryptography just can't protect against an attacker able to plant a keylogger or other spyware.

Answer 4

@kub0x Initially I thought about using AES-256 to protect the private keys in my app, but then you have to worry about protecting its key password. Camouflaging the private key was my next thought. But the camouflaging algorithm would itself be entropy-reducing meaning less-secure. What if someone found out the algorithm? Finally, I settled on using a crypto library’s implementation of ECC (Elliptic Curve Cryptography) and ECDH (Elliptic Curve Diffie Hellman) operations.