Authenticating a communication partner at a device

Abstract

A method for authenticating a communication partner (ST) at a device, wherein in addition to a physical device implementation (FD1) there is at least one virtual device implementation (TD-FD1) assigned to the device, the method having the following steps: - receiving (S1) an access right of a communication partner (ST) in a first device implementation of the two device implementations, - checking (S2) the access right by the first device implementation, and - providing (S3) a right certificate (AC) from the first device implementation to the communication partner (ST) if the access right is considered permissible, and - allowing (S4) an access to a second device implementation of the two device implementations by the communication partner (ST) by means of the right certificate (AC).

Description

Technical Field

[0001] The present invention relates to a method for authenticating a communication partner at a device, wherein in addition to a physical device implementation, there is at least one virtual device implementation assigned to the device. Background Technology

[0002] Access to devices, such as field devices, control devices, and Internet of Things (IoT) devices, via network connections must be authenticated to prevent unauthorized access. In industrial environments, access can be made not only through other devices in the automation system but also, for example, through service technicians who access the devices via a web-based local service interface or via remote maintenance access.

[0003] In industrial environments, the concept of digital twins (also known as Digital Twins or Administration Shells) is playing an increasingly important role. Here, digital twins provide a virtual representation of real-world objects.

[0004] The publication SIEMENS AG et al., “Digital-Twin-Zertifikat” (PRIOR ART PUBLISHING GMBH, PRIOR ART PUBLISHING GMBH, MANFRED-VON-RICHTHOFEN-STR. 9, 12101 BERLIN GERMANY, Bd. www.priorartregister.com, February 21, 2019, pp. 1-5, XP007022409), describes a digital twin certificate assigned not only to a physical object but also to its digital twin. The digital twin certificate contains two public key entries assigned to the physical object or its digital twin, as well as a link (URL) to the digital twin. The physical object uses the digital twin certificate for authentication with a verifier. The verifier can then decrypt the encrypted data transmitted by the digital twin using the second public key and thus access the data.

[0005] WO 2019 / 243429 A1 discloses a method for a client device to securely access cloud services on a cloud server, wherein the access is provided through an application on a third-party server.

[0006] Establishing and managing access permissions for service technicians or other communication partners, as well as establishing and managing corresponding verification data, is costly. Therefore, information such as passwords, public key certificates, or even authorization information must be established and managed in user databases. Furthermore, in industrial environments, communication networks are often isolated from external communication networks, making it impossible to use central security services, such as directory services or authentication servers.

[0007] In addition, such devices typically have low computing power or are powered by batteries, making it necessary to avoid costly queries or operations in such situations. Summary of the Invention

[0008] Therefore, the objective of this invention is to design access authentication for such devices in a manner that is as energy-efficient and capacity-saving as possible, while still ensuring sufficient protection and flexible access possibilities.

[0009] This task is accomplished by the features described in the independent claim. Advantageous improvements of the invention are shown in the dependent claims.

[0010] According to a first aspect, the present invention relates to a method for authenticating a communication partner at a device, wherein in addition to a physical device implementation, there is at least one virtual device implementation assigned to the device, the method comprising the following steps:

[0011] - In the first device implementation of the two device implementations, access permissions to the communication partner are received.

[0012] Access permissions are verified through the first device, and

[0013] If the access permission is deemed permitted, then the first device implementation provides the communication partner with a certificate of authorization (Berechtigungsnachweis) for accessing the second device implementation through the communication partner, and

[0014] - Allows access to the second device implementation of the two device implementations via the communication partner using the permission certificate.

[0015] This enables simplified access for the communication partner to the second device implementation. If the second device implementation receives authorization from the communication partner, it allows access without further verification or with a reduced scope of verification. This allows for the division of tasks, such as parameter verification, between the two device implementations, thereby reducing the burden on each individual device implementation. Therefore, it is not necessary for all parameters to be verified or information about them to be available and managed on both device implementations. Here, the communication partner can transfer access permissions either to the physical device implementation or to the virtual device implementation. If the physical device implementation receives the access permission, it is the first device implementation and correspondingly, the virtual device implementation is the second device implementation. Conversely, if the access permission is sent from the communication partner to the virtual device implementation and received there, the virtual device implementation is the first device implementation. After successful verification, the virtual device implementation provides authorization to the communication partner, which allows access to the physical device implementation, which then represents the second device implementation. Access permissions can be, for example, passwords, access codes, access tokens, biometric authentication information, or cryptographic authentication information using secret / public cryptographic keys or digital certificates containing public keys.

