Protect devices from becoming bricks

Question

We need to be 100% sure that our devices in the field can continue to connect to AWS IoT core for the foreseeable future (30 years minimum). These devices will be deployed in consumer's homes. They must be maintenance free even though it is possible to automate maintenance (if any - such as certificate rotation) if we know those maintenance tasks ahead of time before the devices are manufactured and sold. We of course will plan software/firmware upgrades on the devices. We plan to use the Just In Time Provisioning methodology (https://aws.amazon.com/blogs/iot/setting-up-just-in-time-provisioning-with-aws-iot-core/) to register our devices.   
  
The following certificates and keys are used during the JITP process.  
  
1. Root CA created by us once (used to create Custom CA certificate and Device Certificate)  
2. Our Custom CA certificate generated and registered with AWS IoT once  
3. Device Certificates created during Just in Time provisioning while manufacturing (using our Root CA in step 1)  
4. Device Private Key generated during manufacturing   
5. AWS Root CA downloaded from AWS and installed on the device during manufacturing  
6. Per device certificate issued and attached to the device on AWS IoT  
  
One concern we have is that our devices becoming bricks in customer premises when any of these certificates expire and the devices are unable to connect to AWS IoT. We may not be able to remotely manually bring them online one by one as there may be tens of thousands of these devices in the field. We need these devices to be working flawlessly for a minimum of 30 years without manual intervention.  
  
AWS IoT developer guide has warning such as these sprinkled all over the guide - _"Device and root CA certificates are subject to expiration or revocation. If your certificates expire or are revoked, you must copy a new CA certificate or private key and device certificate onto your device."_ This is too generic. There are no step by step instructions on what to do.    
  
What can we do now (before the devices are manufactured and sold to end users) to make sure we are not surprised. i have Googled and unable to find an authoritative guide on this issue. This must be a common concern for many. The problem here is that we can't afford even a 1% chance of being surprised by something we haven't considered. So making educated guesses of this based on limited understanding is not an option. If we are not 100% sure, we will be better off not using the solution.  
  
How do others approach this problem. Any pointers and advice is very helpful. Thanks in advance for your help  
  
Edited by: pkongara on Jan 23, 2020 8:29 AM  
  
Edited by: DripDeveloper on Jan 23, 2020 8:42 AM

Accepted Answer

Your assessment is correct. Just rotate the AWS Root CA before the expiry date.    
  
Alternatively, if you want to use your own server certificate with longer validity, feel free to checkout the newly announced "Custom Domains for Configurable Endpoints" feature: https://aws.amazon.com/blogs/aws/welcome-to-aws-iot-day/  
  
https://docs.aws.amazon.com/iot/latest/developerguide/iot-custom-endpoints-configurable-custom.html

Alok

Answer

Can any one (perhaps an Amazonian) give me some pointers on this please? Perhaps the answer is that this is not a good question. That feedback is also useful.

Answer

Thanks for the information, Alok.   
  
The "Custom domain" feature may solve even the server certificate expiry issue. This feature is still in Beta and available only in US-East for now.   
  
But if the only additional task in the current workflow is to copy the new AWS Root CA when it is time, that also works.

Answer

While I am waiting for a response here, I continue to investigate.   
  
To clarify a bit more, here is our architecture -   
  
Our device is a MQTT client communicating with AWS IoT broker over TLS. We choose to use MQTT over web sockets (port 443) because our devices are deployed in customer's homes. We don't have control over client's network. Provisioning work flow is important. So we will use the JITP work flow given by AWS IoT.   
(https://aws.amazon.com/blogs/iot/setting-up-just-in-time-provisioning-with-aws-iot-core/)  
  
As for my question regarding various certificates involved in the workflow and their expiry - a lot of them are in our own control.   
  
_1. Root CA created by us once (used to create Custom CA certificate and Device Certificate)_  
  
We can make this valid for 30 years at the time of creation.   
  
_2. Our Custom CA certificate generated and registered with AWS IoT once_  
  
This registered certificate seem to have the same expiry as 1 above. So they can last 30 years.  
  
_3. Device Certificates created during Just in Time provisioning while manufacturing (using our Root CA in step 1)_  
  
We can set the expiry date to be 30 years later at the time of manufacturing.   
  
_4. Device Private Key generated during manufacturing_  
  
N/A (no expiry)  
  
_5. AWS Root CA downloaded from AWS and installed on the device during manufacturing_  
  
Well, this will be expired in 2038 (in 18 years) per AWS IoT.  
  
_6. Per device certificate issued and attached to the device on AWS IoT_  
  
Well, this expires in 2048 as per AWS IoT dashboard.   
  
So it all boils down to  5. AWS Root CA that needs to be put on the device. It can expire in 18 years which is less than our goal of 30 year minimum.   
  
Can we counter this if we simply install newer Root CA during our automated firmware upgrades? Is this even necessary? If needed, will everything else work as expected if we just upgrade Root CA when it is about to expire.   
  
Hoping to get some confirmation on this. Thanks in advance.

Protect devices from becoming bricks

Relevant content