ECU architecture with improved job handling options

Abstract

The invention relates to a control device (1), in particular for an automotive application, comprising: - a number of processor cores (2) - a hardware security module (HSM) (4), - a main memory (3) as a program and data memory for the processor cores (2) and with a shared memory area (31) which is accessible by the processor cores (2) and by the HSM (4), wherein for each software function stored in the main memory (3) a job context is stored in encrypted form in a section of the shared memory area (31); and - a job handler (5) who is trained to ◯ when executing one or more software functions as a respective job, to identify a corresponding job context in the corresponding section of the shared memory area (31), and ◯ transmit pointer information to the HSM (4) that references the corresponding section of the shared memory area (31), ◯ instruct the HSM (4) to decrypt the job context from the corresponding section of the shared memory area (31) into an HSM memory area (41), ◯ to instruct the HSM (4) after completion of the execution of the software function to encrypt the job context and store it in the corresponding section of the shared memory area (31).

Description

Technical area

[0001] The invention relates to control units, particularly for motor vehicles, that have a hardware security module with a job-handling software architecture. The invention further relates to control unit architectures that can circumvent a limitation on the simultaneous storage of job contexts in the hardware security module. This technology can also be extended to trusted execution environments (TEEs). Technical background

[0002] A hardware security module (HSM) is typically a standalone hardware component in control units, particularly in motor vehicles, that secures cryptographic procedures. Typically, the HSM manages and applies cryptographic keys. Sometimes, a context is required to continue a partially executed security operation. For example, a long message to be encrypted is split into smaller sections, and the context (partial result) of each smaller section may be required to proceed to the next sections. This is referred to below as the job context.

[0003] Current job-handling software architectures in an ECU's hardware security module have a limitation on the number of concurrently active jobs. This limitation results from the amount of RAM required to allocate independent data structures for the job contexts. Jobs correspond to software functions that can be activated, operated, or called by multiple users and / or instances.

[0004] The memory (HSM memory) in the HSM is limited and is also used to store other resources, such as global variables, key management, key stack management, and the like. The amount of RAM that can be allocated to job contexts therefore represents a compromise between the required resources.

[0005] Current architectures typically provide a predefined maximum number of job contexts, which is determined by the overall system architecture. This number cannot usually be adapted to changing requirements corresponding to the number of jobs that must be executed during different phases of a vehicle's driving cycle.

[0006] This can lead to either over-allocation of RAM to job contexts or unused memory with under-allocation corresponding to the current demand for the number of concurrent jobs. In particular, the case of over-allocation of HSM memory to job contexts with multiple jobs is critical because, if all job contexts are occupied, new jobs cannot be executed immediately, resulting in performance degradation or, in certain circumstances where the job is safety-critical, potentially compromising the safety of the motor vehicle and its occupants.

[0007] Furthermore, in previous architectures, job context allocation is sequential, which can lead to blocking in the operating system. Blocking is time-critical if the host computer has to wait until the HSM has finished allocating job contexts. The duration of the blocking depends on the current load on the HSM. Furthermore, the shared use of HSM memory by the job contexts of the active jobs limits availability for cryptographic requirements, such as a key manager.

[0008] It is an object of the present invention to provide an improved architecture of a control device in which the number of simultaneously active job contexts is not limited by the available HSM memory and an unrestricted availability of the HSM is ensured. Disclosure of the invention

[0009] This object is achieved by the control device according to claim 1 and by the method for operating a control device according to the independent claim.

[0010] Further embodiments are specified in the dependent claims.

