Illustration générée par IA — visuel conceptuel.
Pourquoi KNX Secure devient un sujet “exploitation” (et pas seulement mise en service)
Sur le papier, activer KNX Secure renforce la confidentialité et l’intégrité des communications. En pratique, un projet peut devenir très difficile à reprendre si les mots de passe, certificats et jeux de clés ne sont pas correctement gérés et remis au DOE.
Ce guide se concentre volontairement sur un objectif concret, utile pour un promoteur, une MOA de villa/hôtel, ou un exploitant : décider quoi sécuriser (IP Secure vs Data Secure), comment gouverner les clés, et quels livrables exiger au DOE pour éviter une dépendance à un seul prestataire.
Pour un rappel général (couches de sécurité, surfaces d’exposition), vous pouvez aussi lire : KNX Secure : comment sécuriser une installation domotique professionnelle ?
Décision n°1 : IP Secure ou Data Secure — choisir selon l’exposition réelle
Ce que la KNX Association distingue officiellement
La documentation KNX distingue deux protections, à des niveaux différents :
- KNX IP Secure : protège les communications KNX transportées sur le média IP (Ethernet).
- KNX Data Secure : protège certains télégrammes « entre appareils » au niveau applicatif et peut s’appliquer sur différents médias KNX.
Source KNX Association (Support) : KNX Secure Devices.
Une règle simple pour cadrer le choix côté MOA / exploitant
Si votre KNX traverse un réseau IP partagé (réseau IT d’hôtel, réseau multi-services, switches communs, prestataires IT, VLANs, accès distant, etc.), le premier sujet est généralement KNX IP Secure, car l’exposition vient du LAN et de ses interconnexions.
Si le risque est “terrain” (accès physique à des tableaux, locaux techniques, faux plafonds, etc.) ou si vous voulez sécuriser des flux précis (certaines commandes, certains retours d’état), alors KNX Data Secure devient pertinent, de manière ciblée, sur ce qui doit réellement être protégé.
Point important : la KNX Association précise une règle d’usage : IP Secure est destiné à la partie exposée à un réseau IP externe, tandis que Data Secure ne devrait être utilisé que pour une partie non exposée à un réseau IP externe. Source : KNX Secure Devices.
Ce que ce choix change pour l’exploitation (les clés ne se gèrent pas pareil)
- En IP Secure, ETS crée une clé partagée (souvent désignée « Backbone Key » / « Multicast Group Key ») chargée dans les équipements IP Secure concernés. Cette clé est indiquée comme visible uniquement dans le Security report. Source : KNX IP Secure.
- En Data Secure, ETS remplace la clé d’usine (FDSK) par une Device Key propre au projet/appareil. La Device Key est indiquée comme visible uniquement dans le Security report. Source : KNX Data Secure.
Décision n°2 : qui doit pouvoir faire quoi (exploitant vs intégrateur)
Un projet KNX Secure “réussi” n’est pas seulement un projet chiffré : c’est un projet où l’exploitant peut, sans urgence et sans dépendance :
- ouvrir/reprendre le projet ETS (même plusieurs années plus tard),
- remplacer un appareil,
- ré-commissionner proprement (sans casser la sécurité),
- restaurer une interface KNX/IP (ou un routeur KNX/IP) en cas de panne.
Si votre objectif global est la pérennité, vous pouvez compléter par : Maintenance KNX : comment garantir qu’une installation restera maintenable.
Comprendre les “objets sensibles” côté ETS : certificats, FDSK, mots de passe et keyring
Certificat appareil et FDSK : à ne pas perdre
Pour les appareils KNX Secure, la KNX Association documente le rôle des certificats et de la clé d’usine (FDSK). Le principe à retenir côté DOE est simple : sans certificat/FDSK, la reprise devient risquée (notamment en cas de reset/remplacement et de re-mise en service).
Sources KNX Association : Security et KNX Data Secure.
Project password : le point d’échec majeur à contractualiser
Avec KNX Secure, ETS s’appuie sur un mot de passe de projet (project password). La KNX Association indique que l’export du projet est chiffré et qu’il n’existe aucun moyen de récupération si ce mot de passe est perdu.
Source KNX Association : Project Password.
Conséquence exploitation : un DOE “complet” mais sans project password (ou avec un mot de passe faux) revient, dans les faits, à un DOE inutilisable le jour où vous devez reprendre la main.
Keyring (.knxkeys) : la sauvegarde des secrets KNX Secure
ETS permet d’exporter une keyring (fichier .knxkeys) et de l’importer dans un autre environnement ETS. La KNX Association documente également que la keyring contient des identifiants chiffrés et précise le chemin d’import dans ETS (Project → Security → Import Keyring).
Source KNX Association : Keyring File Format.
Topologie KNX Secure (IP Secure) : figer un choix… ou documenter l’automatique
Au niveau topologie, la KNX Association documente un réglage KNX Secure avec trois modes : Off, On et Automatic, et décrit l’impact dans ETS (génération/suppression de clé selon les changements d’état).
Source KNX Association : Topology – KNX Secure.
Ce que vous devez exiger au DOE n’est pas “un mode parfait”, mais une documentation exploitable :
- quel mode a été retenu (et pour quelle raison),
- quelles zones/segments KNX/IP sont concernés,
- comment ajouter/remplacer un équipement IP Secure (routeur/interface) sans dégrader la sécurité,
- où se connecte ETS en maintenance (poste, réseau, chemin logique).
DOE KNX Secure : les livrables indispensables pour rester autonome
Les articles Domocasa sur le DOE domotique couvrent le “socle” documentaire. Ici, on liste ce qui est spécifique à KNX Secure (anti-dépendance) :
- DOE domotique : quels documents et sauvegardes le client doit-il recevoir ?
- DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ? (si le projet est hôtelier)
Livrable A — Projet ETS exporté + project password (testé)
- Fichier projet ETS exporté (format ETS), versionné et daté.
- Project password remis via un canal maîtrisé (coffre-fort, scellé, procédure interne).
- Preuve de test : la MOA / l’exploitant sait réimporter et ouvrir le projet avec le mot de passe remis.
Base documentaire KNX Association : Project Password.
Livrable B — Keyring (.knxkeys) + mot de passe associé (et procédure d’import)
- Export de keyring (.knxkeys) “fin de chantier” (et idéalement après toute modification significative).
- Mot de passe utilisé lors de l’export « Backup keyring », archivé avec un niveau de contrôle équivalent au project password (ce mot de passe protège les données sensibles exportées).
- Procédure de reprise : comment importer la keyring dans ETS (et qui est autorisé à le faire).
Base documentaire KNX Association : Keyring File Format et Security.
Livrable C — Inventaire des appareils Secure + certificats/FDSK (méthode de récupération)
Exigez un inventaire exploitable : repérage physique, localisation, rôle, et rattachement aux certificats. L’objectif n’est pas de “collectionner des PDF”, mais de garantir qu’en cas de remplacement ou de re-commissioning, vous n’êtes pas bloqué.
Base documentaire KNX Association : KNX Secure Devices et KNX Data Secure.
Livrable D — Security report (remis de façon contrôlée)
Plusieurs informations (ex. clés créées par ETS) sont indiquées comme visibles uniquement dans le Security report. Ce rapport est donc un livrable critique… et sensible.
- Demandez un export (format lisible) du Security report à la réception.
- Définissez une règle d’accès interne : ce document ne doit pas circuler librement (même logique qu’un plan de mots de passe).
Base documentaire KNX Association : KNX IP Secure et KNX Data Secure.
Livrable E — Note “extended frames” : compatibilité du chemin de maintenance
La KNX Association avertit que les télégrammes chiffrés sont plus longs ; l’interface et les coupleurs entre l’interface et l’appareil doivent supporter les extended frames.
Ce point est crucial en exploitation : une installation peut fonctionner au quotidien, mais devenir pénible à maintenir si le chemin de programmation (là où ETS se connecte réellement) n’est pas compatible.
Base documentaire KNX Association : Workflow & Preparation.
Réception : tests minimaux à faire pour éviter le “verrouillage”
Vous n’avez pas besoin de devenir expert ETS pour réduire fortement le risque. À la réception, organisez (avec l’intégrateur) un test de reprise réaliste :
- Test d’ouverture : import du projet ETS sur un poste désigné (exploitant, AMO, DSI hôtel), avec le project password remis.
- Test keyring : import de la keyring sur un autre environnement ETS (ou, à défaut, simulation de restauration sur le même poste) afin de vérifier que la sauvegarde est exploitable.
- Test “maintenance représentative” : se connecter via l’interface réellement utilisée en exploitation (et pas un accès provisoire de chantier), et vérifier qu’une opération de maintenance typique est possible, en tenant compte du sujet extended frames si des équipements Secure sont concernés.
Sources KNX Association : Project Password et Workflow & Preparation.
Gouvernance des secrets : une recommandation de projet (pas une “fonction KNX”)
La KNX Association documente les mécanismes ETS (mots de passe, keyring, certificats). En revanche, la manière de gérer ces secrets au quotidien relève de votre organisation. Recommandations pragmatiques :
- Séparer stockage et usage : les secrets (project password, mot de passe keyring, exports) doivent être stockés dans un coffre-fort maîtrisé par la MOA/exploitant, et non “dans le PC du programmeur”.
- Limiter l’accès : une poignée de personnes identifiées, procédure d’accès tracée (surtout en hôtellerie ou multi-sites).
- Prévoir le scénario “prestataire indisponible” : qui ouvre le coffre, qui relance ETS, qui a le droit de faire un reset appareil si nécessaire, qui valide la remise en service.
- Ne pas confondre secrets KNX (ETS/projet/keyring) et secrets IT (VPN, comptes supervision, accès distant) : les deux doivent exister, mais ils n’ont pas les mêmes cycles de vie.
À demander avant même de consulter un intégrateur : cadrer l’attendu dans le CCTP
Pour éviter les malentendus, clarifiez dès la consultation :
- quelles zones seront en IP Secure (et pourquoi),
- si des flux doivent être en Data Secure (et lesquels),
- quels livrables DOE KNX Secure sont contractuels (projet ETS, mots de passe, keyring, inventaire certificats, Security report, procédure de reprise),
- comment la réception sera testée (scénario de reprise, pas uniquement “ça marche sur l’appli”).
Pour structurer votre consultation côté villa : Cahier des charges KNX pour une villa. Et côté choix du partenaire : Comment choisir un intégrateur KNX au Maroc ?
En synthèse : “décision sécurité” + “livrables clés” = pérennité
- Décider quoi sécuriser : IP Secure si le KNX circule sur un LAN exposé/partagé ; Data Secure si vous devez protéger des flux spécifiques « entre appareils » (selon l’exposition et l’objectif).
- Éviter le verrouillage : exigez le projet ETS + project password, la keyring + son mot de passe, l’inventaire des certificats/FDSK, et un Security report remis de façon contrôlée.
- Tester à la réception une reprise réelle (import, ouverture, opération de maintenance), pas seulement une démonstration fonctionnelle.
Si vous souhaitez sécuriser contractuellement ces points (CCTP, DOE, scénario de réception), Domocasa peut vous accompagner en AMO sur la partie architecture, livrables et maintenabilité KNX.
