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

Description

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 at least one host module and a hardware trust anchor is preferably part of a system-on-chip, particularly when said at least one host module is an ECU operating in a vehicle.

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.

In a typical automotive scenario, a processing system such as an Electronic Control Unit (ECU) is based on one or more SoCs (System on Chip) 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.).

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.

As such, these protection techniques are designed to more effectively detect and respond to attacks and limit the ability of those attacks to execute exploits.

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:

Therefore, as a result, security hardening real-time operating systems are
- Perform multiple secure operations simultaneously;
Switching between different entities (processes or tasks) according to some predefined logic and scheduling policies;
- Guarantee and maintain confidentiality (information isolation);
Ensuring that common functions are performed and their execution time is known,
It should be possible.

The security-hardened real-time operating system used for HTA may be a static and unmodifiable operating environment. This means 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.

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.

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.

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 computation of a cryptographic signature over the non-volatile software data. The signature may be supplied by either the OEM or the ECU supplier.

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 operations. The above method can also be used to check validity information at runtime.

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

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

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.

The claims form an integral part of the technical teachings provided herein in connection with the various embodiments.

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, the hardware trust anchor comprising a respective secure processing unit, a hardware processing module dedicated to cryptographic operations, and a secure storage means, the hardware trust anchor being configured to store and execute a real-time secure operating system, the real-time secure operating system being configured to perform a validity check on software used in the processing system, the real-time secure operating system being configured to perform a run-time authenticity check that controls the integrity of the software code at run-time, the run-time authenticity check being performed by at least one of the processors of the hardware trust anchor for execution. The system includes a step of identifying signed software blocks and corresponding headers and data blocks present in the program memory of the host computing module and ultimately present 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 the header of the signed software block, and a third step of checking the validity of a hash of the 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 check in a task that has the highest priority over the services of other host computing modules or hardware trust anchors.

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 a step 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 that are also ultimately present in the program memory of the host computing module, and for each signed software block, a first step of checking the validity of a certificate associated with the signed software block, a second step of checking the validity of the header of the signed software block, a third step of checking the validity of a hash of the data of the signed software block, and if an anomaly is detected by one of the checking steps of the validity checks, a step of writing secure log information regarding the detected anomaly, the real-time secure operating system being configured to perform the run-time authenticity check in a task that has the highest priority with respect to the services of other host computing modules or hardware trust anchors.

Embodiments will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which:
FIG. 1 illustrates a schematic diagram of one embodiment of a processing system disclosed herein. FIG. 2 is a schematic diagram illustrating the address space of a memory used by the processing system disclosed herein; FIG. 2 illustrates a schematic representation of memory areas of a memory used by the processing system disclosed herein; FIG. 2 is a flow diagram of an authenticity checking procedure implemented by the processing system disclosed herein. FIG. 2 is a timing diagram illustrating several phases of operation of the processing system disclosed herein. FIG. 2 is a block diagram of a stack of memories of the processing system disclosed herein. FIG. 1 is a flow diagram of a stack overflow control procedure implemented by the processing system disclosed herein. FIG. 2 is a flow diagram of a detection procedure implemented by the processing system disclosed herein.

The following description describes 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, and the like. 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.

In the context 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. Moreover, particular features, structures, or characteristics may be combined as appropriate in one or more embodiments.

The reference signs used in this specification are intended merely for convenience and therefore do not define the scope of protection or the scope of the embodiments.

1 shows a processing system 10, which may correspond to, for example, 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., an application core 11, and a hardware trust anchor (HTA) 12. The application core 11 includes a non-volatile memory 111, a RAM memory 112, a bus interface 114 for communicating with, for example, a vehicle bus, and an application CPU 113. The HTA 12 includes a secure storage 121 including a secure non-volatile memory 121b and a secure RAM memory 121a. The HTA 12 further includes 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 executing a symmetric cryptographic algorithm, an asymmetric cryptographic engine 122c for executing an asymmetric cryptographic algorithm, a random generator module 122d that may include a TRNG and/or a PRNG, and a counter module 122e.

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 following section in Figure 2. Figure 2 shows diagrammatically the address space of memory 121 of the HTA 12 in which the operating systems reside, 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.

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, thus all uninitialized variables are initialized with zeros. Heap Memory HP: The heap is used to provide space for dynamic memory allocation.

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.

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

The security hardened real-time operating system for the HTA described herein comprises:
- a run-time authenticity checking procedure 500 for non-volatile memories, where the authenticity properties are checked via cryptography;
- a stack overflow detection procedure 600 for stack SS (volatile memory 121a), in which the amount of stack SS used 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:

The run-time authenticity checking procedure 500 is a hardening technique based on the authenticity method, consisting in maintaining the integrity of the code under control at run-time. It is performed in parallel with the 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.

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

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

For this reason, and to generalize the description, it is assumed herein that the runtime authenticity checking procedure 500 is configured to check the entire flash memory.

The runtime authenticity check procedure 500 uses a verification mechanism based on signed SW blocks and certificates.

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 the digital signature providing the 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, which gives 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.

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

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 HSM. The host and HTA run at different times and have different purposes. For example, in the host's flash memory: 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.

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.

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.

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 has been determined to require proof of authenticity and integrity.

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.

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

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., the boot loader) that represent intermediate certificates from the ECU's point of view and are validated against such a root certificate.

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 for their execution.

