随着业务的增多，资源包的安全性越来越重要，hytive是怎么做到安全的呢？下面进行分析说明。
hytive 资源包的安全问题主要表现在传输安全和存储安全上, 若被中间人攻击替换代码，会造成较大的危害。
方案选择
方案一： 对称加密
若要在传输过程中不轻易被中间人截获替换，很容易想到的方式就是对代码进行加密，可以用zip的加密压缩，也可以用AES等加密算法。
优点： 简单 缺点： 安全性低，容易被破解。因为密钥要保存在客户端。只要客户端被人反编译，就很容易拿到密码。
对此方案有一些改进方案，例如：
- 可以把密码保存到 keychain 上，但这种方式也是不可靠的，只要随便找一台机器越狱装了这个 APP，用 hook 的方式在 APP 上添加一些代码，获得 keychain 里的密钥值，就可以用于其他所有机器的传输解密了。
- 给每个用户下发不同的密钥。但这样就非常繁琐，需要对下发密钥的请求做好保护，后台需要每次都对脚本进行不同密钥的加密操作，复杂性高了。
综上，对称加密安全性低，若要稍微提高点安全性，就会提升程序复杂度。
方案二：HTTPS
使用https传输，优点是安全性高，只要使用正确，证书在服务器端未泄露，就不会被破解。缺点是部署麻烦，需要服务器支持https，门槛较高。另外，客户端需要做好https的证书验证（如果漏掉，导致安全性大大降低）。
PS： https的认证方式网上文章较多，比如：http://oncenote.com/2014/10/21/Security-1-HTTPS/
如果服务器本来就支持https，使用这种方案也是一种不错的选择。
方案三：RSA 校验
上面两种方案的优缺点很明显，那么有没有安全性高、部署简单、门槛低的方法呢？RSA校验就可以做到。
RSA校验属于数字签名，用了跟https一样的非对称加密，只是简化了，把非对称加密只用于校验文件，而不解决传输过程中数据内容泄露的问题，而我们的目的是防止传输过程和本地存储的过程中数据被篡改，RSA校验正好可以解决这些问题。
Hytive 资源包的整个校验过程如下：
- 请求url
- job打qp包
- 通过私钥加密qp
- 生成加密后的md5
- 将qp和md5等上传到更新服务器
- 客户端请求
- 客户端计算qp包的md5
- 客户端通过公钥解密从服务端拿到的加密的md5
- 对比7和8两步的MD5值， 若相等，则校验通过
只要通过校验，就能保证资源在传输过程中没有被篡改。因为第三方若要篡改资源文件，必须计算出资源文件的md5并用私钥加密，客户端公钥才能解密，而服务端在未泄露的情况下，第三方是拿不到私钥的。
当然这种方案也有缺点，数据内容泄露，第三方可以很容易看到代码逻辑。 PS： 如果在意，可以对资源再进行一次对称加密
最后有个小问题，保存在客户端的代码也可以被人篡改，这个安全问题不大，能篡改本地代码的人，基本上已经有手机所有权限了，这时也无所谓资源会不会被篡改。若有需要，可以加个简单的对称加密。 hytive采用的是每次启动都验证一遍MD5值。