Security in IOT

If you build your own home automation, security is something you should think of from the beginning. You don’t want somebody turning of your heating while you are away for skiing for a week. It is also not too much fun if somebody turns on the lights in your sleeping room during the night.
Joshua Corman explains the security risks in IOT applications (home automation is kind of an IOT application) and what to do to build secure systems.

Click on the image below to view his keynote from the 2016 IoT conference
Screenshot 2016-05-17 09.31.54

How secure is KNX?

Looking at modern home automation communication technologies (like Z-Wave or Zigbee), it seems that most of them have some security issues. These may or may not been fixed in the future. If these modern architectures already show a lot of problems, what about KNX? Let’s make it quick: from an computer security point of view, KNX is not just insecure, but the worst kind of protocol. All devices communicate on a shared medium, there is no encryption, no authentication, no authorisation. If you have access to the KNX bus, you can do everything.

Luckily, there is one good thing about KNX: You need access to the bus. If somebody has physical access to your bus, he can do crazy things. But this means, this person is already in your flat. Even without home automation, a person that has physical access to a light switch can turn it on and off. This means that for a residential installation, cabled KNX installations are perfectly fine, if they are running standalone. However, modern installations aren’t standalone. Nobody wants to install an home automation system anymore that is not somehow connected to a network.

Here are some tips how to make sure this system is still secure.

  1. Don’t simply connect your KNX network to your home LAN (that might be even allow guest WLAN access).
    KNX/IP interfaces are cool products and you will need one. However, be clear that these do not have any security built in. That means everybody that has access to your network can do everything on your home automation installation. This might not be the best idea. I would recommend some gateway that makes sure only authorised system can access your KNX bus.
  2. If you use any commercial product to connect your KNX bus to your LAN, (there are a lot of products available) make sure, the supplier provides regular updates and reacts on security incidents. If the last firmware you can find is 17 months old, the supplier most likely doesn’t do a good job. Most of these gateways are Linux based and you will need regular updates for it.
  3. If you implement some kind of gateway/firewall by yourself, make sure it is designed with security in mind and you also update it regularly.

Remark 1: The concept of physical security can be very critical in environments where multiple parties share a KNX installation. This can be a problem not only in office buildings, but also apartment complexes. If you live in an apartment with some kind of “smart” technology, have a look how it is implemented and who might be able to access it.

Remark 2: With ETS 5.5 the KNX association now supports some kind of encryption. I haven’t looked into it. Why? Because all old devices do not have any idea about it. It might become more popular in the future, but in today’s practical KNX installations, it is usually not supported by the devices that are already in place.

Z-Wave goodbye? Not yet

If you are interested in security, you might already know Steve Gibson’s podcast “Security now”. You might not agree with all of his opinions, but he collects quite a lot of information what’s happening in computer security. Make sure you understand what part of the podcast is advertisement and what is real information – as it is not always obvious.

At the latest episode, Steve has a look at an attack to Z-Wave that had been shown recently. As the podcast is always long, you should skip to 1:41 (minute 101).


Steve has some valid points against Z-Wave. Especially the fact that most of the standard isn’t publicly available means that there can be flaws in the design or the system that can’t be easily corrected. However, if you look at the presentation the podcast if referring to, you will see that the guys did not break the Z-Wave encryption. It just wasn’t available in the network they hacked into as it isn’t widely used today.

Does this mean Z-Wave is secure? Not really, but it also doesn’t mean that Z-Wave is insecure in general. We just don’t know yet how secure it is. Would I use it for a door lock? Most likely not. But it might be still a relatively inexpensive choice for some non-critical functionalities.


Draw your own LCARS home automation user interface with Javascript and SVG

Some time ago I wrote already why I like LCARS as a user interface design for home automation. Looking around on the internet you will find several frameworks to build your own LCARS-styled UI. Some of them are quite old and I did not even look into them. I hope nobody is using Flash for new UIs anymore. Others use a lot of image files. I don’t like this approach as the controls are really simple and you don’t need to load a graphics file for a simple rectangle.

The project I liked most was the LCARS SDK. It is using Javascript in the browser and

blocks to build a UI. However as the documentation wasn’t always clear it took me a lot of time to build even a simple UI.

But why using