[0011] According to a first aspect, a control device, in particular for an automotive application, is provided, comprising: - a number of processor cores - a hardware security module (HSM), - a main memory as program and data memory for the processor cores and with a shared memory area accessible by the processor cores and by the HSM, wherein for each software function stored in the main memory, a job context is stored encrypted in a section of the shared memory area; and - a job handler who is trained to ◯ when executing one or more software functions as a respective job, to identify a corresponding job context in the corresponding section of the shared memory area, and ◯ to transmit pointer information to the HSM that references the corresponding section of the shared memory area, ◯ instruct the HSM to read and decrypt the job context from the corresponding section of the shared memory area, ◯ instruct the HSM, after the software function has finished executing, to encrypt the job context and store it in the appropriate section of the shared memory area.

[0012] The above data processing architecture of an ECU provides for storing the job context for a job to be executed in a shared memory area accessible by both the host computer and the HSM. The HSM should also include Trusted Execution Environments (TEE). For this purpose, the user or instance in the host computer defines the job context of the function to be executed based on the defined data structures in a software component as needed. Thus, for the execution of a job, an area in the host computer's RAM is allocated for the corresponding job context and references it (pointer to memory address) for the execution of cryptographic or related procedures of the job.

[0013] Since the amount of shared memory in the host computer can be very large relative to the amount of data stored in job contexts, this ensures that the number of job contexts that can be active in parallel depends only on user requirements or software functionality, and not on the HSM memory limitations. The HSM can thus be used for requirements with 100 concurrently active jobs with corresponding job contexts, or only 5 concurrently active jobs with corresponding job contexts, for example, without requiring any architectural changes.

[0014] The security of the job context is achieved through cryptographic encryption and authentication mechanisms, making it impossible to tamper with or intercept the host computer. During job execution, the HSM copies the job context to its stack memory and writes it back to RAM, i.e., to the appropriate memory area for job contexts after cryptographic encryption. If the job context is reused, it can be cryptographically verified with authentication data to determine whether any tampering has occurred.

[0015] Because the job context is provided by the user, software function, or instance on the host computer, there are no long wait times before the job executes, as is the case with conventional architectures that require sequential allocation of HSM memory for job contexts. Furthermore, it is no longer possible for a job to fail to execute because the HSM memory is insufficient for job contexts. In addition, the exact size of the required memory area can now be allocated to store the job context for a job, rather than the memory size of the largest possible job context, as was previously the case with conventional architectures, where the reserved job context must encompass any job size.

[0016] According to a further aspect, a method for operating the above control device is provided, comprising the following steps: - when executing one or more software functions as a respective job, identifying a corresponding job context in the corresponding section of the shared memory area, and - Transmitting pointer information to the HSM that references the corresponding section of the shared memory area, - Reading the corresponding job context of the one or more software functions from the corresponding section of the shared memory area - Decrypting and / or authenticating the corresponding job context of the one or more software functions, - after completion of the execution of one or more software functions, encrypting the relevant job contexts; - Saving the relevant encrypted job contexts (with authentication data) in the corresponding sections of the shared memory area. Short description of the drawings

[0017] Embodiments are explained in more detail below with reference to the attached drawings. They show: Fig. 1 a schematic representation of a control unit with a control unit chip on which a data processing architecture is implemented; and Fig. 2 a flowchart illustrating a method for operating a control unit of the Fig. 1. Description of embodiments

[0018] Fig. 1 shows a schematic representation of a control unit 1, in particular for automotive applications, which has a number of processor cores 2 and a main memory 3 as program and data memory of a host computer as well as an HSM 4.

[0019] A plurality of virtual machines can be implemented in the main memory 3, each assigned to a user and providing a variety of software functions. The main memory 3 further comprises a shared memory area 31, which can be accessed by the processor cores 2 and the HSM 4.

[0020] The HSM 4 has an HSM memory 41 as a stack memory in which job contexts for performing cryptographic and authentication operations can be stored.

[0021] The software functions can be called by requesting the execution of the respective software function from a job handler 5. At the same time, a job context is created and stored in a section of the shared memory area 31 of the main memory 3.

