AES - unmöglich zu realisieren?

Begonnen von kossmann, 04 Januar 2013, 14:34:04

Vorheriges Thema - Nächstes Thema

kossmann

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 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.

Dirk

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

kossmann

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.

Samsi

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.
 
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

Dirk

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.

kossmann

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.

kossmann

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?

Samsi

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.
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

Dirk

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

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.

Samsi

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.

FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

kossmann

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.

kossmann

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.

Samsi

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 ;)
FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

martinp876

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?