0

考虑和客户端服务器场景,你有两个选择:

  1. 您可以在客户端中包含服务器的公钥并执行交换。
  2. 您可以使用 Diffie Hellman KeyExchange 算法进行握手,然后交换密钥。

哪种方式更安全?另外,如果公钥将来自商店,比如来自客户端 CA 商店?它会更安全而不是在客户端应用程序中绑定它吗?

部署将通过安装程序完成,每次运行都会验证版本。

4

6 回答 6

3

使用(仅)DH 密钥交换,客户端无法知道它确实是他正在与之交谈的服务器。

所以对话是安全的,不会被窃听者窃听,但有人可能会伪装成服务器并危及客户端。

于 2009-06-23T10:38:57.240 回答
2

不。

如果您需要在生产代码中解决此类问题,请让专家来解决。密码学中有很多微妙的陷阱,你很可能会遇到麻烦。

于 2009-06-23T18:39:53.387 回答
1

可以替换嵌入式密钥。一般来说,如果客户端的机器没有通过非软件方式保护,您就无法防止有足够积极性的攻击者对您的客户端进行黑客攻击。即便是一个TPM也不是灵丹妙药。问题变成了权衡之一:攻击者的工时与获得的效用(利润、名声等)。许可进行计算的程序的唯一真正安全的方法是在您物理控制的服务器上执行所有可许可的计算;https或者SSL可以通过选择适当的密钥长度、散列方案、密码和 c(我对此知之甚少)来确保足够安全。

这里的原则实际上相当简单:您需要设计一种情况,在这种情况下,保护他们的密码/许可证密钥/数据/其他任何东西都符合客户的最大利益。例如,如果您有一个计算服务器并向您的客户收取服务器时间费用,那么客户密钥就是所有者银行账户的代理。

于 2009-06-23T11:01:52.047 回答
1

对于公钥场景,客户端必须生成密钥,您无法确信该密钥是安全生成的(有人可以访问系统并将密钥生成器更改为始终使用相同的值,增加前一个值加一,无论如何,所述攻击者可以在你的通信中永远下降)。公钥加密不是为此目的而设计的。

Diffie-Hellman 会更好,但正如 Tobias 所说,如果你自己投掷,你可能会留下攻击。

于 2009-06-23T18:50:10.017 回答
1

好吧,私钥算法通常比它们的公钥算法提供更好的性能(据我所知是一个数量级或更多)。从这个意义上说,Diffie-Hellman 会比将 RSA 用于客户端-服务器架构更有效。

如果您的客户端远多于服务器,则可以实施公钥算法来减少它们之间的交换。

尽管如此,就像许多人所说的那样,您应该考虑就此事询问/聘请专家,因为存在许多不同类型的攻击(其中大多数只针对实现,而不是算法本身)。如果您仍想继续,我只能祝您好运,并指出您应该仔细阅读的这些资源。

Diffie-Hellman 密钥协商方法

于 2009-06-23T19:08:21.273 回答
0

正如上面提到的 Tobias,最好不要推出自己的协议。我建议使用 TLS 的实现,或者至少在 TLS 上建模您的协议。TLS 为基于 Diffie-Hellman 和基于证书的密钥交换提供了选项。

看看:http ://en.wikipedia.org/wiki/Secure_Sockets_Layer

于 2009-06-23T18:47:47.243 回答