DE102021125750A1 - Computing unit for a vehicle and method and computer program for a computing unit for a vehicle - Google Patents

Abstract

The present invention relates to a computing unit for a vehicle, to a method and a computer program for a computing unit for a vehicle, and to a vehicle with such a computing unit. The computing unit includes one or more storage devices configured to store a cryptographically secured starting base system of the computing unit, an operating system of the computing unit, and one or more computing function blocks of the vehicle. The arithmetic unit also includes one or more processors, designed to start the cryptographically secured starting base system of the arithmetic unit. The one or more processors are designed to check, using the cryptographically secured start base system, an integrity of the operating system of the processing unit based on a cryptographically generated signature of the operating system. The one or more processors are designed to start the operating system of the computing unit if the integrity of the operating system has been determined. The one or more processors are configured to check, by the cryptographically secured boot base system or by the operating system, an integrity of the one or more computing function blocks of the vehicle based on one or more cryptographically generated signatures of the one or more computing function blocks. The one or more processors are configured to start the one or more computational function blocks if the integrity of the one or more computational function blocks has been determined.

Description

The present invention relates to a computing unit for a vehicle, to a method and a computer program for a computing unit for a vehicle, and to a vehicle with such a computing unit.

In modern vehicles, an ever-increasing number of functions are provided by software. These functions are usually implemented by services that are executed on the vehicle's computing units. These functions can be implemented, for example, as arithmetic function blocks (also known as “containers”) that are executed in the vehicle's runtime environment.

For this reason, a distinction is often made in vehicles between two software components - the system software and the calculation function blocks. The system software usually provides the runtime environment for the arithmetic function blocks.

This concept is also used in the so-called "automotive edge" (literally "automotive edge"), which can include the computational function blocks and the system software. A goal of the automotive edge can be to have the possibility to update or install new function containers at any time. For example, it may be desirable that the software elements of the automotive edge can be updated at any time (e.g. with an update cycle of at least one week) without affecting the rest of the system, with only the respective applications (computational function blocks) within the edge updated to install new features. The Automotive Edge can be used as a basic platform for all online services in the vehicle.

The actual system software is upgraded by upgrading large areas of hardware using complex release processes. The system software update cycle is often around six months.

In many automotive edge systems, a secure boot process (start-up process) checks the integrity of the installed software. If the installed software is unchanged, the boot process starts the software. Such a "secure boot" can generally only be used there for static calculation function blocks that are integrated into the statically safe boot process - dynamic software updates may not be possible. Alternatively, for dynamic arithmetic function blocks, there is no need to protect the start. In other systems, the mostly static secure boot process is therefore used for static software (as described above). Also, the data areas (which do not contain executable software) may remain unsecured.

Out of U.S. 2020/0320201 A1 a concept for safe booting of vehicle processors is known. However, this concept does not differentiate between system software that is subject to long release cycles and computing function blocks that are to be updated frequently.

Out of WO 2020/070061 A1 and U.S. 2019/0391802 A1 other concepts for increasing the security of software in vehicles are known. However, both concepts do not use a secure boot process.

There is a need to provide an improved concept for securely booting software-based vehicle functionality.

This need is met by the subject matter of the independent claims.

The present invention is based on the recognition that a secure software boot process of a vehicle can be divided into three components. A start-up base system can be started using the Secure Boot concept. Functionality and cryptographic information that can be used to check the integrity of an operating system (i.e. the system software) using a cryptographically generated signature of the operating system and, if the operating system has integrity, the operating system can now be included within the starting base system secured in this way to start. Now in turn the operating system, or alternatively the start base system, can be used to check the integrity of the arithmetic function blocks by means of corresponding cryptographically generated signatures of the arithmetic function blocks and to start them if they are integer. In this way, a chain of trust is formed from the base system secured via Secure Boot to the operating system and the arithmetic function blocks, so that these can also be started securely. The computing function blocks, together with the associated cryptographically generated signatures, can be updated in a shorter cycle than the operating system, for example, and in particular than the starting base system, with the chain of trust remaining intact. The concept presented thus relates to safe starting for dynamic calculation function blocks (containers).

