feature article
Subscribe Now

Trust and the IoT

Not Your Typical IT Security

Not too long ago, the IoT Security Summit happened – a day spent with all things security as they relate to the IoT. So today we’re going to go over a few interesting points that were made in the course of the event, while acknowledging that much more happened than what we’ll cover.

With all the hoopla over the IoT – and the attendant concerns about security, there’s certainly a lot of energy going into the topic of security by developers. How much of that rolls into actual product has yet to be proven, given that poor real-world IoT security examples are now providing fodder for conference speakers to make the point, “Here’s how you do it wrong.” And, of course, they get more column inches than do the folks that get it right.

So we’re not going to ride the gloat boat here. (OK, maybe just once.) Better to talk about how to do it right, according to speakers from Mocana, ARM, and TI.

The “o” Matters

Mocana made what, in retrospect, might seem like an obvious observation – yet it’s obvious only once you hear it. They pointed out the difference between “IT security” and “IoT security.”

IT security focuses on the network. It looks for odd activity and patterns of activity, often aided by artificial intelligence. As a result, breaches can take 180 days to be detected – and then another 80-90 days to remediate.
No way that’s going to work for the IoT. Any security issues must be detected immediately, so, rather than focusing on the network, the focus must be on the network nodes – devices. And Mocana’s emphasis is on trusted devices that are self-protecting. That includes IoT gadgetry as well as hubs or gateways connecting them. Any such devices can be points of entry; block those points and, hopefully, you block entry.

The critical elements to making this work are:

Know that the device is in a trustworthy state (this is a job for the manufacturer; the customer has to trust that this has been handled), and
Install only known-good updates from a trusted source (a joint job for the manufacturer and customer).

Obviously, the key theme running through this is trust. ARM amplified further on this theme, noting the challenges of the IoT ecosystem – which is much more fractured than an IT ecosystem. The number of gadgets and customers for any given vendor is going to be enormous. And we’ll presumably have an enormous number of vendors. So all of this is going to be arm’s-length: none of that, “Oh yeah, you can trust them – I had beers with the CEO just the other day.”

So that means that each participant in that system has to establish trust. You may be familiar with the concept of the root of trust (RoT); in this case, there is no single root. There may be multiple roots. Each component has to vouch for itself.
12-Step Security

ARM listed 12 different aspects of trust – some obvious, some less so.
Lifecycle management: from on-boarding to decommissioning.

  • Root of Trust management: handling all of those roots and making sure they’re legit.
  • Data protection: both off-line storage (at rest) and working (in use). Encryption is key here.
  • Cryptography: locking down data and messages so that they’re safe from prying eyes.
  • A good true random-number generator (TRNG): necessary for effective cryptography and authentication.
  • Software validation and encryption: making sure that your software hasn’t been corrupted.
  • Secure manufacturing: this is worth some more words below.
  • Software-update validation: making sure customers can’t get hoodwinked into loading bogus code.
  • Rollback protection: for when an update fails; you have to have a known good state to revert to.
  • Trusted storage: where data goes to stay alive while not in use; this is about the storage itself, not whether or not the data is encrypted.
  • Execution environment isolation: obviously ARM points to their TrustZone processors for this, although those tend to be bigger processors than might be found on an IoT gadget. Microkernels and other approaches can also work.
  • Debug authentication.
  • Debugging and Manufacturing

It was interesting that they mentioned debug security. This gets to something that TI said in a presentation on node security: all of the internals of a device – as well as the security itself – must be accessible during validation, test, and debug. But test and debug ports tend to be dangerous back doors. Even if the ports aren’t brought out in the actual product package, a hacker will happily break the package open if it means an easy way in.

So there has to be a way for a limited set of authorized people to get to those resources under tightly controlled circumstances without opening it up to everyone. TI spoke of locking the debug port down after testing was complete; ARM talks about authenticating access to debug.

Then there’s the manufacturing thing. And, based on these discussions and others even more so, I can’t help noticing that manufacturing houses seem to get a pretty bad rap. I’m not going to opine on my own behalf, having had no first-hand bad experiences, but, both here and at ICCAD (which we’ll talk about in another piece), there was talk about certain aspects of manufacturing being done only in a trusted site.

