DE102016106819A1 - Method for updating a firmware component and device of measurement and control technology - Google Patents

Abstract

The invention relates to a method for updating a first firmware component which provides the functionality of a device of the measurement and control technology and which is embedded in a microcontroller of the device, comprising: segment-wise receiving of a first firmware image via a data interface connected to an external device the microcontroller, wherein the first firmware image comprises a data area and a signature field, and wherein the data area for updating the first firmware component includes data comprising a firmware program code and the signature field contains a first authentication information generated after a first crypto process; Performing authentication of the first firmware image based on the first authentication information using an authentication algorithm included in the first firmware component after the first crypto-method; Generating second authentication information for the data contained in the data area of the first firmware image by means of an algorithm comprised by the first firmware component for generating the second authentication information according to a second crypto method different from the first crypto method; After successful authentication of the first firmware image, storing the second authentication information in a persistent memory of the device; Deleting the first firmware component, wherein the deletion is controlled by a second firmware component embedded in the microcontroller; Retransmission of the data used to update the first firmware component as part of a second firmware image involving the second firmware component via the data interface to the microcontroller and storing the data in the persistent memory of the microcontroller; Performing an authentication of the second firmware image received at the retransmission based on the second authentication information stored in the microcontroller by means of an authentication algorithm included in the second firmware component according to the second crypto method, and in the case of a successful authentication of the second firmware -Images Activating and executing the firmware program code transferred and stored with the second firmware image as the new first firmware component.

Description

The invention relates to a method for updating the functionality of a device of measurement and control technology providing firmware component and a device of measurement and control technology.

Measurement and control tasks in the industrial sector are often safety-critical. Customer applications require the correctness and availability of measured and controlled variables of the respective automation. Integrity and availability of the data is in most cases of greater relevance than the also important confidentiality. The particular safety relevance of measuring and control devices, such as measuring devices, controls, sensors, actuators, monitoring circuits, warning displays, fieldbus network technology, etc. arises because the result of malfunction or manipulation of these devices are dangers such as explosions, leakage of hazardous substances / Gases, etc., can be.

Automation solutions consist of a large number of independent subcomponents, such as controllers, sensors, network infrastructure components such as routers, etc. These subcomponents can each be configured individually as a single device of the measurement and control technology or at least partially combined in one device. Each of these subcomponents today usually contains its own software components, so-called firmwares. In addition, every single device, e.g. a field device for pH measurement, consist of several sub-modules, each containing its own firmware, e.g. a subsystem with a microcontroller for a fieldbus interface, a subsystem for the measured value signal processing and a subsystem for the analog-to-digital conversion. The firmware is embedded in the microcontroller. In addition to the integrity of the data transmission on the communication interfaces (fieldbus, Ethernet, wireless hard, etc.) of the devices or subcomponents, the integrity of the measured value processing in the subcomponents (transmitter, sensor) is crucial for the correctness of the measured values.

One possible attack scenario is that an attacker defers manipulated firmware components to the operator of an automation system. For example, within a temperature sensor, the temperature readings measured by the sensor could be deliberately manipulated within the firmware such that a non-critical temperature for the operation of the system is reported to the control system connected to the sensor, while in fact the monitored process has greatly elevated temperatures, e.g. can lead to an explosion of a tank.

For a successful attack, it is usually sufficient to manipulate the firmware of any subcomponent within a compromised device or a system attacked by a variety of devices.

A concrete example using a pH measuring point: A pH measuring point usually comprises a pH and a temperature transducer, which are often combined in a single device. The device further includes a device electronics connected to the transducers. This can include, for example, one or more microcontrollers for analog-to-digital conversion of the output signals of the transducers, a further microcontroller for the measurement signal processing, a fieldbus interface for transmitting the measurement signals via a fieldbus and a system which handles the operation of the fieldbus interfaces. For example, if an attacker wants to manipulate the transmitted temperature readings of such a pH meter, he may achieve the goal by selectively manipulating the firmware within the microcontroller for analog-to-digital conversion of the output of the temperature transducer or the firmware of one of the other subcomponents of the device.

The secure defense of a means of manipulated firmware components launched attack thus requires that the firmware of all participating subsystems and sub-components must be checked.

In the past, it was often common that the integrity of the firmware for such security considerations did not have to be considered because a programming of the firmware via so-called metal masks in the production of the chips was done or in the case of so-called flash memory areas, a design-related only on the production lines device manufacturer of a component was possible. Today, however, the state of the art that even in field use the loading of a new firmware on all sub-components, a so-called firmware update, at any time at runtime is possible.

To ensure the overall integrity of the system, ensuring the integrity of all involved firmware components is crucial.

The consequence of this is that both "large" systems with a lot of memory and very low-power microcontroller systems have to be protected. In the cryptographic context is in this case spoken of the required so-called authenticity of the firmware, in which the receiving system checks that the firmware component to be received in the update is authentic, ie, for example, was really created by the device manufacturer and not by a possible attacker.

• – Symmetrische Prüfsummenverfahren mit Authentifizierungscodes (sogenannte Message Authentication Codes, Abkürzung: MAC), wie AES-CBC, HMAC-MD5, HMAC-SHA256, Chaskey, Chaskey-LTS, Galois-Feldbasierte MACs wie die Authentifizierungskomponente in AES-GCM, sowie Primzahlbasierte Verfahren wie Poly1305, etc.
• – Asymmetrische Signaturverfahren, wie RSA-basierte Signaturen, ECDH-Signaturen auf elliptischen Kurven, EdDSA-Signaturen, Hash-Basierte Signaturverfahren, DSA-Signaturen, etc.

With regard to the cryptographic authenticity check, two large families can be distinguished

• - Symmetric checksum methods with authentication codes (so-called message authentication codes, abbreviation: MAC), such as AES-CBC, HMAC-MD5, HMAC-SHA256, Chaskey, Chaskey-LTS, Galois field-based MACs such as the authentication component in AES-GCM, and primes-based methods like Poly1305, etc.
• - Asymmetric signature techniques, such as RSA-based signatures, ECDH signatures on elliptic curves, EdDSA signatures, hash-based signatures, DSA signatures, etc.

Both classes of methods can be used for this purpose by means of cryptographic methods, also referred to below as crypto methods, authentication information, e.g. generate a checksum or a digital signature that can be shipped with the firmware update of a system serving firmware component. The receiving system can then check, based on the authentication information and key information, whether the delivered firmware component is authentic or not.

The two method classes mentioned above differ on the one hand in that, in symmetrical methods, exactly the same key is used both for generating the authentication information and for checking the authentication information, while different keys are used in asymmetrical methods. On the other hand, the two classes of methods differ in their complexity and according to their need for computation time and / or memory and the code size of the methods implemented in software.

In symmetric methods, any entity that is able to perform an authenticity check is also able to generate a correct checksum as authentication information, since the used key must be "symmetric" available to both partners involved. In asymmetric methods, there are different keys on both sides (generation and testing).

