KNX Secure

Years ago, criminal access to a hotel´s KNX system was provoking wide-ranging discussions about security in KNX community. The increased use of IP and RF was also one reason to introduce suitable protective measures at KNX, known today as KNX Secure.

KNX Secure protects KNX devices from unwanted access and manipulation. Password protection and data encryption prevent unintentional configuration of individual devices and illegal reading of stored data. Changes to a building´s network system by unauthorized persons or attackers are effectively prevented; potential attack surfaces are withdrawn from the outset.

To make use of the KNX Secure protection, it is only necessary to utilize devices that support KNX Secure, or better say devices that have implemented KNX Secure in their firmware. For device manufacturers, the KAIstack system software for implementing KNX communication in end devices offers full KNX Secure support.

Security in KNX installations

Various security criteria must be taken into account when planning and installing a KNX system. As orientation for developing protective measures and concepts, the KNX organization has provided a KNX security checklist. The KNX Secure encryption and authentication mechanisms are one of the points listed here.

Applications and devices with KNX Secure support offer the highest level of security for runtime communication, system settings and user data. KNX Data Secure and KNX IP Secure can be used separately or together in a KNX system.

Why is the ‘Double Protection Concept’ KNX Secure that important?

Due to the grown safety requirements, protecting KNX devices is a constantly increasing challenge for planers, installers, and manufacturers. As the modern communication technology offers a wide variety of hacking opportunities, KNX Secure is the optimum measure to guarantee home and building control is safe. The incomparable high security level KNX Data Secure and KNX IP Secure reach by:

  • Secured communication channels between KNX participants can be created.
  • Bus devices only exchange data with each other if they recognize correct partners.
  • Getting control by manipulated messages is inhibited effectively.
  • Encryption of data makes secured parts of installations almost invulnerable.
  • Operation and configuring are only accessible to authorized persons.
  • Data and information are protected against unwanted modification.
  • No effect of data recordings when replaying them for manipulation or illegal action.
  • Extra protection for using Ethernet, wireless networks, and Internet is assured.

KNX Data Secure encryption protects:

  • commissioning of devices
  • access to a device´s configuration
  • data exchange of devices via group communication, independent of the KNX media
  • the part of a telegram that contains the useful data (like commands etc.)

KNX IP Secure encryption protects:

  • the whole KNX data that is transmitted via IP/Ethernet
  • the bus system from access attempts via IP
  • the Routing between KNX IP couplers
  • the Tunneling channels that KNX IP interfaces provide

Using KNX Secure Devices –Security Mechanisms Details at a Glance

Confidentiality by Security Keys and Secure Commissioning

The fundamental protection by KNX Secure bases on an AES-128 data encryption with CTR operation mode and AES-CBC-MAC signature (CCM). This data encryption protects configuration and runtime communication of a Secure device from the first moment it is used in the installation. How this exactly works and what Security keys the ETS generates for programming Security in Secure devices is explained in the following.

Project password

To be able to program a Secure device that has its secure mode activated (or to activate or deactivate the secure mode of the Secure device), Secure Commissioning must be switched to on in the ETS project. This is only possible if a project password has been assigned to the ETS project before. Without knowledge of the project password, the FDSKs stored in the project are therefore not available for programming and Secure devices already in use cannot be (re)programmed (without entering the FDSKs to a new project). After the first programming of devices, the password-protected project contains all the relevant keys of the KNX installation, in addition to the FDSKs.

Secure commissioning

If Secure Commissioning for a Secure device is activated in the ETS project, the (initial) programming is encrypted. In the Secure device itself Data Secure meaning its secure mode is then active and the device can communicate via secure group addresses (and/or via Secure Tunneling channels) with encryption. For this purpose, the FDSK of the device must have been entered in the project before.

Device Certificate label

The Device Certificate is a 36-character code that was assigned to the device by the manufacturer. Without having it entered in the Device Certificate list of an ETS project, the ETS is unable to recognize a Secure device has to be programmed, nor the ETS is able to switch the Secure device to secure mode or deactivate a device´s secure mode.

 

The Device Certificate can be entered in ETS manually, or by showing the QR code on the tear-off part of the Device Certificate label to a camera. After having done this, it is recommended to remove the tear-off part (before mounting) and store it at a safe place. If necessary, the tear-off part of a certain Secure device can be recognized afterwards by the serial number that is printed on both parts of the label.

Serial number

The serial number is a unique identification number for every KNX device. It is also stored in the firmware of a KNX device. As the ETS is able to extract both the serial number and the FDSK from the Device Certificate, ETS can clearly identify a certain Secure device.

FDSK (Factory Default Setup Key)

The FDSK is assigned to every single Secure device by the manufacturer, as is the serial number. When the ETS knows the Device Certificate of a Secure device, that usually is contained in the Device Certificate list of an ETS project, it also knows the FDSK. The ETS then uses the FDSK during first programming a Secure device to generate a Tool Key. Afterwards the ETS connects to the Secure device via encrypted data exchange by using the Tool Key, that now is only shared between the both communication partners (meaning it is only stored in the password-protected ETS project and the Secure device having secure mode set to on), instead of the FDSK.

