Q&A with ARM: Securing the IoT using ARM Cortex Processors, and a growing mbed platform suite
I’ve been intrigued by ARM®’s mbed™ OS since it was announced at TechCon 2014. Since then, ARM has rolled out multiple announcements pertaining to safety and security—many pertaining to the IoT. Yet connecting the dots has been difficult: until now. In an interview with ARM’s Zach Shelby, vice president, Marketing, and Diya Soubra, senior product marketing manager, Cortex®-M processors, it’s clearer to me now. To help the reader follow along, I’ve added some slides from Peter Aldworth’s briefing, “Securing the IoT.” This ARM-specific preso follows from the more generic (and much longer) “How to secure the Internet of Things?” by ARM’s Hannes Tschofenig (you can find it via Google).
In this edited and excerpted discussion, we address the following topics— all based upon ARM’s key IoT security premise, “You can’t trust big data unless you can trust little data.”:
- ARM mbed OS
- ARM mbed uVisor
- ARM mbed TLS
- the ARM Cortex processor and how it enables security
- security lifecycle management
Chris “C2” Ciufo: Securing the Internet of Things (IoT): what’s new from ARM’s standpoint?
Diya Soubra: The release of mbed OS is coming soon [see Figure]. We have a beta release coming at the end of August, but we won’t be making a huge noise about it. Then at TechCon [in November 2015] we’ll have a stable release of this open source software, and we’ll be encouraging people to use it and make IoT products.
C2: Tell us, what is mbed OS? I’ve watched it evolve, but I admit I’m not completely clear on what it is.
Zach Shelby: mbed OS is redefining what an operating system is for embedded devices like microcontrollers. It used to be that designers picked a kernel, added IP networking and other code, and it was kind of a nosh [collection of disparate pieces]. What mbed OS does is, it builds in all the communication capabilities and security capabilities on top of an OS kernel, including device security, communication security and lifecycle security. ARM is making sure that all devices [for IoT] run mbed OS and have a level of communications interoperability and security support.
C2: What did you mean by “lifecycle”?
Shelby: So when we talk about lifecycle security, we’re talking about the different forms of device management you do throughout the lifecycle of a device. In the early stage we do secure key injections. We make sure there’s a root of trust on the device. Then we bootstrap the device onto a service in a secure way with different keying credentials. We do security management and look to see how the device is behaving. Later, you might go back and do, for example, a firmware update. Then you might even go back to the beginning again and re-bootstrap the device on a new service. All of this is to really make a system or device that has a longer lifecycle than just a throwaway.
ARM considers “IoT Security” to include Lifecycle, Communication and Device security. I want to discuss each of these briefly [see Figure].
C2: Let’s get back to mbed OS for a sec. Does it look like or will it look like a traditional OS or an RTOS, or is it meant to run on top of someone’s favorite embedded operating system?
Shelby: mbed OS is a standalone operating system. It doesn’t sit on top of anything else. It sits on top of bare metal.
And it includes an energy scheduler, an event scheduler and— later in our roadmap—a task scheduler. And by default, we’re very focused on energy and making sure that the energy consumption is really minimized while you’re connected to the Internet and doing different things.
The goals for mbed OS are very different from a traditional RTOS, and in the future we’ll also have support for multi-tasking, which means you can do a little bit of what you do with an RTOS. In general, we’re not positioning mbed OS to replace an RTOS, as those are still very important in the embedded world when you have real time requirements. So if you really want to do real time control of physical things with nanosecond and millisecond time requirements, you probably would use an RTOS.
We have another solution for our RTOS partners, because we have a great RTOS ecosystem, and that’s called the mbed Client. What that does is provide the very upper layer of communications capabilities, which are common across mbed OS and different RTOSs such as cloud communications and communications security.
So the client works on RTOSs as well as Linux, and we’ve made sure there’s interoperability between things that run mbed OS and things that run other operating systems. Both will be available at the end of August.
C2: You said “bare metal” earlier. Let’s start there in the discussion of security.
Shelby: You’re referring to securing the device itself; we should talk about some of the hardware aspects. If you look at the big picture, if you are not an Internet-connected device, if you’re just an embedded device, the biggest thing you need to worry about [when it comes to] device security is keeping secure the information that’s already on your device—and the concern is physical security.
But when you start talking about network or Internet connectivity, you need to start caring about communications security and the lifecycle security we discussed earlier. How you manage the device remotely: that’s really the difference.
Our device-side security solution is uVisor and it’s part of the security services in mbed OS [see Figure].
C2: What does uVisor do?
Shelby: On the device you want the ability to keep things that you’re doing secure from the rest of the software system. In traditional CPU-type systems, you have different ways of doing that, usually via some kind of segmentation. In embedded devices, traditionally this has either been ignored, or done via firmware protection or TrustZone in Cortex-A embedded cores, or the entire device has become a secure device, and that’s what we see with secure [credit/transaction] cards. So there are secure elements of different kinds, including SIM cards, which run on Cortex and are tamper-proof.
That’s an additional level of device security. We don’t see that happening in current IoT deployments, but this could change for specific verticals. We sometimes see things like secure storage to store a key, but that doesn’t always solve the problem of when you go to use that key and software is still vulnerable. And so we’re left with the problem of how do we secure software as it’s operating on a device?
We at ARM thought this was a very important problem, so we came to the conclusion that with the ARMv7-M architecture—the current ARM Cortex®-M3 and Cortex-M4 processors—that we can actually implement a reasonable software segmentation strategy purely in software without requiring additional hardware features. This is uVisor.
C2: You are securely partitioning software on the MCU itself?
Shelby: Correct. It’s using the ARMv7-M architecture with the memory protection units, so we require that you have an MPU [memory protection unit]. The vast majority of our Cortex-M3 and Cortex-M4 based devices have an MPU. We’re able to define what software routines are able to execute in the secure mode, and what pieces of software are not [see Figure].
We can put things—sensitive things like keys—in the secure space. We could put the actual crypto algorithm software libraries into the secure space. We can even put secure drivers for a crypto accelerator in the secure space. As well as things like secure boots for the lifecycle security we discussed earlier. How we manage bootstrapping and configuration can all be done in a secure space. So that if you’re just running a non-trusted third-party application on your device, they can’t access that information or change that software.
Soubra: Let me add one item here. In all of the Cortex-M processors we have a memory protection unit (MPU). I want to contrast this with a memory management unit, which is something you’d use with Linux, for example. The Cortex-M is for real-time, deterministic embedded applications, so it only has the memory protection unit.
The MPU allows you to section off regions of memory and define the protection you can access at the task level. That is, applications can say: “this part is mine, that part is yours.” If the driver is located in the protected area, and if some IoT application tries to access the protected space, then you get an exception saying: “okay, this guy is trying to go where he shouldn’t.” Most of our partners include the MPU because it makes more reliable software, and in the case of the uVisor, to use it to make secure software.
C2: uVisor is new or not new, Zach?
Shelby: New. This is part of mbed OS we’re introducing for the first time.
Soubra: Exactly, so multiple people on the market use MPU. It just makes software more reliable because you can section it. But up to now, you would be very hard-pressed to find somebody who built the whole software stack down from the operating system all the way up to the protocols in such a fashion. That’s what mbed OS is doing, it’s giving you the communication protocols, the security, the handling of the encryption of the keys, the uVisor; you get the whole package, and it sits on top of this technology which is the memory protection unit.
That’s what mbed OS is doing, it’s giving you the communication protocols, the security, the handling of the encryption of the keys, the uVisor; you get the whole package and it sits on top of this technology which is the memory protection unit.
Diya Soubra, ARM
C2: Earlier you defined lifecycle, but can we return to it? Not sure I’m following you.
Shelby: Some people talk about device management. In the context of IoT, we like to talk about security lifecycle management, because it gives a little bit more holistic picture of the whole lifecycle these devices go through.
We are in the process of building different aspects of lifecycle security into mbed OS, and we’ll be doing that continuously because there’s always more you can do. But to start with, we’re very focused on the standards for management protocols, so we built into mbed OS a standard called lightweight M2M device management [LWM2M]. We actually support that in all the devices, and it’s similar to standards we use in the cellular industry to remotely manage cellular devices. This is a new standard that allows you to manage very small devices over connections like a Thread network or a slow telemetry network.
C2: It sounds like there will be more coming out in this area as you talk about configuration, monitoring, provisioning, bootstrapping and related.
Shelby: This will keep us busy for quite a few years, because as the users and the developers of these IoT systems become more sophisticated we have to remember there’s a learning curve here in security. So one of our big pushes is to teach people about this kind of security, what’s needed and how it can be used. Because to be honest, a lot of embedded designs don’t make use of nearly this much security today.
Building on the lifecycle security, we will be building in things like the ability to bootstrap, so you can actually get the device from a blank state onto a service. We already have the ability to do configuration and management remotely, that’s already included in mbed OS, so you can change things such as configuration parameters while [the device] is running. And we will be releasing secure remote update.
C2: Now that we’ve covered lifecycle security, let’s get back to network connectivity, communications and the differences with connectivity.
Shelby: Starting in the middle of your list with communications security, ARM acquired the company Offspark and their PolarSSL product this year. It’s a very well-known embedded communication security solution targeting really embedded devices. PolarSSL offered Internet-class security targeted at the embedded, microcontroller-class device. The cornerstone of all security communications technology is TLS, and we’ve created the mbed TLS software based on PolarSSL technology.
If it works for the Web, we’re pretty sure it’s safe for Internet of “things” as well, because we apply the same standards—so our mbed TLS software does this and it’s included with mbed OS for free. It’ll be released in August, and anybody can use it. We also think device security is really important for the whole Internet when it comes to IoT, so that’s also part of our client, and it’s also available standalone. So we encourage everyone to use mbed TLS for lots of different devices as part of making IoT secure.
C2: And for communications security?
Shelby: When you do communications security, there are some things you’re doing on the device when you’re using the public part of the key that’s part of your certificate. When you’re using those keys to do secure operations, you’re in a vulnerable state.
That is: if you’re using secrets to create new secrets— and you want those secrets to stay private on your device—those secrets could be available if someone had access to the software running on the device. That’s an attack surface.
So there are things that we do in communications security which benefit from device security, so they benefit from a secure segmentation of your software that’s running on your device. You want to be able to do those secure things separately from the rest of the software running, especially things that people can download on the device, or change.
Here’s my point: communications security [via secure key management] really benefits from device security. Are you seeing how these pieces all tie together to make a secure IoT system? The other thing I would say is that we can also benefit from hardware cryptography, like in the Cortex silicon offerings from our partners.
Soubra: There are multiple suppliers in the market that offer IP and several IC suppliers offer chips that include encryption accelerators in hardware. Although the Cortex-M architecture is capable of software encryption, users benefit from hardware encryption.
In the Cortex-M3, for example, we actually have three buses coming out of the processor, and putting encryption IP on the system bus frees the code and data buses so you can simply run code for fetching data while [the] other bus is doing the I/O, including encryption.
C2: Is this only on the Cortex-M3?
Soubra: No, The first mbed OS release in 2015 targets the Cortex-M3 and the Cortex-M4. Encryption may be done in hardware via a dedicated block or via software.
Doing encryption in software requires a 32-bit general purpose processor due to the workload, plus do not forget, we have the rest of the software stack to run too which is the primary reason for having encryption in the first place.
C2: Would these functions be practical in an 8- or 16-bit processor?
Shelby: Ah, good question. With our 32-bit architecture it’s super-important for us to be able to do software encryption as well, because all systems are different. In the past, embedded developers have found it very difficult to do advanced, public-key based security on 8-bit or 16-bit architectures.
In these narrower processors, doing encryption is power consuming. And some things like certificate processing are very slow. It just is not suitable for the types of operations you do for real Internet security. So if you’re talking about connecting something to a very proprietary closed system that doesn’t really require security, then maybe an 8- or 16-bit processor is okay. But if you’re really talking about hooking things up to the Internet, you need cryptography, you need all the security measures around that, and that really does lend itself to 32-bit operations.
C2: Do other processor manufacturers agree with ARM about this?
Soubra: I would add some points I’ve learned from talking to people and the partners and customers in the field. They say that the hardest part of system design is the software integration and the rollout.
So when the chip provider is trying to save costs by saying, “I’m going to make an 8-bit, it’s going to be so small, and it’s going to be for IoT,” what will end up happening up the [system-to-Internet] chain is that the chip will be refused. If you give me an 8-bit chip, and now you tell me do TLS and all these protocols that hook up to the Web, it’s probably going to take double the amount of time or three times the amount of engineering effort just to optimize all this code into this device.
So slowly, the market is actually teaching all the silicon vendors that the IoT is really all about the Web. If you want to play, we want something where we get the maximum software productivity because getting in the market first gives you the market, and nobody has teams of people that just do the software. In short: 32-bit processors are going meet the requirements best.
C2: We’ve not discussed the greater Internet—such as cloud-based IoT services—in our discussion of mbed or security. Is there anything you’d care to comment on there from the enterprise standpoint to the node?
Shelby: The other major thing about the mbed ecosystem as a whole is that we’re building a large ecosystem a large number of partners making boards, silicon, modules, software services and devices.: think thousands. Among these partners are a large number of cloud platforms. They’re what we call cloud partners, and they’re an integral part of what we do.
We’re actually saying, “Okay, we’re going to create an ecosystem of lots of boards, lots of products, lots of cloud services that will work together without having to do anything special.” The board designer didn’t have to do this special support for cloud service A and cloud service B. Just by running mbed OS, you can get support for a much larger number of services. They’re based on the same ability to deal with configuration bootstrapping and security, and we know those things work.
And just last month in May, at MakerCon in San Francisco, we announced the new mbed Enabled Program. The mbed Enabled Program is a free accreditation program where we can ensure that these devices, boards or end products, and the different services from our partners have the ability to work together.
C2: We’re about out of time. What are the key takeaways?
Shelby: I think the thing to remember is that the technology and the people that we work with as ARM and mbed ecosystem, we’re still pretty deep in the value chain. We’re working with silicon providers, board makers, module makers and device OEMs and ODMs as well as cloud technology platform providers. So we’re working in the level of technology, not ready solutions. We’re not selling things to consumers where you get this pretty cool mbed-based light bulb and it’s going to work with this mbed light switch.
We’re not a consumer company, so I think it’s always important to separate expectations. But as a technology ecosystem, and a technology toolkit we’re fully intending that. Somebody who’s building a system has this level of confidence that: “I can run mbed OS on this device.” That means I know it will work with these other mbed devices. and it can work with these other mbed cloud services. It has this level of interoperability.
I still need to design the system as a whole; I need to build my value add, and I think that the nice thing about the mbed platform of technology is that it is open. So yes, it will work with other pieces from the mbed ecosystem, but it’s not limited to doing that. There’s a lot of other industry-specific standards you may need to use on top of mbed OS, and there might be additional features you need. Special things, requirements from your industry, whatever that might be, and you create a solution. And there’s nothing in mbed OS or our cloud partners that would limit you from doing that.
Soubra: The only thing I would add is to somehow convey the message to people that there is not anything missing. We’re not waiting for anything, we’re not waiting for any new technology, we’re not waiting for somebody to invent something new. It’s all here today. We have layered security solutions to fit multiple IoT application types. You take, for example, a Cortex-M3, where there’s a huge amount of selection in the market of devices with Cortex-M3 cores. You put this software on it, and you’re up and running to build these IoT solutions. Yes, you still have to build them, as Zach said, but nothing’s actually stopping you except the willingness to go do it.