assignHmKey funktioniert nicht (bzw. falscher hmKey wird gesetzt)

[Samsi]

Hallo,

ich habe einen neuen Handsender HM-RC-Key4-2 und wollte ihm den hmKey3 mit "set  xxx assignHmKey" übertragen.

ich habe insgesamt 3 hmKeys definiert:

hmkey 01:....
hmkey2 02:....
hmkey3 03:....


Das assignHmKey klappt aber leider nicht. Am Ende bleibt immer "1 CMDs pending" stehen, egal wie oft ich den Config Button am handsender drücke. Wenn ich dann z.B. regset sign on ausführe, dann bekomme ich ein MISSING_ACK und das CMD Pending veschwindet.

aesKeyNbr bleibt auch auf 00 statt wie erwartet auf 06.

Vielleicht hat jemand eine Idee?

EDIT:
Was mir auch nicht so klar ist, um den Key zu ändern, müsste er ja den alten Key 00 wissen (bei einem neuen Device der default key) muss ich den irgendwo noch als hmKey 00 hinterlegen?

[Samsi]

Nachdem ich 1 Stunde vergeblich versucht habe ein Lösung zu finden kam mir gerade der Gedanke das Device noch mal zu pairen und dann hatte es auch mit dem assign geklappt.

Grüße

[Samsi]

Nun ja, scheint so als wäre ich doch noch nicht so ganz durch.
Wie schon geschrieben habe ich 3 keys:

hmkey 01:....
hmkey2 02:....
hmkey3 03:....

Und laut commandref überträgt assignHmKey angeblich den letzten key, doch leider steht bei mir aesKeyNbr auf 02 (also hmKey), korrekt wäre aber 06 (hmKey3).

Deshalb funktioniert die Kommunikation zwischen dem Sender und der Keymatic nicht, denn dort ist aesKeyNbr auf 06.

Ein erneutes assignHmKey hat nun aber nicht geholfen.

[mgernoth]

Hallo Samsi,

Und laut commandref überträgt assignHmKey angeblich den letzten key, doch leider steht bei mir aesKeyNbr auf 02 (also hmKey), korrekt wäre aber 06 (hmKey3).

Den letzten Key überträgt es zumindest bei einem CUL. Was HMLAN/-USB da intern genau machen, weiss ich nicht, dem Befehl an das IO wird in diesem Fall nur der alte Keyindex mitgegeben, nicht der neue. Probier einfach noch 2 mal assignHmKey aus, mit einer Aktion dazwischen welche aesKeyNbr aktualisiert.

Ein erneutes assignHmKey hat nun aber nicht geholfen.

Hmm, stand zu dem Zeitpunkt aesKeyNbr auf 02?

Gruß
  Michael

[Samsi]

Hi,

also aesKeyNbr von dem neuen Device steht auf 02, auch ein neues assignHmKey ändert daran nichts.Ich habe es jetzt zig mal mit assignHmKey probiert und dazwischen auch immer mal das regset sign on/off gewechselt (um aesKeyNr zu aktualisieren). Es bleibt bei aesKeyNr 02. Nach Drücken der Anlerntaste werden auch immer schon alle Befehle abgearbeitet und die Readings sind auch alle aktualisiert:

protState CMDs_done
CommandAccepted  yes
aesCommToDev ok

Der HM-RC-Key4-2 blinkt beim Drücken der Anlerntaste kurz grün, dann mehrmals schnell rot während der Übertragung (set assignHmKey) und am Ende kurz wieder grün.  Ich denke das ist normal so.

Alle anderen Devices (welchen ich früher den Key mit der Windows Software verteilt habe) und die CCU zeigen auch key 06.

Grüße

[mgernoth]

Hi,

also aesKeyNbr von dem neuen Device steht auf 02, auch ein neues assignHmKey ändert daran nichts.Ich habe es jetzt zig mal mit assignHmKey probiert und dazwischen auch immer mal das regset sign on/off gewechselt (um aesKeyNr zu aktualisieren). Es bleibt bei aesKeyNr 02.

Ok, konnte das hier per Hand nachstellen.
Es scheint, als ob die Reihenfolge der Keydefinition eine Rolle spielt. Der neueste Schlüssel (mit dem höchsten Index) muss als erstes definiert werden, da dies der Zielschlüssel des Schlüsselaustauschs ist.

