产品经理需要了解的接口知识

作为后台产品经理，常常需要进行外部系统的对接，在设计开放平台接口过程中，往往会涉及接口传输安全性相关的问题，笔者在详细的查阅大量资料后，结合自身的过往经验，对于接口加密及签名的相关知识做了一个系统性的总结，在方便自己查阅的同时也分享给大家做一些参考，说明不当之处欢迎指正。

接口安全性问题主要来源于几方面考虑：

1. 防伪装攻击即请求来源是否合法？（案例：在公共网络环境中，第三方 有意或恶意 的调用我们的接口）
2. 防篡改攻击（案例：在公共网络环境中，请求头/查询字符串/内容 在传输过程被修改）
3. 防重放攻击即请求被恶意攻击（案例：在公共网络环境中，请求被截获，稍后被重放或多次重放）
4. 防数据信息泄漏（案例：截获用户登录请求，截获到账号、密码等）

从实现接口安全考虑，下面分别就加密解密和签名算法两方面进行讲解。

一、加密解密的概念与算法

1.1 为什么需要加密解密？

在客户端与服务器进行交互时，必然涉及到交互的报文（或者通俗的讲，请求数据与返回数据），如果不希望报文进行明文传输，则需要进行报文的加密与解密。

所以加密的主要作用就是避免明文传输，就算被截获报文，截获方也不知道报文的具体内容。

1.2 对称加密，单向加密，非对称加密的介绍与区别

加密分为对称加密和非对称加密：

• 对称加密效率高，但是解决不了秘钥的传输问题；
• 非对称加密可以解决这个问题，但效率不高。（其中https是综合了对称加密和非对称加密算法的http协议。）

1.2.1 对称加密

采用单钥密的加密方法，同一个密钥可以同时用来加密和解密，这种加密方法称为对称加密，也称为单密钥加密。

即约定一个秘钥，客户端使用这个秘钥对传输参数进行加密并提交至服务端，服务端使用同样的秘钥进行解密；

1）常用的对称加密算法：

1. DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合；
2. 3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高；
3. AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高，支持128、192、256、512位密钥的加密；

2）算法特征：

1. 加密方和解密方使用同一个密钥；
2. 加密解密的速度比较快，适合数据比较长时的使用；
3. 密钥传输的过程不安全，且容易被破解，密钥管理也比较麻烦；

3）加密工具：

openssl，它使用了libcrypto加密库、libssl库即TLS/SSL协议的实现库等。TLS/SSL是基于会话的、实现了身份认证、数据机密性和会话完整性的TLS/SSL库。

1.2.2 单向散列加密

单向加密又称为不可逆加密算法，其密钥是由加密散列函数生成的。单向散列函数一般用于产生消息摘要，密钥加密等

1）常用的单向散列加密算法：

1. MD5（Message Digest Algorithm 5）：是RSA数据安全公司开发的一种单向散列算法，非可逆，相同的明文产生相同的密文；
2. SHA（Secure Hash Algorithm）：可以对任意长度的数据运算生成一个160位的数值。其变种由SHA192，SHA256，SHA384等；
3. CRC-32，主要用于提供校验功能；

2）算法特征：

1. 输入一样，输出必然相同；
2. 雪崩效应，输入的微小改变，将会引起结果的巨大变化；
3. 定长输出，无论原始数据多大，结果大小都是相同的；
4. 不可逆，无法根据特征码还原原来的数据；

3）加密工具：

md5sum；sha1sum；openssl dgst

1.2.3 非对称加密

非对称加密即公钥加密，只有私钥能解密。私钥加密，只有公钥能解密。A首先生成一对公钥和私钥，然后将公钥公开给别人加密，别人使用公钥加密报文发送给A，A使用私钥解密。反之相同。（发送给某人，用某人的公钥加密。证明自己的身份，用自己的私钥加密）

非对称加密很少用来加密数据，速度太慢，通常用来实现身份验证，发送方用对方的公钥加密，可以保证数据的机密性（公钥加密）；发送方用自己的私钥加密，可以实现身份验证（数字签名）；

1）算法特征：

1. 秘钥对，公钥(public key)和私钥(secret key)
2. 非对称加密可以解决秘钥传输问题，但效率不高。

基于非对称加密的特性，又产生了以下两个问题：

问题1：如何确认通信方证书的合法性呢？

借助于第三方机构：CA(Certificate Authority)。CA为每个使用公开密钥的用户签发一个含CA签名的证书，该证书的作用是证明证书中的用户合法拥有证书中的公开密钥，CA机构的数字签名使得攻击者不能伪造和篡改证书。

CA自身也拥有一个证书和私钥。任何人都可以得到CA的证书，并用该证书验证它所签发证书有效性。

