EP3932005A1 - Verfahren und system zur vergabe von öffentlich getrusteten zertifikaten, engineering- oder leitsystem und technische anlage - Google Patents

Verfahren und system zur vergabe von öffentlich getrusteten zertifikaten, engineering- oder leitsystem und technische anlage

Info

Publication number
EP3932005A1
EP3932005A1 EP20718202.3A EP20718202A EP3932005A1 EP 3932005 A1 EP3932005 A1 EP 3932005A1 EP 20718202 A EP20718202 A EP 20718202A EP 3932005 A1 EP3932005 A1 EP 3932005A1
Authority
EP
European Patent Office
Prior art keywords
component
certificate
certification module
publicly
identifier
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.)
Pending
Application number
EP20718202.3A
Other languages
English (en)
French (fr)
Inventor
Roland Eckl
Harald Herberth
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP3932005A1 publication Critical patent/EP3932005A1/de
Pending legal-status Critical Current

Links

Classifications

    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • the invention relates to a method for issuing public Lich trust certificates for system components of a technical system.
  • the invention relates to a system for issuing publicly trustee certificates for system components of a technical system, an engineering or control system for a technical system and a technical system.
  • Digital certificates are used in the context of technical systems. In particular, when it comes to certificates that are used at runtime, one also speaks of operational certificates. Secure, non-compromised and trustworthy communication between different system components, such as devices and / or applications, can be enabled via certificates. By using certificates, for example, authentication and communication integrity of communication participants can be achieved using cryptographic means.
  • RA registration authorities
  • CSR certificate signing requests
  • CA Certificate Authority
  • a system component in the role of a client or an applicant directs its certificate application to the registration office (RA), which in the case of approval / validation sends the application to the certification authority (CA), which is located in the system (“Onsite -CA ”) or a trust center (“ Offsite CA “or” CA as a Service ”) is forwarded.
  • RA registration office
  • CA certification authority
  • Secure connections to websites are often indispensable from a requirements perspective. Certificates are required for this.
  • Certificates should not only be accepted from controlled end devices on which they have been stored as trustworthy, but should also be able to be verified at any time by any other end device, such as mobile devices. This would make it possible, for example, for an operator / user to have data about a control system of a technical system displayed on a mobile device (BYOD).
  • BYOD mobile device
  • certificates must be verifiable in the entire certificate chain up to the generally recognized Trusted Root Certificates (TRC) (see for example the "Root CA Policy" of
  • Google Chrome These are a handful of certificates that are classified as trustworthy across browsers and operating systems and do not have to be installed individually.
  • Certificates are tied to trust. The exhibitor must therefore be able to verify and subsequently attest that an applicant has control over a domain.
  • Lets-Encrypt see, for example, https://letsencrypt.org/).
  • trust is generated in that the owner of a server has to demonstrate that he has control over the server and the domain connected to it.
  • the certification body CA
  • this approach cannot be used for closed networks and areas (LetsEncrypt is based on the ACME protocol). This would not be the case, for example, for a controller, such as a PLC of a technical system with a closed network.
  • Certification management protocols such as the Certificate Management Protocol (CMP, see for example
  • This object is achieved by a method for issuing publicly trusted certificates for system components of a technical system, in which
  • a certification module of at least one component of a technical system that is to receive a publicly trusted certificate at least one preferably requests a clear component identifier and / or at least one preferred for at least one component of a technical system that is to receive a publicly trusted certificate generates a unique component identifier
  • the certification module transmits the at least one queried and / or at least one generated component identifier together with a certificate request for a publicly trusted certificate for the at least component to a registration authority (RA),
  • RA registration authority
  • the registration authority uses the at least one component identifier to check whether the at least one component belonging to the component identifier is assigned to at least one authorized person or at least one authorized company, whose responsibility is for the at least one component,
  • the registration authority requests a publicly trusted certificate for the at least one component in the event that this is the case
  • the requested publicly trusted certificate is created and transmitted to the certification module and is preferably stored in a protected area, in particular of the certification module.
  • the invention provides for a certification module to be provided with which components that are to receive a publicly trusted certificate are unambiguously can be identified, or with which at least one preferably unique and / or temporary identifier for the components to be certified is generated in particular in the event that components have not yet been put into operation and therefore no identifier can (yet) be retrieved from them can be.
  • the certification module then contacts a central service and transmits the (respective) certificate application for a publicly trusted certificate for the preferably uniquely identified component (s) or the uniquely identifiable component (s) based on the generated identifier (s) together with the ( the) identifier (s).
  • the registration authority can then check whether the (respective) identified / identifiable component can be assigned to a person or a company for whom the component is responsible stands, in particular whose property the component is.
  • the person or the company is preferably a customer who has purchased the component.
  • the fact that a component is the responsibility of the person or company means in particular that the person or company has control over the component, which is preferably contractually guaranteed and / or that the consequences are contractually regulated it has if a possible misuse of the requested certificate takes place.
  • the at least one component identifier can, for example, be a serial number and / or a machine / device certificate and / or a fingerprint and / or a type designation.
  • a serial number and / or a device or machine certificate and / or a fingerprint and / or a type pen designation queried and / or generated as component identifier.
  • a database for example a customer database, in order to check whether a component to be certified has been assigned to a person / company bearing responsibility.
  • the check in step c) includes that the registration office is stored in a database in which component identifiers are stored together with associated authorized persons and / or companies who preferably represent the owners of associated components, after at least searches for an entry for the component identifier transmitted together with the certificate request.
  • Associated components are to be understood as components belonging to the stored component IDs. It is preferred that components for which an identifier is stored in the database are the responsibility of the authorized person / company, which is particularly preferably guaranteed by contract.
  • the certificate request (the certificate request) is preferably approved / validated for the component in question. If no such entry is found, however, it is expediently rejected and a requested certificate is therefore not created.
  • the database can be given, for example, by what is known as an "industrial mall" from Siemens.
  • a database includes both own customer data and data from third-party providers, such as OEMs.
  • step e) key material can be transmitted to the certification module together with the publicly trusted certificate.
  • the certification module can preferably transfer certificates to a protected memory of the plant / industrial component in a way that is protected from being read and changed.
  • the plant / industrial component itself can then preferably secure a web server or other aspects using the certificate.
  • a person / company confirms legally binding that they are the owner of the component, for example by agreeing that this applies to all components that have been purchased and, in particular, that are stored in a database, or it is (with certainty) who is known Is the owner / person responsible (a legal assurance can also be given as part of the certificate acquisition, for example in an engineering system).
  • the (respective) component for which a certificate applied for is to apply can be clearly identified by the certification module.
  • the certification module also ensures that the certificate and any key material is never directly accessible to the person / company, in particular the customer, but can only be installed in a secure manner in the predetermined and assigned target component. This ensures that a certificate can only be installed on a component for which there is a legally responsible owner. This does not require the registration authority and / or the certification authority to have access to the component or a web server of such a component.
  • the method according to the invention is suitable both for the initial (first-time) issuing of a publicly trustworthy certificate and for the renewal of the certificate (renewed issuance).
  • the method according to the invention for issuing certificates is thus a method for the initial issuing and / or renewal of publicly trusted certificates.
  • Certificate applications can accordingly be both applications for the purpose of the initial application (bootstrapping) as well as the renewal (update) of certificates.
  • the certification module is preferably located on site at the technical system, in particular in the same network as the technical system. In particular, it is implemented on hardware that forms part of the technical system and / or the network of such a system.
  • the certification module is part of an engineering system of the technical plant or is functionally connected to an engineering system of the technical plant.
  • Industrial engineering systems also known as project engineering tools for industrial applications, can be used for solution design and implementation as well as for later operating and / or management processes. Solutions are to be understood here as industrial solutions, especially for the process and / or discrete industry.
  • the engineering of an automation project usually comprises one or more of the following steps: determining the required functionality in the project, determining which components are required to offer this functionality, assigning functionality and an actual physical position the components in the system, assignment of communication structures to the components (e.g. which components are allowed to communicate with which other components and how they communicate, what the actual purpose of the component is), etc.
  • An automation project correlates with a real project, e.g. the construction of a new production / manufacturing line in a new or existing industrial plant or a new or existing process plant.
  • Some of the many examples in which such automation projects are implemented are the manufacture of vehicles in the automotive industry, the manufacture of electronics, the manufacture of food and beverage products and many more.
  • the engineering system is usually used to generate one or more configurations of system / automation components as part of an industrial automation project.
  • the industrial automation projects can be, for example, factory automation projects, projects for the automation of the process industry and all other automation projects in an industrial context.
  • a system or automation component can be a hardware component and / or a software component or a combination of both, in particular for use in the above-mentioned automation project.
  • Plant and automation components include: programmable logic controllers (PLC), I / O modules, industrial communication devices, industrial network components, sensors, actuators, drives and other industrial devices that are often used in the process or automation industry.
  • Software components that share hardware with other components can also be configured using an engineering system.
  • An engineering system (sometimes also referred to as an engineering tool) has very precise knowledge of the automation products in the plant. It knows the exact hardware (e.g. using the serial number) or the specific product (e.g. using the MLFB, i.e. the machine-readable brand name), but is also able to uniquely identify or identify a component such as a device do (e.g. via a permanently burned-in or safely played machine or device certificate). Likewise, an engineering system usually already has options for securely transferring data to the corresponding automation devices (in the sense of forgery-proof and not visible or readable by third parties).
  • the certification module is integrated into an engineering system of the plant, it cannot be ruled out that it represents a stand-alone tool or stand-alone module or part of another Tools educates. Then there is preferably a functional connection with the engineering system. This means that the tool can also change the network, for example when the system / industrial component operates in a network that is not only accessible from the outside, but cannot itself contact other networks with the outside world.
  • the invention offers several advantages. For systems, a certificate creation and deployment process that is integrated into the engineering and, in particular, tied to the customer contractual relationship, can be obtained.
  • the integration into the engineering offers an extended, simpler and safer handling, for example a significantly smaller hurdle than with the integration of a standardized protocol in every system component / every product.
  • the engineering system naturally knows device-specific access and distribution routes.
  • a CSR generation and / or transmission is possible through the certification module, which is preferably integrated into the engineering system, possibly even before the actual device is available and installed.
  • a certificate and, if necessary, any key material can be deployed in the course of the download or commissioning, again preferably supported by the engineering.
  • a technical trust relationship can be maintained between a certification authority (CA) and system components, such as end devices, since a customer and the devices actually purchased can be identified on the basis of one component identifier (i.e. one or more unique features).
  • CA certification authority
  • the necessary steps can run automatically without a user or customer having to intervene manually.
  • the certification module which is preferably part of an engineering system of the plant or is functionally connected to such a system, obtains the certificates from a preferred external CA.
  • Certificate procurement can be provided as a service (Certificate as a Service, CaaS), for example for customers who have purchased system components to be certified.
  • CaaS Certificate as a Service
  • the certification module can represent a functional unit that can be implemented, for example, by a software component on suitable hardware. It may be that the certification module is implemented by software that is located on the hardware of an engineering system of the technical system. Of course, it is also possible for the certification module to comprise separate “own” hardware. Then, in a preferred embodiment, the certification module or its hardware is functionally connected to an engineering system of the technical installation.
  • a registration office of a technical system is understood to mean a functional entity that receives registration requests such as certificate applications from components of the technical system, checks them and, if successful, forwards them in particular to a certification center of the technical system.
  • the registration body is primarily intended to deal with applications for certification of system components of the technical system.
  • the registration office can be a local registration office that can communicate with a higher-level global registration office, which, for example, can in turn be in direct connection with a certification office of the technical system.
  • the registration authority may include or be provided by a registration service.
  • the registration authority to which the certification module according to the invention transmits the at least one component identifier together with the certificate application is designed and / or set up to determine / check / validate whether using the at least one component identifier, in other words using one or more unique features the (respective) component is assigned to a person / company and is their / his responsibility, in particular whether a legally binding customer relationship exists for the (respective) component.
  • the registration authority ascertains / checks / validates for which application on the at least one component the publicly trusted certificate applied for is intended. Then the registration point is designed and / or set up accordingly.
  • the technical system is in particular a production or process system. It can be a system from the process industry, such as a chemical, pharmaceutical, petrochemical or a system from the food and beverage industry. This also includes all systems from the production industry, plants in which e.g. Cars or goods of all kinds are produced.
  • Technical systems which are suitable for carrying out the method according to the invention can also come from the field of energy generation. Wind turbines, solar systems or power plants for generating energy are also included in the term technical system.
  • these systems each have a control system or at least one computer-aided module for controlling and regulating the ongoing process or production.
  • PKI Public Key Infrastructure
  • the term "Public Key Infrastructure” is used to connect a security infrastructure for a technical system, the services for a secure exchange of data between communication partners of the technical system. With the help of the public key infrastructure, certificates can be issued, distributed and checked.
  • a certificate is understood to be a digital data record that confirms certain properties (in this case of machines, devices, applications and the like). The authenticity and integrity of the certificate can be verified using cryptographic processes.
  • Publicly trusted certificates are to be understood in particular as those that can be verified in the entire certificate chain up to generally recognized Trusted Root Certificates (TRC).
  • TRC Trusted Root Certificates
  • Publicly trusted certificates can also be called publicly recognized certificates.
  • Publicly trusted / recognized certificates are in particular those issued by members of the CA / Browser Forum (see https://cabforum.org/).
  • Publicly trustworthy / recognized certificates that are requested / issued within the scope of the method according to the invention are particularly preferably SSL (Secure Sockets Layer) or TLS (Transport Layer Security) certificates.
  • a system component can be, for example, a control device such as a PLC (Programmable Logic Controller, PLC), a device, in particular a field device, an application or the like. It is in particular an automation component or an automation device.
  • a control device such as a PLC (Programmable Logic Controller, PLC)
  • PLC Process Control Controller
  • a device in particular a field device, an application or the like. It is in particular an automation component or an automation device.
  • the at least one system component preferably has at least one web server or represents a web server.
  • a certificate management protocol can be used to transmit the at least one certificate application from the certification module to the registration authority. It can be a common, in the context of certificate management for a technical installation, in particular a control system of such a protocol commonly used, for example, the Certificate Management Protocol (CMP for short, see, for example, RFC 4210/4211 of the Internet Engineering Task Force (IETF)). CMP can in particular be or will be implemented via https. It should be emphasized that a standard protocol can be used, but does not have to be. The certification module and the RA can also communicate with one another in a purely proprietary manner.
  • CMP Certificate Management Protocol
  • IETF Internet Engineering Task Force
  • the components are already installed in the system.
  • the certification module can read features here, uniquely identify a component (and ensure that there is no other entity with the same features) and securely transfer data and certificates to the component.
  • the components (server) have not yet been installed in the system, but this may first be configured.
  • the certification module may first have to generate the at least one component identifier required for the target component (in other words, one or more unique features, e.g. a machine certificate).
  • Publicly trusted certificates can, however, be requested and generated in advance and kept in the certification module internally for the configured device. Later during commissioning, the certification module then preferably ensures that the at least one preferably unique component identifier (in other words, unique features) is actually present or can be introduced in a forgery-proof manner and is then preferably introduced. If this has been ensured, the publicly trustee certificate can also be transferred there.
  • a further advantageous embodiment is therefore characterized in that, in the event that the certification module in step a) did not query any component identifier (in particular because the at least one component was not yet in operation - offline scenario), the certification module before the transmission of the publicly trustworthy certificate to the at least one component and / or the storage device connected or connectable to the at least one component Queries component identifier of the at least one component and preferably transmits the queried component identifier to the registration office.
  • the (then) queried component identifier can be transmitted to the registration authority.
  • the registration authority can store these in a database.
  • the certification module checks before the transmission of the publicly trusted certificate to the at least one component and / or the storage device connected or connectable to the at least one component whether there is at least one component identifier generated by it in step b) can be saved / filed in a forgery-proof manner in the component.
  • an SD card or a (USB) dongle can receive the complete configuration for a controller (such as a PLC) when downloading, but the actual component can be replaced immediately if a spare part is needed. The download is only made indirectly to the actual component.
  • the representative for example the card or the (USB) dongle, must be clearly identifiable and must be protected against unauthorized access - the data in the protected area must therefore not be easily readable.
  • the relevant component can then take the configuration from the representative, such as the SD card or dongle.
  • the certificate should preferably be encrypted and only the relevant component should preferably be used when reading the Configuration to be able to decrypt the certificate.
  • the certification module expediently has (at least at any point in time) access to the component to be validated or a storage device representing a proxy, such as an SD card or a dongle. This applies in particular if the certification module is part of an engineering system or is functionally linked to one.
  • the publicly trusted certificate (if necessary with accompanying material) can preferably be encrypted directly for the target component. This ensures that the certificate is completely secured and can only be decrypted there.
  • each project in the engineering system can be provided with a customer-specific key so that in the offline case the certification authority (CA) can secure the transport at least up to the certification module.
  • the certification authority CA
  • the material for the specific component such as the specific end device, can in turn be encrypted. Consistent protection is thus also possible.
  • a database in particular can include an entry according to which a user / a person / a company has a certain number of automation components of a given type. After a certificate application has been approved or a certificate has been issued for such a component, the number would increase one reduced.
  • an in particular unique component identifier is preferably played back, that is to say transmitted to the database and stored there. If possible, certificate updates should no longer be carried out for such "general hits" but rather for the specific identifier.
  • a further advantageous embodiment of the method according to the invention is characterized in that the registration authority requests the publicly trustworthy certificate in step d) from a certification authority, in particular by validating the certificate application and / or forwarding it to the certification authority.
  • the certification authority can then create or obtain the requested publicly trusted certificate for the at least one component.
  • the certification module further preferably transmits the publicly trusted certificate transmitted to it in step e) to the at least one component and / or to a storage device connected or connectable to the at least one component.
  • a storage device is preferably a “representative”, for example an SD card, a (USB) dongle or another storage medium onto which a configuration for the component can / will be loaded.
  • the key material is, in particular, that which was transmitted to the certification module together with the certificate, in particular from a certification authority.
  • the publicly trusted certificate is preferably stored in a forgery-proof certificate memory of the at least one component and / or of the memory device connected or connectable to the at least one component.
  • a direct connection between the certification module or between hardware on which the certification module is implemented can be used for the transmission of the publicly trusted certificate from the certification module to the at least one component and / or to the storage device connected or connectable to the at least one component , and the at least one component and / or the storage device connected or connectable to the at least one component exist or be produced.
  • “directly” is to be understood in particular to mean that the certification module can communicate “directly” with the component. It preferably means that the certification module is located in the same network from which the component can be reached and no intermediary is required.
  • a direct wired or wireless connection can exist or be established.
  • the certification module queries the at least one component identifier from the at least one component in step b), with a direct connection between the certification module or between hardware on which the certification module is implemented and the at least a component exists or is produced.
  • Another object of the invention is a system for issuing publicly trusted certificates for system components of a technical system, comprising a certification module and a registration authority,
  • the certification module is designed and / or is directed to query at least one preferably unique component identifier from at least one system component that is to receive a publicly trusted certificate and / or to generate at least one preferably unique component identifier for at least one system component that is to receive a publicly trusted certificate
  • the registration authority is designed and / or set up to use the at least one component identifier to check whether the at least one Component belonging to the component thinking is assigned to at least one authorized person or at least one authorized company, in particular the property of at least one authorized person or at least one authorized company, and in the event that so, a publicly trusted certificate for the to request at least one component
  • the certification module is designed and / or set up to receive the requested publicly trusted certificate and preferably to store it in a protected area.
  • the system according to the invention is particularly suitable for carrying out the method according to the invention.
  • the system according to the invention comprises a database in which component identifiers are stored together with associated authorized persons and / or companies, who are preferably owners of associated components, and the registration authority is designed and / or set up for or within the framework checking whether the at least one component belonging to the component identifier is assigned to at least one authorized person or at least one authorized company, to search the database for at least one entry for the at least one component identifier transmitted together with the certificate request.
  • the certification module preferably forms a (local) “front end” or a (local) “front end” unit of the system or is part of such a unit.
  • the registry is - if necessary together with a database and a Certification authority - preferably part of a (central) "backend” or a central “backend” unit of the system.
  • the certification module is preferably located on site at or in the technical system, while the registration service is preferably located away from it, for example in a computing center. In particular, the registration service can be contacted by several certification modules that can be located at / in different systems and receive certificate applications together with component IDs.
  • a certification authority can be a further component of a "backend” / a "backend” unit of the system.
  • a separate / external certification body can exist which trusts the registration body of the system according to the invention.
  • a separate / external certification authority can be given by a certification authority such as VeriSign or another known certification authority, which preferably has a Trusted Root Certificate (TRC).
  • the invention also relates to an engineering or control system for a technical installation comprising a certification module that is designed and / or set up to
  • RA registration authority
  • the certification module can be an inspection unit
  • an inspection unit is present, it is preferably designed and / or set up to query (in other words read out) at least one preferably unique component identifier from the at least one component that is to receive the publicly frustrated certificate and / or for the at least one component that the public Lich frustrated certificate is to receive, to generate at least one preferably unique component identifier.
  • the deployment unit is preferably designed and / or set up to transmit a publicly frustrated certificate that has been created to the (respective) component, that is to say to upload it to it. It is preferably designed and / or set up to receive publicly frustrated certificates created by a certification authority in order to then be able to pass them on to the (respective) component.
  • the invention relates to a technical installation, in particular a manufacturing or processing installation.
  • the technical system according to the invention preferably comprises at least one engineering or control system according to the invention.
  • a gateway and / or edge device can alternatively or additionally also be used.
  • the certification module is provided / implemented on an edge device.
  • the certification module can, for example, be executed as an app on an edge device / device. If an edge device is used, the request (certificate applications), renewal and secure import of public Trusted certificates on the components, such as devices in the local network of a technical system, take place fully automatically, while the gateway / edge device also allows access to the Internet and the public infrastructure.
  • An edge device is conveniently (as the name suggests) on the outer edge of the closed network and has two network accesses / network adapters. The edge device is then in particular both in the closed internal network and in the public Internet. The devices or components in the closed network, however, usually have no access to the Internet. This is particularly useful in operation for automatic renewals, since the engineering system is not required and the certification module is not first used internally to obtain the ID and then manually switch to the public Internet.
  • the figure shows a system component G and an exemplary embodiment of a system according to the invention for the issuing of publicly trust certificates in a purely schematic representation.
  • the system component G is given by a programmable logic controller, or PLC for short, and is part of a technical system, not shown, in particular a manufacturing or process system.
  • the system includes, inter alia a plurality of sensors that deliver measured values for the controller G, and actuators that receive control values from the controller G. In this way, a process running in the system can be monitored and influenced.
  • the controller G is with the sensors and actuators as well as other system components in a known manner via a Plant network connected.
  • the system network is a local, closed network and the controller G cannot be reached from outside via the Internet.
  • the controller G is characterized by a unique component identifier K, which is given by a device certificate K in the embodiment described here.
  • the controller G should receive a certificate.
  • the controller G or a web server on this should receive such a certificate, which can be verified up to a trusted root certificate TRC and which is also referred to as a publicly trusted certificate C.
  • the controller G has a forgery-proof certificate store CS, which is used in a manner known per se to securely store or store a digital certificate.
  • a publicly trustee certificate C can be stored in the Certificate Store CS.
  • a system S according to the invention is therefore provided for issuing publicly trusted certificates C for system components G of a technical system, which can be used to obtain such a certificate C for the controller G and to store it in it (also referred to as "deployment”) ).
  • the embodiment shown in the figure of such a system S according to the invention includes a certification module ZM, which represents a "front-end” unit or “front end” component of the system 1 and is located on site at or in the technical system.
  • the certification module ZM is integrated into an engineering system ES of the technical system. Specifically, it is a functional unit or a functional module that is implemented by software that is located on the hardware of the engineering system ES.
  • the engineering system forms part of the illustrated embodiment of a system S according to the invention for the issuing of publicly trusted certificates.
  • the engineering system ES can run on standard hardware, such as a conventional PC or industrial PC.
  • the certification module ZM - as in the example shown - is integrated into an engineering system S of the system, this also representing or part of a stand-alone tool or stand-alone module another tool can be. Then there is a functional connection between the engineering system ES and the certification module ZM.
  • the ZM certification module can also be implemented on an edge device which is located on the outer edge of the closed system network and has two network accesses / network adapters, so that it is located both in the closed internal system network and in the public Internet.
  • the engineering system ES has very precise knowledge of the automation products in a technical system. It knows the exact hardware (e.g. using the serial number) or the specific product (e.g. using the MLFB), but is also able to clearly identify a component, such as the controller G, or make it identifiable (e.g. using a machine or device certificate that is burned in or that can be safely uploaded). Likewise, the engineering system ES usually has options for transferring data securely to the corresponding components, such as automation devices (in the sense of forgery-proof and not visible or readable by third parties).
  • the system S also comprises a backend or a backend unit BE with a registration agency RA, a database D and a certification agency CA.
  • the backend or the backend unit BE is not arranged on site at the plant, but is located in a computing center, which is, for example, a few or many kilometers away from the plant. Communication between the certification module ZM and the backend BE is possible via the public Internet.
  • the certification module ZM is designed to communicate with components G of the system.
  • the certification module ZM comprises an inspection unit IE, which is designed to query (in other words, read out) unambiguous component identifiers K from components G that are to receive a publicly trusted certificate C, and for components G that have a publicly trusted certificate C should receive, preferably to generate a clear component identifier K.
  • the query or “probing” is indicated in the figure by an arrow pointing from the inspection unit IE to the device certificate forming the component identifier K.
  • the inspection unit IE is also designed to transmit queried and / or generated component identifiers K together with a certificate request CSR for a publicly trusted certificate C for the respective component G to the registration office RA.
  • the transmission is indicated in the figure by an arrow pointing from the inspection unit IE to the registration office RA, in addition to which a certificate request CSR for the controller G together with the device certificate K of the controller G is shown purely schematically.
  • the certification module ZM also has a deployment unit DE which is designed to transmit publicly trusted certificates C to the (respective) component G, that is to say to upload them to them. It is trained to receive publicly trusted certificates C created or procured by the certification authority CA and then to pass them on to the (respective) component G.
  • the registration office RA is designed to use the at least one component identifier K to check whether the at least one component belonging to the component identifier K nents, in the present case the controller G is assigned to at least one authorized person or at least one authorized company, in particular represents the property of at least one authorized person or at least one authorized company, and, in the event that this is the case, a publicly trusted certificate C for the at least one component G to request.
  • the registration authority RA is able to validate a legally binding customer assignment on the basis of transmitted unique component characteristics K.
  • an embodiment of the method according to the invention for issuing publicly trusted certificates C for system components G of a technical system can be carried out.
  • the certification module ZM queries the controller G, which is to receive a publicly trusted certificate, at least one preferably unique component identifier, in the present case the device certificate K.
  • the certification module ZM which in the present case is integrated into the engineering system of the plant, has direct access to the controller G, so that this query is possible without any problems.
  • the engineering system G is a participant in the closed system network, so that it - and thus the integrated certification module ZM - has access to the controller G.
  • the certification module ZM can also generate at least one preferably unique component identifier for the controller G, which is to receive a publicly trusted certificate, in the present case a (possibly temporary) device certificate .
  • At least one component for example the controller G
  • the generation of at least one unique identifier K by the certification module ZM makes the components clearly identifiable.
  • Publicly trusted certificates C can then already be requested and generated in advance and held internally in the certification module ZM for the projected component G. Later during commissioning, the certification module ZM then preferably ensures that the at least one component identifier K is actually present or can be introduced in a forgery-proof manner. If this has been ensured, the publicly trustee certificate C can also be transferred there.
  • the certification module ZM transmits this together with a certificate request CSR for a publicly trusted certificate C for the controller G to a registration authority RA.
  • the certificate application CSR which the certification module ZM transmits to the registration authority RA, can be or have been made by the certification module ZM or also by the controller G.
  • the registration authority RA uses the device certificate K to check whether the at least one controller G belonging to the component K is assigned to at least one authorized person or at least one authorized company in whose or whose responsibility the controller is.
  • this check is carried out in that the registration authority RA stores the database D in which the component identifiers K, including device certificates K, together with associated authorized persons and / or companies who represent the owners of components G belonging to the component identifiers K. are, after at least one entry for the together with the certificate katsfrage CSR transmitted component identifier, in this case the device certificate K of the controller G, searches.
  • the CSR certificate application is approved / validated by the registration authority RA.
  • the registration authority RA requests the publicly trusted certificate C from the certification authority CA, in particular by forwarding the CSR certificate request to the certification authority CA.
  • the certification authority CA then creates or procures the requested publicly trustworthy certificate C for the control G.
  • the certification authority CA which is part of the backend BE, contacts another, central certification authority zCA in the example described here, which has a trusted root certificate TRC disposes. Since the zCA has a relationship of trust with the CA, it executes the CSR directly.
  • a certificate C is created by or in the registration authority CA or zCA of the backend BE.
  • the certificate C is forwarded together with the associated key material to the deployment unit DE of the certification module ZM, stored there or at another point in the engineering system ES in a protected area that cannot be read or changed from the outside.
  • the certificate C and associated key material are also “deployed” by the deployment unit, that is to say introduced into the control G, specifically stored securely in the certificate store CS. This is indicated again in FIG. 1 by corresponding arrows.
  • the certificate C (can also be referred to as a customer certificate or, in English, customer certificate) points to an intermediate certificate zC from the CA, which in turn refers to the trusted root certificate TRC from the zCA.
  • this certificate chain is indicated by arrows with a dashed line.
  • these arrows indicate the "trust", i.e. the trust between the bodies or certificates.
  • the TRC is the end of the certificate chain.
  • the (customer) certificate C in component G must be above the whole chain up to the TRC of the zCA will be valid.
  • a central certification authority zCA is provided and that the CA can be contacted, but does not have to be.
  • the CA it is also possible for the CA to issue certificates C directly without having to rely on external cooperation from another CA. This is particularly the case if the CA has valid key material.
  • the unique identifier K is now queried from component G and sent to the backend BE transmitted back. There the provisional identifier can now be replaced with the actual one. (If the ES has generated a unique identifier K in advance and this could be incorporated into component G, there is no return transmission, or other identifiers, such as the serial number, are transferred to database D for correct assignment.)
  • the engineering system ES with the certification module ZM can support the following three variants:
  • the components / servers are already installed in the system.
  • the ES can read out features here, uniquely identify a component G (and ensure that there is no other entity with the same features) and securely transfer data and certificates C to the component G.
  • the components / servers are not yet installed in the system, but this may still be configured.
  • the engineering system ES may first generate the unique features required for the target component G (at least one component identifier K) (e.g. a machine certificate). Certificates C can then, however, be requested in advance and generated in the engineering system ES, specifically the certification module ZM internally for the configured component G. Later, during commissioning, the ES ensures that the unique features are actually available or can be incorporated in a forgery-proof manner.
  • the engineering system ES has access to the components G to be validated at least at some point in time.
  • the certificate C can be encrypted directly for the target component G with accompanying material. This ensures that certificate C is completely secured and can only be decrypted there.
  • each project in the ES engineering system can be provided with a (customer) -specific key so that in the offline case the CA can secure the transport at least up to the ES.
  • the material for the specific terminal G can in turn be encrypted in the respective project. Consistent protection is thus also possible.
  • the engineering system ES in which the certification module ZM is integrated, or of which the certification module ZM forms a component, represents an exemplary embodiment of an engineering system according to the invention for a technical installation or for a technical installation.
  • the technical system of which the controller G and the engineering system ES form a component, is also a Embodiment of a technical plant according to the invention ge.
  • a certification module ZM or a system S according to the invention can be used for several components of a technical system (or also several technical systems).
  • the backend BE of a system according to the invention can also represent a control center that communicates with several certification modules ZM and creates several certification modules ZM, possibly various systems, publicly trusted certificates C and transmits them to the several certification modules ZM.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Vergabe von öffentlich getrusteten Zertifikaten (C) für Anlagenkomponenten (G) einer technischen Anlage, bei dem a) ein Zertifizierungsmodul (ZM) von wenigstens einer Anlagenkomponente (G), die ein öffentlich getrustetes Zertifikat (C) erhalten soll, wenigstens eine Komponentenkennung (K) abfragt b) das Zertifizierungsmodul (ZM) die wenigstens eine Komponentenkennung (K) zusammen mit einem Zertifikatsantrag (CSR) für ein öffentlich getrustetes Zertifikat (C) an eine Registrierungsstelle (RA) übermittelt, c) die Registrierungsstelle (RA) anhand der wenigstens einen Komponentenkennung (K) überprüft, ob die wenigstens eine zu der Komponentenkennung (K) gehörige Komponente (G) wenigstens einer berechtigten Person oder wenigstens einem berechtigten Unternehmen zugeordnet ist, d) die Registrierungsstelle (RA) für den Fall, dass dem so ist, ein öffentlich getrustetes Zertifikat (C) für die wenigstens eine Komponente (G) anfordert, e) das angeforderte öffentlich getrustete Zertifikat (C) erstellt und an das Zertifizierungsmodul (ZM) übermittelt wird. Darüber hinaus betrifft die Erfindung ein System (S) zur Vergabe von öffentlich getrusteten Zertifikaten (C) für Anlagenkomponenten (G) einer technischen Anlage, ein Engineering- (ES) oder Leitsystem für eine technisch Anlage und eine technische Anlage.

