Method and device for providing and validating cryptographically secured device identity information

Abstract

The invention relates to a method for providing and validating cryptographically secured device identity information, in which method an initial device certificate is created as device identity information and stored in a device memory. The initial device certificate comprises device information which is selected and signed by the manufacturer and which comprises at least a device identifier, a device attribute, or a device property, and a specification of a public key assigned to a device by the manufacturer. Only after successful device authentication is an additional device certificate created, on the basis of the initial device certificate, as further device identity information and stored in the device memory. The additional device certificate comprises device information selected and signed by a user or an operator, and forms a certificate chain together with the initial device certificate. Following successful device authentication, it is possible to generate, on the basis of the additional device certificate, at least one further additional device certificate which comprises device information selected and signed by a subsequent user or operator and which can be stored in the device memory. During each identity validation of the device, only the most recently generated device certificate, or a device certificate designated for identity validation, is read out from the device memory and verified.

Description

[0001] Description

[0002] Method and device for providing and validating cryptographically secured device identity information

[0003] The present invention relates to a method for providing and validating cryptographically secured device identity information, in particular identity information for devices within an industrial automation system, and a device for carrying out the method.

[0004] Regardless of the grammatical gender of a particular term, persons with male, female or other gender identities are included.

[0005] Industrial automation systems typically comprise a large number of automation devices interconnected via an industrial communication network and serve to control or regulate plants, machines, or equipment within the context of manufacturing or process automation. Due to time-critical conditions in industrial automation systems, real-time communication protocols such as PROFINET, PROFIBUS, Real-Time Ethernet, or Time-Sensitive Networking (TSN) are predominantly used for communication between automation devices.

[0006] Industrial automation devices and end devices that exchange time-critical data with communication partners to control machines or equipment must be protected against manipulation and eavesdropping. One protective measure is the encryption of communication to and from these devices. This is typically achieved using encryption protocols such as TLS (Transport Layer Security) or SSL (Secure Socket Layer), which require each device to provide a key pair and a certificate based on the public key of that key pair.

[0007] To ensure secure communication, all communication partners must be able to trust the certificates of the aforementioned devices. Using self-signed certificates generated by the devices is generally unsuitable, particularly due to potential man-in-the-middle attacks and problematic authentication. Generating key pairs and certificates externally by a Certification Authority (CA) of a Public Key Infrastructure (PKI) is also not entirely without its problems, as the private key of such a key pair can potentially be intercepted during transmission to the respective device. Furthermore, TLS certificates, in particular, must be renewed regularly for security reasons. Therefore, the key pairs and certificates generated by a Certification Authority must be regularly transferred to the devices.This affects a large number of devices in industrial automation systems.

[0008] Furthermore, Secure Device Onboarding (SDO) procedures, such as those based on the BRSKI protocol, are increasingly being used in industrial automation systems, particularly in the context of Zero Trust concepts. These procedures enable, on the one hand, identity verification (Proof of Identity) and, on the other hand, proof of originality verification, and on the other hand, the secure deployment of environment-specific key pairs and certificates to devices within an industrial automation system.

[0009] From WO 2022 / 028975 A1, a method for verifying components of an industrial Kontra II system is known, in which a first module of a verification system is configured to establish a trust relationship with a component of the industrial

[0010] The system is designed to build a Kontra II system and query the component for a component certificate containing relevant information about the component. A second module of the verification system is configured to check the component certificate based on relevant data stored in a trusted database and interacting with the component. This relevant data includes one or more trust chains or one or more certificate revocation lists (CRLs). Accordingly, one or more trust chains or one or more CRLs are validated during the check. Based on the result of the check, a message is generated.

[0011] WO 2024 / 7110524 A1 describes a method for integrating a technical module into a control system, where the technical module comprises multiple technical devices. During integration, the control system retrieves information from a computer-implemented module inventory of the technical module and stores this information in a computer-implemented control system inventory. This information is designed to identify the technical devices of the technical module. Based on the information stored in the computer-implemented control system inventory, operating, monitoring, and automation functions for the technical system are created. The information stored in the computer-implemented control system inventory includes, in particular, certificates that can be used to identify or verify the authenticity of each technical device.Advantageously, the control system automatically evaluates the validity of the certificates. If one of the certificates is invalid, the technical module is excluded from the operating, monitoring, and automation functions for the technical system.

