HomeMatic-Forum / FHZ-Forum

Hallo zusammen,

ich habe seit Wochen die Platine von Alex Reinert erfolgreich mit dem alten Funkmodul "HM-MOD-RPI-PCB" betrieben.
Gestern hab ich dann das neue Funkmodul installiert und folgende Probleme:

• Senden an die Homematic IP Geräte geht nicht mehr

• Empfangen Status der Homematic IP Geräte funktioniert aber

• Senden und Empfangen der Homematic (nicht IP) Geräte funktioniert aber

Am Ende habe ich festgestellt, dass es mit dem USB Kabel zusammenhängt. Nach dem ich das 0815 USB Kabel gegen ein neueres schnellladefähiges getauscht habe, funktioniert das neue Modul (RPI-RF-MOD), bis auf dass der Empfang (mit externer Antenne) schlechter als beim alten Funkmodul (HM-MOD-RPI-PCB) ist.

Meine Systemkonfiguration:

• Intel NUC NUC8I3BEH2

• RaspberryMatic 3.51.6.20200420 (OVA)

• VM: 2 CPU(s), 1GB RAM, 6,25 GB zugewiesen

Da ich hier noch ein zweites neues Funkmodul (RPI-RF-MOD) rum liegen habe, mit dem genau die gleichen phänomeme in Abhängigkeit des verwendten USB Kabels auftreten, schließe ich einen defekt des Funkmodul (RPI-RF-MOD) aus.

Kennt Ihr dieses Phänomen? Was hab ich falsch gemacht?
Falls logs weiterhelfen, bitte mir sagen welche Ihr braucht und wo ich diese auf dem System finden kann.

Also zum ersten Punkt (HmIP Geräte nicht erreichbar) kann ich sagen, das du vmtl. Einfach zu wenig Geduld hattest. Beim Wechselndes Funkmodules müssen über eQ3 Server im Internet für alle deine HmIP neue Keys bezogen/berechnet werden bevor du wieder in der Lage bist mit diesen zu kommunizieren. Und das aus verschiedenen Gründen von wenigen Minuten bis Stunden dauern. Und wenn man dann einfach die Zentrale wieder abschaltet bzw das Funkmodul wieder wechselt dann beginnt das wieder von vorne bzw kann auch Im ungünstigsten Fall zu inkonsistenten führen die dann dazu führen das manche Geräte gehen und manche nicht. Es ist also unbedingt darauf zu achten bei einem Funkmodulwechsel die Zentrale einfach mal über nacht am internet laufen zu lassen anstatt in Aktionismus zu verfallen nur weil seit 30 min die HmIP Geräte nicht erreichbar sind.

Und was den den Punkt des USB Kabels angeht, so kann ich den nicht wirklich nachvollziehen. Auch was den vermeintlich schlechteren Empfang des neuen Funkmodules in Kombination mit einem HB-RF-USB angeht. Aber vielleicht können andere mehr dazu sagen.

Wobei ich hier allerdings genau die Schwachstelle eines FallBacks bei HmIP sehe, im Falle eines Hardware-Fehlers SCHNELL eine Ersatzzentrale hochfahren zu können. Im heutigen case ist man darauf angewiesen, das die HM Server erreichbar sind (Inet Steht, der Hausmeister hat freitag nachmittag bei EQ3 vor Feierabend ein Serverupdate gesartet und die server sind über WE down u.s.w)

Hier würde ich mir ganz klar wünschen, dass optional der vorher gesicherte Key auch local aus einer datei gezogen werden kann und so das system schnell wieder verfügbar ist. Genau wie bei classic auch, dass nach einem restore auf eine neue Zentrale diese mit der ALTEN modulkennung sendet und so nicht alle Geräte rekeyed werden müssen oder als worst case neu angelernt.

Meiner meinung nach ist dieser usecase eine grosse Schwachstelle.

Black

Black hat geschrieben: ↑

06.05.2020, 08:40

Hier würde ich mir ganz klar wünschen, dass optional der vorher gesicherte Key auch local aus einer datei gezogen werden kann und so das system schnell wieder verfügbar ist. Genau wie bei classic auch, dass nach einem restore auf eine neue Zentrale diese mit der ALTEN modulkennung sendet und so nicht alle Geräte rekeyed werden müssen oder als worst case neu angelernt.

So funktioniert das aber nicht. Es ist ja defakto nicht der selbe Key der da nach einem Funkmodulwechsel generiert und dann auf der CCU für jedes HmIP Gerät abgespeichert wird. Das läuft kryptographisch ja meines wissens anders ab, sodass für jeden Funkmodulwechsel komplett neue Gerätekeys erzeugt werden müssen. Und diese kryptographischen Berechnungen dieser Gerätekeys laufen zumindest momentan nur auf eQ3 Servern statt weil dort AFAIK der Hauptkey liegt mit dem die Gerätekeys erzeugt werden. Inwieweit das eQ3 z.b. lokal auf der CCu stattfinden lassen könnte kann ich momentan schwer sagen, aber das es nicht einfach (auch zwecks security) sein wird müsste auch klar sein.

Das Verfahren sei mal aussen vor.