Factory Reset

After executing the Factory Reset, a KNX device is reset to its delivery state. For a Secure device in secure mode, this means that all programmed keys (Backbone Key, Tool Keys, Group Keys) become deleted within the device, its secure mode is shut off and the FDSK, which is embedded in the firmware, is active again. By doing so, no safety-relevant data about the KNX installation can be collected after the reset.

Please note: For again programming the reset Secure device via Secure Commissioning, the project that contains the FDSK is necessary. Otherwise, there is the need to enter the FDSK in a new project. Consequently, Device Certificate and the password of the project, in which this certificate is registered, must never be lost at the same time! Otherwise, after executing the reset, a Secure device can only be operated in plain mode. For an emergency case, only the manufacturer can help via a support request.

Tool Keys

The Tool Key is a security key for programming Secure devices with active secure mode. As already explained under FDSK, each secure device has an individual FDSK (Factory Default Setup Key) stored in the firmware as a 128-bit code. For the P2P communication of the ETS, this FDSK is replaced by the Tool Key during the first secured download into a device. Tool Key and FDSK are not required for programming Secure devices in plain mode.

In summary, after entering the FDSK in ETS via the package-enclosed Device Certificate, all further keys will be automatically compiled. The individual Tool Keys for each Secure device are generated and stored in the ETS project, encrypted and signed. Tool Keys are not accessible to the user, but can be made available to other, especially non-ETS configurable components of an installation via an export file (Keyring).

Group Keys (Runtime Keys)

In order to secure the runtime communication via group addresses with Data Secure, Group Keys are used for encryption and decryption of group telegrams. Each group address is assigned a separate Group Key. An authorization code in the telegrams ensures only the devices of the configured group can exchange data. Without Security Proxy, a group can only exchange data either secured or non-secured.

Backbone Key

When the Backbone Medium of an ETS project is chosen to be IP, and the IP Backbone´s Security is set to on, the ETS generates the Backbone Key for this project. This key will be downloaded to the KNX IP Secure Couplers and KNX IP Secure Interfaces of the project (in case they use secured communication and have Secure Commissioning activated). The Backbone Key, as well as the Security activation status of Secure devices and Tunneling Channels can be seen in the Project Security report.

Keyring

To make available for operation the Tool Keys, Group Keys, and the Backbone Key to devices that cannot be configured by the ETS (like a Visualization device), a Keyring export can be executed. This password-protected export file contains all necessary data for doing this.

Management Password

For device management, IP Secure devices have individual passwords. The Management Password and the authentication code of an IP device are part of its IP settings. No matter if Security of the IP backbone is switched to on or not, the IP properties window of an IP Secure device provides entering these passwords for commissioning and access.

Freshness, Data Integrity, and Authentication

In addition to AES encryption, there are further mechanisms at the telegram level that ensure the security of an installation. Roughly speaking, the freshness of telegrams provides replaying a recorded telegram is ineffective, while data integrity and authentication prevent from illegal manipulation of telegrams.

Sequence number

When a Secure device has Data Secure active, it generates a 6-byte value for every telegram sending to the bus. This value is called sequence number and is added to the data contents of the sent telegram. The receiving device checks this contained sequence number, and only accepts the transmitted data if the sequence number is higher than a previously received one from that sender. This mechanism ensures only fresh data is transmitted and prevents devices to react on illegitimately recorded telegrams.

Time Stamp

For communication via KNX IP Secure, time stamps are also included in the IP frames to ensure freshness. Frames with outdated timer values are discarded (when receiving).

Message Authentication Code (MAC)

When Data Secure is active, an encrypted authentication code is added to each telegram. This data integrity prevents unwanted manipulation, as this allows a receiver to determine whether a telegram has been changed in an inadmissible manner or not. When authenticating secured telegrams, a receiver also ensures that the received telegram actually originates from an admissible source.

Conceivable threat scenarios for an unprotected KNX system (examples)

Attacker gets access via (W)LAN – spies on addresses of door lockings – opens doors.

Attacker dismounts a KNX device, inside or outside of the building, to reach access to the KNX cable – records telegrams – repeats them to open the garage, or to set the alarm system to off.

Attacker discovers there is a not sufficiently connection between internet and installation (router port is open, no firewall is present, or no VPN tunneling is used) – reads out private and confidential data, like passwords, bank account details, or simply consumption data.

This is why KNX Secure effectively prevents:

  • Replay a recorded telegram, to repeat switching or change set values.
  • Manipulate a telegram, to be able to use it with other devices, group addresses etc.
  • Reprogram devices, like couplers, to make their security function ineffective.
  • Read out telegram contents, that can often contain very sensitive data.
  • Reprogram/change functionalities of an installation.
Back