The symmetric checksum methods are today so stable and secure from the point of view of many cryptographers that mathematical attacks on the basic algorithms can practically be ruled out if key lengths of more than 80 bits are used. Frequently symmetric keys of at least 128 or 256 bits in length are recommended today.

However, in the context of systems with small microcontrollers, there is a significant problem with symmetric methods. To verify the authenticity of a newly offered firmware component, it is necessary to have the symmetric key held in the persistent storage of the system. In conventional microcontrollers, however, this memory can not be effectively protected against unauthorized reading. Although there are electronic components from the so-called smart card IC class, the e.g. Protect the persistent memory of a controller against unauthorized access by special metal covers of memory areas and sophisticated protection mechanisms. In commercial microcontrollers, however, such countermeasures are not implemented.

This relatively easily allows an attacker to obtain the symmetric key information without authorization, e.g. by opening the housing or by bypassing the access restriction of an interface for software debugging (debugger interface). The attacker can then easily generate a correct checksum for its manipulated firmware component and defer it to a subsystem without causing a fault.

The main advantage of the symmetric methods is that they can be efficiently implemented even on systems with low computing power. In particular, this requires very little source code and CPU power. For example, a MAC algorithm such as Chaskey-LTS on an ARM Cortex-M0 CPU can already be implemented with approximately 512 bytes of program length. Unlike asymmetric signature methods, e.g. not necessarily a so-called collision-resistant hash algorithm is needed as a subcomponent, which typically requires larger constant tables and relatively much program code.

The main difference between symmetric and asymmetric methods is that in asymmetric methods for generating a signature as authentication information another key is used, as for the verification of the signature. In this case, the key for the generation of the signature is usually referred to as a "private" key and the key used to verify the signature as a "public" key. The private key used for the signature of a firmware component can thus be kept exclusively in a secure environment, for example within an access-restricted area within the development department at the device manufacturer. This private key can thus be protected much more effectively from potential attackers than a key stored in an unprotected memory in a field device. Within the persistent memory of the device's microcontroller systems, when using an asymmetric signature, there is only the non-critical public key that can not be used by an attacker to even sign manipulated firmware.

For asymmetric techniques, from a consideration of possible attacks against the mathematical methods today, key lengths of at least 2048 bits (in methods such as DSA or RSA based on factorization of large numbers and groups on prime number fields) or> 230 bits for methods based on elliptic curves required. Alternative methods, such as the so-called Merkel signatures based on hash trees, code-based signatures (McEliece) or so-called grid-based signature methods (eg LWE, learning with errors) still require much longer keys of 10 kbytes and more and are therefore not widely used in practice , In the context of computationally powerful systems, e.g. Web servers on the Internet find signatures based on methods such as RSA, DSA or ECDSA, e.g. with so-called certificates, as used in encrypted protocols such as HTTPs or TLS.

The challenge is that these algorithms require significantly more computational resources than symmetric algorithms because of the elaborate algorithms and large key lengths. For example, even a highly optimized software implementation of asymmetric cryptography on small microcontrollers already needs about 10 kbytes of memory ( Of. Codes Cryptogr. (2015) 77: 493-514 ). Therefore, in comparison to symmetrical methods, at least a 10 to 100 times memory requirement for the associated program code can be expected.

Within an industrial control device, there are typically individual components that provide sufficient resources for the standard methods. For example, Within a pH sensor, a CPU responsible for fieldbus communication could have sufficient memory and computing power. However, as stated above, hedging a single subsystem is not enough. Rather, all involved firmware components must be protected, even in the smaller subsystems, e.g. for analog-to-digital conversion close to the physical transducer.

Outsourcing the signature check to just the high-performance CPUs of a component runs the risk that errors within the logs within one component can affect the other components. That The security of a firmware component (eg for A / D conversion) then depends on the correctness of another firmware component (eg fieldbus CPU), which may be under the control of another organizational unit or even a third-party company and are not checked can. This increases the amount of possible sources of error in concept and implementation.

For the safety feature, systems of low complexity are always desirable. In practice, this is often only achieved if each CPU is completely responsible for the firmware authenticity check during a firmware update, so the check is done decentrally. In practice, only such secure systems can often be designed.

For the process of firmware update in an embedded system, the following considerations are significant. The computing system usually consists of a computing unit and a RAM memory for dynamic data and a (flash) ROM memory for data to be persisted. The arithmetic unit (CPU) obtains the machine instructions from the ROM memory and also stores there persistent data, such as. cryptographic keys. Today, the state of the art is that microcontrollers have an integrated ROM memory in so-called flash technology. As a rule, the flash memory dominates the silicon area of the microcontroller and is therefore the decisive cost factor in the production of the microcontroller chips. For cost reasons, therefore, building blocks are usually used, which are tailored to the just needed storage space. As a rule, a typical embedded system does not have enough RAM and flash ROM memory to temporarily store both the previous and the "new" firmware components during a firmware update.

For this reason, a distinction is generally made between two firmware components, a so-called bootloader component (also referred to below as bootloader for short) and an application component (also referred to below as an application in the following). In a typical microcontroller with e.g. 64 kbytes of flash memory in total, the overall firmware consists e.g. from a bootloader with e.g. 4 kByte Flash and an application with 59 kByte Flash and 1 kByte data memory.

The task of the bootloader is to enable an exchange of the application firmware. For this purpose, the bootloader first deletes the application area of the flash. In many cases, in microcontrollers, the flash is separated into a so-called "bootloader" section and an "application" section, whereby bootloader and application parts can be deleted separately. In such systems, the maximum possible size of the bootloader is limited by the hardware to lengths of typically 4 or 8 kbytes. After deleting the application is no longer available. Subsequently, a new application firmware is transmitted to the bootloader via an external data interface and then stored again in the flash memory.

Important in the context of generation and / or verification of cryptographic authentication information is that for the generation and verification of authentication information the full firmware component transmitted during the update must be used. For obvious reasons, in the above-described form of firmware update, verification of the authentication information from the bootloader portion of the software is required.

As can be easily seen from the above typical example, it is not foreseen to be able to implement secure asymmetric cryptography techniques (typically with at least 10 Kbytes of code length) under the constraints of the code size limitations of the bootloader. In the context of the normal application (in the example 59 kByte code), however, such methods are very well implemented.

In summary, the object of the invention is to allow a decentralized, secure, asymmetric signature check in the mentioned context, even in subcomponents with low computing power, in particular under the limitations of a boot loader firmware.

This object is achieved by a method having the features of claim 1 and a device of measurement and control technology according to claim 11. Advantageous embodiments are specified in the subclaims.

