Method and system, engineering system or control system and technical facility for issuing a certificate of public trust

Abstract

The invention relates to a method for issuing a publicly trusted certificate (C) for a facility component (G) of a technical facility, wherein a) an authentication module (ZM) queries at least one component identifier (K) from at least one facility component (G) which is to receive a publicly trusted certificate (C), b) the authentication module (ZM) transmits the at least one component identifier (K) together with a certificate application (CSR) for a publicly trusted certificate (C) to a registration authority (RA), c) the registration authority (RA) checks, based on the at least one component identifier (K), whether the at least one component (G) associated with the component identifier (K) is associated with at least one authorized individual or at least one authorized company, d) in the affirmative case, the registration authority (RA) requests a publicly trusted certificate (C) for the at least one component (G), e) the requested publicly trusted certificate (C) is created and transmitted to the authentication module (ZM). In addition, the invention relates to a system (S) for issuing a publicly trusted certificate (C) for a facility component (G) of a technical facility, an engineering system (ES) or a control system for a technical facility, and a technical facility.

Description

Technical Field

[0001] The invention relates to a method for issuing a publicly trusted certificate for a facility component of a technical facility. In addition, the invention relates to a system for issuing a publicly trusted certificate for a facility component of a technical facility, an engineering system or control system for a technical facility and a technical facility. Background Art

[0002] Digital certificates are used in the context of technical installations. In particular, if there are certificates used during operation, these are also called operating certificates. Certificates enable secure, uncompromised and trustworthy communication between different installation components, such as devices and / or applications. For example, the use of certificates enables the authentication of communication participants and communication integrity by cryptographic means.

[0003] In the context of the public key infrastructure of technical facilities, so-called registration authorities (English: registration authorities or abbreviated: RA) are used to receive certificate applications (so-called certificate signing requests or abbreviated CSR) and - in the case of approval / verification - forward these certificate applications to a certification authority (English: Certificate Authority or abbreviated CA). In this case, the RA is the entity that decides which certificate applications are approved / verified, and the CA is the entity that creates the certificates.

[0004] An installation component can apply for a certificate itself, which it needs, for example, to use different security protocols, such as TLS (Transport Layer Security) or OPC UA (OPC Unified Architecture). The installation component as a client or requester sends its certificate application to a registration authority (RA), which, upon approval / verification, forwards the application to a certification authority (CA), for example, located in the installation ("Onsite CA") or in a trust center ("Offsite CA" or "CA as a Service").

[0005] From a demand perspective, secure connections in web pages, such as HTTPS or Secure Web Sockets, are often essential. For this, certificates are required.

[0006] Particularly in industrial environments, separate private networks often exist, and the device (or the web server located on the device) is often not reachable from the public Internet.

[0007] However, especially in network environments there are very diverse environments in which not all participants (especially clients) can be controlled or accommodated in a managed infrastructure completely or in a cost-effective manner. In particular, for example, mobile terminals are often not part of the infrastructure (keyword BYOD, "Bring your own device").

[0008] From the applicant's point of view, it is worthwhile to be able to integrate all devices (clients as well as servers) into a common infrastructure. The certificate should not only be accepted by the controlled terminal device, in which it is stored as trusted, but should also be verifiable at any time by any other terminal device, for example a mobile terminal device. This makes it possible, for example, for an operator / user to display data, for example, of a control device of a technical installation, on a mobile terminal device (BYOD).

[0009] For the browser on the client end device, this requires that the certificate must be verifiable in the entire certificate chain up to a recognized trusted root certificate (TRC) (see, for example, the "Root CA Policy" of Google Chrome). The latter are a few certificates that are classified as trusted across browser systems and operating systems and do not have to be installed separately.

[0010] If verifiability of such a TRC cannot be given, functionality can be limited or even not provided due to lack of verifiability. This means that in the best case the user gets an error message which can at least be circumvented (where it is acknowledged that wanting to continue despite a check failure is a clear security risk and is not recommended), but either the functionality is simply suppressed by default (e.g. by the browser rejecting AJAX calls from the page or not displaying an embedded iframe).

[0011] To the best of the applicant's knowledge, obtaining a publicly trusted certificate for a closed facility is currently either prohibitively expensive or simply impossible.

[0012] Certificates are associated with Trust. Therefore, the issuing party must be able to verify and subsequently prove that the requester has control over the domain.

[0013] As far as the applicant is aware, one possibility for obtaining a publicly trusted certificate is to obtain such a certificate manually. To this end, the requester of the certificate must prove his identity and submit various documents that uniquely identify the requester and ensure that the requester is authorized / legally authorized to obtain a certificate for the desired domain. The requester then gets the certificate transferred and can install it in his domain together with its key material - usually also manually.

[0014] Another possibility is to use Lets-Encrypt (see, for example, https: / / letsencrypt.org / ). In this case, trust is created by the owner of the server having to state that he has control over the server and the domain connected to the server. However, the certification authority (CA) presupposes direct access to the network server, so that this solution cannot be used in closed networks and areas (LetsEncrypt is based on the ACME (Automated Certificate Management Environment) protocol). For example, this requirement cannot be met for control devices, such as SPSs of technical facilities with closed networks.

[0015] Authentication management protocols, such as the Certificate Management Protocol (CMP, see, for example, https: / / de.wikipedia.org / wiki / Certificate_Management_Protocol), do allow for the automated implementation of certificate requests, certificate generation and certificate distribution. However, this requires a complete infrastructure, which must first be established by the operator of the technical facility. Even if this effort is run for a closed network, publicly trusted certificates cannot be issued in this way, because an external CA cannot prove something that it cannot verify itself in a closed system.

[0016] Therefore, to the applicant's knowledge, in practice many users today only employ self-signed certificates, which have all of the above-mentioned disadvantages, because they circumvent the effort or cost of manually obtaining publicly trusted certificates, or because this may not be otherwise possible to implement in the factory so far. Summary of the invention

[0017] Based on the above, the object of the present invention is to create a possibility for issuing publicly trusted certificates for components of a technical installation with a separate, private network with reasonable effort.

[0018] The object is achieved by a method for issuing publicly trusted certificates for installation components of a technical installation, wherein

[0019] a) the authentication module queries at least one preferred unique component identifier from at least one component of the technical installation for which a publicly trusted certificate is to be obtained and / or generates at least one preferred unique component identifier for at least one component of the technical installation for which a publicly trusted certificate is to be obtained,

