Method for gaining access to a field device and corresponding system

Abstract

The invention discloses a method for regaining access to a field device (FG1, FG2), the field device storing a first account, in particular comprising a first username and a first password, the method comprising the following steps carried out by the manufacturer of the field device (FG1, FG2): operating a ticket server (TS); and linking the field device (FG1, FG2) to the ticket server (TS); and comprising the following steps carried out by the user: authenticating the registrant to the ticket server; in the event of a successful authentication: creating a second account, in particular with a second username and / or a second password, for the field device (FG1, FG2) by means of the ticket server (TS); generating one or more tickets (T) for the second account by means of the ticket server (TS); transporting the ticket (T) to the field device (FG1, FG2); checking the ticket (T) on the side of field device (FG1, FG2) as to whether the ticket (T) was actually created by the ticket server (TS); and overwriting the first account in the field device (FG1, FG2) with the second account or storing the second account, if the check is positive. The invention also relates to a system for carrying out the method.

Description

[0001] Procedure for gaining access to a field device and corresponding system

[0002] The invention relates to a method for obtaining access to a field device and a system designed to carry out the method.

[0003] Field devices used in industrial plants are already known from the state of the art. Field devices are widely used in process automation technology, as well as in manufacturing automation technology. Field devices are all devices used close to the process and that provide or process-relevant information. Field devices are used to record and / or influence process variables. Measuring devices or sensors are used to record process variables. These are used, for example, for pressure and temperature measurement, conductivity measurement, flow measurement, pH measurement, level measurement, etc. and record the corresponding process variables such as pressure, temperature, conductivity, pH value, level, flow, etc. Actuators are used to influence process variables.These include, for example, pumps or valves that can influence the flow of a fluid in a pipe or the fill level in a container. In addition to the previously mentioned measuring devices and actuators, field devices also include remote I / Os, wireless adapters, and generally devices located at the field level.

[0004] A large number of such field devices are produced and distributed by the Endress+Hauser Group.

[0005] In modern industrial plants, field devices are usually connected to higher-level units via communication networks such as fieldbuses (Profibus®, Foundation® Fieldbus, HART®, etc.). These higher-level units are usually control systems (DCS) or control units such as a PLC (programmable logic controller). The higher-level units are used, among other things, for process control, process visualization, process monitoring and for commissioning the field devices. The measured values ​​recorded by the field devices, particularly sensors, are transmitted via the respective bus system to one (or possibly several) higher-level units. In addition, data transmission from the higher-level unit to the field devices via the bus system is also required, particularly for the configuration and parameterization of field devices and for controlling actuators.

[0006] Mobile control units can also be used to operate field devices. For example, there are control units that are connected to the fieldbus network. However, the control unit can also communicate with the field devices via a wireless communication connection, particularly based on a Bluetooth standard. The applicant produces and sells devices known as Bluetooth gateways that allow the control units to be connected to the field devices. The field device is connected to a Bluetooth gateway via a wired connection, particularly using the HART or CDI communication standards. Alternatively, the field devices themselves have their own Bluetooth interfaces.

[0007] If a mobile device, such as a smartphone or tablet, is used as an operating unit for wireless communication with the field devices, application programs, so-called apps, are available which make the operating functions for the field device available to the mobile device.

[0008] In industrial environments, most installed field devices have little or no protection against unauthorized access. For example, all device parameters can usually be accessed directly or, for example, after entering an unlock code. As a result of the Federal Security Act, field devices with individual user accounts and role-based authorization are increasingly coming onto the market. Access via a user or machine interface therefore requires a certain degree of "permanent" authorization, which is usually granted through prior authentication.

[0009] In order to reduce the administrative effort for the administration of the individual field devices to an acceptable level, there are isolated efforts to create a central administration, as has been common practice in the IT sector for years with regard to the IT devices there (e.g. printers, workstations, etc.). An example of such a concept is revealed by the

[0010] DE 10 2018 102 608 A1 , in which a means of transport is provided to which user data is transferred from a user database, wherein after checking the user data, access to the field device is granted.

[0011] There are also ideas for limiting the access authorizations required by people to a minimum. DE 10 2019 131 860 A1, for example, discloses the provision of a digital ticket that is transmitted from a server ("ticket server") to the mobile device and contains the access rights and authorized activities for the field device. This ticket is transmitted when the connection to the field device is established. If authorization is present, the tasks contained in the ticket, such as parameterization actions or performing functional tests, can be processed with the field device. Under the assumed conditions, the field devices and their configuration interfaces are well protected, and only authenticated and authorized users have access, for example, to the device's configuration.

[0012] However, entering user data, such as user name and password, via the control unit every time a field device is operated is error-prone and time-consuming.

