ARM Security Update for the IoT

Despite all the enthusiastic discussion about security in the IoT and a healthy market in providers of solutions for the same, it is difficult to believe that we are doing more than falling further behind an accelerating problem. Simon Segars echoed this in his keynote speech at ARM TechCon this year. The issue may not be so much in the big, new and high-profile applications. It’s in the lower-profile, cheaper and legacy devices. You can’t blame the manufacturers; we ourselves, from consumers up to utilities prioritize convenience and cost far ahead of security concerns we don’t seem to understand. And what we don’t prioritize for will certainly not get fixed in products.

The infamous Mirai botnet provided one of the first wide-scale examples of just how exposed we are. Specifically targeting IoT devices as launch-points for bots, this DDoS attack brought down GitHub, Reddit, Twitter, PayPal, Spotify, Netflix, AirBnb and others. Much more recently, the Reaper botnet has evolved from simple DDoS to actively attempting to break into secure devices. Concern about vulnerabilities in critical infrastructure (the grid and power generation plants) is growing sufficiently rapidly that a bi-partisan group of senators are floating legislation to regulate in light of “an obvious market failure” (their view) to self-regulate. When the government steps in to regulate, you know you’re in trouble.

It’s not clear to me yet that there are solutions for dealing with legacy devices (though it seems something should be possible in choking off network access for “uncertified” devices through router enhancements), and the legacy problem may solve itself over time as these devices stop working. But surely we can do more to certify that new devices, whether built by internet giants or garage-shop entrepreneurs, should automatically be guaranteed to follow the highest state-of-the art security standards? This is what ARM aims to ensure through their just-announced Platform Security Architecture (PSA), which they tout as a method to ensure that IoT devices are “born secure”.

It looks like PSA builds on their TechCon announcement of a year ago, also security focused, but now going further. As I read it, their view is that:
· We need a standard architecture for security so that compliance/non-compliance can be assessed easily.
· Becoming compliant with this architecture should be as easy and as inexpensive as possible (carrot).
· Not being compliant with the architecture will shut you out of cloud access / services / a growing ecosystem available to everyone who is compliant (stick).
· And quite likely it will ensure you can never sell your product to the US government or companies who work with the US government (more stick). Not that the government is likely to legislate for ARM-based solutions, but no reason they wouldn’t legislate for security expectations exhibiting similar characteristics to those offered by PSA.

There are three parts to PSA:
· A detailed analysis of IoT threat models
· Hardware and firmware architecture specifications, built on security principles addressing these threat models, to define a best practice for building endpoint devices
· A reference open-source implementation of the firmware specification, called Trusted Firmware-M.

Incidentally, this standard is built for an expectation of deployment on Cortex-M class devices. ARM’s view is that Cortex-A architectures are already well covered with security solutions, the M devices will be most widely deployed in the IoT and are already highest volume and these are potentially most vulnerable for all the reasons covered earlier. Source code (initially for Armv8-M devices) will be released in early 2018.

ARM are also releasing two new IPs – TrustZone CryptoIsland and CoreSight SDC-600 secure debug channel. For the first, security works best when the attack surface is as small as possible. Secure islands are a way to ensure this by minimizing potential for intruding on secure operations like access to keys and the encryption/decryption process, along with provisioning for software updates (a key component in making sure that devices born secure will remain secure). For the second, debug is a famously insecure channel. ARM has integrated a dedicated authentication mechanism to control debug access.

ARM has signed up a bunch of industry partners, from silicon providers (NXP, Renesas, ST, ..), OS providers (Linaro, Micrium, Mentor, ..), security experts (Symantec, Trustonic, ..), systems/network companies (Cisco, Sprint, Vodaphone, ..) and cloud providers (Azure, Amazon, …). Security in the IoT is an ecosystem problem, needing an ecosystem compliance solution; if anything can force IoT makers onto a security straight and narrow (and get them ready for impending regulation), this kind of backing should.

You can learn more about PSA HERE.