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

A.Harrenberg · 06 August 2015, 22:08:10

Hallo,

noch mal ein kleines Update:

Die Implementierung ist prinzipiell geschafft! Das mit der Liste der zu verschlüsselnden Klassen hat jetzt auch funktioniert und läuft bei mir schon mal.

Der Code ist aber noch reichlich unaufgeräumt und muss an einigen Stellen noch etwas bearbeitet und höchstwahrscheinlich auch geändert werden. Ich werde da noch ein wenig aufräumen, mehr Sicherheitsabfragen etc. einbauen und evtl. auch die eine oder andere Funktion noch mal umschreiben, sowie das ganze mal mit dem aktuellen Stand von FHEM abgleichen, meine Implementierung beruht nämlich auf einem alten Stand noch vor den ganzen Problemen mit SourceForge.

Edit: Anscheinend gab es in der Zwischenzeit gar keine Updates für 10_ZWave.pm, d.h. an der Stelle muss ich das Ganze jetzt doch nicht mehr anpassen... (Version 8955)

Ich bin mir auch recht sicher das ich im Code gegen ein paar "Richtlinien" verstosse... Das muss ich mit Rudi nach seinem Urlaub mal abklären.

Gruß,
Andreas.

darkscout · 07 August 2015, 20:25:00

Ich verfolge diesen thread schon eine Weile und freue mich schon den Code auszuprobieren

Gute Arbeit soweit. Habe hier bisher nur ein Zwave Gerät (Danalock).

A.Harrenberg · 08 August 2015, 12:16:38

Hi Darkscout!

Zitat von: darkscout am 07 August 2015, 20:25:00
Ich verfolge diesen thread schon eine Weile und freue mich schon den Code auszuprobieren
Gute Arbeit soweit. Habe hier bisher nur ein Zwave Gerät (Danalock).

ist das Schloß denn bereits verbaut oder ist es zum Testen verfügbar?
Ich habe Krikan eine Vorabversion zum Testen gegeben und das hat natürlich erst mal alles so gar nicht funktionieren wollen... Von daher wäre es vielleicht keine gute Idee ein eingebautes Schloss zum Testen zu nutzen.

Hast Du das Schloss bereits mit ZWave in FHEM ausprobiert? Das Ding müsste ja ein FLIRS (also Frequent Listening) Gerät sein, keine Ahnung ob von Seiten des Controllers oder von FHEM aus irgendetwas besonderes gemacht werden müsste.

Wäre nett wenn Du mal kurz schreiben könntest ob und wie das Ding momentan mit FHEM und ZWave zusammenarbeitet und ob das Ding zum Testen nutzbar wäre.

Gruß,
Andreas.

darkscout · 08 August 2015, 15:19:01

Zitatist das Schloß denn bereits verbaut oder ist es zum Testen verfügbar?
Ich habe Krikan eine Vorabversion zum Testen gegeben und das hat natürlich erst mal alles so gar nicht funktionieren wollen... Von daher wäre es vielleicht keine gute Idee ein eingebautes Schloss zum Testen zu nutzen.

Hast Du das Schloss bereits mit ZWave in FHEM ausprobiert? Das Ding müsste ja ein FLIRS (also Frequent Listening) Gerät sein, keine Ahnung ob von Seiten des Controllers oder von FHEM aus irgendetwas besonderes gemacht werden müsste.

Wäre nett wenn Du mal kurz schreiben könntest ob und wie das Ding momentan mit FHEM und ZWave zusammenarbeitet und ob das Ding zum Testen nutzbar wäre.

Das Schloß ist schon verbaut und wird derzeit per Bluetooth genutzt. Habe es mal per Zwave versucht anzulernen an FHEM (mit Z-Wave ZME_UZB1 Me USB Stick). Gerät wird erkannt (ZWave_ENTRY_CONTROL) aber sonst ist nicht viel möglich.

Code Auswählen

UNPARSED SECURITY 029840
battery 64 %
model Polycontrol Danalock Circle/Square
modelConfig polycontrol/doorlock.xml
modelId 010e-0003-0002
state TRANSMIT_NO_ACK
transmit OK
version Lib 3 Prot 2.78 App 2.4

classes MANUFACTURER_SPECIFIC BATTERY VERSION SECURITY

Seit heute habe ich noch ein "Devolo Home Control - Tür/Fensterkontakt" auch mit Security attribut. Er funktioniert auch einwanfrei ohne Security. Der liegt zum testen bereit auf meinem Schreibtisch.

Als Info - ich bin Software Entwickler. Eher C++, Java und C# aber Perl geht auch

A.Harrenberg · 08 August 2015, 16:21:24

Hi Darkscout,

