1
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ Pretty broad question probably without a single answer. I would recommend however to check which key stores are already present on the system. Zeroization is always a good idea, even though there are limits to what it can achieve on desktops. You don't want unused keys floating around. $\endgroup$ – Maarten Bodewes Apr 1 '16 at 9:06
3
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Thanks for the OWASP guide for secure storage. I will use AES-256 for enciphering combined with GMAC in order to verificate the private key integrity whenever its use is requested. Also I will read about OS keyrings, it seems the best way to store a key without implementing a secure vault by myself. In addition I will also apply a lifetime policy for reissuing/renovating keys and use Zeroisation technique. Good luck with your project. $\endgroup$ – kub0x Apr 2 '16 at 1:02
1
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ The OP wanted signatures too... $\endgroup$ – Henno Brandsma Mar 29 '18 at 21:51
1
$\begingroup$

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.

$\endgroup$
-1
$\begingroup$

@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.

$\endgroup$
  • $\begingroup$ I've voted this down because ECC and ECDH is kind-of used as a magic wand in the answer. Maybe you can provide some more details. Feel free to add a comment with @MaartenBodewes if you do - so I can revisit your answer and possibly change the vote. $\endgroup$ – Maarten Bodewes Apr 7 '17 at 23:20
  • $\begingroup$ @Maarten Bodewes ECC’s contribution appears to be “… smaller key size” and ECDH’s is “key exchange”. I need both for my app. Neither, however, address the OP’s (and my) question: what is the best practice for protecting a private key, for example, in memory? Answer 1 concludes that “the less the key exists in plaintext, the better.” Does that mean it would be worth my dev time to obfuscate my private key? What if my source code eventually becomes public? Doesn’t that mean any hacker could potentially reverse any obfuscation technique I applied to the private key? $\endgroup$ – rtischer8277 Apr 8 '17 at 15:21

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.