[0020] b) the authentication 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 of at least one component to a registration authority (RA),

[0021] c) a registration authority (RA) checks, based on at least one component identifier, whether at least one component associated with the component identifier is associated with at least one authorized person or at least one authorized company, which person or company is responsible for the at least one component,

[0022] d) In the affirmative case, the Registration Authority (RA) requests a publicly trusted certificate for at least one component, and

[0023] e) The requested publicly trusted certificate is created and transmitted to the authentication module and preferably stored in a protected area, in particular in the authentication module.

[0024] In other words, the present invention proposes to provide an authentication module, which can be used to uniquely identify a component that should obtain a publicly trusted certificate, or, in particular when the component has not yet been put into operation and the identifier of the component cannot (yet) be queried, the authentication module can be used to generate at least one preferred unique and / or temporary identifier for the component to be authenticated.

[0025] Subsequently, instead of the component, the authentication module contacts the central service and transmits to the central service a (corresponding) certificate application for a publicly trusted certificate for a preferred uniquely identified (multiple) component(s) or components uniquely identifiable based on the generated (multiple) identifiers together with the (multiple) identifiers.

[0026] Using the provided, preferably unique (multiple) identifiers queried or generated, the registration authority can then check whether the (corresponding) identified / identifiable component can be associated with a person or company who is responsible for the component, in particular the owner of the component. The person or company is preferably the customer who purchased the component. A component that is the responsibility of a person or company means in particular that the person or company has control over the component, which is preferably guaranteed by contract and / or the contract stipulates what consequences may arise in the event of a possible misuse of the requested certificate.

[0027] At least one component identifier can be, for example, a serial number and / or a machine certificate / equipment certificate and / or a fingerprint and / or a type name. Accordingly, in an improved solution of step a), a serial number and / or an equipment certificate or a machine certificate and / or a fingerprint and / or a type name is queried and / or generated as a component identifier.

[0028] An individual or company can (manually) guarantee by contract that the control requirements for the component are met. The existence of such a contractual guarantee can then be detected or identified or queried by a registration authority within the scope of an inspection.

[0029] It is also possible to access a database, for example a customer database, in order to check whether the component to be certified is associated with the responsible person / company.

[0030] Accordingly, in a further development it can be provided that the check in step c) comprises the registration authority searching a database for at least one entry for the component identifier transmitted with the certificate application, in which the component identifier is stored together with the associated authorized person and / or company, which is preferably the owner of the associated component. The associated component is understood here to be the component associated with the stored component identifier. It is preferably applicable that the authorized person / authorized company is responsible for storing the component of the identifier in the database, which is particularly preferably guaranteed by contract.

[0031] If such an entry is found in the database, then the certificate request (certificate application) for the component involved is preferably approved / verified. On the contrary, if such an entry is not found, the certificate application is rejected in an appropriate manner, and then the requested certificate is not created.

[0032] For example, the database can be provided via the so-called “Industrial Mall” of Siemens.

[0033] If a database is used, it is possible for this database to include own customer data and data of third-party suppliers, such as OEMs (Original Equipment Manufacturers).

[0034] In step e), the key material can be transmitted to the authentication module together with the publicly trusted certificate. The authentication module can preferably transmit the certificate to a protected memory of the installation component / industrial component in a protected manner against reading and modification. The installation component / industrial component itself can then preferably protect a network server or other aspects with the help of the certificate.

[0035] For example, compared with manually obtaining a certificate, the processing method according to the present invention satisfies the following aspects:

[0036] - The individual / company confirms in a legally binding manner that it is the owner of the component, for example by the individual / company agreeing that this applies to all purchased components and specifically stored in a database, or it is (definitely) known who the owner / responsible person is (legal guarantees can also be made within the scope of obtaining a certificate, for example in an engineering system).

[0037] - The (corresponding) component can be uniquely identified by means of the certification module, to which the requested certificate shall apply.

[0038] Furthermore, it is ensured by the authentication module that it is never possible for a person / company, in particular a customer, to directly access the certificate and any key material, but rather they can only be installed in a secure manner into a predetermined and associated target component.

[0039] This ensures that the certificate can only be installed on components with a legally responsible owner. This does not require that a registration authority and / or a certification authority have access to the component or a network server of such a component.

[0040] It should be noted that the method according to the present invention is applicable to both the initial (first) issuance of publicly trusted certificates and to certificate renewal (re-issuance). Therefore, the method for issuing certificates according to the present invention is a method for initially issuing and / or renewing publicly trusted certificates.

[0041] Accordingly, the certificate application can be an application for an initial application (Bootstrapping) or an application for an update (Update) of a certificate.

[0042] The authentication module is preferably located on-site at the technical facility, in particular in the same network as the technical facility. In particular, this is implemented on hardware that forms an integral part of the technical facility and / or the network of such a technical facility.

[0043] In a very particularly preferred embodiment, the authentication module is a component of an engineering system of the technical installation or is functionally connected to an engineering system of the technical installation.

[0044] Industrial engineering systems, also referred to as project engineering tools for industrial applications, can be used for the design and implementation of solutions and for the subsequent operation and / or management processes. Here, solutions are understood to be industrial solutions particularly for process industries and / or discrete industries.

[0045] The engineering of an automation project (e.g. for a facility) typically includes one or more of the following steps: determining the functionality required in the project, determining which components are needed to provide that functionality, associating the functionality and the actual physical location with the components in the facility, assigning communication structures to the components (e.g. which components are allowed to communicate with which other components and how they communicate, what is the actual purpose of the components), etc.

[0046] Automation projects are related to real projects, such as the construction of a new production line / processing line in a new or existing industrial facility or a new or existing process facility. Some of the many examples of implementing such automation projects are automobile manufacturing in the vehicle industry, electronics manufacturing, food and beverage product manufacturing, etc.

[0047] In this application, the engineering system is usually used to create one or more configurations of plant components / automation components within the scope of projects for industrial automation. Industrial automation projects can be, for example, factory automation projects, projects for process industry automation and all other automation projects in an industrial context.

[0048] Especially for use in the above-mentioned automation projects, facility components or automation components can be hardware components and / or software components or a combination of both. Facility components or automation components also include: programmable logic controllers (SPS), I / O modules, industrial communication devices, industrial network components, sensors, actuators, drives and other industrial devices often used in process industries or automation industries. Software components that share hardware with other components can also be configured via the engineering system.

