对称（DES/AES）与非对称（RSA/SSL/数字证书）加密介绍及实际应用

本文不对具体的算法做深入研究，只是讲解各种安全算法的原理和使用场景。

---

一、数据校验算法

数据校验,是为保护数据的完整性，用一种指定的算法对原始数据计算出的一个校验值。当接收方用同样的算法再算一次校验值，如果两次校验值一样，表示数据完整。

1、奇偶校验

能检测出信息传输过程当中的一位误码。出现错误不能检测出错误，只能要求重发。

2、 CRC循环冗余校验

         通过增加若干冗余位，可以检测出传输过程中的错误。检错和纠错能力强，在通信领域运用较广泛。

3、MD5校验

MD5算法是一种信息摘要算法，是通过哈希映射的原理得到一个大文件简短的MD5值。该算法是一种不可逆算法，也就是说开发者不能通过MD5值得到原始文件的数据。这里有一种可能性，不同的数据文件得到相同的MD5值，但是这种情况一般开发过程当中都不予考虑（数据碰撞）。

4、 SHA

SHA（Secure Hash Algorithm）是由美国专门制定密码算法的标准机构——美国国家标准技术研究院（NIST）制定的，SHA系列算法的摘要长度分别为：SHA为20字节（160位）、SHA256为32字节（256位）、 SHA384为48字节（384位）、SHA512为64字节（512位），由于它产生的数据摘要的长度更长，因此更难以发生碰撞，因此也更为安全，它是未来数据摘要算法的发展方向。由于SHA系列算法的数据摘要长度较长，因此其运算速度与MD5相比，也相对较慢。

同MD5算法相同，他也是一种不可逆的算法。

---

二、对称加密算法

• 1、Base64 编解码

该算法只能称为一种校验，是对原始的数据进行了一个编码的过程。 有编码就有解码，该过程是一个可逆的。该算法安全性较差，可以很轻松的通过解码将密文转换为明文，从而获取信息。

• 2、DES 数据加密算法

是对称加密算法领域中的典型算法，现在认为是一种不安全的加密算法，因为现在已经有用穷举法攻破DES密码的报道了。尽管如此，该加密算法还是运用非常普遍，是一种标准的加密算法。3DES是DES的加强版本。

DES加密的秘钥是 56位，而3DES加密算法的秘钥是 112位或者168位。3DES加密处理速度较慢、密钥计算时间较长、加密效率不高。

• 3、AES 数据加密算法（推荐使用）

Advanced Encryption Standard ，高级数据加密标准，AES算法可以有效抵制针对DES的攻击算法。

密钥建立时间短、灵敏性好、内存需求低、安全性高

DES/3DES/AES 三种加密算法的对比如下：

• 4、异或加密

异或运算中，如果某个字符（或数值）x 与 一个数值m 进行异或运算得到y，则再用y 与 m 进行异或运算就可以还原为 x ，因此应用这个原理可以实现数据的加密解密功能。

这种加密算法较简单，只是简单的将明文转换为不易看出的密文，破解的复杂度完全取决于秘钥的长度。

---

三、非对称加密算法

公开密钥加密，又称 asymmetric cryptography （非对称加密），即存在两把不同的密钥，分别称为公钥 Pu 和私钥 Pr,公钥通常用来加密明文 M,只有私钥才能解密密文 C,如果用 E 和 D 分别表示加密和解密算法，那么有：

C = E(M，Pu)；   // 加密公式,M为明文，C为密文，

M = D(C，Pr)；   // 解密公式

　　

传统的对称加密需双方共享相同的密钥，通信安全很大程度依赖双方是否能妥善的管理密钥。公开密钥加密发明是密码学最为重要的里程碑之一，它从数学的角度保证了通信安全。公开密钥加密体系有三大范畴：

• Encryption/Decryption:即加密与解密，发送方用接收方的公钥加密消息(秘钥由接收方生成，传送给发送方)

• Digital Signature:数字签名，发送方用公钥加密消息摘要生成签名，保证消息的完整性和可靠性

• Key Exchange:安全的交换密钥，通常用于交换对称加密的密钥（迪菲-赫尔曼密钥交换算法）

1、RSA加密

这种算法以欧拉函数为基础，这里不具体展开：

这种算法非常可靠，密钥越长，它就越难破解。根据已经披露的文献，目前被破解的最长RSA密钥是768个二进制位。也就是说，长度超过768位的密钥，还无法破解（至少没人公开宣布,因为大数的因式分解计算量特别大）。因此可以认为，1024位的RSA密钥基本安全，2048位的密钥极其安全。

具体原理可以见：公钥私钥的生成及加解密过程

http://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.htm

https://www.kancloud.cn/kancloud/rsa_algorithm/48488

2、SSL/TLS协议

具体来说，SSL/TLS 并不是一种算法，而是为了保证通信安全的一种协议，当然里面用到了相关加密算法如非对称加密算法、数字证书、HD秘钥交换算法等。Https多使用这种协议进行网络数据的传输。

---

通过上述这张图大致了解这种协议的通信过程。上述过程的目的只是为了获取比较安全的Session Key，当然这个Key需要Client Random + Server Random + Permaster secret 三者共同生成，安全性较高。Session key 用于后面通信对数据进行对称加密。 双方获得Session Key 后通过http协议进行数据传输，Session Key 用来对http传输的内容进行加密。

关于SSL/TLS的详细讲解请参考 阮一峰的博客链接。

http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

TOTP

TOTP 的全称是"基于时间的一次性密码"（Time-based One-time Password）。它是公认的可靠解决方案，已经写入国际标准 RFC6238。

它的步骤如下。

