With KNX Data Secure all of the KNX communication on every medium is secured.
In this context, all participating devices are KNX Data Secure devices (native TP,RF,PL, IP devices with KNX Data Secure implemented).
The security is set individually on the Group Address level (more information can be also found here).
- From the device perspective, communication can then be both plain and/or secured at the same time (device:Group Object > Functionality = 1:m relationship).
- From the Group Address perspective, communication can then be either plain or secured.
There are two significant settings:
1. Security activated for commissioning
Commissioning - Device Security
Decision – according to the status of the device security – whether during commissioning (initial commissioning or after a change), ETS should communicate with the device in secured or plain mode.
- If the communication at runtime is secured, then at device commissioning the communication must be secured mandatorily.
- If the communication at runtime is plain, then at device commissioning the communication does not necessarily have to be secured.
2. Security activated for runtime
Runtime - Medium Security
Decision whether communication during runtime should be secured or plain. The Group Address inherits - in total - the (best possible) security properties of all connected Group Objects from KNX Secure devices.
- Automatically (optimally)
- Manually (according to the explicit manual selection of the user)
Both options have impact on the security when inserting devices.
All KNX Data Secure devices operating with secured communication use an individual security key per secured Group Address.
- It is created by ETS and is loaded to the KNX Data Secure devices during the commissioning.
- The security key can only be seen in the 'Security' report of a project.
The security properties of a device are predefined by the device manufacturer. KNX Secure can be activated/deactivated (at application level).
In this case all - in a KNX Secure device available - Group Objects basically (must) have the capability of security (regardless if later at runtime they communicate secured or unsecured).
When KNX Data Secure is activated, then Freshness, Data integrity, Authentication and Encryption are active, which means that the content of the telegram is no longer “readable” by anyone not having the necessary keys.
Telegrams are given a timestamp (runtime) (aka 'consecutive sequential number') and an authentication code (HMAC) and are then encrypted using the following methods:
- AES 128 CTR for the Encryption
- AES 128 CBC MAC for the Data integrity/Authentication (generation of the HMAC)
Depending on the status (enabled/disabled) of the respective device security, a decision is made whether the communication between ETS and the device during commissioning should be secured or plain. Enabling/Disabling the device security is performed on the device in ETS.
KNX Data Secure devices are secured while being put into operation. This comprises the following levels.
- Encryption and Data Integrity ('Device Key' aka 'Factory key')
- Freshness (sequential number)
- Authentication ('Device Key' aka 'Factory key')
- Are imported via ETS either in advance or on demand (see Adding device certificates)
- Are created individually by ETS for each KNX Data Secure device and loaded to the devices during the commissioning (new 'Device Key')
- Are saved in the ETS project (contained in the ETS project export)
Factory Default Setup Key (FDSK)
The FDSK is required for the data integrity and (initial) encryption/authentication of the communication of KNX Data Secure devices with ETS.
- Every KNX Secure device has an individual FDSK when delivered. This, in combination with the device’s serial number, provides a unique 'physical link' (device certificate) to a device upon delivery.
- The FDSK cannot be modified by the ETS user.
- The FDSK can be seen here in the ETS interface.
The Device Key is required for the data integrity and (further) encryption/authentication of the communication of KNX Data Secure devices with ETS.
- Because the FDSK is known outside of ETS, e.g. as a QR code or device label, this key shall be changed in the ETS project
If the FDSK remains known, an attacker could eavesdrop the secured communication.
- The FDSK is replaced by a separate (for this ETS and this KNX Data Secure device) 'Device Key'. The subsequent communication of the device vis-à-vis ETS is then performed with this (new) 'Device Key' (instead of the initial FDSK). Consequently, every KNX Data Secure device has a separate 'Device Key' which is different from the initial FDSK after commissioning.
- The 'Device Key' cannot be modified by the ETS user.
- The 'Device Key' can only be seen in the 'Security' report of a project.
KNX Serial Number
- The KNX Serial Number is required in combination with the Factory Default Setup Key during the (initial) commissioning.
- The KNX Serial Number can be seen here in the ETS interface.
For project properties and KNX Secure, see here.