Storing AES keys [duplicate]

Question

This question already has an answer here:

• How do I securely store encryption keys in java? 4 answers

Is there a good way to ship AES keys together with the application, but still make them safe enough?

I don't quite fond regarding the idea of hard-coding the keys (as the app can be de-compiled), but other alternative, saving them on remote server, looks quite dangerous to me in case the server goes down or the network cuts off.

I know that Java provides mechanism called key-store, but AFAIK, if the code is de-compiled, this key-store can be opened as well?

Any idea?

Thanks in advance!

Answer 1

You cannot trust your application to keep your key safe. You cannot trust that the application is really yours.

You can transport the key securely all you like, it's the fact that there is no hardware protecting your key at the application end that means you loose, anyone with a hex editor or debugger can get the key out of your application.

If an application "needs" a key I would be tempted to have each user (or license) simply be a private key and certificate.

You could then use signature checking and Diffie-Hellman key-exchange to 'give' each licensed instance of your application a key from a networked server at runtime. This would also let you make sure only one instance of a license is running at once.

Answer 2

You'd have to describe the application better.

If you are trying to keep the key absolutely safe from the owner of the computer on which the software is installed… you can't. And you shouldn't try. It's their machine and they have a right to know everything on it.

Having the same symmetric key embedded in every copy of some software seems like a bad design. Symmetric keys should be generated fresh, then exchanged using some asymmetric algorithm. This way, only the integrity of the public key needs to be protected; it doesn't matter if someone discovers the key.

Answer 3

If the application uses the key, the key will be in memory at some point. A sophisticated enough user/attacker can see it then. A debugger and a breakpoint at the right moment is all they need.

Answer 4

No, transmitting private encryption keys is a bad idea.

A typical approach is to store encryption keys in a configuration file, which is edited at install/update time by a sysadmin or deployment person. The key itself can be communicated through secure (encrypted) email, or simply read out over the phone, or simply just generated randomly (for each user) at install time.

Answer 5

It depends what you're planning to use the keys for, and what counts as "safe enough", but in general I don't think you can execute code on the client's machine which uses a key and still prevent the client from getting the key.

Answer 6

No, these keys should be generated by the application itself and stored by the user. If you're transmitting the private key you've lost a lot, almost as much as you've lost by having a copy of the private key before you ship the product.

Safety from the user shouldn't be the goal.