ZME_KFOB_S / ZME_KFOB2

[rudolfkoenig]

Klappt die "Secure"-Einbindung bei euch noch?

Na geklappt hat es noch nie, aber es sollte keine Fehler produzieren, und bis nonceReport laufen.
Und auf irgendwelche timer wird noch gar nicht aufgepasst.

[A.Harrenberg]

Hi,

es läuft aber jetzt erst gar nicht mehr bis Nonce-Report, selbst Scheme-Get wird nicht mehr gesendet.

Irgendein Tip was jetzt wieder klemmt?

Gruß,
Andreas.

[rudolfkoenig]

Nein. Ich lass dir diesmal den Vortritt bei der Analyze

[krikan]

Dass Secure inclusion durch "addnode on sec" aufgerufen wird hast Du beachtet?

[A.Harrenberg]

Hi,

Dass Secure inclusion durch "addnode on sec" aufgerufen wird hast Du beachtet?

Nö... Seid wann das denn?
Sollte der Befehl im drop-down vom ZWDongle erscheinen? Ich habe da jedenfalls nichts...

Argh, klappt bei mir das svn update schon wieder nicht richtig?
00_ZWDongle.pm ist 8760
10_ZWave.pm ist 8749

Gruß,
Andreas.

[krikan]

Ist noch(?) nicht im DropdownMenu enthalten. Setze es über Eingabefeld ab. Ist seit Kurzem drin; war mein Wunsch.

[A.Harrenberg]

Hi,

ok, hab' den anderen Thread gefunden und es bereits über Kommandozeile abgesetzt. Hat jetzt auch wieder was mit Security beim Einbinden gemacht.

Vielen Dank für den Hinweis, hatte gerade angefangen mir ein Log-Messages in den Code zu setzen um zu sehen wo der "falsch abbiegt".

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

so habe mir jetzt noch mal das erste Logfile von Krikan mit OpenZwave und dem KFOB genauer angesehen und verstehe nicht wie das funktionieren kann...

Da wird entgegen der vorhandenen Doku mehrmals der Networkkey im Klartext übertragen, wird aber auch nicht irgendwie vom KFOB bestätigt. Laut Doku müsste der Networkkey verschlüsselt übertragen werden und mit einer ebenfalls verschlüsselten NetworkkeyVerify Message beantwortet werden, die ich aber im Log nicht finden kann.

Dann gibt es das Scheme Get/Report, Nonce Get/Report und dann gibt es eine verschlüsselte Antwort, bei der aber anscheinend die CBC-MAC Verschlüsselung nicht passt und es weggeworfen wird.

Trotzdem kann später verschlüsselt ein SupportedGet / SupportedReport gesendet bzw. empfangen werden.
Ein einziges Mysterium...

Ich werde mir übermorgen mal das andere Logfile mit der DSD31-Sirene ansehen und mal schauen was da so im Logfile zu finden ist.

Ich habe noch ein paar verstreute Infos bzg. der AES-Implementierung gefunden, anscheinend braucht man drei verschiedene Blockmodi:
ECB, CBCMAC und OFB. Außerdem braucht man zwei "Passwörter", ich hoffe das ich die in dem OpenZwave Code finde.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi, hallo Christian,

ich bräuchte mal wieder einen "Schubs" in die Richtige Richtung...

Ich verstehe zwar immer noch nicht wieso die Reihenfolge von OpenZWave funktioniert, wollte jetzt aber erst mal den gleichen Zustand herstellen. Habe mir daher mal das Log von Christian mit der Sirene angeschaut, die gleiche habe ich ja auch.

Vergleich der OpenZWave und FHEM Logs zeigt das bei "uns" momentan ein NonceGet/Report an der falschen Stelle ist und wir keinen NonceGet REQUEST vom Gerät erhalten:

[s=gesendet, r=empfangen]
OpenZWave:
01: s:SchemeGet / r:SchemeReport
02: s:NonceGet / r:NonceReport
03: s:NetworkkeySet
04: r:NonceGet / s:NonceReport
05: r: Encrypted Message
[einige unverschlüsselte Nachrichten]
06: s:NonceGet / r:NonceReport
07: s.SupportedGet
08: r:NonceGet / s:NonceReport
09: r: Encrypted Message

Fhem:
01: s:SchemeGet / r:SchemeReport
02: fehlt
03: s:NetworkkeySet
04: s:NonceGet / r:NonceReport

