Inclusion sécurisée et communication chiffrée, bug/not bug?

[loupdefil]

Bonjour à tous,

Je souhaite mettre en oeuvre les communication sécurisée avec Jeedom 2.4.6 et le plugin Z-Wave 1.4.2088 du 17-08-2016.
Il me semble que cela ne fonctionne pas, mais peut-être ai-je mal compris les capacités du mode sécurisé.

Config:
-----------
- Jeedom 2.4.6 sur Debian 8 (patché)
- Plugin Z-Wave 1.4.2088
- Contrôleur Z-Wave USB Aeon Labs Stick ZW090 Z-Stick Gen5
- Aeon Labs Smart Switch Gen5 (ZW075)

Symptômes:
------------------
1) Je fais l'inclusion du Smart Switch en mode sécurisé et lorseque je regarde l'état de santé du réseau Z-Wave à l'aide
de l'icône "Santé" du plugin Z-Wave, le périphérique concerné a le cadenas ouvert.

2) Une clé de chiffrement doit être spécifiée quelque part, je n'ai trouvé aucune indication à ce sujet.

Diagnostiques:
---------------------
Il existe une classe JeeDOM COMMAND_CLASS_SECURITY qui est codée dans le plugin Z-Wave puisque l'on
voit des périphériques avec ou sans cadenas, cadenas ouvert ou fermé.

Il existe un fichier de configuration
/var/www/html/plugins/openzwave/resources/openzwaved/config/options.xml
dans lequel on peut spécifier la valeur "NetworkKey". Par défault le fichier de configuration
ne contient pas la valeur "NetworkKey" et c'est la valeur par défaut du code de
/opt/python-openzwave/openzwave/cpp/src/Driver.cpp
qui est utilisée.

Bug 1 ?
----------
Si l'on spécifie la valeur "NetworkKey" dans /opt/python-openzwave/openzwave/cpp/src/Driver.cpp,
la valeur spécifiée est concaténée (append) à la valeur existante au lieu de remplacer la valeur
par défaut. Cela débouche sur une erreur:
2016-11-19 13:00:06.428 Warning, Invalid Network Key. Does not contain 16 Bytes - Contains
....
2016-11-19 13:00:06.428 Error, Exception: Driver.cpp:6733 - 103 - Failed to Read Network Key

Solution: seuls les N premiers bytes de la valeur du fichier de configuration devrait être lus et remplacer
la valeur par défaut.

Suggestion: il serait agréable de pouvoir configurer cette clé dans l'interface utilisateur.

Bug 2 ?
----------
Il existe une clé de chiffrement par défaut. Il s'agit de la concaténation des valeurs 1 à F sur 16 bytes (128 bits).
Admettons que le Bug 1 ci-dessus n'en soit pas un.
Comment expliquer que la communication avec un device possédant la capacité de communication sécurisée
n'ait pas lieu malgré une inclusion en mode sécurisé ? (cadenas ouvert dans le bilan de santé Z-Wave).

Cela revient à poser la question de savoir quel composant effectue le chiffrement des communications:
- le plugin Z-Wave
- la clé USB contrôleur Z-Wave d'Aeon Labs
et dans quelles conditions (configuré / inclusion sécurisée, reconnu, supporté, ...)

Doutes:
-----------
Je ne suis pas sûr de bien comprendre tout ce qui se passe dans les coulisses du plugin Z-Wave. En particulier
les capacités des périphériques. Ma compréhension du protocole Z-Wave+ me laisse penser que de tels
périphériques devraient être capables de traiter des communications sécurisées.

En lisant les spécifications du protocole Z-Wave+
http://z-wave.sigmadesigns.com/wp-conte ... cation.pdf
On comprend qu'il existe plusieurs classes d'appareils (p.ex. des portails, des claviers de codes, des interrupteurs, ...) et chaque
classe de périphériques a des exigences minimales pour prétendre au label "Z-Wave+".
Les portails (chapitre 4.2) et les claviers (chapitre 4.6) exigent la capcité de sécurité alors que les interrupteurs (chapitre 4.12)
ne l'exigent pas.

