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
Sep 22, 2021
'μWaveRiders' 是ä¸ç³»åˆ—æ—¨å¨æŽ¢è®¨ Cadence AWR RF 产品的博客,按æˆæ›´æ–°ï¼Œå…¶å†…容涵盖 Cadence AWR Design Environment æ新的核心功能,专题视频ï¼...
Sep 22, 2021
3753 Cruithne is a Q-type, Aten asteroid in orbit around the Sun in 1:1 orbital resonance with the Earth, thereby making it a co-orbital object....
Sep 21, 2021
Learn how our high-performance FPGA prototyping tools enable RTL debug for chip validation teams, eliminating simulation/emulation during hardware debugging. The post High Debug Productivity Is the FPGA Prototyping Game Changer: Part 1 appeared first on From Silicon To Softw...
Aug 5, 2021
Megh Computing's Video Analytics Solution (VAS) portfolio implements a flexible and scalable video analytics pipeline consisting of the following elements: Video Ingestion Video Transformation Object Detection and Inference Video Analytics Visualization   Because Megh's ...

featured video

Silicon Lifecycle Management Paradigm Shift

Sponsored by Synopsys

An end-to-end platform solution, Silicon Lifecycle Management leverages existing, mature, world-class technologies within Synopsys. This exciting new concept will revolutionize the semiconductor industry and how we manage silicon design. For the first time, designers can look inside silicon chip devices from the moment the design is created to the point at which they end their life.

Click here to learn more about Silicon Lifecycle Management

featured paper

Designing device power-supply ICs in an application-specific automated test equipment system

Sponsored by Maxim Integrated (now part of Analog Devices)

This application note provides guidelines for selecting the device power-supply (DPS) IC in an automated test equipment (ATE) system. These considerations will help you select the right DPS IC for your specific ATE system. It also explains the best system level architecture to tackle the output current and thermal requirements of the ATE system.

Click to read more

featured chalk talk

Seamless Ethernet to the Edge with 10BASE-T1L Technology

Sponsored by Mouser Electronics and Analog Devices

In order to keep up with the breakneck speed of today’s innovation in Industry 4.0, we need an efficient way to connect a wide variety of edge nodes to the cloud without breaks in our communication networks, and with shorter latency, lower power, and longer reach. In this episode of Chalk Talk, Amelia Dalton chats with Fiona Treacy from Analog Devices about the benefits of seamless ethernet and how seamless ethernet’s twisted single pair design, long reach and power and data over one cable can solve your industrial connectivity woes.

Click here for more information about Analog Devices Inc. ADIN1100 10BASE-T1L Ethernet PHY