Over the air (OTA) bootloading update tutorial?
-
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.
-
Looks like I'll need to make some drawings to understand what is signed. Adding random bytes to the FW packets will not make the crc unpredictable, since the attacker can calcullate the real crc continuously and just needs to modify the last bytes to get the same crc.
I'll try to make some drawings of my impression of what you are saying when I get to a computer (probably tomorrow). From there you'll probably be able to tell me where I have gotten things wrong.
-
Alright. I've spent some time to draw my understanding of what Anticimex is suggesting, and described two attack scenarios.
I've probably misunderstood something along the way, so feel free to correct me if the method is wrong.Attack scenario 2 gives immense power to the attacker. I'm not sure if that is a realistic attack scenario, as Anticimex mentioned before it might be easier to do a smash and grab to get the physical sensor. I'm fine with that, if someone is able to argue that it is a scenario we don't want to protect from.
Text in purple is authenticated. Text in black is not.
I'm attaching the xml file from https://www.draw.io/ - feel free to correct if I have misunderstood something. (Or use whatever neat tool Anticimex used when describing the message signing process.)
MySensors OTA.xmlBase fact: A CRC is, by definition, redundant. That means that the CRC does not add any information to the conversation. The CRC can be computed on-the-fly by anyone. To get a selected CRC, an attacker can flip the corresponding bit(s) anywhere in the message (mod 16 bits).
Attack scenario 1: The attacker is able to read anything and send their own packets, but is unable to block or modify legitimate traffic.
In this case, the attacker is unable to create a valid signature since a new nonce will be generated by the node for every firmware update, and the life time of the nonce is limited (just as described by Anticimex in the signing thread. The only viable attack is for the attacker to ask the Node for new nonces repeatedly until a nonce is re-used.Attack scenario 2: The attacker is able to modify, block and inject traffic in an ongoing conversation.
In this case, if the above OTA method is used, the attacker can simply replace the firmware on-the-fly, calculate the CRC on-the-fly and replace the last two bytes (assuming a CRC16) to arrive at the original CRC. The signature created by the Controller will still be valid. -
I'm not sure I understand the illustration. It seem to suggest that a nonce exchange is performed first, then firmware is transferred and last a signature is verified.
But nonce exchange occurs behind the curtains as soon as a signed message is to be transmitted, so there is nothing sent in between a nonce exchange and the signed message the nonce belongs to.
I still maintain that a solution where a crc is calculated across the firmware blocks and finalized with a signed message where a random component is included in the signed message and the final resulting crc is also included and calculated with that random last part would be enough to guarantee the transmitted firmware authenticity as an attacker would not know what the final crc will be and can't tamper with the last part.
But I do welcome any attempt to attack the security so we can put this to the test. @tekka is working with the OTA solution for 2.0.0 where this scheme is supposed to be implemented. Perhaps you would like to volunteer to set up a attack environment so we can see if crc used in this way can be tricked and a bad firmware can be injected OTA?
I should mention that in theory, you could block the firmware transfer and on the fly generate a custom firmware that matches the crc up to the point where the final signed crc is sent, but the true sender won't wait it will send the final signed message immediately after the firmware, so there won't be a window for the bad firmware to reach the node and the signing backend has a timer. So if the receiver receives a nonce request and no signed message is received within a certain timeout, nonce is discarded and signing session is terminated.
So there is literally very limited time to perform all these operations to interdict the OTA session and still allow the real signed message to arrive without the receiver getting suspicious. And if the signed message does get through in the middle of some rogue FW transfer I suppose the node would reboot with a partially flashed firmware (@tekka might be able to confirm / deny this). -
The firmware require a lot of messages. And none of them are signed.
But nonce and signed message is exchanged immediately. I interpret your illustration as if nonce is exchange first, then firmware is transferred, and finally a signed message using the previous nonce is sent. This is not how signing works. -
From a signing perspective, yes. From current OTA perspective, probably (I'm not sure). From future OTA perspective, no (crc will be sent last and signed with a unknown beforehand component of the final crc)
