Method for securely starting up the device software, in particular the operating system, of an electronic device

Abstract

A method for securely starting up a device software, in particular an operating system, of an electronic device, wherein a plurality of successive software modules (11, 12, 13, 14, 15) containing software code are executed by the device, the method comprising the steps of: a) executing (S1) a first software module (11), b) loading (S2) a subsequent software module (12) by a preceding software module (11), c) checking (S3) the software code of the subsequent software module (12) and identifying security features according to an identification scheme (M1), d) evaluating (S4) the identified security features according to security criteria (P1), e) if the evaluation results in a confidence value above a pre-given threshold, executing (S5) the subsequent software module (12), and f) performing (S6) steps b) to e) for all respectively subsequent software modules (13, 14, 15).

Description

Technical Field

[0001] The present invention relates to a method for securely starting up device software, in particular an operating system, of an electronic device, in which a plurality of successive software modules containing software code are executed, and to a startup device and an electronic device configured to execute the method. Background Art

[0002] In the past, the Basic Input / Output System (BIOS for short) was in charge of starting up the device (also referred to as the boot device) and in particular installing the operating system. Now, instead of the BIOS, modern electronic devices often use the Unified Extensible Firmware Interface (UEFI for short). This UEFI firmware has the advantage that it is built from components in a modular manner and can be easily extended. Example components are components for remotely maintaining the electronic device, components for digital rights management, components including an emulation of the old BIOS functionality, etc. In particular, the UEFI firmware provides components for securely starting up and running the device, which are referred to as Secure Boot.

[0003] This Secure Boot technology checks whether the individual components of the startup components are signed using a cryptographic key contained in the firmware. By checking the signatures of the individual startup components constructed as software code, the proper startup of the device is ensured cryptographically. Thereby, it can be ensured that the individual software modules and thus the software code contained therein exist unchanged. However, this does not ensure that the installed operating system does not contain malicious programs or security vulnerabilities due to which the electronic device becomes vulnerable or insecure during operation. Summary of the Invention

[0004] Therefore, the object of the present invention is to identify security vulnerabilities or malicious programs early on and thereby avoid later manipulation of the electronic device based on security vulnerabilities in the operating system.

[0005] This object is solved by the features mentioned in the independent claims. Advantageous refinements of the present invention are shown in the dependent claims.

[0006] According to a first aspect, the present invention relates to a method for securely starting up device software, in particular an operating system, of an electronic device, in which a plurality of successive software modules containing software code are executed by the device, the method comprising the steps of:

[0007] a) Executing a first software module, the first software module including trusted software code and constituting a root of trust,

[0008] b) Loading subsequent software modules by the previous software module,

[0009] c) Inspect the software code of the subsequent software module and identify security features according to an identification scheme.

[0010] d) Evaluate the identified security features according to security criteria.

[0011] e) If the evaluation results in a confidence value above a pre-given threshold, execute the subsequent software module, and

[0012] f) Execute steps b) to e) for all subsequent software modules respectively, where the security feature is a function performed by the software code and the function is not desired within the software module.

[0013] This has the following advantages: The content of the software module following the first software module, i.e., the software code, is inspected not only for cryptographic integrity but also for the presence or absence of pre-given security features before its execution. The inspection and identification are implemented in particular according to an identification scheme, and the identified security features are evaluated according to security criteria. Thus, it can be determined whether the next software module is trustworthy. Therefore, each software module includes the functionality to perform the inspection and evaluation. The identification scheme and security criteria can be included in the software module itself or loaded through the software module respectively. Only after such inspection and evaluation are trustworthy is the subsequent software module executed. Thus, through each software module, it can be evaluated whether the next, i.e., subsequent, software module to be started has trustworthy behavior and can be started. Therefore, the inspection of the functionality of the subsequent software module has been performed during the boot process, rather than at a later time point, especially when the software module has already been executed.

[0014] The device software can be each software unit executed on the device, and the software unit is started by sequentially executing more than one software module. The start of the device software can be implemented when booting the device to start the operating system or during the runtime of the device, such as when starting a user program. The operating system of the device is an exemplary implementation of the device software, which includes a first software module and, as other successive software modules, a boot loader, an operating system kernel, and a user space program. The first software module includes software code in a boot read-only memory (ROM) and is hereinafter referred to as the boot ROM.

