EP4087184B1 - Method for authenticating interactions independent of a system time, and device for carrying out this method and flame monitor comprising such a device - Google Patents

Description

The invention relates to a method for the authentication of interactions in microcontrollers and/or FPGAs (Field Programmable Gate Array) independent of a system time. based devices or devices, in particular in embedded (engl .: "embedded") systems, and a device for performing this method and a flame detector with such a device.

In the case of interactions between devices communicating with one another, authentication is regularly required for security reasons in order to grant access to a requesting device and, for example, to grant corresponding authorizations on a certifying device. Authentication, i.e. the request for a registration with the assertion of an identity, with subsequent authentication, i.e. a check and validation of the assertion of the identity received, contributes significantly to securing digital access.

Authentication is the verification of an entity that it is actually who it claims to be. This proof should be able to confirm or check the identity. In the case of a so-called two-factor authentication or often also referred to as two-factor authentication (“2FA” for short), the security of the respective digital access is increased by another factor. "2FA" thus refers to the proof of identity of a user using the combination of two different and, in particular, independent authentication components or factors. Typical examples are bank card plus PIN for ATMs, fingerprint plus access code in buildings, or password and transaction number (TAN) for online banking. If access to a system cannot be regulated and limited by other measures, 2FA should always be used for security reasons.

In the IT environment, these two methods have been established for years. In the embedded environment, however, the query of a single common secret (e.g. password) is often the only protection for access to a system. Due to the increasingly complex industrial systems and the seamless connection to existing IT systems, improvements and adjustments must also be made in the embedded environment.

With this adjustment, common and established processes and algorithms, which are already established in the IT environment, should be used in order to be uniform and compatible with other areas. However, this is not always possible in the embedded environment, because, for example, there are not enough resources available, or the initial situations, which are common in IT, for example, differ too much from those in the embedded environment. Accordingly, adaptations of these processes are necessary in order to ensure cyber security when IT and OT are combined.

In contrast to conventional processors that are built into desktop computers, servers, smartphones or tablets, the present invention is about embedded systems that are used specifically to measure and record data or to control other components or systems.

An "embedded system" is understood to be a microcontroller system or an FPGA system that performs a dedicated task, is embedded or integrated into a surrounding system and interacts with or through this system. It serves in particular to measure, record and forward data or is used to control actuators, components or systems.

These embedded systems, i.e. microcontroller or FPGA-based devices and facilities, often have fewer computing resources and even more often only a very limited power supply compared to their powerful counterparts from the IT environment. The environment in which these activities are performed is often far from the ideal operating conditions for electronic components and is called an "embedded" environment.

If you take the example of a sensor for flow measurement, it is used, for example, on gas pipelines in extremely harsh environments and under very difficult operating conditions. For example, this can be a minimum temperature of -30°C or a maximum temperature of +100°C. Real-time capability can also be important for controlling the flow, for example to control valves accordingly. Constant movement, vibrations and other physical disturbances must also be taken into account for use, as must error-free operation despite electromagnetic interference pulses, for example. In addition, there is often no possibility of a permanent connection (e.g. data connections for monitoring or synchronization) to such a device. Even a constant, stable energy supply is often not assured. The same applies to flame detectors. A flame monitor serves to monitor the presence of a flame, for example at least in a partial area of a combustion chamber. An essential part of a flame monitor is a flame sensor for detecting a physical variable of a flame, in particular an intensity of electromagnetic radiation, and generating an associated electrical sensor signal.

Nevertheless, it is also necessary in the embedded environment, in particular in the environment of such sensors, to provide security mechanisms so that only authorized access to such systems from the outside is possible. However, the lack of resources, the difficult operating environment and possibly the lack of connection to data centers and servers represent a new, major challenge for the manufacturers.

The German patent application DE102019106528 is further state of the art.

Before the present invention is discussed in more detail here, however, it is necessary to first briefly explain some of the terms used below.

requesting device

The requesting device makes a request for access (e.g., a resource) from the notarizing device.

Notarizing Device

The certifying device checks the information from the requesting device for validity. If the check is positive, authentication is issued, otherwise access is denied.

OTP

OTP stands for "One-time Password". A one-time password or one-time password is a password used for authentication or authorization. Each one-time password should only be valid for a single use and therefore should not be used a second time.

Challenge Response

The challenge-response method (translated as a request-response method ) is a secure authentication method for a participant based on knowledge. Here, one participant presents a task ( challenge ) that the other must solve ( response ) in order to prove that he knows certain information (e.g. the algorithm used or a shared secret) without admitting this information himself transfer. This is a protection against the specific information (eg a password) being overheard by attackers on the line.

CLI (Command Line Interface)

A command line interface (CLI) accepts commands to a computer program in the form of lines of text.

IT

"IT" is the common term for the full range of information processing technologies, including software, hardware, communication technologies and related services. In general, IT does not include embedded technologies that generate data for business use.

OT

Operational Technology (OT) is hardware and software that detects or causes change through direct monitoring and/or control of physical devices, facilities, processes and events.

HMAC-SHA1

A Message Authentication Code (MAC; German: "Message Authentication Code") is used to obtain certainty about the origin of data or messages and to check their integrity. MAC algorithms require two input parameters, first the data to be protected and second a secret key. The MAC algorithms calculate a checksum from both, the message authentication code. A keyed-hash message authentication code (HMAC) is a message authentication code (MAC) whose construction is based on a cryptographic hash function, such as the Secure Hash Algorithm (SHA), and a secret key. The combination is called HMAC-SHA1, where the number 1 stands for the variant of the cryptographic hash function used.

truncation

In mathematics and computer science, truncation is the limitation of the number of digits to the right of the decimal point. Here it means shortening the length of a given output value. A truncated value is therefore a value that has been shortened in length.

OTP token digits

The number of OTP token digits describes the number of digits and thus the length that a calculated OTP token must have.

Various authentication methods are currently known and used. The OTP method is one of the most commonly used methods for 2FA. In particular, there are three common implementation options for the OTP process.

HOTP - " HMAC-based One-time Password Algorithm " (a definition of this algorithm can be found in the publicly accessible document "Request for Comments No. 4226", abbreviated: RFC 4226)

