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 -
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