Trialing OSCORE for end-to-end IoT security in resource constrained devices

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.

Putting OSCORE to the test in a smart city setting

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).

From the sensor to the cloud

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).

Where OSCORE shines

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).

1. OSCORE protects each payload individually using pre-shared keys. Thus key negotiation and session management is not required anymore.
2. Unlike DTLS, OSCORE messages are not completely encrypted. The metadata is still left in clear text, saving computational resources, power, and bandwidth.

Figure 2: Data and Metadata in OSCORE packets

1. Encrypted OSCORE messages can be as small as 11-13 bytes,[4] significantly smaller than most of the IoT security protocols used today, making OSCORE a suitable security option for constrained IoT nodes.
2. Sending metadata in plaintext while the data itself remains encrypted can increase efficiencies without compromising on security.  For instance, OSCORE allows for HTTP-CoAP protocol translation at a gateway or a proxy. The proxy device converts a HTTP request into a CoAP request allowing powerful HTTP servers/clients to talk securely to resource constrained IoT CoAP clients/servers.

Our initial observations in the field

1. The smallest OSCORE packets, we observed in our quick test, were 22 bytes long for 2 bytes of payload. The mesh network in our office has an MTU of 12 bytes. The mesh nodes handled packet fragmentation robustly.
2. Attempts to dump the packet at the gateway and decrypt/modify the packet was also performed. OSCORE identified all the basic security threats.
3. The OSCORE security context was pre-shared when we provisioned the mesh nodes. This was slightly inefficient. OSCORE works best with RESTful Device Management protocols like OMA-LwM2M. Combinations (like using DTLS for key negotiation and then OSCORE for data exchange) are not as efficient.

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.