DE102018217432A1 - Check the integrity of embedded devices - Google Patents

Abstract

Method and device for recognizing whether the software stored on an embedded device corresponds to the delivery status or a valid update, the device being a trustworthy device; wherein the device is configured to calculate a hash value over a randomly determined area of the software; and wherein the device is further configured to compare a hash value calculated by the device itself of the randomly determined area of the software with the hash value calculated by the device.

Description

The invention relates to a method and a device for recognizing whether the software stored on an embedded device corresponds to the delivery status or a valid update.

Embedded devices are highly specialized devices for specific purposes. Usually, embedded devices are embedded in a specific technical context or in a higher-level technical system, e.g. in home entertainment (consumer electronics, e.g. set-top boxes or routers), in medical technology systems, or in aircraft and vehicle technology. But also e.g. ATMs are examples of embedded devices.

The processors for embedded devices often have high real-time requirements, but also requirements such as low energy consumption or low storage capacity.

The software or firmware for embedded devices can also be stored in the main memory (ROM) in a persistent flash memory.

Software or firmware updates for embedded devices are usually carried out via a corresponding Internet download.

There is a risk that such a download could lead to malware on the embedded device and thus compromise the integrity of the device.

It is also possible that a vulnerability in the software or in the device could allow malicious software to reach the device. The attacker can then use these devices in a botnet for DDoS attacks (Distributed Denial of Service). Since embedded devices are manufactured in large numbers, there is great potential and risk here.

It is therefore the object of the present invention to provide a simple and reliable method for recognizing whether the software stored on an embedded device corresponds to the delivery status or a valid update.

• (VS1) Berechnen eines Hashwertes (z.B. durch SHA256) über einen zufällig bestimmten Bereich (Speicherbereich oder Speicherbereiche in dem oder denen sich die zu überprüfende Software befindet) der Software durch eine vertrauenswürdige Instanz (Tool, Werkzeug, z.B. Diagnosetool oder Engineeringsystem) ;
• (VS2) Berechnen eines Hashwertes über den zufällig bestimmten Bereich (Speicherbereich in dem sich die Software befindet) der Software durch das Gerät selbst;
• (VS3) Vergleichen der berechneten Hashwerte durch die vertrauenswürdige Instanz. Stimmen die berechneten Hashwerte überein, ist sichergestellt, dass die auf dem eingebetteten Gerät (z.B. IP Router, schaltbare Steckdose ...) hinterlegte Software dem Auslieferungszustand oder einem gültigen Update entspricht und keine Kompromittierung vorliegt. Mit dem erfindungsgemässen Verfahren wird erkannt, ob die Software, die sich auf dem Gerät befindet, dem Auslieferungszustand oder einem gültigen Update entspricht. Mit Vorteil wird vor der Durchführung der Verfahrensschritte das eingebettete Gerät von anderen Geräten und insbesondere vom Internet isoliert und jeweils neu gebootet. Dadurch wird sichergestellt, dass sich im Arbeitsspeicher (RAM) des eingebetteten Gerätes keine persistente Schad-Software befindet bzw. vom Gerät nicht mit einem Server des Angreifers Kontakt aufgenommen werden kann. Mit Vorteil werden so viele Bereiche, d.h. Speicherbereiche, durch das Verfahren überprüft, so dass ausgeschlossen werden kann, dass sich Schad-Software auf dem eingebetteten Gerät befindet. Mit Vorteil werden durch das Verfahren alle Bereiche bis auf die Konfigurationsbereiche des Speichers (RAM oder Flash-Speicher) geprüft.

The task is solved by a method for recognizing whether the software stored on an embedded device (eg IP router, switchable socket ...) corresponds to the delivery status or a valid update, the method comprises the following method steps:

• (VS1) calculating a hash value (e.g. by SHA256) over a randomly determined area (memory area or memory areas in which the software to be checked is located) of the software by a trustworthy entity (tool, tool, e.g. diagnostic tool or engineering system);
• (VS2) calculating a hash value over the randomly determined area (memory area in which the software is located) of the software by the device itself;
• (VS3) comparing the calculated hash values by the trusted entity. If the calculated hash values match, it is ensured that the software stored on the embedded device (e.g. IP router, switchable socket ...) corresponds to the delivery status or a valid update and that there is no compromise. With the method according to the invention, it is recognized whether the software on the device corresponds to the delivery status or a valid update. Before the method steps are carried out, the embedded device is advantageously isolated from other devices and in particular from the Internet and in each case rebooted. This ensures that there is no persistent malware in the working memory (RAM) of the embedded device or that the device cannot contact an attacker's server. Advantageously, so many areas, ie memory areas, are checked by the method, so that it can be ruled out that malware is on the embedded device. The method advantageously checks all areas except the configuration areas of the memory (RAM or flash memory).

The method can also be used with embedded devices that have an operating system (e.g. Linux). Such embedded devices have many individual files (e.g. DLLs) in memory.

The hash values are each calculated using suitable hash functions, advantageously using suitable cryptographic hash functions with the properties required for a hash function: one-way function (the original content cannot be generated from a hash value; that is, a hash function must not be reversible), collision safety (different contents must not be assigned the same hash value) and efficiency (the calculation of a hash value must be done as quickly as possible). Currently e.g. SHA-256 is a suitable hash function.

This advantageously ensures that the amount of memory in the device is checked in such a way that it is not possible to remember the original files in parallel with the malware.

This advantageously ensures that the original software cannot be brought to safety during or before the test. E.g. by internet connection (e.g. by upload) or by saving in a memory. The size of the tested memory must be such that it is no longer possible for malicious software to use the original data for the hash calculation.

The interrupt vectors of the processors of the embedded device are also advantageously checked in the main memory (RAM).

A first advantageous embodiment of the invention is that the randomly determined area of the software is determined by a random generator of the trustworthy entity. A cryptographically secure random number generator is advantageously used.

A further advantageous embodiment of the invention is that the method steps (VS1) to (VS3) are repeated until hash values have been calculated and compared for each area of the software. This increases the likelihood of detecting malware.

A further advantageous embodiment of the invention is that hash values are only determined for the areas of the software that comprise the boot loader and operating system and application software (all data that are not changed). Areas, i.e. Memory areas in which data with variable content (e.g. configuration data) are not used for the test.

A further advantageous embodiment of the invention is that hash values are determined in particular for software areas that contain the public key (public key). Public keys can be very long. The public keys can be reduced to small strings and compressed using hash functions. This saves transmission time, since it is not the key that has to be read out, but only the associated hash value. The hash function can also serve as integrity protection (e.g. as a signature) for the key. One can check whether the confidential areas in two devices are the same. For example, private keys can be compared here, since only the hash value is used and the private key is not compromised.

A further advantageous embodiment of the invention is that the method is only carried out when the embedded device and the trustworthy entity (tool, diagnostic tool) are connected to one another in an exclusive communication connection (advantageously bidirectionally). This means that the embedded device and the trustworthy entity are isolated from the environment and in particular from the Internet in terms of data technology. E.g. through an island connection between device and tool; without internet. The exclusive communication connection is advantageously a point-to-point connection, and advantageously a secure point-to-point connection.

The method according to the invention is advantageously used to compare configurations (or parameterizations) of different embedded devices.

The task is further solved by a device (eg tool, diagnostic tool) for recognizing whether the software stored on an embedded device corresponds to the delivery status or a valid update,
the device being a trustworthy device (advantageously a signed device);
wherein the device is configured to calculate a hash value (eg generated by SHA256) over a randomly determined area (memory area in which the software is located) of the software;
the device being further configured to compare a hash value of the randomly determined area of the software (memory area in which the software is located) calculated by the device itself with the hash value calculated by the device.

Before the test, the embedded device is advantageously isolated from other devices and in particular from the Internet and rebooted in each case. This ensures that there is no persistent malware in the RAM (RAM) of the embedded device. If the embedded device has external SD cards, it must be ensured that they have been removed before checking the device integrity. The interrupt vectors of the processors of the embedded device are also advantageously checked in the main memory (RAM).

