Processing system with trust anchor computing device and corresponding method - Patents.com

Abstract

To provide a processing system having a trust anchor computing device.SOLUTION: In runtime authenticity check 500, a processing system identifies 505 a signed software block SSBj that is present in a program memory of a hardware trust anchor for at least execution and a corresponding header and a data block, and executes a first step 510 of checking validity of a certificate associated with the SSBj for each SSBj, a second step 520 of checking validity of a header of the SBBj, and a third step 530 of checking validity of a hash of data of the SSBj. If abnormality is detected by one of the steps 510, 520, 530 for checking validity, a secure log SL regarding detected abnormality is written 560.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] The present description relates to a processing system comprising at least one host computing module including a host processing unit and a host memory means, and a hardware trust anchor, configured to perform trusted operations. The processing system comprising the at least one host module and the hardware trust anchor is preferably part of a system on chip, especially when said at least one host module is an ECU operating in a vehicle. [Background technology]

[0002] A Hardware Trust Anchor (HTA) is a local, isolated computing device that initiates the trust chain and performs both system-critical and security functions, including proactive monitoring of the startup process and shutting down processes if tampering is detected.

[0003] In a typical automotive scenario, a processing system such as an Electronic Control Unit (ECU) is based on one or more SoCs (System-on-Chips) consisting of application processing units, i.e. application cores, for vehicle functions and HTAs for security support. Therefore, Hardware Trust Anchor techniques (HTAs) are used to harden the ECU against external attacks (unauthorized activation of vehicle functions, reading of sensitive key material, software manipulation, etc.).

[0004] The HTA may include a processing unit that uses a real-time operating system (RTOS) that is embedded with a set of mechanisms used to increase the basic security of the HTA side, and is therefore called a security-hardened real-time operating system. In computing, hardening is usually the process of ensuring the security of a system by reducing its surface vulnerabilities.

[0005] These protection techniques are therefore designed to more effectively detect and react to attacks and limit the ability of those attacks to execute exploits.

[0006] HTA is Key management, Certificate management, ·Encryption operations, Software protection (secure boot and secure updates), Data protection (secure storage and secure communication) using access mechanisms for reading and writing sensitive data and encryption techniques to reduce data visibility; Used for security operations involving confidential and sensitive information, such as:

[0007] Therefore, the result is a security-hardened real-time operating system that: - Multiple secure operations can be performed simultaneously Switching between different entities (processes or tasks) according to some predefined logic and scheduling policies; · Guarantee and maintain confidentiality (information isolation); Ensuring that general functions are performed and the time at which they are performed is known; It should be possible.

[0008] A security-hardened real-time operating system used for HTA may be a static and unmodifiable operating environment, meaning that no application objects, tasks, events, or resources can be created or deleted while the application is running. Correctness (integrity) of data and other memory sections should be a fundamental requirement in a secure system.

[0009] Today, most automotive ECUs support software download so that application software or data can be updated at any time. Depending on the OEM requirements, some checks are performed during the software download to ensure that the new software is valid, during power-on of the ECU to ensure that the software is still valid, or a combination of the two. There are various ways to handle the validity information.

[0010] For example, an integrity check may be performed, which is usually required for security reasons. The integrity check is based on a checksum / CRC (Cyclic Redundancy Check) that is calculated over the non-volatile software data and compared to a reference value. If the checksum is correct, the integrity of the whole software block is assumed. However, checksum algorithms like CRC do not provide an authenticity check, since no secret parameters are involved when calculating the checksum.

[0011] Such an authenticity check is instead required by some ECUs that require that only software or data from legitimate sources be used in the ECU (e.g., in security-related ECUs or as coordination protection). Authentication is typically performed by the computation of a cryptographic signature over the non-volatile software data. The signature can be supplied by either the OEM or the ECU supplier.

[0012] The signature calculation algorithm is a combination of hardware-based, such as those executed in modules 122a-122e, or software-based hash calculations and encryption routines to ensure the integrity and authenticity of the downloaded software. If the hardware trust anchor (HTA) does not include modules 122a-122b, or includes only a subset of them, the computation is performed in software and no special hardware is required to perform the encryption operation. The above method can also be used to check validity information at run time.

[0013] Currently, only integrity checks are used at run-time to simply meet safety requirements, but such methods still cannot detect manipulations of the original ECU during normal operation of the ECU itself.

