13

我正在考虑使用 AES256 CBC + HMAC SHA-256 作为确保机密性和身份验证的消息的构建块。

特别是，考虑这种情况：

  • Alice 拥有属于 Bob 的公钥（密钥交换和算法超出了本问题的范围）。Alice 有一个识别密钥 K，也与 Bob 共享，她可以用它来识别自己。只有 Alice 和 Bob 知道密钥 K。
  • Alice 使用 Bob 的公钥加密 (nonce || K)。
  • Bob 解密数据包，现在有 K 和 nonce。
  • Bob 使用 SHA-256 和 SHA256(K || nonce) 来产生 256 位的 K(e)。
  • Bob 使用 SHA-256 和 SHA256(K || nonce + 1) 来产生 256 位的 K(s)。

现在对于 Bob 希望发送给 Alice 的每个数据包，他执行以下操作：

  • 创建一个新的随机 128 位 IV
  • 使用 IV 和 K(e) 作为密钥加密消息。
  • 创建一个 SHA-256 HMAC，其中 K(s) 作为密钥，(IV || Encrypted message) 作为数据。
  • 最后将 (IV || HMAC || Ciphertext) 发送给 Alice

Alice 还计算了 K(e) 和 K(s)，并在接收 Bob 的数据时遵循以下过程：

  • 将消息拆分为 IV、密文和 HMAC。
  • 使用 K(s)、IV 和密文计算 HMAC。
  • 将 HMAC 与发送的 HMAC 进行比较。如果匹配，Alice 认为这个消息被认证为 Bob 发送的消息，否则被丢弃。
  • Alice 使用 K(e) 解密消息

这个协议是否确保 Alice 只解密来自 Bob 的消息，假设除了 Bob 之外没有人可以读取 Alice 发送给他的使用他的公钥加密的加密消息？

即以这种方式构建的消息是否确保机密性和身份验证？

注意：如果协议要求 Bob 发送多条消息，该方案需要稍作修改以避免重放攻击。

PS 我知道 AES-GCM/CCM，但这个方案适用于大多数加密包中的基本 AES、SHA 和 HMAC 算法。这个解决方案也可能会更慢，但这也超出了问题的范围。

4

3 回答 3

19

基本上你正在重新创建SSL/TLS。这意味着有关构建您自己的协议的常见警告，并且强烈建议您将 TLS 与现有库一起使用，而不是重写您自己的。

话虽如此，使用 AES 和 CBC 进行加密，使用 HMAC 进行完整性是合理的。有组合的加密+完整性模式（你知道），CBC+HMAC有点“老派”，但它不会受到伤害。您正在以“科学认可”的方式做事：加密，然后 MAC加密字符串（并且您不会忘记 IV：忘记 IV 是经典错误）。

您的密钥派生可能有点弱。如果 SHA-256 表现得像一个完美的随机预言机，那就完美了，但众所周知，SHA-256 的行为不像一个随机预言机（因为所谓的长度扩展攻击）。这类似于 HMAC 是 HMAC 的原因，具有两个嵌套的散列函数调用，而不是简单的散列（一次）MAC 密钥和数据的串联。TLS 使用特定的密钥派生函数（在 TLS 规范中称为“PRF”），这应该可以避免任何麻烦。该函数基于 SHA-256（实际上是基于 HMAC/SHA-256）构建，并且可以围绕任何典型的 SHA-256 实现来实现。

（我并不是说我知道如何攻击您的密钥派生过程；只是要正确地做到这一点是一件棘手的事情，并且只有在数百名密码学家多年的审查之后才能评估其安全性。这就是为什么重用函数和已经彻底检查过的协议基本上是一个好主意。）

在 TLS 中有两个随机数，称为“客户端随机数”和“服务器随机数”。在您的提案中，您只有“客户随机”。在安全方面，你在这里失去了什么还不清楚。一个谨慎的策略是包含一个随机的服务器（即 Bob 选择的另一个随机数）。我们想要避免的事情是当 Alice 和 Bob 在两个方向上运行协议时，攻击者将来自 Alice 的消息提供给 Alice 自己。对攻击者可以做什么的完整分析是复杂的（它是密码学的一个完整分支）；一般来说，两个方向的随机数往往会避免一些问题。

如果您发送多个数据包，那么您可能会遇到一些关于丢失数据包、重复数据包（“重放攻击”）和无序到达的数据包的问题。在 TLS 的上下文中，这不应该“正常”发生，因为 TLS 是在已经确保（在正常情况下，不计算主动攻击）数据以严格顺序传输的介质上使用的。因此，TLS 在进入 MAC 的数据中包含一个序列号。这将检测到来自攻击者的任何更改，包括重放、丢失记录和记录重新排序。如果可能，您还应该使用序列号。

于 2011-03-08T17:34:32.373 回答
2

上述问题的答案是否定的，不能保证 Alice 只解密来自 Bob 的消息，但这仅仅是因为您没有规定只有Bob 知道K。如果 Alice 和 Bob 是唯一知道K的两个人，那么问题的关键是您的密钥生成协议是否可靠。（我们可以忽略其余的，我相信，因为您只是使用 HMAC-SHA256 和 AES256，因为它们是打算使用的。）

生成协议还不错，但可以改进。从共享秘密创建密钥的公认方法是使用“密钥派生函数”。这些函数以与您在此处所做的类似的方式使用哈希，但它们也故意缓慢以抑制暴力攻击。 PBKDF2似乎是您想要的，因为它 a) 可以派生 512 位（或更多）的关键数据，并且 b) 可以由您可用的原语组成；即SHA256和HMAC-SHA256。

于 2011-03-08T17:03:05.157 回答
1

如果您不想使用 PKI，请查看 TLS-PSK。它似乎可以解决您自己解决的确切问题。请参阅 RFC 4279（和 5487 了解其他密码套件）。

于 2013-12-09T10:42:03.847 回答