HMLAN mit eigenem AES Signierungsschlüssel

[mgernoth]

Hi Martin,

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.

Ja, das ist eine gute Idee.

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.

Ja 00 ist die Nummer des (in diesem Fall HomeMatic Default-)Schlüssels.

Das Format ist:
YSlot,Index,Key

Der Slot ist der HMLAN interne Speicherplatz, der Index ist die "Version" des Schlüssels, wobei 00 (ein evtl. folgender Schlüssel wird ignoriert) wieder den HomeMatic Defaultschlüssel setzt.

Die Geräte geben den Schlüsselindex in einem Signing-Request mit an, damit weiss der HMLAN welchen Schlüssel er verwenden muss (und merkt sich dann wahrscheinlich den Key-Index zum jeweiligen Gerät).
Ich hatte damals noch mehr rausgefunden (u.a. auch den Schlüsselaustausch entschlüsseln können), aber anscheinend die Sniffs nicht aufgehoben. Was ich nicht rausbekommen habe, war was genau bei einer Signing-Response verschlüsselt wurde.

Gruß
  Michael

[Samsi]

Hallo Martin,,

den Fehler beim Speichern kann ich nicht reproduzieren.

Der Fehler kommt nur wenn ich bei edit files auf fhem.cfg speichern klicke.

Wenn ich das Attribut übers Web Interface setze kommt der fehler nicht.

Vielleicht weil ich nur den 2. und 3. Key setze, den ersten aber nicht?

[martinp876]

Hi Michael,

aufgenommen habe ich es auch einmal - aber so weit war ich lange nicht.

dann werde ich
hmKey <key>
hmKey2 <key>
hmKey3 <key>

erlauben und alternativ
hmKey no1:<key>
hmKey2 no2:<key>
hmKey3 no3:<key>

in beliebigen Mischungen der formate.

Zu beachten ist, dass devices beim HMLAN angemeldet werden. dabei werden weitere Datenfelder übertragen - die kann ich nicht dekodieren. Ich denke nicht, dass der HMLAN die zuordnung Key zu Device speichert - temporär schon, aber nicht non-volatil. das muss, genau wie den key, die Zentral senden. Wie weiss ich aber nicht.

Gruss Martin

[mgernoth]

Hi Martin,

Zu beachten ist, dass devices beim HMLAN angemeldet werden. dabei werden weitere Datenfelder übertragen - die kann ich nicht dekodieren. Ich denke nicht, dass der HMLAN die zuordnung Key zu Device speichert - temporär schon, aber nicht non-volatil. das muss, genau wie den key, die Zentral senden. Wie weiss ich aber nicht.

Ja, temporär lernen meinte ich. Es ist gut möglich, dass die Zuordnung in den Datenfeldern drin stand, dummerweise hab ich den Sniff nicht mehr...
Das ist aber nicht so dramatisch, weil das letzte Byte der Challenge eines Geräts den vom Gerät benutzten Key-Index angibt, und so kann der HMLAN dann aus der Kommunikation (volatile) lernen, welches Gerät welchen Key gesetzt hat.

Gruß
  Michael

[martinp876]

SW ist abgegeben...

[gandy]

Hi Martin,

mit der aktuellen Version (00_HMLAN.pm 3968) habe ich folgende Situation bei 15 HM-LC-Bl1PBU-FM:

• 9 ohne AES sign, funktionieren fehlerfrei
• 1 mit AES, funktioniert fehlerfrei
• 5 mit AES, liefern durchgängig AESreject und fahren nicht

Wenn ich mir die Log-Einträge ansehe mit "stat:0030 d:??", sehe ich folgendes Muster für "d:??":

Code Auswählen Erweitern


d:04 1AB518 RolloSchalter02
d:04 1AF52B RolloSchalter04
d:04 1AF995 RolloSchalter07
d:04 1B711B RolloSchalter05
d:00 1B82AA RolloSchalter03
d:04 20BCB3 RolloSchalter10


Nun ist RolloSchalter03 genau derjenige der mit AES problemlos funktioniert (d:00), während die mit d:04 allesamt nicht funktionieren. Ist die Zahl hinter d: der Schlüsselindex? In der bidcos keys datei habe ich tatsächlich 4 Schlüssel stehen; warum der eine dann aber ausgerechnet Index 0 verwenden sollte ist mir unklar.

Anbei das Log vom Versuch, RolloSchalter01..11 auf 100% zu fahren (fhem-2013-09-30.log-1) - Danach habe ich die Schalter mit AES-Problem manuell gefahren (fhem-2013-09-30.log-2)

Bin sehr bereit, weitere Tests zu fahren

Viele Grüße,
Andy.

[martinp876]

Hi Andy,

guter Hinweis, kann ich aber nicht beantworten.
das D: kommt ja vom device - und nach meinen Beobachtungen immer mit der AES message. Könnte also die Nummer des codes sein, der genutzt werden soll.

du kannst testhalber dein key4 setzen - auf einen freien platz im hmKey -also
attr <hmlan> hmkey2 4:<mykey>