[0014] [Objectives and Overview] An aim of one or more embodiments is to overcome the limitations inherent in the solutions achievable by the prior art.

[0015] According to one or more embodiments, this object is achieved by a system having the features defined in claim 1. One or more embodiments may relate to a corresponding system.

[0016] The claims form an essential part of the technical teachings provided herein in connection with the various embodiments.

[0017] According to the solution described herein, the solution is a processing system configured to perform trusted operations, comprising at least one host computing module including a host processing unit and a host memory means, and a hardware trust anchor, said hardware trust anchor comprising a respective secure processing unit, a hardware processing module dedicated to cryptographic operations, and secure storage means, said hardware trust anchor being configured to store and execute a real-time secure operating system, said real-time secure operating system being configured to perform a validity check on software used in said processing system, said real-time secure operating system being configured to perform a run-time authenticity check controlling the integrity of software code at run-time, said run-time authenticity check being configured to at least validate the integrity of the ... and identifying signed software blocks and corresponding headers and data blocks present in a program memory of the host computing module and ultimately in the program memory of the host computing module; and for each signed software block, performing a first step of checking the validity of a certificate associated with the signed software block, a second step of checking the validity of a header of the signed software block, and a third step of checking the validity of a hash of data of the signed software block; and if an anomaly is detected by one of the validity check checking steps, writing secure log information regarding the detected anomaly, wherein the real-time secure operating system is configured to perform the run-time authenticity checks in a task that has highest priority over the services of other host computing modules or a hardware trust anchor.

[0018] The solution described herein also relates to a corresponding method of performing trusted operations in a processing system, including storing and executing a real-time secure operating system that performs validity checks on software used in the processing system, the method including a step of performing a run-time authenticity check to control the integrity of the software code at run-time, the run-time authenticity check including the steps of identifying signed software blocks and corresponding headers and data blocks that are present in the program memory of the hardware trust anchor for execution and ultimately in the program memory of a host computing module, and for each signed software block, performing a first step of checking the validity of a certificate associated with the signed software block, a second step of checking the validity of a header of the signed software block, and a third step of checking the validity of a hash of data of the signed software block, and if an anomaly is detected by one of the validity check checking steps, writing secure log information regarding the detected anomaly, the real-time secure operating system configured to perform the run-time authenticity check in a task that has the highest priority with respect to other host computing modules or the services of a hardware trust anchor. [Brief description of the drawings]

[0019] Embodiments will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which: [Figure 1] FIG. 1 illustrates a schematic diagram of one embodiment of a processing system disclosed herein. [Diagram 2] FIG. 2 is a schematic diagram illustrating the address space of a memory used by the processing system disclosed herein; [Diagram 3] FIG. 2 illustrates a schematic representation of memory areas of a memory used by the processing system disclosed herein; [Figure 4]FIG. 2 is a flow diagram of an authenticity checking procedure implemented by the processing system disclosed herein. [Diagram 5] FIG. 2 is a timing diagram illustrating several phases of operation of the processing system disclosed herein. [Figure 6] FIG. 2 is a block diagram of a stack of memories of the processing system disclosed herein. [Figure 7] FIG. 1 is a flow diagram of a stack overflow control procedure implemented by the processing system disclosed herein. [Figure 8] FIG. 2 is a flow diagram of a detection procedure implemented by the processing system disclosed herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] The following description sets forth various specific details for the purpose of providing a thorough understanding of the embodiments. The embodiments may be implemented without one or more of the specific details, or may be implemented with other methods, components, materials, etc. In other cases, well-known structures, materials, or operations are not shown or described in detail so as not to obscure various aspects of the embodiments.

[0021] In the framework of this description, reference to "one embodiment" or "one embodiment" is intended to indicate that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. Similarly, phrases such as "in one embodiment" or "in one embodiment" that may appear in various places in this description do not necessarily refer to one and the same embodiment. Furthermore, particular features, structures, or characteristics may be combined as appropriate in one or more embodiments.

[0022] The reference signs used herein are intended merely for convenience and therefore do not define the scope of protection or the scope of the embodiments.

