Thomas Weinzierl explains the evolution of KNX Secure, why it is needed, what it comprises, how it works, how it can be applied and what it means for those making KNX products.
Communication and data processing are hardly conceivable today without considering security aspects. Indeed, insecure communication systems are fast becoming unacceptable. 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, despite reports of tampering, there may be little concrete evidence of actual damage by hackers, but their efforts are only likely to increase, so it is necessary to counter potential dangers for technical infrastructure.
The web browser error message below, about the lack of security, should also serve as a warning for building technology.
Making KNX secure
As an association of manufacturers, the KNX Association embraced the subject of security at an early stage under the title ‘KNX Secure’. Specification and implementation took several years; a major reason being the complexity of the KNX protocol, for which group addressing, which is essential to 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 were approved by the KNX Association Technical Board. In addition, the KNX Association 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 were also extended accordingly, and certified KNX Secure products are now available.
So, now that KNX Secure is a reality, let’s look 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 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 or via a mobile app. Input via a keyboard is also possible.
Since the key of the device may be known by others, the ETS replaces it with the ‘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 just 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, such as a KNX RF segment, for which encryption is an important requirement. At the same time, the telegrams should also be able to be sent to conventional KNX Twisted Pair (TP) devices. The solution for this requirement in KNX is the ‘Secure Proxy’. 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. Whereas KNX Twisted Pair is assumed to be relatively secure as a purely local medium located in the wall, 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 also 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 is likely 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.