blocks? There is an even better way: SVG. Scalable vector graphics are part of the web standard since more then 10 years, but they aren’t used widely yet. Fortunately all modern browsers support them and it is very simple to draw some rectangles and circles. You can also add styling using CSS, modify them with Javascript and add Javascript event. Rendering is very lightweight as the number of objects is usually relatively small (between 50 and 500 objects on screen). This makes this approach also ideal for browsers on tablets and mobile phones.

Programming a simple control frame doesn’t need a lot of code:

function home() {
    lcarsgen.next_x = 10
    lcarsgen.next_y = 10
    lcarsgen.knee({x:10, height2: 40})
    save_x = lcarsgen.next_x
    lcarsgen.button({x:10, text:"Light", id:"b_light"})
    lcarsgen.button({x:10, text:"Heating", id:"b_heating"})
    lcarsgen.button({x:10, text:"Blinds", id:"b_blinds"})
    lcarsgen.button({x:10, text:"Weather", id:"b_weather"})
    lcarsgen.button({x:10, text:"Movies", id:"b_movies"})
    lcarsgen.button({x:10, text:"Music", id:"b_music"})
    lcarsgen.button({x:10, text:"Config", id:"b_config"})
    lcarsgen.knee({x:10, height1: 120, height2: 40, \
    save_y = lcarsgen.next_y - lcarsgen.spacing - 40
    // top bar
    lcarsgen.button({y: 10, width: 310, height: 40} )
    lcarsgen.button({y: 10, width: 310, height: 40} )

    // save for text display
    tx = lcarsgen.next_x-lcarsgen.spacing
    lcarsgen.button({y: 10, width: 55, height: 40, \
                     type:"rounded_right"} )

    // bottom bar
    lcarsgen.button({y: save_y, width: 310, height: 40} )
    lcarsgen.button({y: save_y, width: 310, height: 40} )
    lcarsgen.button({y: save_y, width: 55, height: 40, \
                     type:"rounded_right"} )

    lcarsgen.text({x:tx, y: 50, height: 40, text:"H.11 CONTROL", \
                   text_align: "right"} )

The result look already pretty cool:
Screenshot 2016-05-12 12.15.52

Voice control for your home?

I was never a big fan of voice dictation or voice control. When I started to experiment with this technology in the 1990s it was far from perfect. Even today, I use Siri on my iPhone very rarely. However I see some interesting use cases in home automation. What about going to bed and say “turn the lights off”? This should be quite simple. You can already buy products that do things like this. Check out this cool KNX room controller: imgres

It not only looks good, it is also expensive. But is this really the future? It is a start. But there are much better use cases. Both Amazon and Google are working in real assistant services. The Amazon Echo is already on the market in the US, Googles Home will be available soon. I would expect that Apple is working on something similar.

One use case that I can easily think of is the following:

me: “Turn the lights off”
control: “Have a good night, I will wake you tomorrow at 7”

That’s still quite simple, but what about:

me: “Turn the lights off”
control: “I see that you have an early meeting tomorrow. Should I wake you already at 6:30?”

Or this:

control: “It is expected to snow tonight. This might cause delays in public transportation tomorrow. Should I wake you a bit earlier than usual?”

There are many other interesting use cases. Will it be reality soon? I don’t know but I really want to experiment with this.

Innovation begins at home

Andy Stanford-Clark, IBM Distinguished Engineer for the Internet of Things, will explain how his hobby of home automation and his passion for energy saving converges with the Internet of Things.
This has led to projects that have helped alleviate energy poverty in social housing, and are helping commuters from the Isle of Wight check if the ferries are running on time.
Andy will explain that “it’s all about the data” and how these solutions are built from instrumented, interconnected, intelligent devices. He will illustrate his talk with examples from his home, including his twittering mouse traps!

Click on the image to view the video on Vimeo.

Screenshot 2016-05-17 09.22.36

Interfacing a KNX bus with Python

If you are looking for frameworks that allow you to interface a KNX bus using an IP interface, you will find a lot of tools. Many people still use eibd. However, looking at the eibd page you will see that eibd is no longer maintained.

If you read the KNX specification, you will notice that KNX packets are quite small with a simple structure. No XML stuff with namespaces as often used in modern APIs. So why not implementing the communication in a small script? Unfortunately it is a bit more complicated than just sending a packet to the KNX/IP interface an wait for the answer.

While KNX itself is connectionless, the KNX/IP interface isn’t. This means you first have to initialise a control connection to the KNX/IP interface and use this for data transmissions. Also you have to acknowledge every packet, otherwise the KNX/IP interface will drop the connection. Does this seem complicated? It isn’t.

A simple version of a KNX/IP communications stack (with very limited functionality) can be implemented in less than 400 lines of code. This even implements caching. This means the daemon actively listens to the KNX bus and stored the state of every object internally. Just reading the value of an object than does not need any KNX communication when the value has been seen on the bus already.

Using this simple interface, it is very easy to exchange messages with KNX group addresses:

from knx.ip import KNXIPTunnel
import time
import logging

def main():
    logging.basicConfig(format='%(levelname)s:%(message)s', level=logging.DEBUG)

    tunnel = KNXIPTunnel("",3671)
    while (True):
        # Toggle the value of group address 0/0/1
        # display the values of group addresses 0/0/1 to 0/0/5
        for i in range(1,6):
            print("{} = {}".format(i,v))

        # delay
if __name__ == '__main__':


LCARS home automation UI

Star Trek fans for sure know the Library Computer Access/Retrieval System (LCARS). The user interface was first shown in Star Trek: The Next Generation. The cool thing about LCARS is that it uses quite big, non-overlapping controls. That makes it a good choice for a home automation visualisation. Have a look at this interface:

If you want to design your own LCARS-like UI, you will find a lot of interesting designs with a simple Google search.

A minimal KNX setup

If you are an experienced electronics hacker and you want to do some tests with KNX, you need to invest a bit. However, a minimal KNX setup for initial tests doesn’t have to be very expensive:

  • a 29V power supply that supplies at least 300mA
    Most bench power supplies will do the job. For a test you don’t have to buy an expensive KNX power supply.
  • a KNX choke
    You can’t connect KNX devices directly to the power supply. A choke is essential. Without it, no communication on the bus will be possible. Standalone chokes starts at around 35€.
    Another option is using a 47-Ohm resistor in between the power supply and your KNX bus line. While it might not work, it is worth a try as it will cost you only a few cent.
  • a KNX sensor
    If you have some push buttons laying around, a cheap KNX bus coupler from eBay might be the cheapest option. You can get these for less than 30€
  • a KNX actuator
    Some KNX sensors (like wall-mounted push buttons) have status LEDs that can be controlled from the KNX bus. In this case, you do not need a separate actuator. Otherwise have a look on eBay for old binary outputs. You should be able to find something for less than 30€
  • USB or Ethernet interface
    USB interfaces are usually a bit cheaper. You might find used USB interfaces in the range of 50-80€. However, I would still recommend to spend a bit more money and buy an Ethernet/KNX interface. You are more flexible with these as multiple devices can access it simultaneously. You might not be able to save a lot of money on a used one, but new Ethernet interfaces are available from 150€

This means, a minimal KNX setup will cost you between 200€ and 300€. This isn’t really cheap, but still less expensive than many people might think. The good thing: The most expensive component is the Ethernet interface. If you decide not to go on with a full KNX installation, you can still sell it for a good price. Otherwise, you can use this in your house installation.

The minimal installation looks like this:

Minimal KNX installation

Is wireless the future?

Looking at new companies in the home automation industry it looks like many of them prefer some kind of radio frequency data transmission. This makes sense as customers don’t want to have additional cables in their home. But is this really the future of home automation? I’m not sure. Here are some arguments against wireless control:

  1. Reliability: with more and more devices communicating wireless, interoperability problems can become more and more problematic.
  2. Power supply: with some exceptions (e.g. EnOcean), even wireless devices need a power supply. This mean either cabling or batteries that need to be changed regularly
  3. Security: Wireless devices are easier to attack than wired devices (at least if these are not connected to a public network).

Especially the security aspect is important in my point of view. Many home automation devices will be used for 10-50 years. While it might be reasonable to buy a new music player every 5 years, you don’t want to change your wall switches every 10 years. The development of encryption algorithms has shown that no algorithm is secure forever. This means the software has to be updated from time to time. Newer encryption algorithms might even need more powerful hardware. Do you believe your supplier will provide software updates for the devices during the next 20 years?