Zitat von: darkscout am 08 August 2015, 15:19:01
Das Schloß ist schon verbaut und wird derzeit per Bluetooth genutzt. Habe es mal per Zwave versucht anzulernen an FHEM (mit Z-Wave ZME_UZB1 Me USB Stick). Gerät wird erkannt (ZWave_ENTRY_CONTROL) aber sonst ist nicht viel möglich.

Code Auswählen Erweitern
UNPARSED SECURITY 029840 [...] classes MANUFACTURER_SPECIFIC BATTERY VERSION SECURITY

Klar, Security wird nicht unterstützt und die "richtigen" Klassen tauchen erst auf nachdem SECURITY aktiv ausgehandelt wurde. Da nimmt Danalock das aber wirklich ernst mit Security (bei einem Türschloss aber auch gut so...), bei den "normalen" Geräten funktionieren zumindest die Basisklassen ja meist auch ohne Security.

Zitat von: darkscout am 08 August 2015, 15:19:01
Seit heute habe ich noch ein "Devolo Home Control - Tür/Fensterkontakt" auch mit Security attribut. Er funktioniert auch einwanfrei ohne Security. Der liegt zum testen bereit auf meinem Schreibtisch.

Als Info - ich bin Software Entwickler. Eher C++, Java und C# aber Perl geht auch

Ich hänge gleich mal die aktuelle Version an den ersten Post in diesem Thread an, wenn Du magst kannst Du ja mal antesten was bei Dir passiert. Mit der letzten Änderung funktioniert das einbinden der KFOB_S Fernbedienung bei Krikan schon mal soweit, allerdings gibt es dann anscheindend Probleme damit, dass die FB natürlich ein Wake-Up Gerät ist und die Antworten mit der NONCE irgendwie im Sendstack liegenbleiben und dann keine Kommunikation mehr stattfindet... Daher könnte es sein das Du mit dem Tür-/Fensterkontakt da auch erst einmal nicht sehr weit kommst.

