KNX Secure im Projekt: Data Secure und IP Secure

Wer KNX plant, denkt zuerst an Topologie, Gruppenadressen und Inbetriebnahme. Sicherheit kommt oft als Nachgedanke, manchmal gar nicht. Das ändert sich, sobald KNX über IP läuft oder von aussen erreichbar ist. Dann ist eine unverschlüsselte Anlage kein theoretisches Risiko mehr, sondern ein konkretes Problem.

Dieser vierte Teil der Serie «KNX richtig planen» zeigt, wann KNX Secure in die Ausschreibung gehört, was Data Secure und IP Secure im Projektalltag bedeuten und wie die Schlüsselverwaltung von Anfang an geregelt werden muss. Die technischen Grundlagen, also wie AES-128 im CCM-Modus funktioniert und was KNX Secure leisten kann und was nicht, behandelt der Einzelbeitrag «KNX Secure erklärt: Wie es funktioniert, was es bringt und wo die Grenzen liegen».

Warum KNX Secure heute kein Sonderfall mehr ist

KNX wurde ursprünglich als Bussystem für abgeschlossene Gebäudeinstallationen entworfen. Die physische Trennung des Busses vom restlichen Netz war lange die wichtigste Schutzschicht. Dieses Bild hat sich verändert.

Heute laufen KNX-Anlagen fast immer mit einem IP-Backbone. Linienkoppler mit IP-Schnittstelle verbinden Linien über das Hausnetz, Visualisierungen greifen per KNXnet/IP auf den Bus zu, und Fernwartungszugänge sind in vielen Projekten von Anfang an eingeplant. Sobald KNX-Telegramme das Twisted-Pair-Segment verlassen und über IP transportiert werden, gelten andere Regeln. Ein unverschlüsseltes KNXnet/IP-Telegramm ist im lokalen Netz lesbar und, bei falscher Netzkonfiguration, auch veränderbar.

Dazu kommt die zunehmende Vernetzung von Gebäudetechnik und IT. Facility-Management-Systeme, Energiemonitoring und Cloud-Anbindungen teilen sich Netzwerksegmente mit der Gebäudeautomation. Was früher getrennt war, ist heute verbunden. KNX Secure ist die Antwort des Standards auf diese Entwicklung, und sie ist in ISO/IEC 14543-3 sowie EN 50090 verankert.

Für Planer und Bauherren bedeutet das: Die Frage ist nicht mehr, ob KNX Secure nötig ist, sondern wann und in welchem Umfang. Wer diese Entscheidung in der Ausschreibung offenlässt, gibt sie an den Integrator ab, und der entscheidet dann nach Aufwand, nicht nach Schutzbedarf.

Data Secure und IP Secure: zwei verschiedene Schichten

KNX Secure besteht aus zwei unabhängigen Mechanismen, die unterschiedliche Angriffsvektoren adressieren. Es ist wichtig, sie nicht zu verwechseln, weil sie auch unterschiedliche Anforderungen an Geräte, Planung und Betrieb stellen.

KNX Data Secure

KNX Data Secure schützt die Kommunikation auf der Anwendungsschicht. Das bedeutet: Das Telegramm selbst ist verschlüsselt und authentifiziert, unabhängig davon, über welches Medium es transportiert wird. Ob Twisted Pair, IP oder Funk, ein Data-Secure-Telegramm kann von einem Gerät ohne den richtigen Schlüssel weder gelesen noch manipuliert werden.

Data Secure ist gerätebezogen. Jedes Gerät, das Data Secure unterstützt, trägt ab Werk einen individuellen Schlüssel, den sogenannten FDSK (Factory Default Setup Key). Dieser Schlüssel ist auf dem Gerät aufgedruckt oder als QR-Code hinterlegt und wird bei der Inbetriebnahme in der ETS erfasst. Aus diesem Schlüssel leitet die ETS die projektspezifischen Schlüssel ab, die dann auf die Geräte übertragen werden.