• – Segmentweises Empfangen eines ersten Firmware-Images über ein mit einem externen Gerät verbundenes Dateninterface des Mikrocontrollers, wobei das erste Firmware-Image einen Datenbereich und ein Signaturfeld umfasst, und wobei der Datenbereich zur Aktualisierung der ersten Firmware-Komponente dienende, einen Firmware-Programmcode umfassende Daten enthält und das Signaturfeld eine nach einem ersten Kryptoverfahren erzeugte erste Authentifizierungsinformation enthält;
• – Durchführen einer Authentifizierung des ersten Firmware-Images anhand der ersten Authentifizierungsinformation mittels eines von der ersten Firmware-Komponente umfassten Authentifizierungs-Algorithmus nach dem ersten Kryptoverfahren;
• – Erzeugen einer zweiten Authentifizierungsinformation für die im Datenbereich des ersten Firmware-images enthaltenen Daten mittels eines von der ersten Firmware-Komponente umfassten Algorithmus zur Erzeugung der zweiten Authentifizierungsinformation nach einem von dem ersten Kryptoverfahren verschiedenen, zweiten Kryptoverfahren;
• – nach erfolgreicher Authentifizierung des ersten Firmware-Images Speichern der zweiten Authentifizierungsinformation in einem persistenten Speicher des Geräts;
• – Löschen der ersten Firmware-Komponente, wobei das Löschen durch eine in den Mikrocontroller eingebettete zweite Firmware-Komponente gesteuert wird;
• – erneute Übertragung der zur Aktualisierung der ersten Firmware-Komponente dienenden Daten als Bestandteil eines zweiten Firmware-Images unter Beteiligung der zweiten Firmware-Komponente über das Dateninterface an den Mikrocontroller und Speichern der Daten im persistenten Speicher des Mikrocontrollers;
• – Durchführen einer Authentifizierung des bei der erneuten Übertragung empfangenen zweiten Firmware-Images anhand der in dem Mikrocontroller gespeicherten zweiten Authentifizierungsinformation mittels eines von der zweiten Firmware-Komponente umfassten Authentifizierungs-Algorithmus nach dem zweiten Kryptoverfahren, und
• – für den Fall einer erfolgreichen Authentifizierung des zweiten Firmware-Images Aktivschalten und Ausführen des mit dem zweiten Firmware-Image übertragenen und gespeicherten Firmware-Programmcodes als neue erste Firmware-Komponente.

The method according to the invention for updating a first firmware component which provides the functionality of a device of the measurement and control technology and which is embedded in a microcontroller of the device comprises:

• Receiving a first firmware image segment by segment via a data interface of the microcontroller connected to an external device, wherein the first firmware image comprises a data area and a signature field, and wherein the data area is for updating the first firmware component comprising a firmware program code Contains data and the signature field contains a first authentication information generated after a first crypto procedure;
• Performing authentication of the first firmware image based on the first authentication information using an authentication algorithm included in the first firmware component after the first crypto-method;
• Generating second authentication information for the data contained in the data area of the first firmware image by means of an algorithm comprised by the first firmware component for generating the second authentication information according to a second crypto method different from the first crypto method;
• After successful authentication of the first firmware image, storing the second authentication information in a persistent memory of the device;
• Deleting the first firmware component, wherein the deletion is controlled by a second firmware component embedded in the microcontroller;
• Retransmission of the data used to update the first firmware component as part of a second firmware image involving the second firmware component via the data interface to the microcontroller and storing the data in the persistent memory of the microcontroller;
• Performing an authentication of the second firmware image received during retransmission based on the second authentication information stored in the microcontroller by means of an authentication algorithm included in the second firmware component according to the second crypto method, and
• - in the case of a successful authentication of the second firmware image, activating and executing the firmware program code transmitted and stored with the second firmware image as the new first firmware component.

The invention is based on the finding that for a resource-limited firmware component, such as the bootloader described in the introduction, in contrast to asymmetric crypto methods, less expensive crypto methods, such as symmetric checksum methods for checksum checking, are well within reach. This is especially true when using so-called "lightweight" algorithms such as Chaskey, Chaskey LTS or so-called cipher block Chaining (CBC) authentication codes based on light-weight block cipher algorithms such as "Simon" or "Speck" (see also National Institute of Standards and Technology NIST), or in case the corresponding microcontroller Crypto- Accelerator hardware, eg for AES.

By performing authentication of the first firmware image according to an authentication algorithm based on a first crypto method, the first firmware component simultaneously generates authentication information according to a second crypto method different from the first crypto method using the first firmware image; re-transmission of data obtained by the second firmware image from the second firmware component can be authenticated using the authentication information generated by the first firmware component, it is possible to use a more complex, and thus safer, crypto method as the first crypto method As a second crypto-method to use a simpler and thus less resource-requiring crypto-driving. The authentication by the first firmware component can thus ensure by a complex, for example, asymmetric, crypto procedure that manipulations by an attacker are excluded during the first transmission of the data with the first firmware image. Authentication by the second firmware component ensures that the data received when retransmitting with the second firmware image is identical to the data of the first firmware image obtained during the first transmission. Thus, a less expensive, e.g. a symmetric, crypto method.

The method can therefore be advantageously used in a firmware update, as described at the beginning. In this case, the first firmware component corresponds to the application, the second firmware component to the bootloader.

The term firmware image here denotes a suitable combination of a data area, which may contain a firmware program code and constant data, and an optionally existing signature field. The data contained in the data area are also referred to below as firmware data or firmware for short. The first firmware image includes a signature field containing the first authentication information. The second firmware image may include a signature field with authentication information, in particular the first authentication information. In particular, it may completely match the first firmware image, i. that in the above-described method one and the same firmware image is transmitted twice, namely the first time to the first firmware component for authentication after the first crypto-process and for generating the second authentication information and the second time to the second firmware component for the authentication described by means of the first firmware component generated second authentication information. But it is also possible that the second firmware image contains only one data area with the firmware data.

The method may further comprise:
in the case of an unsuccessful authentication of the second firmware image, deleting the data transmitted and stored with the second firmware image, in particular the stored firmware program code.

Here, a successful authentication means that the authentication algorithm leads to the result that the firmware image or the data contained in it is / are authentic.

In an advantageous embodiment, the authentication algorithm encompassed by the first firmware component requires, after the first crypto method, a memory requirement of more than 5 kbytes of ROM and 512 bytes of RAM.

In a further advantageous embodiment, the algorithm encompassed by the first firmware component for generating the second authentication information according to the second crypto method and the authentication algorithm included in the second firmware component requires a memory requirement of less than 512 bytes RAM and 1 according to the second crypto method kBytes ROM.

The first crypto method may be, for example, an asymmetric crypto method. In question, for example, a method based on elliptic curves, in particular based on the EdDSA algorithm on the elliptic curve Curve25519, a method of the ECDSA standard family or a method based on prime number bodies, in particular an RSA or DSA method.

The second crypto method may be, for example, a symmetric crypto method. Suitable, for example, is a MAC method based on a block encryption algorithm, in particular a method based on the algorithm family Chaskey or AES128-CBC.

The first authentication information may be a digital signature generated with a private key using the data contained in the data area, in particular the firmware program code, wherein the performing of the Authentication of the first firmware image comprises a verification of the digital signature by means of a stored in a persistent memory of the microcontroller public key.

