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

[A.Harrenberg]

Hallo,

hier soll ein Thread entstehen, der sich mit der Implementierung der CommandClass SECURITY (0x98) und der darin enthaltenen AES-Verschlüsselung beschäftigt.

In einem anderen Thread im ZWave-Forum (ZME_KFOB_S / ZME_KFOB2) wird die Implementierung der AES-Verschlüsselung für Fernbedienungen (ZWaveMe KFOB) bereits diskutiert. Da der Titel nur auf die Fernbedienung, aber nicht auf die AES-Verschlüsselung oder die entsprechende Befehlsklasse hinweist, eröffne ich hier mal einen neuen Thread.

Ich werde versuchen in diesem ersten Post eine Art Status der Entwicklung und Links zu wichtigen Nachrichten aktuell zu halten, diesen Post also immer wieder mal editieren.

Gruß,
Andreas.

Stand: 04.09.2015

Status:
Die Implementierung ist Dank der zur Verfügung stehenden Logfiles und Sourcen aus OpenZWave jetzt prinzipiell funktionsfähig, die Umsetzung im FHEM Code ist aber noch nicht wirklich schön und vor allem noch nicht gegen irgendwelche Fehler abgesichert.

Aktuell sind keine Fehler in den Security Funktionen bekannt, allerdings gibt es noch Störungen des Kommunikationsprotokolls sobald mehrere Nachrichten "gleichzeitig" bzw. aus dem Wake-Up-Stack abgearbeitet werden. Das ist ein generelles Problem und eigentlich nicht direkt SECURITY spezifisch, die Kommunikation ist aufgrund der größeren Anzahl an Nachrichten aber leider empfindlicher gegen Störungen durch andere Nachrichten.

Die Befehle werden jetzt per Timer und einer "Pause" vom WakeUp-Stack geholt und verschickt. Nach unverschlüsselte Nachrichten wird jetzt nur noch  0.05 Sekunden gewartet, da hier theoretisch keine weiteren Nachrichten gesendet werden sollten, nach  verschlüsselten Nachrichten wird 1.5 Sekunden gewartet. Diese Werte sind neu und müssen sich noch in Tests bewähren...

Es gibt jetzt ein Reading "SECURITY" in dem der Status (hoffentlich ENABLED) gespeichert wird. Falls es hier einen Fehlereintrag mit "DISABLED" gibt, werden die security Befehle nur als dummy 0x9800 ausgegeben. (Hier muss noch eine bessere Lösung gefunden werden...)

Die letzten Änderungen von Rudi aus der 9176 habe ich erst einmal soweit übernommen, aber noch nicht im Zusammenspiel mit Security getestet. Die Zwischenspeicherung der Daten ist jetzt mit "Internals" statt "Readings" implementiert.

Dokumentation ist wieder gefixt, war in der letzten Datei (intern V1.26) leider durcheinander geraten...

Das Ganze ist noch in der Testphase, daher empfehle ich das nur auf Testsystemen auszuprobieren oder man sollte genau wissen was man tut...

• OK: Initialisierung des Controllers, sodass Geräte die SECURITY unterstützen dies auch melden
• OK: erste Befehle zur Vorbereitung des Schlüsselaustauschs implementiert (SchemeGet/-Report, NonceGet/-Report, NetworkkeySet)
• OK: Schlüsselaustausch / Verschlüsselung / Authentifizierung kann offline nachvollzogen werden
• OK: Implementierung Schlüsselaustausch
• OK: Implementierung AES-Verschlüsselung
• OK: Implementierung Abfrage der verschlüsselten Klassen
• OK: Implementierung Messagehandling Senden/Empfangen von verschlüsselten Nachrichten
• OK: Probleme bei Wake-Up Gerät, Work-around eingefügt bis vernünftige Lösung gefunden ist
• OK: Prüfen ob AES-Verschlüsselungsroutingen im CUL-HM kompatibel sind -> CUL-HM nutzt ebenfalls Crypt::Rijndael
• OK: Funktion bei Multi-Channel nachvollziehen, Befehle werden transparent abgearbeitet
• OK: Abarbeiten des WakeUp-Sendstacks per Timer
• Offen: Fehlende Steuerung des Sendstacks
• OK: Status für Securtiy als Reading (ENABLED / DISABLED)
• OK: Abfrage auf Crypt::Rijndael per "eval require" mit Fehlermeldungen im Log
• OK: Abfrage auf SECURITY Klasse mit Fehlermeldungen im Log
• OK: Abfrage auf vorhandenen Netzwerkschlüssel mit Fehlermeldungen im Log
• OK: Abfrage auf Verify des Netzwerkschlüssel per Timer mit Fehlermeldungen im Log
• OK: Umstellung des security stacks von Readings auf Internals
• OK: Umstellung des frame stacks von Readings auf Internals
• Offen: Abbruch eines Befehls falls Status "DISABLED", aktuell wird noch 9800 gesendet...

