Why Firmware Is So Vulnerable to Hacking, and What Can Be Done About It
wired.com
wired.com
One way around this might be to have the device accept two keys – a manufacturer key that is common to every device, and then a user key that is unique to the individual device and whose private key is provided to the user. This would add to cost and complexity, though.
Alternatively, provide some physical means (a jumper, e.g.) by which firmware verification can be temporarily disabled. The downside of this option is that you can't do automated firmware upgrades any more, which makes it more likely you have vulnerable devices in the field for long periods of time.
There seems to be a fundamental tension between allowing users control and keeping them safe, which Alex Stamos recently termed "security paternalism". We see this come up in walled garden app stores vs. allowing users to install anything they want, in making SSL problems "warnings" vs "errors", and so on.
I think it would be an amazing advance in computer security research if we could find a way to provide both at once.
I am not so convinced about the necessity of periodic updates; firmware is, by definition supposed to change far less often than software; it's firm, not soft. For example, motherboard BIOSes were basically almost never updated until manufacturers started using flash instead of EPROMs, and bugs were relatively rare. The assumption that "it can be updated later" has decreased the motivation to get it right the first time.
The case is less strong for things like hard drives, but even there, I think we see growing firmware complexity and a corresponding increase in buggy code (I suspect this is is caused by both economic incentives and the mere fact that lines of code are proportional to number of bugs). My Crucial M4 SSD was recently affected by an integer overflow bug [1] that caused the firmware to hang when it got to ~5000 hours of use, and these sorts of firmware glitches are not uncommon.
In any case, I think the question of whether it needs to be a physical switch or cryptographic signing is one that should probably be addressed on a case by case basis: internet connected devices really should have a way to update firmware without physical intervention, but on other devices it's probably not so critical.
[1] http://forum.crucial.com/t5/Crucial-SSDs/BSOD-Crucial-M4/td-...
1. Drivers for wifi & ethernet ports, and other hardware needed for the device.
2. TCP stack and routing mechanisms for forwarding packets between the two.
3. Access control for wifi portion, which (depending on how much flexibility is needed) may involve keeping track of individual user accounts and permissions.
4. Some way to administer this complexity. Currently the only thing that seems to fly with users is a web administration interface.
5. All the "usual" OS stuff to manage this: process scheduler, filesystem layer, memory management, etc.
Sure, you could design a special purpose OS that's simpler than Linux, but the development effort required would be much higher, and it's not clear to me that you'd end up with something much more bug-free.
All these are symptoms of lazy designers/managers essentially saying "fuck it, just throw a micro in there and do it in software".
A router doesn't need to be a full-stack linux system waiting to get pwned.
A memory stick doesn't need to have a full computer embedded in there waiting to be exploited by BadUSB.
Just like the private keys in our SIM card, eh? https://firstlook.org/theintercept/2015/02/19/great-sim-heis...
That plan doesn't remove the threat, it just moves it: to the privacy of the private key.