【问题标题】:Can I build my own secure communication protocol with ECDH, public-keys, AES using .NET?我可以使用 .NET 使用 ECDH、公钥、AES 构建自己的安全通信协议吗?
【发布时间】:2011-08-13 04:09:17
【问题描述】:

我最近试图找出一种方法来保护单服务器多客户端系统中服务器和客户端之间的通信。在密码学领域没有做太多工作,我希望人们能提供有价值的意见或反馈,以防我错过了一些重要的事情。

如果重要,将使用 .NET Framework 4.0。 现在进入有趣的部分:

  1. 客户端建立到服务器的不安全连接(很可能是 RESTful 调用),请求服务器的公钥(以防它未知)和(伪随机)初始化向量。此时,如果之前未知,客户端也会提交他的公钥。

  2. 双方使用椭圆曲线 Diffie-Hellman(基于哈希或基于 hmac 的密钥派生函数,我还不是 100% 确定;想法?)生成密钥(使用 System.Security.Cryptography.ECDiffieHellmanCng

  3. 双方计算派生的初始化向量 - 例如通过使用客户端的加盐密码哈希作为密钥应用keyed hash

  4. 客户端使用对称加密(AES 或 Rijndael?)恢复通信,使用 (2) 期间生成的密钥和 (3) 中修改的初始化向量,希望确保会话安全。

    李>

现在我想知道:

  • 这种方法是否过于复杂?
  • 是否存在需要改进的弱点?如果有,您有解决方案吗?

【问题讨论】:

  • 对于#4,在 .NET 中,AES 和 Rijndael 是一回事。 AesManaged 和 RijdaelManaged 类是相同的。 AesManaged 只是 RijndaelManaged 的包装。
  • 我真的建议使用 SSL 而不是重新发明它。
  • @vcsjones:在每个框架中都是正确的 - Rijndael 是 AES(高级加密标准)。
  • @vcsjones 和@Noon Silk:不一定正确,.NET 也不一定正确。 AES 是限制为 128 位块大小和 128、192 和 256 位密钥大小的 Rijndael 算法。 Rijndael 本身和 .NET 的 Rijndael 实现支持其他块大小。

标签: .net cryptography


【解决方案1】:

你如何防范中间人?

基本上,您如何验证为您提供公钥的服务器是实际服务器。这就是 TLS 和授权链中的根证书的用途。您是否考虑过只使用 TLS 并为服务器购买 SSL 证书?这将解决 MitM 问题,也许还有一个更大的问题:您不需要编写自己的加密包装器,在这种情况下,您引入的任何细微错误(甚至是易受攻击的做法)都会成为一种责任。

如果您使用 WCF,那么开箱即用,它不会信任自签名证书。

请参阅Best Practices for Security in WCF 了解更多信息。

【讨论】:

  • 好点;一个我以前没有考虑过的,因为我认为它是理所当然的。至于 TLS,我正在考虑,但我不确定是否愿意为我的私人和不起眼的项目投资已颁发的证书。
  • @Manny:颁发证书的成本已降至零 - 例如StartSSL
【解决方案2】:

您所描述的内容与 TLS/SSL 的工作方式非常接近。为什么不直接使用呢?

【讨论】:

  • TSL/SSL 当然是我正在考虑的一种方式。我是个讨厌的精打细算的人,我正在考虑需要更少投资的替代方法。
  • @Manny 为什么 SSL 需要投资?您始终可以创建自己的 CA 并自己签署证书。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-03-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-04-27
  • 1970-01-01
相关资源
最近更新 更多