D.h. anscheinend gibt es ohne das NonceGet an Position 02 auch keine Rückanfragen bei 04.

Ich habe dann mal versucht das NonceGet in der Reihenfolge in ZWave_secureInit(@) zu ändern:

Code Auswählen Erweitern

  if($status == 1) {
    ZWave_Set($hash, $name, "secScheme");
    return ""; # not evaluated

  } elsif($status == 2) {
    ZWave_Set($hash, $name, "secNonce");
    return undef;       # No Event/Reading
  } elsif($status == 3) { 
    Log3 $iodev, 4, "secScheme report: $param";
    my $key = AttrVal($iodev->{NAME}, "networkKey", "");
    ZWave_Set($hash, $name, ("secKey", $key));
    return undef;       # No Event/Reading

  } elsif($status == 4) {
    IOWrite($hash, "secKey ACK", "");
    ZWave_Set($hash, $name, "secNonce");
    return undef;       # No Event/Reading

  } else {
    Log3 $iodev, 4, "secNonce report: $param";
    delete $iodev->{secInitName};
    delete $hash->{secStatus};
    return ZWave_execInits($hash, 0);
  }


Jetzt scheint aber die Reihenfolge der Befehle "durcheinander" zu geraten.

01: s:SchemeGet, r:SchemeReport
02: s:NonceGet
03: s:NetworkkeySet
04: r:NonceReport

D.h. der NetworkkeySet Befehl wird gesendet bevor die Antwort auf den NonceGet empfangen wurde. Die kommt dann zwar später, die Sirene sendet aber dann selbst keinen NonceGet Befehl mehr aus, ich habe sogar ein "Cancel" bekommen...
Ein gekürztes/kommentiertes Log habe ich angehängt.

Ich muss zugeben das ich das System nach dem die Nachrichten gesendet/empfangen werden nicht ansatzweise verstanden habe, daher habe ich jetzt auch keine Idee wie ich an einer Stelle gezielt auf eine Antwort warten kann bevor ich dann weitermache.

Wenn wir die "richtige" Reihenfolge hinbekommen würden müsste das Device im nächsten Schritt ja selbst noch mal nach der Nonce fragen und dann den Networkkey durch die verschlüsselte Nachricht (die ich noch nicht dekodieren kann...) bestätigen.

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

ich habe es nun doch hinbekommen die Befehle in der Reihenfolge:
01: s:SchemeGet / r:SchemeReport
02: s:NonceGet / r:NonceReport
03: s:NetworkkeySet

abzusetzen, allerdings passiert danach nichts, fhem macht mit Association, Manufacterspecific etc weiter.
Die SIrene fragt nicht mit NonceGet...

Hmm, wie geht das denn mit den Timern? Werden die vielleicht bei OpenZWave im Hintergrund verarbeitet und sind nicht im Logfile zu erkennen?

Jetzt bin ich erstmal wieder etwas ratlos warum sich da nicht das gleiche Verhalten ergibt...

Das von mir dabei benutzte 10_ZWave.pm habe ich mal angehängt, Logfile ebenfalls.

Gruß,
Andreas.

[rudolfkoenig]

Andreas, du erwartest zu viel von mir, und vmtl. auch von Christian.

Wir wissen nicht im Detail wie die abgesicherte Kommunikation zu funktionieren hat, das was implementiert ist, ist weit von Fertig. Der naechste Schritt ist die Ver- bzw. Entschlueselung der Daten mit AES zu implementieren. Da in dem Log alle Schluessel, verschluesselter Text und Klartext enthalten ist, kann man das ohne Hardware machen. Wenn man es kann, ich jedenfalls noch nicht auf Anhieb. Ich brauche keine Tester, sondern viel Zeit dafuer, oder Patches.

Timer sind im Moment egal, die sichern nur, dass nicht jemand trotz aktivierten Security Befehle einschleusen oder wiederholen kann. Soweit sind wir aber noch gar nicht.

[A.Harrenberg]

Hallo Rudi,

Andreas, du erwartest zu viel von mir, und vmtl. auch von Christian.

nicht das da Missverständnisse aufkommen, ich erwarte ja auch gar nichts fertiges, ich habe aber noch ziemliche Probleme den internen Ablauf in FHEM bei der Kommunikation mit dem ZWDongle zu verstehen. Das Problem mit der Reihenfolge der Befehle habe ich ja sogar doch noch selbst gelöst bekommen.

