APP和后端HTTP通信加密思路

这篇博客主要介绍笔者做app加密的具体思路

1.浅谈https

    https是目前应用最广泛的接口通信加密方式之一了，优点我就不说了（大家自行百度）。

    主要的两个缺点 a.有一定的技术门槛 b.花钱（最不想用的东西无非是太难或者太贵）

2.常用的加密算法

    1.MD5   

    2. AES 

    3. RSA  

    4.DES (3DES就是用3个不同的秘钥进行3次DES加密) 

    5.SHA-1

    简单地说2和4是对称（能加密能解密）的，1,3,5非对称，1存在暴力破解的可能性，3（公钥只能加密，私钥能加解密）

    任何一种加密方式都不是完美的，都有其应用方向，虽然MD5存在暴力破解的可能性，但是在笔者接触的大多数app和web项目中它却是现在应用次数最多的加密方式 . 一般通过增加加密次数来提高安全系数，例如：MD5（MD5（x））

    大多数产品提高安全性能的思路之一就是增加犯罪成本，加密也是如此。

3.确认加密的内容

    1.  关键信息是否单独加密 例：手机号，身份号，卡号，金额，具体什么是关键信息只能根据业务去判断

    2.  是否全报文加密

               不采用全报文加密意味着你的接口信息总是暴露的

               采用全报文加密会增加服务器的开销，也不能完全保证接口安全

 4.简单加密方案

        1.在app端生成一个随机码 R

        2.用AES+R加密全报文，比如得到加密后全报文data

        3.用RSA+公钥加密R，比如得到RR（app不保存R）

        4.data+RR

        后端解密就是反向操作了，

    由于RSA开销远大于AES所以只用RSA加解密随机码，用AES加密报文

 5.复杂加密方案

        上述的简单加密方案存在一个的风险，由于秘钥不固定不保存，所以一旦发生秘钥解密失败我们就无法获取报文内容。大部分时候当我们受到dos攻击时都是在报文里寻找攻击者的信息，所以大部分系统都不会采用动态的秘钥。

        一旦秘钥确定了加上安卓解包，理论上说接口是能破解的，所以接口安全的思路有一部分是在方法调用上设计

        1.混淆方法名，将aes加密方法名改成rsa，混淆秘钥名，将aes的秘钥命名为RSA_KEY

            混淆各种加密加密方法和秘钥就像郭靖当前写给欧阳锋的九阴真经一样

        2.让秘钥更加可控，首先将秘钥分类例如ZMK（主密钥简称Z）MARK（关键信息加密M），TMK（全报文加密T）用不同的秘钥加密不同的信息，秘钥本身也是密文的，存在后端数据库或者缓存，所有秘钥都受到主密钥的保护，主密钥可以设置分量保护。这样在APP端获取密文秘钥后解密成明文秘钥就不是件容易的事了。秘钥可以采用部分永久有效+部分时效性秘钥，当然这和你对系统的安全性要求是一致的，笔者接触过的系统中有一个用户一套秘钥，也有整个系统就一套秘钥。

        笔者也是新人，才学疏浅，经验不足，希望多多指正