[0016] In an advantageous implementation, the authorization certificate is an access authorization certificate used for the communication partner to perform access authentication at the second device implementation and / or an access permission certificate used to grant the communication partner access to the second device implementation.

[0017] Therefore, the communication partner can authenticate the obtained permission certificate at the second device implementation / or can verify or grant access rights there, for example, according to different security levels of access rights.

[0018] In one advantageous implementation, the validity of the authorization proof is time-limited.

[0019] This reduces the abuse of authentication credentials. The time limit can be, for example, a restricted validity period or a pre-defined time interval within which the authentication credentials are valid. This limits when access authentication for the second device implementation can be performed. After the pre-defined validity period, the communication partner is not allowed to further access the second device implementation. On the other hand, the time-limited validity of the authentication credentials limits the maximum duration for which an established connection can remain active.

[0020] In one advantageous implementation, the number of times access to the second device can be achieved by means of authorization is limited.

[0021] For example, a permission certificate can be used only once, such as to establish a connection with the second device implementation only once. This allows for flexible restrictions on the use of permission certificates for the second device implementation, and thus prevents unintended and unrestricted use of permission certificates by the second device implementation. To this end, the second device implementation can add the used permission certificates to a list of used permission certificates. This allows for the identification of reuse of already used permission certificates and the rejection of those certificates.

[0022] According to the present invention, if the communication connection between the first device and the communication partner is terminated, the authorization certificate is revoked or not updated.

[0023] This allows the connection of a communication partner to be coupled to two device implementations. Therefore, access to the second device implementation is only possible if access to the first device implementation also exists.

[0024] In an advantageous implementation, the authorization certificate is a digital certificate, a cryptographic key, or an access token.

[0025] Digital certificates can be, for example, certificates or attribute certificates containing a public key according to a public key infrastructure method. Such certificates are structured, for example, according to the X.509 standard and contain a public key using an asymmetric cryptographic method. Authorization credentials can be cryptographic keys, particularly keys using a symmetric cryptographic method. If the authorization credentials are access tokens, such as tokens according to the OAuth (Open Authorization) or JSON (JavaScript Object Notation) networks or SAML (Security Assertion Markup Language) standards, then information about authorized access to, for example, protected resources, and here particularly to resources in a second device implementation, is provided. By using these known data structures, only minor changes to integrate these known structures are necessary.

[0026] In one advantageous implementation, the authorization verification includes at least one of the following: an identifier of the communication partner's certificate, authorization information of the communication partner, time and / or geographical restrictions on access to the communication partner, restrictions on available communication media, restrictions on available communication protocols, information about the security status of the communication partner, and an identity verification value for the authorization verification.

[0027] Information regarding the security status of a communication partner can indicate whether the partner's configuration and / or firmware / software status are permissible. This prevents potentially manipulated devices from being used for access.

[0028] Therefore, a large amount of additional information can be transmitted from the first device implementation to the second device implementation through authorization verification, and the information collected in the first device implementation and the verification results can be communicated to the second device implementation. Communication between the first and second device implementations is also possible, and is particularly meaningful for transmitting information about the authentication that has occurred.

[0029] In an advantageous implementation, the authorization certificate is transmitted from the first device to the communication partner and / or from the communication partner to the second device when a secure communication connection is established.

[0030] For example, when establishing a communication connection under the Transport Layer Security (TLS) protocol, authentication credentials can be transmitted from the first device to the communication partner during the TLS handshake. Therefore, authentication credentials are ready for the communication partner at an early point in time, and access permissions can be considered at that point.

[0031] In an advantageous implementation, the authorization certificate is transmitted from the first device to the communication partner and / or from the communication partner to the second device via an authenticated existing communication connection.

[0032] This can be transmitted, for example, in the header portion of a connection according to the Hypertext Transfer Protocol (HTTP). Here, each combination of the type of authorization certificate transmission is possible—either at connection establishment or over an authenticated existing communication connection for two communication connections, specifically for a first communication connection between a first device implementation and a communication partner, and for a second communication connection between the communication partner and a second device implementation. For example, authorization certificates can be transmitted from the first device implementation to the communication partner at the establishment of a secure communication connection, while authorization certificates can be transmitted between the communication partner and the second device implementation via an authenticated existing communication connection.