A shared secret (OTP key) between the user's device and the authenticating device is required to log the user in using cryptographic algorithms and a counter that increments with each login attempt.

This counter must always be in the synchronized range on both the authenticating device and the requesting device of the user, because only then can a resulting calculation of a common token (e.g. 6-8 OTP token digits) be recognized as valid .

The problem with the HOTP procedure is that the counters of both devices, i.e. the requesting and the authenticating device, must always be within a predefined range of one another. If a HOTP generator is used for multiple authenticating devices, the counter on the requesting device increments at a different interval than on the authenticating devices.

HOTP example:

- Three authenticating devices (A, B, C)
- A requesting device Login 1 to authenticating device "A" Counter authenticating device "A" = 1 Counter requesting device = 1 Login 1 to authenticating device "B" Counter authenticating device "B" = 1 Counter requesting device = 2 Login 1 to authenticating device "C" Counter authenticating device "C" = 1 Counter requesting device = 3 Logon 2 to authenticating device "A" Counter authenticating device "A" = 2 Counter requesting device = 4

Keeping the counter of the requesting device synchronized with the counter of the authenticating devices is not possible, they "drift" further apart with each new registration.

A requesting device can therefore only ever be used to access one authenticating device. It is therefore not possible to use a single HOTP key for authentication at multiple authenticating devices. This means that, for example, for a requesting device to access several hundred authenticating devices, several hundred HOTP keys must also be used and managed, since the counter values for each HOTP key can differ from one another.

TOTP - "Time-based One-time Password Algorithm" (a definition of this algorithm can be found in the publicly accessible document "Request for Comments No. 6238", abbreviated: RFC 6238)

A shared secret (OTP key) between the user's device and the authenticating device is required using cryptographic algorithms and the current, shared time of the authenticating and requesting device to log in the user. This time must always be synchronous on both the authenticating device and the requesting device of the user in order to recognize a resulting calculation of a common token (e.g. 6-8 OTP token digits, cyclically changing) as valid. If a TOTP generator is used for registration, it must be ensured that all devices involved use the same time for calculation. Especially in the industrial environment (sensors, actuators, controllers), time synchronization is rare and sometimes not provided at all or even impossible. The more the time stamps used by the requesting and authenticating device, from which the TOTP tokens are derived, deviate from each other within the tolerated TOTP time interval, i.e. the specified period of validity of a TOTP token, the more difficult it is to register, since the acceptance window for the TOTP token is getting smaller and smaller. If the deviation is greater than the TOTP time interval, registration is no longer possible. If a TOTP procedure is aimed at, it is imperative that there is a synchronized time on both devices, both on the requesting and on the authenticating device.

OCRA - "OATH Challenge-Response Algorithm" ( a definition of this algorithm can be found in the generally accessible document "Request for Comments No. 6287", in short: RFC 6287)

The challenge-response method is a generally accepted method that serves the use cases and scenarios that users who cannot use a synchronized authentication system are provided with an asynchronous variant of an authentication system. Such a challenge-response mode for authentication is known. Several manufacturers already offer software applications and hardware devices that implement a challenge-response method - but each of them disadvantageously uses manufacturer-specific, proprietary algorithms. By using OCRA, the manufacturer-specific, proprietary challenge-response procedure is applied in a uniform, standardized and therefore also manufacturer-independent way. The use of countless, manufacturer-specific implementations and the waiver of the standardized solution using OCRA is probably the reason why there are no hardware dongles for the OCRA process on the market that allow automated use. Proprietary variants, on the other hand, are still common. Thus, the use of a challenge-response procedure using hardware dongles requires a fixed connection and the associated dependency of a dongle on a specific manufacturer, which in systems with components from a wide variety of manufacturers precludes the use of hardware dongles for the OCRA procedure .

Based on figure 6 this OCRA method for authentication is briefly explained. It is assumed that single-factor authentication takes place.

In this case, a requesting device 10 communicates with a notarizing device 30. The requesting device 10 has an interface to which an OCRA generator 2 is connected in terms of hardware or implemented in terms of software. The notarizing device 30 has an identical OCRA generator 1 from the same manufacturer. In order to carry out an authentication method between the requesting device 10 and the authenticating device 30 , a shared secret S is stored in the requesting device 10 and in the authenticating device 30 . This shared secret S is stored in the OCRA generator 2 in the requesting device 10 and in the OCRA generator 1 in the authenticating device 30 .

The following process steps are carried out. The requesting device 10 sends an authentication request OCRA to the authenticating device 30 via a communication channel (step 1). The authenticating device 30 then generates a random value as predefinable information R (step 2). This information R is then transmitted to the requesting device 10 (step 3). The requesting device 10 then submits an OCRA request with the information R to the OCRA generator 2 (step 4). The query is forwarded to the OCRA generator 2 so that the O'CRA response to the predefinable information R can be calculated there (step 5). The requesting device 10 receives the calculated O'CRA response from the OCRA generator 2 (step 6). This O'CRA response is then transmitted to the notarizing device 30 (step 7). In order to perform the comparison of the received O'CRA response, the notarizing device 30 itself calculates an OCRA response. This OCRA response is based on the predeterminable information R generated in step 2, ie the previously generated random value (step 8).

The notarizing device 30 then compares the received O'CRA response to the self-calculated OCRA response (step 9). The authenticating device 30 transmits the status of the authentication process, whether it was successful or failed, to the requesting device 10 (step 10). If the authentication process was successful, i.e. the O'CRA response was identical to the OCRA response, an interaction requested by the requesting device 10 is carried out, otherwise it is blocked.

However, as mentioned above, the problem with this known OCRA method is that the manufacturers regularly use their own, manufacturer-specific and thus proprietary algorithms to carry out a challenge-response method and the users are therefore always forced to use challenge-response generators from the same manufacturer use, which runs counter to a broad and mass application of the OCRA authentication method.

The present invention is based on the object of specifying a method and a device for authentication that is independent of a system time and which enables interactions in microcontroller-based and/or FPGA-based devices or devices and in particular in embedded systems and/or flame monitors. In addition, the aim of the invention is also to provide a device for carrying out such a method and to provide a flame detector with such a device.