The generation of the second authentication information comprises, in one embodiment, generating a check-sum serving as second authentication information according to the second crypto-method from a key generated by means of a key generator comprised by the first firmware component and the data contained in the data area, in particular that from the first firmware Image included firmware program code.

The key generated by means of the key generator can be stored in a persistent memory of the microcontroller, wherein performing an authentication of the second firmware image based on the second authentication information comprises the steps of: generating a checksum according to the second crypto method from the key generated by the key generator and data comprised by the second firmware image, in particular the firmware program code comprised by the second firmware image; and comparing the checksum with the second authentication information, wherein the authentication is successful if the checksum matches the second authentication information.

In rare cases, it may be desirable to define within the firmware image also sections, which are to be transferred, but are not cryptographically deducted, i. Sections that are deliberately not used for the calculation of the authentication information. This could e.g. Data areas in which, after the signature generation, explanatory notes to the firmware, such as e.g. a list of known error issues supplemented with software and supplements will be supplemented with description and recommended measures. If necessary, these data sections can be excluded from the signature check after the first crypto procedure or from the checksum generation and authentication according to the second crypto method.

The key generator may, for example, comprise a random number generator, the key being a random number sequence of preferably at least 80 bits.

The firmware program code of the first and second firmware images may optionally be encrypted. In this case, the method additionally comprises the decryption of the firmware program code by means of an additional decryption algorithm of the first and / or the second firmware component. For this purpose, a symmetric encryption method would advantageously be used, the key is stored in the persistent memory of the microcontroller.

• – einen oder mehrere Algorithmen zur Bereitstellung von Funktionalitäten des Geräts;
• – einen Algorithmus zum Empfang eines ersten Firmware-Images, welches einen Datenbereich und ein Signaturfeld umfasst, wobei der Datenbereich zur Aktualisierung der ersten Firmware-Komponente dienende, einen Firmware-Programmcode umfassende, Daten enthält, und wobei das Signaturfeld eine nach einem ersten Kryptoverfahren erzeugte erste Authentifizierungsinformation enthält;
• – einen Authentifizierungs-Algorithmus zur Authentifizierung des ersten Firmware-Images anhand der ersten Authentifizierungsinformation nach einem ersten Kryptoverfahren;
• – einen Algorithmus zur Erzeugung einer zweiten Authentifizierungsinformation aus den in dem Datenbereich enthaltenen Daten, insbesondere dem Firmware-Programmcode, nach einem von dem ersten Kryptoverfahren verschiedenen, zweiten Kryptoverfahren; und
• – einen Algorithmus zur Ablage der zweiten Authentifizierungsinformation in einem persistenten Speicher des Microcontrollers; und wobei die zweite Firmware-Komponente umfasst:
• – einen Algorithmus zum Empfangen eines zweiten Firmware-Images, welches die zur Aktualisierung der ersten Firmware-Komponente dienenden Daten, insbesondere einen zur Aktualisierung der ersten Firmware-Komponente dienenden Firmware-Programmcode, umfasst;
• – einen Algorithmus zum Löschen der ersten Firmware-Komponente und zum Speichern des von dem zweiten Firmware-Image umfassten Firmware-Programmcodes als neue ersten Firmware-Komponente;
• – einen Algorithmus zum Auslesen der zweiten Authentifizierungsinformation aus dem persistenten Speicher;
• – einen Authentifizierungsalgorithmus nach dem zweiten Kryptoverfahren zur Authentifizierung des zweiten Firmware-Images anhand der zweiten Authentifizierungsinformation und der von dem zweiten Firmware-Image umfassten Daten, insbesondere des Firmware-Programmcodes; und
• – einen Algorithmus zum Aktivschalten der neuen ersten Firmware-Komponente.

The invention also encompasses a device of measurement and control technology comprising:
a device electronics with at least one microcontroller;
wherein the at least one microcontroller comprises embedded firmware having at least a first firmware component and a second firmware component,
and wherein the first firmware component comprises:

• One or more algorithms for providing functionalities of the device;
• An algorithm for receiving a first firmware image, comprising a data area and a signature field, the data area containing data for updating the first firmware component, comprising firmware program code, and wherein the signature field generates a first-cryptographic process contains first authentication information;
• An authentication algorithm for authenticating the first firmware image based on the first authentication information after a first crypto procedure;
• An algorithm for generating a second authentication information from the data contained in the data area, in particular the firmware program code, according to a second crypto method different from the first crypto method; and
• An algorithm for storing the second authentication information in a persistent memory of the microcontroller; and wherein the second firmware component comprises:
• An algorithm for receiving a second firmware image which comprises the data for updating the first firmware component, in particular a firmware program code for updating the first firmware component;
• An algorithm for deleting the first firmware component and storing the firmware program code included in the second firmware image as a new first firmware component;
• An algorithm for reading out the second authentication information from the persistent storage;
• An authentication algorithm according to the second crypto method for authentication of the second firmware image based on the second authentication information and that of the second firmware image included data, in particular the firmware program code; and
• An algorithm for activating the new first firmware component.

The device can therefore be designed to carry out the method described above.

The first crypto method may be an asymmetric crypto method and the second crypto method may be a symmetric crypto method. The first firmware component may further comprise: a random number generator comprising a key generator and an algorithm for storing a key generated by the key generator for the second crypto method in a persistent memory of the microcontroller. The authentication algorithm according to the second crypto method may be configured to generate a checksum from the stored key and the firmware program code and to compare them with the second authentication information.

The first and / or the second firmware component can additionally comprise a further algorithm for decoding a firmware image or the data contained in the data area comprised by the firmware image, in particular a firmware program code comprised of the firmware image, in particular with a symmetric encryption method.

The transmission of the first and / or second firmware image to the device can also be done using an easily vulnerable data transmission channel, in particular using a remote maintenance or wireless interface or using a portable storage medium, such as a USB stick or SD card.

In particular, the device can be a measuring device which has a measuring transducer which generates measurement signals which depend on a measured variable, in particular digital signals. In this embodiment, the device electronics may comprise a measuring electronics connected to the measuring transducer for receiving the measuring signals, in particular detachably or non-detachably, which is designed to process the measuring signals and to output the processed measuring signals to a higher-order unit.

The invention will be described below in detail with reference to the example shown in the figure.

The 1 shows a schematic drawing of a device of measurement and control technology.