[0049] The engineering system (also partly referred to as engineering tool) has very precise knowledge of the automation products in the installation. It thus knows the exact hardware (e.g. from the serial number) or the specific product (e.g. from the MLFB, i.e. the machine-readable product name), but is also able to uniquely identify components (e.g. devices) or make them identifiable (e.g. via permanently imprinted or securely installed machine or device certificates). Likewise, the engineering system usually already has the possibility to transfer data securely to the corresponding automation device (in terms of protection against counterfeiting and invisibility or unreadable by third parties).

[0050] It should be noted that, even though it is very advantageous to integrate the authentication module into the engineering system of the installation, this does not exclude that the authentication module is a stand-alone tool or stand-alone module, or forms part of another tool. Subsequently, there is preferably a functional connection to the engineering system. Thus, for example, if the installation component / industrial component is operated in a network that cannot be contacted from the outside and cannot itself communicate externally with other networks, the tool can also switch networks. In this case, it is a completely closed network.

[0051] The present invention provides several advantages: It is possible for an installation to obtain a certificate creation and deployment process that is integrated into the project and specifically tied to the customer contractual relationship.

[0052] In particular, the integration into the engineering provides for an extended, simpler and safer operation, for example with significantly fewer obstacles than if standardized protocols were integrated into each plant component / each product. The engineering system naturally knows the plant-specific access routes and distribution routes.

[0053] Support for offline engineering is possible, for example, this is beyond the control of the LetsEncrypt system, but is essential for engineering of technical infrastructure.

[0054] The creation of the CSR and / or the transmission of the CSR can be realized by means of a certification module which is preferably integrated into the engineering system, if necessary also before the actual device is available and installed.

[0055] The deployment of certificates and possibly key material can take place during the download or startup process, again preferably with the support of engineering.

[0056] Indirect offline scenarios are also possible (e.g. on a special SD card for a SIMATIC PLC or HW Dongle SiPlug).

[0057] A technical trust relationship can be achieved between a certification authority (CA) and an installation component, such as a terminal device, because the customer and the device actually acquired by the customer can be identified based on the component identifier (ie one or more unique characteristics).

[0058] Here, the necessary steps can be run automatically without manual intervention by the user or customer.

[0059] There is no infrastructure for certificate management in the component, in particular on-premises at the customer, but instead an authentication module, which is preferably part of an engineering system of the installation or is functionally connected to such an engineering system, obtains certificates from a preferably external CA.

[0060] Certificate acquisition can be provided as a service (Certificate as a Service, CaaS), for example, for customers who have already acquired facility components to be certified.

[0061] The authentication module can be a functional unit which can be implemented on suitable hardware, for example, by means of a software component. It can be possible to implement the authentication module by means of software which is located on the hardware of a certain / the engineering system of the technical installation. It is obviously also possible that the authentication module comprises independent "dedicated" hardware. Thus, in a preferred design, the authentication module or the hardware of the authentication module is functionally connected to a certain / the engineering system of the technical installation.

[0062] A registration authority of a technical installation is understood to be a functional entity which receives registration requests, such as certificate applications, from components of the technical installation, checks the registration requests and, in the case of success, forwards them in particular to a certification authority of the technical installation. In the present case, the registration authority is primarily provided for processing certificate applications of installation components of the technical installation. The registration authority can be a local registration authority which can communicate with a superior global registration authority which, in turn, can, for example, directly establish a connection with a certification authority of the technical installation. The registration authority can include a registration service or be provided by such a registration service.

[0063] According to the invention, the registration authority to which the authentication module transmits at least one component identifier together with the certificate application is constructed and / or designed to derive / check / verify, based on the at least one component identifier, in other words based on one or more unique characteristics, whether the (corresponding) component is associated with a person / company and the person / company is responsible for the component, and in particular whether a legally binding customer relationship exists for the (corresponding) component.

[0064] It is also possible that the registration authority determines / checks / verifies for which application the requested publicly trusted certificate is provided on at least one component. The registration authority is then designed and / or configured accordingly.

[0065] A technical facility is in particular a manufacturing facility or a process facility. It can be, for example, a facility from the process industry, i.e., for example, a facility from the chemical, pharmaceutical, petrochemical industry or a facility from the food and beverage industry. This also includes any facility from the production industry, for example, a factory producing vehicles or goods of all types. A technical facility suitable for carrying out the method according to the invention can also come from the field of energy production. Wind turbines, solar facilities or power plants for energy production are also included in the term technical facility.

[0066] Typically, the installation has a control system or at least one computer-aided module for controlling and regulating the running process or production, respectively.

[0067] The term "public key infrastructure" (PKI for short) relates to a security infrastructure for a technical installation that provides services for secure data exchange between communication partners of the technical installation. With the help of the public key infrastructure, certificates can be issued, distributed and checked.

[0068] A certificate is understood to be a digital data set that confirms certain characteristics (in this case, certain characteristics of a machine, device, application, etc.). The authenticity and integrity of the certificate can be verified by means of cryptographic methods. Publicly trusted certificates are particularly understood to be certificates that can be verified throughout the entire certificate chain up to a universally recognized trusted root certificate (TRC). Publicly trusted certificates can also be called publicly recognized certificates. Publicly trusted / recognized certificates are in particular those that are distributed by CA / browser forum members (see https: / / cabforum.org / ). Particularly preferably, the publicly trusted / recognized certificate requested / issued within the scope of the method according to the invention is an SSL (Secure Socket Layer) or TLS (Transport Layer Security) certificate.

[0069] The installation component can be, for example, a control device, such as a programmable logic controller (PLC), a device, in particular a field device, an application program, etc. In particular, the installation component is an automation component or an automation device.

[0070] At least one installation component preferably has at least one web server or serves as a web server.

[0071] At least one certificate application can be transmitted from the authentication module to the registration authority using a certificate management protocol. This can be a universal protocol that is often used in the context of certificate management of technical facilities, in particular control systems of technical facilities, such as the Certificate Management Protocol (CMP for short, see, for example, RFC4210 / 4211 (RFC: Request for Comments) of the Internet Engineering Task Force (IETF)). CMP can in particular be implemented or has been implemented via https. It should be emphasized that standard protocols can be used, but this is not necessary. The authentication module and the RA can also communicate with each other in a purely proprietary manner.

