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

[A.Harrenberg]

Hi Rudi,

wenn Du die bisherige GET-Implementierung mit dem ReadAnswerFn rauswirst ohne eine ähnliche Funktion einzubauen, werden die Befehle einfach hintereinander rausgeschickt, ohne das auf evtl. Antworten Rücksicht genommen wird.

Meinem Verständnis nach wird ein Gerät aber eine neue Nachricht abweisen solange das Gerät noch eine Antwort bearbeitet und diese vom Gerät nicht verschickt wurde.

Also Abfrage eines Configwertes (GET-Befehl) und verschicken eines weiteren Befehls bevor die Antwort auf diese Abfrage verschickt wurde muss nach ZWave-Protokoll dazu führen das der zweite Befehl nicht aktzeptiert wird. Hier bin ich bisher davon ausgegangen das dies durch eine CAN-Msg geschieht.

Und ich rede hier nicht von einem Verschicken bevor der Empfang quitiert wurde.
Ich bin daher weiterhin der Meinung das bei GET-Befehlen auch eine Ablaufsteuerung nötig ist um hier kein laufende Kommunikation zu stören.

Vielleicht bekomme ich so einen Fall ja mal provoziert indem ich den ganzen ReadAnswerFn Teil mal deaktiviere und entsprechende Nachrichten erzeuge.

Gruß,
Andreas.

[A.Harrenberg]

Hi,

hier mal ein Test bei dem der gesamte Code in der Behandlung für "get" auskommentiert ist:

Code Auswählen Erweitern

  if($type eq "get") {
    # no strict "refs";
    # my $iohash = $hash->{IODev};
    # my $fn = $modules{$iohash->{TYPE}}{ReadAnswerFn};
    # my $re = $cmdList{$cmd}{regexp};
    # my ($err, $data) = &{$fn}($iohash, $cmd, $re ? $re : "^000400${id}..$cmdId")
    #                     if($fn);
    # use strict "refs";
    #
    # return $err if($err);
    # $data = "$cmd $id $data" if($re);
    #
    # $val = ($data ? ZWave_Parse($iohash, $data, $type) : "no data returned");

  } else {


Ich habe dann mal bei dem Steckdosenschalter ohne Security mehrmals (4x) auf get powerlevel geklickt:

Code Auswählen Erweitern

2015.10.13 21:48:42.283 2: ZWave get ZWave_SWITCH_BINARY_158 powerlevel
2015.10.13 21:48:42.283 5: ZWDongle_Write 00 139e027302259e
2015.10.13 21:48:42.283 5: SW: 010900139e027302259eb3
2015.10.13 21:48:42.467 2: ZWave get ZWave_SWITCH_BINARY_158 powerlevel
2015.10.13 21:48:42.643 2: ZWave get ZWave_SWITCH_BINARY_158 powerlevel
2015.10.13 21:48:42.834 2: ZWave get ZWave_SWITCH_BINARY_158 powerlevel
2015.10.13 21:48:43.283 5: ACK received, removing 010900139e027302259eb3 from dongle sendstack
2015.10.13 21:48:43.303 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.10.13 21:48:43.303 5: SW: 06
2015.10.13 21:48:43.304 5: ZWDongle_0 dispatch 011301
2015.10.13 21:48:43.324 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00139e000002
2015.10.13 21:48:43.324 5: SW: 06
2015.10.13 21:48:43.326 5: ZWDongle_0 dispatch 00139e000002
2015.10.13 21:48:43.326 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.10.13 21:48:43.326 4: ZWDongle_0 transmit OK for 9e
2015.10.13 21:48:43.326 5: ZWDongle_Write 00 139e027302259e
2015.10.13 21:48:43.326 5: SW: 010900139e027302259eb3

Hier wird der zweite Befehl gesendet BEVOR die Antwort auf das erste Get da ist. Aber "sauber" nach dem transmit OK... Also z.B. nicht zwischen Senden und ACK.

Code Auswählen Erweitern


2015.10.13 21:48:43.357 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004009e0473030000
2015.10.13 21:48:43.357 5: SW: 06
2015.10.13 21:48:43.359 5: ZWDongle_0 dispatch 0004009e0473030000
2015.10.13 21:48:43.359 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:9e ARG:0473030000
2015.10.13 21:48:43.360 4: ZWDongle_Read ZWDongle_0: CAN received
2015.10.13 21:48:44.360 2: ZWDongle_ProcessSendStack: no ACK, resending message 010900139e027302259eb3
2015.10.13 21:48:44.360 5: SW: 010900139e027302259eb3
In der Folge kommt dann erst die Antwort, dann wird aber ein CAN für den zu früh gesendeten Get-Befehl empfangen und er muss neu gesendet werden. Ich denke das stützt meine Theorie das man nicht zwischen Frage und Antwort senden sollte und das die CAN-Msg eher vom Gerät kommen als vom Dongle.

Das System "fängt" sich mit den Re-sends zwar wieder, d.h. auf die 4 Get gibt es letztendlich auch 4 Antworten, bei mehr Störungen wird das aber anders aussehen Datenverlust ist recht wahrscheinlich.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

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

wie stehst Du denn jetzt zu meiner Theorie mit der CAN-Msg und dem Senden zwischen SET-Befehl und REPORT-Antwort? Ich gebe ja zu das die meisten Antworten so schnell kommen das die Wahrscheinlichkeit da noch eine weitere Nachricht zu erzeugen nicht so groß ist.

Ich würde ja am liebsten den gesamten Ablauf auf steuerbare Stacks umstellen (und nicht nur die SECURITY), allerdings fehlt mir da etwas der Einstieg wie ich auf eine Antwort warten kann ohne FHEM zu blockieren und im Fall von anderen Störungen im Ablauf z.B. eintreffen eine Nachricht vom Sensor während auf eine Antwort gewartet wird, nicht aus dem ganzen Ablauf rauszufliegen...

Dazu würde mir nur gerade nur was mit InternalTimer einfallen, und bei den Timern habe ich noch nicht wirklich begriffen wie das da mit mehreren gleichzeitigen Timern aussehen würde, bzw. ob das überhaupt zu kontrollieren ist...

Ich habe aber auch gerade Deinen Thread zu FHEM 5.7 gesehen und denke das Du da recht beschäftigt bist. Und das ist sicherlich nichts was man da noch schnell reinbauen sollte...
Es wäre aber hilfreich für mich, wenn Du noch mal kurz Deine Meinung bzw. Deine Pläne beschreiben könntest, damit ich mir in die Richtung auch schon mal weitere Gedanken machen kann.

Gruß,
Andreas.

[rudolfkoenig]

wie stehst Du denn jetzt zu meiner Theorie mit der CAN-Msg und dem Senden zwischen SET-Befehl und REPORT-Antwort?

Ich glaube nicht daran Wenn es stimmen wuerde, dann waeren CallbackIds ueberfluessig.

5.7 sollte nicht so viel Aufwand erzeugen, es ist eher ein Aufruf an die Anderen, nicht jetzt mit grundlegenden Umbaus anzufangen. Ich wuerde aber meinen Sec-Umbau Vorschlag nicht als grundlegend betrachten, da es nur sec betrifft, was bisher auch nicht 100% tut. Apropos: koenntest du mir sagen, was mit sec z.Zt. tut, und was nicht?

[A.Harrenberg]

Hi Rudi,

Ich glaube nicht daran Wenn es stimmen wuerde, dann waeren CallbackIds ueberfluessig.

hmm, das Argument kann ich auf Anhieb nicht entkräften...
Aber wie erklärst Du Dir die CAN-Msg wenn man dazwischen sendet? Wir bräuchten mal einen "Sniffer"...

5.7 sollte nicht so viel Aufwand erzeugen, es ist eher ein Aufruf an die Anderen, nicht jetzt mit grundlegenden Umbaus anzufangen. Ich wuerde aber meinen Sec-Umbau Vorschlag nicht als grundlegend betrachten, da es nur sec betrifft, was bisher auch nicht 100% tut. Apropos: koenntest du mir sagen, was mit sec z.Zt. tut, und was nicht?

Also eigentlich gibt es mMn nur die Probleme mit der fehlenden Ablaufsteuerung, d.h. wenn neue Befehle dazwischenkommen. Das endet eigentlich immer mit CAN-Msg, wobei dann auch recht schnell Datenverlust auftritt.

Funktional ist in SECURITY nur noch offen das überlange Nachrichten nicht in zwei Teile gespilittet gesendet werden. Das ist aber in OpenZWave auch nicht implementiert und bisher hat es da wohl auch keinen Bedarf für gegegeben. Das würde ich mir mal vornehmen sobald es da ein Anwendungsfall gibt. Der Empfang von solchen zweigeteilten Nachrichten ist implementiert und funktioniert einwandfrei.

Status also: Funktioniert, sollte aber vorläufig nur eingesetzt werden wenn man weiß auf was man sich dabei einlässt.

Wenn Du die Änderungen mit dem sec-Stack als nicht so grundlegend betrachtest würde ich sagen das wir mit so einem System mal in's Rennen gehen. Du könntest mir ja einen Patch zur Verfügung stellen mit dem ich dann die weiteren Anpassungen machen kann bevor das dann gesamt implementiert wird. Mir würde es wahrscheinlich auch reichen wenn Du die grundlegende Struktur für den secStack so implementierst wie Du Dir das gedacht hast, den Rest drumherum bekomme ich dann schon hin.

Gruß,
Andreas.

[rudolfkoenig]

Ich habe meinen Vorschlag implementiert.
- Dabei verwendet man ZWave_secStart($hash) vor dem ersten SECURITY relevanten Befehl, und ZWave_secEnd($hash), wenn man keine Daten mehr erwartet.
- ich habe im Security Abschnitt alle ZWave_Get/ZWave_Set Befehle auf ZWave_CMD umgestellt
- ich habe auch schon ZWave_secStart/ZWave_secEnd Aufrufe eingebaut, bin aber unsicher, ob die richtig sind.
- es fehlt sicher noch ein ZWave_secEnd, wenn irgendetwas schiefgeht, z.Bsp. wenn die andere Seite nicht antwortet.
- ich kann es leider nicht richtig testen, immerhin werden die verschluesselten Meldungen meines KFOBs weiterhin entschluesselt, und ich kann bei "normalen" Geraeten auch nichts schlimmes feststellen.

Weiterhin habe ich manche Security Relevante Funktionen umbenannt, so dass alles mit ZWave_sec beginnt.

[A.Harrenberg]

Hallo Rudi,

Ich habe meinen Vorschlag implementiert.

vielen Dank schon mal, damit erübrigt sich meine Bitte in dem anderen Thread das noch mal zu erklären... ,-)