Gruss Martin

[gandy]

Hi Martin,

hatte ich versucht, verlief aber etwa so:

Code Auswählen Erweitern


attr HMLAN1 hmKey2 4:.....
illegal number:4


Edit: Hab nochmal kurz 00_HMLAN.pm angesehen, da wird auf Länge==2 getestet, werde also heut abend nochmal mit der richtigen Syntax versuchen (gut, ich hätte auch gleich nachsehen können bevor ich rummeckere ;-) ):

Code Auswählen Erweitern


attr HMLAN1 hmKey2 04:.....



Gibt es einen Grund für die Beschränkung auf 3 Keys? Siehst Du eine Möglichkeit direkt die keys Datei einzulesen und alle darin befindlichen Keys zu verwenden? Hat sicher keinen Sinn, beliebig viele durchnummerierte hmKey Attribute vorzusehen...

Interessanterweise sind in meiner keys-Datei die ersten drei Schlüssel-codes identisch, erst der vierte (und aktuell genutzte) ist anders. Wohl ein kleiner trial-error-Unfall meiner ersten Zeit mit HomeMatic...

Grüße,
Andy.

[martinp876]

Hallo Andy,

ich habe bisher keine werte grösser Y03 gesehen.

was steht in deiner key-datei? Kannst du diese posten - gerne auch die keys aus-x-en

man müsste dann ein Attribut mit den Dateinamen vergeben... mal sehen.

Gruss Martin

[gandy]

Hi Martin,

hier meine anonymisierte keys Datei. Beachte, Keys 1,2 und 3 sind identisch; Key 4 ist der zuletzt Eingegebene und Aktive:

Code Auswählen Erweitern


Current Index = 4
Key 1 = 00112233445566778899AABBCCDDEEFF
Key 2 = 00112233445566778899AABBCCDDEEFF
Key 3 = 00112233445566778899AABBCCDDEEFF
Key 4 = FFEEDDCCBBAA99887766554433221100
Last Index = 3



Nachdem ich nun

Code Auswählen Erweitern

attr HMLAN1 hmKey2 04:FFEEDDCCBBAA99887766554433221100eingegeben hatte, funktionierte alles perfekt, auch wenn ich nach wie vor Log-Einträge mit AESreject bekomme.

Vielleicht handelt es sich bei "stat:0030" doch nicht so sehr um einen Fehlercode als den Hinweis, dass eine Signierung angefragt wurde? Zum Vergleich zur Situation heute Morgen nochmal ein Log mit funktionierendem KeyId-4 in fhem-2013-09-30.log-3

Beste Grüße und nochmal vielen Dank für Deinen unermüdlichen Einsatz!
Andy.

[martinp876]

Hallo Andy,

da hast du also sicher recht.
das bringt folgende dinge ans Licht:
d:xx ist die Nummer des AES-keys mit dem das Device arbeitet.
mit '0100' zeigt HMLAN an, dass eine AES message empfangen wurde
mit '0030' wird angezeigt, dass die message beantwortet wurde
was gesendet wurde kann man nicht sehen, ist aehnlich den ACKs, die HMLAN sendet.

Anhand deiner Daten möchte ich aktuell das einlesen einer Datei nicht implementieren - vielleicht später. immerhin muss man es parsen... duplikate entfernen.
ich kann mir vorstellen, dass es nicht mehr als 3 mögliche Einträge gibt. Das sollte machbar sein.
was ich einbauen werde ist ein Reading, welchen AES-key das device gerne hätte (also nur die Nummer, klar).
das Reading könnte "AESkeyNbr" heissen.


Gruss Martin

[gandy]

Hallo Martin,

nachdem nun alles sehr lange sehr gut funktionierte, bin ich auf etwas neues gestoßen: Für ein paar weitere Komponenten, die zu weit von meinem HMLAN entfernt ist, habe ich mir einen weiteren HMLAN zugelegt. Den und die daran gepairten Komponenten will ich allerdings ganz ohne AES betreiben (insbesondere auch ohne eigene AES Keys). Nachdem ich nun den HMLAN2 in FHEM eingebunden hatte, lief zunächst noch alles gut, bis plötzlich die RolloSchalter am HMLAN1 (mit eigenen Keys) nicht mehr steuerbar waren. Beheben konnte ich das erst, nachdem ich die Key-Attribute von HMLAN1 auch in HMLAN2 gesetzt hatte.

Deshalb meine Frage: Werden die Keys pro HMLAN Instanz verwaltet oder werden die Keys für alle Instanzen gleichermassen verwendet? Spielt die Reihenfolge der defines eine Rolle?

Im Moment funktioniert mit dem Workaround wieder alles, will nur verstehen wie's gedacht ist

Beste Grüße,
Andy.

[martinp876]

Hallo Andy,

die keys sollten/müssen je HMLAN definiert werden.
Wenn du mit 2 HMLAN arbeitest - wie sind die aufgesetzt? Folgendes musst du entscheiden:
a) HMLAN1 und 2 sollten unterschiedliche HMIds haben
b) du solltest das Attribut IODev bei jedem HM-Device setzen. Automatische Zuordnung macht hier keinen Sinn.

