METHOD FOR OPERATING A CONTROL DEVICE ON WHICH MULTIPLE APPLICATIONS ARE RUNNED

Description

[0001] The present invention relates to the operation of a control unit under the boundary condition that the proper functioning of this control unit can only be ensured by an orderly interaction of several applications. State of the art

[0002] In vehicle control units, an ever-increasing proportion of the functionality is no longer determined by a static arrangement of fixed integrated circuits, but by software that runs on a control unit designed as a computer.

[0003] Increasingly, the functionality of these control units extends to aspects of vehicle operation that are relevant to the vehicle's type approval. This means that unauthorized modifications to the software by the vehicle's user can lead to the invalidation of the type approval and therefore must be made technically more difficult. One example of such a modification is "chip tuning," which increases the vehicle's engine power but results in deviations in exhaust emissions or noise levels from the approved values.

[0004] Manipulations of this kind can, for example, lead to increased wear and tear on the vehicle. If the user restores the original software state after a vehicle malfunction before having the vehicle repaired, the manipulation may go unnoticed.

[0005] The user could then receive a repair under warranty or goodwill, even though he has actually forfeited the warranty through the manipulation.

[0006] DE 10 2012 110 559 A1, DE 10 2012 109 619 A1, DE 10 2014 208 385 A1 and DE 10 2012 109 617 A1 disclose general state of the art for the protection of control units against software manipulation.

[0007] US Patent 6,802,006 B1 discloses the linking of two programs loaded into a computer. This also includes authentication of the two programs. Furthermore, a validator is disclosed that is capable of determining whether a pointer in a second program points to a location in a first program. Disclosure of the invention

[0008] Within the scope of the invention, a method for operating a control unit on which several applications are executed was developed.

[0009] This control unit can be, in particular, a control unit for a vehicle and / or for a vehicle's drive unit. Examples of such control units include engine control units, control units for vehicle dynamics systems (such as the vehicle dynamics control system known as Electronic Stability Program, ESP), and control units for the at least partially automated control of vehicles in traffic.

[0010] An application is understood to be, in particular, a program that, when executed on the hardware of the control unit, implements at least part of the control unit's nominal functionality. An application comprises at least one code block containing executable program code.

[0011] In addition, the application can also include at least one data block that the program code needs to perform its function. This data block can, for example, contain characteristic curves or other parameters for controllers.

[0012] For example, a controller can be implemented generically in program code and adapted to a specific vehicle using the aforementioned characteristic maps or other parameters. The program code can also implement a trained machine learning module, such as a neural network. The data block can then contain parameters that characterize the behavior of the trainable module. In a neural network, these parameters might include weights used to calculate the activation of inputs fed to a neuron or other processing unit.

[0013] As part of the process, a first code block of a first application, containing the executable program code of that application, is obtained using a reference permanently stored in the control unit. Verification information, also permanently stored in the control unit, is then used to check whether this first code block is in a state corresponding to this verification information. If the result of this check is positive, the program code contained in the first code block is released for execution.

[0014] A fixed setting in the control unit refers specifically to a form of data storage that cannot be freely modified by the end user of the control unit, or at least not without the knowledge and consent of the control unit manufacturer or another entity authorized to make changes to the control unit. This can be achieved, for example, using memory modules or storage media in which individual bits, bytes, or blocks of bytes can be set to new values ​​from their initial state through an irreversible physical writing process. An example of this is memory modules in which individual bits are switched by burning out or otherwise destroying electrically conductive structures.

[0015] However, a fixed storage location in the control unit also includes, for example, storage in a Trusted Platform Module (TPM) or a Hardware Security Module (HSM). Such storage can be physically modified subsequently, but is tied to possession of a specific cryptographic key or other authorization feature.

[0016] Obtaining a code block, or more generally any block of information, using a reference, refers in particular to retrieving this block from a programmable memory of the control unit using a memory address specified by the reference. However, this is not the only possibility. The reference can also be used, for example, to download the block from the internet.

[0017] If a sufficiently fast internet connection is available (e.g. via 5G mobile network), then, analogous to the PXE network booting previously practiced in local networks, only minimal functionality needs to be maintained on the control unit itself, and the applications can then always be reloaded in their latest version.

