支付系统中的API属于典型的B2B的产品，对安全性的要求比较特殊，需要验证企业的合法身份，同时和客户端App的安全技术栈不同，面向B2B的API产品通常通过数据签名验签、数字证书和数据加密来保证其接口安全。
1、安全需求
在实施签名和加密安全策略时用签名还是用加密？用对称加密还是非对称加密？
这要从需求说起，安全也是需求的一种。安全需求无非是防篡改、防偷窥、身份识别、防抵赖和防泄露等。要满足这些安全需求，就需要对接口采用不同的安全策略和方法。
我们从安全学的发展历史开始说起。
（1）注册机加密时期。在Licence授权软件时期，并没有网络来验证各种加密算法，同时为了防止单机上的软件被盗用，通常在软件中写一段授权加密算法，如果用户输入的注册码满足注册机算法，就通过校验。这种方法有明显的缺陷：只要有足够强大的技术力量和计算能力，算法都是可以被破解的，所以好的软件一般都会有一 个对应的破解版本或注册机执行器。
（2）对称加密算法时期。在对称加密算法中，明文和密文双方约定使用同一个密钥，加密方用密钥进行加密，解密方用同一个密钥进行解密，如果可以成功解密，则说明加解密方都有权限对数据进行访问。
在API层面，对称加密算法有两种应用场景：数据MD5签名和通信数据加密。
数据MD5签名指采用MD5算法对传输的数据进行签名，以防止数据被第三方劫获并篡改。MD5也叫作MD5信息摘要算法（MD5Message-Digest Algorithm），是一种常用的密码散列函数，可以将数据生成一个128位（16字节）的散列值（Hash Value），从而确保信息传输的完整性和一致性。其做法是对待签名字符串（也就是待传输的数据）进行MD5算法签名，生成的签名数据（为32位小写字符）也就是通常公共参数中sign（签名）的值。
通信数据加密指对传输数据进行加密保护，主要是为了防止第三方偷窥数据信息和泄露信息，一般采用DES、3DES、N-DES、AES等对称加密算法进行处理。由于双方都有密钥，所以一旦密钥泄露，整个传输通道传输的数据都将被破解，这样一来影响面就非常广。并且有一种情况就是可以对数据请求进行抵赖，接收方没办法确认是否为真实发送方发送的数据，所以对密钥的安全保存就十分重要了。在这个时期衍生出来另外一种方式，就是定期对密钥进行升级，但始终解决不了数据抵赖的问题。
（3）非对称加密算法时期。在对称加密时期解决不了数据抵赖的问题，密码学家就在想能否生成一对密钥，于互验双方的身份，这样就可以防止数据抵赖了，所以最终由三位密码学家发明了非对称加密算法。非对称加密算法是一对密钥（由公钥和私钥组成），公钥加密的数据只能由私钥来解密，私钥加密的数据只能由公钥来解密。
并且可以使用公钥和私钥进行数据完整性和一致性的验证，也就是数据通信中的加签和验签。SSL/TLS采用的就是 非对称加密算法（RSA算法）。
（4）数据证书时期。在互联网时代，数字证书是用于识别和认证各方身份的一种数字认证。人们可以用它来识别对方的合法身份。
在支付系统中常用的就是CA（Certificate Authority）证书，CA证书是由证书授权中心颁发的证书，包含：证书拥有者的身份信息，用于证明证书拥有者的身份；在CA机构的数字签名中有一个密钥对（公钥和私钥），用于保证身份的真实性；同时，公钥和私钥用于在传输和通信过程中加解密，从而保证通信信息的安全性。
2、安全策略
所以，在支付行业的技术实现中，针对我们之前提出的接口安全需求，现在都有对应的安全策略。
（1）防泄露和防偷窥。在中等安全级别时可以使用AES、3DES对称加密算法，对于数据安全级别高的情况，可以使用RSA非对称加密算法进行数据加密。在通道层面可以采用SSL或TLS安全传输通道。依据Google的建议，目前大部网站都启用了HTTPS升级策略，支付系统对外公开的部分一般强制要求使用HTTPS通信。
（2）防篡改。在中等安全级别时可以使用对称的MD5数据签名，但如果对数据安全级别要求较高，则可以使用RSA非对称算法进行数据签名摘要和验签，同时可以使用数据证书进行身份验证。比如商业银行发行的网银盾牌硬件产品（U盾）已经成为很多银行的标准配置。
（3）防抵赖。必须使用RSA非对称加密算法进行签名和非对称加密。
（4）请求身份验证。主要用于验证某个网络请求是否由一个合法的请求者发起。HTTPS处理这种身份授权和验证的方法主要有OAuth、HMAC Auth等，不过通常采用OAuth。OAuth（OpenAuthorization）又叫作开放授权，目前的版本是OAuth 2.0，为用户访问授权定义了一个安全、开放及简单的标准，第三方请求授权时，无须知道用户真实的账号及密码，只需知道访问的令牌数据（AccessToken），就可以获取用户的授权信息，然后对资源或API进行访问。
其实现代码与之前的终端安全实现代码基本一致，此处省略。