第一步：用户开启双因素认证后，服务器生成一个密钥。

第二步：服务器提示用户扫描二维码（或者使用其他方式），把密钥保存到用户的手机。也就是说，服务器和用户的手机，现在都有了同一把密钥。

第四步，服务器也使用密钥和当前时间戳，生成一个哈希，跟用户提交的哈希比对。只要两者不一致，就拒绝登录。

注意，密钥必须跟手机绑定。一旦用户更换手机，就必须生成全新的密钥。

算法原理：

TC = floor((unixtime(now) − unixtime(T0)) / TS)

上面的公式中，TC 表示一个时间计数器，unixtime(now)是当前 Unix 时间戳，unixtime(T0)是约定的起始时间点的时间戳，默认是0，也就是1970年1月1日。TS 则是哈希有效期的时间长度，默认是30秒。因此，上面的公式就变成下面的形式。

TC = floor(unixtime(now) / 30)

所以，只要在 30 秒以内，TC 的值都是一样的。前提是服务器和手机的时间必须同步。

接下来，就可以算出哈希了。

TOTP = HASH(SecretKey, TC)

TOTP 有硬件生成器和软件生成器之分，都是采用上面的算法。

---

数字签名过程（防止公钥被伪造 ）：

http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html

1、通过公钥私钥进行加密通信，发送方发送的内容只有通过私钥才能打开，所以保证了发送信息的私密性。

2、第三方可以把伪造的公钥给发送方，再截获发送的信息，通过自己的私钥解密信息。 这里Https协议中引入的CA（certificate authority）可以很好的解决这个问题。证书中心用自己的私钥为传输的公钥和一些信息进行加密，发送者可以通过证书中的公钥解密证书中的信息，这些信息中包含了需要传送的公钥。（暂且认为证书中的信息都是对的，一般证书中心都是可靠性比较高的机构颁发的）

通过Chrome打开百度网页的时候，F12建， Security菜单栏可以看到百度的证书。证书里面包含：颁发者、颁给者、公钥、有效期等信息。

a) 客户端向服务器发出加密请求

b) 服务器用自己的私钥加密网页以后，连同本身的数字证书，一起发送给客户端

c） 客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。

Android端如何使用https发送请求

网上关于https的使用文章大多数是关于浏览器如何通过签名进行验证的，浏览器会保存各个网站由CA认证中心颁发的数字签名并进行校验。那么问题来了，当客户端和服务端握手完成后，客户端如何判断服务端发送的公钥和相关信息没有被第三方篡改(对应c图)?  其实，客户端则需要提前将CA证书导入进来,当创建请求时将证书的相关信息添加进去即可完成https请求和验证。

android端实现https请求具体流程:https://developer.android.com/training/articles/security-ssl

客户端添加证书实现：

InputStream is = getAssets().open("srca.cer");
private SSLSocketFactory getSslSocketFactory(InputStream... certificates){
        try{
            CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");
            KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
            keyStore.load(null);
            int index = 0;
            for (InputStream certificate : certificates)
            {
                String certificateAlias = Integer.toString(index++);
                keyStore.setCertificateEntry(certificateAlias, certificateFactory.generateCertificate(certificate));

                if (certificate != null)
                    certificate.close();
            }

            SSLContext sslContext = SSLContext.getInstance("TLS");

            TrustManagerFactory trustManagerFactory =
                    TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());

            trustManagerFactory.init(keyStore);
            sslContext.init
                    (
                            null,
                            trustManagerFactory.getTrustManagers(),
                            new SecureRandom()
                    );
            return sslContext.getSocketFactory();
        }catch (Exception e){

        }
        return null;

    }

创建HttpsURLConnection完成后将证书信息设置进去再发送请求：

httpsConn.setSSLSocketFactory(sslSocketFactory);

http网络请求中的token

我们都是知道HTTP协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份,那么如何通过只登陆一次就能实现后续已登录状态呢？

1.用户登录校验，校验成功后就返回Token给客户端。

2.客户端收到数据后保存在客户端

3.客户端每次访问API是携带Token到服务器端。

4.服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

那么这里有个问题： 服务端怎么知道携带的token就是这个用户的token而不是伪造的？ 后续补充

签名的实际应用

---

现在有三个参数（A、B、C 封装在一个类Data中）需要传输到服务端，那么如何保证 这三个数据不是别人伪造发送的，可以在传这三个数据数据之外再添加一个数据 sign（String类型）。

　　客户端sign的生成算法：

　　第一步：对三个参数名称（与服务端提前约定好传输变量的名称）进行字典排序，拼接成字符串StringA（key1=value1&key2=value2&key3=value3），同时字符串的拼接遵循指定的规则。

　　第二步：在stringA最后拼接秘钥key（只有服务端和客户端知道，第三方不能获得，这也是签名的关键）得到finalStringA

　　第三部： 对finalStringA 做MD5计算，并将字符数组转换成16进制的字符串。

　　　　自此sign生成过程结束。

生成根据Data 中A、B、C三个参数的值以及Key 生成了sign之后，将sign值赋给Data中的sign。将Data转换成JSONObject格式再转换成字符数组

通过 HttpURLConnection传送到服务端。服务端通过拿到A、B、C的数值后会自己通过同样的算法生成sign，如果和客户端传送的Sign不一样则这次传送可能是第三方伪造的。

　　这种签名就保证了第三方不能伪造数据和服务端进行通信。（具体的流程如下图所示）

但是这里有个问题，其它人员获取到了通信秘钥secret，则可以伪造数据，毕竟客户端的代码很有可能被破解的（就算放在native层都可以被破解），但是对于安全等级较低通信这种加密措施也足够了。