[0018] At least one reference contained in the first code block is used to retrieve a transfer block, which contains a reference to another code block of a different application. This further code block contains executable program code of the other application. Verification information stored in the first code block is used to check whether the transfer block is in a state corresponding to this verification information. If the result of this check is positive, the further code block of the other application is retrieved using the reference contained in the transfer block.

[0019] In the same way, the code block of the next application can also contain a reference that can be used to obtain the next transfer block and finally the next code block of a next application.

[0020] This method allows the boot process of an electronic control unit (ECU) to be secured beyond the mere requirement that only authorized code is executed, by predefining a mandatory sequence for the applications that are executed. This prevents the end user of the ECU from unilaterally changing this sequence or suppressing the execution of specific applications.

[0021] Conversely, this means that breaking down the functionality of the control unit into individual applications that must be executed sequentially no longer poses a particular security risk. While a monolithic application covering the entire functionality of the control unit can be particularly well secured against manipulation (e.g., cryptographically), it is comparatively cumbersome to update or expand. Especially with vehicle control units that cover a wide range of tasks, multiple manufacturers often collaborate on the development and application of these applications. If a monolithic application ultimately has to be created, one manufacturer must merge the contributions from all other manufacturers and repeat this process with every update of an individual component.However, if functionalities implemented by multiple manufacturers are housed in several applications, the applications can be updated independently. Without the additional safeguard described here, this creates opportunities to interfere with the control unit's boot process.

