Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD AND DEVICE FOR PROTECTING DEVICE ACCESS
Document Type and Number:
WIPO Patent Application WO/2017/190857
Kind Code:
A1
Abstract:
The invention relates to a method for secured access of a specific service entity (212) to a device (254). The method comprises a method step for encrypting (110) a security token via an enquiry entity (252), wherein a public key is used for encryption, together with a public parameter, wherein the public key is derived from a distinct service identifier. The method also comprises a method step for generating (120) a service enquiry via the enquiry unit (252), wherein the service enquiry includes the distinct service identifier and the encrypted security token. The method also comprises a method step for transmitting (130) the service enquiry to a second service entity (210). The method also comprises a method step for assigning (140) the service enquiry to the specific service entity (212) via an assignment module (211). The method also comprises a method step for transmitting (150) the service enquiry to an authorisation module (214) via the specific service entity (212). The method also comprises a method step for checking (160), via the authorisation module (214), whether the specific service entity (212) is authorised for access to the device (254) in terms of the service enquiry. The method also comprises a method step for transmitting (170) an identity of the specific service entity (212) and the distinct service identifier to a key server (215) via the authorisation module (214), if the specific service entity (212) is authorised for access to the device (254). The method also comprises a method step for computing (180) a private key for decrypting the encrypted security token, based on the distinct service identifier via the key server (215). The method further comprises a method step for transmitting (190) the private key to the specific service entity (212) via the key server (215).

Inventors:
ASCHAUER HANS (DE)
FRIES STEFFEN (DE)
Application Number:
PCT/EP2017/053453
Publication Date:
November 09, 2017
Filing Date:
February 16, 2017
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SIEMENS AG (DE)
International Classes:
H04L29/06; G06F21/44; H04L9/08; H04L9/30; H04L9/32
Foreign References:
US20100017593A12010-01-21
EP1843509A12007-10-10
US20150082025A12015-03-19
US8531247B22013-09-10
US8892616B22014-11-18
US8300811B22012-10-30
US9147088B22015-09-29
EP2605445B12015-09-30
EP2870565A12015-05-13
EP2891102A12015-07-08
US8843761B22014-09-23
Other References:
DAN BONEH ET AL: "Identity-Based Encryption from the Weil Pairing", SIAM JOURNAL ON COMPUTING, 2001, Philadelphia, pages 586 - 615, XP055370165, Retrieved from the Internet [retrieved on 20170508], DOI: 10.1137/S0097539701398521
APPEARS IN SIAM J. OF COMPUTING, vol. 32, no. 3, 2003, pages 586 - 615
"Proceedings of Crypto 2001", vol. 2139, 2001, SPRINGER-VERLAG, pages: 213 - 229
Download PDF:
Claims:
Patentansprüche

1. Verfahren zum gesicherten Zugreifen einer spezifischen

Serviceentität (212) auf ein Gerät (254) mit den Verfah- rensschritten :

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 Anfrage- entität (252), wobei die Serviceanfrage den eindeutigen Serviceidentifizierer und den verschlüsselten Sicher- heitstoken umfasst;

Übermitteln (130) der Serviceanfrage an eine zweite Ser¬ viceentität (210);