One aspect of the present disclosure relates to a computing unit for a vehicle. The computing unit includes one or more storage devices configured to store a cryptographically secured starting base system of the computing unit, an operating system of the computing unit, and one or more computing function blocks of the vehicle. The arithmetic unit also includes one or more processors, designed to start the cryptographically secured starting base system of the arithmetic unit. The one or more processors are designed to check, using the cryptographically secured start base system, an integrity of the operating system of the processing unit based on a cryptographically generated signature of the operating system. The one or more processors are designed to start the operating system of the computing unit if the integrity of the operating system has been determined. The one or more processors are configured to check, by the cryptographically secured boot base system or by the operating system, an integrity of the one or more computing function blocks of the vehicle based on one or more cryptographically generated signatures of the one or more computing function blocks. The one or more processors are configured to start the one or more computational function blocks if the integrity of the one or more computational function blocks has been determined. The computing function blocks, together with the associated cryptographically generated signatures, can be updated in a shorter cycle than the operating system, for example, and in particular than the starting base system, with the chain of trust remaining intact.

The proposed arithmetic unit forms a chain of trust from the cryptographically secured start-up base system to the operating system and the one or more arithmetic function blocks, so that these can also be started securely. Consequently, the verification of the one or more computing function blocks can be based on a chain of trust that leads back to the cryptographically secured starting base system.

In some examples, the integrity of the one or more computing functional blocks is checked by the cryptographically secured starting base system of the computing unit. For example, the functionality that was used to check the operating system can be reused. However, this may need to be done outside of the operating system.

Alternatively, the integrity of the one or more computing function blocks can be checked by the operating system of the computing unit. Here the check can be carried out within the operating system, so that it is not necessary to switch to the start base system.

The cryptographically secured basic boot system and/or the operating system can be stored, for example, in a cryptographically secured memory area or in a read-only memory area of the one or more storage devices. This can make it difficult or impossible to change the boot base system or the operating system. However, an effort for the update is increased since the memory area has to be replaced or a cryptographic protection has to be implemented.

In contrast, the one or more arithmetic function blocks can be stored in a writable memory area of the one or more memory devices. This simplifies updating of the one or more arithmetic function blocks. Security can be maintained by checking the cryptographically generated signature of the one or more computing function blocks.

For example, the one or more processors can be designed to update an arithmetic function unit by the operating system in that the updated arithmetic function unit is received together with a corresponding cryptographically generated signature and stored in the writable memory area. The integrity of the updated arithmetic function unit can be checked based on the corresponding cryptographically generated signature.

The one or more cryptographically generated signatures of the one or more arithmetic function blocks can be vehicle-specific, for example. This can avoid scenarios where security is compromised by running a computational function block of another vehicle or vehicle type, secured based on the same type of cryptographically generated signatures, on an unsupported vehicle.

The verification of the vehicle-specific cryptographically generated signatures can be linked to vehicle-specific objects. The one or more processors can thus be designed to retrieve a cryptographic key for checking the one or more computing function blocks from a vehicle key of the vehicle. In other words, the vehicle key of the vehicle can include a memory that has a vehicle-specific schen cryptographic key to check the one or more computing function blocks includes, such as a vehicle-specific public key of a public key infrastructure (PKI, public key infrastructure).

As previously mentioned, one or more computational function blocks may be updateable independently of the operating system. As a result, a significantly shorter update cycle can be achieved for the one or more arithmetic function blocks than for the operating system.

The starting of the one or more computing function blocks can be denied if the verification of the one or more cryptographically generated signatures fails. Execution of potentially unsafe arithmetic function blocks can thus be prevented.

For example, the one or more processors can be designed to report a failure of the check of the one or more cryptographically generated signatures to a remote partner. As a result, errors in the signing process can be traced and failed attacks on the security of the processing unit can be logged.

One aspect of the present disclosure relates to a vehicle comprising the computing unit presented above.

