The Cloud IOT online documentation page "Device Security" describes a device provisioning process where a "Provisioner" creates a key pair, and distributes the private key to the Device. They go a step further and recommend using a revolving key strategy for added security. All steps in this device creation process can be automated using IOT core API's, with the exception of the key distribution step.
This alludes to there being a way to safely create the key pair, and transmit the private key to the device programatically for thousands of new devices rather than by hand for each device. Similarly there must be a way to generate and transmit new key pairs in the revolving key strategy.
Any suggestions on how to do this? Perhaps there is a standard method that I am not aware of. Thanks in advance for any feedback.
This alludes to there being a way to safely create the key pair, and transmit the private key to the device programatically for thousands of new devices rather than by hand for each device.
I believe the language here is deliberately less specific to allow room for cases when a device builder has a secure or unique way (e.g. encrypted radio) of transmitting keys to devices. In many cases, you will have a hardware-specific or OS-specific solution for updating device firmware and this mechanism is the best approach and allows you to revoke and recover compromised devices.
I think there are really two core buckets of approaches to distribution of the private key to a given device:
For distribution at manufacture or late manufacture, you generally are going to be installing the keys to the device using something that is physically connected to the device in a secure environment. At manufacture, I would imagine at the manufacture facility the (contract) manufacturer calls the API using delegated credentials to send Google the public key and then securely installs the private key on device. At late manufacture, the same registration process and secure installation of the private key occurs, it's just done outside of the manufacture facility by the person contracting to manufacture the device.
In both cases of device registration at manufacture, you can register multiple certificates per-device so that you can "change your password" effectively over time by rotating through the certificates associated to the device by expiring certificates or can revoke suspicious certificates, using additional on-device credentials. In some circumstances, this is good because if only one of the on-device credentials leaks, you can switch to an on-device, secured-at-manufacture alternate. There is a minor trade-off to this approach in that if multiple credentials for a given device can leak, you will have the banal risk of having multiple credentials leak at once. And this leads us to the second bucket of key distribution, post-manufacture.
For distribution of the private key after manufacture, it gets a bit more complicated because you're effectively creating another channel for devices to be managed in your registry. For this reason, it's difficult to advise on what to do should you not have an established secure channel for completely recovering a compromised device remotely.