Description

Beschreibung
Verfahren und System zur Vergabe von öffentlich getrusteten Zertifikaten, Engineering- oder Leitsystem und technische An lage
Die Erfindung betrifft ein Verfahren zur Vergabe von öffent lich getrusteten Zertifikaten für Anlagenkomponenten einer technischen Anlage. Darüber hinaus betrifft die Erfindung ein System zur Vergabe von öffentlich getrusteten Zertifikaten für Anlagenkomponenten einer technischen Anlage, ein Enginee ring- oder Leitsystem für eine technisch Anlage und eine technische Anlage.
Im Kontext technischer Anlagen kommen digitale Zertifikate zum Einsatz. Insbesondere für den Fall, dass es sich um Zer tifikate handelt, die zur Laufzeit verwendet werden, spricht man auch von operativen Zertifikaten. Über Zertifikate kann eine sichere, nicht-kompromittierte und vertrauenswürdige Kommunikation zwischen unterschiedlichen Anlagenkomponenten, etwa Geräten und/oder Applikationen, ermöglicht werden. Durch die Verwendung von Zertifikaten kann beispielsweise eine Au- thentifikation und eine Kommunikationsintegrität von Kommuni kationsteilnehmern durch kryptographische Mittel erreicht werden .
Im Rahmen einer Public Key Infrastruktur einer technischen Anlage werden sogenannte Registrierungsstellen (englisch: re- gistration authorities oder kurz: RA) verwendet, um Zertifi katsanträge (sogenannte certificate signing requests oder kurz: CSR) entgegenzunehmen und sie - im Falle der Genehmi gung/Validierung - an eine Zertifizierungsstelle (englisch: certificate authority oder kurz: CA) weiterzuleiten. Dabei ist die RA die Instanz, die entscheidet, welche Zertifikats anfragen genehmigt/validiert werden und die CA die Instanz, welche die Zertifikate erstellt. Anlagenkomponenten können die Zertifikate, die sie beispiels weise für die Nutzung verschiedener sicherer Protokolle wie z.B. TLS oder OPC UA benötigen, selbst beantragen. Eine Anla genkomponente in der Rolle eines Clients bzw. eines Antrag stellers richtet ihren Zertifikatsantrag an die Registrie rungsstelle (RA) , welche den Antrag im Falle der Genehmi gung/Validierung an die Zertifizierungsstelle (CA) , die sich beispielsweise in der Anlage („Onsite-CA" ) oder einem Trust Center („Offsite-CA" oder „CA as a Service") befindet, wei terleitet .
Gesicherte Verbindungen bei Webseiten (z.B. HTTPS oder Secure Web Sockets) sind aus Anforderungssicht oftmals unabdingbar. Hierfür werden Zertifikate benötigt.
Gerade im industriellen Umfeld liegen oftmals abgetrennte, private Netzwerke vor und ist es vielfach so, dass Geräte (bzw. darauf befindliche Webserver) nicht vom öffentlichen Internet aus erreichbar sind.
Dennoch liegt gerade im Web-Umfeld ein sehr heterogenes Um feld vor, bei dem nicht alle Teilnehmer (insbesondere Cli ents) vollständig oder mit wenig Aufwand kontrolliert bzw. in eine verwaltete Infrastruktur aufgenommen werden können. Ins besondere mobile Endgeräte beispielsweise sind häufig nicht Teil der Infrastruktur (Stichwort BYOD, „Bring your own de- vice") .
Nach Auffassung der Anmelderin ist es erstrebenswert, dass sich sämtliche Geräte (Clients wie Server) in die öffentliche Infrastruktur integrieren lassen. Zertifikate sollten nicht ausschließlich von kontrollierten Endgeräten akzeptiert wer den, bei denen diese als vertrauenswürdig hinterlegt wurden, sondern sollten auch von beliebigen anderen Endgeräten, etwa mobilen Endgeräten, jederzeit verifiziert werden können. Da durch würde es beispielsweise möglich, dass sich ein Betrei ber/Benutzer Daten etwa einer Steuerung einer technischen An lage auf einem mobilen Endgerät (BYOD) anzeigen lässt. Im Fall von Browsern auf Client-Endgeräten müssen dafür Zer tifikate in der gesamten Zertifikatskette bis hin zu allge mein anerkannten Trusted Root Certificates (TRC) verifizier bar sein (siehe beispielsweise die "Root CA Policy" von
Google Chrome) . Bei diesen handelt es sich um eine Handvoll von Zertifikaten, die browser- und betriebssystemübergreifend als vertrauenswürdig eingestuft werden und nicht individuell installiert werden müssen.
Ist eine Überprüfbarkeit bis hin zu einem solchen TRC nicht gegeben, können Funktionen aufgrund der mangelnden Überprüf barkeit eingeschränkt bis hin zu nicht gegeben sein. Dies be deutet, der Anwender bekommt im besten Fall eine Fehlermel dung, welche zumindest umgangen werden kann (wobei ein Bestä tigen, dass man trotz fehlgeschlagener Überprüfung fortfahren möchte ein eklatantes Sicherheitsrisiko darstellt und nicht zu empfehlen ist) , oder aber die Funktion wird stillschwei gend einfach unterdrückt (etwa AJAX-Calls aus der Seite her aus werden vom Browser abgelehnt oder eingebettete iframes werden nicht dargestellt) .
Der Aufwand für die Beschaffung öffentlich getrusteter Zerti fikate für geschlossene Anlagen ist nach Kenntnisstand der Anmelderin derzeit immens bzw. dies ist gar nicht möglich.
Zertifikate sind an Trust (Vertrauen) gebunden. Der Ausstel ler muss also verifizieren und nachfolgend attestieren kön nen, dass ein Antragsteller die Kontrolle über eine Domäne besitzt .
Eine Möglichkeit, ein öffentlich getrustetes Zertifikat zu erhalten, besteht nach Kenntnis der Anmelderin darin, sich ein solches manuell zu beschaffen. Dazu muss sich der Antrag steller eines Zertifikats ausweisen und diverse Dokumente vorlegen, die ihn eindeutig identifizieren und sicherstellen, dass er berechtigt/legitimiert ist, für die gewünschte Domäne Zertifikate zu erhalten. Danach bekommt er ein Zertifikat übermittelt und kann dieses zusammen mit seinem Schlüsselma terial - meist ebenfalls hündisch - in seiner Domäne instal lieren .
Eine weitere Möglichkeit besteht in der Verwendung von Lets- Encrypt (siehe beispielsweise https://letsencrypt.org/). Hier wird Vertrauen erzeugt, indem der Eigentümer eines Servers darlegen muss, dass er die Kontrolle über den Server und die damit verbundene Domäne hat. Hier setzt die Zertifizierungs stelle (CA) jedoch eine direkte Erreichbarkeit des Webservers voraus, wodurch dieser Ansatz für geschlossene Netze und Be reiche nicht anwendbar ist (LetsEncrypt basiert auf dem ACME Protokoll) . Für eine Steuerung, etwa SPS einer technischen Anlage mit geschlossenem Netz beispielsweise wäre dies nicht erfüllt .
Zertifizierungsmanagement-Protokolle, etwa das Certificate Management Protocol (CMP, siehe beispielsweise
https : //de . wikipedia . org/wiki/Certificate_Management_Protocol ) erlauben zwar eine automatisierte Ausführung von Zertifi katsanforderung, -erstellung und -Zuweisung. Hierzu ist je doch eine komplette Infrastruktur erforderlich, die von dem Betreiber einer technischen Anlage erst errichtet werden muss. Selbst wenn dieser Aufwand für ein geschlossenes Netz betrieben würde, könnten auf diesem Wege keine öffentlich ge- trusteten Zertifikate ausgestellt werden, da eine externe CA nicht attestieren kann, was in einem abgeschlossenen System von ihr selbst gar nicht verifiziert werden kann.
Daher greifen nach Kenntnisstand der Anmelderin in der Reali tät derzeit viele Anwender nur auf self-signed Zertifikate mit all den vorgenannten Nachteilen zurück, da sie entweder den Aufwand bzw. die Kosten der manuellen Beschaffung von öf fentlich getrusteten Zertifikaten scheuen, oder aber weil der Einsatz in einer industriellen Anlage unter Umständen bisher gar nicht anders zu bewerkstelligen ist. Ausgehend davon ist es eine Aufgabe der vorliegenden Erfin dung, eine Möglichkeit zu schaffen, mit vertretbarem Aufwand öffentlich getrustete Zertifikate für Komponenten technischer Anlagen mit abgetrennten, privaten Netzwerken vergeben zu können .
Diese Aufgabe wird gelöst durch ein Verfahren zur Vergabe von öffentlich getrusteten Zertifikaten für Anlagenkomponenten einer technischen Anlage, bei dem
a) ein Zertifizierungsmodul von wenigstens einer Komponente einer technischen Anlage, die ein öffentlich getrustetes Zertifikat erhalten soll, wenigstens eine bevorzugt ein deutige Komponentenkennung abfragt und/oder für wenigstens eine Komponente einer technischen Anlage, die ein öffent lich getrustetes Zertifikat erhalten soll, wenigstens eine bevorzugt eindeutige Komponentenkennung generiert, b) das Zertifizierungsmodul die wenigstens eine abgebfragte und/oder wenigstens eine generierte Komponentenkennung zu sammen mit einem Zertifikatsantrag für ein öffentlich ge trustetes Zertifikat für die wenigstens Komponente an eine Registrierungsstelle (RA) übermittelt,
c) die Registrierungsstelle (RA) anhand der wenigstens einen Komponentenkennung überprüft, ob die wenigstens eine zu der Komponentenkennung gehörige Komponente wenigstens ei ner berechtigten Person oder wenigstens einem berechtigten Unternehmen, in deren oder dessen Verantwortung die we nigstens eine Komponente steht, zugeordnet ist,
d) die Registrierungsstelle (RA) für den Fall, dass dem so ist, ein öffentlich getrustetes Zertifikat für die wenigs tens eine Komponente anfordert, und
e) das angeforderte öffentlich getrustete Zertifikat erstellt und an das Zertifizierungsmodul übermittelt und bevorzugt in einem geschützten Bereich insbesondere des Zertifizie rungsmodul gespeichert wird.
Die Erfindung sieht mit anderen Worten vor, ein Zertifizie rungsmodul bereitzustellen, mit dem Komponenten, die ein öf fentlich getrustetes Zertifikat erhalten sollen, eindeutig identifiziert werden können, bzw. mit dem insbesondere für den Fall, dass Komponenten noch nicht in Betrieb genommen wurden und daher (noch) keine Kennung von diesen abgerufen werden kann, wenigstens eine bevorzugt eindeutige und/oder vorübergehende Kennung für die zu zertifizierenden Komponen ten generiert werden kann.
Anstelle der Komponenten kontaktiert dann das Zertifizie rungsmodul einen zentralen Dienst und übermittelt diesem den (jeweiligen) Zertifikatsantrag für ein öffentlich getrustetes Zertifikat für die bevorzugterweise eindeutig identifizier tein) bzw. aufgrund der generierten Kennung (en) eindeutig identifizierbare (n) Komponente zusammen mit der (den) Ken nung ( en) .
Unter Verwendung der zur Verfügung gestellten abgefragten bzw. generierten bevorzugt eindeutigen Kennung (en) kann die Registrierungsstelle dann prüfen, ob die (jeweilige) identi fizierte/identifizierbare Komponente einer Person bzw. einem Unternehmen zugeordnet werden kann, in deren/dessen Verant wortung die Komponente steht, insbesondere deren/dessen Ei gentum die Komponente ist. Bei der Person bzw. dem Unterneh men handelt es sich bevorzugt um einen Kunden, welcher die Komponente erworben hat. Dass eine Komponente in der Verant wortung der Person bzw. des Unternehmens steht, bedeutet ins besondere, dass die Person bzw. das Unternehmen die Kontrolle über die Komponente hat, was bevorzugt vertraglich zugesi chert ist, und/oder dass vertraglich geregelt ist, welche Konsequenzen es hat, wenn ein etwaiger Missbrauch des bean tragten Zertifikates stattfände.
Bei der wenigstens einen Komponentenkennung kann es sich bei spielswese um eine Seriennummer und/oder ein Maschinen-/Gerä- tezertifikat und/oder einen Fingerprint und/oder eine Typen bezeichnung handeln. Entsprechend wird in Weiterbildung in Schritt a) eine Seriennummer und/oder ein Geräte- bzw. Ma schinenzertifikat und/oder ein Fingerprint und/oder eine Ty- penbezeichnung als Komponentenkennung abgefragt und/oder ge neriert .
Es kann sein, dass eine Person bzw. ein Unternehmen (manuell) vertraglich zusichert, dass die Anforderung der Kontrolle über die Komponente erfüllt ist. Das Bestehen einer solchen vertraglichen Zusicherung kann dann von der Registrierungs stelle im Rahmen der Überprüfung erfasst bzw. erkannt bzw. abgefragt werden.
Auch ist es möglich, dass auf eine Datenbank, etwa eine Kun dendatenbank zugegriffen wird, um zu prüfen, ob eine Zuord nung einer zu zertifizierenden Komponente zu einer/einem die Verantwortung tragendenden Person/Unternehmen gegeben ist.
Entsprechend kann in Weiterbildung vorgesehen sein, dass die Überprüfung in Schritt c) einschließt, dass die Registrie rungsstelle in einer Datenbank, in der Komponentenkennungen zusammen mit zugehörigen berechtigten Personen und/oder Un ternehmen, die bevorzugt Eigentümer zugehöriger Komponenten darstellen, gespeichert sind, nach wenigstens einem Eintrag für die zusammen mit dem Zertifikatsantrag übermittelte Kom ponentenkennung sucht. Unter zugehörigen Komponenten sind da bei zu den hinterlegten Komponentenkennungen gehörige Kompo nenten zu verstehen. Bevorzugt gilt, dass Komponenten, für die eine Kennung in der Datenbank hinterlegt ist, in der Ver antwortung der berechtigten Person/des berechtigten Unterneh mens stehen, was besonders bevorzugt vertraglich zugesichert ist .
Sofern ein solcher Eintrag in der Datenbank gefunden wird, wird die Zertifikatsanfrage (der Zertifikatsantrag) für die betreffende Komponente bevorzugt genehmigt/validiert . Wird kein solcher Eintrag gefunden, wird sie hingegen zweckmäßiger Weise abgelehnt und ein beantragtes Zertifikat daher nicht erstellt . Die Datenbank kann beispielsweise durch eine sogenannte „In dustrial Mall" von Siemens gegeben sein.
Kommt eine Datenbank zum Einsatz, ist es möglich, dass diese sowohl eigene Kundendaten als auch Daten von Drittanbietern, etwa OEMs umfasst.
In Schritt e) kann dem Zertifizierungsmodul zusammen mit dem öffentlich getrusteten Zertifikat Schlüsselmaterial übermit telt werden. Das Zertifizierungsmodul kann bevorzugterweise Zertifikate auf einem vor Mitlesen und Änderung geschützten Weg in einen geschützten Speicher der Anlagen-/ Industrie komponente übertragen. Die Anlagen-/ Industriekomponente selbst kann dann bevorzugt mittels des Zertifikats einen Webserver oder andere Aspekte absichern.
Im Gegensatz beispielsweise zu einem manuellen Zertifikatser werb sind durch die erfindungsgemäße Vorgehensweise folgende Aspekte erfüllt:
- Eine Person/Unternehmen bestätigt rechtlich verbindlich der Eigentümer der Komponente zu sein, beispielsweise, indem sie/es einwilligt, dass dies auf alle gekauften und insbe sondere in einer Datenbank hinterlegten Komponenten zu trifft, bzw. es ist (gesichert) bekannt, wer der Eigentü mer/Verantwortliche ist (eine rechtliche Zusicherung kann auch im Rahmen des Zertifikatserwerbs, beispielsweise in einem Engineering System erfolgen) .
- Die (jeweilige) Komponente, für welche ein beantragtes Zer tifikat gelten soll, ist durch das Zertifizierungsmodul eindeutig identifizierbar.
- Durch das Zertifizierungsmodul wird weiterhin sicherge stellt, dass das Zertifikat und etwaiges Schlüsselmaterial niemals direkt für die Person/das Unternehmen, insbesondere den Kunden zugreifbar wird, sondern auf sichere Weise aus schließlich in die vorbestimmte und zugeordnete Zielkompo nente installiert werden kann. Damit ist sichergestellt, dass ein Zertifikat ausschließlich auf einer Komponente installiert werden kann, für die es ei nen rechtlich zuständigen Besitzer gibt. Dies ohne, dass es erforderlich ist, dass die Registrierungsstelle und/oder die Zertifizierungsstelle Zugriff auf die Komponente bzw. einen Webserver einer solchen haben muss.
Es sei angemerkt, dass sich das erfindungsgemäße Verfah ren sowohl für die initiale (erstmalige) Vergabe eines öffentlich getrusteten Zertifikates als auch die Zerti fikat serneuerung (erneute Vergabe) eignet. Das erfin dungsgemäße Verfahren zur Vergabe von Zertifikaten ist somit ein Verfahren zur initialen Vergabe und/oder Er neuerung von öffentlich getrusteten Zertifikaten.
Bei Zertifikatsanträgen kann es sich entsprechend sowohl um Anträge zwecks der initialen Beantragung (Bootstrapping) als auch der Erneuerung (Update) von Zertifikaten handeln.
Das Zertifizierungsmodul befindet sich bevorzugt vor Ort bei der technischen Anlage, insbesondere im gleichen Netzwerk wie die technische Anlage. Es ist insbesondere auf Hardware im plementiert, die einen Bestandteil der technischen Anlage und/oder des Netzwerks einer solchen bildet.
Das Zertifizierungsmodul ist in ganz besonders bevorzugter Ausgestaltung Bestandteil eines Engineering Systems der tech nischen Anlage oder mit einem Engineering System der techni schen Anlage funktional verbunden.
Industrial Engineering Systeme, auch bekannt als Project En gineering Tools für industrielle Anwendungen, können für das Lösungs-Design und die Implementierung sowie für spätere Be triebs- und/oder Managementprozesse eingesetzt werden. Lösun gen sind hier als industrielle Lösungen insbesondere für die Prozess- und/oder diskrete Industrie zu verstehen. Das Engineering eines Automatisierungsprojekts (z.B. für eine Anlage) umfasst in der Regel einen oder mehrere der folgenden Schritte: Bestimmen der erforderlichen Funktionalität im Pro jekt, Bestimmen, welche Komponenten benötigt werden, um diese Funktionalität anzubieten, Zuordnen von Funktionalität und einer tatsächlichen physikalischen Position zu den Komponen ten in der Anlage, Zuweisen von Kommunikationsstrukturen zu den Komponenten (z.B. welche Komponenten mit welchen anderen Komponenten kommunizieren dürfen und wie sie kommunizieren, was der eigentliche Zweck der Komponente ist), etc.
Ein Automatisierungsprojekt korreliert mit einem realen Pro jekt, z.B. dem Aufbau einer neuen Produktions-/Fertigungs- linie in einer neuen oder bestehenden Industrieanlage oder einer neuen oder bestehenden Prozessanlage. Einige von vielen Beispielen, in denen solche Automatisierungsprojekte reali siert werden, sind die Herstellung von Fahrzeugen in der Au tomobilindustrie, die Herstellung von Elektronik, die Her stellung von Lebensmittel- und Getränkeprodukten und vieles mehr .
In diesen Anwendungen wird das Engineering System in der Re gel verwendet, um eine oder mehrere Konfigurationen von Anla- gen-/Automatisierungskomponenten im Rahmen eines Projekts zur industriellen Automatisierung zu erzeugen. Die Industrie- Au tomatisierungsprojekte können beispielsweise Fabrikautomati onsprojekte, Projekte zur Automatisierung der Prozessindust rie und alle weitere Automatisierungsprojekte im industriel len Kontext sein.
Eine Anlagen- bzw. Automatisierungskomponente kann eine Hard warekomponente und/oder eine Softwarekomponente oder eine Kombination aus beidem insbesondere für den Einsatz im oben genannten Automatisierungsprojekt sein. Anlagen- bzw. Automa tisierungskomponenten umfassen unter anderem: speicherpro grammierbare Steuerungen (SPS), E/A-Module, industrielle Kom munikationsgeräte, industrielle Netzwerkkomponenten, Senso ren, Aktoren, Antriebe und andere industrielle Geräte, die häufig in der Prozess- oder Automatisierungsindustrie verwen det werden. Softwarekomponenten, die Hardware mit anderen Komponenten teilen, sind ebenfalls über ein Engineering Sys tem konfigurierbar.
Ein Engineering System (teilweise auch als Engineering Tool bezeichnet) hat eine sehr genaue Kenntnis über die Automati sierungs-Produkte in der Anlage. So kennt es die exakte Hard ware (z.B. anhand der Seriennummer) oder das konkrete Produkt (z.B. anhand der MLFB, also der maschinenlesbaren Fabrikate bezeichnung) , ist aber auch in der Lage, eine Komponente, et wa ein Gerät eindeutig zu identifizieren oder identifizierbar zu machen (z.B. über ein fest eingebranntes oder sicher auf gespieltes Maschinen- oder Geräte-Zertifikat ) . Ebenso besitzt ein Engineering System in der Regel bereits Möglichkeiten, Daten sicher auf die entsprechenden Automatisierungs-Geräte zu übertragen (im Sinne von fälschungssicher sowie nicht durch Dritte einseh- bzw. mitlesbar) .
Es sei angemerkt, dass auch wenn es sehr vorteilhaft ist, wenn das Zertifizierungsmodul in ein Engineering System der Anlage integriert ist, auch nicht ausgeschlossen ist, dass dieses ein Stand-Alone-Tool bzw. Stand-Alone-Modul darstellt bzw. Teil eines anderen Tools bildet. Dann bestehet bevorzugt eine funktional Verbindung mi dem Engineering System. Dadurch kann das Tool auch das Netzwerk wechseln, etwa wenn die Anla gen-/ Industriekomponente in einem Netzwerk agiert, welches nicht nur von außen erreichbar ist, sondern auch selbst nicht mit weiteren Netzwerken nach außen Kontakt aufnehmen kann.
Man spricht in diesem Fall von vollständig abgeschlossenen Netzwerken .
Die Erfindung bietet mehrere Vorteile. Für Anlagen kann ein in das Engineering integrierter und insbesondere an Kunden- Vertragsbeziehung gebundener Zertifikats-Erstellungs- und -Deployment-Prozess erhalten werden. Insbesondere die Integration in das Engineering bietet eine erweiterte, einfachere und sicherere Handhabung, beispiels weise eine deutlich kleinere Hürde als bei Integration eines standardisierten Protokolls in jede Anlagenkomponente/ j edes Produkt. Das Engineering System kennt gerätespezifische Zu gangs- und Verteilungswege von Natur aus.
Es wird eine Unterstützung des Offline-Engineerings möglich, was Systeme wie beispielsweise LetsEncrypt nicht beherrschen, aber für das Engineering einer technischen Anlage elementar ist .
Es wird eine CSR-Erzeugung und/oder -Übermittlung durch das bevorzugt in das Engineering System integrierte Zertifizie rungsmodul, ggf. auch bevor das tatsächliche Gerät vorhanden ist und installiert wird, möglich.
Es kann ein Deployment eines Zertifikats und ggf. etwaigen Schlüsselmaterials im Zuge des Downloads bzw. der Inbetrieb nahme, wiederum bevorzugt unterstützt durch das Engineering erfolgen .
Es werden auch indirekte Offline-Szenarios möglich (z.B. auf spezielle SD-Karten für SIMATIC PLCs oder HW Dongle SiPlug)
Es kann eine technische Vertrauensstellung zwischen einer Zertifizierungsstelle (CA) und Anlagenkomponenten, etwa End geräten erhalten werden, da aufgrund der einen Komponenten kennung (also eines oder mehrerer eindeutiger Merkmale) ein Kunde und dessen tatsächlich erworbenen Geräte identifiziert werden können.
Die erforderlichen Schritte können dabei automatisch ablau fen, ohne dass ein Benutzer bzw. Kunde manuell eingreifen muss .
Es wird keine Infrastruktur für das Zertifikats-Management in den Komponenten, insbesondere beim Kunden vorausgesetzt, stattdessen bezieht das Zertifizierungsmodul, welches bevor zugt Bestandteil eines Engineering Systems der Anlage oder mit einem solchen funktional verbunden ist, die Zertifikate von einer bevorzugte externen CA.
Die Zertifikatsbeschaffung kann als Service (Certificate as a Service, CaaS) erbracht werden, beispielsweise für Kunden, welche zu zertifizierende Anlagenkomponente erworben haben.
Die Zertifizierungsmodul kann eine funktionale Einheit dar stellen, die beispielsweise durch eine Software-Komponente auf geeigneter Hardware implementiert sein kann. Es kann sein, dass das Zertifizierungsmodul durch Software implemen tiert ist, die sich auf Hardware eines/des Engineering Sys tems der technischen Anlage befindet. Selbstverständlich ist es auch möglich, dass das Zertifizierungsmodul separate „ei gene" Hardware umfasst. Dann ist das Zertifizierungsmodul bzw. dessen Hardware in bevorzugter Ausgestaltung mit ei nem/dem Engineering System der technischen Anlage funktional verbunden .
Unter einer Registrierungsstelle einer technischen Anla ge wird eine funktionelle Instanz verstanden, die Re gistrierungsanfragen wie Zertifikatsanträge von Kompo nenten der technischen Anlage entgegennimmt, diese prüft und im Erfolgsfall insbesondere an eine Zertifizierungs stelle der technischen Anlage weiterleitet. Im vorlie genden Fall ist die Registrierungsstelle vor allem dafür vorgesehen, Z erti fi kats anträge von Anlagenkomponenten der technischen Anlage zu behandeln. Die Registrierungs stelle kann eine lokale Registrierungsstelle sein, die mit einer übergeordneten globalen Registrierungsstelle kommuni zieren kann, welche beispielsweise wiederum direkt in Verbin dung mit einer Zertifizierungsstelle der technischen Anlage stehen kann. Die Registrierungsstelle kann einen Registrie rungsservice umfassen oder durch einen solchen gegeben sein. Die Registrierungsstelle, welcher das Zertifizierungsmodul erfindungsgemäß die wenigstens eine Komponentenkennung zusam men mit dem Zertifikatsantrag übermittelt, ist ausgebildet und/oder eingerichtet, anhand der wenigstens einen Komponen tenkennung, mit anderen Worten anhand eines oder mehrere ein deutiger Merkmale zu ermitteln/überprüfen/validieren, ob die (jeweilige) Komponente einer Person/einem Unternehmen zuge ordnet ist und in deren/dessen Verantwortung steht, insbeson dere, ob eine rechtlich bindende Kundenbeziehung für die (je weilige) Komponente besteht.
Es kann auch sein, dass von der Registrierungsstelle ermit telt/überprüft/ alidiert wird, für welche Anwendung auf der wenigstens einen Komponente das beantragte öffentlich getrus- tete Zertifikat vorgesehen ist. Dann ist die Registrierungs stelle entsprechend ausgebildet und/oder eingerichtet.
Bei der technischen Anlage handelt es sich insbesondere um eine Fertigungs- oder Prozessanlage. Es kann sich etwa um ei ne Anlage aus der Prozessindustrie, wie beispielsweise eine chemische, pharmazeutische, petrochemische oder eine Anlage aus der Nahrungs- und Genussmittelindustrie handeln. Hiermit umfasst sind auch jegliche Anlagen aus der Produktionsindust rie, Werke, in denen z.B. Autos oder Güter aller Art produ ziert werden. Technische Anlagen, die zur Durchführung des erfindungsgemäßen Verfahrens geeignet sind, können auch aus dem Bereich der Energieerzeugung kommen. Windräder, Solaran lagen oder Kraftwerke zur Energieerzeugung sind ebenso von dem Begriff der technischen Anlage umfasst.
Diese Anlagen verfügen in der Regel jeweils über ein Leitsys tem oder zumindest ein computerunterstütztes Modul zur Steue rung und Regelung des ablaufenden Prozesses oder der Produk tion .
Mit dem Begriff „Public-Key Infrastruktur" (kurz: PKI) wird eine Sicherheitsinfrastruktur für eine technische Anlage ver bunden, die Services für einen sicheren Austausch von Daten zwischen Kommunikationspartnern der technischen Anlage be reitstellt. Mit Hilfe der Public-Key Infrastruktur lassen sich Zertifikate ausstellen, verteilen und prüfen.
Unter einem Zertifikat wird ein digitaler Datensatz verstan den, der bestimmte Eigenschaften (in diesem Fall von Maschi nen, Geräten, Applikationen und dergleichen) bestätigt. Eine Authentizität und Integrität des Zertifikats können mittels kryptografischer Verfahren verifiziert werden. Unter öffent lich getrusteten Zertifikaten sind insbesondere solche zu verstehen, die in der gesamten Zertifikatskette bis hin zu allgemein anerkannten Trusted Root Certificates (TRC) verifi zierbar sind. Man kann öffentlich getrustete Zertifikate auch als öffentlich anerkannte Zertifikate bezeichnen. Öffentlich getrustete/anerkannte Zertifikate sind insbesondere solche, die von Mitgliedern des CA/Browser Forums herausgegeben wer den (siehe https://cabforum.org/) . Besonders bevorzugt han delt es sich bei öffentlich getrusteten/anerkannten Zertifi katen, die im Rahmen des erfindungsgemäßen Verfahrens bean tragt/vergeben werden, um SSL (Secure Sockets Layer) oder TLS (Transport Layer Security) Zertifikate.
Bei einer Anlagenkomponente kann es sich beispielsweise um eine Steuerungsvorrichtung, etwa SPS (speicherprogrammierbare Steuerung, englisch: Programmable Logic Controller, PLC), ein Gerät, insbesondere Feldgerät, eine Applikation oder derglei chen handeln. Es handelt sich insbesondere um eine Automati sierungskomponente bzw. ein Automatisierungsgerät.
Die wenigstens eine Anlagenkomponente weist bevorzugt wenigs tens einen Webserver auf bzw. stellt einen Webserver dar.
Für die Übermittlung des wenigstens einen Zertifikatsantrages von dem Zertifizierungsmodul an die Registrierungsstelle kann ein Zertifikatsmanagementprotokoll zum Einsatz kommen. Es kann sich um ein gängiges, im Kontext eines Zertifikatsmana gements für eine technische Anlage, insbesondere ein Leitsys tem einer solchen üblicherweise verwendetes Protokoll, bei- spielsweise das Certificate Management Protocol (kurz: CMP, siehe beispielsweise RFC 4210/4211 der Internet Engineering Task Force (IETF)) handeln. CMP kann insbesondere über https realisiert sein bzw. werden. Es sei betont, dass ein Stan dardprotokoll zum Einsatz kommen kann, jedoch nicht muss. Das Zertifizierungsmodul und die RA können auch rein proprietär miteinander kommunizieren.
Im Rahmen des erfindungsgemäßen Verfahrens können mehrere Va rianten unterstützt werden, insbesondere:
Online Engineering: Die Komponenten (bzw. Server) sind in der Anlage bereits installiert. Das Zertifizierungsmodul kann hier Merkmale auslesen, eine Komponente eindeutig identifi zieren (und sicherstellen, dass es keine weitere Instanz gibt, welche dieselben Merkmale aufweist) und Daten sowie Zertifikate auf die Komponente sicher transferieren.
Offline Engineering: Die Komponenten (Server) sind noch nicht in der Anlage installiert, sondern diese wird ggf. erst noch projektiert. Hierbei muss das Zertifizierungsmodul die für die Zielkomponente notwendige wenigstens eine Komponentenken nung (mit anderen Worten eines oder mehrere eindeutige Merk male, z.B. ein Maschinenzertifikat) eventuell erst erzeugen. Öffentlich getrustete Zertifikate können nun jedoch bereits vorab angefordert und erzeugt werden und im Zertifizierungs modul intern für das projektierte Gerät vorgehalten werden. Später bei einer Inbetriebnahme stellt das Zertifizierungsmo dul dann bevorzugt sicher, dass die wenigstens eine bevorzugt eindeutige Komponentenkennung (mit anderen Worten eindeutige Merkmale) tatsächlich vorliegt bzw. fälschungssicher einge bracht werden kann und dann bevorzugt eingebracht wird. Wenn dies sichergestellt wurde, kann auch das öffentlich getruste te Zertifikat dorthin transferiert werden.
Eine weitere vorteilhafte Ausführungsform zeichnet sich daher dadurch aus, dass für den Fall, dass von dem Zertifizierungs modul in Schritt a) keine Komponentenkennung abgefragt wurde (insbesondere, weil die wenigstens eine Komponente noch nicht in Betrieb war - Offline-Szenario) , das Zertifizierungsmodul vor der Übermittlung des öffentlich getrusteten Zertifikats an die wenigstens eine Komponente und/oder die mit der we nigstens einen Komponente verbundene oder verbindbare Spei chereinrichtung wenigstens eine Komponentenkennung von der wenigstens einen Komponente abfragt und die abgefragte Kompo nentenkennung bevorzugt an die Registrierungsstelle übermit telt. Die (dann) abgefragte Komponentenkennung kann an die Registrierungsstelle übermittelt werden. Die Registrierungs stelle kann diese in einer Datenbank ablegen.
Alternativ oder zusätzlich kann vorgesehen sein, dass das Zertifizierungsmodul vor der Übermittlung des öffentlich ge trusteten Zertifikats an die wenigstens eine Komponente und/oder die mit der wenigstens einen Komponente verbundene oder verbindbare Speichereinrichtung prüft, ob eine von ihm in Schritt b) generierte wenigstens eine Komponentenkennung fälschungssicher in der Komponente gespeichert/abgelegt wer den kann.
Indirekter Offline-Fall: Insbesondere in der Automatisierung existiert der Sonderfall, dass teils gar nicht die tatsächli che Komponente, sondern ein Stellvertreter mit der Konfigura tion versehen wird. So kann z.B. eine SD-Karte oder ein (USB- ) Dongle beim Download die komplette Konfiguration für eine Steuerung (etwa SPS) erhalten, die tatsächliche Komponente im Ersatzteilfall jedoch sofort ausgewechselt werden. Der Down load erfolgt dabei also nur indirekt auf die tatsächliche Komponente. In diesem Fall muss jedoch der Stellvertreter, beispielsweise die Karte oder der (USB- ) Dongle, eindeutig zu identifizieren sein und muss vor unerlaubtem Zugriff ge schützt sein - die Daten im geschützten Bereich dürfen also nicht ohne Weiteres auslesbar sein. Dann kann die betreffen de/jeweilige Komponente dem Stellvertreter, etwa der SD-Karte oder dem Dongle, die Konfiguration entnehmen. Das Zertifikat sollte bevorzugt verschlüsselt sein und es sollte bevorzugt nur die betreffende/j eweilige Komponente beim Einlesen der Konfiguration dazu in der Lage sein, das Zertifikat zu ent schlüsseln .
Das Zertifizierungsmodul hat zweckmäßiger Weise (zumindest zu irgendeinem Zeitpunkt) Zugriff auf die zu validierende Kompo nente bzw. eine einen Stellvertreter darstellende Speicher einrichtung, etwa eine SD-Karte oder einen Dongle. Dies gilt insbesondere, wenn das Zertifizierungsmodul Bestandteil eines Engineering Systems oder mit einem solchen funktional verbun den ist.
Insbesondere im Online-Fall kann das öffentlich getrustete Zertifikat (ggf. mit Begleitmaterial) bevorzugt direkt für die Zielkomponente verschlüsselt werden. So ist gewährleis tet, dass das Zertifikat durchgängig abgesichert ist und aus schließlich dort entschlüsselt werden kann. Darüber hinaus kann jedes Projekt im Engineering System mit einem kundenspe zifischen Schlüssel versehen werden, so dass im Offline-Fall die Zertifizierungsstelle (CA) den Transport zumindest bis zum Zertifizierungsmodul absichern kann. Im jeweiligen Pro jekt kann wiederum das Material für die konkrete Komponente, etwa das konkrete Endgerät verschlüsselt werden. Somit ist ebenfalls eine durchgängige Absicherung möglich.
Es kann vorgesehen sein, dass für den Fall, dass die Überprü fung in Schritt c) ergibt, dass mehrere zu der wenigstens ei nen Komponentenkennung gehörige Komponenten wenigstens einer berechtigten Person oder wenigstens einem berechtigten Unter nehmen zugeordnet sind, insbesondere Eigentum wenigstens ei ner berechtigten Person oder wenigstens eines berechtigten Unternehmens darstellen, die insbesondere in einer Datenbank hinterlegte verfügbare Anzahl potentieller Treffer um eins reduziert wird. Beispielsweise kann insbesondere eine Daten bank einen Eintrag umfassen, gemäß dem ein Benutzer/eine Per son /ein Unternehmen eine bestimmte Anzahl von Automatisie rungskomponenten eines gegebenen Typs besitzt. Nach Genehmi gung eines Zertifikatsantrages bzw. nach Ausstellung eines Zertifikats für eine solche Komponente würde die Anzahl um eins reduziert. Wenn das Zertifikat dann aufgespielt wird, wird bevorzugt eine insbesondere eindeutige Komponentenken nung zurückgespielt, also der Datenbank übermittelt und dort gespeichert. Zertifikatsupdates sollten dann möglichst nicht mehr für solche „allgemeinen Treffer" sondern die konkrete Kennung durchgeführt werden.
Eine weitere vorteilhafte Ausführungsform des erfindungsgemä ßen Verfahrens zeichnet sich dadurch aus, dass die Registrie rungsstelle das öffentlich getrustete Zertifikat in Schritt d) bei einer Zertifizierungsstelle anfordert, insbesondere, indem sie den Zertifikatsantrag validiert und/oder an die Zertifizierungsstelle weiterleitet. Die Zertifizierungsstelle kann dann das angeforderte öffentlich getrustete Zertifikat für die wenigstens eine Komponente erstellen oder beschaffen.
Das Zertifizierungsmodul übermittelt das ihm in Schritt e) übermittelte öffentlich getrustete Zertifikat weiterhin be vorzugt an die wenigstens eine Komponente und/oder an eine mit der wenigstens einen Komponente verbundenen oder verbind bare Speichereinrichtung. Bei einer Speichereinrichtung han delt es sich bevorzugt um einen „Stellvertreter", etwa eine SD-Karte, einen (USB-)Dongle oder ein anderes Speichermedium, auf den eine Konfiguration für die Komponente aufgespielt werden kann/wird.
Zusammen mit dem öffentlich getrusteten Zertifikat kann
Schlüsselmaterial übermittelt werden. Bei dem Schlüsselmate rial handelt es sich insbesondere um solches, welches dem Zertifizierungsmodul zusammen mit dem Zertifikat übermittelt wurde, insbesondere von einer Zertifizierungsstelle.
Das öffentlich getrustete Zertifikat wird bevorzugt in einem fälschungssicheren Zertifikatsspeicher der wenigstens einen Komponente und/oder der mit der wenigstens einen Komponente verbundenen oder verbindbaren Speichereinrichtung abgelegt. Für die Übermittlung des öffentlich getrusteten Zertifikats von dem Zertifizierungsmodul an die wenigstens eine Komponen te und/oder an die mit der wenigstens einen Komponente ver bundene oder verbindbare Speichereinrichtung kann eine direk te Verbindung zwischen dem Zertifizierungsmodul bzw. zwischen Hardware, auf welcher das Zertifizierungsmodul implementiert ist, und der wenigstens einen Komponente und/oder der mit der wenigstens einen Komponente verbundenen oder verbindbaren Speichereinrichtung bestehen bzw. hergestellt werden. Unter „direkt" ist dabei insbesondere zu verstehen, dass das Zerti fizierungsmodul mit der Komponente „direkt" kommunizieren kann. Es bedeutet bevorzugt, dass sich das Zertifizierungsmo dul im selben Netzwerk befindet, von dem aus die Komponente erreichbar ist und kein Vermittler notwendig ist. Eventuell liegt eine Punkt-zu-Punkt Verbindung zwischen dem Zertifizie rungsmodul (bzw. Hardware, auf welcher dieses implementiert ist) und der wenigstes einen Komponente vor (etwa Serial- kalbel-Verbindung, USB-Kabel, usw.) . Es kann insbesondere ei ne direkte kabelgebundene oder kabellose Verbindung bestehen bzw. hergestellt werden.
Analoges kann für das Abfragen der wenigstens einen Komponen tenkennung gelten. So kann vorgesehen sein, dass das Zertifi zierungsmodul in Schritt b) die wenigstens eine Komponenten kennung von der wenigstens einen Komponente abfragt, wobei hierfür eine direkte Verbindung zwischen dem Zertifizierungs modul bzw. zwischen Hardware, auf welcher das Zertifizie rungsmodul implementiert ist, und der wenigstens einen Kompo nente besteht bzw. hergestellt wird.
Ein weiterer Gegenstand der Erfindung ist ein System zur Vergabe von öffentlich getrusteten Zertifikaten für Anlagen komponenten einer technischen Anlage, umfassend ein Zertifi zierungsmodul und eine Registrierungsstelle,
wobei das Zertifizierungsmodul dazu ausgebildet und/oder ein gerichtet ist, von wenigstens einer Anlagenkomponente, die ein öffentlich getrustetes Zertifikat erhalten soll, wenigs tens eine bevorzugt eindeutige Komponentenkennung abzufragen und/oder für wenigstens eine Anlagenkomponente, die ein öf fentlich getrustetes Zertifikat erhalten soll, wenigstens ei ne bevorzugt eindeutige Komponentenkennung zu generieren, und die Registrierungsstelle dazu ausgebildet und/oder einge richtet ist, anhand der wenigstens einen Komponentenkennung zu überprüfen, ob die wenigstens eine zu der Komponentenken nung gehörige Komponente wenigstens einer berechtigten Person oder wenigstens einem berechtigten Unternehmen zugeordnet ist, insbesondere Eigentum wenigstens einer berechtigten Per son oder wenigstens eines berechtigten Unternehmens dar stellt, und für den Fall, dass dem so ist, ein öffentlich ge trustetes Zertifikat für die wenigstens eine Komponente anzu fordern,
und das Zertifizierungsmodul dazu ausgebildet und/oder einge richtet ist, das angeforderte öffentlich getrustete Zertifi kat zu empfangen und bevorzugt in einem geschützten Bereich zu speichern.
Das erfindungsgemäße System ist für die Durchführung des er findungsgemäßen Verfahrens besonders geeignet.
In Weiterbildung umfasst das erfindungsgemäße System eine Da tenbank, in der Komponentenkennungen zusammen mit zugehörigen berechtigten Personen und/oder Unternehmen, die bevorzugt Ei gentümer zugehöriger Komponenten darstellen, gespeichert sind, und ist die Registrierungsstelle dazu ausgebildet und/oder eingerichtet, für die oder im Rahmen der Überprü fung, ob die wenigstens eine zu der Komponentenkennung gehö rige Komponente wenigstens einer berechtigten Person oder we nigstens einem berechtigten Unternehmen zugeordnet ist, in der Datenbank nach wenigstens einem Eintrag für die zusammen mit dem Zertifikatsantrag übermittelte wenigstens eine Kompo nentenkennung zu suchen.
Das Zertifizierungsmodul bildet bevorzugt ein (lokales) „Frontend" bzw. eine (lokale) „Frontend"-Einheit des Systems bzw. ist Bestandteil eines bzw. einer solchen. Die Registrie rungsstelle ist - ggf. zusammen mit einer Datenbank und einer Zertifizierungsstelle - bevorzugt Teil eines (zentralen) „Ba- ckends" bzw. einer zentralen „Backend"-Einheit des Systems. Das Zertifizierungsmodul befindet sich bevorzugt vor Ort bei oder in der technischen Anlage, während der Registrierungs dienst sich bevorzugt entfernt von dieser, etwa in einem Re chenzentrum befindet. Der Registrierungsdienst kann insbeson dere von mehreren Zertifizierungsmodulen, die sich bei/in verschiedenen Anlagen befinden können, kontaktiert werden und Zertifikatsanträge zusammen mit Komponentenkennungen erhal ten .
Neben der Registrierungsstelle - und ggf. einer Datenbank - kann eine Zertifizierungsstelle weiterer Bestandteil eines „Backends" / einer „Backend"-Einheit des Systems sein. Alter nativ oder zusätzlich kann eine separate/externe Zertifizie rungsstelle existieren, die der Registrierungsstelle des er findungsgemäßen Systems vertraut. Eine separate/externe Zer tifizierungsstelle kann durch eine Zertifizierungsstelle wie VeriSign oder eine andere bekannte Zertifizierungsstelle ge geben sein, die bevorzugt ein Trusted Root Certificate (TRC) besitzt .
Die Erfindung betrifft darüber hinaus ein Engineering- oder Leitsystem für eine technisch Anlage umfassend ein Zertifi zierungsmodul, das dazu ausgebildet und/oder eingerichtet ist,
- von wenigstens einer Anlagenkomponente, die ein öffentlich getrustetes Zertifikat erhalten soll, wenigstens eine be vorzugt eindeutige Komponentenkennung abzufragen und/oder für wenigstens eine Anlagenkomponente, die ein öffentlich getrustetes Zertifikat erhalten soll, wenigstens eine be vorzugt eindeutige Komponentenkennung zu generieren,
- die wenigstens eine abgefragte und/oder wenigstens eine ge nerierte Komponentenkennung zusammen mit einem Zertifikats antrag für ein öffentlich getrustetes Zertifikat für die wenigstens eine Komponente an eine Registrierungsstelle (RA) zu übermitteln, - ein öffentlich gefrustetes Zertifikat für die Anlagenkompo nente zu empfangen und bevorzugt in einem geschützten Be reich zu speichern.
Das Zertifizierungsmodul kann eine Inspektionseinheit
und/oder eine Deployment-Einheit umfassen.
Ist eine Inspektionseinheit vorhanden, ist diese bevorzugt dazu ausgebildet und/oder eingerichtet, von der wenigstens einen Komponente, die das öffentlich gefrustete Zertifikat erhalten soll, wenigstens eine bevorzugt eindeutige Komponen tenkennung abzufragen (mit anderen Worten auszulesen) und/oder für die wenigstens eine Komponente, die das öffent lich gefrustete Zertifikat erhalten soll, wenigstens eine be vorzugt eindeutige Komponentenkennung zu generieren.
Ist eine Deployment-Einheit vorhanden, ist diese bevorzugt dazu ausgebildet und/oder eingerichtet, ein erstelltes öf fentlich gefrustetes Zertifikat an die (jeweilige) Komponente zu übermitteln, also auf diese aufzuspielen. Sie ist bevor zugt dazu ausgebildet und/oder eingerichtet, von einer Zerti fizierungsstelle erstellte öffentlich gefrustete Zertifikate zu empfangen, um diese dann an die (jeweilige) Komponente weitergeben zu können.
Schließlich betrifft die Erfindung eine technische Anlage, insbesondere Fertigungs- oder Prozessanlage. Die erfindungs gemäße technische Anlage umfasst bevorzugt wenigstens ein er findungsgemäßes Engineering- oder Leitsystem.
Im Rahmen der erfindungsgemäßen Vorgehensweise kann alterna tiv oder zusätzlich auch ein Gateway- und/oder Edge-Gerät ge nutzt werden. Es kann insbesondere vorgesehen sein, dass das Zertifizierungsmodul auf einem Edge-Gerät vorgesehen/imple- mentiert ist. Das Zertifizierungsmodul kann zum Beispiel als App auf einem Edge-Gerät/-Device ausgeführt werden. Kommt ein Edge-Gerät zum Einsatz, kann die Anforderung (Zertifikatsan träge) , Erneuerung und das sichere Einspielen von öffentlich getrusteten Zertifikaten auf den Komponenten, etwa Geräten im lokalen Netzwerk einer technischen Anlage voll-automatisch erfolgen, während das Gateway-/Edge-Gerät auch einen Zugang zum Internet und der öffentlichen Infrastruktur erlaubt. Ein Edge-Gerät liegt zweckmäßiger Weise (wie der Name sagt) an der Außenkante des geschlossenen Netzwerkes und hat zwei Netzzugänge/Netzwerkadapter. Das Edge-Gerät befindet sich da mit dann insbesondere sowohl im geschlossenen internen Netz als auch im öffentlichen Internet. Die Geräte bzw. Komponen ten im geschlossenen Netzwerk haben hingegen meist keinen Zu gang zum Internet. Das ist insbesondere im Betrieb zum auto matischen Erneuern praktisch, da das Engineering-System nicht benötigt wird und man auch nicht das Zertifizierungsmodul erst intern verwendet, um die Kennung zu erhalten, um dann manuell damit in das öffentliche Internet zu wechseln.
Weitere Merkmale und Vorteile der vorliegenden Erfindung wer den anhand der nachfolgenden Beschreibung erfindungsgemäßer Ausführungsformen unter Bezugnahme auf die beiliegende Zeich nung deutlich.
Die Figur zeigt eine Anlagenkomponente G und ein Ausführungs beispiel eines erfindungsgemäßen Systems zur Vergabe von öf fentlich getrusteten Zertifikaten in rein schematischer Dar stellung .
Die Anlagenkomponente G ist bei dem hier beschriebenen Bei spiel durch eine speicherprogrammierbare Steuerung, kurz SPS, gegeben und Bestandteil einer nicht weiter dargestellten technischen Anlage, insbesondere Fertigungs- oder Prozessan lage. Die Anlage umfasst in an sich bekannter Weise u.a. noch eine Mehrzahl von Sensoren, welche Messwerte für die Steue rung G liefern, sowie Aktoren, welche Stellwerte von der Steuerung G empfangen. So kann ein in der Anlage ablaufender Prozess überwacht und auf diesen eingewirkt werden.
Die Steuerung G ist mit den Sensoren und Aktoren sowie weite ren Anlagenkomponenten in an sich bekannter Weise über ein Anlagennetzwerk verbunden. Das Anlagennetzwerk ist ein loka les, geschlossenes Netzwerk und die Steuerung G ist nicht von außen via Internet erreichbar.
Die Steuerung G zeichnet sich durch eine eindeutige Komponen tenkennung K aus, die bei dem hier beschriebenen Ausführungs beispiel durch ein Gerätezertifikat K gegeben ist.
Insbesondere, damit es möglich wird, dass sich Benutzer Daten der Steuerung G auch auf mobilen Endgeräten ansehen können, soll die Steuerung G ein Zertifikat erhalten.
Im Fall von Browsern auf Client-Endgeräten müssen dafür Zer tifikate in der gesamten Zertifikatskette bis hin zu allge mein anerkannten Trusted Root Certificates TRC verifizierbar sein (siehe beispielsweise die "Root CA Policy" von Google Chrome) . Bei diesen handelt es sich um eine Handvoll von Zer tifikaten, die browser- und
betriebssystemübergreifend als vertrauenswürdig eingestuft werden und nicht individuell installiert
werden müssen.
Die Steuerung G bzw. ein Webserver auf dieser soll ein sol ches, bis hin zu einem Trusted Root Zertifikat TRC verifi zierbares Zertifikat erhalten, welches auch als öffentlich getrustetes Zertifikat C bezeichnet wird.
Die Steuerung G weist einen fälschungssicheren Certificate Store CS, der in an sich bekannter Weise dazu dient, ein di gitales Zertifikat sicher zu verwahren bzw. zu speichern. In dem Certifcate Store CS kann ein solches öffentlich getruste tes Zertifikat C abgelegt werden.
Um öffentlich anerkannte (getrustete) Zertifikate C ausstel len zu können, muss eine CA in der Lage sein
sicherzustellen, dass die Zertifikat-anfordernde Person bzw. das Zertifikat-anfordernde Unternehmen tatsächlich die Kon trolle und/oder Verantwortung über die Komponente bzw. einen darauf implementierten Server und die darauf zeigende Domäne hat. Dies kann gemäß dem Stand der Technik über die Erreich barkeit der entsprechenden Komponente/des entsprechenden Ser vers gewährleistet werden - was jedoch in der industriellen Anlage nicht gegeben ist.
Es ist daher ein erfindungsgemäßes System S zur Vergabe von öffentlich getrusteten Zertifikaten C für Anlagenkomponenten G einer technischen Anlage vorgesehen, welches dafür verwen det werden kann, ein solches Zertifikat C für die Steuerung G zu beschaffen und in dieser abzulegen (auch als „Deployment" bezeichnet) .
Das in der Figur dargestellte Ausführungsbeispiel eines sol chen erfindungsgemäßen Systems S umfasst ein Zertifizierungs modul ZM, welches eine „Frontend"-Einheit bzw. „Frontend"- Komponente des Systems 1 darstellt und sich vor Ort bei bzw. in der technischen Anlage befindet. Das Zertifizierungsmodul ZM ist vorliegend in ein Engineering System ES der techni schen Anlage integriert. Es ist konkret eine funktionale Ein heit bzw. ein funktionales Modul, welches durch Software im plementiert ist, die sich auf Hardware des Engineering Sys tems ES befindet. Das Engineering System bildet einen Be standteil des dargestellten Ausführungsbeispiels eines erfin dungsgemäßen Systems S zur Vergabe von öffentlich getrusteten Zertifikaten. Das Engineering System ES kann auf Standard- Hardware, etwa einem üblichen PC oder Industrie-PC laufen.
Es sei angemerkt, dass es alternativ dazu, dass das Zertifi zierungsmodul ZM - wie bei dem dargestellten Beispiel - in ein Engineering System S der Anlage integriert ist, dieses auch ein Stand-Alone-Tool bzw. Stand-Alone-Modul darstellen bzw. Teil eines anderen Tools sein kann. Dann besteht zweck mäßiger Weise eine funktionale Verbindung zwischen dem Engi neering System ES und dem Zertifizierungsmodul ZM. Das Zerti fizierungsmodul ZM kann auch auf einem Edge-Gerät implemen tiert sein, welches an der Außenkante des geschlossenen Anla gennetzwerkes liegt und zwei Netzzugänge/Netzwerkadapter hat, so dass es sich sowohl im geschlossenen internen Anlagennetz als auch im öffentlichen Internet befindet.
Das Engineering System ES hat eine sehr genaue Kenntnis über die Automatisierungs-Produkte in einer technischen Anlage. So kennt es die exakte Hardware (z.B. anhand der Seriennummer) oder das konkrete Produkt (z.B. anhand der MLFB) , ist aber auch in der Lage eine Komponente, wie die Steuerung G, ein deutig zu identifizieren oder identifizierbar zu machen (z.B. über ein fest eingebranntes oder sicher aufspielbares Maschi nen- oder Geräte-Zertifikat ) . Ebenso besitzt das Engineering System ES in der Regel ohnehin Möglichkeiten, Daten sicher auf die entsprechenden Komponenten, etwa Automatisierungs- Geräte zu übertragen (im Sinne von fälschungssicher sowie nicht durch Dritte einseh- bzw. mitlesbar) .
Das erfindungsgemäße System S umfasst neben dem Engineering System ES mit dem Zertifizierungsmodul ZM weiterhin ein Ba ckend bzw. eine Backend-Einheit BE mit einer Registrierungs stelle RA, einer Datenbank D und einer Zertifizierungsstelle CA. Das Backend bzw. die Backend-Einheit BE ist nicht vor Ort bei der Anlage angeordnet, sondern befindet sich in einem Re chenzentrum, welches beispielsweise einige bzw. viele Kilome ter von der Anlage entfernt ist. Eine Kommunikation zwischen dem Zertifizierungsmodul ZM und dem Backend BE ist über das öffentliche Internet möglich.
Dass sich das Engineering System ES mit dem Zertifizierungs modul ZM und die Steuerung G im Gegensatz zu dem Backend BE vor Ort bei bzw. in der technischen Anlage befinden, konkret einen Bestandteil dieser bilden, ist in der Figur durch eine geschwungene Klammer am Rand angedeutet, welche die Komponen ten vor Ort zusammenfasst.
Das Zertifizierungsmodul ZM ist dazu ausgebildet, mit Kompo nenten G der Anlage zu kommunizieren. Das Zertifizierungsmodul ZM umfasst eine Inspektionseinheit IE, die dazu ausgebildet ist, von Komponenten G, die ein öf fentlich getrustetes Zertifikat C erhalten sollen, bevorzugt eindeutige Komponentenkennungen K abzufragen (mit anderen Worten auszulesen) sowie für Komponenten G, die ein öffent lich getrustetes Zertifikat C erhalten sollen, bevorzugt ein deutige Komponentenkennungen K zu generieren. Die Abfrage bzw. das „Probing" ist in der Figur durch einen von der In spektionseinheit IE zu dem die Komponentenkennung K bildenden Gerätezertifikat weisenden Pfeil angedeutet.
Die Inspektionseinheit IE ist ferner dazu ausgebildet, abge fragte und/oder generierte Komponentenkennungen K jeweils zu sammen mit einem Zertifikatsantrag CSR für ein öffentlich ge trustetes Zertifikat C für die jeweilige Komponente G an die Registrierungsstelle RA zu übermitteln. Die Übermittlung ist in der Figur durch einen von der Inspektionseinheit IE zu der Registrierungsstelle RA weisenden Pfeil angedeutet, neben dem beispielhaft eine Zertifikatsanfrage CSR für die Steuerung G zusammen mit dem Gerätezertifikat K der Steuerung G rein schematisch dargestellt ist.
Das Zertifizierungsmodul ZM weist darüber hinaus eine Deploy- ment-Einheit DE auf, die dazu ausgebildet ist, öffentlich ge- trustete Zertifikate C an die (jeweilige) Komponente G zu übermitteln, also auf diese aufzuspielen. Sie ist dazu ausge bildet, von der Zertifizierungsstelle CA erstellte bzw. be schaffte öffentlich getrustete Zertifikate C zu empfangen und diese dann an die (jeweilige) Komponente G weiterzugeben.
Dies ist in der Figur durch Pfeile angedeutet, von der Zerti fizierungsstelle CA zu der Deployment-Einheit DE und von die ser zu dem Certificate Store CS der Steuerung G weisen und neben denen jeweils ein Zertifikat C rein schematisch darge stellt ist.
Die Registrierungsstelle RA ist dazu ausgebildet, anhand der wenigstens einen Komponentenkennung K zu überprüfen, ob die wenigstens eine zu der Komponentenkennung K gehörige Kompo- nente, vorliegend die Steuerung G wenigstens einer berech tigten Person oder wenigstens einem berechtigten Unternehmen zugeordnet ist, insbesondere Eigentum wenigstens einer be rechtigten Person oder wenigstens eines berechtigten Unter nehmens darstellt, und für den Fall, dass dem so ist, ein öf fentlich getrustetes Zertifikat C für die wenigstens eine Komponente G anzufordern. Die Registrierungsstelle RA ist in der Lage, anhand übermittelter eindeutigen Komponentenmerkma le K eine rechtlich bindende Kundenzuordnung zu validieren.
Unter Verwendung des dargestellten Ausführungsbeispiels eines erfindungsgemäßen Systems S kann ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens zur Vergabe von öffentlich ge- trusteten Zertifikaten C für Anlagenkomponenten G einer tech nischen Anlage durchgeführt werden.
Dabei fragt in einem ersten Schritt das Zertifizierungsmodul ZM von der Steuerung G, die ein öffentlich getrustetes Zerti fikat erhalten soll, wenigstens eine bevorzugt eindeutige Komponentenkennung, vorliegend das Gerätezertifikat K ab. Das Zertifizierungsmodul ZM, welches vorliegend in das Enginee ring System der Anlage integriert ist, hat direkten Zugriff auf die Steuerung G, so dass diese Abfrage problemlos möglich ist. Das Engineering System G ist Teilnehmer des geschlosse nen Anlagennetzes, so dass es - und somit das integrierte Zertifizierungsmodul ZM - auf die Steuerung G Zugriff hat.
Alternativ oder zusätzlich zu dem Abfragen/Auslesen der we nigstens einen Komponentenkennung K kann das Zertifizierungs modul ZM für die Steuerung G, die ein öffentlich getrustetes Zertifikat erhalten soll, auch wenigstens eine bevorzugt ein deutige Komponentenkennung, vorliegend ein (ggf. vorüberge hendes) Gerätezertifikat generieren.
Dies ist vor allem dann vorteilhaft, wenn wenigstens eine Komponente, etwa die Steuerung G noch nicht in Betrieb genom men wurde, sondern dies ggf. erst noch projektiert wird. Mit anderen Worten wird auch ein Offline- bzw. Vorab-Engineering unterstützt. Dies macht es auch möglich, dass sich das Engi neering Systems ES (noch) nicht im Anlagennetz befinden muss. Durch die Generierung wenigstens einer eindeutigen Kennung K durch das Zertifizierungsmodul ZM werden die Komponenten ein deutig identifizierbar. Öffentlich getrustete Zertifikate C können dann bereits vorab angefordert und erzeugt werden und im Zertifizierungsmodul ZM intern für die projektierte Kompo nente G vorgehalten werden. Später bei einer Inbetriebnahme stellt das Zertifizierungsmodul ZM dann bevorzugt sicher, dass die wenigstens eine Komponentenkennung K tatsächlich vorliegt bzw. fälschungssicher eingebracht werden kann. Wenn dies sichergestellt wurde, kann auch das öffentlich getruste te Zertifikat C dorthin transferiert werden.
Im Anschluss an das Abfragen und/oder Generieren der wenigs tens einen Komponentenkennung, vorliegend des abgefragten Ge rätezertifikates K übermittelt das Zertifizierungsmodul ZM dieses zusammen mit einem Zertifikatsantrag CSR für ein öf fentlich getrustetes Zertifikat C für die Steuerung G an eine Registrierungsstelle RA.
Der Zertifikatsantrag CSR, den das Zertifizierungsmodul ZM an die Registrierungsstelle RA übermittelt, kann dabei von dem Zertifizierungsmodul ZM oder auch von der Steuerung G er stellt werden bzw. worden sein.
Die Registrierungsstelle RA überprüft dann anhand des Geräte zertifikates K, ob die wenigstens eine zu der Komponentenken nung K gehörige Steuerung G wenigstens einer berechtigten Person oder wenigstens einem berechtigten Unternehmen, in de ren oder dessen Verantwortung die Steuerung steht, zugeordnet ist. Diese Überprüfung erfolgt bei dem dargestellten Ausfüh rungsbeispiel, indem die Registrierungsstelle RA die Daten bank D, in der Komponentenkennungen K, u.a. Gerätezertifikate K, zusammen mit zugehörigen berechtigten Personen und/oder Unternehmen, die Eigentümer von zu den Komponentenkennungen K gehörigen Komponenten G darstellen, gespeichert sind, nach wenigstens einem Eintrag für die zusammen mit dem Zertifi- katsantrag CSR übermittelte Komponentenkennung, vorliegend dem Gerätezertifikat K der Steuerung G, sucht.
Wird ein Eintrag für die mit dem Zertifikatsantrag CSR über mittelte Komponentenkennung K in der Datenbank gefunden, wird der Zertifikatsantrag CSR von der Registrierungsstelle RA ge nehmigt/validiert .
Es sei angemerkt, dass ein solcher Eintrag in der Datenbank bevorzugt erstellt wurde, nachdem ein Kunde die Steuerung G gekauft hat und somit der Eigentümer wurde. Über den Abruf bzw. die Suche in der Datenbank D kann somit geprüft werden, ob die Steuerung G im Besitz eines berechtigten Kunden steht oder nicht.
Weiterhin sei angemerkt, dass es natürlich möglich ist, dass gemäß der Datenbank D mehrere baugleiche Komponenten, etwa Steuerungen G existieren, die einer Person bzw. einem Unter nehmen zugeordnet sind, insbesondere einer Person bzw. einem Unternehmen gehören. Ist dies der Fall, wird der Zertifikats antrag CSR genehmigt und die Anzahl potentieller Treffer also baugleicher Komponenten G in der Datenbank um eins reduziert.
Die Registrierungsstelle RA fordert in einem nächsten Schritt das öffentlich getrustete Zertifikat C bei der Zertifizie rungsstelle CA an, insbesondere, indem sie den Zertifikatsan trag CSR an die Zertifizierungsstelle CA weiterleitet.
Die Zertifizierungsstelle CA erstellt oder beschafft dann das angeforderte öffentlich getrustete Zertifikat C für die Steu erung G. Dabei kontaktiert die einen Teil des Backends BE darstellende Zertifizierungsstelle CA bei dem hier beschrie benen Beispiel eine weitere, zentrale Zertifizierungsstelle zCA, die über ein Trusted Root Zertifikat TRC verfügt. Da die zCA eine Vertrauensstellung mit der CA besitzt, führt diese den CSR direkt aus. Von bzw. in der Registrierungsstelle CA oder zCA des Backends BE wird ein Zertifikat C erstellt.
Das Zertifikat C wird zusammen mit zugehörigem Schlüsselmate rial an die Deployment-Einheit DE des Zertifizierungsmoduls ZM weitergeleitet, dort oder an einer anderen Stelle in dem Engineering System Es in einem geschützten Bereich, der nicht von außen gelesen oder verändert werden kann, gespeichert.
Das Zertifikat C und zugehörige Schlüsselmaterial werden fer ner von der Deployment-Einheit „deployed", also in die Steue rung G eingebracht, konkret in dem Certificate Store CS si cher abgelegt. Dies ist in der Figur 1 erneut durch entspre chende Pfeile angedeutet.
Das Zertifikat C (kann auch als Kundenzertifikat bzw. eng lisch customer certificat bezeichnet werden) weist bei dem dargestellten Ausführungsbeispiel auf ein Zwischenzertifikat zC der CA, das wiederum auf das Trusted Root Certificate TRC der zCA verweist. In der Figur ist diese Zertifikatskette durch Pfeile mit gestrichelter Linie angedeutet. Man kann auch sagen, dass diese Pfeile den „Trust", also das Vertrauen zwischen den Stellen bzw. Zertifikaten andeuten. Das TRC ist, wie man sieht, das Ende der Zertifikatkette. Das (Kunden- ) Zertifikat C in der Komponente G muss über die ganze Kette bis zum TRC der zCA gültig sein.
Es sei angemerkt, dass eine zentrale Zertifizierungsstelle zCA vorgesehen und con den CA kontaktiert werden kann jedoch nicht muss. Alternativ zu dem in der Figur dargestellten Aus führungsbeispiel ist es auch möglich, dass die CA direkt Zer tifikate C ausstellt, ohne auf externes Mitwirken einer wei teren CA angewiesen zu sein. Dies vor allem, wenn die CA gül tiges Schlüsselmaterial besitzt.
Falls das ES eine vorläufige, nicht abgerufene, sondern gene rierte Kennung K verwendet hat, wird die nun die eindeutige Kennung K aus der Komponente G abgefragt und an das Backend BE zurück übermittelt. Dort kann die vorläufige Kennung nun mit der tatsächlichen ersetzt werden. (Falls das ES vorab ei ne eindeutige Kennung K erzeugt hat und diese in die Kompo nente G eingebracht werden konnte, entfällt die Rückübermitt lung, oder aber es werden weitere Kennzeichen, wie die Se riennummer zur korrekten Zuordnung in der Datenbank D über tragen . )
Weiterhin sei angemerkt, dass für den Fall, dass die RA in der Datenbank keinen Eintrag für die mit dem CSR übermittelte Komponentenkennung K finden könnte, der Antrag CSR abgelehnt und kein Zertifikat C erstellt würde.
Das Engineering System ES mit dem Zertifizierungsmodul ZM kann folgende drei Varianten unterstützen:
- Online Engineering: Die Komponenten/Server sind in der An lage bereits installiert. Das ES kann hier Merkmale ausle- sen, eine Komponente G eindeutig identifizieren (und si cherstellen, dass es keine weitere Instanz gibt, welche dieselben Merkmale aufweist) und Daten sowie Zertifikate C auf die Komponente G sicher transferieren.
- Offline Engineering: Die Komponenten/Server sind noch nicht in der Anlage installiert, sondern diese wird ggf. erst noch projektiert. Hierbei wird das Engineering System ES die für die Zielkomponente G notwendigen eindeutigen Merk male (wenigstens eine Komponentenkennung K) eventuell erst erzeugen (z.B. ein Maschinenzertifikat) . Zertifikate C kön nen dann jedoch bereits vorab angefordert und erzeugt wer den aber im Engineering System ES, konkret dem Zertifizie rungsmodul ZM intern für die projektierte Komponente G vor gehalten werden. Später bei einer Inbetriebnahme stellt das ES sicher, dass die eindeutigen Merkmale tatsächlich vor liegen bzw. fälschungssicher eingebracht werden können.
Wenn dies sichergestellt wurde, kann auch das bereits vor gehaltene Zertifikat C dorthin transferiert werden.
- Indirekter Offline-Fall: In der Automatisierung existiert der Sonderfall, dass teils gar nicht die tatsächliche Kom- ponente G, sondern ein Stellvertreter, etwa eine SD-Karte oder ein (USB-)Dongle mit der Konfiguration versehen wird. So kann z.B. eine SD-Karte/ein Dongle beim Download die komplette Konfiguration für eine SPS G erhalten, die tat sächlich Steuerung G im Ersatzteilfall jedoch sofort ausge wechselt werden. Der Download erfolgt dabei also nur indi rekt auf das tatsächliche Gerät G. In diesem Fall muss je doch der Stellvertreter, also die Karte/der Dongle, eindeu tig zu identifizieren sein und muss vor unerlaubtem Zugriff geschützt sein - die Daten in einem geschützten Bereich dieser bzw. dieses dürfen also nicht ohne Weiteres ausles bar sein.
In allen drei Fällen hat das Engineering System ES zumindest zu irgendeinem Zeitpunkt Zugriff auf die zu validierenden Komponenten G.
Im Online-Fall kann das Zertifikat C mit Begleitmaterial di rekt für die Zielkomponente G verschlüsselt werden. So ist gewährleistet, dass das Zertifikat C durchgängig abgesichert ist und ausschließlich dort entschlüsselt werden kann. Dar über hinaus kann jedes Projekt im Engineering System ES mit einem ( künden) spezifischen Schlüssel versehen werden, so dass im Offline-Fall die CA den Transport zumindest bis zum ES ab sichern kann. Im jeweiligen Projekt kann wiederum das Materi al für das konkrete Endgerät G verschlüsselt werden. Somit ist ebenfalls eine durchgängige Absicherung möglich.
Es sei angemerkt, dass das Engineering System ES, in welches das Zertifizierungsmodul ZM integriert ist, bzw. von dem das Zertifizierungsmodul ZM einen Bestandteil bildet, ein Ausfüh rungsbeispiel eines erfindungsgemäßen Engineering Systems ei ner technischen Anlage bzw. für eine Technische Anlage dar stellt .
Die technische Anlage, von der die Steuerung G und das Engi neering Systems ES einen Bestandteil bilden, ist ferner ein Ausführungsbeispiel einer erfindungsgemäßen technischen Anla ge .
Obwohl die Erfindung im Detail durch das bevorzugte Ausfüh- rungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht durch die offenbarten Beispiele einge schränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen .
Es versteht sich beispielsweise, dass auch wenn die erfin dungsgemäßen Ausführungsformen vorstehend beispielshaft an hand einer Komponente einer technischen Anlage, konkret einer Steuerung G erläutert wurden, selbstverständlich für beliebig viele weitere Komponenten auf entsprechende Weise öffentlich getrustete Zertifikate C beantragt und ggf. erstellt und an diese übermittelt werden können. Dabei kann für mehrere Kom ponenten einer technischen Anlage (oder auch mehrerer techni scher Anlagen) ein Zertifizierungsmodul ZM bzw. ein erfin- dungsgemäßes System S genutzt werden.
Insbesondere das Backend BE eines erfindungsgemäßen Systems kann auch eine Zentrale darstellen, die mit mehreren Zertifi zierungsmodulen ZM kommuniziert und auf die Anfragen mehrere Zertifizierungsmodule ZM, ggf. verschiedener Anlagen, öffent lich getrustete Zertifikate C erstellt und an die mehreren Zertifizierungsmodule ZM übermittelt.

Claims

Patentansprüche
1. Verfahren zur Vergabe von öffentlich getrusteten Zertifi katen (C) für Anlagenkomponenten (G) einer technischen Anla ge, bei dem
a) ein Zertifizierungsmodul (ZM) von wenigstens einer Anla genkomponente (G) , die ein öffentlich getrustetes Zertifi kat (C) erhalten soll, wenigstens eine bevorzugt eindeuti ge Komponentenkennung (K) abfragt und/oder für wenigstens eine Anlagenkomponente (G) , die ein öffentlich getrustetes Zertifikat (C) erhalten soll, wenigstens eine bevorzugt eindeutige Komponentenkennung (K) generiert,
b) das Zertifizierungsmodul (ZM) die wenigstens eine abgeb- fragte und/oder wenigstens eine generierte Komponentenken nung (K) zusammen mit einem Zertifikatsantrag (CSR) für ein öffentlich getrustetes Zertifikat (C) für die wenigs tens Komponente (G) an eine Registrierungsstelle (RA) übermittelt,
c) die Registrierungsstelle (RA) anhand der wenigstens einen Komponentenkennung (K) überprüft, ob die wenigstens eine zu der Komponentenkennung (K) gehörige Komponente (G) we nigstens einer berechtigten Person oder wenigstens einem berechtigten Unternehmen, in deren oder dessen Verantwor tung die wenigstens eine Komponente (G) steht, zugeordnet ist,
d) die Registrierungsstelle (RA) für den Fall, dass dem so ist, ein öffentlich getrustetes Zertifikat (C) für die we nigstens eine Komponente (G) anfordert,
e) das angeforderte öffentlich getrustete Zertifikat (C) er stellt und an das Zertifizierungsmodul (ZM) übermittelt und bevorzugt in einem geschützten Bereich insbesondere des Zertifizierungsmoduls (ZM) gespeichert wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Registrierungsstelle (RA) das öffentlich getrustete Zer tifikat (C) in Schritt d) bei einer Zertifizierungsstelle (CA) anfordert, insbesondere, indem sie den Zertifikatsantrag (CSR) validiert und/oder an die Zertifizierungsstelle (CA) weiterleitet, und die Zertifizierungsstelle (CA) das angefor derte öffentlich getrustete Zertifikat (C) für die wenigstens eine Komponente (G) erstellt oder beschafft.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Zertifizierungsmodul (ZM) das öffentlich getrustete Zertifikat (C) an die wenigstens eine Komponente (G) oder an eine mit der wenigstens einen Komponente (G) verbundenen oder verbindbare Speichereinrichtung übermittelt, wobei das öf fentlich getrustete Zertifikat (C) bevorzugt in einem fäl schungssicheren Zertifikatsspeicher (CS) der wenigstens einen Komponente (G) oder der mit der wenigstens einen Komponente (G) verbundenen oder verbindbaren Speichereinrichtung abge legt wird.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass für die Übermittlung des öffentlich getrusteten Zertifikats (C) von dem Zertifizierungsmodul (ZM) an die wenigstens eine Komponente (G) und/oder an die mit der wenigstens einen Kom ponente (G) verbundenen oder verbindbare Speichereinrichtung eine direkte Verbindung zwischen dem Zertifizierungsmodul (ZM) bzw. zwischen Hardware, auf welcher das Zertifizierungs modul (ZM) implementiert ist, und der wenigstens einen Kompo nente (G) und/oder der mit der wenigstens einen Komponente
(G) verbundenen oder verbindbaren Speichereinrichtung besteht bzw. hergestellt wird.
5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, dass für den Fall, dass von dem Zertifizierungsmodul (ZM) in Schritt a) keine Komponentenkennung (K) abgefragt wurde, das Zertifizierungsmodul (ZM) vor der Übermittlung des öffentlich getrusteten Zertifikats (C) an die wenigstens eine Komponente (G) wenigstens eine Komponentenkennung (K) von der wenigstens einen Komponente (G) abfragt und die abgefragte Komponenten kennung (K) bevorzugt an die Registrierungsstelle (RA) über mittelt .
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Zertifikatsantrag (CSR) , den das Zertifizierungsmodul (ZM) in Schritt b) an die Registrie rungsstelle (RA) übermittelt, von dem Zertifizierungsmodul (ZM) oder von der wenigstens einen Komponente (G) erstellt wird .
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für den Fall, dass die Überprüfung in Schritt c) ergibt, dass mehrere zu der wenigstens einen Kom ponentenkennung (K) gehörige Komponenten (G) wenigstens einer berechtigten Person oder wenigstens einem berechtigten Unter nehmen zugeordnet sind, insbesondere Eigentum wenigstens ei ner berechtigten Person oder wenigstens eines berechtigten Unternehmens darstellen, die insbesondere in einer Datenbank hinterlegte verfügbare Anzahl potentieller Treffer um eins reduziert wird.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass in Schritt a) eine Seriennummer und/oder ein Geräte- bzw. Maschinenzertifikat (K) und/oder ein Finger print und/oder eine Typenbezeichnung als Komponentenkennung abgefragt und/oder generiert wird.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Überprüfung in Schritt c) ein schließt, dass die Registrierungsstelle (RA) in einer Daten bank (D) , in der Komponentenkennungen (K) zusammen mit zuge hörigen berechtigten Personen und/oder Unternehmen, die be vorzugt Eigentümer zugehöriger Komponenten darstellen, ge speichert sind, nach wenigstens einem Eintrag für die zusam men mit dem Zertifikatsantrag (CSR) übermittelte wenigstens eine Komponentenkennung (K) sucht.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Zertifizierungsmodul (ZM) in Schritt b) die wenigstens eine Komponentenkennung (K) von der wenigstens einen Komponente (G) abfragt, wobei hierfür eine direkte Verbindung zwischen dem Zertifizierungsmodul (ZM) bzw. zwischen Hardware, auf welcher das Zertifizierungsmodul (ZM) implementiert ist, und der wenigstens einen Komponente (G) besteht bzw. hergestellt wird.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass sich das Zertifizierungsmodul (ZM) vor Ort bei der technischen Anlage befindet, insbesonde re auf Hardware implementiert ist, die einen Bestandteil der technischen Anlage und/oder eines Leitsystems einer solchen bildet und/oder sich in der gleichen Halle befindet wie die technische Anlage.
12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Zertifizierungsmodul (ZM) Bestandteil eines Engineering Systems (ES) der technischen Anlage oder mit einem Engineering System (ES) der technischen Anlage funktional verbunden ist.
13. System (S) zur Vergabe von öffentlich getrusteten Zerti fikaten (C) für Anlagenkomponenten (G) einer technischen An lage, umfassend ein Zertifizierungsmodul (ZM) und eine Re gistrierungsstelle (RA) ,
wobei das Zertifizierungsmodul (ZM) dazu ausgebildet und/oder eingerichtet ist, von wenigstens einer Anlagenkomponente (G) , die ein öffentlich getrustetes Zertifikat (C) erhalten soll, wenigstens eine bevorzugt eindeutige Komponentenkennung (K) abzufragen und/oder für wenigstens eine Anlagenkomponente (G) , die ein öffentlich getrustetes Zertifikat (C) erhalten soll, wenigstens eine bevorzugt eindeutige Komponentenkennung (K) zu generieren,
und die Registrierungsstelle (RA) dazu ausgebildet und/oder eingerichtet ist, anhand der wenigstens einen Komponentenken nung (K) zu überprüfen, ob die wenigstens eine zu der Kompo nentenkennung (K) gehörige Komponente (G) wenigstens einer berechtigten Person oder wenigstens einem berechtigten Unter nehmen zugeordnet ist, insbesondere Eigentum wenigstens einer berechtigten Person oder wenigstens eines berechtigten Unter- nehmens darstellt, und für den Fall, dass dem so ist, ein öf fentlich getrustetes Zertifikat (C) für die wenigstens eine Komponente (G) anzufordern,
und das Zertifizierungsmodul (ZM) dazu ausgebildet und/oder eingerichtet ist, das angeforderte öffentlich getrustete Zer tifikat (C) zu empfangen und bevorzugt in einem geschützten Bereich zu speichern.
14. System nach Anspruch 13, dadurch gekennzeichnet, dass das System (S) eine Datenbank (D) umfasst, in der Komponentenken nungen (K) zusammen mit zugehörigen berechtigten Personen und/oder Unternehmen, die bevorzugt Eigentümer zugehöriger Komponenten (G) darstellen, gespeichert sind, und die Regist rierungsstelle (RA) dazu ausgebildet und/oder eingerichtet ist, für die oder im Rahmen der Überprüfung, ob die wenigs tens eine zu der Komponentenkennung (K) gehörige Komponente (G) wenigstens einer berechtigten Person oder wenigstens ei nem berechtigten Unternehmen zugeordnet ist, in der Datenbank (D) nach wenigstens einem Eintrag für die zusammen mit dem Zertifikatsantrag (CSR) übermittelte Komponentenkennung (K) zu suchen.
15. Engineering- (ES) oder Leitsystem für eine technisch An lage umfassend ein Zertifizierungsmodul (ZM), das dazu ausge bildet und/oder eingerichtet ist,
- von wenigstens einer Anlagenkomponenten (G) , die ein öf fentlich getrustetes Zertifikat (C) erhalten soll, wenigs tens eine bevorzugt eindeutige Komponentenkennung (K) abzu fragen und/oder für wenigstens eine Anlagenkomponente (G) , die ein öffentlich getrustetes Zertifikat (C) erhalten soll, wenigstens eine bevorzugt eindeutige Komponentenken nung (K) zu generieren,
- die wenigstens eine abgefragte und/oder wenigstens eine ge nerierte Komponentenkennung (K) zusammen mit einem Zertifi katsantrag (CSR) für ein öffentlich getrustetes Zertifikat (C) für die wenigstens eine Komponente (G) an eine Regist rierungsstelle (RA) zu übermitteln, - ein öffentlich gefrustetes Zertifikat (C) für die Anlagen komponente zu empfangen und bevorzugt in einem geschützten Bereich zu speichern.
16. Technische Anlage, insbesondere Fertigungs- oder Prozess anlage, die wenigstens ein Engineering- (ES) oder Leitsystem nach Anspruch 15 umfasst.
EP20718202.3A 2019-04-29 2020-03-27 Verfahren und system zur vergabe von öffentlich getrusteten zertifikaten, engineering- oder leitsystem und technische anlage Pending EP3932005A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP19171566.3A EP3734902A1 (de) 2019-04-29 2019-04-29 Verfahren und system zur vergabe von öffentlich getrusteten zertifikaten, engineering- oder leitsystem und technische anlage
PCT/EP2020/058794 WO2020221528A1 (de) 2019-04-29 2020-03-27 Verfahren und system zur vergabe von öffentlich getrusteten zertifikaten, engineering- oder leitsystem und technische anlage

Publications (1)

Publication Number Publication Date
EP3932005A1 true EP3932005A1 (de) 2022-01-05

Family

ID=66397020

Family Applications (2)

Application Number Title Priority Date Filing Date
EP19171566.3A Withdrawn EP3734902A1 (de) 2019-04-29 2019-04-29 Verfahren und system zur vergabe von öffentlich getrusteten zertifikaten, engineering- oder leitsystem und technische anlage
EP20718202.3A Pending EP3932005A1 (de) 2019-04-29 2020-03-27 Verfahren und system zur vergabe von öffentlich getrusteten zertifikaten, engineering- oder leitsystem und technische anlage

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP19171566.3A Withdrawn EP3734902A1 (de) 2019-04-29 2019-04-29 Verfahren und system zur vergabe von öffentlich getrusteten zertifikaten, engineering- oder leitsystem und technische anlage

Country Status (4)

Country Link
US (1) US20220239641A1 (de)
EP (2) EP3734902A1 (de)
CN (1) CN113748641A (de)
WO (1) WO2020221528A1 (de)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6980660B1 (en) * 1999-05-21 2005-12-27 International Business Machines Corporation Method and apparatus for efficiently initializing mobile wireless devices
KR20160038091A (ko) * 2014-09-24 2016-04-07 현대자동차주식회사 Ｖ２ｘ 통신을 위한 ｃｓｒ 인증서 발급 방법 및 시스템
WO2016110601A1 (es) * 2015-01-05 2016-07-14 Ebiid,Products & Solutions, S.L. Procedimiento de generación de una identidad digital de un usuario de un dispositivo móvil, identidad digital de usuario, y procedimiento de autenticación usando dicha identidad digital de usuario
US11218465B2 (en) * 2017-01-29 2022-01-04 Beame.io Ltd. Establishing an AD-HOC secure connection between two electronic computing devices using a self-expiring locally transmitted information packet
US10749692B2 (en) * 2017-05-05 2020-08-18 Honeywell International Inc. Automated certificate enrollment for devices in industrial control systems or other systems

