Hallo zusammen,
die von einigen HomeMatic-Geräten erzwungene AES-Kommunikation funktioniert mit FHEM und CUL ja leider nicht. Da es sich laut HomeMatic-Inside (//www.homematic-inside.de/archive/tecbase/glossary/item/glossary/aes-authentifizierung.html) aber wohl nicht wirklich um eine AES-Verschlüsselung handelt, sondern nur um eine "Rückfrage" des Aktors bei der Zentrale, frage ich mich...
Ist eine Realisierung der AES-Kommunikation unmöglich oder nur noch nicht geschehen? Wo liegt das Problem genau?
Es ist schade, dass man mit dem CUL die KeyMatic beispielsweise nicht nutzen kann.
Hi kossmann,
bei der "Rückfrage" wird eine korrekte Antwort erwartet. Diese wird zusammen mit dem Systemschlüssel, den man selber vergeben kann und einigen anderen Parametern errechnet.
Und genau diese Berechnung ist bisher nicht bekannt. Daher ist hier eine Lösung mit CUL derzeit nicht möglich.
Es ist zwar bekannt, dass es sicht um eine AES-gesicherte Kommunikation handelt, aber auch hier ist wichtig zu wiessen welche Parameter in die Schlüsselberechnung noch mit eingehen.
Gruß
Dirk
Das die Antwort korrekt sein muss, leuchtet ein ;-)
Wenn ich richtig gelesen habe, ist der Schlüssel in den Aktoren und Zentralen erst mal überall gleich. Wäre folgendes eventuell zu realisieren:
Eine HMLAN wird von irgendwem im Internet betrieben (und per dynamischem DNS erreichbar gehalten) und dient für alle zur Berechnung der Antworten? Wenn der Aktor nun eine "Frage" stellt, reicht FHEM diese in´s Internet zum öffentlichen HMLAN weiter, nimmt die "Antwort" entgegen und schickt diese an den Aktor.
Somit könnte jeder per CUL mit den AES-Zwang-Aktoren kommuniziern - eine Internetverbindung vorausgesetzt, welche aber i.d.R. überall vorhanden sein sollte.
Hallo,
ich würde Dir empfehlen, einen HM-CFG-LAN zu verwenden, dann läuft das auch mit der Keymatic, sogar mit eigenem Schlüssel. Den Schlüssel aber immer gut aufheben ( der wird aber auch in einer Datei in der Windows Software gespeichert, sogar als Historie mit alten Schlüssel, einfach davon immer mal ein Backup machen), dann kann auch nichts passieren.
Am Anfang haben ja alle Module den gleichen Schlüssel, wenn Du also den Schlüssel änderst und dann ein Modul anlernst wird der neue Schlüssel darin gespeichert.
Das hat z.B. zur Folge das wenn die Keymatic schon mit dem Handsender gepaart ist(direktverknüpfung) und Du änderst den Schlüssel, dass dann der Handsender erst mal nicht funktioniert (weil der ja noch den default Schlüssel hat). Erst wenn Du dann den Handsender auch noch mal mit der Windows Software anlernst bekommt dieser ja auch den neuen Schüssel und dann funktioniert automatisch auch die Direktverbindung zwischen Handsender und Keymatic wieder.
Ich habe dann in FHEM dieselbe HMID eingestellt wie Sie von der Windows Software verwendet wird und wechsel dann immer zum Konfigurieren zu der Windows Software, weil man dort auch schön die Einstellungen der Homatic Module im Expertenmodus machen kann, über die Register in FHEM ist mir das einfach noch zu kompliziert.
Die Antwort wird vom Aktor in der Regel innerhalb eines kurzen Zeitfensters erwartet.
Das wird man auch diese Weise wohl nicht realisieren können.
Abgesehen davon würde das die Verschlüsselung aushebeln sofern du dann den "Community-Schlüssel" verwenden würdest. Somit könnte AES auch abgeschaltet bleiben.
Ok. das geht ja wiederum nicht bei allen Aktoren.
Ich bin ja sicher nicht der Einzige mit dem Wunsch, KeyMatic mit FHEM und CUL bedienen zu können. Das Problem am zusätzlichen HMLAN wäre, dass ein Benutzer (wie auch ich) sicher nicht einsieht, zusätzlich zur KeyMatic weitere 50,- Euro für die Steuerung auszugeben und diese auch noch permanent mit Strom zu versorgen.
Dirk, richtig - AES wäre überflüssig. Ich kann nicht beurteilen, wie groß das Sicherheitsloch werden würde, aber ein Angreifer kann HomeMatic-Geräte doch nur "hacken", wenn er die Seriennummer des Aktors und die HMID kennt, oder? Kann man beide sniffen?
Zitat von: kossmann schrieb am Fr, 04 Januar 2013 14:53Das die Antwort korrekt sein muss, leuchtet ein ;-)
Eine HMLAN wird von irgendwem im Internet betrieben (und per dynamischem DNS erreichbar gehalten) und dient für alle zur Berechnung der Antworten? Wenn der Aktor nun eine "Frage" stellt, reicht FHEM diese in´s Internet zum öffentlichen HMLAN weiter, nimmt die "Antwort" entgegen und schickt diese an den Aktor.
Somit könnte jeder per CUL mit den AES-Zwang-Aktoren kommuniziern - eine Internetverbindung vorausgesetzt, welche aber i.d.R. überall vorhanden sein sollte.
Wohl kaum, die AES Berechnung wird ja nicht von dem HMLAN per Netzwerk zurückgegeben sondern per Funk an das zu schaltende Gerät versendet.
Seriennummer wird zu Adressierung benutzt und geht over the Air. UNVERSCHLÜSSELT.
Ich würde auch HM-LAN empfehlen. Der kann auch Batteriebetriebene Aktoren "Aufwecken" und schalten. Kann CUL derzeit auch nicht.
Abgesehen davon kannst du HM und z.B. FS20 mit einem CUL sowieso nicht vollständig bedienen.
Gruß
Dirk
ZitatWohl kaum, die AES Berechnung wird ja nicht von dem HMLAN per Netzwerk zurückgegeben sondern per Funk an das zu schaltende Gerät versendet.
Theoretisch geht das schon, könnte ein CUL ja wieder empfangen und über das Netz zurück geben. Aber trotzdem ist das keine gute Idee.
Zitat von: kossmann schrieb am Fr, 04 Januar 2013 15:08Das Problem am zusätzlichen HMLAN wäre, dass ein Benutzer (wie auch ich) sicher nicht einsieht, zusätzlich zur KeyMatic weitere 50,- Euro für die Steuerung auszugeben und diese auch noch permanent mit Strom zu versorgen.
Laut meinem Energiekostenmessgerät verbraucht das HM-CFG-LAN nicht mal ein Watt und ich kann es per Netzwerk auch an ganz anderen Stellen einsetzen. Hat also auch wesentlich Vorteile, zusammen mit dem Komfort vieles über die Windows Software einzustellen, denn die vielen Möglichkeiten zur Einstellung sieht man bei FHEM nicht so einfach.
Zitat von: Samsi schrieb am Fr, 04 Januar 2013 15:14Wohl kaum, die AES Berechnung wird ja nicht von dem HMLAN per Netzwerk zurückgegeben sondern per Funk an das zu schaltende Gerät versendet.
Ja - zwischen FHEM und Aktor besteht ja auch immer eine Funkverbindung (hier über das CUL).
FHEM (Befehl an Aktor) -> CUL -> Aktor
Aktor (AES Rückfrage) -> CUL -> FHEM
FHEM (AES Rückfrage Weitergabe) -> Internet -> öffentliches HMLAN
öffentliches HMLAN (AES Antwort) -> Internet -> FHEM
FHEM (AES Antwort Weitergabe) -> CUL -> Aktor
Ich weiß nicht, wie groß das Zeitfenster ist, aber über das Internet sind Latenzen im zweistelligen Millisekunden-Bereich zu erwarten - das sollte doch drin sein.
Okay, schade! Ein Watt ist zu verkraften, aber trotzdem wäre es mit dem eigenen CUL schöner - dafür hat man ihn ja.
Ich habe bis jetzt nur Rollladenaktoren und Fenstergriff-Sensoren im Einsatz. Hier funktioniert bis jetzt alles. Nun überlege ich, Rauchmelder und KeyMatic zu erweitern und stoße an die Grenzen.
Zitat von: Dirk schrieb am Fr, 04 Januar 2013 15:18Theoretisch geht das schon, könnte ein CUL ja wieder empfangen und über das Netz zurück geben. Aber trotzdem ist das keine gute Idee.
Ja aber nur theoretisch. Wenn das HMLAN erstmal 50 anfragen pro Sekunde von hunderten von anwendern aus dem Internet bekommt, wird es wohl seinen Dienst quittieren ;)
zeitlich halte ich es für utopisch. i.d.R. warte HM devices so 200ms.
Acktor sendet -> CUL1 empfängt -> internet -> HMLANöffentlich-> CUL öffentlich ->fhem offentlich -> internet ->fhemprivat -> CULprivat -> Aktor
alles in 200ms. Wir habe schon mit internen Antworten von FHEM ggf. timing probleme. Ohne das Internet, welches ohne Garantie arbeitet.
Die Seriennummer wird nicht zur Adressierung verwendet sondern die HMId. Beides geht mit unter unverschüsselt durch die Luft, die Seriennummer aber nur sehr selten.
habt ihr einen Log von einer AES kommunikation?
Hi Martin,
Zitathabt ihr einen Log von einer AES kommunikation?
Könnte ich dir schicken. Dennoch wird die Implementierung sicher nicht einfach.
Weil eben keine Information über den Aufbau der AES Nachricht. Oder weisst du da mehr?
nein, ich weiss nicht mehr - kann auch nicht garantieren, dass irgendetwas dabei rauskommt.
Interessant ist sicher das aufsetzen der AES und dann ein paar einzelne schaltvorgänge.