The drawbacks of today’s Iot device identity implementation and how we can make it better

In our last #Gossipiece, we talked about a device identity and how important it is going to impact the IoT world. In this #Gossipiece, we will be discussing how to use IoT Identity to manage your device fleet securely.

Device Identity is just the first step toward the secure IoT device management, it’s essential, but it’s more important how we protect and use the Device Identity.

To cut the BS. I will only talk about 3 points (You can do a lot to protect your IoT devices, but these 3 points are critical among the critical)

How to protect your Device Identity.

Before you use it, you need to secure it properly. But first and foremost, what do you need to protect??? In other words, what’s the most crucial element of a device Identity???

The answer is the credential, i.e., the keys! Or token, whatever you use. (other stuff like device ID, attributes, they are super important, but the keys are an essential element here, period).

Let’s look at how Microsoft Azure does in IoT Hub (in symmetric encryption):

You have two key pair of primary key – string, and secondary key – string.

After creating a device, those keys are automatically generated, then developers can copy and paste it into their IoT devices, together with other credentials. Super convenient, but can you apply it to business-critical solutions? You’d better not! It’s a horrible practice in handling the keys.

Instead, you should use the X509 certificate route. The certificate makes your life harderโ€ฆ but it’s safe, to some extent.

x509 cert is widely used by many cloud vendors, like AWS, Azure.

So, to what other extent it becomes not safe?

Some of you may be heard about the DigiNotar, a Dutch CA company whose service is compromised in Sep 2011, and it declared bankruptcy in the same month. As a trusted third party, CA company is helping companies manage their certificateโ€ฆ but what if it is hackedโ€ฆ a single point of failure will become a nightmare of your IoT devices.

You can also manage your own certificate instead of trusting a third party. Yes, that will work; it’s not that simple even you purchase a root certificate from CA (easier to verify with trust, 3rd party, huh?!). You still need to manage a lot of certificates of your devices.

A typical way how the certificate works… it’s way more complicated with all the signing, verifying stuff… I try my best to draw it as simple as possible.

So normally, you buy a Root cert from CA. Put it into your cloud, and you can verify it with your CA on the cloud. Kinda of “simple.” Then, in production, you need to generate an intermediate certificate and distribute them to the manufacturer so that they can use it to create a leaf certificate and inject it into the device during the manufacturing process. Then you cloud will be able to recognize your device and vice versa.

The above two solutions that manage the most important element in your device Identity – the KEYs is, actually not that secure, or easy to use.

The cloud design is to control everything on the cloud, so it put everything, including the certificate and keys on the cloud.
  1. Symmetric key distribution is not safe, because people can see the keys. If your connection tampers, or your developer just loses it, or forgets it somewhere…, or you probably don’t even know how you messed up with your keys… you are probably screwed…
  2. Certificate (which use asymmetric encryption and signing system) is relatively safe, but it’s not that easy to use… Regardless that CA brings you the single point of failure risk, which forces you to purchase Root cert from multiple CAs, which again, makes your solution even more complicated…. damn, a dead end ๐Ÿคฃ

There is one way to protect your keys in a much simpler way, but it also requires a very well built architecture to make sure the entire system works seamlessly. The logic is quite simple actually, you let the device generate its own keys (using the asymmetric system, in other words, the public-private key system). If the private key never leaves the device and is stored safely. The only way you can get it is to use brutal force physically. But again, this is the only way to protect the keys in a simple, non-third party way. It would be cool if someone can offer such service using this principle ๐Ÿ˜ .

Conclusion: Symmetric key is super easy to use, but it’s risky. Certificate (private-public key) is safer, but still faces the single point of failure risk. And… it’s damn complicated to implement… Lastly, enable the device itself. Let them generate their keys and keep it inside the device.
I would definitely go for the last solution if I can find such company on the market.

How you should use Device Identity

There is a lot you can do with a well-designed Device Identity. Part of it is a digital twin, which contains all the device attributions that can be used to, for example, labeling, filtering, grouping the devices. This is not I am going to discuss it here. Instead, I want to discuss how you should use the Device Identity.

Device Identity is not a static dataset. Some of them are static, or at least won’t change that often, such as keys (you may need key rotation) and device ID. A lot of device info will change over time, for instance, device ownership, location, the purpose of use, application identifier that associate to it, data identifier associate to it, etc.

You will have a dynamic device identity profile as long as you are using it.

So here are my questions:

  • What if someone changes the profile without telling you?
  • What if a device tampers, but it’s still in your system….
  • What if an old device changes ownership? How do you prove that this device’s age….

All these kinds of questions make me think… Hey, we can use the system log to track all the changes of the Device Identity. If someone changes anything, or there is a change of ownership, etc. You can always track back who did it, when, and what…

Wait a sec… what if …https://resources.infosecinstitute.com/category/certifications-training/ethical-hacking/covering-tracks/log-tampering-101/#gref

๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚

Modify logs is just as easy as a Word file….๐Ÿ˜ฑ

Please don’t take me wrongโ€ฆ Today’s cloud-based system use system log and they work, kinda ofโ€ฆ okayโ€ฆ who is using the log? hmmm, can we trust the log data? hmm๐Ÿค”

From my perspective, the only way you can protect the history of your device identity is to use a tamper-proof technology, i.e., some Merkle-tree structure. Or, something is known better as the blockchain. No super fancy staff here; we want to make sure all the changes can be logged somewhere that nobody can ever change the logs. A simple visualization could be:

All messages are chained up with hashes so that if anything changes in the messages itself, the hash will change.

Final conclusion

  • Device Identity is a complicated thing; it’s a combination of all the identifiers in an IoT solution that you need to do things right.
  • To protect the Device Identity, you need a tamper-proof way. The system log is not always trustable.
  • Cloud solution for IoT is… not enough, you need something better. for IoT.

I got an interesting question for you: 5G is coming, so exciting! But do you think 5G is powerful enough to solve the problem I mentioned above? ๐Ÿ˜๐Ÿ˜Ž๐Ÿ’ช