Eine Version zum Testen (basiert auf 9176) ist angehängt, Auslösen einer "secure Inclusion" geht nur über die Befehlszeile mit:

Code Auswählen Erweitern

set <Devicename ZWave, meist ZWDongle_0> addNode on sec
Das "addNode off" kann dann ganz normal über das DropDown gemacht werden.

Zum Testen muss auch ein Netzwerkschlüssel im ZWDongle Gerät definiert sein:
Attribut 'networkKey' muss mit einer 32-zeichen langen Hexzahl gefüllt werden (ohne 0x), also z.B. '0102030405060708090a0b0c0d0e0f10'.

falls noch jemand wie ich nicht weiß wie man das Perl Modul Crypt::Rijndael unter Ubuntu installiert
apt-get install libcrypt-rijndael-perl
hat bei mir funktioniert.

Infos:

• Ursprüngliche Diskussion zur Fernbedienung (ZME_KFOB_S / ZME_KFOB2)
• Beitrag mit Logfile einer "Secure-Inclusion" des KFOB_S unter OpenZWave (KFOB_S Inclusion mit OpenZWave)
• Beitrag mit weiterem Logfile einer "Secure-Inclusion" des KFOB_S unter OpenZWave (KFOB_S Inclusion mit OpenZWave)
• Beitrag mit Logfile einer "Secure-Inclusion" einer AEON-Labs Sirene unter OpenZWave (DSD31 Inclusion mit OpenZWave)
• Beitrag von Rudi zur Implementierung der Controller Initialisierung (Implementierung Controller Initialisierung)
• Beitrag von Rudi zur Implementierung der ersten SECURITY Befehle (Implementierung Controller Initialisierung)
• Beitrag mit Logfile einer "Secure-Inclusion" des KFOB_S unter Z-Way (KFOB_S Inclusion mit Z-Way)

[A.Harrenberg]

Hallo,

um den ersten Post nicht zu überfrachten hier mal eine etwas ausführlichere Beschreibung des aktuellen Stands:

Für die Implementierung der Befehlsklasse SECURITY sind neben "normalen" Befehlen auch verschlüsselte Nachrichten zu erzeugen, wozu man eine AES Implementierung benötigt und den genauen Ablauf und die Erzeugung der nötigen Schlüsselpaare abbilden muss.

Da dies bei OpenZwave bereits weitgehend implementiert ist, haben wir entsprechende Logfiles einer "Secure Inclusion" zur Verfügung. Deren Analyse hat bereits zu der Implementierung der Initialisierung des Controllers und einiger grundlegender Befehle der Klasse durch Rudi geführt.

In den wenigen zur Verfügung stehenden Dokumenten zu dem Thema ist für eine "Secure Inclusion" beschrieben das direkt nach Ablauf der normalen Inclusion das Aushandeln/Übertragen des Schlüssels durchzuführen ist.

Für die Erklärung des Ablaufs gilt:
C = Controller
N = Node (also das einzubindende Gerät)
S = Send -> CS = Controller sendet etwas, NS = Node sendet etwas
R = Receice -> CR = Controller empfängt etwas, NR = Node empfängt etwas

Der Unterschied zwischen CR (Controller empfängt) und NS (Node sendet) ist, das es sich bei CR normalerweise um eine Antwort auf einen vorherigen Befehl handelt, und bei NS um einen neuen Befehl den die Node verschickt.
Bei den Angaben hinter CR, CS, NR oder NS handelt es sich dann um Befehle der SECURITY Class.

