- Support portal
- Evaluation Kits and partner products
u-blox Support
- Product documentation
Documentation
- About
- Sustainability
- Partners and Alliances
- Contact
About u-blox
- Investor relations
Investor relations
Tech
|
03 Feb 2020
The new lightweight security protocol to secure CoAP messages could well become an industry standard. We implemented it in a smart city project.
The availability of LTE-M and NB-IoT low power wide area (LPWA) cellular networks has enabled countless new applications in areas as diverse as smart homes and cities, connected factories, and public and private utilities. While the specific needs of connected sensors and other devices vary from use case to use case, they tend to have at least a few points in common: They need to be small, cheap, and optimized for a small power budget. And, because the data they sense and communicate can expose people, cities, and companies to cybercriminals, they require end-to-end security.
OSCORE[1], short for Object Security for Constrained RESTful Environments, was defined specifically to meet these increasingly demanding requirements. Defined by IETF (Internet Engineering Task Force), OSCORE offers a number of improvements in securing messages sent using CoAP[2] (constrained application protocol), one of the preferred communication protocols used in LPWA use cases.
Specifically, OSCORE has two distinct advantages over the other most common IoT security protocols. OSCORE encrypts only the data part of the payload, thus decreasing security overhead and increasing bandwidth usage and battery lifetime of the device. Additionally, OSCORE replaces the key negotiation process, which is too resource intensive for most constrained devices, by using pre-shared keys.
In this blog post, we present a prototype implementation of OSCORE to securely send sensor data over several transport links. As depicted in the image, the data is passed through a Bluetooth mesh network to a gateway, from where it is sent to the cloud using UDP before being delivered to a server anywhere in the world. The trial is part of a Vinnova (Swedish Government Innovation Agency) project[3] that tests end-to-end security in public environments. We collaborated directly with one of the contributors of the protocol, from RISE (Research Institutes of Sweden), to become an early adopter of the new standard.
Figure 1: System structure
The mesh nodes are based on the u-blox NINA-B3 Bluetooth low energy module with an onboard MCU to implement the required software functionality and use the standard Bluetooth Mesh protocol. They come in three flavors: the OSCORE node (dark grey), standard mesh nodes (red), and the gateway node (white).
The data’s journey from the sensor to the cloud begins at the nodes depicted in dark grey, which sense the data (e.g. a temperature and a humidity reading) and encrypt it with OSCORE object-level security using cryptographic information pre-shared during setup. The node then sends the CoAP message including the encrypted data in a standard Bluetooth Mesh status message following a publish/subscribe model.
The data propagates across the mesh network, depicted as red nodes, still in the form of OSCORE-encrypted CoAP messages sent as Bluetooth status messages. Because the mesh nodes do not have access to the cryptographic information used for encryption, they are blind forwarders of the information.
The data then reaches the gateway device, in white, which is made up of two modules: a NINA-B3 Bluetooth Mesh module, which is part of the larger mesh network, and a SARA-R4 cellular modem that supports the LTE-M and NB-IoT protocols.
From the gateway, the entire payload – the CoAP message including the OSCORE encrypted data – is re-packed into a UDP message and sent to the cloud via the internet using the cellular modem. Like the mesh nodes, the gateway and other intermediary devices such as routers are completely blind to the data.
Once the data arrives at the cloud server, it can be decrypted using the same cryptographic information that was originally shared with the OSCORE sensor node, allowing it to be presented as plaintext on a webpage or stored in a database (either encrypted or decrypted).
OSCORE is based on symmetric pre-shared keys which are shared only between the end devices (the server and the sensor node in our case).
Figure 2: Data and Metadata in OSCORE packets
With the Open Mobile Alliance (OMA) taking OSCORE into their LwM2M 1.1 specification, OSCORE might become the next preferred protocol for RESTful environments.[5] Observing standardization organizations, like IETF and OMA, makes it clear that end-to-end security in IoT is becoming more important than ever before.
Feel free to contact the authors of this post if you are curious to learn more and would like to have a constructive discussion about OSCORE, Bluetooth Mesh, or end-to-end security in constrained IoT networks.
[3] Security in Public Environments; https://www.vinnova.se/p/iot-sakerhet-i-offentlig-miljo/
Peter Karlsson
Senior Director of Technology, Short Range Radio, u-blox