Modifier la clé de sécurité Z-Wave

nechry

Passionné par les technologies depuis l'enfance, je consacre maintenant la majorité de mes temps libre à la domotique. En tant que développeur principal du plugin Z-Wave pour la solution jeedom et contributeur de la librairie open-source openzwave, mon but est de vous aider à mettre ces technologies à contribution pour vous faciliter la vie !

Vous aimerez aussi...

14 réponses

  1. mortyre dit :

    Merci Nechry pour se super article. Je ne comprends pas à la lecture de celui-ci comment cette fonctionnalité de changement de clé ne soit pas inclus dans Jeedom par défaut, car c’est un réel problème de sécurité, et car devoir le faire manuellement à chaque versionning du plugin c’est rédhibitoire.
    Il faudrait que lors de l’installation du plugin zwave dans JEedom qu’une clé aléatoire soit crée, et le tour serait joué pour que chacun est sa propre clé. Cela ne doit pas être très dur à mettre en place ?

  2. aurel dit :

    merci pour l’article 🙂

  3. Mav3656 dit :

    Bravo pour ce tutoriel. Rares sont les explications d’une telle qualité sur la toile.

  4. arnog23 dit :

    Bonjour Nechry et merci pour ce nouvel article toujours aussi instructif.

    Je viens de faire quelques tests de changement de clé sur une maquette avant de faire cela en prod.

    Si j’exécute tel quelle la commande pour générer une clé, j’obtiens l’erreur suivante : sed: -e expression #1, char 1: unknown command: `▒’ probablement à cause des quotes qui ne passent pas bien en faisant un copier/coller. En corrigeant les back quotes par des quotes dans le sed, la commande s’exécute correctement. En revanche, la commande ne génère pas forcement une clé de 16 octets.

    Voici quelques résultats obtenus (1 clé par ligne) avec des caractères un peu bizarre:
    0xB8, 0x4B, 0xCF, 3▒0xF0, 9▒0xF7, ▒0xF5, 0xAC, 0x42, 0x18, 0xE8, 0x6D, 0x5A, 0x43, A
    0xE9, 0x67, 0xBC, 0x00, 0x50, 0x66, 0x2E, 0x78, ▒0xB2, 0x43, 0x29, 0xC6, 0xC1, 0x76, 0xEC, 8
    0x5B, ▒0x40, 0x2D, 0x42, 0x4F, 0x7A, ▒A▒▒▒0xF7, C▒0x5E, 0x7A, 0x77, 0x52, 0x2C

    J’ai donc généré une clé manuellement pour faire mes tests et je suis tombé sur un comportement qui me surprend.

    J’ai d’abord inclus un FMGS-001 en mode sécurisé avec la clé d’origine (en Regénérant lé detection du noeud puis restart du deamon zwave et reveil du module comme indiqué dans ton autre article (Merci aussi pour celui-ci)). J’ai bien le cadenas fermé pour celui-ci et le module fonctionne correctement.

    J’ai ensuite changé la clé et redémarré le deamon zwave. Et là, surprise, lorque je reveil mon FGMS, je vois bien l’état passé à réveillé sur la page d’info du noeud avec l’heure du dernier message qui correspond. En revanche, le module ne semble pas remonter ses valeurs.

    J’ai ensuite inclus un autre FGMS-001 aussi en mode sécurisé mais avec la nouvelle clé. J’ai bien le cadenas fermé pour celui-ci et le module fonctionne correctement (remontée de ses valeurs avec la nouvelle clé).

    J’ai enfin remis la clé d’origine et redémarrer le deamon zwave. Le premier FGMS fonctionne de nouveau correctement et cette fois même comportement pour le 2eme lorsque je le reveille.

    Il semblerait donc qu’un module inclus avant un changement de clé soit capable de remonter son état après un changement de clé. Cela voudrait-il dire que seulement une partie des communications est sécurisée ? La remonter d’état ne le serait pas par exemple ?

    Merci.

    • nechry dit :

      Oui effectivement je n’ai pas pensé en parler ici mais pas tout les cmd requièrent d’être en mode sécurisé. Dans l’article on voit aussi dans le code une option qui est actuellement activé pour définir quelles cmd doivent être forcées en sécurisé. Comme j’ai fais le lab avec un verrou qui lui exige des cmd sécurisé on est vite bloqué, mais sur lui aussi le ping va fonctionner meme sans la bonne clé.

    • nechry dit :

      Je vais vérifier le petit script de génération de clé, je n’ai pas eux de problème mais ça pourrait venir du passage en page web.

  5. arnog23 dit :

    Quand tu dis que toutes les commandes requièrent d’être en mode sécurisée, cela est-il parametrable au niveau zwave ou bien cela dépend des modules ? De quelle option s’agit-il ? EnforceSecureReception ?

    • nechry dit :

      C’est l’option SecurityStrategy. Mais c’est pas exactement tous, mais soit les essentiels, les supporter ou en mode custom. Custom ont défini les CC que l’ont souhaite supporter. Bien sûr c’est toujours ce que le module expose en sécurisé ou non, on peut pas demande du secure a un module qui ne supporte pas un Cc en sécurisé.

      Le EnforceSecureReception à true va « dropper » les messages reçu en claire s’il devrait arriver en sécurisé.

      Donc ce que je voulais dire avec le doorlock c’est que lui les cmd de verrouillage doivent obligatoirement arriver en mode sécurisé pour fonctionner sinon il ne fonctionnera jamais.

  6. arnog23 dit :

    Quels sont les autres valeurs supportées par l’option SecurityStrategy à part « Supported » ?

    Du coup, que faudrait-il faire pour sécuriser au mieux le réseau zwave en plus de modifier la clé par défaut ?

  1. 22 janvier 2018

    […] Comment modifier sa clé de sécurité Z-Wave. […]

  2. 29 janvier 2018

    […] Comment protéger son réseau à l’aide d’une clé de sécurité privée. […]

  3. 29 janvier 2018

    […] Comment modifier la clé réseau par défaut avec une clé privée unique. […]

Laisser un commentaire

x Shield Logo
This Site Is Protected By
The Shield →
%d blogueurs aiment cette page :