This weekly roundup thread is intended for all culture war posts. 'Culture war' is vaguely defined, but it basically means controversial issues that fall along set tribal lines. Arguments over culture war issues generate a lot of heat and little light, and few deeply entrenched people ever change their minds. This thread is for voicing opinions and analyzing the state of the discussion while trying to optimize for light over heat.
Optimistically, we think that engaging with people you disagree with is worth your time, and so is being nice! Pessimistically, there are many dynamics that can lead discussions on Culture War topics to become unproductive. There's a human tendency to divide along tribal lines, praising your ingroup and vilifying your outgroup - and if you think you find it easy to criticize your ingroup, then it may be that your outgroup is not who you think it is. Extremists with opposing positions can feed off each other, highlighting each other's worst points to justify their own angry rhetoric, which becomes in turn a new example of bad behavior for the other side to highlight.
We would like to avoid these negative dynamics. Accordingly, we ask that you do not use this thread for waging the Culture War. Examples of waging the Culture War:
-
Shaming.
-
Attempting to 'build consensus' or enforce ideological conformity.
-
Making sweeping generalizations to vilify a group you dislike.
-
Recruiting for a cause.
-
Posting links that could be summarized as 'Boo outgroup!' Basically, if your content is 'Can you believe what Those People did this week?' then you should either refrain from posting, or do some very patient work to contextualize and/or steel-man the relevant viewpoint.
In general, you should argue to understand, not to win. This thread is not territory to be claimed by one group or another; indeed, the aim is to have many different viewpoints represented here. Thus, we also ask that you follow some guidelines:
-
Speak plainly. Avoid sarcasm and mockery. When disagreeing with someone, state your objections explicitly.
-
Be as precise and charitable as you can. Don't paraphrase unflatteringly.
-
Don't imply that someone said something they did not say, even if you think it follows from what they said.
-
Write like everyone is reading and you want them to be included in the discussion.
On an ad hoc basis, the mods will try to compile a list of the best posts/comments from the previous week, posted in Quality Contribution threads and archived at /r/TheThread. You may nominate a comment for this list by clicking on 'report' at the bottom of the post and typing 'Actually a quality contribution' as the report reason.
Jump in the discussion.
No email address required.
Notes -
The "S" in IoT stands for Secure
Boy, looong ago now, I broached the topic of security standards for techno-mabobs. At that time, I mentioned that the UK was considering some legislative proposals on the matter. I can't find the comment where I described what I viewed as the core driver of the tension over the topic - the culture of tech folks. That is, they are so used to the 90s consensus that software is gee wiz magic that is pure and sanctified, is the solution to world peace and all of life's problems, and can never possibly be the cause of anything bad, ever. The 90s conclusion was that government absolutely can. not. touch it. Hands off. No regulation whatsoever. No liability whatsoever. No matter what happens, they must have an absolute immunity stronger than even the strongest version that Donald Trump could have ever dreamed of claiming.
Justifications for this view have shifted, but I've always felt they've had a flavor of, "We can't be regulated! We're
autistsartists! We make unique snowflake masterpieces! We have to move fast and break stuff! If we're ever held accountable for breaking anything, even for the most egregious of practices, then the entire economy will grind to a halt!" Whelp, after years of incident after incident exploiting the IoT-of-Least-Resistance, including things like ransomware takedowns of major corporate networks and huge botnets of smart refrigerators, we're about to see how true that really is.Hitting the wire last week, the UK has dropped regulation for smart devices that are sold there. In my original comments five years ago, they were proposing three items; I had only asked for one (the most incredibly basic one - don't have every bloody device have the same default password). I really feel like it's a case of, "If you resist and throw enough of a shitfit over the really simple stuff, it's going to come back around in a much stronger way that you really won't like." The full document of "Baseline Requirements" speaks to fourteen items:
● No universal default passwords
● Implement a means to manage reports of vulnerabilities
● Keep software updated
● Securely store sensitive security parameters
● Communicate securely
● Minimize exposed attack surfaces
● Ensure software integrity
● Ensure that personal data is secure
● Make systems resilient to outages
● Examine system telemetry data
● Make it easy for users to delete user data
● Make installation and maintenance of devices easy
● Validate input data
● Data protection provisions for consumer IoT
Each area is broken down into one or more specifics. There's a helpful table on page 32, detailing whether the requirement is Mandatory, Recommended, and/or Conditional. This is important to know, because a bunch of them are truly just recommendations, but even many of the ones that are Capital M Mandatory are also Conditional, which is actually displaying quite a sense of care about the diversity of devices and possible situations. For example, they acknowledge things like "constrained devices", which is a "device which has physical limitations in either the ability to process data, the ability to communicate data, the ability to store data or the ability to interact with the user, due to restrictions that arise from its intended use". Here, they give some explicit examples, like "The device cannot have its software updated due to storage limitations, resulting in hardware replacement or network isolation being the only options to manage a security vulnerability."
I think this truly is a culture war between the culture of technokings and the culture of They Can't Keep Getting Away With This, and no culture war offensive ever comes without a counteroffensive. Will major corporations, either American or Chinese, bow the knee? Will they pull out of the UK in a weird, polar opposite anti-security stance to the position that has led other companies to pull products like Signal/Telegram from countries that threatened to make them less secure? The UK may be the sixth largest economy in the world by GDP, but that's still only about 4%. Will they go full tizzy and make separate products, where the secure versions go to the UK and the less secure versions go elsewhere? If they don't pull out and don't make different versions, than everyone in the world just got a huge security upgrayyyed. If they don't pull out and make different versions, other countries have a green light to mandate that they should also get the good stuff. So, if they're even thinking about pulling out, they've gotta rally the troops, punish any defectors, and really make the UK feel blockaded as a warning shot to the rest of the world.
My guess is that they'll bow the knee and just do this stuff for everyone. It's pretty much all stuff that everyone has known that they should be doing for quite a while now. Will it cost a little extra? Sure. Will they have to deal with some annoyed developers who feel constrained by law, as basically every other industry ever does, and eventually have to bring their culture into the Industrial Age? Sure. I doubt that having to pay $9 for a smart plug instead of $6 is going to change much about the economics of wiz bang gizmos... but it just might be a step toward not having newspapers filled with nightmare exploits causing millions in damage... at least not every week.
The cost of compliance -- which is to say, the reams of paperwork and signoffs necessary -- will make this impractical for startups. The large companies making this stuff will do it -- eventually, with the UK getting delayed releases. The Chinese knockoffs will continue to be sold unlawfully, and a lot of new stuff just won't appear in the UK at all.
Sneer all you want (I guess you're a Real Engineer), but I think a big reason bits have continued to grow while everything else has stagnated is the regulators haven't caught up with the bits yet.
My read is that they literally just need to fill in that table that I mentioned on page 32. That's not a lot of reams.
I am most decidedly not a Real Engineer.
Like I mentioned, we will see if the economy of bits will grind to a halt... or if they'll take the couple days necessary to not have a default password and to write "Yes, we don't have a default password" in the table on page 32. Perhaps you could formulate your prediction in numerical terms? Maybe something about growth rates in the tech sector over the next ten years? Maybe something about stock prices and how they'll reflect this immense stagnation? Or maybe an explanation for why the market hasn't already priced this in and had a massive drop in valuations in the past week in response to oppressive new regulation?
I don't think you understand how this works if you think that this is the only necessary step once this becomes an obligation by law.
Since this is a potential liability, someone will have to be responsible for filling that form, and they'll also have to have sufficient means to enforce that the form is true. That person is most likely a lawyer and not technical themselves, which means they'll have to rely on auditors, which means not only that you'll have to pay money to get those audits done, you'll also have to find a company that will do them on the tech stack that you are running and is familiar with the intricacies of the particular legislation you're trying to abide by.
And once the bureaucratic machine gets started like this it doesn't stop, standards will get more complex, there will be people whose whole job is to ensure that they are followed and the costs will balloon accordingly.
Compliance is a huge industry. If following the law was that simple, it would not be.
Like Bastiat says, there is what is seen and what isn't seen.
What is seen is the valuation of established companies that have compliance departments and who'll be able to integrate regulation with a marginal cost change they can pass on to the consumer. What isn't seen is how much harder it is or will be to get funding for a startup that designs novel appliances because the costs to enter the market are now higher.
Weird. I hear about that from my friends in literally every other industry ever. They still seem capable of operating.
I'm always sympathetic to concerns of regulatory capture putting barriers to entry in front of small businesses. Totally agree that this is the single strongest argument against these types of requirements. I just doubt that these particular requirements are that onerous. Plenty of smaller shops that actually care about not being a security clusterfuck already do these kinds of things, and you can do most of them without too much difficulty as a hobbyist. In any event, if you're a start up that can't figure out how to not have a default password on all your devices, I actually kind of don't want you selling stuff, anyway.
Eh... they vary a lot, both on context and use case. Requiring secure storage for persistent storage of security parameters (5.4-1) makes sense and has trivial cost for applications like a network storage device, but it'd break a lot of assumptions on FRAM-heavy low-power devices, and that rule notably isn't conditional or a mere recommendation -- perhaps they didn't think about FRAM, or other persistent memory, but I wouldn't bet against UK compliance checks taking that as an excuse. Making security-focused unique IDs tamper-resistant (5.4-2) isn't too bad on a device with a real MAC (though not costless; there are benefits to software-changeable settings here), but for the more ultra-small or ultra-disposable equipment that's largely going to mandate more and more of program flash be devoted to encryption keys (unless you want to decrypt something on discrete flash every time you're doing an update check). Mandating a network update happen over a trusted relationship (5.3-10) and be timely (5.3-6) and be automatic (5.3-4) isn't too bad for a situation like deploying a bunch of wifi access points or phones, as much as I hate 99% of implementations work, but it's an absolute mess for wide deployment public LoRaWAN devices, and a mess for things like CAN- or LIN-networked embedded devices.
Others vary heavily on interpretation. Mandating that "For constrained devices that cannot have their software updated, the product should be isolable and the hardware replaceable" (5.3-15) could mean almost nothing, or it could require vendors to commit to support any optional part of a product until they retire an entire series. And these all definitely kill EPROM devices that it covers -- I'd expect this ends up with a ton of explicit or implicit exceptions, mostly around the "On devices with several microcontrollers (e.g. one for communication and one for the application) some of them might not be updateable", but it's not really obvious from the text.
That gets worse if they start dialing Mandatory-Conditional or Recommended rules into plain Mandatory ones down the road, and a lot of the text suggests that they're planning it:
In particular, SecureBoot (5.7-1), hardware memory access controls (5.6-8), and guaranteeing cryptographic updates for the life cycle of the product (5.5-3) mean throwing out a lot of existing microcontrollers, microprocessors, and often related code. It's clearly intended for big GHz+ microprocessors, but there's a lot of new (mmu'd!) chips that don't have this capabilities. SecureBoot there's some arguable conclusions for some of the bigger devices, like throwing a ATECC608 after a PIC, but a) I'm not sure if that actually complies with the recommendation, and b) no, god, no. Hardware memory access controls... maybe ESP32 memory protect would cover it (though they're software-settable, though the software settings are code-private?). Wherever these hit, a lot of chips aren't going to pass it, and businesses focused around them are going to have to toss inventory and code -- there's just too much of this stuff that isn't portable.
A number are probably gonna have to start now on the off chance that it happens in a couple years.
Now this is the type of response I was hoping for! Actually engaging with the substance!
Perhaps they'll issue a clarification, but from the note in this section, I think someone could read this as "memory"; it has "memory" right in the name! In general, I do expect there to be some clarifications along these lines as folks like you bring up additional concerns.
This one is conditional, and I imagine ultra-small or ultra-disposable devices won't qualify in the first place.
Same here; conditional. We'd at least have to get down to the level of thinking about each of the devices you've mentioned in terms of the conditions.
Notice how they define isolable:
In the section describing the rule, they continue:
I think I would interpret this as, sure, you need to support any part of a product until you tell the customer that you're not supporting it anymore, and the type of support can vary.
Yeah, I have a feeling that these aren't going to pop into the Mandatory category for a while. The real good news is that concerns are really of the type, "Will they at some point make these Mandatory, when it is still too soon?" Because pre-rule-dropping, I imagine the worry would have been of the type, "Will they make this stuff Mandatory now?" And, they, uh, didn't. I think this document shows a pretty decent level of care in getting some of the really basic stuff right and showing the industry the direction they'd like to go in the future. There's no telling at this point whether it'll all actually go that way; one has to imagine that there are differing worlds where it seems more/less plausible to upgrayyyed these Recommendatations into Mandatory.
Whereas this one, I think is fine, given their explanation:
How easy is that? You don't even have to update it at all. But if you do, then at least make sure your shit isn't trivially broken, at least so long as you're telling the customer that you're still supporting it.
Maybe, but so does CMOS RAM, and that's a central example of where you probably do want this rule to apply, and it's (usually) more volatile than FRAM. 5.4-1 to my read isn't about access modes or media type, but about storage volatility, and that makes some amount of sense for certain attack vectors -- you don't want someone reading cloud passwords by probing random SPI flash, as weird as that particular threat is.
But it also makes a lot of design spaces for low-power devices goofy, in ways that don't make sense. There's probably a class of low-power device where it's a really critical security problem is someone delid the main processors and inspects individual FRAM cells during a toggle-off state, but 99% of the time even if someone could hijack a session id from that it's less big of a deal than having access to the board to start with.
Yeah, but the condition is only that applies where ever "a hard-coded unique per device identity is used for security purposes". I think that includes virtually every LoRaWan (DevEUI) and probably every LoRa device, for one common example, but also technically at least most Bluetooth implementations. There's other places where it's a good idea to use hard-coded unique identities per device for security purposes even where it doesn't 'matter', and that's largely going to result in people just dealing with stupid hacks instead to avoid triggering the requirement whenever possible.
Yeah, but the conditions for 5.3-4 is "an update mechanism is implemented", 5.3-6 "an update mechanism is implemented" and "the device supports automatic updates and/or update notifications", and 5.3-10 that "updates are delivered over a network interface" and "an update mechanism is implemented". These are fine when you're talking a full web-UI/app-equipped device, but twenty sensors on a LIN line that can be updated still hit the requirement for 5.3-4, which is on its own a requirement for automatic updates so you now hit 5.3-6. Then you're trying to figure out how 5.3-10 works for devices that don't have user interfaces (and may not have user physical access!), and now you're either stuck tossing an authentication layer on your LIN, implementing a cryptographic security function for comms on said LIN, or spamming users with update notifications like they were running Arch Linux.
Eh...
Let's take the example of a lightning switches attached to a base station, as a fairly common home automation setup where the switches and adapters are... not actually a central case of the constrained device model (they have wall power!) but are at least arguably close. If you build one of these, you're probably going to support a wide variety of light bulb sockets and switch types, but not all of those are going to make sense over the longer term -- maybe a socket type falls out of popularity, or a new lightbulb tech drops that doesn't play well with dimmer circuits, or a vendor you partner with stops selling a product that makes that particular device make sense.
By the text, is a lighting hub "isolable and hardware replaceable" if the vendor doesn't want to sell every attachment for the hub's life cycle? Removing one attached device doesn't make the attached device 'isolable', because turning on and off that light is its core feature. Nor is removing the entire hub from the internet, since there's no sane way to call that a "self-contained environment with other devices if and only if the integrity of devices within that environment can be ensured", when the especially if the entire reason to pop them off the internet has to do with their ability to communicate securely with the local hub. Would it be hardware replaceable is the only hardware replacement doesn't actually fit into the same socket, just because something attaches to the same hub?
Yes, in practice your interpretation is the sane one, and hopefully it's probably going to end up as the sort of asterisk that just confuses people, like vendors just putting out generic 'support may stop without notice for some devices' clauses. But at best that turns the requirement into aspirational text instead of the actual policy.
I think the interpretation of that standard is closer to page 45-46 here, if not on the exact same timelines, and that quickly turns into an eWaste and version hop mandate for a lot of stuff pretty quickly in order to theoretically prevent the plausibility of certain attack classes, rather than blocking trivial ones. But even for its steelman of "don't use WPA2-only chips in new products", I think it's still costly even if well-intended, and a lot of those costs don't make a ton of sense. There's a number of chips and equipment that can't connect on WPA3 at all, and even where it's something that can be implemented in software that doesn't mean it's exactly easy.
More broadly, though, it seems like overbroad application of a rule. A presumption toward encrypting everything makes sense when it's free or nearly-free, but there are a lot of entire devices where it's just not that relevant. If your equipment does literally nothing but relay temperature and humidity values over ISM bands, you might want some amount of authentication to prevent spoofing, but it's really not that big a deal if someone can listen in. And there's a lot of IoT stuff that goes into that category.
There's some parts of the rules that motion around this -- 5.5-1's "Appropriateness of security controls and the use of best practice cryptography is dependent on many factors including the usage context" or the exceptions for ARP, DHCP, DNS, ICMP, and NTP in 5.5-5 -- but again that turns the requirement into aspirational text.
Fair enough. Hopefully the worst case is that this ends up not being covered, even though it should be.
I think I can agree that there may be tradeoffs here for some devices.
I think these would almost certainly just be classified as "constrained devices", and they also give alternate mechanisms for valid trust relations, which I think will be what the automakers go for. They'll do the verification at a different step and say that the lack of physical or other access is what ensures that presence on the network is sufficient.
I think you're right that some portion of this is aspirational text, but I think it's along the lines of, "If you can just put some reason down on the table for why this should be considered aspirational text, then you're probably fine," and the only people who are at risk are the people who are doing the clearly and obviously boneheaded stuff. Like, I don't think it's going to be hard for the maker of a device that does nothing but relay temperature and humidity values over ISM bands to just say, "It's a constrained device; can't do any of that fancy stuff; pretty much no way in anyway," and we can all mostly go home happy. If we start having major corporate networks brought down by botnets of temperature monitors (uh, how?), then perhaps folks will have to figure out how to make it more than aspirational text.
In any event, thanks a bunch for really thinking through edge cases for a wide variety of really specialized and, for lack of a better term, really constrained devices.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link