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

[Netsurfer]

Hallo zusammen,

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.

[A.Harrenberg]

Hi,

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.

guter Hinweis, ich habe das einfach mal in den Post #1 eingefügt. ,-)

Momentan gibt es aber noch ein paar Problemchen mit Security, da jetzt im "normalen" ZWave-code relativ viel umgestellt wurde und noch nicht alles darauf angepasst wurde.

Gruß,
Andreas.

[Netsurfer]

schön das ich auch mal einen kleinen Beitrag leisten konnte 

[A.Harrenberg]

Hallo,

ich wollte nur mal kurz ankündigen das ich die nächsten 3 Wochen leider keinen Support bei Problemen leisten kann. Ich muss jetzt erst mal auf eine Dienstreise und bin anschließend noch privat unterwegs.

Bei Problemen diese ruhig auch in der Zwischenzeit hier posten/schildern, vielleicht ist es ja gar nichts Security spezifisches und Rudi oder Krikan können helfen. Ich erwarte auch keine größeren Probleme mit der mit den internen Verschlüsselungsroutinen. Was auftreten könnte sind häufigere CAN Messages. Das liegt dann einfach daran das durch die Verschlüsselung zusätzliche Nachrichten übertragen werden müssen.

Durch das erneute Versenden der betroffenen Nachrichten sollte es im Idealfall zu keinem Nachrichtenverlust kommen.
Sollten hier ernsthaftere Probleme auftreten muss ich mir das dann nach meiner Rückkehr anschauen.

Gruß,
Andreas.

[Ralli]

Security Evaluation of the Z-Wave Wireless Protocol

[krikan]

Security Evaluation of the Z-Wave Wireless Protocol

Was soll uns das sagen?

[rudolfkoenig]

Dass ich noch immer nicht dazugekommen bin, ZWave in culfw zu implementieren.

[krikan]

Mach Dir mal keinen Stress, sonst "muss" ich mir noch einen CUL kaufen...
Zu kein Stress: Hattest Du meinen Patch http://forum.fhem.de/index.php/topic,32823.msg336233.html#msg336233 gesehen? Habe noch so etwas auf Lager..

[Ralli]

@krikan:

Das ist ein interessanter Artikel über einen Implementierungsfehler vom Key-Exchange, der aber an Sigma kommuniziert wurde. Soll hier in dem Thread einfach für den Hinterkopf sein, dass ggf. eben darauf zu achten ist.

[rudolfkoenig]

@krikan: nein, und ich wuesste gerne wieso. Die Diskussion war nicht auf Beobachtung... Ich schaue es mir heute Abend oder Morgen an. Bitte dein Link nicht loeschen.

@Ralli: das Dokument ist aelter, die beiden Autoren haben die Funk-Telegramme mit einem CC1101 kompatiblen Empfaenger aufgezeichnet. Sie ruecken zwar nicht den ganzen Code raus, aber nach etwas betteln haben sie mir die CC1101 Konfiguration zugeschickt. Leider hat es beim ersten Versuch nicht funktioniert, obwohl ich sehr gerne die ZWave-Funk-Telegramme sehen wuerde. Solange so eine freie Implementierung nicht verfuegbar ist, ist ZWave mAn auch ohne Verschluesselung sicher.

Ob danach ZWave mit Verschluesselung sicher ist, wage ich zu bezweifeln: weder wir von FHEM, noch die Geraetehersteller sind Profis, was Sicherheit betrifft. Die Aussage vom Paper ist (wenn ich es richtig verstanden habe), dass das Firmware im Tueroeffner fehlerhaft war.

Immerhin koennte man mit aktivierten Security dem Einbrecher mit DMCA drohen

[A.Harrenberg]

Hi,

@Ralli: das Dokument ist aelter[...]
Solange so eine freie Implementierung nicht verfuegbar ist, ist ZWave mAn auch ohne Verschluesselung sicher.

