Blog: Jeremy’s Advice on IoT Security

Blog: Jeremy’s Advice on IoT Security

Jeremy, as a software engineer and an expert in LwM2M as you participate in the Open Mobile Alliance TestFest, what are your thoughts about IoT security?

Security will be a monumental challenge. Defective security of a connected device could have critical consequences. Future solutions will need far more robust, comprehensive and integrated considering the highly dynamic nature of the IoT eco-system (hardware, software, networks, etc.) while still remaining open and adaptable as organization continue to evolve.

In 2014, a University of Michigan team accessed a traffic light network using readily available hardware. Once inside the system, the team quickly gained the ability to change traffic signals, alter logic commands, and disable the signal devices. Smart City systems designed to serve citizens could become weapons in the wrong hands.

To enable secure IoT solutions, the entire communication channel from the sensors to the service provider has to be secure. In many cases, current solutions send non-encrypted message that can be too easily intercepted, falsified or misused leading to security breaches as illustrated above. It is critical that IoT developers have adequately considered security features during the design phase of their IoT solution development. Such an approach provides better guaranties in terms of managing the data exchange integrity but also in terms of securing the network as devices are added.

 

Some of us are still novice and curious to understand how security works in the LwM2M standard. Could you explain the mechanisms and how it might be different than the MQTT for instance?

The OMA Lightweight M2M standard mandates the use of TLS protocol on TCP/IP networks and DTLS* protocol on datagram networks which were specially designed to protect messages from being intercepted, modified and falsified on the object’s network. These protocols are a standard within the IoT world. They ensure that Device authentication is used prior to a new sensor admission onto the IoT network and communications between all the IoT elements are secured (thanks to cryptology mechanisms) using light but powerful cryptographic algorithms. DTLS has little impact in terms of computing power and memory as it was designed specifically for constrained devices.

Several encryption methods can be used, like:

  • PSK: Pre-Shared Key
  • RPK: Raw Public Key
  • 509: Certificate

These mechanisms are classified from the easiest to the hardest in term of implementation complexity. And, from the less to the more CPU intensive.

Using 3 different mechanisms allows for the possibility of more easily handling different   solution limitations: constrained device, data server, etc.

A key point to understand is that unlike MQTT, LwM2M does not only use TLS protocol but also defines how the security keys are managed during the IoT device lifetime. The security keys used by a LwM2M device can be revoked or updated by an authorized LwM2M Server in a well-defined and standard way. This guarantees that the security of the system is always up-to-date even if some security material was leaked.

 

IoTerop is participating in the definition of the LwM2M 1.1 with other major IoT key players. Could you tell us what improvement has been made in the newest version?

In LwM2M 1.1, a new mechanism has been added: OSCORE.  This is a major improvement for the constrained network since it can be used to secure the data at the application level.

The major difference with the previous approach is reduction of the encryption footprint by encrypting just the payload of the message instead of the complete message.

 

One last question, could you tell us what are the benefits of using IOWA IoTerop software solution based on the LwM2M?

Some of the drawbacks of enabling robust security are the impacts caused to the devices in terms of computing power needed (thus energy consumption consequence), and to the overall IoT solution in terms bandwidth and communication overhead. IoT developers thus need to choose a security mechanism adapted to the characteristics of the targeted connected object devices and network environment, considering: limited memory, computing power, energy availability, bandwidth availability while trying to envision how future use cases will further task security. In addition, an IoT developer would certainly prefer to rely on a security mechanism that is standardized, componentized, and widely used in the Industry, thus proven robust, interoperable and sustainable as new best practices are adopted.

IoTerop’s solution’s, strong security practices are enabled and enforced at every level. Device authentication on the network is mandatory prior to the addition of new sensors. Communication between all the IoT elements is secured through light but powerful encryption protocols. These combined elements prevent data interception, falsification and hijacking. By using IOWA, these mechanisms are hidden to the user and a common interface has been designed for the user. This means that the user can use whichever mechanisms he wants without altering its own architecture.

 

*Datagram Transport Layer Security (DTLS): The DTLS protocol provides communications privacy for datagram protocols. DTLS allows datagram-based applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security guarantees. The datagram semantics of the underlying transport are preserved by the DTLS protocol — the application will not suffer from the delays associated with stream protocols, but will have to deal with packet reordering, loss of datagram and data larger than a datagram network packet size. The DTLS protocol is defined in RFC 6347 for use with UDP.
Close Menu