In der Doku ist der Ablauf wie folgt dargestellt:
1: CS SchemeGet / CR SchemeReport
2: CS NonceGet / CR NonceReport
3: CS NetworkkeySet (lt. Doku verschlüsselte Nachricht)
4: NS NonceGet / NR NonceReport
5: NS NetworkkeyVerify (lt. Doku verschlüsselte Nachricht)

In den Logfiles von OpenZWave ist das NetworkkeySet aus Schritt 4 nicht verschlüsselt, es erfolgt aber eine verschlüsselte Bestätigung im Schritt 5. Allerdings wird beim Empfang dieser verschlüsselten Bestätigung dort ein Fehler in der Verschlüsselung angezeigt. Im weiteren Verlauf des Logfiles scheint aber trotzdem alles zu funktionieren.

In der aktuellen Version von FHEM kann man eine "secure Inclusion" mit <set ZWDongle_0 addNode on sec> auslösen. Hierbei wird aktuell noch eine andere Reihenfolger der Schritte ausgelöst und es erfolgt KEINE verschlüsselte Bestätigung des Schlüssels.

Ich habe lokal bei mir die Befehle auf die oben dargestellte und in OpenZWave vorhandene Reihenfolge umgestellt, erhalte aber leider trotzdem KEINE verschlüsselte Rückmeldung von meinem Gerät.

Da bis zu diesem Zeitpunkt noch keine Verschlüsselung auf Seiten des Controllers (FHEM) benötigt wird, scheint es demnach immer noch Unterschiede bei der Initialisierung des Controllers oder Details bei den versendeten Befehlen zu geben. Hier sind weitere Analysen der Logfiles nötig um Unterschiede aufzudecken und Anpassungen an FHEM zu machen.

Aktuell habe ich Domoticz/OpenZWave zum Testen unter Windows installiert, da kann ich jetzt zwar einen Vergleichstest machen, ich kann dort allerdings nichts am Code ändern. Als nächsten Schritt werde ich daher versuchen mir OpenZWave und das dazugehörige Control Panel mit den Sourcen unter Linux zu compilieren/installieren, damit ich da die Möglichkeit habe Vergleichstests zu machen und ggf. auch Änderungen wie z.B. erweiterte Debug-Ausgaben neu in den Code einzucompilieren.

Zum Thema AES Verschlüsselung ist momentan noch nicht soo viel zu sagen, soweit bisher bekannt werden verschiedene Block-Modi für AES benötigt, hier gehen die Informationen aus den verschiendenen Quellen aber auseinander. An dieser Stelle ist wahrscheinlich ein reverse Engineering aus den Sourcen von OpenZWave hilfreich.

Soweit erst einmal der Stand, leider bin ich am Mitte der Woche erst mal für 2.5 Wochen in Urlaub, werde mich daher erst nach meinem Urlaub intensiver um das Thema kümmern können.

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

und schon die ersten neuen Erkenntnisse ,-)

Eine erste oberflächliche Analyse des Logfiles von Z-Way zeigt, dass der NetworkkeySet (im Schritt 4 aus dem zweiten Post) dort VERSCHLÜSSELT erfolgt! Das passt dann zu der Beschreibung in der Doku, jedoch nicht zu dem Ablauf bei OpenZWave...

Ich werde mal versuchen mir den Code von OpenZWave anzuschauen, ich hatte bereits den Verdacht das dort der NetworkkeySet auch verschlüsselt erfolgt, dies aber im Logfile nicht zu erkennen weil evtl. die Ausgabe an der "falschen" Stelle im Code erzeugt wird. Das Log von Z-Way verstärkt diesen Verdacht...

Gruß,
Andreas.

[krikan]

Hallo Andreas,
meine Logs mit openzwave waren noch mit dem "alten" security-Branch erstellt. Vielleicht hat sich dort zwischenzeitlich, nach Übernahme in den Master-Branch, noch etwas getan. Soll ich noch mal probieren mit dem aktuellen Master-Branch Logs zu erzeugen?
Gruß, Christian

[A.Harrenberg]

Hallo Christian,

ich habe hier selbst mal mit "domoticz-win32-2_2583-setup" rumgespielt, das sollte eigentlich die neueste Version sein. Falls Du nichts neueres zur Verfügung hast brauch ich da ersteinmal keine weiteren Logfiles.

