AVNET's iotconnect.io cloud platform is an online service that you can use to send data to, and then show it on a dashboard. In this blog series I'm learning how to talk to it with Node-RED. In this post: How to use Signed Certificates in an IoT supply chain. Without giving away your private keys to your subcontractor.
It is not easy to find info with all the steps to do this: you want to outsource programming the firmware to a subcontractor, and the devices they build are loaded with a client certificate that can be validated by your public certificate.
Without sharing passwords or private keys - any direction. You can keep your private key and certificate password secret, as you should. The subcontractor does not have to provide their secrets to you. Still you end up with a chain of trust where they can generate certificates for the things they are building/programming for you.
Attribution:
|
In this post I use three levels, where the top level is the intellectual owner of all things. The lowest level is a device. All intermediates are partners in-house or outsourced partners we may deal with.
- a conglomerate called United States Manufacturing: they are designers of a Thing that should be installed in every city in the United States.
- a number of subcontractor / suppliers. One per state. One is called Louisiana Branch: they manufacture and program the things on behalf of the conglomerate.
- a set of IIOT things (fondly named after the cities they will be installed in). Made and programmed by the subcontractor. Each thing needs its certificate to uniquely define it and enable it to connect.
I use 3 layers. But between the Root and the Things, there can be an arbitrary number of players.
All principles used in this article hold. No one needs to share secrets. All should have a trusting relationship with the one above.
In a typical supply chain, the trust relationship is usually set by negotiations, deals and commercial contracts.
Why Intermediate Certification Authorities (CA)?
This story borrows from Microsoft Azure's documentation.
Fair use. The explanation of MS is conceptional and describes an existing industrial practice. I show step by step how to use it on IoTConnect.io - Avnet's cloud service is hosted on Azure.
The simplest way of working with certificates is: be a Root Certification Authority (RA), and generate + sign certificates for everything you control.
Becoming a Root CA is easy. You just need software for that.
But signing each device that's going to be authenticated against your Root certificate does not scale. And has security issues.
Scaling
A certificate in the IIoT context, represents a unique Thing.
When you are a brand that sells a lot of things, it is not easy to generate a certificate for each of them, and then take care that that certificate and its private key are safely managed up until the program cycle after production.
Typically, a serial number is used to uniquely identify a device. You'd have to generate certificates and keys up front for all the devices your subcontractor will build the next few days.
They would then have to take care that the exact same certificate is picked at the end of production, when firmware + unique certificates are loaded.
It does not scale. And gets worse exponentially when you have several suppliers.
You could ask the subcontractor to generate a certificate on your behalf, at the time they are programming a thing.
But you'd have to share your private key and the related password.
Don't do that.
Security
You should keep your private key and the signing password secret. It's a base principle of working with certificates.
Should you share it with your subcontractors, and their staff at the production line that do the programming? No.
Intermediate Certificates Help
Queue intermediate CA certificates.
They allow that you grant the subcontractor the power to generate and sign Thing certificates on your behalf.
If you allow them, the subcontractors can even generate a dedicated intermediate certificate for each resource (or production batch) that generates and signs certificates at the production line.
All without sharing private keys and passwords.
With full traceability from Root to Thing.
And you, as the conglomerate that owns the chain, can still use your public key only to "validate the validity".
With the power to blacklist devices, particular subcontractors, particular production batches...
Actors and Responsibilities
Actors
In a scenario where generating certificates is outsourced to the supply chain, you have a set of actors that can sign certificates.
All of them have a trust relationship with the predecessor (the fact that the predecessor gives them a certificate with signing power is the Act of Trust).
All of them, except the lowest level, deserve our trust to generate and sign certificates.
The lowest (leaf) actor is the Thing, the device. It gets a certificate when its programmed. It does not have the power to generate certificates.
Responsibilities
The Root CA (you, as the United States Manufacturing Conglomerate) has two roles:
- own the Root Certificate private key and password
- generate intermediate certificates for the entities (subcontractors) you deal with and have signed a trust relationship).
Any intermediate (your subcontractor, their production line staff or sub-subcontractors, ...)
- own the private key and password of the intermediate certificate that's granted to them by the upstream actor
- create and sign downstream intermediate or leaf (Thing) certificates
Certificate use
The Root certificate is used:
- as the ultimate validation and blacklist utility. In our case to Avnet IoTConnect.io cloud.
This one (or any in the downstream that's considered to be the root - long story) is typically uploaded to servers for validation purposes. - as genesis for the first level of intermediate certificates.
Intermediate certificates are used :
- as for the lowest intermediate certificate in the hierarchy, as the certificate to generate and sign Thing/Device certificates.
- to generate downstream intermediate certificates for staff, machines, production batches.
Next posts
- Generate Root CA certificate for the conglomerate "United States Manufacturing".
Load it to IoTConnect Cloud as the certificate that be used to accept any of your Things connections.
Validate it.
- Generate an Intermediate certificate for the subcontractor "Louisiana Branch".
- Create a number of IIoT Things, one to be installed in New Orleans, Lafayette, Baton Rouge, Metairie.
Each with their own certificate, each registered on the Cloud - Use each thing in the real world.