One aspect of the present disclosure relates to a corresponding method for a computing unit for a vehicle. The method includes storing a cryptographically secured starting base system of the computing unit, an operating system of the computing unit and one or more computing function blocks of the vehicle. The method also includes starting the cryptographically secured starting base system of the processing unit. The method also includes checking, by the cryptographically secured start base system, an integrity of the operating system of the computing unit based on a cryptographically generated signature of the operating system. The method also includes starting the operating system of the processing unit if the integrity of the operating system has been determined. The method further includes checking, by the cryptographically secured start-up base system or by the operating system, an integrity of the one or more computing function blocks of the vehicle based on one or more cryptographically generated signatures of the one or more computing function blocks. The method further includes starting the one or more computational function blocks if the integrity of the one or more computational function blocks has been determined.

One aspect of the present disclosure relates to a corresponding program with a program code for performing the method presented above when the program code is executed on a computer, a processor, a control module or a programmable hardware component.

• 1a zeigt ein Blockdiagramm eines Beispiels einer Recheneinheit für ein Fahrzeug;
• 1b zeigt ein schematisches Diagramm eines Beispiels eines Fahrzeugs mit einer Recheneinheit für ein Fahrzeug;
• 1c zeigt ein Flussdiagramm eines Beispiels eines Verfahrens für eine Recheneinheit für ein Fahrzeug; und
• 2 zeigt ein schematisches Diagramm eines Beispiels eines Zusammenspiels verschiedener Komponenten in einer Recheneinheit für ein Fahrzeug.

Some examples of devices and/or methods are explained in more detail below with reference to the accompanying figures, merely by way of example. Show it:

• 1a Fig. 12 shows a block diagram of an example of an arithmetic unit for a vehicle;
• 1b Fig. 12 shows a schematic diagram of an example of a vehicle with a computing unit for a vehicle;
• 1c shows a flow chart of an example of a method for a computing unit for a vehicle; and
• 2 shows a schematic diagram of an example of an interaction of different components in a computing unit for a vehicle.

Some examples will now be described in more detail with reference to the accompanying figures. However, other possible examples are not limited to the features of these detailed described embodiments. These may include modifications of the features, as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe particular examples is not intended to be limiting of other possible examples.

Throughout the description of the figures, the same or similar reference symbols refer to the same or similar elements or features, which can each be implemented identically or in a modified form, while providing the same or a similar function. Also, in the figures, the thicknesses of lines, layers, and/or areas may be exaggerated for clarity.

When two elements A and B are combined using an "or", it is to be understood that all possible combinations are disclosed, i. H. only A, only B and A and B, unless expressly defined otherwise in individual cases. "At least one of A and B" or "A and/or B" can be used as alternative wording for the same combinations. The equivalent applies to combinations of more than two elements.

Where a singular form, such as "a, an" and "the," is used and use of a single element is not explicitly or implicitly required, other examples may use multiple elements to implement the same function . Where a function is described below as being implemented using multiple elements, other examples may implement the same function using a single element or processing entity. It is further understood that the terms "comprises,""comprising,""comprises," and/or "having," when used, imply the presence of the specified feature, integer, step, operation, process, element, component, and/or group describe the same, but does not exclude the presence or addition of any other feature, integer, step, operation, process, element, component and/or group thereof.

1a 12 shows a block diagram of an example of a computing unit 10 for a vehicle 100. The computing unit 10 includes one or more storage devices 16 configured to store a cryptographically secured starting base system 18a of the computing unit, an operating system 18b of the computing unit, and one or more computing function blocks 18d of the vehicle. The computing unit 10 further includes one or more processors 14 and optionally one or more interfaces 12 . The one or more processors 14 are coupled to the one or more memory devices 16 and the one or more optional interfaces 12 . In general, the functionality of the processing unit 10 is provided by the one or more processors 14 using the one or more interfaces 12 (for exchanging information, for example for communicating with a backend server, a remote server) and/or using the one or more storage devices 16 (for storing and retrieving information).

The one or more processors are designed to start the cryptographically secured starting base system of the processing unit. The one or more processors are designed to check, using the cryptographically secured start base system, an integrity of the operating system of the processing unit based on a cryptographically generated signature of the operating system. The one or more processors are designed to start the operating system of the computing unit if the integrity of the operating system has been determined. The one or more processors are configured to check, by the cryptographically secured boot base system or by the operating system, an integrity of the one or more computing function blocks of the vehicle based on one or more cryptographically generated signatures of the one or more computing function blocks. The one or more processors are configured to start the one or more computational function blocks if the integrity of the one or more computational function blocks has been determined.

