Schöner, wenn alle freiwillig ihre Geräte online mit der Cloud verbinden. 
Ist dann halt bequemer und einfacher dem Nachbarn seine Daten zu zeigen.
1 „Gefällt mir“
Habe jetzt hier nicht alles verfolgt, aber ist es nicht so, dass alle WR, die nur irgendwie an die Cloud angebunden sind, grundsätzlich aus der Ferne manipuliert werden könnten, wenn nur genügend kriminelle Energie aufgewendet wird? Gab es das bei Deye nicht auch schon, dass WR aus irgendwelchen technischen (oder politischen?) Gründen einfach per Web-Befehl ausgeschaltet, upgedated oder manipuliert worden sind?
Sicher ist eine Cloud-Anbindung praktisch nie. Wenn irgendein Fernzugriff besteht, gibt es auch immer Einfalltore. Natürlich mehr oder weniger einfach.
Wieviele andere IoT-Systeme von automatischen Fenster- oder Rolladenöffnern, Türöffnern oder Rasenmähern, Saugrobotern etc. etc. könnten sich so fremdsteuern lassen? Vermutlich nahezu alle, die über irgendeine App mit dem Web kommunizieren.
Allerdings sollten die Hersteller schon ein Interesse daran zeigen, es möglichen Angreifern so schwer wie möglich zu machen und auf veröffentlichte Sicherheitslücken schnell reagieren. Wenn das nicht geschieht: grundsätzlich eher Finger weg. Die Chinesen sind da wohl i.d.R. recht dickfellig…
So einfach kann man es nicht sagen. Der Hersteller bzw. Cloudanbieter kann natürlich immer alles. Aber ein Angreifer muss ja in die Kommunikation zwischen Gerät und Cloud reinkommen. Da sehe ich erstmal keine grundsätzlichen Möglichkeiten, die einem da offen stehen.
Die Geräte hängen ja auch nahezu immer hinter einer NAT-Firewall, sind also nicht direkt vom Internet her erreichbar.
1 „Gefällt mir“
Der verlinkte Artikel ist eine perfekte Medienkompetenz Übung.
Null Substanz, 100% Framing und wie sich dann auch herausgestellt hat viel heiße Luft um nichts:
Sorry das ich da so hart reingrätschen muss, selbst als jemand der das ganze Cloud Zeugs auch höchst kritisch sieht, muss man trotzdem ehrlich bleiben und nicht geopolitischer Propaganda auf den Leim gehen.
Weil was beim Laien hängen bleibt:
China Böse! Haben da Spionage und Sabotage Hardware eingebaut.
Obwohl es z.B. nur ein Fall von man hat nen andere Revision vom Mikrocontroller Board genommen wo außer z.B. WiFi auch ein BLE Modul drauf war.
Bzw. die Dokumentation war veraltet.
(Wer ohne Sünde ist werfe den ersten Stein, kein Software Entwickler wird sich da finden)
Und was viel wichtiger ist egal ob aus China USA Europa oder Deutschland, man hängt keinen WR einfach so offen ins Netz, ohne Ausnahme.
Aber zurück zum Thema ich habe auch zwei HM-400 die davon "betroffen" sind, wenn ich die DTU nur Luftlinie ohne weiteres Hindernis 5m weiter stelle und nicht direkt am Fenster 1m von den WR entfernt bricht die Verbindung schon ab.
Also ja ist nicht schön aber die Gefahr ist quasi null. Wenn ein Nachbar wirklich meine Energieerzeugung sabotieren wollte, geht das mit einem Pflasterstein deutlich einfacher als den Fernzusteuern oder die Firmware zu bricken.
(Was beides dank Monitoring auch sofort auffallen würde)
5 „Gefällt mir“
Erstaunlich was so alles erzählt wird.
Bei dem einen verbindet sich der WR nur mit einer DTU und beim nächsten ist die Reichweite nur 5 m.
Bei meinen Open DTU, HM 300, 600 und 1500 ist das anders.
- Ich kann die HM mit mehreren openDTU nutzen
- Und die Reichweite liegt bei allem bei 50 m + (trotz Wänden)
Nur mal so als Ergänzung zum gesammelten Fachwissen. 
Editiert da genau verwechselt, sry.
1 „Gefällt mir“
Die HMS brauchen eine andere DTU /Funkchip als die HM.
Bitte einfach mal Hardware Support - OpenDTU Documentation
anschauen und nicht widersprüchliche Dinge Posten.
Verwechselst Du HM mit HMS?
Die HM-Modelle nutzen das das 2,4-GHz-Band. Da braucht man z.B. das NRF24L01+ Funkmodul. Die HMS das nutzen das 868 MHz-Band. Habe sowohl HM600 als auch HM 1500. Die funktionieren beide nur mit dem 2,4-GHz-Band. Da bin ich mir ziemlich sicher. Ansonsten würde mein OpenDTU nicht funktionieren.
Die HM kann man nicht gleichzeitig mit mehreren DTU oder OpenDTU nutzen. Siehe beispielsweise Flole-Inverter-Tool Flole-Inverter-Tool Software-Dokumentation
Man soll sowas abends nicht mehr nebenbei tippen. Hab's editiert.
Danke für den Hinweis.
Bei mir läuft mit 2 HM 1500 Firmware 01.00.16 die Original DTU Pro ohne Murren parrallel mit einer Ahoy und OpenDTU. Ja die Fehlermeldungen in Ahoy steigen.
Mache das nicht ständig, aber wenn ich gerade was probiere ist das schon der Fall.
Keine der drei DTU beschwert sich.
1 „Gefällt mir“
Klar geht das, habe mir am Wochenende eine neue OpenDTU gebaut und beide gleichzeitig laufen lassen….
Habe das falsch geschrieben.
In den Diskussionen bei OpenDTU in github wurde darüber gesprochen, dass wenn ein HM mit einer DTU verbunden ist, funktioniert “SEARCH ID” nicht mehr.
1 „Gefällt mir“
Ah ok, gut zu wissen. Vielen Dank!
Dann muss ich mir ja keine Gedanken machen. 
Gedanke.
Ich Feind, bügle mit Leistung die DTU nieder, dann bekomme ich die ID wieder
Nö, bin friedlich. Der Panik Käse interessiert mich auch nicht.
Ich hatte verstanden, dass es nicht funktioniert während die DTU kommuniziert.
Hast du zufällig Zitat und Quelle zur Hand?
Ich finds grad nicht. (Zeit)
Ich sortier mal.
Grösste Gefahr Angriff von aussen via coud:
Das kann der Hersteller bzw ein Einbrecher beim Hersteller machen. Dann gibts noch DNS hijacking. 3. Vektor wäre ein verteilter Angriff, der irgendwas aufspielt mit noch nicht bekannten Softwareloch.
Kleine Gefahr Angriff von aussen via lokalem rumlaufen mit Sender:
Für grossflächigen Angriff brauchst tausende Leute. Man kann höchsten gezielt paar wenige WR übernehmen. Oder die Funktion wird verwendet, um via original DTU Geräte zu finden, die nicht zugeordnet sind.
Reichweite:
Bei manchen halt nur 5m, das spricht für fehlerhafte Antenne oder verrauschter Frequenz. “Normale” Reichweite 50-100m bzw bei dem Versuch bis zu 200m. Das reicht 1-2 Wohnblocks weit.
Der theoretisch grösste Angriff:
Ale Geräte an original DTU als repeater verwenden. Alle erreichbaren Geräte als repeater verwenden. In einer dichten Bebauung mit vielen HM/HMS kommst damit schon recht weit. Wenn aber alle Geräte an openDTU und Verwandten nicht auf broadcast reagieren, sind die nicht erreichbar.
Passt?
Sich daher nicht um unsichere Hardware zu kümmern halte ich für mutig.
Grundsätzlich sollten solche Fehler behoben werden.
Wenn jemand dadurch remote nach und nach mehr(alle) HMTs mit eigener Firmware betanken kann ist das einfach falsch.
Beim Auto würde man sich ja auch eher wundern wenn man im vorbeigehen die keyless Go überwinden kann.
Es ist kein Weltuntergang, aber das vorgehen von Hoymiles bzw die dokumentierte (nicht) Reaktion ist meeh
Wenn die Funktion einigermaßen sinnvoll implementiert ist, funktioniert Search ID nur so lange bis die erste Kommunikation des Wechselrichters über die Seriennummer mit einer DTU hergestellt wurde.
Dann hat bei dem nächsten Versuch ein weiter entfernter und bisher nicht verbundener Wechselrichter die Chance seine Seriennummer zu posten.
Das würde man dann solange durchführen können bis keine Antwort auf Search ID kommt.
Damit müsste der HM für den gesamten Tag ab der ersten Verbindung mit seiner DTU - und nicht nur während einer aktiven Verbindung - nicht mehr auf Search ID reagieren.
Kann das jemand verifizieren?
Selbst wenn das hier jemand probiert, der eine SW mit Search-ID hat, wäre es für Dich wohl nicht aussagekräftig. Hoymiles hat für die HM eine Menge SW-Versionen im Einsatz.
Wäre ein nettes Projekt Seach-ID in OpenDTU zu implementieren. Macht bestimmt Spass. Leider habe ich so viele Projekte am Haus, dass ich das dieses Jahr nicht mehr machen könnte. Und dann bastle ich auch weiter an meiner Hausautomatisierung. Und Ende August will Hoymiles ja die gepatchte-Version für HM mit Verschlüsselung rausbringen.
Daher habe ich mich entschieden die Patches von Hoymiles abzuwarten. Habe mir diese Woche eine Hoymiles DTU Lite in Kleinanzeigen für 30 EUR gekauft. Für meine HM. Mit der kann ich dann im im September das Update über die Hoymiles Cloud für meine Wechselrichter machen lassen. So macht ja Hoymiles dir Updates. Über OpenDTU kann man ja kein Update machen.
Mache mir bei meinen Hoymiles HM keinen Kopf. Die sind an einem OffGrid-System, das ich zum Laden des Elektroautos verwende. Nicht mit dem VNB verbunden. Wenn da ein Scherzkeks die abschaltet, schalte ich die halt wieder ein. Keine kritische Infrastruktur bei mir. Und für den Notfall habe ich noch einen Ersatz-Wechselrichter.
Echte Angreifer haben vermutlich anderes zu tun als durch die Lande zu fahren und etwas mit den Hoymiles zu machen. Wenn er das Risko eingeht. Macht er das häufiger, kann der Jagende auch zum Gejagten werden……….
Und wenn es wirklich fortgeschrittene Angreifergruppen sind, ist es für die kein Hindernis, wenn Search-ID nicht funktioniert und der Wechselrichter mit einer DTU, AhoyDTU oder OpenDTU verbunden ist. Dann hören Sie einfach den Funk ab und sehen die IDs im Klartext, die meine OpenDTU zu den Wechselrichtern schickt. Die ist ja auch nicht verschlüsselt.
Insofern hilft es nicht, wenn Seach-ID nicht funktioniert.
Korrekt. Die Verschlüsselung auf den HM-Mikrowechselrichtern ist vollständig unverschlüsselt.
Genau so habe ich mir zuerst eine Art "Sniffer" in Python programmiert, die Kommunikation zwischen openDTU-onBattery und meinen HM-600 und TSUN TSOL-M800(DE) überwacht und sende in einem zweiten Python-Programm mittlerweile nach Analyse (und teilweise copy & paste von C++-Code-Teilen der openDTU-Community) selbst Steuerbefehle an meine zwei Mikrowechselrichter.
Das mache ich allerdings nicht aus Böswilligkeit, sondern rein als Rückfallebene, falls sich die openDTU-onBattery auf meinem Fusion Board mal wieder komplett verabschieden sollte, selbst ein Hard-Reset nicht hilft und als einzige Lösung das erneute Flashen per USB übrig bleibt. In dieser Zeit übernimmt der Raspberry Pi eine Art Notfallkommunikation und steuert sogar die Nulleinspeisung weiterhin. Diese zusätzliche Kommunikation klappt im laufenden Betrieb während die openDTU-onBattery noch funkt und steuert auch einwandfrei.
Ich bin bei einer Sache allerdings sehr verwundert: Die openDTU reagieren auf Netzschwankungen (Thema Nulleinspeisung) eher träge so im Bereich um die 7-10 Sekunden. Bei meiner selbst programmierten Rückfallebene mit eigens angeschlossenem NRF24L01+-Chip und kleiner Antenne gibt es quasi gar keine Verzögerung. Ein Steuerbefehl mit z. B. 300 Watt geht raus und zack, mein Stromzähler meldet direkt (~1 Sekunde) eine Veränderung (Einspeisung oder Bezug). Auch das Abschalten findet nahezu sofort statt. Einzig das Einschalten dauert etwas länger, vermutlich auch, weil sich der Mikrowechselrichter ja immer noch mit dem Netz synchronisieren muss. Gefühlt ist diese Steuerung dennoch deutlich schneller als durch die openDTU. Das fand ich nur interessant zu erwähnen.
Lange Rede, kurzer Sinn:
Ein HM-Mikrowechselrichter ist trotz ständiger Verbindung mit sogar mehreren DTUs gleichzeitig definitiv steuerbar und wer eine DTU im Einsatz hat, ist leider durchaus angreifbar, weil die Kommunikation unverschlüsselt stattfindet und die relevanten Teile der Ziel- und Quell-Seriennummern einfach per simplem Sniffing abgefangen werden können. Mit dem Wissen dieser kann der Angreifer sie anschalten, ausschalten, das Einspeiselimit ändern (wenn diese z. B. an einer Batterie hängen) und Technikaffine können natürlich noch viel schlimmere Dinge wie das Aufspielen eigener Firmware durchführen oder es unbrauchbar machen.
1 „Gefällt mir“