Security is critical for a trustworthy Internet-of-Things. To achieve this, it is crucial we solve the main challenge of secure identities for constrained IoT devices and find efficient ways to deal with the many identity technologies in use. Different ecosystems have disparate needs and practices. Yet it is clear that automation and zero touch mass registration is necessary for scaling up to billions of devices. A secure identity – anchored in hardware – is at the center.
Ericsson, ARM, and u-blox have joined forces to address this issue. Together, we have developed a concept that can integrate and secure IoT devices from any ecosystem – something that is necessary to enable IoT deployments to move to massive scale. A prototype using well-proven security technology from mobile networks, implemented on a u-blox device utilizing ARM mbed OS 5, was demonstrated at this year’s Mobile World Congress.
The importance of security in IoT
Internet of Things comprises billions of connected devices, most of which are small size, low cost, low power, constrained in terms of processing power and storage, operate unattended and can be expected to run more than ten years. Close-to-zero cost for roll-out, provisioning, and operation will be necessary, calling for automated processes.
Security and privacy are among the major concerns for businesses adopting IoT. This increases with the growing significance of IoT in corporate, government, and critical infrastructure contexts. New IoT devices being deployed in new use cases brings significant security challenges.
Secure identities are key components in this context. Two important aspects are needed: an efficient identity technology that can be used also on very constrained devices, and management of these identities during the lifetime of the device.
IoT security terms and concepts
How can secure environments be provided for IoT? Different ecosystems have unique needs and practices. We believe the diversity will continue for at least the foreseeable future, and the best way is to focus on brokering of existing, successful technologies, as a needed solution bridging different ecosystems.
Some key terms and concepts – a brief overview is included at the end of the post.
- Device identity
- Crypto schemes
- Root of trust
- Device authentication and agreeing on keys.
Proof of concept demonstration
Ericsson, ARM, and u-blox have joined forces to create a concept for integrating and securing IoT devices from any ecosystem. This is key to moving IoT deployments to massive scale with zero cost and for IoT to be trusted when involving actors from all concerned ecosystems.
Only a small portion of IoT devices will connect to the Internet via cellular networks. However, the well proven Authentication and Key Agreement (AKA) technology from the cellular networks can be used also when connecting over non-cellular networks and for constrained IoT devices, where saving on power, size, and cost are crucial.
The proof-of-concept uses ARMv7-M based devices running ARM mbed OS 5, which contains an mbed uVisor – a hardware-enforced hypervisor – that allows for creating a trusted execution environment with a strong enough security level to securely store device and AKA identities in the device. Future versions targets ARMv8-M based devices with ARM Trustzone. We leverage the AKA procedure and the EAP-AKA approach for non-cellular access to get an efficient low cost identity solution on the device side and securely provision the identities to the device using the Lightweight Machine-to-Machine (LWM2M) protocol.
To illustrate the concept, we use a smart goods delivery setup, where each parcel contains a constrained device. The solution is implemented on a u-blox ODIN-W2 stand-alone IoT gateway module with Wi‑Fi & Bluetooth utilizing ARM mbed OS 5.
Eco system engagement
“By working with leading companies in the ecosystem, we want to ensure that secure IoT solutions become available to users and developers from all different sectors”, says Jan Höller, Research Fellow, IoT, from Ericsson Research. “Interoperability is key for IoT to take off in a massive way, and secure solutions is one of the hardest nuts to crack, so we went for jointly solving that one.”
“Secure device authentication is a key challenge to deploying constrained IoT devices at scale,” according to Michael Horne, Vice President, IoT Business, ARM. “In order to tackle this, we are collaborating with Ericsson and u-blox to architect in secure system provisioning through the ARM mbed IoT Device Platform. This will enable all enterprises to build secure IoT solutions quickly.”
“As u-blox provides wireless and positioning modules and chips for a wealth of different IoT applications, we have created a security ‘roadmap’ with five critical areas to our product security. This collaboration with market leaders comes as a great opportunity to implement secure IoT solutions on a larger scale,” explains Håkan Svegerud, Product Strategy, Product Center Short Range Radio, u-blox.
Life cycle management
Across the device lifecycle, different stakeholders have different interests and responsibilities to interact with the device in a secure way. It starts at the manufacturing of the chip, then into an automated process of device OEMs, system integrators and solution providers, on to users, application service providers and network providers. Managing security and IoT device identities and the trust relations will be critical in this process and it needs to be done with minimal manual intervention.
Brokering of generic IDs and the relations is needed. In our next blog post, we will describe in more detail the part of the demo that involves identity brokering using blockchain technology.
For more reading on IoT Security, please check out Ericsson’s IoT Security topic page.
IoT Security terms and concepts explained
The device identity is normally a boot strap credential together with a device identifier. The credential is generated or set during manufacturing and used to securely download other sets of credentials used for things like authentication, connectivity, management. The device identifier does not need to be secret but (a part of) the credentials need to be.