前言

安全问题在互联网，软件领域从来都是不可忽视的，而随着移动互联网的发展，移动端不管是在设备持有量上，还是在用户数量上，都已经超越传统PC端，成为第一大入口端。因此提高对于移动安全领域的关注，加强移动端的安全等级，是很有必要的。

而一般情况下，移动端安全大致上可以分为以下几个维度：

• Web安全
• 网络通讯安全
• 本地安全

Web安全，主要考虑Web服务中每一层可能的漏洞，及由此衍生的一系列安全问题，如：存储层中的SQL注入问题，Nginx（容器）层的DDoS问题，前端层级的XSS跨站脚本问题等。
网络通讯安全，需要考虑通讯过程中信息的安全性，防止由于信息泄露导致的其他安全问题，比如：常见的各种形式的中间人问题等。
本地安全主要指客户端本地环境与数据的安全，以及代码被破解获得所导致的安全问题，如：明文存储问题，恶意二次打包问题，越权操作问题等。

其中，本地安全攻击大多发生在攻击者自己手机上，开发者和运维较难感知，所以容易被大家忽略，从而很容易成为整个链路的安全短板。本文将着重就本地安全，公司所采取的安全图片方案跟大家做一个介绍，其中的一些细节基于安全考虑会略去，保留其基本思路，希望对大家有所帮助，也欢迎共同交流。

安全图片解决方案

安全图片方案解决了本地安全的几个问题：

• 明文存储，过度依赖系统安全性（iOS：KC/UserDefault；Android：KeyStore/SharedPreference）
• 恶意二次打包
• 容易被逆向，被调试
• 敏感信息写入代码

优点

• 使用便捷简单
• 对工程及代码侵入性较小
• 显著提高APP的安全性

当然，该方案也存在一些问题，比如字段的存取需要走I/O以及二进制流处理，一定程度上会影响APP性能，同时安全性建立在SDK本身和安全图片安全性的基础上，容易在这一块出现安全短板。
所幸，正常获取字段的开销时间一般都不会超过30毫秒（视具体算法而定）。而安全性问题，还是需要靠持续加强SDK安全性，强化安全图片使用的算法，来提升短板，增大破解成本。

安全图片

我们的安全图片方案主要包含了安全图片生成，安全图片消费，二次打包检查，调试检查等功能，这些功能分布在安全SDK及图片生成工具(以web形式提供)中。

结构如下：

可以看到，图片文件作为信息加密和存储的中心媒介，在其中起到了非常重要的作用。其实这里也可以用其他形式的文件，比如文本文件，视频文件，音频文件。

那么为什么要用图片呢？综合来看：

• 图片资源在我们的移动项目中非常常见，有比较大的混淆性
• 图片的易操作性比较强，比较容易插入想要加密的信息
• 读取性能比较好，同时容易优化

所以技术选型过程中，根据实际业务形态，也可能选择音频、视频、特殊文本等其他文件作为中心媒介，比如富含大量音视频信息的APP/游戏，包含很多特殊格式电子书的电子书阅读软件，等等。

安全图片方案-流程

从结构图可以看出，我们的图片解决方案包含了"获取web端（图片生成工具）生成的安全图片"，"在APP中通过SDK使用安全图片"这两个流程。

获取安全图片

获取安全图片流程中，由于iOS和Android各自的包检查依赖项不一样，在输入项上会有所区别，iOS使用BundleID、Android使用keystore的数字签名SHA1值作为检查项。

在获取到用户输入信息之后，还需要一个加密的关键信息：加密密钥。
这里可以有三种思路：

• 由server端生成密钥，存储在服务器端，之后通过安全的通讯协议(如https)从服务器获取。
• 由server端生成密钥，之后按照某些算法或者规则插入到图片当中
• 从图片中按照某种规则或者算法，生成一个密钥

这三种方式各有利弊：

• 第一种方案的安全性基于通讯安全，能在本地安全被攻破的情况下保持安全链路完整，隔离不同业务方的密钥安全性，但是随之也带来了一些新的问题，如：中间人攻击、网络性能问题等。
• 第二种针对业务方较多的情况下，安全等级较高，能做到不同业务方不同版本APP的安全性隔离，在密钥生成算法或者密钥规则泄露后（低概率），可以及时更新密钥，阻止安全事故的扩大化；但同时也存在，可能对图片的使用造成轻微影响，算法可能较为复杂，在读取时对性能造成影响，算法门槛较高等问题。
• 最后一种较为简单，门槛低，同时对图片影响较小，读取开销相对较小，也能满足一般情况下的密钥获取方案；但当密钥获取算法或规则泄露后（低概率），阻止安全事故扩大化的成本相对较高，容易成为安全短板。

在得到了密钥之后，结合用户输入的信息，通过对称加密算法，生成加密后的密文再写入图片之中。
写入图片的方法很多，比如如下两种：

• 在jpg中，可以通过写入Exif区，这块区域存入了相机拍摄信息：时间、拍摄地点等等，可以在这个区域存入加密后的信息，实现图片的无损加密。
• 在png中，可以在IEND(png文件尾部)区域后追加加密信息，在此区域追加的信息不会影响图像的正常读取。但是用png格式需要注意在编译的时候会被编译器自动压缩，从而失去加密的信息。可以考虑动态获取安全图片来规避这个问题，比如从网络中加载图片再写入本地。

上述方案相对比较简单，如果对安全性有更高的需求，可以从图片本身结构入手，比如通过你要加密的信息构造出RGB、alpha等信息，然后按照标准png/jpg/bmp等格式构造出一张全新的图片，也可以在中间按照某种规则穿插一些混淆数据。这样生成的图片加密程度较高，不容易破解，但相对来说开发成本较高。

消费安全图片

目前我们的方案中，用户拿到包含密文和密钥的安全图片之后，需要把安全图片导入工程文件中（图片可以正常使用），然后由安全SDK获取图片中的密钥及密文，用密钥解密密文后，获取用户所需要的信息。这里的过程基本就是安全图片生成流程的一个反向过程。
不过和图片生成流程不同的是，安全SDK同时需要考虑SDK本身的安全性，所需要做一些额外的事情，比如：

• 检测APP是否被二次打包
• 检测是否正在被调试
• SDK关键方法混淆
• 使用c/c++增加逆向成本

限于篇幅，这里暂不展开讨论。

使用

使用工具生成安全图片

我们的工具是基于h5和node构建的，入口放在了内部移动门户上，使用非常方便。
界面如图：

只需要填入对应的BundleID（SHA1）/Key/Value，再传入一张APP中用到的图片，工具就会根据传入信息生成安全图片，并让用户下载至本地。

使用安全图片获取KEY

整合SDK到APP中，并导入安全图片后，SDK的使用方式非常简单，直接在APP中调用如下代码，即可获取所需key对应的value：

String value = SecuritySDK.get(String key);

总结

本文阐述了我们实现安全图片方案的基本思路，以及安全图片方案的流程。当然，其中还有一些具体实现，以及我们仍未完成但计划去完善的东西，包括但不仅限于以下：

• 包加固，APP加固
• 混淆的解决方案
• 防调试的方法
• 防逆向的方法
• 安全环境监测/风险控制/设备指纹
• 等等

这些在短短的一篇博客中都难以详尽表述，所以会在后续的文章中，再一一和大家详细说明，共同探讨。也欢迎各位不吝赐教，畅所欲言，发表自己的意见和感想。