WO2017190857A1 - Verfahren und vorrichtung zur absicherung von gerätezugriffen - Google Patents

Verfahren und vorrichtung zur absicherung von gerätezugriffen Download PDF

Info

Publication number
WO2017190857A1
WO2017190857A1 PCT/EP2017/053453 EP2017053453W WO2017190857A1 WO 2017190857 A1 WO2017190857 A1 WO 2017190857A1 EP 2017053453 W EP2017053453 W EP 2017053453W WO 2017190857 A1 WO2017190857 A1 WO 2017190857A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
entity
specific
key
request
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.)
Ceased
Application number
PCT/EP2017/053453
Other languages
English (en)
French (fr)
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
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
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, Siemens Corp filed Critical Siemens AG
Publication of WO2017190857A1 publication Critical patent/WO2017190857A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network 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/0442—Network 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key 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/0847—Key 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public 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/3073—Public 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

Definitions

  • the invention relates to a method and a device for securing device access.
  • a first company supplies automation terminals
  • a second company network components and a third company supplies necessary office components / devices in the backend (or control center).
  • a certificate or password is often used.
  • Such a transition to ⁇ mechanism must, however advance on the computer are (usually a laptop) the service technician install or configure.
  • An object of the present invention is to provide a method and a device for securing device access, which allow access to an access-protected device as simply as possible.
  • the invention relates to a method for the secure access of a specific service entity to a device with the method steps:
  • a "specific Serviceenttician” may be related to the patent application, for example, a service technician or a software component understood edit ei ⁇ ne service request or execute.
  • a “device” may be understood to mean, for example, a technical device, for example a production robot or a field device, for example in a production plant or a power plant.
  • a "public key" for encrypting particular a security token may be related to the patent application, for example, an identity insbesonde ⁇ re in the form of an e-mail address
  • the email address may be generated from the unique service identifier and domain information from the public parameter.
  • the public key is generated, in particular, only from the unique service identifier.
  • the public key may serve as the specific service entity for processing the service request as an identity, which may also be referred to as a temporary identity. After processing this identity can be, for example nulliert to ⁇ .
  • the assignment of the temporary identity to the specific service entity can also take place, for example, by the allocation module. This identity can be used, for example, in identity-based encryption [1].
  • a public parameter in particular for forming a public key may be associated with the Patent Application, for example, a domain (eg example.com) or a subdomain (eg service.example.com) in particular the second service entity to be understood.
  • the public parameter may also contain cryptographic parameters that are used to encrypt the
  • a "public parameter” may, for example, also be understood to mean, in particular, a public parameter, as used in an identity-based encryption [1].
  • a "security token” in connection with the patent application for example, key material (Engl. Secu rity credentials), in particular user name and password or digital certificates to be understood that as example ⁇ required for a remote maintenance of the specific Serviceentmaschine on one-to-maintain equipment ,
  • a "unique service identifier" can be understood, for example, as a unique ticket number.
  • this ticket number can be issued by the key server.
  • the unique service identifier may be used as a public key of an identity-based encryption.
  • a "service request” may advises ⁇ , a request for updating firmware of a device or for reading log data for a device of a power plant be understood in connection with the patent application, for example, a service order for a Ge.
  • a "request entity” can be understood, for example, as an operator of an operational network or of a part of the IT infrastructure of a power plant.
  • a “second service entity” may, for example, be understood as an operator of a communications network of a power plant.
  • the term "encrypt” and / or “decrypting” for example, an encrypting / decrypting a security token with geeigne ⁇ th asymmetric cryptographic method may be understood in connection with the patent application. In particular, methods of identity-based encryption [1] are used.
  • An external Comp ⁇ component may, for example over a communications link, such as a network, in particular Ethernet or Internet connection, communicate with the Serviceenttician and / or the components of the Serviceenttician and / or the Request entity and / or components of the Request entity in conjunction.
  • a communications link such as a network, in particular Ethernet or Internet connection
  • the method is advantageous in that authorization is relocated to the time of key collection by the service entity.
  • the specific service entity can be addressed via its temporary identity.
  • Security Token can then be sent encrypted.
  • the release of the private key for decrypting the encrypted security token then takes place, for example after the authentication of the specific service entity.
  • the Request entity for example, has no information on internal structures of the Serviceenttician, especially not on the membership be ⁇ certain specific service entities in a group.
  • asymmetric encryption for example, only one method could be implemented in which, in particular, the security token is encrypted by the request entity, for example with a generic public key of the service entity.
  • Encrypting security tokens and issuing them after successful authentication of the specific service entity has the disadvantage, in particular in comparison to the method according to the invention, that at the time of encryption of the security token, the assignment to a specific service entity must be established. In addition, no separation of the encryption key from the security token can be realized, since the assignment is already established at the time of encryption.
  • the key server comes into contact with the encrypted and / or unencrypted security token, so that decryption is only possible with the authenticated and authorized specific service entity (end-to-end security).
  • the format of the security token does not have to be fixed.
  • a standard token format for example SAML (Security Assertion Markup Language) or even a proprietary format can be used.
  • SAML Security Assertion Markup Language
  • the specific Serviceenttician decrypts the encrypted secure ⁇ integral token and engages by means of the decrypted security tokens to the device to.
  • the security token is generated specifically for each service request.
  • the method is particularly advantageous then go, as the key ⁇ material is generated for the access to the device, for example, for each service request individually. This ensures high reliability is achieved, for example, because the security token is valid, for example, only for a predefined period or the security token for a waste work of the service request by the specific Serviceen ⁇ tity is canceled.
  • checking whether the specific service entity is access-controlled is carried out on the basis of a user name and password and / or a digital certificate and / or predefined rules and / or on the basis of biometric information.
  • the method is particularly advantageous in that, for example, it can be individually determined for each service request how an authentication of the specific service entity to the device takes place.
  • the security token is bound to a security policy.
  • the method is particularly advantageous since, for example of the scope and / or validity is on the Security Policy Setting a ⁇ bar permanently in particular centrally.
  • the security policy specifies how to check whether the specific service entity is access-corrected.
  • a private parameter associated with the public parameter is used to calculate the private key.
  • the method is particularly advantageous in that, for example, as a result, the key server private
  • Key to decrypt the encrypted security tokens can calculate.
  • the key server may calculate the public key based on the service request that includes the unique service identifier.
  • the identity of the specific Serviceenti ⁇ ty, which corresponds to the public key the Keyring ⁇ selserver is transmitted.
  • the method of the public parameters of the Request entity before Locks ⁇ clauses is made known and the private parameter is the
  • the method is particularly advantageous in that for example the encrypted security token can thereby be decrypted by the specific service entity without the key server needing access to the encrypted or decrypted security token. It is for example conceivable that advertising in particular ⁇ sondere is performed only once. It is playing as well as possible at ⁇ that advertising is particular only performed when, for example on ⁇ result of new safety requirements, an updated pub- fentaji parameters is needed.
  • the key server computes the public parameter and the private parameter and advertises the public parameter. The method is particularly advantageous since, for example, the public parameter to thereby mög ⁇ lichst easily can be made public.
  • the invention relates to a system for securely accessing a specific service entity to a device comprising:
  • an encryption module for encrypting a security token by the request entity, wherein a public key is used together with a public parameter for encryption, wherein the public key is derived from a unique service identifier; a generation module for generating a service request encompassed by the Request entity, wherein the request Ser vice ⁇ the unique service identifier and the encrypted security token; a first transmission module for transmitting the service request to a second service entity;
  • an assignment module that assigns the service request to the specific service entity
  • a second transmission module for transmitting the service request by the specific Serviceent relieve to an authorization module, the authorization module checks whether the specific Serviceen ⁇ tity is authorized to access the device in terms of service request;
  • a third transmission module for transmitting an identity of the specific service entity and the unique service identifier to a key server by the authorization module when the specific service entity is assigned to the device; is authorized to access, wherein the key server ei ⁇ NEN private key for decrypting the encrypted security token calculated on the basis of clear ⁇ service identifier; and a fourth transmission module for transmitting the private key to the specific service entity by the key server.
  • the second service entity comprises the authorization module and / or the key server and / or the specific service entity.
  • the authorization module and / or the key server are external components, wherein the public parameter of the request entity can be disclosed in particular by means of the key server.
  • a variant of the computer program product is claimed with program instructions for configuring a creation device, for example a 3D printer or a device suitable for creating processors and / or devices and / or devices, wherein the creation device is configured with the program instructions such that it is compo ⁇ nenten of said system of the invention, preferably the entire system created.
  • a provision device for storing and / or providing the computer program product is claimed .
  • the provisioning device is, for example, a data carrier which stores and / or makes available the computer program product.
  • the provisioning device is, for example, a network service, a computer system, a server system, in particular a distributed computer system, a cloud-based computer system and / or virtual computer system which Computerpro ⁇ program product preferably in the form of a data stream stores and / or provides.
  • This provision takes place, for example, as a download in the form of a program data block and / or command data block, preferably as a file, in particular as a download file, or as a data stream, in particular as a download data stream, of the complete computer program product.
  • This provision for example, but also as a partial download SUC ⁇ gen, which consists of several parts, in particular through a peer-to-peer network downloaded or is provided as a data stream.
  • Such a computer program product is read, for example, using the provision device in the form of the data carrier in a system and executes the program instructions, so that the inventive method is executed on a computer or the authoring device configured such that this system according to the invention or one of his Components created.
  • FIG. 1 shows a flowchart of a first exemplary embodiment of a method according to the invention
  • FIG 2 implements a system of a second embodiment, wel ⁇ ches an inventive method.
  • Fig. 3 shows a system of a third embodiment implemented wel ⁇ ches an inventive method.
  • functionally identical elements are provided with the same reference numerals, unless stated otherwise.
  • the following embodiments are preferably imple mented ⁇ by a processor and / or a memory module, unless otherwise specified.
  • FIG. 1 shows a flow chart of a first exemplary embodiment of a method according to the invention.
  • the method provides a secure access, for example a remote maintenance access, a specific service entity, for example a service technician, to a device, for example a field device of a power plant.
  • a specific service entity for example a service technician
  • the specific service entity can, for example, perform a firmware update in order to eliminate, in particular, security gaps in outdated firmware.
  • the method comprises a first method step for encrypting 110 a security token , for example
  • Key material in particular a remote maintenance access to the device, by a requesting entity, wherein for encrypting a public key is used together with a public parameter, wherein the public key is derived from a unique service identifier.
  • an asymmetrical cryptographic method in particular an identity-based cryptographic method [1] can be used as encryption method.
  • the method includes a second method step for generating 120 a service request by the requesting entity, wherein the service request is unique
  • Service identifier such as a unique ticket number
  • the encrypted security token includes.
  • the service request can additionally contain a description of the service case, for example a precise error description.
  • the unique service identifier it is preferable to ensure that there is a one-to-one relationship between unique service identifiers and service requests, even across different operators of networks or operators of request entities. For example, different namespaces can be defined for this purpose.
  • the security token is preferably generated for exactly this service request and is valid only for this service request.
  • the public key for the encrypted security token is preferably the unique service identifier.
  • the method comprises a third method step for transmitting 130 the service request to a second service entity.
  • the transmission can be carried out, for example, via a network, in particular an Ethernet network or a public Internet communication between the requesting entity and the service entity.
  • the method comprises a fourth method step 140 to assign the service request through a Zuwei ⁇ sungsmodul to the specific Serviceentmaschine.
  • the assignment module for example, a list of specific service-entities which, for example by means of a table or database specific tasks, such as a Aktualisie ⁇ tion firmware for specific devices, are assigned.
  • the allocation module can decide based on predefined rules which Re ⁇ specific Serviceentmaschine the Ser- vice request is assigned.
  • the method comprises a fifth step of transmitting 150 the service request by the spe ⁇ -specific Serviceentmaschine to an authorization module.
  • the method comprises a sixth method step in which the authorization module checks 160 whether the specific service entity for the device is entitled to access the service request.
  • the authorization module checks based on internal rules or based on predefined rules or possibly on the basis of a security policy, whether the specific Ser ⁇ viceenttician is entitled to take over the service request in question and / or to get access to the device.
  • the authentication required for this purpose can be carried out, for example, with digital signatures. This is ensured in particular by the fact that the encrypted / decrypted security token is not made known to the key server at any time.
  • the method includes a seventh method step of transmitting, by the authorization module, an identity of the specific service entity and the unique service identifier to a key server, if the specific service entity is authorized for the device.
  • the authorization module for example, can also be a tegraler in ⁇ part of the key server.
  • the method comprises an eighth method step for calculating 180 a private key for decrypting the encrypted security token by means of the unique service identifier by the key server.
  • the method includes a ninth method step of transmitting 190 the private key to the specific service entity by the key server.
  • the key server may be formed in this embodiment, for example, as an external component. Alternatively, however, the key server may also be an integral component of the second service entity.
  • the method uses identity-based encryption to provide the specific service entity To provide security tokens for access to a serviceable component, such as the device.
  • identity-based encryption to provide the specific service entity
  • security tokens for access to a serviceable component, such as the device.
  • the specific service entity from the allocation module receives the encrypted security token for accessing the component to be serviced.
  • the specific service entity may also fetch this security token from the work dispatcher as part of its maintenance task . To decrypt this security token, the specific service entity must access the associated key server.
  • the authorization of the service technician is checked by the authorization module.
  • the authorization of the specific service entity is typically tied to the authentication.
  • the authentication of the specific see Serviceenttician can reali of typical mechanisms ⁇ Siert such as a user name and pass word ⁇ or a digital certificate especially in the form of an X.509 certificate and corresponding private key.
  • the peculiarity of using identity-based encryption is that the identity of the recipient (eg the e-mail address or a telephone number) is identical to the recipient's public key. This means for example that a transmitter to a receiver one (with this public key) encrypted mail ski ⁇ CKEN can, and it does not require a certificate that binds a öf ⁇ lic key to a given identity.
  • certain attributes can also become part of the identity, which, for example, can include a specific service case in the form of the unique service identifier.
  • Ticket_4711@example.com In the example, this would be interpreted as meaning that the mail is addressed to the service technician who is to process ticket No. 4711.
  • ticket # 4711 the request entity encrypts the security token required for access. Until that time, the Request entity does not have to communicate with the two ⁇ th Serviceentmaschine to exchange the security token.
  • the Request entity sends a message containing the service request and the encryptedreato ⁇ ken, to the email address that is identical to the identity, assuming that the domain
  • com belongs to the second service entity.
  • the email is assigned within the second service entity to a specific service entity that is to process the service case (authorization).
  • the specific service entity is now given the private key with which it can decrypt the encrypted security token.
  • the key material comprising the security token is then used as an authentication feature to detect a remote access ⁇ forth to the device.
  • security token to a particular security policy may, in particular with regard to its off his ⁇ delivery / creation, bound.
  • the following conditions may apply to the delivery / creation:
  • a time or time interval that determines a pickup of the service request or the processing of the service request.
  • FIG. 2 shows a system of a second embodiment implementing a method according to the invention.
  • FIG. 2 may be a concrete implementation of the first embodiment.
  • the system includes a second service entity 210 and a request entity 252.
  • the request entity 252 is part of an attachment 250.
  • the attachment 250 may include additional request entities 257.
  • the installation may comprise a plurality of networks, in particular a first network 253 and / or a second network 260, to which a request entity, in particular the request entity 252 or the further inquiry entity 257, is communicatively connected.
  • Devices are preferably additionally connected to the first network, in particular a device 255 and a second device 254.
  • To the second network devices, and in particular ⁇ sondere another device 258 are preferably additionally connected.
  • Thestationentitä ⁇ th 252, 257 are each a operators 251, 256 of the request entity 252, 257 and / or the networks 253, 260 assigned.
  • the Request entity 252 is configured to service requests and to generate the second Serviceenttician 210 to exceed mittein 130.
  • the service request contains a previously ver ⁇ encrypted security token and a unique service identifier.
  • the Request entity generates 252 and übermit ⁇ telt in this embodiment, for the first device 255, the service request.
  • the second Serviceenttician 210 which may also be a part of the system 250 comprises an assignment module 211, a specifi ⁇ specific Serviceenttician 212, at least one further specific Serviceenttician 213, an authorization module 214, and a key server 215.
  • the authorization module 214 may be game designed as an integral component of the key server 215 in ⁇ .
  • the key server 215 and / or the authorization module 214 can also be designed as an external component.
  • the allocation module 211 allocates the service request of the spe ⁇ -specific Serviceenttician 212, which is suitable for processing the service request.
  • the specific Serviceenttician 212 received 150 the service request to the authorization module 214 and the authorization module 214 checks whether the specific ⁇ fish Serviceenttician for the device 255 is authorized to access in terms of Ser ⁇ vice request.
  • Represents the authorization module 214 determines that the specific Serviceentmaschine is authorized to access 212 for the first device 255, transmitted 170, the authorization module 214, a Identi ⁇ ty of the specific Serviceenttician 212 and the unique service identifier to the key server 215. If found, however, that the specific Serviceenttician 212 is not access-corrected, the transmission is not souge ⁇ leads and thus an access to the first device 255 underb ⁇ the.
  • the key server 215 calculates a private key for decrypting the encrypted security token using the unique service identifier. Subsequently, the key server 215 communicates 190 the identity by means of the private key to the specific service entity 212. This is done suitably in encrypted form, e.g. depending on the authentication of the specific service entity.
  • the specific service entity 212 decrypts the security token with the private key and accesses 236 the first device 255 by using the specific service entity 212, for example, the key material contained in the security token .
  • FIG. 2 shows the interaction between operators 251, 256 of the request entities 252, 257 with operators of communication networks, in particular the second service entity 210.
  • Service Level Agreements (SLA) typically exist between the various operators.
  • the specific Serviceenttician 212 in particular a service technician or a service process that is responsible for the devices 254, 255, 258, and in particular the first Ge ⁇ advises 255, login to change some of this parameterization or read maintenance data.
  • Domain-specific protocols such as IEC 61850 can be used, as well as standard web protocols such as https. The latter especially in that many devices already support integrated web server.
  • the goal here is that the specific service entity 212 may log on to the first device 255 in an authorized manner, with the first device 255 authenticating this access. Often, it is sufficient to review the role of the specific service entity 212 rather than the specific service entity 212 as a single entity.
  • the access is realized via a network by the second service entity 210, which, although trustworthy with respect to. the transport of the data is considered, but should not allow access to the unencrypted security token. Access to this network is provided by second Service entity 210 controlled in accordance with the Service Level Agreement.
  • Fig. 3 shows a system of a third exemplary embodiment, which advantage implemen ⁇ an inventive method.
  • Fig. 3 shows a concrete imple ⁇ tion of the first embodiment may be, for example.
  • the system is configured to allow secure access, in particular remote access, of a specific service entity 212 to a device 254.
  • the system is part of a system 250 and comprises a request entity 252 and / or a further request entity 257, which can each be assigned to an operator 251, 256.
  • the system includes a second service entity 210.
  • the request entity 252 further includes an encryption module 410, a generation module 420, and a first transmission module 430 that are communicatively coupled to one another via a bus 402.
  • the Request entity 252 is in particular ⁇ sondere connected via a first network 253 with a first device 254 and a second device 255th
  • the request entity 252 may additionally have a processor and / or a memory device.
  • the Request entity 252 encrypted with the closures ⁇ averaging module 410 includes a security token, its scrambling system for a public key is used together with a public parameter, wherein the public Keyring ⁇ sel is derived from a unique service identifier. Request entity 252 generates with the generation module
  • the service request has been generated, for example, for the first device 254.
  • the Request entity 252 transmits to the first Mattermitt- averaging module 430, the service request to the second Serviceenti ⁇ ty.
  • the second Serviceenttician 210 comprises an assignment module 211, a second transmission module 450, an authorization module 214, a third transmission module 470, a Keyring ⁇ selserver 215 and a fourth transmission module 490, which, via a third network 401, for example an ether netnetztechnik 401 Communicating with each other.
  • the second service entity 210, the authorization module 214 and / or the key server 215 may additionally each additionally have a processor and / or a memory device.
  • the assignment module 211 may also include another transmission module 255 to allow it to communicate the service request to the specific service entity 212.
  • the second service entity 210 assigns the service request of the specific service entity 212 with the assignment module 211.
  • the specific service entity 212 may additionally comprise a processor and / or a memory device.
  • the specific Serviceenttician 212 communicated with the two ⁇ th transmission module 450, the service request to a authoritarianism s istsmodul 214;
  • the authorization module 214 checks whether the specific Serviceent relieve 212 is authorized to access the device, especially the first Ge ⁇ advises 254 with respect to the service request.
  • the authorization module 214 transmits to the third About ⁇ averaging module 470 an identity of the specific Serviceen- entity and the unique service identifier to a key server 215 when the specific service entity 212 is authorized for the device.
  • the key server 215 calculates a private key for decrypting the encrypted security token using the unique service identifier.
  • the key server 215 transmitted with the fourth Letmitt- averaging module 490 the private key to the specific Ser ⁇ viceent relieve by the key server.
  • the request entities are embodied, for example, as IBM-compatible computers, which include a computer mouse and a keyboard as input devices.
  • a Request entity can a screen, for example ei ⁇ nen TFT monitor include.
  • the components (modules, entities, servers) of the invention may each have their own processor and / or memory device to implement and / or execute the method unless otherwise stated or already mentioned.
  • the components may also include other typical devices known to those skilled in the art. For example, input devices and / or display devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • General Physics & Mathematics (AREA)
  • Algebra (AREA)
  • Storage Device Security (AREA)