- Dabei verwendet man ZWave_secStart($hash) vor dem ersten SECURITY relevanten Befehl, und ZWave_secEnd($hash), wenn man keine Daten mehr erwartet.
- ich habe im Security Abschnitt alle ZWave_Get/ZWave_Set Befehle auf ZWave_CMD umgestellt
- ich habe auch schon ZWave_secStart/ZWave_secEnd Aufrufe eingebaut, bin aber unsicher, ob die richtig sind.
- es fehlt sicher noch ein ZWave_secEnd, wenn irgendetwas schiefgeht, z.Bsp. wenn die andere Seite nicht antwortet.
- ich kann es leider nicht richtig testen, immerhin werden die verschluesselten Meldungen meines KFOBs weiterhin entschluesselt, und ich kann bei "normalen" Geraeten auch nichts schlimmes feststellen.

Ok, ich werde mir das dann mal ansehen, allerdings geht das bei mir leider erst ab Ende nächster Woche wieder intensiver. Hört sich aber doch schon sehr vielversprechend an.

Falls zwischendurch noch jemand testen könnte (und auch berichtet) wäre das natürlich hilfreich!

Danke,
Andreas.

[krikan]

Wenn Ihr mir vorgebt, was/womit ich testen soll, dann mache ich das....

[A.Harrenberg]

Hi Krikan,

da ich noch nicht genau überblicke was Rudi da im einzelnen gemacht hat wären "normale" Funktionstests denke ich ausreichend. Solange alles funktioniert wie vorher ist ja erst mal alles in Ordnung.
So lange keine Auffälligkeiten auftreten hätte ich keine expliziten Anforderungen. WakeUp-Geräte wären natürlich interessant...

Ich habe jetzt nur mal ganz kurz über den Code geschaut und wollte gerade auch mal anfangen ein wenig mit auszuprobieren.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,
meine ersten Tests sehen leider schlecht aus... Sobald ich Befehle an ein security Gerät schicke wird secStack akitv und alle Befehle werden auf den Stack gelegt aber nicht mehr weiter bearbeitet.

Code Auswählen Erweitern

