Method for detecting an anomaly suggesting an operation during a secure startup operation of a software-controlled device

Abstract

The present invention relates to a method for detecting anomalies suggesting manipulation during a secure boot operation of a software-controlled device, said method comprising, inter alia, checking the operating parameters of system components necessary for the operation of a microprocessor, checking flags indicating a boot operation that has not been properly completed, and checking a signature-based authenticity of the loaded software or of the loaded software components. In case of a multi-stage boot operation, a counter value assigned to a particular step is compared with an associated reference value. In case of a fault, each check can emit a signal, which, optionally together with further signals, allows the type of attack to be identified so that specific countermeasures can be initiated.

Description

Technical Field

[0001] The present invention relates to a method for recognizing or identifying an abnormality (for example, an abnormality occurring during an attempt to operate) during a secure boot operation of a software-controlled device.

Background Art

[0002] Many modern devices are controlled by software, which is read from a storage medium, transferred to main memory, and finally executed by a processor in the main memory when each device is powered on.

[0003] Available software is generally not monolithic and can be directly executed in non-volatile memory, such as flash memory. Therefore, individual components for execution must be loaded from non-volatile memory to main memory. Software components are generally stored in a file system adapted to the type of memory so that their locations can be identified based on their file names in non-volatile memory. Immediately after booting a software-controlled device, the microprocessor cannot access the file system because it does not understand the structure of the file system. Therefore, first, it is necessary to load specific auxiliary software that configures the microprocessor to access the file system of the non-volatile memory.

[0004] The specific auxiliary software is first loaded and executed by the firmware of the computer system from a defined memory area (boot sector) of the bootable medium. This firmware is also called a boot loader or a boot program. Then, the boot loader loads further parts of the operating software.

[0005] The bootloader may be subdivided into a plurality of stages that are stacked on top of each other, in which case it becomes a multi-stage bootloader. Such subdivision into each stage is performed, for example, when the program code of the bootloader cannot be completely accommodated in the boot sector of the boot medium. First, only the first stage is loaded and executed, and then the second stage, which the first stage only knows about in terms of length, block number, and media identification information, is loaded and executed. Here, the second stage can handle the specific file system of the media and, for example, load the third stage based on the file name. Here, the third stage is the actual bootloader, and the actual bootloader loads, for example, a configuration file including a selection menu or software components necessary for the operation of the device in a predetermined order if appropriate.

[0006] This multi-stage structure of the bootloader has several advantages. In this regard, in the above case, since the second stage can already handle the file system of the media and can find the third stage based on the file name, the file of the actual bootloader loaded in the third stage can be arbitrarily changed or even physically shifted on the media. In addition, such a bootloader is not subject to the length limitations of the boot block or boot sector.

[0007] Certain devices (e.g., complex machines that are recognized in accordance with regulations and mainly have secure operating points or areas compiled, or devices that control machines that store or process highly personal, commercial, or social value data) are subject to specific requirements regarding the fault tolerance of their operation.

[0008] As is the case in almost all technical fields, here too, attempts are repeatedly made to manipulate the software of such devices, whether it is to change an operating point or area, or to gain access to data or other values.

[0009] To prevent attempts to manipulate software, the device may be configured to load only signed software components, preferably during the boot operation. The signature of each software component is checked before execution, and a security component is configured during the boot operation. This security component is for recognizing operations on software modules during the operation of the device and for configuring countermeasures if necessary. This procedure is also called a secure boot operation or "secure boot".

[0010] During the secure boot operation, for example, a so-called Message Authentication Code (MAC) can be used to verify the origin of software components, data, or messages and to check their integrity.

[0011] The MAC algorithm requires two input parameters, namely the data to be protected and a secret key. Both are used to calculate a checksum, i.e., a message authentication code.

[0012] In the boot operation, the integrity of the software components to be loaded can be checked by the MAC as follows. The private key is stored in a secure memory or memory area of the device, and only the authorized software manufacturer for the device knows the private key otherwise. The software manufacturer calculates the MAC for this key and its software components. The software components and the associated MAC are stored in the non-volatile memory of the device, read from there into the main memory, and executed by the microprocessor as needed. Before the software components are executed, the security function calculates the MAC for the software components stored in the non-volatile memory using the key stored in the secure memory area of the device, and compares the calculated MAC with the MAC stored for the software components. The security function interprets the correspondence of both values as a normal integrity test. That is, it is assumed that the software components are provided by an authorized software manufacturer who knows the private key and have not been changed in the non-volatile memory.

[0013] The MAC is either based on a block cipher, based on a hash function, or a specially developed MAC. HMAC, which is one of the conventional methods of MAC calculation, is based on a cryptographic hash function and is used, for example, in communication methods such as SSL and IPsec. One of the widely used methods among the methods based on block ciphers is the cipher-based message authentication code (CMAC) defined in the NIST SP series document 800-38B, and this code is used together with the AES or triple DES cipher method.

[0014] Here, when a symmetric key is used for software verification, an attacker may try to obtain knowledge of the private key so that the attacker can generate a valid and authenticated MAC for any software. Then, this software is recognized as valid in the check and executed without hesitation.

[0015] Depending on the security measures of the key, this can be very time-consuming and laborious for the attacker. Therefore, another type of attempt is often made to infiltrate the system with modified software or modified software components, in which case a valid signature is not generated for the modified software or modified software components.

[0016] For this purpose, in the case of a device configured for secure boot operation, an attempt is made, if not already all security functions are ready and the boot operation is not correctly parameterized, to provide conditions that would allow the replacement of the original software components with modified software components. Then, these modified software components can be used, for example, during the boot operation or during the operation of the device, to allow the attacker to access operation parameters or data, etc., thereby ultimately achieving the actual purpose of the attack.

[0017] For this purpose, for example, side-channel attacks are used. Side-channel attacks include attacks on system components that are clearly unrelated to the normal execution of software components, or system parameters that are clearly unrelated to the execution of software components, especially to cause the microprocessor to execute unauthorized program code. Side-channel attacks can include, among other things, the manipulation of the microprocessor's clock frequency. This puts the attacker in a position where they can more easily manipulate the address and the data line between the microprocessor and the non-volatile memory to execute code from a memory address where unauthorized code generated by the attacker, different from the code the microprocessor was actually operating on or provided, is placed.

[0018] In a CMAC-based secure boot operation, an attacker generally tries to modify the last block of software or a software component, for example, by directly accessing the memory interface or the data line connecting the memory to the processor, immediately after the CMAC verification of the genuine software or genuine software component has been successfully completed and before its execution. For example, when an AES-based CMAC is used, the attacker generally modifies the last 128-bit block containing the last program instruction to be executed in order to execute an attack against the secure boot operation after authentication. In this case, the attacker tries to cause the processor to execute program code that configures a communication connection via an interface that is provided to a different memory area by the attacker and that contains, for example, a user created by the attacker and the access data of that user, or that is not provided to the original software or software component. In most attempts, this modification ultimately leads to a failure that initiates a reboot of the device. Therefore, the attacker changes the modification of the last block of software after each reboot until the device executes program code in a different memory area and the attacker obtains the desired access. This attack targets not the access provided by the device during normal operation, but rather an attempt is made to operate the device in a different manner (in this example, by reducing the clock frequency and manipulating the address and data lines), and thus this type of attack is also called a side-channel attack.

[0019] Side-channel attacks against CMAC-based secure boot operations are distinguished, inter alia, by frequent changes to at least one block of software during the boot operation, multiple consecutive failed boot operations, multiple reboot attempts within a short period after an operation time less than a predetermined minimum operation time despite the reboot having been originally executed normally, abnormal resource allocation during the boot operation, and / or manipulation of the clock frequency prior to the boot operation. The manipulation of the clock frequency is primarily intended to simplify external access to the address and data lines.

[0020] Such attacks are generally carried out offline, i.e., locally, and since there is no network connection to the attacked device that would allow the attack to be recognized, the device owner or manufacturer cannot gain knowledge of the attack and, as a result, cannot take countermeasures.

[0021] In particular, when a microprocessor-controlled device has limited resources, i.e., only a small memory or low computing power, complex protection means capable of recognizing side-channel attacks cannot be avoided from at least degrading the system performance to an unacceptable level and cannot be simply implemented.

[0022] German Patent Application Publication No. 102019127856A1 discloses a method for secure boot of a control device. The method includes a hardware security module (HSM) and a host. After voltage is applied to the control device and the HSM is at least partially booted, a check is performed to determine whether a flag assigned to the HSM is set to a first value or a second value. If the flag is set to the second value, a check of the integrity and authentication of the software assigned to the control device is executed. If the flag is set to the first value, the boot operation of the HSM is completed by transmitting a request to boot the host from the HSM to the host. If the integrity and authentication check is positive, the flag is set to the first value and a reboot of the HSM is initiated. Then, a check is performed again to determine whether the flag is set to the first value or the second value. The boot operation of the HSM is completed by transmitting a request to boot the host from the HSM to the host if the flag is set to the first value.

[0023] U.S. Patent No. 9,740,863 B2 discloses a device and method for protecting a secure boot operation from side-channel attacks. This device is composed of hardware suitable for encryption for a first boot operation. In addition, a non-volatile memory for storing the operated boot operation is provided. A comparison unit compares the number of operated boot operations with a maximum value. The comparison can be based on the number of read operations of a first real-time clock and a second clock in the non-volatile memory. Based on this comparison, the control logic transfers control from the first boot operation to the second boot operation.

[0024] German Patent Application Publication No. 102019008059A1 discloses a system and method for minimizing the probability that the private key used by the bootloader is subject to unauthorized access. The bootloader is installed on the device. The bootloader is a software program that performs many functions. These functions may include checking the integrity of the checksum of the received software image, decrypting the received software image using the private key, deleting data in the flash memory, installing a new software image in the flash memory, and the like. The bootloader utilizes various techniques to track the version of the software image to be installed. This method also counts the number of incomplete attempts made when attempting to update the software image. By monitoring these parameters, the bootloader can determine the timing at which malicious actors attempt side-channel attacks. Accordingly, the bootloader can deny permission to load a new software image or access the private key.

[0025] German Patent Application Publication No. 102009000874A1 describes a method and system for improving the analyzability of software errors in a microcontroller. A monitoring module assigned to the microcomputer checks at least one function of the microcontroller and generates a signal when a malfunction of the microcontroller is recognized. This signal causes at least indirectly a reboot of the microcontroller. At least one software element executed during the operation of the microcontroller is restarted during the reboot. In the error-free operation of the microcontroller, at least one item of condition information is stored in the memory, the condition information includes at least the condition of the instruction counter, and the memory is not immediately overwritten or erased during the reboot. During or after the reboot, the item of condition information stored in the memory is accessed, and the condition information for analyzing the software error becomes available. SUMMARY OF THE INVENTION

Problems to be Solved by the Invention

[0026] Therefore, an object of the present invention is to propose a method for recognizing different types of attacks and providing corresponding information for starting or initiating countermeasures adapted to each of them without significantly degrading system performance.

Means for Solving the Problems

[0027] The above object is achieved by the method according to claim 1. Advantageous embodiments and further developments are described in the respective dependent claims.

[0028] The following method for recognizing types of attacks against secure boot operations according to the present invention is preferably executed in a separate monitoring component that executes this method in parallel with the actual boot process. Alternatively, the method may also be stored as part of the firmware, preferably in a non-modifiable manner or only modifiable when it is simultaneous with additional security functions, and implemented as a separate process of the first-started bootloader.

[0029] According to the present invention, the method includes, as a first component executed before the first authentication of the software to be loaded or the software component to be loaded, or before the check of the hash value or checksum for the last block of the software or software component and optionally further blocks, reading at least one operating parameter from at least one system component necessary for the operation of the microprocessor, and comparing the at least one read operating parameter with a corresponding stored reference value. The at least one operating parameter may relate to, for example, the supply voltage supplied by a power management unit or the clock signal supplied by a clock generator of the system or microprocessor and further components. The related reference value is preferably read from a particularly secure memory area and / or may be stored in an encrypted and secure manner. If the comparison shows a difference, a first signal is output indicating the recognized side-channel attack and the failed boot operation, and the method and further boot operations are terminated or terminated. Otherwise, further components of the method are executed.