A further advantageous embodiment of the invention is that the device is set up to calculate the respective hash values of regions of the software which are determined at random in each case and to compare them with the respective hash values of these respective regions calculated by the embedded device itself. This increases the probability that the software to be tested in the Delivery status or a valid update is located on the embedded device.

A further advantageous embodiment of the invention is that the device provides an interface for an exclusive communication connection between the device and the device (advantageously bidirectionally). This ensures that there is no persistent malware in the RAM (RAM) of the embedded device.

• 1 eine beispielhafte Vorrichtung zum Erkennen, ob die auf einem Gerät, insbesondere einem eingebetteten Gerät, hinterlegte Software dem Auslieferungszustand oder einem gültigen Update entspricht, und
• 2 ein beispielhaftes Flussdiagramm für ein Verfahren zum Erkennen, ob die auf einem Gerät, insbesondere einem eingebetteten Gerät, hinterlegte Software dem Auslieferungszustand oder einem gültigen Update entspricht.

The invention and advantageous embodiments of the present invention are explained using the example of the following figure. It shows:

• 1 an exemplary device for recognizing whether the software stored on a device, in particular an embedded device, corresponds to the delivery state or a valid update, and
• 2nd an exemplary flow chart for a method for recognizing whether the software stored on a device, in particular an embedded device, corresponds to the delivery status or a valid update.

Embedded devices are highly specialized devices for specific purposes. Usually, embedded devices are embedded in a specific technical context or in a higher-level technical system, e.g. in home entertainment (consumer electronics, e.g. set-top boxes or routers), in medical technology systems, or in aircraft and vehicle technology.

1 shows an exemplary device DW to detect if the on an embedded device EG stored software corresponds to the delivery status or a valid update, whereby it is in the device DW a trustworthy device DW acts; being the device DW is set up a hash value HW2 over a random area B1 - Calculate Bn of the software; and being the device DW is further set up by the embedded device EG self-calculated hash value HW1 of the randomly determined area B1 - Bn the software with that through the device DW calculated hash values HW2 to compare. The device was advantageous DW certified or signed by a trusted authority. For example, through a corresponding certification server, for example through a corresponding internet connection. The hash values HW1 , HW2 can be generated using the hash function SHA256, for example. In the area B1 - Bn are areas of the memory SP1 of the embedded device EG in which the software to be tested is stored. The device DW can check software in memory (RAM) or in a flash memory of the embedded device EG is deposited. Areas are beneficial B1 - Bn, ie memory areas in which data with variable content (eg configuration data) is not used for the test.

One area of the software corresponds e.g. Sections (memory sections) in the main memory (RAM) or in a persistent memory (e.g. flash memory) of the embedded device (e.g. IP router) on which the software is physically stored.

The device DW (eg a diagnostic tool) includes appropriate processing equipment P2 (eg a powerful processor for the effective determination of a hash value HW2 and to compare the hash values HW1 and HW2 ), Storage medium SP2 (RAM, flash memory), and means of communication for connection to the embedded device or to the Internet I. In the illustration according to 1 is the device DW over the communication link KV1 with the embedded device EG connected, for example via a USB interface.

The embedded device EG (eg an IP router) includes appropriate processing equipment P1 (eg a powerful processor for the effective determination of a hash value HW1 ), Storage medium SP1 (RAM, flash memory) with the memory areas B1 - Bn in which the software to be checked (eg application programs, firmware) is stored. Via the communication link KV2 (e.g. radio connection, WLAN) is the embedded device EG connected to the internet.

The device is advantageous DW set up the respective hash values HW2 of randomly determined areas B1 - Calculate bn of the software and with that of the embedded device EG self-calculated respective hash values HW1 of these respective areas B1 - Compare Bn in each case.

The device is advantageous DW set up, an interface for an exclusive communication connection KV1 to the embedded device EG to manufacture. For example, through an island connection between the device EG and device DW ; without internet.

