Over the air (OTA) bootloading update tutorial?
-
@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 ;)
-
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.In it's current stage, the OTA FW update is initiated by a FIRMWARE_CONFIG_RESPONSE message consisting of FW type, FW version, and FW CRC. If any of these parameters mismatches, the node will request a new FW. The CRC is validated at the end of the OTA update process against the transmitted FW and written in the EEPROM. This opens ways to forge the OTA update process, as described by @Anticimex
In order to make the OTA update process more secure, adding a random byte to every FW block transmitted and computing the CRC over all sent bytes makes the process more secure and the CRC less predictable. This also implies that the signed CRC is transmitted at the end of the update process and validated against the received FW + random bytes. If any component of the transmitted FW is altered, the CRC will fail and the new FW discarded.
-
I'm not sure a random byte would be sufficient. How do we verify that the correct random byte is used? If the attacker can choose the random number in their firmware, getting a crc that matches the original firmware is trivial. Or do you suggest that a nonce is used for each FW packet? If so, how is that nonce verified?
-
Why would a random byte not be sufficient? The only problem to solve is to make the crc unpredictable. Also, making sure a OTA process is started and finalized by a signed message, and those messages are a function of the OTA firmware, I don't see any security implications.
-
My point is that a crc is, by definition, never unpredictable. If an attacker records one firmware update, the attacker can easily replace the firmware and adjust the random bytes to arrive at the same crc. Then the attacker can simply re-use the signature, since it will still be valid. Or am I missing something?
-
@mfalkvidd how can an attacker reuse a signature? Nonce used is discarded when a message is signed/verified. If the crc is sent last and based on a unpredictable blob, crc is also unpredictable and only the true source can put a valid signature on a crc that will unlikely be the same two times in a row. On top of that, throw in some AES encryption and I'd say the attacker would be better off with doing a smash & grab on the node to do what he wants.
-
I agree. I guess what's confusing me is that you're talking about validating the conversation, while tekka is talking about validating the crc. Just validating the crc will be insufficient, but that's not what you're talking about.
@mfalkvidd well, that is what I'm talking about. My point being, that you can't forge a valid signature. So you can't record a signed message of a crc, make your own firmware that happens to result in the same crc, transmit that, and then send the same signed crc. The receiver won't accept it since a new nonce is used every time. And the PSK is needed to calculate a new signature with a new nonce.
-
Agreed.
Will adding a random number to each FW packet (as suggested by tekka) add any security? A single nonce somewhere in the conversation should be sufficient I think. Adding random bytes to each packet would add complexity but not security, as the protection would come from the nonce anyway, right?