[0023] 1 shows a processing system 10, which may correspond, for example, to an ECU on a SoC for automotive applications, for example in the control system of an engine or other functional part of a vehicle, and includes an application processing unit, i.e., application core 11, and a hardware trust anchor (HTA) 12. Application core 11 includes non-volatile memory 111, RAM memory 112, a bus interface 114 for communicating with, for example, a vehicle bus, and an application CPU 113. HTA 12 includes a secure storage 121 including a secure non-volatile memory 121b and a secure RAM memory 121a. HTA 12 further comprises a secure processing unit 123, an HTA interface module 124, and a cryptographic hardware acceleration module 122, which may include a hash engine 122a for computing a hash value of software data, a symmetric cryptographic engine 122b for performing a symmetric cryptographic algorithm and an asymmetric cryptographic engine 122c for performing an asymmetric cryptographic algorithm, a random generator module 122d, which may include a TRNG and / or a PRNG, and a counter module 122e.

[0024] The security hardening real-time operating system software is itself software and is typically partitioned in memory, or secure storage 121 as shown in the section below in Figure 2. Figure 2 shows diagrammatically the address space of memory 121 of HTA 12 in which the operating system resides, shown collectively with the HOS. -Text or source code TXS: an area of ​​memory that stores the executable code of a program. This block of memory is usually read-only. Data or Data Flash DT: memory area that stores static / global variables initialized by the programmer. This is also a section of memory where OS applications can have private data.

[0025] BSS (Block Started by Symbol) Memory BS: Memory area that stores uninitialized static / global variables. This segment is filled with zeros by the operating system, hence all uninitialized variables are initialized with zero. Heap Memory HP: Heap is used to provide space for dynamic memory allocation.

[0026] Stack SS: This is a section of volatile memory (RAM) 121a into which local variables defined within functions, registers and data related to function calls such as return are pushed during task execution. Each task can have its own stack area.

[0027] The text memory area TXS and the data memory area DT are non-volatile memories 121b, whereas the BBS memory area BS, the heap memory area HP, and the stack SS are volatile memories 121a.

[0028] The security hardened real-time operating system for HTA described herein comprises: a run-time authenticity checking procedure 500 for non-volatile memories, in which the authenticity properties are checked via cryptography; A stack overflow detection procedure 600 for stack SS (volatile memory 121a), in which the amount of used stack SS is checked against a static bound; The system is configured to check the non-volatile and volatile memory through a variety of specific procedures, including:

[0029] The run-time authenticity checking procedure 500 is a hardening technique based on authenticity methods, consisting in maintaining the integrity of the code under control at run-time. It can be performed in parallel with normal system operation, including startup, where the authenticity is verified starting from the trust root, and at other times, with a frequency that may be related to an external event (such as updating a piece of code), or with a predefined periodic mechanism, or taking advantage of the inactivity time of the HTA.

[0030] In this way, a hardened real-time operating system prevents a compromised system from tampering with its own memory contents.

[0031] This hardening technique takes advantage of the fact that the HTA is available as one additional core with full access to the ECU's flash memory, as shown in Figure 1. As a result, the runtime authenticity checking procedure 500 developed simply to check the hardware trust anchor non-volatile memory can be configured to demonstrate the code integrity of the entire flash memory without causing any impact or delay to safety-critical applications running on the host core.

[0032] For this reason, and for the sake of generality of the description, it is assumed herein that the run-time authenticity checking procedure 500 is configured to check the entire flash memory.

[0033] The run-time authenticity checking procedure 500 uses a verification mechanism based on signed SW blocks and certificates.

[0034] As shown in FIG. 3, which shows a schematic representation of the non-volatile memory 111 of the host 11 and the non-volatile memory 121b of the HTA 12, the signed SW block SSB, i.e. the software block with a digital signature providing authenticity and integrity of the data, is stored in the non-volatile memory 111 and 121b of the host 11 and the hardware trust anchor 12, respectively, in particular in the program memory in the flash memory, and the certificate C and, finally, the secure log SL giving information about the detected anomaly as better explained below, are stored in the non-volatile memory 121b in the secure storage 121, which is also used to store all sensitive data (e.g. keys), including, for example, the program flash memory and the data flash memory.

[0035] The signed SW block SSB corresponds to binary data programmed into the flash memory of the hardware trust anchor 12 and ultimately also into the host 11, specifically the ECU.

