我使用 RSA 来加密服务器和客户端之间的通信。假设我们有 2 个非对称密钥,密钥 1 和密钥 2。

服务器从一开始就有key1(私有),客户端有key1(公共)

所以这是场景:

  1. 客户端生成key2
  2. 客户端连接到服务器
  3. 发送用 key1(public) 加密的 key2(public)
  4. 从现在开始,服务器将发送使用 key2(public) 加密的所有数据
  5. 客户端向服务器发送一些随机数据
  6. 服务器发回相同的散列数据
  7. 客户端验证数据是否正确

据我所知,这应该可以防止中间人攻击,或者我错过了什么?在第 7 点,客户端应该知道是否有人试图向服务器提供错误的加密密钥,因为除了服务器之外没有其他人可以解密 key2(public)。

如果有什么可以提高安全性的,请告诉我。

有帮助吗?

解决方案

为提高安全性,您可以做的最好的事情是使用现有设计而不是尝试重新发明轮子。我并不是说你所做的事情一定是错的,只是那些比你和我更聪明的人花了很多时间思考这个问题。改为使用TLS。

其他提示

只要key1(私有)没有被第三方以某种方式拦截,您的方案看起来就很安全。

我想我实际上是在纸上的某个地方看到过这个。在其中,爱丽丝给鲍勃一个未锁定的盒子(钥匙1公共),然后鲍勃把一堆他自己的盒子(钥匙2公共)放入其中,锁定它并将其发送回爱丽丝。爱丽丝然后打开盒子(钥匙1私人),现在她可以安全地密封鲍勃给她的盒子。

尽管有类似的盒子,但这基本上就是你正在做的事情,所以我说它是安全的。

我同意,只需使用TLS。

此外,第5步到第7步提供了什么价值?想要进行在步骤1-4之后工作的攻击的MITM(例如通过传递n个事务然后停止,从一开始就强制重试的某种类型的DoS)也可以在5-7之后也这样做。他们添加了什么?

- MarkusQ

不,这个协议不安全。

中间人可以拦截客户端发送的数据并将其想要的任何内容发送到服务器,因为您没有为服务器指定任何机制来验证客户端或验证消息的完整性接收。

当然,你可以修改你的协议以解决这些明显的问题,但也会有其他问题。如果你曾经修复过它们,你会有一些映射到TLS或SSH的东西,为什么不从那里开始呢?


@ Petoj—我关注的问题是服务器信任它收到的消息;您的提案不提供任何安全保障。但是,如果您担心机密性,您仍然会遇到问题,因为MITM可以不加改变地来回传递消息,直到他看到想要查找的内容,因为您在客户端消息上没有任何隐私。

您的提案似乎旨在确保来自客户的邮件的完整性。您已经将协议开发到客户端无法区分攻击和网络故障的程度。而不是试图帮助客户端确定服务器是否对篡改的消息采取了行动,而是允许服务器在对其进行操作之前验证消息的完整性。

我同意格雷格的观点 你正在重新发明轮子. 。您本质上描述的是某种基本形式 密钥交换. 。顺便说一句,为了确保它免受中间人攻击,您还必须确定服务器的身份,即确保客户端可以确定地知道它认为是公开的(key1)确实是服务器的而不是中间人的(例如使用 CA 或将服务器的公钥(key1)保存在客户端的安全存储中。)

此外,还有 额外的考虑因素 您必须从系统的角度了解,例如:

  • 非对称密钥加密速度较慢 比对称密钥加密,这是现有解决方案(例如)的原因之一 传输层安全协议 将仅使用非对称密钥加密来协商临时对称密钥,然后将其用于通道加密。
  • 如果第三方的流量分析成功破解了临时对称密钥,则说明您尚未泄露非对称密钥对。你是 鼓励重新协商临时密钥 由于这个原因相对经常。可以说,生成一个新的 key2 在你的场景中会减轻这个方面的影响。
许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top