2

Google's documentation as far as in app billing goes states that:

To keep your public key safe from malicious users and hackers, do not embed it in any code as a literal string. Instead, construct the string 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 you do not want to make it easy for a hacker or malicious user to replace the public key with another key.

But the verification process is calling the Google servers where the private key is stored, so what if they replace the key? it will anyway be rejected by the call to Google servers

Or does it mean that the cracker has also modified the apks code and has also replaced the call to the google servers with a call to their private server? if that is the case, then having the public key visible is the least of the problems.

What am I missing?

microwth
  • 1,016
  • 1
  • 14
  • 27
  • Possible duplicate of [Android In App Billing: securing application public key](http://stackoverflow.com/questions/14352758/android-in-app-billing-securing-application-public-key) – H Raval Oct 15 '16 at 09:08
  • it's not as the linked qa is about how to secure the key. I'm specifically asking where the problem is if the key is replaced – microwth Oct 15 '16 at 09:20
  • with replacement of public key it might be possible to redirect user to different account for payment. this link explains it well how public key and private key works http://security.stackexchange.com/questions/25741/how-can-i-explain-the-concept-of-public-and-private-keys-without-technical-jargo – Amod Gokhale Oct 15 '16 at 09:27
  • doesn't that presume that you have to alter Google's verification code embedded into the apk to point to another account or non gplay server? because if you sent a fake public key then it won't verify with using the private key hosted in gplays servers – microwth Oct 15 '16 at 09:46

1 Answers1

1

The public key (or licence key) is used to create the INAPP_DATA_SIGNATURE from the INAPP_PURCHASE_DATA JSON object.

An intelligent IAP/IAB cracker could create its own INAPP_DATA_SIGNATURE, using its own private key. If your public key was hard-coded and un-obfuscated in the app, it may be able to replace it with its own public key, enabling any client-side validation to return truthy.

Of course, any server-side validation would still fail, the Google Play Developer API wouldn't even recognise the purchase token. But the point of Google's statement is to highlight the dangers and attack vectors of client-side only validation.

TL;DR If your app relies entirely on client-side validation then it may be exposed to potential IAP fraud.

Marc Greenstock
  • 11,278
  • 4
  • 30
  • 54
  • >Of course, any server-side validation would still fail, the Google Play >Developer API wouldn't even recognise the purchase token. that's the answer I was looking for. So that means that they have to also fool the user into buying the application by bypassing the Google servers and calling the fraudulent servers.That can only happen if the user doesn't download the app from play store but from third party providers,right? – microwth Oct 17 '16 at 17:39
  • 1
    Downloading from an app that is already cracked from third party is one way to commit IAP fraud, another is to root the device and install a [IAP/IAB cracker](http://getcydiaapps.com/download-iap-cracker-for-android/). They work by replacing the IAB methods in the app or OS. Instead of contacting Google Play, they fake the interaction and return faux `INAPP_PURCHASE_DATA ` and `INAPP_DATA_SIGNATURE` – Marc Greenstock Oct 17 '16 at 18:01
  • if they are able for such modifications,getting hold of the public key is not that big a deal afterall.Do you think the same? – microwth Oct 17 '16 at 18:14
  • As Google states in [Security and Design](https://developer.android.com/google/play/billing/billing_best_practices.html#sign) - "If practical, you should perform signature verification on a remote server and not on a device". So no, sorry, I don't agree by principle. It's not about getting hold of the public key that is the problem. It's about the possibility of faux purchase data and false positive validation. [Never trust the client](https://en.wikipedia.org/wiki/Defensive_programming). – Marc Greenstock Oct 17 '16 at 18:37