[0022] The job handler 5 communicates with the HSM 4, passing a pointer to the section of the shared memory area 31 in which the job context for the respective software function is stored. This allows the HSM 4 to retrieve the job context from the shared memory area 31, making it available to the HSM 4. In other words, the job context is transferred or copied to the HSM memory 41. The job context is then authenticated and decrypted in the HSM 4 and can be reused.

[0023] The HSM 4 communicates with crypto modules 6 to perform encryption and decryption tasks based on the job contexts stored in the HSM memory 41. The encryption and decryption tasks can be performed using methods known per se.

[0024] When the contents of the section of shared memory 31 for the corresponding job context are transferred to the HSM memory, they can be decrypted and stored unencrypted in a stack memory of the HSM 4 during job execution. After the software function has been completed, the job context in the HSM 4 can be transferred back to the corresponding section of memory 31. The job context is stored encrypted (with authentication data) in the shared memory 31 to ensure tamper protection. This process can be more efficient if there is dedicated hardware support for handling the above-mentioned mechanism.

[0025] Fig. 2 illustrates the method using a flow chart, the sequence of which describes an execution of a software function in the control unit 1.

[0026] In step S1, to call a software function, the job handler 5 is first instructed to call the software function.

[0027] In step S2, the job handler 5 reads the job context from the section of the shared memory area 31 of the main memory 3 of the host computer and transmits it to the HSM 4 in step S3.

[0028] In the HSM 4, the job context is decrypted in step S4 and temporarily stored in a stack memory 41 of the HSM 4 during the execution of the job.

[0029] After the job is completed, the job context in the HSM 4 is transmitted back to the host computer in step S5. The transmission is encrypted so that no manipulation can occur when the job context is stored in the shared memory area 31 of the host computer.

[0030] By storing the job contexts in the HSM 4 only during the execution of the associated job, a much larger number of different jobs can be provided, since blocking a corresponding memory area with limited storage capacity in the HSM 4 is avoided.

Claims

[1] Control device (1), in particular for an automotive application, comprising: - a number of processor cores (2) - a hardware security module (HSM) (4), - a main memory (3) as a program and data memory for the processor cores (2) and with a shared memory area (31) which is accessible by the processor cores (2) and by the HSM (4), wherein for each software function stored in the main memory (3) a job context is stored in encrypted form in a section of the shared memory area (31); and - a job handler (5) who is trained to ◯ when executing one or more software functions as a respective job, to identify a corresponding job context in the corresponding section of the shared memory area (31), and ◯ transmit pointer information to the HSM (4) that references the corresponding section of the shared memory area (31), ◯ instruct the HSM (4) to decrypt the job context from the corresponding section of the shared memory area (31) into an HSM memory area (41), ◯ to instruct the HSM (4) after completion of the execution of the software function to encrypt the job context and store it in the corresponding section of the shared memory area (31). [2] Control device (1) according to claim 1, wherein during the execution of the software function the decrypted job context is stored in a stack memory of the HSM (4). [3] Control device according to claim 1 or 2, wherein the HSM (4) is designed to cryptographically check a job context of a called software function to determine whether manipulation has occurred. [4] Method for operating a control device (1) according to one of claims 1 to 3, comprising the following steps: - when executing one or more software functions as a respective job, identifying a corresponding job context in the corresponding section of the shared memory area (31), and - transmitting pointer information to the HSM (4) that references the corresponding section of the shared memory area (31), - reading the corresponding job context of the one or more software functions from the corresponding section of the shared memory area (31); - Decrypting the corresponding job context of the one or more software functions in the HSM (4), - after completion of the execution of one or more software functions, encrypting the relevant job contexts; - Storing the relevant encrypted job contexts in the corresponding sections of the shared memory area (31). [5] Method according to claim 4, wherein the job context is copied into a stack memory of the HSM (4) before decryption. [6] Computer program arranged to carry out the method according to one of claims 4 to 5. [7] A machine-readable storage medium on which the computer program according to claim 4 or 5 is stored.

Images