Method and system for logging on a user to one or more field devices of automation technology

Abstract

The invention comprises a method for logging on a user (BN, BN') to one or more field devices (FG1, FG2) of automation technology, comprising: - activating a logon mode on the ticket server (TS) for one or more selected field devices (FG1, FG2) by a user (BN, BN'); - generating a logon ticket by the ticket server (TS), wherein the logon ticket contains logon information and information on a defined validity period and is cryptographically encrypted; - logging on an operating unit (BE) to the ticket server (TS) via a first communication connection between operating unit (BE) and ticket server (TS); - transferring the logon ticket from the ticket server (TS) to the operating unit (BE) after successful logon via the first communication connection; - transferring the logon ticket or another ticket containing the logon information from the operating unit (BE) to the field device(s) (FG1, FG2) via a second communication link between the operating unit (BE) and the field devices (FG1, FG2); and - logging on the user (BN, BN') to the field device(s) (FG1, FG2) by means of the logon information, and a system for carrying out the method according to the invention.

Description

[0001] Method and system for logging a user on to one or more field devices in automation technology

[0002] The invention relates to a method for logging a user into one or more field devices in automation technology, wherein a ticket server is provided for user management. The ticket server and the field device have a cryptographically secured and mutually trusting relationship and are configured for mutually transmitting and receiving tickets. The tickets contain information about the intended recipient and cryptographically secured information. Furthermore, the invention relates to a system configured to implement the method according to the invention.

[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. In principle, field devices are all devices that are 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 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 wide range of such field devices are manufactured and distributed by the Endress+Hauser Group. In modern industrial plants, field devices are typically connected to higher-level units via communication networks such as fieldbuses (Profibus®, Foundation® Fieldbus, HART®, etc.). Typically, these higher-level units are control systems (DCS) or process control systems (PCUs).

[0005] Control units, such as a PLC (programmable logic controller). These higher-level units are used for process control, process visualization, process monitoring, and commissioning of field devices, among other things.

[0006] The measured values ​​recorded by the field devices, especially 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 configuring and parameterizing field devices and controlling actuators.

[0007] Mobile control units can also be used to operate field devices that have implemented an FDT framework application. 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 distributes devices that, as so-called Bluetooth gateways, 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.

[0008] 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.

[0009] 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. The authorization must be selected so that the accessing user (permanently) has all the permissions required to perform their tasks.

[0010] To reduce the administrative burden for administering individual field devices to an acceptable level, there are isolated efforts to centralize management, as has been common practice in the IT sector for years with regard to IT devices (e.g., printers, workstations, etc.). An example of such a concept is disclosed in DE 10 2018 1026 08 A1, which provides a transport medium to which user data is transferred from a user database. After verifying the user data, access to the field device is granted.

[0011] There are also ideas for limiting the access authorizations required by humans to a minimum. DE 102019131860 A1, for example, discloses a digital job ticket that is transmitted from a server to the mobile device and contains the access rights and authorized work for the field device. This job ticket is transmitted when the connection to the field device is established. If authorization is present, the tasks contained in the job ticket, such as parameterization actions or performing functional tests, can be processed with the field device.

[0012] Under the assumed conditions, the field devices with their configuration interfaces are well protected and only authenticated and authorized users have access, for example, to the configuration of the device.

[0013] However, entering user data, such as a user name and password, via a control unit every time a field device is operated is error-prone and time-consuming. For online field devices, i.e., field devices that are permanently connected to an IP-capable network, "Single Sign On" (SSO) solutions, such as those specified by OPC UA Security and CIP Security, are well-known 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] The invention extends the above prior art by allowing single sign-on registration at the ticket server, for example, at the start of a shift, eliminating the need for individual logins for the user, even for offline field devices. The security concept remains intact. Based on this problem, the invention seeks to present a concept that allows for a convenient login process for field devices, even over an extended period, while maintaining security.

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

[0019] With regard to the method, it is provided that the method serves to log in a user to one or more field devices of automation technology, wherein a ticket server is provided for user management, wherein the ticket server and the field device are in a cryptographically secured and mutually trusting relationship and are designed for the mutual transmission and reception of tickets, wherein the tickets contain information about the intended recipient and cryptographically secured information, wherein the method comprises:

[0020] - Activating a login mode on the ticket server for one or more selected field devices by a user, comprising setting a validity period for each field device;

[0021] - Generation of a registration ticket by the ticket server, wherein the registration ticket contains registration information and information on the specified validity period and is cryptographically encrypted;

[0022] - Registering a control unit on the ticket server via a first communication connection between the control unit and the ticket server;

[0023] - Transferring the registration ticket from the ticket server to the control unit after successful registration via the first communication connection;

[0024] - Transferring the login ticket or another ticket containing the login information from the control unit to one or more field devices via a second communication link between the control unit and the field devices; and

[0025] - Logging in the user to the field devices if the corresponding field devices can decrypt the login ticket or the additional ticket and verify the login information contained in the corresponding login ticket or the additional ticket as valid, and if the login time is within the specified validity period.

[0026] The invention solves the problem that requires the user to log in to the field device each time they want to operate it, for example, via a smartphone or control units such as the "FieldXpert" marketed by the applicant, by entering a username and password. This is error-prone—especially with good passwords with at least 11 characters—and time-consuming.

[0027] The core of the invention thus lies in the implementation of a "single sign-on" concept, which can also be used for offline field devices. This requires a central ticket server that maintains a mutual, cryptographically trusting relationship with the field devices and the control unit required for offline operation. A single login by the user on the ticket server is sufficient (one-time authentication) to obtain secure access to the selected field devices with the rights stored in the user account (authorization) for a configurable validity period – for example, during a technician's entire shift as a user. Since the login information from this additional login ticket is automatically provided during each login process and does not need to be entered, manual entry of login information by the user is eliminated.

[0028] "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."

[0029] 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. According to an advantageous embodiment of the method, the operating unit stores the registration ticket in a cryptographically secured cyberwallet of the operating unit. Such a cyberwallet is a storage location on the operating unit that is cryptographically protected. Examples of such cyberwallets include application software such as "Apple Wallet" or "Google Wallet," which can be used to store vouchers, boarding passes, and similar virtual objects.

[0030] According to an advantageous embodiment of the method, if the operating unit has not been previously informed of the ticket server, a registration process of the operating unit on the ticket server is carried out before the step of registering the operating unit on the ticket server, thus establishing a cryptographically secured and mutually trusting relationship between the operating unit and the ticket server. This registration process is carried out analogously to the registration of new field devices on the ticket server. In particular, it is provided that so-called "join tickets" are sent from the ticket server to the operating unit, which enable the exchange of cryptographic information with the help of which the trusting relationship is established.

[0031] An advantageous embodiment of the process provides for automatic deregistration of the control unit from the corresponding field devices after the validity period has expired. Re-registration using the registration ticket is then no longer possible.

[0032] According to an advantageous embodiment of the method, the registration information contains a user name.

[0033] As a second component, the login information in a first variant also contains a password verifier. A password verifier is a value of constant length and high entropy, cryptographically derived from a password stored for the field device on the ticket server. Therefore, it is not the password itself that is transmitted, but the resulting value. The value is used as part of a cryptographic procedure (e.g., AucPace), whereby the field device and the control unit determine a common symmetric key.

[0034] As a second component, the login information in a first variant also contains a password, which is in particular in plain text.

[0035] Depending on the configuration, the login information can either be stored on the ticket server and read to create the login ticket. Alternatively, the password can be generated as a random temporary password by the ticket server.

[0036] According to one embodiment of the method, it is provided that before the method according to the invention can start with the step of activating the login mode, the user must authenticate himself to the ticket server.

[0037] According to a first variant, authentication on the ticket server occurs by entering user information, specifically a username 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.

[0038] According to a second variant, the ticket server is designed as an application on a cloud platform, using the same user data for authentication that it also uses for authentication against the cloud platform. This allows the ticket server to be embedded in the cloud environment used by the user, thus reducing the administrative burden of maintaining a multitude of different accounts on different services.

[0039] An advantageous development of the method provides for an emergency account that is present in all field devices and consistent for all field devices, wherein the user enters login data intended for the emergency account into the control unit and / or wherein the control unit obtains the login data intended for the emergency account by scanning a graphic code, wherein the control unit transmits the login data intended for the emergency account to one or more of the field devices via the second data connection, and wherein the user is logged in to the respective field devices if the respective field devices can successfully verify the transmitted login data. For example, key boxes are provided in the system which contain the password and / or the graphic code (for example a QR code). Such a key box is broken open during an emergency, and the password orthe graphic code.

[0040] During the operation, the damage to the key box is visible. Furthermore, all access to the field device is blocked as an "emergency," so only certain functions are accessible via the emergency account. After such an emergency, the password for the emergency account should be changed immediately on the ticket server and redistributed to all field devices.

[0041] To ensure that the emergency accounts have been overwritten with the new password, the field devices create a return ticket to the ticket server after the new password has been adopted in order to ensure an overview of the success of the change.

[0042] Advantageously, the first communication connection is established as an internet connection. Depending on the design of the control unit, an Ethernet network and / or a mobile network connection is used for this purpose. The second communication connection is established, in particular, as a wireless connection, in particular based on Bluetooth, Bluetooth LE, or Wi-Fi.

[0043] 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. One embodiment of the system provides that the operating unit is a mobile device, in particular a tablet or a smartphone.

[0044] The invention is explained in more detail with reference to the following figures.

[0045] Fig. 1 : an embodiment of the system according to the invention;

[0046] Fig. 2: a schematic sequence of an embodiment of the method according to the invention; and

[0047] Fig. 3: a schematic flow of the further development of the method in which an emergency account of a field device is logged in.

[0048] Fig. 1 shows an abstract example of the system according to the invention. For the sequence of the individual method steps and their substeps, please refer to Fig. 2.

[0049] The invention is based on an established field device ticket server infrastructure. There is a plant-central ticket server TS that has already configured accounts for all users BN, BN' (e.g., technicians) of the field devices installed in the plant, along with the corresponding assignment and authorization. The field devices FG1, FG2 have modules that handle user access management on the field device side. Furthermore, the field devices FG1, FG2 are set to a mode in which they can create and receive tickets.

[0050] 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, mutually trusting relationship. The field devices FG1, FG2 can be online field devices, i.e. they communicate with the ticket server via a network. In this 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 can then be transferred from the ticket server TS to the corresponding field devices FG1, FG2 via a transport medium, e.g. an operator control unit BE, and vice versa.

[0051] The user BN, BN' (this may be different users during the process, but may also be the same user) has an account on the ticket server TS. Furthermore, the user BN, BN' also has an account on both field devices FG1 and FG2 shown here.

[0052] 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).