[0036] There are several signed SW blocks SSB in the ECU. Both the host and HTA have their own non-volatile memories including program flash memory and data flash memory, so the SSB may be distributed in the host and the HSM. The host and HTA run at different times and have different purposes. For example, in the host's flash memory, there is a boot loader BL: a piece of code that runs before any application code. Application APP: a piece of code that runs after the boot loader.

[0037] Calibration CLB: A piece of code that contains essential data for an application to run properly. In the flash memory of the hardware trust anchor. Boot: A piece of code that runs before any operating system runs.

[0038] Application APP: A piece of code that runs after the operating system is running. This piece of code may include a real-time operating system.

[0039] Each signed SW block SSB is associated with some information called metadata, which has two sections: a header SSBH and data SSBD. - The header SSBH field contains information about the block's contents and all cryptographic hashes and signatures, The Data SSBD field is a block of data that is determined to require proof of authenticity and integrity.

[0040] A certificate (or digital certificate) is an encapsulated public key used for communication purposes and to prove ownership and validity. Certificates are signed by a certification authority to convey the authenticity of the certificate's contents.

[0041] The certificate, by way of a non-limiting example, is compliant with X.509v3 certificates and encoded in ASN.1 DER format.

[0042] For example, there may be a root certificate in the HTA that represents the highest certificate from the ECU's point of view and cannot be validated against another certificate. There are certificates for application software running on the host and the host software itself (e.g., boot loader) that represent intermediate certificates from the ECU's point of view and are validated against such a root certificate.

[0043] Generally, the runtime authenticity checking procedures 500 are low priority tasks (i.e., background tasks) implemented in the HTA 12 so as not to interfere with other runtime services required by the host. In particular, the runtime authenticity checking procedures 500 should not exceed the allowed delay in their execution.

[0044] However, it is necessary to detect software manipulation while also avoiding the possibility that an attacker or an overly demanding host 11 requesting a large number of operations from the HTA 12 could prevent the execution of the runtime authenticity check 500. At the same time, it must be avoided that the time to verify the entire flash exceeds a certain value.

[0045] To reconcile these opposing visions, the runtime authenticity check is performed in a periodic task that has the highest priority relative to other host / HTA services, and the check is divided into n stages of configurable duration. A flow diagram illustrating the runtime authenticity check procedure 500 is shown in Figure 4.

[0046] The run-time authenticity check 500 includes identifying, in step 505, signed software blocks SSB and corresponding headers SSBH and data blocks SSBD present for execution in the program memory of said hardware trust anchor 12 and ultimately also in the program memory 111 of the host 11, and performing, in step 510, for each signed software block SSBj (j being the identification index of the signed block from zero to a number N of the identified signed software block SSB), a check of the validity of each certificate C associated with each signed SW block SSB. The check of the validity of each certificate includes that any new certificate to be stored in the HTA 12 must be verified against another certificate stored in the HTA 12, unless it is a self-signed certificate.

[0047] Next, in step 520, the header signature field SSBH of the current signed SW block SSBj, HeaderSignature, is verified, thereby ensuring the authenticity and integrity of the contents of the block's header. This field contains a digital signature from the start of the header over its length.

[0048] Next, the current signed SW block code SSBj block hash is verified in step 530. The file digest field in the header of the current signed SW block code specifies a matching SHA-256 digest calculated over the data block, and the check passes only if the file digest field is equal to a matching SHA-256 digest calculated by a runtime authenticity check over the data block in particular in the cryptographic hardware acceleration module 122, in particular by the hash engine 122a for computing hash values.

[0049] If an anomaly is detected in the checking steps 510, 520 or 530, it is checked in step 550 whether a secure log SL has already been created for the SSB during the check. If not, in step 560 a secure log SL is created in the data memory (non-volatile memory 121b) of the HTA 12 and information about the detected anomaly is written therein, i.e. a secure log record is called, otherwise the already created secure log SL is updated. Generally, if one of these validity checking steps 510, 520, 530 detects an anomaly, writing of the secure log SL information about the detected anomaly is performed.

[0050] 5 shows a time diagram illustrating that parts of an authentication procedure 500 are performed during intervals of duration DR, given a duration DH of the execution of a service requested by the host 11 to the HTA 12. The period T has a length such that it includes the service durations DH of the various host services.

