端到端加密 数据包头部_关联数据的端到端身份验证加密

端到端加密 数据包头部

Recently my work requires me to implement the encryption of the credentials entered by the customer from the browser and the decryption at server side, in a secure and compliance manner.

最近，我的工作要求我以安全和合规的方式对客户从浏览器输入的凭据进行加密，并在服务器端进行解密。

The first thought came to my mind was the RSA public key/private key encryption algorism, which is straightforward.

我首先想到的是RSA公钥/私钥加密算法，这很简单。

Code is also straightforward:

代码也很简单：

https://gist.github.com/QingpingMeng/f51902e2629fc061c6b9fc9bb0f3f57b

https://gist.github.com/QingpingMeng/f51902e2629fc061c6b9fc9bb0f3f57b

This worked fine until I learned asymmetric encryption can only encrypt small amount of data which is up to the length of key size modulus minus a small number depending on padding mode.

直到我了解到非对称加密只能加密少量数据(取决于填充模式)，该数据最多达到密钥大小模数的长度减去少量后，此方法才能正常工作。

After some research, it’s usually recommended to use symmetric encryption like AES to encrypt the data where the limit of data size is infinite, then use RSA public key to encrypt the AES symmetric key and finally send the encrypted key and encrypted data to the server.

经过研究后，通常建议使用AES之类的对称加密对数据大小无限制的数据进行加密，然后使用RSA公钥对AES对称密钥进行加密，最后将加密后的密钥和加密后的数据发送到服务器。

The difference here is to generate an AES key with a random iv (initiate vector) from the browser. The plain text is encrypted using the generated AES key. Since this is a symmetric encryption, plain text can be any size. Next, we use the RSA public key to encrypt the AES key. The final cipher text will be the concatenation of encrypted key, iv and encrypted data. Note iv is required for the server side to restore AES decryption.

此处的区别是从浏览器生成带有随机iv(初始化向量)的AES密钥。 纯文本使用生成的AES密钥加密。 由于这是对称加密，因此纯文本可以是任意大小。 接下来，我们使用RSA公钥来加密AES密钥。 最终的密文将是加密密钥，iv和加密数据的串联。 注意iv是服务器端恢复AES解密所必需的。

Sample code: https://gist.github.com/QingpingMeng/f3d83886f66efa75df577b6ed811c5ba

示例代码： https : //gist.github.com/QingpingMeng/f3d83886f66efa75df577b6ed811c5ba

Now this seems good enough, isn’t it? Actually, not really. This is still not perfect because the server cannot validate the received encrypted data was tempered or not. In other words, the server cannot validate the authenticity of the encrypted data.

现在看来已经足够了，不是吗？ 其实不是。 这仍然不是很完美，因为服务器无法验证接收到的加密数据是否已调整。 换句话说，服务器无法验证加密数据的真实性。

There need to be some sort of signature of the encrypted data as part of the final payload so whoever receives the data is confident about its authenticity. So, let’s do solve it now.

作为最终有效负载的一部分，需要某种形式的加密数据签名，以便接收数据的人都可以确信其真实性。 所以，让我们现在解决它。

Now a new key HMAC key is generated on the browser side, which is a 32-byte random data. This HMAC key is used to sign the encrypted data and iv using SHA512 hash function, the result is appended to the final cipher text. At the same time, this HMAC key along with AES key is encrypted using RSA public key so encrypted key now includes two keys.

现在，在浏览器端生成了一个新的密钥HMAC密钥，它是一个32字节的随机数据。 该HMAC密钥用于对加密的数据进行签名，并且使用SHA512哈希函数进行iv，结果将附加到最终的密文中。 同时，此HMAC密钥与AES密钥一起使用RSA公钥加密，因此加密的密钥现在包括两个密钥。

How adding an HMAC key can prevent the encrypted data from being tampered?

如何添加HMAC密钥如何防止加密数据被篡改？

