mPaas组件的安全设计介绍

一 背景

由于金融行业的特殊性,对安全的要求很高,所以mPaas内很多模块都采用了很多安全策略,包括RPC的加签加密,离线包的签名校验,移动同步的tcp+ssl机制,热修复的加密配置等。本文主要介绍下我对常见mPaas模块的安全设计的理解,方便后续更好的使用。

二 RPC

作为mPaas最重要的组件之一,RPC提供了客户端和服务端的安全通信通道,其中涉及安全的主要包括加签和加密。其中加签解决的是防止客户端被伪造,加密解决的是防止请求数据被泄漏。

1. 加签

mPaas组件的安全设计介绍

1. 整体流程

  1. 在mPaas后台初始化应用的时候,会为每一个App创建一个唯一的appSecret
  2. 客户端通过appid,WorkspaceID,appSecret等信息,生成无线保镖图片。通过无线保镖模块的加密,保证了存放在客户端的appSecret的安全性
  3. 客户端请求的时候,从无线保镖获取appSecret,同时添加OperationType,time,requestData等因子做md5计算,添加到header发到MGS网关

4. MGS收到后按照同样的方法再计算一次MD5,如果一致,则通过校验

2. 优势

通过无线保镖机制,保证了内置在客户端内的appSecret的安全性。


2. 加密

mPaas组件的安全设计介绍

1. 整体流程

  1. 通过openssl生成非对称秘钥,客户端保存公钥,服务端报错私钥
  2. 客户端每次请求rpc都会生成一个新的对称秘钥,通过第一步生成的非对称秘钥进行加密,生成SecKey
  3. 客户端使用对称密钥同时对原始数据进行加密,得到加密的数据SecData
  4. 移动网关通过保存的私钥对SecKey进行解密得到对称密钥
  5. 通过上一步得到的对称秘钥,对加密数据SecData进行解密,得到原始数据

2. 优势

RPC的加密采用了混合加密的模式,使用了非对称加密和对称加密的组合。如果单纯使用对称秘钥,虽然性能较好,但是保证不了足够的安全性。如果单独使用非对称加密,虽然保证了安全性,但是会导致性能变差,不适合RPC这种大量通信的场景。所以RPC采取的这种混合加密模式,很好的结合了两者的优点。

3. 防抓包

在客户端端为了防止数据被抓包软件抓到,客户端进行了防止抓包的设置,通过设置网络库禁止代理的方式,解决了被抓包的风险。代码如下

 httpParams.setParameter(ConnRoutePNames.DEFAULT_PROXY, ConnRouteParams.NO_HOST);

三 离线包

作为业务使用很多的离线模块,为了保证下发到本地的离线包模块没有被篡改,离线包提供了签名校验机制。

1. 整体流程

  1. 提前通过openssl生成公钥和私钥,公钥内置在客户端内,私钥存储到服务端
  2. 离线包打包的时候,服务端对当前离线包的文件做md5计算,然后将计算后的值通过非对称秘钥进行加密生成加密后的签名数据,随离线包下发到客户端
  3. 客户端每次打开离线包的时候,通过客户端内的公钥获取下发的md5和本地的离线包文件做md5对比,如果一致,则校验通过,如果不一致,则删除离线包,直接访问fallback资源

mPaas组件的安全设计介绍

2. 优势

  1. 由于是每次打开离线包都做校验,保证了离线包的来源正确和不被篡改
  2. 校验失败后直接降级到fallback地址,减少对客户使用的影响

四 版本发布

版本发布服务提供了apk的发布功能,同时为了保证下载的apk文件不被篡改,提供了基于md5的完整性校验。在上传apk的时候,会基于当前的apk生成md5下发,本地安装的时候本地下载文件的md5和会和服务端下发的md5做匹配,如果匹配成功才会继续安装。服务端下发的md5字段如下图所示。

mPaas组件的安全设计介绍

五 移动同步

移动同步服务Sync是基于TCP进行通信的,为了保证安全,Sync可以配置为TCP+SSL模式进行通信。当指定Sync的端口号为433端口后,客户端就会开始基于tcp+ssl实现长连接,长连接请求到服务端后,需要通过F5或者其他类似负载装置完成SSL卸载,最后到MSS实现长连接。整体流程如下图所示:

mPaas组件的安全设计介绍


上一篇:mPaas客户端证书错误避坑指南


下一篇:mPaaS-H5导航栏定制化