Example scenario to determine that the embedded device does not yet contain any malware:

1. 1. The tool (device DW ) is signed by the manufacturer. The customer can check the integrity of the tool.
2. 2. The tool DW knows the software (or all valid versions) that are in the embedded device EG located.
3. 3. The tool DW calculates a hash value over a randomly selected area of the software HW2 (e.g. SHA256).
4. 4. The tool DW instructs the device EG a hash value over this range HW1 to calculate.
5. 5. The tool DW compares the self-calculated hash value HW2 with the hash value supplied by the device HW1 .
6. 6. If the device EG supplied hash value HW1 deviates from the self-calculated one is the embedded device EG To be regarded as compromised and must be replaced.
7. 7. Steps 2-5 are carried out several times and the random areas B1 - Bn must have all the relevant memory SP1 cover.
8. 8. If all tests are positive, the update for the exchange of the keys or the firmware can be installed.

The memory SP1 in an embedded device EG is limited. Because the areas B1 - Bn from which a hash value is to be calculated by the tool DW can be determined via a random number generator, you can not together with the malware in the device EG be included. For safety, there are various random areas B1 - Bn checked. The areas that contain the public keys (e.g. for checking signed updates) in the device EG are naturally included in the test. Other areas in which there is variable content (eg parameterization) are not checked.

If the tool DW detects that the embedded device EG If the compromised public key has not yet been compromised. For this purpose is in the device EG a second public key with which the update for the public key was signed.

If the check determines that device integrity is no longer given, it can be concluded that either the private key has been compromised or that vulnerabilities have been exploited.

Because the store SP1 in the embedded device EG is limited, it is a device EG with changed memory it is not possible to calculate the hashes. Since the areas for checking are random, the hash values of the malware cannot be known and can already be found in the device. The test must fail and the integrity violation is recognized.

To prevent the device EG loads the hash values over the Internet I from a server of the attacker, a 1: 1 device-PC connection is established for this test or it is ensured in another way that the device does not receive the data from an external source.

As it can happen that the manufacturer is not aware that the private key has been compromised, this check can also be carried out before a "normal" update or as a separate function in a diagnostic tool DW be integrated.

Exemplary advantages of the present invention

The determination of hashes HW1 , HW2 about random areas B1 - Bn of the device memory SP1 of an embedded device to be tested EG . About the random areas B1 - Bn and the number of hashes is not possible for malware to know or calculate the hashes in advance. Due to the simplicity of the procedure, the check can be carried out before each "normal" access. This means that a compromised private key can be identified. Is also a tool DW possible that the integrity of the devices can be determined. The integrity of the tool DW for verification is carried out by signing the tool using a known method.

A signature (i.e. a digital signature) is created by a sender for a message or an electronic artifact (e.g. a software update) using an asymmetric cryptographic procedure with a private key (secret signature key; private key). A recipient can use the public key (public key or verification key) to check the integrity of the message or artifact (e.g. software update, firmware update). Usually, the private key for a digital signature is not applied directly to the message or artifact, but to its hash value, which is calculated using a hash function (such as SHA-256) from the message or from the artifact.

• (VS1) Berechnen eines Hashwertes über einen zufällig bestimmten Bereich der Software durch eine vertrauenswürdige Instanz;
• (VS2) Berechnen eines Hashwertes über den zufällig bestimmten Bereich der Software durch das Gerät selbst;
• (VS3) Vergleichen der berechneten Hashwerte durch die vertrauenswürdige Instanz.

2nd shows an exemplary flow diagram for a method for recognizing whether the software stored on an embedded device corresponds to the delivery state or a valid update. The process comprises the following process steps:

• (VS1) calculating a hash value over a randomly determined area of the software by a trustworthy entity;
• (VS2) calculating a hash value over the randomly determined area of the software by the device itself;
• (VS3) comparing the calculated hash values by the trusted entity.

One area of the software corresponds e.g. Sections (memory sections) in the main memory (RAM) or in a persistent memory (e.g. flash memory) of the embedded device (e.g. IP router) in which the corresponding software is stored.