[0015] A software module contains software code. The software code is structured such that specific pre-given functions are executed or executable at runtime. For example, a security feature is a function with specific content executed by the software code. For example, a security feature can be a debug interface that is not desired within the software module because it enables access to the software module. Other security features can be, for example, malware or other interfaces that are included in the software code of the software module or are implemented when the software module is executed on an electronic device.

[0016] In an advantageous embodiment, the identification scheme is a machine learning function, in particular a neural network. The machine learning function receives subsequent software modules as input and provides information about the presence or absence of at least one security feature as output.

[0017] This has the advantage that the machine learning function can be trained to recognize a large number of different security features. In addition, the machine learning function (such as a neural network) also recognizes security features that may differ from a fixedly pre-given search pattern. Such a machine learning function applied to the software code of a software module can be used very flexibly and recognizes a large number of security features as well as modifications of hitherto known security features.

[0018] In an advantageous embodiment, the identification scheme is a pattern recognition method and / or a rule-based method.

[0019] This has the advantage that security features whose structure is known as a pattern in the program code are reliably recognized with a low false identification rate (false positive). In the case of a rule-based method, specific rules implemented in the program code are analyzed, and such rules are often used in malware. Thus, security features that use such rules, such as inserting a large number of no-operations, can also be reliably identified.

[0020] In an advantageous embodiment, the security criterion is a positive list or a negative list.

[0021] This has the advantage that security features included in the positive list are classified as trustworthy, or such security features pre-given by the negative list are evaluated as untrustworthy. The positive list can be used to confirm allowed security features, and if, for example, a specific pre-given security feature is present, the software module can be evaluated as trustworthy. In contrast, in the case of the negative list, if one or more security features listed in the negative list are identified, the software module is evaluated as untrustworthy.

[0022] In an advantageous embodiment, each software module uses its own module - specific identification scheme and / or its own module - specific security criteria. Such a module - specific identification scheme or security criteria can be specifically set for the corresponding software module and can identify and evaluate security features specific to the software module.

[0023] In an advantageous embodiment, each software module evaluates the software code of subsequent software modules according to a device - specific identification scheme and / or each software module evaluates the identified security features according to device - specific security criteria that are the same for all software modules.

[0024] The device - specific identification module or device - specific security criteria can be applied in the software module solely or in addition to the module - specific identification module or module - specific security criteria.

[0025] This has the advantage that by means of the device - specific identification scheme and security criteria, in particular, it is possible to achieve that software modules with generally trustworthy security features are always executed on the device. In the case of additional checks or evaluations, a minimum basis of common security features can be checked, and nevertheless, other security features can be evaluated as untrustworthy by means of the device - specific security criteria.

[0026] In an advantageous embodiment, a module - specific device trustworthiness value is determined by each individual software module according to the device - specific security criteria, and a total device trustworthiness value is determined from all module - specific device trustworthiness values.

[0027] Thus, the trustworthiness of the entire startup process can be determined, which takes into account the trustworthiness of each individual software module. Thus, although each individual subsequent software module has been evaluated with a module - specific device trustworthiness value above a pre - given threshold and has thus been evaluated as trustworthy, for example, the startup process can still be classified as untrustworthy. This enables the chain of startup modules of the device to be additionally considered overall.

[0028] In an advantageous embodiment, different module - specific security criteria and / or different device - specific security criteria are used for different structurally identical electronic devices.

[0029] This enables the following: Different functionalities are permitted on devices with the same structure. Thus, specific functionalities are released during the startup process, and for example, license specifications are implemented. For example, it is possible to achieve by using different security guidelines on devices with the same structure that, on one of the devices, software using Gigabit Internet may not be run, even if the hardware would be capable of this. Thus, general device functionalities can be permitted or not permitted.

[0030] In an advantageous embodiment, at least one identification scheme and / or at least one security guideline is / are protected cryptographically, and each software module cryptographically verifies its assigned identification scheme and / or its assigned security guideline before execution.

[0031] Protecting the identification scheme and security guideline cryptographically and having each software module verify the identification scheme and security guideline ensures the integrity of the identification scheme and security guideline, and thus ensures that there are no unauthorized modifications. For example, cryptographic protection can be provided by cryptographic signatures or encryption.

