我对物联网设备的密钥轮换有一个基本问题。
我们计划使用安全元素（example）生成密钥对。因此，密钥对是在芯片上，在IoT设备上生成的。
最初将公钥上传到Google IoT后，如何执行密钥轮换？
使用现有的私钥，设备可以签名JWT并向Google IoT进行身份验证。在设备中生成新的密钥对之后，JWT还可用于验证将新的公共密钥上传到注册表吗？
请分享此类平台的任何密钥轮换示例。谢谢！
答案 0 :(得分：3)
来自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。