This object is achieved by a method having the features of claim 1.

Developments of this method are the subject of dependent claims 1 to 11.

An apparatus for carrying out the method is the subject of claim 12. A flame detector according to the present invention is the subject of claim 14.

The method according to the invention therefore provides the following for the authentication of interactions in microcontroller- and/or FPGA-based devices or devices, in particular embedded systems and/or flame monitors, independent of a system time: It is carried out in a requesting device and in a certifying device a cryptographic hash value, which can also be in truncated form, is calculated in accordance with a common shared secret used by both devices and in both devices in a TOTP module working according to the TOTP method. Instead of a system time, the TOTP modules are supplied with predeterminable information for calculating the respective hash value in such a way that the predeterminable information (e.g. a random value) is generated or provided by the authenticating device and transmitted to the requesting device when the requesting device requests it becomes. There it is then fed to the local TOTP module to calculate its own hash value and the hash value calculated there is then transmitted to the authenticating device. If this hash value received from the authenticating device matches the hash value calculated in the authenticating device using the specified information, successful authentication has been carried out and the interaction is released. Otherwise, if there is a mismatch, the interaction will be blocked.

In a preferred embodiment of the invention, the TOTP module assigned to the requesting device is a hardware dongle that can be externally plugged into the requesting device. Provision can be made for the authentication procedure to be started automatically when the hardware dongle is plugged in.

The interactions mentioned can be, for example, configuration, update, parameterization, input, measurement, switching, monitoring and/or control functions in devices or facilities based on microcontrollers and/or FPGAs.

In another development of the invention, it can be provided that at least one of the TOTP modules is realized as a software implementation directly in the requesting device and/or authenticating device. Such a software implementation is preferably implemented in the authenticating device.

In addition, it is possible that, in order to implement a 2FA, a preliminary authentication request with specified access data is sent from the requesting device to the authenticating device or is entered directly there and a further authentication request is only made possible if the validity check is successful.

It is also within the scope of the present invention for a password and/or a user name and/or a certificate to be used as access data. The access data can be stored on a wireless or wired chip unit, in particular a smart card or a USB module.

In a further development of the invention, it is provided that the information that can be specified is a random value which, in one embodiment, can be selected from a specified list of values.

It is also possible for one and the same shared secret to be used for authentication by multiple requesting devices.

The invention also claims independent protection for a flame arrester. Because a particularly suitable field of application of the method according to the invention is that it can be used with sensors, in particular with flame detectors.

The method according to the invention can also be used advantageously in other sensor systems, such as flow sensors, level sensors, etc.

A device according to the invention for carrying out the method is characterized as follows: A microcontroller and/or FPGA-based device, such as a flame monitor, is provided for the authentication of interactions independently of a system time, in which in each case in a requesting device and in a certifying A cryptographic hash value device, which can optionally be in truncated form, can be calculated in accordance with a shared secret used by both devices and in both devices in a TOTP module that works according to the TOTP method, with the TOTP - Modules instead of a system time a predetermined information for calculating the respective hash value can be supplied. This is done in such a way that the information that can be specified can be generated or made available by the authenticating device and when there is a request from the requesting device can be transmitted to the requesting device, where it can then be fed to the local TOTP module for calculating a hash value and the hash value calculated there can be transmitted to the authenticating device, and that if this hash value, which can be received from the authenticating device, matches a hash value calculated in the authenticating device with the predefinable information, successful authentication can be carried out and the interaction can be released and otherwise blocked in the event of a mismatch.

Such a device can particularly preferably be embodied in an embedded system.

The present invention avoids the problems mentioned in the HOTP, TOTP and OCRA methods in a simple manner in that the known TOTP method with its disclosed TOTP algorithm is used, but instead of the system time required for this, predeterminable information, in particular a predeterminable random value, is used. Thus, advantageously, no proprietary algorithms are used.

In a preferred embodiment of the invention, a commercially available hardware dongle, which can be embodied, for example, as a USB stick or smart card or the like, is used with the TOTP algorithm. The hardware dongle must allow the time to be used to be set manually. According to the invention, this hardware dongle receives an adapted transfer value in the form of predeterminable information (e.g. random value) instead of the system time stamp.

As described above, embedded devices often only have a limited system performance and there is often no synchronized system timestamp available. The method according to the invention, on the other hand, enables authentication on a terminal that is independent of the system time stamp. A single hardware dongle can be used for authentication on multiple end devices, ie authenticating devices.

