Method for performing a permission-dependent communication between a field device and an operating device

Abstract

A method for performing a permission-dependent communication between at least one field device of automation technology and an operating device is described and shown, wherein the field device and the operating device are connected to each other via a communication connection and wherein the field device has an electronic field device identifier. The method is implemented in that, in the case that the operating device obtains a permission for communicating with the field device from a permission authority, cryptographic verification data dependent on the field device identifier are deposited on the operating device, the operating device obtains the field device identifier from the field device in order to prepare for the communication with the field device, in a cryptographic comparison step it is checked whether the field device identifier obtained by the operating device is contained in the verification data, and for the case that the field device identifier obtained by the operating device is contained in the verification data, the operating device communicates with the field device, otherwise the operating device does not communicate with the field device.

Description

TECHNICAL FIELD

[0001] The present application relates to a method for performing a permission-dependent communication between at least one field device and an operating device of automation technology, wherein the field device and the operating device are connected to one another via a communication connection and wherein the field device has an electronic field device identifier. BACKGROUND

[0002] Field devices of automation technology are often various sensors or also various actuators which are installed "in the field", i.e. in the technical process and record there measurement values, output control variables or directly as actuators actively influence the process. Such field devices are in direct contact with the technical process, for example in a manufacturing plant. Field devices of the type mentioned here are used, for example, to detect flow, pressure, temperature, pH value and other process-related variables in a measuring technology or also to influence the process, for example by operating regulating valves.

[0003] The field devices considered here can be connected to one another via a communication connection with operating devices, with it then being possible for the operating devices to record data from the field devices or also to influence the field devices, for example in such a way that certain parameters are transmitted to the field devices or in such a way that also functionalities in the field devices are activated and / or configured.

[0004] For different reasons, it can be desirable that a certain operating device should not establish a connection with a connected field device or only be allowed to establish a communication relationship with the field device within a certain scope. The field device must satisfy certain safety technical requirements, for example, and therefore needs reliable protection, but for example also only certain functionalities of the field device can be prescribed for access by the operating device, for example by purchasing certain functional modules. The operating device can be an external device with a so-called device type manager (DTM), for example.

[0005] The solutions known from the prior art for the problem of an operating device or a software component running on an operating device being able to establish a communication connection in a certain way only with a certain connected field device consist for example in the operating device being designed specifically for the device and thus being able to establish a communication relationship in a certain way only with certain field devices. In this case, the access possibilities of the relevant operating device to certain field devices are compiled directly into the software equipment of the operating device. Other solutions provide that the operating device must be connected to a license server at runtime in order to be able to query certain authorizations. Both solutions are expensive, since in the first case individual software must be produced for the operating device and in the second case a connection to the license server must be established. SUMMARY

[0006] The task of the present application is to find a solution that is as simple as possible for an operating device to be able to establish a communication connection with a field device that maintains a communication connection only within certain permission limits.

[0007] The task introduced and explained earlier is solved in the method described at the beginning for performing a permission-dependent communication between a field device and an operating device by depositing on the operating device, in the case of the operating device obtaining a permission from a permission provider to communicate with the field device, cryptographic verification data dependent on a field device identifier; the operating device obtaining the field device identifier from the field device in order to prepare for a communication with the field device; checking in a cryptographic comparison step whether the field device identifier obtained by the operating device is contained in the verification data; and for the case that the field device identifier obtained by the operating device is contained in the verification data, the operating device communicating with the field device, otherwise not communicating with the field device.

[0008] The permission provider can be for example a manufacturer of the operating device and / or of the field device, which wants to find a way of the operating device being able to be run only in association with certain field devices or a certain software component of the operating device being able to be run in association with certain field devices.

[0009] The association between the operating device and its access possibilities to field devices is achieved by depositing on the operating device cryptographic verification data dependent on a field device identifier. The field device identifier can be present for example in a serial number or in a unique identification of the field device during the installation process. Cryptographic verification data means information that is processed in cryptographic techniques, i.e. cryptographically.

