OSCORE for IoT Security: Building Sustainable LPWAN Solutions, Part II

Building an efficient IoT solution is challenging.

Part I of this series looked at how CoAP, an application protocol designed for IoT, can help overcome device-sides constraints like battery capacity, CPU, memory, and data reporting issues using lossy, high-latency LPWANs, and server resources as efficiently as possible.

Still, challenges remain. In addition to being efficient, solutions must be secure.

For transport on LPWANs, CoAP nesting on UDP is more efficient than MQTT sitting on TCP.  However, to transfer data securely, both use byte-adding, energy-consuming, legacy, security protocols. CoAP uses DTLS while MQTT and uses TLS, and herein lies the problem.

Unlike CoAP, TLS and DTLS are both legacy protocols designed for the internet where resources are extensible and not IoT, a world defined by limitations.

CoAP and DTLS perform better than MQTT and TLS over LPWANs, but in a world where each picoamp and byte translate into pennies, operational savings and profitability, better is not good enough.

Introducing: OSCORE

Object Security for Constrained RESTful Environments (OSCORE) or RFC 8613 as the IETF calls it does some provides important benefits when compared to competing approaches:

OSCORE reduces security overhead substantantially improving total solution performance.

• Energy-efficiency: encrypting the payload and not the entire message is clever, saving bytes and picoamps. Studies show OSCORE uses less memory and CPU, resulting in up to 30% energy savings. Theoretically, this could result in more secure battery-operated solutions with better ROIs.
• End-to-end: TLS and DTLS encrypt from the device until the next gateway, at which point the data is unencrypted, re-encrypted, and forwarded on. In this hop-by-hop scenario, information is only as secure as the network. OSCORE encrypts only the payload, and only a pre-authorized end-point may unencrypt the data. Your network could be compromised, and your data would still be secure.
• Flexibility: unlike TLS and DTLS, OSCORE works at the applicative layer and with different transport protocols, so in addition to CoAP, a developer can use OSCORE with Non-IP Data Delivery (NIDD), SMS, TCP, and others.

OSCORE unlike other approaches secures data end-to-end.

Unfortunately, OSCORE does not currently have a native key exchange mechanism, and workarounds must be used, but this is doable. EDHOC, a standardized key exchange mechanism, is already being evaluated by the IETF.

Other design considerations should be taken into account when using OSCORE. Many networks like NB-IoT and LTE-M already encrypt data at the network level. So for battery-operated smart water metering and gas metering solutions where energy is at an absolute premium, OSCORE combined with the network encryption provides sufficient security. Add an efficient transport mechanism like NIDD that strips out the cumbersome, non-necessary IP, and you have the perfect energy-efficient, secured transport model. Alternatively, in cases where security is prized and energy, not an issue, OSCORE may be used in conjunction with TLS and DTLS doubling up the encryption, so to speak, while providing a key exchange mechanism. 

Conclusion

Billions of devices will soon deliver the goods and services we need to live, from water and electricity to the street lights helping to secure public spaces. IoT’s potential is enormous, but the idea of IoT without security is terrifying.

Good security practices begin during the development phase.  All IoT solutions benefit from robust device management security practices like zero-touch commissioning, firmware updates (FOTA), authentication, and solution encryption, all part of Lightweight M2M.