HMLAN mit eigenem AES Signierungsschlüssel

Samsi · 25 September 2013, 13:16:23

Hallo,

mir ist heute zum 2. mal aufgefallen, das ich meine Keymatic nicht mehr mit FHEM und HMLAN steuern lies. Dem bin ich auf den Grund gegangen. Also habe ich kurz den HMLAN mit der Windows Software verbunden und dann wieder mit FHEM. Danach ging das steuern wieder mit FHEM. Ich habe dann den HMLAN Stromlos gemacht und danach ging es wieder nicht und ich musste ihn erneut mit der Windows Software verbinden.

Da ich alles andere noch steuern konnte (Licht etc.) gehe ich davon aus, das es das es an meinem eigenen AES Signierung-Schlüssel liegt. SChienbar wird der Schlüssel nicht dauerhaft im HMLAN gespeichert und wenn der HMLAN Stromlos wird, müsste FHEM den Schlüssel neu setzen.

Gibt es dafür ein Atrtibbut, so ähnlich wie man die HMID setzt, in der CommandRef habe ich nichts gefunden:

attr HMLAN1 hmId AACCEE

Oder liegt es doch an etwas anderem, das es nach einem Stromausfall nicht mehr geht?

martinp876 · 25 September 2013, 14:44:47

hallo samsi,

kann ich dir leider nicht sagen. AES nutze ich nicht. ich denke aber dass es doch einige nutzen. Und die werden wohl nicht immer die windows-SW zwischenschalten.
Demnach müsste es etwas anderes sein...

wenn du bereit bist, die init-sequenz des HLMAN mit der PC-SW zu loggen kann ich es durchsehen. Gerne auch per pm

Gruss Martin

Samsi · 25 September 2013, 15:44:01

Hallo,

habe es gerade mal mit Wireshark mitgeschnitten. Das Passwort wird tatsächlich bei der Initialisierung übertragen, und zwar so, wie es in der keys Datei im Ordner BidcosService von der Windows software abgespeichert wurde. Ist vermutlich nur ein Hash des eigentlichen Passworts.

Ich hab das Passwort aber in der Datei die ich dir schicke mal ersetzt.

Anstelle von ABCDEF12345678901234567890123456 steht dort mein richtiges Passwort.

Grüße

EDIT: Habe gerade mal geschaut das was in der Keys gespeichert wird und an den HMLAN übertragen wird ist ein MD5 Hash des originalen Passwortes.

mgernoth · 25 September 2013, 16:40:47

Hallo,

als ich versucht habe die AES-Kommunikation zu reverse-engineeren, habe ich mir folgendes notiert:

Code Auswählen


Setting a key (Position 0x01, Index 0x10):
< Y01,10,00112233445566778899AABBCCDDEEFF
> I00,10,00,00

Deleting a key (Position 0x01):
< Y01,00
> I00,00,00,00

Getting key index:
< Y
> I00,00,00,00

Die 0x10 ist der Schlüsselindex (wird genutzt um Geräte mit verschiedenen Schlüsseln erreichen zu können und z.B. einen Key-Exchange durchzuführen). Die Geräte kennen den Index "ihres" Schlüssels. Die Windows-Software kann mehrere Keys mit jeweiligem Index in der keys-Datei abspeichern. Index 0x00 ist der HM-Defaultschlüssel.

Wenn ich 00_HMLAN.pm richtig lese, wird ein als Attribut hmKey am HMLAN abgelegter Schlüssel bei der Initialisierung mit Key-Index 01 an den HMLAN übertragen. Evtl. wäre es hier praktisch, den Key-Index auch noch in einem Attribut zu speichern.

Gruß
Michael

Samsi · 25 September 2013, 16:56:56

Hallo,

ich habe auch mehrere Keys in der Bidcos Keys DAtei, insgesamt 3 stück und 2 davon tauchen auf:

Y02,02,ABCDEF12345678901234567890123456 (Key 2)
Y01,03,ABCDEF12345678901234567890123456 (Key 3 bzw. Current Key)

Den ersten Key (also den HM-DEfaultkey) habe ich aber nicht im Mitschnitt gefunden.

martinp876 · 25 September 2013, 22:25:20

hi,

somit ist Y01, Y02... eine Speicher für keys

aktuell werden sie in fhem immer zu null gesetzt

HMLAN_Send: LANIf1 I:C
HMLAN_Send: LANIf1 I:Y01,01,
HMLAN_Send: LANIf1 I:Y02,00,
HMLAN_Send: LANIf1 I:Y03,00,
HMLAN_Send: LANIf1 I:Y03,00,

