Emergent Tech

Internet of Things

Arm isn't saying IoT firmware sucks but it's writing a free secure BIOS for device makers

Take the hint, manufacturers of weak kit

By Chris Williams, Editor in Chief

25 SHARE

TechCon Arm hopes to release open-source code early next year that will help secure Internet-of-Things devices – by encrypting their communications and installing over-the-air security fixes.

The firmware will be a reference implementation of what processor core designer Arm calls its Platform Security Architecture, details of which were published today.

The architecture sets out essentially a recipe for creating a device – such as a home security camera or a smart electricity meter – with these key features enabled by default, each relying on strong cryptography:

This recipe includes a shopping list of hardware requirements – such as a suitable cryptographically secure random-number generator – and a specification defining how software can access the above security features. Manufacturers of IoT products and other gadgets that use Arm-designed processors will be strongly encouraged to adhere to the architecture in future gizmos.

The blueprints were designed after Arm engineers studied various embedded devices out there powered by its processor cores, including the webcams and routers hijacked by the Mirai botnet used to wage war on the internet last year, and developed a threat model – basically, a description of typical miscreants commandeering internet-connected devices and the vulnerabilities exploited to achieve this. With this model in mind, the blueprint to tackle the flaws could be produced.

There are three main problems with many IoT devices today. They cannot be easily, or are rarely, updated with new software to patch over security holes, leaving them open to hijacking by hackers. They have hardcoded credentials – such as "admin" for the username and password – allowing miscreants and malware to login to their control panels and take over the device. They also send private information over the web in plaintext, allowing eavesdroppers to snoop on people's daily lives or tamper with the data in transit.

Do fear the Reaper: Huge army of webcams, routers raised from 'one million' hacked orgs

READ MORE

Not all IoT devices are this bad; the latest smart home kit from big names, for example, take the above seriously. However, there are umpteen network-connected webcams, storage boxes, smart meters and TVs, infotainment systems, home routers, and other gadgets that bungle it one way or another, such as failing to automatically patch gear in the field or hardwiring in obvious passwords.

Rather than see a fragmentation of solutions to the above – basically, manufacturers each trying to solve these problems to varying degrees of failure – Arm decided to go ahead and develop an industry-wide architecture, in which security is non-optional, that it can press upon hardware makers that rely on its technology.

It was also, we suspect, driven by a pang of responsibility for the monster it inadvertently helped create. Arm's lightweight but capable processor cores are used in system-on-chips and microcontrollers that have fueled billions of internet-connected devices around the world, from whizzbang smartphones to crappy hacked webcams that get press-ganged into botnets. Terrible software running on Arm's cores is hardly Arm's fault. However, the chip designer is bent on getting a trillion connected devices online by 2035 – and if that's going to happen, then for fsck's sake, someone needs to secure it or it's going to be a frustrating and fractured future when our web-facing fridges and freezers are turned against us by internet fiends.

So, Arm has drawn up this Platform Security Architecture to lay the ground rules, and hopefully steer manufacturers toward not palming poorly secured Wi-Fi-connected tat onto us. And to get the ball rolling, a freely available open-source firmware implementing this platform architecture will be developed and released by Arm for its ARMv8-M 32-bit microcontrollers, which feature TrustZone among other security features.

This reference firmware, dubbed Trusted Firmware-M, is kinda like a secure BIOS: it's a thin layer of code that runs first thing on the processor, sets up services like automatic over-the-air updates and device identity, and then boots a verified and cryptographically signed operating system, such as your favorite real-time OS or Arm's own mbed OS. The software running on top of Trusted Firmware-M is expected to use the underlying security services so that secure over-the-air updates can be fetched and installed, and authentication using weak passwords will be a thing of the past. Well, we can all dream.

Déjà vu

If this seems familiar, it is. Arm touted very similar low-level technology in 2014: the aforementioned mbed OS. This was supposed to provide a consistent software interface across all the various and wildly different Arm-powered system-on-chips on the market, as well provide things like trusted boot and communications secured using TLS encryption.

We're told, though, that mbed OS is focused on ARMv7-M and older microcontrollers, whereas Trusted Firmware-M is strictly ARMv8-M, and the mbed team is still working on a reference Platform Security Architecture firmware for all Cortex-M cores. The idea is to run mbed OS on the ARMv7-M trusted firmware.

So, in summary, if you're using an ARMv8-M core in your product, you can use Firmware-M. If you're not, you'll have to wait for the mbed OS team to implement the security architecture in the form of a reference firmware for your Cortex-M microcontroller. Or you could write your own code by following the specifications.

This split is a little unfortunate, but it seems to us that this is due to mbed OS being a primarily ARMv7-M project, with a sizable number of chip families to support, and the security architecture team wanted to target the latest flavor of the Cortex-M range, ARMv8-M. It's also a handy way to drum up ARMv8-M licenses for future system-on-chip designers, by providing a trusted firmware layer right out the gate.

We hope the two halves, mbed OS and Firmware-M, will eventually be joined under a coherent branding.

In any case, it's not just all on Arm. Even with the trusted firmware in place, the software running above it has to make use of its services and avoid the usual pitfalls that leave systems open to attack. That means no more hardcoded passwords, no more buffer overflows that can be exploited, no more command-injection bugs in web-based control panels, no more plaintext network connections, no more programming blunders that would render the secure BIOS useless.

Unfortunately, switching to things like certificate authentication from simple passwords in applications will drive up development costs, which is unpalatable to manufacturers in razor-thin-margin embedded-hardware markets. In any secure system, every component is as strong as the weakest component. And all it takes is one bad, exploitable app-level bug to bring the house crashing down around you, hopefully not literally.

It's funny how crap third-party programmers never feature in threat models.

It's hoped market forces will play a role here, that non-security-architecture-conforming manufacturers will be called out or shunned, that shoppers will avoid gadgets that are repeatedly hacked, and that developers will regularly push out bug fixes via Firmware-M's update mechanism. Again, we can dream.

The reference firmware is due to arrive in the first quarter of 2018. Arm also said it will publish the security analyses it carried out on IoT devices during the development of the security architecture. This week, the Softbank-owned Brit chip architectures is holding its annual technology conference, Arm TechCon, in Silicon Valley. ®

Sign up to our NewsletterGet IT in your inbox daily

25 Comments

More from The Register

Web browsers sharpen knives for TLS 1.0, 1.1, tell protocols to dig their own graves for 2019

IE, Edge, Safari, Firefox, Chrome, all planning to deprecate lousy old versions by 2020

Huawei enterprise comms kit has a TLS crypto bug

You don't want insecure kit from a vendor the Pentagon hates, do you?

PayPal reminds users: TLS 1.2 and HTTP/1.1 are no longer optional

Insecure connections will break after June 30th. And it's acquired Hyperwallet, too

ARM’s embedded TLS library fixes man-in-the-middle fiddle

IoT security helper is vulnerable to attacks by malicious peers

TLS proxies? Nah. Truthfully Less Secure 'n' poxy, say Canadian infosec researchers

You thought you were buying better security, right?

It's time for TLS 1.0 and 1.1 to die (die, die)

IETF floats formal deprecation suggestion, even for failback

OpenSSL alpha adds TLS 1.3 support

Shambling corpse of ancient, shoddy, buggy, crypto shoved towards the grave

TLS developers should ditch 'pseudo constant time' crypto processing

Fixes for Lucky 13-type bugs could still be vulnerable

It's official: TLS 1.3 approved as standard while spies weep

Now all you lot have to actually implement it

Facebook cracks opens its bottle of Fizz – a carbonated TLS 1.3 lib

Crypto-code unleashed to inflict security, performance and stability on devs