Fhem und HM-SEC-KEY

martinp876 · 02 Juli 2014, 09:28:00

in deinem Log war nichts geheimes drin.
Das einzig kritische wäre der Bootvorgang. Da schickt die Zentrale die AES-keys an das HMLAN

Das kommt immer, wenn sich das HMLAN neu connected (der key wird im ram gehalten - ist also nach power-down verloren)
das sind die messages:
09:23:58.425 0: HMLAN_Send: iohl1 I:Y01,01,dd4b21e9ef71e1291183a46b913ae6f2
09:23:58.427 0: HMLAN_Send: iohl1 I:Y02,02,834B23152C250AADD5C0C378432B228A

Alles andere ist unkritisch. War also kein Problem.
Was ich wissen will ist, welche dieser messages die eQ3 SW an das HMLAN sendet (beim Booten) und welche du in FHEM einträgst. Das müsste der kritische Punkt sein.
Wenn du es mir senden kannst könnte ich es prüfen. Ich weiss nicht, wo du wohnst

noice · 02 Juli 2014, 13:15:35

erstmal vielen Dank das du mir weiterhilfst. Ich hoffe das ich auch daraus lernen kann.

Protokoll hast Du per mail bekommen

martinp876 · 03 Juli 2014, 19:27:43

für alle AES Nutzer:
FHEM muss HMLAN für jedes Device mitteilen, welchen AES-key dies verwenden soll. Aktuell ist das immer '01'.

Es muss also ein neues Attribut geben, mit dem der key (die nummer des Keys) festgelegt werden kann.

Der Key sollte nicht von IO verwaltet werden sondern von der vccu. Also werde ich bei der Gelegenheit auch dies umziehen (falls es eine VCCU gibt werden die Keys von dieser dem HMLAN/USB mitgeteilt).

Alles noch in Arbeit...

Gruss Martin

noice · 03 Juli 2014, 22:14:43

ist es nicht so das der hmlan weiß welchen code welches gerät benötigt bzw fragt das gerät nicht nach dem code 05 ?
also in meinem Beispiel benötigt die Keymatic den AES Code 05 also sendet der HMlan den code 05 (also der der darunter gespeichtert ist)