The randomly determined area of the software is advantageously determined by a random generator of the trustworthy entity. Benefit from a cryptographic random number generator.

The method steps (VS1) to (VS3) are advantageously repeated until hash values have been calculated for each area of the software and have been compared in each case. If all memory areas (RAM and flash memory) in which the software is stored are checked, it is ensured that there is no malware on the embedded device.

Advantageously, hash values are only determined for those areas of the software that include the boot loader and operating system and application software. It saves time if the areas that contain variable data (e.g. configuration data) are not checked.

Some configurations contain keys for symmetric encryption. These keys must not be compromised. The keys are not compromised by calculating a hash via the key. However, the configuration data can be determined and compared by different devices. This enables incorrect configurations to be determined.

Hash values are advantageously determined, in particular, for software areas which contain the public keys.

The method is advantageously carried out only when the device and the trustworthy entity are connected to one another in an exclusive communication connection.

It is advantageous to carry out the procedural steps VS1 - VS3 the embedded device is isolated from other devices and especially from the Internet and rebooted. This ensures that there is no persistent malware in the RAM (RAM) of the embedded device.

The method can e.g. be carried out by means of an appropriately set up device (e.g. diagnostic tool or engineering tool) with appropriate software and hardware equipment.

Method and device for recognizing whether the software stored on an embedded device corresponds to the delivery status or a valid update, the device being a trustworthy device; wherein the device is configured to calculate a hash value over a randomly determined area of the software; and wherein the device is further configured to compare a hash value calculated by the device itself of the randomly determined area of the software with the hash value calculated by the device.

Reference list

EG

Embedded device

DW

Diagnostic tool

KV1, KV2

Communication link

SP1, SP2

Storage

P1, P2

processor

B1 - Bn

Area

HW1, HW2

Hash value

VS1 - VS3

Procedural step

Claims (10)

Process for recognizing whether the software stored on an embedded device (EG) corresponds to the delivery status or a valid update, the process comprises the following process steps: (VS1) calculating a hash value (HW2) over a randomly determined area (B1 - Bn) of the software by a trustworthy entity (DW); (VS2) calculating a hash value (HW1) over the randomly determined area (B1 - Bn) of the software by the device (EG) itself; (VS3) comparing the calculated hash values (HW1, HW2) by the trustworthy entity (DW). Procedure according to Claim 1 , the randomly determined area (B1 - Bn) of the software being determined by a random generator of the trustworthy entity (DW). Method according to one of the preceding claims, wherein the method steps (VS1) to (VS3) are repeated until hash values (HW1, HW2) have been calculated and compared in each case for each area (B1-Bn) of the software. Method according to one of the preceding claims, wherein hash values are determined only for the areas (B1 - Bn) of the software which comprise the boot loader, operating system and application software. Method according to one of the preceding claims, wherein hash values are determined in particular for software areas (B1-Bn) which contain the public keys (public key). Method according to one of the preceding claims, the method being carried out only if the device (EG) and the trustworthy entity (DW) are connected to one another in an exclusive communication connection (KV1). Method according to one of the preceding claims, wherein the method is used to compare configurations of different devices (EG). Device (DW) for recognizing whether the software stored on an embedded device (EG) corresponds to the delivery status or a valid update, the device (DW) being a trusted device; the device (DW) being set up to calculate a hash value (HW2) over a randomly determined area (B1 - Bn) of the software; wherein the device (DW) is further configured to compare a hash value (HW1) of the randomly determined area (B1 - Bn) of the software calculated by the device (EG) with the hash value (HW2) calculated by the device (DW). Device (DW) after Claim 8 , The device being set up to calculate the respective hash values (HW2) of randomly determined areas (B1 - Bn) of the software and with the respective hash values (HW1) of these respective areas (B1 - Bn) calculated by the device (EG) itself to compare each. Device (DW) after Claim 8 or 9 , comprising an interface for an exclusive communication connection (KV1) to the device (EG).

Images