Secure Boot Could Eliminate Botnets - But Manufacturers Ignore It

100% agree!

As you wrote secure boot is only one way to protect a camera.

I'm not sure but I don't think the latest attack could be prevented this way. The problem was that Mirai gained access to the cameras using default username and passwords.

I think the manufacturers think that first they need to solve the simple ways that malware get hold of a camera and only then handle the more sophisticated methods.

As all/most of the cameras use Linux as the camera OS it a little more difficult to create and maintain a secure boot but since there are already examples of how to do it out there I think its worth the effort.

More on secure boot and Linux can be found here: How Secure Boot Works on Windows 8 and 10, and What It Means for Linux

This would be a fantastic solution if implemented properly.  There are a few flaws in doing so in our current world though.  #1 - most of the OS's and applications are just being pirated and copied by so many manufacturers that they just don't know how to safely alter them.  This is why a list of 63 username/passwords were able to get into so many different devices, they were all using pretty much the same version of Busybox Linux that the manufacturers didn't know how to safely modify or just didn't want to.  #2 - "though sometimes for a slight additional cost compared to lower-end chips" this shoots it down immediately.  These companies are doing everything they can to save every penny, they refuse to do anything that will increase the cost at all.

We (the professionals that use IPVM as a great industry reference tool) would love these changes, but unfortunately the manufacturers care more about just getting every single penny and if it can be done with cheaper parts and insecure software then so be it.  They will suffer no consequences from these botnets other than an uncomfortable week or two of bad press and then it's back to normal.

I 100% agree with you on this.  Unfortunately most of the "security" industry these days just wants the cheapest and easiest products to slap into a home/small business so they can get their check and hopefully never hear from the customer again until they want to buy another $10 camera.  The true security professionals will try to guide customers and provide them with the best solution possible, but this costs more and in the current disposable, Walmart world we live in, the vast majority just wants cheap and quick which falls right into these manufacturers ball parks.  Sorry for the cynicism, hasn't been the best year in the industry as I'm sure most of you are also suffering with.

I could be wrong but I was under the impression this technology was only effective in preventing rootkit-level infection.

Rootkits run at the BIOS level and can hide their presence in some ways, which makes it easy for them to re-infect the target in case someone removes the malware or factory defaults the unit (which probably isn't deep enough to touch/clean the BIOS).

The vast majority of botnet clients do not require that level of infection, and I imagine it's very hard to accomplish a rootkit level infection on an IoT device without physical access. Unless of course the BIOS supports kicking off updates from the OS.

If I'm not wrong (I'm only feeling 50% here), then there would be little to no value in implementing secure boot with regard to the standard level of attacks out there including Mirai.

However, if I were sourcing equipment for a government or other high security project, I would prefer to use SOE-enabled devices as it would potentially protect against APT's or advanced persistent threats. I imagine nearly all APT's are carefully designed and implemented and are in a different classification from the "script kiddie" stuff usually seen.

If I'm wrong and the signature used by SOE is somehow based on the OS drive(s), such that any changes to key areas of the filesystem would invalidate the signature check, then this would be a beautiful way to lock down IoT devices. I think this would be fairly far-fetched though.

At the OS level, I'm sure linux has the same ability to deny running "unsigned" code considering Windows already does this to prevent unsigned device drivers from being installed. Linux probably had this feature first. It seems like configuring the linux to execute only code signed by a shortlist of keys would be the best bet.

If manufacturers were to do this, then the only ways to accomplish remote code execution would be to either steal the private key from the manufacturer so you can sign your infectious code, or to discover a flaw in the manufacturers proprietary software allowing for remote code execution directly through the manufacturers software/processes.

"why do manufacturers not enable it?" severely understates the effort that would be required for this. Signed bootloaders, kernels, and even kernel modules? Sure, that's already well-developed. But userspace? In Linux, at least, that's still a whole lot more than just something to be "enabled".

See: https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture

Sure it's clarified later with "The main costs of implementation come from additional development work needed to implement Secure Boot/SOE. This can require heavily modifying open-source code", and maybe I'm just being pedantic, but the opening just seems flippant.

Nitpicking aside, do there exist today any OSes that will run only signed code at every level? Genuinely curious.

Wasn't some of the security issues found recently down to people reverse engineering the firmware to find hard coded accounts and passwords. To what extent does secure code limit this? Would the user set admin account (which is forcibly set at first boot to a unique identifier)  be the encryption key for secure boot?