I have a basic question about key rotation for IoT devices.
We are planning on using a secure element (example) to generate the key pairs. The key pairs are therefore generated on the chip, on the IoT device.
After the public key is initially uploaded to Google IoT, how can key rotation be performed?
Using an existing private key, the device can sign a JWT and authenticate itself to Google IoT. After generating a new key pair in the device, can the JWT also be used to authenticate uploading the new public key to the registry?
Please share any examples of key rotation for this type of platform. Thanks!
From Google Cloud IoT Core + ATECC608 documentation:
For example, the private key is generated by the secure element itself, not an external party (CA). The chip uses a random number generator to create the key, making it virtually impossible to derive. The private key never leaves the chip, ever. Using the private key, the chip will be able to generate a public key that can be signed by the chosen CA of the company.
Microchip performs this signature in a dedicated secure facility in the US, where an isolated plant will store the customer’s intermediate CA keys in a highly secure server plugged into the manufacturing line. The key pairs and certificates are all generated in this line in a regulatory environment which allows auditing and a high level of encryption.
Once the secure elements have each generated their key pairs, the corresponding public keys are sent to the customer’s Google Cloud account and stored securely in the Cloud IoT Core device manager.
So the key-pair is fixed for a given secure element chip. While GCP IoT Core allows for up to 3 public keys per IoT device, you would have to physically replace the secure element chip to get a new key pair to rotate keys.
The idea of the secure element is that the private key can't be compromised so doesn't need rotating (read: can't rotate). While rotating keys is commonly recommended, the ability to rotate keys inherently introduces a vulnerability-- a bad actor could theoretically rotate in a new key of their choosing to gain control of the system, since the mechanism exists to replace the key. If no mechanism exists, then that is not a vector for hacking. There is a review of this behavior which you can read for further info.
The most common use case for this, in my experience, is where you have a device in the field, and you replace the "main board" that includes the secure element. You could add the public key of the new secure element that was shipped as a replacement into IoT Core so that when the "main board" is replaced, the new key pair is already registered and the device can automatically pull state and config information from IoT core. As long as the device was syncing config and state information with IoT Core, the new "main board" can then become the same device, but with a new "brain" and new key pair.
The JWT is generated based on the keys, but by design, the JWT has a short life (default 1 hour with a maximum of 24 hours). So new JWTs will be generated based on the same keys.