从iPhone上的应用程序验证了到服务器的通道

难道您不能只使用客户端证书（由您签名）并与您的服务器建立 HTTPS 连接，该连接已配置为仅接受由您签名的客户端证书开始的连接吗？

生成一个随机的，相当长的东西，然后把分数钉到最后，也许是名字或其他静态的东西，然后SHA1/MD5，并将两者都传递给服务器，验证随机哈希值是否等于哈希值。

事后思考：如果你想让逆向 engenier 更难，那么将你的随机数乘以当天的数字表示（星期一=1，星期二=2,...）

长话短说，您可以导出数字签名代码，几乎没有限制。要了解更多信息，请从BIS出口常见问题开始。

您可能想查看 EAR 742.15（b）3，其中涵盖了数字签名豁免。

当然，《我不是律师》，规则在去年可能已经改变。

一个可能足够好的想法：

• 设 Secret1、Secret2、Secret3 为任意随机字符串。
• 设 DeviceID 为 iPhone 的唯一设备 ID。
• 设 Hash（Foo + Bar） 表示我将 Foo 和 Bar 连接起来，然后计算一个哈希值。

然后：

1. 应用首次与服务器通信时，会发出 DevicePassword 请求。iPhone 发送：DeviceID、Hash（DeviceID + Secret1）

2. 服务器使用 Secret1 来验证请求是否来自应用。如果是这样，它会生成一个 DevicePassword，并将 DeviceID 和 DevicePassword 之间的关联保存在服务器上。

3. 服务器回复：DevicePassword， Hash（DevicePassword + Secret2）

4. 该应用程序使用 Secret2 来验证密码是否来自服务器。如果是这样，它会保存它。

5. 要提交分数，iPhone 会发送：DeviceID、Score、Hash（Score + DevicePassword + Secret3）

6. 服务器使用 Secret3 和 DevicePassword 进行验证。

DevicePassword 的优点是每个设备实际上都有一个唯一的密钥，如果我不知道，通过数据包嗅探提交的分数会更难确定密钥。

此外，在正常情况下，应用程序每次安装应该只请求一次 DevicePassword，因此您可以轻松识别对 DevicePassword 的可疑请求，或者只是将其限制为每天一次。

免责声明：这个解决方案不在我的脑海中，所以我不能保证这个方案没有重大缺陷。

使用真正的加密货币实际上不会在这里买到任何东西。您基本上与典型的DRM问题相反。在这种情况下，您想阻止人们解密内容，但他们必须解密内容才能观看内容，因此无论如何您都必须将他们交给密钥。

在你的情况下，你想防止人们签署虚假的分数，但他们必须能够签署真实的分数，所以你无论如何都必须给他们钥匙。

您需要做的就是确保您的计划比潜在奖励需要更多的努力才能破解。由于我们谈论的是游戏排行榜，因此赌注并不高。这样做是为了让使用 tcpdump 的人不会太快弄清楚，你应该没问题。如果你的服务器足够聪明，可以检测到“实验”（来自一个来源的大量失败提交），那么你将比依赖任何加密算法更安全。