[0010] If the field device and the operating device are connected to each other or come into connection with each other via a communication connection, the operating device first obtains the field device identifier of the field device from the field device. Then, in a password comparison step, it is checked using a cryptographic technique whether the field device identifier obtained by the operating device, i.e. the field device identifier that has been transmitted from the field device to the operating device, is contained in the verification data. Here, it does not necessarily have to be identified whether the field device identifier is contained in the verification data in plain text, i.e. the verification data is not necessarily the field device identifier, but it is also meant that the verification data explicitly depends on the field device identifier and can indirectly determine whether the obtained field device identifier is present in the verification data in some way, including a cryptographically hidden way. If the field device identifier obtained by the operating device is contained in the verification data in some way in this sense, i.e. the comparison step is positive, it is judged on the operating device that it can communicate with the field device; in the case of a negative output of the password comparison step, the operating device or the involved software components on the operating device cannot communicate with the field device. That is, the operating device judges itself on the basis of the result of the password comparison step whether it can communicate with the connected field device. This is, however, completely sufficient for many application cases in industrial practice.

[0011] If the operating device does not have permission to communicate with the field device, it is of course still possible to deposit the password verification data on the operating device, however, which does not depend on the corresponding field device identifier. In this case, the password comparison step can still be carried out, however, which then has a negative result, so that the operating device cannot communicate with the field device.

[0012] According to a preferred design of the method, it is provided that a first license key is calculated as verification data from the field device identifier and from a secret key using a password license algorithm. The calculation can take place, for example, on a license server, on which it is known which field device with which field device identifier should be accessible by the operating device by means of the communication connection. In general, the licensor, i.e. in particular the manufacturer of the operating device and / or the manufacturer of the communication software for implementing on the operating device to communicate with the field device, knows the secret key.

[0013] In a preferred design of the method described above, it is provided that the password license algorithm performs a calculation of a hash value from the combination of the field device identifier and the secret key.

[0014] According to an extension of the method, the secret key is deposited on the operating device. This can be done in plain text, in particular, however, protected, for example, in the compiled communication software of the operating device or in another encrypted form.

[0015] In an extended version of the method, in the cryptographic method step, a second license key is calculated using a cryptographic license algorithm from a field device identifier obtained from the field device and a secret key stored on the operating device. Then, in order to verify whether the field device identifier obtained by the operating device is contained in the verification data, it is checked whether the first license key coincides with the second license key.

[0016] Preferably, the calculation of the second license key is performed on the operating device. Alternatively, the calculation can also be carried out on a computer connected to the operating device.

[0017] It is clear from the illustrated embodiment aspect that the "containment" of the field device identifier in the verification data does not mean that the field device identifier must be obtainable in plain text from the verification data. However, the calculation of the hash value from the field device identifier is sufficient to explicitly prove that the field device identifier is actually contained in the verification data.

[0018] According to an alternative design of the method, which is alternative to the use of a secret key, it is provided that a digital certificate is created as verification data, wherein the digital certificate comprises in a first certificate part a cryptographic public key of the licensor and at least one field device identifier of those field devices for which the operating device has or should obtain a communication license. The digital certificate comprises in a second certificate part a digital signature calculated from the first certificate part, wherein the digital signature is calculated using a cryptographic certificate private key of an asymmetric cryptographic certificate key pair.

[0019] The first design of the method based on a secret key is mainly suitable for assigning an operating device to a unique field device or for assigning a software component on the operating device to a unique field device, whereas the certificate solution now discussed is also suitable for being able to assign to multiple field devices.

[0020] Preferably, the digital certificate can also be created by the licensor, i.e. in particular by the manufacturer of the operating device and / or by the manufacturer of the communication software for carrying out on the operating device the communication with the field devices. However, this is not essential. Alternatively, the digital certificate can also be created by a certification authority (CA) different from the licensor, as this is known, for example, from certificates in the field of Internet communication.

[0021] In one extension of the certificate-based method it is provided that at least one field device identifier contained in the digital certificate is determined on the operating device in the password comparison step and at least one determined field device identifier is compared with at least one field device identifier obtained from the field device. In the case of a coincidence of the field device identifiers it is verified that the relevant at least one field device identifier obtained by the operating device is contained in the verification data. In this case the operating device can communicate with the connected field device.

[0022] In this context, in one particularly preferred design of the method it is provided that the certificate public key of the asymmetric cryptographic certificate key pair is transmitted to the operating device and the certificate is checked for integrity on the operating device using the certificate public key. In the case of a negative check result the communication of the operating device or of a software component of the operating device with the connected field device is excluded; and / or in the case of a negative check result the damage (Korruption) of the certificate is displayed and / or further reported. BRIEF DESCRIPTION OF DRAWINGS

