问服务器共享或不共享公钥？

EN

在大厅和游戏服务器中不使用相同的私钥的一个潜在的显著优点是，即使一个或多个游戏服务器密钥被破坏，大厅服务器密钥(其公共部分与客户端捆绑在一起，使其难以更改)仍然是安全的。

想必，游戏服务器的攻击面比专用的大堂服务器要大得多(而且变化更频繁)，因此设计您的系统使其能够从对游戏服务器的攻击中恢复是有意义的，同时使大堂服务器尽可能难以妥协。

您的第三种选择也具有这一优势，因为只有登录服务器需要知道绑定密钥的私有部分。事实上，根据“大厅”服务器正在执行的身份验证之外，将关键的身份验证功能分离到专用服务器上可能是个好主意。

另外，您的第三种选择保证客户端将无法绕过大厅/登录服务器，即使他们设法获得了游戏服务器公钥的副本(例如，从另一个已泄露的客户端)。(如果客户端以某种方式获得了另一个客户端的对称密钥，那么客户机仍然可以绕过登录服务器，但是由于这些密钥被绑定到客户机it，所以您的服务器应该能够检测到它。)根据您的用例，这可能是一种优势，也可能不是一种优势，但至少不应该伤害您。

顺便说一句，我觉得我真的应该修改这个旧的答案，注意到有一个比上面所描述的任何选项更安全(更实用)的选项：

• 不要在客户端捆绑任何游戏或大堂服务器公钥。相反，将“根”数字签名密钥的公共部分捆绑在一起，同时将私有部分保存在安全的地方(即不在任何可公开访问的服务器上)。
• 使用私有根密钥对游戏和游说服务器的公钥进行签名。
• 当客户端连接到服务器时，服务器首先(通过不安全的通道)显示一个包含其签名公钥的“证书”。客户端首先使用其捆绑的公钥验证签名，然后使用验证的公钥建立到服务器的安全通道。

您还需要一些撤销受损服务器密钥的机制。最简单的方法是在对公共服务器密钥进行签名之前将过期时间戳附加到公共服务器密钥，并让客户端拒绝使用过期密钥。当然，这意味着您必须在服务器密钥过期之前定期更改(或至少重新签名)，这是您想要自动化的。

您还可以在您的协议中包括一个选项，例如，auth/大堂服务器向客户端发送一个客户端不应该信任的已撤销服务器密钥列表，即使这些密钥在其他情况下看起来是有效的。这至少允许快速撤销游戏服务器密钥，而不必等待它们过期。这可能是有用的，例如，如果一些游戏服务器由第三方运行，他们无法很容易地接收到自动密钥更新，使得使用非常短的过期时间对他们的密钥是不方便的。

当然，另一种选择是让第三方游戏服务器运营商拥有自己的“分支”签名密钥，由根密钥本身签名，这样他们就可以生成并签署自己的服务器密钥。当然，客户端需要能够一直跟踪这样的签名密钥链，直到捆绑的根密钥。分支密钥需要携带一些(签名的)元数据，以指示哪些服务器是有效的，这样第三方就不能生成和签署自己的大厅/服务器密钥。

不过，好的一点是，您不必自己实现这些特性，因为它们都是公钥基础设施模型的一部分，用于TLS (和DTLS)，该协议是web浏览器用来安全连接到堆栈Exchange (和任何其他HTTPS网站)的协议。虽然TLS是一个非常复杂的协议(由于功能的历史积累)，您确实不想自己实现它，但是您可以使用大量的TLS库。现在，您的语言运行库很可能已经绑定了一个。(如果它可以从https:// URL中获取数据，那么它可以，或者使用与您的操作系统捆绑在一起的数据。)

当然，您仍然需要学习如何配置您的TLS库以满足您的需要(例如，只信任您自己的根证书，并禁用您不想要的任何遗留特性)，以及如何生成和签名TLS密钥，这本身就是一项重要的任务。但是，这肯定比从零开始就单独实现安全通信协议容易得多。