[0013] For online field devices, i.e., field devices that are permanently connected to an IP-capable network, single sign-on (SSO) solutions are well known, for example, via OIDC / Oauth2, as specified by OPC UA Security and CI Security, and are also prevalent on the internet. There are also established solutions in the enterprise IT environment, such as MS Active Directory or LDAP.

[0014] Caching passwords in web browsers or using password safes (e.g., “KeyPass”) on IT devices also represent state of the art.

[0015] The vast majority of field devices have severe resource limitations (e.g., low permissible power consumption in explosive environments, low storage capacity, low computing power, etc.) and are mostly connected to the control system via 4...20 mA or HART. Even in systems that use the PROFINET fieldbus standard, for example, the field devices are often decoupled from the system bus via remote I / Os. This means they do not have a permanent connection to an IP-capable network, unlike online field devices, which, in turn, are very rarely used in systems. Nevertheless, offline field devices also have additional digital configuration interfaces (e.g., a local display, Bluetooth interfaces, a point-to-point web server, etc.), which require the access protection for user accounts described above.

[0016] The above-mentioned state of the art is not applicable to offline field devices, and an industry-specific SSO solution that primarily addresses offline devices is not available.

[0017] DE 10 2023 133 179, which was still unpublished at the filing date of this document, extends the above-described concept by adding a single sign-on login to the ticket server, for example, at the start of a shift. This eliminates the need for individual logins for the user, even for offline field devices. The security concept remains intact.

[0018] However, if a user forgets their password and they don't have access to an alternative password reset mechanism or none is available (e.g., an on-site emergency button or an on-site recovery button), problems can arise. For example, Bluetooth doesn't have a "forgotten password" function for field devices. If field devices are configured with very secure settings, there's a chance the user could permanently lock themselves out of the field device.

[0019] This makes logging into the field device impossible, and in the worst case, the device could only be disposed of. Alternatively, a "back door" must be open, which is obviously not desirable.

[0020] The invention is based on the object of providing a possibility to gain access to a field device if the password actually required for this purpose has been lost or forgotten.

[0021] The object is achieved by a method according to claim 1 and by a system according to claim 9.

[0022] Specifically, the solution is implemented through the following steps, which are performed by the manufacturer of the field device: operating a ticket server; and linking the field device to the ticket server, whereby a first account, in particular comprising a first user name and a first password, is stored on the field device. The further steps of the method are performed by the user: authenticating the registrant to the ticket server, creating a second account, in particular with a second user name and a second password, for the field device via the ticket server;

[0023] Generate one or more tickets from the ticket server for the new account;

[0024] Transporting the ticket to the field device; checking the ticket on the field device to determine whether the ticket was actually created by the ticket server; and saving the account on the field device or overwriting the first account with the second account if the check is positive.

[0025] To implement this idea, a ticket server is required that has a mutual, cryptographic trust relationship with the field devices and the control unit required for offline operation.

[0026] "Mutual, cryptographic trust" means that the components have been made aware of each other in advance. For this purpose, cryptographic information, such as the public key of a key pair, has been exchanged. Thus, the data exchange between the respective components that have this trust relationship fulfills the protection goals of "integrity," "confidentiality," and "availability." Examples of field devices have already been listed in the introductory part of the description. Network components, such as edge devices and gateways, also fall under the definition of a field device within the scope of the invention described here.

[0027] This process allows the user to log back into the field device if the login credentials for the original account are no longer available. To do this, the user must authenticate themselves with the ticket server, which is operated by the manufacturer. This can be done, for example, by entering login credentials for a special account provided for the user by the field device manufacturer. The user can obtain these login credentials, for example, via a customer portal or by phone. They can also authenticate themselves by phone, for example.

[0028] A new account, called a "second account," is then created for the user. The user can select the login credentials for the second account after successful authentication. Alternatively, the second account can be an "emergency account," in which the user is provided with the login credentials for the second account by the field device manufacturer.

[0029] The ticket loads the second account onto the field device, allowing the user to log in using credentials for the second account. The field device can be updated with the second account, leaving the first account intact. However, the first account can also be overwritten with the second account.

[0030] In one embodiment, the ticket is transported via an operating unit, whereby the operating unit connects to the field device, for example via Bluetooth.

[0031] In one embodiment, the ticket is only valid for the control unit.

[0032] An advantageous feature of the process provides that after the validity period expires, the control unit is automatically deregistered from the corresponding field devices. Re-registration with the ticket is then no longer possible.

[0033] According to an advantageous embodiment of the method, the login information contains a user name. According to one variant, authentication on the ticket server occurs by entering user information, in particular a user name and password, which the user uses for authentication in their IT office administration. Services such as "Oauth2 / OISC," "LDAP," "MS AD," etc., are used for this purpose. This has the advantage that the user can reuse existing accounts.

[0034] According to one variant, the ticket server is designed as an application in a cloud platform, whereby it uses the same user data for authentication that it also uses for authentication against the cloud platform.

