关于Android应用中SDK密钥安全交付与存储的技术咨询

你说得太对了——只要SDK密钥和APK打包在一起，不管你藏在代码里、strings.xml、assets文件夹甚至是经过简单混淆的地方，有心的人都能通过反编译、内存dump这类手段把密钥扒出来，这确实是移动端安全里的老大难问题。

下面给你分享几个实际可行的思路，也是业内常用的方案：

• 后端代理模式：这是目前最稳妥的思路。把需要用密钥的第三方SDK操作全部迁移到你的后端服务器上，APP只和自己的后端接口通信，完全不碰SDK密钥。比如你要用某地图SDK的路径规划服务，APP把起点终点传给后端，后端用密钥调用地图SDK接口，再把结果返回给APP。这样密钥全程只在你可控的服务器环境里，根本不会出现在客户端，从根源上避免了泄露风险。
• 动态获取临时密钥：如果业务上必须在客户端使用密钥，可以考虑APP启动后从你的后端接口获取短有效期的临时密钥，过期自动失效。就算这个临时密钥被拿到，可用时间也很短，能把风险降到最低。同时后端可以加校验逻辑，比如只给合法签名的APP、正常设备ID下发密钥，过滤异常请求。
• Android Keystore加密存储：如果一定要把密钥存在本地，绝对不能存明文。可以先通过Android Keystore生成加密密钥对，把SDK密钥用这个公钥加密后，再存在SharedPreferences或者本地数据库里。Keystore的私钥是存储在系统安全区域的，普通应用无法直接访问，就算APP被反编译，攻击者拿到的也只是加密后的密文，没有私钥解不开。不过要注意，root后的设备可能存在一定风险，但比明文存储安全太多。
• 混淆与环境隔离：永远不要直接硬编码密钥，用Gradle的buildConfigField或者productFlavors根据开发/生产环境注入不同的密钥，至少把开发环境和生产环境的密钥隔离开，减少泄露影响。同时开启R8代码混淆，虽然混淆不能彻底防反编译，但能大幅增加攻击者的破解成本。

至于官方解决方案，Google在Android安全文档里重点推荐了后端代理和Keystore加密这两种核心思路，没有能彻底解决所有问题的“银弹”，只能根据你的业务场景选择最适合的组合方案。

内容来源于stack exchange