[0051] Thus, as explained immediately above, in one embodiment, a processing system 10 configured to perform trusted operations comprises at least one host computing module 11, including a host processing unit 113 and, for example, volatile and non-volatile host memory means 111, 112, and a hardware trust anchor 12. The hardware trust anchor 12 comprises a respective secure processing unit 123, a hardware processing module 122 dedicated to cryptographic operations, and a secure storage means 121. Here, the hardware trust anchor 12 is configured to store and execute a real-time secure operating system HOS. The real-time secure operating system HOS is configured to perform validity checks on software used in the processing system 10. Said secure operating system is specifically configured to perform a runtime authenticity check 500 that controls the integrity of the software code at runtime. Said run-time authenticity check 500 comprises a step 505 of identifying signed software blocks SSB and corresponding headers SSBH and data blocks SSBD present at least for execution in the program memory, i.e. non-volatile memory 121b, of said hardware trust anchor computing module 12 and ultimately also in the program memory, i.e. non-volatile memory 111, of the host, and a step of performing, for each signed software block SSB, a first step 510 of checking the validity of the certificate C associated with said signed software block SSB, a second step 520 of checking the validity of the header SSBH of said signed software block SSB, a third step 530 of checking the validity of the hash of the data SSBD of said signed software block (SSB), and, if an anomaly is detected by one of such validity checking steps 510, 520, 530, a step of writing secure log SL information regarding the detected anomaly, i.e. a step of creating a secure log SL containing information about the detected anomaly or a step of writing the anomaly in such secure log SL.The secure operating system HOS is configured to perform the above mentioned runtime authenticity check 500 in a task PL that has the highest priority relative to the services of other hosts 11 or hardware trust anchors 12. The processing system 10 also implements a stack overflow detection procedure 600 as mentioned.

[0052] To handle multiple schedulable entities that need to execute simultaneously, operating systems implement multiprocessing. A process (or a task in a secure-hardened real-time operating system) is an independent thread of execution that contains an independent sequence of schedulable code. These entities that make up a secure-hardened real-time operating system can compete independently for CPU execution time, at the expense of performance (time and memory overhead). Each task has its own dedicated area of ​​volatile memory that stores local variables defined within the functional units, registers and data associated with function calls.

[0053] When the scheduler wants to switch from the execution of one task to another, it has to save the context of the old task and load the context of the new task. A task's context is the set of registers that the task uses (program counter, stack pointer, other working registers). In particular, one of these registers (the stack pointer) is a pointer to the stack area currently used. For the correct operation of the system it is essential to ensure that there is no interference between different stack areas. This aspect is important from a security point of view, since stack interferences are notorious for being frequent in vehicles under attack by malicious users.

[0054] Integrity checking of parts of the code and data in non-volatile memory is not always possible as for volatile memory, since the data contained in those parts of memory is continually modified during the execution of the process, it is preferable not to verify the integrity of the data but to check that the memory area used by the process does not exceed pre-established boundaries.

[0055] 6 shows the banked registers R of the secure processing unit 123 and the RAM memory 121a. In the RAM memory 121a, a stack SS is shown, which includes a process stack PSS and a main stack MSS. As is known, a process stack or task stack is typically a pre-reserved area of ​​system memory used for return addresses, procedure arguments, temporary save registers, and locally allocated variables. The processing unit typically includes a register, i.e., a CPU register R, which points to the top of the stack by a stack pointer STP.

[0056] As shown, in the process stack MSS, there is a first stack SSA of the first task TA and a second stack SSB of the second task TB with respective stack sizes TSS, which define corresponding stack ranges in the process stack MSS. As shown, the last part of the stack ranges, e.g. corresponding to the last 8 / 16 bytes, in both the first stack SSA of the first task TA and the second stack SSB of the second task TB represents a stack pattern SP. This will be explained with reference to the flow diagram of FIG. 7.

[0057] During the change of task behavior, the operating system needs a way to keep track of which task is running using a task or scheduler table. In this case, three routines are required: - as shown in Figure 6, a context switch is performed, where the exiting task registers present in the CPU, i.e. the task registers of the first task TA, are saved in the stack area SSA of the first task TA, and then the entering task registers, i.e. the task registers of the second task TB, are reloaded from the stack area SSB of the second task TB in the CPU registers; Initializing the system and updating the state machines and internal structures that constitute the secure real-time operating system; - Jump to the new task, i.e. the second task TB.

