Over the air (OTA) bootloading update tutorial?
-
-
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? -
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? -
Nonce provide security for a single message. The signed message is secure in the sense that it is authenticated. This means that the signed message could only be made from a trusted sender. Securing OTA is therefore a matter of crafting a solution where the signed messages cover data that is a function of the OTA firmware. Preferably a function which is difficult to reverse-engineer (like a cryptographic hash function). So, if there is a signed message with some form of checksum of the firmware that is enough to guarantee authenticity of the firmware. In this case, assuming the signing paradigm is ideally secure, the signature is good enough but the security will always be limited to the strength of the checksum. Injecting signed messages in the OTA flow at some intervals to continuously "monitor" the procedure could also help increasing the security.
-
and yes, I agree with @tekka, in that making an "unpredictable" crc and signing that crc would make it really hard for an attacker to temporarily block the senders firmware and inject a bad firmware and then let through the senders signed crc since the attacker would not know in "runtime" what the crc will be. Especially if the last random bit is provided in the signed crc message. That makes a secure chain where the last link is signed, and unpredictable.