Es ist aber eine gewaltige Schwachstelle dass ein System bei Ausfall der eq3 Rechenleistung NICHT auf einem Ersatzsystem restored werden kann.

Stichwort Verfügbarkeit

Dies betrifft auch HmIPW.

Black

Black hat geschrieben: ↑

06.05.2020, 11:37

Das Verfahren sei mal aussen vor.

Wenn man den Punkt Sicherheit im Kopf hat, kann man das Verfahren nicht aussen vorlassen.

Black hat geschrieben: ↑

06.05.2020, 11:37

Es ist aber eine gewaltige Schwachstelle dass ein System bei Ausfall der eq3 Rechenleistung NICHT auf einem Ersatzsystem restored werden kann.

Glaub mir, die weitaus größere Schwachstelle wäre wenn das Verfahren krypographisch dadurch unsicher würde wenn die Schlüsselerzeugung zu lasten der Sicherheit auf der CCU selbst einfach so stattfinden würde. Und bei einem Accesspoint für HmIP-Cloud läuft das übrigens genau gleich ab. D.h. wenn ein Accesspoint z.B. kaputtgehen sollte und man einen anderen bräuchte, dann muss auch dieser erst die Keys über eQ3 Server neu berechnen lassen bevor der neue Accesspoint dann in der Lage ist mit den HmIP Geräten zu kommunizieren. Inwieweit man allerdings doch mit einem gewissen Maß an Sicherheit vielleicht die Schlüsselerzeugung auf die Zentrale selbst verlagern könnte kann ich aktuell nicht zu 100% sagen, das kann ich aber gerne bei der nächten Telcon mit eQ3 einmal nachfragen.

jmaus hat geschrieben: ↑

06.05.2020, 08:29

Es ist also unbedingt darauf zu achten bei einem Funkmodulwechsel die Zentrale einfach mal über nacht am internet laufen zu lassen anstatt in Aktionismus zu verfallen nur weil seit 30 min die HmIP Geräte nicht erreichbar sind.

Das habe ich auch so gemacht, erstmal die Nacht durchlaufen lassen, die Thematik mit den keys war mir bekannt.
Sorry hätte ich oben mit erwähnen sollen

Bleibt aber nach wie vor das Phänomen mit dem USB-Kabel.
Akutell funktioniert alles, wechsel ich das Kabel, hab ich wieder die Probleme mit dem Senden - ist reproduzierbar.

jmaus hat geschrieben: ↑

06.05.2020, 08:29

Auch was den vermeintlich schlechteren Empfang des neuen Funkmodules in Kombination mit einem HB-RF-USB angeht. Aber vielleicht können andere mehr dazu sagen.

Ich habe einen HM-ES-TX-WM im Schaltschrank im Keller. Mit dem neuen Modul bekomme ich immer wieder Servicemeldungen bzgl. Empfang war gestört. Mit dem Alten Modul hatte ich diese nicht. Der RSSI Wert ist auch um 10dbm schlechter als mit dem alten Modul.

Hi,

von höherer Sicherheit zu sprechen, wenn es einen zentralen Masterschlüssel gibt, merkste selber, oder?

Ein Sicheres System wäre er, wenn der Schlüssel für ein Gerät rein zufällig in SGTIN und Key des Geräts zu finden wäre. Grundsätzlich muss das ja auch der Fall sein, weil sonst der Weg der Anmeldung ohne Internetzugang nicht klappen würde. Allerdings würde das natürlich massiv die Bequemlichkeit verringern, wenn man diese bei jeder Anmeldung eines Neugeräts und bei jedem Funkmodulwechsel neu eingeben müsste. Wobei ich persönlich sogar sagen würde, dass ein Speichern der SGTIN und Key auf der CCU (außerhalb des Funkmoduls) ohne einen Masterschlüssel sicherer wäre, als der Masterschlüssel. Nicht weil die CCU sicherer ist, sondern weil der zentrale eQ-3 Server ein viel interessanteres Angriffsziel ist, wenn ich darüber alle Keys erhalten kann und damit natürlich auch deutlich mehr Aufwand beim Angriff rechtfertigt. Die Qualität eines solchen Schlüssel wäre kryptografisch auch keineswegs unsicher, weil bei dem gesamten Verfahren überhaupt keine Schlüssel auf der CCU erzeugt werden, diese sind im Funkmodul und in den Geräten ja bereits ab Herstellung unveränderlich drin, es geht nur um das Verfahren für den Schlüsselaustausch.

Viele Grüße
Alex

Scrounger hat geschrieben: ↑

06.05.2020, 11:58

Bleibt aber nach wie vor das Phänomen mit dem USB-Kabel.
Akutell funktioniert alles, wechsel ich das Kabel, hab ich wieder die Probleme mit dem Senden - ist reproduzierbar.

Nachtrag: Es scheint wohl kein Probelm des USB Kabels zu sein, sondern ein Problem des USB Ports:
Verwende ich den USB-Port (orange) mit 1,5A sind die Probleme weg und das USB Kabel ist egal.

Nur als Info: Ich verwende selbst eine NUC7i7BNH zusammen mit vmWare ESXi und einem HB-RF-USB und habe diesen an einen der hinteren blauen USB Anschlüsse angeschlossen und kann nicht von solchen Problemen berichten.