By Thomas Weinzierl, Weinzierl Engineering GmbH.
Communication and data processing are hardly conceivable today without considering security aspects. In the future, insecure communication systems are unlikely to be accepted. The way has already been shown by the Internet, with the well-known http protocol from 1991 having been largely replaced by the encrypted https variant. Incidentally, one year earlier than http, the KNX system was launched in 1990 under the name EIB.
Even in buildings, the need for secure communication can no longer be overlooked. At present, the danger of damage caused by hackers does not seem to be very concrete. Despite reports of tampering, especially in hotels, there is little evidence of actual damage. Nevertheless, it is necessary to counter potential dangers for technical infrastructure.
The web browser error message below, about the lack of security, should also be a warning for building technology.
Making KNX secure
The KNX Association, as an association of manufacturers, took up the subject of security at an early stage under the title ‘KNX Secure’. Nevertheless, specification and implementation took several years – a major reason being the complexity of the KNX protocol, for which group addressing, which is essential for the entire KNX system, is quite a challenge for secure encryption.
By the beginning of 2019, both the system and test specifications were considered stable and have been approved by the KNX Association Technical Board. The KNX Association has invested a great deal of effort in implementing the security theme in the ETS – the central installation software for KNX. The test tools for the development of KNX Secure devices have also been extended accordingly.
Communication stacks with KNX Secure are available from system providers such as Weinzierl, and the first product certifications have been successfully completed. KNX Secure is now a reality and should be looked at in more detail with its two variants, namely KNX Data Secure and KNX IP Secure.
KNX Data Secure
KNX Data Secure aims to secure communication at the telegram level. It can be used independently of the KNX medium both for commissioning and for runtime communication.
The KNX Association has set itself the goal of ‘security right from the start’. This means that even the first download to devices by the ETS is encrypted from the start. For this purpose, each device is delivered with an individual FDSK (Factory Default Setup Key) to the firmware, which the ETS must know before programming. The key information is mapped together with the serial number of the device into a QR code and printed on the device. The code can be scanned and evaluated by the ETS using a PC or laptop camera. Input via a keyboard is also possible.
Since the key of the device may be known to others, the ETS replaces it with the so-called tool key, i.e. a key for programming. This key is also generated individually for each device.
Further keys are required for the group telegrams. For maximum security, a separate key is used for each group address. Encryption prevents the data from being monitored. At the same time, an authorisation code in the telegram ensures that only authorised devices can participate in the communication.
A well-known attack on systems is the so-called replay attack. The attacker uses telegrams which they listen to and send again later without being able to interpret them themselves. In order to prevent this scenario, each telegram contains a telegram number which the respective sender assigns consecutively. The receiver may only accept telegrams which have a higher number than the telegram which it last received from this station. Due to the 6-byte length of this number, an overflow is practically impossible and is interpreted as an error.
Mixed security installations
Since it is not expected that all required devices will be available as a secure variant at short notice, it is important that secure and insecure communication can be mixed in one installation. The secure property is defined at group level. If two group objects that both support security are connected, the ETS proposes a secure link. However, if only one object is in a group without security, the entire group must communicate insecurely.
Different communication objects in a device can have different security properties. Thus it is possible, for example, that the switching telegrams for a switching actuator are encrypted, but the feedback messages are sent unencrypted in order to display them on visualisation. Security could also be used on a case-by-case basis for a blinds actuator. This means that blinds can be controlled unprotected, while window openers only accept encrypted telegrams.
Another scenario is encryption only in partial segments of the installation. Encryption is an important requirement for KNX RF in particular. At the same time, the telegrams should also be able to be sent to conventional KNX Twisted Pair devices. For the solution of this requirement, the so-called Secure Proxy was specified in KNX. This is a software module that is implemented in a coupler. In the above example it is implemented in the KNX RF/TP coupler. The Secure Proxy translates secure communication from the radio side to unsecured telegrams on KNX TP and vice versa. However, the Secure Proxy can also be implemented in line couplers (TP/TP), for example to connect secured external lines to an unsecured internal KNX network.
KNX IP Secure
KNX IP Secure follows an alternative approach, but is based on the same encryption methods as KNX Data Secure. KNX IP Secure is a pragmatic approach based on the assumption that there is a point of attack at the IP level. KNX Twisted Pair is assumed to be relatively secure as a purely local medium located in the wall. On the other hand, IP communication is often connected to the Internet and can therefore be attacked remotely.
KNX IP Secure protects KNX IP communication whilst communication on KNX TP remains unencrypted. The main advantage of this approach is that the existing KNX TP devices and installations can continue to be used unchanged. Only the KNX IP devices, i.e. essentially KNX IP interfaces and KNX IP routers, must be replaced.
KNX IP includes the routing protocol, which is used for IP backbones, but also represents the KNX IP medium. On the other hand, the tunnelling protocol is used to enable a client (e.g. ETS) to access a TP line via IP. While KNX IP routers usually implement both protocols, KNX IP interfaces only support the tunnelling function.
As different as the two applications of KNX IP are, so different are the respective extensions for security. With the Secure Routing protocol, which is based on UDP Multicast, a common key is used to encrypt all KNX IP routing communication. A special feature is the telegram counter during routing. This is time-based and thus represents a time stamp that allows obsolete telegrams to be detected. The common system time is continuously synchronised between the devices.
With the tunnelling protocol, the client and KNX IP device (KNXnet/IP server) first establish a secure channel using the so-called Diffie-Hellmann method. Only then are the user ID and password transferred. A new feature of KNX Secure Tunnelling is the possibility of establishing the connection with TCP. In addition to the option of accessing a bus line, tunnelling also enables KNX IP devices to be programmed very quickly.
KNX Secure from the manufacturer’s point of view
KNX Secure is certainly a challenge for manufacturers. The expansion of existing KNX devices with KNX Secure will, in most cases, not be possible without changing the hardware, as the requirements for available memory and computing power increase. Key allocation and printing must also be implemented as QR code in production.
New requirements arise for the manufacturers of software for KNX, for example visualisations. It is no longer sufficient to import or enter the group addresses of the project. Even knowledge of the keys used is not sufficient to send encrypted group telegrams. Rather, each participant must be made known to all the devices it is to reach. This is currently, and looks set to continue to be, only possible via the ETS. For most devices on the market that cannot be put into operation using the ETS today, the way to a secure KNX communication system is likely to be a challenge, albeit a manageable one.
Dr.-Ing. Thomas Weinzierl is the CEO of Weinzierl Engineering GmbH, manufacturer of KNX products and provider of a full range of hardware and software development and testing services.
