Android In App Billing: securing application public key

Question

From Android In App Billing version 3 (TrivialDrive)sample application coming with sdk

MainActivity.java

/* base64EncodedPublicKey should be YOUR APPLICATION'S PUBLIC KEY
 * (that you got from the Google Play developer console). This is not your
 * developer public key, it's the *app-specific* public key.
 *
 * Instead of just storing the entire literal string here embedded in the
 * program,  construct the key at runtime from pieces or
 * use bit manipulation (for example, XOR with some other string) to hide
 * the actual key.  The key itself is not secret information, but we don't
 * want to make it easy for an attacker to replace the public key with one
 * of their own and then fake messages from the server.
 */
String base64EncodedPublicKey = "CONSTRUCT_YOUR_KEY_AND_PLACE_IT_HERE";

Well I am not sure I understand this security measure. I know how to get the application public key (which is already base 64 encoded) from Google Play Developer Console.

What I am not understanding is this part

 /* Instead of just storing the entire literal string here embedded in the
 * program,  construct the key at runtime from pieces or
 * use bit manipulation (for example, XOR with some other string) to hide
 * the actual key
 */

As far as I know, this public key is a constant string, which is given from Google during application upload process.

How can we create the same key programmatically using any bit manipulation process? Has someone done it before? Is there any sample code on how to do this?

Answer 1

Something like this:

String Base64EncodedPublicKey key = "Ak3jfkd" + GetMiddleBit() + "D349824";

or

String Base64EncodedPublicKey key = 
         DecrementEachletter("Bl4kgle") + GetMiddleBit() + ReverseString("D349824");

or anything that doesn't put the key in base64 plaintext in a single string. Probably also something that doesn't store the key in base64 would be a good idea too, since raw base64 text fragments are pretty easy to spot.

It's not a particularly GOOD way to protect the key. But it protects against a trivial attack where somebody just searches through literal strings in you APK looking for something that looks like a base64-encoded public key. At least you make the #$#$ers work a little bit.

Presumably evil people can do bad things if they identify your public key. Google seems to think so, apparently. I can guess what this step does, but I'm not sure I really want to speculate on that in an open forum, and give anyone any ideas. You want to do it though.

The basic plot summary would be that you're making it more difficult for somebody to write an application that programmatically de-LVLs an applciation.

One assumes that anyone who's doing this makes a living cracking 20 or 30,000 android apps and republishing them. Chances are, I suppose that they're not going to take the extra ten minutes to add your app to the list of 20,000 Android apps that have already been broken by a program, if they actually have to do a little bit of manual work. Unless you have a top tier application. And then the battle is potentially endless, and probably ultimately futile.

Splitting the key into consecutive chunks (as proposed in another answer) probably isn't good enough. Because the key will end up in consecutive strings in the string constant tables in the APK. Too easy to find that with a program.