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

[A.Harrenberg]

Hallo Rudi,

ich habe jetzt mal eine Patch-Datei für 10_ZWave.pm erzeugt. Das ganze basiert auf der aktuellen revision 9176.

+ Zeilenbreite ist jetzt 80 Zeichen
+ use Crypt::Rijndael ist durch eine "eval require" Funktion ersetzt
+ Fehlermeldungen und Status-Reading falls Rijndael Modul nicht installiert, Networkkey nicht gesetzt, Gerät Security gar nicht unterstützt (aber dennoch secure inclusion gestartet wurde) oder der Networkkey vom Gerät nicht verifiziert werden konnte
+ Logmeldungen etwas reduziert und an die verbose-Level angepasst
+ Zwischenspeichern des security stacks und der frames bei langen Nachrichten ist von Readings auf Internals umgestellt
+ die langen Zeichenketten in den AES Funktionen habe ich angepasst
+ Dokumentation für Security ist enthalten

++ WakeUpStack Abarbeitung ist ggü. der 9176 allerdings leicht verändert. "Meine" Version verschickt nicht per Schleife sondern per Timer, da dies bei Security ansonsten Probleme macht.
++ zwei GET-Befehle für DOOR_LOCK, allerdings noch ohne Dokumentation... (muss nicht mit rein)

In dem Diff sind jede Menge "nicht geänderter" Zeilen, da im SVN Code die Zeilen teilweise ein Leerzeichen angehängt haben, das entfernt mein Editor anscheinend...

