DE102016207635A1 - Verfahren und Vorrichtung zur Absicherung von Gerätezugriffen - Google Patents

Verfahren und Vorrichtung zur Absicherung von Gerätezugriffen Download PDF

Info

Publication number
DE102016207635A1
DE102016207635A1 DE102016207635.3A DE102016207635A DE102016207635A1 DE 102016207635 A1 DE102016207635 A1 DE 102016207635A1 DE 102016207635 A DE102016207635 A DE 102016207635A DE 102016207635 A1 DE102016207635 A1 DE 102016207635A1
Authority
DE
Germany
Prior art keywords
entity
service
request
specific service
service entity
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
DE102016207635.3A
Other languages
English (en)
Inventor
Hans Aschauer
Steffen Fries
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.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Priority to DE102016207635.3A priority Critical patent/DE102016207635A1/de
Priority to PCT/EP2017/053453 priority patent/WO2017190857A1/de
Publication of DE102016207635A1 publication Critical patent/DE102016207635A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0847Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving identity based encryption [IBE] schemes
    • 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/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H04L9/3073Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves involving pairings, e.g. identity based encryption [IBE], bilinear mappings or bilinear pairings, e.g. Weil or Tate pairing

Abstract

Die Erfindung betrifft ein Verfahren zum gesicherten Zugreifen einer spezifischen Serviceentität auf ein Gerät. Im Einzelnen stellt das Verfahren einen gesicherten Zugriff, beispielsweise einen Fernwartungszugriff, einer spezifischen Serviceentität, beispielsweise einem Servicetechniker, auf ein Gerät, beispielsweise ein Feldgerät einer Kraftwerksanlage, bereit. Mittels des Fernwartungszugriffs kann die spezifische Serviceentität beispielsweise ein Firmwareupdate durchführen um insbesondere Sicherheitslücken in einer veralteten Firmware zu beseitigen.

