Practical advice on how to secure legacy and future KNX systems, with examples of products offering a range of security features and tips on how to take advantage of them.

After years of warning of the risks of leaving network ports open, KNX Association has recently announced that there are reports of systems being hacked. Even if all modern projects have been set up securely, there are still countless legacy projects that may have been installed in less secure ways, so we all have some work to do to make sure we protect both KNX end-users and the reputation of the industry.

The good news is there are countless ways of making a KNX installation secure yet still able to provide remote access for both users and for maintenance. It’s even possible to lock down the system within the property, which proves KNX as one of the most secure systems available.

Before looking at the ways to secure a KNX system, let’s quickly explore the issues so we are all on the same page.

Unsecure KNX systems

Assuming you are using the standard ports (3671) or multicast address (224.0.23.12) on an IP interface or router, it’s possible to open the same ports in the firewall, thus making the KNX system immediately accessible from outside. If left without any additional protection such as only accepting connections from a specific IP address, then anyone with basic hacking tools will be able to find the open connection and potentially gain access to the KNX system. If for some reason this connection method is the only possible option, then even the basic step of changing from the default ports will help. However, this connection method should be avoided wherever possible – particularly as there are much better ways to provide remote access.

VPN access

A longstanding method of secure remote access is to create a VPN (Virtual Private Network) as a secure tunnel into the system. Once the authentication has been used to connect you, you are effectively local within the building, allowing you to make any changes needed or connect apps or visualisation.

One way of creating a VPN is to use a network router that has an embedded VPN server. On most installations where multiple systems are being installed in the home, such as AV, CCTV and KNX, then it’s more likely the network will be fully managed and the router capable of running the VPN connection. On smaller installations, or where the homeowner isn’t willing to put in a more advanced router than the standard unit supplied by the Internet service provider, then another solution is needed.

In this case, it’s possible to install a separate VPN server within the property. A great example of this is the Gira X1, which has an OpenVPN server that is embedded. The installation is quite simple, with the only major complication being the need to open some ports on the router. However, unlike opening ports directly to a KNX interface or router, the X1 requires credentials to prevent unauthorised access. Via the X1 and the OpenVPN server, it’s possible to not only allow access for remote control for the X1 app, but you can also access devices on the rest of the network such as the KNX system or a CCTV camera.

Cloud- or object-based remote access

Supported by a wide range of manufacturers, this works in a similar way to a VPN, but instead of a tunnel, it uses a local device and a secure website to encode all traffic in and out of the installation. Because the device makes the first connection out of the building, a secure path is created, meaning there is no configuration required on the network router. By either running an application on a remote computer or logging in via the secure website, it is possible to access the network devices within the home.

There are a few different applications of this:

Gira S1- a dedicated remote access device. This is configured in ETS and, once set up, makes a secure outbound connection to the Gira Portal. Not only can it be used for email notifications and remote programming, it also integrates with the Gira X1 and Gira HomeServer visualisation solutions, so end-users can simply and securely connect to their installation.

Jung IP Interface – with the purchase of a license, Jung IP interfaces can be quickly configured for remote access for programming devices on the KNX bus. Configured via an ETS plugin, and with the option for the homeowner to enable remote access, this is a great way to maintain the system remotely, particularly where a separate KNX server isn’t being used.

Basalte Core Mini – moving the remote connection from a standalone bus device, the Basalte Core mini has this functionality integrated. Along with the Basalte Live Cloud services, this provides a secure remote connection for programming and user control. And if you have a local IP interface, it can also be used to program KNX devices.

These are just some examples. Most KNX Manufacturers now provide a method to securely connect their products and the wider KNX system to the outside world.

KNX Secure

The secure connection methods above are well established and have been used for many years in order to ensure projects are protected. But there is another way. KNX Secure offers two additional methods to secure a project, and with manufacturers all supporting these methods, it is quickly becoming the de facto approach. Even better, it creates the possibility to implement multiple layers of security making KNX near impossible to be hacked.

KNX Data Secure

The first is KNX Data Secure which allows device objects to have a layer of security. Using industry-standard security algorithms, the application data within a KNX telegram is encoded using keys shared between devices. This is a great tool for securing and encoding key information on the KNX bus, or even making the entire bus unreadable unless you have the project with the keys.

KNX IP Secure

The other method is KNX IP Secure. This approach takes the existing KNX IP telegram and wraps it in a security blanket, again using an industry-standard approach. The primary application of this is to encode the communication between two or more IP routers that are being used to create an IP backbone. It can also be used to encode the traffic from ETS or external systems to an IP router or interface, making all IP communications secure.

Conclusion

It could be as simple as adding a secure device for remote access or designing a system from the ground up to take advantage of multiple layers of security; either way, making sure you include security as a key component of the system will ensure that your customers, your business, and the wider reputation of the KNX system is protected. It’s also a great opportunity to revisit old projects and offer an upgrade, not only of the security, but the rest of the system. This will ensure that even legacy projects are being protected, and it is a great opportunity to re-engage with old customers.

With so many ways to secure a KNX project, there really isn’t an excuse for leaving KNX projects, either past, present or future, open to attack. If we all support this, and do the right thing for our customers, then as an industry we will also be protected.