【项目】API接口的加签和验签

近期工作学习中，遇到了几个对接第三方 API 的需求。对于提供接口的平台，提供的接口为什么能保证安全可靠呢？这其中又是如何防止第三方的恶意使用呢？如何鉴别调用者的身份呢？

API 接口加密的原理

API 接口加密的原因无非就两个：

1. 核实调用方的身份，签名验签
2. 验证调用传输数据，数据加密

加密和解密的方式，根据加解密方式的异同可以分为：对称加密和非对称加密。

• 对称加密，加密和解密使用的是同一把密钥。常用的对称加密算法：DES，AES，3DES
• 非对称加密，加密和解密使用的是不同的密钥，一把作为公开分享给加密方的叫做公钥，另一把不分享作为解密的私钥。公钥加密的密文只有私钥能进行解密；私钥加密的密文也只有公钥能进行解密。常见的非对称加密算法：RSA，ECC
• 在效率上来说，对称加密的效率显然更高，但是非对称加密的安全性更高。所以一般在实际的HTTPS加密过程中，首次连接使用的是公钥加密算法（非对称加密）来传输数据加密所要使用的对称加密的密钥，之后传输中使用的都是对称加密算法。

公私钥加密和解密

鉴于对称加密的安全性通常并不高，所以通常是使用非对称加密的方式。这种方式，可以很大程度保证一个数据的安全。举个例子：

发送方将数据加锁，但是钥匙只有接收方才有。这样在数据加密之后，这段数据都是相对比较安全的状态。

发送者和接收者都有两种加解密的方法，而且把其中一套加密方法和解密方法都对外公开。这里默认加密方法是不能反推出解密方法的，解密方法是不能反推出加密方法的。也就是说，A 加密就必须 A 解密，B 加密就必须 B 解密。

在 HTTPS 中，使用非对称加密方式。比如 RSA 加密方式，使用的是大数取模运算，通过欧拉公式，得到加密之后的密文；但是因为取模运算本身不可逆，再加上大数取模运算，以现有的计算水平也很难在短时间内破解，所以只有拿到私钥才能知道原文的内容。

1. 在 A 向 B 发送信息的同时，需要带上自己的签名，这个时候 A 用自己才知道的加密方法 b 进行签名加密，因为任何人都知道解密方法 b，所以任何人都可以看到 A 的签名，也就是任何人都知道这条是 A 发出来的信息，但因为签名不是不能公开的信息，所以被解密了也没有关系。
2. 对于真正要发送的数据，A 会使用接收方公开的加密方式 c 来对数据进行加密。这样只有 B 使用自己的解密方法 c 才能解开，任何人即便获取了这个密文，包括 A 在内都无法再针对密文进行反向解密操作。

这样的方式下：

① 签名可以被任何人解密和获取，但是签名不涉及核心数据，无影响；
② 发送方使用接收方公开的加密方式进行数据加密，加密的数据只有接收方才能解密得到原始数据；
③ 接收方在收到调用方的数据之后，首先需要核验签名，如果签名不正确，那么数据也就不需要解密，直接抛弃该请求。

这样的过程会有一些问题存在：
一、因为签名可以被第三方破解，会不会出现签名伪造的情况？

不会。因为签名使用的加密方式，应该是发送方私有的加密方式，第三方即便知道解密后的签名，但是因为签名加密方法未知（请求方私有），还是无法伪造签名。

二、如果直接获得发送方的加密消息和签名呢？如何识别该请求来自于 A 呢？

就近期的工作中遇到的实际情况来说，这种情况不需要考虑，接受直接返回正常处理过后的数据即可。因为会考虑到请求方有使用其他客户端程序的情况，所以这种情况一般不予考虑。
原因有：
① 方便请求方的各种调试
② 接口提供方通常使用的是 Https 协议

三、这种方式的具体实现形式有哪些？

一般接口提供方会以 SDK 、 人工认证、平台文档的形式提供可公开的部分数据加解密方式，对应于图中的公开环境部分。
所接触到的各种验证方式，有：各种形式的 Token 结合使用、OAuth 验证对象传输。