Data Secure schützt auch gegen Wiederholungsangriffe. Ein Angreifer, der ein gültiges Telegramm aufzeichnet und später erneut einspielt, scheitert am Sequenzzähler, der in jedem Gerät mitläuft.

KNX IP Secure

KNX IP Secure schützt die Kommunikation zwischen IP-fähigen KNX-Geräten im Netz. Es sichert den KNXnet/IP-Tunnel und den Routing-Multicast, also die Verbindungen zwischen IP-Kopplern, zwischen ETS und Anlage sowie zwischen Visualisierungen und dem Bus.

IP Secure arbeitet auf der Transportschicht und ist unabhängig von Data Secure. Eine Anlage kann IP Secure aktiviert haben, ohne dass die einzelnen Geräte auf dem Twisted-Pair-Bus Data Secure unterstützen. Umgekehrt kann Data Secure auf dem Bus aktiv sein, während der IP-Backbone unverschlüsselt bleibt. Beide Kombinationen sind technisch möglich, aber nicht immer sinnvoll.

In der Praxis empfehlen wir, beide Mechanismen gemeinsam zu planen, wenn die Anlage über IP kommuniziert. IP Secure allein schützt den Transportweg, aber nicht das Gerät. Data Secure allein schützt das Gerät, aber nicht den Weg zwischen IP-Kopplern.

Wann gehört KNX Secure in die Ausschreibung?

Die Antwort auf diese Frage hängt von der Systemarchitektur und dem Schutzbedarf ab. Wir formulieren sie bewusst als Entscheidungsbaum, weil es keine universelle Pflicht gibt, aber klare Situationen, in denen KNX Secure nicht fehlen darf.

IP-Backbone vorhanden: Sobald KNX-Telegramme über IP transportiert werden, sei es über IP-Koppler, KNXnet/IP-Router oder IP-Tunneling, gehört KNX IP Secure in die Ausschreibung. Das gilt für praktisch jeden Neubau mit mehr als einer Linie.

Fernzugriff geplant: Wenn die Anlage von aussen erreichbar ist, über VPN, Cloud-Dienste oder Fernwartungszugänge, ist IP Secure unbedingt erforderlich. Ein unverschlüsselter Fernzugang zu einer KNX-Anlage ist ein offenes Einfallstor.

Sicherheitsrelevante Funktionen: Zutrittskontrolle, Alarmfunktionen, Beschattung in Verbindung mit Einbruchmeldern oder ähnliche Anwendungen erhöhen den Schutzbedarf. Hier empfehlen wir Data Secure auch auf dem Twisted-Pair-Bus.

Öffentliche oder halböffentliche Gebäude: In Schulen, Verwaltungsgebäuden, Hotels oder Gesundheitseinrichtungen ist der physische Zugang zum Buskabel schwerer zu kontrollieren als in einem Einfamilienhaus. Data Secure reduziert das Risiko, dass jemand mit einem Busankoppler Telegramme einspielt.

Reine TP-Anlage ohne IP, ohne Fernzugriff: In kleinen, abgeschlossenen Anlagen ohne IP-Anbindung ist der Schutzbedarf geringer. KNX Secure ist dann nicht zwingend, aber auch kein Fehler. Wer heute auf Secure-fähige Geräte setzt, hält sich die Option für spätere Erweiterungen offen.

Der FDSK: Schlüssel, der am Gerät klebt

Der FDSK ist der Ausgangspunkt jeder Data-Secure-Inbetriebnahme. Er ist herstellerseitig auf dem Gerät hinterlegt, meist als aufgedruckter Code oder als QR-Aufkleber auf dem Gehäuse oder der Verpackung. Dieser Schlüssel ist einmalig und geräteindividuell. Es gibt keinen zweiten.

