HMLAN mit eigenem AES Signierungsschlüssel

[gandy]

Hallo Martin,

super, das automatische setzen werde ich beim nächsten Schwung Hardwareanlernen gleichmal testen, die meisten gehen über HMLAN1 und nachdem HMALN2 bei mir danach definiert ist, waren die letzten Anlernversuche immer zweistufig (anlernen mit autocreate, IOdev einstellen, dann nachholen was ohne IOdev nicht geklappt hat, weil HMLAN2 ausserhalb der Reichweite lag).

Dass meine Devices unterschiedliche AES keys benutzen liegt sicher daran, dass ich in mehreren Wellen angelernt habe, ab und an mal versuchsweise den Schlüssel neu setzte (kriegt anscheinend trotz identischem Hash nen neuen Index) und nicht jedesmal alle Geräte neu angelernt habe. Deshalb sitzen die meisten (seitdem nicht zurückgesetzten) SEC-RHS (FensterSensor) auch auf AES key 01. Mache RolloSchalter habe ich in jüngster Vergangenheit auf Werkseinstellungen zurückgesetzt, dann aber die AES Signierung mit Werks-AES key aktiviert, ich vermute das sind die mit 00 statt 03/04?

Status 0x0050 finde ich in meinem Logfile im Zusammenhang mit dem "babbelnden" FensterSensor07 - das betreffende Logile (FensterSensor07-babble.log-anfang) findest du in dem betreffenden Threadbeitrag http://forum.fhem.de/index.php/topic,17759.msg117426.html#msg117426 . Darin sind:

Code Auswählen Erweitern


196CA9 FensterSensor03
196A3F FensterSensor04
196980 FensterSensor07

Bei FS03 und FS04 kann ich mich erinnern, beim Schließen rot gesehen zu haben - ein späterer Versuch wurde dann mit grün quittiert und ich habs erstmal ad acta gelegt. Was mit dem FS07 geschah, lern ich ja vielleicht noch...

Grüße,
Andy.

[martinp876]

der Status 0050 kommt alternativ zu 0040. Es scheint also 0040 & 0010 zu sein - diese sind ggf getrennt auszuwerten.
Die Messages 0050 und 0040 sind alle eine Art Info des HMLAN. Die Messages wurden schon mit dem Status 0100 verarbeitet.

HMLAN sender in dem Bit-bereich infos wie "messages wurde gesendet" oder "Antwort auf gesendete Messages empfangen/nicht Empfangen".

Deutungen können noch abgegeben werden

[mueller_f]

Hallo Martin,

ich habe ein AES Problem mit dem Tür/Fenster Sensor HM-SEC-SC. Obwol ich die AES-Keys in FHEM genau wie in der Bidcos-Datei der Windows-Software gesetzt habe, kann ich keine Befehle an den Sensor senden (z.B. Register abfrage). Das Sensor Attribut "aesKeyNbr" zeigt "FF" an, was mich überrascht. In meiner Windows Bidcos-Datei gibt es nur 5 Keys und keine 255 (falls ich FF als Hex-Zahl interpretiere). Hast Du einen Verdacht wo das Problem liegen könnte? Außerdem habe ich noch nicht verstanden, wie ich empfangene Pakete prüfen kann ob sie von einem Sender mit korrektem AES-Key stammen. Die Befehle lesen kann ich natürlich, aber woher weiss ich, dass sie wirklich von dem korrekten Sender stammen?

Vielen Dank für deine Arbeit an der HMLAN-Anbindung.
Viele Grüße

Fabian

[martinp876]

Hallo Fabian,

hex ist richtig, ist alles hex hier. 255 kommt, wenn kein Key genutzt wird.

Außerdem habe ich noch nicht verstanden, wie ich empfangene Pakete prüfen kann ob sie von einem Sender mit korrektem AES-Key stammen.

kann ich auch nicht... Es läuft normal so, dass jemand (meist die Zentrale) einen request stellt. So AES eingeschaltet am empfänger antwortet er mit einer AES-anfrage die vom initiator korrekt beantwortet werden muss. Bekommt der Empfänger eine korrekte Antwort wird der ursprüngliche Request abgearbeitet und es kommt ein Bestätigung an den Sender.

Die Befehle lesen kann ich natürlich, aber woher weiss ich, dass sie wirklich von dem korrekten Sender stammen?

