“Security” is the proverbial dead horse we all like to beat when it comes to technology. This is of course not unjust — we live in a technological society built with a mindset of “security last”. There’s always one reason or another proffered for this: companies need to fail fast and will handle security once a product proves viable, end users will have a harder time with setup and use if systems are secured or encrypted, and governments/law enforcement don’t want criminals hiding behind strongly secured systems.
This is an argument I don’t want to get bogged down in. For this discussion let’s all agree on this starting point for the conversation: any system that manages something of value needs some type of security and the question becomes how much security makes sense? As the title suggests, the technology du jour is home automation. When you do manage to connect your thermostat to your door locks, lights, window shades, refrigerator, and toilet, what type of security needs to be part of the plan?
Join me after the break for an overview of a few Home Automation security concerns. This article is the third in our series — the first asked What is Home Automation and the second discussed the Software Hangups we face.
These have all been inspired by the Automation challenge round of the Hackaday Prize. Document your own Automation project by Monday morning to enter. Twenty projects will win $1000 each, becoming finalists with a chance at the grand prize of $150,000. We’re also giving away Hackaday T-shirts to people who leave comments that help carry this discussion forward, so let us know what you think below.
I am the Keymaster. Are You the Gatekeeper?
Security from the wider world is what comes to most people’s minds when talking about tech. Is there a risk that someone can open your garage door, turn off your furnace, or watch a video feed of your infant? I feel like this is a solved problem: every home should have a properly secured router for their LAN — the same holds true for Home Automation. It should be a walled garden.
If you’re with me on that thought, this becomes a standards issue. WiFi devices work across different hardware and throughout the world, offering both reliable connections and robust security. But as we heard in a lot of the comments in the last article, WiFi isn’t really ideal for Home Automation so other protocols like Bluetooth and Z-Wave have been tapped.
Software defined radio has become affordable and easy — you would think we can figure out a specification that adds a home automation router in between your walled garden and your Internet router that leverages SDR to speak to all devices. But who will do this work (the IEEE was named dropped last time) and what will drive adoption within industry? Anyone know how WiFi became the thing and what happened to the competitors that didn’t?
Does Your Lightbulb Need Encryption?
There’s nothing quite like a simple light bulb to underline how sticky this topic is. Elliot Williams and I have been discussing home automation security off and on for a few months now and coming back to the same question. If you have your system protected from the wider Internet, do you need to have every device encrypted?
First off, WiFi and Z-Wave already have encryption built into the specification. If you’re using a Flux smart lightbulb, your neighbors won’t be sniffing your packets without that wicked-complicated WPA2 password you use. But does that bulb really need to be encrypted? What if your lightbulb is on 433Mhz and only listens for on and off commands from a hub. How secure does this need to be?
I’m of the opinion that critical automation tasks should never be possible to actuate remotely. For instance, you should be able to shut off your stove remotely, but not turn it on. You should be able to set your furnace to a reasonable temperature or to vacation mode remotely but not turn it off. It’s fine keep your house 50F in the winter and 85F in the summer but you shouldn’t be able to shut if off so that pipes could freeze or pets could perish. How much protection do we need from someone parked at the curb turning your lights on or off?
The Weakest Link
The final concern I’d like to hear from you about is a weakest-link issue. If we build our walled garden to protect our devices from the big-bad Internet, do we open up a local attack vector for our entire system? Can you sit at the curb, spoof my light bulb, and make it to the sensitive documents on my server thanks to Home Automation devices being trusted on the LAN?
We want to hear from you. What is a reasonable level of security to aim for as we build up Home Automation on every block and boulevard. What did I miss above, and how do we plan for the unforeseen?
To answer that you need to answer the WHY question. Specifically, why do you want your thermostat, door locks, lights, window shades, refrigerator, and toilet connected to anything. If your answer is “because it’s cool”, that requires much less security than “because I want to reduce my energy consumption… somehow”.
I strongly disagree. Why do people have WiFi? Because it is cool/convenient. If you really care about security, switch to an all-wired network. Is that practical? Not really. Why does “cool” and “secure” have to be mutually exclusive?
Who said they have to exclusive? Why do they even have to be linked?
Mike is asking how much security is adequate and I’m saying that depends on why your toaster is connected to your toilet in the first place.
If you’re a manufacturer selling IoT devices because early adopters will pay extra and you’re protected from culpable liability due legal loop holes…. security is of little concern.
If your IoT Christmas lights are insecure, allowing anyone to change colors, probably don’t care about security.
If your motorized blinds in your bathroom can get hacked and all that’s at risk is your ego and the company’s image…. meh.
If you’re trying to live out some bad 80’s movie scene where your pre-loaded toast pops JUST as you walk past, catching it in mid-air, then you probably care about security so your house doesn’t burn down.
I think a better article would explain why/how IoT devices should be inherently safe, not necessarily secure. Too often a microprocessor handles everything in hardware with no mechanical safeguards. Only software ensures ‘bad things’ don’t happen.
If your IoT house water system is hacked and orders itself one million replacement filters, no big deal because you can contact them and get out of the bill. If that same water filter can somehow poison you due to the manufacturer using the same processor which handles network communication to handle which valves can be open simultaneously…. Security is required simply due to poor design. I think MOST IoT devices fall into this category.
All-wired is a lot more practical than many people here give it credit for these days.
If you own the house then it’s a no-brainer. Just do it.
If you don’t… lot’s of people use the excuse that they can’t run wires because they live in an apartment. I ran wires in several apartments back in my college days and some years beyond until I got a house. I never got in any trouble with a landlord.
First.. 99% of us own furniture. For most of us, especially in apartments where space is often constrained the only place that the lower walls are really exposed are the walking paths, the doors and hallways. With a little creativity you can probably run the majority of your ethernet wires just by dropping them against the wall behind the furniture. There will be a few places where you have to cross walkways or walls but with a bit of creativity you can reduce those to a minimum.
For crossing a walkway… there is always the time tested tradition of just throwing a rug over it. How hard is that? Don’t do it with power wires as they might get hot but Ethernet should be fine. Don’t like extra rugs on your carpet? Just run the wire under the carpet. I have done this in several apartments. I have never lost any of my deposit this way. Just plan the run for the most narrow spot such as across a hallway. Pull the carpet away from the tackboard over just a couple inches length, both sides of the run and run it through with a coat hanger. When you are done tuck the carpet back in as best you can. Do the same on move-out day when you remove your wire.
Need to go through a wall? Still not that hard! Method 1.. just drill a hole. Do this as close to the floor as possible, preferably near a corner and it will not be very noticeable. This worked in my first several apartments and no landlord ever noticed or complained. Key here is keeping the hole small and low. If it’s low enough and you have a bushy carpet then the bristles might even hide it after you remove the wire to move out! To keep your hole small you might have to learn a new skill… crimping RJ45 connectors. Fitting the connector on the end of the cable through a hole means you need a big hole. Fitting a cut off wire through.. not so much. If this scares you then get over it. It is not hard and the tools to do it are not expensive anymore thanks to the internet. If you only ever need to do this when you move to a new apartment it’s not like you need an expensive, professional quality crimper that will survive 100s of crimps a day for years. A chinese cheapie will do just fine!
Method 2… Is the apartment wired for telephone or cable? Is there a jack on the wall for that and another jack on the adjacent room in the same location? Just swap out the existing wall plate for one that has the requisite cable or telephone jack AND an ethernet jack. Do this on both sides, cut a little piece of Cat-5 and crimp it into one of the plates before you install. (Actually, even cheap CAT-3 will probably work since it is only going a few inches) Push the wire through and install the plate. Now crimp it to the other plate and install that. Ta da.. you have a nice ethernet feed through.
Method 3. For some reason many cable and phone companies don’t install their jacks that way, back to back on both sides of an interior wall. It seems obvious to me, two rooms wired for the price of one fish! Usually when I have ran into this one of the rooms was a bedroom which simply didn’t have a cable tv or telephone jack. So.. just give it one! To do this I remove the plate in the room that has the jack. Then I drill through the back of the hole into the next room. Now I have a guide to know exactly where to cut. Just enter the next room and cut a little hole around the drill hole. Now you can treat it just like method 2 above… put plates on both sides. If you are starting with a cable tv outlet then add a splitter to activate both sides. For phone you might need to extend the wires a bit so you can punch it on both sides.
Yah, that one is a bit more ballsy. You just made a big hole in the wall. So what? As long as you are using a factory made wall plate it will look like it was meant to be there. It is unlikely the landlord will notice. If they do… so what again? Now there is TV or phone available in a room that didn’t have it before. If anything you made the place more marketable. That was my theory back then anyway… now that might not apply so much if it’s a phone plate since landlines are so outdated but it certainly still applies to cable TV jacks!
Method 4.. just following the trend above… what if there is no existing jack in the wall. You can just puch a hole in both sides and put and install ethernet only plates. This is probably the most likely method to get you into trouble as when you leave all that remains is an Ethernet jack which the landlord probably knows they never installed. In most apartments though it is unlikely they will even look that closely. They just want to clean the place up and rent it to the next person as quickly as possible. They aren’t counting the conductors in what at first glance looks like a telephone jack! Also it is still possible that the next tenant may realize what it is and be glad to use it.
Finally.. you can do method 2 and cover your tracks or sort of cover your tracks even for 3 and 4. Just replace the plates when you go to leave with ones that only have the original TV or phone jacks, no ethernet. In the case of method 4, when there was no pre-existing jack just use a blank wall plate. Many of the college town apartments I lived in had these because they once had connectors for a shared TV antenna on the roof before cable came in and the CATV guys rarely re-use the existing holes.
I have used all 4 of these methods though and never removed my ethernet jacks before moving out and it never lead to any trouble. I like to leave them in because I hope that the future tenants might recognize what they are and use them.
Notice the things that I have not suggested:
1) Running an ethernet feedthrough at your power outlet holes. Don’t do that. There is another website for that particular suggestion.. The Darwin Awards!
2) Asking permission. The answer is no. It is almost 100% sure going to be no. Nobody is going to know or care and future tennants might even benefit if you just do it but if you ask it is all over. Embrace the dark side!
Also… always start by checking those bottom of the wall corners for pre-existing holes. It is entirely possible that some previous tennant already drilled a hole for ethernet, cable, telephone or whatever. I have seen this and have taken advantage of it myself!
I am of the mindset that anything and everything needs encryption. I want an encrypted packet to a local MQTT server, not something offsite. I think each device should not have it’s own logic outside of safe boundaries in case the server goes offline, and push all the logic to that local MQTT server. The idea that people can have dozens of streams of data going out to the internet reading and controlling parts of the house is ridiculous, and just disconnecting the internet from the house will render the house broken.
if everything is local, why the need for encryption? If someone has access to your network, either they are physically in your house plugging into a lan port, or they have hacked onto your wifi network. Either way, turning your lights on and off in that situation is the least of your worries.
The WiFi is the relevant encryption in that scenario, even if the server is on the internet.
But what if the devices don’t use WiFi, and use some other wireless protocol instead? They still need at least authentication so that no one else can manipulate them, and if they’re sending possibly sensitive data (e.g. cameras), encryption as well.
But I definitely think that the only server the devices should connect to is local. However, that doesn’t preclude remote control over the internet.
Agreed. Even simple microcontrollers can implement some basic level of security/encryption. If its not a hardware module you can implement it in SW. I’m OK with keeping people from driving by with an SDR and taking over my widgets. If they have physical access I would assume they will be able to crack it, but at least try and make it non-trivial.
As for a gateway, I like the idea of an SDR type device that can span multiple standards and that acts a firewall to the outside world.
Any performant Arduino Libs to mention here?
I’m not big on arduino and don’t know any specific libraries, but there’s a fairly straight forward API to talk to the ATECC508A part from Atmel which will give you TLS security online and allow you to connect to Amazon Web Services. http://www.atmel.com/devices/ATECC508A.aspx
First: This is a question that has personally bothered me as well and it’s great to see this being discussed with the wider community!
Common sense would suggest hacking or getting into the network would need some form of input. So if the light control signal is a one-way street (the RF link is one-way) there should be no way to get into the network by toggling lights? If there’s a sensor, then I could potentially see invalid/out-of-bound/specially crafted values to cause buffer overflows in the software stack.
Also, if the last-mile command to turn on and off the light is merely a bit flip, then all one needs is a SDR to figure out the protocol. There needs to be some form of authentication (rolling codes? but they have been broken) – I know at least one solution using HMAC codes. How about something like two-factor authentication with a shared key between the bulb and hub established at the time of pairing or establishing the home automation network?
Clarification: By 2-factor authentication here, I don’t mean two factor authentication as in entering an additional code or OTP while switching your device. I actually mean two-factor authentication *between devices* as some “additional” information being sent along with the command that needs to be authenticated so that the command can be processed – think keyfobs with changing codes every minute or so?
It should at least have some level of challenge-response authentication for the local devices involving some form of encryption.
I wouldn’t mind Two Factor Authentication for my LED lights in my house. But that’s just me. My wife and child might not appreciate it, so wall switches have to work just like wall switches.
If your comment was in response to my 2FA suggestion, I suggest looking at the clarification I just added to my existing comment as a reply.
An important part of security is isolation. IoT devices in particular are generally ‘as secure as was possible when designed’ and rarely updated. I would put all IoT related hardware on a separate VLAN and entirely isolated from my day to day systems. It’s extremely possible that they’re a valuable attack vector to an attacker. Those devices also juggle with ease of use and security, and that overlap is likely to be rife with vulnerabilities.
A former employer of mine made a decision when we were designing a piece of hardware to omit encryption from a control protocol because the protocol was custom, and “no one would be able to figure it out.” It’s not difficult to imagine that this line of thinking is still more prevalent than it should be today.
Companies also have to weigh the consequences of a vulnerability. Is it likely that the press would pick up on hooligans running around toggling your lights? Maybe. The general public doesn’t have a lot of knowledge on the topic yet, so that might scare a lot of people away from this type of automation.
The VLAN would prevent co-mingling across your networks, but you’re still giving up security to all your IoT devices. Each individual device would still need to be locked down in some way. You can implement secure authentication (PKI, signed certs, etc) and provide a decent level of security even on small/low power embedded device.
Everything should fail-useful. Your remote-operable thermostat should have local thermostat capability even if it loses it’s uplink. Also, any connected device should have a locally accessible API and be usable without cloud services at minimum. The startup du jour doesn’t like that model though because then they can’t sell your data.
Tell that to the companies who make TVs and DVD Players that can’t be operated if your remote breaks
I am so sick of that! My cable box has only one button, the power button. If I lose the remote I can only watch one channel until I find it again or get the backup remote.
Seriously, I have a backup remote. ;)
Our 10 y/o tv just broke a couple of weeks ago and we bought our first butonless one. I do agree that buttons would be better but I doubt your TV is actually inoperable if the remote breaks. I barely use the remote that came with our TV. I have an app on my phone for that! Of course if you don’t have an IR capable phone universal remotes have been a common thing for nearly 30 years now.
Agree 100%. I tend to be more interested in products that allow me to control my own data on a server within my own network so the cloud is not required.
Security is often inversely related to usability by normal people, and is seen as a support cost to a company. In service, most domestic IT people have been eliminated in favour of off-shoring workers, cloud based services, and pre-configured network routers. The current zero-accountability security concepts have degraded into an variable-cost issue rather than a corporate reputation issue, as any legitimate advisory service will have 100 negligent spammers cloning their website for a few pennies a day.
The chain of trust at one time was preserved by the ability of the authors to limit the scope of device functionality to minimize attack vectors, and consistently monitor the servers for anomalies while in operation. If you have a network printer for example, then its going to develop vulnerabilities eventually due to never being updated, or likewise being updated by intentional/unintentional malicious payloads, and or being physically sabotaged by the public.
While it is possible to integrate a hardened network infrastructure. Most consumers don’t want to pay $200 for a light-bulb with traffic shaping, and don’t know or care about Internet Of Thoughtless-marketing rhetoric. Note that no RTOS has stood very long without being compromised, as complex systems eventually fall to automated exploit testing.
People could pay competent people to fix this mess, but the CISCO salesman said he can do it now with zero risk – and most HR people only know “competent” costs money.
If a device needs power, why not use a power-line communication instead of WiFi or anyelse wireless communication ?
Concerning outside capacities, in my opinion, some devices just need a shutdown remote capacity, and others, maybe limiting outside changes capacity to a mode but not settings of this mode.
PLC is unreliable and depends on how the wiring was done.
All it takes to break it one cheap phone charger on the same circuit.
That and it generates RFI like crazy. Proper well made PLC chipsets have advanced DSP in them to notch out stuff like broadcast AM band, FM broadcast , amateur bands and aircraft coms.
Not that the cheap stuff has any of that. Same with cheap SMPS.
I am a fan of using real network security standards in this regards, put your management server in one subnet, All automation devices in another subnet. After this, firewall rules to allow connections to come from server to automation but not the other way (feed back would be transmitted on the first established session and not need the rule). At this point build the automation pieces to not know how to correctly build its own session so even if lightbulb a was hacked it does no good. You could go really insane with it and make a crap ton of /30 vlans and make a policy for each one. but depending on your hardware your limited to 1024 or 4096 vlans at that point. (some gear does go below or above those numbers)
I had a friend who was very interested in network security and started playing with enterprise grade switches and firewalls when we were in high school. He went on to attend a great college and get an impressive job doing some sort of admin work for some big government labs.
He never had reliable at-home internet access and even his email address was non-functional more often than not until he finally broke down and got a gmail account. That was because his home network and servers (self-hosted email) were always broken due to needing to tweak his firewall settings or subnet configuration!
I still believe that security is important but to this day I am convinced that when security becomes TOO important all you get is a pile of non-functional equipment.
For the 2 factor identification idea, what about voice printing not just speech recognition for the many home controllers available and then the user could be holding a fob of some sort to identify a known user. A problem with this may be the fact that speech recognition tends to use web services. A work around for that might be a first time setup speech training that is used for user identification as well as speech recognition clarity.
For two factor identification, or really verification that the radio contact that the device is hearing is valid, and not from a scammer… how about just a simple damn button? When setting up, initiating the radio (WiFi, zigbee, whatever) link, if you press the button during that process you are verified. A hacker outside your home won’t be able to press the button, therefore his radio signal will not be recognised as valid.
Spoofing an already validated link is an entirely different matter and has to be dealt with using encryption or some other mechanism. The ‘fail safe’ idea is good… only allow a door to be locked (external) or unlocked (internal)… only allow the stove to be turned off… etc.
If you want to be secure, don’t buy an automated house. Buy a condom.
:o)
I’d argue that being able to turn a stove off or toggle a light is enough to be downright annoying of the wrong people gain access.
e.g. turning the lights on and off repeatedly in quick succession, or turning the stove off shortly after you walk out of the kitchen so your meal doesn’t cook. Some food items have to be discarded if not cooked through properly.
Annoying is one thing…but no-one ever burned their house down by forgetting to turn ON their stove…
This is a bit of a hot button issue with me. I believe that lighting information, presence detection, heating trends, music habits, and other internet connected luxuries can be used to determine optimal times to break into a house. Think of it this way. If someone wants to choose a house to break into, and they manage to hack into the Nest database. From there they can determine when the presence detector has been triggered historically. No presence between 9 am and 5 pm, maybe 10 am is a good time to break in.
With all that said the other question is that of someone just pulling pranks. Albeit your life will not be drastically altered if someone parks on the curb and turns all your lights off, or sets them to strobe. You will be inconvenienced at the very least, not to mention they could turn them on while you are sleeping, waking you up before you need to go in for that life changing job interview tomorrow.
My answer to this is pretty simple. I use PFsense for my firewall and have multiple DMZ’s Like Hillary, I run my own E-mail server. I do not allow mail delivery outside of my domain so I don’t have to worry about spam or it being hacked and used as a spam bot. This sits on a traditional DMZ.
The cameras, light bulbs, presence detection, thermostat, and NVR sit on a separate DMZ. This one has zero connectivity to the internet. There is also a controller computer that runs some bash scripts that have effectively done what everyone else uses the cloud for. When presence is detected, turn on lights. When not detected turn lights off. When presence is not detected and it gets dark, turn on lights in a specified pattern to make it look like I am home.
The concept here is to remove the “Cloud” from my set up. Make all notifications happen through the E-mail server I control and make all automation happen on a controller I control. This has been a slow and time consuming build, but I can be assured that hacking my system will prove more difficult than a prankster will want to go through. Also no one will know if I am home or not based on hacks into a central controlling server that I do not own for an IOT device.
If people developed their automation they would be much happier with it, and we would all be just that much more secure.
^^ This ^^ The first paragraph nails it. The biggest vulnerability from thoughtless IoT implementation won’t be remotely toggling your hall light, it will be the additional knowledge it ‘leaks’ to the outside, whether it’s to professional house-robbers or direct marketers.
I have the same thought scheme as you. I pretty much have the same network infrastructure as you (except for the mail server ;). A sub network of devices connected to a custom controller.
But there is somethings I don’t agree with in your setup.
First, I think that you need to be able to “control” any device connected to this network. Be it in a “secure” way as discussed (turning-the-stove-off-an- non-on), but read-only automation is not worth it. What’s the point of realizing your forgot to lock the door if you can’t lock it from a distance? I think there is a way of doing this kind of thing in a pretty secure way. Unless you are specifically targeted, your average teenager-hacker-in-the-making neighbor will surrender quickly to a properly setup firewall and will try to find another neighbor to bother.
But now, you and me like to do things properly. But what about the damn light bulb, programmed by underpaid Chinese engineers who just don’t give a dime at security (btw, don’t buy any IP camera coming out of China)? You make shure that your network infrastructure is properly safe but the weakest link is the damn lightbulb! Nowadays, you just can’t trust companies. Hell, they’ll sue you if you try to make their crappy firmware safer. And I’m not even talking about data collecting from the makers of these IoT devices.
That’s why I truly believe that until some open source / community backed devices where you can actually trust the code running in the microcontroller, people should either avoid off-the-shelf cheap IoT devices or make it / hack it if they want to be shure it is secure.
For example, I hacked my electronic doorlock (an old Weiser smartcode running my own firmware) and I wired it because I didn’t want to spend too much time making shure the WiFi dongle I was using was safe. And it’s working great!. If I wanted to have automated lightbulbs (I just don’t see the point of it) I would use good’ol X10 powerline communicating modules.
Bottom line is I think companies are not to be trusted with mass market devices. Their profit margins are too small and most importantly, they give a f**k about their customers.
There’s no reason why everything can’t be almost completely secure while still quite usable. Here’s about what I’d do (although there are probably a few issues with it):
Devices connect to a local server over wireless, with encryption at a higher layer.
The server can show all visible unpaired devices that are in range, probably including a unique identifier.
Each device has a button to make it unpair from the server if already paired, and to make it visible for, say, one minute.
The server has a public-private key pair. The device randomly generates a key pair each time it pairs with a server.
When setting things up, the user turns on the device, pushes the button, goes to the server, and selects to pair with that device.
The server sends its public key, and gets the device’s new public key in exchange. Using a key-exchange mechanism, they both generate the same secret key which they use to encrypt all further communications. No one can eavesdrop on them, and nor can they send anything as they don’t have the key. Replay attacks can be prevented by including a message number or something.
The server would allow smartphones to connect to it over the LAN and/or internet, and have a similar pairing system to devices – both for limiting who can control it (the LAN probably has multiple users), and making sure everything is safe over the internet.
Even a lightbulb should have security, and wireless is probably a bad move.
What harm could one do with remote control of a lightbulb?
Turn on the lights in bedroom when somebody is sleeping – on and off enough to disturb sleep,
preferably without fully waking the individual.
Poor sleep/lack of sleep is a major issue in US (and maybe other places).
Affects health, affects job performance, mental health, etc.
Turn off the lights when somebody is doing something hazardous (on stairs, working in shop, etc.).
Use it as a way of finding out if people are home/where they are.
If the lights come on in regular schedule, try turning them off – then see what happens. If somebody turns them on again,
there is probably somebody there. If not, suggests nobody is home (an automated system).
Automated systems could detect such manipulation. But do they? (Detect it, fix it, log anomalous events,
notify the user so know there is an issue.)
Also the matter of monitoring, recording when lightbulb on/off commands are being sent might
tell me about the behavior of people in a neighborhood. (When they get up, when they get home, where they spend time.)
All sorts of interesting possibilities there. (Sure this is more privacy than security,
but it can become security if, e.g. one uses information to tell when best to break in, when
the neighbors are ensconsed in front of the TV or away, etc.)
And if the device is switched too rapidly the relays can fail.
TOR already has a large part of the security solution. My home automation system is running a .onion that can only be accessed (routed to) with an authentication token, which I have on my phone. I could lock it down further to only allow access through TOR, such that guests on my LAN cannot access it. It’s pretty cool stuff — they call it the “Internet of Onion Things”.
Get back to me when you run out of sub-net space on your IPv4 private network, because until then if you have lumped all your stuff together it is your problem for being ignorant or taking avoidable risks.
It is not hard to build a pfsense system that slices and dices the entire LAN into sections for each function then imposes exactly what sections can talk to what other sections and what types of connections they are allowed to make.
Start with the Unix model of “secure by default” and only connect or open up access when it is required. If a product requires an unreasonable level of access, replace it with a more sensible one, even if you have to make it yourself.
Use VPN servers too, never let your security cameras leak data onto the web, let them connect to a local server and then VPN to that with your mobile phone to monitor them.
IoT needs a bill of rights along the lines of:
1) Device must function and inter operate with other local devices without an internet connection. Requiring a cloud so a switch can talk to a light bulb is not acceptable.
2) Any functionality that requires an internet connection must be over a documented and published API to prevent losing functionality because of arbitrary business decisions, bankruptcy, being purchased by another company, etc.
3) Any IOS or Android client must use above mentioned API
4) Any communications need to encrypted to prevent MiTM or replay attacks
5) Any router/gateway to/from an IoT network must support ACL/White lists or a explicit pairing to prevent attackers from gaining access to the IoT network
With the above users would be protected from:
* attackers trying to detect if you are home
* cloud downtime (like the various google/nest issues)
* companies deciding to discontinue product (like google did with the pre-nest hardware)
With the above a home owner could make intelligent investments in their smarthome without having to buy some vertically integrated system or be subject to the whims of random businesses. Products might not be supported, but the information needed for a community to support itself would be available.
To Mike’s question, “If you have your system protected from the wider Internet, do you need to have every device encrypted?” I’d say: if those devices can still reach out to the Internet, then absolutely encrypt them. A rough analogy might be that I run virus protection on every computer in my house even though I have a properly secured router installed in the home.
Fun and cool and crazy.
For my part, my implemented so!ution for 12 years now is quasi fully wired.
Crazy? Yes, but facilitated and cheap as the big house I bought in 2004 has to be fully rearranged ( main power, heating, isolation, doors, windows….)
Basically I’ve 128 on-off detectors for all doors, windows and light switches, 48 SSR to switch on-off whatever I want (mainly light), 24 thermomètres (at least one per room). Add a lot of RJ45 plus for cat100 cables, either at a low level for conecting any device to the LAN or at heigher level (ceiling) to connect presence detectors or IP-cam. Sure main power and water consumption are also registered.
At this time (2004) no Raspberry, no duino. All HW was home made and managed by an old laptop running debian. Due to modular architecture all this has evolved very easely.
Crazy and fun as I told you but without real security concerns…
A lot of good comments here! I’ll list some features I hope for, though it overlaps some of the above comments.
1 ISOLATE AND LAYER. Put IoT devices on separate network. Allow only a very restricted data flow between that network and the more sensitive home networks (PCs, laptops, phones). Layered security.
2 STANDARDIZE MORE MINIMAL WIRED DATA TRANSFER. Many IoT devices have miniscule data transfer needs. Regular ethernet cables are overkill. Standardize cables/connectors that are much thinner, blend in well and are very easy to attach/detach/move around. E.g. some thin transparent tape that the end user safely and easily can apply to walls/ceilings and as easily remove without any marks. Where wiring all the way is too inconvenient then wire some of the way and use e.g. line of sight IR data transfer the last stretch.
3 SUSTAINABLY SECURE COMPONENTS. IoT should be designed for security *and* when exploits surfare (they will!) there should be a standardized way for users to be promptly notified and to be able to quickly easily patch the problem – even years after purchase. How to get there: a de facto standard and public pressure (consumers, reviewers, …) that market shame/punish substandard products. Likely also legal liabilities for harm due to non-patched exploits.
4 GEO CONSTRAIN WIRELESS ACCESS TO THE HOME ROUTERS. Home router PR still mostly boast of range and speed. But with range comes risk.
– A simple geo constrain it to standardize settings that allow users to *decrease* the wifi range if the default range extends further than needed. A bonus would be less wifi congestion in densely populated areas.
– This second point is more speculative. But tell me where I’m wrong here: multiple wireless home routers on the same wired net could triangulate the exact geolocations of connecting wireless devices and refuse access to devices outside the apartment/house geospace. A 3D map of the living space including obstacles like walls and heavy furniture and some initial setup/training may be needed. That would make direct local attacks on the heart of the network more difficult. Such attacks would need to go through exploits in outer layer devices like IoT bulbs. But for that we could combine 4 with 1.
The concensus here seems to be to put the IoT devices on WiFi but with a separate subnet from the home internet connection. Then, if you want remote access some computer or computer like device bridges the gap between them.
There is already so much WiFi out there… why bother? You are just subjecting your devices to all the interference that is out there from every other WiFi enabled home AND adding your own interference too.
I’d rather use something like Zigbee or a Jee Node or something like that and not one that operates within the same frequencies as WiFi.
“Can you sit at the curb, spoof my light bulb, and make it to the sensitive documents on my server thanks to Home Automation devices being trusted on the LAN” – Kinda, or sometimes the opposite – your LAN might be trusted by the light bulb too much. See: http://utbblogs.com/watch-blackberry-hack-a-tea-kettle/
The tea kettle knows the WiFi SSID + WPA2 password to connect to. If presented with a stronger version of the same SSID by the attacker (EG cantenna pointed at your home) the kettle could trivially be convinced to join that instead, EVEN IF the attacker’s spoofed SSID was passwordless (kettle ignores the WiFi password – it didn’t seem to be required). It’s then easy to scan for the IP address of the kettle, then use a crappy default password (hey, who would have thought you needed a good password, on a SECURE WPA2 network?!?) to log into the kettle “to configure it”, then extract the (known) SSID and (previously not known) WPA2 password from the config. Then join the real home WiFi network with the newly stolen credentials.
I have yet to determine if everybody’s favourite ESP8266 suffers from this – if I AT+CWJAP=”SSID”,”password”, will it gladly join an unencrypted version of the SSID WITHOUT the password? I wouldn’t be surprised, in which case best next line of defence would be to NOT have a crappy password on any API that can fetch all the rest of the config including the WiFi creds
I suspect the “WiFi AP had no password, I didn’t actually need that one you provided, but thanks!” approach is WAY more common than we might imagine, so any assumption that “It’s on my nicely firewalled encrypted secure WPA2, passwords and stuff are less important” might be very vulnerable to drive-by cantenna hacking.
Many other IoT devices scan for TWO SSIDs – one for “your home”, and one “default / recovery SSID” for conveniently reconfiguring the device from that convenient smartphone app when you want to put it on a new network (EG you took it to a friend’s house, and want to reprogram it but you’re NOT on your home WiFi, simple! Use the recovery SSID! And the app does this for you, it’s so easy to use!). Some can be convinced to route packets between the “recovery SSID” and the “home SSID”, almost a kind of an “unfirewall” gateway into your trusted network and beyond. Others can’t route, but can still be trivially hacked from the “recovery SSID” to extract the credentials for the “home SSID” side.
If you’re buying off the shelf, there’s a good chance it’s vulnerable to SOME attack the manufacturer didn’t know/care about. If you’re building your own, it’s fine to include simple recovery procedures, but they should require physical access, and in the meantime DO NOT assume your network is secure just because it’s got a really good WPA2 password on it – your IoT device might consider that optional – so make sure to use good secure authenticated protocols for everything above that AS WELL :-/
Another mitigating approach would be a DIFFERENT SSID for all your untrusted IoT devices, vs somewhat more trusted laptops / NAS / internet / whatever – an “IoT DMZ” with different firewall rules. Assume your lightbulbs WILL be hacked, and make sure they can’t see/steal/ruin any of the rest of your stuff when they are.
Amen.
Here’s something that came across my feed today that highlights this exact issue: https://motherboard.vice.com/read/smart-electrial-sockets-could-be-the-next-botnet
“How much protection do we need from someone parked at the curb turning your lights on or off?”
Have you ever seen National Lampoon’s Christmas Vacation? Turning a light on or off can cause serious consequences, and possibly kill people if done at the right time. The guy in the movie likely had a concussion, and he was lucky. Older/paranoid people could be coaxed into stress-induced heart attacks – think of a light being set to red and slowly pulsing on and off in the middle of the night, and then mix in control of the home stereo and some pulsing bass? I know several people who would freak at that.
If you own it and control it, only those people that you choose to share control with should have it. To this end, everything discussed here needs to have the strongest encryption possible, and reasonable authentication and isolation.
Very precisely put. Yes most business owners fail to document the process and steps involved due to time constraints and financial constraints. As a business owner of a home automation company in Chennai, I too faced the same regret as you a couple of months back. Now I have employed a person to help me with the documentation process.