[0012] However, WO 2024 / 7110524 A1 does not indicate that, during device identity validation, only the most recently generated device certificate or one specified for identity validation is read from the device memory and verified. Rather, certificates for technical devices installed in a technical module can be obtained from a user certification authority via a control system interface. This does not, however, constitute a block on the use of an initial device certificate, in particular an IDevID certificate, during identity validation in favor of exclusively using a most recently derived device certificate, in particular an LDevID certificate.

[0013] The earlier international patent application WO 2024 / 175336 A1 relates to a method for integrating a plant component into a communication network of a technical plant. First, the plant component identifies an integration service of the technical plant. Furthermore, the plant component transmits information regarding the types of integration procedures it supports to the integration service of the technical plant. Taking into account the information available to the integration service regarding the types of integration procedures supported by the communication network of the technical plant, and the information transmitted by the plant component regarding the types of integration procedures supported by the plant component, the integration service checks whether automated integration of the plant component into the communication network of the technical plant is possible.If automated integration of the plant component into the communication network of the technical plant is possible, the integration of the plant component into the communication network of the technical plant will take place.

[0014] Currently, authenticity checks typically only verify the origin of a device from a specific manufacturer. Often, the origin from an original manufacturer is irrelevant to end customers. This applies, for example, to scenarios where a machine manufacturer produces a machine using components from various manufacturers. For end customers, users, or buyers of the machine, the origin of the components is frequently far less important than the origin of the machine or a key component from a specific manufacturer.

[0015] The present invention therefore aims to provide an efficient method for providing and validating cryptographically secured device identity information that is actually relevant to device users or is selectively made available to device users, and to specify a suitable device for the technical implementation of the method.

[0016] This problem is solved according to the invention by a method with the features specified in claim 1 and by a device with the features specified in claim 12. Advantageous embodiments of the present invention are specified in the dependent claims.

[0017] According to the inventive method for providing and validating cryptographically secured device identity information, an initial device certificate is created as device identity information and stored in a device memory. This initial device certificate comprises manufacturer-selected and signed device information, including at least one device identifier, one device attribute or property, and additionally, a specification of a manufacturer-assigned public key to the device. Only after successful device authentication using the initial device certificate is an additional device certificate created as further device identity information and stored in the device memory.

[0018] According to the invention, the additional device certificate comprises device information selected and signed by the user or processor and forms a certificate chain with the initial device certificate. After successful device authentication using the additional device certificate, at least one further additional device certificate can be generated, which comprises device information selected and signed by a subsequent user or processor and can be stored in the device memory. The initial device certificate can, for example, be an Initial Device Identifier or X.509 certificate, while the additional or further additional device certificates can, in particular, be an Initial Device Identifier, a Locally Significant Device Identifier, or an X.509 certificate.

[0019] According to the invention, during device identity validation, only the most recently generated device certificate or one specified for identity validation is read from the device memory and verified. Preferably, the device identity validation checks whether the device has access to a private key that corresponds to the specified or most recently generated device certificate. In particular, the identity validation can be automated according to the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol or according to OPC Unified Architecture protocol, Part 21, Device Onboarding.

[0020] The present invention enables the selective consideration of intermediate instances along a value chain, from component suppliers through system integrators to end customers, users, or operators of a technical system or complex technical device, during authenticity checks using the aforementioned certificate chaining. In this way, the authenticity and integrity of device identity information can be ensured and efficiently verified along multi-stage value chains.

[0021] Preferably, when verifying the initial device certificate, it is checked whether the device has access to a private key that corresponds to the manufacturer-assigned public key. Alternatively or additionally, reading the initial device certificate or at least one additional device certificate from the device memory can be selectively blocked. In particular, the initial device certificate or at least one additional device certificate can be released for reading only by a directly subsequent or selected user or processor, or by a manufacturer. This enables particularly secure use of initial and additional device certificates. Advantageously, the device certificate to be used for identity validation is specified by the manufacturer or by the user or processor.Accordingly, device certificates not intended for identity validation are blocked from being read.