[0035] This allows the ticket server to be embedded in the cloud environment used by the user, thus reducing the administrative burden of managing a multitude of different accounts across different services. The ticket is transported via Bluetooth, a memory card (such as an SD card), or a digital protocol (such as HART).

[0036] One embodiment provides that the field device is connected to the ticket server and the ticket is transported via this connection.

[0037] One design provides that the newly created account is time-limited.

[0038] One design provides for further login to the field device to be done via single sign-on.

[0039] One embodiment provides for the following step to be carried out: Granting access to the field device after the user has successfully logged in to the field device, in particular with user name and password.

[0040] With regard to the system, it is provided that the system is designed to carry out the method according to the invention and comprises at least one field device, a ticket server and an operating unit.

[0041] One design of the system provides for the control unit to be a mobile device, in particular a tablet or a smartphone.

[0042] This is explained in more detail using the following figures.

[0043] Fig. 1 shows the claimed system.

[0044] Fig. 2 shows the claimed system in one embodiment. In the figures, identical features are identified by identical reference numerals.

[0045] The invention is based on an established field device ticket server infrastructure. There is a ticket server TS operated by the manufacturer of the field devices FG1, FG2. The field devices FG1, FG2 are linked to the ticket server TS via a "join process," see below. Linking occurs, for example, during the production of the field devices, but in any case before the field devices FG1, FG2 are delivered to the respective user.

[0046] Such a ticket server TS can, for example, be implemented on the applicant's IoT infrastructure, such as the Endress+Hauser Group's "Netilion" platform. Additional services can also be provided via this platform.

[0047] The field devices FG1 and FG2 have modules that handle user access management on the field device side. Furthermore, the field devices FG1 and FG2 are set to a mode in which they can create and receive tickets T (see below). "Tickets" are described, for example, in DE 10 2018 102 608 A1 and DE 10 2019 131 860 A1.

[0048] A join process of the field devices FG1, FG2 on the ticket server TS has already been carried out, so that as a result the ticket server TS and the field devices FG1, FG2 have a cryptographically secured, mutual trust relationship. The field devices FG1, FG2 can be online field devices, i.e. they communicate with the ticket server via a network. In the present case, however, the field devices FG1, FG2 are offline field devices, i.e. there is no direct communication connection with the ticket server TS. The tickets T can then be transferred from the ticket server TS to the corresponding field devices FG1, FG2 via a transport medium, e.g. an operating unit BE, and vice versa.

[0049] User BN (this may refer to different users during the process, but may also be the same user) has a primary account on both field devices FG1 and FG2 shown here. However, user BN has forgotten the username and / or password for the primary account on field devices FG1 and FG2. The "user" is the same as the "operator" of the field device.

[0050] Furthermore, a control unit (BE) is provided. The control unit (BE) is primarily a mobile device, such as a smartphone or tablet. The control unit (BE) also has an established relationship of trust with the ticket server (TS).

[0051] According to the invention, the following additional steps are now carried out. In a first method step, the user BN logs in to the ticket server, or authenticates himself with it, and creates a second account, in particular with a second user name and password, for the field device FG1, FG2. If necessary, a validity period can also be specified. Depending on the criticality of the system and standard operational procedures, the validity period is variable (e.g., hours, for this shift, etc.). Under certain circumstances, these steps are not performed by the user BN, but by a user with extensive authorizations, for example, an administrator. In one embodiment, these steps can be performed by the manufacturer.

[0052] In a process step, one or more tickets T are then generated by the ticket server TS for the new account or the command set for deleting all accounts.

[0053] Ticket T contains or corresponds to a transaction. A transaction is a sequence of program steps that are considered a logical unit because, after error-free and complete execution, they leave the data set in a consistent state. Therefore, a transaction is required to be executed either completely and error-free or not at all.

[0054] A ticket generally defines order data for a work order to be performed. The order data can include, for example, the following: unique identification of the service employee or user, the field device, the work order (e.g., maintenance measure, activation of a defined parameter, calibration, replacement of the field device, etc.), and, if applicable, the period in which the work order is to be performed.

[0055] The following options are also advantageous: Field devices have orderable product features (software features). These are currently enabled or executed / activated by entering a code. Using the invention, it is now possible for the activation to be included in the order data of the ticket. This allows corresponding product features of the field devices to be easily and securely activated and / or deactivated.