Zuweisen (140) der Serviceanfrage durch ein Zuweisungs¬ modul (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 Serviceidentifi- zierers 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üs¬ seln des verschlüsselten Sicherheitstokens anhand des eindeutigen Serviceidentifizierers durch den Schlüssel¬ server (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 Ser- viceentität (212) den verschlüsselten Sicherheitstoken entschlüsselt und mittels des entschlüsselten Sicher- heitstokens 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 Service¬ entitä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 Parame¬ ter der Anfrageentität (252) vor dem Verschlüsseln bekannt gemacht wird und der private Parameter dem Schlüs¬ selserver (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üssel¬ server (215) den öffentlichen Parameter und den privaten Parameter berechnet und den öffentlichen Parameter bekannt macht .

System zum gesicherten Zugreifen einer spezifischen Ser- viceentitä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), wo¬ bei die Serviceanfrage den eindeutigen Service- identifizierer und den verschlüsselten Sicherheits- token 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 Übermit¬ teln der Serviceanfrage durch die spezifische Ser¬ viceentitä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 zugriffsbe¬ rechtigt ist;

ein drittes Übermittlungsmodul (470) zum Übermit¬ teln einer Identität der spezifischen Serviceentität und des eindeutigen Serviceidentifizierers an einen Schlüsselserver (215) durch das Autorisierungsmodul (214), wenn die spezifische Serviceenti¬ tä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 Service- identifizierers berechnet; und

ein viertes Übermittlungsmodul (490) zum Übermit¬ teln des privaten Schlüssels an die spezifische Serviceentität (212) durch den Schlüsselserver (215) .

System nach Anspruch 10, wobei das Autorisierungsmodul und/oder der Schlüsselserver externe Komponenten sind, wobei insbesondere mittels des Schlüsselservers der öf¬ fentliche Parameter der Anfrageentität bekannt gemacht wird .

Computerprogrammprodukt mit Programmbefehlen zur Durch¬ führung des Verfahrens nach einem der Ansprüche 1-9.

Computerprogrammprodukt mit Programmbefehlen für ein Erstellungsgerät, das mittels der Programmbefehle konfi guriert wird, das System nach einem der Ansprüche 10-11 zu erstellen.

Bereitstellungsvorrichtung für das Computerprogrammprodukt nach Anspruch 12 oder 13, wobei die Bereitstel¬ lungsvorrichtung das Computerprogrammprodukt speichert und/oder bereitstellt.

Description:
Beschreibung

Verfahren und Vorrichtung zur Absicherung von Gerätezugriffen 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 durchge- fü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 Zu ¬ gangsmechanismus 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. Idealer- weise 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 ei- nes 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 Bl, das Dokument EP 2 870 565 AI, das Dokument EP 2 891 102 AI 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 zugriffgeschultztes 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 Serviceenti- tät auf ein Gerät mit den Verfahrensschritten:

Verschlüsseln eines Sicherheitstokens durch eine Anfra- geentitä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 Anfrageenti- tät, wobei die Serviceanfrage den eindeutigen

Serviceidentifizierer und den verschlüsselten Sicher- heitstoken umfasst;

Übermitteln der Serviceanfrage an eine zweite Serviceen- titä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 spezi ¬ fische 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 ei ¬ nen Schlüsselserver durch das Autorisierungsmodul, wenn die spezifische Serviceentität für das Gerät zugriffsbe ¬ rechtigt ist;

Berechnen eines privaten Schlüssels zum Entschlüsseln des verschlüsselten Sicherheitstokens anhand des eindeu- tigen 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 ei ¬ ne 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 insbesonde ¬ re in Form einer Emailadresse

(z. B. Ticket_1234@service.example.com) oder in Form des eindeutigen Serviceidentifizierers verstanden (z. B. Ti- cket_1234) werden. Die Emailadresse kann beispielsweise aus dem eindeutigen Serviceidentifizierer und einer Domäneninformation aus dem öffentlichen Parameter erzeugt werden. Alter- nativ 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 an ¬ nulliert 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 kryptogra- phische 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. Secu- rity Credentials) , insbesondere Benutzername und Passwort oder digitale Zertifikate, verstanden werden, das beispiels ¬ weise für einen Fernwartungszugriff der spezifischen Serviceentität auf ein zu wartendes Gerät benötigt wird.

Unter einem "eindeutigen Serviceidentifizierer" kann im Zu- sammenhang 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 Ver- Schlüsselung verwendet werden.

Unter einer "Serviceanfrage" kann im Zusammenhang mit der Patentanmeldung beispielsweise ein Wartungsauftrag für ein Ge ¬ rä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 geeigne ¬ ten asymmetrischen kryptographischen Verfahren verstanden werden. Insbesondere werden Verfahren der identitätsbasieren- den Verschlüsselung [1] verwendet.

Unter "externe Komponenten" kann im Zusammenhang mit der Patentanmeldung beispielsweise eine Komponente verstanden wer ¬ den, die insbesondere kein integraler Bestandteil der Anfra- geentität oder der Serviceentität sind. Eine externe Kompo ¬ nente 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 insbeson- dere 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 Ent ¬ schlü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 be ¬ stimmter 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 Sicher- heitstoken von der Anfrageentität beispielsweise mit einem generischen öffentlichen Schlüssel der Serviceentität verschlüsselt wird. Dies hat insbesondere im Vergleich zum er ¬ findungsgemäß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 insbesonde ¬ re 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 gege ¬ ben. 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 authenti- sierten 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 As- sertion 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 Sicher ¬ heitstoken und greift mittels des entschlüsselten Sicher- heitstokens 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üssel ¬ material 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 Ab- arbeiten der Serviceanfrage durch die spezifische Serviceen ¬ tität annulliert wird.

Bei einer weiteren Ausführungsform des Verfahrens wird das Überprüfen, ob die spezifische Serviceentität zugriffsberich- tigt 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ültigkeits- dauer insbesondere zentral über die Security-Policy festleg ¬ bar 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 Sicherheits- tokens berechnen kann. Der Schlüsselserver kann beispielsweise anhand der Serviceanfrage, die den eindeutigen Service- identifizierer umfasst, den öffentlichen Schlüssel berechnen. Alternativ wird die Identität der spezifischen Serviceenti ¬ tät, die dem öffentlichen Schlüssel entspricht, dem Schlüs ¬ selserver übermittelt.

Bei einer weiteren Ausführungsform des Verfahrens wird der öffentliche Parameter der Anfrageentität vor dem Verschlüs ¬ seln 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 insbe ¬ sondere nur ein einziges Mal durchgeführt wird. Es ist bei ¬ spielsweise aber auch denkbar, dass das Bekanntmachen insbesondere nur dann durchgeführt wird, wenn beispielsweise auf ¬ grund neuer Sicherheitsanforderungen ein aktualisierter öf- fentlicher 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ög ¬ lichst 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 Service- anfrage durch die Anfrageentität , wobei die Ser ¬ viceanfrage 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 Autorisie- rungsmodul überprüft, ob die spezifische Serviceen ¬ tität für das Gerät hinsichtlich der Serviceanfrage zugriffsberechtigt ist;

ein drittes Übermittlungsmodul zum Übermitteln ei- ner 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 zu- griffsberechtigt ist, wobei der Schlüsselserver ei ¬ nen privaten Schlüssel zum Entschlüsseln des verschlüsselten Sicherheitstokens anhand des eindeuti ¬ gen Serviceidentifizierers berechnet; und - ein viertes Übermittlungsmodul zum Übermitteln des privaten Schlüssels an die spezifische Serviceenti- tä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 Kompo- nenten, wobei insbesondere mittels des Schlüsselservers der öffentliche Parameter der Anfrageentität bekanntmachbar ist.

Des Weiteren wird ein Computerprogrammprodukt mit Programmbe ¬ fehlen zur Durchführung des genannten erfindungsgemäßen Ver- fahrens 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 Kompo ¬ nenten des genannten erfindungsgemäßen Systems, vorzugsweise des gesamten Systems, erstellt.

Darüber hinaus wird eine Bereitstellungsvorrichtung zum Speichern und/oder Bereitstellen des Computerprogrammprodukts be ¬ ansprucht. 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 Computerpro ¬ grammprodukt 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 erfol ¬ gen, 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 Bereitstellungsvorrich- tung 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 er- stellt.

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 Zusam- menhang mit der folgenden Beschreibung der Ausführungsbeispiele, die im Zusammenhang mit den Figuren näher erläutert werden. Dabei zeigen in schematischer Darstellung:

Fig. 1 ein Ablaufdiagramm eines ersten Ausführungsbei- spiels eines erfindungsgemäßen Verfahrens;

Fig. 2 ein System eines zweiten Ausführungsbeispiels, wel ¬ ches ein erfindungsgemäßes Verfahren implementiert; Fig. 3 ein System eines dritten Ausführungsbeispiels, wel ¬ ches 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 imple ¬ mentiert, sofern nichts anderes angegeben ist.

Fig. 1 zeigt ein Ablaufdiagramm eines ersten Ausführungsbeispiels eines erfindungsgemäßen Verfahrens.

Das Verfahren stellt einen gesicherten Zugriff, beispielsweise einen Fernwartungszugriff, einer spezifischen Serviceenti- tät, beispielsweise einem Servicetechniker, auf ein Gerät, beispielsweise ein Feldgerät einer Kraftwerksanlage, bereit. Mittels des Fernwartungszugriffs kann die spezifische Ser- viceentität beispielsweise ein Firmwareupdate durchführen um insbesondere Sicherheitslücken in einer veralteten Firmware zu beseitigen. Das Verfahren umfasst einen ersten Verfahrensschritt zum Ver ¬ schlü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], einge- setzt werden.