Du meinst, das jemand deinen Aktor gehäckt haben könnte und du eine AES-anfrage von der Zentrale starten willst? Habe ich nicht probiert...


Wenn bei key-nummer immer FF drin steht ist AES evtl garnicht aktiviert - kannst du einen mitschnitt schicken?

Gruss Martin

[jab]

@Samsi: Du sagst, dass die Windowssoftware einfach den MD5 Hash des Passworts überträgt. Hast du mal geschaut was sie überträgt wenn man keinen Key angibt? Also kann man den Default AES Key so rausbekommen? Ein anderer Versuch wäre mal der md5 Hash von dem leeren String (also d41d8cd98f00b204e9800998ecf8427e). Hast du Lust das mal zu probieren?

Gruß,
Jan

[mueller_f]

Hallo Martin,

vielen Dank für deine schnelle Antwort.

Ich habe ein Teil des Problems mit dem HM-SEC-SC Sensor gelöst: Ich wusste nicht, dass ich nach einem Set getConfig kurz die Pair-Taste drücken muss um die Register abzufragen. Die AES Verschlüsselung scheint zu funktionieren (Gegentest mit gelöschtem Key funktionierte nicht.)

Allerdings liest FHEM den offen/geschlossen Zustand auch mit falschem AES schlüssel korrekt ein. Soweit ich verstanden habe ist ja auch bei AES "signing" ein mitlesen der gesendeten Nutzdaten immer möglich. Dies ist für mich auch grundsetzlich kein Sicherheitsproblem, solange ich sicherstellen kann, dass der gesendete Befehl nur von einem autorisierten Sender kommt. In folgendem Szenario könnte dies andernfalls ein Problem sein: Fernbedienung sendet an FHEM, FHEM öffnet per Key-Matic die Tür.

Keymatic prüft natürlich ob FHEM autorisiert ist, aber wie kann ich in FHEM prüfen ob die Fernbedienung authorisiert war? Fall ich das AES-Challenge-Response Verfahren richtig vertstanden habe, müsste ich dazu irgendeinen Wert in FHEM abfragen können der mir anzeigt ob die Challenge Reponse vom Sender ( hier die Fernbedienung) an FHEM korrekt war. Gibt es diese Möglichkeit oder falls nicht, kann man das implementieren?

Vielen Dank und viele Grüsse
Fabian

[martinp876]

Hi Fabian,

man kann in der FB je peer eines Tasters einschalten "expextAES". Dann liegt es an FHEM einen AES-request zu senden, den die FB beantworten muss.
Du nutzt einen virtuellen Aktor...
dieser Code fehlt in FHEM - das ist korrekt. Ich denke, man könnte ihn einbauen...

Gruss Martin

[Samsi]

@Martin:

das wäre nicht schlecht, dann könnte man auch seine Alarmanlage über einen Handsender schalten. Wenn ich es richtig verstehe bekommt man momentan das Notify des Handesenders auf jeden Fall und kann nicht erkennen ob es ein autorisierter Handsender war. Also das wäre nicht schlecht, nur ein Notify zu bekommen, wenn die AES Challenge Response korrekt war.

@Jan
Werde ich mal ausprobieren. Ich installiere mal die HMLAN Software auf einem anderen PC neu , schau was in den Keys Dateien steht und logge dann mal mit, was er bei der ersten Verbindung zum HMLAN macht.

[Zeitisen]

Hallo,

ich bin relativ neu bei FHEM. Ich habe einen HMLAN  und verschiedene Rolladen-Aktoren, die ich über Webinterface mit fhem oder direkt über einen gepeerten Schalter  steuern möchte.
FHEM läuft auf einem RaspberryPi.

Ich möchte diese Aktionen über AES gesichert ausführen. Ich habe dazu einen eigenen AES Schlüssel erzeugt und ihn in hmkey eingetragen.
Bei den Aktoren habe ich das Register sign auf on gestellt. Der Wert  aesKeyNbr zeigt immer noch FF.

• Was muss ich noch tun?
• Was habe ich übersehen?
• Wie kann ich sonst noch prüfen, ob die Kommunikation über AES läuft?

[Samsi]

Hallo,

Ich habe dazu einen eigenen AES Schlüssel erzeugt und ihn in hmkey eingetragen.