1b 12 shows a schematic diagram of an example of a vehicle 100 having the computing unit 10. Accordingly, the computing unit 10 may be a computing unit of the vehicle 100, such as a vehicle computing unit. The computing unit 10 can be designed to provide software-based vehicle functionality.

1c FIG. 12 shows a flowchart of an example of a corresponding method for the computing unit for the vehicle. The method includes storing 110 a cryptographically secured starting base system of the computing unit, an operating system of the computing unit and one or more computing function blocks of the vehicle. The method includes starting 120 the cryptographically secured starting base system of the processing unit. The method includes checking 130, by the cryptographically secured start base system, an integrity of the operating system of the processing unit based on a cryptographically generated signature of the operating system. The method includes starting 140 the operating system of the processing unit if the integrity of the operating system has been determined. The method includes checking 150, by the cryptographically secured starting base system or by the operating system, an integrity of the one or more computing function blocks of the vehicle based on one or more cryptographically generated signatures of the one or more computing function blocks. The method includes starting 160 the one or more computational function blocks if the integrity of the one or more computational function blocks has been determined. For example, the method can be performed by the computing unit 10, for example by the one or more processors 14 of the computing unit or by the one or more storage devices 16 of the computing unit (for storing the cryptographically secured starting base system of the computing unit, the operating system of the computing unit and the one or more calculation function blocks of the vehicle).

In the following, the functionality of the processing unit in relation to the processing unit 10 of the 1a and 1b introduced. Features that are part of the processing unit 10 of 1a and/or 1b can also be introduced into the corresponding procedures of 1c be taken over.

The present disclosure deals with the computing unit 10 for a vehicle. This processing unit can be, for example, a processing unit of a plurality of processing units of a vehicle. For example, as already mentioned, the computing unit can be a computing unit for providing software-based vehicle functionality.

This vehicle functionality is essentially provided by the plurality of computing function blocks. The calculation function blocks are logical units that provide software-based vehicle functionalities. A technology can be used in which services that provide software functionalities of the vehicle are packaged in the computing function blocks. These arithmetic function blocks can in turn be implemented by so-called software containers or correspond to them. One or more services can be encapsulated with all their dependencies in a software container. These containers are known in particular for use on servers and developer devices. For example, such containers can be provided by different container engines (Docker, Podman, Crio, ...). The present disclosure provides for use of such containers in a vehicle. The computing unit 10 can be designed to run a runtime environment (18c in 1a) for the arithmetic function blocks/containers. This runtime environment can in turn be provided by the operating system of the processing unit.

The one or more arithmetic function blocks are thus at the top of a layer model - the one or more arithmetic function blocks 18d are, as in 1a is shown executed in a runtime environment 18c, which in turn is executed in the operating system 18b or provided by the operating system 18b. This in turn is checked and started by the starting base system 18a. A chain of trust proceeds from the starting base system, with which the execution of the operating system, and either directly or transitively via the operating system, the execution of the one or more arithmetic function blocks is secured.

The starting point of the chain of trust is the starting base system, which, like the operating system and the one or more computing function blocks, is stored in the one or more memory devices of the computing unit. In this case, the starting base system and the operating system on the one hand, and the one or more functional computing units on the other hand, can definitely be treated differently and stored differently. For example, the starting base system can be stored in a read-only memory of the processing unit. For example, the starting base system can be part of a so-called firmware of the computing unit. This basic starting system can, for example, only be changed by so-called "flashing" of the firmware. Alternatively, the boot base system can be modified along with the operating system, such as by "flashing" the firmware, or by storing the boot base system and the operating system in an additional secured storage area of the one or more storage devices. For example, the cryptographically secured boot framework and the operating system may be stored in a cryptographically secured storage area or in a read-only storage area of the one or more storage devices. The read-only memory area can have hardware protection against changes that can only be overcome by "flashing" the firmware (or by hardware bridging). The cryptographically secured memory area can have a cryptographically generated signature, it being possible to identify changes in the cryptographically secured memory area based on the cryptographically generated signature. The cryptographically generated signature can be based on a hash value (scrambling value) of the data stored in the cryptographically secured memory area, with the hash value being encrypted based on a private cryptographic key (e.g. from the manufacturer of the computing unit or the vehicle manufacturer) in order to Generate cryptographically generated signature. The signature, i.e. the cryptographically encrypted hash value, can be verified using a public key matching the private key in order to verify the integrity of the cryptographically secured memory report.