[0022] According to a further advantageous embodiment of the present invention, identity validation is performed within the framework of a network access authorization requested by and for the device by a registration instance. To authorize network access, the device transmits a request to the registration instance containing the most recently generated device certificate or the device certificate specified for identity validation. After successful identity validation, the registration instance creates an additional device certificate and transmits it to the device. The device can then authenticate itself for network access using this additional device certificate.In particular, the registration authority can request a confirmation of authenticity for the device from a manufacturer, user, or processor verification authority based on the most recently generated device certificate or the device certificate specified for identity validation. Identity validation is only successfully completed after this confirmation of authenticity has been received. Furthermore, the manufacturer, user, or processor verification authority can request a cryptographically secured confirmation that a selected network, for which network access authorization is requested, is a trusted environment for the device. In this case, the device will only connect to the selected network after this cryptographically secured confirmation has been received.Overall, the above implementation variants enable efficient and particularly secure device onboarding in a target network environment.

[0023] The device according to the invention is designed and configured for carrying out a method according to the preceding descriptions, and is configured and set up so that an initial device certificate is created as device identity information and stored in a device memory, wherein the initial device certificate comprises manufacturer-selected and signed device information, which includes at least a device identifier, a device attribute and / or a device property and a specification of a public key assigned to a device by the manufacturer.Furthermore, the device is designed and configured so that only after successful device authentication using the initial device certificate is an additional device certificate created as further device identification information and stored in the device memory. This additional device certificate contains device information selected and signed by the user or processor, and forms a certificate chain with the initial device certificate. After successful device authentication, at least one further additional device certificate can be generated using the additional device certificate. This second certificate contains device information selected and signed by a subsequent user or processor and can be stored in the device memory.Furthermore, the device is designed and configured so that during identity validation of the device, only the most recently generated device certificate or the device certificate specified for identity validation is read from the device memory and checked.

[0024] The present invention is explained in more detail using an exemplary embodiment with reference to the drawing. The figure shows a schematic representation of the provision and validation of cryptographically secured device identity information along a chain from a device manufacturer, via a machine or plant manufacturer and a distributor, to an end customer.

[0025] The embodiment shown in the figure is merely an example of the manufacture of a device and its subsequent processing or use along a general, multi-stage value chain. In the present embodiment, a device 1 has been manufactured by a device manufacturer 10. The manufacturer creates an initial device certificate 100 as the first device identification information and stores it in a device memory of the device 1. The initial device certificate 100 comprises device information selected and signed by the manufacturer. This device information, in turn, includes at least a device identifier, a device attribute or property, and a specification of a public key assigned to the device by the manufacturer.

[0026] In a subsequent step, device 1 is installed by a machine or plant manufacturer as a component of machine 2 or plant. The machine or plant manufacturer generates an additional device certificate 200 as a second piece of device identification information and stores it in the device memory, but only after successful device authentication using the initial device certificate 100. The additional device certificate 200 forms a certificate chain with the initial device certificate 100. Specifically, when the initial device certificate 100 is checked, it is verified whether device 1 has access to a private key that corresponds to the manufacturer's assigned public key.