[0033] In an advantageous implementation, the address information implemented by the second device is additionally provided to the communication partner from the implementation of the first device.

[0034] This makes it easy for the communication partner to correctly address the second device implementation.

[0035] In an advantageous implementation, when verifying access permissions via the first device, the integrity and / or permissibility of the current configuration of the communication partner are verified.

[0036] Here, for example, it can be verified whether the firmware / software installed on the communication partner is valid and permitted, and whether the so-called patch level, i.e., the firmware or software upgrade status, is currently in place. Furthermore, it can be verified whether the virus scanner is active and / or whether a current virus pattern exists. This is often referred to as "zero-trust access." Because these checks are typically costly, it is advantageous for the first device implementation to perform these integrity checks on the communication partner during connection establishment. The second device implementation can then verify the authorization certificate issued by the first device implementation: the integrity of the communication partner has been successfully verified. The first device implementation can encode the determined and verified configuration of the communication partner in a password-protected manner, allowing the second device implementation to verify the information content-wise without having to collect and evaluate the information itself again.

[0037] In one advantageous implementation, the first device transmits information about the device's configuration to a communication partner.

[0038] This enables less verification overhead for communication partners. If a communication partner has already verified the information regarding the configuration of the first device through the first device implementation and classified it as permitted, the communication partner uses the provided permission credentials to access the second device implementation without re-verifying the information regarding the device configuration. Since the physical device and its digital twin are two device implementations configured in a consistent manner, re-verification can be avoided.

[0039] A second aspect of the invention relates to an apparatus comprising a physical device implementation and an allocated virtual device implementation, the physical device implementation and the allocated virtual device implementation being configured for use with respect to physical devices and virtual devices.

[0040] - In the first device implementation of the two device implementations, access permissions to the communication partner are received.

[0041] Access permissions are verified through the first device, and

[0042] If the access permission is deemed permitted, then the first device implementation provides the communication partner with a permission certificate for accessing the second device implementation through the communication partner, and

[0043] - Allows access to the second device implementation of the two device implementations via the communication partner using the permission certificate.

[0044] For devices that have both physical and virtual implementations, such as digital twins, complex verifications, especially within the scope of zero-trust authentication, cannot be performed by the real device, i.e., the physical device implementation, but are instead transferred to its digital twin, i.e., the virtual device implementation. The physical device implementation of the device can, for example, be a digital twin now assigned to an older device. The digital twin allows for flexible configuration and upgrades: what information is needed for zero-trust access and how that information can be transmitted.

[0045] In one advantageous implementation, the virtual device is configured as an OPC UA server according to the Open Platform Communications Unified Architecture standard.

[0046] If the OPC UA server is implemented, for example, as an integrated virtual device implementation on top of a physical device implementation, it is possible that when accessing the device, such as when controlling data communications or accessing an integrated device network server, the device provides authentication credentials for accessing the virtual device implementation within the device. Specifically, when establishing a secure communication connection, temporary access to the OPC UA server implemented on the physical device can be established, and authentication credentials can be transmitted to the communication partner. Thus, the communication partner can access the OPC UA server, which is implemented as a virtual device on top of a physical device implementation.

[0047] In one advantageous implementation, the virtual device implementation is constructed on a central server, an edge server, or on the physical device implementation of the device.

[0048] Central servers or edge servers located at the edge of automated networks provide greater computing power than the devices themselves and typically include other databases, such as configuration or debugging databases, through which large amounts of data about the devices and communication partners can be accessed quickly with low transmission bandwidth, and thus access permissions for the devices and highly efficient verification of communication partners can be queried.

[0049] A third aspect of the invention relates to a computer program product comprising a non-volatile computer-readable medium capable of being directly loaded into the memory of a digital computer, including program code portions suitable for performing the steps of the method.