Ob danach ZWave mit Verschluesselung sicher ist, wage ich zu bezweifeln: weder wir von FHEM, noch die Geraetehersteller sind Profis, was Sicherheit betrifft. Die Aussage vom Paper ist (wenn ich es richtig verstanden habe), dass das Firmware im Tueroeffner fehlerhaft war.

Immerhin koennte man mit aktivierten Security dem Einbrecher mit DMCA drohen

der beschriebene Fehler lag wie von Rudi geschrieben in der Firmware des Gerätes und nicht im Protokoll von ZWave.

Das Protokoll ist sicher, solange niemand die Kommunikation währed der Inklusion belauscht. Dort wird das Passwort nämlich mit einem Standard-Passwort verschlüsselt übertragen. Da dieses Standard-Passwart jetzt kein "Geheimnis" mehr ist, liesse sich aus der Kommunikation das Passwort extrahieren. Ohne die Kenntnis des Passworts ist das Protokoll an sich sicher, Implementierungsfehler in den Geräten (oder in FHEM...) könnten das evtl. aber aushebeln wie in dem Beispiel gezeigt wurde.

Aber selbst mit Kenntnis des Passworts wäre es ein ziemlicher Aufwand sich mit geeigneter Hardware als der eigentliche Controller im Netzwerk auszugeben und entsprechende Nachrichten zu verschicken. Die Haustüre einzutreten ist da viel einfacher...

Der eigentliche Controller würde ja die Anfragen für die NONCE des Gerätes auch beantworten und damit dann wahrscheinlich ein heilloses Durcheinander an CAN und NO_ACK Messages erzeugen... ,-)

Gruß,
Andreas.

P.S.: Bin wie zu erkennen ist wieder aus dem Urlaub zurück, so wie ich das sehe ist in der Zwischenzeit nicht sooo viel an Rückmeldungen bzgl. SECURITY aufgelaufen. Ich werde mir in den nächsten Tagen dann mal die letzten Änderungen am Code ansehen und dann mal schauen was noch zu tun ist.

[Ralli]

Hallo Andreas,

... das erinnert mich an Homematic. Sobald du das Initalpasswort bzw. den Initialschlüssel kennst, kannst du nur noch im pharadäischen Käfig sicher anlernen  .

[rudolfkoenig]

Nicht ganz.
Bei Homematic hat man (frueher?) das Default-Passwort verwendet, da ein selbstgewaehltes Passwort diverse und zum Teil schwerwiegende Probleme verursacht hat. Hier ist die Rede von der Verwendung eines Initialpasswortes nur waehrend des Anlernens, ein default Passwort gibt es mWn bei ZWave nicht. Homematic hat das Problem bei der Iniitalisierung zusaetzlich.

[A.Harrenberg]

Hi,

... das erinnert mich an Homematic. Sobald du das Initalpasswort bzw. den Initialschlüssel kennst, kannst du nur noch im pharadäischen Käfig sicher anlernen  .

das problem ist nun mal leider systembedingt wenn man ein Passwort über das gleiche Medium aushandelt auf der auch die Kommunikation stattfindet...
Immerhin wird das Passwort überhaupt schon mal verschlüsselt übermittelt und nicht im Klartext. Damit ist schon mal die Kenntnis des Initalpassworts nötig.

"Umgehen" liesse sich das nur mit Geräteindividuellen Initalpasswörtern, die z.B. auf jedem Gerät aufgedruckt wären und die man manuell für die Initiale Verschlüsselung des Netzwerkschlüssels verwenden würde. Dann müsste ein Angreifer Kenntnis über dieses individuelle Passwort haben um den Netzwerkschlüssel rekonstruieren zu können.

Bei der Inklusion mit Security wird ein "Security-Scheme" ausgehandelt, hier gibt es momentan nur ein einziges Scheme "00", wer weiß was in zukünftigen Versionen der Schemes implementiert wird.

Gruß,
Andreas.

[rudolfkoenig]

das problem ist nun mal leider systembedingt wenn man ein Passwort über das gleiche Medium aushandelt auf der auch die Kommunikation stattfindet...

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