为什么远程服务器上的签名验证比设备上的签名验证更安全？
应用内结算概述中的安全控制部分指示在远程服务器而不是在应用程序（在 Android 设备上本地运行）中执行“签名验证”：
通过执行签名验证，您可以帮助检测响应 已被篡改或已被欺骗。你可以 在您的应用程序中执行此签名验证步骤；然而， 如果您的应用程序连接到安全的远程服务器那么我们 建议您对其执行签名验证 服务器。
但是，如果我在远程服务器上执行签名验证，只期望得到 yes/no 或 true/false 答案，这实际上不是更容易被拦截和修改吗？攻击者？
如果来自远程服务器的答案是另一个签名，那么如何在设备上本地验证第二个签名比验证第一个（市场）签名更安全？
我缺少什么？
更新：@alf正确地指出，如果服务器也负责交付购买的内容，并且在服务器上进行签名验证，那么即使攻击者破坏了应用程序，服务器也不会交付内容通过应用内结算购买。这是微不足道且很好理解的。
我最初没有提到的是，我实际上指的是服务器不传递任何内容而只是验证签名的场景，以便应用程序可以决定是否解锁某些功能。那么，远程服务器签名验证相对于应用内签名验证有什么优势呢？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您使用 SSL 与服务器通信，它们无法拦截和更改回复。 SSL 还验证服务器的身份，因此您确信您正在与自己的服务器而不是攻击者的服务器通信。
至于为什么要在服务器上进行签名验证，原文档注释的想法是，如果在客户端上进行签名验证，则需要将公钥存储在应用程序内部。攻击者可能可以用自己的密钥交换密钥，并且攻击者生成的签名将验证正确。您可以通过在服务器上进行验证来避免这种情况。然而，现实生活中的破解工具，例如 AntiLVL 只会查找返回的字节码 < code>true/false 并修改它以始终返回
true。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/falseand modify it to return alwaystrue.因为你可以控制服务器上的验证码。设备端的代码可能已被泄露。
Because you have control of the verification code on the server. The code on the device end could have been compromised.
如果您不在服务器上进行签名验证，攻击者就不会打扰您的设备。或者，如果他愿意，他可以下载您的应用程序，反编译它，然后删除验证。对于更改后的应用程序，您将采取什么措施？
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?