Over the air (OTA) bootloading update tutorial?
-
@Anticimex I'm testing different scenarios, one using a signed checksum to initiate the OTA - this would be compatible with the current framework. The challenges are obviously size limitations and the lack of a RNG...
-
@Anticimex I'm testing different scenarios, one using a signed checksum to initiate the OTA - this would be compatible with the current framework. The challenges are obviously size limitations and the lack of a RNG...
@tekka a signed initiation I believe would come for free unless the initiation message is explicitly ignored when deciding to sign a message in the library. It is if/when the bootloader has to do signing or verification things get tricky. A signed initiation could be hacked though. An attacker could detect am initiated OTA transfer (target reboots in bootloader/OTA mode) and then (if the bootloader is unable to process signed messages) anyone could feed anything to it. If the bootloader could verify messages though, there would be no issue of course. The payload could be sent unsigned (for efficiency) and last a checksum is sent signed (which is validated both for signature and checksum on received payload) before bootloader marks flashed software as valid.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@tekka a signed initiation I believe would come for free unless the initiation message is explicitly ignored when deciding to sign a message in the library. It is if/when the bootloader has to do signing or verification things get tricky. A signed initiation could be hacked though. An attacker could detect am initiated OTA transfer (target reboots in bootloader/OTA mode) and then (if the bootloader is unable to process signed messages) anyone could feed anything to it. If the bootloader could verify messages though, there would be no issue of course. The payload could be sent unsigned (for efficiency) and last a checksum is sent signed (which is validated both for signature and checksum on received payload) before bootloader marks flashed software as valid.
@Anticimex the bootloader will only go to update mode if the initiation msg is signed and valid. The initiation msg is nothing but a signed crc+type+version fw_config message. This message is validated against the current fw crc and the type/version settings stored in the eeprom. If the message is invalid, the bootloader will proceed with the normal startup procedure (=validate fw crc against eeprom settings and start if ok).
Now, an attacker could indeed interfere with unsigned fw payload blocks - but at the end, the crc from the newly transmitted fw will not match, and thus, the eeprom settings are not updated. At this point you are left with a non-functional node and a bootloader which requests a new (valid) fw. -
@Anticimex the bootloader will only go to update mode if the initiation msg is signed and valid. The initiation msg is nothing but a signed crc+type+version fw_config message. This message is validated against the current fw crc and the type/version settings stored in the eeprom. If the message is invalid, the bootloader will proceed with the normal startup procedure (=validate fw crc against eeprom settings and start if ok).
Now, an attacker could indeed interfere with unsigned fw payload blocks - but at the end, the crc from the newly transmitted fw will not match, and thus, the eeprom settings are not updated. At this point you are left with a non-functional node and a bootloader which requests a new (valid) fw.@tekka that sounds good. But this initiation message, it is sent during "normal" MySensors operation, right? If so, then you won't need to dabble with signing support in the bootloader. If the initiation message contain a crc of the "pending" FW, and this crc is protected by signature, the node will fully validate it, identify it as a OTA startup, store the crc in eeprom and reboot into FW upgrade mode. The bootloader just does it normal thing, receiving the new FW, and matching the calculated FW crc against the eeprom crc and reject the image if crc does not match. That's perfectly adequate for signed OTA.
-
I should add that this signing goes right under the "normal" signing configuration. The receiving node has to be configured to require signed messages (and be able to process them) , and the GW has to be able to calculate signatures.
-
Hey guys,
So, I am new to MySensors community and I am very interested in OTA. I've read this thread and I am wondering if there is some tutorial teaching how we can transfer from controller/gateway to the nodes the sketch. -
This post is deleted!
-
@Oitzu could you share how you are building the messages and other things to send the new hex?
-
As examples i recommend the nodejs controller: https://github.com/mysensors/Arduino/blob/development/NodeJsController/NodeJsController.js
Also the bootloader source:
https://github.com/mysensors/Arduino/tree/master/Bootloader -
@KaaIoT What is the webinar exactly about? I spend the last 2-3 evenings rebuilding the OTA functionallity in a custom controller and compiling the bootloader for my 8mhz 3.3v nodes.
Maybe i can learn something to improve it?@Oitzu said:
@KaaIoT What is the webinar exactly about? I spend the last 2-3 evenings rebuilding the OTA functionallity in a custom controller and compiling the bootloader for my 8mhz 3.3v nodes.
Maybe i can learn something to improve it?I think maybe it was spam or something. The post is gone.
-
@Oitzu said:
@KaaIoT What is the webinar exactly about? I spend the last 2-3 evenings rebuilding the OTA functionallity in a custom controller and compiling the bootloader for my 8mhz 3.3v nodes.
Maybe i can learn something to improve it?I think maybe it was spam or something. The post is gone.
-
I am starting to play with OTA updates and I'm interested in testing the DualOptiBoot method. I have been searching the forum but I haven't been able to find a recommendation for what external flash memory to get. Does anyone have any suggestions? An eBay link would be fantastic if possible.
-
I have a mouser link to a memory that should work: http://eu.mouser.com/Search/m_ProductDetail.aspx?R=AT25DF512C-SSHN-Bvirtualkey58070000virtualkey988-AT25DF512CSSHN-B
-
-
Does a signed crc really provide sufficient security? Modifying a firmware in a way that results in the same crc should be fairly easy, since crc is very predictable.
@mfalkvidd if so, the choice of crc algorithm is bad. And a hash should be used instead.
-
Well, obviously. We already have sha256 capability. But not publicly available.