Das Schloss sollte FLIRS machen und sich eigentlich wie ein "normales" Geräte verhalten, das Risiko muss Du selber abschätzen falls sich da was in der Kommunikation verabschiedet... (Ich geh' mal davon aus das Du es momentan über Bluetooth bedienst, oder?)
Der Test könnte aber spannend werden, für die Kommunikation müssen für jeden Befehl sogenannte NONCE Werte ausgetauscht werden, der in Deinem Log aufgetauchte "UNPARSED SECURITY 029840" ist so eine Anfrage für eine NONCE. Es gibt in der Befehlsliste noch einen Befehl der darauf schliessen lässt das es hier auch eine verschlüsselte Version dieser Übertragung geben könnte, das ist aber selbst in OpenZWave nicht implementiert. Falls das Danalock sowas nutzt wird es richtig spannend, das rauszubekommen geht dann nur mit Try-and-Error (und viel Glück...)

Ach ja, Einbinden mit Security geht nicht über das Menü sondern nur über die "Kommandozeile":

set <ZWDongle-Device-Name> addNode on sec

Gruß,
Andreas.

A.Harrenberg · 08 August 2015, 16:48:28

Hi,

eine erste Testversion für Mutige ist jetzt im ersten Post dieses Thread angehängt.

Gruß,
Andreas.

A.Harrenberg · 09 August 2015, 18:14:29

Hallo Rudi,

mal eine Frage zu dem Sendstack für die Wake-Up Geräte:

Kann es sein das die dort gespeicherten Nachrichten nur gesendete werden wenn eine Wake-Up-Notification eintrifft, und nicht auch wenn das Gerät einfach so sendet?

Ich bin mir da unsicher ob ein Gerät so eine Wake-Up Notification schicken soll wenn es per Timer aufwacht, also einfach nur mal horcht ob was für ihn anliegt oder auch wenn es z.B. auf den Tastendruck reagiert und sowieso auch aktiv eine Nachricht verschickt. Im Logfile von Krikan kommen Nachrichten mit einer Nonce-Request vom der KFOB ohne das ich Wake-Up Notifications erkennen kann, die Nonce-Antworten landen dann aber alle im Sendstack und werden auch nach dem Eintreffen des nächsten Nonce-Request nicht verschickt.

Bei meinem RFID Leser scheint es so zu sein das der mir erst die Nachricht schickt das ein RFID-Tag erkannt wurde und DANACH (< 1sek) dann eine Wake-Up-Notification. Da ist aber auch so einiges merkwürdig im Logfile.

Wenn meine erste Analyse so richtig ist, fürchte ich das wir da einiges umstellen müssen. Würde es helfen wenn ich beim Eintreffen eines Nonce-Request den lastMsgTimestamp setze?

Code Auswählen

$hash->{lastMsgTimestamp} = time();
Damit müsste ich dann ja eigentlich den Sendstack umgehen, oder?

Gruß,
Andreas.

A.Harrenberg · 09 August 2015, 21:13:49

Hallo,

ich habe den angesprochenen kleinen Hack mit dem Setzen des Zeitstempels einfach mal eingebaut und bei ersten Tests von Krikan mit dem KFOB funktioniert es damit schon mal ohne offensichtliche Probleme.

Ob das alles so bleiben kann wird sich im Laufe der Zeit zeigen, ich denke es kann mit der Version aus Post #1 getestet werden, ich würde aber empfehlen das erst einmal nur auf einem Testsystem zu machen. Die aktualisierte Fassung von 10_ZWave.pm (basierend auf 9041) habe ich wie gesagt an Post #1 angehängt.

Gruß,
Andreas.

A.Harrenberg · 11 August 2015, 13:22:18

Hallo,

bei der Implementierung der SECURITY Class treten jetzt die ersten "Folgeprobleme" auf...

Nach der secure-Inclusion tauchen Befehlsklassen auf, die noch nicht in FHEM implementiert sind...
Aktuell gibt es hier z.B. das DanaLock, das nach secure-Inclusion

Code Auswählen

secure_classes DOOR_LOCK USER_CODE SCHEDULE_ENTRY_LOCK CONFIGURATION TIME MANUFACTURER_SPECIFIC BATTERY VERSION MARK
meldet...

Die Klassen:
DOOR_LOCK
SCHEDULE_ENTRY_LOCK
werden zur Zeit noch nicht von FHEM unterstützt, für DOOR_LOCK gibt es zumindest eine Dokumentation für eine Version V1 (aktuell scheint aber V3 zu sein...), für SCHEDULE_ENTRY_LOCK habe ich bisher nichts an Dokumentation gefunden.

Die Implementierung von SECURITY ist hier dann nur der erste Schritt, die zusätzlichen Klassen müssen dann auch noch implementiert werden damit die Geräte auch funktionieren.

DOOR_LOCK könnte ich mir in V1 mal ansehen, für höhere Versionen müsste man mal schauen was z.B. in OpenZWave bereits implementiert ist. Gleiches gilt für SCHEDULE_ENTRY_LOCK, wenn es in OpenZWave implementiert ist hat man Chancen sich das da herauszupicken was man braucht, ansonsten ist das ohne Doku der Klasse sehr mühsames Try-and-Error...

Da ich momentan noch mit dem Aufräumen des Codes für SECURITY beschäftigt bin und die Implementierung ja auch noch nicht von Rudi "abgesegnet" ist, kann ich da erst mal nicht so viel Zeit in neue Klassen stecken.

Wer hier also an DOOR_LOCK oder SCHEDULE_ENTRY_LOCK arbeiten möchte, dem kann ich gerne meine Informationen zur Verfügung stellen, ansonsten muss das noch warten bis wieder Zeit dafür ist.

Gruß,
Andreas.

A.Harrenberg · 11 August 2015, 23:20:55

Hallo,

habe mal ganz grob mit DOOR_LOCK V1 angefangen... Falls jemand noch Informationen zu V2 oder V3 haben sollte bitte melden, ein kurzer Blick in OpenZWave ergibt für mich da auch nur eine V1.

Gruß,
Andreas.

alexschomb · 13 August 2015, 14:20:57

Hallo Andreas,

Danke für deine Arbeit an der DOOR_LOCK Implementierung, ich hoffe dass sich hier noch ein wenig mehr Dokumentation finden wird. Ich habe bisher KeyMatic verwendet gehabt, jedoch nach einem Motorschaden kein Vertrauen mehr in das System. Jetzt bin ich auf DanaLock gestoßen und habe bei der Recherche (habe gerade bei DanaLock angerufen) festgestellt, dass es wohl verschiedene Versionen davon gibt. Bisher in Deutschland mit Z-WAVE verfügbar ist nur die "ganz alte Version", bspw. gerade bei Amazon mit der Kennung POL_BTZEC100. Laut Aussage der Mitarbeiterin kommt Ende August in Deutschland auch die neue Version (POL_BTZE125?) heraus wie man sie bereits bei Danalock US findet. Zwischen der alten Version, der aktuell offiziell in DE verfügbaren Version mit Bluetooth (POL_BT125) und der neuen Version mit BT & Z-WAVE hat sich laut der Mitarbeiterin von Danalock einiges intern getan. Eine Vermutung von mir ist, dass hieraus auch die 3 verschiedenen Versionen von DOOR_LOCK resultieren.

A.Harrenberg · 13 August 2015, 19:40:45

Hallo,

kleiner Bug-fix...

ZitatBei Test mit einem Tür-/Fensterkontakt von DarkScout und Krikan traten weitere Probleme auf, hier wurde die Antwort mit den zu verschlüsselnden Klassen nicht richtig dekodiert und daher nicht akzeptiert. Problem lag an einer falschen Berechung der Blocklänge, ein Bug ist gefunden und damit (hoffentlich) gefixt.

Bei der ganzen Verschlüsselung müssen die Daten immer auf Blocklänge aufgefüllt werden, bei der Routine zum Auffüllen auf diese Blocklänge hatte ich leider einen kleinen Gedankenfehler drin. Die Antwort des Devices von DarkScout und Krikan (sind wohl baugleiche Sensoren von verschiedenen OEM) hatte genau die erforderliche Blocklänge, ich habe jedoch durch meinen Bug noch einen Block voll mit '00' angehängt.

Code ist geändert, an Post #1 ist die aktualisierte Version angehängt.

Gruß,
Andreas.

A.Harrenberg · 13 August 2015, 19:53:40

Hi,

Zitat von: alexschomb am 13 August 2015, 14:20:57
Danke für deine Arbeit an der DOOR_LOCK Implementierung, ich hoffe dass sich hier noch ein wenig mehr Dokumentation finden wird.

Bisher ist da noch nicht viel passiert. Die Befehle die in V1 definiert sind jetzt auch nicht sooo umfangreich. Ich bin mir nicht sicher wie "weit" man mit der V1 bei dem DanaLock kommt. Die Versionen sind immerhin immer abwärtskompatibel, d.h. auch wenn das DanaLock eine V3 hat, so muss es die Befehle von V1 weiterhin unterstützen.

Zitat von: alexschomb am 13 August 2015, 14:20:57
Jetzt bin ich auf DanaLock gestoßen und habe bei der Recherche (habe gerade bei DanaLock angerufen) festgestellt, dass es wohl verschiedene Versionen davon gibt. Bisher in Deutschland mit Z-WAVE verfügbar ist nur die "ganz alte Version", bspw. gerade bei Amazon mit der Kennung POL_BTZEC100. Laut Aussage der Mitarbeiterin kommt Ende August in Deutschland auch die neue Version (POL_BTZE125?) heraus wie man sie bereits bei Danalock US findet. Zwischen der alten Version, der aktuell offiziell in DE verfügbaren Version mit Bluetooth (POL_BT125) und der neuen Version mit BT & Z-WAVE hat sich laut der Mitarbeiterin von Danalock einiges intern getan. Eine Vermutung von mir ist, dass hieraus auch die 3 verschiedenen Versionen von DOOR_LOCK resultieren.

Die Versionen von DOOR_LOCK nicht direkt was mit den Versionen des DanaLock zu tun. Die werden vom ZWave-Konsortium festgelegt, allerdings teilweise auf Anforderung der Kunden/Hersteller. Es kann also durchaus sein das einige Funktionen die DanaLock implementieren wollte in die ZWave Definition gekommen sind.

Ohne weitere Doku oder Mitschnitte von anderen Systemen die schon V2 oder V3 unterstützen sehe ich da keine große Hoffnung da mehr zu implementieren. Das ist immerhin ein recht teures Gerät was man durch rumprobieren an unbekannten Parametern durchaus (mechanischen) Schaden nehmen könnte...

Aber erst mal abwarten wie weit ich mit der V1 komme, SECURITY hat da erst noch Priorität.

Gruß,
Andreas.

A.Harrenberg · 13 August 2015, 20:58:41

Hallo,

ein Problem gelöst, schon ist das nächste da...
Das Testgerät nutzt nun leider einen Befehl (SecurityCmd_MessageEncapNonceGet = 0xc1) den ich noch nicht kenne, und der deshalb auch nicht implementiert ist.

Ich hoffe ich werde da auch bei OpenZWave fündig.

Gruß,
Andreas.

A.Harrenberg · 15 August 2015, 22:35:13

Hallo,

noch mal ein kleines Update, Befehle mit SecurityCmd_MessageEncapNonceGet (98c1) werden nun auch verarbeitet. Es hat sich herausgestellt das dies ein kombinierter Befehl ist, es wird eine verschlüsselte Nachricht verschickt, gleichzeitig wird mit dem Befehl die NONCE für die nächste angefordert. Das spart einen Befehl und verringert den ohnehin schon recht hohen overhead für SECURITY...

Allerdings gibt es noch merkwürdige Kommunikationsprobleme mit dem Testgeräte von Krikan (bzw. DarkScout, baugleiche Geräte). Anscheinend werden dort get-Befehle an verschlüsselte Klassen nicht verarbeitet und es gibt unbekannte Rückmeldungen vom Gerät.

Meine erste Analyse der Logfiles von Krikan hat leider noch keinen Anhaltspunkt bzw. Grund für dieses Verhalten oder für die unbekannte Rückmeldung ergeben.

Falls noch jemand Geräte mit Unterstützung für SECURITY hat und bereit wäre das mal anzutesten würde das schon mal helfen zu unterscheiden ob es ein geräteabhängiges Problem oder ein generelles Problem ist.

Gruß,
Andreas.