Abstract

Verfahren und Vorrichtung zur Absicherung von Gerätezugriffen Die Erfindung betrifft ein Verfahren zum gesicherten Zugreifen einer spezifischen Serviceentität (212) auf ein Gerät (254). Das Verfahren umfasst einen Verfahrensschritt zum 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. Das Verfahren umfasst einen weiteren Verfahrensschritt zum Generieren (120) einer Serviceanfrage durch die Anfrageentität (252), wobei die Serviceanfrage den eindeutigen Serviceidentifizierer und den verschlüsselten Sicherheitstoken umfasst. Das Verfahren umfasst einen weiteren Verfahrensschritt zum Übermitteln (130) der Serviceanfrage an eine zweite Serviceentität (210). Das Verfahren umfasst einen weiteren Verfahrensschritt zum Zuweisen (140) der Serviceanfrage durch ein Zuweisungsmodul (211) an die spezifische Serviceentität (212). Das Verfahren umfasst einen weiteren Verfahrensschritt zum Übermitteln (150) der Serviceanfrage durch die spezifische Serviceentität (212) an ein Autorisierungsmodul (214). Das Verfahren umfasst einen weiteren Verfahrensschritt zum Überprüfen (160) durch das Autorisierungsmodul (214), ob die spezifische Serviceentität (212) für das Gerät (254) hinsichtlich der Serviceanfrage zugriffsberechtigt ist. Das Verfahren umfasst einen weiteren Verfahrensschritt zum Ü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. Das Verfahren umfasst einen weiteren Verfahrensschritt zum Berechnen (180) eines privaten Schlüssels zum Entschlüsseln des verschlüsselten Sicherheitstokens anhand des eindeutigen Serviceidentifizierers durch den Schlüsselserver (215). Das Verfahren umfasst einen weiteren Verfahrensschritt zum Übermitteln (190) des privaten Schlüssels an die spezifische Serviceentität (212) durch den Schlüsselserver (215).

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.

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.
PCT/EP2017/053453 2016-05-03 2017-02-16 Verfahren und vorrichtung zur absicherung von gerätezugriffen Ceased WO2017190857A1 (de)

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=58108584

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/053453 Ceased WO2017190857A1 (de) 2016-05-03 2017-02-16 Verfahren und vorrichtung zur absicherung von gerätezugriffen

Country Status (2)

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

Cited By (1)

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

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1843509A1 (de) * 2005-01-14 2007-10-10 Nan, XiangHao Verfahren und einrichtung zur erzeugung von privatschlüsseln auf der basis von kennungen
US20100017593A1 (en) * 2008-06-23 2010-01-21 Putz Ingrum O Identity-based-encryption system
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
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
US20150082025A1 (en) * 2012-02-27 2015-03-19 Nachiket Girish Deshpande Authentication and secured information exchange system, and method therefor
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 (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8831228B1 (en) * 2009-08-28 2014-09-09 Adobe Systems Incorporated System and method for decentralized management of keys and policies
JP5618881B2 (ja) * 2011-03-25 2014-11-05 三菱電機株式会社 暗号処理システム、鍵生成装置、暗号化装置、復号装置、暗号処理方法及び暗号処理プログラム

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1843509A1 (de) * 2005-01-14 2007-10-10 Nan, XiangHao Verfahren und einrichtung zur erzeugung von privatschlüsseln auf der basis von kennungen
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
US20100017593A1 (en) * 2008-06-23 2010-01-21 Putz Ingrum O Identity-based-encryption system
US8300811B2 (en) 2008-12-10 2012-10-30 Siemens Aktiengesellschaft Method and device for processing data
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
US20150082025A1 (en) * 2012-02-27 2015-03-19 Nachiket Girish Deshpande Authentication and secured information exchange system, and method therefor
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 (3)

* Cited by examiner, † Cited by third party
Title
"Proceedings of Crypto 2001", vol. 2139, 2001, SPRINGER-VERLAG, pages: 213 - 229
APPEARS IN SIAM J. OF COMPUTING, vol. 32, no. 3, 2003, pages 586 - 615
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 <URL:https://crypto.stanford.edu/~dabo/papers/bfibe.pdf> [retrieved on 20170508], DOI: 10.1137/S0097539701398521 *

Cited By (2)

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

Also Published As

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

Similar Documents

Publication Publication Date Title
DE602005001613T2 (de) Einrichten eines sicheren kontexts zur übermittlung von nachrichten zwischen computersystemen
EP3488555B1 (de) Gesichertes verarbeiten einer berechtigungsnachweisanfrage
EP3125492B1 (de) Verfahren und system zum erzeugen eines sicheren kommunikationskanals für endgeräte
DE102007033615B4 (de) Verfahren und Vorrichtung zum Umwandeln von Authentisierungs-Token zur Ermöglichung von Interaktionen zwischen Anwendungen
DE60214632T2 (de) Multidomäne Berechtigung und Authentifizierung
DE112011101729B4 (de) Verwaltung von Ressourcenzugriff
EP2250598B1 (de) Client/server-system zur kommunikation gemäss dem standardprotokoll opc ua und mit single sign-on mechanismen zur authentifizierung sowie verfahren zur durchführung von single sign-on in einem solchen system
EP2593897B1 (de) Verfahren zur zertifikats-basierten authentisierung
DE112018005203T5 (de) Authentifizierung unter Verwendung von delegierten Identitäten
EP3854022B1 (de) Verfahren und vorrichtung zum übertragen von daten in einem publish-subscribe-system
EP4179758B1 (de) Authentisierung eines kommunikationspartners an einem gerät
DE112017007393T5 (de) System und verfahren für netzwerkvorrichtungssicherheits- und vertrauenswertbestimmung
EP3031226A1 (de) Unterstützung der nutzung eines geheimen schlüssels
DE112011102224B4 (de) Identitätsvermittlung zwischen Client- und Server-Anwendungen
EP3672142A1 (de) Verfahren und system zur sicheren übertragung eines datensatzes
WO2007045395A1 (de) Vorrichtungen und verfahren zum durchführen von kryptographischen operationen in einem server-client-rechnernetzwerksystem
DE102017211267A1 (de) Verfahren zum Schützen einer Zertifikatsanforderung eines Clienten-Rechners und entsprechendes Kommunikationssystem
EP3537323A1 (de) Projektbezogenes zertifikatsmanagement
WO2020165041A1 (de) Verfahren zur bereitstellung eines herkunftsortnachweises für ein digitales schlüsselpaar
EP3785459A1 (de) Einrichtung einer zugangsberechtigung zu einem teilnetzwerk eines mobilfunknetzes
WO2017190857A1 (de) Verfahren und vorrichtung zur absicherung von gerätezugriffen
DE102014210058B4 (de) Informationsverarbeitungsserversystem, Steuerverfahren und Programm
DE60219915T2 (de) Verfahren zur Sicherung von Kommunikationen in einem Computersystem
EP3734478A1 (de) Verfahren zur vergabe von zertifikaten, leitsystem, verwendung eines solchen, technische anlage, anlagenkomponente und verwendung eines identitätsproviders
EP3937451B1 (de) Verfahren zu herstellung einer verschlüsselten verbindung

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17706707

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17706707

Country of ref document: EP

Kind code of ref document: A1