4

我正在尝试构建一个安全系统，用于将数据从客户端 Android 应用程序传输到运行 PHP 的 Web 服务器。

我想要做的是确保系统在密码学上是安全的，这样来自应用程序的消息可以被验证为实际上来自应用程序本身，而不是来自可能编写了自定义脚本的狡猾用户，或者可能使用 cURL 来游戏系统。

这种验证有很多用例，例如：-

  • 如果某个应用包含您从中收集指标的广告，您可能希望验证点击数据是从该应用发送的，而不是来自发现您的 API 并发送虚拟数据的恶意用户。

  • 该应用程序可能有一个多项选择调查，并且您希望再次确保从该应用程序收集调查结果。

  • 该应用程序正在收集 GPS 轨迹，您希望确保数据是从应用程序本身发送的。

在每种情况下，您都希望确保消息的来源是应用程序本身，而不仅仅是运行简单脚本来伪造数据的用户。

我考虑过的一些想法：-

  • SSL - 适用于保护通道和防止篡改（满足某些要求），但仍不能确保数据源的完整性。

  • 公钥加密- 客户端应用程序可以使用私钥加密数据，然后将其传输到可以解码的服务器。问题是私钥需要在应用程序中进行硬编码——可以对应用程序进行反编译，提取私钥，然后用于发送虚假数据。

  • 自制算法- 一个与此非常相似的问题在这里被问到解决方案只在“有人弄清楚你的算法”之前有效 - 即不是一个很好的解决方案！

  • 哈希链- 这似乎是一种使用一次性密钥来验证从客户端到服务器的每个数据负载的非常有趣的方式，但它再次依赖于应用程序本身不被反编译，因为密码仍然需要由应用程序存储.

我对密码学的有限了解让我认为，理论上不可能以这种方式构建一个完全可验证的系统，因为如果我们不能信任最终客户端或通道，那么就没有任何信任的基础。 .但也许有一些我忽略了！

4

1 回答 1

0

这并不难，您只需要对应用程序进行身份验证。您可以使用简单的用户名和密码（通过 SSL）或使用客户端身份验证来执行此操作。在这两种情况下，凭据都需要在应用程序中，攻击者可以提取它们并模拟应用程序。您必须离开它，并且可能实施一些方法来减轻它。

您还可以通过使用非对称密钥（RSA 等）或对称密钥（HMAC 等）对消息进行签名来验证消息。随机数有助于防止重放，其中有人捕获有效签名的消息并将其一遍又一遍地发送到您的服务器。根据您的协议，使用一个的开销可能太多。

为了保护凭证，您可以让客户端生成它们并将它们保存在系统中KeyStore，尽管公共 API 不太支持它，请参阅此处了解一些详细信息。当然，这需要一个额外的步骤，您需要将生成的凭据（例如，公钥）安全地发送到您的服务器，这可能很难正确实施。

无论您做什么，都不要试图发明自己的加密算法或协议，使用已建立的加密算法或协议。

于 2012-12-19T06:53:43.100 回答