oder ist es eher so das dem gerät eigentlich egal ist an welcher stelle der code steht Hauptsache er stimmt ?!?`

sorry für die komische Fragerei .. ich versuch nur zu verstehen $:-\$

noice · 03 Juli 2014, 23:25:10

so .. nun glaub ich aber das ich spinn ....

nach Eingabe meines letzten keys (05) in alles 5 hmkey´s fing an mein Keymatic auf Kommandos zu reagieren

kann nur momentan nicht weiter testen da meine Tochter schläft und der Motor nicht gerade den begriff "flüstern" erfunden hat.
ich teste morgen im laufe des Tages nochmals und werde berichten

martinp876 · 03 Juli 2014, 23:32:03

An deinem Log konnte ich es sehr schön sehen (war mit so nicht bewusst):
- im HMLAN kannst du mehrere AES codes eintragen (FHEM erlaubt 5)
- FHEM assigned jedes Device dem HMLAN, wenn es als IO genutzt werden soll. Hierbei muss FHEM mitteilen, welcher key (also dessen Nummer) genutzt werden soll, wenn den AES gefordert werden sollte.

=> alle andere geht dann HMLAN-intern.

Es ist also primär egal, welche Nummer ein AES-key hat. Wichtig ist, dass die Kombination passt.
So ist es aktuell nicht implementiert. Es wird immer key 01 zugewiesen.
Wenn du es also einmal testest: den Key 05 also key01 setzen und probieren. Wenn es klappt ist das der Beweis.
Ich werde es auch noch einmal testen.

Setze also einfach nur HMkey auf den Wert des orginalen 05. Die Anderen scheinen nicht gebraucht zu werden.

Es bleiben bei mir noch ein paar Fragen: Wie ist das bei Devices untereinander?

noice · 03 Juli 2014, 23:38:41

also den 05 auf den hmkey 01 zu setzen hat nicht funktioniert .. hab ich heute abend / nacht probiert .. nun hab ich aus frust den einen key auf alle 5 hmkey´s eingetragen und nun hat er reagiert ...
ich werde mich morgen nochmals damit beschäftigen (sobald Deutschland gespielt hat)

kann ein device also nur einen AES code kennen oder auch mehrere?

no_Legend · 04 Juli 2014, 08:13:45

Ich hab das hier mit den 5 Schlüsseln gelesen.

Dazu hab ich mal eine Frage, ich hab zwei mal den Schlüssel geändert.
Ich war mir nicht sicher ob es beim ersten mal gemacht hatt.
Nun steht in der Keys Datei zwei Keys, die genau gleich sind.

Bisher hab ich noch keine Gerät angelernt, welches AES benutzt.

Kann ich nun einen Key aus der Datei einfach löschen?

martinp876 · 04 Juli 2014, 08:28:18

Kann ich nun einen Key aus der Datei einfach löschen?
das würde ich nicht.
Ich bin noch nicht sicher, ob die Nummer des Key mitgegeben wird.

no_Legend · 04 Juli 2014, 08:32:10

Wenn ja aber noch keine Device angelernt wurde.
Dann kann ja auch nix passieren.

Wenn ich beide Keys in der Windows Konfig drin lasse, sollte ich dann auch beide KEys in FHEM eintragen?

Das ganze sieht so ungefähr aus:

Code Auswählen

Current Index = 2
Key 0 =
Key 1 = 6167AF6935FC9E6B642A4D751D6B42C9
Key 2 = 6167AF6935FC9E6B642A4D751D6B42C9
Last Index = 1

martinp876 · 04 Juli 2014, 12:19:25

so lange AES ausgeschaltet ist, kann nichts passieren.
Aktuell sollte man die Keys genau wie aus der HM_SW übernehmen.
Weitere Details muss ich mir noch klar machen. So lange du es nicht einschaltest passiert sowieso nichts.
FHEM ändert auch weder den Key noch die Zuordnung in einem Device. Das einzige, was man machen kann, ist AES im Device einschalten. Wenn man das macht wird das Device bei Änderungen den gültigen key fordern. U.a. Abschalten ist dann nur möglich, wenn man den Key auch eingestellt hat.

Die Einstellung dass FHEM (also das IO) AES fordert ist hingegen jederzeit abschaltbar. Das ist eine Einstellung im HMLAN und die ist spätestens nach reboot vergessen (wird ggf neu gesetzt).

no_Legend · 04 Juli 2014, 12:52:37

Hi Martin,

AES auf dem LAN kann man ausschalten. (Ist Sie nicht deaktiviert kann FHEM nichts mit HMLAN anfangen)

Wenn man aber einen Keymatic betreib ist das ausschalten von AES auf der Funkstrecke, nicht möglich.
Zität von der Produktbeschreibung von ELV: (Auch in der Wiki http://www.fhemwiki.de/wiki/HM-SEC-KEY_KeyMatic)

ZitatSichere Funkverbindung.
Die Kommunikation mit der KeyMatic® verläuft nur AES-authentifiziert

noice · 04 Juli 2014, 12:56:31

Achtung... AES auf dem lan und AES für das funkprotokoll sind 2 Paar Schuhe

Gesendet von meinem HTC One X mit Tapatalk

martinp876 · 04 Juli 2014, 16:02:21

Man kann:
1) AES auf dem LAN ein und ausschalten
2) AES "in der Luft" nutzen

Hier reden wir nur über 2)

Wenn man AES in der Luft nutzt wird immer der Empfänger den Sender nach einer Bestätigung fragen, bevor er das Kommando akzeptiert.
AES muss immer am Aktor eingeschaltet sein, damit dieser "nachfragt".
2a) AES zwischen remote und Aktor: remote sendet Trigger, Aktor fragt nach AES, remote beantwortet, aktor schickt ok ( also ACK)
2b) FHEM schickt an ein Device (trigger oder configuration): wie 2a, FHEM ist hier die Remote
2c) device sendet trigger an FHEM: wie 2a, FHEM ist hier Aktor. Man muss/kann in FHEM einschalten, dass ein AES request gesendet wird. Dies ist interessant, wenn man sicherheitsrelevante Schaltungen vornimmt und FHEM dazu notifies ausführen soll.
Mit dem Attribut aesCommReq kann man das einschalten.

den korrekten Key und dessen korrektes Handling braucht man für 2b und 2c - klar