[riot-devel] Call for OTA (Over the Air Update) Task Force
frank-riot2015 at holtznet.de
Wed Jan 21 16:29:47 CET 2015
Am 20.01.2015 um 18:47 schrieb Arvid Picciani:
> - Who is interested in such feature, and what is your approach to OTA?
i'm interested having OTA update capability. At the moment i work on
integrate micro-ecc library and flash api into RIOT. These are useful
things for OTA updates.
> - When can we meet virtually (or physically in case anyone is in Berlin)?
I'm available only in the evening for virtual or physical meeting.
> While “when” and “from which buffer” is totally application specific,
> there are some
> common Ideas how to approach OTA in the core os itself that i have
> collected from people so far:
> - Simply over-writing RIOT in flash with a new copy, by keeping the
> flasher code external.
This needs to load flasher code into RAM. On battery powered/buffered
devices i think this is an practicable way. There are MCU like ATMEGA
which cannot execure code from RAM.
> - Insert SD cards with a new image and reboot
I think this is unpractical by limiting designs to have an SD card slot.
> - Two copies of RIOT on the same flash, with a boot loader selecting
> the active one
Two copies are an good idea but this needs to link an firmware for both
possible start addresses. An alternative is receive an firmware image
into an free area and then flash it into correct region after checking
if all received correctly.
> - Re-flashing only the application part of RIOT over the air while
> keeping the OS part forever.
> - Any relevant concepts missing here?
My Idea is to have an boot loader with limited functionality. This boot
loader checks an checksum(CRC,Fletcher or cryptogaphic) of flash memory.
Is the checksum is correct included code is executed. If not boot loader
jumps into receive mode for an limited time. An flash update can
initialized by RIOT function call or by reset/power on.
The code needs to detect how reset is performed and jumps to flash code
imminently when MCU is reset by an wake up interrupt. If not the boot
loader waits one or two seconds if update packets are received.
Update packages are send by another RIOT node at lowest possible network
level to reduce code size of boot loader. The node acts as proxy by
receiving updates from an update service. The node has to repeat
packages until they are committed by node in boot loader mode.
The firmware upgrade should by encrypted and signed. To reduce code size
XTEA64 (encryption) and Fletcher checksums are candidates. This can
implemented optional per Board/MCU when not enough ressources are
available for an second instance of AES/CRC code.
The firmware can provided by an update service which knows the key of
every device. The firmware is signed by an predefined key. If an device
requests an upgrade the firmware is encrypted with the device key. The
boot loader checks the signature before and after flashing and
calculates an check sum which is checked on every boot. The update
service has to know every device so its possible to send only changed
On nRF51 MCU there are two code regions available, so its possible to
protect boot loader information from RIOT Application access. I think
there are more MCU's with similar functionality.
I think an fresh bootloader can accept any signing key, which is stored
locally. The MCU can initially flashed with an application for key
generation and key exchange. An reseted boot loader needs to accept
unencrypted software to recreate an key or there is a need for an
asymmetric key exchange in boot loader code.
I think if public key signature checking is implemented the update
service and can be insecure and the encyption key is only needed if the
firmware content needs to be secured.
The public signature of firmware needs to be checked with first packet
to avoid corrupting firmware image by external ressources.
- Choose frequency/scan for update packages
- Auto update functionality
- How acceptable signing keys exchanged? (as part of application firmware?)
- How to reset boot loader accept any signing key? (button? or press
then times reset?)
> Open discussion points are wether we need:
> - Cryptographically signed OTA updates
I think this needed to avoid unwanted firmware updates. But if it
implemented correctly its possible to create devices with RIOT without
the possibility to replace the firmware with an own version. I love to
hack things with MCU so the boot loader needs an reset procedure which
is accepting any signing key. The reset procedure needs to erase all non
boot loader pages. The accepted singing key must be erased after
cleaning all flash pages to protect any information stored into flash.
> - Are HW watchdogs necessary to check if the new image boots properly?
In development this is needed. But there are MCU which can't disable an
watchdog after it's enabled. On other MCU the watchdog must be disabled
by boot loader to avoid an endless reset.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel