Experts Propose Standard For IoT Firmware Updates (bleepingcomputer.com) 61
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.
frosty MAB psot (Score:2)
Slight flaw: even if this costs 0.00000001 cents per device that's 0.00000001 cents too much.
Re: frosty MAB psot (Score:1)
As usual, your post isn't correct. While the value placed on security is very low, definitely far too low, it isn't zero as your post suggests. There has to be some consideration of the risk of fines or a lawsuit because of improper security on IoT devices. If the risk is deemed low, the value placed on security will also be disproportionately low, but it is nonzero. When the lack of security results in substantial fines and/or forced recalls that significantly cut into a business's profits, the value place
Re: (Score:2)
Whatever. At least it's not pure fantasy...
Re: (Score:1)
Following industry standard security procedures probably shields the vendor from a lot of liability both from consumers claiming the devices are defective and from others harmed by DDoS attacks from IoT botnets. Following these standards reduces the risk, and if the risk is substantial enough, there will be plenty of incentive to implement them. Establishing regulatory standards for what constitutes a defective device and implementing procedures for handling such defects raises the risk for companies that d
Re: (Score:2)
"Establishing regulatory standards" is the single point of failure.
I won't say that it can't happen. After all, new cars come with seatbelts now.
Re: (Score:1)
As usual, your post isn't correct. While the value placed on security is very low, definitely far too low, it isn't zero as your post suggests. There has to be some consideration of the risk of fines or a lawsuit because of improper security on IoT devices. If the risk is deemed low, the value placed on security will also be disproportionately low, but it is nonzero. When the lack of security results in substantial fines and/or forced recalls that significantly cut into a business's profits, the value placed on security will rise.
Mind citing for me all those lawsuits and fines that have been against IoT manufacturers due to shitty security practices?
Yeah, I thought so. Shitty security isn't something that was invented with IoT. As indicated in TFA, security experts have been recommending these practices for years. And for years they've been ignored because of the sheer lack of impact.
I'd suggest a law that seems any device with a security hole discovered within five years from the initial release is defective and must either be fixed (such as with a software patch) or recalled with a full refund of the purchase price to the customer.
95% of consumer electronics these days has a 1-year warranty. You expect to mandate a manufacturer's give-a-shit level beyond that? Talk about fuc
Re: (Score:2)
And that's the problem with this proposal. IoT doesn't get updated because of a lack of standards for doing so (there's been firmware-update standards around for a lot longer than IoT, e.g. this one [ietf.org]), but because the vendors don't care about it, or the device can't be updated. Proposing a standard isn't going to change this.
In any case this isn't a standard, it's a bunch of ruminations jotted down on paper. To be a standard, it has to be at least 100 pages long, include XML, HTTP, TCP, and LDAP, and requ
Re: (Score:2)
Now, name any case where a crappy IOT device faced a fine or forced recall for any reason.
Too many words, too (Score:2)
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!
Ironically this is why I buy Apple products (Score:2)
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 diff
Lock-in (Score:3)
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.
Re: Lock-in (Score:1)
It seems like there ought to be a second key paid unique to each device and the private key is distributed to the end-user when the device is sold. That key allows the user to sign custom firmware. Upon doing so, the user assumes all liability for damage caused to others by the custom firmware (if it's vulnerable and is exploited to harm others) and the warranty won't cover damage to the device caused by using such firmware but otherwise remains in effect.
Re: (Score:2)
If the device private key is distributed in electronic form the the user then a trojan could scour their computer looking for it. I'd prefer a physical mechanism as that prevents remote manipulation. A sticker on the device with the private key would work. A dip switch or similar inside the device would work too.
Unfortunately.. (Score:2)
That would be frowned upon as it would be opening things up for supply chain attacks.
Re: (Score:1)
Re: (Score:1)
That switch costs money. Besides manufacturers do not like people with will.
Re: (Score:2)
Well, they've got "public key cryptography" and also "broadcast" so this is just another libdvdcss situation and the encryption is meaningless.
Re: (Score:2)
I work on IoT, and don't want this faux standard solution. There's going to be a fight though; the standards fans who insist we adopt this instantly so that they can add another buzzword to the marketing literature, and the implementors who will point out that it won't fit, will use up too much battery life, and so forth. It's one thing to have security guidelines that everyone should follow, but making this a standard that applies equally to 8-bit sensors all the way up to 64 bit phones is pointless.
Most
How about a standard for IoT security (Score:5, Insightful)
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!
Re: (Score:2)
Not sure how putting stickers on them will help.
Re: (Score:2)
Well, you may only put the sticker on if your system complies with its requirements.
You may only sell your gadget if it has the sticker.
See how it would help?
Re:How about a standard for IoT security (Score:5, Informative)
Except you have completely misread that FCC notice. The notice puts zero requirements or liability on the manufacturer of the device, it is about the requirements and limitations on the USE of the device. 'Must accept interference' does not mean 'can handle interference', it means that if the device does not work because of interference, you have no legal recourse. 'Must not cause harmful interference' means that if the device is interfering with a licensed service, even if the device is operating perfectly, you must stop using it. If you continue using it, YOU, not the manufacturer, will be fined.
So a similar thing thing on the Internet would be: this gadget may malfunction if it receives bad data. If it does, too bad. If this device is sending out harmful packets you must stop using it. If you don't, you will be fined.
Re: (Score:1)
The notice puts zero requirements or liability on the manufacturer of the device, it is about the requirements and limitations on the USE of the device.
Then fine anyone who buys and uses these devices. The resulting bad press should have at least some effect on the sales.
Re: (Score:2)
Works for me too, might make people think twice before buying crappy IoT junk if they suddenly get to pay for putting a bank out of business for a few days.
Re: (Score:2)
Hackers don't.
Companies trying to do business do.
People potentially liable for operating faulty devices do.
Re: (Score:2)
You can't do that? Then stop putting an internet connection on your fucking toaster and you're fine!
Stop telling your Internet connected toaster the IP of your gateway router. Problem solved.
Re: (Score:2)
You mean the gateway router that the ISP configured with a DHCP-Server that you do not have the password to so you could reconfigure it (provided you know how to, anyway)? That gateway router?
Re: (Score:2)
Except for the obvious problem: The lease secure devices are those pieces of Chinese shit that make it across the border yet can't even draw the FCC or CE logos correctly much less actually have proper certification.
This is before you actually realise that the liability on Part 15 lies 100% with the user and not at all with the manufacturer.
Common Sense, isn't common. (Score:2)
"...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.
Not the problem (Score:1)
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 s
More productive.. (Score:2)
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 pi
Re: (Score:2)
Egress control should have become a core feature of residential and small office firewall/router units back during the massive worm days, but it never did.
Why am I letting random_device_03 make unlimited, unfiltered, unmanaged outgoing connections in the first place? Well, I'm not. But why does my neighbor's plug-and-play router do that?
Re: (Score:1)
Because they need to "just work" for non-technical folks which are 99% of their customers.
Cryptographic signing? (Score:1)
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.
Missing requirement (Score:2)
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).