2015.10.25 21:28:28.974 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configBatteryReportingThreshold
2015.10.25 21:28:28.974 1: configBatteryReportingThreshold: Secure operation in progress, executing in background
2015.10.25 21:28:28.974 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configCommandOptions
2015.10.25 21:28:28.974 1: configCommandOptions: Secure operation in progress, executing in background
2015.10.25 21:28:28.975 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configEnableDisableLockConfiguration
2015.10.25 21:28:28.975 1: configEnableDisableLockConfiguration: Secure operation in progress, executing in background
2015.10.25 21:28:28.975 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configEnableMotionSensor
2015.10.25 21:28:28.975 1: configEnableMotionSensor: Secure operation in progress, executing in background
2015.10.25 21:28:28.975 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configGroup1Interval
2015.10.25 21:28:28.975 1: configGroup1Interval: Secure operation in progress, executing in background
2015.10.25 21:28:28.975 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configGroup1Reports
2015.10.25 21:28:28.976 1: configGroup1Reports: Secure operation in progress, executing in background
2015.10.25 21:28:28.976 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configGroup2Interval
2015.10.25 21:28:28.976 1: configGroup2Interval: Secure operation in progress, executing in background
2015.10.25 21:28:28.976 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configGroup2Reports
2015.10.25 21:28:28.976 1: configGroup2Reports: Secure operation in progress, executing in background
2015.10.25 21:28:28.976 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configGroup3Interval
2015.10.25 21:28:28.976 1: configGroup3Interval: Secure operation in progress, executing in background
2015.10.25 21:28:28.977 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configGroup3Reports
2015.10.25 21:28:28.977 1: configGroup3Reports: Secure operation in progress, executing in background
2015.10.25 21:28:28.977 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configHumidityCalibration
2015.10.25 21:28:28.977 1: configHumidityCalibration: Secure operation in progress, executing in background
2015.10.25 21:28:28.978 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configHumidityReportingThreshold
2015.10.25 21:28:28.978 1: configHumidityReportingThreshold: Secure operation in progress, executing in background
2015.10.25 21:28:28.978 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configLowBattery
2015.10.25 21:28:28.979 1: configLowBattery: Secure operation in progress, executing in background
2015.10.25 21:28:28.979 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configLowTempAlarm
2015.10.25 21:28:28.979 1: configLowTempAlarm: Secure operation in progress, executing in background
2015.10.25 21:28:28.980 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configLuminanceCalibration
2015.10.25 21:28:28.980 1: configLuminanceCalibration: Secure operation in progress, executing in background
2015.10.25 21:28:28.980 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configLuminanceReportingThreshold
2015.10.25 21:28:28.981 1: configLuminanceReportingThreshold: Secure operation in progress, executing in background
2015.10.25 21:28:28.981 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configOnTime
2015.10.25 21:28:28.981 1: configOnTime: Secure operation in progress, executing in background
2015.10.25 21:28:28.981 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configReportingThreshold
2015.10.25 21:28:28.981 1: configReportingThreshold: Secure operation in progress, executing in background
2015.10.25 21:28:28.981 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configTemperatureCalibration
2015.10.25 21:28:28.982 1: configTemperatureCalibration: Secure operation in progress, executing in background
2015.10.25 21:28:28.982 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configTemperatureReportingThreshold
2015.10.25 21:28:28.982 1: configTemperatureReportingThreshold: Secure operation in progress, executing in background
2015.10.25 21:28:28.982 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configUVReportingThreshold
2015.10.25 21:28:28.982 1: configUVReportingThreshold: Secure operation in progress, executing in background
2015.10.25 21:28:28.982 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configUltravioletCalibration
2015.10.25 21:28:28.982 1: configUltravioletCalibration: Secure operation in progress, executing in background
2015.10.25 21:28:28.982 2: ZWave set ZWave_SENSOR_MULTILEVEL_168 configWakeUp10MinutesOnPowerOn
2015.10.25 21:28:28.982 1: configWakeUp10MinutesOnPowerOn: Secure operation in progress, executing in background

Danach passiert dann gar nichts mehr. Ein Set-Befehl endet ebenso im Nirvana.

Ich habe aber jetzt leider nur SEHR wenig Zeit da zu debuggen. Vielleicht ist es sinnvoller das Update morgen nicht zu verteilen...

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

Du hattest ein ZWave_Get übersehen...
Patch ist angehängt. Damit läuft die Kommunikation erst mal, allerdings endet ein ConfigRequestAll natürlich immer noch in jeder Menge CAN-Msg und Time-Out.
Da muss ich dann auf jeden Fall noch weiter nachschauen. Mehr kann ich jetzt aber nicht mehr machen.

Gruß,
Andreas

[rudolfkoenig]

Den Patch habe ich eingespielt.

Dass du beim configRequestAll CAN bekommst bedeutet, dass man man keine Befehle an dem Endgeraet schicken darf, wenn das Endgeraet selbst Daten schicken will.

Das Problem bei configRequestAll koennte man mit einer Ausnahme umgehen (kein secEnd bei config... request, habs eingecheckt, bitte testen), generell sehe ich aber ein Problem, und keine Loesung. Ideen?

