Android 网络交互之移动端与服务端的加密处理
在开发项目的网络模块时，我们为了保证客户端（Client）和服务端（Server）之间的通信安全，我们会对数据进行加密。
谈到网络通信加密，我们可以说出：对称加密，非对称加密，md5单向加密，也能提到RSA，AES128，以及MD5等专业名词。
下面我们就来说明客户端（Client）与服务端（Server）的加密通信逻辑。
一、加密相关名词解析
- RSA：非对称加密，会产生公钥和私钥，公钥在客户端，私钥在服务端。公钥用于加密，私钥用于解密。
- AES：对称加密，直接使用给定的秘钥加密，使用给定的秘钥解密。(加密解密使用相同的秘钥)。
- MD5：一种单向的加密方式，只能加密，不能解密。
- Base64编码：对字节数组转换成字符串的一种编码方式。
二、通信加密的逻辑
2.1 明文传输通信逻辑（不安全）
1). 客户端将要上传的数据以字典(Map)的方式打包，Post提交给服务器。
2). 服务器接收提交的数据包，通过Key-Value的形式获取客户端提交的值，进行处理。
3). 处理结束，将数据以字典(Map)的形式打包，返回给客户端处理。
2.2 加密传输通信逻辑
整体流程：客户端上传数据加密 ==> 服务器获取数据解密 ==> 服务器返回数据加密 ==> 客户端获取数据解密。
三、通信请求安全性实现方案
请求安全性主要体现为： 服务器端在接收到请求的时候，要主动鉴别该请求是否有效，是否可接受。
常用方案如下：
3.1 使用 token 已登陆用户的识别码
解决问题：
用户调用接口时，不用每次都带上用户名和密码，避免了频繁在网络中传输密码被截获的风险。
使用场景：
用户登录系统时传入用户名和密码，服务器校验成功之后，根据uuid等参数生成token返回给客户端，同时把该token和该用户的对应关系缓存在服务器端。客户端在后续的请求接口中不用每次都传入用户名和密码，只需要传入token即可。服务器会根据token确定客户端的身份。
注意事项:
token可设置生效时间，token失效之后，客户端重新请求token。
3.2 sign:请求参数的签名
解决问题:
避免请求参数被恶意修改。保证了请求数据的一致性。
使用场景:
客户端和服务端约定一个签名生成算法。客户端在请求接口之前调用签名算法，根据参数生成sign值。然后把sign和请求参数一并传给服务器。服务器收到到参数和签名之后，根据请求参数，调用签名算法计算出签名，然后比较该签名和客户端传过来的签名是否一致，如果一致，则说明请求参数未被修改过，如果不一致，则说明请求参数被修改过。
3.3 nonce：请求中附带的随机数
解决问题:
防止恶意程序重复向服务器重复发送相同的请求。
使用场景：
客服端在向服务器发出请求之前，随机生成nonce参数。服务器在接收到请求之后，取出nonce参数，然后去缓存中查找是否已存在nonce的值。如果存在，则说明该请求已经收到过，则 拒绝本次请求，如果不存在，则说明首次接收到该请求，正常进行处理。
3.4 timestamp：客服端发送请求的时间戳
timestamp机制一般和nonce组合使用
解决的问题:
防止服务器端缓存nonce数据量过大的问题。当服务器缓存的nonce较多时，每次查找nonce就会耗费大量时间。通过添加请求时间戳，判断请求时间到服务器接收到请求的时间差是否在有效处理时间内（例如5分钟），如果在5分钟之内则进行处理，如果超出五分钟则拒绝该请求。这样，服务器端在缓存nonce的时候，可以设置nonce的缓存时间为5分钟，超出5分钟之后，自动清除掉缓存中的nonce，这样就避免了缓存大量nonce的问题。
使用场景:
客服端在发出请求时，附带timestamp，记录下当前的请求时间。服务器接收到请求时，取出timestamp，判断和当前的时间差，如果超出一定的时间(例如5分钟)，则放弃该请求。如果在5分钟之内，则取出nonce，去缓存中查找nonce，如果已存在则拒绝掉，如果不存在则正常处理。
四、通讯的数据保密性
数据保密性： http请求的数据无论是GET还是POST都可能会被抓包获取到数据。为了避免用户的敏感数据被窃取，则需要对数据进行加密处理。
1. AES:对称加密算法
使用方式:
客服端和服务器端共同确定一个用来加密和解密的秘钥。然后客服端在请求服务器是通过该秘钥对数据进行加密，服务器端在接收到请求之后使用该秘钥对数据进行解密。
优势：
加密效率高
缺点:
秘钥需要共享给客户端，具有泄露的风险
2.RSA:非对称加密算法
使用方式:
服务器端生成公钥和私钥，把私钥发送给客户端。客服端在请求服务器是，通过公钥对数据进行加密。服务器端接收到请求之后，使用私钥对加密的数据进行解密。
优势:
不需要共享私钥，避免了私钥泄露的风险。
劣势：
加密效率低，数据量大时较为耗时
五、Android端加密需要注意的问题
平时在开发的时候，尽量避免出现密钥硬编码。
开发者一般在做密钥存储的时候，主要形式有：
1、密钥直接明文存在sharedprefs文件中，这是最不安全的。
2、密钥直接硬编码在Java代码中，这很不安全，dex文件很容易被逆向成java代码。
3、将密钥分成不同的几段，有的存储在文件中、有的存储在代码中，最后将他们拼接起来，可以将整个操作写的很复杂，这因为还是在java层，逆向者只要花点时间，也很容易被逆向。
4、用ndk开发，将密钥放在so文件，加密解密操作都在so文件里，这从一定程度上提高了的安全性，挡住了一些逆向者，但是有经验的逆向者还是会使用IDA破解的。
5、在so文件中不存储密钥，so文件中对密钥进行加解密操作，将密钥加密后的密钥命名为其他普通文件，存放在assets目录下或者其他目录下，接着在so文件里面添加无关代码（花指令），虽然可以增加静态分析难度，但是可以使用动态调式的方法，追踪加密解密函数，也可以查找到密钥内容。
保证密钥的安全确是件难事，涉及到密钥分发，存储，失效回收，APP防反编译和防调试，还有风险评估。可以说在设备上安全存储密钥这个基本无解，只能选择增大攻击者的逆向成本，让攻击者知难而退。而要是普通开发者的话，做妥善保护密钥这些事情这需要耗费很大的心血。
产品设计者或者开发者要明白自己的密钥是做什么用的，重要程度怎么样，密钥被逆向出来会造成什么风险，通过评估APP应用的重要程度来选择相应的技术方案。一般情况下使用4、5就够了，尽量避免使用1、2、3的方式保存密钥。如果需要更高的安全性，建议使用一些知名的安全加固组件服务。
