AES256 CBC + HMAC SHA256确保机密*和*身份验证?

Nuo*_*oji 13 security cryptography aes hmac

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

特别要考虑这种情况:

  • Alice拥有属于Bob的公钥(密钥交换和算法超出了该问题的范围).Alice有一个识别密钥K,也是与Bob共享的,她可以用来识别自己.只有Alice和Bob知道密钥K.
  • Alice使用Bob的公钥加密(nonce || K).
  • 鲍勃解密数据包,现在有K和nonce.
  • Bob使用SHA-256和SHA256(K || nonce)来产生256位的K(e).
  • Bob使用SHA256和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算法.此解决方案也可能较慢,但这也超出了问题的范围.

Tho*_*nin 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中有两个 nonce,称为"客户端随机"和"服务器随机".在您的提案中,您只有"客户端随机".你在这里失去的安全性,有点不清楚.谨慎的策略是随机包含服务器(即Bob选择的另一个nonce).我们想要避免的事情是Alice和Bob在两个方向上运行协议,并且攻击者自己将Alice的消息传递给Alice.对攻击者可以做什么的完整分析是复杂的(它是密码学的一个完整分支); 一般来说,两个方向的随机数往往会避免一些问题.

如果您发送了几个数据包,那么您可能会遇到一些有关丢失数据包,重复数据包("重放攻击")和无序到达数据包的问题.在TLS的上下文中,这不应该"正常"发生,因为TLS用于已经确保(在正常条件下,不计算主动攻击)数据按严格顺序传输的介质上.因此,TLS包括进入MAC的数据中的序列号.这将检测攻击者的任何更改,包括重播,丢失记录和记录重新排序.如果可能,您还应该使用序列号.