Description

  • Die Erfindung bezieht sich auf ein Verfahren und eine Vorrichtung zur Absicherung von Gerätezugriffen.
  • Speziell im Automatisierungsumfeld werden oft Installationen von mehreren, verschiedenen Auftraggebern/Firmen durchgeführt.
  • Beispielsweise liefert eine erste Firma Automatisierungs-Endgeräte, eine zweite Firma Netzwerk-Komponenten und eine dritte Firma notwendige Office-Komponenten/Geräte im Backend (oder Control Center). Um z. B. Service-Technikern den Zugang zu Automatisierungs-Geräten zu ermöglichen wird oftmals ein Zertifikat oder ein Passwort verwendet. Ein derartiger Zugangsmechanismus muss jedoch vorab auf dem Rechner (in der Regel ein Laptop) des Service-Technikers installiert bzw. konfiguriert werden.
  • Um lange Ausfallzeiten, welche speziell im Automatisierungs-Umfeld kritisch sind, zu vermeiden, muss es möglich sein, solche Zugriffe so schnell wie möglich einzurichten. Idealerweise sind diese Zugriffe auch nur in einem Wartungsfenster erlaubt. Problematisch wird es, wenn wie beschrieben, mehrere Firmen kooperieren und in einem Fehler- bzw. Service-Fall verschieden Entitäten involviert sind. Z. B. kann es sein, dass ein Service-Techniker auf Automatisierungs-Endgeräte eines Anlagenbetreibers via Remote-Zugang zugreifen möchte, sich hierfür aber erst mittels VPN am Netzwerk anmelden muss, das von einem Infrastrukturbetreiber bereitgestellt wird.
  • Aus dem Stand der Technik sind das Dokument US 8,531,247 B2 , das Dokument US 8,892,616 B2 , das Dokument US 8,300,811 B2 , das Dokument US 9,147,088 B2 , das Dokument EP 2 605 445 B1 , das Dokument EP 2 870 565 A1 , das Dokument EP 2 891 102 A1 und das Dokument US 8 843 761 B2 bekannt.
  • Eine Aufgabe der vorliegenden Erfindung ist es, ein Verfahren und eine Vorrichtung zur Absicherung von Gerätezugriffen bereitzustellen, die es erlauben, möglichst einfach auf ein zugriffgeschütztes Gerät zuzugreifen.
  • Die Aufgabe wird durch die in den unabhängigen Ansprüchen angegebenen Merkmale gelöst. In den Unteransprüchen sind vorteilhafte Weiterbildungen der Erfindung dargestellt.
  • Gemäß einem ersten Aspekt betrifft die Erfindung ein Verfahren zum gesicherten Zugreifen einer spezifischen Serviceentität auf ein Gerät mit den Verfahrensschritten:
    • – Verschlüsseln eines Sicherheitstokens durch eine Anfrageentität, wobei zum Verschlüsseln ein öffentlicher Schlüssel zusammen mit einem öffentlichen Parameter verwendet wird, wobei der öffentliche Schlüssel von einem eindeutigen Serviceidentifizierer abgleitet wird;
    • – Generieren einer Serviceanfrage durch die Anfrageentität, wobei die Serviceanfrage den eindeutigen Serviceidentifizierer und den verschlüsselten Sicherheitstoken umfasst;
    • – Übermitteln der Serviceanfrage an eine zweite Serviceentität;
    • – Zuweisen der Serviceanfrage durch ein Zuweisungsmodul an die spezifische Serviceentität;
    • – Übermitteln der Serviceanfrage durch die spezifische Serviceentität an ein Autorisierungsmodul;
    • – Überprüfen durch das Autorisierungsmodul, ob die spezifische Serviceentität für das Gerät hinsichtlich der Serviceanfrage zugriffsberechtigt ist;
    • – Übermitteln einer Identität der spezifischen Serviceentität und des eindeutigen Serviceidentifizierers an einen Schlüsselserver durch das Autorisierungsmodul, wenn die spezifische Serviceentität für das Gerät zugriffsberechtigt ist;
    • – Berechnen eines privaten Schlüssels zum Entschlüsseln des verschlüsselten Sicherheitstokens anhand des eindeutigen Serviceidentifizierers durch den Schlüsselserver; und
    • – Übermitteln des privaten Schlüssels an die spezifische Serviceentität durch den Schlüsselserver.
  • Unter einer ”spezifischen Serviceentität” kann im Zusammenhang mit der Patentanmeldung beispielsweise ein Servicetechniker oder eine Softwarekomponente verstanden werden, die eine Serviceanfrage bearbeiten oder abarbeiten.
  • Unter einem ”Gerät” kann im Zusammenhang mit der Patentanmeldung beispielsweise ein technisches Gerät, beispielsweise ein Fertigungsroboter oder ein Feldgerät, beispielsweise in einer Fertigungsanlage oder einem Kraftwerk verstanden werden.
  • Unter einem ”öffentlichen Schlüssel” insbesondere zum Verschlüsseln eines Sicherheitstokens kann im Zusammenhang mit der Patentanmeldung beispielsweise eine Identität insbesondere in Form einer Emailadresse (z. B. Ticket 1234@service.example.com) oder in Form des eindeutigen Serviceidentifizierers verstanden (z. B. Ticket 1234) werden. Die Emailadresse kann beispielsweise aus dem eindeutigen Serviceidentifizierer und einer Domäneninformation aus dem öffentlichen Parameter erzeugt werden. Alternativ wird der öffentliche Schlüssel insbesondere nur aus dem eindeutigen Serviceidentifizierer erzeugt. Der öffentliche Schlüssel kann beispielsweise der spezifischen Serviceentität für die Abarbeitung der Serviceanfrage als Identität, die auch als temporäre Identität bezeichnet werden kann, dienen. Nach der Abarbeitung kann diese Identität beispielsweise annulliert werden. Das Zuweisen der temporären Identität an die spezifische Serviceentität kann beispielsweise auch durch das Zuweisungsmodul erfolgen. Diese Identität kann beispielsweise bei einer identitätsbasierten Verschlüsselung [1] verwendet werden.
  • Unter einem ”öffentlichen Parameter” insbesondere zum Bilden eines öffentlichen Schlüssels kann im Zusammenhang mit der Patentanmeldung beispielsweise eine Domain (z. B. example.com) oder eine Subdomain (z. B. service.example.com) insbesondere der zweiten Serviceentität, verstanden werden. Der öffentliche Parameter kann beispielsweise auch kryptographische Parameter enthalten, die zur Verschlüsselung des Sicherheitstokens verwendet werden. Unter einem ”öffentlichen Parameter” kann im Zusammenhang mit der Patentanmeldung beispielsweise insbesondere auch ein öffentlicher Parameter verstanden werden, so wie dieser in einer identitätsbasierenden Verschlüsselung [1] eingesetzt wird.
  • Unter einem ”Sicherheitstoken” kann im Zusammenhang mit der Patentanmeldung beispielsweise Schlüsselmaterial (engl. Security Credentials), insbesondere Benutzername und Passwort oder digitale Zertifikate, verstanden werden, das beispielsweise für einen Fernwartungszugriff der spezifischen Serviceentität auf ein zu wartendes Gerät benötigt wird.
  • Unter einem ”eindeutigen Serviceidentifizierer” kann im Zusammenhang mit der Patentanmeldung beispielsweise eine eindeutige Ticketnummer verstanden werden. Diese Ticketnummer kann beispielsweise von dem Schlüsselserver ausgegeben werden. Der eindeutige Serviceidentifizierer kann beispielsweise als öffentlicher Schlüssel einer identitätsbasierenden Verschlüsselung verwendet werden.
  • Unter einer ”Serviceanfrage” kann im Zusammenhang mit der Patentanmeldung beispielsweise ein Wartungsauftrag für ein Gerät, eine Anfrage zur Firmwareaktualisierung eines Gerätes oder zum Auslesen von Protokolldaten eines Gerätes einer Kraftwerksanlage verstanden werden.
  • Unter einer ”Anfrageentität” kann im Zusammenhang mit der Patentanmeldung beispielsweise ein Betreiber eines operativen Netzes oder eines Teils der IT-Infrastruktur einer Kraftwerksanlage verstanden werden.
  • Unter einer ”zweiten Serviceentität” kann im Zusammenhang mit der Patentanmeldung beispielsweise ein Betreiber eines Kommunikationsnetzes einer Kraftwerksanlage verstanden werden.
  • Unter einem ”Verschlüsseln” und/oder ”Entschlüsseln” kann im Zusammenhang mit der Patentanmeldung beispielsweise ein Verschlüsseln/Entschlüsseln eines Sicherheitstokens mit geeigneten asymmetrischen kryptographischen Verfahren verstanden werden. Insbesondere werden Verfahren der identitätsbasierenden Verschlüsselung [1] verwendet.
  • Unter ”externe Komponenten” kann im Zusammenhang mit der Patentanmeldung beispielsweise eine Komponente verstanden werden, die insbesondere kein integraler Bestandteil der Anfrageentität oder der Serviceentität sind. Eine externe Komponente kann beispielsweise über eine Kommunikationsverbindung, beispielsweise ein Netzwerk, insbesondere Ethernet oder einer Internetverbindung, mit der Serviceentität und/oder den Komponenten der Serviceentität und/oder der Anfrageentität und/oder Komponenten der Anfrageentität in Verbindung stehen.
  • Das Verfahren ist beispielsweise dahingehend vorteilhaft, da eine Autorisierung auf den Zeitpunkt der Schlüsselabholung durch die Serviceentität verlagert wird. Dabei ist insbesondere vorteilhaft, dass die spezifische Serviceentität über seine temporäre Identität angesprochen werden kann. Damit lassen sich beispielsweise auch einfach Gruppen-Accounts für Serviceentitäten einrichten, über die insbesondere der Sicherheitstoken dann verschlüsselt verschickt werden kann. Insbesondere die Freigabe des privaten Schlüssels zum Entschlüsseln des verschlüsselten Sicherheitstokens erfolgt dann, beispielsweise nach der Authentisierung der spezifischen Serviceentität. Insbesondere die Anfrageentität besitzt beispielsweise keine Information über interne Strukturen der Serviceentität, insbesondere nicht über die Zugehörigkeit bestimmter spezifischer Serviceentitäten zu einer Gruppe.
  • Mit Hilfe ”gewöhnlicher” oder ”konventioneller” asymmetrischer Verschlüsselung ließe sich jedoch beispielsweise nur ein Verfahren realisieren, bei dem insbesondere der Sicherheitstoken von der Anfrageentität beispielsweise mit einem generischen öffentlichen Schlüssel der Serviceentität verschlüsselt wird. Dies hat insbesondere im Vergleich zum erfindungsgemäßen Verfahren den Nachteil, dass dann beispielsweise verschiedene Schlüsselmaterialien in einer Art Gateway (das den zum generischen Public Key gehörigen Private Key kennt) innerhalb der zweiten Serviceentität (also insbesondere als integraler Teil der zweiten Serviceentität) zentral entschlüsselt werden müssten. Es wäre also insbesondere keine Ende-zu-Ende-Sicherheit für sensible Sicherheitstoken gegeben. Alternativ könnte beispielsweise auch der öffentliche Schlüssel einer Serviceentität verwendet werden, um den Sicherheitstoken zu verschlüsseln und nach erfolgreicher Authentisierung der spezifischen Serviceentität an diese herauszugeben. Dies hat insbesondere im Vergleich zum erfindungsgemäßen Verfahren den Nachteil, dass zum Zeitpunkt der Verschlüsselung des Sicherheitstokens die Zuweisung zu einer spezifischen Serviceentität festgelegt sein muss. Darüber hinaus kann keine Trennung des Verschlüsselungsschlüssels vom Sicherheitstoken realisiert werden, da die Zuordnung schon zum Zeitpunkt der Verschlüsselung festgelegt wird.
  • Insbesondere kann mit dem erfindungsgemäßen Gegenstand unterbunden werden, dass der Schlüsselserver mit dem verschlüsselten und/oder unverschlüsselten Sicherheitstoken in Berührung kommt, so dass eine Entschlüsselung erst bei der authentisierten und autorisierten spezifischen Serviceentität möglich ist (Ende-zu-Ende-Sicherheit). Damit ergibt sich insbesondere der weitere Vorteil, dass das Format des Sicherheitstokens nicht festgelegt sein muss. Es kann also beispielsweise ein Standardtokenformat, beispielsweise SAML (engl. Security Assertion Markup Language) oder auch ein proprietäres Format genutzt werden.
  • Bei einer ersten Ausführungsform des Verfahrens entschlüsselt die spezifische Serviceentität den verschlüsselten Sicherheitstoken und greift mittels des entschlüsselten Sicherheitstokens auf das Gerät zu.
  • Bei einer weiteren Ausführungsform des Verfahrens wird der Sicherheitstoken für jede Serviceanfrage spezifisch erzeugt.
  • Das Verfahren ist insbesondere dahingehen vorteilhaft, da beispielsweise für jede Serviceanfrage einzeln das Schlüsselmaterial für den Zugriff auf das Gerät erzeugt wird. Dadurch wird beispielsweise eine hohe Sicherheit erreicht, da der Sicherheitstoken beispielsweise nur für einen vordefinierten Zeitraum gültig ist oder der Sicherheitstoken nach einem Abarbeiten der Serviceanfrage durch die spezifische Serviceentität annulliert wird.
  • Bei einer weiteren Ausführungsform des Verfahrens wird das Überprüfen, ob die spezifische Serviceentität zugriffsberichtigt ist, anhand eines Benutzernamens und Passworts und/oder eines digitalen Zertifikats und/oder von vordefinierten Regeln und/oder anhand einer biometrischen Information durchgeführt.
  • Das Verfahren ist insbesondere dahingehend vorteilhaft, da beispielsweise für jede Serviceanfrage einzeln festgelegt werden kann, wie eine Authentifizierung der spezifischen Serviceentität gegenüber dem Gerät erfolgt.
  • Bei einer weiteren Ausführungsform des Verfahrens ist der Sicherheitstoken an eine Security-Policy gebunden.
  • Das Verfahren ist insbesondere dahingehend vorteilhaft, da beispielsweise der Gültigkeitsbereich und/oder Gültigkeitsdauer insbesondere zentral über die Security-Policy festlegbar ist.
  • Bei einer weiteren Ausführungsform des Verfahrens gibt die Security-Policy vor, wie das Überprüfen, ob die spezifische Serviceentität zugriffsberichtigt ist, durchgeführt wird.
  • Bei einer weiteren Ausführungsform des Verfahrens wird für das Berechnen des privaten Schlüssels ein dem öffentlichen Parameter zugeordneter privater Parameter verwendet.
  • Das Verfahren ist insbesondere dahingehend vorteilhaft, da beispielsweise hierdurch der Schlüsselserver den privaten Schlüssel zum Entschlüsseln des verschlüsselten Sicherheitstokens berechnen kann. Der Schlüsselserver kann beispielsweise anhand der Serviceanfrage, die den eindeutigen Serviceidentifizierer umfasst, den öffentlichen Schlüssel berechnen. Alternativ wird die Identität der spezifischen Serviceentität, die dem öffentlichen Schlüssel entspricht, dem Schlüsselserver übermittelt.
  • Bei einer weiteren Ausführungsform des Verfahrens wird der öffentliche Parameter der Anfrageentität vor dem Verschlüsseln bekannt gemacht und der private Parameter wird dem Schlüsselserver vor dem Berechnen des privaten Schlüssels bekannt gemacht.
  • Das Verfahren ist insbesondere dahingehend vorteilhaft, da beispielsweise hierdurch der verschlüsselte Sicherheitstoken von der spezifischen Serviceentität entschlüsselt werden kann, ohne dass der Schlüsselserver Zugriff auf den verschlüsselten oder entschlüsselten Sicherheitstoken benötigt. Es ist beispielsweise denkbar, dass das Bekanntmachen insbesondere nur ein einziges Mal durchgeführt wird. Es ist beispielsweise aber auch denkbar, dass das Bekanntmachen insbesondere nur dann durchgeführt wird, wenn beispielsweise aufgrund neuer Sicherheitsanforderungen ein aktualisierter öffentlicher Parameter benötigt wird.
  • Bei einer weiteren Ausführungsform des Verfahrens berechnet der Schlüsselserver den öffentlichen Parameter und den privaten Parameter und macht den öffentlichen Parameter bekannt.
  • Das Verfahren ist insbesondere dahingehend vorteilhaft, da beispielsweise hierdurch der öffentliche Parameter auf möglichst einfache Weise bekannt gemacht werden kann.
  • Gemäß einem weiteren Aspekt betrifft die Erfindung ein System zum gesicherten Zugreifen einer spezifischen Serviceentität auf ein Gerät aufweisend:
    • – eine Anfrageentität umfassend,
    • – ein Verschlüsselungsmodul zum Verschlüsseln eines Sicherheitstokens durch die Anfrageentität, wobei zum Verschlüsseln ein öffentlicher Schlüssel zusammen mit einem öffentlichen Parameter verwendet wird, wobei der öffentliche Schlüssel von einem eindeutigen Serviceidentifizierer abgleitet wird;
    • – ein Generierungsmodul zum Generieren einer Serviceanfrage durch die Anfrageentität, wobei die Serviceanfrage den eindeutigen Serviceidentifizierer und den verschlüsselten Sicherheitstoken umfasst;
    • – ein erstes Übermittlungsmodul zum Übermitteln der Serviceanfrage an eine zweite Serviceentität;
    • – die zweite Serviceentität umfassend,
    • – ein Zuweisungsmodul, das die Serviceanfrage der spezifischen Serviceentität zuweist;
    • – ein zweites Übermittlungsmodul zum Übermitteln der Serviceanfrage durch die spezifische Serviceentität an ein Autorisierungsmodul, wobei das Autorisierungsmodul überprüft, ob die spezifische Serviceentität für das Gerät hinsichtlich der Serviceanfrage zugriffsberechtigt ist;
    • – ein drittes Übermittlungsmodul zum Übermitteln einer Identität der spezifischen Serviceentität und des eindeutigen Serviceidentifizierers an einen Schlüsselserver durch das Autorisierungsmodul, wenn die spezifische Serviceentität für das Gerät zugriffsberechtigt ist, wobei der Schlüsselserver einen privaten Schlüssel zum Entschlüsseln des verschlüsselten Sicherheitstokens anhand des eindeutigen Serviceidentifizierers berechnet; und
    • – ein viertes Übermittlungsmodul zum Übermitteln des privaten Schlüssels an die spezifische Serviceentität durch den Schlüsselserver.
  • Bei einer ersten Ausführungsform des Systems umfasst die zweite Serviceentität das Autorisierungsmodul und/oder den Schlüsselserver und/oder die spezifische Serviceentität.
  • Bei einer weiteren Ausführungsform des Systems sind das Autorisierungsmodul und/oder der Schlüsselserver externe Komponenten, wobei insbesondere mittels des Schlüsselservers der öffentliche Parameter der Anfrageentität bekanntmachbar ist.
  • Des Weiteren wird ein Computerprogrammprodukt mit Programmbefehlen zur Durchführung des genannten erfindungsgemäßen Verfahrens beansprucht.
  • Zusätzlich wird eine Variante des Computerprogrammproduktes mit Programmbefehlen zur Konfiguration eines Erstellungsgeräts, beispielsweise ein 3D-Drucker oder ein zur Erstellung von Prozessoren und/oder Geräten und/oder Vorrichtungen geeignetes Gerät, beansprucht, wobei das Erstellungsgerät mit den Programmbefehlen derart konfiguriert wird, dass es Komponenten des genannten erfindungsgemäßen Systems, vorzugsweise des gesamten Systems, erstellt.
  • Darüber hinaus wird eine Bereitstellungsvorrichtung zum Speichern und/oder Bereitstellen des Computerprogrammprodukts beansprucht. Die Bereitstellungsvorrichtung ist beispielsweise ein Datenträger, der das Computerprogrammprodukt speichert und/oder bereitstellt. Alternativ und/oder zusätzlich ist die Bereitstellungsvorrichtung beispielsweise ein Netzwerkdienst, ein Computersystem, ein Serversystem, insbesondere ein verteiltes Computersystem, ein cloudbasiertes Rechnersystem und/oder virtuelles Rechnersystem, welches das Computerprogrammprodukt vorzugsweise in Form eines Datenstroms speichert und/oder bereitstellt.
  • Diese Bereitstellung erfolgt beispielsweise als Download in Form eines Programmdatenblocks und/oder Befehlsdatenblocks, vorzugsweise als Datei, insbesondere als Downloaddatei, oder als Datenstrom, insbesondere als Downloaddatenstrom, des vollständigen Computerprogrammprodukts. Diese Bereitstellung kann beispielsweise aber auch als partieller Download erfolgen, der aus mehreren Teilen besteht und insbesondere über ein Peer-to-Peer Netzwerk heruntergeladen oder als Datenstrom bereitgestellt wird. Ein solches Computerprogrammprodukt wird beispielsweise unter Verwendung der Bereitstellungsvorrichtung in Form des Datenträgers in ein System eingelesen und führt die Programmbefehle aus, sodass das erfindungsgemäße Verfahren auf einem Computer zur Ausführung gebracht wird oder das Erstellungsgerät derart konfiguriert, dass dieses das erfindungsgemäße System oder eines seiner Komponenten erstellt.
  • Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusammenhang mit der folgenden Beschreibung der Ausführungsbeispiele, die im Zusammenhang mit den Figuren näher erläutert werden. Dabei zeigen in schematischer Darstellung:
  • 1 ein Ablaufdiagramm eines ersten Ausführungsbeispiels eines erfindungsgemäßen Verfahrens;
  • 2 ein System eines zweiten Ausführungsbeispiels, welches ein erfindungsgemäßes Verfahren implementiert;
  • 3 ein System eines dritten Ausführungsbeispiels, welches ein erfindungsgemäßes Verfahren implementiert.
  • In den Figuren sind funktionsgleiche Elemente mit denselben Bezugszeichen versehen, sofern nichts anderes angegeben ist.
  • Die nachfolgenden Ausführungsbeispiele werden vorzugsweise mittels eines Prozessors und/oder einem Speichermodul implementiert, sofern nichts anderes angegeben ist.
  • 1 zeigt ein Ablaufdiagramm eines ersten Ausführungsbeispiels eines erfindungsgemäßen Verfahrens.
  • Das Verfahren stellt einen gesicherten Zugriff, beispielsweise einen Fernwartungszugriff, einer spezifischen Serviceentität, beispielsweise einem Servicetechniker, auf ein Gerät, beispielsweise ein Feldgerät einer Kraftwerksanlage, bereit. Mittels des Fernwartungszugriffs kann die spezifische Serviceentität beispielsweise ein Firmwareupdate durchführen um insbesondere Sicherheitslücken in einer veralteten Firmware zu beseitigen.
  • Das Verfahren umfasst einen ersten Verfahrensschritt zum Verschlüsseln 110 eines Sicherheitstokens, beispielsweise Schlüsselmaterial insbesondere einen Fernwartungszugriff auf das Gerät, durch eine Anfrageentität, wobei zum Verschlüsseln ein öffentlicher Schlüssel zusammen mit einem öffentlichen Parameter verwendet wird, wobei der öffentliche Schlüssel von einem eindeutigen Serviceidentifizierer abgleitet wird. Als Verschlüsselungsverfahren kann hier beispielsweise ein asymmetrisches kryptographisches Verfahren, insbesondere ein identitätsbasierendes kryptographisches Verfahren [1], eingesetzt werden.
  • Zusätzlich umfasst das Verfahren einen zweiten Verfahrensschritt zum Generieren 120 einer Serviceanfrage durch die Anfrageentität, wobei die Serviceanfrage den eindeutigen Serviceidentifizierer, beispielsweise eine eindeutige Ticketnummer, und den verschlüsselten Sicherheitstoken umfasst.
  • Die Serviceanfrage kann zusätzlich eine Beschreibung des Servicefalls, beispielsweise eine genaue Fehlerbeschreibung, enthalten. Für den eindeutigen Serviceidentifizierer ist vorzugsweise sicherzustellen, dass es eine 1-zu-1-Beziehung zwischen eindeutigen Serviceidentifizierer und Service-Anfragen gibt, auch über verschiedene Betreiber von Netzwerken oder Betreibern von Anfrageentitäten hinweg. Beispielsweise können hierfür verschiedene Namensräume definiert werden. Der Sicherheitstoken ist vorzugsweise für genau diese Serviceanfrage erzeugt und nur dafür gültig. Der öffentliche Schlüssel für den verschlüsselten Sicherheitstoken ist vorzugsweise der eindeutige Serviceidentifizierer.
  • Zusätzlich umfasst das Verfahren einen dritten Verfahrensschritt zum Übermitteln 130 der Serviceanfrage an eine zweite Serviceentität. Das Übermitteln kann beispielsweise über ein Netzwerk, insbesondere ein Ethernetnetzwerk oder einer öffentlichen Internetkommunikation zwischen der Anfrageentität und der Serviceentität durchgeführt werden.
  • Zusätzlich umfasst das Verfahren einen vierten Verfahrensschritt zum Zuweisen 140 der Serviceanfrage durch ein Zuweisungsmodul an die spezifische Serviceentität. Das Zuweisungsmodul umfasst beispielsweise eine Liste von spezifischen Serviceentitäten denen beispielsweise mittels einer Tabelle oder Datenbank bestimmte Aufgaben, beispielsweise ein Aktualisierung einer Firmware für bestimmte Geräte, zugeordnet sind. Hierzu kann das Zuweisungsmodul anhand von vordefinierten Regeln entscheiden welcher spezifischen Serviceentität die Serviceanfrage zugewiesen wird.
  • Zusätzlich umfasst das Verfahren einen fünften Verfahrensschritt zum Übermitteln 150 der Serviceanfrage durch die spezifische Serviceentität an ein Autorisierungsmodul.
  • Zusätzlich umfasst das Verfahren einen sechsten Verfahrensschritt bei dem das Autorisierungsmodul überprüft 160, ob die spezifische Serviceentität für das Gerät hinsichtlich der Serviceanfrage zugriffsberechtigt ist.
  • Mit anderen Worten prüft das Autorisierungsmodul anhand von internen Regeln oder anhand von vordefinierten Regeln oder evtl. anhand einer Security Policy, ob die spezifische Serviceentität berechtigt ist, die betreffende Serviceanfrage zu übernehmen und/oder Zugriff auf das Gerät zu erhalten. Die dazu benötigte Authentisierung kann beispielsweise mit digitalen Signaturen durchgeführt werden. Dies wird insbesondere dadurch sichergestellt, dass dem Schlüsselserver zu keinem Zeitpunkt der verschlüsselte/entschlüsselte Sicherheitstoken bekannt gemacht wird.
  • Zusätzlich umfasst das Verfahren einen siebten Verfahrensschritt zum Übermitteln 170 einer Identität der spezifischen Serviceentität und des eindeutigen Serviceidentifizierers an einen Schlüsselserver durch das Autorisierungsmodul, wenn die spezifische Serviceentität für das Gerät zugriffsberechtigt ist. Das Autorisierungsmodul kann beispielsweise auch ein integraler Bestandteil des Schlüsselservers sein.
  • Zusätzlich umfasst das Verfahren einen achten Verfahrensschritt zum Berechnen 180 eines privaten Schlüssels zum Entschlüsseln des verschlüsselten Sicherheitstokens anhand des eindeutigen Serviceidentifizierers durch den Schlüsselserver.
  • Zusätzlich umfasst das Verfahren einen neunten Verfahrensschritt zum Übermitteln 190 des privaten Schlüssels an die spezifische Serviceentität durch den Schlüsselserver.
  • Der Schlüsselserver kann in dieser Ausführungsform beispielsweise als externe Komponente ausgebildet sein. Alternativ kann der Schlüsselserver aber auch eine integrale Komponente der zweiten Serviceentität sein.
  • Mit anderen Worten nutzt das Verfahren eine identitätsbasierte Verschlüsselung, um der spezifischen Serviceentität einen Sicherheitstoken für den Zugriff auf eine zu wartende Komponente, beispielsweise das Gerät, bereitzustellen. Dabei wird insbesondere sichergestellt, dass der Schlüsselserver zu keinem Zeitpunkt Zugriff auf den verschlüsselten oder entschlüsselten Sicherheitstoken hat.
  • Hierbei erhält die spezifische Serviceentität vom Zuweisungsmodul, beispielsweise einem Work Dispatcher, den verschlüsselten Sicherheitstoken für den Zugriff auf die zu wartende Komponente. Alternativ kann die spezifische Serviceentität sich diesen Sicherheitstoken als Teil seines Wartungsauftrages auch vom Work Dispatcher abholen. Um diesen Sicherheitstoken zu entschlüsseln, muss die spezifische Serviceentität auf den zugeordneten Schlüsselserver zugreifen.
  • In diesem Kontext wird die Autorisierung des Servicetechnikers durch das Autorisierungsmodul geprüft. Die Autorisierung der spezifischen Serviceentität wird typischerweise an die Authentisierung gebunden. Die Authentisierung der spezifischen Serviceentität kann über typische Mechanismen realisiert werden, wie beispielsweise einen Nutzernamen und Password oder ein digitales Zertifikat insbesondere in Form eines X.509 Zertifikats und zugehörige private Schlüssel.
  • Die Besonderheit bei der Verwendung der identitätsbasierenden Verschlüsselung besteht darin, dass die Identität des Empfängers (z. B. die Email-Adresse oder eine Telefonnummer) identisch mit dem öffentlichen Schlüssel des Empfängers ist. Das heißt beispielsweise, dass ein Sender an einen Empfänger eine (mit diesem öffentlichen Schlüssel) verschlüsselte Mail schicken kann, und dafür kein Zertifikat benötigt, das einen öffentlichen Schlüssel an eine gegebene Identität bindet.
  • Nun können mithilfe eines geeigneten Verfahrens neben der Identität des Empfängers auch noch bestimmte Attribute Teil der Identität werden, die beispielsweise einen bestimmten Servicefall in Form des eindeutigen Serviceidentifizierers, beinhalten können. Ein Beispiel für eine solche Identität ist: Ticket 4711@example.com. In dem Beispiel wäre das so zu interpretieren, dass die Mail an den Servicetechniker gerichtet ist, der das Ticket Nr. 4711 bearbeiten soll. Für diese Identität (Ticket Nr. 4711) verschlüsselt die Anfrageentität das für den Zugang erforderliche Sicherheitstoken. Bis zu diesem Zeitpunkt muss die Anfrageentität nicht mit der zweiten Serviceentität kommunizieren, um den Sicherheitstoken auszutauschen.
  • In einer Variante verschickt die Anfrageentität eine Mail, die die Serviceanfrage und den verschlüsselte Sicherheitstoken enthält, an die Email-Adresse, die mit der Identität identisch ist, wobei angenommen wird, dass die Domain example.com zu der zweiten Serviceentität gehört. Die Email wird innerhalb der zweiten Serviceentität einer spezifischen Serviceentität zugeordnet, die den Servicefall bearbeiten soll (Autorisation). Die spezifische Serviceentität bekommt nun den privaten Schlüssel zugestellt, mit dem er den verschlüsselten Sicherheitstoken entschlüsseln kann. Das Schlüsselmaterial, das der Sicherheitstoken umfasst, dient dann als Authentisierungsmerkmal, um zum Gerät einen Fernzugriff herzustellen.
  • In einer weiteren Variante, kann der Sicherheitstoken an eine bestimmte Security Policy, insbesondere bezüglich seiner Auslieferung/Erstellung, gebunden sein. Für die Auslieferung/Erstellung können beispielsweise folgende Bedingungen gelten:
    • – Vordefinieren einer bestimmten Authentisierung der spezifischen Serviceentität aus einer Vielzahl von Authentisierungsmöglichkeiten, beispielsweise ein Einmalpasswort und/oder ein digitales Zertifikat und/oder ein Benutzername mit einem Passwort und/oder biometrisch Authentisierungsverfahren.
    • – Vordefinieren eines Zeitpunktes oder Zeitintervalls, der eine Abholung der Serviceanfrage oder die Abarbeitung der Serviceanfrage festlegt.
  • Es besteht insbesondere die Annahme, dass es für die Abarbeitung bzw. für das Senden der Serviceanfrage ein entsprechendes Service Level Agreement zwischen der Anfrageentität und der zweiten Serviceentität gibt.
  • 2 zeigt ein System eines zweiten Ausführungsbeispiels, welches ein erfindungsgemäßes Verfahren implementiert. 2 kann beispielsweise eine konkrete Implementierung des ersten Ausführungsbeispiels sein.
  • Das System umfasst eine zweite Serviceentität 210 und eine Anfrageentität 252. Die Anfrageentität 252 ist insbesondere ein Teil einer Anlage 250. Im Einzelnen kann die Anlage 250 weitere Anfrageentitäten 257 umfassen. Die Anlage kann mehrere Netzwerke, insbesondere ein erstes Netzwerk 253 und/oder ein zweites Netzwerk 260, umfassen, mit dem eine Anfrageentität, insbesondere die Anfrageentität 252 oder die weitere Anfrageentität 257, kommunikativ verbunden ist. Mit dem ersten Netzwerk sind vorzugsweise zusätzlich Geräte, insbesondere ein Gerät 255 und ein zweites Gerät 254, verbunden. Mit dem zweiten Netzwerk sind vorzugsweise zusätzlich Geräte, insbesondere ein weiteres Gerät 258 verbunden. Den Anfrageentitäten 252, 257 sind jeweils ein Betreiber 251, 256 der Anfrageentitäten 252, 257 und/oder der Netzwerke 253, 260 zugeordnet.
  • Die Anfrageentität 252 ist dazu ausgebildet Serviceanfragen zu generieren und an die zweite Serviceentität 210 zu übermitteln 130. Die Serviceanfrage umfasst einen zuvor verschlüsselten Sicherheitstoken und einen eindeutigen Serviceidentifizierer. Die Anfrageentität 252 generiert und übermittelt in diesem Ausführungsbeispiel für das erste Gerät 255 die Serviceanfrage.
  • Die zweite Serviceentität 210, die auch ein Teil der Anlage 250 sein kann, umfasst ein Zuweisungsmodul 211, eine spezifische Serviceentität 212, mindestens eine weitere spezifische Serviceentität 213, ein Autorisierungsmodul 214 und einen Schlüsselserver 215. Das Autorisierungsmodul 214 kann beispielsweise als integrale Komponente des Schlüsselservers 215 ausgebildet sein. Der Schlüsselserver 215 und/oder das Autorisierungsmodul 214 können auch als eine externe Komponente ausgebildet sein.
  • Das Zuweisungsmodul 211 weist 140 die Serviceanfrage der spezifischen Serviceentität 212 zu, die zur Abarbeitung der Serviceanfrage geeignet ist. Die spezifische Serviceentität 212 übermittelt 150 die Serviceanfrage an das Autorisierungsmodul 214 und das Autorisierungsmodul 214 überprüft, ob die spezifische Serviceentität für das Gerät 255 hinsichtlich der Serviceanfrage zugriffsberechtigt ist.
  • Stellt das Autorisierungsmodul 214 fest, dass die spezifische Serviceentität 212 für das erste Gerät 255 zugriffsberechtigt ist, übermittelt 170 das Autorisierungsmodul 214 eine Identität der spezifischen Serviceentität 212 und den eindeutigen Serviceidentifizierer an den Schlüsselserver 215. Wird jedoch festgestellt, dass die spezifische Serviceentität 212 nicht zugriffsberichtigt ist, wird das Übermitteln nicht durchgeführt und somit ein Zugriff auf das erste Gerät 255 unterbunden.
  • Der Schlüsselserver 215 berechnet einen privaten Schlüssel zum Entschlüsseln des verschlüsselten Sicherheitstokens anhand des eindeutigen Serviceidentifizierers. Anschließend übermittelt 190 der Schlüsselserver 215 anhand der Identität den privaten Schlüssel an die spezifische Serviceentität 212. Dies erfolgt geeignet in verschlüsselter Form, z. B. in Abhängigkeit der Authentisierung der spezifischen Serviceentität.
  • Die spezifische Serviceentität 212 entschlüsselt mit dem privaten Schlüssel den Sicherheitstoken und greift 236 auf das erste Gerät 255, indem die spezifische Serviceentität 212 beispielsweise das im Sicherheitstoken enthaltene Schlüsselmaterial nutzt.
  • Mit anderen Worten zeigt 2 das Zusammenwirken zwischen Betreibern 251, 256 der Anfrageentitäten 252, 257 mit Betreibern von Kommunikationsnetzen, insbesondere der zweiten Serviceentität 210. Zwischen den verschiedenen Betreibern existieren typischerweise Service Level Agreements (SLA).
  • Insbesondere kann sich in dem dargestellten Ausführungsbeispiel die spezifische Serviceentität 212, insbesondere ein Servicetechniker oder ein Serviceprozess, der für die Geräte 254, 255, 258 zuständig ist, insbesondere auf dem ersten Gerät 255, anmelden, um beispielsweise die Parametrierung zu ändern oder Wartungsdaten auszulesen. Dazu können domänenspezifische Protokolle wie IEC 61850 verwendet werden, aber auch Standardwebprotokolle wie https verwendet werden. Letzteres insbesondere dadurch, dass viele Geräte schon integrierte Web-Server unterstützen.
  • Ziel ist es hier, dass sich die spezifische Serviceentität 212 auf dem ersten Gerät 255 autorisiert anmelden kann, wobei das erste Gerät 255 diesen Zugriff authentisieren soll. Hierbei ist es oftmals ausreichend die Rolle der spezifischen Serviceentität 212 zu überprüfen und nicht die spezifische Serviceentität 212 als einzelne Entität.
  • Das vermeidet, dass ein Administrator die Zugangsdaten für jeden mögliche spezifische Serviceentität auf dem ersten Gerät 255 konfigurieren muss. Um beispielsweise nun zusätzlich flexibel zu sein, um eine spezifische Serviceentität nach Aufgabenplanung zuzuweisen, wird der hier vorgeschlagene Ansatz umgesetzt.
  • Der Zugriff wird dabei über ein Netzwerk von der zweiten Serviceentität 210 realisiert, das zwar als vertrauenswürdig bzgl. des Transports der Daten angesehen wird, jedoch keinen Zugriff auf den unverschlüsselten Sicherheitstoken ermöglichen soll. Der Zugang zu diesem Netzwerk wird von zweiten Serviceentität 210 entsprechend den Service Level Agreement kontrolliert.
  • Die 3 zeigt ein System eines dritten Ausführungsbeispiels, welches ein erfindungsgemäßes Verfahren implementiert. 3 kann beispielsweise eine konkrete Implementierung des ersten Ausführungsbeispiels sein.
  • Das System ist dazu ausgelegt ein gesichertes Zugreifen, insbesondere einen Fernzugriff, einer spezifischen Serviceentität 212 auf ein Gerät 254 zu ermöglichen.
  • Das System ist beispielsweise Teil einer Anlage 250 und umfasst eine Anfrageentität 252 und/oder eine weitere Anfrageentität 257, die jeweils einem Betreiber 251, 256 zugeordnet sein können. Zusätzlich umfasst das System eine zweite Serviceentität 210.
  • Die Anfrageentität 252 umfasst darüber hinaus ein Verschlüsselungsmodul 410, ein Generierungsmodul 420 und ein erstes Übermittlungsmodul 430, die über einen Bus 402 kommunikativ miteinander verbunden sind. Die Anfrageentität 252 ist insbesondere über ein erstes Netzwerk 253 mit einem ersten Gerät 254 und einem zweiten Gerät 255 verbunden. Die Anfrageentität 252 kann zusätzlich noch einen Prozessor und/oder eine Speichereinrichtung aufweisen.
  • Die Anfrageentität 252 verschlüsselt mit dem Verschlüsselungsmodul 410 einen Sicherheitstoken, wobei zum Verschlüsseln ein öffentlicher Schlüssel zusammen mit einem öffentlichen Parameter verwendet wird, wobei der öffentliche Schlüssel von einem eindeutigen Serviceidentifizierer abgeleitet wird.
  • Die Anfrageentität 252 generiert mit dem Generierungsmodul 420 eine Serviceanfrage, wobei die Serviceanfrage den eindeutigen Serviceidentifizierer und den verschlüsselten Sicherheitstoken umfasst. Die Serviceanfrage ist beispielsweise für das erste Gerät 254 generiert worden.
  • Die Anfrageentität 252 übermittelt mit dem ersten Übermittlungsmodul 430 die Serviceanfrage an die zweite Serviceentität.
  • Die zweite Serviceentität 210 umfasst ein Zuweisungsmodul 211, ein zweites Übermittlungsmodul 450, ein Autorisierungsmodul 214, ein drittes Übermittlungsmodul 470, einen Schlüsselserver 215 und ein viertes Übermittlungsmodul 490, die über ein drittes Netzwerk 401, beispielsweise ein Ethernetnetzwerk 401, miteinander kommunikativ in Verbindung stehen. Die zweite Serviceentität 210, das Autorisierungsmodul 214 und/oder der Schlüsselserver 215 können jeweils zusätzlich noch einen Prozessor und/oder eine Speichereinrichtung aufweisen.
  • Das Zuweisungsmodul 211 kann ebenfalls ein weiteres Übermittlungsmodul 255 aufweisen, damit es die Serviceanfrage an die spezifische Serviceentität 212 übermitteln kann.
  • Die zweite Serviceentität 210 weist mit dem Zuweisungsmodul 211 die Serviceanfrage der spezifischen Serviceentität 212 zu. Die spezifische Serviceentität 212 kann zusätzlich noch einen Prozessor und/oder eine Speichereinrichtung aufweisen.
  • Die spezifische Serviceentität 212 übermittelt mit dem zweiten Übermittlungsmodul 450 die Serviceanfrage an ein Autorisierungsmodul 214;
  • Das Autorisierungsmodul 214 überprüft, ob die spezifische Serviceentität 212 für das Gerät, insbesondere das erste Gerät 254, hinsichtlich der Serviceanfrage zugriffsberechtigt ist.
  • Das Autorisierungsmodul 214 übermittelt mit dem dritten Übermittlungsmodul 470 eine Identität der spezifischen Serviceentität und den eindeutigen Serviceidentifizierer an einen Schlüsselserver 215, wenn die spezifische Serviceentität 212 für das Gerät zugriffsberechtigt ist.
  • Der Schlüsselserver 215 berechnet einen privaten Schlüssel zum Entschlüsseln des verschlüsselten Sicherheitstokens anhand des eindeutigen Serviceidentifizierers.
  • Der Schlüsselserver 215 übermittelt mit dem vierten Übermittlungsmodul 490 den privaten Schlüssel an die spezifische Serviceentität durch den Schlüsselserver.
  • In einer Variante sind die Anfrageentitäten beispielsweise als IBM-kompatible Computer ausgebildet, die eine Computermaus und eine Tastatur als Eingabegeräte umfassen. Zusätzlich kann eine Anfrageentität einen Bildschirm, beispielsweise einen TFT-Monitor, umfassen.
  • Die Komponenten (Module, Entitäten, Server) der Erfindung können, sofern nicht anders angegeben oder bereits erwähnt, jeweils einen eigenen Prozessor und/oder Speichereinrichtung aufweisen, um das Verfahren zu implementieren und/oder auszuführen. Die Komponenten können auch weitere typtische Einrichtungen aufweisen, die einem Fachmann bekannt sind. Beispielsweise Eingabegeräte und/oder Anzeigegeräte.
  • Obwohl die Erfindung im Detail durch die Ausführungsbeispiele näher illustriert und beschrieben wurde, ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt, und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen.
  • Literaturstellen
    • [1] Appears in SIAM J. of Computing, Vol. 32, No. 3, pp. 586–615, 2003. An extended abstract of this paper appears in the Proceedings of Crypto 2001, volume 2139 of Lecture Notes in Computer Science, pages 213–229, Springer-Verlag, 2001.
  • 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 Patentliteratur
    • US 8531247 B2 [0005]
    • US 8892616 B2 [0005]
    • US 8300811 B2 [0005]
    • US 9147088 B2 [0005]
    • EP 2605445 B1 [0005]
    • EP 2870565 A1 [0005]
    • EP 2891102 A1 [0005]
    • US 8843761 B2 [0005]
  • Zitierte Nicht-Patentliteratur
    • IEC 61850 [0081]