[0032] In an advantageous embodiment, at least one identification scheme and at least one security guideline of subsequent software modules are protected cryptographically, and the software module cryptographically verifies the assigned identification scheme and / or the assigned security guideline of the subsequent software module.

[0033] Thus, the cryptographic integrity of the assigned identification scheme and the assigned security guideline is verified before the software code is loaded. It is thus ensured that only unmodified identification schemes and security guidelines are loaded into the next software module, and thus subsequent loading phases as well as further verification and evaluation of the chain of software modules are carried out as required. Here, for at least the first software module, this verification preferably takes place in secure hardware, such as a secure element or, for example, a Trusted Platform Module (also known as Trusted Plattorm Modul (Trusted Platform Module, TPM)).

[0034] In an advantageous embodiment, the software code exists as object code.

[0035] Object code represents the translated software code, which is also referred to as machine code. This has the advantage that manipulations of the software code during the transformation from source code to object code, for example by a compiler, are taken into account during verification, since such manipulations are reflected in the object code.

[0036] In an advantageous embodiment, if the confidence value and / or the module-specific device confidence value and / or the overall device confidence value results in a value that is equal to or lower than a respectively pre-given threshold value, a substitute function is executed.

[0037] By means of this substitute function, even in the absence of confidence, the method switches to a known pre-given state. For example, other measures, log entries or warning messages are triggered by the substitute function.

[0038] A second aspect of the invention relates to a boot device for a device software, in particular an operating system, for securely booting an electronic device, the boot device being connectable to the electronic device, the boot device comprising at least one processor, the processor being configured to load a plurality of successive software modules containing software code and to perform the following steps:

[0039] a) Execute a first software module by means of a security device, the first software module comprising trusted software code and constituting a root of trust,

[0040] b) Load subsequent software modules by means of the preceding software modules,

[0041] c) Examine the software code of the subsequent software module and identify security features according to an identification scheme,

[0042] d) Evaluate the identified security features according to security criteria,

[0043] e) If the evaluation results in a confidence value above a pre-given threshold, execute the subsequent software module, and

[0044] f) Perform steps b) to e) for all other subsequent software modules, where the security feature is a function executed by the software code, the function being undesirable within the software module.

[0045] A third aspect of the invention relates to an electronic device, the electronic device comprising at least one processor, the processor being configured to load device software, in particular an operating system, by means of a plurality of successive software modules containing software code and to perform the following steps:

[0046] a) Execute a first software module by means of a security device, the first software module comprising trusted software code and constituting a root of trust,

[0047] b) Load subsequent software modules by means of the preceding software modules,

[0048] c) Examine the software code of the subsequent software module and identify security features according to an identification scheme,

[0049] d) Evaluate the identified security features according to security criteria,

[0050] e) If a confidence value above a pre-given threshold is evaluated, then execute the subsequent software module, and

[0051] f) For all other subsequent software modules, perform steps b) to e), where the security feature is a function executed by the software code, and the function is not desired within the software module.

[0052] This ensures that the electronic device includes an operating system that is trustworthy and compliant with pre-given security guidelines, and the operating system correctly executes the programs and applications (Anwendungen) of the electronic device. Therefore, the operating system of the electronic device can be examined in view of security weaknesses before or when setting up the operating system of the electronic device, and can be restricted in terms of its functionality according to the confidence value.

[0053] A fourth aspect of the present invention relates to a computer program product that can be directly loaded into the memory of a digital computer, and the computer program product includes a program code portion that is suitable for performing the steps of the described method.

[0054] The expressions "software module inspection, evaluation, etc." should be understood to mean that the software module contains software code, and when the software code is executed on a processor, the software code performs the corresponding actions. The terms "assigned identification scheme" or "assigned security guidelines" denote an identification scheme or security guidelines executed or used by the software module. Such an identification scheme or such security guidelines may exist as an integral part of the software module, or else may be stored in a storage device outside the security module and received in the software module.

