1

编辑

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

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

主要问题是

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

这是算法草图

  • 对于首次配对，实现了“点对点无线网络中的密钥协议”（DH-SC）中提出的解决方案。我基于以下承诺：
    • 通信实体/角色的修复“UUID”（128 位，在协议开始时发送，在提交之前）
    • DH 公钥（192 位私钥，基于 1024 位 Oakley 组）
    • 24 位随机挑战
  • 提交是使用 SHA256 计算的
    • c = sha256（UUID || DH 酒吧 || 查尔）
  • 双方交换此承诺，开放和传输上述价值的明文内容。
    爱丽丝鲍勃
    ca = 提交（）                        
                    --------^ 约
                                            cb = 提交（）
                    cb ^-----------
    打开
                    ---^ DH pub a, chall a
                                            打开
                    DH pub b，chall b ^---
  • 24位随机显示给用户进行手动认证

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

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

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

    • c = sha256（UUID || DH pub || DH sess || 查尔）

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

由于这并不完全符合我迄今为止发现的协议（以及它们的安全证明），我很想在这里获得更多启用加密的人的意见。顺便提一句。我确实读过“EKE”协议，但我不确定额外的安全级别是什么。

4

4 回答 4

2

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

对于这个小故事，VISA的家伙必须重新开始4次才能变得足够强大。

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

于 2010-12-29T09:42:06.753 回答
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 的值都与以前相同，那么哈希值之间就会存在关系。您应该注意避免散列扩展问题或在要散列的数据中包含盐值，方法是通过链接传递盐值或为每个代码路径设置不同的值。

附带说明：当您已经保存了先前的会话密钥并且不需要要求用户手动确认挑战码时，是否真的有必要传输挑战？

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

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

“1024 位组 DH 的整体安全性如何”

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

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

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

于 2011-01-02T06:15:51.197 回答
1

根据我对协议的理解，我提出了这种可能的攻击，灵感来自 Lowe 对 Needham-Shroeder 公钥协议的攻击：

  • 爱丽丝想重新连接。计算其承诺 ca 并发送给 Bob。该消息被马洛里捕获。
  • 马洛里回答。她不知道共享的秘密，所以她发明了一个。计算 cb 并发送给 Alice。
  • 在这一步，Alice 还不能验证共享密钥。所以她发送 DHpubA 和 ChallA。
  • 马洛里忽略了爱丽丝的消息并消失了。

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

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

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

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

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

于 2011-01-02T11:03:53.173 回答
0

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

于 2010-12-29T09:56:20.580 回答