[krikan]

... man man keine Befehle an dem Endgeraet schicken darf, wenn das Endgeraet selbst Daten schicken will.
... generell sehe ich aber ein Problem, und keine Loesung. Ideen?

Verstehe ich das richtig:
Dann muss bei allen Befehlen (unabhängig von SECURITY) , die von Fhem an ein Endgeraet geschickt werden, auf die Antwort gewartet werden, bevor ein neuer Befehl verschickt wird. Nur dann kann man doch diese CANs verhindern.
Und dann (neuer Versuch  ): Fortlaufende Callback-Ids zur Befehl-Antwort-Zuordnung.

[A.Harrenberg]

Hi Rudi,

Den Patch habe ich eingespielt.

Danke!

Dass du beim configRequestAll CAN bekommst bedeutet, dass man man keine Befehle an dem Endgeraet schicken darf, wenn das Endgeraet selbst Daten schicken will.

Ich sag' ja das man zwischen einem GET und dem daraus resultieren REPORT vom Gerät nichts senden darf da sonst CAN Msg erzeugt werden die dann ab einer gewissen Menge an erzeugtem Chaos durch die Timeouts zu Datenverlust führen.

Das Problem bei configRequestAll koennte man mit einer Ausnahme umgehen (kein secEnd bei config... request, habs eingecheckt, bitte testen), generell sehe ich aber ein Problem, und keine Loesung. Ideen?

Noch keine zu Ende gedachte Idee, aber für die Security Sachen werde ich mir einen Status anlegen müssen ob die akutelle Kommunikation noch läuft. Abhängig davon muss dann das secEnd gesteuert werden. Dabei muss ich auch mal überlegen was passiert wenn das Gerät einen GET-NONCE schickt und damit die Kommunikation startet.

Über secStart / secEnd kann jetzt ja kontrolliert werden das keine weiteren "non-security" Befehle mehr abgearbeitet werden, laufenden Security Kommunikationen können sich aber weiterhin untereinander stören wenn das secEnd "zu früh" kommt.

Ich habe diese Woche jetzt jeden Tag ganztägig Kundenbesuch und kann daher nicht viel machen. Ich werde mich aber am WE mal etwas näher mit dem Ablauf befassen und mal versuchen alle Möglichen Varianten einer Kommunikation (nur SET, Get mit "einteiliger" Antwort, Get mit "zweiteiliger" Antwort, eingehende Nachrichten vom Gerät, Time-out,...) mal aufzumalen und zu schauen ob bzw. an welchen Stellen sich da eine Steuerung realisieren lässt.

Problematisch sehe ich da gerade den Fall das eine ankommende verschlüsselte Nachricht auf jeden Fall abgearbeitet wird, selbst wenn secStart aktiv ist. Das wäre übrigens auch eine Stelle wo eine ID hilfreich wäre ,-)

Falls wärend einer security-Kommunikation das Gerät etwas verschicken möchte, schickt es erst mal einen GET-NONCE. Das passiert während einer laufenden Kommunikation natürlich auch mehrmals, hier wäre die ID Möglichkeit zu erkennen das es sich hier um eine NEUE Kommunikation handelt. Ob das kriegsentscheidend ist kann ich momentan nicht sagen, die NONCE wird ja in jedem Fall verschickt, es kommt dann nur nicht die erwartete Antwort sondern eine andere Nachricht vom Gerät.

Gruß,
Andreas.

[rudolfkoenig]

@Christian: Neuer Versuch abgelehnt Wenn ich weiss, dass Geraet X nur ein ausstehendes Befehl haben darf, dann brauche ich gar kein CallbackId, da ich das Geraete-Id zusaetzlich kriege.

@Andreas: keine Hektik. Deine CANs sind in meinen Augen noch kein Beweis, evtl. haengt das auch mit deinem USB-Stick zusammen.

Problematisch sehe ich da gerade den Fall das eine ankommende verschlüsselte Nachricht auf jeden Fall abgearbeitet wird, selbst wenn secStart aktiv ist. Das wäre übrigens auch eine Stelle wo eine ID hilfreich wäre ,-)

Ich glaube das musst du mir ganz detailliert aufmalen. Nach meinem Verstaendnis kollidiert das naemlich mit deiner CAN Theorie: zwei Nachrichten in parallel kann (dein? / der) Kontroller nicht ab, ID hin oder her.

Kann mir jemand einen Aktor empfehlen, was SECURITY kann? Muss nicht superteuer sein.