经过身份验证的Diffie Hellman的变种安全审查 [英] Security review of an authenticated Diffie Hellman variant
问题描述
修改
我仍然希望在这一些建议，我想澄清我的意图...
当我在移动通信框架临到设备配对我研究了大量的论文对这个话题，并且还得到了previous问题，一些输入在这里。但是，我没有找到一个准备执行协议解决方案 - 所以我发明了一种衍生物和我是没有加密怪胎我不知道有关的最终解决方案的安全注意事项：
主要的问题是
- 是SHA256足以作为一个提交功能？
- 就是加入了共享密钥作为提交字符串中的认证信息安全吗？
- 什么是1024位组的整体安全性DH
- 我认为成功的中间人攻击（因为24位挑战）最多为2 ^ -24位的概率。这是合理的？
- 什么可能是最有前途的攻击（除了翻录设备出了我的麻木，冰冷的手）
这是算法小品
- 对于第一次配对，在对等网络的无线网络密钥协商中提出的解决方案（DH-SC）被实现。我根据它源自一个承诺：
- 系统修复UUID为通信实体/角色（128位，在协议开始发送，承诺之前）
- 公共DH密钥（192位密钥的基础上，1024位Oakley组）
- 24位的随机挑战
- 提交使用SHA256计算
- C = SHA256（UUID || DH酒馆||查尔）
- 双方交换这一承诺，开放和转让上述值的普通内容。
爱丽丝鲍伯
CA =提交（）
------- ^ CA
CB =提交（）
CB ^ -----------
打开
--- ^ DH酒馆，CHALL一
打开
DH酒馆B，CHALL b ^ ---
- 24位随机显示给用户手动验证
-
DH会话密钥（128字节，见上文）计算
-
当用户选择持久配对，会话密钥存储在远程UUID作为一个共享的秘密
-
下一次设备连接，提交，通过附加散列随机挑战前的previous DH会话密钥计算。可以肯定的打开当它不转移。
- C = SHA256（UUID || DH酒馆|| DH SESS ||查尔）
-
现在用户不打扰身份验证时，当地党委可以用自己的存储previous DH会话密钥产生相同的承诺。成功的连接后，新的DH会话密钥成为新的共享机密。
由于这并不完全符合我迄今发现协议（，因此它们的安全性证明），我会很感兴趣得到从这里一些加密启用家伙的意见。 BTW。我看过关于EKE协议，但我不知道额外的安全级别是什么。
是SHA256足以作为一个提交功能？
使用SHA256应该就好了。我听到的唯一的问题是，它有一个哈希扩展漏洞。如果生产使用相同的数据的多个哈希值不只是的concat更多的数据，以您已散列的数据的末尾。在您的文章有有两个散列SHA256（UUID || DH酒馆||查尔）和SHA256（UUID || DH酒馆|| DH SESS ||查尔）。如果第二个是SHA256（UUID || DH酒馆||查尔|| DH SESS），那么就不会有散列值之间的关系，如果UUID，DH酒馆，和查尔都是相同的价值观和以前一样。您应该小心避免哈希扩展问题，或者包括盐值到待哈希数据，或者通过为每个code路径通信链路上的盐或具有不同的山谷。
在一个侧面说明：是不是真的需要发送查尔，当你已经有一个previous会话密钥保存，无需要求用户手动确认挑战code
就是加入了共享秘密，因为在提交字符串安全认证信息？
我猜你的意思是问是否安全，包括在一个哈希是要公开的秘密信息？如果秘密是什么，真的很难猜测，并会采取很长一段时间对抗进行暴力破解攻击，那么是的，它是安全的。如果秘密的东西容易被猜到或者只有很少的可能值，则没有，这不是安全的，除非你的，在同一时间，包括一些难以猜测的秘密，迫使潜在的窃听者必须同时猜测所有这些秘密。对于像DH共享秘密大，有效的随机数就应该就好了。
什么是1024位DH组的整体安全性
我不知道，如果DH组1024是你想用什么。这被认为是一个密钥交换是接近于为你使用是521位的ECDH SHA256散列算法有效。 ECDH的加密强度被认为是1/2，所以如果你想256位的安全性，你想521位ECDH。不幸的是，我不能确定有关已公布的许多个人521位ECDH群体的安全性。
我想顶多2 ^ -24成功的中间人攻击（因为24位挑战）的位概率。这是合理的？
有一个以上的方式进行MITM攻击。夏娃将使用一切资源在她的处置进行她的攻击，如果你不小心，她会利用一些你没有想到的。这就是为什么同行评议是密码必要的。
EDIT
I'm still hoping for some advice on this, i tried to clarify my intentions...
When i came upon device pairing in my mobile communication framework i studied a lot of papers on this topic and and also got some input from previous questions here. But, i didn't find a ready to implement protocol solution - so i invented a derivate and as i'm no crypto geek i'm not sure about the security caveats of the final solution:
The main questions are
- Is SHA256 sufficient as a commit function?
- Is the addition of the shared secret as an authentication info in the commit string safe?
- What is the overall security of the 1024 bit group DH
- I assume at most 2^-24 bit probability of succesful MITM attack (because of 24 bit challenge). Is this plausible?
- What may be the most promising attack (besides ripping the device out off my numb, cold hands)
This is the algorithm sketch
- For first time pairing, a solution proposed in "Key agreement in peer-to-peer wireless networks" (DH-SC) is implemented. I based it on a commitment derived from:
- A fix "UUID" for the communicating entity/role (128 bit, sent at protocol start, before commitment)
- The public DH key (192 bit private key, based on the 1024 bit Oakley group)
- A 24 bit random challenge
- Commit is computed using SHA256
- c = sha256( UUID || DH pub || Chall)
- Both parties exchange this commitment, open and transfer the plain content of the above values.
Alice Bob
ca = commit()
-------^ ca
cb = commit()
cb ^-----------
open
---^ DH pub a, chall a
open
DH pub b, chall b ^---
- The 24 bit random is displayed to the user for manual authentication
DH session key (128 bytes, see above) is computed
When the user opts for persistent pairing, the session key is stored with the remote UUID as a shared secret
Next time devices connect, commit is computed by additionally hashing the previous DH session key before the random challenge. For sure it is not transfered when opening.
- c = sha256( UUID || DH pub || DH sess || Chall)
Now the user is not bothered authenticating when the local party can derive the same commitment using his own, stored previous DH session key. After succesful connection the new DH session key becomes the new shared secret.
As this does not exactly fit the protocols i found so far (and as such their security proofs), i'd be very interested to get an opinion from some more crypto enabled guys here. BTW. i did read about the "EKE" protocol, but i'm not sure what the extra security level is.
"Is SHA256 sufficient as a commit function?"
The use of SHA256 should be just fine. The only issue I have heard of is that it has a hash extension vulnerability. If you produce multiple hashes using the same data don't simply concat more data to the end of the data you already hashed. In your post have have the two hashes "sha256( UUID || DH pub || Chall)" and "sha256( UUID || DH pub || DH sess || Chall)". If that second one was "sha256( UUID || DH pub || Chall || DH sess)" then there would be a relation between the hash values if UUID, DH pub, and Chall were all the same values as before. You should either take care to avoid the hash extension issue or include a salt value into the data to be hashed, either by communicating the salt across the link or having differing vales for each code path.
On a side note: is it really necessary to transmit a Chall when you already have a previous session key saved and don't need to ask the user to manually confirm the challenge code?
"Is the addition of the shared secret as an authentication info in the commit string safe?"
I'm guessing you mean to ask "Is it safe to include secret information in a hash that is to be made public?" If the secret is something that is really hard to guess and would take a really long time to perform a bruteforce attack against, then yes it is safe. If the secret is something easy to guess or has only a few possible values, then no, it's not safe unless you, at the same time, include some hard to guess secret to force a potential eavesdropper to have to guess all such secrets simultaneously. For a large, effectively random number like a DH shared secret then it should be just fine.
"What is the overall security of the 1024 bit group DH"
I'm not sure if DH group 1024 is what you want to use. A key exchange that is considered to be close to being as effective as the SHA256 hash algorithm you're using would be 521 bit ECDH. The cryptographic strength of ECDH is considered to be 1/2, so if you want 256 bit security, you want 521 bit ECDH. Unfortunately, I'm not certain about the security of the many individual 521 bit ECDH groups that have been published.
"I assume at most 2^-24 bit probability of succesful MITM attack (because of 24 bit challenge). Is this plausible?"
There is more than one way perform a MITM attack. Eve will use every resource at her disposal to perform her attacks and if you are not careful she will exploit something you didn't think of. This is why peer review is necessary in cryptography.
这篇关于经过身份验证的Diffie Hellman的变种安全审查的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