[0053] According to the invention, the following additional steps are now carried out:

[0054] In a first process step SO, a user BN, for example, the administrator of the ticket server TS, enables a login mode ("SSO" mode) on the ticket server and specifies the validity period of the login tickets to be created in the ticket server TS configuration. Depending on the criticality of the system and operational standard operating procedures (SOPs), the validity period is variable (e.g., hours, shift, days, week, quarter, etc.).

[0055] In a process step S1, the control unit used by user BN' (e.g., a technician) to operate the device will also be brought into a mutual, cryptographically secured trust relationship, if this has not already been done. This occurs once via a join process for control units. This involves the creation and transmission of join tickets from the ticket server TS to the control unit BE, through which cryptographic information, in particular designed to calculate (symmetric) keys, is transmitted.

[0056] The application on the BE control unit advantageously includes a cryptowallet for the secure storage of the cryptographic keys. The shared symmetric key calculated as a result of the join process is securely stored in this wallet.

[0057] In a process step S2, the user BN' logs on to the ticket server TS via an application on the operating unit BE. The application on the operating unit must additionally have a post office service for exchanging tickets. As a second additional feature, it must include the aforementioned cryptographically secured cryptowallet.

[0058] In a first sub-step S2.1, the user BN' opens the application and selects a command to log in to the ticket server TS. In a sub-step S2.2, the control unit BE connects to the ticket server TS, in particular via the Internet, and establishes an initial communication connection.