This in 1 schematically illustrated device 1 is a measuring device with a transducer 2 and a sensor electronics 3 , The sensor electronics 3 includes an A / D converter 4 that of the transducer 2 generated analog signals digitized, a microcontroller 5 receiving and processing the digitized measurement signals, and a data interface 6 about which the microcontroller 5 the processed measuring signals and / or other information by radio 7 or via a conductor loop 8th to a higher-level unit 9 . 10 can spend. At the parent unit 10 In the present example this is a portable computer, eg a smartphone. The parent unit 9 may be, for example, a process control center of an industrial process. The device 1 also has an interface 11 for connecting a storage medium, eg an SD card 12 , on. The device 1 can optionally with the parent unit 9 and / or the parent unit 10 get connected. To perform a firmware update, a firmware image containing the program code of the new firmware may be removed from the unit 9 over the conductor loop 8th or from the unit 10 via radio 7 or from across the interface 11 with the device 1 connected SD card 12 to the device 1 , specifically via the data interface 6 to the microcontroller 5 , be transmitted.

The microcontroller 5 has a flash memory with a firmware 13 which comprises at least two firmware components A, B. The first component is an application component, hereinafter referred to as application A for short. The second component is a bootloader component, hereinafter referred to as bootloader B for short. Application A represents basic functionalities of the device 1 to disposal. The boot loader B serves to update the application A in the form of a firmware update according to the method described in the introduction. Next has the device 1 a persistent store 16 in the present example as part of the microcontroller 5 is shown. In the persistent memory of the device 16 There is a public key PK filed an asymmetric signature procedure.

• – Eine Entropiequelle 17, beispielsweise einen Zufallszahlengenerator
• – Einen Algorithmus 18 zum, insbesondere segementweisen, Empfang eines neuen Firmware-Images
• – Einen Algorithmus 19 zur asymmetrischen Signaturprüfung
• – Einen Algorithmus 20 zur Generierung einer als Authentifizierungsinformation dienenden symmetrischen Prüfsumme MAC nach einem symmetrischen Kryptoverfahren, z.B. einen MAC-Algorithmus
• – Eine Software-Komponente zur Ablage eines symmetrischen Schlüssels SK und einer generierten symmetrischen Prüfsumme MAC im persistenten Speicher 16

Firmware component A has the following components:

• - An entropy source 17 , for example, a random number generator
• - An algorithm 18 for, in particular segementweise, receiving a new firmware image
• - An algorithm 19 for asymmetric signature verification
• - An algorithm 20 for generating a symmetric checksum MAC serving as authentication information after one Symmetric crypto methods, eg a MAC algorithm
• A software component for storing a symmetric key SK and a generated symmetric checksum MAC in the persistent memory 16

• – Einen Algorithmus 21 zum Empfang eines neuen Firmware-Images
• – Einen Algorithmus 22 zum Auslesen des symmetrischen Schlüssels SK und MAC aus einem Speicher 16 und zur Errechnung und Prüfung einer symmetrischen Prüfsumme MAC der mit dem neuen Firmware-Image übermittelten neuen Firmware.

The firmware component B contains the following components

• - An algorithm 21 to receive a new firmware image
• - An algorithm 22 for reading the symmetric key SK and MAC from a memory 16 and to calculate and check a symmetric checksum MAC of the new firmware transmitted with the new firmware image.

Optionally, the components A and / or B additionally contain an algorithm for decoding a firmware image or a firmware program code contained in the firmware image with a symmetric key (not in FIG 1 shown). However, this encryption component only serves for the know-how protection of the device manufacturer of the automation component, and not primarily for the protection of a plant operator from a data security attack. It is therefore optional.

The procedure for updating the firmware 13 , in particular the application A, is that the authentic device manufacturer selects an asymmetric signature algorithm and generates a public / private key pair for this algorithm. He ensures with sufficient care that only authorized persons, who are responsible for the release of an authentic software, can gain control over the private key. The associated public key PK is then made known and among other things in the memory 16 of the delivered device 1 stored so that this public key PK for the process of firmware update is available there.

• 1. Zunächst wird mit dem Zufallszahlengenerator 17 eine unvorhersagbare Zufallszahlensequenz SK von vorzugsweise mindestens 80 Bits generiert und im Speicher persistiert. Diese Zufallszahlensequenz dient in einem weiteren Verfahrensschritt als symmetrischer Schlüssel SK für einen symmetrischen MAC-Algorithmus.
• 2. Dann wird über das externe Dateninterface 6 ein erstes Mal die neue Firmware als Bestandteil eines Firmware-Images von einem externen Gerät, z.B. einer der übergeordneten Einheiten 9, 10 oder von der SC-Karte 12 übertragen. Die empfangenen Firmware-Daten werden dabei von dem Algorithmus 18 segmentweise empfangen und nur an die zwei unten beschriebenen Kryptographiealgorithmen weiter geleitet und anschließend verworfen und nicht weiter gespeichert. Dadurch muss der Mikrocontroller 5 keinen wesentlichen Speicherplatz für den Empfang und die Authentifizierung der neuen Firmware bereitstellen.
• 3. Mit den eingegangenen Firmware-Daten wird parallel zur Übertragung der symmetrische MAC-Prüfsummenalgorithmus 20 durchgeführt. Dieser erhält neben den empfangenen zu prüfenden Firmware-Daten als Eingabegröße den soeben neu generierten Schlüssel SK aus dem Speicher 16. Zeitgleich erfolgt die asymmetrische Signaturprüfung durch den Algorithmus 19 unter Verwendung des im Speicher 16 abgelegten öffentlichen Schlüssels PK.
• 4. Nach vollständig erfolgter Übertragung des neuen Firmware-Images liegt das Ergebnis der asymmetrischen Signaturprüfung vor. Ebenfalls liegt die auf Basis des gerade eben selbst generierten Schlüssels SK errechnete, einfach zu verifizierende symmetrische MAC-Prüfsumme MAC vor.
• 5. Sofern die asymmetrische Signaturprüfung erfolgreich war, wird die zugehörige symmetrische MAC-Prüfsumme im Speicher 16 persistiert. Dort liegen also nun ein frisch generierter symmetrischer Schlüssel SK und der für diesen Schlüssel generierte symmetrische Prüfsumme MAC für die im Rahmen des asymmetrischen Verfahren als „authentisch“ erkannte neue Firmware. Besonders vorteilhaft ist dabei, dass der für die symmetrische Prüfsummenberechnung verwendete Schlüssel SK für einen Angreifer nicht vorhersagbar ist.

In firmware component A, the following method steps are then implemented for the firmware update:

• 1. First, use the random number generator 17 generates an unpredictable random number sequence SK of preferably at least 80 bits and persists in memory. This random number sequence is used in a further method step as a symmetric key SK for a symmetric MAC algorithm.
• 2. Then via the external data interface 6 a first time the new firmware as part of a firmware image from an external device, such as one of the higher-level units 9 . 10 or from the SC card 12 transfer. The received firmware data are thereby from the algorithm 18 received segment by segment and forwarded only to the two cryptographic algorithms described below and then discarded and not stored further. This requires the microcontroller 5 do not provide significant memory for receiving and authenticating the new firmware.
• 3. With the received firmware data is parallel to the transmission of the symmetric MAC checksum algorithm 20 carried out. This receives in addition to the received firmware data to be tested as an input size just newly generated key SK from the memory 16 , At the same time, the asymmetric signature check is performed by the algorithm 19 using the in store 16 filed public key PK.
• 4. After complete transfer of the new firmware image, the result of the asymmetric signature check is available. Also, based on the just self-generated key SK calculated, easy to verify symmetric MAC checksum MAC is present.
• 5. If the asymmetric signature check was successful, the associated symmetric MAC checksum will be in memory 16 persists. There, a freshly generated symmetrical key SK and the symmetrical checksum MAC generated for this key are now located there for the new firmware recognized as "authentic" within the framework of the asymmetrical method. It is particularly advantageous that the key SK used for the symmetric checksum calculation is unpredictable for an attacker.