[0027] Reading the initial device certificate 100 or the additional device certificate 200 from the device memory can be selectively blocked. This also applies accordingly to subsequently created additional device certificates. For example, the initial device certificate 100 or the additional device certificate 200 can be released for reading only for a directly subsequent or selected user or processor of the device 1, and advantageously for the device manufacturer 10 and the machine or plant manufacturer. In particular, the respective device certificate to be used for identity validation can be specified by the manufacturer or by the user or processor. In this case, device certificates not specified for identity validation are preferably blocked from being read. After the device 1 has been installed as a component of the machine 2, or...In this exemplary embodiment, the machine or plant manufacturer delivers the device to a distributor 20. After successful device authentication using the additional device certificate 200, a further additional device certificate 300 is generated there as a third piece of device identity information. This further additional device certificate 300 contains device information selected and signed by the distributor 20 and is stored in the device memory analogously to the above descriptions. The further additional device certificate 300 forms a certificate chain with the initial device certificate 100 and the additional device certificate 200. During identity validation of the device 1 installed in the machine 2 or plant, for example by an end customer 30 who uses the machine 2 or plant, the device 1 is then verified.When a system receives a device from distributor 20, only the most recently generated device certificate 100, 200, or 300, or one specified for identity validation, is read from the device memory and verified. In particular, it is not necessary to read all or multiple device certificates 100, 200, or 300 from the device memory for this purpose. This allows, depending on the application-specific requirements, either only the first device manufacturer-side device identity, only the second machine or system manufacturer-side device identity, or only the distributor-side device identity to be verified. In the present embodiment, the identity validation of device 1 installed in machine 2 or system checks whether device 1 has access to a private key that corresponds to the specified or most recently generated device certificate 100, 200, or 300.

[0028] The initial device certificate 100, for example, can be an Initial Device Identifier or an X.509 certificate. Similarly, the additional device certificates 200 and 300 can be Initial Device Identifier, Locally Significant Device Identifier, or X.509 certificates, respectively. Based on such certificates, identity validation can be automated, for example, according to the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol or the OPC Unified Architecture protocol, Part 21, Device Onboarding. In particular, the BRSKI protocol enables automated initialization and configuration of devices in many application environments, even if they are located in an end-user network or a network with limited connectivity without prior configuration.

[0029] On the end-user side, in addition to device certificates 100, 200, and 300, a further device certificate can be generated as a fourth piece of device identity information in this exemplary embodiment, analogous to the procedure described above. In particular, identity validation on the end-user side can be performed as part of an authorization for network access requested by and for device 1 through a registration authority, such as a Local Registration Authority (LRA). To authorize network access in an end-user environment, device 1, in this exemplary embodiment, transmits a request to the registration authority that includes the most recently generated device certificate or the device certificate 100, 200, or 300 specified for identity validation. After successful identity validation, the registration authority creates the end-user device certificate and transmits it to device 1.Accordingly, device 1 can authenticate itself for network access using the end-customer's device certificate. An end-customer's own registration instance is not necessarily required to authorize network access. Instead, services provided by third parties based on a Manufacturer Authorized Signing Authority (MASA) can be used. Device onboarding using a MASA service typically occurs in several steps.

[0030] 1. Device identification and registration

[0031] Device 1 is identified and registered. It receives a unique identifier that is used for communication with the MASA service.

[0032] 2. Certificate creation

[0033] Device 1 generates a key pair, comprising a public and a private key, and requests an X.509 certificate. This certificate is signed by MASA and serves to authenticate Device 1.

[0034] 3. Voucher request

[0035] Device 1 requests a voucher from the MASA service. The voucher contains information about Device 1 and its permissions.

[0036] 4. Voucher signing

[0037] The MASA service signs the voucher with its private key.

[0038] 5. Voucher transfer to the device

[0039] The signed voucher is transferred to device 1. The device can use this voucher to receive, for example, software updates or configuration changes.

[0040] 6. Use of the voucher

[0041] Device 1 presents the voucher when communicating with a service that provides software updates or configuration changes. The service verifies the voucher's signature against a public key of the MASA service to confirm its authenticity. These steps ensure that only trusted devices can receive updates and configuration changes, particularly in end-user environments.

[0042] In principle, the registration instance can request an authenticity confirmation for Device 1 from a manufacturer, user, or processor verification instance based on the most recently generated device certificate or the device certificate specified for identity validation (100, 200, 300). Identity validation is only successfully completed after the authenticity confirmation has been received. Furthermore, Device 1 can request a cryptographically secured confirmation from the manufacturer, user, or processor verification instance that a selected network, for which network access authorization is requested, is a trusted environment for Device 1. In this case, the device will only connect to the selected network after the cryptographically secured confirmation has been received.

Claims