The reason this is key is because of… well… keys, at the very least. The security “provisioning” step happens during manufacturing. There are different ways of doing this, but, mostly typically, the device being manufactured will have a key loaded using a trusted platform module, or TPM. The key goes both into the device and, typically, into a database. When the device is on-boarded, its key is validated against the database.
So access to those keys and that database can be problematic, to say the least, if done by some factory of questionable repute. (Overbuilding and other typical sketchy manufacturing practices apply here as well, of course.)
What surprised me was the amount of discussion about doing part of your manufacturing in one place, while the delicate parts (from a security standpoint) are then done in a trusted site. My only guess here is that trustworthy sites charge a lot more, so you use the cheap and grungy house to save bucks and the house with integrity only for what’s necessary. Maybe there’s a different reason, but it certainly seems like it would add work and logistics to send your parts around to more than one house.

This is, of course, why you need roots of trust for your manufacturing houses as well – as many as the companies you use. Yeah, we got more RoTs than a root cellar!

The TI Version

TI had its own list of security layers that it used in their SimpleLink WiFi module. It included:

  • Separate execution environment (a la isolation from ARM);
  • Critical hardware accelerators; in their case, specifically for AES, SHA, RC4, PKA, and TRNG;
    Encrypted storage;
  • Boot loader and bundle protection (more on this shortly); and
  • Device identity.

Much overlap with what ARM has.

The software update validation piece merits some further elaboration. The “obvious” steps (“obvious” not meaning that they’re followed religiously) have always been to make sure an update is legit before installing. That might mean receiving a digest separately for confirming the integrity of the update. But TI noted one more aspect: testing that the update works before declaring the job done.

Why? Well, as an example (yes, this is the one gloat), a smart door-lock company sent out an update for one of their models. Problem is, they also sent it to users of a different model – and it made those devices decidedly not smart. So much so that the devices couldn’t even connect to the cloud, meaning that the company couldn’t solve the problem remotely.

So TI adds a step to their update routine: test the dang thing out, and, if it doesn’t work, roll back to the previous version (suggested also by ARM). This, of course, means more storage, since you need to be able to house both the current and new versions at the same time; you can’t just overwrite the old stuff. But, in return for that extra storage cost, you’ll likely be spared some support – and PR-gloating – nightmares.

More info:
IoT Security Summit

One thought on “Trust and the IoT”

Leave a Reply

featured blogs
May 18, 2022
Learn how award-winning ARC processor IP powers automotive functional safety tech, from automotive sensors to embedded vision systems, alongside AI algorithms. The post Award-Winning Processors Drive Greater Intelligence and Safety into Autonomous Automotive Systems appeared...
May 18, 2022
The Virtuoso Education Kit has just been released and now there is already a new kit available: The Organic Printed Electronics PDK Education Kit ! This kit also uses Virtuoso as the main Cadence... ...
May 12, 2022
By Shelly Stalnaker Every year, the editors of Elektronik in Germany compile a list of the most interesting and innovative… ...
Apr 29, 2022
What do you do if someone starts waving furiously at you, seemingly delighted to see you, but you fear they are being overenthusiastic?...

featured video

EdgeQ Creates Big Connections with a Small Chip

Sponsored by Cadence Design Systems

Find out how EdgeQ delivered the world’s first 5G base station on a chip using Cadence’s logic simulation, digital implementation, timing and power signoff, synthesis, and physical verification signoff tools.

Click here for more information

featured paper

Introducing new dynamic features for exterior automotive lights with DLP® technology

Sponsored by Texas Instruments

Exterior lighting, primarily used to illuminate ground areas near the vehicle door, can now be transformed into a projection system used for both vehicle communication and unique styling features. A small lighting module that utilizes automotive-grade digital micromirror devices, such as the DLP2021-Q1 or DLP3021-Q1, can display an endless number of patterns in any color imaginable as well as communicate warnings and alerts to drivers and other vehicles.

Click to read more

featured chalk talk

Single Pair Ethernet : Simplifying IIoT & Automation

Sponsored by Mouser Electronics and Analog Devices

Industry 4.0 with its variety of sensing solutions and fieldbus systems can make communication pretty tricky but single pair ethernet can change all of that. In this episode of Chalk, Amelia Dalton chats with representatives from three different companies: Analog Devices, HARTING and Würth Elektronik to discuss the benefits of single pair Ethernet, what the new IEEE standard means to SPE designs, and what you should consider when working on your next single pair Ethernet design.

Click here for more information about Single Pair Ethernet solutions from Analog Devices, HARTING and Würth Elektronik