views:

367

answers:

6

Hi.

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!

A: 

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.

Thomas Leonard
Just looking to encrypt some info, which would be stored in a plain file.
SyBer
If you want to protect against a casual user (as opposed to a determined reverse engineering specialist), AES is an overkill. I used, in a situation like this, a simple XOR-with-key encryption, with a hard-coded key.In general, all data protection tasks come in two flavors - protection against a well-meaning, if mistaken, user and protection against deliberate cracking. The second is much more complicated; in your case, it's not solvable in theory. So assume you're solving the first kind of problem and act accordingly.
Seva Alekseyev
+4  A: 
erickson
I want to use the key to encrypt the amount of left grace period - i.e. the time left for application to run, while it can't connect to the online authority for license check.Can you provide a bit more info about the asymmetric keys?Are there any good articles on java for this?Thanks.
SyBer
A: 

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.

Chuck Vose
Why I'm lost, if the key moving through SSL?
SyBer
Because you have had the private key in your possession. It makes it twice as hard to secure when at least 2 people have had that key. If you're just encrypting info on the client machine then all _you_ need is their public key which is safe to transport. Private key should be locked in a little box that only the person encrypting should have access to. Otherwise skip AES and just go for something like 3DES. If you aren't taking advantage of the public/private key architecture don't use it.
Chuck Vose
I need both encrypt AND decrypt the information on same machine.The key is kept very short time after transmission, and then it's discarded.So is there still any risk at that?
SyBer
+3  A: 

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.

Seva Alekseyev
You right here, still it requires a larger level of experience, which probably only 1% of attacker have.
SyBer
Depends on the user base. And the value of the data. Attackers, who actually do attack, are a sophisticated lot :)
Seva Alekseyev
+1  A: 

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.

Loadmaster
Why it so bad, if the link is secured, for example HTTPS?
SyBer
+1  A: 

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.

IanNorton
Hi.Are there any open-source (preferred) / commercial packages that implement this approach?Thanks.
SyBer