Das geht nicht. Du musst das mit der Windows Konfigurationssoftware machen, nur diese überträgt dann auch den Schlüssel an die Geräte (bei den schaltern musst Du dafür evtl. die anlernen Taste Drücken, wenn sie batteriebetrieben sind, das sonst der Schlüssel nicht übertragen werden kann). Das eintragen in hmkey stellt nur sicher, das HMLAN auch ein entsprechend signierte Antwort geben kann. Aber dazu müsste der Schlüssel erst über die Windows Software an alle Geräte verteilt werden.
Testen kannst Du es dann, indem du HMLAN kurz stromlos machst (damit er den key vergisst) und dann mit FHEM versucht zu steuern, ohne erst ohne hmkey und dann mit hmkey. Ohne darf es nicht gehen und mit muss es dann gehen.

Da die keys ach einen Index besitzen, solltest Du dir die Datei Bidcos-Service/keys von der Windows Software ansehen. Da stehen alle keys mit index drin (falls du versehentlich schon mehrere hast)

Grüße

[netbus]

Das mit dem Schlüssel übertragen auf die Aktoren usw. ist die eine Sache nur wie kann ich die AES Kommunikation aktivieren in den Geräten.
In der Windows Software finde ich keine Möglichkeit das zu de- oder aktivieren.

[Samsi]

Hallo,

schau die mal die REgsiter expextAES und sign an. Ich glaube mit sign schaltest du das beim Aktor an und mit expext AES sagst du dem Sender das der Aktor AES erwartet. Ganz sicher bin ich mir da aber jetzt auch nicht.
Grüße

[martinp876]

Sollte so stimmen.
sign wird je kanal gesetzt - im Empfänger von Kommandos
expextAES wird im Sender gesetzt, wenn zu erwarten ist, dass der peer AES anfragen wird.

Gruss Martin

[Zeitisen]

@Samsi

Du musst das mit der Windows Konfigurationssoftware machen

Das habe ich. Zu diesem Zeitpunkt war der betreffende Aktor aber noch gar nicht vorhanden.
Den Schlüssel habe Ich aus der Datei Bidcos-Service/keys von der Windows Software.

Die Frage ist dann auch, ob ich die Geräte an die Windows-Software anlernen muss.
Irgendwo im Wiki steht, dass das nicht empfehlenswert ist. Ist das jetzt Käse?

Wenn die Geräte angelernt werden müssen, dann hat natürlich kein Aktor den neuen Key.
Geht das Anlernen da auch mit Befehl von der Software aus? Wenn nicht, dann habe ich ein Problem.
Die Aktoren sind ja eingebaut und nicht ohne weiteres erreichbar ( In Verteilerdosen, Lampenbaldachinen ...).
Außerdem haben viele keinen Taster angeschlossen, weil keine schaltende Leitung hin geht (sonst bräuchte ich ja keinen Funk )

Der Key wird doch im HMLAN gespeichert. Eigentlich müsste doch der den Schlüssel verteilen?
Es ist schon mühsam, wenn ich immer erst ein Windows in einer virtuellen Maschine herauskramen muss, nur um irgendwelche Initialisierungen zu machen, wenn ein neuer Aktor dazukommt.
Ich arbeite normalerweise nur mit Linux. Ich wollte mir auch die Mühe sparen, mich in die Windowssoftware einzuarbeiten.

Bis zu den Schaltern (Sensoren) bin ich noch gar nicht gekommen

Ich habe bisher nur einen Key.

[martinp876]

Zu diesem Zeitpunkt war der betreffende Aktor aber noch gar nicht vorhanden....
Die Frage ist dann auch, ob ich die Geräte an die Windows-Software anlernen muss.

ja, muss angelernt sein

Irgendwo im Wiki steht, dass das nicht empfehlenswert ist. Ist das jetzt Käse?

setze die HMId für die Windows SW gleich der von FHEM. Dann musst du nicht noch einmal pairen

Wenn nicht, dann habe ich ein Problem. Die Aktoren sind ja eingebaut und nicht ohne weiteres erreichbar (

versuche es über die Seriennummer zu machen.

Der Key wird doch im HMLAN gespeichert. Eigentlich müsste doch der den Schlüssel verteilen?

HMLAN ist ein IO, keine Zentrale. Wenn die Zentrale (windows-SW) sagt "verteilen" dann wird er verteilt. FHEM hat dies nicht implementiert.

Gruss Martin