• 1. Der Speicherbereich, in den die neue Firmware abgelegt werden soll, wird vorbereitet (gelöscht). Dieser Speicherbereich wurde vorher eventuell von der Applikation A zumindest teilweise beansprucht.
• 2. Anschließend wird die neue Firmware als Bestandteil eines weiteren Firmware-Images ein zweites Mal von dem externen Gerät über die Datenschnittstelle 6 übertragen und jetzt während des Empfangs in dem vorbereiteten Speicherbereich persistiert. In diesem Schritt erfolgt auch die optionale Entschlüsselung des Firmware-Programmcodes (um den Firmware-Code vertraulich zu halten und Know-How z.B. des Geräteherstellers zu schützen).
• 3. Parallel zu dieser zweiten Übertragung wird auf Basis des persistierten Schlüssels SK und des mit geringem Speicherbedarf implementierbaren symmetrischen MAC-Algorithmus 22 die symmetrische Prüfsumme errechnet.
• 4. Nach Empfang des vollständigen Firmware-Images wird anschließend geprüft, dass die vom Bootloader B errechnete MAC-Prüfsumme mit der von der Applikation A entsprechend errechneten und im Speicher 16 abgelegten Prüfsumme MAC übereinstimmt. Übereinstimmung der MAC-Prüfsummen impliziert die Übereinstimmung des von dem Bootloader B bei der zweiten Übertragung empfangenen Firmware-Daten mit den zuvor bei der ersten Übertragung von der Applikation A empfangenen und mittels des Algorithmus 19 zur asymmetrischen Signaturprüfung authentifizierten Firmware-Daten. Liegt diese Übereinstimmung vor, ist gleichzeitig die Authentizität des an den Bootloader B bei der zweiten Übertragung übertragenen Firmware-Images bzw. der darin enthaltenen Firmware-Daten sichergestellt.
• 5. Sofern die von den Firmware-Komponenten A und B errechneten symmetrischen Prüfsummen identisch sind, wird die neu empfangene und jetzt auch im Speicher persistierte Firmware aktiv geschaltet und ausgeführt. Anderenfalls wird erneut Schritt 1 aus dieser Aufführung ausgeführt und die offenbar nichtauthentische Firmware wieder gelöscht.

Afterwards the control will be handed over to the Bootloader B after the successful completion of the above steps. There are then the steps:

• 1. The memory area in which the new firmware is to be stored is prepared (deleted). This memory area was previously possibly claimed by the application A at least partially.
• 2. Subsequently, the new firmware, as part of another firmware image, is re-used a second time by the external device via the data interface 6 and persists during reception in the prepared memory area. This step also includes the optional decryption of the firmware program code (to keep the firmware code confidential and to protect the know-how of the device manufacturer, for example).
• 3. Parallel to this second transmission is based on the persisted key SK and the symmetric MAC algorithm that can be implemented with low storage requirements 22 calculates the symmetric checksum.
• 4. After receiving the complete firmware image, it is then checked that the MAC checksum calculated by Bootloader B is calculated in memory with that calculated by Application A and stored in memory 16 stored checksum MAC matches. Correspondence of the MAC checksums implies that the firmware data received from the boot loader B during the second transmission matches the one previously received at the first transmission from the application A and by means of the algorithm 19 for asymmetric signature verification authenticated firmware data. If this match exists, the authenticity of the firmware image transferred to the bootloader B during the second transfer or the firmware data contained therein is ensured at the same time.
• 5. If the symmetrical checksums calculated by the firmware components A and B are identical, the newly received firmware, which has now also been stored in the memory, will be activated and executed. Otherwise, step 1 will be executed again from this performance and the apparent nonauthentic firmware will be deleted.

It is noteworthy that in the case of the combination of firmware signature (authenticity) and firmware encryption (confidentiality) described as an option, the sequence of signature calculation and encryption are interchangeable and the order for the method described here is irrelevant. Preferably, it is recommended to first encrypt the firmware and calculate the signature via the encrypted firmware.

In the concrete embodiment, this is in the device 1 contained system to which a new firmware is to be transferred from a microcontroller 5 with 64 kbytes of flash memory. This memory is divided into 59k application program (component A), 1 kByte data section eg for cryptographic keys and MAC codes (memory 16 ) and 4 kByte bootloader (component B). In many cases, the memory of the microcontroller is directly integrated, in some systems the memory of the microcontroller is connected via an external memory chip outside the case of the CPU.

Candidates for this microcontroller would be e.g. 8-bit Atmel CPUs from the AVR series or ARM-based microcontrollers from Texas Instruments, NXP or ST-Microelectronics with comparable memory configuration. These systems typically have 8 to 16 KB of RAM.

In addition to the routines for receiving the firmware via a serial SPI or UART interface, the bootloader B also integrates routines for partial deletion of the flash.

The data for the firmware update are sent to the device via a suitable interface 1 transmit that the subsystem, which is to receive a firmware update, this data can be transmitted via the serial interface. This transmission can take place, for example, radio-based via Bluetooth or WLAN via the Internet via a remote maintenance access or via a fieldbus interface. In this case, an attacker who at least partially receives control over the data channel can transmit a non-authentic firmware image to the field device.

It is noteworthy that, especially in the case of radio or Internet connections, the transmission of firmware data could be manipulated completely unobserved and in this case the authenticity check of the firmware via an asymmetric firmware signature may be particularly important.

Alternatively, it is possible to transfer the data via a portable storage medium, such as e.g. SD cards or USB sticks to submit. Again, an attacker with at least temporary access to the meter has the opportunity to try to transmit a nonauthentic firmware image.

It may be advantageous to temporarily cache (cache) the data of the new firmware in an optionally available "larger" microprocessor system of the same meter before transmitting it to the small microcontroller via the serial interface. In this case, the microcontroller has a serial data connection to the "larger" partner controller, which passes on the possibly cached firmware image.

Bootloader B implements a symmetric MAC algorithm (Algorithm 22 ) for checksum calculation. As a concrete embodiment, the implementation of the algorithm Chaskey-LTS is proposed, alternatively, the use of a MAC method based on the algorithm AES128-CBC, for example, if in the microcontroller, a hardware accelerator unit for AES128 should be available or other checksum method, such as eg from the siphash family. These algorithms can be implemented with a RAM requirement of the order of 64 bytes and a flash requirement of the order of 512 bytes and are thus compatible with the total memory budget of bootloader B of 4 Kbytes.