Das hat praktische Konsequenzen für den Projektablauf. Der FDSK muss bei der Lieferung erfasst werden, bevor das Gerät verbaut ist. Ist das Gerät einmal in der Unterverteilung montiert und der Aufkleber nicht mehr zugänglich, wird die Inbetriebnahme aufwendig. In einigen Fällen muss das Gerät ausgebaut werden, um den Code zu lesen.

Wir empfehlen deshalb, den FDSK-Erfassungsprozess in der Ausschreibung explizit zu regeln. Der Integrator soll die FDSKs aller Secure-fähigen Geräte vor dem Einbau erfassen und dokumentieren. Diese Dokumentation gehört zur Lieferdokumentation und wird mit dem ETS-Projekt an den Bauherrn übergeben.

Ein weiterer Punkt: Wird ein Gerät im Betrieb ersetzt, weil es defekt ist, braucht der Integrator den FDSK des Ersatzgeräts. Dieser liegt auf dem neuen Gerät, aber nicht im ETS-Projekt des alten. Der Austauschprozess muss deshalb im Betriebshandbuch beschrieben sein, damit er auch Jahre nach der Inbetriebnahme reibungslos funktioniert.

Das Projektpasswort: wem es gehört

Neben den gerätespezifischen Schlüsseln gibt es in der ETS ein Projektpasswort. Dieses Passwort schützt das ETS-Projekt selbst und steuert den Zugang zu den gespeicherten Schlüsseln. Wer das Projektpasswort nicht kennt, kann das Projekt zwar öffnen, aber keine Secure-Geräte umprogrammieren oder neue Geräte hinzufügen.

Das Projektpasswort gehört dem Bauherrn. Das klingt selbstverständlich, ist es in der Praxis aber nicht. Wir sehen regelmässig Projekte, bei denen das Passwort beim Integrator liegt und der Bauherr es nie erhalten hat. Wechselt der Integrator, ist die Anlage faktisch gesperrt.

Die Lösung ist einfach, muss aber in der Ausschreibung stehen: Das Projektpasswort wird bei der Abnahme schriftlich an den Bauherrn übergeben, zusammen mit dem ETS-Projekt. Wer das Passwort festlegt, ist eine organisatorische Frage. Wir empfehlen, dass der Bauherr oder sein Vertreter das Passwort selbst wählt und dem Integrator für die Inbetriebnahme temporär zur Verfügung stellt. So liegt die Kontrolle von Anfang an beim Bauherrn.

Dieser Punkt hängt eng mit dem Thema des fünften Teils dieser Serie zusammen. «Das ETS-Projekt gehört dem Bauherrn» behandelt die Übergabe des gesamten Projekts, einschliesslich aller Schlüssel und Passwörter, als Teil der Abnahme.

Schlüsselübergabe als Vertragsbestandteil

Die Schlüsselverwaltung bei KNX Secure ist kein technisches Detail, das man der Inbetriebnahme überlassen kann. Sie ist ein organisatorischer Prozess, der von Anfang an geregelt sein muss. Wir empfehlen, folgende Punkte in der Ausschreibung und im Werkvertrag explizit aufzuführen.

Erfassung der FDSKs: Der Integrator erfasst alle FDSKs vor dem Einbau und dokumentiert sie gerätebezogen. Die Dokumentation ist Teil der Lieferdokumentation.

Projektpasswort: Das Projektpasswort wird bei der Abnahme schriftlich an den Bauherrn übergeben. Der Integrator darf das Passwort für die Dauer des Projekts verwenden, hat aber keinen Anspruch darauf, es dauerhaft zu behalten.

ETS-Projekt mit Schlüsseln: Das ETS-Projekt enthält alle projektspezifischen Schlüssel. Es wird als vollständige Datei übergeben, nicht als Export ohne Schlüssel. Wir behandeln diesen Punkt ausführlich in Teil 5 der Serie «KNX richtig planen».

Ersatzgeräteprozess: Das Betriebshandbuch beschreibt, wie bei einem Geräteaustausch vorzugehen ist, wer den FDSK erfasst, wer das ETS-Projekt aktualisiert und wer die Übergabe dokumentiert.