Donc je ne sais pas s'il est "normal" (ou pas) qu'un interrupteur communique en non-sécurisé bien qu'il soit estampillé
"Z-Wave+".

Un autre doute est lié au fait que lorse que l'on observe les détails des registres internes à l'interrupteur
(Plugin Z-Wave, équipement interrupteur, Configuration, paramètres) l'on ne voit pas d'indication sécurisé ou pas.
Une telle indication est probablement nécessaire pour gérer l'interropérabilité avec des autres périphériques.

Conclusion:
-----------------
Je ne suis pas certain que les phénomènes observés soient des bugs ou si ce n'est le fait qu'il n'est
pas exigé d'avoir des communication chiffrées pour toutes les classes de devices Z-Wave+.

J'aprécierais tout commentaire éclairé à ce sujet ainsi que des correctifs si cela s'avérait être des bugs.
Meilleures salutations
Fil.

[fwehrle]

Sujet interessant. Je vais suivre le fil.

[loupdefil]

Bonjour à toutes et à tous,

Je pense avoir trouvé une partie des réponses à mes questions dans une note datée du 28 avril 2015 sur le blog d'un développeur sur Github:
https://github.com/OpenZWave/open-zwave ... ces-to-OZW
Cette note contient en substance les éléments suivants:

1) Une classe de commandes sécurisée a été définie "COMMAND_CLASS_SECURITY"
2) Les commandes sécurisées doivent utiliser pour communiquer la clé symétrique partagée que l'on
peut définir au moyen de la variable "NetworkKey" (voir plus haut). Il s'agit d'un clé AES 128 bit (16 byte).
3) La procédure d'inclusion sécurisée contient des étapes supplémentaires pour l'échange de cette clé.
De plus la procédure ne peut avoir lieu que directement entre le contrôleur et le périphérique apairé.
Le développeur suggère que cette apairement se fasse au niveau applicatif du côté du contrôleur et par
un reset complet du périphérique.
Il s'agit d'une limitation de Z-Wave+. Cela s'avérera lourd pour la maintenance d'interrupteurs au grenier par exemple
4) L'utilisation de commandes sécurisées nécessite un réseau Jeedom en "bonne santé", c'est à dire avec peu
de répétitions des commandes.

Ce qui me paraît plus ennuyeux (voir les références ci-dessus):
- En l'état seuls les périphériques "serrures" et "claviers pour introduire le code d'accès" ont été spécifiés avec le mode
sécurisé. Le développeur demande un retour d'expérience si d'autres personnes implantent de nouvelles variantes.
Je cite la FAQ (Foire aux questions) de l'article du blog ci-dessus:

% Q: Not all the features of my device are available:
% A: That is quite possible. The initial work just focused on enabling
% the Security Command Class. Now that that class has been implemented,
% there is a whole range of additional command classes that we need
% to investigate and implement. Our focus initially will be
% the "Door Lock" and "Door Lock Logging" classes as door locks
% seem to be the most requested feature for OZW, and after that,
% we will investigate other command classes.
% If you have a device other than a Door Lock, and it supports
% the Security Command Class and some other classes that we don't
% implement - We would love to hear from you! Also, we should point
% out, that Applications that use OZW may have to update to support
% the Door Locks etc. This entirely depends upon how the application
% was created/coded etc. Best to ask the people developing your
% application if it will work now, or if they need to implement
% something.

- La limitation actuelle de l'implantation du plugin Z-Wave qui consiste à définir de manière statique
la clé de chiffrement dans le code me paraît être bénigne en comparaison du fait que le protocole
de dialogue avec les périphériques devraient être revus (au moins en ce qui concerne l'échange de
la clé de chiffrement). Certains arguments du développeur ne sont pas clairs pour moi
en ce qui concerne les commandes sécurisées elles-mêmes. D'un coté il dit que que du moment
que la communication est sécurisée il n'y a rien à modifier aux commandes, de l'autre il espère
un retour de commentaires au cas où des modifications de protocole seraient nécessaires.