Code Auswählen Erweitern


attr vccu hmkey 03:3333...
attr vccu hmkey2 02:2222...
attr vccu hmkey3 01:1111...


Hier mein manueller Test in hmland -i getippt:

Code Auswählen Erweitern


AAAAAAA
Y01,03,33333333333333333333333333333333
Y02,02,22222222222222222222222222222222
Y03,01,11111111111111111111111111111111

S12345678,00,00000000,01,12345678,01A004AAAAAABBBBBB0100
-> sendet 19 01 A0 04 AAAAAA BBBBBB 01063333333333333333F6607E296FA5(d) (AESkey kNo: 3, first part, oldKey: default)

S12345678,00,00000000,01,12345678,02A004AAAAAABBBBBB0101
-> sendet 19 02 A0 04 AAAAAA BBBBBB 010733333333333333337C1D7E296FA5(d) (AESkey kNo: 3, key: 33333333333333333333333333333333, oldKey: default)

S12345678,00,00000000,01,12345678,03A004AAAAAABBBBBB0102
-> sendet 19 03 A0 04 AAAAAA BBBBBB 0106333333333333333355C37E296FA5(d) (AESkey kNo: 3, first part, oldKey: 11111111111111111111111111111111)

S12345678,00,00000000,01,12345678,04A004AAAAAABBBBBB0103
-> sendet 19 04 A0 04 AAAAAA BBBBBB 010733333333333333338CED7E296FA5(d) (AESkey kNo: 3, key: 33333333333333333333333333333333, oldKey: 11111111111111111111111111111111)

S12345678,00,00000000,01,12345678,05A004AAAAAABBBBBB0104
-> sendet 19 05 A0 04 AAAAAA BBBBBB 010633333333333333334BDD7E296FA5(d) (AESkey kNo: 3, first part, oldKey: 22222222222222222222222222222222)

S12345678,00,00000000,01,12345678,06A004AAAAAABBBBBB0105
-> sendet 19 06 A0 04 AAAAAA BBBBBB 0107333333333333333335547E296FA5(d) (AESkey kNo: 3, key: 33333333333333333333333333333333, oldKey: 22222222222222222222222222222222)


Der Teil vor dem (d) geht verschlüsselt durch die Luft.

Also einfach mal die hmKey-Attribute ändern und assignHmKey ausführen, dann sollte es tun.

Viele Grüße
  Michael

[Samsi]

Hi,

danke, das hat jetzt funktioniert.

Allerdings:
Erst nachdem ich die Reihenfolge auch bei der ccu geändert hatte, obwohl in dem Handsender HMLAN1 als IO device angegeben war und IOgroup leer war.

Offensichtlich wird immer die hmKey von der ccu genommen.


