Over the air (OTA) bootloading update tutorial?
-
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)
-
Well, I agree that crc can be spoofed. So I follow you on that. But I don't agree that sending a signed message to conclude the OTA session with a crc that needs to match previously sent firmware can be hijacked. This because transmissions are driven by the sender, also for signed messages, and signed messages cannot be delayed. We gave timers in place to detect that. So an attacker cannot delay the final signed message in order to prepare a different firmware that matches the crc. The sender will not wait with sending the final crc. And each firmware blob will contain a random part to scramble crc so a previous OTA session can not be used for reference.
This would in my opinion secure OTA. But it is worth stressing that this is not how OTA works today, and hence my big disclaimer on my signing post on OTA. Tekka is working on this and might be able to provide you the documentation you seek. For signing, I refer to my post on that (and the doxygen link if you want to look at the bleeding edge development branch). -
I think there are some missing information here and I will provide some further detail to answer some of the open questions regarding the OTA process in 2.0.0.
As for the CRC: the CRC used in the OTA update process is a function of the transmitted firmware AND a random element (added by the controller). In the final "validation" message, which is signed of course, the CRC and the last random element is transmitted and the node validates it to authorize the newly transmitted FW.
Due to the random element present in the validation message, the final CRC cannot be predicted before it is actually send and not be forged due to the signature. -
I think there are some missing information here and I will provide some further detail to answer some of the open questions regarding the OTA process in 2.0.0.
As for the CRC: the CRC used in the OTA update process is a function of the transmitted firmware AND a random element (added by the controller). In the final "validation" message, which is signed of course, the CRC and the last random element is transmitted and the node validates it to authorize the newly transmitted FW.
Due to the random element present in the validation message, the final CRC cannot be predicted before it is actually send and not be forged due to the signature.@tekka said:
Due to the random element present in the validation message, the final CRC cannot be predicted before it is actually send and not be forged due to the signature.
That statement is incorrect. The crc is available to the attacker the instant the last byte of the firmware message is sent.
If the attacker blocks the original firmware messages and sends their own firmware instead, all that's required after the last byte of the original firmware message is sent is to send one more fake firmware message with 2 bytes.
If the signing timer is short enough to prevent a 2 byte message, the attacker will indeed be prevented from sending a fake firmware with the same crc as the original firmware. But is the timer really that short?
-
@tekka said:
Due to the random element present in the validation message, the final CRC cannot be predicted before it is actually send and not be forged due to the signature.
That statement is incorrect. The crc is available to the attacker the instant the last byte of the firmware message is sent.
If the attacker blocks the original firmware messages and sends their own firmware instead, all that's required after the last byte of the original firmware message is sent is to send one more fake firmware message with 2 bytes.
If the signing timer is short enough to prevent a 2 byte message, the attacker will indeed be prevented from sending a fake firmware with the same crc as the original firmware. But is the timer really that short?
@mfalkvidd I'm not sure I understand your point. The last random element necessary to compute the CRC is transmitted together with the CRC and that message is signed, hence the CRC is not predictable until it is send.
Please elaborate your scenario with the 2 byte message and how this results in a valid CRC.
-
I will provide a more elaborate explanation of the signing timer since my point is being missed. But I don't have the time right now so it will be later today. But in short, we have safeguards to ensure there is no way of delaying signing handshaking so if the signed crc is sent immediately after the FW, if anyone tried to delay that (and they would need to in order to inject a new FW) either the sender or receiver will detect this.
-
Alright. I now only talk about 2.0.0 OTA, just to be clear.
Sender will push OTA FW "unconditionally". That is, it will not use ACK handshaking, just duke out the packets and when done send the final signed crc.
In this scenario, an attacker wants to replace the FW with a custom FW that will result in a crc that "belong" to the signed crc. So the attacker listens in to the transmitted packets to determine how crc "evolves" but also has to prevent receiver from receiving these packets. When the signed crc arrives, the attacker needs to delay the reception og this message.
There are two options for delaying a signed message.- Delay reception of nonce request.
- Delay reception of signed message.
For 1. As soon as sender transmits nonce request, it waits for the timer (5s) and if timed out, session terminates.
For 2. As soon as nonce leaves the receiver, it starts the timer, and if expired (5s) the nonce is purged from memory and session therefore terminates.
So, assuming no handshaking is done during firmware transfer, and attacker has to delay the signed message long enough to transfer the bad FW to the receiver before the signed message can be let through. And I don't think 5s is enough for flashing a custom firmware, and if it is, the delay is a public config variable which can be decreased as user see fit.
And again, it's important that the sender forces out the FW packets and the final signed message as fast as possible without hesitation to give an attacker minimum time for preparing mischief. I'm not sure how long a typical OTA session lasts, but the signing timer should be set to below that so no bad FW can be snuck in while a signing session is active.
-
Thanks for clarifying Anticimex.
What you are describing seems reasonable, as long as the attacker is unable to send the fake firmware at the same time as the original firmware is sent by the controller. Sending at the same time (or with some milliseconds delay to allow for adaptation of the firmware to match the original crc) would give the attacker plenty of time to submit their firmware.
In a wired network, blocking original traffic while sending fake traffic is a valid attack scenario. Does such a scenario not apply to radio?
-
As both sender and receiver are on the same channel, blocking out the receiver from hearing the sender also means the receiver does not hear anything else, so from rf knowledge I have, it ought not be possible to jam a transmitter without also jamming a receiver in this case. Someone might perhaps correct me on this though, but I find it an unlikely care. Also, the jammer has to both jam the sender and at the same time listen in on the sender to determine the crc to fake and that ought also be a tricky problem.
-
ok. That means that my attack scenario 2 is invalid, which is fine. Thanks a lot for bearing with me.
If we are sure that the attacker is unable to send while the controller is transmitting, why do we bother with signing the CRC? We are saying that the attacker will be unable to transmit any firmware in the short time frame available during the signing. Why add the complexity of signing the CRC if it doesn't add to security?
Edit: I'm not arguing that we should skip the signed message, but we should keep the signed message as standard as a regular signed message and not extend it by including CRC.
