ESP32 IoT Device Management using LWM2M

Device Management means to connect, configure, control, monitor and update devices, individually or collectively.

The challenge can range from managing a single or multiple devices on the same location to managing thousands spread all over the world in other cases, to complicate things further, devices can connect in various ways, either through Ethernet, WiFi,Cellular, Lora, SMS and numerous other ways. It can use a slow or fast network, it can be connected all the time or just ping your servers once a day to save power, so many things to consider.

At about 2015 Open Mobile Alliance realized these challenges and released the first version of  Lightweight Machine to Machine standard, the standard describes device management using COAP protocol with UDP/DTLS or SMS transports, recently added TCP/TLS and even MQTT was added though its not part of the standard yet.

Source

So how does LWM2M help you with your device management needs?

LWM2M standardizes the way your devices will talk to your servers, the clients are very lean and designed to work on constrained devices, the connectivity has very low bandwidth needs and doesn't even require the devices to stay connected and that can fit a very broad spectrum of products, it can help you track your temperature sensors throughout your facility or even a buoy in the middle of the ocean, just imagine you can plan a firmware update to a device you'll never see again with maximum safety!

I've chose to implement firmware updates because I had an itch to try it on ESP32, while doing it I've also implemented a basic device that can turn a light on or off and report the current time and a few other properties.

The way I did it was to port wakaama and tinydtls to ESP32, about 90% of it worked without any modification, I've added WiFiManager and NTP Client to the mix and it just worked. (not very efficiently in terms of size though, but good enough for my experiment, the firmware was about 1.2MB in case you're wondering, out of it DTLS and Wakaama were about 100kb-200kb each and took about 6-10kb of RAM, leaving me with about 210kb of RAM which is not bad.)

As soon as it started connecting to my local Leshan Server, I've hooked into the firmware object the update function I've wrote, most of it based on esp-idf OTA with custom certificate validation and I've had a complete solution, the firmware and the signature would be sent over http/https, the completed firmware will be validated against the stored certificate and if it worked, the device will attempt to boot into the new firmware,a few diagnostics will be executed and if the device achieved connectivity and stability, it will mark the new firmware as valid.

The fun part started when I've sent the package URI (/5/0/1) to the device through Leshan Server and Executed the update (/5/0/2), the firmware was downloaded from a local web server, the device validated the firmware and finally rebooted into the new firmware.

Why firmware over-the-air is so important?

Lets agree that time to market is a critical business need, more than once we hear about superior devices and software being ditched because a significant player already got a grip on the market and trying to push a new product is hard if not impossible at times. Many times its the first product or the first player that wins the game.

To achieve a significantly short time to market compromises needs to be made, sometimes a scaled down product, less features and even compromises on a thinner layer of security are essential to get the product out of the door. Once a product gains significant traction and more resources becomes available, a better product can be developed, a more robust firmware, features as well as better security or even security vulnerabilities needs to be deployed while there is no physical access to devices. More over, device recall can kill a business and most companies try to avoid it at any cost. literally.

This is where firmware over-the-air comes in, assuming the device can connect to some kind of network, either by WiFI, or GPRS/3G or even SMS and LORA, it should be able to pull a firmware update when needed or it becomes available.

How does firmware over-the-air works?

Once a device has connectivity, it can either pull a firmware, for example from HTTP server or can be pushed a firmware, for example through COAP blockwise transfers, lets assume its relatively simple to implement it or already has a library available.

To support firmware updates more than once, the device will keep track on two partitions and switch between them every time the firmware is updated, this way the old firmware is kept until the device determines the new firmware is good enough to switch to permanently.

Lets drill down to the specifics of one way OTA can be implemented

1. a device is configured with 2 application partitions, one for the factory application and a 2nd is left empty for future update.
2. a device is notified of an available firmware, the OTA process can start.
3. the device determines the next OTA partition for use, if it just went out of the factory, the 2nd partition is empty, if OTA was completed successfully, the first partition is available for the next update.
4. firmware is downloaded directly to the available partition.
5. the device validates the new firmware, for example with a checksum and/or a certificate.
6. the device boots into the partition and makes sure it works as designed, so it checks the various sensors, network connectivity can still be achieved and either marks the new firmware as valid or invalid, if it crashes, either intentionally or through a watchdog, it will reboot back into the old partition.

I would argue that adding a secure validation on the new firmware is very important even if its only so it will not become another zombie in a large botnet.

The way I've implemented security in my experiment is as follows:

1. Generate a self signed certificate:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365
2. Extract the public key:
openssl x509 -pubkey -noout -in cert.pem > pubkey.pem
3. Copy the public key into a certificate.h file
4. Create a new firmware and sign it:
openssl dgst -sha256 -sign key.pem -out firmware.signature firmware.bin
5. Copy both files to a web server, set the package URI and Execute the Update.

Though if you want to implement secure firmware on ESP32, you can do it "by the book".

OMA LWM2M Includes many device management options and includes on-boarding procedures, which is very important once your production reaches a certain number of devices since you won't be able to do it manually anymore.

You can monitor, configure and control your devices, you can request to be notified using the Observe mechanism and you can query the device state, send commands so the device will turn on or off a certain actuator, reset to factory defaults or even remote wipe a device if it comes to it.

And we can't really talk about LWM2M without talking about IPSO Smart Objects as well, which is a list of objects defining the structure of various sensors and actuators so you won't have to do it.

LWM2M is a lot of fun, you should definitely consider it in your next product!

Tags: