Why is signature verification on remote server mor

问题:

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?

回答1:

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.

回答2:

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

回答3:

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?