IP-Router MDT SCN-IP100.03

[tobiasr]

Wenn er an den MDT Support quasi die gleichen Infos gesendet hat wie an uns, hätte dort kommen müssen: "Wir haben die Pakete mal in unseren Paketanalysator gestopft" und der sagt "Verschlüsselt!". Bitte stellen Sie sicher, dass ihre Software Verschlüsselung unterstützt oder deaktivieren sie KNX Secure.

[kbabioch]

Ich bin mir nicht sicher, ob man erwarten kann/soll/darf, dass der Support kunden Mitschnitte dekodiert. Klar, hätte man auch ohne darauf kommen können bzw. rückfragen müssen, ob und sie KNX Secure eingestellt isr, usw.

Bzgl. der Frage wo das Ganze definiert ist:
ISO 22510:2019

Der Zugang kostet aber Geld. Insgesamt ist es aber aus kryptografischer Sicht aber altbacken mit alten kryptografischen Primitiven, usw. Natürlich bietet es Schutz vor einigen Angriffszenarien, aber in der Praxis ist es fragwürdig, ob man das wirklich will/braucht. Vor allem im EFH. Bei Hotels mit Zugang zu KNX Leitungen durch Fremde mag es wieder anders aussehen, aber man handelt sich hier viele Fehlerquellen/Komplexität ein, und der Mehrwert in der Praxis hält sich stark in Grenzen, vor allem wenn nicht alle Geräte KNX Secure fähig sind.

Ob FHEM das kann, keine Ahnung. Vermutlich nicht, aber es gibt durchaus schon Open Source Implementierungen, die das beherrschen.

Mit freundlichen Grüßen,
Karol Babioch

[derneugierige]

Ich halte das gar nicht für so leicht, den Titel immer von Anfang an passend zu wählen,
vor allem dann, wenn es um ein Problem geht, und man die Ursache noch gar nicht kennt.
Am besten wäre es dann wohl, das Problem in Stichworten möglichst gut zu beschreiben.

Eben...

Hier in diesem Fall geht es ja darum, wie man mit FHEM verschlüsselt kommunizieren kann,
oder hab' ich das falsch verstanden?

Im Grunde ja. Zu dem Zeitpunkt an dem ich den Thread eröffnete wusste ich das aber nicht.

[derneugierige]

Hättest du dir wirklich erwartet, dass der MDT-Support ein Problem lösen kann, dass mit MDT überhaupt nichts zu tun hat?

Das nicht.

Allerdings hätte ich gehofft, dass der Support nicht schon nach DHCP versus Statische IP mit seinem Latein am Ende ist. Schon die Frage "haben Sie vielleicht KNX IP Secure aktiv?" hätte mich auf die richtige Spur gesetzt. Diese Stichworte hätte ich dann schon an Tante Gockel verfüttern können.

Fairerweise muss man aber sagen, dass ähnliches auch bei vielen anderen Firmen zu beobachten ist: nach dem Dreisatz DHCP/DNS/Browsercache weiss man nicht mehr weiter...

[derneugierige]

Bzgl. der Frage wo das Ganze definiert ist:
ISO 22510:2019

Danke! Werde mir das mal anschauen...

Insgesamt ist es aber aus kryptografischer Sicht aber altbacken mit alten kryptografischen Primitiven, usw. Natürlich bietet es Schutz vor einigen Angriffszenarien, aber in der Praxis ist es fragwürdig, ob man das wirklich will/braucht. Vor allem im EFH. Bei Hotels mit Zugang zu KNX Leitungen durch Fremde mag es wieder anders aussehen, aber man handelt sich hier viele Fehlerquellen/Komplexität ein, und der Mehrwert in der Praxis hält sich stark in Grenzen, vor allem wenn nicht alle Geräte KNX Secure fähig sind.

Naja, wir reden hier ja über die IP-Ebene. Und da ist man dann gleich bei potentiellen Löchern in (WLAN?)Router usw/usf. Insofern tue ich mir noch schwer, das zu deaktivieren. Schlechter als Klartext wird es wohl kaum sein, selbst wenn es altbacken ist.

Ob FHEM das kann, keine Ahnung.

Nein, FHEM kann das (noch?) nicht.

aber es gibt durchaus schon Open Source Implementierungen, die das beherrschen.

Hmm, hast Du da vielleicht einen Hinweis?

[kbabioch]

Naja, wir reden hier ja über die IP-Ebene. Und da ist man dann gleich bei potentiellen Löchern in (WLAN?)Router usw/usf. Insofern tue ich mir noch schwer, das zu deaktivieren. Schlechter als Klartext wird es wohl kaum sein, selbst wenn es altbacken ist.

Gerade die IP Ebene kann man aber mit anderen Mitteln viel besser absichern (z.B. VPN / VLANs 802.1X, usw.). Dann ist es im Prinzip völlig egal, was darüber ausgetauscht wird, wenn es auf IP Ebene verschlüsselt ist und nur berechtigte Geräte Zugang erhalten. Du könntest z.B. über ein dediziertes Netz für die Gebäudeleittechnik nachdenken, etc. Es einfach in dein Heimnetz zu packen ist an sich schon problematisch - zumindest wenn dir die IT Sicherheit wichtig ist. In der Praxis im Einfamilienhaus spielt das alles aber vermutlich kaum eine Rolle. Gute Praxis ist es trotzdem nicht :-).

Wo KNX Security im Prinzip schön wäre (und es aktuell keine guten Schutzmechanismen gibt), wäre eher auf Ebene der "grünen Datenleitung" (TP) bzw. bei RF. Aktuell ist es halt möglich, dass jemand mit Zugang zum Datenbus (z.B. eben in Hotelumgebungen, usw.) oder mit etwas SDR Equipment Telegramme mitschneidet / manipuliert / versendet. Der einzige Schutz wäre aktuell die Segmentierung in viele Linien mit vielen Kopplern und entsprechenden Filtertabellen, usw. Hier wäre Verschlüsselung / Authentifizierung ein echter Mehrwert.

Hmm, hast Du da vielleicht einen Hinweis?

Siehe z.B. hier. Soll aber nur ein Beispiel sein, ich bin mit dem Projekt weder verwandt noch benutze ich es, etc.

Auch für knxd gibt es Überlegungen KNX Secure zu implementieren, siehe z.B. hier.

[derneugierige]

Gerade die IP Ebene kann man aber mit anderen Mitteln viel besser absichern (z.B. VPN / VLANs 802.1X, usw.). Dann ist es im Prinzip völlig egal, was darüber ausgetauscht wird, wenn es auf IP Ebene verschlüsselt ist und nur berechtigte Geräte Zugang erhalten. Du könntest z.B. über ein dediziertes Netz für die Gebäudeleittechnik nachdenken, etc.

Guter Hinweis!

Siehe z.B. hier.

Ahja, das Calimero-Projekt. Das hatte ich bewusst ignoriert, weil ich eine gewisse Abneigung zu Java habe...

Auch für knxd gibt es Überlegungen KNX Secure zu implementieren, siehe z.B. robertguetzkow[/B][/B]

robertguetzkow

robertguetzkow

knxd/knxd/issues/418"]hier[/URL].

[/quote]
Ja. Allerdings ist das ein wenig eingeschlafen, weil @robertguetzkow wohl doch ein anderes Thema für seine Diplomarbeit bekommen hat..