[0050] Unless otherwise stated in the following description, the terms "receive," "verify," "provide," "allow," etc., preferably relate to actions and / or processes and / or steps of altering and / or generating data and / or converting data into other data, wherein the data can be represented, in particular, as physical parameters or can exist as physical parameters, such as electrical pulses. The device, and particularly physical device implementations and virtual device implementations, may include one or more processors. In connection with the invention, a processor can be understood, for example, as a main processor, microprocessor, or microcontroller. For example, it can also be a virtual processor or a soft CPU.

[0051] Computer program products, such as computer program components, may be provided or supplied as storage media, such as memory cards, USB sticks, CD-ROMs, DVDs, or as files downloadable from a server on a network. This can be done, for example, by transferring the corresponding files to the computer program product or computer program component over a wireless communication network. Attached Figure Description

[0052] Embodiments of the method and device according to the invention are illustrated by way of example in the accompanying drawings and are described in more detail below. Wherein:

[0053] Figure 1 An embodiment of the device according to the invention incorporated into a facility network is illustrated schematically;

[0054] Figure 2 A first embodiment of the method according to the invention is illustrated in the form of a message flow diagram; and

[0055] Figure 3 A second embodiment of the method according to the invention is shown in the form of a message flow diagram, wherein two devices, one with a physical device implementation and the other with a virtual device implementation, perform authentication. Detailed Implementation

[0056] Corresponding parts are equipped with the same reference numerals in all figures.

[0057] Figure 1A communication network with multiple devices is illustrated. These devices are, for example, field devices connected to the communication network of an industrial facility. Each device includes physical device implementations FD1, FD2, FD3, FD4, FD5 and at least one assigned virtual device implementation DT-FD1, DT-FD2, DT-FD3, DT-FD4, DT-FD5. Physical device implementations FD1, FD2, FD3 are connected to a subnetwork 10, such as an automation network. Subnetwork 10 is connected to an open network 11 via an edge server 12. The edge server 12 provides transfer functions for collaborating with components of the facility network located outside of subnetwork 10. Physical device implementations FD4, FD5 are directly connected to the open network 11, such as an office network or the public internet. A central server, such as a cloud server, is connected via the open network 11, which centrally provides computing power and storage capacity to the facility network.

[0058] Two virtual device implementations, DT-FD1 and DT-FD2, are assigned to physical device implementations FD1 and FD2, respectively. Virtual device implementations DT-FD1 and DT-FD2 are deployed on edge server 12 and cloud server 13, respectively. The virtual device implementation DT-FD3 for physical device implementation FD3 is deployed within physical device implementation FD3 and additionally on central server 13. The virtual device implementations DT-FD4 and DT-FD5 assigned to physical device implementations FD4 and FD5 are deployed solely on central server 13. Virtual device implementations are often referred to as digital twins and can be constructed, for example, as applications. In particular, virtual device implementations can also be constructed as OPC UA servers.

[0059] Information about the physical device implementation can be queried by accessing the OPC UA server. The OPC UA server can be configured outside the physical device implementation, for example, within edge server 12 or central server 14. However, the OPC UA server for a virtual device implementation can also be implemented as an OPC UA application service on the device itself, such as for both physical and virtual device implementations FD3 and DT-FD3. In this case, the physical device implementation FD3 itself can provide the communication partner with credentials to access the OPC UA server integrated into the physical device implementation. If the communication partner can access the first device implementation, such as the physical device implementation FD3, then the communication partner also automatically gains access to the second device implementation, here the virtual device implementation DT-FD3, and in this case, the device's OPC UA server. This is particularly meaningful if multiple instances of the service run separately on the physical device implementation FD3. For example, via an authenticated HTTPS communication connection, the communication partner can access the web server of the physical device implementation.

[0060] Figure 2 A specific embodiment is now shown, in which the communication partner ST, such as a service technician, establishes a DT-FD1 connection with the device's virtual device and queries authorization credentials. The device in Figure 2 The first example shown is the implementation of DT-FD1 using a virtual device and the implementation of FD1 using a physical device.

[0061] First, the communication partner ST performs authentication at the first device implementation, specifically at the virtual device implementation DT-FD1. Here, in the first method step S1, the virtual device implementation DT-FD1 receives the access permissions from the communication partner ST. The first device implementation then verifies the access permissions, see method step S2, and in method step S3 provides the communication partner ST with an access certificate AC. Figure 2 In this context, the authorization certificate used to access the physical device via the communication partner ST to implement FD1 is called AC-FD1-ST. The authorization certificate AC here is, for example, implemented from the virtual device via the acknowledgment message ACC-Cred, where DT-FD1 is transmitted to the communication partner ST.