[0058] To ensure the integrity of the process and system execution, it is necessary to execute a task overflow control mechanism, namely, stack overflow detection procedure 600. Stack overflow detection procedure 600 also verifies that the bounds of the valid stack region are not overwritten. Stack overflow detection procedure 600 is illustrated in the flow diagram of FIG.

[0059] In step 610, the stacks, eg, SSA, SSB, allocated to a task, eg, TA, TB, are filled with a known pattern, ie, the stack pattern SP at the time the system and the task are initialized.

[0060] Then, during every context switch, the operating system checks (620) the last portion of the valid stack range, e.g., the last 8 / 16 bytes, to ensure that this pattern remains unchanged (not overwritten).

[0061] If test step 620 verifies that none of these bytes at the bottom of the stack have been modified from their original values, then a stack overflow hook function is called in step 630. Such a stack overflow hook function will catch the anomaly and raise an error code (640) as well as log an anomaly event, i.e. the anomaly, similar to step 550, preferably in the same log SL (650), thus making the anomaly apparent to the operating system.

[0062] While procedure 600 catches, i.e., raises, errors and logs anomalies, i.e., most stack overflow occurrences, it is expected that some may be missed, for example, when a stack overflow occurs without the last byte being written.

[0063] The system 10 is also configured to execute a real-time detection procedure 700 to ensure execution within functional time of the HTA 12. Such a procedure 700 monitors task execution and reacts if the time exceeds the allocated time budget (worst case execution time).

[0064] This mechanism controls and run-time authenticity checks verify that on large timescales, integrity analysis has been performed, but on smaller timescales, it verifies that all security functions mapped to HOS tasks have been executed and performed in time.

[0065] During the analysis and design of the system, to ensure that the code executes in real time, a maximum duration (time budget) is assigned to each task to allow the system to schedule the tasks and not violate hard real-time requirements. These execution time verifications are performed in real time by the system during the execution of the tasks, and corrective and logging actions can be taken if a possible violation is detected.

[0066] A periodic task TK, defined between the time it is scheduled to execute and its completion / response time, is defined by three parameters C, D, and T, where C denotes the worst case execution time (WCET) or resource time budget, i.e., computing time, D is the relative deadline, i.e., the deadline time, and T is the period (time period).

[0067] Considering a sporadic task system where there are multiple periods between two successive job instances of the same task, a job occurring at a particular time must be executed at most C time units in the time interval before the corresponding deadline D.

[0068] A particular case of a sporadic task is a periodic task whose period is exactly separated in time between the arrival of two successive jobs generated by the task.

[0069] an absolute deadline system, where for each instance, a deadline D corresponds to a period T; a constrained deadline system, where for each case the deadline D is less than the period T; An arbitrary deadline system, where there is no constraint between the deadline D and the period T; are distinguished.

[0070] The processing system 10 is configured to execute a time detection procedure 700 as described herein with reference to the flow diagram of Fig. 8. Now, no constraint exists between the deadline D and the duration, but a stage 710 is executed of checking violations of the general task TK for the task worst execution time C, where the value of the worst execution time C for the given example is given by an offline time analysis. In stage 720, anomalies are preferably recorded in the same security log SL. From the above explanation, the advantages of the described solution are therefore clear.

[0071] The described system advantageously comprises a secure-hardened real-time operating system, where secure hardening is obtained by performing authenticity checks either on the operating system software or on the application software at run-time. Authenticity checks are performed in real-time, periodically with high priority, and by utilizing dedicated hardware for cryptographic and certificate validation.

[0072] In particular, the system disclosed herein performs the authentication procedure in a periodic task that has the highest priority over other host / HTA services, thus preventing an attacker or an overly demanding host that requests a large number of actions from the HTA from preventing the execution of the runtime authenticity check and detecting software tampering, while at the same time preventing the time to verify the entire flash from exceeding a predetermined value.

[0073] Naturally, details of construction and embodiments may be widely modified from those described and illustrated herein, purely by way of example, without affecting the principles of the embodiments and without departing from the scope of the present embodiments as defined in the following claims.

Claims