Ich muss allerdings sagen das ich mit Domoticz ganz schön gekämpft habe bis da mal ein vernünftiges Logfile rauskam.

Falls Du doch noch was testen möchtest, einfach im Logfile schauen ob da ein 9806 (SECURITY NetworkkeySet) als Befehl drin vorkommt, falls ja ist es unverschlüsselt... (oder nicht richtig geloggt).
Ansonsten müsste nach dem SchemeGet/-Report, NonceGet/-Report ein 9881 (SECURITY MessageEncap) als Befehl vorkommen. Das wäre dann ein verschlüsseltes Packet, so eins kommt dann später als Antwort und müsste eigentlich eine 9807 (SECURITY NetworkKeyVerify) enthalten.

Gruß,
Andreas.

[krikan]

mal mit "domoticz-win32-2_2583-setup" rumgespielt, das sollte eigentlich die neueste Version sein.

Wenn ich das richtig verstehe, enthält das nicht den aktuellen Master-Branch, sondern nur den von mir getesteten security-branch.

Falls Du doch noch was testen möchtest, ......

Möchten, mmh . Aber wenn es Dir/uns ggfs. hilft probiere ich es.

[A.Harrenberg]

Hi Christian,

momentan ist meine Zeit eh recht knapp, da ich vor dem Urlaub beruflich und privat noch so einige andere Sachen zu erledigen habe... Und im Urlaub habe ich kein Internet ,-)

Von daher würde ich sagen das ich momentan mit weiteren Logfiles nicht sooo viel anfangen kann, Ich denke ich werde erst mal versuchen mir das ganze OpenZWave mit der Console aus den aktuellen Sourcen zu kompilieren und das auf meiner Linuxrechner ans Laufen zu bringen. Das bringt auf lange Sicht wohl mehr.

Das schöne an Perl ist ja das man "mal eben" eine weitere Zeile mit einer Logausgabe zum Code hinzufügt und es sofort ausprobieren kann. Bei OpenZWave muss man ja compilieren, und das werde ich mir unter Windows nicht "antun".

Wenn ich diese Woche noch ein wenig Zeit finde schaue ich mir den Sourcecode von OpenZWave noch mal an um zu sehen ob dieser NetworkkeySet nun wirklich unverschlüsselt gesendet wird oder ob da das Logging nicht stimmt.

Also würde ich sagen warten wir mal ab bis mein OpenZWave mit den akutellen Sourcen läuft, dann kann ich da weitere Logfiles erzeugen und habe dann wahrscheinlich auch schon mehr Übersicht über den Sourcecode.

Gruß,
Andreas.

[krikan]

OK, dann habe ich noch mal Glück gehabt . Wenn ich etwas testen/probieren kann, gib einfach Bescheid. Ansonsten schönen Urlaub.

[A.Harrenberg]

Hallo,

so, habe es jetzt nach einigen Anläufen geschafft mir Domoticz auf dem Linux Rechner zu installieren und habe die Inclusion dort noch mal ausgeführt.

Es ist jetzt ziemlich sicher das auch OpenZwave den NetworkkeySet verschlüsselt überträgt. Das Logfile der etwas neueren Version ist da etwas gesprächiger, der Befehl für die Schlüsselübertragung ist im Klartext angegeben, danach kommt die verschlüsselte Variante und das danach dürfte die MAC sein.

Beim der Logzeile mit dem "Send" wird dann wieder die unverschlüsselte Version ausgegeben, so wie in den alten Logfiles auch, wodurch ja das Missverständnis aufkam.

Code Auswählen Erweitern

2015-06-28 17:32:07.907 Info, Node001, Setting Up Inclusion Network Key for Secure Communications
2015-06-28 17:32:07.907 Info, Plain Text Packet:: 0x00, 0x98, 0x06, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10
2015-06-28 17:32:07.907 Info, Node001, Setting Up Inclusion Network Key for Secure Communications
2015-06-28 17:32:07.907 Info, Encrypted Packet: 0x1d, 0x31, 0xdd, 0x53, 0xf7, 0xee, 0x56, 0x41, 0x90, 0x36, 0x8b, 0x71, 0xdc, 0x01, 0xdf, 0xb3, 0x3a, 0xea, 0x52
2015-06-28 17:32:07.907 Info, Raw Auth (minus IV): 0x81, 0x01, 0x28, 0x13, 0x1d, 0x31, 0xdd, 0x53, 0xf7, 0xee, 0x56, 0x41, 0x90, 0x36, 0x8b, 0x71, 0xdc, 0x01, 0xdf, 0xb3, 0x3a, 0xea, 0x52