[0023] Now, a plurality of possibilities exist for designing the method for performing a permission-dependent communication between at least one field device and an operating device of an automation technology according to the application in detail. The corresponding extensions are the subject matter of the dependent claims and are subsequently described with respect to the shown embodiments. In the drawings:

[0024] Figure 1 A general method for performing a permission-dependent communication is shown very schematically;

[0025] Figure 2 An implementation of the method according to the application is shown in the case of the use of a license key, which is calculated from a field device identifier and a secret key; and

[0026] Figure 3 A design of the certificate-based method according to the application is shown. DETAILED DESCRIPTION

[0027] In all three figures, a method 1 for performing a permission-dependent communication 2 between at least one field device 3 of automation technology and an operating device 4 is shown. The field device 3 and the operating device 4 are connected to one another via a communication connection 5. The communication connection 5 can be a wired connection, but the communication connection can also be implemented via a radio interface. Standardized interfaces can be involved, but connections using manufacturer-specific proprietary device interfaces can also be involved; this is not essential here. In any case, the field device 3 has an electronic field device identifier IDF. Such a field device identifier can have been given at the manufacturer, for example, an explicit field device identifier IDF can alternatively or additionally be specified by the user of the field device; this is not essential here either.

[0028] With the method 1 shown, it should be achieved that permission-dependent communication 2 between the field device 3 and the operating device 4 is realized with very simple means, i.e. for example without the need for a connection to a license server or without the operating device and / or the field device having to be run with device-specific software.

[0029] All the methods 1 shown have in common that, in the case of the operating device 4 obtaining or having obtained permission from a permission provider 6 to communicate with the field device 3, password verification data VDL dependent on the field device identifier IDF is deposited on the operating device 4. The password verification data VDL is thus a carrier of the communication permission. It is also provided that the operating device 4 obtains the field device identifier IDF from the field device 3 in order to prepare for communication with the field device 3. In a password comparison step 9, it is checked whether the field device identifier IDF obtained by the operating device 4 is contained in the verification data VDL. In all embodiments, the password comparison step 9 is carried out on the operating device 4. For the case that the field device identifier IDF obtained by the operating device 4 is contained in the verification data VDL, the operating device 4 can communicate with the field device 3, otherwise the operating device cannot communicate with the field device 3. An internal check on the operating device 4 or a software component running on the operating device 4 makes the decision as to whether the operating device 4 can use the communication connection 5 to communicate with the field device 3.

[0030] In Figure 1In FIG, the dependence of the cryptographic verification data VDL on the field device identifier is depicted as follows: the verification data VDL is a function f of the field device identifier IDL. The abbreviation IDL is used here for the field device identifier rather than the abbreviation IDF to make it clear that the field device identifier IDF located at the field device 3 may differ from the field device identifier IDL—in the embodiment shown, this is known to the licensor 6. In other words, the field device identifier IDL is the identifier of the field device to which authorization for communication with a particular operating device is to be granted, while the field device identifier IDF is the field device identifier of the actually connected field device.

[0031] In all figures, the password comparison step 9 is performed on the operating device 4 and is shown there as a diamond. Figure 1 It is very common to check whether the field device identifier IDF of the field device 3 is contained in the verification data VDL. In this case, "contains" does not mean that the field device identifier IDF is contained in plain text in the verification data VDL. It only requires that there is a clear correlation between the verification data VDL and the field device identifier IDF to be checked, so that in principle it can be checked whether the operating device 4 should be allowed to communicate with the field device 3 having the identifier IDF.

[0032] exist Figure 2 The embodiment in FIG has clearly shown that the field device identifier IDF does not have to be included in the verification data VDL in plain text. Figure 2 : The calculation of the first license key using the cryptographic license algorithm f, i.e., from the field device identifier IDL and from the confidentiality key KEY, as verification data VDL is shown. The confidentiality key KEY is known to the licensor 6, for example, the manufacturer of the operating device or possibly the manufacturer of the communication software implemented in the operating device 4 for communicating with the field device 3.

[0033] exist Figure 2 In the embodiment shown in , the cryptographic license algorithm f performs calculation of a hash value based on a combination of the field device identifier IDL and the secret key KEY.