[0030] This method additionally includes checking the state of a flag set in the boot operation that has not yet completed successfully as a second component that is also executed before the first authentication of the software to be loaded or the software component to be loaded, or before the check of the hash value or checksum for the last block and optionally further blocks of the software or software component. If the flag is set, a second signal is output indicating the recognized attack and the failed boot operation, and the method and further boot operations are terminated or aborted. If the flag is not set during the check, the flag is then set and further components of the method are executed. Preferably, the flag is set in non-volatile memory such that it retains its state for a relatively long time even without a power supply. This component can be used, inter alia, to recognize fault injection attacks that often lead to a reset at a specific point in time before the end of the boot operation, for example due to a watchdog signal. The watchdog recognizes a boot operation that has stopped after a certain time due to an unacceptable change in the software or software component, or due to a so-called "hard" reset (i.e., a reset forced by disconnecting the device from the power supply) caused by an attacker. Since the flag has not been deleted, it can be recognized during a subsequent boot operation, in contrast to when the boot operation has ended properly.

[0031] The method additionally includes, as a third component, calculating an authentication code for the software or software component to be loaded, and as a first check step, comparing the calculated authentication code with the authentication code of the preceding boot operation read from memory. If the comparison shows a difference, a third signal is output indicating the recognized fault injection attack and the failed boot operation, and the method and further boot operations are terminated or ended. Otherwise, as a second check step, the previously calculated authentication code is compared with a reference code read from memory, preferably a secure memory or memory area. If the comparison shows a difference, a fourth signal is output indicating the recognized fault injection attack and the failed boot operation, and the method and further boot operations are terminated or ended. If no attack is recognized and the boot operation is not terminated and all components are executed, the stored authentication code of the preceding boot operation is replaced with the authentication code calculated for the current boot operation, the flag set in the boot operation not yet completed normally is deleted, and the method ends. Optionally, a signal can be output indicating that the secure boot operation has been executed successfully.

[0032] Instead of calculating an authentication code for comparison with the corresponding authentication code of the preceding boot operation (which can involve a significant computational complexity in certain situations), in the first check step of the third component, a hash value or checksum, such as a CRC value, is calculated for the last block and optionally further blocks of the software or software component and compared with the value of the same block stored in the previous boot operation. As a result, the complexity of the first check step can be kept low, and the more complex calculation of the authentication code need only be performed if no attack is confirmed in this first check step. This is advantageous especially for devices at risk of frequent attacks.

[0033] Common failures of software or software components (e.g., due to memory errors) have the same hash value or checksum for multiple boot operations, but the hash values or checksums in the case of an attack are different from each other due to changes generally in the last block in each boot operation.

[0034] When a multi-stage boot operation is performed, i.e., when multiple programs or software components are loaded sequentially, the method may include a fourth component that monitors the corresponding correct multiple executions of the third component. The fourth component includes comparing a value assigned to the currently loaded stage with a reference value assigned to this stage. The value assigned to the currently loaded stage may be, for example, part of a file containing program code, or may be locatable based on a file name or other features in a table. The reference values for each stage or table of the secure boot operation may be readable, for example, from a secure memory or memory area.

[0035] If the individual stages must be processed sequentially in a specific order, a counter value may be stored in the software or software component of each stage, and the counter value is compared with the current counter value. After the software or software component of a certain stage is processed normally, the counter is incremented before the next stage is loaded so that a new counter value is available for comparison in the next stage. When the fourth component of the method is called, the counter is first reset, and correspondingly the software or software component of the first stage includes the value 0.

[0036] If the comparison shows a difference, a fifth signal is output indicating the recognized fault injection attack and the failed boot operation, and the method and further boot operations are terminated. In this case, among other things, a counter value enabling identification of the affected software or software component may be provided for evaluating the type of attack and / or stored for subsequent security improvements.

[0037] If the comparison shows no difference, the execution of the boot operation continues and the fourth component checks subsequent stages until the last stage of the boot operation indicated by the corresponding reference value is loaded.

[0038] In one or more embodiments of the method, it is preferred that unique time information is stored in a secure memory or memory area and / or encrypted with a private key stored in the device at the start of the boot operation and / or after normal completion. For each new boot operation, the current time information is preferably compared with the stored time information, preferably before the first authentication of the software or software component. If the difference between the two items of time information is less than or equal to a predetermined value, a sixth signal is output indicating the recognized attack and the failed boot operation. Thereafter, the method is terminated and further boot operations are terminated.

[0039] In an alternative embodiment, multiple points in time of consecutive reboot operations are stored and compared with the maximum number of reboot operations allowed within a given first period. If the number of reboot operations exceeds the maximum allowed, a sixth signal is output notifying of the recognized attack and the failed boot operation. Thereafter, the method ends and further boot operations are terminated. This embodiment is particularly suitable when sufficiently accurate time information independent of the system is not immediately available at the start of the boot operation, but rather is provided only after the system has been started up from an external time signal such as, for example, a GPS, NTP server, DCF-77 radio signal. These embodiments utilize the insight that a large number of attacks fail and are terminated and repeated in a short period, in which case either no successfully completed boot operation occurs or the actual operating period after a normal boot operation is shorter than a previously defined "normal" minimum operating period.

[0040] The two above-described embodiments are particularly well-suited for generating signals for recognizing fault injection attacks which generally require resource-intensive monitoring of program execution. However, fault injection attacks can also be distinguished by a series of specific events or characteristics, in particular, manipulation of the clock frequency, cold boot, i.e., a boot after a relatively long period without operation, or frequent reboot operations of the first device after a so-called "hard" reset, or repeated execution of the same software part in the actual boot operation and interruption of the entire verification chain (where only a specific stage of the boot operation is repeatedly executed and verified and terminated when the verification fails). A hard reset can be recognized, for example, using a flag in a boot operation that has not yet been successfully completed. Further flags can be set by software executed after a properly executed boot operation so that the software can distinguish the reason for the reboot based on the state of the two flags when starting a reboot of the device. In this case, when the device is properly shut down or put into a standby state, the flags can be deleted, for example, even if they were previously set.

[0041] In one or more embodiments of the method, where the inherent time information is stored at the start of the boot operation and / or after normal completion, the start and / or normal completion of the boot operation is confirmed, for example, by corresponding data provided by a power management IC, based on the typical power consumption at start and / or normal completion. The power consumption typically reaches a minimum during successive boot operations and then rises rapidly again.

[0042] In one or more embodiments of the method, the start of the boot operation is determined based on a reset signal output by a microprocessor. Such a reset signal is often used to boot further components of a first device that need to be brought into an operating state only during the operation of the first device as well.

[0043] In one or more embodiments of the method, the allocation of at least one system resource of the first device is monitored during the boot operation. For example, the processor cache is emptied, and the frequency with which it is reallocated from zero to the same process, and / or the frequency with which it is written from zero for this process is monitored. The number of allocations of the same system resource to the same process within a predetermined second period is compared to a predetermined maximum value of this system resource. If the number of allocations of the same system resource to the same process exceeds the predetermined maximum value, a seventh signal is output that indicates a recognized attack and a failed boot operation. In addition, the method is terminated and further boot operations are terminated. Here, the term "process" can denote any desired software or software component, thread, etc. This embodiment can be used in particular, preferably, in a multiprocessor system or a system having a multi-core processor. Here, the method is executed exclusively and securely in one of the processors or processor cores, but nevertheless, in this case, access to internal processor system resources can be detected more easily.

[0044] According to a further aspect of the present invention, a device comprises one or more processors, and further volatile and non-volatile memories allocated thereto, which are communicably connected to each other via one or more data lines or data buses. Computer program instructions are stored in the non-volatile memory, and when the computer program instructions are executed by at least one processor, the device is configured to execute one or more embodiments of the method according to the present invention.

[0045] A computer program product according to a further aspect of the present invention includes instructions that, when executed by a microprocessor of a device, cause the microprocessor of the device to execute one or more embodiments and further developments of the above method.

[0046] The computer program product may be stored on a computer-readable medium or data carrier. The medium or data carrier may be in a physical embodiment such as, for example, a hard disk, CD, DVD, or flash memory, but the medium or data carrier may also include a modulated electrical signal, electromagnetic signal, or optical signal that can be received by a computer by a suitable receiver and stored in the memory of the computer.

[0047] The method according to the present invention makes it possible to recognize side-channel attacks or fault injection attacks against the secure boot operation while suppressing the load on system resources and system performance compared to conventional encryption methods. In particular, in a time-critical boot operation of software or software components that must be completed within a specific maximum time, for example, in a system context of a plurality of processes operating at least partially in parallel, a system, or a plurality of devices communicably connected to each other, it is advantageous that attacks can be recognized almost simultaneously during the boot operation without the boot operation being delayed so much that it can be recognized.

[0048] Therefore, the method according to the present invention can advantageously be used whenever a resource-saving recognition of side-channel attacks or fault injection attacks against the secure boot operation is required, for example, in the case of devices related to the Internet of Things (IoT) or distributed sensor infrastructure.

[0049] Preferably, the software or software component implementing the method is loaded early and as part of the bootloader, ideally before other software or other software components, so that the security function can be prepared as early as possible. Alternatively or additionally, at least individual parts of the method can be executed by a dedicated program-fixed security processor.

[0050] Hereinafter, the present invention will be described in more detail with reference to the accompanying drawings.

Brief Description of the Drawings

[0051]

Figure 1

Figure 2

Mode for Carrying Out the Invention

[0052] In the drawings, the same or similar elements may be referred to by the same reference numerals.

[0053] FIG. 1 shows a flow diagram of an exemplary method 100 for recognizing a side-channel attack against an AES-CMAC-based secure boot operation of a microprocessor-controlled device 200. The purpose here is to recognize the operation of the last 128-bit block of the boot operation. In this example, it is assumed that a reset is executed every time there is a software verification error. When checking authenticity and integrity, the AES-CMAC method is used, and the same key is used at each stage of the boot operation. First, in a first component I, the presence of a side-channel attack is checked. For this purpose, in step 101, at least one currently set operating parameter of at least one system component 208 (e.g., a clock generation unit) of the device 200 that is necessary for the operation of the microprocessor 202 is read, and in step 102, it is compared with a corresponding reference value read from a secure memory area 206a. If it is determined by the comparison that the currently set operating parameter(s) do not correspond to the reference value(s) (the "N" branch of step 102), the method branches to step 130, and in step 130, a signal is output indicating that a side-channel attack has been recognized and the secure boot operation has failed. Depending on the signal, corresponding countermeasures can then be taken.

[0054] If it is determined by the comparison that the currently set operating parameter corresponds to the reference value (the "Y" branch of step 102), the method branches to step 103 of a second component II. Step 103 includes checking whether a flag "boot operation not yet completed successfully" has been cleared. If the flag is set, i.e., not cleared (the "N" branch of step 103), the method branches to step 130, and in step 130, a signal is output indicating that the previous boot operation did not end correctly, that an attack is present, and that the secure boot operation has failed. Depending on the signal, corresponding countermeasures can then be taken.

[0055] If the flag has been deleted, i.e., not set (the "Y" branch in step 103), the flag is set in step 104. Thereby, the software provided for the secure boot operation or the corresponding software component can be loaded and further security checks can be performed.

[0056] In step 105 of the fourth component IV, the counter of the stage where the current boot operation has been executed normally is reset, and in step 106, a check is performed to confirm whether the counter of the stage where the boot operation has been executed normally corresponds to the reference value of the current stage. The reference value for each stage of the secure boot operation can be stored, for example, in a secure memory area. In this case, the software or software component of the stage can be identified based on, for example, a file name or other characteristics and compared with the correspondingly assigned reference value.

[0057] If the individual stages must be processed continuously in a specific order, for example, a counter value may be stored in the software or software component of each stage, and the counter value is compared with the current counter value. Since the counter is reset in step 105, accordingly, the software or software component of the first stage includes the value 0. Each software or software component of the stage increments the counter after normal processing so that the new counter value is available for comparison in the next stage.

[0058] Instead of incrementing the counter, it is also possible to write any value to the memory after normal processing, and that value is read by each stage. In that case, the corresponding value of the preceding stage must be programmed into each software or software component. This is possible especially when all stages are provided by a manufacturer who knows that value. This security feature can recognize whether a stage of the secure boot operation has been skipped or omitted.

