Android常见网络数据加密

这两天在整理网络请求加密相关的知识，发现有篇文章总结的很不错，转载一下，整体知识结构如原作者文章所述，部分地方有加入自己的补充或修改
转载请注明出处：
Android网络请求加密机制详解

Android开发中，难免会遇到需要加解密一些数据内容存到本地文件、或者通过网络传输到其他服务器和设备的问题，但并不是使用了加密就绝对安全了，如果加密函数使用不正确，加密数据很容易受到逆向破解攻击。还有很多开发者没有意识到的加密算法的问题。

1、需要了解的基本概念

密码学的三大作用：加密（ Encryption）、认证（Authentication），鉴定（Identification）
加密：防止坏人获取你的数据。
鉴权：防止坏人假冒你的身份。
明文、密文、密钥、对称加密算法、非对称加密算法，这些基本概念和加密算法原理就不展开叙述了。

加解密.png

$\color{blue}{Base64编码算法}$

Base64编码算法是一种用64个字符（ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/）来表示任意二进制数据的方法。在计算机网络发展的早期，由于“历史原因”，电子邮件不支持非ASCII码字符，如果要传送的电子邮件带有非ASCII码字符（诸如中文）或者图片，用户收到的电子邮件将会是一堆乱码，因此发明了Base64编码算法。至于为何会乱码？请大家自行Google。在加解密算法中，原始的数据和加密后的数据一般也是二进制数据，为了不传输出错，方便保存或者调试代码，一般需要对加密后的数据进行base64编码。
Android提供了Base64编码的工具类android.util.Base64，可以直接使用，不用自己去实现base64编码的算法了。如：

            /**
             * base64 编码
             * input: 第一个参数一般是加密后的byte型数据
             * flag: 第二个参数flag是编码解码方式，可填多个，此处表示略去换行符，还有其他几种flag下面有详细介绍
             */
            String base64String = Base64.encodeToString(input, Base64.NO_WRAP);

            /**
             * base64 解码
             * output: 需要base64解码的数据
             * flag: 编码解码方式，同上
             */
            byte[] bytes = Base64.decode(base64String , Base64.NO_WRAP);

Base64编码方式有以下几种：
CRLF：这个参数看起来比较眼熟，它就是Win风格的换行符，意思就是使用CR LF这一对作为一行的结尾而不是Unix风格的LF
DEFAULT：这个参数是默认，使用默认的方法来编码
NO_PADDING：这个参数是略去编码字符串最后的“=”
NO_WRAP：这个参数意思是略去所有的换行符（设置后CRLF就没用了）
URL_SAFE：这个参数意思是编码时不使用对URL和文件名有特殊意义的字符来作为编码字符，具体就是以-和_取代+和/
NO_CLOSE：这个参数意思是不关闭正在包装的输出流

开发者建议： base64只是一种编码方式，并不是一种加密算法，不要使用base64来加密数据。

$\color{blue}{消息认证算法}$

要确保加密的消息不是别人伪造的，需要提供一个消息认证码（MAC，Message authentication code）。
消息认证码是带密钥的hash函数，基于密钥和hash函数。
密钥双方事先约定，不能让第三方知道。
消息发送者使用MAC算法计算出消息的MAC值，追加到消息后面一起发送给接收者。
接收者收到消息后，用相同的MAC算法计算接收到消息MAC值，并与接收到的MAC值对比是否一样。

开发者建议：
建议使用HMAC-SHA256算法，避免使用CBC-MAC。

$\color{blue}{对称加密}$

在对称加密算法中，数据发信方将明文（原始数据）和加密密钥一起经过特殊加密算法处理后，使其变成复杂的加密密文发送出去。收信方收到密文后，若想解读原文，则需要使用加密用过的密钥及相同算法的逆算法对密文进行解密，才能使其恢复成可读明文。在对称加密算法中，使用的密钥只有一个，发收信双方都使用这个密钥对数据进行加密和解密，这就要求解密方事先必须知道加密密钥。

该算法的缺点是，如果一旦密钥泄漏，那么加密的内容将都不可信了。

DES
DES算法把64位的明文输入块变为64位的密文输出块，它所使用的密钥也是64位
DES算法流结构如下：

DES算法结构.png

DES算法流程图如下：

DES算法流程.png

由于DES默认使用56位加密密钥，已经不安全，如果想要安全使用DES加密，则需要注意避开使用第8,16,24，...64位作为有效数据位，操作起来没有那么方便，因此不是很经常使用，对称加密一般使用AES加密。
AES
AES算法流程
对于发送方，它首先创建一个AES私钥，并用口令对这个私钥进行加密。然后把用口令加密后的AES密钥通过Internet发送到接收方。发送方解密这个私钥，并用此私钥加密明文得到密文，密文和加密后的AES密钥一起通过Internet发送到接收方。接收方收到后再用口令对加密密钥进行解密得到AES密钥，最后用解密后的密钥把收到的密文解密成明文。下图是这个过程的实现流程。

AES算法流程.png

开发者建议：
1、建议使用AES算法。
2、DES默认的是56位的加密密钥，已经不安全，不建议使用
3、Android 提供的AES加密算法API默认使用的是ECB模式，所以要显式指定加密算法为：CBC或CFB模式，可带上PKCS5Padding填充。AES密钥长度最少是128位，推荐使用256位。

$\color{blue}{非对称加密}$

非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密（这个过程可以做数字签名）。
非对称加密主要使用的是RSA算法。

