我有一个关于物联网设备密钥轮换的基本问题。
我们计划使用安全元素 (example) 来生成密钥对。因此，密钥对是在芯片上、物联网设备上生成的。
在最初将公钥上传到 Google IoT 后，如何执行密钥轮换？
使用现有的私钥，设备可以签署 JWT 并向 Google IoT 验证自身。在设备中生成新的密钥对后，是否也可以使用 JWT 来验证将新的公钥上传到注册表？
请分享此类平台的任何密钥轮换示例。谢谢！
【问题讨论】：
标签： iot google-cloud-iot
来自Google Cloud IoT Core + ATECC608 documentation：
例如，私钥由安全元件生成 本身，而不是外部方 (CA)。芯片使用随机数 生成器来创建密钥，使其几乎不可能派生。 私钥永远不会离开芯片。使用私钥， 该芯片将能够生成一个可以由以下人员签名的公钥 公司选定的 CA。
Microchip 在专用的安全设施中执行此签名 美国，一个孤立的工厂将存储客户的中间体 插入生产线的高度安全服务器中的 CA 密钥。 密钥对和证书都是在这一行中生成的 允许审计和高水平的监管环境 加密。
一旦安全元件各自生成了它们的密钥对， 相应的公钥会发送到客户的 Google Cloud 帐户并安全地存储在 Cloud IoT Core 设备管理器中。
因此，对于给定的安全元件芯片，密钥对是固定的。虽然 GCP IoT Core 允许每个 IoT 设备最多使用 3 个公钥，但您必须物理更换安全元件芯片才能获得新的密钥对以轮换密钥。
安全元素的想法是私钥不能被泄露，因此不需要旋转（阅读：不能旋转）。虽然通常建议轮换密钥，但轮换密钥的能力固有地引入了一个漏洞——理论上，一个不良行为者可以在他们选择的新密钥中轮换以获得对系统的控制权，因为存在替换密钥的机制。如果不存在任何机制，那么这不是黑客攻击的载体。有一个review of this behavior，您可以阅读以获取更多信息。
根据我的经验，最常见的用例是您在现场拥有一台设备，然后更换包含安全元件的“主板”。您可以将作为替代品交付的新安全元件的公钥添加到 IoT Core 中，以便在更换“主板”时，新密钥对已经注册，并且设备可以自动从 IoT 中提取状态和配置信息核。只要设备与 IoT Core 同步配置和状态信息，新的“主板”就可以成为相同设备，但具有新的“大脑”和新的密钥对。
JWT 是基于密钥生成的，但根据设计，JWT 的生命周期很短（default 1 hour，最长为 24 小时）。因此将基于相同的密钥生成新的 JWT。
【讨论】：