DE102008009691A1 - Verfahren für die Gebäudeautomatisierung - Google Patents

Verfahren für die Gebäudeautomatisierung Download PDF

Info

Publication number
DE102008009691A1
DE102008009691A1 DE102008009691A DE102008009691A DE102008009691A1 DE 102008009691 A1 DE102008009691 A1 DE 102008009691A1 DE 102008009691 A DE102008009691 A DE 102008009691A DE 102008009691 A DE102008009691 A DE 102008009691A DE 102008009691 A1 DE102008009691 A1 DE 102008009691A1
Authority
DE
Germany
Prior art keywords
data
standard
standard message
transmitted
security
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102008009691A
Other languages
English (en)
Inventor
Thomas Dr.-Ing. Weinzierl
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
WEINZIERL ENGINEERING GmbH
Original Assignee
WEINZIERL ENGINEERING GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by WEINZIERL ENGINEERING GmbH filed Critical WEINZIERL ENGINEERING GmbH
Priority to DE102008009691A priority Critical patent/DE102008009691A1/de
Publication of DE102008009691A1 publication Critical patent/DE102008009691A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/04Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0423Input/output
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H05ELECTRIC TECHNIQUES NOT OTHERWISE PROVIDED FOR
    • H05BELECTRIC HEATING; ELECTRIC LIGHT SOURCES NOT OTHERWISE PROVIDED FOR; CIRCUIT ARRANGEMENTS FOR ELECTRIC LIGHT SOURCES, IN GENERAL
    • H05B47/00Circuit arrangements for operating light sources in general, i.e. where the type of light source is not relevant
    • H05B47/10Controlling the light source
    • H05B47/105Controlling the light source in response to determined parameters
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/26Pc applications
    • G05B2219/2642Domotique, domestic, home control, automation, smart house
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/30Nc systems
    • G05B2219/36Nc in input of data, input key till input tape
    • G05B2219/36542Cryptography, encrypt, access, authorize with key, code, password
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80Wireless
    • H04L2209/805Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Lock And Its Accessories (AREA)

Abstract

Es wird ein Verfahren für die Gebäudeautomatisierung vorgeschlagen, bei dem Standardnachrichten (5, 7) durch Sicherheitsdaten (6) erweitert werden, mit denen sich die Herkunft und die Nachrichteninhalte der Standardnachrichten (5, 7) authentifizieren lassen. Die Sicherheit, insbesondere bei der drahtlosen Übertragung von Daten im Rahmen der Gebäudeautomatisierung, wird dadurch wesentlich erhöht, ohne dass die Kompatibilität mit dem bestehenden Standard beeinträchtigt wird.