[0059] Step 107 of the third component III executes the authentication of the software or software components to be loaded according to each implementation form in the device. For example, based on the private key stored in the secure memory area, the CMAC of the software or software components to be loaded is calculated, stored, and in step 108, it is compared with the result stored in the same way as the authentication of the previous secure boot operation. In the first boot operation, optionally, in a secure environment, the correct value of the previous secure boot operation can be written to the memory, or an error message that cannot be applied and the termination of the boot operation can be suppressed in some other way. If it is found by comparison that the results of two directly consecutive authentication operations are different from each other (the "N" branch of step 108), typically, there is a fault injection attack related to the block of software or software components that are changed in each boot operation, and thus, it can be assumed that different MACs are calculated in each boot operation and the secure boot operation has failed. Accordingly, the method branches to step 130, and in step 130, a signal is output indicating that there is a fault injection attack and the secure boot operation has failed.

[0060] If it is found by comparison that the results of two directly consecutive authentication operations are the same (the "Y" branch in step 108), in step 109, the authentication result is compared with a reference value read from a secure memory area for the authentication of this software or software component. If it is found by comparison that the authentication result also corresponds to the reference value for authentication (the "Y" branch in step 109), in step 110, the authentication result from step 107 is stored as the new result of the authentication of the preceding secure boot operation. In the process, the previously stored result is overwritten. By storing the result of the latest authenticity check each time, it is possible to quickly recognize a fault injection attack in step 108. If, despite the same values for two consecutive boot operations, the result does not correspond to the reference value, for example, a memory error can be presumed. Changes in the values stored between step 109 and step 110 are also recognized in this way. In the subsequent step 111, the counter for the normally executed stage of the boot operation is incremented, and in step 112, a check is performed to determine whether the value of the incremented counter corresponds to the stored reference value for the last stage of the boot operation. In the affirmative case (the "Y" branch in step 112), in step 113, the flag "boot operation not completed normally" is deleted, and the secure boot operation ends normally.

[0061] If it is found by the comparison in step 109 that the authentication result does not correspond to the reference value for authentication (the "N" branch in step 109), in step 120, the flag "boot operation not completed normally" is deleted, a signal is output, and in response to the signal, countermeasures for an attack to bypass the secure boot, known to those skilled in the art, can be initiated.

[0062] Figure 2 shows an exemplary block diagram of a device 200 configured to execute one or more aspects of method 100 according to the present invention. In addition to microprocessor 202, device 200 includes volatile memory 204 and non-volatile memory 206, and at least one further system component necessary for the operation of microprocessor 202 (e.g., a clock generator and / or a power management IC). The elements of device 200 are communicatively connected to each other via one or more data lines or a data bus 210. Non-volatile memory 206 includes computer program instructions that, when executed by microprocessor 202, configure the device to execute one or more embodiments of the method according to the present invention.

Explanation of Signs

[0063] 100 Method 101 Read the operating parameters of the clock generation unit 102 Compare the operating parameters with the reference value 103 Is the flag set? 104 Set the flag 105 Reset the stage counter 106 Does the read value of the counter match the current stage of the boot operation? 107 Calculate the authentication code / hash value / checksum 108 Does the authentication code / hash value / checksum match the previous boot operation? 109 Compare the authentication code / hash value / checksum with the corresponding reference value 110 Store the authentication code / hash value / checksum 111 Increment the counter 112 Has the last stage been reached? 113 Delete the flag 120 An attack to bypass secure boot is recognized and the boot operation fails 130 A side-channel attack is recognized and the boot operation fails 200 Device 202 Microprocessor 204 Volatile Memory 206 Non-Volatile Memory 206a Secure Memory Area 208 Further System Components 210 Power Line or Data Line / Bus

Claims