EDIT:
Das bedeutet, wenn ich jetzt den Key ändern möchte (was ich auch vorhabe, weil mein Passwort mit 9 Stellen aus dem der MD5 generiert wurde in ca. 400 Sekunden  gecrackt werden könnte laut https://blog.ploetzli.ch/2015/on-the-security-of-aes-in-homematic/ ) dann muss ich erst alle keys umkopieren und hmKey freimachen und dort den neuen Key reinschreiben. Das ist etwas umständlich. Vielleicht kann man doch dafür sorgen das der letzte hmKey4 benutzt wird?

[mgernoth]

Hi,

danke, das hat jetzt funktioniert.

Gut

Offensichtlich wird immer die hmKey von der ccu genommen.

Ja, VCCU wird zuerst durchsucht. Es reicht die Keys nur da zu definieren, ist sinnvoller um im ganzen System die gleichen Keys zu haben.

Das bedeutet, wenn ich jetzt den Key ändern möchte (was ich auch vorhabe, weil mein Passwort mit 9 Stellen aus dem der MD5 generiert wurde in ca. 400 Sekunden  gecrackt werden könnte laut https://blog.ploetzli.ch/2015/on-the-security-of-aes-in-homematic/ ) dann muss ich erst alle keys umkopieren und hmKey freimachen und dort den neuen Key reinschreiben.

Ja.

Das ist etwas umständlich. Vielleicht kann man doch dafür sorgen das der letzte hmKey4 benutzt wird?

Du kannst gerne den Code so ändern, dass das funktioniert.

Aber beachten: HMLAN/HMUSB unterstützen nur 3 Schlüssel gleichzeitig, ein hmKey4-Attribut gibt es nicht.

Viele Grüße
  Michael

[Samsi]

Aber beachten: HMLAN/HMUSB unterstützen nur 3 Schlüssel gleichzeitig, ein hmKey4-Attribut gibt es nicht.

Sicher? Ich dachte es gehen deutlich mehr:

http://forum.fhem.de/index.php/topic,31360.msg239612.html#msg239612

martinp876: wenn der key unter "14" betrieben wird solltest du es so eintragen.

[mgernoth]

Hi,

Sicher?

Ja.

Ich dachte es gehen deutlich mehr:

Nein. Mehr als 3 führen zu einem Crash des IOs, da dann anderer Speicher überschreiben wird. Es gibt kein Attribut hmKey4, schau nach.

Viele Grüße
  Michael

[mgernoth]

Hallo,

so, ich habe mal den Code so umgebaut, dass die hmKeys (hoffentlich) sortiert werden. Bitte den Patch im Anhang mal ausprobieren.

Viele Grüße
  Michael

[martinp876]

da wird nur die reihenfolge beim schreiben geändert? braucht man das?

[mgernoth]

Hallo Martin,

da wird nur die reihenfolge beim schreiben geändert? braucht man das?

Ja, der HMLAN scheint bei einem assignHmKey als neuen Schlüssel immer den in Slot 01 definierten zu nehmen, daher sollte in diesem Slot der Schlüssel mit dem der höchsten Version abgelegt werden. Das macht der Patch.

Viele Grüße
  Michael

[Samsi]

Hi,

ich fasse das mal zusammen ob ich das alles richtig verstanden habe.

Nehmen wir an meine Keys sind so definiert:

hmKey = 01:A
hmKey1 =02:B
hmKey2 = 03:C

Jetzt will ich einen neuen Key angeben. Mehr las drei kann ich nicht definieren, also mache ich folgendes:


den 3. Key kann ich nicht nehmen, der wird ja zur zeit verwendet, also überschreibe ich eine der ersten beiden:

hmKey = 01:A
hmKey1 =04:D
hmKey2 = 03:C

Und Deine Codeänderung sortiert die dann intern um das es dann so aussieht

hmKey = 04:D
hmKey1 = 03:C
hmKey2 = 01:A

So weit so gut. Aber wie weit gehen denn die Key-Indizes eigentlich? bis 05 oder 10 und was passiert dann wenn man mal am Ende angelangt ist?

Wenn jetzt z.B. 05 der höchste Index ist:

hmKey = 03:C
hmKey1 = 04:D
hmKey2 = 05:E

Jetzt müsste ich ja wieder von vorne anfangen und 01 mit dem neuen Schlüssel setzen. Da aber der höchste 05 immer auf hmKey sortiert wird, wird das dann nicht mehr funktionieren.

Viele Grüße

[mgernoth]

Hi,

Nehmen wir an meine Keys sind so definiert:

hmKey = 01:A
hmKey1 =02:B
hmKey2 = 03:C

Jetzt will ich einen neuen Key angeben. Mehr las drei kann ich nicht definieren, also mache ich folgendes:

den 3. Key kann ich nicht nehmen, der wird ja zur zeit verwendet, also überschreibe ich eine der ersten beiden:

hmKey = 01:A
hmKey1 =04:D
hmKey2 = 03:C

Und Deine Codeänderung sortiert die dann intern um das es dann so aussieht

hmKey = 04:D
hmKey1 = 03:C
hmKey2 = 01:A

So weit so gut.

Ja, genau.

Aber wie weit gehen denn die Key-Indizes eigentlich? bis 05 oder 10 und was passiert dann wenn man mal am Ende angelangt ist?

Das kann wohl nur eQ3 beantworten...
Im Homegear Sourcecode taucht 253 als Grenze auf, das kann aber nicht sein, da der doppelte Wert in ein Byte passen muss. Evtl. ist es 126, also 7E.

Jetzt müsste ich ja wieder von vorne anfangen und 01 mit dem neuen Schlüssel setzen. Da aber der höchste 05 immer auf hmKey sortiert wird, wird das dann nicht mehr funktionieren.

Ich würde erwarten, dass die Geräte kein "downgrade" akzeptieren, getestet habe ich es aber nicht.

Gruß
  Michael