In-app Billing API (IAB Version 3) Security

Question

Right now I'm adding IAB for the first time. I've read the documentation, downloaded the sample and it seems to work. However, setting things up isn't my problem I want to understand the following two recommendation’s by Google which should improve security

• Encrypt the public key

If an attacker decompiles my app he can also remove my encrypting-, string-split- or bit shifting- stuff.

• The Developer Payload

Same thing here. Actually I can do it the way google has recommended that. I have the user ID’s on my server and can put this to request and compare it afterwards… But I think it’s quite easy to remove this logic from code when my app is decompiled.

I obfuscate my code with Proguard and I always decompile my App before I upload it to Google Play to see if it works and is setup correctly. That’s why I say that these two recommendations don’t bring a big security benefit.

I also know how the private/public key system works. That's why I can say that it is impossible to let my app communicate with a "fake" server without decompiling it. If Google wouldn't use some kind of async encryption I may understand why I have to check if the response came from a fake server...

Can you help me understand that?

Cheers, Stefan

Answer 1

Security is all about tradeoff between invested effort into hacking your app and gained benefit from hacking it. If your app costs 99 cents and a hacker needs 3 hours to hack it, and he needs to hack every new version again and again, then it makes no sense to invest his time in hacking it, although he can technically do this. Just implement as much security to make your app unattractive target for hackers.

Insecurely stored public key will allow attackers to replace it with own public key easily. If your public key is replaced, then your app will successfully validate responses signed by attacker's server. That is why you need to make finding and replacement of your public key in the app more difficult.

Development Payload. It is used for protecting your app from the attacks, when an attacker tries to give your app a valid signed response back, which has been already used by another purchase from another user in the past. For instance, I bought an extension of your app in the past and I stored Google Play response in byte form. If your code cannot differentiate two valid responses from each other, then I can give this response to other users and they can use it for further purchase. That is why Google suggests to add a development payload, which you can verify when a valid response comes back. In a simple case this can be user's e-mail. In more complex cases, you need a server, which will generate a string for a user's purchase and store it in a database. Later, when response comes back it will validate this response agains that generated string.

I hope this gives you a better understanding why this is needed.