Keymatic mit Virtual Button Peeren

[Dirk]

Hallo zusammen,

hat jemand schon mal versucht die Keymatic mit einem Virtual Button zu peeren?
Das Peering klappt soweit, aber ein press short oder press long bringt lediglich ein "no ACK from Device"
Normales lock/unlock fuktioniert.

Fehlt hier vielleicht ein gesetztes AES-Bit in der virtual implementation oder übersehe ich hier was?

In der Config sieht das so aus:

Code Auswählen Erweitern

define vRemote CUL_HM 123456
attr vRemote model virtual_2
attr vRemote peerIDs
attr vRemote subType virtual

define vRemote_Btn1 CUL_HM 12345601
attr vRemote_Btn1 model virtual_1
attr vRemote_Btn1 peerIDs 18D1A301,
attr vRemote_Btn1 webCmd press short:press long

define keyMatic CUL_HM 18D1A3
attr keyMatic firmware 2.4
attr keyMatic model HM-SEC-KEY-S
attr keyMatic peerIDs 00000000,12345601,12345602,
attr keyMatic serialNr JEQ0048201
attr keyMatic subType keyMatic
attr keyMatic webCmd unlock:lock:inhibit on:inhibit off

Gruß
Dirk

[martinp876]

Hallo Dirk,

ich denke auch, dass es etwas mit AES zu tun hat. für virtuellen Aktoren muss FHEM die AES message generieren. Aber das macht FHEM nicht, nur HMLAN. Und da keymatic sinnvoller weise IMMER AES benötigt geht es aktuell nicht.

Wenn wir also AES einbauen WÜRDEN konnten wir auch dies. Dazu muss aber der AES key in FHEM hinterlegt werden. Wir jemand in einem anderen Thread darauf hingewiesen hat ist dies ein weiteres Security loch, da der key, den wir dann haben müssten, nicht gesichert gespeichert werden könnte.

Ausserden habe ich keine fertige Implementierung zur AES berechnung.

Gruss Martin

[Dirk]

Hi Martin,

sollte das komplette AES-Handling nicht transparent der HM-LAN übernehmen? Da macht er beim "normalen schalten" der Keymatic ja auch.
Oder gibt es hier einen Unterschied mit dem "Schalten" über Virtual-Buttons und normalen Befehlen.

Zumindestens die Messages von einer "normalen" Fernbedienung und einem Virtual-Button sehen nicht so verschieden aus.
Hast du noch Tipps was ich mir ggf. ansehen kann.

Gruß
Dirk

[martinp876]

beim normalen schalten ist HMLAN der Empfänger. Bei virtuellen Devices nicht, da vergibst du die HMID. Warum sollte HMLAN darauf antworten? darf es nicht.

Gruss Martin

[Dirk]

Bei virtuellen Devices nicht, da vergibst du die HMID. Warum sollte HMLAN darauf antworten? darf es nicht.

Das war der Entscheidende Hinweis!

Man gebe der Virtual Remote die selbe HMID wie dem HMLAN. Schon funktioniert es :)
Das währ noch ein kleiner Hinweis für die Doku. Geht dann halt nur eine Virtual-Remote mit dieser ID die dann AES unterstützt. Aber hier kann man ja genügend virtuelle Tasten erstellen.

Danke.

Gruß
Dirk

[martinp876]

ja, der Gedanke ist mir auch schon gekommen.
Da ich aber noch nicht über Gefahren und Nebenwirkungen nachgedacht habe ... kanst du es jetzt testen ;-)

HMIDs werden zwar auf "einzigartigkeit" geprüft, aber die IO devices sind nicht mit eingeschlossen.

Evtl muss ich bei den ACKs nacharbeiten... virtuals haben da besonderheiten.

Wenn dir Probleme auffallen melde dich.
Gruss Martin

[Dirk]

Da ich aber noch nicht über Gefahren und Nebenwirkungen nachgedacht habe ...

Die Überlegung dahinter ist die Sicherheit zu eröhen.

Folgende Idee:
Die Keymatic soll ausschließlich per FHEM abschließen können. Ein Aufschließen soll nicht möglich sein. Somit bleibt die Tür zu, auch wenn mein Netzwerk kompromittiert sein sollte. Das Aufschließen erfolgt ausschließlich über angelernte Fernbedienungen.

Eine Taste der Virtual-FB wird daher ausschließlich mit der Abschließen-Aktion der Keymatic gepeert.
Nach der Konfiguration wird die Keymatic vom HM-LAN abgelernt. Somit ist keine weitere Konfiguration möglich, da zum wiederanlernen (Pairen) ein physischer Tastendruck an der Keymatic notwendig ist.
Soweit die Idee. Wenn ich nix übersehen habe sollte das so funktionieren und ein Aufschließen per Netzwerk unmöglich machen. (Vorausgesetzt mein AES-Key bleibt geheim und die AES-Implementation hat hier keine Lücken.)

Gruß
Dirk

[martinp876]

Hallo Dirk,

das Prinzip habe ich schon verstanden. Und ja, AES ist bei Keymatic notwendig. Somit MUSS die HMID des virtual device die des HMLAN sein, sonst funktioniert es derzeit nicht.

Ich habe keine Bedenken zur Sicherheit, sondern zum korrekten Ablauf der ACKs, die ich bei virtual device sende. Könnte unnötige Messages erzeugen.

Wenn du willst kannst du mir ein paar rohmessages schicken von den Transferes, gerne auch per pm

Gruss
Martin

[Dirk]

Hi Martin,

ich werde morgen mal sehen dass ich ein paar Messages mit logge.
Was hättest du lieber, Messages "aus der Luft" also z.B. mit einem zusätzlichem CUL, oder reichen dir die Messages vom FHEM an dem der HM-LAN hängt?

Noch als Idee:
Gib der vRemote, sofern man keine eigene HMid vergibt doch automatisch die HMid vom HMLAN, alternativ vom CUL
Die HMid hier also optional machen.

Gruß
Dirk

[martinp876]

Hallo Dirk,

die Logs sind interessant, insbesondere da hier noch ein Problem mit AES-Rollos offen ist.
In jeden Fall möchte ich logs vom fhem-HMLAN. Da stehen die Stati drin, die HMLAN rücksendet. Wenn du parallel die Luft aufnehnem kannst, super. Kann gerne auch gemischt im Log stehen, wenn du eine CUL "passiv" mitlesen lässt.

Die HMID automatisch vergeben ist nicht ganz einfach.
a) bei der definition eines HM devices ist die ID pflicht. Hier weiss ich noch nicht, dass es virtuell werden soll.
b) es gibt evtl mehrere IO devices, ggf mit unterschiedlichen HMDIs - welches soll ich nehmen?

Einzige Lösung wäre, dass man
define vbtn CUL_HM <IOname>
angeben darf... dann muss man nur den Namen des IO devices angeben.
Wenn das mit den Logs passt werden ich dies vorsehen.

Ein weiteres Problem habe ich dann bei der Dekodierung der HMID - die ist dann nicht mehr eindeutig.... hmmm ich melde dann sicher immer den virtuellen Button, nie das IO device.

Ausserdem wird es eine Diskrepanz zu fhem.cfg geben, da steht nach save die HMID drin... auch nicht gut.

Gruss Martin