假设机构A向CA发出一个证书签发请求：(证书签发流程)

1. CA首先生成一对公钥和私钥，并自签署一个CA证书certificate；
2. A向CA提供自己的基本信息和自己的公钥；
3. CA先对A的基本信息和公钥计算一个特征码，然后再使用自己的私钥对特征码进行加密，加密生成的字符串（数字签名）、A的公钥、A的基本信息共同组成了CA签发的数字证书；

有了CA签发的数字证书，就可以通过CA来确认证书拥有者的身份，也就解决了通信中身份确认的问题。

问题2：通过CA实现了身份验证，那如何保证数据的机密性呢？

保证数据的机密性，无非就是给数据加密，非对称加密的加密速度慢，不适合对通信数据进行加密，而在实际通信过程中，身份确认完毕之后，通常使用对称加密方式来加密数据。那如何协商对称加密的秘钥呢？通常有以下两种方法。

方法1：秘钥交换(Internet Key Exchange, IKE)算法

Diffie-Hellman算法秘钥协商流程，假设A/B双发进行通信，

1） A/B通信前，先生成p,g两个大素数，作为生成数

2） A选定一个数x，B选定一个数y

3） A/B加密结果如下：

• A加密之后传递给B的内容: g^x%p –> B
• B加密之后传递给A的内容: g^y%p –> A

注意：互联网上的用户可以看到：p,g,g^x%p,g^y%p

4） A/B获得到数据之后解密得到相同的结果

• A: (g^x%p)^x=g^xy%p
• B: (g^y%p)^y=g^xy%p

这样A/B就协商出了一个共同的秘钥g^xy%p，A/B双方使用非对称加密确认完身份之后，就可以是用该秘钥加密通信数据了。

方法2：公钥加密的方式协商秘钥

1） A随机生成一个字符串STR作为秘钥，A先使用自己的私钥加密STR得到STR1，A再使用B的公钥加密得到STR2，A将STR2发送给B；

2） B接收到STR2，先使用B的私钥解密，再使用A的公钥解密，最后得到秘钥STR；

这样A、B就完成了秘钥的协商，协商的秘钥为随机字符串STR。

常用的非对称加密算法

• RSA：由 RSA公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的；既可以实现加密，又可以实现签名
• DSA（Digital Signature Algorithm）：数字签名算法，是一种标准的 DSS（数字签名标准）；
• ECC（Elliptic Curves Cryptography）：椭圆曲线密码编码；

ECC和RSA相比，在许多方面都有对绝对的优势，主要体现在以下方面：

1. 抗攻击性强，相同的密钥长度，其抗攻击性要强很多倍。
2. 计算量小，处理速度快。ECC总的速度比RSA、DSA要快得多。
3. 存储空间占用小,ECC的密钥尺寸和系统参数与RSA、DSA相比要小得多，意味着它所占的存贮空间要小得多。这对于加密算法在IC卡上的应用具有特别重要的意义。
4. 带宽要求低，当对长消息进行加解密时，三类密码系统有相同的带宽要求，但应用于短消息时ECC带宽要求却低得多。带宽要求低使ECC在无线网络领域具有广泛的应用前景。

1.3 加密算法

（1）DES加密算法

DES加密算法是一种分组密码，以64位为分组对数据加密，它的密钥长度是56位，加密解密用同一算法。

DES加密算法是对密钥进行保密，而公开算法，包括加密和解密算法。这样，只有掌握了和发送方相同密钥的人才能解读由DES加密算法加密的密文数据。

因此，破译DES加密算法实际上就是搜索密钥的编码。对于56位长度的密钥来说，如果用穷举法来进行搜索的话，其运算次数为256。

随着计算机系统能力的不断发展，DES的安全性比它刚出现时会弱得多，然而从非关键性质的实际出发，仍可以认为它是足够的。不过，DES现在仅用于旧系统的鉴定，而更多地选择新的加密标准。

（2）AES加密算法

ES加密算法是密码学中的高级加密标准，该加密算法采用对称分组密码体制，密钥长度的最少支持为128、192、256，分组长度128位，算法应易于各种硬件和软件实现。

这种加密算法是美国联邦政府采用的区块加密标准，这个标准用来替代原先的DES，已经被多方分析且广为全世界所使用。

AES加密算法被设计为支持128／192／256位（/32=nb)数据块大小（即分组长度）；支持128／192／256位（/32=nk)密码长度，，在10进制里，对应34×1038、62×1057、1.1×1077个密钥。

（3）RSA加密算法

RSA加密算法是目前最有影响力的公钥加密算法，并且被普遍认为是目前最优秀的公钥方案之一。

