经典的 PKI 场景……你想要一个 CA……
您所有的同行都需要提前知道公共 CA 证书...
一旦对等点向服务器注册,它应该加密自己的密钥,以便服务器可以确保接收到的密钥没有被篡改......
对于数据结构,您可能应该使用 X509
从程序员的角度来看:
对等体 A 想要注册一个新的密钥对...
-> 生成密钥对
-> 填写证书的标识详细信息,并附上公钥(您现在拥有的通常称为“证书请求”)
-> 对称加密请求(带有随机 IV 的 AES-CBC-256 看起来是一个不错的选择)
-> 加密对称密钥,并将其与加密请求和明文 IV 一起发送到服务器(可选地,包括服务器在加密部分提供随机数或附加会话数据)
在服务器端:
解密,检查数据,尤其是请求的标识信息,如果没问题,获取请求(ID 部分 + 公钥)并使用 CA 密钥签名
向对等点 A 报告并移交签名证书(因为它不包含任何秘密,可能是明文或使用为对等点 A 提供的密钥加密)
一旦你需要在同行之间建立联系,你只需要一些联系信息:
如果对等点 X 想联系对等点 A,您只需提供如何联系 A 的地址...我的证书。”)......在交换证书后,验证签名......如果 CA sig 没问题,双方都会生成随机数(“nonce”;使用过的数字)并使用来自收到并验证的证书并将它们移交给另一个对等方......在收到加密值时解密,并使用其他方密钥重新加密,然后发回......在使用您自己的私钥收到解密值后,并验证它是否与您发送的号码相同...已建立经过身份验证的连接,您现在可以继续移交对称密钥并开始传输加密数据
如果您认为无需对其他对等方进行身份验证就可以生存,则可以在检查其证书上的 CA 签名后直接开始传输加密数据……但请考虑在这种情况下,攻击者可以接收不适合他的数据(他可以'不解密,但他可以假装是另一个同行......)