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.
