Open lbdroid opened 5 years ago
Do you guys have an update on this?
no ETA
What would it take to implement secure DFU into this library? upgrade sdk?
a complete rewrite
According to this comment; https://github.com/adafruit/Adafruit_nRF52_Arduino/issues/218#issuecomment-479990008
The issue of somebody randomly taking over your device via unsecured DFU mode has at least been mitigated. DFU mode is not enabled unless you explicitly enable it.
In other words, while DFU mode is still not implemented securely, at least you have to tell it to switch to that mode before it is possible to rewrite the firmware using it.
So if you need to implement DFU updates, you could arrange it so that you need to send it a secure command to switch DFU mode on, then use DFU mode, and reboot to resume DFU-disabled mode.
Edit: See this commit; https://github.com/adafruit/Adafruit_nRF52_Arduino/commit/865ac99c7feac0298ee3c5d842eb537904ab10ae
Hi, sorry for necromancing this.
We have been investigating this issue increasingly and found that WebBluetooth explicitly blocks Nordic's update service, making it impossible to do via WebBluetooth (see https://github.com/WebBluetoothCG/registries/blob/master/gatt_blocklist.txt ).
Is there an ETA by now (since it seems to be on the roadmap) or maybe even work in progress-branch we could support in for this bootloader to do the Nordic Secure OTA DFU? It would be greatly appreciated also if you clearly state that this is planned or not.
Hi,
I am also interested in this feature because of the WebBluetooth blocklist. @CSC-Sendance in the meantime, a good alternative is to use a different UUID for the DFU service.
Cheers.
On instructions https://github.com/adafruit/Adafruit_nRF52_Arduino/issues/218#issuecomment-455039283, I'm re-posting this issue against what is apparently a more appropriate repository.
Looking through the literature on these as carefully as I can, I've come across reference to a mode referred to as "OTA DFU", which can apparently be triggered by Nordic's nRF Toolbox application, allowing the storage memory to be rewritten over an unsecured bluetooth connection.
I've also seen indication that there is absolutely no security on this functionality at all: #162 (comment)
What I need to be able to do is disable this mode altogether, or in the very least, be able to program it with an update key that I (and only I) am in control of. This "feature" otherwise presents a security hole that makes it completely unsuitable for any application that has even fringe security related implications.