Patent claims 1. Method for providing and validating cryptographically secured device identity information, in which - an initial device certificate (100) is created as device identity information and stored in a device memory, wherein the initial device certificate (100) includes manufacturer-selected and signed device information that includes at least a device identifier, a device attribute and / or a device property and a specification of a manufacturer-assigned public key to a device (1), - only after successful device authentication using the initial device certificate (100) is an additional device certificate (200) created as further device identity information and stored in the device memory, wherein the additional device certificate (200) forms a certificate chain with the initial device certificate (100), characterized in that - the additional device certificate (200) includes user- or processor-selected and signed device information, - after successful device authentication using the additional device certificate (200), at least one further additional device certificate (300) can be generated, which includes device information selected and signed by a subsequent user or processor and can be stored in the device memory, - during identity validation of the device (1), only one most recently generated or one specified for identity validation device certificate (100, 200, 300) is read from the device memory and checked.

2. Method according to claim 1, wherein, during a verification of the initial device certificate (100), it is checked whether the device (1) has access to a private key that corresponds to the manufacturer-assigned public key.

3. Method according to one of claims 1 or 2, wherein reading the initial device certificate (100) and / or the at least one additional device certificate (200, 300) from the device memory is selectively blocked.

4. Method according to claim 3, wherein the initial device certificate (100) and / or the at least one additional device certificate (200, 300) is released for reading only for an immediately subsequent or selected user or processor (20, 30) and / or for a manufacturer (10).

5. Method according to one of claims 3 or 4, wherein the device certificate to be used for identity validation is specified by the manufacturer and / or by the user or processor, and wherein device certificates not specified for identity validation are blocked from being read.

6. Method according to any one of claims 1 to 5, wherein, during identity validation of the device, it is checked whether the device has access to a private key that corresponds to the specified or last generated device certificate.

7. A method according to any one of claims 1 to 6, wherein the identity validation is carried out within the framework of an authorization of network access requested by and for the device by a registration instance, wherein the device transmits a request to the registration instance for the authorization of network access comprising the last generated device certificate or the device certificate specified for identity validation, wherein, after successful identity validation, the registration instance creates an additional or further additional device certificate and transmits it to the device, and wherein the device authenticates itself for network access using the additional or further additional device certificate.

8. Method according to claim 7, wherein the registration instance requests a confirmation of originality for the device from a manufacturer's, user's or processor's verification instance based on the most recently generated device certificate or the device certificate specified for identity validation, and wherein the identity validation is only successfully completed after the confirmation of originality has been received.

9. The method of claim 8, wherein the device requests cryptographically secured confirmation from the manufacturer's, user's, or processor's verification instance that a The selected network, for which authorization for network access is requested, is a trusted environment for the device, and the device will only connect to the selected network after cryptographically secured confirmation has been received.

10. Method according to any one of claims 1 to 9, wherein the initial device certificate is an Initial Device Identifier and / or X.509 certificate and wherein the additional or further additional device certificate is an Initial Device Identifier, a Locally Significant Device Identifier and / or X.509 certificate.

11. Method according to any one of claims 1 to 10, wherein the identity validation is automated in accordance with the Bootstrapping Remote Secure Key Infrastructure protocol and / or in accordance with the OPC Unified Architecture protocol, in particular Part 21, Device Onboarding.

12. Device for carrying out a method according to one of claims 1 to 11, wherein the terminal device is designed and configured to - an initial device certificate is created as device identity information and stored in a device memory, wherein the initial device certificate includes manufacturer-selected and signed device information that includes at least a device identifier, a device attribute and / or a device property and a specification of a manufacturer-assigned public key to a device, - only after successful device authentication using the initial device certificate is an additional device certificate created as further device identity information and saved in the device memory, whereby - the additional device certificate includes user- or processor-selected and signed device information, - the additional device certificate forms a certificate chain with the initial device certificate, - after successful device authentication using the additional device certificate, at least one further additional device certificate can be generated, which includes device information selected and signed by a subsequent user or processor and can be stored in the device memory, During identity validation of the device, only the most recently generated device certificate or the device certificate specified for identity validation is read from the device memory and checked.

Images