我有一个有关物联网设备键旋转的基本问题。
我们正计划使用安全元素（示例）生成密钥对。因此，密钥对是在芯片上，物联网设备上生成的。
最初将公共密钥上传到Google IoT之后，如何执行密钥旋转？
使用现有的专用密钥，该设备可以签署JWT并对Google IoT进行身份验证。在设备中生成新密钥对后，JWT还可以用来身份验证将新的公共密钥上传到注册表吗？
请分享此类平台的任何键旋转示例。谢谢！
来自Google Cloud IoT Core ATECC608文档：
例如，私钥由安全元素生成 本身，不是外部政党（CA）。芯片使用随机数 生成器创建密钥，使其几乎不可能得出。 私钥永远不会离开芯片。使用私钥， 芯片将能够生成一个可以由 公司选择的CA。
Microchip在专用的安全设施中执行此签名 美国，一个孤立的工厂将存储客户的中级 高度安全的服务器中的CA键插入了制造线。 密钥对和证书都是在此行中生成的 监管环境允许审核和高水平 加密。
一旦安全元素生成了钥匙对， 相应的公共钥匙发送到客户的Google云 帐户并牢固地存储在云物联网核心设备管理器中。
因此，为给定的安全元件芯片固定了密钥对。虽然GCP IoT Core允许每个IoT设备最多3个公共键，但您必须物理替换安全元素芯片，以将新的密钥对置于旋转键。
安全元素的想法是，私钥不能妥协，因此不需要旋转（读：不能旋转）。尽管通常建议使用旋转密钥，但旋转键的能力本质地引入了漏洞 - 不良演员可以从理论上在他们选择获得对系统控制的新密钥中旋转，因为该机制存在以替换密钥。如果不存在机制，那不是黑客入侵的向量。有关于此行为的评论，您可以阅读以获取更多信息。
根据我的经验，最常见的用例是您在现场拥有设备，然后替换包含安全元素的"主板"。您可以添加已替换为IoT Core的新安全元素的公共密钥核。只要该设备正在将配置和状态信息与IoT Core同步，新的"主板"就可以变为相同设备，但使用新的"大脑"和新钥匙对。
JWT是根据键生成的，但是根据设计，JWT的寿命短（默认1小时，最多24小时）。因此，将根据相同的键生成新的JWT。