Eine (vor-)letzte Version hat Krikan kurz angetestet und keine Auffälligkeiten bemerkt, danach habe ich "nur" noch die Zeilenlängen auf 80 Zeichen angepasst.
Die zum Patch gehörende Version der 10_ZWave.pm habe ich ebenfalls angehängt (und werde Sie auch noch an Post #1 hängen), falls Du mehr Rückmeldungen benötigst finden sich ja vielleicht noch ein oder zwei andere Tester...

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

Krikan hat gerade noch Merkwürdigkeiten in der Patchdatei gefunden. Anscheinend ist da im Bereich der Dokumentation was schief gelaufen, da werden wohl haufenweise Zeilen "gelöscht" die ich nicht gelöscht habe... Anscheinend kommt da der Diff mit einige Sachen nicht zurecht.

Ich schau da heute abend noch mal rein.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

habe die Datei jetzt noch mal neu abgeglichen und dann einen neuen Diff gemacht. Sieht jetzt besser aus. Irgendwie funktioniert das mit dem SVN bei mir anscheinend nicht immer sauber, da hatte ich ja schon mal Schwierigkeiten... Liegt aber wahrscheinlich daran das ich da mit Windows und Linux gleichzeitig dran arbeite... Sollte mich wohl mal auf Linux beschränken. Danke noch mal an Krikan für das wachsame Auge!

Neue Version vom Patch und der Datei ist angehängt.

Gruß,
Andreas.

[rudolfkoenig]

Hallo Andreas,

dein Patch ist ok, bis auf zwei Ausnahmen:
- ich meine das Senden der Daten aus den WakeUp-Stack per Timer ist auch falsch (genau wie meine Methode, alles zu senden), hier muss man auf die Nachricht vom Controller warten. Das werde ich jetzt umbauen.
- Ich wuerde presumed_State als Internal speichern. Eigentlich kann man das aus lastMsgTimestamp ableiten, allerdings muss man ein gesendetes wakeupNoMoreInformation beruecksichtigen.

Ich uebernehme diesen Patch, werde aber die o.g. Punkte umbauen.
Ich bitte dich Security nach dem Umbau zu testen, und evtl. zu korrigieren.

Gruss,
  Rudi

[krikan]

Hallo Andreas, Hallo Rudi!

Habe 10_ZWave.pm (r9203) aus dem SVN mit PST02-1A getestet. Leider läuft die secure-Inklusion nicht durch. Offensichtlich funktioniert die Ermittlung des Attributs secure_classes nicht. Ich habe es jetzt mehrfach versucht.

2 Versuche habe ich beigefügt (jeweils list und log in der Datei)
Einmal scheitert Einbindung wegen zu vieler CAN, beim 2. Versuch verstehe ich das Problem nicht.
Eine manuelle Abfrage der secure_classes führt auch nicht zum Erfolg.
Wäre schön, wenn ihr Euch das anschauen könntet.

Wenn ihr mehr Infos/Tests braucht, bitte anfordern...

@Rudi: Den Sensor habe ich zu den SECURITY-Tests der 10_ZWave.pm-Versionen aus diesem Thread genutzt und das lief jetzt seit längerem problemlos.

Gruß, Christian

[rudolfkoenig]

Christian, du warst zu schnell.

Die von dir getestete Version war ein Zwischenschritt, bevor ich die Warteschlangen umgebaut habe, damit nicht alles in einem Version untergebracht wird. Ich weiss zwar immer noch nicht, ob security mit der aktuellen Version (9204) tut, sie hat aber eine Chance. Bei der 9203 funktioniert sie sicher nicht, da hier die alte (meine) Warteschlange drin war, und Andreas hat es schon gesagt, dass damit Security nicht funktioniert, deswegen hat er sie modifiziert.

[krikan]

Habe ich schon gemerkt und Test mit r9204 läuft. Erster ist leider wieder nicht durchgelaufen.

Habe im Log mit Stacktrace folgende Ausgabe (Zusammenhang?):

Code Auswählen Erweitern

2015.09.05 22:30:26 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040418028407
2015.09.05 22:30:26 5: SW: 06
2015.09.05 22:30:26 5: ZWDongle_0 dispatch 00040418028407
2015.09.05 22:30:26 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:18 ARG:028407
2015.09.05 22:30:26 5: ZWDongle_Write 00 1318039804002518
2015.09.05 22:30:26 5: SW: 010a0013180398040025185c
2015.09.05 22:30:26 5: ACK received, removing 010a0013180398040025185c from dongle sendstack
2015.09.05 22:30:26 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.05 22:30:26 5: SW: 06
2015.09.05 22:30:26 5: ZWDongle_0 dispatch 011301
2015.09.05 22:30:26 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00131800
2015.09.05 22:30:26 5: SW: 06
2015.09.05 22:30:26 5: ZWDongle_0 dispatch 00131800
2015.09.05 22:30:26 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:
2015.09.05 22:30:26 4: ZWDongle_0 transmit OK for 18
2015.09.05 22:30:26 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 2722.
2015.09.05 22:30:26 3: stacktrace:
2015.09.05 22:30:26 3:     main::__ANON__                      called by fhem.pl (2722)
2015.09.05 22:30:26 3:     main::RemoveInternalTimer           called by ./FHEM/00_ZWDongle.pm (543)
2015.09.05 22:30:26 3:     main::ZWDongle_ProcessSendStack     called by ./FHEM/00_ZWDongle.pm (674)
2015.09.05 22:30:26 3:     main::ZWDongle_Read                 called by fhem.pl (3057)
2015.09.05 22:30:26 3:     main::CallFn                        called by fhem.pl (651)
2015.09.05 22:30:27 5: ZWDongle_Write 00 13180284082518
2015.09.05 22:30:27 5: SW: 010900131802840825184e
2015.09.05 22:30:27 5: ACK received, removing 010900131802840825184e from dongle sendstack
2015.09.05 22:30:27 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.05 22:30:27 5: SW: 06
2015.09.05 22:30:27 5: ZWDongle_0 dispatch 011301
2015.09.05 22:30:27 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00131800
2015.09.05 22:30:27 5: SW: 06
2015.09.05 22:30:27 5: ZWDongle_0 dispatch 00131800
2015.09.05 22:30:27 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:
2015.09.05 22:30:27 4: ZWDongle_0 transmit OK for 18

[rudolfkoenig]

Hab den Stacktrace-Bug geloest, sollte aber keine Nebenwirkungen haben. Das Security-Problem sollte zunaechst Andreas anschauen, da ich deutlich mehr Zeit brauche, um sein Code zu verstehen.

[krikan]

Leider läuft secure-Inklusion mit r9204 nicht durch. Log und list anbei.
secure_classes habe versuchsweise manuell ergänzt. Hat aber keine erkennbaren positiven Auswirkungen.
Morgen mit r9205 mehr Tests (auch außerhalb SECURITY) und gesetztem Attribut mseclog.

[A.Harrenberg]

Hallo Rudi,

dein Patch ist ok, bis auf zwei Ausnahmen:
- ich meine das Senden der Daten aus den WakeUp-Stack per Timer ist auch falsch (genau wie meine Methode, alles zu senden), hier muss man auf die Nachricht vom Controller warten. Das werde ich jetzt umbauen.

Das Timer falsch ist weiß ich, ging aber erst mal nicht anders. Für Security muss die gesamte Abarbeitung von bis zu 8 Nachrichten "AM STÜCK" geschützt werden, obwohl da erst mal nur ein Befehl auf dem Stack (Nonce-Get) liegt. Ich muss mir Deine Lösung erst ansehen und ausprobieren, dann sehen wir weiter.

- Ich wuerde presumed_State als Internal speichern. Eigentlich kann man das aus lastMsgTimestamp ableiten, allerdings muss man ein gesendetes wakeupNoMoreInformation beruecksichtigen.

Ja, Internal ist auch hier besser, die Steuerung über das presumed_State war im Patch noch gar nicht fertig, das hatte ich jetzt bei cnkru für den Danfoss in einer ersten Version probiert. Da waren noch zwei Fehler drin, ansonsten hat das sehr schön funktioniert und alle Nachrichten so lange an das Ende des Stack gepackt bis der Stack abgearbeitet war.

Ich uebernehme diesen Patch, werde aber die o.g. Punkte umbauen.
Ich bitte dich Security nach dem Umbau zu testen, und evtl. zu korrigieren.

Ja, werde ich mir gleich ansehen, erste Tests von Krikan gibt es ja auch bereits, wird aber eine Weile dauern bis ich da durch bin.

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

GANZ kurzer Zwischenstand bei mir mit 9205:

• Inklusion läuft prinzipiell durch, einige Merkwürdigkeiten noch offen
• set <..> configRequestAll läuft nicht durch, die meisten Befehle scheinen da auf dem Stack zu vergammeln und werden nach 10 sekunden abgeräumt
  

Es scheint da Probleme mit dem ReadAnswer zu geben, könnte daran liegen das ich ZWave_CMD rekursiv aufrufe...

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

hab' mir mal ein paar Logmessages eingebaut und "set <...> configRequestAll" mit Security gemacht. Es sieht so aus als ob die ReadAnswerFn gestartet wird, BEVOR der eigentlich dazugehörige Befehl aus dem Sendstack gesendet wurde. Dann kommt es zu den Verzögerungen und den "alten" Nachrichten auf dem SendStack.

Das erste "2015.09.06 09:41:53.062 2: ZWave get ZWave_SWITCH_BINARY_154 secNonce " funktioniert noch,
das zweite "2015.09.06 09:41:53.553 2: ZWave get ZWave_SWITCH_BINARY_154 secNonce " dann nicht mehr.

Die erste Nachricht wird durch das Warten auf Godot erst 13 Sekunden später ausgeführt.
2015.09.06 09:42:05.560 5: SW: 011e00139a179881e9da194b1d43f01c91ef6b7b09184d07c2afe16453259a84

Ohne Security passiert das bei diesem Beispiel nicht, da alles als SET-Befehl implementiert ist. Einzelne manuell Get-Befehle haben ohne Security bisher auch nicht dieses Verhalten gezeigt. "Problem" dürfte noch größer werden wenn man das Delay nutzt, oder?

Any Idea?

Gruß,
Andreas.

Code Auswählen Erweitern

2015.09.06 09:41:53.062 2: ZWave set ZWave_SWITCH_BINARY_154 configEnableDisableLockConfiguration request
2015.09.06 09:41:53.062 3: ZWave_SWITCH_BINARY_154 SECURITY: 7005fc stored for encryption
2015.09.06 09:41:53.062 2: ZWave get ZWave_SWITCH_BINARY_154 secNonce
2015.09.06 09:41:53.062 1: ZWave_SWITCH_BINARY_154: adding 139a029840259a to Sendstack
2015.09.06 09:41:53.062 1: ZWave_SWITCH_BINARY_154: processing SendStack
2015.09.06 09:41:53.063 1: ZWave_SWITCH_BINARY_154: sending 00139a029840259a from SendStack
2015.09.06 09:41:53.063 5: ZWDongle_Write 00 139a029840259a
2015.09.06 09:41:53.063 5: SW: 010900139a029840259a1a
2015.09.06 09:41:53.064 1: ZWave_SWITCH_BINARY_154: type=get; data=139a029840259a
2015.09.06 09:41:53.064 1: ZWDongle_ReadAnswer arg:secNonce regexp:^0004009a..98
2015.09.06 09:41:53.451 5: ACK received, removing 010900139a029840259a1a from dongle sendstack
2015.09.06 09:41:53.471 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.09.06 09:41:53.471 5: SW: 06
2015.09.06 09:41:53.472 5: ZWDongle_0 dispatch 011301
2015.09.06 09:41:53.491 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00139a000002
2015.09.06 09:41:53.491 5: SW: 06
2015.09.06 09:41:53.492 5: ZWDongle_0 dispatch 00139a000002
2015.09.06 09:41:53.492 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.09.06 09:41:53.492 4: ZWDongle_0 transmit OK for 9a
2015.09.06 09:41:53.492 1: ZWave_SWITCH_BINARY_154: processing SendStack
2015.09.06 09:41:53.551 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004009a0a98800953477ad6c8302e
2015.09.06 09:41:53.551 5: SW: 06
2015.09.06 09:41:53.552 4: ZWDongle_ReadAnswer for secNonce: 0004009a0a98800953477ad6c8302e
2015.09.06 09:41:53.552 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:9a ARG:0a98800953477ad6c8302e
2015.09.06 09:41:53.552 3: ZWave_SWITCH_BINARY_154 SECURITY: 7005fc retrieved for encryption
2015.09.06 09:41:53.552 2: ZWave set ZWave_SWITCH_BINARY_154 secEncap 81e9da194b1d43f01c91ef6b7b09184d07c2afe16453
2015.09.06 09:41:53.552 1: ZWave_SWITCH_BINARY_154: adding 139a179881e9da194b1d43f01c91ef6b7b09184d07c2afe16453259a to Sendstack
2015.09.06 09:41:53.553 2: ZWave set ZWave_SWITCH_BINARY_154 configPartnerID request
2015.09.06 09:41:53.553 3: ZWave_SWITCH_BINARY_154 SECURITY: 7005c8 stored for encryption
2015.09.06 09:41:53.553 2: ZWave get ZWave_SWITCH_BINARY_154 secNonce
2015.09.06 09:41:53.553 1: ZWave_SWITCH_BINARY_154: adding 139a029840259a to Sendstack
2015.09.06 09:41:53.553 1: ZWave_SWITCH_BINARY_154: type=get; data=139a029840259a
2015.09.06 09:41:53.553 1: ZWDongle_ReadAnswer arg:secNonce regexp:^0004009a..98
2015.09.06 09:41:56.556 5: ZWDongle_ReadAnswer: select timeout
2015.09.06 09:41:56.556 1: configPartnerID: Timeout reading answer for get secNonce
2015.09.06 09:41:56.557 2: ZWave set ZWave_SWITCH_BINARY_154 configResetDefaultConfiguration request
2015.09.06 09:41:56.557 3: ZWave_SWITCH_BINARY_154 SECURITY: 7005ff stored for encryption
2015.09.06 09:41:56.557 2: ZWave get ZWave_SWITCH_BINARY_154 secNonce
2015.09.06 09:41:56.557 1: ZWave_SWITCH_BINARY_154: adding 139a029840259a to Sendstack
2015.09.06 09:41:56.557 1: ZWave_SWITCH_BINARY_154: type=get; data=139a029840259a
2015.09.06 09:41:56.557 1: ZWDongle_ReadAnswer arg:secNonce regexp:^0004009a..98
2015.09.06 09:41:59.557 5: ZWDongle_ReadAnswer: select timeout


[A.Harrenberg]

Hallo Rudi,

anbei ein kleiner Patch für 10_ZWave.pm. (9205)

Hintergrund: Falls ein Gerät mit Security "unsolicited" Messages verschickt, also z.B. ein Bewegungsmelder, dann muss auch vor der WU-Notification auf den Nonce-Get geantwortet werden können ohne das diese Nachricht in den WakeUp-Stack gelangt.

Ich habe das bisher nur "simuliert" indem ich meinem (netzbetriebenem) Device die WakeUp Klasse hinzugefügt habe und dann per dispatch einen Nonce-Get geschickt habe. Bei mir hat es funktioniert, Krikan hatte bisher (noch) keine Zeit das zu testen, wird sich aber sicherlich noch mit einem Log dazu melden.

Gruß,
Andreas.

[rudolfkoenig]

- patch meldet bei mir "patch: **** malformed patch at line 23:  "
- habs per Hand eingefuegt, aber den regexp mit einem ^ ergaenzt, sonst ist das mit zu unsicher.
- habs eingecheckt.

[A.Harrenberg]

Hallo Rudi,

muss gestehen das ich an dem File editiert hatte, aber eigentlich nur die anderen Unterschiede rausgelöscht hatte, sorry wenn es dadurch nicht direkt funktioniert hat.

Danke,
Andreas.