如何保障移动应用中客户端生成数据的完整性与来源合法性？

一、数据完整性保障：绑定身份的签名机制 #

• 放弃全局通用的签名密钥，把应用专属签名密钥嵌入合法应用代码中（必须做混淆加固，比如拆分存储、动态拼接，防止反编译提取）。客户端每次提交行程数据时，用该密钥对行程核心数据（距离+起止时间）+用户JWT+请求时间戳做HMAC-SHA256签名，服务器端存储相同密钥，收到请求后重新计算签名并比对。
  • 加入时间戳是为了避免重放攻击，服务器可以拒绝超出时间窗口（比如5分钟）的请求。
  • 请求体示例：

    {
      "trip_distance": 5.2,
      "start_time": "2024-05-20T10:00:00",
      "end_time": "2024-05-20T10:30:00",
      "jwt": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
      "signature": "a1b2c3d4...",
      "timestamp": 1716183000
    }
    

二、合法应用实例验证：多层完整性校验 #

• 应用签名校验：客户端在发起请求前，先验证自身的签名合法性——Android通过PackageManager获取APK签名哈希并和预设值比对；iOS校验Bundle的签名信息，只有校验通过才允许生成请求签名。
• 应用篡改检测：借助第三方加固工具（如腾讯乐固、阿里聚安全）对APK/IPA做加固，防止代码被反编译篡改；也可以自行实现简单的本地校验，比如计算DEX/Mach-O文件的哈希值，和服务器端存储的合法哈希比对。
• 设备-应用绑定：收集设备非敏感特征（如Android硬件ID哈希、iOS IDFA哈希，注意遵循隐私合规），和用户JWT、应用签名哈希绑定存储在服务器。当请求的特征组合不匹配时，触发二次验证（如短信验证码）。

三、补充防御措施 #

• 请求频率限制：针对同一用户+设备+应用特征的请求设置频率阈值，比如1分钟内最多提交3次行程数据，防止批量伪造。
• 业务规则校验：虽然无法独立验证数据真实性，但可以通过业务逻辑过滤异常数据——比如行程时长不到1分钟却有5公里距离、起止时间顺序颠倒等，这类请求直接拦截或触发人工审核。
• 动态密钥更新：定期在服务器端更换应用签名密钥，客户端通过应用内静默更新获取新密钥，避免密钥泄露后被长期滥用。

四、关于你提及方案的补充说明 #

• 客户端证书：如果用应用级证书（而非每个实例单独分发），嵌入应用后做加固，本质和签名密钥方案类似，只是校验流程更规范，但同样要解决证书被提取的问题，适合对合规性要求更高的场景。
• Diffie-Hellman：仅能协商临时加密密钥，无法直接验证应用身份，恶意客户端也能参与协商，必须结合应用签名来确认协商后的密钥合法性，否则意义不大。

内容的提问来源于stack exchange，提问作者user20231989