Secured uboot image
-
@nsmith said in Secured uboot image:
So there is no way to prevent the code (either the one in the flash, or the one running in memory) from getting read out and recreated?
No.
I completely agree with @crispyoz that all security is relative!
But I‘d like to point out that reading out the flash in a SoC designed like the MT7688 (as a cost effective network router chip) is particularily easy. It does not even require unsoldering or opening the Omega. You might need to cut a single track on the PCB and contact a few SPI pins, then you can access the flash contents with anything that can speak SPI, like another Omega or Raspberry or CH431A ultra-cheap SPI programmer…
-
@luz Is this the case if there is no additional external flash i.e. just the flash integrated with the Omega device itself?
-
@huntc This is an image of an Omega2S+ with the lid taken off, you can clearly see the flash chip so it's not hard to access..
-
@huntc said in Secured uboot image:
@luz Is this the case if there is no additional external flash i.e. just the flash integrated with the Omega device itself?
Yes. The pins needed to access the internal flash are exposed (the SPI pins of the Omega), as is the VDD of the flash chip, so it can be accessed easily. Which is, for non-backbox applications, mostly an advantage. It allows for efficient factory flashing and debricking even of the bootloader.
I'd be genuinely interested in understanding the background of wanting to prevent reading out firmware in the first place.
Does it contain real secrets such as key material? Hopefully not. Or is it just not disclosing some algorithms? For both I cannot imagine an attacker for whom that kind of low level information is valuable/useful but who would not be capable of surmounting any protection short of a completely secured (iPhone-style) platform...
-
@crispyoz Thanks. This makes things clear.
-
I'd be genuinely interested in understanding the background of wanting to prevent reading out firmware in the first place.
I now realise that the Omega family of chips is not positioned as being secure, but I do need to demonstrate that I can do all that is reasonable to make hacking difficult. We've gone to great lengths to ensure that our software services are secure. At the end of the day though, while we can't do a great deal to protect against physical access, there is information that we need to protect reasonably. Having uboot provide an easy way to gain access to the file system via the console seems avoidable, so we should attend to that. Again, having Onion support this style of bootloader would be great as I imagine most commercial deployments involving the Omega family would/should want it. However, building one's own flavour of the bootloader is arduous unless you're familiar with the process.
If an attacker gains physical access via hardware and is determined by taking the cover off the Omega chip and connecting to its flash over SPI, I'm not sure there's much that can be done to prevent that given the MT7688 architecture. That is, other than potting a board hosting the Omega in resin or similar (including its console pins).
-
@huntc I know this is an old topic but I am not looking for secure u-boot options for the Onion. Were you able since then to compile a u-boot image with your desired specifications? I do see from the rest of the conversations that it may not be muhc improvement on the current architecure of the Onion but still thought it may be worth a shot to ask
-
@baby-Onioneer Since the Omega2 devices utilise OpenWrt and u-boot, the question really is for the OpenWrt team. I watch the OpenWrt developer lists and there has been a lot of discussion on this topic over the years and they seem to always come back to the same point. If you need to rescue a device you need to be able to access the console for safe mode or reflashing using the u-boot tools. Once you're in safe mode it is possible to mount the overlay file system. Locking that down would hinder recovery.
Even if you locked down the console, anyone who gains physical access doesn't even need the console, you can simply remove the cover and access the flash directly. So now you have to look at an encrypted file system, but that presents range of issues.
The approach I take is to not keep any sensitive data on the device for any period of time. I also use some logic to determine if the device has been tampered with, or too many failed logins. If any of these checks fail then any sensitive data or configurations will be purged. I have an override mechanism for this process. None of this prevents a determined user from access the flash directly and perhaps getting some sensitive stuff, but in my experience hackers try a few other things before resorting to wiring up the flash and by that time anything sensitive has been purged.
-
@crispyoz I understand. My hope is to be able to install some sort of secure boot on top of the current one and hoping that will be good for now until I figure something else. Thanks for your reply I will take it into account
-
@Lazar-Demin Maybe I have been looking in the wrong places but how big of bootloader binaries can the Omega2S+ handle? Or maybe it is the same?