However, it is necessary to prevent the possibility that an attacker who requests a large number of operations from the HTA 12 or an overly demanding host 11 may prevent the execution of the runtime authenticity check 500, and to detect software manipulation. At the same time, it must be prevented that the time to verify the entire flash exceeds a certain value.

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. Figure 4 shows a flow diagram illustrating the runtime authenticity check procedure 500.

The run-time authenticity check 500 includes identifying, in step 505, the signed software blocks SSB and corresponding headers SSBH and data blocks SSBD present in the program memory of the hardware trust anchor 12 for execution and, ultimately, in the program memory 111 of the host 11, and performing, in step 510, for each signed software block SSBj (j being the signed block identification index from zero to the 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.

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.

Next, in step 530, the current signed SW block code SSBj block hash is verified. 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 the matching SHA-256 digest calculated by the runtime authenticity check over the data block in the cryptographic hardware acceleration module 122, in particular by the hash engine 122a for computing the hash value.

If an anomaly is detected in the checking steps 510, 520 or 530, then in step 550 it is checked 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. In general, 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.

In FIG. 5, a time diagram is shown showing that, given a duration DH of the execution of a service requested by the host 11 to the HTA 12, a portion of the authentication procedure 500 is executed during an interval of duration DR. The period T has a length such that it includes the service durations DH of the various host services.

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 includes 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. The 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 performing, for each signed software block SSB, a first step 510 of checking the validity of a certificate C associated with said signed software block SSB, a second step 520 of checking the validity of a header SSBH of said signed software block SSB, a third step 530 of checking the validity of a 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. creating a secure log SL including information regarding the detected anomaly or 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 over 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.

To handle multiple schedulable entities that need to execute simultaneously, operating systems implement multiprocessing. A process (or 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.

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. The context of a task is the set of registers used by the task (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.

Checking the integrity 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 continuously 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.

Figure 6 shows the bank registers R of the secure processing unit 123 and the RAM memory 121a. Within the RAM memory 121a, stacks SS are shown, including 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, the CPU register R, that points to the top of the stack via a stack pointer STP.

As shown, within the process stack MSS there is a first stack SSA of a first task TA and a second stack SSB of a second task TB with respective stack sizes TSS, which define corresponding stack ranges within 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 the stack pattern SP. This will be explained with reference to the flow diagram of FIG. 7.

During the change of task activity, the operating system needs a way to keep track of which task is running using the 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, ie the second task TB.

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

At step 610, the stacks, e.g., SSA, SSB, allocated to the tasks, e.g., TA, TB, are filled with a known pattern, i.e., the stack pattern SP at the time the system and tasks were initialized.

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).

If test step 620 verifies that none of the bytes at the end of these stacks 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, preferably in the same log SL (650) as in step 550, making the anomaly clear to the operating system.

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

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

This mechanism control and run-time authenticity check verifies that on large timescales an 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.

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

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 duration (time period).

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.

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.

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

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 logged in the same security log SL. Thus, from the above explanation, the advantages of the described solution are clear.

The described system advantageously comprises a secure-hardened real-time operating system, where secure hardening is obtained by performing authenticity checks on either 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.

In particular, the system disclosed herein performs the authentication procedure in a periodic task that has the highest priority over the services of other hosts/HTAs, thereby avoiding the possibility that an attacker or an overly demanding host that requests a large number of operations from the HTA could prevent the execution of the runtime authenticity check, and also detecting software tampering. At the same time, it is avoided that the time to verify the entire flash exceeds a predetermined value.

Naturally, the details of construction and the embodiments may be widely varied from those described and illustrated herein, merely 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 (12)

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. The system of claim 1, wherein the run-time authenticity check is also applied to the signed software block (SSB) residing in a non-volatile memory of the host computing module. 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 stage is divided into multiple sub-stages of configurable duration (DH) that are performed during each period (T). 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. The system of claim 1, wherein the second step of checking the validity of the header (SSBH) of the signed software block (SSB) includes verifying a header signature field of the current signed software block (SBB). 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) includes a step of calculating, in particular by a hash engine, a hash value over the data block (SSBD) in a cryptographic hardware acceleration module, and a step of 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. 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 volatile memory of the hardware trust anchor used to execute a task, the stack overflow detection procedure including checking an amount of stack (SS) used against a static bound. The system of claim 1, wherein the real-time secure operating system is configured to perform a real-time detection procedure including a step of 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 a step of writing information about the detected anomaly in a secure log (SL) if the checking step detects an anomaly. The system of claim 1, wherein the at least one host computing module and the hardware trust anchor are part of a system on chip, and in particular, the at least one host computing module is an ECU operating in a vehicle. The system of claim 1, wherein the step of writing information about the detected anomaly to the secure log (SL) includes a step of creating a secure log (SL) including information about the detected anomaly, or a step of writing the anomaly in the secure log (SL). 11. A method of performing trusted operations in a processing system, comprising storing and executing a real-time secure operating system (HOS) for performing 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 for controlling 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. 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