- Newest
- Most votes
- Most comments
If I understand it, your current firmware has both code and credentials built in? If that's the case and the firmware (code) is common for the three things, look to use multiple partitions and store your credentials and configuration in one partition (such as nvs), and the firmware in another. Then when an OTA update is applied, you can download just the new code, restart the device, and have the code use the unchanged credentials in the other, untouched, partition.
It's a good idea to figure out a partition scheme ahead of time. For instance, two firmware partitions (A/B) allow for rollback to known working firmware in the case an OTA job fails.
Also, if possible, consider using a secure element to store the private key associated with the thing's X.509 certificate. This can reduce someone extracting the key from the device.
That leads into the best practice of unique credentials per devices. While AWS IoT does support a single certificate/key used across multiple connections (things), it's an anti-pattern. If the key is compromised on one thing, the entire fleet has been compromised. With unique credentials per thing, the blast radius is just that thing.
Hope this helps, please follow up if needed.
storing the credentials can solve part of my problems. That's an option I can use.
On the other hand, when I do JITP I need to create a "Thing name", this Thing name must match the "Thing name" variable I'm using in my firmware to connect my device to AWS.
So, if I have 3 devices, I will have 3 Thing names, all 3 being different in the firmware.
I can see that starts to become a little messy.
Reading about provision by claim it seems this option uses the same certificate for all the Things, is that possible to implement in ESP32 without using AWS IoT SDK for embedded C?
Relevant content
- Accepted Answerasked a month ago
- asked 9 months ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 3 years ago
Similar to how the certificates should be separate from the firmware image, so should the thing name. Customers often use metadata, like a serial number, as the thing named. In regards to the certificate, as Gavin explained, you should not use the same certificate on every device. The claim certificate is only intended as a temporary birthing certificate; your devices would implement the fleet provisioning workflow to each obtain a unique certificate.