[0034] exist Figure 2In the case of method 1 shown in , the confidentiality key KEY is stored on the operator device 4. This then allows a cryptographic comparison step 9 to be performed on the operator device 4. In this case, in cryptographic comparison step 9, a cryptographic license algorithm f is used to calculate a second license key f(IDF, KEY) based on the field device identifier IDF obtained from the field device 3 and the confidentiality key KEY stored on the operator device 4. To verify whether the field device identifier IDF obtained by the operator device 4 is contained in the verification data VDL, a check is performed to determine whether the first license key VDL is consistent with the second license key f(IDF, KEY). This consistency check of these license keys can be positive (pos), thereby terminating communication, but it can also be negative (neg), thereby preventing communication between the operator device 4 and the field device 3.

[0035] Method 1 Figure 3 The embodiment shown in Figure 2 An alternative implementation to the implementation shown in , where a secret key is used. Figure 3 The alternative solution shown in works using digital certificates. That is, a digital certificate ZERT is created as verification data VDL, wherein the digital certificate ZERT includes in a first certificate part the cryptographic public key PUBL of the licensor 6 and the field device identifiers IDL or field device identifiers IDL1, IDL2 of the field devices for which the operating device 4 should obtain communication permission. The digital certificate ZERT includes in a second certificate part a digital signature SIGN_PRIVZ calculated based on the first certificate part. The digital signature - as is common for certificates - is calculated using the cryptographic certificate private key PRIVZ of the asymmetric cryptographic certificate key pair PUBZ, PRIVZ. This key pair is usually issued by a certification authority. This certification authority can be an institution completely unrelated to the licensor 6, but the licensor 6 (for example, in the form of a manufacturer of the operating device 4 and / or the field device 3 and / or the communication software for the operating device 4) can of course also work as a certification authority.

[0036] In a comparison step 9, at least one field device identifier IDL contained in the digital certificate ZERT is determined 10 at the operating device 4. In the present case, two field device identifiers are contained in the digital certificate ZERT, namely the field device identifiers IDL1 and IDL2. The determined field device identifiers IDL1, IDL2 are compared with the field device identifiers IDF1, IDF2 obtained from the field device 3. In the case of a coincidence of the field device identifiers IDF1, IDF2, IDL1, IDL2, it is verified that the relevant and by the operating device 3 obtained field device identifiers IDF1, IDF2 are contained in the verification data VDL. The communication between the operating device 4 and the one or more field devices 3 is permitted accordingly or also blocked.

[0037] In Figure 3 It can also be seen in that the certificate public key PUBZ of the asymmetric cryptographic certificate key pair PUBZ, PRIVZ has been transmitted to the operating device 4. At the operating device 4, the certificate public key PUBZ is used to check the integrity of the certificate ZERT. This is an additional check to the check in the comparison step 9. Here, the communication of the operating device 4 with at least one field device 3 is also excluded in the case of a negative check result. Alternatively or additionally, it can be provided that a display and / or further reporting of the damage of the certificate ZERT is effected in the case of a negative check result.

[0038] Reference signs

[0039] 1 Method

[0040] 2 Communication

[0041] 3 Field device

[0042] 4 Operating device

[0043] 5 Communication connection

[0044] 6 Licensee

[0045] 7 Storing verification data

[0046] 8 Obtaining field device identifier

[0047] 9 Comparison step

[0048] 10 Determining field device identifier

[0049] IDL Field device identifier for granting a communication permission

[0050] IDF Field device identifier of an actually connected field device

[0051] VDL Verification data

[0052] COM communication permission / prohibition

[0053] KEY secret key

[0054] ZERT digital certificate

[0055] PUBZ public key of the certification authority

[0056] PRIVZ private key of the certification authority

[0057] PUBL public key of the licensor.

Claims