[0055] Unless otherwise stated in the following description, the terms "execute", "load", "examine", "evaluate", "implement", etc. preferably relate to actions and / or processes and / or processing steps that change and / or produce data and / or transform data into other data, where the data may in particular be represented and exist as physical parameters, such as electrical pulses. In particular, the expressions "computer" and "electronic device" are interpreted as broadly as possible so as to in particular cover all electronic devices having data processing characteristics. Electronic devices and computers may include, for example, industrial devices, especially industrial devices in the Internet of Things, such as field devices, personal computers, servers, handheld computer systems, mobile radio devices and other communication devices, and processors for processing data.

[0056] In connection with the present invention, a processor may be understood, for example, as an electronic circuit. The processor may in particular be a main processor (CPU), a microprocessor or a microcontroller, such as an application-specific integrated circuit or a digital signal processor, possibly combined with a storage device for storing program instructions, which are also referred to as software code. The processor may also be understood as a virtualized processor or a soft CPU. The processor may also be, for example, a programmable processor, which is equipped with a configuration step for executing the method according to the invention mentioned, or is configured with a configuration step so that the programmable processor implements the features according to the invention of the method according to the invention.

[0057] In the context of the present invention, a storage unit is to be understood as meaning, for example, a working memory or a memory in the form of an erasable and programmable memory unit (EEPROM).

[0058] A computer program product, such as a computer program device, can be provided or delivered, for example, as a storage medium, such as a memory card, a USB stick, a CD-ROM or in the form of programmable firmware or also in the form of a file downloadable from a server in a network. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Exemplary embodiments of the method according to the invention, the starting device according to the invention and the electronic device according to the invention are shown by way of example in the drawings and are explained in more detail in the following description. In particular:

[0060] Figure 1 An exemplary embodiment of the method according to the invention is shown as a flow chart;

[0061] Figure 2 A second embodiment of the method according to the invention is shown based on a schematic diagram of software modules and their functions;

[0062] Figure 3 An embodiment of a protection device according to the present invention is shown in a block diagram; and

[0063] Figure 4 An embodiment of an electronic device according to the present invention is shown in a block diagram.

[0064] In all the Figures, parts which correspond to one another are provided with the same reference symbols. DETAILED DESCRIPTION

[0065] For an electronic device composed of at least one processor and other units for storing and processing data, an operating system is installed when the electronic device is started. Usually, this occurs by executing a plurality of software modules, which are implemented as a chain of successive software modules. Each software module contains software code. This software code includes program instructions, which in turn perform different functions. Such a plurality of successive software modules for starting the operating system is called a boot chain. For example, a software module of such a boot chain is a first software module, which includes trusted software code and constitutes a root of trust (also called Root of Trust). For example, this software module can be provided on a read-only storage unit, such as UEFI firmware. The second software module following it is, for example, a so-called boot loader. The software module following it is, for example, an operating system kernel (also called a kernel). The software module following it includes, for example, programs in a so-called user space. Other software modules are possible.

[0066] Figure 1 As a first method step S1, it is shown to execute the first software module. Since the first software module must be particularly protected to ensure the credibility of the entire method, this is preferably executed in a security device in the device.

[0067] Subsequently, as method step S2, the subsequent software module, i.e., the second software module, is loaded. Subsequently, in method step S3, the software code of the subsequent software module is checked and its security features are identified according to an identification scheme. In method step S4, the identified security features are evaluated according to security criteria. Here, a credibility value is determined and the credibility value is compared with a pre-given threshold to evaluate the credibility. For example, the credibility value and the pre-given threshold can be numerical values, but can also be boolean values, which only take two states "true" or "false" or also "1" or "0".

[0068] If the evaluation yields a credibility value above the pre-given threshold, then in method step S5, the subsequent software module is executed. Subsequently, the next software module is loaded from the chain of software modules, and method steps S2 to S5 are implemented for this software module. In the shown method step S6, for this purpose, it is checked whether the last executed software module is the last software module. If this is the case, steps S2 to S6 are traversed again. If it is determined in step S6 that it is the last software module, see the arrow with the flag y, then the method ends.