Wir wissen nicht im Detail wie die abgesicherte Kommunikation zu funktionieren hat, das was implementiert ist, ist weit von Fertig. Der naechste Schritt ist die Ver- bzw. Entschlueselung der Daten mit AES zu implementieren. Da in dem Log alle Schluessel, verschluesselter Text und Klartext enthalten ist, kann man das ohne Hardware machen. Wenn man es kann, ich jedenfalls noch nicht auf Anhieb. Ich brauche keine Tester, sondern viel Zeit dafuer, oder Patches.

Bis zu dem Zeitpunkt an dem die verschlüsselte Anfrage des "SupportedGet" erfolgt braucht man auf der Controller Seite ja anscheinend erst mal keine Verschlüsselung (zumindest nach den Logs von OpenZWave), daher dachte ich, es wäre schon mal gut so weit zu kommen dass das Device schon mal eine verschlüsselte Nachricht schickt, auch wenn wir die zur Zeit noch nicht entschlüsselen können. (Ich kann aber z.B. auch mit der entschlüsselten Antwort von OpenZWave nichts anfangen...)

Nur leider reagiert die Sirene trotz erst mal "richtigem" Ablauf nicht so wie sie es mit OpenZWave tut. ;-(

Ich werde mir dann wohl doch auch ein OpenZWave installieren und auch dort mal ein paar weitere Logzeilen erzeugen damit (für mich) klarer verständlich wird was da passiert. Momentan kann ich mir noch vorstellen das der NetworkkeySet bereits verschlüsselt gesendet wird, die Verschlüsselung aber nicht im Logfile angezeigt wird. Das würde dann auch wieder eher mit dem in der Doku beschriebenen Ablauf passen und würde dann erklären warum es keine verschlüsselte Bestätigung von der Sirene gibt.

Noch mal, ich erwarte nicht das Du das alles (alleine) machst, ganz im Gegenteil, Du machst hier schon mehr als man erwarten kann! Ich bin dabei mich einzuarbeiten und werde auch aktiv Patches schreiben wenn es denn Fortschritte gibt, nur leider fehlt mir (noch) das globale Verständnis wie fhem intern so arbeitet und der Einstieg ist da nun mal leider nicht soo leicht.

Was die AES Verschlüsselung angeht stehe ich da noch genauso auf dem Schlauch, habe aber inzwischen noch ein paar weitere Informationsfetzen im Internet finden können. Ich fürchte jedoch, dass es am effektivsten sein wird den OpenZWave Code zu analysieren und die Funktionen von dort nachzubilden.

Ich werde also mal OpenZWave installieren und mir den Code von dort mal genauer ansehen und dann versuchen die benötigten AES Funktionen dort zu extrahieren bzw. zu schauen ob die AES Implementation von Perl das nicht doch kann.

Sorry wenn die letzten Nachrichten "fordernd" rüberkamen, so war das wirklich nicht gemeint.

Gruß,
Andreas.

[krikan]

Hallo Andreas,
lese Deine Beiträge zwar mit, aber werde Dir mangels Kenntnissen nur wenig helfen können. Wenn es etwas zu testen gibt, bin ich dabei. Würde mich freuen, wenn Du am Thema dranbleibst  .
Gruß Christian

[A.Harrenberg]

Hi,

momentan bleibe ich ja meist bei allgemeinen Sachen hängen, da bin ich dann für jeden Tip dankbar.

Ich bleib' auf jeden Fall dran, auch wenn ich selbst Security momentan ja gar nicht brauche, ob die Sirene jetzt per SECURITY eingebunden ist macht für mich momentan keinen Unterschied. Ich brauchte damals den USER-CODE für den RFID-Leser, da habe ich von euch profitiert, da kann ich jetzt vielleicht auch noch was zum System beisteuern.

Sobald es wieder was gibt poste ich das hier, oder sollten wir vielleicht für SECURITY einen eigenen, neuen Thread aufmachen?
@Rudi, was sagst Du?

Ich bin aber ab Mitte nächster Woche auch erst einmal für 2.5 Wochen in Urlaub...

Gruß,
Andreas.

[rudolfkoenig]

Ich habe kein Problem mit einem eigenen Thread.