Application A implements the same symmetric MAC algorithm (Algorithm 20 ) and in addition an asymmetric method for signature verification (algorithm 19 ). For the additional asymmetric signature check used there during the firmware update, for example, a method based on elliptic curves is used there. Eg the algorithm EdDSA on the elliptic curve Curve25519. The use of the curve Curve25519 and EdDSA enables a particularly code- and resource-saving implementation of the signature check.

As an alternative to EdDSA on Edwards curves, so-called Koblitz curves on Galois bodies or so-called "Short-Weierstrass" curves from the standards of NIST, the SECP group or the so-called Brainpool working groups can be used, for which under the name ECDSA asymmetric Signature procedures are standardized (see, eg Standard ANS X9.62, http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf ). The EdDSA algorithm uses a so-called scalar multiplication on the elliptic curve, a cryptographically secure, collision-resistant HASH algorithm, eg SHA512 or SHA-3. The signature verification algorithm EdDSA on Curve25519 (including SHA512) requires a memory requirement of approx. 15 kbytes of ROM and approx. 512 bytes of RAM and can thus be implemented in the memory budget of the application firmware A.

Alternatively, implementations of asymmetric signatures based on prime number fields are possible for application A, e.g. RSA or DSA-based signatures. In comparison with signature algorithms based on elliptic curves (ECDSA, EdDSA), the advantage of the latter is that the signature fields are significantly shorter than in RSA or DSA algorithms and, compared to RSA-based signatures, only marginally slower and with a smaller memory requirement of RAM can be calculated.

The public key PK required for the signature check is preferably compiled into each delivered firmware image. However, it could also be stored independently of the firmware image in a defined memory area of the microcontroller, for example in the mentioned 1 kbyte area (memory 16 ) which is reserved for data.

The random number generation for generating a for each firmware update freshly generated device-specific key SK is based on the known methods for cryptographically secure random number generation. In particular, in the exemplary embodiment, the random number generator is parameterized, inter alia, by a so-called seed value transmitted once during device production, and additionally by entropy sources available in the device, such as noisy measurement values, unpredictable time stamps and possibly hardware random number generators.

For example, it is proposed to generate the random numbers by first determining the various sources of entropy, such as initial device-specific factory randomization FRS (initially calculated by the testing station of the manufacturer and stored in flash), boot counter BC, noisy ADC values ADCNOISE, etc. by means of a so-called cryptographic hashing algorithm such as SHA512 to a number RS = SHA512 (FRS || BC || ADCNOISE). The result RS can itself be used as a random number, or used as a key for a so-called stream cipher algorithm, such as AES128-CTR, Salsa20, Chacha20, which is then used to generate the random numbers. This procedure ensures that a potential attacker can not predict the exact value of the key SK used in the course of the firmware update and thus has no possibility to generate a firmware image with manipulated data that in the above described second transmission over the external data interface to the bootloader B is incorrectly recognized as authentic.

For a new firmware to be transferred to update the firmware of the system in the device 1 A signature field is generated using the private key. This key is only available to selected device groups at the device manufacturer. The resulting EdDSA signature AS is then appended to the program code and, if appropriate, associated constant data areas of the firmware. The term firmware image here denotes a suitable combination of data area (firmware program code + constant data) and an optionally existing signature field AS. The data contained in the data area is also called firmware or firmware data. In the prior art, various so-called container formats are known to attach to a data block a signature field, for example, under the ITU-T Standard X.509 as used for internet certificates. For such container formats, there are, for example, ready-made standard programs for checking the signature field. For the case described here, however, it is also completely sufficient, for example, to generate the firmware image by prefixing the data area with a length specification and appending the signature field to the data area.

For the firmware update is from the application A in the microcontroller 5 a fresh key SK is detected. Subsequently, the firmware image becomes the asymmetric signature verification algorithm 19 fed in parallel to the symmetric MAC algorithm 20 (eg Chaskey-LTS). The latter uses for the checksum calculation the symmetric key SK, which was freshly generated from the random number generator and in memory 16 is persisted. It is important to note that neither the signature check nor the symmetric checksum method requires that the firmware image be available at all times in the RAM memory of the microcontroller at any given time. Rather, it is sufficient to process the data of the firmware image segment by segment, for example in blocks of 16 or 128 bytes. In each case one such sub-segment is used in turn for the checksum method and then overwritten in memory, if necessary, by the subsequent data segment. In technical terminology, this often refers to the fact that the two cryptography methods can be implemented via a memory-saving so-called "streaming" application interface in which the data is transmitted in the form of a sequential "stream" of smaller sub-segments.

During the transmission of the complete firmware image, the application A also receives the generated signature field AS attached to the firmware image via the serial interface. This externally received value AS is determined by the EdDSA algorithm 19 checked for authenticity using the available public key of the device manufacturer.

If the signature check was successful, the symmetric checksum value MAC calculated with the symmetric key SK becomes the data of the currently received firmware image in the flash memory 16 filed and the control of the CPU to the boot loader firmware B delivered.

This then deletes the memory area previously occupied by application A in Flash. She finds in the store 16 the one for the symmetric algorithm 22 (eg Chaskey) to use key SK and the correct result of the checksum MAC before, which has just calculated the firmware component A just. This checksum MAC is unpredictable for anyone, not even for the device manufacturer, since in this value the unpredictable key SK is included.

The bootloader B then again requests the transmission of the complete firmware data, receives a subsequently transmitted second firmware image containing the firmware data, carries out the symmetrical checksum calculation with the received firmware data and verifies the correctness of the retransmitted firmware. Images based on the required match with the corresponding result of the old application A (which is now no longer available in Flash). During this second transmission, therefore, the symmetrical checksum calculation and the storage of the data in the prepared deleted flash area takes place.

Once the new firmware image has been completely retransmitted, the symmetric checksum is checked. If the result matches the checksum calculated by the old application A, authenticity is detected and the new firmware is validated and switched to active. It thus replaces the previously deleted, old application A. Subsequently, the bootloader transfers the control to the new application and deletes the memory area of the memory 16 , in which the keys SK and the symmetric checksum were stored during the last update.

The advantage of this method is that even under the constraints of a limited memory budget of a bootloader firmware, a reliable and robust asymmetric signature verification can now be successfully implemented.

In addition to the above-described variant without encryption of the firmware, the person skilled in the art will also consider variants in which not only a firmware authenticity check takes place, but also the firmware itself is encrypted. For this purpose, in addition to the public key of the device manufacturer, the signature algorithm also stores a (secret) symmetric key for the firmware decryption. The signature check is preferably carried out for the encrypted firmware, but can also be performed for the decrypted firmware in a different order.

