Aujourd'hui, la communication et le traitement des données sont difficilement concevables sans considérer les aspects de sécurité. En effet, les systèmes de communication non sécurisés deviennent rapidement inacceptables. La voie a déjà été montrée par Internet, le protocole bien connu 'http' de 1991 ayant été largement remplacé par la variante cryptée 'https'. D'ailleurs, un an avant http, le système KNX a été lancé en 1990 sous le nom d'EIB.
Même dans les bâtiments, la nécessité d'une communication sécurisée ne peut plus être négligée. À l'heure actuelle, malgré les rapports de falsification, il y a peu de preuves concrètes de dommages réels causés par les pirates. Toutefois, leurs efforts ne feront que s'intensifier et il est donc nécessaire de contrer les dangers potentiels au niveau de l'infrastructure technique.
Sécuriser KNX
En tant qu'association de fabricants, la KNX Association a très tôt abordé le sujet de la sécurité sous le titre ‘KNX Secure'. La spécification et la mise en œuvre ont pris plusieurs années ; principalement en raison de la complexité du protocole KNX, pour lequel le groupe adresse qui est essentiel à l'ensemble du système KNX, est tout un défi pour le cryptage sécurisé.
Au début de 2019, les caractéristiques du système et des tests étaient considérées comme stables et approuvées par le conseil technique de l'association KNX. De plus, l'association KNX a investi beaucoup d'efforts dans la mise en œuvre du thème de la sécurité dans l'ETS - le logiciel d'installation central pour KNX. Les outils de test pour le développement d'appareils KNX Secure ont également été étendus en conséquence et des produits certifiés KNX Secure sont désormais disponibles.
Donc, maintenant que KNX Secure est une réalité, regardons plus en détail ses deux variants, à savoir KNX Data Secure et KNX IP Secure.
KNX Data Secure
KNX Data Secure vise à sécuriser la communication au niveau des télégrammes. Il peut être utilisé indépendamment du support KNX aussi bien pour la mise en service que pour la communication d'exécution.
L'association KNX s'est fixé l'objectif de ‘la sécurité dès le départ'. Cela signifie que même le premier téléchargement vers les appareils par l'ETS est crypté dès le départ. À cet effet, chaque appareil est livré avec une FDSK (Factory Default Setup Key) individuelle au firmware, que l'ETS doit connaître avant la programmation. Les informations clés sont intégrées avec le numéro de série de l'appareil dans un code QR et imprimées sur l'appareil. Le code peut être scanné et évalué par l'ETS à l'aide d'un PC ou d'une caméra portable ou via une application mobile. La contribution via un clavier est également possible.
Étant donné que la clé de l'appareil peut être connue par d'autres, l'ETS la remplace par la 'clé d'outil', c'est-à-dire une clé de programmation. Cette clé est également générée individuellement pour chaque appareil.
D'autres touches sont nécessaires pour les télégrammes de groupe. Pour une sécurité maximale, une clé distincte est utilisée pour chaque adresse de groupe. Le cryptage empêche la surveillance des données. En parallèle, un code d'autorisation dans le télégramme garantit que seuls les appareils autorisés peuvent participer à la communication.
Une attaque bien connue contre les systèmes est la soi-disant 'attaque par rejeu'. L'attaquant utilise des télégrammes qu'ils écoutent et renvoient plus tard sans qu'ils puissent les interpréter eux-mêmes. Afin d'éviter ce scénario, chaque télégramme contient un numéro de télégramme que l'expéditeur respectif attribue successivement. Le récepteur ne peut accepter que des télégrammes dont le numéro est supérieur au dernier télégramme qu'il a reçu de cette station. En raison de la longueur de 6 octets de ce numéro, un débordement est pratiquement impossible et est interprété comme une erreur.
Installations de sécurité mixtes
Comme on ne s'attend pas à ce que tous les appareils requis soient disponibles en tant que variante sécurisée à court terme, il est important que les communications sécurisées et non sécurisées puissent être combinées dans une seule installation. La propriété sécurisée est définie au niveau du groupe. Si deux objets de groupe supportant tous les deux la sécurité sont connectés, l'ETS propose une liaison sécurisée. Cependant, si un seul objet se trouve dans un groupe sans sécurité, l'ensemble du groupe doit communiquer de manière non sécurisée.
Différents objets de communication dans un appareil peuvent avoir des propriétés de sécurité différentes. Ainsi, il est possible, par exemple, que les télégrammes de commutation pour un actionneur de commutation soient cryptés, mais les messages de retour d'information soient envoyés en clair afin de les afficher lors de la visualisation. La sécurité pourrait également être utilisée au cas par cas pour un actionneur de stores. Cela signifie que les stores peuvent être contrôlés sans protection, tandis que les ouvre-fenêtres n'acceptent que les télégrammes cryptés.
Un autre scénario est le cryptage uniquement dans des segments partiels de l'installation, comme un segment KNX Radiofréquences, pour lequel le cryptage est une exigence importante. Dans le même temps, les télégrammes doivent également pouvoir être envoyés aux appareils KNX Twisted Pair (TP) conventionnels. La solution à cette exigence dans KNX est le « Secure Proxy ». Il s'agit d'un module logiciel qui est implémenté dans un coupleur. Dans l'exemple ci-dessus, il est implémenté dans le coupleur KNX Radiofréquences/TP. Le Secure Proxy traduit la communication sécurisée du côté radio en télégrammes non sécurisés sur KNX TP et vice versa. Cependant, le Secure Proxy peut également être implémenté dans des coupleurs de ligne (TP/TP), par exemple pour connecter des lignes externes sécurisées à un réseau KNX interne non sécurisé.
KNX IP Secure
KNX IP Secure suit une approche alternative, mais est basé sur les mêmes méthodes de cryptage que KNX Data Secure. KNX IP Secure est une approche pragmatique basée sur l'hypothèse qu'il existe un point d'attaque au niveau IP. Alors que KNX Twisted Pair est supposé être relativement sécurisé en tant que support purement local situé dans le mur, la communication IP est souvent connectée à Internet et peut donc être attaquée à distance.
KNX IP Secure protège la communication KNX IP tandis que la communication sur KNX TP reste non cryptée. Le principal avantage de cette approche est que les appareils et installations KNX TP existants peuvent continuer à être utilisés sans changement. Seuls les appareils IP KNX, c'est-à-dire essentiellement les interfaces IP KNX et les routeurs IP KNX, doivent être remplacés.
KNX IP inclut le protocole de routage, qui est utilisé pour les zones IP, mais représente également le support KNX IP. D'autre part, le protocole de tunnel est utilisé pour permettre à un client (par exemple ETS) d'accéder à une ligne TP via IP. Alors que les routeurs IP KNX implémentent généralement les deux protocoles, les interfaces IP KNX ne prennent en charge que la fonction de tunnel.
Aussi différentes que soient les deux applications de KNX IP, les extensions respectives pour la sécurité sont aussi différentes. Avec le protocole de routage sécurisé, basé sur UDP Multicast, une clé commune est utilisée pour crypter toutes les communications de routage IP KNX. Une particularité est le compteur de télégrammes pendant le routage. Celui-ci est basé sur le temps et représente donc un horodatage qui permet de détecter les télégrammes obsolètes. L'heure système commune est synchronisée en permanence entre les appareils.
Avec le protocole de tunnel, le client et l'appareil IP KNX (serveur KNXnet/IP) établissent d'abord un canal sécurisé à l'aide de la méthode dite Diffie-Hellmann. Ce n'est qu'alors que l'ID utilisateur et le mot de passe sont transférés. Une nouvelle fonctionnalité de KNX Secure Tunneling est la possibilité d'établir la connexion avec TCP. Outre la possibilité d'accéder à une ligne de bus, le tunnel permet également de programmer très rapidement les appareils IP KNX.
KNX Secure du point de vue du fabricant
KNX Secure est certainement un défi pour les fabricants. L'extension des appareils KNX existants avec KNX Secure ne sera, dans la plupart des cas, pas possible sans changer le matériel, car les exigences en matière de mémoire disponible et de puissance de calcul augmentent. L'attribution des clés et l'impression doivent également être implémentées sous forme de code QR en production.
De nouvelles exigences apparaissent également pour les fabricants de logiciels pour KNX, comme par exemple les visualisations. Il ne suffit plus d'importer ou de saisir les adresses de groupe du projet. Même la connaissance des clés utilisées n'est pas suffisante pour envoyer des télégrammes de groupe cryptés. Au contraire, chaque participant doit être connu de tous les appareils qu'il doit atteindre. Ceci n'est actuellement, et continuera probablement d'être, possible que via l'ETS. Pour la plupart des appareils sur le marché qui ne peuvent pas être mis en service à l'aide de l'ETS aujourd'hui, la voie vers un système de communication KNX sécurisé est susceptible d'être un défi, mais il sera gérable.
Dr.-Ing. Thomas Weinzierl est le PDG de Weinzierl Engineering GmbH, fabricant de produits KNX et fournisseur d'une gamme complète de services de développement et de test de matériel et de logiciels.