[0059] In substep S2.3, the user enters the user data for the ticket server TS. In the alternative step S2' shown in Fig. 1, the user BN logs in via Oauth2 of the company's IT system.

[0060] In substep S2.4, the login attempt is made on the ticket server TS. If this is successful (substep S2.5), in addition to the usual account tickets (substep S2.6), a login ticket is also created and transferred to the cryptowallet of the control unit BE (substep S2.7). Subsequently, the first communication connection between the control unit BE and the ticket server TS is terminated (substep S2.8).

[0061] The login ticket is encrypted with a shared symmetric key and secured with HMAC (e.g., ChaCha20-Poly1305). It contains the specified validity period and login information, such as the user name of user BN' and a password verifier (an intermediate value for a cryptographic 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. Alternatively to the password verifier, a plaintext password or a random temporary password can also be included. In process step S3, user BN' logs in to field device FG2. For this purpose, user BN' is on-site at field device FG1 and selects it to establish a connection (e.g., by selecting it from a LiveList) (substep S3.1).Instead of the usual login screen, where user BN' enters their login credentials, the cryptowallet now temporarily decrypts an existing, valid login ticket and transmits the contained login information, packaged in another ticket, specifically an account ticket, to field device FG1 (sub-step S3.2) for login. Field device FG1 decrypts (sub-step S3.3) the login information contained in the ticket and checks it for validity. If field device FG1 can verify it as valid and the login time is within the specified validity period, user BN' logs in to field device FG1 using their control unit BE'.

