Over the air (OTA) bootloading update tutorial?
-
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.
-
It is still a good idea to validate that the received firmware is not corrupted in "any" way during transfer before it is accepted and booted. CRC offer a reasonable validation in this sense.
-
I agree that it is a good idea to try to detect unintentional errors when transmitting the firmware. That doesn't mean the CRC should be signed.
Signing the CRC might fool someone that the CRC can be trusted, leading to unnecessary mistakes in the future. Sending the CRC unsigned makes it clear that the CRC can only be used to detect unintentional errors.
-
Let's agree to disagree ;) anyway, the OTA security for 2.0.0 is currently under discussion and it might well be that we go for sha256 checksumming. That remains to be seen.
-
It's been decided that we do go for sha256. It will be hashed by the controller and the receiver will calculate the hash of the received payload. The controller will then send the calculated hash of the true firmware in a separate message (that will be signed if enabled) or possibly several (if we want to use the full 32 byte hash in the verification which we probably want). @tekka and me will communicate on the matter and security related activities can be tracked on the GitHub issue list.
-
@mfalkvidd thanks for challenging OTA security. Although I maintain that crc with signature is safe, we never picked up the topic of repeaters where the ability to inject bad stuff is a very real scenario. But sha256 will put a definite end to any questions about OTA FW authentication. (together with signing, because the hash means nothing if it is not trusted)
-
Can I use i2c EEPROM for OTA bootloading with DualOptiboot or it has to be Serial SPI. I was not able to find any documentation on it. I brought a breakout board and it seems to be i2c, and i2c chips are easily available where I live.
-
Can I use i2c EEPROM for OTA bootloading with DualOptiboot or it has to be Serial SPI. I was not able to find any documentation on it. I brought a breakout board and it seems to be i2c, and i2c chips are easily available where I live.
Request, if some one help me with this question. Thanks
-
Dualoptiboot use spi protocol for eeprom. So you can't. you would have to rewrite the code to use i2c protocol.
I don't know if there are cheap spi alternative and I have not looked at ali, I buy mine at mouser. -
@scalz Thanks buddy :thumbsup: . Probably I would have to keep hunting for SPI EEPROMs iguess.:sweat:
@Suresh-Mali I have the same problem. Only I2C IC is available in my country :(
Looks like we have to hack the code. I will inform you when I reach this phase in my project.