RSA是第一个能同时用于加密和数宇签名的算法，它能够抵抗到目前为止已知的所有密码攻击，已被ISO推荐为公钥数据加密标准。

RSA加密算法基于一个十分简单的数论事实：将两个大素数相乘十分容易，但那时想要，但那时想要对其乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥。

（4）Base64加密算法

Base64加密算法是网络上最常见的用于传输8bit字节代码的编码方式之一，Base64编码可用于在HTTP环境下传递较长的标识信息。

例如，在JAVAPERSISTENCE系统HIBEMATE中，采用了Base64来将一个较长的唯一标识符编码为一个字符串，用作HTTP表单和HTTPGETURL中的参数。

在其他应用程序中，也常常需要把二进制数据编码为适合放在URL（包括隐藏表单域）中的形式。此时，采用Base64编码不仅比较简短，同时也具有不可读性，即所编码的数据不会被人用肉眼所直接看到。

（5）MD5加密算法

MD5为计算机安全领域广泛使用的一种散列函数，用以提供消息的完整性保护。

对MD5加密算法简要的叙述可以为：MD5以512位分组来处理输入的信息，且每一分组又被划分为16个32位子分组，经过了一系列的处理后，算法的输出由四个32位分组组成，将这四个32位分组级联后将生成—个128位散列值。

MD5被广泛用于各种软件的密码认证和钥匙识别上。MD5用的是哈希函数，它的典型应用是对一段信息产生信息摘要，以防止被篡改。

MD5的典型应用是对一段Message产生fingerprin指纹，以防止被“篡改”。如果再有—个第三方的认证机构，用MD5还可以防止文件作者的“抵赖”，这就是所谓的数字签名应用。

MD5还广泛用于操作系统的登陆认证上，如UNIX、各类BSD系统登录密码、数字签名等

二、签名的概念与方法

2.1 为什么要签名？

1） 在客户端与服务器进行交互时，报文虽然加密了，但我们并不能确认这个报文是谁发过来的。例如，与第三方服务器B进行交互时，我方收到了一个已加密的请求，但我方并不能确认是服务器B发送的这个报文，此时我们可以用数字签名的方式来进行验证。作用：认证数据来源

2） 如果我方收到一个B服务器签名的请求，那么B服务器也无法否认这个请求，因为带有它的签名，作用：抗否认性。

3） 我方收到一个B服务器签名的请求，但我方并不能确认这个请求是否被篡改过（虽然报文加了密，也可能被篡改），此时即可用签名，验证签名中的报文与传过来的报文是否一致。作用：保证了数据的完整性

2.2 签名算法过程

签名的方式多种多样，常见的形式如下：

2.2.1 APPKEY+签名认证

1） 对除签名外的所有请求参数按key做的升序排列,value无需编码。（假设当前时间的时间戳是12345678）

例如：有c=3,b=2,a=1 三个参，另加上时间戳后， 按key排序后为：a=1，b=2，c=3，_timestamp=12345678。

2） 把参数名和参数值连接成字符串，得到拼装字符：a1b2c3_timestamp12345678

3） 用申请到的appkey 连接到接拼装字符串头部和尾部，然后进行32位MD5加密，最后将到得MD5加密摘要转化成大写。

示例：假设appkey=test，md5(testa1b2c3_timestamp12345678test)，取得MD5摘要值 C5F3EB5D7DC2748AED89E90AF00081E6 。

风险在于一但appkey被别人获取，即可仿照签名，造成安全性问题

2.2.2 token+签名认证

token+签名认证的主要原理是：

1） 做一个认证服务，提供一个认证的webapi，用户提交相关身份信息如供应商编码，先访问它

2） 服务端收到请求，去验证相关身份信息，验证成功后，服务端会签发一个token，token一般可以存储在缓存或数据库中，以方便后面查询出来进行验证。再把这个 Token 发送给客户端

3） 客户端收到 token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里；客户端每次向服务端请求资源的时候拿着相应的token以及请求的参数和服务器端提供的签名算法计算出签名后再去访问指定的api，服务端收到请求，就获取对应用户的token和请求参数，服务器端再次计算签名和客户端签名做对比，如果验证通过则正常访问相应的api，验证失败则返回具体的失败信息.

安全的关键在于参与签名的token，整个过程中token是不参与通信的，所以只要保证token不泄露，请求就不会被伪造。然后我们通过timestamp时间戳用来验证请求是否过期，这样就算被人拿走完整的请求链接也是无效的。

2.2.3 https模式

追求安全可以考虑https的双向验证模式 + 参数的sign签名的规则双重验证达到安全的请求后台

本文由 @不桡 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: