Implementierung der ZWAVE Command Class SECURITY (0x98, AES Verschlüsselung)

[A.Harrenberg]

Hallo Rudi,

Nicht unbedingt, siehe https://de.wikipedia.org/wiki/Public-Key-Verschl%C3%BCsselungsverfahren

stimmt, allerdings benötigt man dann, zumindest bei der Inklusion, für jeden Empfänger einen eigenen Schlüssel.

Ein solches System könnte eine Möglichkeit für eine zukünftige "Scheme 01" Implementierung sein.
Gerät sendet seinen öffentlichen Schlüssel, Controller/FHEM verschlüsselt den Netzwerkschlüssel damit und sendet an das Gerät. Das Gerät kann den Schlüssel mit seinem (internen) geheimen Schlüssel entschlüsseln und ab da kann es wie bisher weitergehen und wäre damit sicher solange keine Implemtierungsfehler auftreten.

Ich habe sowieso ein wenig "Angst" davor das Sigma in einem V2 Update für Security solche Sachen einbaut. Dann wird es SEHR aufwändig das wieder zu rekonstruieren.

Gruß,
Andreas.

[krikan]

Hallo Andreas!

Hier http://www.zwave.de/problembehebung-mit-philio-mehrfachsensor/ wird über Probleme mit SECURITY zwischen Z-Way und Philio (=devolo?) berichtet. Es wird mir nur nicht klar, ob es an Z-way oder am Sensor liegt.

Wir sollten mMn dringend auch andere batteriebetriebene Geräte mit SECURITY testen oder ist das schon geschehen?

Gruß, Christian

[A.Harrenberg]

Hi Krikan,

Hier http://www.zwave.de/problembehebung-mit-philio-mehrfachsensor/ wird über Probleme mit SECURITY zwischen Z-Way und Philio (=devolo?) berichtet. Es wird mir nur nicht klar, ob es an Z-way oder am Sensor liegt.

Wir sollten mMn dringend auch andere batteriebetriebene Geräte mit SECURITY testen oder ist das schon geschehen?

ist ja 'ne tolle Lösung... Einfach keine Security verwenden...

Ist das eigentlich der Sensor den Du hast oder ein anderer? Bisher habe ich nur Logs von Dir bzw. von einem baugleichen Sensor bekommen. Und jetzt die Logs von dem 6-fach Sensor, die nutzen aber nichts, da dort die Inclusion ja gar nicht richtig durchgelaufen ist.

Ich überlege ernsthaft mir auch so einen 6-fach Sensor zu kaufen damit ich das hier bei mir lokal testen kann, das ist deutlich einfacher/schneller...

Zuerst muss ich aber mal mein System updaten (ist ja >3 Wochen alt) und dann mal die letzten Änderungen nachvollziehen. Dann kann ich mal probieren ob meine Sirene noch mit Security will. Falls das noch geht muss ich mir mal ansehen was dann bei den WakeUp Geräten schief läuft.

Gruß,
Andreas.

[krikan]

,ist ja 'ne tolle Lösung... Einfach keine Security verwenden...

Ich finde den Tipp klasse 

Ist das eigentlich der Sensor den Du hast oder ein anderer? Bisher habe ich nur Logs von Dir bzw. von einem baugleichen Sensor bekommen. Und jetzt die Logs von dem 6-fach Sensor, die nutzen aber nichts, da dort die Inclusion ja gar nicht richtig durchgelaufen ist.

Kann ich nicht definitiv sagen, da zwave.de keine Modellbezeichnung angibt. In dem Gehäuse gibt es mehrere Varianten. Vermutung aber: Ja

Ich überlege ernsthaft mir auch so einen 6-fach Sensor zu kaufen damit ich das hier bei mir lokal testen kann, das ist deutlich einfacher/schneller...

Wenn Du den gebrauchen kannst; ansonsten teste ich weiter...
Wollte mich bei Gelegenheit auch mal mit meinen anderen SECURITY-Geräten beschäftigen. KFOB-S-Test ist schon zu lange her und den AEOTEC Mulitisensor  habe ich noch gar nicht probiert.

Gruß, Christian

[A.Harrenberg]

Hi Krikan,

Wenn Du den gebrauchen kannst; ansonsten teste ich weiter...

ich meine damit den AEOTEC, ich bin mit meinem Homematic Bewegungsmelder nicht wirklich zufrieden, die Empfindlichkeit von dem Ding ist manchmal sehr schlecht. So ein Philio wollte ich mir nicht zulegen, die Bauform kann ich nicht vernünftig montieren...
Bei den Tests die wir mit Deinem Philio gemacht haben konnte ich aber keine prinzipiellen Probleme mit Security erkennen, vielleicht ist es ja doch eher ein Problem mit Z-way.

Wollte mich bei Gelegenheit auch mal mit meinen anderen SECURITY-Geräten beschäftigen. KFOB-S-Test ist schon zu lange her und den AEOTEC Mulitisensor  habe ich noch gar nicht probiert.

So ein KFOB-S würde mich ja auch interessieren, dafür hätte ich aber keine Verwendung mehr da ich ja den RFID-Leser nutze. Und nur zum "spielen" ist das Ding zu teuer.

Gruß,
Andreas.

[A.Harrenberg]

Hi,

Tests mit der Version 9371 sehen leider immer noch nicht wirklich gut aus mit aktivierter SECURITY. Bei einem "set ... configRequestAll" auf meine (netzbetriebene) Sirene gehen  reproduzierbar zwei Packete aufgrund des "Durcheinanders" beim Senden verloren.

Das ganze habe ich hier im Forum ja schon mal etwas beschrieben.

DIe bisherigen Änderungen an ZWave und dem Sendstack machen den Transport insgesamt zwar deutlich stabiler und Fehlertoleranter falls Störungen/Kollisionen auftreten sollten, helfen aber bei diesem prinzipbedingten Problem leider nicht. Sobald die erste Antwort mit der NONCE ankommt, wird bereits der nächste Befehl vom Sendstack verarbeitet und gesendet, bevor die erste Nachricht mit der Nonce verschlüsselt und gesendet werden könnte. Dadurch kommt dann die ganze Kommunikation durcheinander und letztendlich bleiben dann Befehle "übrig" die gar nicht mehr abgearbeitet werden.

Bei einzelnen Kommandos tritt dieses Problem normalerweise nicht auf, da hier keine weiteren Befehle dazwischenkommen, das Abarbeiten des WakeUp-Stacks verursacht aber die gleichen Probleme.

Ohne einen steuerbaren Sendstack wird sich dieses Problem mMn nicht lösen lassen, allerdings habe ich momentan noch keinen richtigen Ansatz wie ich diese Steuerung realisieren kann.
Ich muss mir die Abläufe jetzt noch mal genauer ansehen und dann schauen ob ich eine Lösung finden kann die auch für den normalen Betrieb ohne Security funktioniert.
Solange bis hier eine Lösung gefunden ist, ist Security leider nur etwas eingeschränkt nutzbar...

Ich bin aber optimistisch das wir eine Lösung finden werden.

Gruß,
Andreas.

[rudolfkoenig]

Ohne einen steuerbaren Sendstack wird sich dieses Problem mMn nicht lösen lassen

Sehe ich auch so. Vorschlag:
- device Variable secInProgress. Falls gesetzt, schieben ZWave_Get und ZWave_Set neue FHEM-Befehle(!) auf einem secStack, ohne ZWave_Cmd aufzurufen. Vermutlich kann man diese Variable nach dem Aufruf von ZWave_isSecureClass setzen.
- in den Security-Routinen muss man  die Funktion ZWave_Cmd direkt verwenden, statt ZWave_Get und ZWave_Set.
- Falls die sec-Befehlskette fertig ist (auch wg. timeout!), muss man ZWave_processSecStack aufrufen, der secInProgress zuruecksetzt, und fuer die Abarbeitung der secStack sorgt, indem sie die gespeicherten Daten an ZWave_Get/ZWave_Set weitergibt.

Falls du damit einverstanden bist, wuerde ich das bauen, du muesstest nur den Aufruf von  ZWave_processSecStack an den richtigen Stellen ergaenzen, da fuehle mich naemlich unsicher.

[A.Harrenberg]

Hallo Rudi,

meine erste Idee sah etwas anders aus, ich hatte eher überlegt eine Art Token OBEN auf den Sendstack zu legen der die weitere Abarbeitung des Stacks verhindert, und neue Nachrichten die zu der laufenden Security-Kommunikation gehören, dann auch OBEN auf den Stack (also über das Token zu setzen). Neue unverschlüsselte Befehle wie sonst auch auch ganz normal unten an den Sendstack zu hängen. Sobald dann die Security-Kommunikation beendet ist sollte das Token wieder oben liegen und könnte entfernt werden.

Deine Idee klingt aber auch gut und ist strukturierter. Gib mir bitte ein paar Tage Zeit das mal gedanklich in einigen Fällen durchzuspielen bevor Du das das so umsetzt. Hier muss ich mir vor allem mal überlegen was mit den Befehlen bei eingeschlafenen WakeUp-Geräten passiert. Aktuell "fange" ich diese Befehle ja ab und lege nur den ersten "get Nonce" Befehl auf den Stack.

Oder hast Du vor den Sendstack insgesamt auf ungeparste FHEM-Befehle umzustellen?

Danke schon mal,
Andreas.

[rudolfkoenig]

Ich habe auch mit sowas wie dein Token angefangen, ist aber komplizierter/verwirrender, als der aktuelle Vorschlag.
Wenn sendStack auch auf FHEM-Befehle umgestellt waere, dann wuerde wir wieder bei einer komplizierter Variante landen.

[A.Harrenberg]

Hallo Rudi,

Ich habe auch mit sowas wie dein Token angefangen, ist aber komplizierter/verwirrender, als der aktuelle Vorschlag.
Wenn sendStack auch auf FHEM-Befehle umgestellt waere, dann wuerde wir wieder bei einer komplizierter Variante landen.

mal ein kleines "was wäre wenn": Device soll mal ein WakeUp-Gerät mit Security sein das "eingeschlafen" ist.

1. unverschlüsselter Befehl wird ausgelöst -> landet geparst im Sendstack
2. verschlüsselter Befehl wird ausgelöst -> Befehl wird geparst, aber "abgefangen" und auf meinen security-Stack gelegt
3. unverschlüsseltes Anfordern der NONCE für den verschlüsselten Befehl aus 2 -> landet geparst im Sendstack

Hierdurch beginnt jetzt eine Security-Kommunikation, die neue Variable "secInProgress" wird gesetzt, neue Befehle werden in ZWave_Set/Get ungeparst auf einen neuen secStack geschoben.

4. Egal welche Befehle (unverschlüsselt oder verschlüsselt) jetzt noch erzeugt werden, diese landen alle auf dem neuen secStack

5. Irgendwann kommt dann mal eine WU-Notification
6. Sendstack wird abgearbeitet -> unverschlüsselter Befehl aus 1 wird gesendet
7. Anforderung der NONCE aus Schritt 3, Befehl wird gesendet
8. NONCE wird vom Gerät empfangen
9. Befehl aus 2 wird mit NONCE verschlüsselt und gesendet

Problem #1: da der Befehl bereits geparst abgefangen und gespeichert wurde, ist jetzt nicht mehr klar ob es ein SET oder ein GET war! D.h. in der momentanen Implementierung ist nicht klar ob eine Antwort erwartet wird oder nicht.

10. Ende der Security-Kommunikation wird (irgendwie) erkannt, "secInProgress" kann wieder gelöscht werden.
11. Aufruf von ZWave_processSecStack um die weiteren im secStack gespeicherten Befehle abzuarbeiten. Diese werden aber erst jetzt geparst und versendet, falls ein verschlüsselter Befehl dabei war wird wieder "secInProgress" gesetzt...

Falls das Gerät eine Security-Nachricht schickt, kommt als erstes die Anfrage für eine NONCE, das wäre dann der Zeitpunkt secInProgress zu setzen, danach wäre es wieder wie oben...

