Kommunikation HM-Dis-WM55 -> vccu -> keymatic mit indivduellem AES key absichern

Begonnen von FhemPiUser, 03 Dezember 2017, 18:25:49

Vorheriges Thema - Nächstes Thema

FhemPiUser

Hallo,
ich versuche aktuell die Kommunikation von einem Schalter (HM-Dis-WM55), der über die vccu (long (to vccu)) eine keymatic schaltet, mit AES abzusichern. Und das natürlich mit einem geändertem Systemschlüssel.

Ich habe erstmal bei der vccu den Klartext-hmkey mit attr vccu hmkey xxx gesetzt. Wird damit auch automatisch der key den IODevs (bei mir HMLAN und Raspberry-Modul) zugewiesen?

Hier hat mich schon gewundert, dass ich den key als attr im Klartext sehen kann. Ich dachte der wird von fhem nur als md5 gespeichert?

Im Wiki steht
ZitatDie Schlüssel werden MD5 kodiert - man kann ihn im Klartext oder bereits kodiert eingeben. FHEM kodiert ihn, wenn er im Klartext eingegeben werden sollte.

Nur woher weiss fhem, ob der eingegebene key Klartext oder bereits md5 kodiert ist? Man kann das ja nicht angeben...

Dann habe ich beim keymatic den key mit set keymatic assignhmkey zuweisen. Wie kann ich kontrollieren, ob das geklappt hat? An dem erhöhten aesKeyNbr?

Genauso habe ich beim Schalter den key mit set schalter assignhmkey zugewiesen. Aber aesKeyNbr erhöht sich nicht, scheint also nicht geklappt zu haben? Oder kann der HM-Dis-WM55 kein AES?

Mir ist auch nicht klar, ob für meinen Fall noch ein aesCommReq oder ein sign on notwendig ist. Laut Wiki nur für Empfänger, aber der Schalter ist ja eigentlich nicht Empfänger. Empfänger wären ja vccu und keymatic. Muss ich für diese noch set vccu/keymatic aesCommReq 1 oder set vccu/keymatic sign on eingeben?

Aus dem Wiki Artikel ist das für mich nicht ganz eindeutig...



FhemPiUser

ZitatHier hat mich schon gewundert, dass ich den key als attr im Klartext sehen kann. Ich dachte der wird von fhem nur als md5 gespeichert?

na super, das klartextpasswort enthielt nur zahlen und buchstaben aus dem hexadezimalraum. kann es also  sein, dass fhem es als md5 kodiert erkannt hat, obwohl es klartext war, und ich damit jetzt selbst das klartextpasswort nicht kenne? und nun?

ich fände es sinnvoll, wenn man beim attr hmkey explizit angeben muss, ob das eingegebene passwort klartext oder md5 kodiert ist...

mgernoth

Hallo,

Zitat von: FhemPiUser am 04 Dezember 2017, 14:26:21
na super, das klartextpasswort enthielt nur zahlen und buchstaben aus dem hexadezimalraum. kann es also  sein, dass fhem es als md5 kodiert erkannt hat, obwohl es klartext war, und ich damit jetzt selbst das klartextpasswort nicht kenne? und nun?

Das "Klartextpasswort" ist in dem Fall dann Dein String, der wohl aus 32 Zeichen aus dem Hex-Zeichenraum besteht. Nur in diesem Fall macht Fhem nicht md5() über diesen String. Ein echtes "Klartextpasswort" vor MD5 brauchst Du nicht (nichtmal für die CCU, da kann man den Hex-Key auch direkt in eine Datei schreiben).

Zitat von: FhemPiUser am 03 Dezember 2017, 18:25:49
Dann habe ich beim keymatic den key mit set keymatic assignhmkey zuweisen. Wie kann ich kontrollieren, ob das geklappt hat? An dem erhöhten aesKeyNbr?

Ja, wenn Du die Keymatic über Fhem schliesst/konfigurierst und die aesKeyNbr dabei auf 2 geht (und Du AES-Meldungen im Monitor hast).

