> How else do you explain how woefully unprepared we are?
What do you mean? This is an expected outcome of the "ship ASAP", "competition uber alles" culture, rewarding short term gains over everything else. Our whole technological ecosystem was built on this mindset.
I think ZigBee has already been deprecated in favor of Thread, which seems to be slightly more focused on security, although it's still probably nowhere near where it needs to be.
The vendors of Thread devices probably care even less about security and, for instance, choose to make every single one of their devices Internet-accessible instead of creating gateway apps for a local mesh network of devices.
I would have thought that Zigbee had zero traction some years ago. But since then Hue (and Lightify and other Zigbee LightLink solutions) popped up and now are probably the most sold personal home automation things around. The manufacturers do want for sure to push the ecosystem and are announcing more products based on it. Compared to that Thread has next to zero available devices (don't know whether Nest uses it). So I think currently it's a bit too soon to talk of ZigBee being deprecated.
Note that ZigBee should have a lower attack surface than the Hue/LightLink extension. The regular ZigBee protocol requires a Coordinator in the mesh network, most of the LightLink protocol deals with doing away with that requirement.
Tragedy of the commons. No individual manufacturer really cares about the issues created by the ecosystem of IoT, so they have no real incentive to address it.
Tragedy of the Commons really means "the structure of a market failed to produce the desired outcome". The common good may be the victim, but the market is the culprit.
The solution of course is alternate economic structures that respect the commons. The distinguished economist Elinor Ostrom wrote a whole book called Governing the Commons which presents real-life alternatives to markets for commons-like economic activity.
Or we could continue marching to the drum of neoliberalism and try to contort markets until they meet our needs. Love me some procrustean capitalism.
The opposing viewpoint is that only public resources suffer from tragedies of the common (they become a free-for-all), whereas with private ownership there's usually a natural incentive to make your profit-producing resource sustainable. Of course, it's always more nuanced than that (mining and resource extraction industries are problematic), the ideal is probably somewhere in the middle. So we argue about exactly where it should be :)
The situation you are lamenting (and I agree with your sentiment) is not a "tragedy of the commons." I think you are trying to describe a collective action problem. Collective action problems are frequently brought up during a discussion of the tragedy of the common but the existence of a collective action problem does not imply that there is a tragedy of the commons. If you are interested in these types of issues Mancur Olsen's "The Logic of Collective Action" is the standard introduction.
"Yet" is the key word. Even rumors are sometimes enough and as powerful as lawsuits.
Market forces are really powerful. See Samsung's recent troubles -- once everything was fine, and then -- BAMM! - their phone sales went down without any external regulation. (pun intended.)
How is this "tragedy of the commons"? The only "common" they are using is the RF spectrum, which they are presumably not polluting too badly or the FCC would start smashing down doors.
Let's not start claiming the internet itself somehow qualifies as a "common", because with common ownership rationally comes common censorship (as with the FCC and public broadcasts).
I think you are mistaking "tragedy of the commons". It is a behavioral outcome, where individual actors take actions that immediately benefit them, but if everyone else does the same thing, then no one wins. Overfishing a public pond is a common example (the commons is obvious here: the pond), but another great example is standing up to get a better view at a large stadium event. If you stand up, you can see better. Unfortunately, this means the person behind you also has to stand up. Once everyone is standing up, no one is any better off than if they were all sitting.
The analogy here is more like the latter: It is better for Manufacturer X to rush their IoT device to market to maximize profits, ignoring security concerns. If every manufacturer does this (the person in front of you at the stadium just stood up, so you stand up too), then whoa, we have millions of insecure devices waiting to be exploited. This is indeed a tragedy of the commons.
Seems unwise to reason backwards from your desired conclusion (commons implies censorship/regulation, so it can't be a commons).
Security is indeed a commons because the overall security of the ecosystem only benefits each person weakly, and so every actor rationally benefits by neglecting security.
External regulation isn't the only way to address commons problems. Manufacturers can see the writing on the wall and work together to solve issues, but only if the public pushes them to.
I imagine that it can also get better once a company can gain competitive advantage by advertising that "our device is secure!" But I suppose a precondition for this is customer awareness of the issue, which probably requires some well publicized high impact/casualty incidents first? :/
> But I suppose a precondition for this is customer awareness of the issue, which probably requires some well publicized high impact/casualty incidents first? :/
I'd say it absolutely requires a high-impact case, something like downing of an airplane, or a cyberattack that sets half of the city in flames. Otherwise, any concern of people about security will quickly get papered over by marketing - as it always is.
Of course, anyone can say "our device is secure", and if the industry is left to its own devices to create a standard for being allowed to say that, they'll pick the cheapest standard possible. Then, so long as they can say "we were following the standards", and the standards company can say "we're updating the standard" every time, nobody cares.
Basically control frames run in the same band as the payload data, so if you put a ZigBee header half way down your packet and cause some noise, the inside application data turns into a new packet header. You can't do this on 802.11b/g/n/etc because the control data is send out of band from the application layer data.
It's considerably different from the attack mentioned in this post, but we've know at least that the protocol has been broken for years.
What's great about this argument is how versatile it is. Climate change got you down? How about deforestation, or antibiotic overuse? Tired of people telling you not to write web applications in C? Your one liner seamlessly shuts down discussion in any of those debates!
In fact: the finger-waggers have been right about this issue since approximately 1988, when Paul Graham's friend shut down much of the Internet with a tiny C program that shouldn't have been possible to write back then, but is in fact still possible to write in 2016.
Fortunately, folks "woke up" a bit as a result of that event (granted, security wasn't really a concern at that time). Unfortunately, it was relatively quickly forgotten and it took another 10-15 years before security really became something that was looked at as anything other than an inconvenience or an impediment.
I'm becoming more and more convinced that nothing is going to change (with regard to overall security in general) until we have some huge event that negatively impacts a large portion of the population in a major way. Until then, things will continue as they are, and security won't be taken seriously.
I'm ready for the 2016 version of the 1988 sendmail worm (or perhaps something with the "average user"-visible impact of the 1990 AT&T crash), just to "get it over with" and get us moving forward.
The lack of liability changes in the wake of the Target breach (at the very least) means that companies can foist whatever security model they feel like upon the market without any possible repercussions. You basically have to be VW compromising a highly regulated industry for there to be any negative effects beyond PR, and internet-accessible data is so far completely unregulated.
And even then the benefits to ignoring the warnings for companies is still pretty powerful. VW may have been caught and punished in the US but here in Canada they are still dragging their feet with any mention of compensation to victims and our courts are letting them.
"We can't keep driving these and feel good about ourselves. So something needs to be done and I just want an answer.… It's not about the initial mistake — it's what you do to make things better." http://www.cbc.ca/news/canada/toronto/vw-emissions-1.3708372
Even if a big event occurs I think the security drive will be short-lived. You'll then find a few manufacturers taking shortcuts to beat their security-minded colleagues to market... then the floodgates open again as everyone races to the bottom.
Admittedly I am now interested and, I apologize in advance if this is in the thread already and missed it (thanks poor vision!) but, would you happen to have a link or explainer as to this incident? Sounds very intriguing.
Anyone in tech with two braincells to rub together could tell you that security is a hard problem. And yet there has been a consistent pressure in IoT enthusiasm which rested on the premise that security was a solved problem. Everything about IoT went against decades of hard-won wisdom about internet security: lessen your surface area, keep as much stuff off the internet (behind firewalls) as possible, constant vigilance through patching and staying up to date on vulnerabilities is important, use strong credentials to secure anything that could ever be reached from the internet. In short, that internet security was a big and difficult job, and a constant battle that required careful risk management.
IoT enthusiasts dismissed all of that and never had a good counter-argument, just the insistence that nothing, not even security issues, should get in the way of how cool IoT devices could be.
It was obvious that this would be a problem. And every security expert made mention of it. There is no "oops, well how were we to know?" about it.
The charitable response is that it was a metaphor. I would assume you understood that but it would mean you intentionally posted that terrible half-pun. I'd rather assume you just didn't realize it was a metaphor in the first place.
How, exactly, are you identifying "fear-mongering stories"? Mislabeling real security issues as "fear-mongering" is how widespread security problems are created.
When attacks can be trivially copied, even obscure security issues can become easily exploitable problems under attack from bulk exploitation tools.
It's a headline problem. Typically these issues are labeled as "all of IoT is terrible".
For as many of these REAL security issues we face, there are many stories published that have no real-world impact.
Examples:
The story from defcon (or blackhat, cant remember which) about installing ransom-ware on your smart thermostat.
The headlines were all "Hackers make thermostat ransom-ware" or "Your smart thermostat is now vulnerable to ransom-ware"
A few points:
- It required local access
- It required an SD card reader
- It also required the thermostat run a local HTTP server
Another decent example were the SmartThings security holes from earlier this year:
- It was mostly an oauth2 authorization issue (applications requesting grant types it didn't need)
- The apps were actually independently developed (not ST official) and took some technical knowledge to deploy yourself
- The rest were known security issues in the Zigbee protocol that SmartThings has little control over. Similar to this article.
Or the botnet of cameras which is probably the most high-profile example and most relevant are labeled as "The IoT brought down the internet"
That's a lesson for the makers of those cheap DVRs and Cameras, it was also a lesson in user documentation to avoid them doing stupid things. That's the only example in recent years I've seen that goes anywhere, but the problem is it's drowned out by nonsense and clickbait headlines.
Yes (and no). Asymmetric which is based on key pairs (generally one public and one private) allow you to pass around a key that can be intercepted without compromising your ability to communicate securely using the key your didn't pass around. That said, it is always important to be attuned to whether or not those keys can be compromised by "brute force" or through a weakness.
So the vendor who is thinking about it, would have told me about their public key system which is used in the initial transfer to protect the secrets. Then they would have described how they can upgrade and change keys over time as attackers gain the upper hand on various bit lengths, and how the elements of their system that depend on randomness, do so without being susceptible to a birthday attack or an algorithm attack on their PRNG.
When they do that, I know they've been thinking seriously about how such systems are built and deployed and there is some hope that doing the do diligence "deep dive" will show me a solid system.
And one part that is often forgotten: How to authenticate the other side.
Without authentication asymmetric encryption is still useless, because someone could man-in-the-middle your key exchange, swap out the public key that is sent both ways and make either side think they now have a secure channel with each other while in reality they have a secure channel with the man in the middle.
So the challenge is that they'll need some equivalent of what in the HTTPS world would be a Certificate Authority. For which you'll have the same kind of update/upgrade path questions that you very rightfully ask for the key lengths.
Very true. Early on in Java's gestation I was building into it a full capabilities system for security. One of the challenges of loading classes which provided export proscribed encryption capability was having the JVM authenticate the class, and having the class authenticate the JVM it was being loaded in to.
Of course not all situations need that, but understanding what the endpoints are trying to achieve and how that objective could be compromised by an attacker will inform on which identities must be established, and to whom, in order to achieve that objective.
I was wondering the same thing ... shouldn't a design goal for the signing mechanism be to make it impossible to derive signing capability without access to some secret not present on the device?
Like being "blindsided"... by a steamroller... from 20 miles away. Then again, "Disaster in slow motion" seems to be the order of the day, from economics to climate.
It's theoretically sound with a good HSM. But agreed, I'd rather rely on getting a sound software implementation of an asymmetric signature scheme than rely on protecting a symmetric key with hardware.
Hue forces updates on you every time you go into the app if there's one available, and you can't use the app until you've updated. Granted this isn't ideal if you primarily use your light switch or an amazon echo to control the lights, and fully automatic updates would probably be better, but it comes pretty close to aggressively pushing updates.
It's pretty aggressive alright. I'm working on my own (RPi-based) controller but for now, I'm still primarily using Hue app for controlling the lights at my home. So every two weeks or so, when I come home in the evening, I'm forced to sit in darkness for 10 minutes as the update installs itself (they say lights must stay powered, so I don't dare powercycle them during the update).
I am very happy that my preferred third party app (Huetro, which runs on just about every device the UWP supports) checks for updates for me (and is kind enough not to nag about it but make it clear when one is available) because I never open the official app anymore (but as this article points out do need to keep things updated).
>We should hold manufacturers accountable for not aggressively pushing security updates on their users.
There's really no way to /force/ companies to support products they release like that. The company may not even exist a few years down the road. You could force them to release the firmware source so the users/community can patch it themselves but I don't see a way to do what you're saying.
I get your point about internet connected light bulbs, but is there a particular reason you selected incandescents over other more energy efficient bulbs that don't have IoT capabilities?
the quality of light from your average energy bulb is typically terrible. I like warm light and whilst I know I can't see infra-red frequencies I want to see a concentration of light towards that end of the spectrum. It just makes for a much more relaxed feeling.
I stockpiled too. and I have dimmers on pretty much every lamp (including the toilet), so the bulbs last for a very long time. when you don't burn them on full wattage they last much much longer.
The perceived color temperature of the light is not the main issue in light quality, but rather the smoothness of the frequency composition of the light. Cheap LED bulbs have a "gappy" spectrum. "High CRI" bulbs are probaably what the OP is looking for.
So what you're saying is that if someone does make it work, we should reverse engineer the worm for understanding how to achieve better device interop? ;-)
> It's not even possible to get two ZigBee products from
> different manufacturers to operate (like a switch and a
> lamp).
It may require a distinct payload for each type of device/software, but it should be possible. You start by infecting a group of devices of one type with a specific payload, and from there see which other types of devices are in range, and either carry the required payloads with you or fetch one over a nearby wifi.
And indeed, if someone were to implement this, they would basically have built a standard ZigBee inter-device communication protocol, by using existing software features (bugs), in otherwise incompatible devices.
This is not too far off from something like Stuxnet, so -- given enough available capital -- it should be possible.
> And indeed, if someone were to implement this, they would basically have built a standard ZigBee inter-device communication protocol, by using existing software features (bugs), in otherwise incompatible devices.
I was indeed half-joking, half-serious. Actually, aren't there cases where viruses (the biological kind) have ended up serving a function in the DNA machinery of multi-cellular life-forms? Would be a funny parallel.
You can't jump from and to -any- devices. They can't talk to each other. They have different network stacks.
Lemme me give a simple illustration. You know that wifi has different encryptions standards: WPA1, WPA2, WPA2-something, TKIP, AES (and mixes of those).
Now, imagine that Zigbee has no encryption standard, each manufacturer invented something of his own. [That's a simple example of a piece of the L2 layer. Trust me, ALL the upper layers are are even more of a mess :D].
There are thousands of bugs in Zigbee devices for sure, but they are specific per device/firmware/network stacks. Not cool enough for a fun apocalypse.
Did they detail if they heard anything back from Atmel? Or did they reach out to the Zigbee alliance? I'm reading through the paper and haven't found it yet. Only that they heard from Philips.
This is also why you're starting to see more and more devices opt to a completely device to cloud infrastructure instead of local communication. More control of the stack on device and in the air.
Well, the HTML contains some very shady (encoded and obfuscated) JavaScript code.
If you want to investigate further replace the "return r;" in the very end of those two "evals" with "console.log(r);" then get the decoded code from the browser's console. Then run through code beautifier (built-in in Firefox JS debugger) to get readable code. But there are more code obfuscations later, though easy to reverse but I don't have the time right now.
Yeah, if it works (which I'm not even sure that it would), it would bear a lot of resemblance to a computer virus and no resemblance at all to a nuclear bomb.
Nuclear does not necessarily mean a bomb
It mean something in the (atomic) nuclei or related to these. Forces, reactions, particles, etc.
Surely chain reaction is a member of this set, but not the only thing. Sure, most nuclear devices we hear about use the chain reaction (power plants, bombs), but an x-rax machine is also somewhat a nuclear device.
Sometimes we even induce neutron capture, which is the opposite of chain reactipn (afaik to create some special isotopes, or to start/sustain a chain reaction).
How else do you explain how woefully unprepared we are?