Zusätzlich umfasst das Verfahren einen zweiten Verfahrensschritt zum Generieren 120 einer Serviceanfrage durch die An frageentität , wobei die Serviceanfrage den eindeutigen

Serviceidentifizierer, beispielsweise eine eindeutige Ticket nummer, 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-l-Beziehung zwi- sehen 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 Si- cherheitstoken ist vorzugsweise für genau diese Serviceanfra- ge 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 Verfahrens- schritt 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 Zuwei ¬ sungsmodul an die spezifische Serviceentität. Das Zuweisungs ¬ modul umfasst beispielsweise eine Liste von spezifischen Ser- viceentitäten denen beispielsweise mittels einer Tabelle oder Datenbank bestimmte Aufgaben, beispielsweise ein Aktualisie ¬ rung einer Firmware für bestimmte Geräte, zugeordnet sind. Hierzu kann das Zuweisungsmodul anhand von vordefinierten Re ¬ geln entscheiden welcher spezifischen Serviceentität die Ser- viceanfrage zugewiesen wird.

Zusätzlich umfasst das Verfahren einen fünften Verfahrensschritt zum Übermitteln 150 der Serviceanfrage durch die spe ¬ zifische 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 Ser ¬ viceentitä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 digi- talen 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 in ¬ tegraler Bestandteil des Schlüsselservers sein.