Es ist kein Problem, diese Werte zu senden. Michael, du weisst, wie man ihn generiert? Es ist wohl immer ein 16 byte wert, ascii-hex übertragen.
wir können das in einem Attribut speichern, oder besser den Wert eingeben und dann kodiert speichern.
Wenn du die codierungsvorschrift schickst, kann ich es probieren

Danke Martin

ps:
nachtrag - es gibt ja noch das attribut "hmkey" - trage deinen key einfach einmal dort ein.
Falls mehr keys benötigt werden können wir dies erweitern

Gruss Martin

mgernoth · 26 September 2013, 18:45:13

Hallo Martin,

Zitat von: martinp876 schrieb am Mi, 25 September 2013 22:25somit ist Y01, Y02... eine Speicher für keys

Ja, genau.

Zitataktuell werden sie in fhem immer zu null gesetzt

Nicht ganz:

ZitatHMLAN_Send: LANIf1 I:Y01,01,

Das setzen eines leeren Keys an einem anderen Index als 00 ist ungültig, damit wird der Key in Slot 01 nicht angefasst (und der von Windows gesetzte Key auch nicht überschrieben).

ZitatHMLAN_Send: LANIf1 I:Y02,00,
HMLAN_Send: LANIf1 I:Y03,00,
HMLAN_Send: LANIf1 I:Y03,00,

Die Keys in den anderen Slots werden aber hiermit in der Initialisierungsphase gelöscht.

ZitatEs ist kein Problem, diese Werte zu senden. Michael, du weisst, wie man ihn generiert? Es ist wohl immer ein 16 byte wert, ascii-hex übertragen.

Ja, das ist wie Samsi sagte der MD5-Hash (128bit) des in die Windows-Software eingegebenen Passworts.

Zitatwir können das in einem Attribut speichern, oder besser den Wert eingeben und dann kodiert speichern.
Wenn du die codierungsvorschrift schickst, kann ich es probieren

Code Auswählen


use Digest::MD5 qw(md5);

my $key = unpack('H*', md5($passwort));

Zitatnachtrag - es gibt ja noch das attribut "hmkey" - trage deinen key einfach einmal dort ein.
Falls mehr keys benötigt werden können wir dies erweitern

Ja, das nimmt aber immer Keyindex 1. Da die Geräte ihren Keyindex kennen, wird die Kommunikation nur funktionieren, wenn der richtige Key mit dem richtigen Index gespeichert ist (Bei Samsi ist es beispielsweise 3). Also sollte der Index auch noch in ein Attribut.

Gruß
Michael

Samsi · 26 September 2013, 19:03:22

Hallo Michael,

ich fände es gut, wenn man in der FHEM.cfg nur den Hash speichert,den kann sich ja jeder aus der Windows Software raus kopieren, dann hat er auch gleich den richtigen Index. Es gibt ja immer noch leute, die nehmen für alles das gleiche Passwort, es sollte deshalb nicht im Klartext in der Config stehen.

martinp876 · 26 September 2013, 19:26:56

Hallo Michael
ok, baue ich einmal ein. Danke

@Samsi,
stimme ich absolut zu. Die Eingabe kann man im klartext machen stelle ich mir vor. oder eben auch also hash

Gruss Martin

martinp876 · 26 September 2013, 23:02:19

ist eingebaut.

du hast 3 keys. Bei der Eingabe wird, wenn er nicht encrypted ist die encryption gestartet.
Sollte ein key vorliegen, also er aussehen wie ein key, wird er nicht konvertiert sondern so genommen. Das erlaubt auch das speichern der des coded keys in fhem.cfg.

siehe Version 3965,teste doch einmal

hast du eine Idee, wozu die 3 gebraucht werden? könnte man in der Beschreibung aufnehmen

Ach ja, das setzen des Attibutes bringt eine rückmeldung. geht nicht anders, da ich sonst den Inhalt nicht modifizieren kann.

Gruss Martin

Samsi · 27 September 2013, 14:39:05

Hallo Martin,

ich denke nicht das es nur 3 sind, denn jedes mal wenn ich den key in der Windows Software ändere, kommt ein neuer Eintrag dazu. Ich denke die werden gebraucht, da es ja manche Geräte gibt, bei denen man die Anlerntaste drücken muss, erst dann kann er den neuen Key updaten.
Wenn jetzt ein User das nicht weiss (und das wird vermutlich vielen Usern am Anfang so gehen) und mehrmals den Schlüssel ändert, hat er plötzlich 10 Geräte mit 5 verschiedenen Keys.

Geht jetzt ein Gerät in den Anlernmodus, nachdem der User den Schlüssel schon zum 5. mal geändert hat und gibt an das er eine Signierung mit key 01 erwarted, dann kann der Adapter das entsprechend auch durchführen. Außerdem ist das System so auch dann noch funktionsfähig falls auf einigen Aktoren der Key nicht geändert werden konnte, wenn der Aktor mitteilt, mit welchem Key er die Signierung erwartet.

