5 ms·
Call me old fashioned but I'd prefer to just make it impossible to write the firmware without physical access. Verification just brings it's own issues and is
by foxfluff 5y ago
Call me old fashioned but I'd prefer to just make it impossible to write the firmware without physical access. Verification just brings it's own issues and is not a panacea.
Who owns the key(s)? If not you, how do you trust them? If you, how do you write them? How do you prevent attacker from writing them? Or is it one-time programmable and your hardware becomes brick / unresellable / un-updateable if you lose your keys or don't want to pass them on to next owner? How do you make sure your keys are more secure than the machine that somehow got its firmware infected? What if the code that checks your signature turns out to have a bug? Are you stuck with it, or can you update the code? What if an attacker can infect that code..?
Making this all convenient and safe is very hard and in practice either takes freedoms from you (you must trust your vendor and their signed binaries), or gives a potential attacker the same freedoms that you get. Giving you full access without enabling an attacker to have the same access is quite impractical (read: unlikely to ever happen for consumer hardware that you can order over the internet), and you still have to trust the hardware is what it claims to be when you get your hands on it.
In practice, I can't audit the hardware but I'd be pretty good if I could flash it myself once it's in my hands.
- foobiekr 5y agoPhysical access just means that evil maid attacks go back to being interesting. You need both.
- Moru 5y agoAnd here is was thinking we had all this solved already, a jumper on the mother board that has to be shorted to update the bios. But I'm too old to understand why that isn't good enough I guess :-)
- eternityforest 5y agoI'd be annoyed if I had to open a machine. Then again, I don't think I've ever updated a BIOS in the first place. Enabling it in a machine-controlled menu that can't be navigated except by the physical keys might be better
- iso1210 5y agoCan you sell your idea as a software-as-a-service platform that can rapidly expand to a $1m/month revenue stream?
- ArnoVW 5y agoThat works great for you and me. But the average person (or even the average IT dept) does not want to open their machine to update the BIOS. Essentially your proposition comes down to 'no BIOS updates. And that has it's own problems, from a security pov and from a manufacturing recall pov.
- cheese_van 5y ago>But the average person (or even the average IT dept) does not want to open their machine to update the BIOS. I happily updated BIOS until I experienced a catastrophic failure that bricked the board, don't know how. Since then I'm terrified of updating BIOS. I've also experienced UEFI conflicts(?) loading linux to new boards that took forever to sort out. It seems BIOS development has not progressed as well or far as one might expect, but that may just be me and my klutzy bad luck.
- cesarb 5y ago> I happily updated BIOS until I experienced a catastrophic failure that bricked the board, don't know how. Since then I'm terrified of updating BIOS. My experience with BIOS updates has been mixed. The first time I did a BIOS update, it added an option to tell it that the HDD connection had 80 wires instead of 40 wires, which enabled a faster transfer mode. The second time I did a BIOS update (on that same machine), however, it made the realtime clock lose touch with reality, apparently running twice as fast, so I had to revert this update. That put me off from doing BIOS updates for a while. My latest laptop can be updated through LVFS (using UEFI capsule updates), and it's new and under warranty, so I decided to risk it. One of the first BIOS updates I did made, according to its release notes, an important-looking change to the battery management. Some time later, the laptop started crashing randomly (the crashes happened when the display turned off, but not every time). After a lot of searching, I found out that a later BIOS update made some unknown change which causes these crashes, unless you add "i915.enable_dc=0" to the kernel command line. For now, I'll keep risking it (at least while it's still under warranty), and hope no other obscure BIOS-update-caused bugs happen (and I'll probably keep using "i915.enable_dc=0" on this laptop forever, since there's no way to know whether a later BIOS fixed it).