Secured uboot image
-
Hello,
Were you able to solve this problem? im pretty sure im going to need this too since we probably dont want random people reading out the code from the flash.
Thanks
-
-
@huntc @crispyoz the uboot flashed on Omega2 devices in the factory is based on this repo: https://github.com/OnionIoT/omega2-bootloader
The new OnionIoT/u-boot repo is an experiment!
With regards to @huntc's original question, there's two options to prevent flash access through the bootloader:
- Modify the bootloader (OnionIoT/omega2-bootloader) to disable console output alltogether. This should be doable but I'm not sure where/how
- Modify the bootloader to disable the firmware flashing options. See lib_mips/board.c line 2066 for the bootloader menu, and config.mk for the defines that control what options are compiled in.
Just make sure your bootloader binaries are 192kB or less - as that's the size of the bootloader partition on the Omega2 devices.
-
Thanks for the replies here. I was away of course.
While I could modify the bootloader, I suppose I was hopeful that Onion might be interested in supporting one along the lines of the current one. Perhaps a distribution along the lines of what is recommended here: https://www.timesys.com/security/securing-u-boot-a-guide-to-mitigating-common-attack-vectors/.
I'm of course very happy to help and contribute, but again, I'd like to see Onion support a secured bootloader if possible.
-
While I understand the goal, I don't see how securing an MT7688 based system, which has no anchor for the needed chain of trust, could work at all.
For an attacker who has physical access to the device, reflashing or reading out the SPI chip directly is about as hard or easy as getting access to the uboot console. So just removing flash access commands from uboot does not help much, IMHO...
To protect against attackers without physical access, it is sufficient to have an update mechanism which checks signatures, like yours probably already does.
Am I missing something?
-
@luz I do think that removing console access provides a slightly improved level of protection against the les technical "snoop". Even though I am not a hardware engineer, if I really wanted access, I'd just remove the flash and put it on another device.
-
@crispyoz ok, but who else but a at least moderately technically skilled snoop would want to get at a embedded device's firmware binary in the first place? Just wondering - without knowing what @huntc's threat model actually is and what type of secrets are to be proteced, it's hard to guess...
-
@luz I made my point badly, I was in agreement with you. I think huntc mentioned in a previous post he was using RUST so perhaps the plethora of decompilers is seen as a risk.
I'm a big believer is round pegs in round holes and square pegs in square holes. Omega2 was not designed to be a super secure platform. If my firmware has gold embedded in it, I'll hire a couple of pinketons or use a platform that supports TPM et al.
I miss the days of obfuscation competitions.
-
@crispyoz 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?
-
@nsmith As @luz was explaining, messing with u-boot is not really setting up a chain of trust, u-boot just bootstraps the device, once it's running then it accessies flash. If I desperately wanted to look at your firmware and u-boot was nobbled, I'd just open the lid, reflow the O2S and remove the flash chip then install it in a O2S that had an un-noblled u-boot.
A hardeware engineer would probably just breadboard the thing and access the flash that way.
As @luz said, it depends on what your security requirements are.
30 years ago I was engaged by an embassy to troubleshoot their core consular communications system. It was in a bullet proof glass enclosure and I was ony permitted to enter the room with 2 guards toting shotguns who stood so close to me I could smell their lunch. I assumed they would shoot me if I did anything that looked suspicious, but I wasn't sure they had the expertise to know if I was doing anythig suspicion.
The only client I ever "inappropriately" copied software from was a max security military installation that took 2 hours to pass through security to get in to do a 30 minutes job, then another hour to pass back out of security, where they checked every floppy dist I had on me. Fortunatley they didnt know what an optical disk was and had no way read it if they did know what it was. I could now be writing this from inside guantanamo
The point is that security is relative, you need to assess the risk, the skills of your adversary and the cost and effort of mitigation.
-
@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?