Erste Erkenntnis: Ich werde meinen Stack um den Modus (Set oder Get) erweitern müssen um das Ende der Kommunikation erkennen zu können.
Zweite Erkenntnis: Die Routine zum Versenden einer verschlüsselten Nachricht sollte ich sowohl als Set- als auch als Get-Befehl implementieren
Dritte Erkenntnis: "Hinter" einem verschlüsselten Befehl könnten sich eine Menge Befehle ansammeln die dann erst nach Abarbeiten des verschlüsselten Befehls geparst werden.
Vierte Erkenntnis: Time-Out, CAN, NO_ACK etc. muss ich auch irgendwie zuverlässig erkennen.

Abgesehen von "meinem" Problem #1 sehe ich momentan nichts, was gegen eine solche Lösung sprechen würde.
(Mir wird nur gerade klar das bei GET-Befehlen aus WU-Stack keine ReadAnswerFn aufgerufen wird...)

Entspricht der Ablauf dem was Du Dir bei der Struktur gedacht hast?

Gruß,
Andreas.

[rudolfkoenig]

Problem #1 verstehe ich nicht. Wozu muss man wissen, ob das urspruengliche Kommando ein get oder ein set ist?

Ich vermute, dass get ueber security bisher auch nicht funktioniert hat, und damit meine ich nicht die ZWave_Gets, die fuers Protokoll benoetigt werden (als secNonce, usw).

[A.Harrenberg]

Hi Rudi,

Problem #1 verstehe ich nicht. Wozu muss man wissen, ob das urspruengliche Kommando ein get oder ein set ist?

Ich vermute, dass get ueber security bisher auch nicht funktioniert hat, und damit meine ich nicht die ZWave_Gets, die fuers Protokoll benoetigt werden (als secNonce, usw).

ich muss ja nach Ende der Security-Kommunikation den normalen Ablauf durch löschen von secInProgress wieder freigeben. Dazu muss ich aber doch wissen ob ich nach dem Versenden der verschlüsselten Nachricht eine Antwort von dem Gerät erwarte oder nicht. Falls das ein verschlüsselter SET-Befehl ist kann ich direkt nach dem Transmit-OK secInProgress freigeben, bei einem verschlüsseltem GET-Befehl muss ich die Antwort abwarten (inklusiver der ganzen Nonce-Kommunikation).

Oder wie würdest Du entscheiden das secInProgress gelöscht werden kann, vielleicht übersehe ich ja was ganz offensichtliches...

Gruß,
Andreas.

[rudolfkoenig]

Ok, ich meine das Problem zu verstehen.

Ich behaupte, dass get mit security sowieso nicht funktionieren kann, jedenfalls nicht so wie es z.Zt. implementiert ist und damit meine ich nicht die security-Implementierung, sondern die Schleife in ZWave_Cmd. Habe keine gute Idee, die Beste ist get komplett abzuschaffen.

[A.Harrenberg]

Hallo Rudi,

Ok, ich meine das Problem zu verstehen.

Ich behaupte, dass get mit security sowieso nicht funktionieren kann, jedenfalls nicht so wie es z.Zt. implementiert ist und damit meine ich nicht die security-Implementierung, sondern die Schleife in ZWave_Cmd. Habe keine gute Idee, die Beste ist get komplett abzuschaffen.

die Unterscheidung in GET- und SET-Befehle finde ich aber weiterhin sinnvoll. Damit kann/sollte man unterscheiden ob eine Antwort erwartet wird oder nicht.

Mein Vorschlag wäre daher eher die Struktur mit ReadAnswerFn durch eine Struktur mit "secInProgress" zu ersetzen, wobei man das dann in "communicationInProgress" ändern könnte ,-)

Falls man die Befehle auf dem Stack dann noch durch "get" bzw. "set" erweitert könnte man das ganze durchgehend sogar für Nachrichten auf dem WakeUp Stack unterscheiden.

Man müsste dann beim Versenden eine Funktion triggern die entweder auf Transmit_OK wartet, oder auf Transmit_OK und die nächste Nachricht, je nach set oder get, und diesen Status an eine Kontrollebene zurückmeldet. Im fall von Security müssen ja mehrere Nachrichten versendet werden und nicht nur eine.

Wie im anderen Thread geschrieben sollte das ganze wohl überlegt sein...

Gruß,
Andreas.

[rudolfkoenig]

Netter Plan, ich kapiere es nur nicht welches Problem er loesen soll.