我有一个关于物联网设备关键轮换的基本问题。
我们计划使用安全元素(示例)来生成密钥对。因此,密钥对在芯片上生成,在……上
从 Google Cloud IoT Core + ATECC608文档 :
例如,私钥由安全元件生成 本身,而不是外部方(CA)。芯片使用随机数 生成器创建密钥,使其几乎不可能派生。 私钥永远不会离开芯片。使用私钥, 芯片将能够生成可以签名的公钥 公司选择的CA. Microchip在专用安全设施中执行此签名 美国,一个孤立的工厂将存储客户的中间产品 插入生产线的高度安全的服务器中的CA密钥。 密钥对和证书都是在这一行中生成的 允许审计和高水平的监管环境 加密。 一旦安全元素每个都生成了它们的密钥对,那么 相应的公钥将发送到客户的Google Cloud 帐户并安全地存储在Cloud IoT Core设备管理器中。
例如,私钥由安全元件生成 本身,而不是外部方(CA)。芯片使用随机数 生成器创建密钥,使其几乎不可能派生。 私钥永远不会离开芯片。使用私钥, 芯片将能够生成可以签名的公钥 公司选择的CA.
Microchip在专用安全设施中执行此签名 美国,一个孤立的工厂将存储客户的中间产品 插入生产线的高度安全的服务器中的CA密钥。 密钥对和证书都是在这一行中生成的 允许审计和高水平的监管环境 加密。
一旦安全元素每个都生成了它们的密钥对,那么 相应的公钥将发送到客户的Google Cloud 帐户并安全地存储在Cloud IoT Core设备管理器中。
因此,对于给定的安全元件芯片,密钥对是固定的。虽然GCP IoT Core每个IoT设备最多允许3个公钥,但您必须在物理上更换安全元件芯片才能获得新的密钥对。 旋转键 。
私有元素的概念是私钥 不能 受到损害所以不需要旋转(读:不能旋转)。虽然通常建议使用旋转键,但是旋转键的能力固有地引入了一个漏洞 - 一个坏的演员理论上可以在他们选择的新键中旋转以获得对系统的控制,因为存在替换键的机制。如果不存在任何机制,那么这不是黑客攻击的载体。有一个 审查这种行为 您可以阅读更多信息。
根据我的经验,最常见的用例是您在现场拥有设备,并替换包含安全元素的“主板”。您可以添加作为替代品发送到IoT Core的新安全元素的公钥,以便在更换“主板”时,新密钥对已经注册,设备可以自动从IoT提取状态和配置信息核心。只要设备将配置和状态信息与IoT Core同步,就可以使用新的“主板” 成为 该 相同 设备,但有一个新的“大脑”和新的密钥对。
JWT是基于键生成的,但是按照设计,JWT的寿命很短( 默认1小时 最多24小时)。因此,将基于相同的键生成新的JWT。