[0022] One motivation for such interventions by the end user might be that some vehicles, such as electric micro-vehicles (also known as "e-scooters") or electrically assisted bicycles ("pedelecs" or "e-bikes"), are produced for use in many countries, but are subject to different regulatory requirements in each country. From a purely technical standpoint, these vehicles are equipped with all the functions required in any of the intended countries and designed for the maximum power and speed required in each of those countries. It is only the software on the control unit that determines, for example, that the pedal assistance of an e-bike in Germany is only active up to a speed of 25 km / h and that the motor can only be activated by pedaling, not by operating a throttle or other hand-held control.Compliance with these regulations is a mandatory prerequisite for the e-bike to be legally classified as a bicycle and used on public roads without a driver's license or insurance. Somewhere in the e-bike's boot process, an application will be present that determines the permissible parameters based on the country of use, before, for example, an application for the drive system actually allows the e-bike to operate according to these defined parameters. If the end user manages to reverse this boot sequence, they can also use the prohibited functions and ride at the maximum technically possible speed.If such an intervention is possible with just a few simple steps and without special knowledge or tools, even this abstract possibility can have significant consequences for the user, even if he does not intend the intervention: He will first be confronted with an investigation for driving an unregistered, untaxed and uninsured vehicle (and possibly also without a driver's license) and must defend himself against this charge.

[0023] Advantageously, the verification information contained in the transfer block is used to check whether the subsequent code block is at a state corresponding to this verification information. If the result of this check is positive, the program code contained in the subsequent code block is released for execution. In this way, starting from a single reference permanently stored in the control unit and a single data record with verification information (the "root of trust"), a chain of trust can be established that extends across any number of sequentially executed applications.

[0024] In a particularly advantageous embodiment, the transfer block is not directly retrieved based on the reference contained in the first code block, but rather a reference block is retrieved first. Using the verification information stored in the first code block, it is then checked whether the reference block is in a state corresponding to this verification information. If the result of this check is positive, the transfer block is retrieved using a reference contained in the reference block. The reference block can then optionally contain its own verification information, which can be used in place of the verification information in the first code block to verify the transfer block.Since there is a chain of trust from the verification information in the first code block to the verification information in the reference block, the specific verification information used to confirm the transfer block is irrelevant to the security level. If the reference block contains its own verification information, this allows for even greater granularity regarding which entities can modify the ECU's boot process and in what way.

[0025] Inserting a reference block facilitates separation of tasks, particularly in the scenario described earlier, where applications from different vendors interact. For example, the reference block allows you to select which application is executed next, while the maintenance and updates of that application can be left to the respective third-party vendor.

[0026] In the aforementioned example of the e-bike, a localization team could be responsible for each country of use, translating the legal requirements regarding the use of the e-bike in road traffic into corresponding operating parameters for the e-bike (e.g., regarding speed or the availability of functions). The e-bike manufacturer, on the other hand, is responsible for ensuring that the e-bike's behavior is adapted to the respective country of use.

[0027] This scenario can be implemented, for example, by creating a handover block for each intended country of use. This block contains a reference (such as a URL) to a localization application for that country, as well as a public cryptographic key of the corresponding localization team. The e-bike manufacturer can then specify which of these handover blocks is selected for a particular unit, depending on the intended country of use. Each e-bike can therefore be equipped with the same set of handover blocks; only the reference block needs to be changed for each unit. Updates or other changes to the localization applications do not require any changes to either the handover block or the reference block.It is sufficient to upload a new version with a digital signature to the URL stored in the transfer block, which can be verified with the public key stored in the transfer block.

[0028] The verification information can, for example, include a hash value. If this hash value matches a hash value generated from a code block, transfer block, or reference block, it can then be determined that this code block, transfer block, or reference block is in a state corresponding to the verification information.

[0029] In a particularly advantageous embodiment, the verification information includes at least one public key of an asymmetric cryptosystem. Based on the fact that a code block, transfer block, or reference block is validly signed with a secret key belonging to this public key, it can then be determined that this code block, transfer block, or reference block is in a state corresponding to the verification information. Using a public key as verification information has the particular advantage that this key can remain the same even if the code block, transfer block, or reference block being verified is modified. If the signature can be confirmed, it is established that it was made with the correct secret key. This then establishes that the code block, transfer block, or reference block was modified by an authorized entity.

[0030] Using public keys as verification information makes it particularly easy to manage, in a tiered manner, who is authorized to change certain processes and settings. For example, certain changes can be reserved exclusively for a vehicle manufacturer, while other changes, such as the additional initialization of an electronic trailer hitch, can also be delegated to the road traffic office or the vehicle inspection agency (TÜV), who then approve the retrofit of this trailer hitch and register it in the vehicle documents.

[0031] In a further, particularly advantageous embodiment, the first code block, the transfer block, and / or the reference block additionally includes a specification of permissions for accessing the control unit's system resources and / or for executing actions in or with the control unit. The subsequent application's access to system resources and / or execution of actions is limited according to these permissions. In this way, the aforementioned division of tasks between manufacturers of different applications can be improved by reducing mutual interference and incompatibilities between applications. At the same time, especially when a control unit is used in a vehicle, safety is always generally enhanced if an application can and may only perform actions that correspond to its intended purpose.

[0032] For example, since the widespread introduction of the CAN bus, vehicles have been internally networked in such a way that, in principle, all sensors, actuators, and control units could communicate with each other. Before this networking was implemented, large wiring harnesses were used to create dedicated point-to-point connections for precisely those communication relationships that were desired and intended for the vehicle. This networking allows for much greater flexibility, which, among other things, significantly simplifies the retrofitting of functionality. However, it is not without its drawbacks if, for example, the entertainment system is also capable of communicating with vehicle dynamics systems. The entertainment system may not do so during normal operation, but it could very well do so after being compromised by an attacker.For example, if the implementation of the codec for decoding DAB digital radio is not sufficiently secure, an attacker could use a specially crafted, non-conforming data stream to force the codec into a situation never intended during its development. If, for instance, the specification requires a data field to announce the size of a subsequent block of audio data, the attacker could send 5000 bytes instead of the announced 1000 bytes. If the codec has only reserved memory for 1000 bytes in response to the 1000-byte announcement, the excess 4000 bytes could potentially overwrite information in memory that is relevant to the codec's control flow. The codec would then no longer perform its intended task, but rather execute whatever the attacker has packed into the extra 4000 bytes.The attack could be carried out on many vehicles simultaneously using a sufficiently powerful FM transmitter at an exposed location.

[0033] However, if the application responsible for the entertainment system only has access to the interior speakers and the instrument cluster in the cockpit, but not to driving dynamics systems, then the potential damage in the attack scenario described as an example can be significantly reduced.

[0034] Specifying permissions in the context of a predecessor application is particularly advantageous because it grants a successor application permissions only to the same extent as those granted to the predecessor application. This makes it more difficult to circumvent permission restrictions by executing another existing application, which may even be validly signed.

[0035] The subsequent application or successor application is advantageously excluded from accessing or executing specific system resources or actions that could affect driving safety and / or a vehicle's operating permit by specifying permissions. This prevents, for example, the vehicle owner from exploiting the previously described vulnerability in the vehicle's entertainment system or any other security flaw to "liberate" their vehicle from technical and legal restrictions, similar to the popular smartphone "jailbreaking" or "rooting" techniques. This would allow them to, for instance, achieve increased engine power at the expense of the general public, who would suffer from the deteriorated emissions and noise levels.

[0036] In a further particularly advantageous embodiment, at least one application causes the control unit to provide one or more services that remain active even after switching to the execution of the other application. The method can then be used to forcefully define a sequence for starting these services, so that, for example, a vehicle with the control unit is always in a defined state after the services have started up.

[0037] In the aforementioned e-bike example, such a service could monitor the current speed and pedal pressure. The relationship between speed and pedal pressure could then determine whether motor assistance should be activated, provided the maximum permissible speed is not exceeded. The mandatory boot sequence ensures that the aforementioned country-specific restrictions are met before motor assistance is activated.

[0038] In a further, particularly advantageous embodiment, in addition to checking whether a code block is in a state corresponding to verification information, it is also checked whether a data block required during the execution of this code block is in a state corresponding to verification information. The program code contained in the code block is only released for execution if the result of this check is also positive. As mentioned at the outset, the specific behavior of the application is often characterized by a data block, which can, for example, include characteristic maps of controllers or weights of neural networks. Accordingly, manipulating the data block can interfere with the functionality of the control unit just as severely as manipulating the executable program code.Targeted manipulation of the data block, for example by a vehicle user, is sometimes significantly easier than manipulating the program code, which the user cannot understand without specialized knowledge. Reverse engineering an application that exists only as binary object code to determine the effect of different program code changes is a very demanding task. In contrast, it is obvious that in a data block containing an engine map, for example, increasing values ​​that are already high can lead to an increase in engine performance.

[0039] The functionality of the described method can be implemented wholly or partially in software. Therefore, the invention also relates to a computer program with machine-readable instructions which, when executed on one or more computers, cause the computer(s) to execute one of the described methods. In this sense, control units for vehicles and embedded systems for technical devices, which are also capable of executing machine-readable instructions, are also to be considered computers.

[0040] The invention also relates to a machine-readable data carrier and / or a downloadable product containing the computer program. A downloadable product is a digital product that can be transmitted over a data network, i.e., downloaded by a user of the data network, and which can, for example, be offered for immediate download in an online shop.

[0041] Furthermore, a computer can be equipped with the computer program, the machine-readable data carrier, or the download product. This computer can, in particular, be a control unit for a vehicle and / or for a vehicle's drive unit.

[0042] In a particularly advantageous embodiment, this control unit includes a hardware security module (HSM) and / or a trusted platform module (TPM). This HSM or TPM contains the reference to the first code block of the first application, which is permanently stored within the control unit, as well as the verification information for this first code block. These modules are particularly secure repositories for the trust anchors used to verify all subsequent code blocks, transfer blocks, and reference blocks.

[0043] Further measures improving the invention are described in more detail below, together with a description of preferred embodiments of the invention, with reference to figures. Examples of implementation

[0044] It shows: Figure 1 Exemplary embodiment of method 100 for operating a control unit 1; Figure 2 Exemplary embodiment of a control unit 1 on which three applications 2, 3, 4 are installed.

[0045] Figure 1 is a schematic flowchart of an embodiment of method 100 for operating a control unit 1, the contents of which are in Figure 2 is described in more detail.

[0046] In step 110, a first code block 21 of a first application 2, containing the executable program code of this application 2, is obtained based on a reference 1a permanently stored in control unit 1. In step 120, verification information 1b, also permanently stored in control unit 1, is used to check whether this first code block 21 is in a state corresponding to this verification information 1b. Optionally, according to block 121, it can also be checked whether a data block required during the execution of the first code block 21 is in a state corresponding to the verification information 1b. If the check for code block 21, and optionally also for the data block, yields a positive result (truth value 1), the program code contained in the first code block 21 is released for execution in step 130.

[0047] A reference 21a contained in code block 21 can now point directly to a transfer block 23, which can then be obtained in step 140. Alternatively, reference 21a can also point to a reference block 22. This reference block is then obtained in step 132, and in step 134 it is checked whether reference block 22 is in a state corresponding to the verification information 21b from the first code block 21. If this is the case, transfer block 23 can be obtained according to block 141 using a reference 22a contained in reference block 22.

[0048] In step 150, at least the verification information 21b stored in the first code block 21 is used to check whether the transfer block 23 is in a state corresponding to this verification information 21b. Instead of using the verification information 21b directly, verification information 22b from a reference block 22 can also be used, which in turn has been confirmed with the verification information 21b of the first code block 21. If the result of this check is positive (truth value 1), in step 160 the further code block 31, 41 of the further application 3, 4 is obtained using the reference 23a contained in the transfer block 23.

[0049] In step 170, verification information 23b contained in transfer block 23 is used to check whether the subsequent code block 31, 41 is in a state corresponding to this verification information 23b. Analogous to step 120, block 171 can also be used to check whether this verification information 23b can confirm a data block required during the execution of code block 31, 41. If the result of the check for code block 31, 41, and possibly also for the required data block, is positive (truth value 1), the program code contained in the subsequent code block 31, 41 is released for execution in step 180.

[0050] The execution of this program code can be subject to constraints in step 190 regarding permissions for accessing system resources of control unit 1 and / or for executing actions in or with control unit 1. These constraints can be set by corresponding specifications in the first code block 21, in the transfer block 23, and / or in the reference block 2. In particular, for example, according to block 191, a specification of permissions in the context of a predecessor application 21 can grant a successor application 31, 41 to be executed only to the extent that the predecessor application 21 also possesses these permissions.

[0051] According to Block 192, the further application or successor application 31, 41 can be excluded by specifying permissions, in particular, for example, from accessing such system resources or from executing such actions that may affect driving safety and / or a granted operating permit of a vehicle.

[0052] Figure 2 Figure 1 shows an example of the contents of a control unit 1, which can be operated according to the previously described procedure 100. The control unit 11 has a hardware security module, HSM 11, and / or a Trusted Platform Module, TPM 12, in which the reference 1a and the verification information 1b are permanently stored.

[0053] Using reference 1a, the first code block 21 of the first application 2 can be obtained. It can then be verified using the verification information 1b. In the Figure 2In the example shown, a reference 21a in the first code block 21 can optionally point to a first reference block 22 or to a second reference block 22'. If the reference 21a points to the first reference block 22, this first reference block 22 can be obtained and verified with the verification information 21b in the first code block 21. If, on the other hand, the reference 21a points to the second reference block 22', this second reference block 22' can be obtained and verified with the verification information 21b.

[0054] The first reference block 22, with its reference 22a, points to the first transfer block 23, which can be confirmed with verification information 22b from the first reference block 22 (or with verification information 21b from the first code block 21). The first transfer block 23, with its reference 23a, in turn points to the code block 31 of the second application 3 and also contains verification information 23b, with which this code block 31 can be confirmed. Code block 31 contains, analogously to code block 21, a reference 31a and verification information 31b.

[0055] The second reference block 22' points, via its reference 22a', to the second transfer block 23, which can be confirmed with verification information 22b' of the second reference block 22' (or also with verification information 21b of the first code block 21). The second transfer block 23', via its reference 23a', in turn points to code block 41 of the third application 4 and also contains verification information 23b', with which this code block 41 can be confirmed. Code block 41 contains, analogously to code block 21, a reference 41a and verification information 41b.

[0056] In this way, by simply replacing the first reference block 22 with the second reference block 22', which requires only a very small amount of data, it can be determined that after the first application 2 the third application 4 is executed instead of the second application 3.

[0057] The switch from the second application 3 to the third application 4 as the next application to be executed can alternatively also be effected by directly replacing the first transfer block 23 with the second transfer block 23'.

[0058] The third application 4 does not necessarily have to be completely different from the second application 3, but could, for example, also be an update of the second application 3.

[0059] Optionally, reference blocks 22, 22' can also reference data blocks required by application 2. Reference blocks 22, 22' can also reference key blocks, which, analogous to transfer blocks 23, contain a reference to the data block and verification information for its confirmation. This allows each data block to have its own signature source, which can be used to freely define who is authorized to update that data block.

Claims

1. Method (100) for operating a control unit (1) on which multiple applications (2, 3, 4) are executed, comprising the steps of: • taking a reference (1a) permanently stored in the control unit (1) as a basis for obtaining (110) a first code block (21) of a first application (2), which code block contains executable program code of this application (2); • taking verification information (1b) permanently stored in the control unit (1) as a basis for checking (120) whether this first code block (21) is at a level that corresponds to this verification information (1b); • responding to the result of this check being positive by approving (130) the program code contained in the first code block (21) for execution; • taking at least a reference (21a) contained in the first code block (21) as a basis for obtaining (140) a transfer block (23) that contains a reference (23a) to another code block (31, 41) of another application (3, 4), this other code block (31, 41) containing executable program code of the other application (3, 4); • taking at least verification information (21b) stored in the first code block (21) as a basis for checking (150) whether the transfer block (23) is at a level that corresponds to this verification information (21b); • responding to the result of this check being positive by taking the reference (23a) contained in the transfer block (23) as a basis for obtaining (160) the other code block (31, 41) of the other application (3, 4).

2. Method (100) according to Claim 1, wherein • verification information (23b) contained in the transfer block (23) is taken as a basis for checking (170) whether the other code block (31, 41) is at a level that corresponds to this verification information (23b), and • in response to the result of this check being positive, the program code contained in the other code block (31, 41) is approved (180) for execution.

3. Method (100) according to either of Claims 1 to 2, wherein • the reference (21a) contained in the first code block (21) is taken as a basis for obtaining (132) a reference block (22); • the verification information (21b) stored in the first code block (21) is taken as a basis for checking (134) whether the reference block (22) is at a level that corresponds to this verification information (21b); and • in response to the result of this check being positive, a reference (22a) contained in the reference block (22) is taken as a basis for obtaining (141) the transfer block (23).

4. Method (100) according to one of Claims 1 to 3, wherein the verification information (1b, 21b, 22b, 23b) comprises at least one hash value and wherein, in response to this hash value matching a hash value formed for a code block (21, 31, 41), transfer block (23) or reference block (22), this code block (21), transfer block (23) or reference block (22) is determined (120, 134, 150, 170) as being at a level that corresponds to the verification information (1b, 21b, 22b, 23b).

5. Method (100) according to one of Claims 1 to 4, wherein the verification information (1b, 21b, 22b, 23b) comprises at least one public key of an asymmetric cryptosystem and wherein, in response to a code block (21, 31, 41), transfer block (23) or reference block (22) being validly signed with a secret key belonging to this public key, this code block (21, 31, 41), transfer block (23) or reference block (22) is determined (120, 134, 150, 170) as being at a level that corresponds to the verification information (1b, 21b, 22b, 23b).

6. Method (100) according to one of Claims 1 to 5, wherein the first code block (21), the transfer block (23) and / or the reference block (22) additionally comprises an indication of permissions for accessing system resources of the control unit (1), and / or for performing actions in or with the control unit (1), and wherein the other application's access to system resources, and / or the performance of actions by the other application (31, 41), is limited (190) according to these permissions.

7. Method (100) according to Claim 6, wherein an indication of permissions in the context of a predecessor application (21) grants (191) permissions to a successor application (31, 41) that is to be executed only to the particular maximum extent to which the predecessor application (21) also has these permissions.

8. Method (100) according to either of Claims 6 to 7, wherein the indication of permissions excludes (192) the other application (31, 41), or successor application (31, 41), from accessing specifically such system resources, or from performing specifically such actions, as can affect the driving safety of and / or an issued operating licence for a vehicle.

9. Method (100) according to one of Claims 1 to 8, wherein at least one application (2) causes the control unit (1) to provide one or more services that remain active even after execution has switched to the other application (3, 4).

10. Method (100) according to one of Claims 1 to 9, wherein, in addition to the check (120, 170) to ascertain whether a code block (21, 31, 41) is at a level that corresponds to verification information, a check (121, 171) is also carried out to ascertain whether a data block required during the execution of this code block (21, 31, 41) is at a level that corresponds to verification information (1b, 23b), and wherein the program code contained in the code block (21, 31, 41) is released for execution only if the result of this check is also positive.

11. Computer program, containing machine-readable instructions that, when executed on one or more computers, cause the computer(s) to carry out the method (100) according to one of Claims 1 to 10.

12. Machine-readable data carrier and / or download product comprising the computer program according to Claim 11.

13. Computer comprising the computer program according to Claim 11 and / or comprising the machine-readable data carrier and / or download product according to Claim 12.

14. Control unit (1) for a vehicle and / or for a drive unit of a vehicle as a computer according to Claim 13.

15. Control unit (1) according to Claim 14, comprising a hardware safety module, HSM (11), and / or a trusted platform module, TPM (12), which contains the reference (1a) permanently stored in the control unit to the first code block (21) of the first application (2) and also the permanently stored verification information (1b) for this first code block (21).