Cloud IOT 在线文档页面“设备安全”描述了设备配置过程，其中“配置者”创建密钥对，并将私钥分发给设备。他们更进一步，建议使用循环密钥策略来增加安全性。此设备创建过程中的所有步骤都可以使用 IOT 核心 API 自动化，但密钥分发步骤除外。
这暗示有一种方法可以安全地创建密钥对，并以编程方式将私钥传输到设备以供数千个新设备使用，而不是为每个设备手动传输。同样，在循环密钥策略中必须有一种方法来生成和传输新的密钥对。
关于如何做到这一点的任何建议？也许有一种我不知道的标准方法。提前感谢您的任何反馈。
这暗示有一种方法可以安全地创建密钥对，并以编程方式将私钥传输到设备以供数千个新设备使用，而不是为每个设备手动传输。
我相信这里的语言故意不那么具体，以便在设备制造商有安全或独特的方式（例如加密无线电）向设备传输密钥的情况下留出空间。在许多情况下，您将拥有特定于硬件或特定于操作系统的解决方案来更新设备固件，这种机制是最佳方法，允许您撤销和恢复受损设备。
我认为实际上有两种核心方法可以将私钥分配给给定设备：
对于制造时或后期制造时的分发，您通常会使用在安全环境中物理连接到设备的东西来安装设备的密钥。在制造时，我会想象在制造设施中，（合同）制造商使用委托凭证调用 API 向 Google 发送公钥，然后将私钥安全地安装在设备上。在后期制造时，会发生相同的注册过程和私钥的安全安装，这只是由签约制造设备的人在制造设施之外完成的。
在制造设备注册的两种情况下，您都可以为每个设备注册多个证书，这样您就可以通过在与设备相关联的证书中轮换通过过期证书来有效地“更改密码”，或者可以撤销可疑证书，使用额外的-设备凭据。在某些情况下，这很好，因为如果只有一个设备上的凭据泄漏，您可以切换到设备上的、制造时安全的替代方案。这种方法有一个小的权衡，因为如果给定设备的多个凭据可能会泄漏，您将面临一次泄漏多个凭据的平庸风险。这将我们引向第二个密钥分发桶，即制造后。
对于制造后的私钥分发，它会变得有点复杂，因为您实际上是在为要在注册表中管理的设备创建另一个通道。出于这个原因，如果您没有已建立的安全通道来远程完全恢复受感染的设备，则很难建议该怎么做。