[0072] Within the scope of the method according to the invention, a number of variants can be supported, in particular:

[0073] Online Engineering: The component (or server) is installed in the facility. Here, the authentication module is able to read the signature, uniquely identify the component (and ensure that there is no other entity with the same signature) and securely transfer the data and the certificate to the component.

[0074] Offline engineering: A component (server) has not yet been installed in the facility, but can still be planned if necessary. For this purpose, the authentication module may first have to generate at least one component identifier (in other words, one or more unique features, such as a machine certificate) required for the target component. However, it is now already possible to request and create a publicly trusted certificate in advance and to keep it within the authentication module for the planned device. Later, at startup, the authentication module then preferably ensures that at least one preferably unique component identifier (in other words, unique feature) is actually present or can be introduced in a forgery-proof manner and then preferably introduced. If this has been ensured, the publicly trusted certificate can also be transmitted there.

[0075] Therefore, a further advantageous embodiment is characterized in that, for the case in which the component identifier is not requested by the authentication module in step a), in particular because the at least one component is not yet operational - offline scenario, the authentication module queries the at least one component for the at least one component before transmitting the publicly trusted certificate to the at least one component and / or to a storage device connected or connectable to the at least one component, and preferably transmits the queried component identifier to a registration authority. The queried component identifier can (subsequently) be transmitted to the registration authority. The registration authority can store the component identifier in a database.

[0076] Alternatively or additionally, it can be provided that the authentication module checks, before transmitting the publicly trusted certificate to at least one component and / or a storage device connected or connectable to at least one component, whether at least one component identifier generated by the authentication module in step b) can be stored / archived in the component in a forgery-proof manner.

[0077] Indirect offline situation: A special situation that exists in particular in automation, namely that sometimes the actual component is not provided with a configuration at all, but the agent is provided with a configuration. Thus, for example, an SD card or a (USB) dongle can obtain the complete configuration of the control device (e.g. SPS) during downloading, but the actual component is immediately replaced in the case of replacement. Here, therefore, the download to the actual component is only indirect. However, in this case, the agent, such as an SD card or a (USB) dongle, must be uniquely identified and the agent must be protected from unauthorized access - so the data in the protected area must not be easily read. The relevant / corresponding component can then extract the configuration from the agent, such as an SD card or a dongle. The certificate should preferably be encrypted and it should preferably be possible for the relevant / corresponding component to decrypt the certificate only when the configuration is read in.

[0078] The authentication module can advantageously (at least at any time) access the component to be authenticated or a storage device, such as an SD card or a dongle, which is represented as a proxy. This is particularly applicable when the authentication module is a component of an engineering system or is functionally connected to such an engineering system.

[0079] In particular, in the online case, a publicly trusted certificate (with accompanying material if necessary) can preferably be encrypted directly for the target component. This ensures that the certificate is universally protected and can only be decrypted there. In addition, each project in the engineering system can be provided with a customer-specific key, so that in the offline case a certification authority (CA) can protect the transmission at least up to the certification module. The material for a specific component, for example for a specific terminal device, can be encrypted again in the corresponding project. Universal protection is thus also possible.

[0080] It can be provided that, in the case where the check in step c) shows that a plurality of components associated with at least one component identifier are associated with at least one authorized individual or at least one authorized company, in particular with the ownership of at least one authorized individual or at least one authorized company, the available number of potential hits, which is stored in particular in the database, is reduced by one. For example, the database can in particular include entries according to which a user / individual / company has a certain number of automation components of a given type. After approval of the certificate application or after issuance of a certificate for such a component, the number is reduced by one. If the certificate is subsequently installed, the in particular unique component identifier is preferably restored, i.e. the component identifier is transmitted to the database and stored there. Subsequently, the certificate update should, as far as possible, no longer be carried out for such "general hits", but for specific identifiers.

[0081] Another advantageous embodiment of the method according to the invention is characterized in that in step d), the registration authority requests a publicly trusted certificate from a certification authority, in particular by the registration authority verifying the certificate request and / or forwarding the certificate request to the certification authority. The certification authority can then create or obtain the requested publicly trusted certificate for at least one component.

[0082] The authentication module also preferably transmits the publicly trusted certificate transmitted to the authentication module in step e) to at least one component and / or to a storage device connected to or connectable to at least one component. The storage device is preferably a "proxy", such as an SD card, a (USB) dongle or other storage medium, on which the configuration of the component is installed / can be installed.

[0083] Key material can be transmitted together with a publicly trusted certificate. Key material is in particular key material that is transmitted to an authentication module together with a certificate, in particular by a certification authority.

[0084] The publicly trusted certificate is preferably stored in a certificate of authenticity memory of the at least one component and / or a memory device connected or connectable to the at least one component.

[0085] In order to transfer a publicly trusted certificate from the authentication module to at least one component and / or to a storage device connected to or capable of being connected to at least one component, a direct connection can exist or be created between the authentication module or the hardware (on which the authentication module is implemented) and at least one component and / or the storage device connected to or capable of being connected to at least one component. "Directly" is here in particular understood to mean that the authentication module can communicate "directly" with the component. This preferably means that the authentication module is located in a network from which the component can be contacted and no intermediary is required. There may be a point-to-point connection (e.g. a serial cable connection, a USB cable, etc.) between the authentication module (or the hardware on which the authentication module is implemented) and at least one component. In particular, a direct wired or wireless connection can exist or be created.

[0086] Similar content can apply to querying at least one component identifier. It can therefore be provided that in step b), the authentication module queries at least one component identifier from at least one component, wherein for this purpose a direct connection exists or is created between the authentication module or the hardware on which the authentication module is implemented and the at least one component.

[0087] Another subject matter of the invention is a system for issuing publicly trusted certificates for installation components of a technical installation, the system comprising an authentication module and a registration authority,

[0088] The authentication module is constructed and / or designed to query at least one preferred unique component identifier from at least one installation component for which a publicly trusted certificate is to be obtained and / or to generate at least one preferred unique component identifier for at least one installation component for which a publicly trusted certificate is to be obtained,