Zusätzlich umfasst das Verfahren einen achten Verfahrensschritt zum Berechnen 180 eines privaten Schlüssels zum Ent- schlü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ätsbasier- te 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 kei ¬ nem Zeitpunkt Zugriff auf den verschlüsselten oder entschlüs- selten Sicherheitstoken hat.

Hierbei erhält die spezifische Serviceentität vom Zuweisungs ¬ modul, beispielsweise einem Work Dispatcher, den verschlüs ¬ selten Sicherheitstoken für den Zugriff auf die zu wartende Komponente. Alternativ kann die spezifische Serviceentität sich diesen Sicherheitstoken als Teil seines Wartungsauftra ¬ ges 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 spezifi- sehen Serviceentität kann über typische Mechanismen reali ¬ siert werden, wie beispielsweise einen Nutzernamen und Pass ¬ word 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 schi ¬ cken kann, und dafür kein Zertifikat benötigt, das einen öf ¬ fentlichen 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 1 b

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 zwei ¬ ten Serviceentität kommunizieren, um den Sicherheitstoken auszutauschen .

In einer Variante verschickt die Anfrageentität eine Mail, die die Serviceanfrage und den verschlüsselte Sicherheitsto ¬ ken 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 her ¬ zustellen .

In einer weiteren Variante, kann der Sicherheitstoken an eine bestimmte Security Policy, insbesondere bezüglich seiner Aus ¬ lieferung/Erstellung, gebunden sein. Für die Auslieferung/Erstellung können beispielsweise folgende Bedingungen gelten :

Vordefinieren einer bestimmten Authentisierung der spe- zifischen Serviceentität aus einer Vielzahl von Authen- tisierungsmöglichkeiten, beispielsweise ein Einmalpass- wort und/oder ein digitales Zertifikat und/oder ein Be ¬ nutzername mit einem Passwort und/oder biometrisch Au- thentisierungsverfahren .

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 Abarbei ¬ tung bzw. für das Senden der Serviceanfrage ein entsprechendes Service Level Agreement zwischen der Anfrageentität und der zweiten Serviceentität gibt.

Fig. 2 zeigt ein System eines zweiten Ausführungsbeispiels, welches ein erfindungsgemäßes Verfahren implementiert. Fig. 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 Anfrageenti- tät, insbesondere die Anfrageentität 252 oder die weitere An- frageentitä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, insbe ¬ sondere ein weiteres Gerät 258 verbunden. Den Anfrageentitä ¬ ten 252, 257 sind jeweils ein Betreiber 251, 256 der Anfrage- entitä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 über- mittein 130. Die Serviceanfrage umfasst einen zuvor ver ¬ schlüsselten Sicherheitstoken und einen eindeutigen Service- identifizierer. Die Anfrageentität 252 generiert und übermit ¬ telt 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 spezifi ¬ sche Serviceentität 212, mindestens eine weitere spezifische Serviceentität 213, ein Autorisierungsmodul 214 und einen Schlüsselserver 215. Das Autorisierungsmodul 214 kann bei ¬ spielsweise als integrale Komponente des Schlüsselservers 215 ausgebildet sein. Der Schlüsselserver 215 und/oder das Auto- risierungsmodul 214 können auch als eine externe Komponente ausgebildet sein.

