React Native移动应用密钥安全存储及Lambda信任验证技术问询

一、React Native 常规密钥存储方式 #

• .env环境变量：打包时会直接编译进代码，反编译后极易获取，仅适合存储非敏感配置，绝对不能用于存放密钥。
• AsyncStorage/MMKV本地存储：数据存在设备本地，root或越狱设备可轻松读取，敏感密钥禁止存入此类存储。
• 原生层安全存储：iOS用Keychain、Android用Keystore，相比前端存储安全性更高，但原生二进制文件仍存在被逆向破解的可能，只是攻击门槛更高，无法做到完全安全。

二、安全存储的核心思路：避免密钥随安装包分发 #

既然本地存储密钥始终存在被盗风险，最稳妥的做法是不在客户端存储任何敏感密钥，需要使用时通过后端服务（如Lambda）动态获取。核心问题在于要确认调用Lambda的请求确实来自你的应用，而非伪造。

三、建立Lambda与应用的信任关系方案 #

以下是几种实用的验证方式：

1. 应用合法性校验

   • iOS：借助苹果的DeviceCheck或App Attest框架，客户端请求Lambda时携带框架生成的验证Token，Lambda调用苹果官方API校验Token有效性，结合Bundle ID确认请求来自你的应用。
   • Android：客户端在请求中携带应用的签名哈希值，Lambda预先存储你的应用合法签名哈希，对比一致则放行；也可使用Google的SafetyNet Attestation，客户端获取Attestation证书，Lambda调用Google API校验证书，确认应用未被篡改且运行在正常环境。

2. 短期令牌机制

   • 为你的应用分配唯一客户端ID，客户端首次启动时，先通过上述应用合法性校验，从Lambda获取短期有效访问令牌。后续每次调用Lambda都携带该令牌，Lambda仅对合法且未过期的令牌返回密钥。

3. 请求签名验证

   • 客户端与Lambda通过安全方式约定临时密钥（该密钥不存于客户端，由首次身份验证后获取），每次请求时，客户端用此密钥对请求参数、时间戳等信息签名，Lambda收到请求后用相同方式生成签名对比，同时校验时间戳防止重放攻击。

4. IP限制（辅助手段）

   • 给Lambda设置安全组，仅允许特定地区或移动运营商的IP访问，但此方式仅作辅助，因IP可伪造，不能单独依赖。

四、额外提醒 #

• 即便实施上述验证，也无法完全杜绝攻击，但能大幅提升攻击门槛，普通攻击者难以伪造请求。
• 动态获取的密钥仅在内存中临时存储，使用后立即销毁，禁止写入本地存储。
• 定期轮换Lambda的验证密钥和客户端凭证，降低泄露后的影响范围。

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