[0089] and the registration authority is constructed and / or designed to check, based on the at least one component identifier, whether the at least one component associated with the component identifier is associated with at least one authorized individual or at least one authorized company, in particular associated with the ownership of the at least one authorized individual or at least one authorized company, and in the affirmative case, request a publicly trusted certificate for the at least one component,

[0090] Furthermore, the authentication module is designed and / or configured to receive the requested publicly trusted certificate and preferably store it in a protected area.

[0091] The system according to the invention is particularly suitable for carrying out the method according to the invention.

[0092] In an improved embodiment, the system according to the invention comprises a database in which component identifiers are stored together with the associated authorized individuals and / or companies, which are preferably the owners of the associated components, and a registration authority is constructed and / or designed to, for a check as to whether at least one component related to the component identifier is associated with at least one authorized individual or at least one authorized company or within the scope of this check, search in the database for at least one entry for at least one component identifier transmitted together with the certificate application.

[0093] The authentication module preferably forms a (local) "front end" or a (local) "front end" unit of the system or is a component of such a front end or such a front end unit. The registration authority - optionally together with the database and the authentication authority - is preferably part of the (central) "back end" or a central "back end" unit of the system. The authentication module is preferably located at or in a technical facility on site, while the registration service is preferably remote from the technical facility, for example in a computing center. In particular, the registration service can be contacted by a plurality of authentication modules, which can be located at / in different facilities, and the registration service can receive the certificate application together with the component identifier.

[0094] In addition to the registration authority - and optionally in addition to the database - the certification authority can be a further component of the "backend" / "backend" unit of the system. Alternatively or additionally, there can be an independent / external certification authority that trusts the registration authority of the system according to the invention. The independent / external certification authority can be provided by a certification authority such as VeriSign or other known certification authorities, which preferably have a trusted root certificate (TRC) .

[0095] The invention further relates to an engineering system or control system for a technical installation, the engineering system or control system comprising an authentication module, which is constructed and / or designed for:

[0096] - querying at least one preferred unique component identifier from at least one facility component that should receive a publicly trusted certificate and / or generating at least one preferred unique component identifier for at least one facility component that should receive a publicly trusted certificate,

[0097] - transmitting at least one queried and / or at least one generated component identifier together with a certificate request for a publicly trusted certificate of at least one component to a registration authority (RA),

[0098] - Publicly trusted certificates of plant components are received and preferably stored in a protected area.

[0099] The authentication module can include a checking unit and / or a deployment unit.

[0100] If a checking unit is present, it is preferably constructed and / or designed to query (in other words read) at least one preferably unique component identifier from at least one component that is to receive a publicly trusted certificate and / or to generate at least one preferably unique component identifier for at least one component that is to receive a publicly trusted certificate.

[0101] If a deployment unit is present, the deployment unit is preferably constructed and / or designed to transmit the created publicly trusted certificate to the (corresponding) component, i.e. install it on the component. The deployment unit is preferably constructed and / or designed to receive a publicly trusted certificate created by a certification authority so that it can then forward the certificate to the (corresponding) component.

[0102] Finally, the invention relates to a technical installation, in particular a production installation or a process installation. The technical installation according to the invention preferably comprises at least one engineering system or control system according to the invention.

[0103] In the scope of the processing method according to the invention, alternatively or additionally, gateway devices and / or edge devices can also be used. In particular, it can be provided that an authentication module is provided / implemented on the edge device. For example, the authentication module can be implemented as an application on the edge device / edge device. If an edge device is used, it is possible to request (certificate application), update and securely load publicly trusted certificates on devices in the local network of components, such as technical facilities, fully automatically, while the gateway device / edge device also allows access to the Internet and public infrastructure. The edge device is advantageously located (as the name implies) at the outer edge of a closed network and has two network access points / network adapters. Therefore, the edge device is particularly located in a closed internal network and in the public Internet. In contrast, devices or components in a closed network generally cannot access the Internet. This is particularly useful in the operation of automatic updates, because no engineering system is required and the authentication module is not used internally to obtain an identifier, so as to subsequently manually switch to the public Internet. BRIEF DESCRIPTION OF THE DRAWINGS

[0104] Other features and advantages of the present invention will become apparent from the following description of embodiments according to the present invention with reference to the accompanying drawings.

[0105] The drawing shows a purely schematic illustration of an exemplary embodiment of a system component G and of a system according to the invention for issuing publicly trusted certificates. DETAILED DESCRIPTION

[0106] In the example described here, the plant component G is provided by a programmable logic controller, SPS for short, and is a component of a technical plant, in particular a production plant or process plant, not shown in detail. The plant also includes, in a manner known per se, a plurality of sensors, which provide measured values ​​for the control device G, and actuators, which receive manipulated variable values ​​from the control device G. Thus, processes running in the plant can be monitored and influenced.

[0107] The control device G is connected in a manner known per se to the sensors and actuators and further installation components via an installation network. The installation network is a local, closed network and the control device G cannot be contacted from the outside via the Internet.

[0108] The control device G is characterized by a unique component identifier K, which is provided by a device certificate K in the exemplary embodiment described here.

[0109] In particular, it is thus possible for the user to also view the data of the control device G to which the certificate is to be issued on the mobile terminal.

[0110] In the case of a browser on a client terminal device, for this purpose the certificate must be verifiable in the entire certificate chain up to a universally recognized trusted root certificate (TRC) (see, for example, the "Root CA Policy" of Google Chrome). This certificate is one of the few that is classified as trustworthy across browsers and operating systems and does not have to be installed separately.

[0111] The control device G or a network server on the control device is to receive certificates that can be verified up to a trusted root certificate TRC, which is also referred to as a publicly trusted certificate C.

[0112] The control device G has a forgery-proof certificate repository CS, which is used in a manner known per se to securely store or store digital certificates. Such publicly trusted certificates C can be stored in the certificate repository CS.

[0113] In order to be able to issue a publicly recognized (trusted) certificate C, the CA must be able to ensure that the person or company requesting the certificate actually has control and / or responsibility for the component or the server implemented on the component and the domain pointing to the component. According to the prior art, this can be ensured via the contactability of the corresponding component / corresponding server - however, this is not provided in industrial facilities.

[0114] The system S according to the invention is therefore provided for issuing a publicly trusted certificate C for an installation component G of a technical installation, which can be used to obtain such a certificate C for a control device G and store it therein (also referred to as “deploy”).