Claims (14)

  1. Verfahren zum gesicherten Zugreifen einer spezifischen Serviceentität (212) auf ein Gerät (254) mit den Verfahrensschritten: – Verschlüsseln (110) eines Sicherheitstokens durch eine Anfrageentität (252), wobei zum Verschlüsseln ein öffentlicher Schlüssel zusammen mit einem öffentlichen Parameter verwendet wird, wobei der öffentliche Schlüssel von einem eindeutigen Serviceidentifizierer abgleitet wird; – Generieren (120) einer Serviceanfrage durch die Anfrageentität (252), wobei die Serviceanfrage den eindeutigen Serviceidentifizierer und den verschlüsselten Sicherheitstoken umfasst; – Übermitteln (130) der Serviceanfrage an eine zweite Serviceentität (210); – Zuweisen (140) der Serviceanfrage durch ein Zuweisungsmodul (211) an die spezifische Serviceentität (212); – Übermitteln (150) der Serviceanfrage durch die spezifische Serviceentität (212) an ein Autorisierungsmodul (214); – Überprüfen (160) durch das Autorisierungsmodul (214), ob die spezifische Serviceentität (212) für das Gerät (254) hinsichtlich der Serviceanfrage zugriffsberechtigt ist; – Übermitteln (170) einer Identität der spezifischen Serviceentität (212) und des eindeutigen Serviceidentifizierers an einen Schlüsselserver (215) durch das Autorisierungsmodul (214), wenn die spezifische Serviceentität (212) für das Gerät (254) zugriffsberechtigt ist; – Berechnen (180) eines privaten Schlüssels zum Entschlüsseln des verschlüsselten Sicherheitstokens anhand des eindeutigen Serviceidentifizierers durch den Schlüsselserver (215); und – Übermitteln (190) des privaten Schlüssels an die spezifische Serviceentität (212) durch den Schlüsselserver (215).
  2. Verfahren nach Anspruch 1, wobei die spezifische Serviceentität (212) den verschlüsselten Sicherheitstoken entschlüsselt und mittels des entschlüsselten Sicherheitstokens auf das Gerät (254) zugreift.
  3. Verfahren nach Anspruch 1 oder 2, wobei der Sicherheitstoken für jede Serviceanfrage spezifisch erzeugt wird.
  4. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Überprüfen, ob die spezifische Serviceentität (212) zugriffsberechtigt ist, anhand eines Benutzernamens und Passworts und/oder eines digitalen Zertifikats und/oder von vordefinierten Regeln und/oder anhand einer biometrischen Information durchgeführt wird.
  5. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Sicherheitstoken an eine Security-Policy gebunden ist.
  6. Verfahren nach Anspruch 5, wobei die Security-Policy vorgibt, wie das Überprüfen, ob die spezifische Serviceentität (212) zugriffsberechtigt ist, durchgeführt wird.
  7. Verfahren nach einem der vorhergehenden Ansprüche, wobei für das Berechnen des privaten Schlüssels ein dem öffentlichen Parameter zugeordneter privater Parameter verwendet wird.
  8. Verfahren nach einem der vorhergehenden Ansprüche, insbesondere nach Anspruch 7, wobei der öffentliche Parameter der Anfrageentität (252) vor dem Verschlüsseln bekannt gemacht wird und der private Parameter dem Schlüsselserver (215) vor dem Berechnen des privaten Schlüssels bekannt gemacht wird.
  9. Verfahren nach einem der vorhergehenden Ansprüche, insbesondere nach Anspruch 7 oder 8, wobei der Schlüsselserver (215) den öffentlichen Parameter und den privaten Parameter berechnet und den öffentlichen Parameter bekannt macht.
  10. System zum gesicherten Zugreifen einer spezifischen Serviceentität (212) auf ein Gerät (254) aufweisend: – eine Anfrageentität (252) umfassend, – ein Verschlüsselungsmodul (410) zum Verschlüsseln eines Sicherheitstokens durch die Anfrageentität (252), wobei zum Verschlüsseln ein öffentlicher Schlüssel zusammen mit einem öffentlichen Parameter verwendet wird, wobei der öffentliche Schlüssel von einem eindeutigen Serviceidentifizierer abgleitet wird; – ein Generierungsmodul (420) zum Generieren einer Serviceanfrage durch die Anfrageentität (252), wobei die Serviceanfrage den eindeutigen Serviceidentifizierer und den verschlüsselten Sicherheitstoken umfasst; – ein erstes Übermittlungsmodul (430) zum Übermitteln der Serviceanfrage an eine zweite Serviceentität (210); – die zweite Serviceentität (210) umfassend, – ein Zuweisungsmodul (211), das die Serviceanfrage der spezifischen Serviceentität (212) zuweist; – ein zweites Übermittlungsmodul (450) zum Übermitteln der Serviceanfrage durch die spezifische Serviceentität (212) an ein Autorisierungsmodul (214), wobei das Autorisierungsmodul (214) überprüft, ob die spezifische Serviceentität (212) für das Gerät (254) hinsichtlich der Serviceanfrage zugriffsberechtigt ist; – ein drittes Übermittlungsmodul (470) zum Übermitteln einer Identität der spezifischen Serviceentität und des eindeutigen Serviceidentifizierers an einen Schlüsselserver (215) durch das Autorisierungsmodul (214), wenn die spezifische Serviceentität (212) für das Gerät (254) zugriffsberechtigt ist, wobei der Schlüsselserver (215) einen privaten Schlüssel zum Entschlüsseln des verschlüsselten Sicherheitstokens anhand des eindeutigen Serviceidentifizierers berechnet; und – ein viertes Übermittlungsmodul (490) zum Übermitteln des privaten Schlüssels an die spezifische Serviceentität (212) durch den Schlüsselserver (215).
  11. System nach Anspruch 10, wobei das Autorisierungsmodul und/oder der Schlüsselserver externe Komponenten sind, wobei insbesondere mittels des Schlüsselservers der öffentliche Parameter der Anfrageentität bekannt gemacht wird.
  12. Computerprogrammprodukt mit Programmbefehlen zur Durchführung des Verfahrens nach einem der Ansprüche 1–9.
  13. Computerprogrammprodukt mit Programmbefehlen für ein Erstellungsgerät, das mittels der Programmbefehle konfiguriert wird, das System nach einem der Ansprüche 10–11 zu erstellen.
  14. Bereitstellungsvorrichtung für das Computerprogrammprodukt nach Anspruch 12 oder 13, wobei die Bereitstellungsvorrichtung das Computerprogrammprodukt speichert und/oder bereitstellt.