Also Published As

Publication number Publication date
US20220239641A1 (en) 2022-07-28
CN113748641A (zh) 2021-12-03
EP3734902A1 (de) 2020-11-04
WO2020221528A1 (de) 2020-11-05

Similar Documents

Publication Publication Date Title
EP3488555B1 (de) Gesichertes verarbeiten einer berechtigungsnachweisanfrage
EP3669498B1 (de) Verfahren und steuersystem zum steuern und/oder überwachen von geräten
DE102011081804B4 (de) Verfahren und System zum Bereitstellen von gerätespezifischen Betreiberdaten, welche an ein Authentisierungs-Credential gebunden werden, für ein Automatisierungsgerät einer Automatisierungsanlage
AT513782B1 (de) Vorrichtung und Verfahren zur Übermittlung von Daten
EP3673623A1 (de) Verfahren und steuersystem zum steuern und/oder überwachen von geräten
EP3605253B1 (de) Automatisierte public key infrastructure initialisierung
EP3763089B1 (de) Verfahren und steuersystem zum steuern und/oder überwachen von geräten
WO2019081434A1 (de) Verfahren und steuersystem zum steuern und/oder überwachen von geräten
EP3718263B1 (de) Verfahren und steuersystem zum steuern und/oder überwachen von geräten
EP4154070A1 (de) Digital-twin basierte prozesssteuerung in einem iot-netzwerk
EP3714575B1 (de) Verfahren und system zum steuern und/oder überwachen von geräten
EP3985532B1 (de) Zertifikatsmanagement für technische anlagen
WO2020221523A1 (de) Verfahren zur vergabe von zertifikaten, leitsystem, verwendung eines solchen, technische anlage, anlagenkomponente und verwendung eines identitätsproviders
EP3932005A1 (de) Verfahren und system zur vergabe von öffentlich getrusteten zertifikaten, engineering- oder leitsystem und technische anlage
WO2020207717A1 (de) Verfahren und steuersystem zum steuern einer ausführung von transaktionen
EP2333624A1 (de) Verfahren und Einrichtung zur Konfigurierung einer Komponente in einer industriellen Automatisierungsanordnung
WO2022022997A1 (de) Kanalbasierte kommunikation in einem iot-netzwerk
EP3993339B1 (de) Zertifikatsmanagement in einer technischen anlage
EP3681099A1 (de) Verfahren zum betreiben eines rechnersystems für eine automatisierungsanlage und/oder fertigungsanlage sowie rechnersystem
EP3537323A1 (de) Projektbezogenes zertifikatsmanagement
EP3953830B1 (de) Verfahren und system zum sicheren bereitstellen von daten eines gegenstands über dessen gesamten lebenszyklus
WO2018114101A1 (de) Verfahren zum überprüfen einer mandantenzuordnung, computerprogrammprodukt und automatisierungssystem mit feldgeräten
EP4032243A1 (de) System und verfahren zum manipulationssicheren verwalten von daten eines feldgeräts der automatisierungstechnik
EP3944108A1 (de) Revokation von zertifikaten in einer technischen anlage
WO2024046552A1 (de) Computer-implementiertes verfahren zum einrichten einer neuen komponente in einer technischen anlage und leitsystem für eine technische anlage

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210930

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)