因为某些接口涉及到用户支付信息和公司的一些敏感信息，所以领导提了个新需求要求研究接口的加密，所以本人对非对称加密做了一些小的研究和学习
基本流程：
1.服务端生成公钥和私钥。将公钥提供给客户端
2.客户端在请求接口之前要用服务端提供的公钥对请求参数进行加密
3.服务端用私钥对客户端传递的加密参数进行解密，处理请求
4.服务端用私钥对响应数据进行加密，之后传递给客户端
5.客户端接收到响应数据后用公钥解密，处理响应结果
这个是基本流程，但是有个问题出现了，假如有人也获得了公钥，并且用这个公钥模拟一个请求来请求服务端，那服务端是无法识别这个人的身份的，所以客户端在每个请求后面都要加上自己的身份标识，也就是数字签名来确保请求的合法性。
数字签名的基本流程：
1.服务端和客户端各自生成自己的公钥和私钥，并且交换各自的公钥
2.客户端每次请求前要用自己的请求参数要生成一段摘要，这段摘要是和参数内容唯一对应的
3.生成摘要后客户端用自己的私钥对摘要进行加密，用服务端的公钥对参数进行加密。然后把这段摘要放到参数结尾，发送请求。
4.服务端得到请求后首先取出这段加密后的摘要，用客户端提供的公钥进行解密，得出摘要结果；在用自己的私钥对请求参数进行解密，请求参数结果
5.服务端对解密后的参数结果进行摘要运算，再与解密的摘要结果进行比对，如果结果相同，说明请求合法，反之请求不合法。
看起来完美无缺了，但是又有一个问题出现了。这个hack很厉害，他将服务端和客户端各自提供的公钥都替换成他自己的公钥了，这样的话就完成了中间人攻击(Man-in-the-MiddleAttack)，所以数字证书。我认为数字证书类似与一个权威部门(Certificate Authority 简称CA)给我们提供公钥和私钥。获得CA的方法是去CA机构网站上填写一些自己的信息，然后CA 机构会使用自己的私匙将这些信息进行数字签名
CA(数字证书)的基本流程
1.客户端每次首先会向服务端请求数字证书，并且服务端在接收请求后会返回给客户端数字证书
2.客户端用本地的CA证书(客户端也要有权威部门颁发的证书)对回传的CA证书进行验证，来确定此证书是否由合法的CA结构颁发的。
3.如果此CA证书合法，那么验证证书内的公开信息(比如公司主页，公司名字什么的)来确定响应是否合法
以上3种方法的结合能很大程度上保障接口的安全性，但是所谓“道高一尺魔高一丈”，我们与hack的斗争从未停止
