挑战-响应协议-如何结合客户端的随机性
挑战-响应协议-如何结合客户端的随机性
提问于 2018-11-06 13:21:53
我正在设计一个挑战响应协议，以使客户端能够对服务器进行身份验证。客户端拥有一个私钥和一个证书(由受信任的CA颁发)。在协议的这一点上，服务器知道客户机声称是谁，但想证明它。我的第一次尝试是：
C ← S : r_S
C → S : S_C (r_S)
其中：
r_S是由S(服务器)生成的随机挑战。S_C(r_S)是挑战的签名，与C的S(客户的私钥)签署。
问题在于，私钥+证书可以用于其他目的，而不是将客户端标识到服务器上。(例如，授权发票付款。)妥协的服务器可以向客户端发送发票支付授权的散列，并获得必要的签名来授权它。
下一次尝试：
C ← S : r_S
C → S : r_C, S_C (H(r_S | r_C))
其中：
r_C是由C生成的随机数。- H是一个合适的密码散列函数。
- 其他条款如下
这安全吗？具体来说，妥协的服务器可以使用这样的方案来计算某些预定值的S_C(V) V吗？
特别地，
- 把
r_C放在连接中会更安全吗？ - 简单的连接是否足够好，或者我是否需要使用硬编码密钥
K甚至\text{HMAC}_{r_C}(r_S)(使用r_C作为HMAC的密钥)计算D32？
回答 1
Cryptography用户
发布于 2018-11-06 18:52:23
- 在可能的情况下，不应允许为不同目的使用相同的证书/私钥。
- 您的问题的答案首先取决于您使用的签名方案的安全性。如果签名方案令人难以忘怀，那么您应该很好。不可伪造性是指恶意服务器可以选择任何消息并获得相应的签名，但仍然不能伪造未查询的消息的签名。服务器只获得
H(r_s||r_c)的签名，但不能生成其他签名。然后，问题是H(r_s||r_c) =m的可能性有多大，其中m是有意义的东西，而服务器想要它的签名。在这种情况下，无法忘记是不够的，因为服务器可以简单地重用签名而不需要伪造签名。如果您使用的H是冲突电阻，而r_c足够长，那么H(r_s||r_c)应该是一个一致的随机值。H(r_s||r_c)不太可能有意义，而且这种情况的可能性是可以忽略不计的。 - 命令不重要，MAC也不需要。注在这里得到签名的消息是
H(r_s||r_c)(此哈希值将由签名方案使用的哈希函数进行散列)，而不是r_s||r_c。
页面原文内容由Cryptography提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://crypto.stackexchange.com/questions/63738
复制相关文章
相似问题
腾讯云开发者