Zitat
Genauso habe ich beim Schalter den key mit set schalter assignhmkey zugewiesen. Aber aesKeyNbr erhöht sich nicht, scheint also nicht geklappt zu haben? Oder kann der HM-Dis-WM55 kein AES?

Bei Sendern ist es nicht so einfach herauszubekommen, welchen Schlüssel sie verwenden. Das Gerät muss eine SIgnaturanforderung stellen, wobei der aktuelle Schlüsselindex an Fhem übertragen wird.

Ändere mal die Konfiguration des Schalters (sign off/sign on z.B.), dann sollte die Nummer aktualisiert werden.

Zitat
Mir ist auch nicht klar, ob für meinen Fall noch ein aesCommReq oder ein sign on notwendig ist. Laut Wiki nur für Empfänger, aber der Schalter ist ja eigentlich nicht Empfänger.

Äh, aesCommReq ist für Sender, wenn Fhem vom Sender eine Signatur anfordern soll. sign ist für Empfänger, damit diese eine Signatur anfordern. Kann man bei der KeyMatic nicht abschalten.

In Deinem Fall des direkten Peerings zwischen Taster und Keymatic brauchst Du es aber nicht.

Zitat
Muss ich für diese noch set vccu/keymatic aesCommReq 1 oder set vccu/keymatic sign on eingeben?

Beides kannst Du nur auf Geräten setzen, nicht auf der VCCU.

aesCommReq brauchst Du nicht und sign kann man bei der keyMatic eh nicht abschalten.

Peere jetzt einfach den Schalter mit der Keymatic und schaue, ob Du schalten kannst und ob aesKeyNbr bei beiden Geräten auf 2 steht. Evtl. musst Du im Peering im Taster noch expectAes setzen.

Viele Grüße
  Michael

automatisierer

wie genau steuerst du den keymatic mit dem taster? hast du direkt gepeert oder machst du das ganze über ein notify oder DOIF?

FhemPiUser

Vielen Dank, Deine Antworten haben schon einmal ein Stück weitergeholfen.

Die keymatic scheint den individuellen Schlüssel zu nutzen, den aesKeyNbr ist erhöht.

Allerdings will ich nicht den Taster direkt mit dem keymatic peeren, sondern über die vccu. D.h. der Taster der HM-Dis-WM55 führt dazu, dass fhem ein Fhem("set keymatic open") ausführt.

Hintergrund: Ich will die keymatic mit inhibit on verwenden, damit die Taster an der keymatic nicht gehen (Kindersicherung und Sicherheit gegen durchgreifen durch die Glasscheibe der Tür). Mit inhibit on geht kein direktes peering mit der keymatic soweit ich weiss. Außerdem sollen mit dem HM-Dis-WM55 Taster gleichzeitig auch noch andere Funktionen (Anzeige weiterblättern, Sirene aus) ausgeführt werden.

Beim HM-Dis-WM55 gibt es kein "set sign on/off", obwohl es aesCommToDev und aesKeyNbr als Readings gibt. Ich konnte nur ein "set HM-Dis-WM55 regset sign on/off" machen, aber das gibt immer eine Fehlermeldung "cannot calculate value. Please issue set HM-Dis-WM55 getConfig first - invalid". getconfig und anlerntaste o.ä. helfen aber auch nicht. aesKeyNbr bleibt immer bei 0. Ich fürchte fast das Problem ist, dass der HM-Dis-WM55 kein AES unterstützt (zumindest nicht funktionsfähig in fhem)...




automatisierer

sign on/off gibt es nicht beim Device sondern nur bei den Channels. Bei Devices die quasi nur einen Channel haben (Wie der Keymatic) ist dieser direkt ins Device integriert...

