Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
6 years, 6 months ago.
FOTA for private LoRaWAN
@janjongboom Jan, Thanks for the posts on your work with OTA firmware updates, it's really cool. I'm still working through what you've written, and could use some clarification on a couple items.
1) In the states, we're still using mostly private LoRaWAN deployments (combination of private MultiTech Conduit and mDot/xDots edge devices). We rely on unique DevEUI & AppKeys pairs to secure device communication. We're relying on this to ensure a) that the device is joining the our gateway, and not someone else's gateway b) the gateway is letting join our LoRa end points, not someone else's end points
My understanding is that public LoRa deployments utilize the same mechanism for security. It seems like signing the firmware (per the method you've detailed) is an additional security measure above and beyond the trust level established by LoRaWAN transport layer. Is there some aspect of public LoRaWAN networks that makes this more necessarily than private LoRaWAN deployments? Or is it your assumption that firmware updates need a more robust level of security than the typical telemetry data that traverses the network, regardless of public vs. private deployments.
2) I'm very interested in implementing the Delta Updates feature to reduce update times. In your example system, you have the M3 on the xDot and a separate NXP M4 application microcontroller. Was there a need for the NXP micro specifically? Would delta updates work if we're using the xDot as the application micro? Assuming we have a bootloader and some external SPI flash?
Question relating to:
1 Answer
6 years, 6 months ago.
Hi Eric,
Quote:
My understanding is that public LoRa deployments utilize the same mechanism for security. It seems like signing the firmware (per the method you've detailed) is an additional security measure above and beyond the trust level established by LoRaWAN transport layer. Is there some aspect of public LoRaWAN networks that makes this more necessarily than private LoRaWAN deployments? Or is it your assumption that firmware updates need a more robust level of security than the typical telemetry data that traverses the network, regardless of public vs. private deployments.
Firmware update security is a very big attack vector, and thus transport level security is not good enough. Without firmware signing someone can pwn all your devices if they gain access to your private network server.
A more complete answer is here.
Quote:
2) I'm very interested in implementing the Delta Updates feature to reduce update times. In your example system, you have the M3 on the xDot and a separate NXP M4 application microcontroller. Was there a need for the NXP micro specifically? Would delta updates work if we're using the xDot as the application micro? Assuming we have a bootloader and some external SPI flash?
Yeah, the original setup was dual-MCU setup, because we already had an update client running on the NXP micro. In the last months I've ported the update client to just the xDot. So in the new setup you only need an xDot (or other micro with at least 32K of RAM) + SPI flash. Delta updates are also implemented there. See binary-diff-mbedos5.