[0056] In this document, however, the main focus of a "ticket" is on the following aspect: Login to the field device is achieved using an authorized device, an operating unit, or an authorization tool. User BN is automatically authorized to carry out the work order by presenting ticket T to field device FG1, FG2. The ticket therefore contains the access authorization to field device FG1, FG2. Ticket T thus serves as an identifier (e.g. user name) and as an authenticator (e.g. it contains a password or a password equivalent for direct access to the field device), and it also contains the authorization to operate the field device accordingly. By using a password equivalent instead of a password, the real password does not have to be disclosed. The password may also only be valid for a limited time.If the user delivers the ticket T to the field device, the login data is automatically transmitted to the field device. After the task has been completed, the ticket T automatically becomes invalid. The ticket is encrypted with a shared symmetric key and secured with HMAC (e.g., ChaCha20-Poly1305) and contains the specified validity period and login information, such as the user name BN and a password verifier (an intermediate value for a crypto function used by the field device and control unit to determine a shared symmetric key for the field device and control unit) from the ticket server TS database. As an alternative to the password verifier, a clear text password or a random temporary password can also be included.

[0057] The ticket T is transmitted to the field device via any data transmission channel - e.g. manually, via a control unit, via a wireless or wired network (e.g. HART, Bluetooth) - or it is stored on a storage medium, e.g. a USB stick or SD card, and is transmitted to the field device by the user.

[0058] To this end, in one process step, the operating unit used by user BN to operate the device is also brought into a mutual, cryptographically secured trust relationship, if this has not already been done. This occurs once via a join process for operating devices. This involves the creation and transmission of join tickets from the ticket server TS to the operating unit BE, through which cryptographic information, particularly designed for calculating (symmetric) keys, is transmitted.

[0059] The ticket T is then sent to the field device FG1, FG2, for example, via the BE or HART control unit as mentioned above. In one embodiment, the field device is connected to the ticket server. Ticket T can then be transported directly via this route.

[0060] Finally, in a process step, the ticket T is checked by the field device FG1, FG2 to see whether the ticket was actually created by the ticket server. If the check is positive, the second account is saved on the field device FG1, FG2 or the first account is overwritten with the second account. In one process step, for example, the user BN logs on to the field device FG2. For this purpose, the user BN is on site at the field device FG2 and selects it to establish the connection (for example, by selecting it in a live list). The login is via the second user name with the second password. If the field device FG2 can verify this as valid and the login time is within the specified validity period, the user BN logs on to the field device FG2 using his control unit BE.

[0061] The field device FG2 can then be operated by the user BN using the usual tickets (see, for example, DE 10 2019 131 860 A1). Further login to the field device can also be done via single sign-on, for example.

[0062] In the example in Fig. 2, a ticket server TS is operated by the manufacturer of the field devices FG1, FG2. In addition, the user of the field devices FG1, FG2 has his own ticket server TS 1 . This ticket server TS 1 is regularly used to manage accounts. Only in emergencies is the manufacturer's ticket server TS used.

[0063] List of reference symbols

[0064] BE control unit

[0065] BN User

[0066] FG1 , FG2 field devices

[0067] T-Ticket

[0068] TS, TS' Ticket Server

Claims

Patent claims 1 . A method for regaining access to a field device (FG1, FG2), wherein a first account, in particular comprising a first user name and a first password, is stored on the field device, comprising the steps which are carried out by the manufacturer of the field device (FG1, FG2): - Operating a ticket server (TS); and - Linking the field device (FG1, FG2) with the ticket server (TS); as well as the steps to be performed by the user: - Authenticating the registrant to the ticket server; - In case of successful authentication: creation of a second account, in particular with a second user name and / or a second password, for the field device (FG1, FG2) via the ticket server (TS); - Generating one or more tickets (T) from the ticket server (TS) for the second account; - Transporting the ticket (T) to the field device (FG1, FG2); - Checking the ticket (T) by the field device (FG1, FG2) to see whether the ticket (T) was actually created by the ticket server (TS); and - Overwrite the first account on the field device (FG1, FG2) with the second account or save the second account if the check is positive.

2. Method according to claim 1, wherein the transport of the ticket (T) takes place via an operating unit (BE), wherein the operating unit (BE) connects to the field device (FG1, FG2), for example via Bluetooth.

3. Method according to claim 2, wherein the ticket (T) is only valid for the operating unit (BE).

4. The method according to claim 1, wherein the transport of the ticket (T) takes place via Bluetooth, a memory card, such as an SD card or a digital protocol, for example HART.

5. The method according to claim 1, wherein the field device (FG1, FG2) is connected to the ticket server (TS) and the transport of the ticket (T) takes place via this connection 6. Method according to one of the preceding claims, wherein the second account is time-limited.

7. Method according to one of the preceding claims, wherein the further registration on the field device (FG1, FG2) takes place via single sign-on.

8. Method according to one of the preceding claims, further comprising the step - granting access to the field device (FG1, FG2) after successful login on Field device (FG1, FG2) by the user, in particular with a second user name and second password.

9. System which is designed to carry out the method according to one of claims 1 to 7, comprising at least one field device (FG1, FG2), a ticket server (TS) and a control unit (BE).

10. System according to claim 8, wherein the operating unit (BE) is a mobile terminal, in particular a tablet or a smartphone.

Images