1

I have a secret key that is used by both a server and my application. This key is used for being sure the requests come from the application. Server has not registered users but with this application users may send requests.

I cannot find another solution... I thought about asymmetric keys, Diffie-Hellman... but nothing solves my problem apart from the symmetric key... But the problem is: how to store that key in my java code and protect it?

Massimo
  • 3,436
  • 4
  • 40
  • 68
  • 1
    May this helps : http://stackoverflow.com/questions/2050292/how-to-securely-store-a-privatekey-in-code – Alexis C. May 25 '13 at 14:15
  • Yes but it does not solve the problem... I think the only way is to confuse a hacker which tries to get that value... – Massimo May 25 '13 at 14:20
  • You said that you thought about asymmetric keys. I think it's largely a safer way than trying to store the private key in your code. – Alexis C. May 25 '13 at 14:34
  • Yes, but it does not solve my problem... I explain you the situation: a user may send a request which has the result of creating a row on a db, though the secret key the application protect a message and the server decrypts it, if it is a valid string the server manages it and creates a row on the db. What to do with an asymmetric key? each one can create a message, protect it with the public key and send it to the server... the result might be a DOS attack which fills the db... – Massimo May 25 '13 at 14:39
  • From your server, could you get the message, decrypt it with the private key and then check that if it is a valid insert ? I mean before doing the insert in the db, just checking if the table_name/column_name etc.. are ok. I'm not sure if it does answering your problem, but I insist, don't store your private key from both sides in your java code. – Alexis C. May 25 '13 at 14:54

1 Answers1

1

It is impossible to do this without getting a shared secret (ex: password) from an outside source (ex: user, SMS, etc).

Everyone has access to your entire program. If no outside information is used, it will always be possible for someone to send a forged packet that looks like it came from your application.

Typically you can send a single verification string to the user via email or SMS that they can then enter into the application. If the string is only valid for a short amount of time (say 5 minutes) then it does not have to be extremely long.

To create a temporary key from this string you hash it. You then use this temporary key to prove to the server that you are who you say you are, and obtain a long-term key from the server and store it in a safe place.

abh
  • 453
  • 3
  • 11
  • I've found the class ObfuscatedString, it generates a string with an array of longs. Using this class for obfuscating a string and proguard for obuscating the code it could be work, what do you think about? The creation of a string is made with a code similar to the following: String key = new ObfuscatedString(new long[] {0x2233850333551220L, 0xFBAD239EF4CB2711L, 0xA21102AB357EF211L}).toString(); I tried to reverse engeneer the code and cannot find the long numbers passed to the ObfuscatedString's constructor. – Massimo May 26 '13 at 15:33
  • It all depends on how motivated someone is to access the obfuscated information. The more popular your app is, the more motivated someone might be to determine your secret key. One approach would be to reverse engineer the app and find where the code sends data. This is very easy to do as Proguard doesn't (and can't) obfuscate calls to android.jar. They would then work backwards to determine how the request was formed. In many cases they probably wouldn't even notice your key was obfuscated. – abh May 27 '13 at 03:09