The feasibility of the method according to the invention has already been demonstrated in tests. An implementation of the TOTP procedure and a manual setting of the time with two different TOTP-capable hardware dongles from two different hardware manufacturers was tested. As an example, here are the hardware dongles "Nitrokey Pro 2" (see https://shop.nitrokey.com / de DE / shop / product / nk- pro -2-nitrokey-pro-2-3 ) and the "OnlyKey " (see https: // onlykey.io / de called ). Using their CLI interface, a command can be used to pass a value (usually a time value) to the TOTP generator as input for generating a TOTP token. The two hardware dongles mentioned serve only as an example. The method according to the invention can be implemented with any hardware or software generator for TOTP tokens, provided that the time for calculating the TOTP token can be set manually there.

A Nitrokey Pro 2 or OnlyKey is a USB security module for processing specific cryptographic tasks. This can be used, among other things, for the administration and use of OTP keys. Up to 24 OTP keys can be managed simultaneously on the Nitrokey Pro 2. These are stored in so-called slots. When requesting a TOTP token, the slot is specified. Depending on the selected slot, the associated OTP key used for TOTP token generation. This TOTP token is then returned.

Figur 1

einen prinzipiellen Ablauf des erfindungsgemäßen Verfahrens,

Figur 2

ein Blockschaltbild einer Durchflusssensoreinrichtung,

Figur 3

ein beispielhaftes Ablaufdiagramm eines Authentifizierungsverfahrens für einen Durchflusssensor gemäß Figur 2,

Figur 4

ein Blockschaltbild einer Kransteuerung,

Figur 5

ein beispielhaftes Ablaufdiagramm eines Authentifizierungsverfahrens für eine Kransteuerung gemäß Figur 4, und

Figur 6

den bereits eingangs beschriebenen, prinzipiellen Ablauf eines bekannten OCRA-Authentifizierungsverfahrens.

The present invention is explained in more detail below using exemplary embodiments and flowcharts. Show it:

figure 1

a basic sequence of the method according to the invention,

figure 2

a block diagram of a flow sensor device,

figure 3

an exemplary flow chart of an authentication method for a flow sensor according to FIG figure 2 ,

figure 4

a block diagram of a crane control,

figure 5

an exemplary flow chart of an authentication method for a crane controller according to FIG. 4, and

figure 6

the basic process of a known OCRA authentication method already described at the beginning.

This in figure 1 The flowchart shown shows an example of a possible process for authenticating interactions in a microcontroller- and/or FPGA-based device or device, as can be used in embedded systems and/or flame detectors in particular. It is essential that this method for authentication is carried out with a conventional TOTP module, but is independent of a system time as required.

The TOTP module can be implemented in software in the device or device or plugged into the device or device as a hardware dongle.

This in figure 1 The procedure outlined can be implemented as a single-factor (option B) or as part of a multi-factor authentication, here a 2FA (option A).

• 1a (nur A) - Authentifizierungs-Anfrage des anfragenden Geräts 10 mit Zugangsdaten:
  Das anfragende Gerät 10 stellt über einen beliebigen Kommunikationskanal, der drahtgebunden oder drahtlos ausgebildet sein kann, eine Authentifizierungs-Anfrage an das beglaubigende Gerät 30. Ebenfalls ist eine Authentifizierungs-Anfrage via Direkteingabe, z.B. über eine Tastatur oder einen Bildscanner oder Ähnlichem am beglaubigenden Gerät 30 möglich. Die Authentifizierungs-Anfrage beinhaltet Zugangsdaten Z, z.B. aber nicht darauf begrenzt: ein Passwort, Nutzername und Passwort, Zertifikat oder Smart-card usw..
• 1b (nur A) - Prüfung der Zugangsdaten des anfragenden Geräts 10:
  Das beglaubigende Gerät 30 prüft die Validität der erhaltenen Zugangsdaten Z.
• 1 (nur B) - Authentifizierungs-Anfrage des anfragenden Geräts:
  Das anfragende Gerät 10 stellt über einen beliebigen Kommunikationskanal, der ebenfalls drahtgebunden oder drahtlos sein kann, eine Authentifizierungs-Anfrage TOTP an das beglaubigende Gerät 30. Ebenfalls ist eine Authentifizierungs-Anfrage via Direkteingabe am beglaubigenden Gerät 30 möglich.
• 2 - Erzeugung der vorgebbaren Information R auf dem beglaubigenden Gerät:
  Das beglaubigende Gerät 30 generiert eine vorgebbare Informationen R, z. B. einen Zufallswert, im Wertebereich des TOTP-Verfahrens. Anstatt der Generierung einer vorgebbaren Information R können ebenfalls vordefinierte, andere Informationen, z.B. Zahlenwerte aus einer Liste genutzt werden. Eine Kombination aus Beidem ist ebenso möglich.
• 3 - Übertragung der vorgebbaren Information R zum anfragenden Gerät 10:
  Die vorgebbare Information R muss, über einen beliebigen Kommunikationskanal an das anfragende Gerät 10 übertragen werden. Dies kann über eine Antwort auf die Authentifizierungs-Anfrage oder mit einer eigenen Anfrage an das anfragende Gerät 10 umgesetzt werden. Ebenso ist eine optische Ausgabe auf dem beglaubigenden Gerät 30 möglich. Diese muss dem anfragenden Gerät 10 durch Eingabe oder Abscannen übergeben werden.
• 4 - Anfrage an den TOTP-Generator des anfragenden Gerätes 10:
  Das anfragende Gerät 10 stellt eine TOTP-Anfrage mit der vorgebbaren Information R (RTOTP-Anfrage) als fiktiven Zeitstempel an den TOTP-Generator 12. Die Anfrage wird an einen extern durch Einstecken in einen entsprechenden Steckanschluss in das anfragende Gerät 10 angebundenen TOTP-Generator 12, insbesondere einen Hardware-Dongle, weitergegeben. Anstelle eines einsteckbaren Hardware-Dongles kann der TOTP-Algorithmus im anfragenden Gerät 10 auch mittels einer Software-Implementierung realisiert sein.
• 5 - Berechnung des R'TOTP
  Durchführung der TOTP Berechnung mit der vorgebbaren Information R auf dem TOTP-Generator 12 entsprechend der Anfrage. Diese Berechnung kann von dem Hardware-Dongle oder einer Software-Implementierung umgesetzt werden.
• 6 - Antwort des TOTP-Generators 12:
  Das anfragende Gerät 10 erhält die R'TOTP-Antwort des TOTP-Generators 12. Das im TOTP-Generator 12 errechnete Ergebnis ist ein Hash-Wert, der als trunkierter Hash-Wert R'TOTP an das anfragende Gerät 10 weitergegeben wird.
• 7 - Übertragung der R'TOTP-Antwort zum beglaubigenden Gerät 30:
  Die R'TOTP-Antwort muss, über einen beliebigen Kommunikationskanal an das beglaubigende Gerät 30 übertragen werden. Ebenso ist eine direkte Eingabe der R'TOTP-Antwort am beglaubigenden Gerät 30 möglich, sofern keine Verbindung zwischen anfragendem Gerät 10 und beglaubigendem Gerät 30 besteht.
• 8 - Berechnung des Vergleichswerts auf dem beglaubigenden Gerät 30:
  Für die Durchführung des Vergleichs der empfangenen R'TOTP-Antwort muss das beglaubigende Gerät 30 selbst ebenfalls eine RTOTP-Antwort basierend auf zuvor erzeugter vorgebbarer Information R berechnen. Die Berechnung des Vergleichswerts kann zu einem beliebigen Zeitpunkt nach Schritt 2 und vor Schritt 9 durchgeführt werden.
• 9 - Vergleich der RTOTP-Antworten:
  Abschließend muss das beglaubigende Gerät 30 die empfangene R'TOTP-Antwort mit der selbst berechneten RTOTP-Antwort vergleichen. Nur wenn diese identisch sind, ist die Prüfung der R'TOTP-Antwort erfolgreich.
• 10 - Übertragung vom Authentifizierungsstatus:
  • Das beglaubigende Gerät 30 überträgt den Status des Authentifizierungsvorgangs, ob dieser erfolgreich war oder fehlgeschlagen ist, an das anfragende Gerät 10.
  • Der Authentifizierungsvorgang ist erfolgreich, wenn die Prüfung der RTOTP-Antwort aus Schritt 9 erfolgreich war und bei Option A zusätzlich die Prüfung der Validität der Zugangsdaten Z ergeben hat, dass die Zugangsdaten valide sind. War der gesamte Authentifizierungsvorgang erfolgreich, wird die angefragte Interaktion durchgeführt, andernfalls nicht freigegeben und gesperrt.

The time course of the authentication method in Figure 1 is as follows:
It is assumed that a requesting device 10 communicates with an authenticating device 30 . The requesting device 10 has an interface to which a so-called TOTP generator 12 can be connected. This TOTP generator 12 can be implemented in a hardware dongle, for example. Such a hardware dongle is generally designed as a USB stick. The notarizing device 30 also has a TOTP generator 32 . This is preferably implemented in software in the authenticating device 30 . In order to carry out an authentication method between the requesting device 10 and the authenticating device 30 , a so-called shared secret S is stored in the requesting device 10 and in the authenticating device 30 . In the requesting device 10, this shared secret S is preferably stored in the pluggable TOTP generator 12, ie preferably in the hardware dongle mentioned. The following process steps are carried out.

• 1a (A only) - authentication request from the requesting device 10 with access data:
  The requesting device 10 sends an authentication request to the notarizing device 30 via any communication channel, which can be wired or wireless. There is also an authentication request via direct input, e.g. via a keyboard or an image scanner or the like on the notarizing device 30 possible. The authentication request includes access data Z, e.g. but not limited to: a password, username and password, certificate or smart card, etc.
• 1b (A only) - Checking the access data of the requesting device 10:
  The authenticating device 30 checks the validity of the access data Z received.
• 1 (B only) - authentication request from the requesting device:
  The requesting device 10 sends an authentication request TOTP to the authenticating device 30 via any communication channel, which can also be wired or wireless. An authentication request via direct entry at the authenticating device 30 is also possible.
• 2 - Generation of the predeterminable information R on the authenticating device:
  The authenticating device 30 generates a predetermined information R, z. B. a random value in the value range of the TOTP procedure. Instead of generating predeterminable information R, other predefined information, for example numerical values from a list, can also be used be used. A combination of both is also possible.
• 3 - Transmission of the predeterminable information R to the requesting device 10:
  The information R that can be specified must be transmitted to the requesting device 10 via any communication channel. This can be implemented via a response to the authentication request or with a separate request to the requesting device 10. Optical output on the notarizing device 30 is also possible. This must be passed to the requesting device 10 by entering or scanning.
• 4 - Request to the TOTP generator of the requesting device 10:
  The requesting device 10 makes a TOTP request with the predefinable information R (RTOTP request) as a fictitious time stamp to the TOTP generator 12. The request is connected to an external TOTP generator by plugging it into a corresponding plug-in connection in the requesting device 10 12, in particular a hardware dongle. Instead of a hardware dongle that can be plugged in, the TOTP algorithm can also be implemented in the requesting device 10 by means of a software implementation.
• 5 - Calculation of the R'TOTP
  Implementation of the TOTP calculation with the predeterminable information R on the TOTP generator 12 according to the request. This calculation can be performed by the hardware dongle or a software implementation.
• 6 - TOTP Generator 12 Response:
  The requesting device 10 receives the R'TOTP response from the TOTP generator 12. The result calculated in the TOTP generator 12 is a hash value which is forwarded to the requesting device 10 as a truncated hash value R'TOTP.
• 7 - Transmission of the R'TOTP response to the notarizing device 30:
  The R'TOTP response must be transmitted to the notarizing device 30 over any communication channel. A direct input of the R'TOTP answer on the authenticating device 30 is also possible if there is no connection between the requesting device 10 and the authenticating device 30 .
• 8 - Calculation of the comparison value on the notarizing device 30:
  In order to carry out the comparison of the received R'TOTP response, the authenticating device 30 itself must also calculate an RTOTP response based on predeterminable information R generated beforehand. The comparison value can be calculated at any time after step 2 and before step 9.
• 9 - Comparison of RTOTP responses:
  Finally, the notarizing device 30 must compare the received R'TOTP response with the self-calculated RTOTP response. The check of the R'TOTP response is only successful if these are identical.
• 10 - Transmission of authentication status:
  • The authenticating device 30 transmits the status of the authentication process, whether it was successful or failed, to the requesting device 10.
  • The authentication process is successful if the check of the RTOTP response from step 9 was successful and, in the case of option A, the check of the validity of the access data Z has also shown that the access data are valid. If the entire authentication process was successful, the requested interaction is carried out, otherwise not released and blocked.

The advantages of the authentication method according to the invention become clear on the basis of the representation of the principle mode of operation of the authentication method. Only the requesting device 10 and the authenticating device 30 need to know a common shared secret S, preferably stored. This shared secret S is preferably stored in a non-readable manner. Furthermore, predeterminable information R, e.g. a generated random value or a random value from a list, is entered at the requesting device 10 and converted into a truncated hash value R′TOTP using a conventional TOTP generator 12 . The authenticating device 30, which also knows the predeterminable information as required, calculates its own truncated hash value RTOTP using the TOTP module 32 present there. If the two truncated hash values match, the authentication via the TOTP modules 12, 32 is successful.

Based on figures 2 and 3 a specific exemplary embodiment of the method according to the invention is illustrated using a sensor such as a flow sensor used in a flow measurement pipeline. However, instead of a flow sensor, another sensor, in particular a flame detector or the like, could also be a possible application in which the method according to the invention is used. Such a flame monitor is used, for example, to detect whether there is a flame in a burner or not.

With such sensors, it is imperative that only trained and authorized personnel have access to these sensors. This applies in particular to the maintenance, monitoring, parameterization, configuration, updating and control of these sensors. The method according to the invention is ideally suited here.

For example, in order to be able to correctly bill the amount of liquid passed through, the flow sensor must be correctly configured and calibrated. A manipulated calibration or flow measurement can cause considerable economic damage. To do this, it is imperative to secure access to the flow sensor and only allow authorized persons.

The block diagram of a flow sensor device shows figure 2 . It shows a flow sensor 50 which, for example, is mounted directly on a pipeline (not shown) in order to record the flow rate there. Away from this, for example in a control center of a waterworks, there is a terminal 52 or a PC, via which a connection to the flow sensor can be established wirelessly (for example a WLAN connection). At Terminal 52 there is a slot for this, into which a hardware dongle 54 with an integrated TOTP generator can be plugged in by an operator.

In the example mentioned, the user or the operator does not log on to the terminal 52, but the user logs on directly to the flow sensor 50 using the method according to the invention. The flow sensor 50 itself is the authenticating device and the terminal 52 is the requesting device within the meaning of the present invention device. The service technician has access to the terminal 52 and inserts a hardware dongle 54 configured for the respective flow sensor 50 into the terminal 52 . The terminal 52 now establishes a connection to the flow sensor 50, preferably after a previous request for a PIN from the user for the hardware dongle 54. Only when the previously stored, common shared secret S is known on both sides and the RTOTP token is therefore calculated identically on both sides, can the user register from the terminal 52 and thus configure or calibrate the flow sensor 50 .

The RTOTP token is calculated on the part of the terminal 52 in the hardware dongle 54 plugged in there. Correspondingly, no fixed assignment of a specific terminal 52 to a flow sensor 50 is necessary. The loss or theft of the terminal 52 is also not a critical incident, since no authentication data for logging on to the flow sensor 50 can be stolen and therefore no unauthorized configuration of the flow sensor 50 is possible with the terminal 52 alone.

A sequential check of the further availability of the hardware dongle 54 at the sensor terminal 52 can also ensure that a configuration/calibration is only possible when the hardware dongle 54 is plugged in. If the hardware dongle 54 is removed, the user is logged off from the flow sensor 50.

If the user takes a break, for example, he takes the hardware dongle 54 with him. An unauthorized configuration is therefore not possible even with unprotected access to the terminal 52. However, unauthorized access to the hardware dongle 54 should be avoided. A physical and physical key in the form of the hardware dongle 54 is thus used to register at a digital interface.

The functional sequence in detail is based on 3 as follows.

In 3 is an example of the flow of communication for authentication in chronological order. For this purpose, the flow sensor 50 communicates wirelessly or by wire with a terminal 52 into which a hardware dongle 54 of a user or user 56 can be plugged. This hardware dongle 54 has an internal TOTP generator in which a shared secret S is stored. This shared secret S is also stored in the flow sensor 50 . The flow sensor 50 also has an internal TOTP generator that is implemented in the form of a TOTP module that can be implemented in software.

It is assumed that the user 56 wants to read data from the flow sensor 50 . For this purpose, the user 56 must legitimize that he is also authorized for this readout is. The authentication method according to the invention is already used for this.

In a first step 300 the user 56 inserts his hardware dongle 54 into the sensor terminal 52 . When this hardware dongle 54 is plugged in, a configuration command is sent to the sensor terminal 52 in a subsequent step 302 . In step 304, the sensor terminal 52 waits for such a configuration command. As soon as this configuration command has been received, in step 306 the sensor terminal 52 sends an authentication request to the flow sensor 50. In step 308 an RTOTP request is generated in the flow sensor 50 and the sensor terminal 52 is queried. This request is awaited in step 310 in the sensor terminal 52 . In the RTOTP request from the flow sensor 50 to the sensor terminal 52 , information R that is provided in the flow sensor 50 and that can be specified as a random value, for example, or can be derived from a previously stored list of values, is communicated to the sensor terminal 52 . In step 310, the sensor terminal 52 learns the predefinable information R for the later calculation of an associated hash value or truncated hash value. In the subsequent step 312, the sensor terminal 52 sends an RTOTP request to the hardware dongle 54, in which the predefinable information R is made available to the TOTP generator in the hardware dongle 54 as a fictitious time stamp.

In order to make the authentication process even more secure, 3 additional authentication is carried out with the hardware dongle. For this purpose, the user 56 must identify himself as an authorized person on the hardware dongle by entering a PIN. This is done in step 314. The user is prompted to enter a PIN. Instead of such a PIN entry, it is also possible to insert a smart card, it may be necessary to place a finger on a suitable fingerprint sensor or similar. In step 316, the user 56 enters a PIN. The hardware dongle 54 waits for this input in step 318 . As soon as the PIN has been entered by the user 56, it is checked in step 320 whether the PIN input was correct or not. If the PIN input was not correct, an error message occurs in step 322, which is transmitted from the hardware dongle 54 to the sensor terminal 52. If, on the other hand, the PIN input in step 320 was correct, in step 324 the truncated hash value R′TOTP is calculated. This value is transmitted to the sensor terminal 52 in step 324 . There, in step 326, the R'TOTP response is awaited.

The sensor terminal 52 determines in step 328 whether an error message or an R'TOTP response was previously received in step 326 . If an error message has been received, an error message occurs in a subsequent step 330 and a configuration or a reading of the flow sensor 50 is blocked.

If, on the other hand, it has been recognized in step 328 that there is no error message but rather an R'TOTP response has been received, then in a subsequent step 332 this R'TOTP response is sent to the flow sensor 50 . An internal calculation of a separate truncated hash value RTOTP has previously taken place in the flow sensor 50 in an internal calculation step 309 . For this purpose, a conventional TOTP generator is used in the flow sensor 50, which, instead of a time stamp, is provided with exactly that predeterminable information R that was previously also sent to the sensor terminal 52 in step 308. In the TOTP generator of the flow sensor A truncated hash value RTOTP is calculated from this. In step 334, the R'TOTP response from the sensor terminal 52 is awaited. As soon as such an R'TOTP response from the sensor terminal 52 arrives at the flow sensor 50, the R'TOTP response from the sensor terminal 53 is compared there in step 336 with the calculated RTOTP value according to step 309 in the flow sensor 50. This comparison takes place in step 336. A decision is then made in step 338 as to whether or not the comparison of the two values was correct. If the comparison in step 338 shows that the two values are not correct, an error is sent to the sensor terminal 52 in step 340 . In step 342, the sensor terminal 52 waits for a response from the flow sensor 50. If, on the other hand, the comparison is positive, i.e. the values R'TOTP calculated in the sensor terminal 52 and RTOTP calculated in the flow sensor 50 are identical, then in the Step 344 communicated to the sensor terminal 52 a confirmation of the authentication, ie a correct authentication.

In the sensor terminal 52, depending on the comparison result in step 338, a decision is made as to whether the authentication was successful or not. This takes place in step 346. If the authentication of the truncated hash values R'TOTP and RTOTP was not successful, an error is displayed and step 330 is jumped to. However, if the authentication of the truncated hash values was successful, in step 348 a configuration command is sent to the flow sensor 50, which in step 350 waits for this. In step 352, the configuration command is triggered in the flow sensor 50 and, if necessary, it is signaled that a positive authentication has taken place. If this is the case, the user 56 can den Read out the flow sensor 50, configure it, provide it with a new update, parameterize it and so on.

Although related to figure 3 and steps 314 to 320 also involve entering a PIN and thus additional authentication of the user with the hardware dongle, such a PIN entry is only optional. The method described can take place without such a PIN entry. However, the authentication is then less secure. In particular, successful authentication with a stolen hardware dongle cannot be prevented.

In a second embodiment, in the figures 4 and 5 is illustrated, a crane controller 72 of a crane unit 70 (for example a loading bridge or a lattice boom crane) is presented. In this case, the method according to the invention for authentication is again used.

The following conditions should apply in this exemplary embodiment. The crane unit 70 is controlled by radio. Only trained and authorized personnel may have access to the storage location of a remote control of the crane control 72. Only this authorized personnel also has access to the hardware dongle 74 belonging to the crane unit 70. It is a prerequisite that a common shared secret S is stored in the crane unit 70 and in the hardware dongle 74.

Typically, an operator always logs on with an interaction between man and machine. This is often error-prone or is implemented unsafely by humans. For example, there is no logout from the system if an operation is interrupted for a short time. Similar to on a Windows PC, on which a screen lock is activated when leaving the workplace, the cyber security in the operation of a crane unit, which represents an embedded environment, can be significantly increased by an easy-to-use authentication measure.

The risk of a radio-based authentication attack on the control of the crane unit 70 can also be greatly reduced by a second authentication factor since no static authentication data is used.

In the present example, the crane driver 76 does not log on to the remote control of the crane controller 70. Instead, the remote control authenticates itself to the crane unit 70 using the method according to the invention. For this purpose, the crane driver 76 has access to the remote control and inserts a hardware Dongle 74 into the remote control of the crane control 72. The remote control establishes a connection to the crane unit 70 via the method according to the invention. Only when the shared secret S is known on both sides and the RTOTP response is therefore calculated identically on both sides can the remote control of the crane controller 70 be registered and thus the crane unit controlled. The RTOTP response is calculated on the part of the remote control in the hardware dongle 74, which must be plugged into the remote control. Correspondingly, no fixed assignment of a specific remote control to a crane unit 70 is necessary. The loss or theft of the remote control is also no longer a critical incident, since the remote control does not contain any authentication data for logging on to a crane unit 70 and therefore none malicious control of a crane unit is no longer possible. However, attention must be paid to the hardware dongle 74 or its loss must be avoided.

A sequential check of the continued availability of the hardware dongle 74 on the remote control can also ensure that crane control is only possible if the hardware dongle 74 is plugged into the remote control. If the hardware dongle 74 is removed, the remote control logs off from the crane unit 70, preferably automatically. If the crane operator 76 takes a break, for example, he takes the hardware dongle 74 with him. Unauthorized operation of the crane unit 70 is therefore no longer possible, even with unprotected access to the remote control of the crane control 72.

In figure 5 the flow chart of an authentication of a crane operator 76 on a crane unit 70 is shown over time. The crane driver 76 is supposed to control the crane unit 70 via a crane controller 72 . The crane controller 72 is equipped with a hardware dongle 74 that represents a physical and physical authorization code for an authorized crane operator 76 . A TOTP module in the form of a TOTP generator is integrated in the hardware dongle 74 . In addition, a shared secret S is stored in the hardware dongle 74 . This shared secret S is also stored in the crane unit 70 . A TOTP generator is also integrated in the crane unit 70 . The function sequence with which the crane controller 72 legitimates itself in order to be allowed to operate the crane unit 70 is as follows:
In step 700, the crane operator 76 plugs the hardware dongle of the crane controller 72 into the crane controller 72, e.g. B. the one for it provided remote control, a. In step 702, the crane driver 76 then sends a control command to the crane controller 72. In step 704, the crane controller 72 waits for such a control command. In the subsequent step 706, the crane controller 72 sends an authentication request to the crane unit 70. There, in step 708, a so-called RTOTP request is generated by providing specified information R, which is randomly generated, for example, or can be taken from a list of values. This predeterminable information R is transmitted back to the crane controller 72 in the form of an RTOTP request, which waits for this in step 710 . In step 712, an inquiry is generated in the crane controller 72 from this inquiry and the transmitted predeterminable information R, which inquiry is sent to the hardware dongle 74 as an RTOTP inquiry. In step 714, an R'TOTP response is then generated in the hardware dongle 74 using the predefinable information R in the TOTP generator there and sent to the crane controller 72, which in step 760 waits for such a response. In the subsequent step 718, the crane controller 72 sends this R'TOTP response, i.e. a truncated hash value, to the crane unit 70. In step 720, the crane unit 70 waits for such a response from the crane controller 72. Before that, in the crane unit 70 an RTOTP response has been calculated in step 709 in the TOTP generator there using the aforementioned predeterminable information R. This is again a truncated hash value. In step 722, the value RTOTP of the crane unit 70 and the received value R'TOTP of the crane controller 72 or the hardware dongle 74 connected there are compared. In step 724 the result of the comparison from step 722 is determined. If the comparison does not yield a matching result, in step 726 an error is sent to the crane controller 52, which in step 728 responds to a Crane unit 70 response awaits. At the same time, in step 730 a result of the authentication is awaited and in step 732 an error is displayed, which signals that the comparison between the truncated hash values R'TOTP and RTOTP brought a negative result. Control of the crane unit 70 has failed and is blocked. A corresponding display can take place in step 732 .

If, on the other hand, the comparison in step 722 yields a match, the comparison in step 724 signals a positive result. In step 740, an acknowledgment is sent that the comparison of R'TOTP and RTOTP yielded a matching result. On the one hand, this positive result in step 740 is communicated to the crane control 72 , which in step 730 recognizes a successful authentication and in step 742 sends a control command to the crane unit 70 . In step 744, the crane unit 70 waits for such a control command. In step 746, the crane unit 70 then executes the control command desired by the user 76.

In contrast to the embodiment of figure 3 found in the crane control of figure 5 no additional authentication of the user takes place with the hardware dongle. A previously successfully performed PIN entry is in the embodiment of figure 5 not provided, but can also be provided here.

Reference List

1

OCRA generator

2

OCRA generator

10

requesting device

12

TOTP generator

30

notarizing device

32

TOTP generator

50

flow sensor

52

terminal

54

hardware dongle

56

user

70

crane unit

72

crane control

74

hardware dongle

76

operator, crane driver

S

shared secret

Z

access data

R

Specifiable information, random value

OCRA

OCRA response in notarizing device 30

O'CRA

O'CRA response in requesting device 10

RTOTP

hash value in the notarizing device 30,

R'TOTP

hash value in the requesting device 10,

(1a)-

( 10 ) steps

300-352

steps

700-746

steps

Claims (14)

1. Method for a system time independent authentication of interactions in microcontroller-based and/or FPGA-based devices or systems, in particular embedded systems and/or flame monitors, in which, in each one of a requesting device (10) and an authenticating device (30), a cryptographic hash-value (R'TOTP, RTOTP) is calculated in accordance with one of mutually shared secrets (S) used by both devices (10, 30) and in a TOTP module (12, 32) operating in accordance with a TOTP method in both devices (10, 30), wherein, instead of a system time, a specifiable information (R) is provided to the TOTP modules (12, 32) for calculating the respective hash value (R'TOTP, RTOTP), such that the specifiable information (R) is generated or provided by the authenticating device (30) and, upon request of the requesting device (10) or by means of a direct input into the authenticating device (30), is transferred to the requesting device (10), where it is then provided to the TOTP module operating there for calculating a hash value and the hash value (R'TOTP) calculated there is transmitted to the authenticating device (30), and in that, if this hash value (R'TOTP) received from the authenticating device (30) matches the hash value (RTOTP) calculated in the authenticating device (30) using the specified information (R), a successful authentication is carried out and the interaction is allowed which, if there is no match, will otherwise be blocked.
2. Method in accordance with claim 1,
   characterized in that a hardware dongle, which can be externally plugged into the requesting device (10), is employed as the TOTP module (12) assigned to the receiving device (10).
3. Method in accordance with claim 1 or 2,
   characterized in that the hash value (R'TOTP, RTOTP) is provided as a truncated hash value.
4. Method in accordance with claim 1,
   characterized in that at least one of the TOTP modules (12, 32) is realized as a software implementation directly in the requesting device (10) and/or the authenticating device (30).
5. Method in accordance with claim 1,
   characterized in that, for the realization of a 2FA, a preliminary authentication request having specified access data (Z) is sent from the requesting device (10) to the authenticating device (30), or is directly input into it, allowing, in the case of a successful validity test, an authentication request.
6. Method in accordance with claim 5,
   characterized in that a password and/or a user name and/or a certificate is (are) used as access data.
7. Method in accordance with claim 5,
   characterized in that the access data (Z) are stored on a chip unit which operates wirelessly or wire-based, in particular, on a smart card or a USB module.
8. Method in accordance with any of claims 1 to 7,
   characterized in that the specifiable information (R) is a random value which is generated by the authenticating device (30) or is selected from a specified list of values.
9. Method in accordance with any of claims 1 to 7,
   characterized in that one and the same shared secret (S) is used by numerous requesting devices (10) for authentication.
10. Method in accordance with any of claims 1 to 9,
    characterized in that interactions in devices or systems based on microcontrollers and/or FPGAs such as, for example, flame monitors, are configuration, update, parameterization, measurement, service, switching, monitoring and/or control functions in industrial installations.
11. Method in accordance with any of claims 1 to 10,
    characterized in that the method is carried out in a microcontroller and/or an FPGA of a flame monitor.
12. Microcontroller and/or FPGA based device for a system time independent authentication of interactions in microcontroller-based and/or FPGA-based devices or systems, in particular embedded systems and/or flame monitors, in which, in each one of a requesting device (10) and an authenticating device (30), a cryptographic hash-value (R'TOTP, RTOTP) can be calculated in accordance with one of mutually shared secrets (S) used by both devices (10, 30) and in a TOTP module (12, 32) operating in accordance with a TOTP method in both devices (10, 30), wherein, instead of a system time, a specifiable information (R) can be provided to the TOTP modules (12, 32) for calculating the respective hash value (R'TOTP, RTOTP), such that the specifiable information (R) can be generated or provided by the authenticating device (30) and, upon request of the requesting device (10) or by means of a direct input into the authenticating device (30), can be transferred to the requesting device (10), where it then can be provided to the TOTP module operating there for calculating a hash value and the hash value (R'TOTP) calculated there can be transmitted to the authenticating device (30), and in that, if this hash value (R'TOTP) received from the authenticating device (30) matches the hash value (RTOTP) calculated in the authenticating device (30) using the specified information (R), a successful authentication can be carried out and the interaction can be allowed which, if there is no match, can otherwise be blocked.
13. Device in accordance with claim 12,
    characterized in that the device is an embedded system.
14. Flame monitor
    characterized by a device in accordance with either of claims 12 or 13, in particular characterized in that it comprises a microcontroller and/or FPGA based system in accordance with either of claims 12 or 13 for a system time independent authentication of interactions.

Images