A New Game-Changer for IoT Connected Product Security

Security is hot on every IoT developer’s mind these days.  Walking the floor at Embedded World 2017 earlier this year you could see all of the major platform vendors displaying their new Trusted Platform Module (TPM) chips.  These modules deliver security features designed to shelter IoT devices from tampering once deployed in field, either via software hacks in person, or through hijacking Over the Air (OTA) updates.  Common features for these TPMs include certificate and credential storage in secure flash, crypto algorithms built into hardware, and tamper protection and alerts.

But these are the early days of this new level of IoT security. Solutions demoed just a few months ago were external to the reference platform itself, being attached over proprietary connectors in some relatively cumbersome way.  Companies who want to quickly develop applications which leverage these features will have to roll up their sleeves and get their hands dirty.

It reminded me of the early days of IoT sensor connectivity.  Hooking up a sensor just a few years ago included soldering or wiring parts together from different manufacturers, with different drivers and interfaces.  This made the process seem daunting to newcomers of the industry looking to prototype new ideas.  But today budding IoT developers can pull a board off-the-shelf with networking, MCU, and built-in sensors built with an all-in-one device, vastly simplifying IoT development and decreasing time to market for new ideas.

With Xively we saw the same evolution towards simplicity in security when TI debuted the new CC3220.  Their off-the-shelf CC3220SF Launchpad reference platform includes all of the bells and whistles of the old CC3200, but with secure storage of firmware, tamper detection, cloning protection, and lots of flash storage for larger, more complex applications.

But what truly attracts us is the platform’s ability to securely install new firmware.  When in production mode, the platform requires signatures for all firmware images before it accepts them. This is a new frontier in firmware capabilities, and frankly, we’re pretty excited about what it means for IoT product security.

Firmware is stored in an internal section of memory for validation purposes. Think of it as a firmware airlock.  If the device cannot validate the signature using a securely stored certificate or key, then the device safely rejects the imposter image.  But if validated, the firmware is absorbed into the devices’ internal flash storage (which has no other direct external access).

This feature puts up large barrier to anyone attempting to compromise your device.  And it comes out of the box with a simple to configure WiFi and MCU combo with mature development SDKs.

To learn more, check out our latest connectivity tutorials which are now available on the Xively Developer Center.

Leave a comment
Comments are closed.

Explore our other Xively News or Recent posts.