The present disclosure is based on cryptographically generated signatures and cryptographic keys. As the use of the terms "private key" and "public key" already indicates, the use of a public key method based on a public key and an associated private key is assumed below.

In contrast, the one or more arithmetic function blocks can be stored in a writable memory area of the one or more memory devices. This can be done to allow the one or more computational functional blocks to be independent of the boot base system and independent of the operating system can be updated. In other words, the one or more computing function blocks can be updateable independently of the operating system. The updating of a computing function block can be performed by the operating system by receiving the updated computing function block, for example from a backend server (such as the backend server 200 of 2 ), and receiving a corresponding cryptographically generated signature of the updated computational function block along with the updated computational function block. In the proposed concept, the arithmetic function block can be downloaded from a backend server and stored in an (unsecured) data memory, such as the writable memory area. Attackers may be able to access this (unsecured) data store and modify/overwrite it, but this can be detected by checking the signature. For example, the one or more processors can be designed to update an arithmetic function unit by the operating system in that the updated arithmetic function unit is received together with a corresponding cryptographically generated signature and stored in the writable memory area. However, the computational functional block is verified by an operation running on the backend server and receives a certificate, token, etc. (the cryptographically generated signature) if the backend checks are successful.

The backend server can be given the role of generating the cryptographically generated signatures used (of the one or more arithmetic function blocks and optionally of the operating system and/or the starting base system). In other words, the cryptographically generated signatures used can be generated by the backend server. Furthermore, the one or more arithmetic function blocks can be provided by the backend server together with the one or more signatures for the arithmetic unit and can therefore also be updated. If an arithmetic function block is updated, the corresponding signature is also updated at the same time and made available with the arithmetic function block.

A two-tier security strategy is used in the proposed concept. In this two-tier concept, the system software continues to use the existing Secure Boot operation - and is therefore considered secure. Consequently, the one or more processors are designed to start the cryptographically secured starting basic system of the processing unit. It uses the cryptographic security of the boot base system to provide Secure Boot functionality or Secure Boot-like functionality. The starting base system can in turn be secured by a cryptographically generated signature, which is checked by the processing unit, for example by a so-called UEFI (Unified Extensible Firmware Interface, unified, extensible firmware interface) and is started after checking. The start base system can provide a boot loader, for example, which in turn can be used to check and start the operating system. The arithmetic function blocks, on the other hand, do not use the existing Secure Boot operation.

If the start base system is successful, for example because the cryptographic security of the start base system is intact, the operating system can now be checked and started. The one or more processors are designed to check, using the cryptographically secured start base system, an integrity of the operating system of the processing unit based on a cryptographically generated signature of the operating system. Similar to what was written in relation to the cryptographically secured memory area, the verification can be based on the fact that the cryptographically generated signature is based on a hash value of the (integral) operating system and based on a private key (e.g. from the manufacturer of the computing unit, the vehicle or the Operating system) is generated, the signature based on an associated public key (such as the manufacturer of the computing unit, the vehicle or the operating system) and the hash value of the operating system can be checked. For example, the public key may be included in the boot base system and therefore protected via Secure Boot functionality. The one or more processors are designed to start the operating system of the computing unit if the integrity of the operating system has been determined. In this way, the chain of trust could be extended from the basic start system to the operating system for checking and starting the operating system.

This chain of trust is now extended to the arithmetic function blocks.

