KNX IP Secure (ISO 22510) adds AES-128-CBC encryption and device authentication to KNXnet/IP communication — protecting KNX automation from network eavesdropping, telegram injection, and unauthorized control. It is increasingly specified in commercial buildings, data centres, and government projects where cybersecurity requirements mandate encrypted building automation. This guide covers the KNX IP Secure specification, ETS6 security configuration, certificate management, device keyring, and network design for secure KNX backbone deployment.

KNX IP Secure specification overview

KNX IP Secure (standardised as ISO 22510, part of KNX specification) provides: (1) Confidentiality: AES-128-CBC encryption of KNXnet/IP telegrams — prevents sniffing of group address values (e.g., alarm codes, access codes, occupancy status). (2) Authentication: HMAC-SHA256 message authentication code — prevents telegram injection (attacker cannot forge a valid KNX telegram). (3) Replay protection: sequence number in each telegram — prevents replay attacks (replaying a captured door-open telegram). KNX IP Secure applies to: KNXnet/IP routing (multicast between IP routers), KNXnet/IP tunnelling (ETS6 programming connections and HomeServer connections). KNX Data Secure (separate, for TP bus) provides encryption on the KNX TP line — requires Data Secure capable devices (newer generation).

ETS6 security project setup

ETS6 6.x: project security settings under Project > Properties > Security. (1) Enable KNX IP Secure: toggle ON. ETS6 generates a project-wide backbone key (256-bit random, stored in ETS6 project). (2) Toolkey: ETS6 generates a toolkey for each KNXnet/IP tunnelling connection (allows ETS6 to connect to secured IP routers). (3) Device certificates: each KNX IP Secure device has a factory-installed X.509 device certificate (installed by manufacturer). ETS6 reads device certificate when scanning — verify manufacturer and serial number match physical device label. (4) Key assignment: ETS6 assigns a unique session key to each IP device based on backbone key. Keys are encrypted with device public key during download — only the target device can decrypt its own keys.

Supported devices and firmware

KNX IP Secure requires specific device support: not all KNX IP routers and tunnelling interfaces are KNX IP Secure capable. Check KNX Association product database for "IP Secure" certification mark. Examples of KNX IP Secure certified devices: MDT SCN-IP100.02 (KNX IP router, AES-128, v3.x firmware), Gira X1 (homeserver, IP Secure tunnelling), ABB IPS/S 2.1 IP router, Weinzierl KNX IP Interface 740 (USB, ETS tunnelling). For existing non-IP-Secure routers: firmware upgrade may add IP Secure capability — check manufacturer release notes. Older IP routers without IP Secure hardware cryptography module cannot be upgraded — must replace hardware.

Keyring export and device programming

Workflow for programming an IP Secure KNX installation: (1) ETS6 creates project with IP Secure enabled, backbone key generated. (2) Add all KNX IP Secure devices to ETS6 topology. (3) Download: ETS6 > Download > Full Device Configuration to each IP router — this downloads both KNX application (group address table) AND security keys (encrypted with device certificate public key). The device decrypts its session keys using factory private key, stores in secure memory. (4) Keyring export: ETS6 > Security > Export Keyring (.knxkeys file) — contains backbone key and device-specific keys for runtime tools. Needed for: HomeServer connections (Gira X1 needs keyring to connect securely to IP routers), third-party KNXnet/IP clients. Keyring file is encrypted with a password — protect it. (5) Toolkey for ETS6: ETS6 tunnelling connections to secured IP routers require toolkey — generated in ETS6, loaded into IP router during download, used for all future ETS6 sessions.

Network design for secure KNX backbone

VLAN segmentation: place all KNXnet/IP devices on a dedicated VLAN (e.g., VLAN 100) — separate from general office LAN. Managed switch: configure VLAN 100 as access VLAN on all ports with KNX IP routers. Inter-VLAN routing: allow only specific traffic: KNXnet/IP multicast (224.0.23.12, port 3671), KNXnet/IP unicast (port 3671), NTP (for timestamp synchronisation in IP Secure replay protection). Block: all other traffic from KNX VLAN to office LAN (prevent KNX devices being accessible from office PCs). Firewall rules: on building LAN firewall, permit 224.0.23.12/32 UDP from KNX VLAN only. If HomeServer or KNX visualisation on different VLAN: add specific allow rule (HomeServer IP → KNX VLAN IP, port 3671). This VLAN design reduces attack surface — even with KNX IP Secure encryption, it is best practice to restrict network access.

Testing and verifying IP Secure operation

After IP Secure programming: (1) ETS6 Group Monitor: verify telegrams appear in group monitor — if IP Secure is working, ETS6 decrypts and displays values normally. If not working (key mismatch), group monitor shows no telegrams. (2) Wireshark capture on KNX VLAN: verify KNXnet/IP packets show cEMI with Security information field — encrypted payload (not readable as plain text). If plain text GA values visible in Wireshark → IP Secure not active. (3) MDT IP router status display: front LED shows lock icon when IP Secure session established. (4) Attempt connection from non-authorised ETS6 (different project, wrong toolkey): should fail with authentication error. (5) Test replay protection: capture one KNXnet/IP packet, replay it with tcpreplay — IP router should reject it (sequence number already used). Document: IP Secure enabled, backbone key ID (first 8 bytes hex, do not export full key), list of secured devices, VLAN design, keyring storage location.