Basics of IoT Security — Device Identity and Cloud onboarding
The Internet-of-Things(IoT) is steadily progressing from a buzzword to an attractive, mature market. A few years ago, people scoffed at the idea of everyday objects being connected to the internet but today, you would be hard pressed to walk through a retail store without running into an aisle stocked with these ‘smart’ devices.
Unsurprisingly, hackers aren’t far behind. Just google “IoT security breaches” and you will get well over a million hits with a plethora of information on how someone could get access to your devices.
While part of the problem is simply growing pains of a new market segment, the real challenge exists in finding a cost-effective way to implement (traditionally) ‘enterprise-grade’ security in a ‘consumer-grade’ product
The nice thing is, the past couple of years have seen tremendous progress with hardware based security becoming a standard offering in even small Cortex-M class Microcontroller’s (MCU).
Hardware based security can mean a lot of things and this article will focus on the ‘Device Identity’ piece and how it is used to on-board to a Cloud provider.
Who am I?
One of the fundamental tenants of network security is being able to identify an entity as being authentic before communicating any meaningful information to it.
Philosophical debates aside, proving an individuals identity is usually a matter of someone showing a document issued by a trusted authority like the a local government. Traditionally, this can be split into two-steps
- Check that the document is valid by the physical attributes(e.g., paper quality, color) and validating against a known database from the issuing authority
- Use the information in the document e.g., picture(or even a fingerprint) in the document to cross-verify that the presenter is the true owner(and not just some guy who stole the original document)
Now, how can you extend the above to a IoT device?
Obviously in the world of IoT, we will need some other unique attributes we can trust, since pictures/fingerprints aren’t available.
Enter, Public Key Infrastructure(PKI)
Fortunately, the math wizards have solved this problem several decades earlier already and the concepts and implementations are all in-place already from the early days of the internet.
The fundamental concepts behind PKI originate from Asymmetric key cryptography. This is a vast and interesting field which is beyond the scope of this article but this article is a pretty great read.
There are several interesting attributes to Asymmetric keys but at this time , we are specifically interested in it’s ability to ‘sign’ a given blob of data and the ability to validate the ‘signature’ without needing to know any secrets
Asymmetric key encryption has a concept of a ‘key-pair’, one Public and the other Private. In essence, the Public key may be safely shared with anyone wanting to validate data, and the Private key is securely stored.
This attribute makes the asymmetric key scheme extremely useful to validate if a chunk of data originated(or is trusted) by a given entity. For example,
In the above simple use-case, Bob could also have just driven over to Alice and handed over his public key, thereby making it trustworthy. However, the easier way would have been if he could send some form of ‘passport-esque’ document, issued by some trusted authority which proves that his public key is trustworthy.
In the networking world, this typically takes the form of a X.509 certificate and this is nothing but, you guessed it, another signed blob.
Now all Bob would need to do is send Alice his Certificate, Alice can cross-verify if the contents of certificate by using the certifying authorities(CA) public key. If the certificate is valid, then she can implicitly trust the Bob’s public key.
Pretty much all modern internet websites work off of the same principles of trust and all of these steps happen automagically whenever your browser attempts to connect to a https website. Note that this is a pretty simplified view, there typically can be several layers of trust but the basic concept of hashing, signing and validation never really changes.
Well, that’s interesting but I don’t see how this ties back to IoT devices…
Let’s walk back to IoT land now. Pretend you’re the manufacturer of one of these ‘smart’ devices and you want to make a few thousand pieces of hardware. You setup your cloud service with one of the big providers and now you want to connect them up to your service.
Now, how do you ensure that only your devices are on-boarded? Something like ‘knowing the right server address’ and a magic number test isn’t fool-proof as the secrecy of the information is dependent on protecting it both within the device as well as en-route to the manufacturing facility.
Using PKI, you could have every device have a unique public/private key pair with an associated certificate. Once you trust a public key, you can challenge the ownership of the private key, which(if you did things right) would only be known to your smart device.
Logically, this is functionally equivalent to the steps we performed for validating a person’s identity i.e.,
The flow of validating device identity before on-boarding to the cloud is shown below,
Device identity formation in a manufacturing environment
How you choose to implement the PKI scheme depends on the hardware technology and the type of vendor you choose in your end product. From a purely functional point-of-view, all you need is a key-pair and an associated certificate for a IoT device to have an identity you can validate.
For this, you can either,
- Pre-generate a set of public/private key pairs and their associated certificates and put them on each device in your manufacturing flow.
- Hardware-based Security — Have the device generate a unique key pair, and export only the public key. You form the certificate in your manufacturing flow and put it back in the device(i.e., your manufacturing flow has some equipment which makes it a Root CA or more likely, an intermediate CA).
These aren’t the only two ways available, you could also choose to generate keys outside of the device, sign them and inject them into the part or even; pre-installing an intermediate trusted identity for you to claim later. In general though, most systems will boil down to the above basic variants
The first option seems to be the easiest, but it does mean you are transporting private keys in the ‘clear’ and you do expose yourself to the risk of having those keys being read/re-used by malicious players.
The latter generally is the more secure option, since only the device will know it’s own private key and is never exposed. However, since the device public key must be signed on a per-device basis, this also means that you need something like a Hardware Security Module(HSM) to issue said certificates on your manufacturing flow.
Historically, the functionality to generate a secret key-pair used to be in the exclusive purview of Secure Elements but is available with many Secure MCU vendors as well.
Closing thoughts
Hopefully, this article gave you an idea of how device identities can be formed using cryptographic techniques and how you can validate them to be authentic.
It is important to understand that just having an identity doesn’t mean that the device is ‘secure’. There are a plethora of other attacks like run-time attacks against key storage and side-channel attacks; this just provides a foundation with which you can start to build a secure system.