During the starting process of the computing function blocks in the vehicle, the system software, i.e. the operating system or the starting basic system, the certificate, the token etc. (i.e. the signature) and the integrity of the function container can now check, for example by a hash/checksum check and/or or a certification exam. The one or more processors are configured to verify, by the cryptographically secured boot framework or by the operating system, an integrity of the one or more Computing function blocks of the vehicle based on one or more cryptographically generated signatures of the one or more computing function blocks. Similar to checking the integrity of the operating system, cryptographically generated signatures are used again. Again, the verification of a computing function block can be based on the cryptographically generated signature based on a hash value of the (integral) computing function block and based on a private key (e.g. the manufacturer of the computing unit, the vehicle or the computing function block) is generated, whereby the signature can be verified based on an associated public key (e.g. from the manufacturer of the computing unit, the vehicle or the computing function block) and the hash value of the computing function block. For example, the public key may be included in the boot framework and therefore protected via the Secure Boot functionality, or the public key may be included in the operating system and therefore transitively protected via the boot framework. Therefore, the validation of the one or more computational functional blocks may be based on a chain of trust that traces back to the cryptographically-secured starting base system, such as directly or transitively through the starting base system.

So far it has been assumed that the cryptographically generated signatures of the one or more arithmetic function blocks were generated with a non-vehicle-specific key, such as a private key of the manufacturer of the arithmetic unit, the vehicle or the respective arithmetic function block. In some cases, however, the concept can be extended to use a cryptographic key that is vehicle-specific (i.e. used for a single vehicle). Accordingly, the one or more cryptographically generated signatures of the one or more computational function blocks may be vehicle specific. For this purpose, for example, a vehicle-specific (private) key can be derived from a (private) cryptographic key of the manufacturer of the computing unit, the vehicle or the computing function block, which in turn is used to generate the cryptographically generated signature of the computing function block. The signature can then be checked, for example, using a corresponding vehicle-specific public key. The origin of this vehicle-specific public key can now be checked based on the public key of the manufacturer of the computing unit, the vehicle or the computing function block. The vehicle-specific (public) key can now be stored in the start-up base system or in the operating system. Optionally, synchronization can be performed via a car key (for example, the backend verification can sign the computational function block with a private key, with the car key being assigned a corresponding public key). The one or more processors can thus be designed to retrieve the (public) cryptographic key for checking the one or more computing function blocks from a (physical) vehicle key of the vehicle, for example via the one or more interfaces 12.

If these checks are successful, the system container can be started, since a trustworthy chain is built up from the secure boot process of the vehicle, the system software, the backend checks (to generate the signatures) and the function container. The one or more processors are therefore configured to start the one or more computing function blocks if the integrity of the one or more computing function blocks has been determined. If these checks are unsuccessful (because, for example, the functional software has been modified by an attacker), the software will not start. Consequently, the starting of the one or more arithmetic function blocks is denied if the verification of the one or more cryptographically generated signatures fails.

Optionally, an alarm can be raised in the backend if modified software is detected, and additional shutdowns can be performed for other functions/operations. Consequently, the one or more processors can be designed to report a failure of the verification of the one or more cryptographically generated signatures to a remote peer. The one or more processors can also be designed to restrict execution of the operating system, the runtime environment and/or at least one computing function block if the check of the one or more cryptographically generated signatures fails.

The proposed concept thus creates a two-stage (or three-stage) secure boot process for system software and computational function blocks. Secure boot is enabled at the system level and verification of the computational function blocks built into the secure system software is used to extend the secure boot process to the computational function blocks. In this case, the verification can be carried out by the backend in that the signatures are generated by the backend. Thus, a combination of Secure Boot for system software and a backend check of the computational functional blocks is provided. A chain of trust is going out from the secure system software to the verification functionality in the system software and verification by the backend.

The same concept can be used, for example, for safety-related calculation function block updates for industrial applications.

The one or more interfaces 12 may correspond, for example, to one or more inputs and/or one or more outputs for receiving and/or transmitting information, such as in digital bit values, based on a code, within a module, between modules, or between modules of different ones entities.

The one or more processors 14 may correspond to any controller or processor or programmable hardware component. For example, the functionality of the one or more processors 14 can also be implemented as software that is programmed for a corresponding hardware component. In this respect, the one or more processors 14 can be implemented as programmable hardware with correspondingly adapted software. Any processors, such as digital signal processors (DSPs) can be used. Exemplary embodiments are not limited to a specific type of processor. Any processors or even multiple processors are conceivable for the implementation. In this case, the one or more processors, for example in interaction with a firmware/UEFI, can be designed to provide a secure boot operation (to check or start the basic boot system).

