In-app Billing API（IAB 版本 3）安全性

Question

现在我是第一次添加 IAB。我已经阅读了文档，下载了示例，它似乎可以工作。 但是，设置不是我的问题，我想了解 Google 的以下两条建议，它们应该可以提高安全性

• 加密公钥

如果攻击者反编译我的应用程序，他还可以删除我的加密、字符串拆分或位移位的东西。

• 开发者负载

这里也一样。其实我可以按照谷歌推荐的方式来做。我的服务器上有用户 ID，可以将其用于请求并在之后进行比较……但我认为当我的应用被反编译时，很容易从代码中删除此逻辑。

我使用 Proguard 混淆了我的代码，并且我总是在将我的应用程序上传到 Google Play 之前对其进行反编译，以查看它是否工作并且设置是否正确。这就是为什么我说这两个建议不会带来很大的安全优势。

我也知道私钥/公钥系统是如何工作的。这就是为什么我可以说不反编译就不可能让我的应用程序与“假”服务器通信。如果 Google 不使用某种异步加密，我可能会理解为什么我必须检查响应是否来自假服务器......

你能帮我理解吗？

干杯， 斯蒂芬

Answer 1

安全性就是在投入精力破解您的应用程序和从破解应用程序中获得收益之间进行权衡。如果您的应用程序花费 99 美分，而黑客需要 3 个小时来破解它，并且他需要一次又一次地破解每个新版本，那么花时间破解它是没有意义的，尽管他在技术上可以做到这一点。只需实施尽可能多的安全措施，让您的应用成为黑客的目标即可。

不安全存储的公钥将允许攻击者轻松地用自己的公钥替换它。如果您的公钥被替换，那么您的应用程序将成功验证攻击者服务器签名的响应。这就是为什么您需要在应用程序中查找和替换您的公钥变得更加困难。

开发负载。 当攻击者试图给你的应用一个有效的签名响应返回时，它用于保护你的应用免受攻击，该响应已被另一个用户的另一个购买使用过去。例如，我过去购买了您的应用程序的扩展，并以字节形式存储了 Google Play 响应。如果您的代码无法区分两个有效响应，那么我可以将此响应提供给其他用户，他们可以将其用于进一步购买。这就是为什么 Google 建议添加一个开发有效负载，您可以在返回有效响应时进行验证。在一个简单的情况下，这可以是用户的电子邮件。在更复杂的情况下，您需要一个服务器，它会为用户的购买生成一个字符串并将其存储在数据库中。稍后，当响应返回时，它将再次验证该响应生成的字符串。

我希望这能让您更好地理解为什么需要这样做。