AWS IoT – Use a temporary certificate created at build time to authenticate a device for self-enrolment
Let's say we produce IoT devices and want them to access AWS IoT Core.
The best solution is something like: every device has a (unique) private key and a public X.509 certificate signed by a valid Certification Authority. This way, the devices present their certificate to AWS, which validates them.
If devices cannot receive a private key and public certificate during manufacturing, AWS offers the "trusted user" procedure where:
- A "trusted" human user logs into AWS using a bespoke app (e.g. a mobile one)
- The user request a temporary private key and public certificate from AWS and forwards them to the IoT device via e.g. Bluetooth; those are temporary because they will expire in 5 minutes
- The device uses the temporary said artifacts to request from AWS a new private key and public certificate, and then proceeds to store them safely
In short, the "trusted" user confirms the identity of the device to be enrolled.
At the moment, we have public X.509 certificates (produced by a "reliable" CA like Digicert, Baltimore etc. and transmitted to the device during manufacturing, i.e. in a factory) and private keys on our devices, but can't access the key or use it in any way because of software limitations and internal policy. In other terms, we cannot use the private key in any way and the situation is the same as not having it at all on our device.
One proposal is: replace a trusted user model with a self-enrolment model, where instead of having a user confirm the device identity, the device sends a certificate based on a trusted intermediate certificate to AWS, so AWS sends a temporary key and certificate (like in the trusted user model).
IoT Core will accept only leaf certificates that derive from a root Certificate, stored in IoT Core only. Those leaf certificates are the ones on the devices.
Would this be a reliable mechanism to self-enroll to AWS, if the certificate is never exposed and disabled once used? AFAIK the certificate is not stored in a secure storage/TPM etc though.
One limitation that was discussed is: each certificate can be used just once. This way, the public X.509 certificate would be conceptually similar to a one-time code.
I've read this whitepaper but I'm unsure about the proposed "custom" procedure.
What do we risk this way?
I guess that “trust” can be breached if:
- The CA leaks (or publishes somewhere) the intermediate certificate provided to us or any leaf certificates
- The factory (or factories) leaks one or more device/leaf certificates
- Someone who buys a device uses the device leaf certificate
Is the biggest risk that one (or more) leaked certificates are used to authenticate and then try a DDoS attack against IoT Core (where mitigations might be more or less effective against this)?
Are we missing any other weak point?
In general, would this be a reliable mechanism to prove a device's identity and enroll it to AWS?
Would you encourage/discourage its adoption?