1. A method (1) for carrying out permission-dependent communication (2) between at least one field device (3) and an operating device (4) in automation technology, wherein the field device (3) and the operating device (4) are connected to one another via a communication connection (5) and wherein the field device (3) has an electronic field device identifier (IDF). in, When the operating device (4) obtains permission from the licensor (6) to communicate with the field device (3), cryptographic verification data (VDL) from the licensor, which depend on the field device identifier IDL present at the licensor, are stored (7) on the operating device (4), wherein the cryptographic verification data (VDL) is a function f of the field device identifier IDL; wherein the operating device (4) obtains (8) the field device identifier IDF from the field device (3) to prepare for communication with the field device (3); wherein, in a cryptographic comparison step (9), it is checked on the operating device (4) whether the verification data (VDL) obtained from the licensor is explicitly dependent on the field device identifier IDF obtained by the operating device (4) from the field device (3); and wherein the operating device (4) communicates with the field device (3) if the verification data (VDL) explicitly depends on the field device identifier IDF obtained by the operating device (4) from the field device (3), and otherwise the operating device does not communicate with the field device (3), wherein a first license key is calculated as verification data (VDL) from the field device identifier IDL and from a secret key (KEY) using a cryptographic license algorithm (f), or In this case, a digital certificate (ZERT) is created as verification data (VDL), wherein the digital certificate (ZERT) includes in a first certificate part the cryptographic public key (PUBL) of the licensor (6) and at least one field device identifier IDL, IDL1, IDL2 of those field devices (3) for which the operating device (4) has communication permission, and wherein the digital certificate (ZERT) includes in a second certificate part a digital signature (SIGN_PRIVZ) calculated based on the first certificate part, wherein the digital signature (SIGN_PRIVZ) is calculated using the cryptographic certificate private key (PRIVZ) of the asymmetric cryptographic certificate key pair (PUBZ, PRIVZ).

2. The method (1) according to claim 1, characterized in that The licensor (6) knows the secret key (KEY).

3. The method (1) according to claim 2, characterized in that The manufacturer of the operating device (4) and / or the manufacturer of the communication software implemented on the operating device for communicating with the field device (3) knows the secret key (KEY).

4. The method (1) according to claim 1, characterized in that The cryptographic license algorithm (f) performs calculation of a hash value based on a combination of the field device identifier IDL and the confidentiality key (KEY).

5. The method (1) according to any one of claims 1 to 4, characterized in that The confidentiality key (KEY) is stored on the operating device (4).

6. The method (1) according to claim 5, characterized in that The confidentiality key (KEY) is stored in a protected manner on the operating device (4).

7. The method (1) according to claim 5, characterized in that The confidentiality key (KEY) is stored on the operating device (4) in the form of compiled communication software or in another encrypted form.

8. The method (1) according to any one of claims 1 to 4, characterized in that In the cryptographic comparison step (9), a second license key (VDF) is calculated using the cryptographic license algorithm (f) based on the field device identifier IDF obtained from the field device (3) and the secret key (KEY) stored on the operating device (4); and in order to verify whether the verification data (VDL) clearly depends on the field device identifier IDF, it is checked whether the first license key is consistent with the second license key (VDF).

9. The method (1) according to claim 8, characterized in that The calculation of the second license key (VDF) takes place on the operating device (4).

10. The method (1) according to claim 1, characterized in that The digital certificate (ZERT) is created by the licensor (6).

11. The method (1) according to claim 10, characterized in that The digital certificate (ZERT) is created by the manufacturer of the operating device (4) and / or by the manufacturer of the communication software implemented on the operating device (4) for communicating with the field device (3).

12. The method (1) according to any one of claims 1, 10 to 11, characterized in that In the cryptographic comparison step (9), at least one field device identifier IDL1, IDL2 contained in the digital certificate (ZERT) is determined (10) on the operating device (4), and the at least one determined field device identifier IDL1, IDL2 is compared with at least one field device identifier IDF1, IDF2 obtained from the field device (3), and in the event of an agreement between the field device identifiers, it is confirmed that the verification data (VDL) clearly depends on the field device identifier IDF, because the relevant at least one field device identifier IDF1, IDF2 obtained by the operating device (4) is contained in the verification data (VDL).

13. The method (1) according to any one of claims 1, 10 to 11, characterized in that The certificate public key (PUBZ) of the asymmetric cryptographic certificate key pair (PUBZ, PRIVZ) is transmitted to the operating device (4), and the integrity of the certificate (ZERT) is checked on the operating device (4) using the certificate public key (PUBZ), wherein in the case of a negative check result, communication between the field device (4) and at least one field device (3) is excluded and / or in the case of a negative check result, damage to the certificate (ZERT) is displayed and / or further reported.

Images