经过身份验证的Diffie Hellman变体的安全性审核

Question

修改

我仍然希望就此提出一些建议，我试图澄清我的意图......

当我在我的移动通信框架中遇到设备配对时，我研究了很多关于这个主题的论文，并且从此前的问题中得到了一些意见。但是，我没有找到准备实施协议解决方案 - 所以我发明了一个衍生物，因为我不是加密极客，我不确定最终解决方案的安全警告：

主要问题是

• SHA256是否足以作为提交功能？
• 是否在提交字符串安全中添加了共享密钥作为身份验证信息？
• 1024位组DH的整体安全性是什么
• 我假设成功MITM攻击的概率最多为2 ^ -24位（因为24位挑战）。这有道理吗？
• 最有希望的攻击可能是什么（除了从麻木，冰冷的手中撕下装置）

这是算法草图

• 对于第一次配对，实施了“对等无线网络中的密钥协议”（DH-SC）中提出的解决方案。我的基础是：
  • 修复通信实体/角色的“UUID”（128位，在协议开始时，在承诺之前发送）
  • 公共DH密钥（192位私钥，基于1024位Oakley组）
  • 24位随机挑战
• 使用SHA256计算提交
  • c = sha256（UUID || DH pub || Chall）
• 双方交换这一承诺，公开并转让上述价值观的简单内容。

    Alice                                   Bob
    ca = commit()                        
                    -------^ ca
                                            cb = commit()
                    cb ^-----------
    open
                    ---^ DH pub a, chall a
                                            open
                    DH pub b, chall b ^---

• 向用户显示24位随机数以进行手动验证

• 计算DH会话密钥（128字节，见上文）

• 当用户选择持久配对时，会话密钥与远程UUID一起存储为共享密钥

• 下次设备连接时，通过在随机质询之前另外散列先前的DH会话密钥来计算提交。确保打开时不会转移。

  • c = sha256（UUID || DH pub || DH sess || Chall）

• 现在，当本地方可以使用他自己的，存储的先前DH会话密钥来获得相同的承诺时，用户不会打扰进行身份验证。成功连接后，新的DH会话密钥将成为新的共享密钥。

由于这并不完全符合我迄今为止发现的协议（以及它们的安全性证据），我非常有兴趣从这里获得更多加密启用的人的意见。 BTW。我读过有关“EKE”协议的内容，但我不确定额外的安全级别是什么。

Answer 1

简单地说，如果您制作自己的加密解决方案，那么它很弱。

对于这个小故事，VISA人员必须再次开始4次才能变得足够强大。

我不是安全专家，但这是我的加密老师每次都告诉我们的。

Answer 2

“SHA256是否足以作为提交函数？”

使用SHA256应该没问题。我听说的唯一问题是它有一个散列扩展漏洞。如果使用相同的数据生成多个哈希，则不要简单地将更多数据连接到已经哈希的数据的末尾。在你的帖子中有两个哈希“sha256（UUID || DH pub || Chall）”和“sha256（UUID || DH pub || DH sess || Chall）”。如果第二个是“sha256（UUID || DH pub || Chall || DH sess）”，那么如果UUID，DH pub和Chall与之前的值相同，则哈希值之间会存在关系。您应该注意避免散列扩展问题，或者在要散列的数据中包含salt值，方法是通过链接传递salt或者为每个代码路径使用不同的值。

旁注：如果您已经保存了以前的会话密钥并且不需要让用户手动确认质询代码，是否真的有必要传送一个Chall？

“在提交字符串中添加共享密钥作为身份验证信息是否安全？”

我猜你的意思是问“将秘密信息包含在公开的哈希中是否安全？”如果这个秘密很难被猜测并且需要很长时间才能进行暴力攻击，那么肯定是安全的。如果这个秘密很容易被猜到或只有几个可能的值，那么不，这是不安全的，除非你同时包含一些难以猜测的秘密，迫使潜在的窃听者必须同时猜测所有这些秘密。对于一个大的，有效的随机数，如DH共享秘密，它应该没问题。

“1024位组DH的总体安全性是什么”

我不确定DH组1024是否是您想要使用的。被认为与您正在使用的SHA256哈希算法一样有效的密钥交换将是521位ECDH。 ECDH的加密强度被认为是1/2，因此如果您想要256位安全性，则需要521位ECDH。不幸的是，我不确定已发布的许多521位ECDH组的安全性。

“我假设最多2 ^ -24位成功的MITM攻击概率（因为24位挑战）。这是否合情合理？”

执行MITM攻击的方法不止一种。夏娃将使用她掌握的每一种资源来进行攻击，如果你不小心，她会利用你没想到的东西。这就是密码学中必须进行同行评审的原因。

Answer 3

基于我对协议的理解，我提出了这种可能的攻击，受到Lowe's Attack to Needham-Shroeder Public Key Protocol的启发：

• Alice想要重新连接。计算其承诺ca并发送给Bob。该消息由Mallory捕获。
• 马洛里回答。她不知道共同的秘密，所以她发明了一个秘密。计算cb并发送给Alice。
• 在此步骤中，Alice尚未验证共享密钥。所以她发送DHpubA和ChallA。
• Mallory忽略来自Alice的消息并消失。

现在，Mallory有一个有效的DHpubA，ChallA和相应的（有效）ca。

• Mallory将ca发送给Bob。
• Bob用cb。
回答
• Mallory发送一组有效的DhpubA，ChallA
• Bob发送他的DhpubB和ChallB

由于Bob可以验证Mallory的消息，因此她被认证为Alice。显然，Mallory并不知道DHprivA，她无法计算当前的会话密钥，但是你有一个安全漏洞，因为Bob认为他正在和Alice谈话。

一般建议：避免实施您自己的加密解决方案，并且不信任除了已建立的安全公司之外的任何人的安全审核。

如果您认为标准主流加密不满足您的安全要求，请尝试说明您的要求并询问是否存在与之匹配的安全协议。

Answer 4

听起来不错。不确定你的意思是“修复[ed] UUID”？ 流氓应用程序是否可以访问UUID和会话密钥：它们是存储在系统范围内还是存储在服务中？ SDK中有一些文本表明任何密钥库在返回密钥之前总是等待用户确认。