Aujourd'hui je vais vous présenter un retour d'expérience sur la mise en œuvre du plugin Z-Wave (version du 2017-12-08) sur une JeedomSmart 3.1.7 avec 2 modules Z-Wave+ : un répéteur AEOTEC et un switch FIBARO.
Le présent billet "(Part2)" fait suite au précédent ici
et a pour objectif de fournir un complément d'information sur la sécurité Z-Wave+ en répondant à la question posée par anto35 :
J'ai procédé en 3 étapes :anto35 a écrit :
Un noeud non sécurisé est il capable de router des paquets sécurisés ? J'avoue que je me perd un peu avec ça. Il me semble qu'un noeud avec cadenas route des messages en clair, mais j'ai un doute sur l'inverse.
-étude théorique
-étude pratique
-réponse à la question posée
1) Etude théorique
Je me suis appuyé dans ma réflexion sur un article du magazine MISC de novembre 2015 écrit par Kevin Bontems intitulé « La sécurité du protocole Z-Wave », accessible ici :
https://connect.ed-diamond.com/MISC/MIS ... ole-Z-Wave
Voici les extraits choisis qu'il convient de retenir pour aider à répondre à la question posée :
(uniquement relevés dans les 4 premiers paragraphes)
- Z-Wave permet d’établir un maillage (réseau) pour relayer les communications
- implémente un mécanisme de retour d’état (ACK) permettant de garantir que les messages ont bien été reçus et compris
- sécurise les communications en s’appuyant sur un chiffrement symétrique AES (128 bits)
- 2 types d'équipements : contrôleurs et nœuds esclaves
- le réseau et ses équipements sont représentés par un identifiant respectivement « HomeID » et « NodeId »
- Certains nœuds peuvent être utilisés pour relayer le signal Z-Wave à d’autres. Un tel relais permet de construire un maillage et rend le réseau plus tolérant aux erreurs de transmission et de communication.
- Z-Wave est un protocole propriétaire (Une implémentation open source « OpenZWave » a été développée en analysant le fonctionnement du protocole) mais est basé sur un standard (ITU-T G.9959) normalisant les couches basses MAC et PHY). Au-dessus de ces deux couches bas-niveau, une troisième couche applicative décrit toutes les informations permettant de contrôler les modules et d’en rapporter l’état.
- le contenu des premiers champs de la couche applicative peut légèrement varier pour les trames multicast, routées ou chiffrées.
- Z-Wave permet aux modules (noeuds) de chiffrer les communications en AES 128 bits en utilisant la classe de commande COMMAND_CLASS_SECURITY. Celle-ci permet d’encapsuler les données de la couche applicative
- Avec OpenZWave, la liste des classes reconnues et sécurisées pour les différents périphériques est stockée dans le fichier de configuration zwcfg_[HomeID].xml
Essayons maintenant d’interpréter ces informations:
En théorie si un noeud ayant des capacités de routage reçoit un message Z-Wave qui ne lui est pas destiné il le retransmet au destinataire final (notion de voisins et de table de routage). « Router » ou « relayer » ou « répéter » les messages/commandes de la couche applicative se réalise au niveau de la couche MAC sur la base des identifiants source et destination des nœuds. Qu'une commande soit chiffrée ou non (couche applicative) l'identifiant du noeud source et du nœud destination est toujours en clair (couche MAC).
Autrement dit il semble que théoriquement un nœud sécurisé ou non sécurisé ayant des capacités de routage pourrait être capable de router des commandes sécurisées ou non sécurisées.
2) Etude pratique
Pour mettre en pratique l'énoncé théorique précédent, j'ai utilisé la JeedomSmart et les 2 modules Z-Wave+ suivant :
-AEOTEC ZW117-C15 Range extender 6 Gen5 (v1.04) Répéteur
-FIBARO FGS-223 ZW5 Double switch 2 (v3.2) Double charge
Le micromodule switch est monté avec un interrupteur et une ampoule classique.
L'idée c'est d'avoir un nœud routeur (le répéteur) situé entre la JeedomSmart et le switch et d'éloigner suffisamment le switch de la JeedomSmart et du répéteur de telle manière que le switch ne puisse communiquer avec la JeedomSmart qu'au travers du répéteur (et non pas en direct).
Pour s'assurer que le switch est suffisamment éloigné pour ne pas communiquer directement avec la JeedomSmart il faudra partir d'un cas ou on peut effectivement allumer l'ampoule, puis débrancher le répéteur et constater qu'il n'est plus possible d'allumer l'ampoule.
Nous allons mettre en oeuvre 2 cas :
Cas 1 : JeedomSmart (commande non sécurisé) → répéteur (en mode sécurisé) → switch non sécurisé
Cas 2 : JeedomSmart (commande sécurisé) → répéteur (en mode non sécurisé) → switch sécurisé
Pour passer d'un cas à l'autre il faut faire une exclusion et une réinclusion (en inversant le mode sécurisé/non sécurisé) du répéteur et du switch.
La jeedomSmart est utilisée pour réaliser les inclusions et les exclusions des 2 modules dans le réseau Z-Wave.
Pour inclure et exclure les équipements :
-Switch1: pour inclusion ou exclusion, appuyer rapidement 3 fois sur l'interrupteur S1. (voir la documentation du FGS-223 pour le montage de l'interrupteur)
-Répéteur :
. Inclusion :
en mode non sécurisé : appuyer rapidement une fois sur le bouton.
en mode sécurisé : appuyer rapidement 2 fois en moins d'une seconde sur le bouton,
. Exclusion : appuyer rapidement une fois sur le bouton
A noter que lorsque le switch est en mode sécurisé, la valeur du paramètre « Associations in Z-Wave network security mode » est à 15 par défaut : sécurise tous les groupes d'associations.
Cas 1 : répéteur sécurisé, switch non sécurisé
Compte tenu de la disposition (JeedomSmart, répéteur, switch) qui a été réalisée, lorsqu'on débranche le répéteur, le switch passe en statut « DEATH » (visible dans la page santé zwave). Cela prouve que la JeedomSmart ne "voit" le switch qu'en passant par le répéteur, ce qui est le but recherché.
Pour refaire passer le switch en statut « Complete » il suffit de rebrancher le répéteur et d'allumer/éteindre une fois l'ampoule sur le switch à l'aide de l'interrupteur.
On allume l'ampoule en cliquant sur le bouton « Tester » de la commande « On » du Switch.
ATTENTION ! : cette classe de commande fonctionne ce qui ne veut pas dire que cela fonctionnerait pour toute les classes de commande.
Cas 2 : répéteur non sécurisé, switch sécurisé
La disposition (JeedomSmart, répéteur, switch) est identique au cas précédent. Cependant
même si le répéteur est branché le Switch reste en statut « DEATH »
Ce qui veut dire que la JeedomSmart ne voit pas le switch via le répéteur, et donc que le clique sur le bouton « Tester » de la commande « On » du Switch n'a pas d'effet.
Voici le résultat des tests :
3) Réponse à la question posée
Conclusion,
il semblait que théoriquement un nœud sécurisé ou non sécurisé ayant des capacités de routage pourrait être capable de router des commandes sécurisées ou non sécurisées,
mais en pratique la JeedomSmart ne « voit » pas le switch sécurisé « derrière » le répéteur non sécurisé et considère que le switch est mort, ce qui empêche d'envoyer une commande sécurisée.
Ma réponse @anto35 est donc la suivante :
> Un noeud sécurisé est il capable de router des paquets non sécurisés ?
oui en théorie et oui avec la JeedomSmart, le répéteur AOTEC et le Switch FIBARO.
> Un noeud non sécurisé est il capable de router des paquets sécurisés ?
Il semble que oui en théorie mais je n'ai pas réussi à confirmer ou infirmer à ce stade avec la JeedomSmart, le répéteur AOTEC et le Switch FIBARO.
La réponse n'est donc pas définitive.
Il conviendrait de poursuivre l'expérimentation, éventuellement avec d'autres équipements.
Voila j'espère que ce retour d’expérience sera utile aux membres Jeedom.
akenad