The one or more storage devices 16 can be, for example, at least one element from the group of computer-readable storage medium, magnetic storage medium, optical storage medium, hard drive, flash memory, floppy disk, random access memory (also engl. Random Access Memory), programmable read only memory (PROM), erasable include programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), and network storage.

More details and aspects of the computing unit as well as the corresponding method and computer program and the vehicle are mentioned in connection with the concept or examples described before or after (see 2 ). The computing unit, the corresponding method and/or computer program and the vehicle may comprise one or more additional optional features corresponding to one or more aspects of the proposed concept or the described examples as described before or after.

2 shows a schematic diagram of an example of an interaction of different components in a computing unit 10 for a vehicle. In this case, the processing unit 10 of the processing unit 10 of 1a and/or correspond to 1b. The computing unit 10, which is arranged in a vehicle, comprises a secure boot block 18a, which comprises the starting basic system and is started first (indicated by the number 1 in a circle). Based on the secure boot block 18a, the operating system 18b is started as well as a computational function block (RFB) boot system 18e (indicated by the number 2 in a circle). In this case, the RFB boot system 18e can be part of the operating system. The RFB boot system 18e may be configured to perform the integrity of the computational function blocks RFB1-RFB4 18d. The operating system 18b, the RFB boot system 18e and the arithmetic function blocks RFB1-FRB4 18d are protected by cryptographically generated signatures (represented by the number 2 in the square box) generated by the backend server 200. The RFB boot system 18e can receive a vehicle specific public key from the vehicle key 105 .

More details and aspects of the computational unit are mentioned in connection with the concept or examples described before or after (see 1a until 1c ). The computing unit may comprise one or more additional optional features corresponding to one or more aspects of the proposed concept or the described examples as described before or after.

The aspects and features described in connection with a certain of the previous examples can also be combined with one or more of the further examples in order to replace an identical or similar feature of this further example or to additionally introduce the feature into the further example .

Examples may further include or relate to a (computer) program having program code for performing one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component. Thus, steps, operations, or processes of various methods described above may also be performed by programmed computers, processors, or other programmable hardware components. Examples can also include program storage devices genes, such as digital data storage media, which are machine, processor or computer readable and which encode or contain machine-executable, processor-executable or computer-executable programs and instructions. The program storage devices may include or be, for example, digital memory, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media. Further examples can also be computers, processors, control units, (field) programmable logic arrays ((F)PLAs = (Field) Programmable Logic Arrays), (field) programmable gate arrays ((F)PGA = (Field) Programmable Gate arrays), graphics processors (GPU = graphics processor unit), application-specific integrated circuits (ASIC = application-specific integrated circuit), integrated circuits (IC = integrated circuit) or single-chip systems (SoC = system-on-a-chip). ) that are programmed to perform the steps of the above procedures.

It is further understood that disclosure of a plurality of steps, processes, operations, or functions disclosed in the specification or claims should not be construed as necessarily being in the order described, unless expressly stated in an individual case or is compellingly necessary for technical reasons . Therefore, the foregoing description is not intended to limit the performance of any number of steps or functions to any particular order. Further, in other examples, a single step, function, process, or operation may include and/or be broken into multiple sub-steps, functions, processes, or operations.

If some aspects have been described in the preceding paragraphs in the context of a device or a system, these aspects are also to be understood as a description of the corresponding method. For example, a block, a device or a functional aspect of the device or the system can correspond to a feature, such as a method step, of the corresponding method. Correspondingly, aspects described in connection with a method are also to be understood as a description of a corresponding block, element, property or functional feature of a corresponding device or system.

The following claims are hereby incorporated into the Detailed Description, with each claim being able to stand on its own as a separate example. It should also be noted that although a dependent claim in the claims refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject-matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in individual cases that a specific combination is not intended. Furthermore, features of a claim are also intended to be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Reference List

10

unit of account

12

interface