It is noteworthy that after performing the process step 1.) in the bootloader component B, a firmware update is possible only with exactly the same firmware that was previously verified in the application as correct. Advantageously, therefore, together with the key SK and the symmetrical MAC checksum calculated by the application, a firmware identifier is also stored in the flash memory, which uniquely identifies the firmware data to be transmitted, for example a firmware version number. By means of this firmware version number, for example, the bootloader software of the transmitting remote station can be transmitted via the data interface 6 tell you exactly what firmware version is expected now. This may be relevant, for example if a firmware update has been aborted (eg because of a power failure) and should be resumed at a later date.

In summary, the invention opens up the possibility of performing secure asymmetric signatures for securing firmware updates even in the smallest microcontroller systems with a limited storage budget.

This advantage is essentially only paid for by the disadvantage that the firmware must be transferred not only once, but twice, and in the first step, the signature verification takes place and the storage of the image and the overwriting of the previous memory only in the subsequent step.

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited non-patent literature

• Of. Codes Cryptogr. (2015) 77: 493-514 [0021]
• Standard ANS X9.62, http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf [0075]
• ITU-T standard X.509 [0080]

Claims (15)

Method for updating a first firmware component which provides the functionality of a device of the measurement and control technology and which is embedded in a microcontroller of the device, comprising: Receiving a first firmware image segment by segment via a data interface of the microcontroller connected to an external device, wherein the first firmware image comprises a data area and a signature field, and wherein the data area is for updating the first firmware component comprising a firmware program code Contains data and the signature field contains a first authentication information generated after a first crypto procedure; Performing authentication of the first firmware image based on the first authentication information using an authentication algorithm included in the first firmware component after the first crypto-method; Generating second authentication information for the data contained in the data area of the first firmware image by means of an algorithm comprised by the first firmware component for generating the second authentication information according to a second crypto method different from the first crypto method; After successful authentication of the first firmware image, storing the second authentication information in a persistent memory of the device; Deleting the first firmware component, wherein the deletion is controlled by a second firmware component embedded in the microcontroller; Retransmission of the data used to update the first firmware component as part of a second firmware image involving the second firmware component via the data interface to the microcontroller and storing the data in the persistent memory of the microcontroller; Performing an authentication of the second firmware image received during retransmission based on the second authentication information stored in the microcontroller by means of an authentication algorithm included in the second firmware component according to the second crypto method, and - in the case of a successful authentication of the second firmware image, activating and executing the firmware program code transmitted and stored with the second firmware image as the new first firmware component. Method according to claim 1, further comprising: in the case of an unsuccessful authentication of the second firmware image, deleting the data transmitted and stored with the second firmware image, in particular the stored firmware program code. Method according to claim 1 or 2, wherein the first crypto-method is an asymmetric crypto-method, For example, a method based on elliptic curves, in particular based on the EdDSA algorithm on the elliptic curve Curve25519, a method of the ECDSA standard family or a method based on prime number bodies, in particular an RSA or DSA method. Method according to claim 3, the second crypto method being a symmetric crypto method, For example, a MAC method based on a block encryption algorithm, in particular a method based on the algorithm family Chaskey or AES128-CBC. The method of claim 4, wherein the symmetric cryptographic method does not include a collision-resistant hash algorithm as a subcomponent. Method according to one of claims 3 to 5, wherein the first authentication information is a digital signature generated with a private key using the data contained in the data area, in particular the firmware program code; and wherein performing the authentication of the first firmware image comprises verifying the digital signature using a public key stored in a persistent memory of the microcontroller. Method according to one of claims 4 to 6, wherein generating the second authentication information comprises: Generating a check sum serving as second authentication information according to the second crypto method from a key generated by means of a key generator comprised by the first firmware component and the data contained in the data area, in particular the firmware program code included in the first firmware image. The method of claim 7, wherein the key generated by the key generator is stored in persistent memory of the microcontroller, and wherein performing authentication of the second firmware image based on the second authentication information comprises: Generating a checksum according to the second crypto method from the key generated by the key generator and the data comprised by the second firmware image, in particular the firmware program code comprised by the second firmware image; and comparing the checksum with the second authentication information, wherein the authentication is successful if the checksum matches the second authentication information. The method of claim 7 or 8, wherein the key generator comprises a random number generator and wherein the key is a random number sequence, in particular of at least 80 bits. Method according to one of claims 1 to 9, wherein the firmware program code of the first and second firmware images is encrypted, and wherein the method further comprises: Decrypting the firmware program code using an additional decryption algorithm of the first and / or the second firmware component. Instrument of measurement and control technology comprising: a device electronics with at least one microcontroller; wherein the at least one microcontroller comprises embedded firmware having at least a first firmware component and a second firmware component, and wherein the first firmware component comprises: One or more algorithms for providing functionalities of the device; An algorithm for receiving a first firmware image, comprising a data area and a signature field, the data area containing data for updating the first firmware component, comprising firmware program code, and wherein the signature field generates a first-cryptographic process contains first authentication information; An authentication algorithm for authenticating the first firmware image based on the first authentication information after a first crypto procedure; An algorithm for generating a second authentication information from the data contained in the data area, in particular the firmware program code, according to a second crypto method different from the first crypto method; and An algorithm for storing the second authentication information in a persistent memory of the microcontroller; and wherein the second firmware component comprises: An algorithm for receiving a second firmware image which comprises the data for updating the first firmware component, in particular a firmware program code for updating the first firmware component; An algorithm for deleting the first firmware component and storing the firmware program code included in the second firmware image as a new first firmware component; An algorithm for reading out the second authentication information from the persistent storage; An authentication algorithm according to the second crypto-method for authenticating the second firmware image based on the second authentication information and the data included in the second firmware image, in particular the firmware program code; and An algorithm for activating the new first firmware component. Apparatus according to claim 11, wherein the first crypto-method is an asymmetric crypto-method and the second crypto-method is a symmetric crypto-method, and wherein the first firmware component further comprises: a key generator comprising a random number generator and an algorithm for storing a key generated by the key generator for the second crypto-method in a persistent memory of the microcontroller; and wherein the authentication algorithm according to the second crypto method is configured to generate a check sum from the stored key and the data comprised by the second firmware image, in particular the firmware program code, and to compare these with the second authentication information. Apparatus according to claim 11 or 12, wherein the first and / or the second firmware component comprises a further algorithm for decoding a firmware image or the data contained in the data area comprised by the firmware image, in particular one of the firmware. Image include firmware program codes, in particular with a symmetric encryption method include. Device according to one of claims 11 to 13, wherein the transmission of the first and / or second firmware image to the device using an easily vulnerable data transmission channel, in particular using a remote maintenance or wireless interface or using a portable storage medium, such as a USB Sticks or an SD card. Apparatus according to any one of claims 11 to 14, wherein the device comprises a transducer which generates, dependent on a measured variable, in particular digital, measuring signals; and the device electronics comprise a measuring electronics connected to the measuring transducer for receiving the measuring signals, in particular detachably or non-detachably, which is designed to process the measuring signals and to output the processed measuring signals to a higher-order unit.

Images