我正在构建一个由 3 个部分组成的系统。系统A，系统B，系统C。
系统 A 不能直接与系统 C 对话，需要经过系统 B。系统 B 可能包含许多系统 C。这里还有一个问题是系统 B 有可能创建自己的副本/克隆并将其包含在自身之下（作为系统 C）。
我想从系统 A 向所有系统 C 广播消息。系统 B 包含它封装的所有系统 C 的列表。我想在系统 C 中添加逻辑，其中只有来自系统 A 的消息被认为是有效的（因此标记为安全的以供进一步处理）。
作为第一次切割，我正在考虑通过 diffie-hellman 算法协商一个私钥。但意识到系统 B 可以创建自己的副本，将其作为系统 C 的实例包含在内并获得私钥。是否有更好/标准的方法来做到这一点，以便可以在系统 C 端验证源的真实性？
在我看来，每个系统 A 的简单私钥/公钥就是您所需要的。
DH 根本不参与其中。
系统 A 创建密钥对。系统 A 使用其密钥对消息的散列进行签名，并根据需要通过尽可能多的系统 B 将其发送出去。系统 B 无法更改消息或派生私钥，因此他们所能做的就是不传递消息或重播它们（如果出现问题，您需要采取预防措施）。系统 C 需要在消息上验证 A 的签名，它要么以某种方式知道系统 A 的公钥，然后验证签名。
要拥有多个系统 A，让（所有）系统 C 知道所有系统 A 公钥很快变得不切实际，以解决您对为系统 A 和系统 C 签署证书的证书颁发机构 (CA) 创建信任的问题信任该 CA 签署的证书。（它不需要在线，也不需要能够与 CA 交谈来做到这一点，信任可以很容易地离线）。
如果您确实要进行离线操作，请注意密钥（和/或证书）可能需要更新，因此请预见一种机制。
如您所见，B 只是其中的一种交通工具。
如果事先没有共享任何内容，则 aC无法区分来自A的消息和来自B想要冒充 a 的消息A。在您的情况下，共享密钥将不起作用，因为这将允许B伪造消息。所以你需要一个像公钥这样的东西A，B可以C用来验证消息，但只能A用来创建/签名消息。