这种情况是否安全？

Question

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

服务器从一开始就KEY1（私人）和客户有KEY1（公共）

因此，这里的情景：

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

至于我可以看到这应防止一个人在中间的攻击，还是我错过了什么？ 在第7点，客户端应该知道是否有人试图给服务器加密的错误密钥，因为除了服务器之外没有其他人可以解密密钥2（公共）。

如果有任何事情可以改善安全性，请告诉我。

Answer 1

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

Answer 2

只要key1（私人）没有被第三方拦截，您的方案看起来很安全。

我想我实际上在纸上看到了这个地方。其中，爱丽丝给了鲍勃一个开锁的盒子（关键1公开），然后鲍勃把一大堆他自己的盒子（关键2公开）放入其中，锁定它并将其发送回爱丽丝。然后Alice打开盒子（密钥1私人），现在她可以安全地密封Bob给她的盒子。

尽管箱子比喻，这基本上是你在做什么，所以我会说它的安全。

Answer 3

不，这个协议是不安全的。

中间人可以拦截客户端发送的数据并将所需的任何内容发送到服务器，因为您尚未指定任何服务器身份验证客户端或验证消息完整性的机制它收到。

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

---

@Petoj —我被集中在的问题是，服务器信任它接收到的消息;你的建议不提供任何安全。但是，如果您担心机密性问题，您仍然有问题，因为MITM可以将消息不加改变地传递，直到他看到想要查找的内容为止，因为您在客户机消息中没有任何隐私。

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

Answer 4

我同意，只是使用TLS。

另外，步骤5到7提供了什么值？一个MITM想要做一个在步骤1-4之后执行的攻击（例如，通过传递n个事务然后停止，从一开始就强制重试的某种类型的DoS）可以在5-7之后完成。他们添加了什么？

- MarkusQ

Answer 5

我将与格雷格同意你重新发明轮子。你基本上描述的是key exchange的一些基本形式。顺便说一下，为了确保它能抵御中间人攻击，您还必须确定服务器的身份，即确保客户可以确定地知道它认为是公共的（key1）真的是服务器的，而不是的（例如，使用CA或具有服务器的公钥（在客户端上的安全存储KEY1））的中等人在

此外，还有额外的考虑你必须知道从系统的角度来看，如：

• 非对称密钥加密比对称密钥加密慢，这是原因之一为什么现有解决方案（如TLS）将仅使用非对称密钥加密来协商临时对称密钥，然后将其用于通道加密。
• 如果第三方的流量分析成功破解临时对称密钥，那么您并未损害您的非对称密钥对。由于这个原因，鼓励您相对经常地重新谈判临时密钥，您是。可以说，在您的方案中生成新的key2可以缓解这方面的问题。