前后端分离敏感数据 RSA或SM2，AES加密-解密

博主： Ganhua
发布时间：2021 年 06 月 19 日
6536 次浏览
1 条评论
2647字数
分类： Java 全栈笔记

前后端分离后通过Token令牌可以证明用户请求的合法地位，签名验签算法只能保证数据不被篡改，但是却无法对数据进行保密，首先明确一点就是https也是可以抓包的，当爬虫想要获取某个网站的数据的时候，显而易见的就是以下数据，这样使得别人分析该网站数据更容易。
</div>

```json
{
  "code": 79381119.43553731,
  "success": false,
  "message": "qui sed pariatur",
  "request_id": "ad dolor",
  "data": {
    "total": -8018639.024903253,
    "pageSize": 94441269.2485142,
    "pages": 90126383.11911938,
    "result": [
      {
        "id": 41490699.77987799,
        "userId": -32584976.230891317,
        "deviceName": "ullamco in nulla do occaecat",
        "ip": "ex eu ipsum amet mollit",
        "address": "elit dolore",
        "createTime": 83403093.16497034
      }
    ],
    "currentPage": -14141419.698228523
  }
}
```

#### RSA非对称加密

RSA加密算法是一种非对称加密算法，公钥加密技术有诸多的优点,但是其缺点也一样很明显,大多的公钥加密算法其性能开销基本都比密钥对称加密大得多,因此,他们一般都不用于加密大量的数据,在实际使用中,它们大多被用于交换其它更加经济快速的加密密钥对,或者被设计与数字签名，RSA算法中可能存在NSA的预置后门，对RSA算法的安全性产生巨大影响，RSA最大的缺点就是加解密中必须考虑到的密钥长度、明文长度和密文长度问题。明文长度需要小于密钥长度，而密文长度则等于密钥长度。

#### SM2国密非对称加密

SM2算法由国家密码管理局于2010年12月17日发布，是我国自主设计的公钥密码算法，基于更加安全先进的椭圆曲线密码机制，在国际标准的ECC椭圆曲线密码理论基础上进行自主研发设计，具备ECC算法的性能特点并实现优化改进。相对于RSA算法，256位的SM2密码强度已经比2048位的RSA密码强度要高，SM2算法具有抗攻击性强、CPU 占用少、内容使用少、网络消耗低、加密速度快等特点。

#### AES对称加密

AES的优点是无论明文有多大它都可以加解密。但是缺点是它不区分私钥和公钥，密钥只有一个，任何知道秘钥的人都可以加解密信息。

#### 非对称加密与对称加密结合使用取长补短

RSA和AES都有各自的优缺点，如果我们把他们结合使用就可以取长补短，我们可以使用RSA来保护AES的秘钥，这样可以保证只有双方知道AES的秘钥，并且AES可以加密任何长度的信息，这样就解决了它们各自的缺点。

#### 密钥交换逻辑

1. 客户端向服务器申请公钥，服务器生成SM2秘钥对，将公钥发送给客户端，我们起名叫Server publicKey。
2. 客户端收到服务器给的Server publicKey，客户端生成自己的SM2秘钥对，通过Server publicKey加密自己的公钥（Client publicKey）发送给服务端。
3. 服务端收到加密后的密文，通过Server privateKey解密出Client publicKey。（如果使用SM2国密算法，到这一步流程基本就结束了，因为SM2国密是没有加密长度限制的）。
4. 服务端生成属于某个客户端的唯一AES秘钥，通过Client publicKey加密后发送给客户端。
5. 客户端收到密文后，通过Client privateKey解密。
6. 以后所有的请求数据，全部使用该AES秘钥加密解密传输。

![请输入图片描述](https://cdn.ganhua.work/blog_static/images/2021/06/Encryption_process.jpg)

* 敏感数据建议使用post请求，加密过程：[Java示例代码](https://gitee.com/agile-bpm/rsa-encrypt-body-spring-boot)

</div>

##### 相关疑问

1. 为何前端还要在生成一次SM2秘钥给到后端公钥，然后由后端生成AES对称秘钥给前端呢，如果是前端生成AES对象秘钥然后通过后端的公钥加密给到后端，这样会有什么风险吗？

<span style='color:#FF0000'>其实这个逻辑是没有问题的，但是根据行业习惯服务端是不应该信任客户端的任何东西的，如果客户端生成AES秘钥，后端还需要判断这个秘钥是否正确，是否符合项目秘钥规定强度，且如果服务端生成，更容易管理相应的秘钥，服务端来确定是否过期等等。</span>
2. 在上面的这个流程中，如果在第一步客户端向浏览器请求公钥因为是走明文的，如果这时候服务端返回的公钥被中间人替换掉了，中间人把自己的公钥给到前端，这样后续的请求是不是就就不再安全了？这样的话这个流程是不是可以认为不算是安全的呢？

<span style='color:#FF0000'>关于中间人攻击，就需要引入第三方来解决信任问题，https 的 ssl 证书就可以，比如我请求www.baidu.com，你说你（中间人）是www.baidu.com，那你就出具 ssl 证书证明你是，如果证书对不上，那我就不信任你，不会继续交换秘钥了。申请 ssl 证书的时候会审核域名所有权，不是随便就能申请的，所以假冒的服务器端（中间人）是无法出具证书证明自己是www.baidu.com的。</span>

最后修改：2021 年 10 月 18 日