Voilà, si d'autres personnes ont des informations plus actuelles ou des expériences pratiques
concernant ces aspects de communication sécurisés avec Z-Wave+, je serai heureux de les
entendre.

Meilleures salutations.
Cheers Fil.

[nechry]

Zwave+ est pour identifier la puce donc pas obligatoirement le mode secure. Pour la key elle est setté dans le plugin lui même donc ton bug1 en est pas un.

Certains modules ne fonctionnent qu'en mode secure, d'autre pas du tout ou mal. Donc faut faire lorsque requis ou au minimum supporter par le module. Mais cette information est pas toujours façile à trouver.


Sent from my iPad using Tapatalk

[loupdefil]

Bonjour nechry,

Je ne serai pas aussi optimiste que vous en ce qui concerne le "bug 1 ?" et la situation des commandes non sécurisées.

Un clé de chiffrement connue n'est plus une clé de chiffrement
- Actuellement sa valeur par défaut est 01 02 03 04 05 06 07 08 08 10 0A 0B 0C 0D 0E 0F
- De plus on ne peut pas la changer au moyen du fichier options.xml, cela génère une erreur.
Pouvez-vous documenter la procédure (hack/workaround) pour changer cette clé ?

En ce qui concerne les commandes Z-Wave+ non sécurisées, cela me paraît plus grave, en tout
cas plus difficile à améliorer.
Le fait que le contenu (payload) des paquets Z-Wave transmis ne soient pas chiffrés me pose
quelques questions de sécurité pour une infrastructure qui peut commander des appareils
potentiellement dangereux (chauffage, arosage, ...) Les expériences de hackers avec un drône
allumant des lampes de bureau Zigbee depuis l'extérieur d'un bâtiment me sont plutôt
sympatiques: http://www.theverge.com/2016/11/3/13507 ... drone-hack
Un feu ou une innondation le sont beaucoup moins
Le développeur du mode sécurisé a bien compris qu'une serrure ou que le code d'accès tapé sur un clavier
ne doivent pas être lisibles. J'irai un pas plus loin. On utilise une serrure pour interdire l'accès à un bâtiment
(et à son contenu). Les ondes radio permettent d'activer des périphériques sans avoir à pénétrer dans le
bâtiment. Je ne suis pas sûr que les personnes qui désirent protéger légitimement leur porte d'entrée
soient prêtes à monter un interrupteur allumant leur chauffage depuis leur jardin, elles admettent implicitement
que cet interrupteur soit protégé au même titre que le reste des biens situés dans leur maison.

Je reprends donc votre argument: il est difficile de trouver des informations précises sur la
capacité des commandes sécurisées. En d'autres termes ce n'est pas réalisé systématiquement
(et cela ne fait pas partie des exigences des spécifications Z-Wave+).

Peut-être avez-vous des références sur des traces (dumps) ou la manière de tracer de paquets Z-Wave+.
Je crois savoir que certaines réalisations utilisent les port sériels (logiques) pour accéder au contrôleur
Z-Wave.

J'espère ne pas vous apparaître comme trop rabat-joie.

Meilleures salutations,
Loudefil

[nechry]

Comme j'ai dis la clé est contenue dans le code du plugin, je n'ai toute fois rien affirmé en disant qu'elle est bien ou non. Sans se voiler la face elle est pas bonne comme elle est connue. On a pas dans le moment un moyen simple pour vous de la modifier, mais ça sera la cas dans une future version du plugin.


Sent from my iPad using Tapatalk

[loupdefil]

Merci

[nechry]

pour info, les future produit zwave devront implémenter la nouvelle CC de sécurité S2 pour recevoir la certification de la zwave alliance dès avril 2017.
http://www.abavala.com/securite-renforc ... ls-z-wave/