1. A method (100) for recognizing types of attacks against a secure boot operation of a microprocessor-controlled device (200), comprising: reading, by a microprocessor (202), at least one operation parameter from at least one system component (208) necessary for the operation of the microprocessor (202) (101), and comparing, by the microprocessor (202), the at least one read operation parameter with a corresponding stored reference value (102), wherein if the comparison shows a difference, a first signal indicating a recognized side-channel attack and a failed boot operation is output, the method is terminated, and further boot operations are terminated; checking, by the microprocessor (202), the state of a flag set in a boot operation that has not yet completed successfully (103), wherein if the flag is set, a second signal indicating a recognized fault injection attack and a failed boot operation is output, the method is terminated, and further boot operations are terminated, and if the flag is not set, the flag is set after the check; The microprocessor (202) calculates a hash value or checksum for at least one block of software or a software component, and the microprocessor (202) compares the calculated hash value or checksum with the stored hash value or checksum for the same at least one block of the software or software component in a previous boot operation, or the microprocessor (202) calculates an authentication code for the software to be loaded or the software component to be loaded (107), and the microprocessor (202) compares the calculated authentication code with the authentication code of a previous boot operation read from memory (108), and if the comparison shows a difference, a third signal is output indicating the recognized attack and the failed boot operation, the method ends, and further boot operations are terminated, and If not already done previously, the microprocessor (202) calculates an authentication code for the software to be loaded or the software component to be loaded (107), and the microprocessor (202) compares the calculated authentication code with a reference code read from memory (109), and if the comparison shows a difference, a fourth signal is output indicating the recognized fault injection attack and the failed boot operation, the method ends, and further boot operations are terminated, and The microprocessor (202) replaces the authentication code of the previous boot operation read from the memory with the authentication code calculated for the current boot operation (110), and the microprocessor (202) deletes the flag set in the boot operation that has not yet been successfully completed (113) and A method (100) comprising. Claim 2 If the boot operation is of a multi-stage design, the microprocessor (202) compares the current stage of the multi-stage boot operation with a reference value assigned to this stage (106). If the comparison shows a difference, a fifth signal is output indicating the recognized fault injection attack and the failed boot operation, the method ends, further boot operations are terminated, and if not, the execution of the boot operation and the loading of subsequent stages continue until the last stage of the boot operation indicated by the corresponding reference value is loaded. The method (100) according to claim 1, further comprising.

3. At the start of the boot operation and / or after normal completion, the microprocessor (202) stores unique time information. The microprocessor (202) compares the current time information with the time information stored in the previous boot operation for each new boot operation. If the comparison shows a difference smaller than a predetermined value, a sixth signal is output indicating the recognized attack and the failed boot operation, the method ends, and further boot operations are terminated. The method (100) according to claim 1, further comprising.

4. At the start of the boot operation and / or after normal completion, the microprocessor (202) stores unique time information. The microprocessor (202) compares the number of previous reboot operations within a predetermined time for each new boot operation with the allowed maximum value. If the number of reboot operations exceeds the allowed maximum value, a sixth signal is output indicating the recognized attack and the failed boot operation, the method ends, and further boot operations are terminated. The method (100) according to claim 1, further comprising.

5. The method according to claim 3, wherein the start and / or the normal completion of the boot operation are confirmed based on a typical power consumption for the start and / or the normal completion.

6. The method according to claim 3, wherein the start of the boot operation is determined based on a reset signal output by the microprocessor (202).

7. Monitoring, by the microprocessor (202), the allocation of at least one system resource of the device (200) in the boot operation, comparing, by the microprocessor (202), the number of allocations of the same system resource to the same process within a predetermined second period with a predetermined maximum value for this system resource, and when the number of allocations of the same system resource to the same process exceeds the predetermined maximum value, outputting a seventh signal indicating the recognized attack and the failed boot operation, terminating the method, and terminating further boot operations, The method according to claim 1, further comprising.

8. A device (200) comprising at least one processor (202) communicatively connected to each other via one or more data lines or one or more data buses (210), a volatile memory (204) and a non-volatile memory (206), and at least one further system component (208) necessary for the operation of the microprocessor, wherein computer program instructions are stored in the non-volatile memory (206) in an accessible manner, and when the computer program instructions are executed by the at least one processor (202), the device (200) is configured to execute the method (100) according to any one of claims 1 to 7.

9. A computer program comprising computer program instructions that, when executed by a microprocessor (202) of a device (200), cause the microprocessor (202) to execute the method (100) according to any one of claims 1 to 7. Claim 10 A computer-readable recording medium having recorded thereon the computer program according to claim 9.

Images