有赞移动

安全图片方案

前言

安全问题在互联网,软件领域从来都是不可忽视的,而随着移动互联网的发展,移动端不管是在设备持有量上,还是在用户数量上,都已经超越传统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:

1
String value = SecuritySDK.get(String key);

总结

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

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

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