Aufbewahrung: Der Bauherr bewahrt das ETS-Projekt und das Projektpasswort sicher auf, getrennt voneinander und mit Zugriffsschutz. Eine Kopie gehört ins Gebäudedossier.

Geräteauswahl und Ausschreibungsformulierung

KNX Secure ist nicht bei allen KNX-Geräten verfügbar. Die Unterstützung hängt vom Gerät und vom Hersteller ab. Wer KNX Secure in der Ausschreibung fordert, muss sicherstellen, dass die geforderten Geräte auch tatsächlich Secure-fähig sind.

In der Praxis bedeutet das: Die Ausschreibung soll nicht nur «KNX Secure» fordern, sondern spezifizieren, welche Mechanismen für welche Gerätegruppen gelten. Für IP-Koppler und KNXnet/IP-Router ist IP Secure zu fordern. Für Aktoren und Sensoren auf dem Twisted-Pair-Bus ist Data Secure zu fordern, wenn der Schutzbedarf es verlangt.

Ein häufiger Fehler ist die pauschale Forderung nach KNX Secure ohne Differenzierung. Das führt dazu, dass Integratoren die Anforderung unterschiedlich interpretieren. Einer aktiviert IP Secure auf den Kopplern und lässt den Bus offen. Ein anderer fordert Data Secure auf jedem Gerät, auch dort, wo es keinen Mehrwert bringt. Klare Vorgaben in der Ausschreibung verhindern diese Unklarheiten.

Wir empfehlen ausserdem, in der Ausschreibung festzuhalten, dass die ETS-Konfiguration von KNX Secure durch den Integrator zu dokumentieren ist. Das umfasst, welche Geräte mit welchem Mechanismus gesichert sind, und eine Begründung für Ausnahmen. So ist im Betrieb nachvollziehbar, was gesichert ist und was nicht.

Auswirkungen auf Gateways und Schnittstellen

KNX Secure hat Auswirkungen auf alle Geräte und Systeme, die auf den KNX-Bus zugreifen. Das betrifft insbesondere Gateways zu anderen Protokollen.

Ein KNX-BACnet-Gateway, das Datenpunkte aus dem KNX-Bus in BACnet-Objekte übersetzt, muss auf den Bus zugreifen können. Ist Data Secure aktiviert, braucht das Gateway die entsprechenden Schlüssel und muss im ETS-Projekt als Teilnehmer mit den richtigen Zugriffsrechten konfiguriert sein. Nicht jedes Gateway unterstützt das. Wer ein Gateway einsetzt, muss vor der Ausschreibung prüfen, ob es Data Secure unterstützt.

Dasselbe gilt für Visualisierungen, die per KNXnet/IP auf den Bus zugreifen. Ist IP Secure aktiviert, muss die Visualisierungssoftware IP Secure unterstützen und mit den richtigen Zugangsdaten konfiguriert sein. Auch hier ist die Kompatibilität vor der Ausschreibung zu klären, nicht danach.

MQTT-Gateways, die KNX-Datenpunkte in einen Broker exportieren, stehen vor derselben Frage. Wir behandeln diese Schnittstellen in den Beiträgen «KNX und BACnet: Raumautomation an die Gebäudeleittechnik» (Teil 4 der Serie «Schnittstellen rund um KNX») und «KNX und MQTT: Gebäudedaten für Dashboards und Cloud» (Teil 5 der Serie «Schnittstellen rund um KNX»).

Die wichtigste Regel lautet: Jedes System, das auf einen KNX-Secure-Bus zugreift, muss im ETS-Projekt bekannt sein und die nötigen Schlüssel erhalten. Ein System, das nicht im Projekt konfiguriert ist, kommt nicht an die Daten. Das ist gewollt, muss aber bei der Planung berücksichtigt werden.

Der rote Faden zu unseren Fachbeiträgen

Dieser Artikel ist Teil 4 der Serie «KNX richtig planen». Die Grundlagen der Topologie, also wie Liniensegmente, Bereiche und IP-Backbone aufgebaut werden, behandelt Teil 2 «Topologie, Linien und IP-Backbone sauber aufbauen». Wer verstehen möchte, wie Gruppenadressen und Namenskonventionen als Fundament der Anlage dienen, findet das in Teil 3 «Gruppenadressen und Namenskonvention als Fundament».

Die technischen Hintergründe von KNX Secure, also wie AES-128 im CCM-Modus funktioniert, was Sequenzzähler leisten und wo die Grenzen des Standards liegen, erklärt der Einzelbeitrag «KNX Secure erklärt: Wie es funktioniert, was es bringt und wo die Grenzen liegen».

Die Übergabe des ETS-Projekts, einschliesslich aller Schlüssel und Passwörter, ist Thema von Teil 5 «Das ETS-Projekt gehört dem Bauherrn». Wer die Anlage nach der Übergabe in Betrieb nimmt, findet den Ablauf in «Inbetriebnahme und Abnahme einer KNX-Anlage» (Teil 1 der Serie «KNX in Betrieb und Bestand»).

Wer KNX Secure im Kontext der übergeordneten IT-Sicherheit in der Gebäudeautomation einordnen möchte, empfehlen wir den Beitrag «KBOB IKT-Sicherheit in der Gebäudeautomation: Was die neue Empfehlung für Planer und Betreiber bedeutet» sowie «BACnet/SC, Sicherheit & Migration: Standards & Schweizer Regulatorik» (Teil 5 der Serie «BACnet/SC: Sicherheit & Migration»).

Fazit

KNX Secure ist kein optionales Upgrade, das man nachträglich aktiviert. Es ist eine Planungsentscheidung, die Geräteauswahl, Ausschreibung, Inbetriebnahme und Betrieb beeinflusst. Sobald KNX über IP läuft oder von aussen zugänglich ist, gehört KNX Secure in die Ausschreibung, und zwar mit klarer Differenzierung zwischen Data Secure und IP Secure.

Die Schlüsselverwaltung ist dabei kein technisches Detail, sondern eine organisatorische Aufgabe. Der FDSK muss vor dem Einbau erfasst werden. Das Projektpasswort gehört dem Bauherrn. Das ETS-Projekt mit allen Schlüsseln wird bei der Abnahme vollständig übergeben. Und der Ersatzgeräteprozess muss im Betriebshandbuch stehen, damit er auch in fünf Jahren noch funktioniert.

Wer diese Punkte in der Ausschreibung regelt, schützt die Anlage und sichert die Handlungsfähigkeit des Bauherrn über den gesamten Lebenszyklus.

Sie haben Fragen dazu?

Sie planen eine KNX-Anlage und möchten wissen, welche Secure-Anforderungen in Ihre Ausschreibung gehören? Oder Sie haben eine bestehende Anlage und fragen sich, ob und wie KNX Secure nachgerüstet werden kann? Wir helfen Ihnen weiter. Schreiben Sie uns unter info@wenget.ch oder besuchen Sie wenget.ch.

Quellenverzeichnis

• ISO/IEC 14543-3: Informationstechnik, Heimelektronik-Systeme (HES), KNX (inkl. KNX Secure: AES-128 CCM, FDSK, Sequenzzähler, Data Secure und IP Secure)
• EN 50090: Elektrische Systemtechnik für Heim und Gebäude (ESHG), KNX-Normenreihe
• EN ISO 22510 (KNXnet/IP): Kommunikation über IP-Netze, Tunneling und Routing
• KNX Association (Brüssel): Markeninhaberin der eingetragenen Marken KNX und ETS; Landesorganisation Schweiz: KNX Swiss
• Eigene Projekterfahrung der WENGET GmbH aus KNX-Planung, Ausschreibungsbegleitung und Inbetriebnahme