[0062] The field device FG1 can then be operated by the user BN' using the usual tickets (see, for example, DE 102019131860 A1), in particular account tickets.

[0063] This process step S3 can be repeated multiple times without the user BN' having to manually enter their login information (single sign-on). Login to other field devices FG2 is also possible if these have been previously selected by the user BN and are listed in the login ticket.

[0064] A special case of the inventive concept lies in the provision of a so-called emergency account for the field devices, see Fig. 3. In this case, a consistent emergency account is provided for all field devices FG1, FG2. The user BN' can access this account by manually entering login data or by means of a graphic code CD, which the control unit BE can optically read.

[0065] In the event of an emergency, user BN' accesses the graphic code CD or the login data (process step N1). This is located, for example, in an emergency box or a key box. In process step N2, user BN' opens the application on the control unit BE (process step N2) and enters the login data into the application or scans the graphic code (process step N3), whereupon the login data is read from the graphic code.

[0066] In process step N4, user BN4 selects the field device FG1 they wish to access in an emergency. In process step N5, the communication connection to the field device FG1 is established, and the login credentials are transmitted to the field device FG1. If the field device FG1 can successfully verify the transmitted login credentials, emergency access to the field device FG1 is granted. The emergency account grants access only to certain functionalities of the field device FG1.

[0067] After such an emergency, the password for the emergency account should be changed immediately on the ticket server TS and redistributed to all field devices FG1, FG2.

[0068] List of reference symbols

[0069] BE control unit

[0070] BN, BN' User CD graphic code

[0071] FG1 , FG2 field devices

[0072] N1, N2, N5 Emergency response procedures

[0073] SO, S1, S2, S2.1,... S3, S3.1.. Process steps including sub-steps

[0074] TS Ticket Server

Claims