[0069] Now according to Figure 2The method will be described in more detail based on a boot chain consisting of five software modules 11, 12, 13, 14, 15. Each software module 11, ..., 15 contains software code which has a check and identification function 16 for checking the software code and identifying security features and an evaluation function 17 for evaluating the security features. Starting from the first software module 11, subsequent software modules 12 are loaded, for example, from a permanent storage medium into the main memory of the electronic device. The first software module 11 is implemented as a boot read-only memory (ROM) of a central processing unit (CPU) and is executed after a "Power-On-Reset". The subsequent software module 12 is now checked by the first software module 11 and in particular by the check and identification function 16 contained in the first software module 11, and the security features are identified according to the identification scheme M1. Subsequently, the identified security features are checked according to the security criterion P1. If, by evaluation, there is a confidence value above a pre-given threshold, the software module 12 is executed.

[0070] When the software module 12 is executed, the subsequent software module 13 is loaded, the security features are identified according to the identification scheme M2 and the security features are evaluated according to the security criterion P2. If this evaluation results in a positive outcome, the software module 13 is trustworthy and is executed. When the software module 13 is executed, the subsequent software module 14 is loaded, evaluated according to the identification scheme M3 and the security criterion P3 and executed in the case of a positive result. Correspondingly, the software module 15 is checked and evaluated in the software module 14 according to the identification scheme M4 and the security criterion P4. If the software module 15 is the last link in the boot chain, no further checking and evaluation takes place here, and the identification scheme M5 and the security criterion P5 only optionally exist.

[0071] The described checking and evaluation of the directly following software module according to the identification scheme and the security criterion of the software module can also take place during the ongoing operation of the electronic device. For example, the kernel can perform a check before each execution of a user space program.

[0072] The identification schemes M1, ..., M5 are preferably configured as machine learning functions, for example as neural networks. For checking, the identification schemes M1, ..., M5 receive the subsequent software modules 12, ..., 15 as input data and output the presence or absence of one or more security features as output. The identification schemes M1, ..., M5 can in particular be pre-trained neural networks. In addition or alternatively, pattern recognition methods or rule-based methods can also be used as the identification schemes M1, ..., M5.

[0073] The software code of the software module preferably exists as object code. The object code is examined by identification schemes M1, ..., M5 and is either checked by machine learning methods or by signature or rule-based methods and a pre-given pattern corresponding to the security feature is recognized. The non-finding of the examined pattern by the identification schemes M1, ..., M5 can also contribute to the evaluation of the credibility of the subsequent software modules 12, ..., 15.

[0074] The evaluation of the identified security feature is performed, for example, by the evaluation function 17 included in the currently existing software module 11. In the case of using security criteria P1, ..., P5, the evaluation function 17 evaluates whether the identified security feature is permitted or not. Here, it is usually also possible to largely examine whether the security feature for the trusted software assumption exists. If the software modules 12, ..., 15 are classified as trusted according to the identified security feature, then the software modules are executed and the boot process continues.

[0075] Here, the credibility is evaluated, for example, by a credibility value assigned to the security feature, and when, for example, a threshold value is exceeded, the software module under consideration is evaluated as trusted.

[0076] If the criteria P1, ..., P5 are not met, then a substitute function (Ersatzfunktion) can be executed accordingly. Such a substitute function can vary according to the identified security feature or also according to the absence of a specific security feature. For example, one implementation of the substitute function can be to end the boot chain. Here, for example, the subsequent software modules 12, ..., 15 are not executed. Alternatively or additionally, the substitute function can be to generate a log entry. From the log entry, the boot behavior can be understood or statistics on the frequency and type of the security features that occur can be determined. For example, an external switching signal (e.g., for an adjacent processor) can be set as another substitute function. Another substitute function can execute the subsequent software modules 12, ..., 15 with only limited functions or permissions. If a specific security feature is recognized or missing, then, for example, the software module can only be run as a so-called "non-root user".

[0077] Here, each software module 11, ..., 15 can use its own software-module-specific identification scheme M1, ..., M5 and its own module-specific security criteria P1, ..., P5. Alternatively or additionally, each software module 11, ..., 15 can use a device-specific identification scheme DM and a device-specific security criterion DP that apply to all software modules. By means of the device-specific model DM and the device-specific security criterion DP, in particular, it is possible to achieve that software modules with generally trusted security features are always executed on the device. Thus, according to the device-specific security criterion DP, each individual software module determines a module-specific device trustworthiness value. The total device trustworthiness value is determined from all the module-specific device trustworthiness values. By using different device-specific security criteria DP1, DP2, devices with the same structure can have different functionality.

