5

The Security Controls section in the In-app Billing overview instructs to perform a "signature verification" at a remote server rather than in the app (running locally on the Android device):

By performing signature verification you can help detect responses that have been tampered with or that have been spoofed. You can perform this signature verification step in your application; however, if your application connects to a secure remote server then we recommend that you perform the signature verification on that server.

But if I perform the signature verification on the remote server, expecting only a yes/no or true/false answer, isn't this actually easier to intercept and modify by an attacker?

And if the answer from the remote server is yet another signature, then how verifying the second signature locally on the device safer than doing so for the first (Market) signature?

What am I missing?

Update: @alf noted correctly that if the server is also responsible for delivering purchased content and the signature verification is performed on the server, then even if the attacker compromises the app, the server will not deliver the content purchased via In-app billing. This is trivial and well understood.

What I failed to mention originally is that I am actually referring to a scenario in which the server does not deliver any content but rather only verifies the signature, so that the app can decide whether to unlock certain features. In such case, what is the advantage of remote server signature verification over in-app one?

Bill The Ape
  • 3,261
  • 25
  • 44
  • I am also wondering if server signature checking is really required when implementing in-app-billing just to unlock features. What were your findings? – Thomas Wana Sep 15 '14 at 19:09

3 Answers3

3

isn't this actually easier to intercept and modify by an attacker?

If you are using SSL to communicate with the server, they cannot intercept and change the reply. SSL also verifies the identity of the server, so you are sure you are talking to your own server, not the attacker's.

As for why perform signature verification on the server, the idea of the original doc comment is that if you do it on the client, you need to store the public key inside the app. The attacker could presumably swap the key with their own, and attacker-generated signatures will verify OK. You can avoid this by doing the verification on the server. However, real-life cracking tools such as AntiLVL will just look for the bytecode that returns true/false and modify it to return always true.

Nikolay Elenkov
  • 52,576
  • 10
  • 84
  • 84
  • And with this so called ["clever SSL certificate trickery"](http://techcrunch.com/2011/11/14/siri-cracked-open-theoretically-opening-it-up-to-other-devices-or-even-android/) it seems like there is no point to any kind of verification, not even on the server via SSL... – Bill The Ape Mar 05 '12 at 05:04
  • Nothing special about this -- it's just DNS spoofing. This can be done easily in a controlled lab environment, but not trivial on the real Internet. Especially for major sites. – Nikolay Elenkov Mar 05 '12 at 05:11
2

Because you have control of the verification code on the server. The code on the device end could have been compromised.

Charlie Martin
  • 110,348
  • 25
  • 193
  • 263
2

If you don't perform signature verification on the server, attacker will not bother with your device. Or, if he wants, he can download your app, decompile it, and just remove the verification. What will you do against a changed app?

alf
  • 8,377
  • 24
  • 45
  • Even if I perform the signature verification on the server, the attacker can decompile the app and just remove the part that communicates with the server to get the result of the verification. What will I do against that? – Bill The Ape Jan 09 '12 at 21:43
  • 3
    In this case, the attacker will not get your precious content which is server's responsibility to deliver. The assumption is that Android Market servers trusted (ha!), your server is trusted, but you have no control over the application. – alf Jan 09 '12 at 21:54
  • In this case you are right, of course. I forgot to mention that I am talking about using In-app billing to unlock features, not to deliver content. Can you refer to that scenario? +2 for now. – Bill The Ape Jan 09 '12 at 22:04