Wenn du den Taster mit aes betreibst, dann macht das ganze nur Sinn, wenn du mit deinem notify/DOIF auf Events reagierst die etwas mit AES zu tun haben und nicht auf das normale press short/long. Die short/long Events werden nämlich erzeugt bevor FHEM den Taster nach dem AES Key fragt und auch wenn der TAster nicht den richtigen Key kennt - also AES fail.

Ich hab das bei meinen Handsendern so gelöst:

([Garage_MOD_1_Btn_01:"^trig_aes_vccu:.ok"] and [?Garage_MOD_1_Btn_01] =~ "Short"

Das DOIF wird getriggert, wenn das Event "trig_aes_vccu: ok" kommt und dann wird überprüft ob Long/Short gedrückt wurde.


FhemPiUser

ahh ok, wieder etwas gelernt.

Allerdings scheitere ich momentan noch daran, überhaupt AES beim HM-Dis-WM55 zu aktivieren bzw. den Schlüssel zu übertragen. Aeskeynbr steht noch immer auf 0...

automatisierer

das ist immer nen bissl tricky...

am besten mal clear msgEvents und dann ein getConfig - drauf achten, das alle CMD's abgearbeitet wurden (CMDs_done), danach assignHmKey und dann in einem Channel sign off und wieder on. Wenn der Taster nicht von FHEM geweckt werden kann, musst du nach jedem Schritt die Config taste drücken...


Was für ein IO nutzt du? Eines von HM oder nen CUL? CUL ist wegen timing-Problemen auch immer schwierig...

FhemPiUser

nutze vccu mit HMLAN und Raspberry Modul.

Ich habe aber die Befürchtung, dass beim HM-Dis-WM55 AES garnicht funktioniert...

FhemPiUser

egal was ich beim HM-Dis-WM55 probiere (set sign on, set assignhmkey,...) und welche Tasten ich auch drücke, im Event Monitor erscheint keine einzige AES Meldung.

Hat irgendjemand einen HM-Dis-WM55 mit AES am Laufen?

Kann es sein, dass der HM-Dis-WM55 kein AES unterstützt?

frank

Zitat von: FhemPiUser am 04 Dezember 2017, 19:04:23
egal was ich beim HM-Dis-WM55 probiere (set sign on, set assignhmkey,...) und welche Tasten ich auch drücke, im Event Monitor erscheint keine einzige AES Meldung.

Hat irgendjemand einen HM-Dis-WM55 mit AES am Laufen?

Kann es sein, dass der HM-Dis-WM55 kein AES unterstützt?

sieht wohl so aus:

Zitat<?xml version="1.0" encoding="ISO-8859-1"?>
<device version="17" rx_modes="CONFIG" peering_sysinfo_expect_channel="false" supports_aes="false">
   <supported_types>
      <type name="HM Wireless Status Display" id="HM-Dis-WM55" updatable="true" priority="2">
         <parameter index="10.0" size="2.0" const_value="0x00D3"/>
      </type>
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

FhemPiUser

ah danke, das erklärt natürlich alles ;)

Schade eigentlich. Komisch nur, dass das der HM-Dis-WM55 standardmäßig die Readings "aesCommToDev" und "aesKeyNbr" hat und auch ein set assignhmkey und set sign on/off stehen zur Auswahl...

Ich frage mal bei eq3 nach, vielleicht erweitern sie die firmware entsprechend (die Hoffnung stirbt zuletzt)...

Wo ist denn das xml her?


frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

automatisierer

Zitat von: FhemPiUser am 04 Dezember 2017, 19:04:23
egal was ich beim HM-Dis-WM55 probiere (set sign on, set assignhmkey,...) und welche Tasten ich auch drücke, im Event Monitor erscheint keine einzige AES Meldung.


das ist natürlich blöd...
rein Interessehalber, kommen denn überhaupt Events von den Tastendrücken an? Oder sind die Taster nur zum "Internen umblättern" der Nachrichten die im dem Dingen gespeichert sind?

FhemPiUser

die events von den tastern kommen an und kann man für notify etc verwenden...