> 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!
Would you feel comfortable with end-to-end encryption via an open, documented, free protocol? This is literally my raison d'être as a company, so I'd be interested to hear your comfort level.
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?
I've been debating about hooking my garage door opener up using a built-in feature so I could open the door from my iPhone. I don't trust that whatever central site I'll be connected to is safe. If I _knew_ the vendor had implemented your protocol/software well, and I _knew_ your software was safe, yeah, I'd use it. But I don't know those two things, so no way am I hooking my home's door up to the Internet...
In my case you actually do know that the vendor is using the protocol. You would have to be running the protocol on (in this example) your iPhone in order to talk to it. Everything is client-side verified and enforced by encryption.
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.
When you say I'd have to be running the protocol, wouldn't I really be running their garage door opener app? In other words, how do I know your protocol is being used?
If they were using the protocol, they have two options:
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.
With #2 do I know they are using your additional install? Would your app indicate their app was a registered client and was sending commands through it?
It certainly could, as it has full knowledge of what's connected. That's quite a ways down the road though; for now we're focusing on Razpi <-> computer. Mobile deployment is much more complicated (also a much larger market though).
Definitely. First a disclaimer: I've held off on creating a dedicated post for this until the code is stable (as in not crashing) enough for other people to play with the demo. That will hopefully happen tomorrow, or possibly Friday. At that point I'll be posting here on HN as well as several subreddits. Until then, I'd request it not be posted on social media, so I can maximize the impact of the potential exposure.
So totally this. I refused to buy a Nest for exactly this reason. In the words of the Cluetrain manifesto: 'We are not seats or eyeballs or end users or consumers. We are human beings - and our reach exceeds your grasp. Deal with it.'
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.
Apparently this is kind of a hard thing to handle. I battle with this and PS4 Remote Play -- about 80% of the time, RP will give up looking on my local network and go out to the internet to find my PS4... which is right here on the same network. If I cancel it and retry a few times it always ends up seeing it but man what a pain.
We've been using the term "endpoint hostile" to describe how networks are typically deployed, especially with IPv4.
"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.
This is exactly why the use of a remote server exists in so many IoT devices. Widely deployed home APs, even in USA, come with device isolation on by default or even not disableable.
IMO: this is actually a good default setting. Home-router designers should assume that things are hostile by default. Of course, it should be dead-simple to turn this off as well.
So you're in favor of Grandparents getting cryptowall from someone else connected to their WEP-encrypted wifi because screw them for using Windows XP and a cheap router? Off-switches for things like this are cool, because people who need them will find them, and people who don't won't.
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.
Yes, if this is the cost. Loss of local connectivity is not a small degradation. It's like losing floating point math from your CPU or the ability of your car to go in reverse.
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:
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.
Also worth pointing out that the reason everything talks over HTTP now is because companies figured out that the only port on a typical user's computer that can be assumed to be free of bullshit pseudo-security rules is the port 80...
It's closer to losing ECC; if you need it you can get it and if you don't need it you don't even need to know it exists. You're being rather alarmist, don't you think?
> 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.
I also believe that trading real networks for supposed security would be a very bad move.
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.
If you are OK with building it yourself, you could do this with an ESP8266, a USB to serial cable, a solid state relay, a power brick, and some miscellaneous things like a power cord and a socket (and ideally some case to put all this in for safety).
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.
Don't even need to make it yourself, Itead sells the Sonoff for $4.85 + S&H. It's an ESP8266 connected to a relay, with integrated AC-DC power supply and a properly designed, physically isolated PCB.
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.
Get a power strip and a electrical enclosure from the hardware store or you can get a replacement appliance cord+wall outlet+electrical box. Also get a outlet wiring tester to make sure you wired it correctly (eg: didn't get hot/neutral/ground mixed up)
Make sure to put a 10A fuse in series, use wire rated for 10A and pass the ground wire through.
To add to this, the whole board pops out of the protective plastic enclosure with minimal effort and is pretty compact, so if you wanna build your own enclosure it's pretty easy.
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.
> If I choose to expose this over the internet, great!
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.
I'd argue that these guys are actually supplying. Just firewall it out to a specific network segment for these devices, have one box that interacts with it and modify it to your own liking, you have root on it afterall.
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.
heh, that's actually what I kind of do now with a couple of devices. Then I ban that vlan from the internet. I'm speaking more in general though: Too many IoT devices require cloud access to work properly. I don't want to put a hacky solution together, I'd rather things would out of the box. I don't like the idea of having to be defensive against my own equipment.
That's the part of the business model. IoT isn't about giving you some value - it's an extension of SaaS, but with the twist that it has to convince you to give service provider some value that they can then sell back to you.
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.
HomeKit works with non-Apple connected devices like lights, switches, cameras, locks, etc. Apple doesn't actually make any such devices themselves. But as far as I know, you need an iOS or tvOS device to actually run the HomeKit framework and connect the devices together.
I applaud Apple for trying to make security for IoT devices less shitty. That said, Apple has never been able to make cloud services work well, and when they work at all they don't work on non-Apple platforms and they tend to get worse over time. So yeah, Apple's not an option for my home control needs either.
Or you implement a HomeKit bridge in software and use that to make non-HomeKit devices available in HomeKit, e.g. using
https://github.com/nfarina/homebridge
I don't believe you need a custom chip, but HomeKit does require some advanced crypto that many low-end embedded devices probably can't support. See the dependency list for this open source Go implementation of the HomeKit Accessory Protocol: https://github.com/brutella/hc#dependencies
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.
I'm in the same boat... Spent a couple years looking for a wifi thermostat that didn't require a cloud service. Actually I purchased a couple and hacked on them, but never hooked any of them up to my AC unit. Granted I had some pretty specific requirements (long list having to do with multiple zones/etc).
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.
Well, I've been building my own with rpi's and whatnot. But I'd love to save time and just buy an off-the-shelf product that's been thoroughly tested, etc.
Agreed, I am following the same route. In many cases, I want my gadgets net-enabled primarily for timekeeping, since a lot of automation for me is really scheduling (and having to manually trigger things remotely is an edge case).
I have that, based on zwave devices. Can be bought off the shelf, requires some tinkering to set up usually when you want to do something that's not trivial, but is as flexible as you want it to be. Can run on raspi, there are diy sets for it etc. Ppl bitch about zwave being 'proprietary' but it's open/documented enough to be hackable to your heart's content.
Personally, I don't want to invest into a closed platform. Hackable solutions are nice, but I've purposefully avoided zwave because they aren't open source. Maybe I'm naive, but I'm holding out for something that actually is open-source, not seems to be open source.
Having never used zwave though, it sounds like your point is valid.
We're working toward some IoT developer products designed to allow global p2p connectivity for IoT devices over networks the user can control: https://www.zerotier.com/
ZeroTier already runs fine on embedded Linux, which is a large subset of IoT, and we've researched a lightweight port to FreeRTOS.
You could install it on a device and then remotely access it. The software handles a lot of complexity for you. We're working with several vendors about incorporating it as a network layer and then using our (to be released soon) SDK to allow iOS/Android apps to directly access things.
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.
Well, there's no point in waiting around for a company to make a local service their device connects to for us, since the incentive is not to deliver what we would really get the most use out of, but to deliver something that maximizes their revenue, likely though only accepting other devices of the same company, or those that have licensed access in some way. If we make a system that can be interacted with, we'll get some cheap cheap manufacturers that use it because they'll try anything, and if it catches, either we'll have a good system, or more likely, manufacturers will band together to create their own standard that's technically not as good but more likely to be supported widely.
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?
This is a genuine question, and I think I've come to the opposite conclusion as you. You write:
>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.
I think your severely mis-interpreting what I'm saying.
> 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.
So there is a great amount of lists, blogposts and information about awful/bad IoT things, but if someone like me want to have a list about IoT things that are actually secure and well-working, where would I find that?
It's not that easy. I stick with brands/products that are reviewed by people I trust or have seemed to pick up some momentum.
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).
It doesn't bridge directly to real IP, there will be a 'hub' somewhere. You can't talk directly to the devices from any PC or mobile on the network, which is less convenient but reduces the attack surface to just the hub.
(It's also much more power-efficient; you can't really use wifi on battery powered devices unless you charge them frequently)
I've gotten an ESP8266 device to last for about 3 days with (2) AAs when in using sleep mode aggressively for the wifi. Not to say that the Python stack is stable on it. It's not.
Insteon isn't bad either. Though it's proprietary, which is a big downside. But without you setting up a Hub or software on your PC, the hardware has no way of talking to the Internet. (And most of Insteon works without a Hub or PC even!)
Say you wanted to build a protocol for IoT stuff. What would be on your feature list?
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.
Isn't this idea hiding the problem though? While using uncommon hardware and protocols may thwart certain users, it's really not solving the problem of security. It's somewhat similar to the idea of using a hidden wireless network and calling that security instead of securing your network with WPA2, etc.
As these devices become more popular, we'll start seeing more Zigbees and Z-wave devices become commodity hardware.
Not at all, anyone can "join" the network, but nobody can decrypt the traffic without the key.
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.
I've installed tens (if not hundreds) of thousands of Zigbee devices over the last handful of years. Zigbee may be uncommon in residential, but it is not uncommon.
Compared with wifi, though? Trying to screw with your wifi equipment requires just about any laptop sold in the last ten years. Trying to screw with your Zigbee equipment would presumably require me to go find some kind of dongle.
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.
Sure, in the world there are probably more wifi devices, and I'll agree that wifi adapters are as mainstream as it gets. But just because the hardware to mess with Zigbee stuff isn't consumer mainstream doesn't mean the devices don't exist and aren't "used that much," as the comment OP incorrectly claimed.
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.
None of those are actual finished products (except for the amazon dash... which also isn't really a product). There's hardware and software components and recommendations, but (perhaps tellingly) no "IOT thermostat" or "IOT fridge".
I'd love a list like that as well, but sadly I don't think one exists and I don't think there's any money in doing it. Nobody wants to hear about good IoT devices, they want to make fun of bad ones and feel superior, that's what sells clicks.
I've been to a conference literally sponsored by a door knob manufacturer. But they don't target "end users", they target the people you hire to design and renovate your house.
Similarly, the home automation solution targeted at those people usually aren't shit cloud-based products.
I think you nailed it: hackers don't want to write blog posts saying "damn, this thing was pretty well made".
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.
I'll write one when I find something worthy of it. I've got stupidly high standards though.
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.
It's not just that people don't want to write about it, it's that people don't want to read it either.
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.
People don't want to read it, otherwise the front page of HN would be carpeted with astroturfed 5 star reviews of bad products. (See also: most Amazon reviews)
>It's running Linux and includes Busybox and dnsmasq, so plenty of GPLed code. I emailed the manufacturer asking for a copy and got told that they wouldn't give it to me, which is unsurprising but still disappointing.
Has the GPL really lost it's power that much? I mean not responding to inquiries is one thing, but outright saying no?
Lost its power? This is just copyright apathy. Nothing new, especially in China. Look at it from the manufacturer's point of view. They know how expensive this would be to take to China and prosecute and they know they're a tiny fish. It's simply a reasoned gamble that saying no is the fastest, most efficient way to get this dealt with. Much easier than auditing the code, having the developer separate out sensitive data, etc. Well before you consider the long term archiving of this stuff. They're probably already making the next generation of this rubbish.
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.
This makes me wonder how imports are handled. If I can buy a third party power supply from a US based order system (amazon), and this ps is dangerous (eg. those knock off Apple power supplies). How is this legal, presumably the device hasn't passed safety regulations here. So, there must be some way to stop this product from entering the country. Why isn't that mechanism happening?
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?
I cannot speak to copyright, but there seem to be mechanisms in place for stopping import of trademark infringing goods to the US. See for example the run-in which SparkFun had with importing lookalike Fluke Multimeters a few years ago: https://www.sparkfun.com/news/1428 and previous HN discussion here: https://news.ycombinator.com/item?id=7428799
This might actually do more to confirm than dispute your comment about "laws for those with money/power", though.
There are mechanisms for policing (certainly in the UK) this but:
- 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 also curious how many manufacturers (especially of questionable-quality products like this) simply don't bother to read and understand the licenses of the OSS they're using. I suspect it's a lot.
Pretend that you knew you could get away with not paying tax or keeping records. You might get an email from the IRS but in this imaginary world, they only prosecute the biggest cheats.
I'm sure you're a fine person who would keep paying but do you think everybody would because it's the right thing?
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.
Well, if it's a project with lots of contributors, any one of them can sue¹. If no contributor can be identified, it's probably unenforceable, yes, though IANAL.
¹I believe there are some exceptions, like having contributed only an insignificant fraction of the whole work.
That reasoning works until the judge considers damages. Then let's say it's a small developer, not too much work, and no commercial interest in the code. Damages are limited, in western law, to, well, damages. You need to have suffered a financial loss, the other party needs to have violated the license/contract/law/... and you need to show the causal connection between the two.
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 ...
Injunction is a way to prevent more damage from occurring. So generally speaking, injunctions :
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.
mjg59 is a copyright holder for Linux though. Surely he of all people should be actually lawyering up rather than just telling people not to use this device on the internet.
The GPL is not and has never been magic pixie dust. Ensuring companies and people comply with it costs money thanks to the legal system. The folks at gpl-violations.org and Software Freedom Conservancy do a lot of good work bringing companies into compliance, including helping Linux developers to sue VMware for their infringing use of the Linux kernel.
I've heard of companies like BMW (not true, see edit) just ignoring requests for GPL code, or promising to release it but just never doing so.
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...
You're only required to distribute sources if you modify them _and_ distribute the resulting binaries right? Is there any evidence that the busybox and/or dnsmasq binaries are anything besides the normal stock installation? The customization is in other binaries that need not necessarily be GPL it seems.
> Eventually I plugged my phone into my laptop and ran adb logcat, and the Android debug logs told me that the app was trying to modify a network that it hadn't created. Apparently this isn't permitted as of Android 6, but the app was handling this denial by just trying again. I deleted the network from the system settings, restarted the app, and this time the app created the network record and could modify it. It still didn't work, but that's because it let me give it a 5GHz network and it only has a 2.4GHz radio, so one reset later and I finally had it online.
Madness. And people wonder why there's so much skepticism about IoT being adopted by non-techies.
As a counter example, my brother who never uses a computer setup his chromecast in 5 minutes with zero help from me. I know b/c he called me and asked for help. I told him he wouldn't need it, but he didn't believe me.
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.
I don't consider Chromecast as being part of IoT. Chromecast is mostly used as an internet media device, whereas I usually interpret IoT as slapping Internet capabilities on traditional appliances (light bulbs, fridges, whatever). Curious what other people think.
Only in as much as it lets you access content streams on the Internet. It doesn't let you control your TV via the cloud or anything. In terms of functionality I think it's pretty comparable to any other content stream you can hook up to your TV, going back to Ataris and VCRs.
Sure, they're getting better, but only with big name manufacturers like Google.
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).
The Chromecast has the advantage that it can tell you what to do (and what's going on during the setup process) on the TV; an internet-connected lightbulb or door knob doesn't have that luxury.
a bit off topic.
Why can't somebody sell a reasonably priced Thunderbolt 3 eGPU enclosure. Oh right intel's certification process takes several months... All in the name of quality assurance yet most thunderbolt 3 products feel subpar considering their price.
I have the same view, but there are all these companies investing billions into it, so there's something I don't see?
It's like this is being rammed down everyone's throats. IoT is heralded as "the next big thing" and nobody want to miss out on it. Which means everybody is investing and developing it, which means it will probably become a reality. A self-fulfilling prophecy of sorts, which is kind of sad because IMO it's not a particularly compelling vision. There are thousands of things we could improve rather than placing chips with sensors everywhere.
Chips with sensors everywhere is inevitable; both are cheap and getting cheaper.
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.
There's so much potential in the market for proper, well made IoT devices that would bring around the hardcore skeptics like myself. I mean really well made products, properly encrypted with well made API endpoints that come with good apps for the uninitiated -AND- the ability to be scripted and automated by the techies. (You can do both, there's no reason why you can't and I don't understand why everyone refuses to). Oh, and not having them phone home to who-knows-where-istan around Australia, or at the very least, having the ability to TURN THAT OFF.
Seriously why have NO companies come forward with products like this. I'd buy a house worth if someone did.
The commercial side of building automation is robust, but the components are pricey, the platforms proprietary* and end-user aavailibility seems to be limited. The beauty of the other side is every switch, sensor & controller's first objective is not to monetize the user but rather to simply do it's intended job. Look into building automation controls and you will find what you yearn for; Siemens, Johnson Controls, Honeywell/Novar, BAS... However, retail/public access, setup & end-user friendliness will still be significant hurdles outside of hiring a pricey, authorized contractor.
*The components are simple & generic, the interface & controls are mostly based on a universal framework w/ their proprietary gui/front-end locked on.
That's what I'm getting at though, there is clearly a market for consumer ready devices that don't cost what solutions like that do and don't need a contractor to install them. I mean you can't tell me that in today's world we couldn't manufacture an outlet with electronic control of the flow of current out of it's outlets, and do it in such a way that uses proper SSL and endpoints, without having to price it so high? I don't believe it.
I totally agree, the demand & the means exist. However, the intent of retail providers is anything but enabling simple, automated controls. Everything is about grabbing the data cash bag and, as an afterthought, let's personalize your experience. I have been pondering this and the only conclusion I can come up with is the market controllers(more than mere "forces") have much to gain by selling the perception instead of reality and their treasure troves of patents(from commercial side) allow them to maintain this position. IMO, the digital revolution of ours has transformed sharing into one way collecting and the consumers into commodities. Both of which I find quite offensive, and sometimes, outright hostile. Alas, our money is our only true vote. Vote accordingly.
I suppose but it still seems like a copout (not on you of course, on them) to play the brand lock-in game. You don't need a centralized server to personalize and operating those servers, even on something like AWS, costs money. Why not put that on the consumer instead? Many consumers I know would prefer the roll-your-own solution and it saves the manufacturer money.
Thanks for your manners, but it is probably a copout on my part. I have the wherewithal(-money) to build something like this in my own home but I believe most of these controls are over-engineered progress for progress' sake... for anything less than a few thousand square foot structures. All I really need is a programmable thermostat, a couple timer plugs & my 'routine'. As always, YMMV.
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.
But this is assuming that I expect something beyond the transaction. I don't. I expressly DON'T want a continuing relationship where Nest decides my perfectly functional thermostat no longer works or that Phillips decides their controller is only going to work with Phillips light bulbs.
I want them to sell me the product and then politely f*ck off so it keeps working. :)
Well, we are on a something.ycombinator.com website right now... why don't you throw together a prototype, register a company, and present to ycombinator?
Which problems do you want to solve with these IoT devices? What should they do? In my opinion existing IoT devices generally replace simple, proven systems with complex and abstruse ones.
A good example would be the smart outlet ones, so I could for example setup one to automatically power cycle my cable modem and router, or even one that could handle the load of a space heater I keep in my office during the winter months and switch it on 15 minutes before I get home. I don't even need the ability to manage it over the WAN, I'd be fine with just something my linux boxes at home could handle with cron jobs.
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.
I'd like regulation agencies to mandate, as a condition of market entry, for each and every electronic product:
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.
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.
Completely agree except the light argument -- having my lights cloud connected allows me to control them remotely. The main use for this is for time or sunrise/sunset scheduling. However you could quite easily architecture this without cloud connectivity, it seems easiest to keep the bulb dumb and keep the 'smarts' elsewhere (whether that's on a phone locally or a server in the cloud).
Scheduling isn't stock market, you don't need a live feed for that. All such a bulb needs is an accurate date and time source - the rest, including (if you also add one-time geographical area input) the sunrise/sunset times can be determined with a little bit of trivial math on the uC that said "smart" bulb already has.
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).
I would say the principal reason they need to be connected is because consumers expect it. But yes, some unscrupulous businesses will take advantage of that. People need to vote with their money and not buy from companies that do this.
Consumers don't expect it, but they are being told they should. That's marketing at work, literally trying to create the market for this shit-engineering non-solutions.
IoT devices can be fine, but there are lots of companies involved in it that don't know what they're doing and would be better off staying out of the market. I always advice friends / family to look for upgrading capabilities, ability to do useful work when not connected to the Internet proper, user control (do you own this device or effectively borrow it per licensing etc.?), and other similar things before purchasing any IoT device. Some IoT devices are great, but some are abysmal.
And it sounds like this one was like 80% of the way there. I mean they used encryption (badly, but they still used it), had a way to update the software on the device (even if only over http), and uses passwords (although doesn't enforce them).
Come on, the last thing he reviewed sent everything in plaintext, had no root password, called out to multiple chinese servers, ran ssh via a hardcoded password that was something like a simple word, and didn't have any way of actually updating the code on the device. Oh, and it barely even functioned as a lightbulb...
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...
Agreed. It may not be technically good, but it's as good as the door locks that hundreds of millions of people rely on to protect their homes every day. Most home doors/deadbolts are easily pickable with a few weeks' practice.
I somewhat agree. Since it's only a plug, if the worst that a hacker can do is turn your plug on and off, it's not the end of the world.
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.
If we can empower users build their own pipes between devices and online services, then we spur competition which could lead to better security. We need a gateway that gives users that choice. I've been working on command line interfaces for devices that can be used to pipe data/state back and forth between command line interfaces. These interfaces to devices and online services can be written in any language and run nicely on small computers like the $35 Raspberry Pi. The downside is setting these pipes up requires familiarity with the command line... But if there was some funding there we could build a UI that was easy to use... So I actually built that, but don't have the time to maintain it. For the time being I'm maintaining these command line interfaces.
>What we need is a push for openness and interoperability in the cloud
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.
That's a fair point, and I agree. However, the reality is that a major selling point for these things is along the lines of "control it from anywhere", and whether people actually need remote access or not, it seems that a lot of consumers still see it as a major upside.
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.
Or change the marketing from cloud connected to owning the cloud. I mean, for someone who would depend on stable Internet connection to be able to control all this shit, he'd be off hosting a personal cloud on the same connection as well. Even better, because if there are operations happening in a local network and WAN goes out, the devices will still operate inside the LAN.
The short version: they introduced terrible vulnerabilities on your network, they violated the GPL and they were also just bad at being...
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?
There's that Upton Sinclair quote about understanding and salary...
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.
Shameless plug to a 100% OSS IoT / home automation system I contribute to that agrees. Everything IoT should be fully open source and not rely on cloud connections:
Sounds like there is a strong need for a standard OS build for IoT devices.
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.
I think openwrt on the main unit (a good router) + nodemcu based sensor units would work well.
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.
Ideally the base should be from a project that handles base system upgrades, so that consumers don't have to trust that the vendor is building security updates in a timely manner.
Last I checked, OpenWRT did not do security updates, and it's up to the user to recompile everything if they want newer versions.
I feel that the people who are now talking about IoT are the same people who were totally into 'semantic web' back in the day. And it's pretty much the same kind of story: "Wouldn't it be neat if all these systems could interoperate?" and again the answer is "Yes, but not neat enough justify the cost and hassle of actually making it happen".
I think we're due for a proper realization of the semantic web in the next couple years. Things seem about at the point where the cost and hassle can be overcome without a significant financial motivation to do so.
Maybe in another decade or so IoT will make sense other than as something fun to experiment with.
The stuff from wirelesstags.net are generally very good. I have a bunch of sensors and their Reed sensors for detecting opening and closing of doors are very good. I hook it up with ifttt and turn on my Hue lights when I open and close my doors. Clearly not ground breaking stuff but useful.
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 wirelesstags.net stuff looks good, but it also is tied to their cloud services. I couldn't find a local API to talk to their bridge device.
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.
Yes that was a concern of mine as well. They stated that if they do go out of business they would open source everything so that we could build our own solution. That's basically what convinced me to go all in with their product.
Does anyone still need convincing? Don't buy anything that connects to the Internet that isn't built and maintained by a major software company. Even then, be careful. Duh.
That's been my understanding as well. The cpu's used typically aren't powerful enough to do anything other than simple encryption in a reasonable amount of time. Ssl is generally out of the question. Someone please educate me if that's incorrect.
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...
But more to the point: there is no purpose to SSL/TLS on an appliance because it will not have a valid certificate, hence it won't protect anything. You might as well just use WPA2-PSK.
If you're using a custom client-side app to access the device, which many of these things seem to do, you can create a CA for the devices, put the public cert for the CA into the app, and issue each device an individual cert at the factory signed by that CA. Then the app can be reasonably secure and assured.
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.
Nobody's going to invest money into flashing each device with an individual cert just to protect against an attacker MITMing a home user's home wifi network to turn off a lamp. And you'd have to bundle your own whole TLS stack and browser with the app just to get the CA validated; that's a lot of extra software engineering.
If the user really cares about security enough, they can buy their own real TLS cert and install the cert on the brick.
Ah, I meant to add to my list of bad practices sticking the same cert on every device. Sorry. To be clear, I'm saying you got me on that one. I missed that.
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.
I'm not a cryptographer, in my hobby project I used a port of nacl to AVR to do encryption. Such an IoT device doesn't need to process a large amount of data for encryption, it can be done on a 8bit uC.
What kind of latency is really an issue here? The payload isn't going to be large for lots of these IoT devices. If it takes a couple of hundred milliseconds longer to carry out the transaction is that really a big deal?
Maybe if you're talking about an Arduino (which is more of a micro controller than a full-on CPU). Anything resembling a real CPU definitely has the horsepower for SSL.
The ESP8266, which is popular for hobbyist IOT projects doesn't have enough memory to do SSL.
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.
Alright so this is mostly OT, but I figured people who are into IoT might be able to help; does anyone know of a setup that would easily let me control a remote AC outlet by plugging a sensor into an existing hard-switched AC outlet? I'd rather not deal with installing a hub and programming scenes etc. Thanks!
I enjoy reading this kind of article about lousy security, because I say to myself "Wow, that was lousy!" and laugh. BUT I still don't know how I could avoid this. I genuinely ask: could anyone share with me the "2016 Guide of the best pratices for securing an API/ a web app"?
Hold on - it sounds like this thing is running Android. Has reference to connecting with ADB, apks, and Android versions. But it's also running a SSH server and OpenWRT? What's going on there, is it running 2 different OSes for some reason, or did they somehow merge Android and OpenWRT?
Funny timing... I just bought an LG LFXS30776S refrigerator and the first thing I noticed was that all of a sudden I had a new WiFi broadcast. Turns out that according to tech support there's no way to shut this off.
Yes. He is a major contributor to the Linux kernel, and unless I remember incorrectly, he was almost single handedly responsible for getting UEFI support in Linux.
Yes, but mainly commercial stuff. It costs 3-10x what the consumer appliances cost but it's usually actually secure and stable. Aruba, Ruckus, Cisco, Meru, etc.
> 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!