[0062] The communication partner ST then sends an authentication request AuthConReq containing the authentication certificate AC to the second device implementation, where the physical device implementation is FD1. The authentication certificate AC is verified in the second device implementation, and access to the second device implementation FD1 is subsequently granted to the communication partner ST. This is confirmed using an acknowledgment message AuthConRsp from the second device implementation to the communication partner ST. As in the example shown, the authentication certificate AC can be an access authentication certificate used by the communication partner ST for access authentication at the second device implementation. However, the authentication certificate AC can also serve as an access permission certificate for the communication partner's granted access to the second device implementation. Therefore, the communication partner ST, which can access the first device implementation, can also access the second device implementation.

[0063] There is no need to manage access authentication and access permission information on both device implementations. This reduces management overhead and avoids fundamentally inconsistent access data configurations between the two device implementations. In particular, this also enables the physical device implementation FD1 to not only directly obtain and verify the access permissions of its communication partner ST, but also additionally obtain the access authorization certificate AC used to grant access to the virtual device implementation DT-FD1. Furthermore, it is possible to obtain log messages regarding key actions, such as those required during auditing, not only from the physical device implementation FD1 but also from the virtual device implementation DT-FD1.

[0064] The validity of the issued authentication certificate (AC) may be time-limited. This usage restriction can be transmitted within or outside the authentication certificate AC. For this purpose, the authentication certificate may, for example, include a timestamp. Here, the validity period can specify the time interval within which access authentication or access requests to the second device are permitted, or the maximum duration for which an established communication connection can remain. It is also possible that the number of times access to the second device can be achieved through the authentication certificate AC is limited. For example, the authentication certificate AC may be usable only once, meaning it only has the right to establish a connection with the second device once.

[0065] If the communication connection between the communication partner ST and the first device implementation, here virtual device implementation DT-FD1, is terminated, the issued authorization certificate AC is, for example, revoked or no longer updated. Therefore, access to the second device implementation is only possible if access to the first device implementation also exists. If the connection with the first device implementation, such as a communication session, is terminated, then access to the second device implementation is no longer possible. This can be achieved, for example, through a so-called heartbeat mechanism associated with the corresponding authorization certificate AC. For this purpose, a network connection is established between the first and second device implementations, here DT-FD1 and FD1, where the two device implementations are notified to each other that the device implementation is ready to operate and can still perform its tasks, i.e., it is still alive (am Leben). Such a “heartbeat” connection (see SesHB) is established between the first and second device implementations in method step S41 and between the communication partner and the first device implementation in method step S42.

[0066] In the illustrated example, the virtual device implementation DT-FD1 can issue an authentication certificate (AC) that enables the communication partner ST to access the virtual device implementation DT-FD1, i.e., the digital twin. The transmitted and thus issued authentication certificate (AC) can be, for example, a digital certificate, a cryptographic key, or an access token (Zugangstoken), which enables access to or right to specific services or resources of the device.

[0067] The authorization certificate AC may, for example, contain a fingerprint of the certificate as an identifier for the communication partner ST's certificate. Specifying the certificate's serial number and issuer is also possible. Alternatively, the authorization certificate AC may also contain or reference secrets that the communication partner ST and both devices implementing DT-FD1 and FD1 must know and use. Here, the identifier of the certificate, or even the entire authorization certificate AC, is encrypted cryptographically. The authorization certificate AC may further contain authorization information, such as the role of the communication partner ST or attributes specific to a particular action. The authorization certificate AC may also contain time restrictions, such as the time or duration of access and / or the geographical location of the communication partner ST at the time of access. Furthermore, the authorization certificate AC may contain restrictions on the communication media that can be used, such as access via a wired connection only or via a cordless communication connection using W-LAN or mobile radio.

[0068] The authentication certificate AC may also contain information about the security status of the communication partner ST. Such a security status can be determined, for example, by a local agent in the communication partner ST that periodically checks the system status of the communication partner ST. Furthermore, the authentication certificate AC may contain an integrity checksum. This is, for example, a signature or cryptographic checksum that enables the integrity of the authentication certificate AC to be verified at the corresponding receiver, i.e., the communication partner ST or a second device, here at FD1.