RSA
RSA算法实现流程
首先，接收方创建RSA密匙对，即一个公钥和一个私钥，公钥被发送到发送方,私钥则被保存在接收方。发送方在接收到这个公钥后,用该公钥对明文进行加密得到密文，然后把密文通过网络传输给接收方。接收方在收到它们后，用RSA私钥对收到的密文进行解密，最后得到明文。图8是整个过程的实现流程。

RSA算法实现流程.png

开发者建议：
1、注意密钥长度不要低于512位，建议使用2048位的密钥长度。

$\color{blue}{AES与RSA相结合数据加密方案}$

RSA算法是公开密钥系统的代表，其安全性建立在具有大素数因子的合数，其因子分解困难这一法则之上的。Rijndael算法作为新一代的高级加密标准，运行时不需要计算机有非常高的处理能力和大的内存，操作可以很容易的抵御时间和空间的攻击，在不同的运行环境下始终能保持良好的性能。这使AES将安全，高效，性能，方便，灵活性集于一体，理应成为网络数据加密的首选。相比较，因为AES密钥的长度最长只有256比特，可以利用软件和硬件实现高速处理，而RSA算法需要进行大整数的乘幂和求模等多倍字长处理，处理速度明显慢于AES[5]；所以AES算法加解密处理效率明显高于RSA算法。在密钥管理方面，因为AES算法要求在通信前对密钥进行秘密分配，解密的私钥必须通过网络传送至加密数据接收方，而RSA采用公钥加密，私钥解密（或私钥加密，公钥解密），加解密过程中不必网络传输保密的密钥；所以RSA算法密钥管理要明显优于AES算法。

从上面比较得知，由于RSA加解密速度慢，不适合大量数据文件加密，因此在网络中完全用公开密码体制传输机密信息是没有必要，也是不太现实的。AES加密速度很快，但是在网络传输过程中如何安全管理AES密钥是保证AES加密安全的重要环节。这样在传送机密信息的双方，如果使用AES对称密码体制对传输数据加密，同时使用RSA不对称密码体制来传送AES的密钥，就可以综合发挥AES和RSA的优点同时避免它们缺点来实现一种新的数据加密方案。加解密实现流程如下图：

AES与RSA相结合数据加密.png

具体过程是先由接收方创建RSA密钥对，接收方通过Internet发送RSA公钥到发送方，同时保存RSA私钥。而发送方创建AES密钥，并用该AES密钥加密待传送的明文数据，同时用接受的RSA公钥加密AES密钥，最后把用RSA公钥加密后的AES密钥同密文一起通过Internet传输发送到接收方。当接收方收到这个被加密的AES密钥和密文后，首先调用接收方保存的RSA私钥，并用该私钥解密加密的AES密钥，得到AES密钥。最后用该AES密钥解密密文得到明文。

Android端 AES+RSA结合实践
基本要求：
保证传输数据的安全性
保证数据的完整性
能够验证客户端的身份
基本流程：
Android端：

1.服务器端(server)分别生成自己的RSA密钥对,并提供接口给Android客户端获取RSA公钥(rsaPublicKey)。
2.client生成AES密钥(aesKey)。
3.client使用自己的AES密钥(aesKey)对转换为json格式的请求明文数据(data)进行加密，得到加密后的请求数据encryptData。
4.client提供server提供的接口获取RSA公钥(rsaPublicKey)。
5.client使用获取RSA公钥(rsaPublicKey)对AES密钥(aesKey)进行加密，得到encryptAesKey。
6.client将encryptAesKey作为http请求头参数，将加密后的请求数据encryptData作为请求体一起传输给服务器端。

服务器端

1.server响应client的http请求，读取http请求头。获得client传过来的加密后的AES密钥(encryptAesKey)，
读取http请求体，获得client传过来的加密后的请求数据(encryptData)。
2.server使用自己的RSA私钥(rsaPrivateKey)对加密后的AES密钥(encryptAesKey)进行RSA解密，得到AES密钥(aesKey)。
3.使用解密后的AES密钥(aesKey)对加密后的请求数据(encryptData),进行AES解密操作，得到解密后的请求数据(data)，该数据为json格式。
4.对解密后的请求数据(data)进行json解析，然后做相关的响应操作。

基本上如下图所示的流程：

Android端 AES+RSA流程.png

总结

几条原则：
1、不要自己设计加密算法和协议，使用业界标准的算法。
2、对称加密算法不要使用ECB模式，不建议使用DES算法。
3、要选择合适长度的密钥。
4、要确保随机数生成器的种子具有足够的信息熵。
5、不要使用没有消息认证的加密算法加密消息，无法防重放。
6、当多个字符串拼接后做hash，要非常当心。
7、当给算法加yan盐取值时不要太短，不要重复。
8、使用初始化向量时IV时，IV为常量的CBC，CFB，GCM等和ECB一样可以重放，即采用上一个消息的最后一块密文作为下一个消息的IV，是不安全的。
9、密钥应遵循的原则
（1）密钥不能为常量，应随机，定期更换，如果加密数据时使用的密钥为常量，则相同明文加密会得到相同的密文，很难防止字典攻击。
（2）开发同学要防范密钥硬编码的毛病。
而在实际开发中，密钥如何保存始终是绕不过的坎？如果硬编码在代码中容易被逆向，如果放在设备的某个文件，也会被有经验的破解者逆向找到，在这里推荐阿里聚安全的安全组件服务，其中的安全加密功能提供了开发者密钥的安全管理与加密算法实现，保证密钥的安全性，实现安全的加解密操作。