Description

  • Die Erfindung betrifft ein Verfahren für die Gebäudeautomatisierung, bei dem Daten zwischen Geräten mithilfe einer Standardnachricht übertragen werden, die von einem empfangenden Gerät ohne Sicherheitsimplementierung auswertbar ist.
  • Ein derartiges Verfahren ist beispielsweise die Funkübertragung von Steuerdaten zwischen Geräten der Gebäudeautomatisierung mithilfe des KNX-Standards. KNX ist ein offener Standard für die Vernetzung und Steuerung von Gebäudetechnik. KNX beinhaltet die Medien Twisted Pair, Powerline, IP (Ethernet) und Funk. Der Anwendungsbereich konzentriert sich auf Steuerungsaufgaben im Gebäude. KNX ist unter anderem geeignet, die Beleuchtung, Jalousien oder auch das Raumklima zu steuern. KNX ist ein Europäischer und internationaler Standard. Die wesentlichen Standards sind in Tabelle 1 aufgelistet.
  • An Installationsorten, an denen keine Leitungen eingesetzt werden können, bietet KNX-RF (Radio Frequency, Funk) die Möglichkeit, Daten drahtlos zu übertragen. Im aktuellen KNX Standard ist nur die Absicherung der Daten gegen Übertragungsfehler mit Hilfe von Prüfsummen vorgesehen. Maßnahmen gegen die gezielte Beeinflussung von außen sind nicht vorgesehen. Gerade bei Funk als offenem Medium, ist die Sicherheit ein wichtiges Qualitätsmerkmal für das System.
  • Ausgehend von diesem Stand der Technik liegt der Erfindung die Aufgabe zugrunde, ein Verfahren für die Gebäudeautomatisierung zu schaffen, bei der der Datenaustausch über ein Datennetz, insbesondere über Funk, gegen unberechtigte Eingriffe geschützt ist.
  • Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des unabhängigen Anspruchs gelöst. In davon abhängigen Ansprüchen sind vorteilhafte Ausgestaltungen und Weiterbildungen angegeben.
  • Bei dem Verfahren werden Daten zwischen den Geräten für die Gebäudeautomatisierung mithilfe von Standardnachrichten übertragen, die von einem empfangenden Gerät ohne Sicherheitsimplementierung auswertbar ist. Nach dem Senden der Standardnachricht werden weitere, der Authentifizierung des Telegramms dienende Sicherheitsdaten ausgesendet. Mithilfe der Sicherheitsdaten lässt sich die Herkunft der Standardnachricht verifizieren. Dadurch wird verhindert, dass ein Angreifer Standardnachrichten an Geräte übermitteln kann und dadurch das System der Gebäudeautomatisierung beeinflussen kann. Gleichzeitig bleibt jedoch die Konformität mit bestehenden Standards bestehen, da die eigentliche Standardnachricht unverschlüsselt bleibt und von herkömmlichen Geräten, die den herkömmlichen Standard implementieren, gelesen werden kann. Die Kompatibilität zu bestehenden Standards bleibt daher gewahrt, aber Angriffe von Außen werden wesentlich erschwert. Insbesondere, wenn die Übertragung von Daten zwischen Geräten auf drahtlosem Wege erfolgt, ist das Verfahren von großem Vorteil, da Funk ein offenes Medium darstellt, das von Angreifern grundsätzlich ohne Eingriffe in die Infrastruktur beeinflusst werden kann.
  • Vorzugsweise handelt es sich bei den Sicherheitsdaten um Signaturdaten, mit denen die Authentifizierung der Standardnachricht durchgeführt werden kann. Mithilfe von Signaturen lässt sich die Authentizität des Senders und des Inhalts des Telegramms sicherstellen.
  • Vorzugsweise wird eine die Standardnachricht authentifizierende digitale Signatur verwendet, die anhand von der Standardnachricht zugeordneten Daten bestimmt wird. Die Signatur kann insbesondere anhand eines Schlüssels und anhand von die Abfolge der Standardnachrichten beschreibenden Abfolgedaten bestimmt werden. Durch die Berücksichtigung von der Standard nachricht zugeordneten Daten, insbesondere durch die Berücksichtigung der Abfolgedaten kann verhindert werden, dass die Standardnachricht einschließlich Sicherheitsdaten von Dritten mitgehört und anschließend zu Manipulationszwecken wiederholt wird.
  • Bei einer bevorzugten Ausführungsform enthält die Standardnachricht neben Standardnutzdaten Standardkontrolldaten. Ungenutzte Bestandteile der Standardkontrolldaten können dazu verwendet werden, dem empfangenden Gerät die nach der Übermittlung der Standardnachricht erfolgende Übertragung von Sicherheitsdaten anzuzeigen. Auf diese Weise können empfangende Geräte, die das vorgeschlagene Verfahren implementieren, auf den Empfang der Sicherheitsdaten vorbereitet werden.
  • Die Standardkontrolldaten können darüber hinaus auch Längenangaben zur Länge der Standardnachricht enthalten, aus denen das empfangende Gerät die Länge der Standardnachricht und den Beginn der Übertragung der Sicherheitsdaten entnehmen kann. Die Längenangaben erfolgen dabei vorzugsweise standardkonform, so dass das Telegramm auch von herkömmlichen Geräten gelesen werden kann, die das vorgeschlagene Verfahren nicht unterstützen.
  • Um die Übertragung der Sicherheitsdaten zu bewerkstelligen, können in den Sicherheitsdaten neben Sicherheitsnutzdaten, die sich auf die Authentifizierung der Standardnachricht beziehen, Sicherheitskontrolldaten enthalten sein, die beispielsweise die Länge der Sicherheitsdaten angeben oder die Datensicherheit bei der Übertragung der Sicherheitsdaten gewährleisten. Letzteres kann beispielsweise mithilfe von Prüfsummen bewerkstelligt werden, die anhand der Sicherheitsdaten gebildet werden. Daneben können die Sicherheitsdaten auch Informationen zur Klassifizierung der in den Sicherheitsdaten enthaltenen Sicherheitsnutzdaten umfassen.
  • Bei einer bevorzugten Ausführungsform werden beim Empfang durch ein Gerät mit Sicherheitsimplementierung vom empfangenden Gerät erzeugte Abfolgedaten zur Validierung der Standardnachrichten verwendet. Diese Angaben können Nachrichtenzählerstände sein, die ausgewertet werden. Dadurch wird es möglich, Angriffe zu erkennen, bei denen gültige Standardnachrichten von fremden Geräten wiederholt werden.
  • Die zur Validierung der Sicherheitsdaten erforderlichen Informationen werden vorzugsweise bei der Konfiguration der Geräte den Geräten zur Verfügung gestellt. Während des kurzen Zeitfensters der Konfiguration kann die Übertragung der für die Validierung der Sicherheitsdaten erforderlichen Informationen ungeschützt erfolgen.
  • Die Sicherheitsdaten können übertragen werden, indem die Synchronisierung auf die Standardnachricht für die Übertragung der Sicherheitsdaten verwendet wird und die Sicherheitsdaten an die Standardnachricht angehängt werden. Dies bietet sich insbesondere dann an, wenn Funk als Medium verwendet wird, da dort die Länge der Standardnachrichten festen Regeln unterworfen ist und die Standardnachricht folglich ohne weiteres von den Sicherheitsdaten unterschieden werden kann.
  • Daneben ist es möglich, dass die Sicherheitsdaten als Nutzdaten in einer weiteren Standardnachricht übertragen werden. Diese Vorgehensweise bietet sich insbesondere dann an, wenn ein Anhängen der Sicherheitsdaten an die Standardnachricht mit bestehenden Geräten nicht kompatibel wäre. Ein Grund kann sein, dass das Protokoll unmittelbar nach der Standardnachricht ein Zeitfenster für die Bestätigung (Acknowledge) vorsieht.
  • Vorzugsweise werden als Standardnachrichten Telegramme gemäß dem KNX-Standard verwendet, da damit ein verbreiteter Standard für die Gebäudeautomatisierung zur Verfügung steht.
  • Weitere Vorteile und Eigenschaften der Erfindung gehen aus der nachfolgenden Beschreibung hervor, in der Ausführungsbeispiele der Erfindung anhand der Zeichnung im Einzelnen erläutert werden. Es zeigen:
  • 1 die Darstellung eines drahtlosen Datennetzes für die Gebäudeautomatisierung;
  • 2 die Darstellung eines Telegrammkopfes gemäß KNX-RF-Standard;
  • 3 die Datenstruktur eines ersten Datenblocks eines Telegramms gemäß KNX-RF-Standard;
  • 4 die Datenstruktur eines zweiten Datenblocks eines Telegramms gemäß KNX-RF-Standard;
  • 5 die Datenstruktur eines modifizierten ersten Datenblocks eines Telegramms; und
  • 6 die Datenstruktur eines Datenblocks, der an das Telegramm angehängt wird.
  • Im Folgenden wird das Verfahren beispielhaft am Medium KNX-RF erläutert, da bei Funk Sicherheitsaspekte von besonderer Bedeutung sind. Zudem bietet das KNX-RF Protokoll die Möglichkeit, Sicherheitsinformationen unmittelbar an das Telegramm anzuhängen wie dies später erläutert wird. Gundsätzlich kann das nachfolgend beschriebene Verfahren aber auch im Rahmen von KNX-TP, KNX-Powerline oder KNX-IP verwendet werden.
  • 1 zeigt die Grundstruktur eines Datennetzes 1 für die Heimautomatisierung, bei dem Daten auf drahtlosem Wege per Funk übertragen werden. Das Datennetz 1 umfasst einerseits Sensoren 2. Die Sensoren 2 können beispielsweise Umgebungssensoren, wie zum Beispiel Lichtsensoren, Temperatursensoren, Feuchtesensoren, Bewegungsmelder oder ähnliche Sensoren sein oder aber auch von Schaltern gebildet sein. Weiterhin umfasst das Datennetz 1 Aktoren 3 und 4, die dazu eingerichtet sind, Schaltvorgänge auszuführen. Bei dem in 1 dargestellten Datennetz 1 werden Daten zwischen den Sensoren 2 und den Aktoren 3 und 4 gemäß dem KNX-RF-Standard übertragen.
  • KNX-RF definiert ein Protokoll, um innerhalb des Datennetzes 1 Daten drahtlos zu übertragen. Die Funkschnittstelle von KNX-RF entspricht den gesetzlichen Vorgaben für Funkgeräte kurzer Reichweite (= Short Range Devices). Die Funkübertragung findet bei einer Mittenfrequenz von 868,3 MHz. Für die Modulation wird eine Frequenzumtastung verwendet, die im Bereich von +–50 kHz liegt. Für die Codierung wird eine Machester Codierung mit einer Symbolrate (= chip rate) von 32.768 Symbolen pro Sekunde verwendet. Die Sendeleistung liegt in der Regel zwischen 1–25 mW.
  • Wie nachfolgend noch im Einzelnen beschrieben wird, erfolgt die Datenübertragung vom Sensor 2 zu den Aktoren 3 und 4 gemäß dem KNX-RF-Standard. Im vorliegenden Fall erfolgt die Datenübertragung zur Laufzeit mithilfe von Laufzeittelegrammen 5, an die, wie im vorliegenden Fall, ein Signaturblock 6 angehängt ist. Mithilfe des Signaturblockes 6 können im Laufzeittelegramm 5 enthaltene Daten vom Aktor 3 auf nachfolgend noch näher beschriebene Weise authentifiziert werden.
  • Mithilfe der Laufzeittelegramme 5 können insbesondere Nutzdaten übertragen werden. Zum Beispiel können Nutzdaten zum Schalten von Licht oder zum Senden der Raumtemperatur mithilfe der Laufzeittelegramme 5 übermittelt werden. Daneben sind gemäß dem KNX-RF-Standard Managementtelegramme 7 und 8 vorgesehen, an die bei Bedarf ebenfalls der Sicherheitsblock 6 angehängt werden kann.
  • Es sei angemerkt, dass Managementtelegramme 7 und 8 vorzugsweise zur Konfigurationszeit ausgetauscht werden. Im soge nannten Drucktastenmodus (Easy Push Button-Modus) werden Drucktasten 9 und 10 am Sensor 2 und Aktor 4 betätigt, durch die der Sensor 2 und der Aktor 4 in den Konfigurationsmodus umgeschaltet und die Managementtelegramme 7 und 8 ausgetauscht werden können.
  • Im Folgenden wird das Datenformat der Laufzeittelegramme 5 und der Managementtelegramme 7 und 8 sowie die Funktion des Sicherheitsblocks 6 anhand der 2 bis 6 näher erläutert. Im Folgenden werden beide die Laufzeittelegramme 5 und die Managementtelegramme 7 beide kurz als Telegramme bezeichnet. Die in den 2 bis 6 vorgenommene Darstellung der Datenstruktur der Telegramme für KNX-RF ist stark vereinfacht und dient nur der Erläuterung des Verfahrens. Details zur Datenstruktur der Telegramme sind in EN 50090-5-5 zu finden.
  • Das Datenformat von Telegrammen für KNX-RF besteht aus mehreren Elementen. Gemäß 1 startet jedes Telegram mit einem Preheader 11, auf den sich der Empfänger synchronisiert.
  • Nach dem Preheader folgt der in 3 dargestellte erste Block 12. Der erste Block 12 besteht immer aus zehn Datenbytes und besitzt eine eigene Prüfsumme mit zwei Bytes (CRC hi, CRC 10). Daneben enthält der erste Block 12 weitere Kontrolldaten. Die Kontrolldaten umfassen die ersten vier Byte und beginnen mit einem Byte, das eine Längenangabe (Length) zur Länge des Telegramms enthält. Daran schließen sich zwei weitere Byte (C-Field, ESC), die die Art der Datenübertragung kennzeichnen. Das folgende Byte (Ctrl) wird für die Kontrolle der Datenübertragung nach dem KNX-RF Standard verwendet. Daran schließen sich mit SN bezeichnete Byte an, die der Angabe der Seriennummer oder der Domgin-Adresse des Absenders dienen.
  • Die eigentlichen Nutzdaten folgen in einem in 4 dargestellten zweiten Block 13, der maximal eine Länge von sechzehn Bytes plus zwei Bytes (CRC hi, CRC lo) Prüfsumme haben kann. Der zweite Block beginnt ebenfalls mit Kontrolldaten. Zu Beginn wird in einem Byte (KNX-Ctrl) der Typ des Datenblocks 13 angezeigt. In den beiden folgenden Byte (Src hi, Src 10) finden sich Angaben zur individuellen Adresse des Senders. Daran schließen sich weitere zwei Bytes (Dest hi, Dest 10) an, die die individuelle Adresse oder Gruppenadresse des Empfängers enthalten. Das nächstfolgende Byte (L/NPCI) enthält Angaben über die Adressenart, Zähler für die Routingvorgänge und Ähnliches. Die folgenden Bytes (TPCI, APCI) enthalten schließlich Information zum Transport- und Anwendungsprotokoll. In den letzten sechs Bits des letzten Bytes (APCI) sind dann in diesem Beispiel die Nutzdaten enthalten.
  • Bei längeren Nutzdaten stehen die Daten in den Feldern DATA. Zudem können weitere Datenblöcke mit Nutzdaten folgen. Die Codierung der Daten ab dem zweiten Block 13 entspricht im Wesentlichen dem KNX Telegrammformat, wie es auch für die anderen KNX Medien definiert ist. Dieses Telegrammformat wird jeweils um medienspezifische Informationen ergänzt.
  • Der Schutz vor Manipulation von außen wird nun durch eine digitale Signatur der Telegramme erreicht. Ein Empfänger kann durch die Auswertung der Signatur entscheiden, ob das Telegramm tatsächlich von einem berechtigten Kommunikationspartner stammt oder nicht. Für die Signatur kann beispielsweise ein Streuwert (= Hash-Wert) verwendet werden, der anhand eines Schlüssels und eines Telegrammzählers berechnet wird. Der Streuwert kann dann als Signatur an den Empfänger übertragen werden, der anhand des Schlüssels und eigenen Telegrammzählerstands den Streuwert seinerseits berechnen und mit dem übermittelten Streuwert vergleichen kann.
  • In den Streuwert können je nach Algorithmus auch Daten des Telegramms und weitere Fülldaten eingerechnet werden. Während der Algorithmus für die Verschlüsselung öffentlich bekannt sein muss, dürfen der Schlüssel und der Stand des Telegrammzählers in der Regel nur dem Sender und dem Empfänger oder den Empfängern bekannt sein, zwischen denen die Datenübertragung stattfinden soll.
  • Durch die Einbeziehung der Daten des Standardtelegrams in die Berechnung des Streuwerts, können diese vom Empfänger auf Unverfälschtheit überprüft werden. Mit Hilfe des bereits erwähnten Telegrammzählers kann verhindert werden, dass Telegramme von Dritten mitgehört und anschließend zu Manipulationszwecken wiederholt werden. Durch das Übermitteln des aktuellen Telegrammzählers bei der Herstellung einer Verbindung (Linking), werden die Telegrammzähler von Empfänger und Sender abgeglichen. Damit ist der Empfänger bereit zum Empfang des Telegramms mit dem nächsten Zählerwert. Der Empfänger sollte alle Telegramme annehmen, wenn der enthaltene Zählerwert dem gespeicherten Wert entspricht oder nicht wesentlich größer ist. Damit ergibt sich für den Zählerwert ein Akzeptanzfenster für den Fall, dass ein oder mehrere Telegramme nicht empfangen werden. Beim Empfang eines gültigen Telegramms wird der enthaltene Zählerwert im Empfänger als aktueller Wert übernommen. Liegt der empfangene Zählerwert außerhalb des Akzeptanzfensters ist das Telegramm als Angriff zu werten. Bei einem Angriff kann der Empfänger einen Alarm auslösen und/oder blockieren, bis ein erneuter Abgleich, zum Beispiel durch eine Wiederholung des Aufbaus einer Verbindung, durchgeführt wird.
  • Daneben kommen für die Ermittlung der Signatur weitere Sicherheitsalgorithmen infrage. Bei der Auswahl des Sicherheitsalgorithmus und bei der Bestimmung der Schlüssellänge ist insbesondere die verfügbare Rechenleistung und Speicherplatz zu berücksichtigen.
  • Das Datenformat der Telegramme gemäß KNX-RF soll weitgehend unverändert bleiben. Nur ein Bit (Flag) im Telegramm soll anzeigen, dass dem Telegramm Sicherheitsdaten angehängt sind. Dieses Flag soll hier als SEC-Flag bezeichnet werden. Als Position bietet sich das höchstwertiges Bit (= MSB = Most Significant Bit) des Bytes "RF-Ctrl" an, welches in dem ersten Block 12 eines Telegramms übertragen wird. Dieses Bit ist bisher reserviert und wird bisher stets auf "0" gesetzt. In 5 ist ein entsprechender modifizierter erster Block 14 dargestellt.
  • Die Sicherungsdaten folgen stets nach dem letzten Block eines KNX-RF Telegrams in Form des in 6 im Detail dargestellten zusätzlichen Sicherheitsblocks 6. Dieser Sicherheitsblock 6 enthält neben den Sicherheitsnutzdaten (Sec) eine eigene Längeninformation (Sec-Len) und ein Klassifikationsbyte (Sec-Ctrl) enthalten, das den Typ der Sicherungsdaten klassifiziert.
  • Damit Übertragungsfehler, insbesondere Bit-Fehler, in KNX-RF korrigiert werden können, sollte für den zusätzlichen Sicherheitsblock 6 eine eigene Prüfsumme (CRC hi, CRC lo) gebildet werden. Dazu bietet sich dasselbe Generatorpolynom an wie für die anderen Blöcke 12 und 13. Die Größe des Sicherheitsblocks 6 soll die Länge von 16 + 2 Bytes nicht überschreiten.
  • Damit Geräte über KNX Nutzdaten austauschen können, müssen deren Datenpunkte miteinander verknüpft werden. Beispielsweise müssen sich der Sensor 2 und die Aktoren 3 und 4 im Rahmen der Verbindungsherstellung kennen lernen. Für die Verbindungsherstellung bei KNX gibt es verschiedene Modi. Im Folgenden wird insbesondere auf den so genannten "Easy Push Button-Modus" eingegangen, da das hier beschriebene Verfahren insbesondere bei diesem Modus besondere Vorteile hat.
  • Im Easy Push Button-Modus (einfacher Modus mit Drucktasten) können zwei oder mehrere Geräte ohne zusätzliche Hilfsmittel in Betrieb genommen werden. Der Sensor 2, zum Beispiel ein Tastsensor zum Lichtschalten, und der Aktor 4, zum Beispiel ein Lichtaktor, werden jeweils durch Tastendruck auf die beiden Drucktasten 9 und 10 an beiden Geräten in den so genannten Linkmodus gesetzt und miteinander gekoppelt oder gelinkt.
  • Der Sensor 2 und der Aktor 4 linken sich, indem Sie sich gegenseitig die Sendeadressen der einzelnen Datenpunkte mitteilen. Hierbei wird jeder potentielle Link durch ein separates Telegramm übertragen. Der Inhalt entspricht etwa: "Habe einen Ausgang Schalten auf Adresse 1234". Der empfangende Aktor 4 entscheidet dann, ob er diese Adresse einem geeigneten Eingang zuordnen kann.
  • Um in diesem Modus eine gesicherte Verbindung (Link) herzustellen, müssen für jeden Datenpunkt sowohl ein Schlüssel als auch der Telegrammzähler übermittelt werden. Die zusätzlichen Informationen können wie oben beschrieben an die der Herstellung einer Verbindung (Linking) dienenden Managementtelegramme 7 angehängt werden. Durch das SEC-Bit kann ein Gerät anzeigen, dass die entsprechenden Informationen in einem weiteren Block, dem Sicherheitsblock 6, folgen. Die Sicherungsdaten enthalten in diesem Fall keine Signatur, sondern den Schlüssel und den Telegrammzähler. Durch den Austausch der Schlüssel und dem Sicherheitszähler zwischen den Datenpunkten des Aktors 2 und des Sensors 4 wird gleichzeitig der Datenabgleich zwischen Sender und Empfänger bewerkstelligt.
  • Im laufenden Betrieb werden die KNX-RF Telegramme unverändert übertragen. Lediglich das SEC-Bit im ersten Block zeigt an, dass ein zusätzlicher Block mit Sicherheitsinformationen folgt. Bei Laufzeit-Telegrammen (zum Beispiel „Licht-Ein") beinhalten die Sicherheitsinformationen eine digitale Signatur.
  • Im laufenden Betrieb können die Geräte, die keine Authentifizierung kennen, sowohl ungesicherte als auch gesicherte Telegramme problemlos empfangen, wenn sie das SEC-Flag nicht auswerten. Der zusätzliche Sicherungsblock wird von diesen Geräten ignoriert, da er in der Längeninformation des Telegramms nicht angezeigt wird.
  • Wenn im anderen Fall ein gesicherter Aktor ein Telegramm ohne Signatur (Sicherheitsblock) empfängt, kann im Gerät entschieden werden, ob das Telegramm für den jeweiligen Datenpunkt angenommen wird oder nicht.
  • Anstatt den Sicherheitsblock 6 direkt an das Telegramm anzuhängen, werden bei einem abgewandelten Verfahren die Sicherheitsinformationen in einem separaten Telegramm im Anschluss an das Standardtelegramm, zum Beispiel das Laufzeittelegramm 5 oder das Managementtelegramm 7, gesendet. Ein solches Telegramm mit Sicherheitsinformationen soll stets die gleiche Adressierungsart und die gleiche Zieladresse wie das zu sichernde Standardtelegramm verwenden. Ferner sollten die Berechnung der Sicherheitsdaten auch die Nutzdaten des ersten Standardtelegramms einbeziehen, da in sonst kein unmittelbarer Zusammenhang zwischen Standardnachricht und Sicherheitsdaten vorhanden ist, so dass es einem Angreifer grundsätzlich möglich wäre, Teile des ersten Standardtelegramms zu ersetzen. Durch eine Signatur, die auch die Nutzdaten des Standardtelegramms berücksichtigt wird diese Möglichkeit ausgeschlossen.
  • Um die Sicherheitsinformationen als solche zu kennzeichnen, kann ein eigener APCI-Service (Application Protocol Control Information-Service) für diesen Zweck reserviert werden. Bei den APCI-Services handelt es sich um Kennungen für die Servicefunktionen, die vom empfangenden Gerät unterstützt werden und die die übertragenen Nutzdaten verarbeiten. Im KNX Standard müssen neue APCI-Services von bestehenden Geräten ignoriert werden. Somit bleibt auch in diesem abgewandelten Ausführungsbeispiel die Kompatibilität gewährleistet.
  • Bei Medien, bei denen die zusätzlichen Sicherungsinformationen nicht angezeigt werden können, da zum Beispiel kein Bit verfügbar ist, kann die Sicherungsinformation vom Empfänger auch implizit angenommen werden, da ein Empfänger stets weiß, ob er Sicherungsinformation erwartet oder nicht. Kann eine erwartete Sicherungsinformation nicht empfangen werden, kann der Empfänger entsprechend reagieren, zum Beispiel das Telegramm verwerfen.
  • Durch das hier beschriebene Verfahren wird die Kompatibilität im KNX System erhalten und gleichzeitig die Sicherheit bei der Datenübertragung erhöht. Dabei bleibt auch die für den KNX-Standard typische Möglichkeit der Gruppenadressierung erhalten, da jeder Sender auch mit mehreren Empfängern verknüpft werden kann. Da der zusätzliche Informationsfluss in diesem Verfahren stets vom Sensor zum Aktor verläuft, schließt es unidirektionale Geräte, die nur senden können, ein. Diese sind vor allem bei Funksensoren, zum Beispiel Handsendern, üblich. Das Verfahren beinhaltet die Authentifizierung, nicht aber die Verschlüsselung der Daten.
  • Das hier beschriebene Verfahren stellt daher eine einfache, aber effektive Methode dar, mit der die Sicherung der Kommunikation mit Hilfe von Authentifizierung erreicht wird.
  • Abschließend sei noch darauf hingewiesen, dass Merkmale und Eigenschaften, die im Zusammenhang mit einem bestimmten Ausführungsbeispiel beschrieben worden sind, auch mit einem anderen Ausführungsbeispiel kombiniert werden können, außer wenn dies aus Gründen der Kompatibilität ausgeschlossen ist.
  • Schließlich wird noch darauf hingewiesen, dass in den Ansprüchen und in der Beschreibung der Singular den Plural einschließt, außer wenn sich aus dem Zusammenhang etwas anderes ergibt. Insbesondere wenn der unbestimmte Artikel verwendet wird, ist sowohl der Singular als auch der Plural gemeint. Tabelle 1
    EN Standard Nr. ISO/IEC Standard Nr. Inhalt
    50090-2-1 14543-2-1 Struktur für Heimautomatisierung; Einleitung und Gerätarität der Geräte.
    50090-3-2 14543-3-3 Anwendungsprofile
    50090-4-1 14543-3-1 Applikationsschicht
    50090-4-2 14543-3-2 Transport Schicht, Netzwerkschicht und allgemeine Teile der Sicherungsschicht
    50090-5-1 14543-3-5 Medienbeschreibung und medienabhängige Schichten-Powerline
    50090-5-2 14543-3-6 Medienbeschreibung und medienabhängige Schichten-Zweidrahtbus
    50090-5-5 14543-3-7 Medienbeschreibung und medienabhängige Schichten-Funk
    50090-7-1 14543-3-4 Konfigurationsprozeduren
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • - EN 50090-5-5 [0030]
    • - 50090-2-1 [0055]
    • - 14543-2-1 [0055]
    • - 50090-3-2 [0055]
    • - 14543-3-3 [0055]
    • - 50090-4-1 [0055]
    • - 14543-3-1 [0055]
    • - 50090-4-2 [0055]
    • - 14543-3-2 [0055]
    • - 50090-5-1 [0055]
    • - 14543-3-5 [0055]
    • - 50090-5-2 [0055]
    • - 14543-3-6 [0055]
    • - 50090-5-5 [0055]
    • - 14543-3-7 [0055]
    • - 50090-7-1 [0055]
    • - 14543-3-4 [0055]

Claims (21)

  1. Verfahren für die Gebäudeautomatisierung, bei dem Daten zwischen Geräten (2, 3, 4) mithilfe einer Standardnachricht (5, 7) übertragen werden, die von einem empfangenden Gerät (3, 4) ohne Sicherheitsimplementierung auswertbar ist, dadurch gekennzeichnet, dass nach dem Senden der Standardnachricht (5, 7) von einem sendenden Gerät (2) zu der Standardnachricht (5, 7) weitere Sicherheitsdaten (6) ausgesendet werden, die von einem empfangenden Gerät (3, 4) mit Sicherheitsimplementierung auswertbar sind.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass für die Sicherheitsdaten (6) eine die Herkunft der Standardnachricht authentifizierende digitale Signatur verwendet wird, die anhand von der Standardnachricht (5, 7) zugeordneten Daten bestimmt wird.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Signatur anhand eines Schlüssels und anhand von die Abfolge der Standardnachrichten (5, 7) beschreibenden Abfolgedaten bestimmt wird.
  4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Standardnachricht (5, 7) neben Nutzdaten Kontrolldaten enthält.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass in den Kontrolldaten der Standardnachricht (5, 7) die Übertragung von Sicherheitsdaten (6) angezeigt wird.
  6. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass die Kontrolldaten Längenangaben zur Länge des Standardtelegramms (5, 7) übertragen werden.
  7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass in den Sicherheitsdaten (6) neben Sicherheitsnutzdaten Sicherheitskontrolldaten enthalten sind.
  8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass in den Sicherheitskontrolldaten Längenangaben zur Länge der Sicherheitsdaten übertragen werden.
  9. Verfahren nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass in den Sicherheitskontrolldaten Informationen zur Klassifizierung der Sicherheitsdaten übertragen werden.
  10. Verfahren nach einem der Ansprüche 7 bis 9, dadurch gekennzeichnet, dass in den Sicherheitskontrolldaten die Übertragung sichernde Prüfdaten übertragen werden.
  11. Verfahren nach einem der Ansprüche 3 bis 10, dadurch gekennzeichnet, dass von einem empfangenden Gerät (3, 4) mit Sicherheitsimplementierung zur Validierung der empfangenen Standardnachricht (5, 7) im empfangenden Gerät (3, 4) erzeugte Abfolgedaten der Standardnachricht (5, 7) verwendet werden.
  12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass bei der Konfiguration der Geräte (2, 3, 4) Validierungsdaten für die Validierung der in den Sicherheitsdaten enthaltenen Sicherheitsnutzdaten übertragen werden.
  13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass bei der Konfiguration der Geräte (5, 7) ein Anfangszustand der die Abfolge der Standardnachrichten (5, 7) anzeigenden Abfolgedaten übertragen wird.
  14. Verfahren nach einem der Ansprüche 3 bis 13, dadurch gekennzeichnet, dass bei der Konfiguration der Geräte (5, 7) der zur Validierung der Signatur erforderliche Schlüssel übertragen wird.
  15. Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass die Synchronisierung auf die Standardnachricht für die Übertragung der Sicherdaten (6) verwendet wird und die Sicherheitsdaten (6) an die Standardnachricht (5, 7) angehängt werden.
  16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass die Standardnachricht (5, 7) eine Reihe von Datenblöcken (11, 12, 13) umfasst und die Sicherheitsdaten in einem weiteren Datenblock (6) an die Standardnachricht angehängt werden.
  17. Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass die Sicherheitsdaten als Nutzdaten in einer weiteren Standardnachricht (5, 7) übertragen werden.
  18. Verfahren nach einem der Ansprüche 1 bis 17, dadurch gekennzeichnet, dass die Daten auf drahtlosem Wege vom sendenden Gerät (2) zum empfangenden Gerät (3, 4) übertragen werden.
  19. Verfahren nach einem der Ansprüche 1 bis 18, dadurch gekennzeichnet, dass als Standardnachricht ein Telegramm gemäß dem KNX-Standard übertragen wird.
  20. Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass als Standardnachricht (5, 7) ein Telegramm gemäß dem KNX-RF-Standard übertragen wird.
  21. Gerät für die Gebäudeautomatisierung, dadurch gekennzeichnet, dass das Gerät als Sender (2) und/oder als Empfänger (3, 4) mit Sicherheitsimplementierung zur Teilnahme an einem Verfahren gemäß einem der Ansprüche 1 bis 20 eingerichtet ist.
DE102008009691A 2008-02-18 2008-02-18 Verfahren für die Gebäudeautomatisierung Withdrawn DE102008009691A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102008009691A DE102008009691A1 (de) 2008-02-18 2008-02-18 Verfahren für die Gebäudeautomatisierung

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102008009691A DE102008009691A1 (de) 2008-02-18 2008-02-18 Verfahren für die Gebäudeautomatisierung

Publications (1)

Publication Number Publication Date
DE102008009691A1 true DE102008009691A1 (de) 2009-08-20

Family

ID=40874081

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102008009691A Withdrawn DE102008009691A1 (de) 2008-02-18 2008-02-18 Verfahren für die Gebäudeautomatisierung

Country Status (1)

Country Link
DE (1) DE102008009691A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012025375A1 (de) * 2010-08-26 2012-03-01 Robert Bosch Gmbh Verfahren zum übertragen von sensordaten
WO2012031861A1 (de) * 2010-09-09 2012-03-15 Siemens Aktiengesellschaft Verfahren zum verarbeiten von nachrichten in einem kommunikationsnetz aus mehreren netzknoten
EP2571335A3 (de) * 2011-09-15 2014-06-18 Ingenium, Ingenieria Y Domotica S.L., Parque Tecnologico de Bewegungsmelder

Non-Patent Citations (17)

* Cited by examiner, † Cited by third party
Title
14543-2-1
14543-3-1
14543-3-2
14543-3-3
14543-3-4
14543-3-5
14543-3-6
14543-3-7
50090-2-1
50090-3-2
50090-4-1
50090-4-2
50090-5-1
50090-5-2
50090-5-5
50090-7-1
EN 50090-5-5

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012025375A1 (de) * 2010-08-26 2012-03-01 Robert Bosch Gmbh Verfahren zum übertragen von sensordaten
WO2012031861A1 (de) * 2010-09-09 2012-03-15 Siemens Aktiengesellschaft Verfahren zum verarbeiten von nachrichten in einem kommunikationsnetz aus mehreren netzknoten
US9021588B2 (en) 2010-09-09 2015-04-28 Siemens Aktiengesellschaft Method for processing messages in a communication network comprising a plurality of network nodes
EP2571335A3 (de) * 2011-09-15 2014-06-18 Ingenium, Ingenieria Y Domotica S.L., Parque Tecnologico de Bewegungsmelder

Similar Documents

Publication Publication Date Title
DE102014224694B4 (de) Netzwerkgerät und Netzwerksystem
EP3138258B1 (de) Verfahren zur erzeugung eines geheimnisses oder eines schlüssels in einem netzwerk
DE60319722T2 (de) Heim-endgerätevorrichtung und kommunikationssystem
DE102004016580B4 (de) Verfahren zur Übertragung von Daten in einem Ad Hoc Netzwerk oder einem Sensornetzwerk
EP3298722A1 (de) Verfahren zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
DE102008009691A1 (de) Verfahren für die Gebäudeautomatisierung
DE102016208451A1 (de) Verfahren zur Erzeugung eines Geheimnisses oder eines Schlüssels in einem Netzwerk
EP3520351B1 (de) Vorrichtung und verfahren zur durchgängigen und medienübergreifenden übertragung von kommunikationsprotokollen ohne protokollumsetzung
DE102013215577A1 (de) Verfahren und System zur geschützten Gruppenkommunikation mit Sender-Authentisierung
WO2018215209A1 (de) Verfahren und vorrichtung zum schutz einer kommunikation zwischen mindestens einer ersten kommunikationseinrichtung und wenigstens einer zweiten kommunikationseinrichtung insbesondere innerhalb eines kommunikationsnetzwerkes einer industriellen fertigung und/oder automatisierung
DE102006034066B4 (de) Verfahren zur Übertragung von Nutzdaten zwischen Teilnehmern und Teilnehmer-Einrichtungen hierfür
EP2685696A1 (de) Verfahren zum sicheren Betrieb von Verbundnetzen, insbesondere von Windpark- oder anderen ausgedehnten Netzen
EP3298721A1 (de) Verfahren zur erzeugung eines geheimnisses oder schlüssels in einem netzwerk
DE102019204951A1 (de) Verfahren zum sicheren austauschen von nachrichten zwischen endgeräten in einem netzwerk
DE102016208453A1 (de) Verfahren zur Erzeugung eines Geheimnisses oder eines Schlüssels in einem Netzwerk
Goltz Investigating the Filter Capacity of Linecouplers in KNX regarding network security
DE102015220083A1 (de) Schaltungsanordnung zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
DE102015220081A1 (de) Verfahren zur Erzeugung eines Schlüssels in einer Schaltungsanordnung
DE102015220055A1 (de) Verfahren zur Erzeugung eines Geheimnisses oder Schlüssels in einem Netzwerk
DE102016208445A1 (de) Verfahren zur Erzeugung eines Geheimnisses oder eines Schlüssels in einem Netzwerk
DE102016208449A1 (de) Verfahren zur Erzeugung eines Geheimnisses oder eines Schlüssels in einem Netzwerk
DE102016208442A1 (de) Verfahren zur Erzeugung eines Geheimnisses oder eines Schlüssels in einem Netzwerk
DE102016208444A1 (de) Verfahren zur Erzeugung eines Geheimnisses oder eines Schlüssels in einem Netzwerk
EP4014424A1 (de) Verfahren zum verarbeiten von telegrammen in einem automatisierungsnetzwerk, automatisierungsnetzwerk, masterteilnehmer und slaveteilnehmer
DE102016208448A1 (de) Verfahren zur Erzeugung eines Geheimnisses oder eines Schlüssels in einem Netzwerk

Legal Events

Date Code Title Description
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20110901