1

I have an URL which returns JSON string with my data. Now, I would like to keep this data in secret, so only my Android application could display it.

My first idea was to encode data with private key (on the server-side) and store the same private key in the application, so it can decode the message. However, attacker (user) can decomplie the .apk and obtain the private key.

  1. Do you have an idea how to secure it?
  2. Decompiling Java is simple. How about Android .apk? I heard that there is something called ProGuard - does Android use this by default and does it secure the code?
Community
  • 1
  • 1
Adam Stelmaszczyk
  • 19,665
  • 4
  • 70
  • 110
  • "Do you have an idea how to secure it?" It will *never* be 100% secure, anything you as a human can implement to secure it can be undone by some other human. – FoamyGuy Sep 03 '12 at 02:09
  • @FoamyGuy I agree with you that this will never be 100% secure. But we can make it more secure. However, I can't agree with a general statement "anything you as a human can implement to secure it can be undone by some other human". For example [One-time pad encryption](http://en.wikipedia.org/wiki/One-time_pad). – Adam Stelmaszczyk Sep 03 '12 at 12:42

2 Answers2

2

This generally cannot be done: if the user needs to see the data, they have to be able to decrypt it, etc. You can make it somewhat harder by not storing the data on disk, etc., but a determined user/attacker can dump memory, use a debugger, etc. to see the data. Think about what threats you are trying to protect from first, and then decide on a course of action.

If you want only your app to be able to download the data, you need to use some sort of authentication + SSL. If you hardcode a key or password in the app, it is fairly easy to extract it, so that doesn't buy you much. If you make the user enter the password each time they use the app, they will get frustrated quickly and leave a bunch of 1-star ratings. A middle ground would be to use some sort of token-based authentication, such as OAuth (or ClientLogin, if you really have to, but it is being deprecated) and have the user authenticate with their existing account, so that they don't have to register and remember yet another password. Most Android devices already have a Google Account setup, so you can use that, but this requires additional permissions and user consent (confirmation dialog).

Nikolay Elenkov
  • 52,576
  • 10
  • 84
  • 84
1

Some obfuscators are much better than others but that protects code from being reverse engineered, not data from being seen, it protects you from non-motivated hackers but not much else.

If you are trying to protect the data from someone who has decompiled / recompiled your code successfully then the data should never be in the clear unless the user authorizes it with a password that is not stored on the device and is used to encrypt/decrypt the data on the fly.

The simplest way I think would be to use password secured HTTPS session for data transmission and then either encrypt/decrypt it on the fly using that same NEVER TO BE STORED password or store it encrypted in SQL using that same NEVER TO BE STORED password.

This can get pretty sophisticated dependent on what you are really trying to do, how secure it really needs to be and how much control you have on the server side etc. lots of stuff on the web that is more detailed, this is an interesting read for instance

If you do want to go custom then Android pretty much has secure key exchange protocols, private / public key support, and a lot of general crypto support so it's all doable but I am not sure I would try and roll your own unless you are pretty comfortable with all of the protocols and proper use there of.

People don't usually need as much security as they think they do, but you can get pretty dang secure if your willing to put in the infrastructure and take the time to review it.

Community
  • 1
  • 1
Idistic
  • 6,281
  • 2
  • 28
  • 38