-
Im Rahmen der immer weiter gehenden Digitalisierung von Prozessen gibt es immer mehr Anwendungsfälle, bei denen Prozesse, die in einem privaten Bereich unter Verwendung eines elektronischen Gerätes stattfinden über digitale Kommunikation, insbesondere über das Internet, überwacht und gegebenenfalls gesteuert werden. Ein aktuell intensiv diskutiertes und vorangetriebenes Beispiel für eine solche Anwendung ist das im Rahmen der Energiewende in Deutschland forcierte „Smart Metering“, weshalb auch in dieser Anmeldung eine Terminologie verwendet wird, die auf aus dem Kontext dieser Technologie, beispielsweise aus der Technischen Richtlinie BSI TR TR-03109-1 des Bundesamts für Sicherheit in der Informationstechnik bekannte Bezeichnungen für die Benennung von Komponenten zurückgreift, woraus nicht abzuleiten ist, dass die offenbarten Sachverhalte sich nur auf diese Anwendung beziehen.
-
Systeme, mit denen derartige Prozesse realisiert werden, umfassen üblicherweise mindestens ein zu überwachendes und/oder zu steuerndes Gerät, das im Rahmen dieser Offenbarung als kontrollierbares lokales System oder „Controllable Local System“, alternativ auch abgekürzt als „CLS“ bezeichnet wird, das üblicherweise in ein als „Home Area Network“, alternativ abgekürzt als „HAN“ bezeichnetes Netzwerk im privaten Bereich eingebunden ist, beispielsweise in ein lokales LAN Netz. In vielen praktischen Anwendungen kann das CLS auch eine von mehreren oder eine zentrale Steuerbox sein, die unterschiedlichen Komponenten -z.B. für Smart Home Anwendungen- über unterschiedliche Applikationen oder Kommunikationsprotokolle steuert, beispielsweise Beleuchtungskomponenten über DALI, eine Heizung oder eine Türsteuerung über KNX oder Unterhaltungselektronik über ein Web-Protokoll.
-
Auf dieses CLS soll von mindestens einem, typischerweise als Server konfigurierten, Rechner, der ebenfalls Bestandteil des Systems ist, eines dazu befugten Dritten zugegriffen werden, um Daten auszulesen, die vom CLS aufgenommen werden und/oder um Steuerbefehle zu senden, mit denen das CLS zu bestimmten Aktionen veranlasst wird oder das CLS soll mit diesem Rechner kommunizieren können, etwa um Daten zu übermitteln. Da dieser Rechner in den meisten Fällen zu einem kommerziellen Dienst gehört, der von einer Firma oder Person erbracht wird, wird dieser externe Server im Rahmen dieser Offenbarung als „Externer Marktteilnehmer“, alternativ abgekürzt als EMT, bezeichnet, was aber die Möglichkeit, dass es sich um eine Privatperson handelt, nicht ausschließen soll. Dieser Rechner bzw. Server ist an ein Weitverkehrsnetz, abgekürzt als WAN bezeichnet, angeschlossen, typischerweise erreichbar über das Internet.
-
Naturgemäß ist aus Sicherheitserwägungen ein unmittelbarer, freier Zugriff aus dem WAN auf das HAN unerwünscht. Daher ist ein weiterer zwingend erforderlicher Bestandteil eines solchen Systems ein transparenter Proxy-Server, der insbesondere im Zusammenhang mit Smart-Meter-Applikationen als Smart Meter Gateway bezeichnet wird und für den dementsprechend auch die Abkürzung SMGW verwendet wird. Geschützte, insbesondere TLSgeschützte Kommunikationskanäle in Richtung zum CLS und zum EMT werden in diesem transparenten Proxy-Server terminiert und die jeweils empfangenen Daten werden von dem transparenten Proxy-Server, der auch die Aufgaben einer Firewall erfüllt und die angebundenen Netze voneinander separiert, weitergeleitet. Damit dies von dem transparenten Proxy-Server geleistet werden kann, muss für die einzelnen zulässigen Verbindungen jeweils ein Kommunikationsprofil hinterlegt sein, und sowohl bei der Ergänzung einer zusätzlichen Komponente als auch bei der Änderung von Server-Adressen muss jeweils eine aufwändige Neukonfiguration durchgeführt werden.
-
Die Terminologie des Smart Metering wird nachfolgend auch insoweit für die Beschreibung von Kommunikationsprozessen verwendet, als auf die aus diesem Zusammenhang bekannten Kommunikationsszenarien „HKS3“ für die Beschreibung einer Kommunikation zwischen CLS und EMT, die vom CLS initiiert wird, „HKS4“ für die Beschreibung einer Kommunikation zwischen CLS und EMT, die vom EMT -allerdings in diesem Kontext auch gegebenenfalls indirekt- initiiert wird und „HKS5“ für die Beschreibung einer Kommunikation zwischen CLS und EMT, die vom SMGW initiiert wird, zurückgegriffen wird.
-
Die Aufgabe der Erfindung besteht daher darin, ein Verfahren zum Betrieb eines solchen Systems und ein solches System bereitzustellen, das den Konfigurationsaufwand reduziert und einfacher modifizierbar und/oder rekonfigurierbar ist. Diese Aufgabe wird gelöst mit einem Verfahren mit den Merkmalen des Patentanspruchs 1 und einem System mit den Merkmalen des Patentanspruchs 9. Vorteilhafte Weiterbildungen der Erfindung sind Gegenstand der abhängigen Ansprüche.
-
Das erfindungsgemäße Verfahren dient zum Betrieb eines Systems, das mindestens ein lokales kontrollierbares Gerät, mindestens einen externen Server und mindestens einen transparenten Proxy-Server umfasst, wobei letzterer insbesondere ein Smart Meter Gateway sein kann. Beim Betrieb des Systems wird insbesondere eine Verbindung zwischen dem lokalen kontrollierbaren Gerät und dem externen Server über den transparenten Proxy-Server aufgebaut.
-
Um dies zu ermöglichen, sind in dem Proxy-Server für jedes lokale kontrollierbare Gerät ein erstes Profil für den Verbindungsaufbau des lokalen kontrollierbaren Geräts zum transparenten Proxy-Server, für jeden externen Server ein zweites Profil für den Verbindungsaufbau des transparenten Proxy-Servers zum externen Server und ein Proxy-Profil, welches das jeweilige Profil für den Verbindungsaufbau des lokalen kontrollierbaren Geräts mit dem jeweiligen Profil des externen Servers verbindet, hinterlegt.
-
Ganz allgemein entsprechen solche Profile Dateien, in denen die Kommunikation ermöglichende Informationen, insbesondere Zieladressen und gegebenenfalls weitere die Kommunikation betreffende Informationen gespeichert sind.
-
Wichtig ist dabei, dass das zweite Profil, das Informationen zum Verbindungsaufbau des transparenten Proxy-Servers zum externen Server enthält, einen eindeutigen Bezeichner für das Profil und mindestens eine Zieladresse vom Typ URI mit Schema (scheme) und hierarchischem Teil (hier-part) enthält. Der Aufbau einer solchen Adresse vom Typ URI ist standardisiert und z.B. in der RFC 3986 beschrieben:
- URI = scheme „:“ hier-part [ „?“ query ] [ „#“ fragment ]
-
Die URI-Schemes (scheme) sind von der IANA.org festgelegt; sie stellen einen Protokollselektor dar, während der hierarchische Teil (hier-part) die Zieladresse festlegt, zu der die Verbindung hergestellt werden soll.
-
Wird nun eine Verbindung zwischen dem transparenten Proxy-Server (SMGW) und einem externen Server (EMT) aufgebaut, so kann dazu das Profil für diesen externen Server (EMT) anhand des logischen Bezeichners identifiziert und eine Zieladresse aus der Liste der darin enthaltenen Zieladressen zum Verbindungsaufbau genutzt werden.
-
Erfindungswesentlich ist dabei, dass zumindest das Schema der zum Verbindungsaufbau verwendeten Zieladresse vom transparenten Proxy-Server dem jeweiligen lokalen kontrollierbaren Gerät, das mit dem entsprechenden externe Server über den transparenten Proxy-Server verbunden werden soll, mitgeteilt wird, und dass das lokale kontrollierbare Gerät anhand des mitgeteilten Schemas
- - identifiziert, welches Protokoll für die Kommunikation zu dem externen Server (EMT) zu verwenden ist, und
- - das entsprechende Protokoll lädt oder eine Verbindung zu einer zu dem entsprechenden Protokoll passenden nachgelagerten Applikation herstellt.
-
Mit anderen Worten erhält also das CLS die Informationen über das bei der Verbindung zum EMT zu verwendende Protokoll beim Verbindungsaufbau zwischen dem SMGW und dem EMT.
-
Als Konsequenz aus dieser Vorgehensweise verringert sich der Konfigurationsaufwand erheblich. Insbesondere kann ein Austausch von Adressen des externen Servers oder eine Umstellung des Protokolls, das dieser nutzt, nun einfach durch Anpassung der im zweiten Profil, also dem Profil für den EMT, vorhandenen Adressen erfolgen; eine Anpassung des ersten Profils, also des Profils für das CLS, kann vollständig entfallen.
-
In einer besonders vorteilhaften Ausgestaltung des Verfahrens ist vorgesehen, dass das Schema der zum Verbindungsaufbau verwendeten Zieladresse vom transparenten Proxy-Server SMGW dem jeweiligen lokalen kontrollierbaren Gerät CLS, das mit dem entsprechenden externe Server EMT über den transparenten Proxy-Server SMGW verbunden werden soll, bereits mitgeteilt wird, ehe der Verbindungsaufbau zwischen dem transparenten Proxy-Server SMGW und dem entsprechenden externen Server EMT verbunden werden soll, abgeschlossen ist. Auf diese Weise können Zeitverluste bei der Kommunikation konsequent minimiert werden.
-
Es hat sich ferner als vorteilhaft erwiesen, wenn bei dem Verfahren der Verbindungsaufbau zwischen dem transparenten Proxy-Server SMGW und dem entsprechenden externen Server EMT eine Namensauflösung auf Grundlage der Domain und des Ports umfasst, was im Umkehrschluss bedeutet, dass das Schema ignoriert wird. Diese Vorgehensweise ist insbesondere dann sinnvoll, wenn das Protokoll für diesen Verbindungsaufbau immer gleich ist, beispielsweise weil zur Verschlüsselung das TLS-Protokoll zum Einsatz kommt, wie es für einen Smart Meter Gateway vorgeschrieben ist.
-
Die Weiterleitung der Information über das Schema, das für die Kommunikation zwischen dem lokalen kontrollierbaren Gerät CLS und dem externen Server EMT verwendet werden soll, kann besonders einfach dadurch erfolgen, dass das Schema der zum Verbindungsaufbau verwendeten Zieladresse vom transparenten Proxy-Server SMGW dem jeweiligen lokalen kontrollierbaren Gerät CLS, das mit dem entsprechenden externe Server EMT über den transparenten Proxy-Server SMGW verbunden werden soll, dadurch mitgeteilt wird, dass die beim Verbindungsaufbau zwischen dem transparenten Proxy-Server SMGW und dem entsprechenden externen Server EMT von letzterem an den transparenten Proxy-Server SMGW kommunizierte gebundene URI, die ja insbesondere die Information über das zu verwendende Protokoll in Form des Schemas (scheme) der URI enthält, an das jeweilige lokale kontrollierbare Gerät zurückgeliefert oder weitergeleitet wird.
-
In einer anderen vorteilhaften Weiterbildung des Verfahrens ist vorgesehen, dass in dem hinterlegten zweiten Profil mindestens eines externen Servers EMT als logischer Bezeichner ein vollständiger Name der Domain, also ein Fully Qualified Domain Name FQDN des externen Servers verwendet wird.
-
Besonders bevorzugt ist, wenn zur Kommunikation das SOCKS5-Protokoll verwendet wird und wenn der Verbindungsaufbau zwischen dem transparenten Proxy-Server SMGW und dem entsprechenden externen Server EMT durch ein an den Proxy-Server SMGW gerichtetes SOCKSConnect-Request angestoßen wird. In diesem Fall kann der Adresstyp der Anfrage unmittelbar aus dem SOCKSConnect-Request übernommen werden und eine adresstypspezifische Weiterverarbeitung erfolgen.
-
Der als Adresstyp im Rahmen einer Anfrage zum Verbindungsaufbau übergebene Wert kann vorzugsweise bei der Herstellung einer Verbindung zwischen dem transparenten Proxy-Server SMGW und einem externen Server EMT ausgewertet werden.
-
Zumindest dann, wenn der Adresstyp ein Domainname ist und einem Fully Qualified Domain Name FQDN entspricht, kann das zweite Profil für diesen externen Server EMT anhand des logischen Bezeichners identifiziert werden und die Liste der darin enthaltenen Zieladressen sequentiell abgearbeitet werden, wobei dann die erste erreichbare Zieladresse zum Verbindungsaufbau genutzt wird. Man kann in diesem Fall insbesondere z.B. durch die Reihenfolge der angegebenen Zieladressen sicherstellen, dass im ISO-Schichtenmodell (Layer 7 Modell) eine möglichst hohe oder tiefe Schicht verwendet wird.
-
Das erfindungsgemäße System umfasst mindestens ein lokales kontrollierbares Gerät CLS, mindestens einen externen Server EMT und mindestens einen transparenten Proxy-Server SMGW und zeichnet sich dadurch aus, dass das System zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 8 ausgelegt und eingerichtet ist.
-
Die Erfindung wird nachfolgend anhand von Figuren, die ein Ausführungsbeispiel zeigen, näher erläutert. Es zeigen:
- 1: Ein Ausführungsbeispiel für ein erfindungsgemäßes System, und
- 2: ein vereinfachtes Beispiel für einen Verbindungsaufbau, hier für ein HKS3 Kommunikationsszenario.
-
1 zeigt ein Ausführungsbeispiel für ein erfindungsgemäßes System 1, wie es z.B. im Rahmen einer Smart-Home Anwendung für ein Haus 2 realisiert sein kann. Das System 1 umfasst ein lokales kontrollierbares Gerät CLS, einen externen Server EMT und einen transparenten Proxy-Server SMGW. Das lokale kontrollierbare Gerät CLS ist eine Steuerbox, welche unterschiedliche Komponenten, die in das Smart-Home System integriert sind, bedient, und zwar mit unterschiedlichen Applikationen, die z.B. auch unterschiedlichen Smart-Home-Standards unterfallen können. Im dargestellten Beispiel wird die Beleuchtung des Hauses 2 über DALI mit einer geeigneten Applikation AppDALI vom lokalen steuerbaren Gerät CLS, auf dem die Applikation läuft, kontrolliert, Jalousien und die Heizungsanlage über KNX mit einer geeigneten Applikation AppKNX und der Zugriff auf eine Komponente oder ein Gerät über http mit einer geeigneten Applikation Appweb. Um die externe Steuerung dieser Komponenten von außerhalb des Hauses nur durch Befugte sicher zu ermöglichen, wird eine Verbindung zu dem externen Server EMT über den transparenten Proxy-Server SMGW aufgebaut.
-
Ein vereinfacht dargestelltes Beispiel für eine erfindungsgemäße Vorgehensweise wird nachfolgend unter Beiziehung der schematischen Darstellung der 2 beschrieben. 2 zeigt dabei ein HKS3-Kommunikationsszenario; der wesentliche Unterschied zu einem HKS4- oder HKS5-Kommunikationsszenario liegt jedoch nur darin, dass der Verbindungsaufbau zwischen CLS und SMGW im Schritt 110 im gezeigten Kommunikationsszenario durch das CLS initiiert wird und in den beiden anderen Szenarien durch den transparenten Proxy-Server SMGW.
-
In der schematischen Darstellung der 2 sind die wesentlichen Verfahrensschritte 110, 120, 130, 140a, 140b, die in der Reihenfolge von oben nach unten, aber nicht zwingend unmittelbar nacheinander ohne weitere Zwischenschritte, und teilweise auch miteinander zeitlich überlappend durchlaufen werden, von oben nach unten dargestellt.
-
In 2 sind von links nach rechts jeweils auf gestrichelten Linien liegend unterschiedliche Instanzen dargestellt, die in die Verfahrensabläufe eingebunden sind. Von links betrachte stellen die ersten drei Instanzen unterschiedliche Programme oder Applikationen dar, die alle auf der bzw. durch die CLS-Hardware ausgeführt werden, nämlich die Applikation Appweb , die Applikation AppKNX und der cSocksv5Client 10. Die von links betrachtet vierte Instanz läuft auf dem transparenten Proxy-Server SMGW ab und die von links betrachtet fünfte Instanz auf dem externen Server EMT.
-
Im ersten Schritt 110 wird vom CLS durch den cSocksv5Client 10 eine Verbindung zum SMGW aufgebaut, insbesondere durch ein TCP-Connect zum Port 1080 des SMGW und Aufbau einer TLSgesicherten Verbindung zwischen CLS und SMGW nach den Regeln des SOCKSv5 Protokolls.
-
Anschließend wird im Schritt 120 über die hergestellte TLSgesicherte Verbindung die Verbindungsanfrage, insbesondere als SOCKSConnect-Request, des CLS mit einem bestimmten externen Marktteilnehmer EMT an den transparenten Proxy-Server SMGW übermittelt. Gemäß RFC 1828 enthält diese Anfrage insbesondere im Feld ATYP Informationen zum Adresstyp, der entweder einem der Standards IPv4 oder IPv6 entspricht oder ein Domainname ist, und in den Feldern DST.ADDR und DST.PORT Informationen zu Adresse und Port, über den die Verbindung hergestellt werden soll des angefragten externen Servers EMT. Insbesondere diese Informationen entnimmt der transparente Proxy-Server SMGW aus der Verbindungsanfrage bzw. dem SOCKSConnect-Request.
-
Der SMGW wertet diese Information aus. Ist der Adresstyp IPv4 oder IPv6, so wird im auf dem SMGW hinterlegten zweiten Profil zum Verbindungsaufbau mit einem EMT geprüft, ob der durch die übermittelte Adresse und den übermittelten Port definierte Endpunkt in der Liste zulässiger Verbindungen vorhanden ist.
-
Ist das nicht der Fall, wird der Fehlerstatus 0x2: connection not allowed by ruleset zurückgeliefert.
-
Ist ein entsprechender Eintrag vorhanden, wird versucht, eine Verbindung zu diesem Endpunkt herzustellen. Diese Verbindung wird stets unabhängig vom Schema/scheme über das TLS-Protokoll durchgeführt; die Namensauflösung erfolgt auf Grundlage der Domain und des Ports.
-
Scheitert die Herstellung dieser Verbindung, so wird eine Statusmeldung, die den Fehler identifiziert, an den SMGW zurückgeliefert. Insbesondere kommen als Fehlermeldungen in Frage:
- • 0x01: general SOCKS server failure
- • 0x03: Network unreachable
- • 0x04: Host unreachable
- • 0x05: Connection refused
- • 0x08: Address type not supported
-
Ist die Verbindung erfolgreich, wird ein succeeded-Status sowie die gebundene IPv4 bzw. IPv6-Adresse an den transparenten Proxy-Server zurückgeliefert.
-
Wird mit dem SOCKSConnect-Request an den transparenten Proxy-Server SMGW ein Domainname übermittelt, so prüft dieser zunächst, ob es sich um einen Fully Qualified Domain Name FQDN handelt oder um eine URI, also einen Uniform Resource Identifier nach RFC 3986.
-
Handelt es sich um einen Fully Qualified Domain Name FQDN, wird geprüft, ob dieser dem logischen Bezeichner bzw. logical_name des zu dem entsprechenden EMT gehörigen zweiten Profils entspricht. Wenn dies nicht der Fall ist, wird der Fehlerstatus 0x02: connection not allowed by ruleset zurückgeliefert.
-
Entspricht hingegen der Fully Qualified Domain Name FQDN dem logischen Bezeichner bzw. logical_name des zu dem entsprechenden EMT gehörigen zweiten Profils, wird die Liste der in diesem zweiten Profil hinterlegten Adressen dest_adresses der Reihe nach abgearbeitet und jeweils versucht, eine Verbindung mit dem jeweiligen Eintrag aufzubauen, wobei der mit dem Feld DST.PORT übermittelte Port ignoriert wird.
-
Scheitert die Herstellung dieser Verbindung, so wird eine Statusmeldung, die den Fehler identifiziert, an den SMGW zurückgeliefert. Insbesondere kommen als Fehlermeldungen in Frage:
- • 0x01: general SOCKS server failure
- • 0x03: Network unreachable
- • 0x04: Host unreachable
- • 0x05: Connection refused
- • 0x08: Address type not supported
-
Wenn der Verbindugsaufbau hingegen gelingt, wird ein succeeded-Status sowie die gebundene IPv4- oder IPv6-Adresse bzw. die gebundene URI zurückgeliefert, mit welcher die Verbindung gemäß dem dest_address aufgebaut wurde.
-
Wird mit dem SOCKSConnect-Request an den transparenten Proxy-Server SMGW als Domainname eine URI, also einen Uniform Resource Identifier nach RFC 3986 übermittelt, wird genau dieser Eintrag in der Liste der dest_adresses des EMT-Profils, also des zweiten Profils, gesucht. Existiert der Eintrag nicht, wird der Fehlerstatus 0x02: connection not allowed by ruleset zurückgeliefert.
-
Existiert der Eintrag, wird versucht, eine Verbindung mit diesem Ziel aufzubauen, wobei die Namensauflösung auf Grundlage der Domain und des Ports erfolgt. Das Protokoll ist immer TLS, weshalb das Schema/scheme für den Verbindungsaufbau ignoriert wird.
-
Scheitert die Herstellung dieser Verbindung, so wird eine Statusmeldung, die den Fehler identifiziert, an den SMGW zurückgeliefert. Insbesondere kommen als Fehlermeldungen in Frage:
- • 0x01: general SOCKS server failure
- • 0x03: Network unreachable
- • 0x04: Host unreachable
- • 0x05: Connection refused
- • 0x08: Address type not supported
-
Wenn der Verbindugsaufbau hingegen gelingt, wird ein succeeded-Status sowie die gebundene URI zurückgeliefert, mit welcher die Verbindung gemäß dem dest_address aufgebaut wurde.
-
Wichtig ist, dass in allen Fällen, in denen es zu eine Verbindung kommt, die gebundene Adresse, sei es eine IPv4-Adresse, eine IPv6-Adresse oder eine URI vom EMT dem SMGW übermittelt wird und vom SMGW an den SOCKSv5Client des CLS weitergeleitet wird.
-
Diese Information wird im Schritt 130 im lokalen kontrollierbaren System CLS benutzt, um das jeweilige Schema/scheme der weitergeleiteten oder zurückgelieferten gebundenen Adresse zu bestimmen, und in Abhängigkeit von dem jeweiligen Ergebnis die richtige Applikation gestartet, mit der dann im Schritt 140a bzw. 140b die Kommunikation zwischen CLS und EMT auf die bereits bekannte Art und Weise durchgeführt wird. Anders als bislang muss aber nicht mehr jeweils eine separate Konfiguration für den Austausch von http-Daten und knx-Daten vorhanden sein, um diese Verbindungen aufbauen zu können.
-
Bezugszeichenliste
-
- 1
- System
- 2
- Haus
- 10
- cSocksv5Client
- 110, 120, 130, 140a, 140b
- Verfahrensschritt
- AppWeb
- Web-Applikation
- AppDALI
- Dali-Applikation
- AppKNX
- KNX-Applikation
- CLS
- lokales kontrollierbares System
- SMGW
- transparenter Proxy-Server
- EMT
- externer Marktteilnehmer bzw. dessen externer Server