[0115] The embodiment of the system S according to the invention shown in the figures comprises an authentication module ZM, which is a "front-end" unit or "front-end" component of the system 1 and is located on site at or within the technical facility. The authentication module ZM is currently integrated into the engineering system ES of the technical facility. It is specifically a functional unit or a functional module implemented by software on the hardware of the engineering system ES. The engineering system forms an integral part of the illustrated embodiment of the system S according to the invention for issuing publicly trusted certificates. The engineering system ES can be run on standard hardware, for example on a conventional PC or industrial PC.

[0116] It should be noted that, as an alternative to the authentication module ZM being integrated into the engineering system S of the installation, as in the example shown, the authentication module can also be a separate tool or a separate module or be part of another tool. A functional connection is then advantageously present between the engineering system ES and the authentication module ZM. The authentication module ZM can also be implemented on an edge device which is located at the outer edge of the closed installation network and has two network access points / network adapters, so that the edge device is located both in the closed internal installation network and in the public Internet.

[0117] The engineering system ES has very precise knowledge of the automation products in the technical installation. It therefore knows the exact hardware (e.g. from the serial number) or the specific product (e.g. from the MLFB), but can also uniquely identify or can uniquely identify components, such as control devices G (e.g. via a machine or device certificate that is permanently burned in or can be securely installed). Likewise, the engineering system ES generally always has the possibility to transfer data securely to the corresponding component, such as the automation device (in terms of protection against counterfeiting and invisibility or unreadable by third parties).

[0118] In addition to the engineering system ES with the authentication module ZM, the system S according to the invention also comprises a backend or backend unit BE with a registration authority RA, a database D and a certification authority CA. The backend or backend unit BE is not arranged on site at the facility, but is located, for example, in a computing center a few kilometers or several kilometers away from the facility. Communication between the authentication module ZM and the backend BE can be achieved via the public Internet.

[0119] Compared to the back end BE, the engineering system ES with the authentication module ZM and the control device G is located on site at or within the technical facility, specifically forming a component of the technical facility, as indicated in the figure by the arc-shaped brackets at the edge, which group the components on site together.

[0120] The authentication module ZM is designed to communicate with a component G of the installation.

[0121] The authentication module ZM comprises a checking unit IE which is designed to preferably query (in other words read) a unique component identifier K from a component G which is to receive a publicly trusted certificate C and to preferably generate a unique component identifier K for the component G which is to receive a publicly trusted certificate C. This query or “probing” is indicated in the figure by an arrow pointing from the checking unit IE to the device certificate which forms the component identifier K.

[0122] The checking unit IE is furthermore designed to transmit the queried and / or generated component identifier K to a registration authority RA together with a certificate application CSR for a publicly trusted certificate C for the respective component G. This transmission is indicated in the figure by an arrow from the checking unit IE to the registration authority RA, except that a certificate application CSR for the control device G together with the device certificate K of the control device G is shown purely schematically as an example.

[0123] Furthermore, the authentication module ZM has a deployment unit DE, which is designed to transfer a publicly trusted certificate C to the (corresponding) component G, i.e. to install it on the component. The deployment unit is designed to receive a publicly trusted certificate C created or acquired by a certification authority CA and subsequently forward it to the (corresponding) component G. This is indicated in the figure by arrows pointing from the certification authority CA to the deployment unit DE and from the deployment unit to the certificate store CS of the control device G, and otherwise the certificates C are shown in each case purely schematically.

[0124] The registration authority RA is designed to check, based on at least one component identifier K, whether at least one component, in particular a control device G, associated with the component identifier K is associated with at least one authorized person or at least one authorized company, in particular is associated with the ownership of at least one authorized person or at least one authorized company, and in the affirmative case to request a publicly trusted certificate C of the at least one component G. The registration authority RA can verify the legally binding customer association based on the transmitted unique component identity K.

[0125] With the illustrated exemplary embodiment of the system S according to the invention, an exemplary embodiment of the method according to the invention for issuing a publicly trusted certificate C for an installation component G of a technical installation can be carried out.

[0126] In this case, in a first step, the authentication module ZM queries the control device G for which a publicly trusted certificate is to be obtained for at least one preferably unique component identifier, in the present case a device certificate K. The authentication module ZM, which is currently integrated into the engineering system of the installation, has direct access to the control device G, so that this query can be carried out without problems. The engineering system G is a participant in the closed installation network, so that the engineering system - and thus the integrated authentication module ZM - has access to the control device G.

[0127] Alternatively or additionally, in addition to querying / reading out the at least one component identifier K, the authentication module ZM can also generate at least one preferably unique component identifier for the control device G which is to receive a publicly trusted certificate, in the present case a (possibly temporary) device certificate.

[0128] This is particularly advantageous when at least one component, such as a control device G, has not yet been put into operation and the control device may still be planned. In other words, offline engineering or pre-engineering is also supported. This also makes it unnecessary for the engineering system ES to be (yet) in the facility network. By generating at least one unique identifier K by the authentication module ZM, the component can be uniquely identified. Subsequently, a publicly trusted certificate C can already be requested and generated in advance and retained internally in the authentication module ZM for the planned component G. Later, at startup, the authentication module ZM then preferably ensures that at least one component identifier K can actually exist or be introduced in a forgery-proof manner. If this has been ensured, the publicly trusted certificate C can be transferred there.

[0129] After querying and / or generating at least one component identifier, in this case the queried device certificate K, the authentication module ZM transmits this device certificate together with a certificate request CSR for a publicly trusted certificate C of the control device G to a registration authority RA.

[0130] In this case, a certificate request CSR can be created or has been created by the authentication module ZM or by the control device G, which the authentication module ZM transmits to the registration authority RA.

[0131] The registration authority RA then checks, based on the device certificate K, whether at least one control device G associated with the component identifier K is associated with at least one authorized person or at least one authorized company who is responsible for the control device. This check is performed in the illustrated exemplary embodiment by the registration authority RA searching for at least one entry for the device certificate K for the component identifier transmitted with the certificate application CSR, in the present case the control device G, in a database D in which the component identifier K, in particular the device certificate K, is stored together with the associated authorized person and / or company who is the owner of the component G associated with the component identifier K.

[0132] If an entry for the component identifier K transmitted with the certificate application CSR is found in the database, the certificate application CSR is approved / validated by the registration authority RA.

