服务器和客户端之间的双向加密/身份验证

Question

说实话，我不知道这是否合适，因为我对这个领域完全陌生，但我会尽力在下面解释。

该场景可以建模为一组功能相同的服务器和一组功能相同的客户端。假设每个客户端都知道所有服务器的端点（可能来自代理或某种名称服务），并随机选择一个与之交谈。

问题 1： 客户端和服务器首先需要相互验证自己的身份（即客户端必须向服务器表明它是一个有效的客户端，反之亦然）。

问题 2： 之后，客户端和服务器通过某种加密相互通信。

对于问题 1，我不知道最好的解决方案是什么。对于问题 2，我正在考虑让每个客户端创建一个私钥，并在身份验证后将相应的公钥提供给它与之对话的服务器，这样其他人就无法解密它的消息；并让所有服务器共享一个私钥，并将对应的公钥分发给所有客户端，使外界（包括客户端）无法解密客户端发送给服务器的内容。

不过，这些可能是非常幼稚的方法，所以我非常感谢任何关于这些问题的帮助和想法。谢谢。

Answer 1

大约半年前我在这里问过一个类似的问题，我被重定向到Information Security。

阅读我的回答并重新考虑您的问题后，如果您仍然有如此广泛的问题，我建议您在那里提问。据我所知，StackOverflow 更多的是关于编程（因此编程中的安全性）而不是安全概念。无论哪种方式，您在进行项目时都可能不得不迁移到那里。

首先，您需要认真考虑系统中需要保护的内容。与here (check Gilles' comment and others) 一样，首先要做的也是最重要的事情之一就是考虑您必须采取哪些安全措施。您刚刚提到了身份验证和加密，但还有很多重要的事情，例如数据完整性。检查wiki page for security measures。在了解更多关于这些的信息后，您可以选择您需要的（如果有的话）加密算法、散列函数和其他。

例如，忘记数据完整性就是忘记哈希，这是我在 SO 上遇到的最流行的安全措施。通过应用加密，您“仅仅”可以期望没有其他人能够阅读该消息。但是您无法确定它是否会因为拦截器或信号丢失而原封不动地到达目的地（如果有的话）。我认为你需要确定。

我所知道的典型架构假设私钥交换采用非对称加密，然后使用私钥进行通信。这是因为 公钥基础设施 (PKI) 假设其中一方的密钥是公开的，这使得通信更容易，但肯定更慢（例如，由于密钥长度：RSA [非对称] 以 512 位开头，但现在典型的密钥长度是 2048，我可以将其与最弱但仍然安全的 AES [对称]（密钥长度以 128 位开头）进行比较）。问题是，正如您所说，服务器和用户没有相互验证，因此服务器并不真正知道发送数据的人是否真的是他们声称的人。此外，数据可能在交通期间发生了变化。 为了防止这种情况，您需要一种所谓的“密钥交换算法”，例如 Diffie Hellman 方案之一（因此，DH 可能是两者的“原始”答案你的问题）。

考虑到以上所有因素，您可能希望使用一种（或多种）流行的协议和/或服务来定义您的架构。流行的是 SSH、SSL/TLS 和 IPSec。阅读它们，定义您需要的服务，检查它们是否存在于上述服务之一中，并且您愿意使用该服务。如果没有，您始终可以使用原始加密算法和摘要（哈希）设计自己的。