2015-06-28 17:32:07.907 Info, Computed Auth: 0x05, 0xac, 0xda, 0x23, 0xf8, 0x45, 0x00, 0x72
2015-06-28 17:32:07.907 Info, Node040, Sending (Security) message (Callback ID=0x0d, Expected Reply=0x04) - SecurityCmd_NetworkKeySet (Node=40): 0x01, 0x19, 0x00, 0x13, 0x28, 0x12, 0x98, 0x06, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10, 0x25, 0x0d, 0x69


Damit ist jetzt klar das wir jetzt auf die AES Implementierung angewiesen sind um diesen Schritt auszuführen. Immerhin bin ich jetzt beruhigt das dies mit der Dokumentation übereinstimmt. In dieser Version von OpenZWave ist der MAC-Fehler bei der NetworkkeyVerifiy Antwort vom Gerät allerdings immer noch enthalten, das sollte sicherlich auch nicht so sein...

Gruß,
Andreas.

[A.Harrenberg]

Hallo zusammen,

mal ein kleiner Gruß aus meinem Urlaub... Hab' doch Internet...

Ich wollte mal einen ersten kleinen, aber durchaus wichtigen Erfolg melden: Mittels Crypt:Rijndael konnte ich jetzt offline die Entschlüsselung eines Packetes nachvollziehen und bekomme auch das gleiche Ergebnis wie OpenZWave...

Dabei kam auch raus, das OpenZWave das erste Packet mit der Bestätigungsantwort des Netzwerkschlüssels falsch dekodiert, dies aber nicht weiter beachtet. Wenn ich die verschlüsselte Nachricht entschlüssel dann erhalte ich wie im Protokoll vorgesehen eine "0x98 0x07", was dann "Networkkey Verify" ist.

Als nächstes muss ich mir jetzt mal eine gesendete Nachricht anschauen, die sollte aber prinzipiell genauso verschlüsselt werden, das Verfahren ist an der Stelle symmetrisch.

Danach muss ich dann noch die an die Nahricht angehängte Authentifizierung (MAC message authentication code) nachvollziehen, hier wird ein anderer Modus verwendet, ich denke aber das ich das auch "nachbauen" kann.

Dann wäre die eigentliche Verschlüsselung schon mal geklärt, ich fürchte allerdings das die Implementierung einige größere Änderungen an der bisherigen Struktur von 00_ZWDongle und 10_ZWave benötigt. Dazu muss ich dann aber erst mal besser verstehen wie der Ablauf dort funktioniert.

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

so, jetzt bin ich soweit "durch"...

Ich kann jetzt alle Verschlüsselungsschritte und auch die Authentifizierung die OpenZWave macht offline nachvollziehen.

Bei der Verschlüsselung der ersten Nachricht (die Übermittelung des Networkkey Set) sowie der dazugehörigen MAC (message authentification code) werden jeweils temporäre Keys für die Verschlüsselung und die Authentifizierung verwendet.

Aus dem angegebenen Networkkey wird jeweils ein "encryption key" und ein "authentication key" gebildet mit dem dann bereits die Antwort (Networkkey Verify) verschlüsselt und authentifiziert ist.

Ab hier werden dann nur noch der "encryption key" und der "authentication key" verwendet.

Der Fehler bei OpenZWave besteht im Moment darin das dort versucht wird die Antwort noch mit dem temporären Keys zu entschlüsseln und zu authentifizieren. Dies ist zwar unschön, hat aber weiter keine Auwirkung, da die Antwort nicht weiter geprüft wird.

Mehr kann ich dann erst wieder von zu Hause machen.

Gruß,
Andres

[A.Harrenberg]

Hi,

kurzer "Zwischenbericht":