1. 1. A processing system configured to perform trusted operations, comprising at least one host computing module including a host processing unit and a host memory means, and a hardware trust anchor, the hardware trust anchor comprising a respective secure processing unit, a hardware processing module dedicated to cryptographic operations, and secure storage means, the hardware trust anchor configured to store and execute a real-time secure operating system (HOS), the real-time secure operating system (HOS) configured to perform validity checks on software used in the processing system, The real-time secure operating system (HOS) is configured to perform a runtime authenticity check to control the integrity of software code at runtime, the runtime authenticity check identifying at least a signed software block (SSB) and corresponding header (SSBH) and data block (SSBD) present in a program memory of the hardware trust anchor for execution; a first step of checking the validity of a certificate (C) associated with said signed software block (SSB), a second step of checking the validity of a header (SSBH) of the signed software block (SBB); A third step of checking the validity of a hash of the Signed Software Block (SSB) data (SSBD); and if an anomaly is detected by one of the validity checks, writing information about the detected anomaly to a secure log (SL); Including, The system, wherein the real-time secure operating system (HOS) is configured to perform the runtime authenticity check in a task that has highest priority (PL) relative to the services of other host computing modules or hardware trust anchors.

2. The system of claim 1 , wherein the runtime authenticity check is also applied to the signed software block (SSB) residing in a non-volatile memory of the host computing module.

3. 3. The system of claim 1 or 2, wherein the real-time secure operating system (HOS) is configured to perform the runtime authenticity check in a periodic task (PL) having a given period (T) that is given top priority over the services of other host computing modules or hardware trust anchors, and the checking step is divided into multiple sub-steps of configurable duration (DH) that are executed during each period (T).

4. 2. The system of claim 1, wherein the first stage of checking the validity of a certificate (C) associated with the signed software block (SSB) includes verifying any new certificate to be stored in the hardware trust anchor against another certificate stored in the hardware trust anchor, unless the new certificate is a self-signed certificate.

5. 2. The system of claim 1, wherein the second step of checking the validity of a header (SSBH) of the signed software block (SSB) includes verifying a header signature field of the current signed software block (SBB).

6. 2. The system of claim 1, wherein the third step of checking the validity of the hash of the data (SSBD) of the signed software block (SSB) comprises: calculating, in particular by a hash engine, a hash value over the data block (SSBD) in a cryptographic hardware acceleration module; and comparing the hash value with the contents of a field in a header (SSBH) that stores a hash value defining a matching digest calculated over the data block.

7. 2. The system of claim 1, wherein the real-time secure operating system is configured to perform a stack overflow detection procedure for a stack (SS) of the hardware trust anchor volatile memory used for task execution, the stack overflow detection procedure including checking an amount of stack (SS) used against a static bound.

8. 2. The system of claim 1, wherein the real-time secure operating system is configured to perform a real-time detection procedure including: checking for violations of a task worst-case execution time (C), the value of the task worst-case execution time (C) for a given instance of the task being given by an offline time analysis; and, if an anomaly is detected by the checking step, writing information about the detected anomaly to a secure log (SL).

9. The system of claim 1 , wherein the at least one host computing module and the hardware trust anchor are part of a system on a chip, and in particular the at least one host computing module is an ECU operating in a vehicle.

10. 2. The system of claim 1, wherein the step of writing information regarding the detected anomaly to the secure log (SL) includes creating a secure log (SL) including information regarding the detected anomaly or writing the anomaly within the secure log (SL).

11. 11. A method of performing trusted operations in a processing system, comprising storing and executing a real-time secure operating system (HOS) that performs validity checks on software used in the processing system according to any one of claims 1 to 10, the method comprising the steps of performing a run-time authenticity check to control the integrity of software code at run-time, the run-time authenticity check identifying at least a signed software block (SSB) and corresponding header (SSBH) and data block (SSBD) present in a program memory of the hardware trust anchor for execution; For each Signed Software Block (SSB), a first step of checking the validity of a certificate (C) associated with said signed software block (SSB), a second step of checking the validity of a header (SSBH) of the signed software block (SBB); A third step of checking the validity of a hash of the Signed Software Block (SSB) data (SSBD); and if an anomaly is detected by one of the validity checks, writing information about the detected anomaly to a secure log (SL); Including, The method of claim 1, wherein the real-time secure operating system is configured to perform the runtime authenticity check in a highest priority task (PL) relative to the services of other host computing modules or a hardware trust anchor.

12. The method according to claim 11, wherein the method comprises the operation of a system according to any one of claims 2 to 10.

Images