Ist das so? Welches IODev wurde bei dem fraglichen Rollo angezeigt?

Gruss Maritn

[gandy]

Danke Martin für den Hinweis, ich hatte tatsächlich fälschlicherweise angenommen, dass die FHEM-Entity des neu angelernten Device "weiss" welches sein IOdev sein sollte. Könnte diese Information nicht als Default aus der Information aus dem HM-Device abgeleitet werden?

Jedenfalls waren die IODev schnell für alle HM-Devices manuell gesetzt, nun funktioniert alles perfekt.

Eine andere Sache ist mir noch aufgefallen: Bei allen meinen HM-Devices steht das Reading aesKeyNbr auf "FF". Ich hatte Dich seinerzeit so verstanden, dass hier der key-index zu finden sein soll.

In den Logeinträgen habe ich gesehen, dass bei verschiedenen stat:xxxx auch unterschiedliche d:yy zu sehen sind. Hier eine Tabelle, für welche stat-Werte welche d-Werte bei den einzelnen Entities zu sehen sind:

stat	0000	0001	0021	0030	0040	0041	0050	0100	0201
BewegungsmelderEingang	d:FF	d:FF	----	----	----	----	----	----	d:FF
DisplayKeller	d:FF	d:FF	----	----	----	----	----	----	----
FensterSensor01	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor02	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor03	d:FF	----	----	----	d:01	----	d:01	d:FF	----
FensterSensor04	d:FF	----	----	----	d:01	----	d:01	d:FF	----
FensterSensor05	d:FF	----	----	----	----	----	----	----	----
FensterSensor06	d:FF	----	----	----	----	----	----	----	----
FensterSensor07	d:FF	----	----	----	d:01	----	d:01	d:FF	----
FensterSensor08	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor09	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor10	d:FF	----	----	----	----	----	----	----	----
FensterSensor11	d:FF	----	----	----	----	----	----	----	----
FensterSensor12	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor13	d:FF	----	----	----	----	----	----	----	----
FensterSensor14	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor15	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor16	d:FF	----	----	----	----	----	----	----	----
FensterSensor17	d:FF	----	----	----	d:01	----	----	d:FF	----
FensterSensor18	d:FF	----	----	----	----	----	----	----	----
FensterSensorKeller	d:FF	d:FF	----	----	d:01	d:01	----	d:FF	----
LichtDimmer01_dev	d:FF	d:FF	----	----	----	----	----	----	----
RolloSchalter01	d:FF	d:FF	d:00	d:04 d:00	----	----	----	d:FF	----
RolloSchalter02	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter03	d:FF	d:FF	d:00	d:00	----	----	----	d:FF	----
RolloSchalter04	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter05	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter06	d:FF	d:FF	d:00	d:00	----	----	----	d:FF	----
RolloSchalter07	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter08	d:FF	d:FF	d:00	d:00	----	----	----	d:FF	----
RolloSchalter09	d:FF	d:FF	d:00	----	----	----	----	d:FF	----
RolloSchalter10	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter11	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter12	d:FF	d:FF	d:04	----	----	----	----	d:FF	----
RolloSchalter13	d:FF	d:FF	d:04	----	----	----	----	d:FF	----
RolloSchalter14	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
RolloSchalter15	d:FF	d:FF	d:04	d:04	----	----	----	d:FF	----
Schalter6fach_01	d:FF	----	----	----	----	----	----	----	----
TH_Keller	d:FF	d:FF	----	----	----	----	----	----	----
TH_Loggia	d:FF	----	----	----	----	----	----	----	----
TH_Schlafzimmer	d:FF	----	----	----	----	----	----	----	----
TuersensorEingang	d:FF	d:FF	----	----	d:01	d:01	----	d:FF	----
TVPanelSupplySwitch	d:FF	d:FF	d:03	----	----	----	----	d:FF	----

Ein Sonderfall ist hier RolloSchalter01, den ich im Lauf des Monats mal zurückgesetzt habe und der seitdem auf dem "Standard"-AES-key besteht.

Hoffe das hilft, ansonsten kann ich auch gern konventionelle Log-Einträge beisteuern

Beste Grüße,
Andy.

[martinp876]

Hallo Andy,

Bei IODev gibt es einen Fortschritt:
- attribut IODev wird automatisch beim pairen gesetzt (auch überschrieben). Gesetzt wird das IODev,  von dem das pairen ausgelöst wurde
- sollte kein IODev eingetragen sein wird nich einmal gesucht

Stat und AES:

die Nummer des AES keys wird in d: benannt bei (Stat & 0x0020) - also bit 5 gesetzt.

Status 0x0200 signallisiert high-load (10 % bis Overload)

Falls verfügbar kannst du einen logausschnitt mir status 0x0050 schicken - den habe ich noch nie gesehen.

kritisch sehe ich TVPanelSupplySwitch - der ist auf AES key 03, alle anderen  sind auf nummer 04.


Gruss Martin