DE102016207635.3A 2016-05-03 2016-05-03 Verfahren und Vorrichtung zur Absicherung von Gerätezugriffen Withdrawn DE102016207635A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102016207635.3A DE102016207635A1 (de) 2016-05-03 2016-05-03 Verfahren und Vorrichtung zur Absicherung von Gerätezugriffen
PCT/EP2017/053453 WO2017190857A1 (de) 2016-05-03 2017-02-16 Verfahren und vorrichtung zur absicherung von gerätezugriffen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102016207635.3A DE102016207635A1 (de) 2016-05-03 2016-05-03 Verfahren und Vorrichtung zur Absicherung von Gerätezugriffen

Publications (1)

Publication Number Publication Date
DE102016207635A1 true DE102016207635A1 (de) 2017-11-09

Family

ID=58108584

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102016207635.3A Withdrawn DE102016207635A1 (de) 2016-05-03 2016-05-03 Verfahren und Vorrichtung zur Absicherung von Gerätezugriffen

Country Status (2)

Country Link
DE (1) DE102016207635A1 (de)
WO (1) WO2017190857A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112187786B (zh) * 2020-09-25 2023-08-22 深圳乐信软件技术有限公司 网络服务的业务处理方法、装置、服务器及存储介质

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8300811B2 (en) 2008-12-10 2012-10-30 Siemens Aktiengesellschaft Method and device for processing data
US8531247B2 (en) 2008-04-14 2013-09-10 Siemens Aktiengesellschaft Device and method for generating a random bit sequence
US20130339754A1 (en) * 2011-03-25 2013-12-19 Nippon Telegraph And Telephone Corporation Cryptographic processing system, key generation device, encryption device, decryption device, cryptographic processing method, and cryptographic processing program
US8843761B2 (en) 2007-08-16 2014-09-23 Siemens Aktiengesellschaft Method and apparatus for protection of a program against monitoring flow manipulation and against incorrect program running
US20140289525A1 (en) * 2009-08-28 2014-09-25 Sunil C. Agrawal System and method for decentralized management of keys and policies
US8892616B2 (en) 2007-08-27 2014-11-18 Siemens Aktiengesellschaft Device and method for generating a random bit sequence
EP2870565A1 (de) 2012-09-28 2015-05-13 Siemens Aktiengesellschaft Überprüfung einer integrität von eigenschaftsdaten eines gerätes durch ein prüfgerät
EP2891102A1 (de) 2013-01-02 2015-07-08 Siemens Aktiengesellschaft Rfid-tag und verfahren zum betreiben eines rfid-tags
US9147088B2 (en) 2011-04-18 2015-09-29 Siemens Aktiengesellschaft Method for monitoring a tamper protection and monitoring system for a field device having tamper protection
EP2605445B1 (de) 2011-12-14 2015-09-30 Siemens Aktiengesellschaft Verfahren und Vorrichtung zur Absicherung von Blockchiffren gegen Template-Attacken

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1262087C (zh) * 2005-01-14 2006-06-28 南相浩 基于标识的密钥产生方法
US8656177B2 (en) * 2008-06-23 2014-02-18 Voltage Security, Inc. Identity-based-encryption system
WO2013128470A1 (en) * 2012-02-27 2013-09-06 Deshpande Nachiket Girish Authentication and secured information exchange system, and method therefor

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8843761B2 (en) 2007-08-16 2014-09-23 Siemens Aktiengesellschaft Method and apparatus for protection of a program against monitoring flow manipulation and against incorrect program running
US8892616B2 (en) 2007-08-27 2014-11-18 Siemens Aktiengesellschaft Device and method for generating a random bit sequence
US8531247B2 (en) 2008-04-14 2013-09-10 Siemens Aktiengesellschaft Device and method for generating a random bit sequence
US8300811B2 (en) 2008-12-10 2012-10-30 Siemens Aktiengesellschaft Method and device for processing data
US20140289525A1 (en) * 2009-08-28 2014-09-25 Sunil C. Agrawal System and method for decentralized management of keys and policies
US20130339754A1 (en) * 2011-03-25 2013-12-19 Nippon Telegraph And Telephone Corporation Cryptographic processing system, key generation device, encryption device, decryption device, cryptographic processing method, and cryptographic processing program
US9147088B2 (en) 2011-04-18 2015-09-29 Siemens Aktiengesellschaft Method for monitoring a tamper protection and monitoring system for a field device having tamper protection
EP2605445B1 (de) 2011-12-14 2015-09-30 Siemens Aktiengesellschaft Verfahren und Vorrichtung zur Absicherung von Blockchiffren gegen Template-Attacken
EP2870565A1 (de) 2012-09-28 2015-05-13 Siemens Aktiengesellschaft Überprüfung einer integrität von eigenschaftsdaten eines gerätes durch ein prüfgerät
EP2891102A1 (de) 2013-01-02 2015-07-08 Siemens Aktiengesellschaft Rfid-tag und verfahren zum betreiben eines rfid-tags

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
Appears in SIAM J. of Computing, Vol. 32, No. 3, pp. 586–615, 2003. An extended abstract of this paper appears in the Proceedings of Crypto 2001, volume 2139 of Lecture Notes in Computer Science, pages 213–229, Springer-Verlag, 2001
IEC 61850
RSA-Kryptosystem. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand: 13. April 2016. URL: https://de.wikipedia.org/wiki/RSA-Kryptosystem?oldid=153438875 [abgerufen am 26. Januar 2016] *
RSA-Kryptosystem. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand: 13. April 2016. URL: https://de.wikipedia.org/wiki/RSA-Kryptosystem?oldid=153438875 [abgerufen am 26. Januar 2016]

