Frage: Was würdet Ihr heute anders machen

[Black]

stimmt, wenn sowas iWie key oder Winmatic m Einsatz ist... würde ichs anders sehen... ist bei mir aber nicht. Die Fragestellung muss dann jeder für sich selber beantworten.

Wer das equipment hat, synthetische Funktelegramme zu senden, hat dann auch das wissen, den Funkverkehr zu belauschen und das Handshake mit Sicherer verbindung mitzuschneiden und auszuwerten. und kann damit auch gefakte telegramme senden.

Dauert Zugegeben etwas länger.

[hobbyquaker]

Wer das equipment hat, synthetische Funktelegramme zu senden, hat dann auch das wissen, den Funkverkehr zu belauschen und das Handshake mit Sicherer verbindung mitzuschneiden und auszuwerten. und kann damit auch gefakte telegramme senden.

Wie kommst Du darauf? Stand heute hat noch niemand ein erfolgreichen Angriff auf den AES-Handshake zeigen können - wenn ein individueller Schlüssel gesetzt ist. Das wurde bisher nur beim Default-Key gezeigt. Und ich bin fast sicher: wenn es jemand geschafft hätte hätte er es sich auch nicht nehmen lassen das auf dem C3 vorzutragen... Und Du kannst Dir sicher sein es haben sich schon mehrere begabte Leute die Zähne daran ausgebissen...

[Black]

ok, da du bekannterweise tiefer in der Materie drin bist wie ich, berichtige mich, wenn das folgende nicht zutrifft

ich habe vonfolgenden Szenario gehört.

Man verfügt über das Equipment telegramme zu senden und zu empfangen und sowohl head als auch payload zusammensetzen zu können.
man belauscht den Funkverkehr, beispielsweise Befehl von Fernbedienung (oder CCU) an keymatik
damit kennt man das Funkpaket mit dem Schaltbefehl als auch das Funkpaket was die CCU (Fernbedienung) als Authentifizierung gesendet hat
habe ich equipment, was nun diese beiden belauschten telegramme technisch auch funken kann, verhält sich ein Laptop mit Sendestick genau wie eine CCU.
ich muss also nicht den Schlüssel kennen, ich muss nur vorher das Handshake belauscht und aufgezeichnet haben.
klingt für mich schlüssig, ok setzt equipment, fachwissen und geduld (vorheriges Aufzeichen) vorraus.

black

[hobbyquaker]

ich muss also nicht den Schlüssel kennen, ich muss nur vorher das Handshake belauscht und aufgezeichnet haben.

Zum Glück ist das nicht so. Der AES-Handshake ist dazu da genau solche einfachen "Replay Attacken" zu verhindern.
Eine Analyse des BidCos AES Handshakes von Michael Gernoth findest Du hier: https://git.zerfleddert.de/hmcfgusb/AES/
Im Chat sagte er mir dazu mal dass der Handshake an sich hinreichend sicher und nicht zu beanstanden ist (wenn man nicht den Default Key nutzt) - Gefahr droht eher durch Fehler in der Implementierung desselben (in der Aktor-Firmware) die natürlich nicht auszuschließen sind. Aber wie gesagt: bisher hat niemand einen erfolgreichen Angriff zeigen können.

Siehe auch ganz unten auf der Seite:

... a secure authentication mechanism which seems quite attack-proof (if the key is changed by the user)

[Black]

ok, dann habe ich etwas dazugelernt. Danke.

[Linedancer10]

Vielen Dank für die Rückmeldungen.

Ich hab inzwischen fast alle Programme nach iobroker umgezogen. Der Rest kommt auch noch.
Auf der CCU2 läuft noch CUXD für einige FS20 Komponenten und 2 Wrapper devices. Dazu ein Ping device mit dem ich prüfe ob der iobroker Rechner lebt.
Scripte gibt's auf der CCU2 keine mehr.

Bin zufrieden....

[dtp]

...was würdet ihr heute bei einer Neuinstallation anders/besser machen?

Kurze Antwort: Nichts.

EDIT: Obwohl, vielleicht würde ich heute komplett auf HMIP in Verbindung mit der CCU2 setzen. Aber nur aus dem Grund, dass ich zukünftig eher Neuentwicklungen bei HMIP, als bei HM erwarte.

[dtp]

ansonsten sowenig wie möglich Scripte (soll iobroker machen)

Vielleicht noch was zu diesem Punkt. Ich sehe das etwas differenzierter. Warum soll die CCU2 nicht Programme und Skripte ausführen, die unmittelbar mit ihr verbundene Aktoren und Sensoren betrifft? Für mich hat das den Vorteil, dass man nicht von einer zusätzlichen Instanz, wie z.B. dem ioBroker, abhängig ist. So gerne ich auch den ioBroker nutze, so häufig hatte ich schon in der Vergangenheit mehr oder weniger starke Probleme bei Updates des js-controllers. Da ist es dann sehr ärgerlich, wenn plötzlich nichts mehr geht. Die CCU2 läuft durchaus sehr zuverlässig, wenn man sich an gewisse Regeln hält und sie nicht mit zu viel Jobs überfrachtet.

Für mich macht daher ein Mixbetrieb aus CCU2 und ioBroker mehr Sinn, wobei die CCU2 alles übernimmt, was unmittelbar die mit ihr verbundenen HM-Komponenten betrifft, während der ioBroker dann zum Zug kommt, wenn es um die Visualisierung oder die Eindindung HM-fremder Komponenten und Dienste geht. So funktioniert dann immer noch ein Teilsystem (wenn evtl. auch eingeschränkt), wenn das andere Teilsystem mal ausfällt.

Bis dann,

Thorsten

[klassisch]

Ich mach's ähnlich. Was auf der CCU an Steuerung läuft, bleibt erst mal drauf. Wobei ich sehr sparsam mit Skripten umgehe - weil ich zu wenig davon verstehe.
Dinge, die ich nicht zu Steuerung brauche, wie weitere Temperatur- etc. Sensoren, Wetterdaten, Geigerzähler, ... möchte ich künftig direkt auf den ioBroker schieben ohne Durchgang durch die CCU.
Visualisierung, Diagramme, Datensammeln läuft nur auf ioBroker, nichts auf der CCU.
Und neue Spielzeuge wie Ikea Tradfri, Xiaomi Sauger etc, gehen eh nicht auf der CCU. Da braucht es ioBroker, FHEM oder so etwas.
Schwierig wird es, wenn man was rechnen möchte. WebUI kann das nicht. Mit den Skripten bin ich vorsichtig. Also käme ioBroker ins Spiel oder man rechnet es bereits im Sensor, wenn es z.B. ein ESPxx ist.

[dtp]

Schwierig wird es, wenn man was rechnen möchte. WebUI kann das nicht. Mit den Skripten bin ich vorsichtig.

Das geht aber mit Skripten durchaus sehr gut auf der CCU2. Insbesondere, seitdem jmaus die Math-Optionen deutlich erweitert hat.

Man muss ja Skripte nicht unbedingt auf dem zugegebenermaßen sehr hohen Niveau von BadenPower schreiben. Meistens kommt man auch mit kleinen und übersichtlichen Skripten schon sehr weit.

Ein Problem ist halt, dass die CCU2 von Hause aus keinen Debugger oder dergleichen mitbringt. Da ist man dann in der Regel auf das extrem simple "Skript testen"-Fenster angewiesen. Aber damit kann man auch schon sehr weit kommen. Und wenn man die Skripte geschickt geschrieben hat, kommt man teilweise auch mit Copy & Paste recht weit.

Gruß,

Thorsten