公私钥的非对称加密 + session key 对称加密

公私钥的加密和解密方式，跟 Https 的公私钥加密是有部分相似的。

加密的过程中，一样使用的是公钥加密和私钥解密。区别是 Https 中使用的是 CA 来进行签名的核验和公钥的发布，使用的是系统层面写定的 CA 证书，相比于网络环境中公开的天然具有更高的安全性。
说回到 API 的公私钥的加解密方式，这样的方式中：
无论签名还是数据，使用的都是非对称加密和解密的方式进行。这类运算，通常使用的算法是比较复杂的，会对计算性能有一定的要求和影响。为了提高程序的性能表现，我们需要更加高效且能保证安全的加解密方式。
于是就有了公私钥的非对称加密 + Session Key 的方式。

这种方式，通信过程：

1. 发送方使用加密方式 b 加密自己的签名，接收方就可以利用解密方法 b 对签名进行解密操作。
2. 接收方生成一个 Session Key ，之后使用加密方法 a 对 Session Key 进行加密操作。之后接收方将加密之后的 Session Key 发送给发送方。发送方使用解密方法 a 对加密之后的 Session Key 进行解密操作。
3. 这样发送和接收双方都得到了相同的 Session Key ，之后的数据都使用 Session Key 作为密钥进行加密。协商之后，流通在网络环境中只有加密的数据，而不会再有和 Session Key 有关的数据。

实际生产中，这样的措施还有一定的安全风险。所以一般会对生成的 Session Key 有时效限制，在失效之后会重新进行第二步的 Session Key 生成和传输。

① 保证对称加密的密钥具有时效性，避免固定的规律被破解
② 由非对称加密转为了非对称加密

一、Session Key 被获取之后，如何保证安全？

首先，Session Key 被获取本身就非常困难。其次，被获取之后，Session Key 是具有时效性的，获取之后在一定时间之后会失效。再者，知道了 Session Key ，但是无法知道签名的加密方法，无法伪造发送方的身份，还是无法正常调用接口。

二、该方式和 Https 有什么区别？

实际上，该方式就是现在普遍使用的 Https 的方法的原理。先非对称加密，之后对称加密。只是对于时效性的控制上，会存在区别。

生产环境中的 Session Key/Token/Signature 更新实现

根据所接触过的生产案例，对于 Session Key/Token/Signature （简称 Token）数据，都会有时效性限制。一般常用的有三种方式更新：
一、附带一个 Refresh 值
在发送请求的时候，附带一个 refresh key ，该值和 token 的失效时长并不保持一致，通常会比 token 拥有更长的有效期。于是，两者就会存在一个时间差。当处在这段时间差时，表示 token 已经失效，但是 refresh 值还是有效状态，这个时候就可以将这两个值重新返回新值。
设计上，需要将这两个值设置为 k-v 结构，在使用时才能保证安全性。
二、使用原始的 client_id 和 client_secret 重新请求生成
一旦 token 失效，会提供一个专门的接口用来生成 token 并且回调。这个时候就需要根据原有的 client_id 以及 client_secret 进行重新获取 token 操作。

三、使用一次性 Token
每一次请求都会返回新的 token 值覆盖掉原有的 token 值。这意味着 token 只有一次的有效期。这样接口在返回的时候，会需要每次都返回下一次需要使用的 token 。

三者的选择：
在效率上考量，第二种会更好一些。因为网络 IO 中不需要服务方返回 Token 值，传输的数据量会更好。
安全性上考虑，一次性 token 的方案会更好。
难易程度考虑，前两者区别不大，第三种会对客户端带来一定的不便。

总结

接口的安全性，和网络是分不开的。所以大多数情况下，还是需要考虑网络环境的安全性。提到的解决方案，也有很多思想借鉴于网络协议。

参考文档：API接口入门（二）：API接口的签名验签和加解密原理
API 接口签名验签_新猿一马的博客-CSDN博客_接口签名