Elliptic curve crypto on a micro controller

  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.

PHolder

Well-known member
Sep 16, 2020
737
2
356
Ontario, Canada
Let's say firmware updates need to be signed
If that's the case, then you already have the authentication you need to verify the authenticity of all devices in the network. The issue is that verifying signatures requires asymmetric crypto, which goes back to the original cost equation of the need for it. The problem still boils to initial trust. If you think of how TLS works, for example, you have to have a trusted list of CAs and they are "verified" by DNS. You just need to give a really good hard think to how you're going to provide initial trust, and handle reversion back to "known good" if the hardware is reset, resold or reused.
 

Janne Oksanen

Member
Mar 29, 2021
13
2
If that's the case, then you already have the authentication you need to verify the authenticity of all devices in the network.
I wouldn't go quite that far. But it can protect against malicious firmware updates.
The issue is that verifying signatures requires asymmetric crypto, which goes back to the original cost equation of the need for it.
The need for asymmetric crypto was never in question here. It's been assumed from the very beginning. :)
If you think of how TLS works, for example, you have to have a trusted list of CAs and they are "verified" by DNS.
I don't think that TLS and DNS need to be involved here. The public key can be in the firmware and then it's only a matter of checking the signature against that.
 

Darcon

Member
Oct 8, 2020
6
3
If that's the case, then you already have the authentication you need to verify the authenticity of all devices in the network.
You can't assume all IOT devices will be from the same manufacturer as not all manufacturers create IOT devices for all purposes.

In a non-homogeneous network, verification of all devices is more difficult as they don't have a common manufacturer or root.

If you could get a trusted root public key for devices that are from a different manufacturer, then validate the device has it's private key and their public key is signed by the root, then you know the device is authentic and has the private key.

Getting that trusted root is the problem. If you get the root from the device, you just know the hierarchy of the keys for the device, not if it can be trusted. If there is a method to get it from the manufacturer, then DNS and routing alterations could get a fake root. Getting from both device and manufacturer would reduce risk of getting a fake IOT device as they would have to hack both the network and the device. Then there is the issue of offline IOT, where they are on an isolated private network. In this case, homogeneity may be required for trust, but hope that you didn't get all fake devices.

Then it all comes down to why you need to trust the IOT device and is the information it is getting or giving important enough to encrypt and trust. Or do you just assume all IOT is untrustworthy and use the data as a general guidance, and verify through other methods?