NervesKey and Certificates Questions

Hi @meraj,

The NervesKey is really an ATECC608A. These chips are highly configurable so for Nerves, we decided on a setup that worked for our use cases of connecting to AWS IoT and NervesHub. There are two slots for keys and certificates: one slot is permanent and the other can be rewritten as much as you want (it’s called the aux slot for historical reasons). Everything is open-source, so you can modify it if you want, but my hope is that you don’t need to.

One thing to be aware of is that public key infrastructure is used more simply in practice with IoT services (I’m familiar with NervesHub and AWS IoT, but I’ve been told that others are similar).

So we’re using the same words: Devices have a public and private certificate. When using the ATECC608A, the private key in the private certificate is stored so that it never leaves the chip. The device’s public certificate is signed by another certificate generically called the signing certificate. This can be the CA certificate or an intermediate like in your case.

The crucial piece of information is that NervesHub, AWS IoT, and other services like that record device public certificates. That means that if a device is known to a service, ONLY the device’s public certificate needs to be valid to authenticate the device. That means that the signing certificate can be invalid and it won’t matter.

Of course, at some point in time you have to tell NervesHub or AWS IoT about your device. The server needs to know the signing certificate at this point. There are two ways of provisioning the server with new devices.

It can be done off the device. For example, if you make a lot of devices, you can write a script that records device certificates from the manufacturing line and upload them to the server. The certificates will need to be signed and the signing certificate needs to be valid for the server to accept the device certs.

The registration can also be done on the device. This is called JITP (just in time provisioning) on AWS and the idea is that the first time a device connects, the certificate chain will be validated and the device certificate registered. The downside to JITP is that if your device sits in a warehouse for a long time and the signing certificate’s expiration date passes, you’ll have to manually update the cert on the device for it to work.

The point is that there might be a way to avoid the 30 day re-signing of certificates.

Regarding your second question about SSH. If you have ssh running and the device is reachable, you’ll be able to get an IEx prompt. If your device is behind a firewall, then take a look at NervesHub. You have to enable IEx prompt access with NervesHub on your device, but if you do that, NervesHub will enable a button on the UI that will give you a shell window.

Hope this helps!

Hi @fhunleth

Thank you for the detailed answer. This was very helpful to understand the flow. After going through these details, I have these questions to hopefully fully understand it.

What I understand from your reply is that the CA / Intermediate Certificate validation (that it is not expired) is done at two occasions:

1. It is verified when we we are signing the device certificate and once it is signed with it and is valid, the device certificate generated will continue to work without issues even if in future our CA / Intermediate Certificate expires?
2. This information is validated when device is connecting for the first time to our server, once we are connected then even if the CA / Intermediate Certificate which signed it expires, it won’t impact it. Right?

So if the above is true, then we don’t need to worry about the devices as expiration of our CA certificate will not impact it, we will only need to make sure that when we are signing and upon connection to server, the CA certificate need to be valid so the device public certificate created is valid.

Sorry if I am repeating myself again and again as it is quite new for me and would like to understand. Thank you

What I described is specific to the servers that I’ve used, and both of those have code that saves device certificates. It’s kind of like usernames and passwords, except instead of a username, you have a device ID, and instead of a password, you store the device’s public certificate. The intermediate/CA certificate validation is more like having someone vouch for the authenticity of the device cert before saving it to a database.

All of this needs to be integrated with whatever code is terminating the TLS connection for it to work. When the device connects, there needs to be some callback that checks whether the device certificate that’s being presented is known. That’s the custom piece of code that you either need to add or reuse from someone else’s service. The Erlang SSL stack has a callback for this, but you might be using something else. Honestly, this is where it gets fuzzy for me since I mostly work on the device side. If you have more questions on how the server side is implemented, hopefully someone else can help out. If nothing else, I might try going on the Elixir lang slack and asking around on the #nerves_hub channel.

@fhunleth Thank you. I understood. We are also considering using AWS IoT or NervesHub so what you said will be true for us as well.

I will discuss with our team further and update as we are able to finalise our flow. I hope that will be hopeful to other members here as well.