我正在为 Android 和 iOs 开发一个移动应用程序。对于将发送到 Web 服务的移动应用程序中的数据加密，最佳实践是什么？
基本上我会生成一个字符串，其中包含一些参数，如 GPS 和时间。此字符串需要加密，然后传递给 Web 服务。
我考虑过使用非对称加密来做到这一点。用公钥加密字符串（必须硬编码？）并用私钥解密。因为每个应用程序都可以被逆向工程，所以这根本不安全。在找到硬编码的公钥和字符串生成函数后，很容易伪造你想要的任何东西。
任何输入都受到高度赞赏。
编辑：我的问题的更清晰的方法：我的应用程序的一个函数将生成一个字符串，另一个函数将加密这个字符串，该字符串将被发送到服务器。在对我的应用程序进行逆向工程后，如何防止将自制字符串传递给加密函数？换句话说，我能否通过加密技术确保我的移动应用程序发送到服务器的数据不是由其他人制作的？
你不能。这是通用计算的基本原理。
你遇到了香农的格言：
敌人知道系统。设计系统时应该假设敌人会立即完全熟悉它们。
只是为了让我的观点完全清楚：你给某人一辆车，并要求他们只开车到一个特定的地方。没有什么能阻止他们决定去其他地方 - 你依靠他们遵守你的要求。
如果您的安全机制取决于希望有人不会查看您的可执行文件并发现您的加密方法/嵌入式密钥，那么它不是安全机制；这是一个默默无闻的机制。
据我所知，您正试图通过 GPS 坐标强制用户位于指定区域内，并且还希望确保他们不会欺骗这些坐标。这无法在智能手机等通用计算平台上完成。让我们看一下技术栈：
所以你不能强制你接收到你的 webapp 的 GPS 坐标是正确的，因为它们可能在应用程序级别、操作系统级别、硬件级别甚至 GPS 信号级别被篡改。或者，除此之外，有人可能会完全跳过电话并手动向您的 Web 应用发送包含虚假数据的请求！
解决方案是接受风险或更改您的安全模型。
您应该始终使用 SSL。
SSL 有一个内置的公钥，并提供“身份验证”，这意味着它确保您正在与之通信的服务器实际上是您想要的 Web 服务，而不是冒名顶替者。
由于您没有另行说明，或者您有任何其他需要，我认为 SSL 将解决您对将数据发送到服务器并在传输过程中保护数据的所有担忧。
更新
根据您在评论中更新的要求，我了解您希望防止欺骗发送到您的网络服务的 GPS 数据。
如果您无法控制设备（管理或其他方式）@Polynomial 所说的是正确的。如果您正在创建封闭系统、嵌入式系统或在公司中，您可能有更多选择。
假设您可以完全控制您的应用程序将在其上运行的每部手机。这意味着锁定手机，保持对管理员密码的独占控制，并且永远不要将其提供给最终用户。
接下来，您可以为每个设备分配一个唯一密钥，以加密要发送到 Web 服务的数据。
如果给定的电话遭到入侵，您将能够根据所使用的密钥确定它是哪个设备。
最佳实践取决于确切的用法。
我从您的问题中收集到的是，您有一个向您发送 GPS 数据和时间的应用程序，例如“足迹”应用程序。您要确保您没有收到虚假数据，因此您要确保数据来自您的真实客户而不是虚假数据。
好吧，不幸的是，正如其他答案所述，这是不可能的。鉴于您的应用程序的 APK 文件，有人可以将其反编译成 Java 源代码，这可能不如您自己的源代码那么优雅，但绝对可行。然后，他们可以使用您的代码构建自己的应用程序，以您期望的方式与您的应用程序进行通信，并使用它来为您提供虚假数据。
因此，您用于数据传输的任何方案都不应信任客户端。相反，它应该信任用户。
考虑这个解决方案；您的应用程序服务器使用受信任的公钥证书进行签名（在这种情况下，它可能是受信任的，唯一原因是您的应用程序知道应该提供的确切证书；这称为“证书固定”，无论您是否获得了由全球 CA 签署的证书）。根据要求，它会将该证书提供给任何要求它的人；这是公共信息，你可以在互联网上的每个黑客论坛上贴上这个东西，它的安全性也不会降低。您的客户端使用此证书来协商安全通信隧道；这是非常标准的东西。
现在，你有保密了。你需要真实性；如果您不确定对方是谁，那么没有人可以听到你们两个之间的对话也没关系。因此，一旦通道打开，您期望的下一件事就是包含用户凭据的身份验证请求。如果会话未通过身份验证，您应该拒绝任何发送 GPS 数据的请求。用户在此类请求中提供的凭据可能是他们的用户名和密码、他们手机的 IMEI 或 MAC 地址、来自加密密钥卡的 10 位代码，任何您认为正确确保只有特定用户才能使用的必要信息提供这些凭据。
一旦您拥有这些凭据并验证它们是否符合预期，无论您想要这样做，您都可以将它们发回一个“身份验证令牌”。这与用于任何其他打开会话的随机数一样简单。V4 GUID 也是一个不错的选择。此标识符将作为在此会话期间在此通道上发送或接收数据的任何请求的一部分，它将仅在此特定通道上被接受，并且仅在此唯一会话打开时才被接受。
一旦所有这些都设置好，通过该会话的安全通道进行的任何服务调用（包括正确的身份验证令牌）通常都可以被信任。您可能应该再包括一件事，这是一种防止重放攻击的措施。攻击者不必通过简单地重复已经说过的话来确切地知道来回发送的内容来搞砸你。因此，为了确保您的系统无论发送多少次都只处理一次唯一消息，每条消息都应该包含一个随机数，一次使用的唯一值。一个简单的序列计数器值，构成请求结构的一部分并由安全通道加密，就足够了；然后，您所要做的就是忽略序列号不是您希望从客户端接收到的下一个消息的任何消息（这可能存在一些固有的容错性，但永远不要接受来自同一服务器的相同类型的服务请求具有相同序列号的客户端两次）。