Communicatie en dataverwerking zijn tegenwoordig nauwelijks denkbaar zonder rekening te houden met veiligheidsaspecten. Onveilige communicatiesystemen zijn onaanvaardbaar. Het internet heeft de weg al gewezen met het bekende http-protocol uit 1991, dat grotendeels werd vervangen door de versleutelde https-variant. In 1990, een jaar voor het http-protocol, werd het KNX-systeem gelanceerd onder de naam EIB.
Ook in de gebouwenautomatisering kan de behoefte aan veilige communicatie niet langer over het hoofd worden gezien. Ondanks meldingen van sabotage is er momenteel misschien weinig concreet bewijs van daadwerkelijke schade door hackers, maar hun inspanningen zullen waarschijnlijk alleen maar toenemen. Potentiële gevaren voor de technische infrastructuur moeten dus absoluut worden tegengegaan.
KNX veilig maken
Als vereniging van fabrikanten omarmde de KNX Association het onderwerp 'veiligheid' al in een vroeg stadium onder de naam ‘KNX Secure'. Specificatie en implementatie duurden enkele jaren. De belangrijkste oorzaak is de complexiteit van het KNX-protocol, waarbij de groepsadressering die essentieel is voor het hele KNX-systeem, een ware uitdaging is voor veilige versleuteling.
Begin 2019 keurde de technische raad van de KNX Association zowel de systeem- als de testspecificaties goed en werden ze als stabiel beschouwd. Daarnaast heeft de KNX Association veel energie geïnvesteerd in het implementeren van veiligheidaspecten in ETS - de centrale installatiesoftware voor KNX. De testtools voor de ontwikkeling van KNX Secure-apparaten werden overeenkomstig uitgebreid. Er zijn nu gecertificeerde KNX Secure-producten beschikbaar.
Nu KNX Secure een realiteit is, kunnen we de twee varianten, KNX Data Secure en de KNX IP Secure, onder de loep nemen.
KNX Data Secure
KNX Data Secure heeft als doel de communicatie op telegramniveau te beveiligen. Het kan onafhankelijk van het KNX-medium worden gebruikt, zowel voor inbedrijfname als voor runtimecommunicatie.
KNX Association stelde ‘veiligheid vanaf het begin' voorop. Dat houdt in dat zelfs de eerste download naar apparaten door de ETS vanaf het begin versleuteld is. Hiervoor wordt elk apparaat geleverd met een individuele FDSK (Factory Default Setup Key) voor de firmware, die de ETS moet kennen voor de programmering. De belangrijkste informatie wordt samen met het serienummer van het apparaat in een QR-code omgezet en op het apparaat afgedrukt. De code kan door de ETS worden gescand en geëvalueerd met behulp van een pc- of laptopcamera of via een mobiele app. Input kan ook via een toetsenbord.
Aangezien de sleutel van het apparaat bij anderen bekend kan zijn, vervangt de ETS deze door de 'tool key', een sleutel voor de programmering. Deze sleutel wordt ook afzonderlijk voor elk apparaat gegenereerd.
Voor de groepstelegrammen zijn nog andere sleutels nodig. Om de veiligheid te maximaliseren, wordt voor elk groepsadres een aparte sleutel gebruikt. Versleuteling voorkomt dat de data worden gemonitord. Tegelijkertijd zorgt een autorisatiecode in het telegram ervoor dat alleen geautoriseerde apparaten aan de communicatie kunnen deelnemen.
Een bekende aanval op systemen is de 'replay attack'. De aanvaller gebruikt telegrammen die hij afluistert en later opnieuw verzendt zonder ze zelf te kunnen interpreteren. Om dit scenario te voorkomen, bevat elk telegram een telegramnummer dat de betreffende afzender achtereenvolgens toekent. De ontvanger mag alleen telegrammen aannemen die een hoger nummer hebben dan het telegram dat hij het laatst van deze afzender heeft ontvangen. Omdat dit nummer 6 bytes lang is, wordt een overflow praktisch onmogelijk en als een fout geïnterpreteerd.
Gemengde veiligheidsinstallaties
Omdat niet wordt verwacht dat alle benodigde apparaten op korte termijn als veilige variant beschikbaar zullen zijn, is het van belang dat veilige en onveilige communicatie in één installatie kunnen worden gemengd. De veiligheidseigenschap wordt gedefinieerd op groepsniveau. Als er twee communicatieobjecten zijn aangesloten die allebei de veiligheid ondersteunen, stelt de ETS een veilige koppeling voor. Maar als er zich slechts één object zonder veiligheid in een groep bevindt, moet de hele groep onveilig communiceren.
In een apparaat kunnen zich verschillende communicatieobjecten bevinden met verschillende veiligheidseigenschappen. Zo is het mogelijk dat de schakeltelegrammen voor een schakelactor versleuteld zijn, maar dat de terugmeldingen onversleuteld worden verzonden om ze op een beeldscherm te visualiseren. Veiligheid kan ook geval per geval worden gebruikt voor een jaloezieënactor. Dit betekent dat jaloezieën onbeschermd kunnen worden aangestuurd, terwijl raamopeners alleen versleutelde telegrammen aanvaarden.
In een ander voorbeeld zit de versleuteling enkel in gedeeltelijke segmenten van de installatie, zoals een KNX RF-segment, waar versleuteling vereist is. Tegelijkertijd moeten de telegrammen ook naar conventionele KNX Twisted Pair of TP-apparaten kunnen worden verzonden. Hiervoor is de 'Secure Proxy' de oplossing in KNX. Dit is een softwaremodule die is geïmplementeerd in een koppelaar. In het bovenstaande voorbeeld werd de module ingevoerd in de KNX RF/TP-koppelaar. De Secure Proxy vertaalt veilige communicatie van de radiozijde naar onbeveiligde telegrammen op KNX TP en omgekeerd. De Secure Proxy kan echter ook worden toegepast in lijnkoppelaars (TP/TP), bijvoorbeeld om beveiligde externe lijnen aan te sluiten op een onbeveiligd intern KNX-netwerk.
KNX IP Secure
KNX IP Secure volgt een alternatieve benadering, maar is gebaseerd op dezelfde versleutelingsmethoden als KNX Data Secure. KNX IP Secure heeft een pragmatische aanpak, gebaseerd op de veronderstelling dat er een aanvalspunt is op IP-niveau. Waar KNX Twisted Pair, een zuiver plaatselijk in de muur gemonteerd medium, als relatief veilig wordt beschouwd, kan IP-communicatie die vaak verbonden is met het internet, vanop afstand worden aangevallen.
KNX IP Secure beschermt KNX IP-communicatie terwijl communicatie op KNX TP onversleuteld blijft. Het belangrijkste voordeel van dit systeem is dat de bestaande KNX TP-apparaten en -installaties ongewijzigd kunnen worden gebruikt. Alleen de KNX IP-apparaten, d.w.z. vooral de KNX IP-interfaces en KNX IP-routers, moeten worden vervangen.
KNX IP omvat het routingprotocol, dat wordt gebruikt voor IP-backbones, maar vertegenwoordigt ook het KNX IP-medium. Anderzijds wordt het tunnellingprotocol gebruikt om een client (bijv. ETS) toegang te geven tot een TP-lijn via IP. Terwijl KNX IP-routers meestal beide protocollen implementeren, ondersteunen KNX IP-interfaces alleen de tunnellingfunctie.
Zo verschillend als de twee toepassingen van KNX IP, zo verschillend zijn de respectieve extensies voor veiligheid. Met het Secure Routing-protocol, dat is gebaseerd op UDP Multicast, wordt een gemeenschappelijke sleutel gebruikt om alle KNX IP-routingcommunicatie te versleutelen. Een bijzondere functie is de telegramteller tijdens de routing. Die is op tijd gebaseerd en vertegenwoordigt dus een timestamp waarmee verouderde telegrammen kunnen worden gedetecteerd. De gemeenschappelijke systeemtijd wordt continu gesynchroniseerd tussen de apparaten.
Met het tunnellingprotocol brengen de client en het KNX IP-apparaat (KNXnet/IP-server) eerst een veilig kanaal tot stand met de Diffie-Hellmann-methode. Pas dan worden de gebruikers-ID en het wachtwoord overgedragen. Het tot stand brengen van de verbinding met TCP is een nieuwe functie van KNX Secure Tunnelling. Naast de optie om toegang te krijgen tot een buslijn, maakt tunnelling ook de zeer snelle programmering van KNX IP-apparaten mogelijk.
KNX Secure vanuit het oogpunt van de fabrikant
KNX Secure is zeker een uitdaging voor fabrikanten. De uitbreiding van bestaande KNX-apparaten met KNX Secure zal in de meeste gevallen niet mogelijk zijn zonder de hardware te wijzigen, aangezien de vereisten voor beschikbaar geheugen en rekenkracht toenemen. Sleuteltoewijzing en printen moet ook worden geïmplementeerd als QR-code in productie.
Ook voor de fabrikanten van software voor KNX ontstaan nieuwe eisen, bijvoorbeeld visualisaties. Het is niet langer voldoende om de groepsadressen van het project te importeren of in te voeren. Zelfs kennis van de gebruikte sleutels is niet voldoende om versleutelde groepstelegrammen te verzenden. In plaats daarvan moet elke deelnemer worden bekendgemaakt op alle apparaten die hij moet bereiken. Dit is momenteel alleen mogelijk via ETS, en dat zal waarschijnlijk zo blijven. Voor de meeste apparaten op de markt die vandaag niet in gebruik kunnen worden genomen met ETS, is de weg naar een veilig KNX-communicatiesysteem waarschijnlijk een (beheersbare) uitdaging.
Dr.-Ing. Thomas Weinzierl is de CEO van Weinzierl Engineering GmbH, fabrikant van KNX-producten en leverancier van een volledig assortiment ontwikkelings- en testdiensten voor hardware en software.