Slashdot Mirror
Experts Propose Standard For IoT Firmware Updates (bleepingcomputer.com)
An anonymous reader quotes a report from Bleeping Computer: Security experts have filed a proposal with the Internet Engineering Task Force (IETF) that defines a secure framework for delivering firmware updates to Internet of Things (IoT) devices. Filed on Monday by three ARM employees, their submission has entered the first phase of a three-stage process for becoming an official Internet standard. Titled "IoT Firmware Update Architecture," their proposal -- if approved -- puts forward a series of ground rules that device makers could implement when designing the firmware update mechanism for their future devices. The proposed rules are nothing out of the ordinary, and security experts have recommended and advocated for most of these measures for years. Some hardware vendors are most likely already compliant with the requirements included in this IETF draft. Nonetheless, the role of this proposal is to have the IETF put forward an official document that companies could use as a baseline when designing the architecture of future products. This document could also serve as a general guideline for lawmakers who could draft regulations forcing manufacturers to adhere to this baseline. Some of the main requirements put forward by three ARM engineers in their IETF draft include: The update mechanism must work the same even if the firmware binary is delivered via Bluetooth, WiFi, UART, USB, or other mediums; The update mechanism must work in a broadcast type of delivery, allowing updates to reach multiple users at once; End-to-end security (public key cryptography) must be used to verify and validate firmware images.
Slight flaw: even if this costs 0.00000001 cents per device that's 0.00000001 cents too much.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
End-to-end security (public key cryptography) must be used to verify and validate firmware images.
Sounds good to prevent bootloader trojans etc. But it does mean you cannot tinker with the device yourself unless the vendor allows the mechanism to be bypassed. And what happens if the vendor goes out of business - then noone can create new firmware?
Overall, I think it is a reasonable measure to prevent massive botnets running on all kinds of devices, but I do hope there is a physical bypass of the verification.
I'm thinking of something akin to the FCC Title 47 CFR Part 15. You know, the "this gadget can handle interference and doesn't broadcast interference" sticker you find on every piece of equipment sold in the US. By law, these things have to comply to this.
How about a "this gadget can handle malformed and malicious signals from the internet and does not broadcast any" sticker? And noncompliance gets you slapped with a fine from here to Albuquerque.
You can't do that? Then stop putting an internet connection on your fucking toaster and you're fine!
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
IoT is completely useless, and while a few people will buy this (they'll buy anything), sales will be "disappointing" while the damage to the internet immense.
As a society, we should just call the whole thing off.
"...security experts have recommended and advocated for most of these measures for years."
This tends to highlight the chances of security experts being heard this time around.
I've come to the conclusion that manufacturers like burning themselves on the proverbial stove over and over again. It's reached a level of ignorance that is beyond reproach. Watch and see how proposed standards will be ignored due to a potential impact on profits. Greed is all that matters.
Some hardware vendors are most likely already compliant ...
The problem isn't an inability to upgrade the hardware; it is:
1) Inadequate security built into the device
2) Refusal to provide updates.
Both of these problems extend from portable/IoT devices using a monolithic system. If plug-gable modules were used for middle-ware, anybody could write an update for all devices using that CPU. The OEM only has to convert that into an encrypted update, which is a lot less responsibility and means devices can be maintained for 6-10 years. Such a methodology has it's own security issues but they aren't complex. It's just no-one wants to develop a standard, even with a first-mover advantage: It's not the vendor who will be attacked because of poor device security.
Shoddy practices will continue as long as customers and service providers devalue security. It's necessary to win their 'hearts and minds', then vendors will be forced to follow.
They will privately regulate your things from ex-your computer through Internet, dear ex-user.
The remote cryptography is for lock/unlock the life that you can do to this signed genuine computer.
So, don't waste your $$$ from this crap.
That would be frowned upon as it would be opening things up for supply chain attacks.
XML is like violence. If it doesn't solve the problem, use more.
Standard to identify devices and their vendors and automatically filter network access depending on vendor and vitality of vendor. If a vendor of your IoT device goes away, then no longer allow the device to reach out to the non-existant servers. If vendor is still around, limit connectivity based on addresses that would be relevant to said vendor.
This is of course a terrible sort of thing, but the IoT devices and vendors are themselves already terrible and limited, so in that context, it's a matter of picking the lesser of the evils, and these devices security problems can ruin the experience of everyone, not just those who opt into the silly things.
XML is like violence. If it doesn't solve the problem, use more.
As part of the IOT Botnet Operators' Guild, I'd like to point out that The Right To Tinker means that all keys for signing firmware should be made available to all users.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Hackers do not care about certifications.
Reality does not care about certifications.
as getting timely Android updates for non-Google branded phones. Great to have a standard, but the cheap bastards aren't going to use it.
For years I would only buy Apple Wifi Hubs (air ports). THe rationale was simple: there was a built in mechanism to update the firmware. Your Mac computer would detect the firmware update was available and let you know. then you okayed the download and provisioning. While I might have paid $40 extra got get the airport over a cheaper alternative without that, I knew I was getting a great service and peace of mind. It also meant i didn't have to learn any new archane processes for monitoring every different router or worry the company would stop supplying updates for the "cheap" router I bought. Indeed you can never even tell if a cheap router is even upgradable.
Thus like the XKCD cartoon points out trying to unify standards is a temporary bussiness. But conversely it's a bussiness opportunity for companies that do provide peace of mind.
Some drink at the fountain of knowledge. Others just gargle.
that user settings should be preserved across an update. It can be frustrating when user choices are reset to default and allow the vendor access to things that you had closed off (Microsoft - I am looking at you).
I was already weary of this until I got to:
"This document could also serve as a general guideline for lawmakers who could draft regulations forcing manufacturers to adhere to this baseline."
Now I think we've gone past the maybe to it's a terrible idea. If this is where we are headed I don't want to take part. If users don't want to partake in purchasing crappy products stop buying crappy products. I don't use many many products/companies: Facebook anything, Microsoft anything, Apple anything, Google almost anything (except for search, when I'm desperate), Twitter, most "smart" devices (no smart TV here, but sadly I do have a "smart" phone, though did get away with a dumb phone for a long time, open source OS is the only selling point and crypto currencies), IoT devices, and plenty of other services/devices/operating systems/software/services/etc.
I also avoid using the US dollar (it's easier to do in New Hampshire because crypto currencies have taken off here, more than a few dozen local businesses take it in my little town of just 25,000 people, ie Keene, NH), taking part in government except where I'm involved in dismantling it, etc.
Slight flaw: even if this costs 0.00000001 cents per device that's 0.00000001 cents too much.
The proposed RFC tries to solve far too many problems at once, and is about as elegant as a bowl of spagetti. We don't like that in code any more, much less as a requirements statement
Too many words, take some out!
davecb@spamcop.net