Ist allerdings nur eine Vermutung, aber ich denke so müsste es ein, sonst würde nach einem Schlüsselwechsel absolutes Chaos herrschen und der HMLAN müsste erst mal alle Keys die er kennt durchprobieren und zurück funken bis er den richtigen hat.

Viele Grüße

martinp876 · 27 September 2013, 17:43:30

Hi,

kann ich mir nicht vorstellen, dass HM keys "durchprobiert". HMLAN kennt wohl auch keine Tabelle einer Zuordnung... oder, wo ich es gerade so schreibe, evtl doch.
Ich muss jedes Device im HMLAN bekanntgeben - da sind auch werte dabei, die ich nicht kenne. Könnte sein, dass dabei auch die Nummer des keys ist.
FHEM müsste dann die Zuordnung verwalten.

Das der Grund ein verzögertes Anlernen des keys ist kann ich mir doch nicht vorstellen.

Immerhin muss man sicherstellen, dass die Sensoren und die Aktoren auch miteinander können. Also ist eigentlich nur ein Key systemweit sinnvoll.

Unterm Strich ist es unklar.

Funktioniert es bei dir, wie es jetzt eingebaut ist?

Gruss Martin

Samsi · 27 September 2013, 22:36:08

Hallo Martin

Zitatkann ich mir nicht vorstellen, dass HM keys "durchprobiert"

Eben,ich auch nicht (ich meinte nur wenn er die keys nicht indizieren würde, müsste er alle durchprobieren). Deshalb gibt die Software vermutlich dem HMLAN immer die komplette INDZIERTE Liste mit allen Schlüssel. Wenn dann irgend ein Gerät eine Signierung am HMLAN anfordert braucht es nur noch seinen Keyindex mitzusenden und HMLAN weis sofort mit welchem Key es die Antwort erstellen muss.

ZitatAlso ist eigentlich nur ein Key Systemweit sinnvoll.

Richtig. Aber als ich meinen Key das erste mal geändert hatte, stand ich genau vor dem Problem, das die Keymatic sofort den neuen Key übernommen hatte, die angelernten Handsender aber nicht. Damit HMLAN aber den Key später bei den Handsendern ändern kann muss es ja auch den vorherigen Key kennen, denn ohne den alten key kann es ja nicht mit dem Handsender kommunizieren um den neuen Key zu speichern. Da HMLAN aber nicht genau weiss ob wirklich bei allen Geräten der Key geändert wurde, müssen folglich alle bisherigen Keys im HMLAN gespeichert werden.

Ich denke das es bei mir mit 3 Key ausreichen wird. Wenn aber jemand schon 5 mal den Schlüssel geändert hat und der aktuelle Schlüssel index 5 hat, das er dann auch 5 keys übertragen müsste, oder zumindest so das man den index für einen key, nämlich den aktuellsten, frei wählen kann.

Wenn Du mir sagt was ich in die fhem.cfg eingeben muss, teste ich es mal.

Ich werd jetzt erst mal updaten und hoffen das danach noch alles wie vorher läuft ;)

Samsi · 27 September 2013, 23:39:26

Hallo Martin,

ich habe es eben getestet, funktioniert einwandfrei. Wenn ich den key3 mit dem Schlüssel setze geht meine Keymatic. Setze ich den falschen key geht sie erwartungsgemäß nicht mehr.

Setze ich den aktuellen Schlüssel an hmkey2, geht Sie auch nicht. Wenn also jemand schon bei index 5 ist, wird er den richtigen key nicht setzen können.

Beim speichern der fhem.cfg kommt Error: hmKey3 set to (und dann Mein Key) funktionert aber trotzdem.

Allerdings wenn ich den HMLAN kurz vom Strom nehme wird der Key nicht neu übertragen. Ich muss dann die fhem.cfg einfach noch mal speichern, damit es geht.

Ich sage auf jeden Fall schon mal Danke ;)

martinp876 · 28 September 2013, 08:38:01

hi samsi,

das mit dem HMLAN init werde ich nachreichen - mein Fehler.

den Fehler beim Speichern kann ich nicht reproduzieren.

Die Liste der keys zu verlängern bedeuted, das format zu aendern - ich kann ja keine Parameter 1-99 vorsehen. Man könnte den key dann eingeben mit nummer,trennzeichen,key. also
1:key.

somit konnte man einige keys zulassen, aber die nummer des keys wählbar machen. Vor dem einbau hätte ich gerne stabilere infos...

unklar ist auch das format. bisher kenne ich
Y01,00
Y02,00
Y03,00

wobei die 00 die nummer des schlüssels sein KÖNNTE. oder die Y01. auch unklar.

Gruss Martin