14

processor

16

storage device

18a

Start base system

18b

operating system

18c

runtime environment

18d

Arithmetic Function Blocks

18e

Compute function block boot process

100

vehicle

105

vehicle key

110

Storing a cryptographically secured boot base system, an operating system, and one or more computational function blocks

120

Starting the cryptographically secured starting base system

130

Checking the operating system

140

Starting the operating system

150

Checking the one or more arithmetic function blocks

160

Starting the one or more arithmetic function blocks

200

backend server

QUOTES INCLUDED IN DESCRIPTION

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

Patent Literature Cited

• US20200320201A1 [0007]
• WO 2020070061 A1 [0008]
• US 20190391802 A1 [0008]

Claims (15)

A computing unit (10) for a vehicle, comprising: One or more storage devices (16) designed to store a cryptographically secured starting base system (18a) of the computing unit, an operating system (18b) of the computing unit and one or more computing function blocks (18d) of the vehicle; and One or more processors (14) configured to: starting the cryptographically secured starting base system of the computing unit; Checking, by the cryptographically secured starting base system, an integrity of the operating system of the computing unit based on a cryptographically generated signature of the operating system; starting the operating system of the processing unit if the integrity of the operating system has been determined; verifying, by the cryptographically secured boot base system or by the operating system, an integrity of the one or more computing function blocks of the vehicle based on one or more cryptographically generated signatures of the one or more computing function blocks; and Starting the one or more computational function blocks if the integrity of the one or more computational function blocks has been determined. The device according to claim 1 , wherein the verification of the one or more arithmetic function blocks is based on a chain of trust that leads back to the cryptographically secured starting base system. The device according to one of Claims 1 or 2 , wherein the integrity of the one or more arithmetic function blocks is checked by the cryptographically secured starting base system of the arithmetic unit. The device according to one of Claims 1 or 2 , wherein the integrity of the one or more arithmetic function blocks is checked by the operating system of the arithmetic unit. The device according to one of Claims 1 until 4 , wherein the cryptographically secured boot base system and the operating system are stored in a cryptographically secured storage area or in a read-only storage area of the one or more storage devices. The device according to one of Claims 1 until 5 , wherein the one or more computational function blocks are stored in a writable memory area of the one or more memory devices. The device according to claim 6 , wherein the one or more processors are configured to, through the operating system, update an arithmetic functional unit in that the updated arithmetic functional unit is received together with a corresponding cryptographically generated signature and stored in the writable memory area. The device according to one of Claims 1 until 7 , wherein the one or more cryptographically generated signatures of the one or more computing function blocks are vehicle-specific. The device according to claim 8 , wherein the one or more processors are designed to retrieve a cryptographic key for checking the one or more arithmetic function blocks from a vehicle key of the vehicle. The device according to one of Claims 1 until 9 , wherein the one or more computational functional blocks are updateable independently of the operating system. The device according to one of Claims 1 until 10 , wherein the starting of the one or more arithmetic function blocks is denied if the verification of the one or more cryptographically generated signatures fails. The device according to one of Claims 1 until 11 , wherein the one or more processors are designed to report a failure of the verification of the one or more cryptographically generated signatures to a remote peer. A vehicle (100) comprising the computing unit (10) according to any one of Claims 1 until 12 . A method for a computing unit for a vehicle, comprising: storing (110) a cryptographically secured starting base system of the computing unit, an operating system of the computing unit and one or more computing functional blocks of the vehicle; starting (120) the cryptographically secured starting base system of the computing unit; Checking (130), by means of the cryptographically secured starting base system, an integrity of the operating system of the computing unit based on a cryptographically generated signature of the operating system; Starting (140) the operating system of the arithmetic units heit if the integrity of the operating system has been determined; verifying (150), by the cryptographically secured boot base system or by the operating system, an integrity of the one or more computing functional blocks of the vehicle based on one or more cryptographically generated signatures of the one or more computing functional blocks; and starting (160) the one or more computational function blocks if the integrity of the one or more computational function blocks has been determined. Program with a program code for performing the method according to Claim 14 , when the program code is executed on a computer, processor, control module or programmable hardware component.

Images