Modifier la clé de sécurité Z-Wave
Deuxième sujet dans cette série d’articles sur la sécurité du protocole Z-Wave, comment modifier la clé de sécurité Z-Wave.
Dans le premier sujet, nous avons vu que la clé privée pouvait être utilisée dans des attaques sur votre réseau Z-Wave.
Une des premières actions à prendre serait de modifier la clé générique par une clé privée unique.
Comment modifier la clé de sécurité de son réseau Z-Wave
Une clé de sécurité privée est requise pour effectuer les inclusions en mode sécurisé. Cette clé de sécurité devrait être secrète, sinon, malgré l’inclusion sécurisée, si tout le monde connaît votre clé, c’est comme de verrouiller la porte d’entrée en laissant la clé sous le paillasson.
Lorsque les inclusions sécurisées ont été supportées dans Jeedom, nous avons utilisé une clé de sécurité générique qui est la clé de sécurité par défaut proposée dans la librairie openzwave.
Cette clé de sécurité est simplement :
0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F 0x10
Cette clé de sécurité est livrée avec le plugin. Il n’y a pas à l’heure actuelle de possibilité de la modifier via l’interface de configuration du plugin.
Il n’empêche que vous pouvez sans problème modifier cette clé de sécurité en éditant le fichier:
resources/openzwaved/ozwave/manager_utils.py
à la ligne 24, il s’agit l’option NetworkKey qui sera utilisé lors du chargement du réseau Z-Wave.
Considérations
Choses importantes à savoir avant d’entreprendre la modification de la clé de sécurité de son réseau ZWave:
- Si vous avez déjà procédé à des inclusions sécurisées avec la clé par défaut, la modification de la clé rend impossible les communications avec les modules inclus en mode sécurisé. Il vous faudra les exclure et inclure à nouveau.
- Lorsque le plugin Z-Wave est mis à jour, votre clé privée personnelle sera remplacée par celle par défaut. L’ensemble des fichiers du plugin sont écrasés lors d’une mise à jour. Il faudra alors éditer à nouveau le fichier pour remettre votre clé privée personnelle.
- En complément au point précédent, il vous vaudra faire une copie de votre clé réseau privé sur un lieu sûr. Vous pouvez par exemple utiliser un keypass ou tout autre endroit sécurisé. Si vous perdez votre clé privée, vous ne serez plus en mesure de communiquer avec vos modules et il vous faudra refaire les inclusions avec une nouvelle clé.
Dernier point je pense que le plugin Z-Wave va continuer à évoluer et que vous aurez la possibilité de gérer votre clé privée via l’écran de configuration du plugin.
Préparation
Avec ces différentes considérations je continue sur la procédure de modification de la clé de votre réseau Z-Wave.
Il faudra se connecter en SSH à votre Jeedom, sous mac c’est simplement via le terminal et on tape ssh jeedom@ipjeedom en remplaçant ipjeedom par l’adresse ip de votre box jeedom, comme par exemple :
ssh jeedom@168.192.1.110
Votre jeedom demande votre mot de passe par défaut c’est Mjeedom96 puis on se retrouve en mode console dans votre Jeedom. Sous Windows il vous faudra utiliser le logiciel Putty pour établir une connexion ssh avec votre jeedom.
Le plugin Z-Wave se trouve dans le dossier /var/www/html/plugins/openzwave/ pour une installation Apache.
Se rendre donc dans le dossier contenant le fichier à modifier avec
cd /var/www/html/plugins/openzwave/resources/openzwaved/ozwave
Penser à faire une copie de sécurité du fichier avant de le modifier
sudo cp manager_utils.py manager_utils.old
Par exemple pour en faire une copie nommée manager_utils.old
Génération d’une clé privée unique
Vous devez choisir une valeur de 16 octets comme clé de réseau.
Une façon simple pour générer votre clé aléatoire est la suivante :
cat /dev/urandom | tr -dc '0-9A-F' | fold -w 32 | head -n 1 | sed -e 's/\(..\)/0x\1, /g' -e 's/, $//'
Attention au copié collé, les guillemets sont des fois altérés.
Pour obtenir par exemple :
0xE0, 0x4B, 0xF2, 0x47, 0x64, 0x55, 0x25, 0x49, 0xE6, 0x6A, 0xF7, 0xE9, 0x23, 0x44, 0xA8, 0x51
A chaque exécution une nouvelle clé unique est générée.
On copie le contenu de cette clé, et penser à la sauvegarder sur un lieu sûr.
Puis à l’aide de votre éditeur préféré vi, nano ou autre on édite le fichier manager_utils.py, ici avec nano:
sudo nano manager_utils.py
On remplace la clé par défaut par la nouvelle précédemment générée juste avant
Puis on quitte l’éditeur avec CTRL-x, on nous demande de sauvegarder
On confirme avec Y puis ENTER pour valider le nom de fichier.
Redémarrer le plugin
On peut maintenant redémarrer le demon du plugin Z-Wave pour prendre en compte le changement de la clé.
Via l’écran de configuration du plugin on clique le bouton Redémarrer.
Conclusion
Voilà, vous avez maintenant une clé de réseau privée unique et vous pouvez commencer à effectuer des inclusions en mode sécurisé.
Comme j’avais expliqué dans le premier sujet sur la sécurité du protocole Z-Wave, il est relativement simple d’écouter les trames pour trouver le HomeId. La clé réseau, elle, c’est plus complexe, si vous avez toujours la clé générique de la librairie, un hacker (ou plutôt un malfaiteur) pourrait simplement essayer la clé générique en espérant que vous ne l’avez pas remplacée. Il faut nettement plus d’effort pour extraire la clé privée, déjà il faudra que la personne soit à proximité restreinte du module.
Remplacer la clé réseau générique par défaut par une clé unique privée n’est dans tous les cas pas une mauvaise chose à faire si vous souhaitez mieux sécuriser votre domotique.
Pensez aussi, du coup, à modifier le mot de passe de votre Jeedom (si ce n’est pas encore fait).
Maintenant que nous avons une clé privée unique, on peut passer au prochain article, les inclusions en mode sécurisé.
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 ?
merci pour l’article 🙂
Bravo pour ce tutoriel. Rares sont les explications d’une telle qualité sur la toile.
merci beaucoup, ça fait bien plaisir.
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.
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é.
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.
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 ?
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.
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 ?
Soit Essentiel, Supported ou Custom comme expliqué plus haut. Le supported est le bon choix, comme il ce calque avec le module.
Merci Nechry pour ce topic qui une fois de plus apporte de l’eau (Suisse !) au moulin de Jeedom !
Covernant la commande de generation de clef, il faut après le paste repasser sur les ‘ et les retaper depuis le clavier et alors ….
manu@jtest:/var/www/html$ cat /dev/urandom | tr -dc ‘0-9A-F’ | fold -w 32 | head -n 1 | sed -e ‘s/\(..\)/0x\1, /g’ -e ‘s/, $//’
0x9F, 0x94, 0x1F, 0x19, 0x83, 0xCF, 0xEE, 0xA7, 0x90, 0xF3, 0x64, 0x44, 0x31, 0xFE, 0x65, 0x09
Merci du retour, je vais voir pour adapter l’article, je pense le format web a altéré la cmd.
Super série d’articles très instructifs, merci Nechry.
Au sujet de la clef privée, j’ai récemment remarqué que le dongle USB ZWave ZW090 de Aeotec stocke aussi une clef de sécurité, que l’on peut voir ou paramétrer dans le logiciel de sauvegarde lorsqu’on connecte le dongle en USB à un ordi Windaube. On peut voir le réglage dans les copies d’écrans ici:
https://aeotec.freshdesk.com/support/solutions/articles/6000167023-how-to-use-z-stick-gen5-backup-software-backup-and-restore-
Quel est le lien entre la clef que l’on définit dans Jeedom et la clef stockée dans le dongle ZW090 ? Est-ce que la clef du dongle écrase celle de Jeedom ?
salut Aktarus, alors tu as besoin de fournir la clé (celle que tu définie dans jeedom, que ce soit celle par défaut ou la privée) dans l’entrée de la clé de l’utilitaire de Aeotec. L’utilitaire Aeotec n’extrait pas la clé c’est là seulement pour la saisir lorsqu’on travail en mode sécurisé