There are a few ways you could do this. The best option will depend on how your factory manufacturing and test process is going to work. Unfortunately we don't have ready to roll out examples of any of this, at the moment you'll have to assemble some parts on your own. We are in the planning stages of producing end-to-end examples and tools for manufacturing flows, but no ETA for this.
It sounds like you are currently embedding device keypairs into the firmware (this is the simplest way, and it's the default configuration for the AWS example projects). You probably don't want to do this for production, instead you can move the certificate and key files to "blobs" in the
NVS storage partition or files on an embedded filesystem partition like SPIFFS or read-only FATFS. This way each device can have the same firmware binary but a different device key and certificate pair. The IDF AWS examples have some config items which can be configured to pick up the certificates from a filesystem.
So you have a bundle of key/certificate pairs signed by your Amazon trusted CA. How to get the certificates into the devices? There are a few options for this part:
- Include them in the initial factory flash. The best supported way to do this is to use the Manufacturing Utility to create individual per-device NVS partitions (ie each partition can have a different certificate.) Alternatively you could generate SPIFFS or read-only FATFS partitions with the correct contents. The downside to this approach is that at the factory each device needs to get a different flash payload - this rules out using some bulk SPI flash flashers, for example.
- Include them in the end-of-line test. Your product probably has some kind of end-of-line test done at the factory, where you make sure all the functionality is working correctly. Does this include a Wi-Fi test where the device connects to a local AP that you supply to the factory? If so, you can have a test firmware binary which runs any other device self-tests, connects to the AP, downloads the per-device payload from the AP, stores it in flash. Then resets into the "product" factory firmware (either OTA updated downloaded from the AP as well, or pre-flashed to another partition) and finally the factory firmware erases the test partition. The main downside is that you need a piece of software on each in-factory AP to manage this (many factories do not have good internet access, so you want any test AP to be self-contained in most cases).
- Provision in the initial setup process. If your device has an app or something else which is used to do initial setup (let the user enter their initial Wi-Fi app details,for example) then you could have the app quietly send the key and certificate to the device at this point. This is not a good security option, because you have to trust both the app and the device (which has no way to prove its identity to the app without a key/certificate pair), but you could (for example) authorise the user in the app and then have the server send the data to the app, as associated with that user. Don't recommend this way, but it is possible to do it.
Sorry there any "out of the box" solutions for this at the moment.