We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

Secured uboot image



  • @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..O2SP_Topless.JPG



  • @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.



  • @luz

    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).


Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.