Ich habe mir im ersten Schritt jetzt mal ganz grob die Verschlüsselung und Authentifizierung für den "NetworkKey_Set" Befehl in den bisher vorhandenen SecureInit reingebastelt. (Das wird anders verschlüsselt als die nachfolgenden Nachrichten, da der Key beim Empfänger ja noch nicht bekannt ist)
Ich kann jetzt mit der empfangenen Nonce vom Gerät eine verschlüsselte Nachricht erzeugen und auch verschicken, allerdings reagiert mein Gerät leider NICHT mit einer entsprechenden Antwort darauf.  ,-(

Ich habe mir in Domoticz/OpenZwave ein paar zusätzliche Logmeldungen eingebaut, bisher aber keine prinzipiellen Unterschiede feststellen können.
Leider kann man das ja nich so einfach vergleichen, da die Verschlüsselung ja die empfangene Nonce berücksichtigt und die Packete damit jedesmal anders lauten.

Ich werde mir morgen mal die beiden verschlüsselten Nachrichten (von FHEM und OpenZWave) nehmen und die noch mal offline entschlüsseln, vielleicht habe ich ja doch noch einen oder mehrere Fehler bei der Verschlüsselung reingebaut. Falls nicht könnte es noch etwas mit der Initialisierung des Controllers zu tun haben. Dazu muss ich mir aber JEDES Packet aus dem Domoticz/OpenZwave Logfile ansehen...

Ich hatte eigentlich gehofft hier schneller weiter zu kommen, da die Verschlüsselung jetzt ja eigentlich klar ist...
Ich werde dann morgen noch mal berichten.

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

zweiter Versuch, meine erste Antwort ist gerade im Nirvana verschwunden ,-(

Ich werde mir morgen mal die beiden verschlüsselten Nachrichten (von FHEM und OpenZWave) nehmen und die noch mal offline entschlüsseln, vielleicht habe ich ja doch noch einen oder mehrere Fehler bei der Verschlüsselung reingebaut.

Natürlich waren noch Fehler bei der Verschlüsselung drin...

Aber jetzt funktioniert es!

Ich bekomme jetzt auf das verschlüsselte Senden des Netzwerkschlüssels eine verschlüsselte Antwort vom Gerät. Diese kann ich zwar aktuell nur offline entschlüsseln, es ist aber "Networkkey_Verify"!

Damit wäre der "Proof of Concept" gemacht, die aktuelle Umsetzung ist aber nicht allgemein tauglich sonder ist nur diesen ersten Schritt zusammengebastelt. Da sind z.B. etliche Sachen einfach fest eingetragen statt vernünftig berechnet zu werden und der Ablauf ist auch alles andere als "schön" realisiert. Aber es ging mir jetzt eigentlich nur darum festzustellen ob denn das Gerät die Verschlüsselung akzeptieren würde.

Momentan habe ich noch keinen richtigen Ansatz wie man das "schön" implementieren kann, irgendwie hat das immer etwas von Sonderfallregelung und Work-around...

Hier mal ein paar Gedanken zum Ablauf zur Diskussion:

Beim Versenden eine Nachricht muss geprüft werden ob die Nachricht verschlüsselt gesendet werden muss. Hierzu könnte ich mir ein zusätzliches Attribut (oder besser Internal) "secure_classes" vorstellen das aus der Abfrage des "Supported_Get" bei der secure-Inklusion gebildet werden muss. Die Nachricht würde man wahrscheinlich am besten in ZWave_Cmd "abfangen" und müsste sie zwischenspeichern. Dann müsste man bei dem Geräte eine Nonce anfragen und auf die Antwort warten. Mit der empfangenen Nonce, einer eignenen Nonce und dem Netzwerkschlüssel kann die Nachricht dann versendet werden.
Das Abfangen und zwischenspeichern könnte man evtl. ähnlich zu dem Sendstack für Wake-Up Geräte realisieren, das habe ich mir aber bisher noch nicht genau genug angesehen.

Beim Empfang einer verschlüsselten Nachricht muss es vorher eine Anfrage für eine Nonce gegeben haben. Diese muss generiert, verschickt und zwischengespeichert werden, da sie zur Entschlüsselung benötigt wird. Wenn dann eine verschlüsselte Nachricht eintrifft muss man die dazu passende Nonce "wiederfinden" und die Nachricht mit dem Netzwerkschlüssel entschlüsseln. Die so entschlüsselte Nachricht muss dann noch mal in FHEM eingespeist werden, hier hatte Rudi in einem anderen Thread das Stichwort "Dispatch" gebracht.

@Rudi, bitte versteh' das jetzt nicht falsch, aber der aktuelle Code für ZWave ist teilweise sehr schwer nachzuvollziehen und enthält schon eine ganze Menge an Sonderfällen und Work-arounds. Dies würde durch die beschriebenen Funktionen sicherlich nicht besser werden sondern noch mal deutlich leiden.

Aktuell habe ich aber auch (noch) keinen Verbesserungsvorschlag, fürchte jedoch das sich Security nicht wirklich sauber in den aktuellen Code implementieren lässt...

Hast Du evtl. konkrete Ideen zur Implementierung/Umstrukturierung die Du mal kurz beschreiben könntest? Das soll ja nicht bedeuten das Du es dann auch umsetzen sollst, ich denke das ich mich so langsam einarbeite und da sicherlich auch einiges umsetzen kann, zumal man ja auch fragen kann ,-)

So, jetzt muss ich aber frühstücken, wollte ich ja vorhin schon, nur ist dann die Antwort verschwunden...

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

noch mal ein kurzer Bericht zum Zwischenstand:

Ich habe jetzt einige Unterroutinen erstellt mit deren Hilfe ich die Nachrichten ver- und entschlüsseln kann, sowie die Authentfizierung erstellen bzw. prüfen kann. Das ganz funktioniert jetzt schon sehr schön bis zum Empfang der verschlüsselten Bestätigung des Netzwerkschlüssels. Die Entschlüsselung der empfangenen Nachricht funktioniert jetzt auch schon, muss aber noch etwas erweitert werden.

Soweit schon mal gut, jetzt muss ich diesen entschlüsselten Befehl nur noch wieder in neu in FHEM einspeisen, meine erste Idee mit "dispatch" wird leider nicht funktionieren, da es ja an der Stelle keine komplette ZWave Nachricht mehr ist. Wahrscheinlich kann ich den Befehl aber einfach in ZWave_Parse einspeisen. Momentan ist im Code noch so gut wie keine Sicherheitsabfragen drin, aber so langsam wird das was...

Als nächstes muss ich dann eine verschlüsselte Nachricht mit "Supported_Get" erzeugen und die Rückgabewerte auswerten.

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

nachdem ich ein paar Tage leider nichts machen konnte habe ich gestern mal wieder etwas gebastelt und bin dabei auch ein gutes Stück weitergekommen.

Das Entschlüsseln einer empfangenen Nachricht und erneutes "Einspeisen" dieser Nachricht in FHEM funktioniert ja schon und gestern abend habe ich es dann geschafft eine unverschlüsselte Nachricht mit dem Supported_Get, "abzufangen", zu verschlüsseln und dann verschlüsselt zu verschicken. Das Gerät hat auch brav die verschlüsselte Nachricht mit dem Supported_Report zurückgeschickt, das Parsen dieser Antwort ist dann als nächstes dran, das sollte aber einfach zu erledigen sein, die Routine für das Parsen der normalen Befehlsklassen existiert ja schon, die muss ich nur kopieren und ein wenig anpassen.

Mit der Liste der unterstützten verschlüsselten Klassen aus dem Supported_Report kann ich dann ein Attribut "secure_Classes" füllen, aus dem ich dann abfragen kann ob ich die Nachricht abfangen und verschlüsseln muss, momentan ist da nur der "Supported_Get" fest codiert... Hier muss ich allerdings einige Sonderfälle bei der SECURITY-Class selbst beachten.

Sobald das mit der Liste implementiert habe wäre das schon mal soweit funktionsfähig, wobei ich vor allem mit dem Ablauf der Initialisierung noch alles andere als Glücklich bin. Der Code ist momentan auch noch überfrachtet mit Logmessages und ist an vielen Stellen auch noch verbesserungswürdig...

Sobald ich dann da mal etwas aufgeräumt habe könnte ich dann mal eine Version zum Antesten zur Verfügung stellen, wobei das ganze momentan nicht auf der aktuellsten Version von FHEM basiert.

Gruß,
Andreas.