[0069] When establishing a secure communication connection, the authentication certificate AC can be transmitted from the first device (here, DT-FD1) to the communication partner ST and / or from the communication partner ST to the second device (here, FD1). In particular, when establishing a connection according to the Telecommunication Layer Protocol (TLS), the authentication certificate AC can be transmitted, for example, in the TLS extension field during authentication and key agreement. Therefore, when establishing a TLS connection with the first device (TD-FD1), the authentication certificate is automatically provided to the communication partner ST, and then used to establish a connection with the second device (FD1).

[0070] In addition to the authentication authority (AC), the address information of the second device implementation (FD1 in this case) can be provided to the communication partner ST from the first device implementation (DT-FD1 in this case). Such address information may be, for example, the IP address of the second device implementation FD1, the name of the domain name server, or the URL address of the second device implementation.

[0071] Similarly, it is also possible to provide the authentication certificate (AC) via the Open Platform Communication Unified Architecture Protocol (OPC UA). The authentication certificate AC is transmitted as valid data over an established and authenticated communication connection, such as an HTTP connection. Alternatively, the authentication certificate AC can already be transmitted within the handshake of a secure communication connection, for example, during the establishment of the TLS protocol. Therefore, it is not necessary to manage separate authentication certificate ACs for accessing the first or second device implementation. Furthermore, because the provided authentication certificate AC is more compact than, for example, the digital certificate used during full authentication, connection establishment with the second device implementation can be performed more efficiently, especially faster, or with less data.

[0072] The first device implementation, here the virtual device implementation DT-FD1, is therefore issued an authorization certificate AC for accessing the physical device implementation FD1. Conversely, it is also possible to first establish a connection with the physical device implementation FD1 and establish an authorization certificate AC via said connection for establishing a connection with the virtual device implementation DT-FD1. The authorization certificate AC in the form of a structured digital certificate according to the X.509 standard can in particular have the following extensions for transmitting one or more of the mentioned information. The following extensions are examples and are written in the abstract syntax notation ASN.1:

[0073]

[0074] This means that, for example, a virtual device implementation DT-FD1 can issue digital certificates that enable protected access to the assigned physical device implementation FD1. Here, the physical device implementation is the actual physical device. Figure 1 The example shown is field device FD1. The digital certificate used as proof of authorization is a self-signed certificate, which is created by a first device implementation of the device and verified and accepted by a second device implementation of the same device. Therefore, it is unnecessary to establish and operate a generally accepted private key infrastructure (PKI), as these special certificates or proofs of authorization are issued and verified solely by the individual device itself.

[0075] Figure 3 An embodiment for field device FD1 to access a second field device FD2 is shown, wherein device FD1 and device FD2 establish a cryptographically protected, mutually authenticated connection. However, the actual, complex authentication between the physical devices FD1 and FD2 is performed through their digital twins, i.e., their virtual device implementations DT-FD1 and DT-FD2, respectively.

[0076] Here, physical device implementation FD1 makes a request to its own virtual device implementation DT-FD1. In the example shown, the virtual device implementation first sends the authentication request AuthCon to physical device implementation FD2. From there, the request is internally transferred to its assigned virtual device implementation DT-FD2. Virtual device implementation DT-FD2 then initiates authentication for virtual device implementation DT-FD1 using the authentication request. Here, authentication is requested from virtual device implementation DT-FD2 by virtual device implementation DT-FD1. The method steps for virtual device implementation DT-FD1, as a communication partner, to request authentication at virtual device implementation DT-FD2 are indicated by reference numerals S1, S2, S3, and S4. The method steps for second device implementation DT-FD2, as a communication partner, to authenticate at virtual device implementation DT-FD1 are the method steps indicated by reference numerals S1', S2', S3', and S4'.