on va vers un mieux, c'est claire, mais on est pas encore rendu. on a beaucoup augmenté les aspect sécurité dans l'ensemble jeedom et dans les action sur les plugins.

tu peux sans problème modifier la clé contenue dans le fichier /var/www/html/plugins/openzwave/resources/openzwaved/openzwaved.py
c'est la ligne

Code : Tout sélectionner

options.addOptionString("NetworkKey", "0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10", True)

par contre si tu as déjà effectué des inclusion sécure avec des module la key ne sera plus valide, il faudra exclure et inclure a nouveau ces modules.

il n'y aura pas de nouvelle version du plugin avant 2017 je pense donc ton fichier avec ta clé privé ne sera pas écrasé dans les prochains jours. Et et déjà dis une prochaine version permettra de spécifier vous même la clé au lancement du demon, donc tu pourras normalement injecté ta clé. Il faudra bien entendue conserver cette clé en sureté, mais tu semble bien au claire avec ces pratiques

[loupdefil]

Bonsoir Nechry,

Merci pour le hack de mise à jour de la clé de chiffrement du plugin ZWave.
Merci également pour l'annonce de la perspective de l'arrivée d'un mode de communication Z-Wave plus sécurisé.
http://z-wave.sigmadesigns.com/wp-conte ... on-0_9.pdf

Cette version préliminaire de la spécification suggère qu'il devrait être possible de faire des mises à jour des firmware
des périphériques existants (chapitre 3.1.1.3). Je le souhaite sincèrement. Le chapitre 3.1.6.3 et la table 8 du chapitre 3.1.6
soulignent la nécessité de générer la clé publique du périphérique dont on fait la mise à jour du firmware. Je suis curieux
de voir comment les fabricants résoudront cette difficulté.

Tout cela va dans la bonne direction. Je suis impatient de voir la spécification en version finale et les firmware associés
Je peux imaginer que les fabricants généreront des firmwares "personalisés" avec une clé unique pour chaque périphérique
et le moyen de générer une étiquette QR code.

A bientôt
Loupdefil

[loupdefil]

Bonjour à tous,

Mes préoccupations semblent être partagées par les membres de la Z-Wavealliance qui ont décidé le 17-Nov-2016 de
rendre obligatoire l'adoption du framework de sécurités dit "S2" mentionné ci-dessus dès le 17-Avr-2017.
http://z-wavealliance.org/z-wave-allian ... t-devices/

Je suis curieux de voir dans quelle mesure et dans quels délais les périphériques existants seront mis à jour par leurs
constructeurs respectifs

Salutations
Loupdefil

[nechry]

c'est surtout pratiquement impossible de mettre ajour les devices existant.

Il y a avec aeotec ou c'est vraiment simple, si on possède un dongle USB. Nouvellement Fibaro mais a condition d'avoir une Home Center 2. les autre on a pas vraiment de moyen.

[Mguyard]

Comme j'ai dis la clé est contenue dans le code du plugin, je n'ai toute fois rien affirmé en disant qu'elle est bien ou non. Sans se voiler la face elle est pas bonne comme elle est connue. On a pas dans le moment un moyen simple pour vous de la modifier, mais ça sera la cas dans une future version du plugin.

Désolé de déterré le sujet. Est-ce qu'une version permettant le set de la clé est déjà disponible ?
Je ne trouve rien, ni sur le forum, ni la doc du plugin zwave.
Merci d'avance

[nechry]

ici : https://nechry-automation.ch/2018/01/22 ... ite-zwave/

[Mguyard]

ici : https://nechry-automation.ch/2018/01/22 ... ite-zwave/

Merci. Oui je l’ai lu ça. Mais tu semblais indiqué que ça allais être intégré à l’avenir.
Car avec cette méthode c’est perdu à chaque changement. Alors que intègré ça pourrait prendre en compte la clé

Donc je présume que c’est pas encore intégré