RSA加密在与银行端Http REST接口调用中的应用

简单介绍一下我们项目的背景，我们公司是金融公司A，开发的这个系统是一个跟第三方银行B进行接口调用的系统，每天公司A内部系统会生成一批数据，这些数据包括公司客户名，身份证号，银行卡号，扣款金额等信息，会通过HTTP Web API接口调用的方式，把这些数据推送给银行B端，因为这些客户都是签署了代扣协议的，银行B端就会从这些人的银行卡中扣款。最后，银行会把批量的扣款结果，通过回调我们公司A接口的方式，推回我们公司。

 

1. 如果使用HTTP协议，肯定会存在安全问题。举个例子，在A向银行B发送的数据中，包含用户张三的应扣款为20块钱，使用http的方式传输，并且使用的是明文，这些流量在半路被人拦截了，并进行了篡改，张三的应扣款被改为了5块钱，到达银行那端的话，银行也是无法察觉的。所以不能使用明文传输的方式。

 

2. 为了保护信息不被篡改，我们进行了改进，将明文变成了密文。采用的是RSA加密的方式。银行端产生了一对公钥B跟私钥B，他们自己保留私钥B，然后通过证书的形式把公钥B给我们公司。我们保留自己的私钥A，然后通过证书的形式把公钥A给银行。注意，这时候一共有两对秘钥对，分别是银行的私钥B跟公钥B，我们公司A的私钥A跟公钥A。在我们自己的服务器上有两个文件，一个是pfx文件，包含我们自己的私钥A，另一个是cer文件，包含银行的公钥B. 相对的，银行端服务器也有两个文件，私钥B跟公钥A.

每次我们向银行发消息的时候，会先用银行的公钥B进行加密，然后银行那端收到消息后会进行解密，用私钥B进行解密。然后银行端向我们公司调接口的时候，会用公钥A进行加密，然后我们这端收到消息后会用私钥A进行解密。这样保证了消息传播的安全。

3. 如果说我们公司自己去制造一个私钥公钥并且生成证书比较复杂的话，可以参照HTTPS的过程对项目进行改进。这样，就只有银行端具有一对公钥与私钥，银行保留私钥，然后将公钥以证书的形式给到我们公司。接下来，如果传输一次数据，那么就不仅仅是一个http请求，而是多次的http请求，需要对我们每一次的API请求进行结构化，即(1)我们公司先发一个请求到银行，一个http请求，可能只包含一个简单的文字，比说Start, 告诉银行端这要发起一个API调用，(2)然后我们公司需要先动态生成一个对称秘钥，然后我们使用银行的公钥，对这个动态生成的秘钥进行加密，加密完成后传给银行。银行接受到之后，明白了之后需要用这个秘钥进行加密解密。这里之所以是以后用对称加密，是因为非对称加密比较效率低。现在有了可靠的方式传输对称秘钥，以后就可以用对称加密传输内容了。(3) 我们这边用对称加密的秘钥进行加密，然后传给银行端。(4) 银行端接到消息后，用对称加密的秘钥进行解密。(5) 公司端发一个结束的请求给银行，只包含一个简单的文件，比如End, 告诉银行这次请求结束了，你把刚刚发给你的秘钥删了吧。(6) 银行删秘钥。准备好下一轮的请求。

 

其实，这个逻辑更适用于TCP的模式，而不是HTTP。 TCP的话是一个连接，这个使用HTTP的话，会有多次的连接打开关闭。