Also Published As

Publication number Publication date
WO2017190857A1 (de) 2017-11-09

Similar Documents

Publication Publication Date Title
EP3488555B1 (de) Gesichertes verarbeiten einer berechtigungsnachweisanfrage
DE602005001613T2 (de) Einrichten eines sicheren kontexts zur übermittlung von nachrichten zwischen computersystemen
EP3125492B1 (de) Verfahren und system zum erzeugen eines sicheren kommunikationskanals für endgeräte
DE112011101729B4 (de) Verwaltung von Ressourcenzugriff
EP3292496B1 (de) Vorrichtung und verfahren zum verwenden eines kunden-geräte-zertifikats auf einem gerät
DE102017124844A1 (de) Sicheres Transportieren von Daten über eine Datendiode für gesicherte Prozesssteuerungskommunikationen
DE102017124821A1 (de) Veröffentlichung von daten über eine datendiode für gesicherte prozesssteuerungskommunikationen
EP3681102B1 (de) Verfahren zur validierung eines digitalen nutzerzertifikats
DE112011102224B4 (de) Identitätsvermittlung zwischen Client- und Server-Anwendungen
EP3031226A1 (de) Unterstützung der nutzung eines geheimen schlüssels
DE102013203101A1 (de) Erweitern der Attribute einer Credentialanforderung
DE102016222523A1 (de) Verfahren und Vorrichtung zum Übertragen von Daten in einem Topic-basierten Publish-Subscribe-System
WO2020108847A1 (de) Verfahren und vorrichtung zum übertragen von daten in einem publish-subscribe-system
EP3058701B1 (de) Verfahren, verwaltungsvorrichtung und gerät zur zertifikat-basierten authentifizierung von kommunikationspartnern in einem gerät
DE102017211267A1 (de) Verfahren zum Schützen einer Zertifikatsanforderung eines Clienten-Rechners und entsprechendes Kommunikationssystem
DE102017201891A1 (de) Programmierbares Hardware-Sicherheitsmodul und Verfahren auf einem programmierbaren Hardware-Sicherheitsmodul
DE102016207635A1 (de) Verfahren und Vorrichtung zur Absicherung von Gerätezugriffen
EP3734478A1 (de) Verfahren zur vergabe von zertifikaten, leitsystem, verwendung eines solchen, technische anlage, anlagenkomponente und verwendung eines identitätsproviders
EP3672142A1 (de) Verfahren und system zur sicheren übertragung eines datensatzes
DE102018102608A1 (de) Verfahren zur Benutzerverwaltung eines Feldgeräts
DE60219915T2 (de) Verfahren zur Sicherung von Kommunikationen in einem Computersystem
EP3945702A1 (de) Kanalbasierte kommunikation in einem iot-netzwerk
EP3739834A1 (de) Verfahren, vorrichtung und anordnung zum verarbeiten von daten
DE102015208176A1 (de) Gerät und Verfahren zur Autorisierung eines privaten kryptographischen Schlüssels in einem Gerät
EP3881486B1 (de) Verfahren zur bereitstellung eines herkunftsortnachweises für ein digitales schlüsselpaar

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee