Mdt Sicherheitsmodul

[Tipi]

Also nochmal, wo wird das Passwort eingegeben?
Im Sicherheitsmodul ist ja ein Passwort, wo wird dieser verlangt?

[xrk]

Das mit der Verwendung von einem Kennwort ist Optional beim Sicherheitsmodul. Ich würde abraten damit zu Experimentieren bevor Du nicht das Grundlegende verstanden hast und Sicherheitsmodul sonst problemlos schon am laufen hast.

Falls es soweit ist, wäre das Prozedere folgender: 1) Du parametrierst den Sicherheitsmodul mit von Dir ausgesuchtem Kennwort (im Applikation unter Sicherheitsfunktionen) und 2) den gleichen Kennwort parametrierst Du in dem Gerät, womit Du den Sicherheitsmodul unscharf schalten willst als Ausgabe (z.B. ein KNX-Taster, oder ein Visu o.ä.) mit 14-Byte Datentyp (DPT 16).

[tsb2001]

Also ich hab das Ding noch nie in der Hand gehabt, aber die Anleitung ist doch deutlich:

Man kann dem Gerät über Bus mit dem Kommunikationsobjekt 229 die im Sicherheitsmodul hinterlegten Passwörter über KNX übertragen und somit:

• den Sicherheitsmodus aktivieren
• den Sicherheitsmodus deaktivieren
• die Alarmquittierung veranlassen

Mehr nicht...

Das ist nichts anderes, als eine Freigabemöglichkeit (Steuerung) zur Busprogrammierung aus der Ferne, entweder über Passwort oder als 1-Bit-Objekt, damit man nicht zu dem Gerät laufen muss.

[Tipi]

Danke dir Xrk.

Ich habe einen Gt2 vom Mdt, mit dem wollte ich die freigabe machen. Jetzt verstehe ich nicht wo ich beim Gt2 einen Passwort eingeben soll? Das ist derzeit mein Problem

[xrk]

Ich glaube, GT2 unterstützt nicht das Aussenden einer DPT 16 Nachricht (14-Byte Datenfolge), daher nur mit GT2 geht es leider nicht.

Es würde gehen, z.B. mit Hilfe einer Logikengine, dessen DPT16 Ausgabe Du dann z.B. über GT2 triggerst (im Detail könnte GT2 ein DPT1 Nachricht an das Logikengine schicken, das Logikengine würde nach Eintreffen dieser Nachricht wiederrum ein DPT16 Telegramm an das Sicherheitsmodul aussenden).

[DerStandart]

Wenn ich #14 richtig verstanden habe, muss es nicht zwingend DPT16 sein, sondern es kann auch DPT1 sein.

Aber ich glaube, vorerst müsste noch ein kleines Verständnisproblem auf Layer 8 gelöst werden.

[tsb2001]

Wenn ich aber schon ein Passwort in einer Logikengine im Klartext speichere, um das über einen Ein-Bit-Befehl zu triggern, kann ich mir das Passwort auch sparen und direkt den Befehl an das Sicherheitsmodul senden. Das kann ja schließlich auch die Ein-Bit-Variante verarbeiten.

Sinnig ist das doch lediglich, wenn ich das Passwort in einer Visu bei Bedarf eingebe und das dann per KNX zum Modul als Telegramm sende.

[DirtyHarry]

Wenn ich aber schon ein Passwort in einer Logikengine im Klartext speichere, um das über einen Ein-Bit-Befehl zu triggern,

Wenn der Button dann nur in der Passwortgeschützten Visu ist (und nicht über den Bus auslösbar ist), lass ich mir das noch gefallen. Ansonsten gebe ich dir Recht.

[xrk]

DerStandart, tsb2001, DirtyHarry - Ihr habt alle Recht, man kann den Sicherheitsmodus von SCN-SAFE.01 auch mit DPT1 (d.h. 1 Bit Nachticht) Ein- und Ausschalten (KO 227). In diesem Fall aber ohne Kennwortübertragung. Sicherheitsmodul wird üblicherweise in "unsicheren" Linie installiert und mit DPT1 ist Manipulation einfacher (hier nehme ich an, dass Data Secure nicht verwendet wird, aktuelle V.01 des SCN-SAFE unterstützt es auch noch nicht).

Mit Konversion zu DPT16, wie in #20 von mir oben vorgeschlagen, wäre meiner Meinung nach eine höhere Sicherheit gegen Manipulation gegeben. Voraussetzungen sind, dass das zu triggernde Gerät (hier bei Tipi GT2) und das Konversionsgerät (=Logikengine) in sicheren Innenlinie untergebracht sind. Über unsichere Außenlinie wird "Kennwort" mit DPT16 übertragen (14-byte Telegramm an Sicherheitsmoduls KO 229).

Am sichersten wäre überhaupt kein (Ein-/)Ausschalten des Sicherheitsmodi über den Bus zuzulassen und dies ausschließlich über physikalische Knöpe am Sicherheitsmodul zu erlauben (angenommen, Sicherheitsmodul liegt nicht im gut/öffentlich zugänglichen Verteiler. Dies wäre sowieso sinnlos, da man den Sicherheitsmodul einfach vom Bus so trennen könnte).

Prinzipiell kann der Bösewicht ggf. lang genug die unsichere Linie monitoren/lauschen und so auch den im Klartext übertragenen "Kennwort" mithören und es danach selber verwenden um den Sicherheitsmodi auszuschalten. Daher, ohne Freischaltung von solchem Freigabe über Bus, benötigt man zwingend physikalischen Zugang zu KNX-Verteiler wo Sicherheitsmodul untergebracht ist. In einer öffentlichen Gebäude/Gaststätte/Hotel würde ich den Sicherheitsmodul immer ohne Busfreischaltung parametrieren, auch wenn dies die Fernwartung dadurch erschwert.

[Hantago]

Hallo,

wie ist das denn mit mehreren Liniensegmenten? Reicht ein SCN-SAFE pro Linie oder brauche ich pro Segment einen eigenen? Hab dazu in der Doku nichts gefunden.

Danke

[xrk]

Da es physikalisch in TP-Linie die dominante Bits setzt um Telegramme zu unterbinden, muss jede zu schützende TP-Linie eigenen SCN-SAFE bekommen.

[Hantago]

Jede Linie ist klar... aber auch jedes durch Linienverstärker abgetrennte Liniensegment? Hab nur eine Linie mit 3 Segmenten.

[xrk]

Häufige LV-Vertreter (eigentlich meist LK, die Filtertabellen nicht verwenden und alles weiterleiten) bufferen Telegramme und leiten diese üblicherweise Zeitverzögert weiter. Ob dabei beim Parametrieren in anderen Segmenten zu beabsichtigten Störung durch SCN-SAFE kommt, ist in der Tat eine gute Frage.