[0133] It should be noted that such an entry is preferably created in the database after the customer has purchased the control device G and has thus become the owner. Via a search or query in the database D, it can therefore be checked whether the control device G is owned by an authorized customer.

[0134] It should also be noted that it is possible that there are a plurality of structurally identical components, for example control devices G, which are associated with, in particular related to, an individual or a company according to the database D. If this is the case, the certificate application CSR is approved and the number of potential hits, i.e. the number of structurally identical components G, is reduced by one in the database.

[0135] In the next step, the certificate application CSR is forwarded to the certification authority CA, in particular by the registration authority, and the registration authority RA requests a publicly trusted certificate C from the certification authority CA.

[0136] The certification authority CA then creates or obtains the requested publicly trusted certificate C for the control device G. Here, in the described example, the certification authority CA, which is represented as part of the backend BE, contacts a further, central certification authority zCA, which has a trusted root certificate TRC. Since the zCA has a trust relationship with the CA, the latter can directly execute the CSR.

[0137] The certificate C is created by or in the zCA or registration authority CA of the backend BE.

[0138] The certificate C is forwarded together with the associated key material to the deployment unit DE of the authentication module ZM and is stored there or at another location in the engineering system Es in a protected area which cannot be read or altered from the outside.

[0139] Furthermore, the certificate C and the associated key material are “deployed” by the deployment unit, ie introduced into the control device G, specifically securely stored in the certificate store CS. This is again indicated in FIG. 1 by corresponding arrows.

[0140] In the embodiment shown, the certificate C (which can also be called a customer certificate or in English customer certificate) points to the intermediate certificate zC of the CA, which in turn points to the trusted root certificate TRC of the zCA. In the figure, this certificate chain is represented by an arrow with a dashed line. It can also be said that this arrow represents "trust", that is, trust between institutions or certificates. As can be seen, TRC is the end of the certificate chain. The (customer) certificate C in component G must be valid throughout the chain up to the TRC of the zCA.

[0141] It should be noted that the central certification authority zCA can, but does not have to, be set up and contacted via the CA. As an alternative to the embodiment shown in the figure, it is also possible for the CA to directly issue the certificate C without relying on external cooperation from other CAs. This is especially true if the CA has valid key material.

[0142] If the ES uses a temporary, unused, but generated identifier K, the unique identifier K is currently queried from the component G and transmitted back to the back end BE. There, the temporary identifier can now be replaced with the actual identifier. (If the ES creates the unique identifier K in advance and can introduce it into the component G, the transmission back is omitted or another identifier, such as a serial number, is passed for the correct association in the database D.)

[0143] It should also be noted that in case the RA cannot find an entry in the database for the component identifier K transmitted with the CSR, the application CSR is rejected and the certificate C will not be created.

[0144] The Engineering System ES with the certification module ZM supports the following three variants:

[0145] - Online Engineering: The component / server is already installed in the facility. Here the ES is able to read the signature, uniquely identify component G (and ensure that no other entity with the same signature exists) and securely transfer the data to component G along with the certificate C.

[0146] - Offline engineering: The component / server has not yet been installed in the facility and can still be planned if necessary. For this purpose, the engineering system ES may first create the unique features (at least one component identifier K) required for the target component G (e.g. a machine certificate). However, the certificate C can already be requested and created in advance, but is kept internally in the engineering system ES, specifically in the authentication module ZM, for the planned component G. At startup, the ES then ensures that the unique features are actually present or can be introduced in a forgery-proof manner. If this has been ensured, the already reserved certificate C can also be transferred there.

[0147] - Indirect offline case: There are special cases in automation, namely that sometimes the actual component G is not provided with a configuration at all, but a proxy, such as an SD card or a (USB) dongle, is provided with the configuration. Thus, for example, an SD card / dongle can obtain the complete configuration for the SPS G during downloading, but the actual control device G is immediately replaced in the case of replacement. Therefore, the download to the actual device G is only indirect here. However, in this case, the proxy, i.e. the card / dongle, must be uniquely identified and must be protected from unauthorized access - so that the data in the protected area of ​​the card or the dongle cannot be easily read.

[0148] In all three cases, the engineering system ES has access to the component G to be verified at least at a certain point in time.

[0149] In the online case, the certificate C with the accompanying material can be encrypted directly for the target component G. This ensures that the certificate C is universally protected and can only be decrypted there. In addition, each project in the engineering system ES can be provided with a (customer) specific key, so that in the offline case the CA can protect the transmission at least up to the ES. In the respective project, the material for the specific terminal device G can be encrypted again. In this way, universal protection can also be achieved.

[0150] It should be noted that the engineering system ES represents an embodiment of an engineering system according to the invention for a technical installation or an embodiment of an engineering system according to the invention for a technical installation, wherein the authentication module ZM is integrated into the engineering system or forms a component of the engineering system.

[0151] Furthermore, a technical installation of which the control device G and the engineering system ES form a component part is an exemplary embodiment of a technical installation according to the invention.

[0152] Although the present invention has been further illustrated and described in detail by preferred embodiments, the present invention is not limited to the disclosed examples and other variations can be derived therefrom by those skilled in the art without departing from the scope of protection of the present invention.

[0153] It goes without saying that even if the embodiments according to the invention have been explained above with the aid of a component of a technical installation, in particular a component of a control device G, it is self-evident that a publicly trusted certificate C can be requested and, if necessary, created in a corresponding manner for any number of other components and transmitted to the component. In this case, the authentication module ZM or the system S according to the invention can be used for a plurality of components of a technical installation (or a plurality of technical installations).

[0154] In particular, the backend BE of the system according to the invention can also be represented as a control center, which communicates with multiple authentication modules ZM and, upon request of multiple authentication modules ZM (if necessary from different facilities), creates a publicly trusted certificate C and transmits it to multiple authentication modules ZM.

Claims

