前言
在这个互联网和移动互联网高速发展的时代，数据安全成了企业的头等大事。数据安全的范畴很大，包含：技术安全、服务安全、存储安全、传输安全等，本文主要是从传输安全的层面，设计一种基于JWE的API加密方案。
名词说明
**JWE **
JSON Web Encryption ，详细资料：http://self-issued.info/docs/draft-ietf-jose-json-web-encryption.html
目录
(一) 安全算法扫盲
(二) 安全方案演变
(三) JWE的介绍
(四) 基于JWE的API加密方案
本文主要讲解相关理论，后续会有实践的更新
(一) 安全算法扫盲
1.信息安全算法
1.1 加密相关算法
现代密码学中，把算法的加密技术主要分为：
单密钥模式
双密钥模式
无密钥模式
单密钥模式，也称为对称密钥模式，加密和解密方采用同一个密钥。采用这种模式的算法就叫做对称加密算法。
双密钥模式，也称作非对称密钥模式，加密和解密方采用不同的密钥。采用这种模式的算法就叫做非对称加密算法。
无密钥模式，也称作随机密钥模式，每次的密钥都是随机生成，使用一次之后失效。这是一种理想的加密模式，由于设计难度大，目前未得到广泛应用。
本文中主要针对前两类加密算法进行简单介绍。
1.1.1 对称加密算法（Symmetric Encryption）
对称加密算法，又称私钥加密算法，顾名思义加密和解密过程中只用到一个密钥，该密钥也称作私钥。
常见的对称加密算法有：DES、IDEA(基于DES)、3DES(基于DES)、RC4、RC5、RC6、AES。
特点
Feature 1. 速度较快，可适用于大数据加密；
Feature 2. 算法公开，密钥安全决定该算法安全；应用过程中要严格管理密钥。
部分算法对比
| 算法名 | 密钥长度 | 运算速度 | 解密时间(假设机器每秒尝试255个 ) | 资源消耗 |
|---|---|---|---|---|
| AES | 128、192、256 | 快 | 1490000亿年 | 低 |
| 3DES | 112、168 | 慢 | 45亿年 | 高 |
| DES | 56 | 较快 | 无参考 | 中 |
此数据转自:[http://blog.csdn.net/leolewin/article/details/48653351](http://blog.csdn.net/leolewin/article/details/48653351%29 和 [http://blog.csdn.net/dragon_ton/article/details/46651489]%28http://blog.csdn.net/dragon_ton/article/details/46651489)
1.1.2 非对称加密算法（Asymmetric Encryption）
非对称加密算法，又称公私钥加密算法，顾名思义加密和解密过程使用不同的密钥。公钥即为公开的密钥，一般用作加密；私钥即为私有的密钥，一般用作解密。
常见的非对称加密算法有：RSA、ECC、DSA。
特点
Feature 1. 速度慢，用于较小数据的加密；
Feature 2. 安全系数高
部分算法对比
| 算法名 | 成熟度 | 安全性 | 运算速度 | 资源消耗 |
|---|---|---|---|---|
| RSA | 高 | 高 | 慢 | 高 |
| DSA | 高 | 高 | 慢 | 只用于签名 |
| ECC | 低 | 高 | 快 | 低 |
数据参考：http://blog.csdn.net/dragon_ton/article/details/46651489
1.1.3 对称加密和非对称加密算法的对比
| 算法种类 | 代表 | 优点 | 缺点 |
|---|---|---|---|
| 对称加密算法 | AES | 运行速度快 | |
| 非对称加密算 | RSA | 安全系数高 | 运行速度慢、系统开销大 |
1.2 信息校验相关算法
信息校验相关算法主要分为3类：信息摘要、信息认证、信息签名。
1.2.1 信息摘要（MD-Message Digest）
信息摘要又称数字摘要，采用单向Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。
Hash算法又称散列函数，是一种单向的，从明文到密文的映射过程。
常见算法的Hash算法有：MD2、MD4、MD5、HAVAL、SHA-1、SHA256等。
特点
Feature 1. 过程不可逆。
Feature 2. 输出数据长度固定。
Feature 3. 保证数据的完整性。
部分算法对比
| 算法名 | 输出数据长度(bit) | 运算速度 | 安全性 |
|---|---|---|---|
| MD2 | 128 | 慢 | 低 |
| MD4 | 128 | 慢 | 低 |
| MD5 | 128 | 快 | 较高 |
| SHA1 | 160 | 快 | 较高 |
| SHA256 | 256 | 快 | 高 |
| SHA384 | 384 | 快 | 高 |
| SHA512 | 512 | 快 | 高 |
数据参考：
1.2.2 消息认证(MA-Message Authentication)
消息认证是指通过对消息或者消息有关的信息进行加密或签名变换进行的认证，目的是为了防止传输和存储的消息被有意无意的篡改，包括消息内容认证（即消息完整性认证）、消息的源和宿认证（即身份认证0)、及消息的序号和操作时间认证等。
消息认证通常在摘要算法基础上再做一个对称或非对称加密算法，用于防止信息被窃取，用于证明原文的完整性和准确性，也就是说，消息认证主要用于防止信息被篡改。
常用的消息认证算法是含有密钥散列函数算法，兼容了MD和SHA算法的特性，并在此基础上加上了密钥，通常也成为HMAC算法。
HMAC的详细介绍：http://www.ietf.org/rfc/rfc2104.txt
常见的算法有：HMAC-MD2、HMAC-MD4、HMAC-MD5、HMAC-SHA1、HMAC-SHA256、HMAC-SHA384、HMAC-SHA512。
特点
Feature 1. 保证数据完整性、准确性
Feature 2. 过程不可逆
Feature 3. 输出数据长度固定
部分算法对比
| 算法名 | 输出数据长度(单位:bit) | 运算速度 |
|---|---|---|
| HMAC-MD2 | 128 | 慢 |
| HMAC-MD4 | 128 | 慢 |
| HMAC-MD5 | 128 | 快 |
| HMAC-SHA1 | 160 | 快 |
| HMAC-SHA256 | 256 | 快 |
| HMAC-SHA384 | 384 | 快 |
| HMAC-SHA512 | 512 | 快 |
以下为具体测试数据
算法名：HMAC-MD2 循环次数：10000 总耗时：7943ms
算法名：HMAC-MD4 循环次数：10000 总耗时：4686ms
算法名：HMAC-SHA51 循环次数：10000 总耗时：96ms
算法名：HMAC-SHA256 循环次数：10000 总耗时：91ms
算法名：HMAC-MD5 循环次数：10000 总耗时：65ms
算法名：HMAC-SHA384 循环次数：10000 总耗时：100ms
算法名：HMAC-SHA1 循环次数：10000 总耗时：70ms
算法名：HMAC-MD2 循环次数：100000 总耗时：62078ms
算法名：HMAC-MD4 循环次数：100000 总耗时：51112ms
算法名：HMAC-SHA512 循环次数：100000 总耗时：892ms
算法名：HMAC-SHA256 循环次数：100000 总耗时：918ms
算法名：HMAC-MD5 循环次数：100000 总耗时：441ms
算法名：HMAC-SHA384 循环次数：100000 总耗时：919ms
算法名：HMAC-SHA1 循环次数：100000 总耗时：768ms
测试代码详见：https://github.com/vvvvken/SecurityAlgorithmCompare
1.2.3 数字签名（DS-Digital Signature）
数字签名技术是将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
数字签名保证信息传输的完整性、发送者的身份认证、防止交易中的抵赖发生。
常用的数字签名算法都是信息摘要的基础上用一个非对称加密算法进行加密处理。
常用的数字签名算法有：RSA、DSA、ECDSA。
特点
1.保证数据的完整性、正确性、不可抵赖性。
2.过程不可逆。
部分算法对比
| 算法 | 速度 | 安全性 | 密钥交换 | 用途 |
|---|---|---|---|---|
| RSA | 慢 | 高 | 支持 | 加密、解密、签名 |
| DSA | 较快 | 较高 | 不支持 | 仅用于签名 |
1.3 总结
信息安全相关的算法简单总结如下表：
| 算法类型 | 特点 | 算法举例 |
|---|---|---|
| 对称加密 - Symmetric Encryption | 速度快、可用于处理大数据、文件 | DES、3DES、AES |
| 非对称加密 - Asymmetric Encryption | 速度慢、用户小数据 | RSA、ECC |
| 消息摘要(MD) - Message Digest | 完整性 | MD2、MD4、MD5、SHA1、SHA256 |
| 消息认证(MA) - Message Authentication | 完整性、真实性 | HMAC-MD5、HMAC-SHA1、HMAC-SHA256、HMAC-SHA384 |
| 数字签名(DS) - Digital Signature | 完整性、真实性、不可抵赖性 | RSA、DSA、ECDSA |
(二) 安全方案演变
2.1 API数据加密方案的演变
2.1.1 HTTP+对称加密
在很久很久以前，互联网发展不久，部分企业开始注重安全，基于对称加密算法，设计了此方案。
如下图所示，用HTTP+AES举例的整个交互流程：
整个过程中只涉及到AES(对称)算法，仅且对传输中的数据进行加密。
安全性
| 安全项 | 描述 |
|---|---|
| 数据安全 | 通过AES实现 |
| 数据完整性(防篡改) | 无 |
| 数据真实性(防伪造) | 无，密钥暴露之后，可以被任意伪造 |
缺陷
- 密钥单一，无法实现动态密钥管理
- 密钥暴露之后，整套方案的安全性不攻自破
2.1.2 HTTP+对称加密+消息摘要
HTTP+对称加密这种方式有个明显的问题，信息在传输过程中可以被任意修改，无法保证数据的完整性，所以产生了此类方案。
如下图所示，用HTTP+AES+HASH摘要举例的整个交互流程：
在AES的加密基础上，做了消息摘要，服务端每次进行解密之前进行摘要验证，保证了数据的完整性。
安全性
| 安全项 | 描述 |
|---|---|
| 数据安全 | 通过AES实现 |
| 数据完整性(防篡改) | 通过信息摘要实现 |
| 数据真实性(防伪造) | 通过认证码实现 |
缺陷
- 密钥单一，无法实现动态密钥管理
- 密钥暴露之后，整套方案的安全性不攻自破
2.1.3 HTTP+对称加密+消息认证
HTTP+对称加密+消息摘要的方式已经在一些对安全性要求不是特别高的场合下使用了，但是对于安全性要求特别高的行业比如金融、教育等行业，还有待提高。所以人们改进了摘要机制，把消息摘要用消息认证码替换，形成了HTTP+对称加密+消息认证的方案。
如下图所示，用HTTP+AES+HMAC举例的整个交互流程：
AES+HMAC.png
此方式的特点是用消息认证码替换摘要，在普通的摘要基础上增加双向的校验，保证了数据的真实性。
安全性
| 安全项 | 描述 |
|---|---|
| 数据安全 | 密钥一旦暴露，客户端和服务端的过程都被破译 |
| 数据完整性(防篡改) | 通过认证码实现 |
| 数据真实性(防伪造) | 无，密钥暴露之后，可以被任意伪造 |
缺陷
- 密钥单一，无法实现动态密钥管理
- 密钥暴露之后，整套方案的安全性不攻自破
2.1.4 HTTP+非对称加密
前面的方案都是基于非对称加密算法，统一的缺陷就是密钥单一，无法实现动态管理，密钥本身的安全性得到了很大的威胁。基于这个考虑，提出了此方案。
如下图所示，用HTTP+RSA举例过程：
RSA.png
用非对称加密算法，整体替换对称加密算法。安全性都得到了保证，唯一的缺陷就是非对称加密算法的效率太慢，不适合大数据的加密。
安全性
| 安全项 | 描述 |
|---|---|
| 数据安全 | 通过RSA实现 |
| 数据完整性(防篡改) | 通过RSA实现 |
| 数据真实性(防伪造) | RSA的公钥和私钥配对实现 |
缺陷
- 性能低下，速度慢
- 不适用于大数据以及文件的加解密
2.1.5 HTTP+对称加密+消息认证+非对称加密
上述所有的方案都有缺陷，缺陷本身来源于加密算法，那么有没有一种办法把对称加密和非对称加密结合起来，互补对方的缺陷呢？
答案是肯定，人类的智慧是无穷，于是想到这种方案：
报文用对称加密，对称算法的密钥用非对称加密，如下图所示，用HTTP+AES+认证+RSA举例：
AES+HMAC+RSA.png
从安全的层面，该方案已经足够安全，能够达到绝大数的安全需求。现在市面上用此类方案的公司也很多。
特点
1，AES加密原始报文，速度快
2，HMAC对AES结果认证码，确保数据真实性
3，每次AES和HMAC的密钥都是随机生成，达到动态密钥的效果
4，密钥的安全由RSA算法保证，数据小，发挥RSA的优点
5，�RSA的密钥为2组，实现了双向认证
2.2.JWE的产生
假设1
假设我们用json格式来描述 HTTP+对称加密+消息认证+非对称加密的方案 的数据，那么json应该这样：
{
"ciphertext": "...",
"key": "...",
"authCode": "...",
}
客户端和服务端按照约定的算法进行相关操作，就可以正确的加解密数据。
假设2
在假设1的情况下，在json里面增加算法的描述，那么json应该这样：
{
"ciphertext": "...",
"key": "...",
"authCode": "...",
"cipherAlgorithm": "AES128",
"keyAlgorithm": "RSA1_5",
"authAlgorithm": "HMAC-SHA256"
}
客户端和服务端通信过程中实现指定的算法，就可以正确的加解密数据。
BINGO！到这里，我们主角就诞生了
3.1 JWE第一眼
这是一个使用标准JWE序列化的JSON
{
"protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected": {
"jku": "https://server.example.com/keys.jwks"
},
"header": {
"alg": "A128KW",
"kid": "7"
},
"encrypted_key": "6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ",
"iv": "AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext": "KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag": "Mz-VPPyU4RlcuYv1IwIvzw"
}
跟假设2的数据字段对比，有极其相似的字段，也有特有的字段。
回顾前面的过程，从2.1到2.5的算法演变，本质上都是安全性本身的提升，到了1.5之后，基本达到了一个非常安全算法设计。为什么会有JWE的提出呢？接下来，我们来认识JWE。
(三) JWE的介绍
JWE是JSON Web Encryption的缩写，简言之：用JSON描述加密。
JWE并不神秘，我们一步一步来了解它
3.1 JWE输出
3.1.1 输出数据
| 数据 | 描述 |
|---|---|
| JWE Encrypted Key | 密钥的加密数据 |
| JWE Initialization Vector | 加密原始报文用到的向量数据 |
| JWE AAD | Addtional Authentication Data,附件的认证数据 |
| JWE Ciphertext | 原始报文的加密数据 |
| JWE Authentication Tag | 数字认证标签 |
| JWE Protected Header | 受保护的Header字段，主要包含加密与认证相关的算法说明 |
| JWE Shared Unprotected Header | 非受保护的Header字段，除开Protected Header的其他信息 |
| JWE Per-Recipient Unprotected Header | 单条的Header字段 |
3.1.2 Header字段
| alg | 描述密钥用到的加密算法 | {"alg":"RSA-V1_5"} | 密钥使用RSA pkcs1算法进行密钥加密 | 是 |
|---|---|---|---|---|
| enc | 描述原始保护的加密算法 以及 认证码的生成算法 | {"enc":"A128CBC-HS256"} | 原始报文使用AES算法加密，密钥长度为128位，模式为CBC。认证码算法使用HMAC-SHA256 | 是 |
| zip | 描述原始报文的压缩算法 | {"zip":"def"} | 采用默认的压缩算法 | 否 |
| jku | 包含公钥的JWK Set的URL链接 | {"jku":""} | 密钥集合采用的地址为：https://server.example.com/keys.jwks | 否 |
| jwk | JWK的具体内容 | {"jwk":"..."} | 密钥采用的具体JWK值 | 否 |
| kid | JWK Set中指定的kid | {"kid":"rsa"} | JWK Set中采用id为“rsa”的JWK | 否 |
另外还有更多的header字段，参看：http://self-issued.info/docs/draft-ietf-jose-json-web-encryption.html#Header
3.1.2 JSON 格式
采用标准的JSON进行目标数据序列化
字段
| 字段名 | 描述 | 数据格式 | 是否密文 |
|---|---|---|---|
| protected | JWE Protected Header数据 | Base64UrlEncode | 否 |
| unprotected | JWE Shared Unprotected Header数据 | 字符串 | 否 |
| header | 字符串 | 否 | |
| encrypted_key | 密钥加密后数据 | Base64UrlEncode | 是 |
| iv | 向量数据 | Base64UrlEncode | 否 |
| ciphertext | 原始报文加密数据 | Base64UrlEncode | 是 |
| tag | 认证标签 | Base64UrlEncode | 是 |
json格式化
{
"protected":"<integrity-protected header contents>",
"unprotected":<non-integrity-protected header contents>,
"header":<more non-integrity-protected header contents>,
"encrypted_key":"<encrypted key contents>",
"aad":"<additional authenticated data contents>",
"iv":"<initialization vector contents>",
"ciphertext":"<ciphertext contents>",
"tag":"<authentication tag contents>"
}
样例
{
"protected": "eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0",
"unprotected": {
"jku": "https://server.example.com/keys.jwks"
},
"header": {
"alg": "A128KW",
"kid": "7"
},
"encrypted_key": "6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ",
"iv": "AxY8DCtDaGlsbGljb3RoZQ",
"ciphertext": "KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY",
"tag": "Mz-VPPyU4RlcuYv1IwIvzw"
}
3.1.3 压缩格式
压缩格式把数据进行BASE64UrlEncode，完了通过"."拼接每段数据结构。
序列化格式
BASE64URL(UTF8(JWE Protected Header)) || '.' ||
BASE64URL(JWE Encrypted Key) || '.' ||
BASE64URL(JWE Initialization Vector) || '.' ||
BASE64URL(JWE Ciphertext) || '.' ||
BASE64URL(JWE Authentication Tag)
样例
eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.
OKOawDo13gRp2ojaHV7LFpZcgV7T6DVZKTyKOMTYUmKoTCVJRgckCL9kiMT03JGe
ipsEdY3mx_etLbbWSrFr05kLzcSr4qKAq7YN7e9jwQRb23nfa6c9d-StnImGyFDb
Sv04uVuxIp5Zms1gNxKKK2Da14B8S4rzVRltdYwam_lDp5XnZAYpQdb76FdIKLaV
mqgfwX7XWRxv2322i-vDxRfqNzo_tETKzpVLzfiwQyeyPGLBIO56YJ7eObdv0je8
1860ppamavo35UgoRdbYaBcoh9QcfylQr66oc6vFWXRcZ_ZT2LawVCWTIy3brGPi
6UklfCpIMfIjf7iGdXKHzg.
48V1_ALb6US04U3b.
5eym8TW_c8SuK0ltJ3rpYIzOeDQz7TALvtu6UG9oMo4vpzs9tX_EFShS8iB7j6ji
SdiwkIr3ajwQzaBtQD_A.
XFBoMYUZodetZdvTiFvSkQ
3.1.4 序列化对比
| 序列化方式 | 简洁性 | 参数化(整体化) | 安全性 |
|---|---|---|---|
| JSON格式 | ✔️ | ✘ | ✘ |
| 压缩格式 | ✘ | ✔️ | ✔️ |
说明：
参数化是只把整个结果当做某个参数，比如在HTTP/GET中当做参数。
总结：
应用过程中，推荐使用压缩格式(JWE Compact Serialization)。
3.2 JWE过程
3.2.1 标准过程
从上面的JWE的输出结果，我们可以看出JWE大致需要，生成密钥、加密密钥、加密原始报文、数字认证等过程。我们来看看一个标准的JWE过程是怎样的：
step 1. 明确算法，生成JWE Header
step 2. 随机生成密钥
step 3. 加密密钥，并且Base64UrlEncode，生成JWE Encrypted Key
step 4. 随机生成向量，并且Base64UrlEncode，生成 JWE Initialization Vector
step 5. 加密原始报文，并且Base64UrlEncode，生成 JWE Ciphertext
step 6. 生成认证算法生成AAD
step 7. 截断AAD，获取Authentication Tag，并且Base64UrlEncode，生成JWE Authentication Tag
step 8. 序列化以上生成的5部分数据，导出JWE Serialization数据
图示如下：
3.3.2 示例
根据标准流程，我们使用一个一个AES+RSA+HMAC的例子来具体看JWE的示例过程
图示：
说明：
step 2.生成密钥，这个过程可以分2次随机，每次生成128bit，再拼接。
step 6.AAD数据可以不用传输，最关键的数据为step7生成的Authenticcation Tag。
3.3 JWE本质
通过上面的了解，我们可以简单总结下：
Feature 1. JWE并非某种特定的加密算法，是一套加密的协议
JWE可以根据需要，灵活结合各种加密算法。
Feature 2. JWE约束了加密流程步骤
** **JWE约束了基本的加密流程， 必须实现原始报文加密、密钥加密、数字认证等安全过程。
Feature 3. JWE约束了输出数据格式，有固定数据结构
JWE有固定的数据结构，2种学序列化格式都有严格的格式。
(四) 基于JWE的API加密方案
4.基于JWE的数据安全方案
4.1方案原型
回顾2.1-2.5的方案，我们来看看JWE的方案原型：
推荐做法
在JWE的过程中，基于安全考虑，密钥的的加密算法通常使用非对称加密算法，内容的加密用对称加密算法。改进后的原型如下：
4.2 算法选择
JWE的过程中，需要三次加密过程，通常的做法是
| 加密过程 | 算法 | 举例 |
|---|---|---|
| 原始报文加密 | 对称算法 | AES128、AES256 |
| 密钥加密 | 非对称算法 | RSA、ECC |
| 认证码生成 | HMAC | HMAC-MD5、HMAC-SHA1、HMAC-SHA256、HMAC-SHA384 |
4.3 特性
| 性质 | 描述 |
|---|---|
| 安全性 | 2次加密过程保证 |
| 真实性 | 通过数字认证机制保证 |
| 不可抵抗性(双向认证) | 通过非对称加密算法进行验证 |
| 动态密钥交换 | 对称算法的密钥每次都随机生成 |
网友评论