Last line of defense for IoT security

If I grab 10 technologists and ask what are the most important issues surrounding the Internet of Things today, one of the popular answers will be “security.” If I then ask them what IoT security means, I probably get 10 different answers. Encryption. Transport protocols. Authentication. Keying. Firewalls. Secure boot. Over-the-air updates. Rogue apps. Data archival. Penetration testing. All the above.

Most of these are answers from a system-level perspective, developed over years of enterprise IT and OT experience. There is a prevailing assumption that a server with various technologies, locked in a room with controlled physical access and configured with software for controlled virtual access, can be made “secure”.

So, driving the same concepts down to chip-level should be easy, right?

Because of the enterprise experience, trust has been a lot the focus in SoCs. Trust implies that a device is what it claims to be, has the software it is supposed to have, and is allowed to exist on the network.

ARM TrustZone creates a Trusted Execution Environment around ARM Cortex-A class cores and ARM Mali GPUs, and for the rest of the chip a bit travels around on AMBA indicating if other IP blocks can be trusted or not – “one bit security”, as CTO Drew Wingard of Sonics put it in a recent interview. (He should know. ARM is a licensee of the Sonics technology discussed shortly.)

More trust efforts are springing up for SoCs. Imagination has created OmniShield for a multi-domain separation-based architecture, and Intel has just launched Enhanced Privacy ID (EPID) for attestation of devices. Once again, the IoT is spawning dueling specifications, and betting on the wrong one may be bad. I’d question if they are even solving the real problem, or just lulling us into a false sense of security. These steps are a good start, but more is needed.

Trust is not, and never was, a substitute for security.

Security at the chip-level needs something akin to red/black processing, with secure subsystems handling clear-text transactions, and non-secure subsystems providing less critical functions. That suggests some hardware subsystems need duplication, which starts to get expensive in SoCs. MMUs provide some benefit for protecting memory regions, alleviating the need for separate physical memory paths. Shared memory is a far easier implementation approach. However, MMUs don’t help everything: performance dictates that DMA and I/O peripherals usually run in physical address space.

In the MCU neighborhood, where pins count for a few cents each and die size is critical to holding costs down, duplication is usually prohibitive except for very specialized devices. This is why ARM turned to an MPU, a very lightweight fence to protect just a couple memory regions, in some Cortex-M families. It’s also why SecurCore is a separate product line. DMA is becoming more important, even distributed, and “bit banging” of peripherals is slowly going away.

As I’ve appealed before, we need to step back and really think about the IoT problem in chip design. If you are designing a SoC specifically for a secure application, you might be able to afford heavyweight methods and overdesign. If you are designing merchant MCU-like parts for incremental customer use cases with a variety of packages and features, NRE is a bad thing, but falling down on security in the name of cost savings is worse. The goal is securing a part (maybe in multiple configurations) flexibly so customers can actually use it, without huge NRE costs.

What we need is mutually independent, mutually secure domains encompassing every IP block on a chip – not just the CPU core and maybe a GPU, and not just a high-end version with an MMU. It also needs to account for distributed DMA techniques. The solution also needs to be massively configurable, not locking customers in to fixed partitioning schemes.

Since 2002, Sonics has been shipping and refining technology that provides the last line of defense for sharing IP blocks in and across domains in a secure fashion.

SonicsGN, the flagship Sonics network-on-chip product, delivers a hardware-level protection mechanism that can be designed into the chip for security. The idea is known as NoC-Lock (where the dash is very important to preserve the meaning; we wouldn’t want to mistake this for “no clock”, which is another subject entirely).

It starts with multi-region firewalling that enforces access policies. Firewalls are re-programmable on a per-target basis, supporting many domains with variable region sizes. Layers are also supported – for instance, one can install a firewall in front of a chip-wide firewall controller, a handy feature for things like a “very secure debug mode”. The point of secure boot is to configure these domains, and after trust is established, chip reconfiguration is blocked.

The protection mechanism provides target access control. The basic question is should this IP block be able to send a transaction to that IP block – if not, disallow and report an error. Target agents in the network-on-chip control target access without adding latency. Access is configurable per initiator, per role (with an understanding of the domains and layers), and per access type (read, write, supervisor, user).

Sonics has also done something interesting for massive configurability: wherever there are software values, customers can go in and “hardwire” those using means like NVM, laser trimming, or gates. Alternatively, they can leave those things programmable for the OS to take care of at secure boot. A single die can thus be tailored for security – IP blocks can disappear, registers can be made invisible, and the like.

How can this type of protection provided by Sonics help IoT designs, specifically?

First, it is far easier to configure and secure radio IP using NoC-Lock and setting up protection appropriately. (Or, you could wait for TrustZone or OmniShield compatible radio IP, and maybe have to move up to a bigger processor core to use it.) Second, configuration of protection in SonicsGN is straightforward, and it does not add overhead or depend on CPU-specific schemes or software, saving power. Third might be my favorite – an over-the-air update could enable a hidden feature based on a premium subscriber model or a deployment tweak, and bring all the pieces of it into the right NoC protection domains.

Oh, and there’s the secure transaction thing as well – it is the main point here. Many IoT designs are using the traditional fixed embedded programming model. Some are starting to use things like OSGI to install apps. There are also lightweight, app-centric OS solutions like Google Brillo showing up. Do you want to leave it to the (maybe trusted, maybe not) operating system and (much less trusted) installed apps managing who gets to talk to what part of the chip under what conditions? The protection mechanism in NoC-Lock doesn’t fall under the spell of an open-source port or a rogue app.

When I talked with Wingard about this last point, we had a good chuckle. What happens to the transaction errors? They can be reported anywhere. Personally, I’d like to know what is going on my IoT network that shouldn’t be – but that edge device or gateway might be thousands of miles away, not just down the hall.

If I trust my IoT chip with its operating system, I should be able to do more than just let NoC-Lock protection block any badness and report the errors back to my own processor core. For instance, I could let the IoT provisioning system know that this edge device is seeing these bad transactions. This could be far more secure than software-level virus detection alone, which is completely impractical to run on edge devices, and probably looking for the wrong things at the gateway and infrastructure. Since Sonics doesn’t do error processing on these protected transactions, that means my security process is mine, safe from Sonics and other Sonics customers – not that we shouldn’t trust them, but just saying, this is the world we live in.

NoC-Lock is built into the base SonicGN product, and its use is optional. Sonics offers services such as microarchitectural descriptions for customers as an aid in design and auditing, which is bound to come up in security discussions. Visit the Sonics website for more on SonicsGN.

Maybe now NoCs will start showing up in those answers to the IoT security question.

Share this post via:

• 
• 
• 
•