When server side received the cipher text, it can get the HMAC key and AES key buy decrypting the corresponding part. Next, server can use AES to get encrypted data and use HMAC key to re-calculate the authentication tag to make sure the result matched the authentication tag part of cipher text.

当服务器端接收到密文时，可以得到HMAC密钥和AES密钥购买来解密相应的部分。 接下来，服务器可以使用AES获取加密的数据，并使用HMAC密钥重新计算身份验证标签，以确保结果与密文的身份验证标签部分匹配。

Image the message was intercepted, since the attacker didn’t have the private key, it cannot know the HMAC key (HMAC is generated for each encryption and only browser know it). If attacker attempt to temper the data, the authentication tag will not match, and server can just throw this tampered message away.

图像被截获的消息，因为攻击者没有私钥，所以它无法知道HMAC密钥(HMAC是为每种加密生成的，只有浏览器知道它)。 如果攻击者试图调整数据，则身份验证标签将不匹配，服务器可以将这些被篡改的消息丢弃。

In this way, a secure E2E encryption is established.

这样，建立了安全的端到端加密。

Well till now, this is already very secure solution, but a little bit from perfection. Image the browser side need to send some insensitive payload to the server like the algorithms for encryption and signing and server can get this payload without decrypting the cipher text.

到目前为止，这已经是非常安全的解决方案了，但是离完美还差一点。 图像浏览器端需要向服务器发送一些不敏感的有效负载，例如用于加密和签名的算法，并且服务器无需解密密文就可以获取此有效负载。

So, we can add an extra header payload to the final cipher text. This payload is not participating the encryption but need to be protected from being tampered like the payload part of JWT.

因此，我们可以在最终的密文中添加额外的标头有效负载。 此有效负载未参与加密，但需要像JWT的有效负载部分一样受到保护，以防篡改。

Note a new input headers is introduced in this iteration. headers is base64Url encoded into a (short for associated data) and the length of headers is base64Url encoded into a_length .

请注意，此迭代中引入了新的输入headers 。 headers被base64Url编码为a (关联数据的缩写)，并且headers的长度被base64Url编码为a_length 。

The length of the associated data input a is included in the HMAC input to ensure that the encryptor and the decrypter have the same understanding of that length. Because of this, an attacker cannot trick the receiver into interpreting the initial bytes of cipher text as the final bytes of a.

相关数据输入a长度包含在HMAC输入中，以确保加密器和解密器对该长度具有相同的理解。 因此，攻击者无法诱骗接收者将密文的初始字节解释为a的最终字节a.

a and a_length are sent for calculating the authentication tag and a is appended to the first part of the final cipher text.

发送a和a_length以计算认证标签，并将a附加到最终密文的第一部分。

Now when server receives the final cipher text, it can extract the first part and decoded to get some unencrypted data.

现在，当服务器收到最终的密文时，它可以提取第一部分并进行解码以获得一些未加密的数据。

To make the server’s life easier without struggling to split the cipher text into various parts by byte size, we can leverage JWE (Json Web Encryption) to build the cipher text in this format.

为了使服务器的工作更轻松，而又不致于将密文按字节大小分成多个部分，我们可以利用JWE(Json Web加密)以这种格式构建密文。

This is exactly what is described below:

这正是下面描述的内容：

[AEAD-CBC-SHA] https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05

[AEAD-CBC-SHA] https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05

[RFC7516] https://tools.ietf.org/html/rfc7516

[RFC7516] https://tools.ietf.org/html/rfc7516

Final code sample for encryption at browser and decryption at server side:

用于浏览器加密和服务器端解密的最终代码示例：

https://gist.github.com/QingpingMeng/2313a08f6d86a4c1ac7eae7e52b2e54b

https://gist.github.com/QingpingMeng/2313a08f6d86a4c1ac7eae7e52b2e54b

翻译自: https://medium.com/swlh/end-to-end-authenticated-encryption-with-associated-data-d547595845a6

端到端加密 数据包头部