一、前言
随着移动通信技术的成熟和发展，移动互联网向各个行业的渗透开始加速，面向不同的人群和场景，金融行业也推出了各种移动应用，提供灵活便捷的移动金融服务。移动互联在金融行业快速推广的同时，系统安全和信息泄露问题也逐渐被人们所重视，从技术角度看，移动金融应用面临的风险主要体现在以下几方面： l App本地安全
由于目前智能手机尤其是Android手机的生态环境较为开放，并且Android开发编译后的中间语言因反编译难度不高而面临诸多风险，如：代码篡改、数据窃取、二次打包和病毒植入等。 l App操作安全
登录、注册、密码输入等涉密性较高的提交类操作面临着键盘监听、界面劫持等操作类风险。 l 网络通信安全
网络通信过程中，敏感信息易被http嗅探劫持，中间人攻击欺骗等。
在场外移动App的开发中，我们针对上述不同类型的风险引入与之相对应的技术组件来进行防范，下面分类进行介绍。
二、App本地安全
在移动应用开发的早期，通过字符串、类名、方法名混淆的，使反编译后的代码难以解读，从而使破解者无法下手修改。
随着业内技术的成熟，对移动应用的反篡改、反窃取、反调试、反逆向等方面都有了成熟的解决方案：
反篡改：对应用包内的代码文件、配置文件及资源文件生成唯一指纹标识，并提取文件的完整特征。在程序运行时对文件指纹及完整性进行校验，防止病毒植入、二次打包等恶意内容篡改。
反窃取：对应用运行中产生的数据文件内容进行加密，对文件路径进行加密。
反调试：使用多重加密技术对应用运行时的进程空间进行防护，防止动态调试、代码注入、Hook等恶意攻击。
反逆向：对应用执行文件采用高压缩和加密变形处理，对关键核心逻辑代码进行VMP保护，防止apktool、jeb等逆向工具分析获取获取源码。
在场外移动项目开发中，通过对业内主流应用加固厂商的调研，最终采用了360加固保的解决方案，在应用安装包体积、启动时间无影响的前提下，保证了场外移动应用的本地安全。
三、App操作安全
为了在用户输入关键信息时得到安全防护，阻止不法之徒利用键盘钩子、木马病毒等手段窃取用户数据，我们使用了图形验证码、手势密码、指纹密码、安全键盘等安全组件防范这些风险。 l 图形验证码
图形验证码采用四位数字组合，对登录、注册业务流程配合图形验证码来进行校验，可以防止恶意破解密码、批量注册等操作。 l 手势密码
手势密码组件能够对用户的关键操作进行身份认证。将用户创建的手势密码的九孔坐标转化为对应的数字密码，使用AES加密算法对数字密码进行加密，保存在系统钥匙串中。每次用户在进行手势密码验证时，从钥匙串中取出数字密码解密，与用户绘制的密码进行比对，验证通过则进入相应功能页面，并且在用户操作App的5分钟内不再进行手势密码的校验；验证失败提示剩余验证次数，验证失败次数超过5次，则直接5分钟内禁止手势密码验证。 l 指纹密码
对于支持指纹识别的机型，优先采用指纹密码进行身份认证。通过使用系统级Api进行指纹的识别与比对，能够更好地保证指纹密码的安全，在操作过程中指纹的识别率非常高，识别速度达到毫秒级别。 l 安全键盘
自定义安全键盘能够避免第三方输入法搜集用户输入信息，同时为了避免通过屏幕录制的方式获取密码，将安全键盘的进行无按下效果的处理。
四、网络通信安全
移动端与后台服务交互的方式有很多，RestApi和基于soap协议的webservices是常用两种交互方式，这两种方式的应用层协议都是http，http协议是没有加密的明文传输协议，很容易在数据传输的过程中被http嗅探工具劫持，修改传输的内容。为了保护用户的信息安全，我们从三个方面保护数据在网络上的传输，首先是采用https构建更安全的通信信道，其次是使用CA证书对传输内容进行签名，最后对整个报文再次进行加密处理，以增加恶意破解和修改的成本。 l 采用https构建更安全的通信信道
Https解决了通信信道的两个问题：一是建立了信息安全通道，来保证数据传输的安全；二是确认后台服务的真实性，即保证APP访问的是自己的服务器。
Https在真正请求数据前，先会与服务进行握手验证，以证明相互的身份，以下图为例
① 客户端发起一个https的请求，把自身支持的一系列Cipher Suite（密钥算法套件，简称Cipher）发送给服务端。
② 服务端接收到客户端所有的Cipher后与自身支持的对比，然后选择加密算法并生成证书和密钥对。
③ 服务器将证书和公钥返回给客户端。
④ 客户端验证服务器返回证书的合法性
⑤ 客户端生成随机对称秘钥key，使用服务端公钥加密发送给服务端
⑥ 服务端使用私钥解密，获取对称秘钥key。
⑦ 服务器端使用对称秘钥key对响应内容进行加密，并返回给客户端
⑧ 客户端使用对称秘钥key对返回内容进行解密，完成通信握手
因为这串对称密钥只有客户端和服务端知道，所以即使中间请求被拦截也是没法解密数据的，以此保证了通信的安全 l 使用CA证书对传输内容进行签名
上面的https解决了App只访问自己服务器的问题，那么如何解决服务器只能被自己的App访问呢？这里通过服务器验证签名的方式解决此问题。App发起请求前，将请求的内容信息通过hash算法得到摘要，再使用CA证书对摘要进行签名，服务器端接收到请求后，首先验证签名的准确性，验签不通过则拒绝访问。
Https+CA签名完成了通信流程上的双向认证，即移动端只能访问通过认证的服务器，而服务器只响应那些通过验证的移动端请求。 l 报文加密处理
为了增加传输内容的安全性和恶意破解的成本，我们在http通信链路加密的基础上，对每一次传输的内容也进行加密处理。具体加密方式如下图：
转播
