RAVENS is the result of my internship at Orange. The challenge this project is solving is updating the firmware of extremely small devices in a secure, resilient and efficient manner.
The project is open source, available on GitHub at https://github.com/Orange-OpenSource/RAVENS. We’re open to suggestions, and pull requests! 😀
To get a bit more in the weeds, RAVENS is able to generate and install delta updates in-place, with minimal extra memory (≈ 6kB of RAM, ≈ 20kB of dedicated flash storage) and in a manner that can sustain abrupt interruptions (power cut). Moreover, RAVENS doesn’t require any significant change to the overall firmware, besides the integration of Munin (the installation routine) and a couple of simple drivers.
Why is this a big deal? Installing delta updates in-place has traditionally been a major challenge because of write-before-read conflicts:
- Delta updates involve reusing old data to make the update payload lighter and more efficient ;
- Installing an update in-place mean that the old data are overwritten by the new data as the update progresses, meaning that we don’t need much reserved space to install the update (traditional approaches require twice the size of the firmware).
Installing a delta update in-place therefore forces us to keep any data that is going to be used in the future in a safe place. Otherwise, we’re risking conflicts and making the device non-functional. Approaches trying to achieve this goal usually reserve some space to backup up the overwritten data or embed it in the update payload, making it less efficient. As far as we are aware, this is the current state of the art. RAVENS aims at requiring a limited, fixed amount of non-volatile memory (which we are confident is close to the theoretical minimum), while avoiding storing any extraneous data in the update payload. This will enable smaller devices to update and hopefully fight against massive botnet fleets against which very little can be done, without increasing costs.
The RAVENS architecture is based on three components:
- Hugin: A server-based component able to generate delta updates easy to install in-place ;
- Odin: A simple server that import updates generated by Hugin and communicate with Munin to securely transmit them, without requiring a TLS stack. The protocol used is designed to protect against update replay with a severely limited device (no clock, network fully under the attacker’s control, no PRNG…) ;
- Munin: A client-based routine implementing the protocol to communicate with Odin and securely verify and install the update payload.
In the next couple of posts, I’ll explain the various challenges RAVENS had to solve, and how it did so.
The first post, detailing how RAVENS installs an update and can sustain power cut is available here.
The second, exploring the contraints of securely downloading a blob of data when the device is really limited is available here.
The third post goes into the weed regarding the write-before-read conflict, and how Hugin generates the updates here.
The forth post details why and how we wrote a custom compression algorithm to compress our Update Payload here.
If you want to get in touch, have an early look at some of the future articles and chat, feel free to hit me up on Twitter.