[0078] The security criteria P1, ..., P5, DP, DP1, DP2 can in particular be implemented as a positive list or can also be implemented as a negative list. In the case of a positive list, it contains all the security features that can be included in the software module and are thus permitted. In the case of a negative list, it contains the security features that are not permitted and thus may not be included in the software module.

[0079] In order to further increase the trustworthiness of the boot process, the identification schemes M1, ..., M5 and the security criteria P1, ..., P5 are preferably protected cryptographically and are checked by the software module before execution. Here, on the one hand, a security module, such as security module 12, can cryptographically check the identification scheme M2 and the security criterion P2 assigned to this security module. But additionally, security module 12 can also check the identification scheme M3 and the security criterion P3 assigned to the subsequent software module 13 before executing software module 13. This cryptographic check takes place in particular in secure hardware, such as a security element.

[0080] Examples of security features that can be verified are vulnerabilities, Trojans, malware, backdoors, debug interfaces, cryptographic codes, hardening measures such as Stack-Protection, the presence of access control systems such as SELinux, etc. Specific examples of the identified security features of typical software modules that display the boot chain in industrial control devices. In the bootloader, it can be verified via the boot ROM whether the bootloader to be loaded does not contain functionality for, for example, a serial console with a Universal Asynchronous Receiver and Transmitter (UART) circuit, so that the device cannot be attacked via this UART circuit in the early boot phase. Via the bootloader, which is a software module, it can be verified whether the Linux kernel, which is a subsequent software module, does not provide an interface to the entire main memory. Whenever a user space program should be started, the kernel can verify whether the program to be started can execute privileged system calls. This ensures that a program that could damage other programs via such program calls is not started. This ensures that an attacker has fewer possibilities to manipulate the device at runtime.

[0081] Figure 3 There is now shown a boot device for securely starting an operating system of an electronic device, the electronic device having at least one processor configured to execute the different method steps of the described method.

[0082] The boot device 20 includes at least one processor, which is not shown separately for better overview. The boot device includes a security device 21. The processor further includes a loading device 22, an execution device 23, a storage device 25, a verification device 26, and an evaluation device 27.

[0083] The security device 21 is configured to, in particular, protect the first software module from manipulation and execute the functions of the software module. The loading device 22 is configured to load the next software module, respectively. The storage device 25 stores module-specific and device-specific identification schemes or security guidelines. The identification schemes and software guidelines can also be loaded or updated from an external device, for example, via an interface 24.

[0084] The boot device 20 is preferably fixedly installed in the electronic device or at least can be detachably connected to the electronic device.

[0085] Figure 4 There is shown an electronic device 30, the electronic device including at least one processor for securely starting an operating system, the processor being configured to execute the described method.

[0086] Exemplarily, the electronic device 30 includes a security device 31 that stores and executes a first software module. The security device 31 is, for example, configured on a processor 38 on which there are also configured a loading and execution device 32 for loading, verifying, and evaluating subsequent software modules, as well as a verification function 35 and an evaluation function 36. For example, an assigned identification scheme and assigned security criteria can be loaded from a storage device 33. For example, subsequent software modules can be stored on another storage device 34. The device 30 has a second processor 39 that also has a loading and execution device 32, an evaluation function 36, and a verification function 35 for one or more of the subsequent software modules. Different software modules can thus be configured in a manner distributed over different devices or processors 38, 39 in the electronic device 30.

[0087] Compared with traditional methods for starting an operating system, the described method has the advantage that no additional password security precautions are required, such as integrity protection or encryption for verifying security features in software modules. It is possible to verify whether a new, modified kernel version is trustworthy by the same method without having to, for example, re-sign the kernel version. The method can also be used in combination with common secure boot methods. In this case, subsequent software modules are verified both with respect to integrity and with respect to security features in the software code itself. In addition, trustworthy or supported security features on the device or their presence on the device can be ensured in a dedicated manner. Weaknesses or malicious programs can be identified during the startup process and thus before the electronic device is run, and thus before their execution. If, for example, the operating system kernel inadvertently contains a debugging interface that an attacker could exploit, the debugging interface can be identified during the boot process before the operating system actually runs despite a valid signature.