1. A method for issuing a publicly trusted certificate (C) for a programmable logic controller (G) of a technical installation, wherein a) the authentication module (ZM) queries at least one unique component identifier (K) from at least one programmable logic controller (G) for which a publicly trusted certificate (C) is to be obtained and / or generates at least one unique component identifier (K) for at least one programmable logic controller (G) for which a publicly trusted certificate (C) is to be obtained, wherein: The authentication module (ZM) is a component of an engineering system (ES) of the technical installation or is functionally connected to the engineering system (ES) of the technical installation, b) the authentication module (ZM) transmits at least one queried and / or at least one generated component identifier (K) together with a certificate request (CSR) for a publicly trusted certificate (C) of at least one programmable logic controller (G) to a registration authority (RA), c) the registration authority (RA) checks, based on at least one of the component identifiers (K), whether at least one of the programmable logic controllers (G) associated with the component identifier (K) is associated with at least one authorized individual or at least one authorized company, the individual or the company being responsible for the at least one of the programmable logic controllers (G), d) in the affirmative case, said registration authority (RA) requests a publicly trusted certificate (C) for at least one of said programmable logic controllers (G), e) Creating the requested publicly trusted certificate (C) and transmitting the requested publicly trusted certificate to the authentication module (ZM) and storing in a protected area of ​​the authentication module (ZM).

2. The method according to claim 1, characterized in that In step d), the certificate application (CSR) is verified by the registration authority and / or forwarded to the certification authority (CA), the registration authority (RA) requests the publicly trusted certificate (C) from the certification authority (CA), and the certification authority (CA) creates or obtains the requested publicly trusted certificate (C) for at least one of the programmable logic controllers (G).

3. The method according to claim 1, characterized in that The authentication module (ZM) transmits the publicly trusted certificate (C) to at least one of the programmable logic controllers (G) or to a storage device connected to or capable of being connected to at least one of the programmable logic controllers (G), wherein the publicly trusted certificate (C) is stored in an anti-counterfeiting certificate memory (CS) of at least one of the programmable logic controllers (G) or of the storage device connected to or capable of being connected to at least one of the programmable logic controllers (G).

4. The method according to claim 3, characterized in that In order to transmit the publicly trusted certificate (C) from the authentication module (ZM) to at least one of the programmable logic controllers (G) and / or to the storage device connected to or capable of being connected to at least one of the programmable logic controllers (G), a direct connection exists or is established between the authentication module (ZM) or the hardware and at least one of the programmable logic controllers (G) and / or the storage device connected to or capable of being connected to at least one of the programmable logic controllers (G), and the authentication module (ZM) is implemented on the hardware.

5. The method according to claim 3 or 4, characterized in that: In the case where the authentication module (ZM) does not query the component identifier (K) in step a), the authentication module (ZM) queries at least one component identifier (K) from at least one programmable logic controller (G) before transmitting the publicly trusted certificate (C) to at least one programmable logic controller (G), and transmits the queried component identifier (K) to the registration authority (RA).

6. The method according to any one of claims 1 to 4, characterized in that The certificate request (CSR) which the authentication module (ZM) transmits to the registration authority (RA) in step b) is created by the authentication module (ZM) or by at least one of the programmable logic controllers (G).

7. The method according to any one of claims 1 to 4, characterized in that If the check in step c) reveals that a plurality of programmable logic controllers (G) associated with at least one of the component identifiers (K) are associated with at least one authorized individual or at least one authorized company, the available number of potential hits stored in the database is reduced by one.

8. The method according to any one of claims 1 to 4, characterized in that In step a), a serial number and / or a device certificate or machine certificate (K) and / or a fingerprint and / or a model name is queried and / or generated as a component identifier.

9. The method according to any one of claims 1 to 4, characterized in that The check in step c) comprises: the registration authority (RA) searches for at least one entry for at least one component identifier (K) transmitted with the certificate application (CSR) in a database (D), in which the component identifier (K) is stored together with the associated authorized person and / or company.

10. The method according to any one of claims 1 to 4, characterized in that In step b), the authentication module (ZM) queries at least one of the component identifiers (K) from at least one of the programmable logic controllers (G), wherein for this purpose a direct connection exists or is established between the authentication module (ZM) or the hardware on which the authentication module (ZM) is implemented and at least one of the programmable logic controllers (G).

11. The method according to any one of claims 1 to 4, characterized in that The authentication module (ZM) is located on site at the technical installation, the authentication module being implemented on hardware which forms a component of the technical installation and / or of a control system of such a technical installation and / or is located in the same plant as the technical installation.

12. A system (S) for issuing a publicly trusted certificate (C) for a programmable logic controller (G) of a technical installation, the system comprising an authentication module (ZM) and a registration authority (RA), wherein: The authentication module (ZM) is constructed and / or designed to retrieve at least one unique component identifier (K) from at least one programmable logic controller (G) to which a publicly trusted certificate (C) is to be obtained and / or to generate at least one unique component identifier (K) for at least one programmable logic controller (G) to which a publicly trusted certificate (C) is to be obtained, wherein the authentication module (ZM) is a component of an engineering system (ES) of the technical installation or is functionally connected to the engineering system (ES) of the technical installation, The registration authority (RA) is constructed and / or designed to check, based on at least one component identifier (K), whether at least one programmable logic controller (G) associated with the component identifier (K) is associated with at least one authorized individual or at least one authorized company and, in the affirmative case, to request a publicly trusted certificate (C) for at least one programmable logic controller (G), The authentication module (ZM) is designed and / or configured to receive the requested publicly trusted certificate (C) and to store it in a protected area.

13. The system according to claim 12, characterized in that The system (S) comprises a database (D) in which component identifiers (K) are stored together with the associated authorized individuals and / or companies, and the registration authority (RA) is constructed and / or designed to search in the database (D) for at least one entry for the component identifier (K) transmitted together with a certificate application (CSR) for or within the scope of checking whether at least one of the programmable logic controllers (G) related to the component identifier (K) is associated with at least one authorized individual or at least one authorized company.

14. An engineering system (ES) or control system for a technical installation, comprising an authentication module (ZM), which is constructed and / or designed for: - querying at least one unique component identifier (K) from at least one programmable logic controller (G) that should obtain a publicly trusted certificate (C) and / or generating at least one unique component identifier (K) for at least one programmable logic controller (G) that should obtain a publicly trusted certificate (C), wherein, The authentication module (ZM) is a component of an engineering system (ES) of the technical installation or is functionally connected to the engineering system (ES) of the technical installation, - transmitting at least one queried and / or at least one generated component identifier (K) together with a certificate request (CSR) for a publicly trusted certificate (C) of at least one programmable logic controller (G) to a registration authority (RA), - A publicly trusted certificate (C) of the programmable logic controller is received and stored in a protected area.

15. A technical installation comprising at least one engineering system (ES) or control system according to claim 14.

Images