假设服务器向合作伙伴提供用户的公钥,从而使加密通信成为可能。但是,服务器没有访问私钥的权限。
无论如何--假设服务器被黑客攻击,并且不发送所请求的公钥:
爱丽丝要求鲍勃的公钥 服务器发送Eve的公钥 鲍勃要求艾丽斯的公钥 服务器发送Eve的公钥 爱丽丝给鲍勃发了个口信 服务器解包消息,读取它和它的->发送给鲍勃. 鲍勃给爱丽丝发了个口信 服务器解包消息,读取它,并将它的->发送给爱丽丝.
我的问题是-如何防止这种虐待?爱丽丝怎么能确定她使用的是鲍勃的公钥,反之亦然?
发布于 2010-08-28 15:46:05
在您刚才提出的方案下,您不能。这里的密钥(没有双关意)是,如果用于验证密钥有效性的方法被破坏,您就会失败。
SSL试图通过创建一个签名链来避免这种情况--一些密钥(非常谨慎,并由其他方法验证)密钥签名另一个密钥,签名另一个密钥,签名Alice的密钥。通过验证链中的每个步骤,您(原则上)可以知道该链是有效的-但是如果链中任何一步的私钥被破坏,您就会失败。
PGP (又名GPG)试图以一种不同但类似的方式解决这个问题--键可以由任意数量的其他键签名,形成一个图(称为信任网)。您选择一些您已确认有效的密钥,例如,亲自验证它们,并将它们标记为可信的。然后,通过小于N个步骤(和/或从来自不同可信根的M个不同路径)可到达的任何键也被认为是有效的。
如果你真的疑神疑鬼,当然,你可以把钥匙交给另一个人。当然,他们必须确定不是一个伪装成你的人.
尽管如此,验证密钥有效性的唯一真正可靠的方法是自己生成密钥.除非您的硬件/OS/编译器/大脑也受到损害:)
发布于 2010-08-28 15:45:02
这里缺少的关键部分是身份验证。爱丽丝需要一种方法来知道她真的在使用Bobs公钥。一种方法是亲自交换钥匙,但这并不总是可能的。
这就是信任网的作用所在。如果其他各方确定此密钥属于用户,则可以对用户的公钥进行签名。如果您的其他联系人(您信任的)中有足够(3)人签署了Bob的公钥,您可以相对确定这是他的密钥。
发布于 2010-08-28 15:48:04
这是公钥加密的主要问题。您没有任何方法来验证您收到的公钥实际上是您预期接收者的公钥。HTTPS/SSL的解决方法是通过使用受信任的证书颁发机构。证书颁发机构用其私钥对当事人的公钥进行签名,保证公钥自提供给证书颁发机构以来没有发生任何变化。即使这样,也只能保证在您请求时提供给您的密钥与最初提供给证书颁发机构的密钥相同。但是,如果提供这些证书的服务器被破坏,您仍然会遇到麻烦。即使像上面建议的那样让服务器对密钥签名也不是愚蠢的证明,如果服务器本身被破坏了。最终,如果您的密钥分发服务器必须维护安全性,则此系统才能正常工作。
https://stackoverflow.com/questions/3591342
复制相似问题