[0088] Within the scope of the present invention, all described and / or depicted features can be advantageously combined with each other. The present invention is not limited to the described embodiments.

Claims

1. A method for securely starting up the device software of an electronic device, wherein a plurality of successive software modules containing software code are executed by the device, the method comprising the steps of: a) Executing a first software module, the first software module including trusted software code and constituting a root of trust; b) Loading subsequent software modules by a previous software module; c) Verifying the software code of the subsequent software module and identifying security features according to an identification scheme; d) Evaluating the identified security features according to security criteria; e) If the evaluation yields a confidence value above a pre-given threshold, executing the subsequent software module, and f) Performing steps b) to e) for all other subsequent software modules, wherein a security feature is a function executed by the software code, the function being undesirable within the software module.

2. The method according to claim 1, wherein the device software is an operating system.

3. The method according to claim 1, wherein the identification scheme is a machine learning function, and the machine learning function receives the subsequent software module as input and provides information about the presence of at least one security feature as output.

4. The method according to claim 3, wherein the identification scheme is a neural network.

5. The method according to claim 1, wherein the identification scheme is a pattern recognition method and / or a rule-based method.

6. The method according to any one of claims 1 to 5, wherein the security criteria is a positive list or a negative list.

7. The method according to any one of claims 1 to 5, wherein each software module uses its own module-specific identification scheme and / or its own module-specific security criteria.

8. The method according to any one of claims 1 to 5, wherein each software module verifies the software code of the subsequent software module according to a device-specific identification scheme and / or each software module evaluates the identified security features according to a device-specific security criteria.

9. The method according to claim 8, wherein a module-specific device confidence value is determined by each individual software module according to the device-specific security criteria, and a total device confidence value is determined from all module-specific device confidence values.

10. The method according to claim 9, wherein different module-specific security criteria and / or different device-specific security criteria are used for different structurally identical electronic devices.

11. The method according to any one of claims 1 to 5, wherein at least one identification scheme and / or at least one security criteria is protected cryptographically and each software module cryptographically verifies its assigned identification scheme and / or its assigned security criteria before execution.

12. The method according to any one of claims 1 to 5, wherein at least one identification scheme and at least one security criteria of the subsequent software module are protected cryptographically and the software module cryptographically verifies the assigned identification scheme and / or the assigned security criteria of the subsequent software module.

13. The method according to any one of claims 1 to 5, wherein the software code exists as object code, and the translated software code is represented by the object code.

14. The method according to claim 9, wherein if the confidence value and / or the module-specific device confidence value and / or the total device confidence value results in a value equal to or lower than a respectively pre-given threshold value, a substitute function is executed.

15. A boot device for securely booting device software of an electronic device, the boot device being connectable to the electronic device, the boot device comprising at least one processor configured to load a plurality of successive software modules containing software code and to perform the following steps: a) Execute a first software module, the first software module comprising trusted software code and constituting a root of trust, b) Load subsequent software modules by means of the preceding software modules, c) Inspect the software code of the subsequent software modules and identify security features according to an identification scheme, d) Evaluate the identified security features according to security criteria, e) If the evaluation results in a confidence value above a pre-given threshold value, execute the subsequent software module, and f) Perform steps b) to e) for all other subsequent software modules, wherein the security feature is a function executed by the software code and the function is not desired within the software module.

16. The boot device according to claim 15, wherein the device software is an operating system.

17. An electronic device comprising at least one processor configured to load device software by means of a plurality of successive software modules containing software code and to perform the following steps: a) Execute a first software module, the first software module comprising trusted software code and constituting a root of trust, b) Load subsequent software modules by means of the preceding software modules, c) Inspect the software code of the subsequent software modules and identify security features according to an identification scheme, d) Evaluate the identified security features according to security criteria, e) If the evaluation results in a confidence value above a pre-given threshold value, execute the subsequent software module, and f) Perform steps b) to e) for all other subsequent software modules, wherein the security feature is a function executed by the software code and the function is not desired within the software module.

18. The electronic device according to claim 17, wherein the device software is an operating system.

19. A computer program product directly loadable into the memory of a digital computer, the computer program product comprising program code portions adapted to carry out the steps of the method according to any one of claims 1 to 14.

Images