Patent claims 1. A method for logging on a user (BN, BN') to one or more field devices (FG1, FG2) of automation technology, wherein a ticket server (TS) is provided for user management, wherein the ticket server (TS) and the field device or the field devices (FG1, FG2) are in a cryptographically secured and mutually trusting relationship and are designed for the mutual transmission and reception of tickets, wherein the tickets contain information about the intended recipient and cryptographically secured information, comprising: - activating a login mode on the ticket server (TS) for one or more selected field devices (FG1, FG2) by a user (BN, BN'), comprising setting a validity period for each field device (FG1, FG2); - Generation of a registration ticket by the ticket server (TS), wherein the registration ticket contains registration information and information on the specified validity period and is cryptographically encrypted; - Registration of an operating unit (BE) on the ticket server (TS) via a first communication connection between the operating unit (BE) and the ticket server (TS); - Transferring the registration ticket from the ticket server (TS) to the control unit (BE) after successful registration via the first communication connection; - Transferring the login ticket, or another ticket containing the login information, from the control unit (BE) to the field device or devices (FG1, FG2) via a second communication connection between the control unit (BE) and the field devices (FG1, FG2); and - Logging in of the user (BN, BN') to the field device or devices (FG1, FG2) if the corresponding field devices (FG1, FG2) can decrypt the login ticket or the additional ticket and verify that the login information contained in the login ticket or the additional ticket is valid, and if the login time is within the specified validity period.

2. The method according to claim 1, wherein the operating unit (BE) stores the registration ticket in a cryptographically secured cyberwallet of the operating unit (BE).

3. The method according to claim 1 or 2, wherein, in the event that the operating unit (BE) has not been made known to the ticket server (TS) in advance, a registration process of the operating unit (BE) on the ticket server (TS) is carried out before the step of registering the operating unit (BE) on the ticket server (TS), so that a cryptographically secured and mutual trust relationship is established between the operating unit (BE) and the ticket server (TS).

4. Method according to one of the preceding claims, wherein after expiry of the validity period, the operating unit (BE) is automatically logged off from the corresponding field devices (FG1, FG2).

5. The method according to any one of the preceding claims, wherein the login information includes a user name.

6. The method of claim 5, wherein the login information additionally includes a password verifier.

7. The method according to claim 5, wherein the registration information additionally contains a password, in particular in plain text.

8. The method according to one of claims 6 or 7, wherein the registration information is stored on the ticket server (TS) and is read out for the creation of the registration ticket.

9. The method according to claim 7, wherein the password is generated as a random temporary password by the ticket server (TS).

10. Method according to one of the preceding claims, wherein the user (BN, BN') must authenticate himself to the ticket server (TS) before the step of activating the login mode.

11. The method according to claim 10, wherein the authentication is carried out by entering user information, in particular user name and password, in particular which the user (BN, BN') uses for authentication in his IT office administration.

12. The method according to claim 10, wherein the ticket server (TS) is designed as an application in a cloud platform, wherein the ticket server uses the same user data for authentication as it also uses for authentication against the cloud platform.

13. Method according to one of the preceding claims, wherein an emergency account is provided which is present in all field devices (FG1, FG2) and consistent for all field devices (FG1, FG2), wherein the user (BN, BN') enters login data provided for the emergency account into the operating unit (BE) and / or wherein the operating unit (BE) obtains the login data provided for the emergency account by scanning a graphic code (CD), wherein the operating unit (BE) transmits the login data provided for the emergency account to one or more of the field devices (FG1, FG2) via a second data connection and wherein the user (BN, BN') is logged on to the respective field devices (FG1, FG2) if the respective field devices (FG1, FG2) can successfully verify the transmitted login data.

14. Method according to one of the preceding claims, wherein the first communication connection is established as an Internet connection.

15. Method according to one of the preceding claims, wherein the second communication connection is established as a wireless connection, in particular based on Bluetooth, Bluetooth LE or WiFi.

16. System designed to carry out the method according to one of claims 1 to 15, comprising at least one field device (FG1, FG2), a ticket server (TS) and an operating unit (BE).

17. System according to claim 16, wherein the operating unit (BE) is a mobile end device, in particular a tablet or a smartphone.

Images