More awful IoT stuff
mjg59.dreamwidth.org
mjg59.dreamwidth.org
> The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me.
I also want it to be upgradeable, and hackable. I'm willing to pay a lot of money for standalone quality devices, but nobody is supplying!
A look at the practicalities here: http://fortune.com/2015/06/09/ceo-apple-homekit-mess/
Edit: Missed this line in the original article:
The issue, according to Lombard, is that Apple HomeKit certification requires a co-processor to handle device authentication. That co-processor is where the device’s encryption key is stored and handles the computing associated with encryption.
Looks like (for security purposes) Apple wants a dedicated crypto co-processor. Probably a tamper-proof chip that stores a private key, similar in concept to Apple's Secure Enclave.
> Is that compatible with non-apple devices?
You could pay an amateur electronics hacker to make you such devices.
I imagine something like the following would be good:
- Each component runs in it's own chroot/container/virt so the manufacturer can provide whatever they want, and the user can throttle it if it's poorly engineered.
- Discovery service that allows installed network server components to register with it for discovery. (Sun's RPC service, anyone?)
- Possibly also to proxy all traffic through discovery service, so network components have to specifically register for direct network access with very specific access limits if they want to use an internet service or talk to a company server.
- Separate file systems exposed for the application and stored data for each app, so a memory card card can be used for the data portion, and replacing hardware is fairly simple (after base software is installed, each application will discover it's configuration and stored data from the provided memory card). Possibly even a separation between data and config as well. IP cameras can spool all their recorded video to the data partition, which might be a large attached disk, but their config can be on a separate, easily swapped memory card, for maximum choice when upgrading.
- Let the manufacturers work out standardizing protocols for their industry, or not, and integrating with other apps, but let apps see the list of available apps, and request access to other ones, so devices from the same manufacturer or ones with a partnership can leverage each other.
- Lots of other stuff people will come up with along the way.
I imagine you could get any relatively cheap box, install the base software (linux distro of choice plus framework, or distro dedicated to this), and have it mostly work. Something like FreeNAS and similar projects.
Does anyone know of any groups out there working on something like this? Maybe some docker oriented distro that aims to be super simple comes closest?
Edit: Added another point or two.
And I can't even control which of my apps should not connect to the network. There are lots of fun apps e.g. games, photo editing etc. where internet connectivity is solely needed for ads. I'm OK with that. However I don't want them uploading any personal information to their servers. I wish I could stop that.
What I've got is a platform that 1.) makes it substantially easier for IoT developers to get their devices to market and 2.} enforces end-to-end encryption and affirmative consensual sharing. It works by running as a background service on both the IoT device and on any connecting computers. In a similar vein to IPFS, the service magically switches between local and nonlocal networks dynamically, so it doesn't matter if your interent connection goes out; as long as you have power (and a local server set up, but I'd like to add P2P capability over LAN in the near future) you're good to go.
I realize this isn't the whole device you want, but is that a starting point you'd be interested in?
+ Golix is the name of the protocol: https://github.com/Muterra/doc-golix
+ Hypergolix is the background service I've written to implement it, which is backed by a PaaS on AWS: https://www.hypergolix.com
+ This is a demo of Hypergolix: https://github.com/Muterra/py_hypergolix_demos/tree/master/e...
Cheers, and thanks for the feedback!
You wouldn't have any guarantee that the garage door opener isn't also running a separate web connection in the background, but arguably unless you're actively monitoring your LAN (or just plain radio) traffic you don't have that anyways.
Put a different way, you can't prevent your manufacturer from, for example, adding a SIM card and wireless connection to your garage door opener. At some point you have to trust them.
1. Roll their own implementation (highly discouraged). Increase their development burden. Introduce higher maintenance burden. Slightly more flexibility for app deployment. And run the risk of my company disallowing interoperable embedded commercial implementations out of security concerns for the users. Basically, at this point the company is better off not using the protocol.
2. Use our implementation (Hypergolix). Massively decrease development and maintenance burden. They now have an install dependency, though, so distribution is a bit more complicated. Significant reduction in time and money invested in the app.
The critical point is this: with option 1, you're correct in that you don't know the protocol is in use, but it's extremely likely that they wouldn't be using it here, nor advertise that they were. With option two, you know that they are using it, because you have to manually install the application to run the protocol.
1. It plugs into the wall
2. You can plug an appliance of some sort into it
3. The device has a USB interface
4. The device has a WiFi interface
5. When I plug in the device with the USB interface, it looks like a serial device
6. The device has a very simple protocol that you can use to set it up, over the serial interface
7. You can optionally have the device join a WiFi network, and you can choose to enable a simple REST web service
8. Whether you choose USB or Wifi, the device only does 3 things:
a. Tell you whether it is supplying power to the appliance
b. Supply power to the appliance, if not already doing so
c. Stop supplying power to the appliance, if not already doing so
edit:formatting
The ESP8266 is a micro controller with built in WiFi and network stack and a serial interface, and several digital I/O pins you can use to interface to other things.
Various vendors sell small modules that couple an ESP8266 with some flash memory to hold your code. These often come with built in firmware that provides a serial interface similar to the old modem "AT" interface, but with commands for WiFi. There is a free SDK available for programming the thing in C/C++. There are several firmware replacements available. There is one that brings the Arduino environment to the ESP8266. There is one that offers MicroPython. There is one that offers Lua.
A solid state relay is a four terminal device. Two terminals are the control terminals, and two are the load terminals. Put a specified voltage across the control terminals, and the devices acts like a closed switch between the load terminals. If the control voltage is below the specified level, the device acts like an open switch between the load terminals. A typical SSR can handle AC voltage on the load terminals of well over what any standard household or office uses. The control voltage is typically around 3-30 V to close the virtual switch, which a logic one in a 3.3 V system (like the ESP8266) falls within, so you may be able to control the SSR directly from an ESP8266 I/O pin. (But you'd need to check the specs for the relay and make sure it doesn't require more current than the pin provides. If it does you might have to toss in a transistor to drive the relay).
This would be a good first project to get started in micro controllers or IoT or home automation or home sensing.
Two caveats are that it doesn't directly have a USB plug. The serial header is exposed and you can reprogram the device with your own firmware to make it report whatever you like, but you do need a USB-Serial cable and maybe to solder on some header pins. Also, it is meant to be spliced into a power cable - it has input and output wire terminals and not an outlet-type connector.
I have a couple of these, they're quite useful. One controlling a fan and another I spliced into a light switch to control some overhead lights.
Make sure to put a 10A fuse in series, use wire rated for 10A and pass the ground wire through.
http://www.aliexpress.com/item/USA-Canada-2-Prong-Male-to-Fe...
Or just cut and splice the regular power cord, that's what I did with a room fan. The Sonoff has thick plastic covers for the terminals with little teeth to hold the wires in place as it's meant to be put directly in line with a power cable. Note that the relay inside is claimed rated for 10A, so I wouldn't power appliances with it. It also only switches the hot and neutral lines, so if you need a 3-pin connection you have to splice it to the line and neutral while keeping the ground line connected.
It goes without saying however that you should be extremely careful and only splice wires like this if you know what you're doing. Don't damage cable insulation while stripping, wire things up to the right connectors, don't leave exposed wires, use the correct wire gauges for your load, etc. Mains electricity is dangerous, yo.
The datasheet says the control current is 7.5 mA at 12 V. It doesn't say what it would be at 3.3 V, so that would be the one thing I'd worry about. ESP8266 GPIO pins can source a maximum of 12 mA, so if you want to hook it up in a way that uses the GPIO pin as the current source there might be some issues.
I think to be safe, I'd just go ahead and add a transistor. That also can provide protection against a logical 1 being enough less than 3.3 V or a logical 0 being enough more than 0 V to cause problems.
You can find similar relays on Amazon for a bit less (search "solid state relay"), and even cheaper on AliExpress if you aren't in a hurry.
"Endpoint hostile" networks are designed with a single use case in mind: accessing remote servers, usually via HTTP/HTTPS. Other use cases are prohibited or broken.
Here are some of the characteristics that would label a network as endpoint hostile:
- "Device isolation," which prohibits local LAN device communication. This is common on some WiFi networks. It's forgivable on a public WiFi but not elsewhere.
- Symmetric NAT
- Multiple levels of nested NAT e.g. consumer routers plugged into consumer routers. It's important to note that this makes everything flaky due to weird interactions and timeout behaviors. In our experience it's disturbingly common. We talked to one person whose company had at least five levels of this, requiring things like "ServerAliveInterval 10" in ssh_config.
- Lack of support for NAT hairpinning. (NAT can't NAT-traverse with itself.)
- Short NAT/firewall stateful connection timeout (120s is the RFC recommendation, but 30-60s is common and we've seen 15.)
- IPv6 absent (assuming it's available upstream) or deployed in a silly way (e.g. IPv6 NAT).
- Lack of support for local multicast or broadcast
- Aggressive edge firewall rules that prohibit UDP, non-standard TCP ports, etc. or that DPI traffic and attempt to block anything other than HTTP, SSH, and SSL.
- Badly implemented NAT ALGs for things like FTP and SIP that break other traffic.
- Lack of uPnP or NAT-PMP support.
- Mandatory proxy configuration.
- Middle boxes that modify traffic in general. This includes things that bork TCP in a misguided attempt to "optimize" it, things that inject HTTP headers (or worse JavaScript), things that modify DNS to strip A/AAAA records for "private" IPs or strip TXT records, etc.
Some of this stuff is just stupidity or brokenness, but much of it is implemented for "security" reasons.
I personally consider reliance on network edge controls for security to be a borderline-obsolete cargo cult practice, since the vast majority of today's vulnerabilities and attack vectors are unaffected by it and involve things like cloud services, e-mail, web, app updates, etc. I've worked in netsec/infosec and have seen a number of intrusions, and so far I have yet to see one in the past 10 years that was mitigated in any way by the presence of a firewall. Yet a generation of IT people thinks "firewall equals security" and I'm increasingly thinking this generation will have to just pass along.
Basically you have a 2000 mile data path to your light bulb because routers suck and networking engineers are cargo cult morons.
Let badly written junk burn. Then people will learn it's junk and stop using it or the developers and vendors will be forced to fix it.
It's unnecessary if everyone drives competently, but it also successfully prevents people crashing through no fault of their own.
It also breaks or complicates use cases like "changing which direction you're going on the highway".
This is remarkably similar to defeatable traction-control; people who care enough to figure out what that button does will push it and have fun. People who don't won't and they'll be safe.
If we're building endpoint networks to prohibit local traffic, we are forcing a terrible architecture with terrible long-term privacy and security implications. Because of this, we will have a future where the NSA (and vendors, and advertisers, and the Chinese PLA, and ...) will literally know when you flush your toilet. In the future every interaction you have with every device in your house will be broadcast to third parties across multiple national boundaries and clouds.
... because we had to protect Windows XP machines from rare, marginal threat profiles. (Has anyone actually seen malware spread this way in the past 10 years in the wild?)
The potential criminal and totalitarian applications of a cloud-powered IoT world are incredible. Look into "nudge theory" for a starting point, and then consider things like:
http://www.theatlantic.com/technology/archive/2014/02/when-y...
http://www.ibmbigdatahub.com/blog/power-behavioral-fingerpri...
The decision of how to architect our communications infrastructure today and whether to, for example, permit local traffic could in the future determine whether or not we evolve into a borg-like totalitarian collective or a cooperative society of sovereign individuals. Communications infrastructure affects... well... how we communicate... which in turn affects every single aspect of human society and culture over very long spans of time.
It's a special case of a larger phenomenon called path dependence. Small choices that you make today based on what seem like rational reasons today can have huge differences in the long term outcome of things in the distant future. While the future isn't fully knowable, sometimes conceptual reasoning from first principles can tell us what the likely outcome of a particular path might be.
> Has anyone actually seen malware spread this way in the past 10 years in the wild
Yup, had several IR cases (trending up) where this was determined to be the initial vector. Related: stop making this argument. Nothing is seen in the wild until it is (go back a few years and realize this argument was made about cryptowall-style malware).
I think you should re-read the end of my first paragraph; isolation should have an off switch. Give people the option and let them choose. Sorry if that's bad for your business model.
Network node security should not be delegated to the network. Not only would this necessitate forgoing very useful features that networks enable, you won't improve node security. Devices that are vulnerable by merely sharing a network with other nodes tend to have other more sever security lapses.
I agree that a button is simple way to switch between modes, but it will also make point-to-point the default. People don't change defaults, and companies will eventually cease to implement network capability as a result.
I'm all for better network security, but not at the expense of discarding the network itself.
https://www.facebook.com/kokonautweathersensors/
It's not using my network, but it's hackable enough that you can use it on your own network if you know how to flash it yourself.
I haven't released the code for it yet, but there are plenty of tutorials online. It's using NodeMCU and a DHT11. If there's more interest in hacking the device, I can provide some blogposts or tutorial videos.
There are 5 available and 15-25 more are on the way. Please contact me if you're interested. I'm planning on selling it for around $35 and for the first few batches at $30 (as an early adopter discount). Email: antoniuschan99@gmail.com
For personal uses, I have a waterproof temperature sensor coming in, and plan to use that for my aquarium, so maybe I will produce that version. Also I am tinkering with electrical outlets that can be remotely triggered. So you can set the weather alarm to trigger appliances.
Monitor the temperature in my office (I run a few servers)
Check the temperature outside. I'm close enough to a major city that everything uses that location, but often it's different from where I'm actually at.
My garage. Sometimes I have paints/stains/beer/etc that shouldn't be above/below a certain temperature.
I'll look at it more then email you
Having never used zwave though, it sounds like your point is valid.
>I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home.
and
>I also want it to be upgradeable,
So let's be super-super clear.
You do want it to be upgradeable. That means you want it to be able to be better in the future than the day you bought it. (Otherwise it's not an upgrade.)
So.
You want to be able to enjoy upgrades.
Meanwhile, are you sure that you 100% definitely want non-technical users who plug in the device and never want to take any further action, to ever enjoy the benefits of any automatic upgrade they don't need to know or touch or think about? You want to monopolize upgrades for hackers, and deny them to 99.999% of world's population, right?
You don't want devices to stay on the latest version pushed by their companies, by default? (By default).
I want to be super-clear about your thinking on this.
It's a binary line in the sand. Either devices do, or they don't, upgrade by default whenever the company decides to push a version. I don't update my version of Chrome - Google does, whenever they want. I didn't set it that way. I agree it's best practice.
Do you want to deny this benefit to all purchasers of all IOT devices? (Genuine question.)
The conclusion I've come to is the opposite one that you've come to. I've come to the conclusion:
-> The default settings should have an option "Stay on latest version. Upgrades will be applied automatically." You as a hacker can turn it off to instead get the behavior you suggest.
If the user does not disable that option:
-> By default devices should ping to see if their company wants to push an update.
-> If there's nothing to ping because their companies have gone out of business or the product is no longer supported, then they should stay on their current version and NOT stop working or be bricked. A Nest-like debacle shouldn't happen. Devices shouldn't be bricked by an end to support.
-> If the device has its ping answered it should download the update and check that it is signed with a key in its list of accepted keys, however, only if it successfully reaches a revocation server and the revocation server does not say the key is revoked. It should have a set of possible keys, and if they have all been revoked then it should never apply another automatic update. If it can't reach the revocation server it should never apply an update.
-> Since you're a hacker you can just add a file to the filesystem into the list of keys. This is fine because anyone who can read your device's filesystem in person can already do anything, such as replace the contents of the file after it has been checked, verified, and decrypted, but before being run. So this is not a vector that concerns us. This means that code-signing doesn't destroy anything of your own control over your own device, nor place an inordinate burden on you.
-> Once a signed update has been received it will just be run as root regardless of its contents.
In practice what the scripts should do is copy the current filesystem to an Updated filesystem, then use the scripts to modify the Updated filesystem. It should then issue a reboot command and the device firmware should attempt to reboot into the Updated filesystem. If successful and tests pass then the Updated filesystem becomes Current. If it fails then after a while the firmware will reboot to the old version. The device in this case (via scripts) reports to the server, by encrypting with the non-revoked key, that its update failed. It will then go back to pinging for updates as normal. The server can choose whether and when to push another update, or what other update to push. So if devices in the field are failing to update then the server operator can turn off the push of the updates and fix the problem.
That's it. This is the architecture that I envision.
What do you think? It's the exact OPPOSITE conclusion from the one you've reached. It is far, far beyond the line in the sand that you've drawn.
But your line in the sand means you want the benefits of upgrades, but you want your non-technical dad (or mom), grandparent, non-technical boyfriend or girlfriend, cousin, all the people buying the device and driving the price down for you, not to enjoy upgrade benefits.
Are you sure this is what you want? Positive?
But MEN can update things themselves, right.?
> Meanwhile, are you sure that you 100% definitely want non-technical users who plug in the device and never want to take any further action, to ever enjoy the benefits of any automatic upgrade they don't need to know or touch or think about? You want to monopolize upgrades for hackers, and deny them to 99.999% of world's population, right?
I never said nobody else can upgrade, or that having cloud services (for things like upgrades) available are a bad thing. What I want is a device that doesn't assume it will be connected to the cloud, and doesn't lose any usability if it's not connected to the cloud. I think the best option would be a product that has both: Cloud services, and standalone services, and "home-cloud" services that I can install on my own home server.
> The default settings should have an option "Stay on latest version. Upgrades will be applied automatically." You as a hacker can turn it off to instead get the behavior you suggest.
I absolutely agree. By default I think auto-upgrades are a good thing. But I want to have the final control to turn those off if I want.
I actually really like your idea for how upgrades should be applied. I don't think it's the opposite of my desires though.
They're dirt cheap, they work, and you get root so it's completely upgradable and hackable.
Can't beat that really if you have decent security practices outside of the device.
It's definitely an investment in terms of time to beat it into shape, but it sounds like a fun weekend project to me.
Personally, I consider most of IoT products to be a waste of resources used to create them. It's a blatant promotion of shitty engineering in an attempt to get some money out of people.
ZeroTier already runs fine on embedded Linux, which is a large subset of IoT, and we've researched a lightweight port to FreeRTOS.
I'm not here to be monetized by being glued to the hip to your infrastructure that may go away for any number of reasons (technical or non) and make my property suddenly stop working.
Not to long ago I settled for a couple of the venstar T7900's. They aren't perfect by any means, but they are light years ahead of anything else I could find. In fact they have a whole bunch of options that harken back to some of the early programmable thermostats. For example, out of the box you can control the max cycles/hour, or the number of degrees of variance from the setpoints. Buried in the menus are a wealth of options, including a few for limiting features available to "unprivileged" users. Funny enough, they can be subscribed to the power companies remote kill features, but the user is still in control and can disable the feature, which is probably why they are excluded from my power companies list of "smart" thermostats that qualify for rebates.
So, the cloud service can do a lot of things that aren't available from the published API, but running a local deamon and polling runtimes, setpoints, etc is all very straightforward, as is forcing a thermostat on/off from a server on the local network.
Anyway, that is my .02 for a thermostat that isn't owned by $megacorp/etc and can be disabled at the wim of a company that decides paying for a bunch of cloud servers is no longer in their interest.
My general rule of thumb is I NEVER buy anything IoT that is WiFi based. Zigbee or Z-Wave based devices will save you a lot of security nightmares (though definitely not all).
As these devices become more popular, we'll start seeing more Zigbees and Z-wave devices become commodity hardware.
Zigbee has built-in, easy, encryption. You simply set your router to allow unsecured joins temporarily whenever you get a new device, which then learns the key.
When the network is set to allow only secure joins only devices pre-configured with the key can see anything other than encrypted frames.
Of course, wifi has gotten more secure over time to the point that I'd be more concerned about giving the devices internet access than I would about intruders on the network.
In just one highrise project I did in Las Vegas last year we installed something like 65,000 Zigbee devices, and that's not atypical for highrise hotel construction. Zigbee is everywhere in building automation.
Low power: it should not require much in the way of network traffic or heartbeats so that you could leave the radio mostly off.
Mesh networking: ideally the devices should be able to repeat commands so that they could be low-power and not have to broadcast across entire houses.
Secure: it should have specific ways to join a network that don't require a keyboard on the device.
IoT application focused: the protocol should make it easy to do things like turn a device on/off, set a value or read a value.
Z-Wave and Zigbee do these things (for the most part), while WiFi is sort of hacked to try to maybe accomplish it. For instance, my Z-wave thermostat has been running off the same lithium AA batteries for about a year now, and the battery level is at 77%. I can't imagine a WiFi device being able to achieve that.
(It's also much more power-efficient; you can't really use wifi on battery powered devices unless you charge them frequently)
Maybe i'm just being cynical...
F.ex. when's the last time you saw a commercial for a door knob?
Similarly, the home automation solution targeted at those people usually aren't shit cloud-based products.
Perhaps an open-source effort to document & track what work has been done, even if it's just pulling firmware images and taking a look around. Maybe some kind of gamification to motivate researchers to pull things apart and report what they see.
You'd never see a post on the front page of HN about how IoT device X was well designed and is generally secure, but you see (and will continue to see) them top out about how awful they are.
Just look at this thread. Half the answers to "what are some good IoT devices" is "lol there aren't any"... The HN crowd doesn't want good IoT devices, they want to make fun of bad ones.
I've bought everything from wireless hard drives to $250 Wifi routers to $20 ethernet/3G bridges and the quality of the firmware is pretty garbage on all of them.
I see brand new devices on kernel 2.4 and 2.6 with no upgrade plans in sight, and hacked up kernel trees that have no chance of building except on the developers' Red Hat 9 (!) workstations.
http://www.devttys0.com/blog/ is another good place to follow. I guess it's more fun to write a negative article, not to mention it gets a lot more views.
Perhaps a good strategy would be to still offer an interesting read despite a lack of "hey i found epic 0days and hacked everything":
- here's my methodology
- here are some cool ways they made this thing robust
- here is how I tried/successfully defeated the defenses
- some tooling I created to break this thing
Here ya go!
...
Has the GPL really lost it's power that much? I mean not responding to inquiries is one thing, but outright saying no?
It's up to the copyright holder to enforce it.
¹I believe there are some exceptions, like having contributed only an insignificant fraction of the whole work.
Let's say you contributed 500 lines of code to some project. You sue somebody for violating GPL and not publishing their changes. The judge has to give them the choice : either pay damages or actually comply (another western legal principle : money buys your way out of anything, as long as it isn't criminal).
What damages to assign ? Well, seems reasonable to say "how much for 500 lines of code ? A week's wages ? Okay, 2500 dollar damages awarded". The other party might become scared because other developers could conceivably sue, but ...
1) are only available either during a trial or as a last resort (if you can make a good case the defendant won't pay even if the judge compels them)
2) you'd still have to prove more damage will be done if injunction isn't there. Those have to be real damages, with real monetary amounts on them.
This is western law, it's practical. Anything you do that either doesn't bother anyone, or you prevent damage from occuring is legal, no matter how much it is against (civil) law.
The fact that something violates copyright, by itself, is not sufficient to get anything done in court at all.
If it has "no clear copyright owner" because it comes from an entire community and has a ton of copyright holders for little bits of the code here and there, then it means that every copyright holder can sue for breach of copyright.
If on the other hand it has "no clear copyright owner" because it was written by one person under a pseudonym and that holder is almost surely never going to come forward to prove that they are the person intended... then it's de facto public domain even if that's not its status de jure. If you really want to push it in court, you can say that you met the person in-person at a conference and that they verbally told you to do anything you want with it: unless they stand up to say "that's a total lie!" there's no way of proving, because just because some code C has been licensed to a million people under the GPL, it doesn't mean it hasn't been licensed to one other person under the WTFPL.
As for how this could happen... It could be that everything suggests that they never want to come back, like the apparent disappearance from Earth of Satoshi Nakamoto; it could also be something with more stake, for example if Ross Ulbricht had gotten out of the Silk Road business and GPLed his code as the Dread Pirate Roberts before he was caught; in that hypothetical universe, nobody would want to prove that they were the DPR until some statute of limitations for running the black market had passed.
And that's a shitty thing to do which I 100% disagree with, but at least it gives lip service that they are doing something wrong. If what this reviewer says is true, the company just told him no.
That's not ignoring copyright/GPL, that's laughing in it's face.
Edit: BMW apparently did not do that, I probably read that somewhere that had an axe to grind...
It required a second request, and BMW's internal bureaucracy took some days (or weeks?), but they did fully comply.
http://www.theregister.co.uk/2016/03/30/bmw_complies_with_gp...
I dare say if this were a major manufacturer, more effort would be made to make them behave, but we're talking about a short-run switch here.
If there ever becomes a mechanism to DMCA-takedown physical products on an international level, we might see some movement here. But China (et al) would never, ever agree to that. It's hard enough to get them to block things that clearly break international safety standards.
Same applies for this device. If a mfg is infringing on copyright then shouldn't we have a mechanism to stop it from being imported?
It strikes me that we have two laws in this country. The laws for those with money/power (e.g. MPAA to protect US corporate media interests), and then those same laws that are not applied to protect consumers. Is the only difference that MPAA has lawyers to ensure copyright infringement stops while consumers don't?
This might actually do more to confirm than dispute your comment about "laws for those with money/power", though.
- Containers are MASSIVE. Seriously. You can fit hundreds and hundreds and hundreds of thousands of plug-sized widgets in a container.
- Millions of containers leave China every day.
- People lie about certification, provenance, component specs. Even if you do test one, the next 999,999 are probably all using shitty capacitors.
- There are many ports that don't all share data.
The only stuff that gets refused are where you have repeat offenders coming into the same port with the same dangerous stuff.
And yes, MPAA and other trademark bandits with all the cash can pay to police this stuff. It isn't fair... But I'm not sure the world would have the appetite for absorbing the costs in import tax. A testing container of plugs would push the price up way beyond $30 a unit and that's testing 1/1000.
Demanding certified manufacturing might be an option but that's expensive for China so they'll resist (or do a job equally shitty as the plugs they'd be supposed to police).
I'm sure you're a fine person who would keep paying but do you think everybody would because it's the right thing?
That's all that's happening here.
Madness. And people wonder why there's so much skepticism about IoT being adopted by non-techies.
Things are getting better. There will always be more crap out there than good stuff. That's why walmart is so popular, but things will generally improve.
Go to your local home depot and look at all the home automation stuff. Its all no-name garbage and the stuff I recognize still aren't getting things right (all the QA problems with the nest, the documented security issues with garage door openers, everything relaying on the OEM's servers to keep things running with no fallback or no non-cloud options, etc).
[edit:spelling]
Solutions in search of money before the market wises up to how crap these products are.
The real question in my mind is whether the devices will be using proprietary protocols to communicate with centralized corporate cloud servers, or some kind of open, interoperable mesh network. Right now I don't like the way the trend is going.
Seriously why have NO companies come forward with products like this. I'd buy a house worth if someone did.
> I could for example setup one to automatically
> power cycle my cable modem and router
Previously I had an Airport Extreme that was fantastic but didn't have UPnP which is more or less required to make our two XBoxes work. Right now I have a DD-WRT Buffalo N300 in front, with the Airport running most of the network and the wifi behind it. So far that's been the best solution.
*The components are simple & generic, the interface & controls are mostly based on a universal framework w/ their proprietary gui/front-end locked on.
Second because I'm not at all a hardware guy.
Thirdly I'm not at a point where I feel entrepreneurial yet, I don't have enough experience.
Lastly I'm incredibly lazy.
As for the providers, I have to admit, a service economy cannot sustain itself using only transactional relations. In order to ensure future revenues, a contracted service agreement &/or proprietary walled garden approach is the only sustainable model they have come up with. I am a 'break-fix' geezer stuck in my ways and don't subject my clients to lock-in, but my widely varying income from month to month can make affording life difficult at times.
edit: +&/or proprietary walled garden approach
I want them to sell me the product and then politely f*ck off so it keeps working. :)
1) Full firmware source code and required toolchains/sign keys/... be submitted to the national libraries, to be kept for secure archival until the device is officially unsupported by the manufacturer.
2) For networked products, the full source code must be either published, or licensed institutes must perform a security check.
3) There must be provisions in place to ensure timely reactions in case of security issues. If the manufacturer does not respond to security issues, national libraries have the right to release the source code.
4) Required tools, service manuals, datasheets etc. must be submitted to the national libraries.
This should basically kill off GPL-abusing companies, as well as ensure serviceability, even for discarded products.
http://www.ul.com/cybersecurity/
How good or useful this will be I don't know. But clearly they see this as an area where people will be looking for some expert help; not everyone has the skill of a Linux kernel hacker to check these things for themselves.
Turn on lights with a phone? No need for Internet.
Open doors with a fingerprint? No need for Internet.
An auto-adjusting energy-saving thermostat? No need for Internet.
A fridge that knows the milk is low? No need for Internet.
Charge people money to use their toaster? You need the Internet for that.
All that IoT stuff doesn't need Internet access. Hell, most of it doesn't need much of a network at all, but just having them default to intranet would deliver all the value without the problems (and the rent-seeking).
This is lightyears better than that, and yeah they fucked up a bunch of stuff, but it at least shows they tried. Even shitty AES is going to increase security over plaintext...
It keeps honest people honest.
But if there is a vulnerability that lets someone use this plug to pivot an attack on the rest of your machines in your network, now it's a big fuckin deal.
> Right now, the cloud - especially for IoT - isn't a healthy ecosystem. Your shiny new smart thermostat might as well be dialing into AOL on a dedicated landline. And unlike public services, these proprietary service providers lack long-term guarantees of service availability.
> What we need is a push for openness and interoperability in the cloud, and that will only happen if consumers demand it. The service providers are incentivized to do just the opposite.
Personally I think that is the opposite of what we need. Most IoT devices should be local-network-only. So if by cloud you mean a personal cloud (local network or VPN), then yes, I agree. Otherwise keep the interwebs away from my thermostat.
Maybe what we really need are more consumer-friendly, self-hosted (and secure) home VPN options. That way you can just run your services on the local network, and still have remote access without opening your devices to the world (or to other companies' servers). Until the average grandma can do that, the "personal cloud" idea will probably be overshadowed by manufacturers' desire to provide proprietary remote access options, because those go hand-in-hand with things like subscription pricing models, data mining, etc.
Overall: the hardware seems fine, the software is shoddy and the security is terrible
This article begins and ends with two great tl;dr for IoT. There is value in this. Just look at the prevailing cluelessness, and be much better than that to stand out from the pack. In fact, how about applying that formula to the next nascent big thing that comes along?
Point two comes in play only if the user experience is horrible, otherwise it's acceptable.
Regular consumers rarely think about point three.
The point being, the business model of IoT is literally lending you a device that due to purposefully shitty engineering is not useful if you're not paying the rent. I wish there'd be a founder that cares about making stuff that's primarily delivering value to the customer, but in IoT space, I'm yet to hear about one.
https://home-assistant.io/blog/2016/04/05/your-hub-should-be...
I'm not expert in the area, but I would imagine a standard API could be implemented to handle the vast majority of use cases. Connecting to an app securely, turning things on and off, basic scheduling.
Openwrt is powerful enough to take care of logging, connecting to the internet etc, and the sensor units can form a pseudo mesh using their wifi capabilities.
Last I checked, OpenWRT did not do security updates, and it's up to the user to recompile everything if they want newer versions.
https://en.wikipedia.org/wiki/Inferno_(operating_system)
That gets you:
1. Communications between devices are encrypted by the OS.
2. Access to the devices are handled with simple file-permissions.
3. Feature-providing utilities can be run either locally (i.e. on the device's CPU) or remotely (on some hub-CPU.)
Maybe in another decade or so IoT will make sense other than as something fun to experiment with.
The Hue lights are great but expensive. The Hue switch made things a lot more useful as well. I'm waiting for them to come out with a compatible light switch so I can control my recessed lights the same way as my light bulbs.
What they need to work on is a better outdoor camera with motion detection that doesn't get triggered by shadows or wind moving a tree branch. I've tried almost every solution and none is acceptable.
The nice thing about Hue is that their bridge can run completely disconnected from the internet and still respond to RESTful API requests, which means that when Phillips end-of-lifes Hue my bridge will keep working with Home Assistant.
(fast enough for streams in 'real-time' - I don't know)
If this thing is capable of running OpenWRT, it can run some sort of SSL for what it needs. Might be tight and might have to not be OpenSSL, but it can be done.
Lesser-capable devices may have issues. But note that one way or another, the devices must speak some decent encryption to get on to WPA2 networks. Of course that's probably done in the Wifi hardware, but it still shows that it's not like we're living in the 1980s where we literally wouldn't have been able to afford the silicon in a consumer device. Hardware acceleration of SSL shouldn't be that hard to get a hold of, for instance: https://en.wikipedia.org/wiki/SSL_acceleration#Central_proce...
I say only "reasonably" because defending against the "I cracked into the device and stole its cert" is pretty hard, but I'd submit, also not all that realistic a threat in this case. I'm really looking to defend more against "I bashed together some encryption so crappy I can hack this by making you visit a hostile web page" than "I want to use this lightbulb without the NSA knowing". (On that note, an SSL cert only valid to a custom app that your browser won't accept isn't all bad, it prevents that sort of thing.)
I mean, this it total pie-in-the-sky in terms of the ask I'm making here for security knowledge and willingness to do something correctly instead of bashing out some terrible, incorrect crypto with direct and incorrect use of the primitives. But it's possible.
Actually... I won't call myself an SSL expert per se, but one of the things that I find personally frustrating in dealing with some people is that once you do know what's going on, using SSL is often much much simpler than bashing together your own crap crypto. Any sensible SSL library has places to stick the CA certs. Generating them isn't that hard, more just tedious. Generating a big pile of certs at the factory and siging them isn't that hard. Even if you're very sloppy with your SSL usage, where you don't do a great job of protecting your core cert, where you use the root of the CA instead of an intermediate so the private key of the root is "live" in the factory, you don't set up a good revocation solution and you just set the expiration as far into the future as you can, because you probably haven't got a mechanism for updating them... even if you make all those errors, it's still better than just bashing crap crypto together, because it'll still resist more attacks than your crap crypto and it's not really all that hard.
But I have abundant experience that shows people would way rather futz around directly with RSA keys and HMAC and spend days and weeks scraping something together rather than even entertain the suggestion of doing it even half correctly. I don't fully understand it. Do other people find futzing with crypto that fun? I play defense a lot in security, but I honestly find correct crypto a royal pain in the ass and do everything I can to outsource it via SSL (which may not be perfect but isn't necessarily bad and has the advantage of being very defensible when people ask "what do you do to secure things") or NaCL or something. Is it just the psychological difficulty of admitting that you don't really know what you're doing with this crypto stuff? I dunno.
If the user really cares about security enough, they can buy their own real TLS cert and install the cert on the brick.
Of course, one person steals that cert and they've cracked the system wide open. But that's the default case for crap crypto anyhow, so what's the difference, except you spent about 10 minutes in the shell and passed some parameters to your library instead of spending.... well... anything more than 10 minutes futzing around with AES and RSA and so on?
Also, while I understand your use of "nobody" in the slangy English sense rather than the strict mathematical sense, I would point out that as these devices get more sophisticated, eventually they tend towards a manufacturing process that will do something to each one in the factory anyhow. For instance, if you're doing any sort of burn-in testing you've already done the vast bulk of the hard work it would take to also use that time to stick a cert on there. Yeah, your cheap knock-off Wifi light won't do that, but as the industry matures I think you'll see practices that would permit certs without much additional work.
That's not to say that you can't do encryption though, just that you need to rethink how to do it, where the solution is not just unencrypted JSON APIs.
Also, all of this can be done with plain openssl, there is no need for additional tools.
[1] https://blog.cloudflare.com/introducing-cfssl/ [2] https://www.vaultproject.io/intro/
oh baby!
Is he the author of one of the libraries it uses?