[0077] The corresponding first device implementation receives the access permission request message AuthConReq from the communication partner (see S1, S1'), verifies the access permission (see S2, S2'), and provides the authorization certificates AC-FD1FD2 and AC-FD2FD1 to the communication partner, which is, in this case, the virtual device implementation DT-FD1 or DT-FD2. The corresponding authorization certificates AC-FD1FD2 and AC-FD2FD1 are transmitted from the first device implementation (DT-FD1 or DT-FD2) to the corresponding assigned second device implementation (FD1 or FD2) using the message ACC-Cred. The physical device implementation FD1 then sends the authentication request AuthConReq containing the authorization certificate AC-FD1FD2 to the physical device implementation FD2 and obtains access permission from that physical device implementation, which is confirmed using the confirmation message AuthConRsp (see also the illustrated method step S4). Accordingly, in method step S4', after the authentication request from the second device implementation FD2 and the included authorization certificate AC-FD2FD1, the second device implementation FD1 grants access to the physical device implementation FD1.

[0078] Therefore, the two virtual device implementations verify the communication partner, namely the physical device implementations FD2 and FD1. The physical device implementations can be, for example, devices already existing in the network that do not support zero-trust access verification.

[0079] All method steps can be implemented using corresponding devices suitable for implementing the respective method steps. All functions that can be implemented by specific features can be method steps of the method. Within the scope of the invention, all described and / or drawn features can be advantageously combined with each other. The invention is not limited to the described embodiments.

Claims

1. A method for authenticating a communication partner at a device, wherein in addition to a physical device implementation, there is at least one virtual device implementation assigned to the device, the method comprising the steps of: - In the first device implementation of the two device implementations, access permissions to the communication partner are received. - The access permission is verified through the first device, and If the access permission is deemed permitted, then the first device implementation provides the communication partner with a permission certificate for accessing the second device implementation through the communication partner, and - Allow access to the second device implementation of the two device implementations via the communication partner using the authorization certificate, wherein if the communication connection between the first device implementation and the communication partner is terminated, the authorization certificate is revoked or not updated, wherein access to the second device implementation is possible only if access to the first device implementation also exists.

2. The method according to claim 1, wherein the authorization certificate is an access authorization certificate for access authentication and / or an access permission certificate for the granted access rights.

3. The method according to claim 1 or 2, wherein the validity of the authorization certificate is time-limited.

4. The method according to claim 1 or 2, wherein the number of times access to the second device is achieved by means of the permission proof is limited.

5. The method according to claim 1 or 2, wherein the proof of authorization is a digital certificate, a cryptographic key, or an access token.

6. The method according to claim 1 or 2, wherein the authorization certificate includes at least one of the following: -The identifier of the communication partner's certificate, -The authorization information of the communication partner, -Time and / or geographical restrictions on access to the aforementioned communication partners. -Limitations of available communication media -Limitations of available communication protocols - Information regarding the security status of the communication partner. - The integrity verification value of the permission proof.

7. The method according to claim 1 or 2, wherein the authorization certificate is transmitted from the first device to the communication partner and / or from the communication partner to the second device when a secure communication connection is established.

8. The method of claim 1 or 2, wherein the authorization certificate is transmitted from the first device to the communication partner and / or from the communication partner to the second device via an authenticated existing communication connection.

9. The method of claim 1 or 2, wherein the address information implemented by the second device is additionally provided from the first device implementation to the communication partner.

10. The method of claim 1 or 2, wherein when verifying the access permission via the first device, the integrity and / or permissibility of the current configuration of the communication partner are verified.

11. The method of claim 1 or 2, wherein the first device transmits information about the configuration of the device to the communication partner.

12. An apparatus for authenticating a communication partner, the apparatus comprising a physical device implementation and an assigned virtual device implementation, the physical device implementation and the assigned virtual device implementation being configured for... - In the first device implementation of the two device implementations, access permissions to the communication partner are received. - The access permission is verified through the first device, and If the access permission is deemed permitted, then the first device implementation provides the communication partner with a permission certificate for accessing the second device implementation through the communication partner, and - Allow access to the second device implementation of the two device implementations via the communication partner using the authorization certificate, wherein if the communication connection between the first device implementation and the communication partner is terminated, the authorization certificate is revoked or not updated.

13. The device of claim 12, wherein the virtual device implementation is an OPC UA server based on the Open Platform Communication Unified Architecture standard.

14. The device according to claim 12 or 13, wherein the virtual device implementation is configured on a central server, an edge server, or on the physical device implementation of the device.

15. A computer program product comprising a program code portion adapted to perform the steps of the method according to any one of claims 1 to 11 when the program code portion is executed on a processor.

Images