Das Zuweisungsmodul 211 weist 140 die Serviceanfrage der spe ¬ zifischen Serviceentität 212 zu, die zur Abarbeitung der Ser- viceanfrage geeignet ist. Die spezifische Serviceentität 212 übermittelt 150 die Serviceanfrage an das Autorisierungsmodul 214 und das Autorisierungsmodul 214 überprüft, ob die spezi ¬ fische Serviceentität für das Gerät 255 hinsichtlich der Ser ¬ viceanfrage 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 Identi ¬ tä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 durchge ¬ führt und somit ein Zugriff auf das erste Gerät 255 unterbun ¬ den .

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 pri- vaten 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üssel ¬ material nutzt. Mit anderen Worten zeigt Fig. 2 das Zusammenwirken zwischen Betreibern 251, 256 der Anfrageentitäten 252, 257 mit Betreibern von Kommunikationsnetzen, insbesondere der zweiten Ser- viceentität 210. Zwischen den verschiedenen Betreibern existieren typischerweise Service Level Agreements (SLA) .

Insbesondere kann sich in dem dargestellten Ausführungsbei ¬ spiel 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 Ge ¬ rä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 Ge ¬ rä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 Fig. 3 zeigt ein System eines dritten Ausführungsbei- spiels, welches ein erfindungsgemäßes Verfahren implemen ¬ tiert. Fig. 3 kann beispielsweise eine konkrete Implementie ¬ rung des ersten Ausführungsbeispiels sein.

Das System ist dazu ausgelegt ein gesichertes Zugreifen, ins- besondere einen Fernzugriff, einer spezifischen Serviceentität 212 auf ein Gerät 254 zu ermöglichen.

Das System ist beispielsweise Teil einer Anlage 250 und um- fasst eine Anfrageentität 252 und/oder eine weitere Anfrage- entitä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üs- selungsmodul 410, ein Generierungsmodul 420 und ein erstes Übermittlungsmodul 430, die über einen Bus 402 kommunikativ miteinander verbunden sind. Die Anfrageentität 252 ist insbe ¬ sondere ü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üsse ¬ lungsmodul 410 einen Sicherheitstoken, wobei zum Verschlüs- sein ein öffentlicher Schlüssel zusammen mit einem öffentlichen Parameter verwendet wird, wobei der öffentliche Schlüs ¬ sel von einem eindeutigen Serviceidentifizierer abgeleitet wird . Die Anfrageentität 252 generiert mit dem Generierungsmodul

420 eine Serviceanfrage, wobei die Serviceanfrage den eindeu ¬ tigen Serviceidentifizierer und den verschlüsselten Sicher- heitstoken umfasst. Die Serviceanfrage ist beispielsweise für das erste Gerät 254 generiert worden.

Die Anfrageentität 252 übermittelt mit dem ersten Übermitt- lungsmodul 430 die Serviceanfrage an die zweite Serviceenti ¬ tät .

Die zweite Serviceentität 210 umfasst ein Zuweisungsmodul 211, ein zweites Übermittlungsmodul 450, ein Autorisierungs- modul 214, ein drittes Übermittlungsmodul 470, einen Schlüs ¬ selserver 215 und ein viertes Übermittlungsmodul 490, die über ein drittes Netzwerk 401, beispielsweise ein Ether- netnetzwerk 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 Übermitt- lungsmodul 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 zwei ¬ ten Übermittlungsmodul 450 die Serviceanfrage an ein Autori- sierungsmodul 214;

Das Autorisierungsmodul 214 überprüft, ob die spezifische Serviceentität 212 für das Gerät, insbesondere das erste Ge ¬ rät 254, hinsichtlich der Serviceanfrage zugriffsberechtigt ist.

Das Autorisierungsmodul 214 übermittelt mit dem dritten Über ¬ mittlungsmodul 470 eine Identität der spezifischen Serviceen- titä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 Übermitt- lungsmodul 490 den privaten Schlüssel an die spezifische Ser ¬ viceentität durch den Schlüsselserver.

In einer Variante sind die Anfrageentitäten beispielsweise als IBM-kompatible Computer ausgebildet, die eine Computer- maus und eine Tastatur als Eingabegeräte umfassen. Zusätzlich kann eine Anfrageentität einen Bildschirm, beispielsweise ei ¬ nen 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. Bei- spielsweise 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 an- dere 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.