Over the air (OTA) bootloading update tutorial?
-
@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.
-
@mfalkvidd even if crc can be predictable, the signing mechanism is not. So let's assume you can fabricate a firmware with a desirable crc, you still need to provide a valid signature for that crc. And that would not be so easy given the use of a random nonce and a PSK.
-
The use of random nonce ensures (at least to a significant extent) that two signatures will never look the same even with the same payload. So replaying signed messages won't work. Based on that, it won't be possible for an attacker to provide a trusted crc of any form after it has sent the forged FW that yield the same crc as a valid firmware would.
The only way I see that this could be exploited is if the attacker managed to predict the resulting crc and black out the valid FW as it is sent OTA and instead inject the forged FW. And then it let the valid senders signed crc pass though.
But that require the attacker to know the resulting crc of the real FW. And if the OTA solution include a random component with the firmware that is covered by crc that also becomes a tricky task. @tekka might be interested in that.Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
