Processing system including trust anchor computing instrument and corresponding method

Abstract

The present invention relates to a processing system configured to perform trusted operations. The processing system includes at least one host computing module and a hardware trust anchor. The host computing module includes a host processing unit and a host memory device. The hardware trust anchor includes a corresponding security processing unit, a hardware processing module dedicated to cryptographic operations, and a secure storage device. The hardware trust anchor is configured to store and run a real-time secure operating system. The secure operating system is configured to perform validity verification on software used in the processing system.

Description

Technical Field

[0001] This specification relates to a processing system configured for trusted operation, comprising at least one host computing module and a hardware trust anchor, the host computing module comprising a host processing unit and a host memory device. Preferably, the processing system with the at least one host module and the hardware trust anchor is part of a system-on-chip, and more particularly, the at least one host module is an ECU operating in a vehicle. Background Art

[0002] A hardware trust anchor (HTA) is a local and isolated computing device that starts the chain of trust and performs system-critical and security functions, including active monitoring of process startup and shutdown when tampering is detected.

[0003] In typical automotive scenarios, processing systems such as electronic control units (ECUs) are based on one or more SoCs (systems on chips), consisting of an application processing unit (i.e., application core) for vehicle functions and a hardware trust anchor (HTA) for security support. To harden ECUs against external attacks (unauthorized activation of vehicle features, access to sensitive key material, manipulation of software, and other such attacks), hardware trust anchor (HTA) technology is used.

[0004] The HTA may include a processing unit that utilizes a real-time operating system (RTOS) that embeds a set of mechanisms for strengthening the basic security of the HTA side, so the system is called a security-hardened RTOS. In computing, hardening is generally the process of protecting a system by reducing its surface area of ​​vulnerability.

[0005] Therefore, these protection technologies are configured to more effectively detect / react to attacks, as well as limit their ability to perform exploits.

[0006] HTAs are employed for security operations involving confidential and sensitive information, such as:

[0007] • Key management;

[0008] • Certificate management;

[0009] • Cryptographic operations;

[0010] • Software protection (secure boot and secure updates);

[0011] • Data protection (secure storage and secure communication), using access mechanisms for reading and writing sensitive data and encryption techniques to reduce data visibility;

[0012] Therefore, a security-hardened RTOS should be able to:

[0013] • Conduct multiple security operations simultaneously;

[0014] • Switching between various entities (processes or tasks) according to some predefined logic and scheduling policy;

[0015] • Ensure and maintain confidentiality (information isolation)

[0016] • Ensure common functions are executed and know when they are executed

[0017] The security-hardened real-time operating system used for HTAs is likely to be a static, unmodifiable operating environment. This means that application objects, tasks, and event resources cannot be created or deleted during application execution. The correctness (integrity) of data and other memory components should be a fundamental requirement for secure systems.

[0018] Today, most automotive ECUs support software downloads, allowing applications or data to be updated at any time. Depending on the OEM's requirements, some checks are performed during the software download process to ensure the new software is valid, some checks are performed during the ECU power-up to ensure the software is still valid, or a combination of both.

[0019] There are various methods for processing validity information.

[0020] For example, integrity checks, often required for security reasons, can be provided based on a checksum / CRC (Cyclic Redundancy Check) calculated on non-volatile software data and compared with a reference value. If the checksum is correct, the integrity of the complete software block is assumed. Incidentally, checksum algorithms like CRC do not provide authenticity checks, as no secret parameters are involved during the checksum calculation.

[0021] Conversely, some ECUs require this type of authenticity verification, as they require that only software or data from legitimate sources be used on the ECU (for example, in safety-related ECUs or as a tuning protection). This authentication is typically performed by calculating a cryptographic signature on the non-volatile software data. This signature can be provided by the OEM or the ECU supplier.

[0022] The signature calculation algorithm combines a hash calculation with hardware-based cryptographic routines (such as those performed in modules 122a-122e) or software-based cryptographic 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 the modules, the calculation is performed in software and no special hardware is required to perform the cryptographic operations.

[0023] The above method can also be used to verify validity information at runtime.

[0024] Currently, only integrity checking is used at runtime to meet safety requirements, but this still makes it impossible to detect manipulation on the original ECU during normal operation of the ECU itself. Summary of the Invention

[0025] It is an object of one or more embodiments to overcome limitations inherent in solutions available in the prior art.

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

[0027] The claims form an integral part of the technical teachings provided herein relating to the various embodiments.

[0028] According to the solution described herein, the solution relates to a processing system configured to perform trusted operations, the processing system including at least one host computing module and a hardware trust anchor, the host computing module including a host processing unit and a host memory device, the hardware trust anchor including a corresponding security processing unit, a hardware processing module dedicated to cryptographic operations, and a secure storage device, the hardware trust anchor configured to store and run a real-time secure operating system, the secure operating system configured to perform validity verification on software used in the processing system.

[0029] The secure operating system is configured to perform runtime authenticity checking to control the integrity of software code at runtime, wherein the runtime authenticity checking includes identifying signed software blocks and corresponding header and data blocks, the signed software blocks and corresponding header and data blocks being present at least in the program memory of the hardware trust anchor for execution and ultimately also in the program memory of the host; and for each signed software block, performing:

[0030] The first step is to verify the validity of the certificate associated with the signed software block,

[0031] The second step is to verify the validity of the header of the signed software block.

[0032] The third step is to verify the validity of the hash of the data of the signed software block, and

[0033] If one of the validation steps of the validity check detects an anomaly, information about the detected anomaly is written in the security log,

[0034] The secure operating system is configured to run the runtime authenticity check in a task with the highest priority relative to other host or hardware trust anchor services.

[0035] The solution described herein is also directed to a corresponding method for performing trusted operations in the above-mentioned processing system, including storing and running a real-time secure operating system for validating the software used in the processing system, the method comprising:

[0036] Performing runtime authenticity checking to control the integrity of the software code at runtime, the runtime authenticity checking comprising identifying signed software blocks and corresponding headers and data block headers present in the program memory of the hardware trust anchor for execution and ultimately also in the program memory of the host; and performing, for each signed software block:

[0037] The first step is to verify the validity of the certificate associated with the signed software block,

[0038] The second step is to verify the validity of the header of the signed software block.

[0039] The third step is to verify the validity of the hash of the data of the signed software block, and

[0040] If one of the validation steps of the validity check detects an anomaly, information about the detected anomaly is written to the security log.

[0041] The secure operating system is configured to run the runtime authenticity check in a task with the highest priority relative to other host modules or hardware trust anchor services. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Embodiments will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which:

[0043] - Figure 1 schematically illustrates an embodiment of a processing system disclosed herein;

[0044] - Figure 2 Schematically illustrates the address space of the memory used by the processing system disclosed herein;

[0045] - Figure 3 schematically illustrates memory areas of a memory used by the processing system disclosed herein;

[0046] - Figure 4 a flow chart representing an authenticity verification process implemented by the processing system disclosed herein;

[0047] - Figure 5 represents a timing diagram showing stages of operation of the processing system disclosed herein;

[0048] - Figure 6A block diagram representing a stack of memories of the processing system disclosed herein;

[0049] - Figure 7 A flow chart representing a stack overflow control process implemented by the processing system disclosed herein.

[0050] - Figure 8 A flow chart representing a detection process implemented by the processing system disclosed herein. DETAILED DESCRIPTION

[0051] The following description shows various specific details intended to provide a deeper understanding of the embodiments. The embodiments may be implemented without one or more of the specific details, or with other methods, components, materials, etc. In other cases, well-known structures, materials, or operations are not shown or described in detail so that aspects of the embodiments are not obscured.

[0052] References to "an embodiment" or "one embodiment" throughout this specification are intended to indicate that a particular configuration, structure, or feature described in connection with that embodiment is included in at least one embodiment. Similarly, phrases such as "in an embodiment" or "in one embodiment" that may appear in various aspects of this specification do not necessarily refer to the same embodiment. Furthermore, particular configurations, structures, or features may be appropriately combined in one or more embodiments.

[0053] References used herein are for convenience only and therefore do not limit the scope of protection or the scope of the embodiments.

[0054] exist Figure 1FIGURE 1 illustrates a processing system 10, which may correspond to an ECU on a system-on-chip (SoC) for automotive applications (e.g., in a vehicle's engine or other control system). The system 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 (e.g., for communicating with a vehicle bus), and an application CPU 113. HTA 12 includes secure memory 121, which includes secure non-volatile memory 121b and secure RAM memory 121a. HTA 12 also includes a security processing unit 123, an HTA interface module 124, and a cryptographic hardware acceleration module 122. Cryptographic hardware acceleration module 122 may include a hash engine 122a for calculating hash values ​​for software data, a symmetric cryptographic engine 122b for performing symmetric cryptographic algorithms, an asymmetric cryptographic engine 122c for performing asymmetric cryptographic algorithms, a random generator module 122d, which may include a TRNG and / or PRNGS, and a counter module 122d.

[0055] like Figure 2 As shown in the following section, the security-hardened real-time operating system software (which is itself software) is typically split in memory (i.e., secure memory 121). The diagram schematically shows the address space of the memory 121 of the HTA 12, where the operating system represented together with the HOS exists:

[0056] - Text or source code TXS: A memory area that stores the executable code of a program. This memory block is usually read-only.

[0057] - Data or Data Flash DT: Memory area that stores static / global variables initialized by the programmer. This is also the memory section where OS-Applications can have private data.

[0058] BSS (Block Starting with Symbol) memory BS: Memory area that stores uninitialized static / global variables. This segment will be filled with zeros by the operating system, so all uninitialized variables will be initialized with zeros.

[0059] Heap memory HP: The heap is used to provide space for dynamic memory allocation.

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

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

[0062] The security-hardened RTOS for HTA described here is configured to verify non-volatile and volatile memory through various specific procedures, including:

[0063] - A runtime authenticity verification process 500 for non-volatile memory, wherein authenticity attributes are verified cryptographically;

[0064] - A stack overflow detection process 600 for the stack SS (volatile memory 121 a ), wherein the amount of used stack SS is checked against static boundaries.

[0065] The runtime authenticity verification process 500 is a hardening technique based on an authenticity approach that involves maintaining code integrity under control at runtime. This is performed in parallel with normal system operations, including startup, where authenticity is verified from a root of trust, and at other times, with a frequency associated with external events (such as updating a portion of code) or a predefined periodic mechanism, or by utilizing HTA inactivity.

[0066] In this way, the hardened RTOS prevents a compromised system from using its own memory contents for deception.

[0067] The advantages of this strengthening technology are that, e.g. Figure 1 As shown, the HTA is provided as another core with full access to the ECU's flash memory. As a result, the runtime authenticity verification process 500, which was developed to verify only the hardware trust anchor non-volatile memory, can be configured to verify the code integrity of the entire flash memory without causing any impact or delay to safety-critical applications executing on the host core.

[0068] For this reason, and to simplify its description, it is assumed herein that the runtime authenticity check process 500 is configured to check the entire flash memory.

[0069] The runtime authenticity verification process 500 uses a verification mechanism based on signed SW blocks and certificates.

[0070] like Figure 3As shown, the non-volatile memory 111 of the host 11 and the non-volatile memory 121b of the HTA 12 are schematically shown, and the signed SW blocks SSB (i.e., software blocks to which a digital signature is applied to provide data authenticity and integrity) are stored in the program memory (particularly in flash memory) in the non-volatile memories 111 and 121b of the hardware trust anchor 12 and the host 11, respectively, while the certificate C and eventually the security log SL (which provides information about the detected anomalies), as better explained below, are stored in the non-volatile memory 121b in the secure memory 121. The non-volatile memory 121b includes, for example, a program flash memory and a data flash memory. The non-volatile memory 121b is also used to store all sensitive data (e.g., keys).

[0071] The signed SW block SSB corresponds to binary data that is programmed into the flash memory of the hardware trust anchor 12 and eventually also into the host 11 , in particular the ECU.

[0072] The ECU contains several signed SW blocks (SSBs). Since both the host and HTA have their own non-volatile memory, including program flash and data flash, the SSBs can be distributed across the host and HSM. They execute at different times and have different purposes. For example, in the host's flash:

[0073] Bootloader BL: is a piece of code that runs before any application code;

[0074] Application APP: is a piece of code that runs after the boot loader;

[0075] Calibration CLB: is a piece of code that contains the data necessary for the application to work properly.

[0076] In the flash memory of the hardware trust anchor:

[0077] Boot: is a piece of code that runs before any operating system runs;

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

[0079] Each signed SW block SSB is associated with some information (called metadata) which has two parts, a header SSBH and data SSBD:

[0080] - The header SSBH field contains information about the block contents and all cryptographic hashes and signatures;

[0081] - The Data SSSBD field is a data block that has been identified as requiring proof of authenticity and integrity.

[0082] A certificate (or digital certificate) is a packaging of a public key used for communication purposes to prove ownership and validity. It is signed by a certificate authority to convey confidence in the certificate's contents.

[0083] The certificate, by way of non-limiting example, conforms to an X.509v3 certificate and is encoded in ASN.1 DER format.

[0084] For example, a root certificate can exist in an HTA. This root certificate represents the highest certificate from the ECU's perspective and cannot be validated against another certificate. Certificates for application software running in the host and certificates for the host software itself (e.g., the bootloader) exist. These certificates represent intermediate certificates from the ECU's perspective and are validated against this root certificate.

[0085] Typically, the runtime authenticity check process 500 is a low priority task (ie, a background task) implemented in the HTA 12 so as not to interfere with other runtime services required by the host. In particular, the allowed delay in their execution should not be exceeded.

[0086] However, it must also be avoided that an overly demanding host 11 or attacker requiring a large number of operations from the HTA 12 could prevent the runtime authenticity check 500 from running and detecting software tampering. It must also be avoided that the time to verify the entire flash memory exceeds a predefined value.

[0087] To merge these opposing visions, runtime authenticity checks are run in a periodic task with the highest priority relative to other host / HTA services, and the checks are divided into n steps of configurable duration.

[0088] exist Figure 4 , a flow chart representing a runtime authenticity checking process 500 is shown.

[0089] The runtime authenticity check 500 comprises identifying, in step 505, a signed software block SSB and a corresponding header SSBH and data block (SSBD), and for each signed software block SSBj present in the program memory of the hardware trust anchor 12 for execution and ultimately also in the program memory 111 of the host 11, where j is the identification index of the signed block (from zero to the number N of the identified signed software block SSB), verifying, in step 510, the validity of each certificate C associated with each signed software block SSB. This verification of the validity of each certificate involves the fact that any new certificate to be stored in the HTA 12 must be verified as another certificate stored in the HTA 12, unless it is a self-signed certificate.

[0090] Then, in step 520, the header signature field SSBH of the currently signed SW block SSBj, i.e., the HeaderSignature, is verified, which guarantees the authenticity and integrity of the contents of the header of the block. This field contains a digital signature from the beginning of the header through the length.

[0091] Then, in step 530, the hash of the current signed SW block code SSBj block is verified:

[0092] The header of the current signed SW block code File Digest The field defines the qualified SHA-256 digest computed on the data block;

[0093] The check passes only when the file digest field is equal to the qualified SHA-256 digest calculated by the runtime authenticity check on the data block (particularly in the cryptographic hardware acceleration module 122, particularly by the hash engine 122a).

[0094] If an anomaly is detected in verification steps 510, 520, or 530, a check is performed in step 550 to determine whether a security log SL has already been created for the SSB being verified. If step 560 is negative, a security log SL is created in the HTA 12's data memory (non-volatile memory 121b) and information about the detected anomaly is written therein, i.e., the security log is invoked. Otherwise, the already created security log SL is updated. Generally, if an anomaly is detected in one of these validity verification steps 510, 520, or 530, information about the detected anomaly is written to the security log SL.

[0095] exist Figure 5 A time diagram is shown in which, given a duration DH for performing the services required by the host 11 to the HTA 12, a part of the authentication process 500 is performed with a period T within an interval of duration DR, the period T having a length such that the service duration DH of the different host services is included.

[0096] Therefore, as described above, in an embodiment, a processing system 10 configured to perform trusted operations includes at least one host computing module 11 and a hardware trust anchor 12. The host computing module 11 includes a host processing unit 113 and host storage devices 111 and 112 (e.g., volatile and non-volatile). The hardware trust anchor 12 includes a corresponding security processing unit 123, a hardware processing module 122 dedicated to cryptographic operations, and a secure storage device 121. The hardware trust anchor 12 is configured to store and run a real-time secure operating system HOS, which is configured to perform validity verification on software used in the processing system 10. The secure operating system is specifically configured to perform runtime authenticity verification 500 to control the integrity of software code at runtime. The runtime authenticity verification 500 includes:

[0097] At least the signed software blocks SSB and the corresponding headers SSBH and data blocks SSBD present in the program memory (i.e., the non-volatile memory 121 b ) of the hardware trust anchor computation module 12 for execution and eventually also in the program memory (i.e., the non-volatile memory 111 ) of the host are identified 505 and for each signed software block SSB:

[0098] A first step 510 is to verify the validity of the certificate C associated with the signed software block SSB.

[0099] The second step 520 is to verify the validity of the header SSBH of the signed software block SSB.

[0100] The third step 530 is to verify the validity of the hash of the data SSBD of the signed software block (SSB), and

[0101] If one of such verification steps 510, 520, 530 of validity detects an anomaly, information about the detected anomaly is written to the security log SL, i.e. a security log SL is created comprising information about the detected anomaly, or an anomaly is written in such a security log SL,

[0102] The secure operating system HOS is configured to run the runtime authenticity check 500 in a task with the highest priority PL relative to other host 11 or hardware trust anchor 12 services.

[0103] As mentioned, processing system 10 also implements stack overflow detection process 600 .

[0104] To handle the need for multiple schedulable entities to run simultaneously, operating systems implement multiprocessing. A process (or task in a safety-hardened RTOS) is an independent thread of execution, containing a sequence of independently schedulable code. These entities can independently compete for CPU execution time, at the expense of performance (time and memory overhead). Each task has its own dedicated area of ​​volatile memory, where it stores local variables and registers defined within the function, as well as data associated with the function call.

[0105] When the scheduler switches from running one task to another, it must save the contents of the old task and load the contents of the new one. The contents of a task are the set of registers used by the task (program counter, stack pointer, and other working registers). In particular, one of these registers (the stack pointer) points to the currently used stack area. Ensuring that there is no interference between different stack areas is essential for proper system operation. This aspect is important from a security perspective, as stack interference is a well-known attack vector commonly used by malicious users.

[0106] Integrity verification of code and data sections in non-volatile memory is not always possible with respect to volatile memory. The data contained in these sections of memory is constantly modified during the execution of a process, so instead of verifying the integrity of the data, it is preferable to verify that the memory area used by the process does not exceed pre-determined boundaries.

[0107] exist Figure 6 1 shows a bank of registers R and RAM memory 121a of the security processing unit 123. RAM memory 121a shows a stack SS including a process stack PSS and a main stack MSS. As is well known, a process stack or task stack is typically a pre-reserved area of ​​system memory used for return addresses, process parameters, temporarily saved registers, and locally allocated variables. A processing unit typically includes registers, namely CPU registers R, which point to the top of the stack via a stack pointer STP.

[0108] As shown in the figure, the stack MSS in the process is a first stack SSA of the first task TA and a second stack SSB of the second task TB, which have their own stack sizes TSS, which define the corresponding stack ranges within the process stack MSS. As shown in the figure, the last part of the stack range (e.g., corresponding to the last 8 / 16 bytes) in the first stack SSA of the first task TA and the second stack SSB of the second task TB presents the stack pattern SP, which will be referred to in the process. Figure 7 Provide explanation.

[0109] During the change task operation, the operating system needs a way to keep track of the tasks in progress using a task or scheduler table. Three routines are then needed:

[0110] - Execute as Figure 6 The content switching shown is to save the output task register (i.e., the output task register of the first task TA) in the CPU to the stack area SSA of the first task TA, and then reload the input task register (i.e., the input task register of the second task TB) from the stack area SSB of the second task TB in the CPU register.

[0111] - Initialize the system, update the state machine and internal structures that make up the secure real-time operating system;

[0112] - Jump to the new task, the second task TB.

[0113] In order to ensure the integrity of process and system execution, it is necessary to implement a task overflow control mechanism, namely the stack overflow detection process 600, which also verifies that the limit of the valid stack area is not overwritten, and its Figure 7 The flowchart is shown in FIG.

[0114] In step 610 , the stack (eg, SSA, SSB) allocated to the task (eg, TA, TB) is filled with a known pattern, ie, the stack pattern SP when the system and tasks are initialized.

[0115] Then, during each context switch, the operating system checks 620 the last part within the valid stack range, eg the last 8 / 16 bytes, to ensure that the pattern remains unmodified (not overwritten).

[0116] If it is verified in the test step 620 that any of these stack last part bytes have been changed from their original value, a stack overflow hook function is called in a step 630. This stack overflow hook function intercepts the exception and makes it apparent to the operating system so that an error code 640 is raised and the exception event is logged, i.e., an exception 650 similar to step 550, preferably in the same log SL.

[0117] Program 600 catches (ie, raises an error and logs the exception) most stack overflow occurrences, although it is conceivable that some may be missed, such as where a stack overflow occurs and the last byte is not written.

[0118] The system 10 is also configured to perform a real-time detection process 700 to ensure timely execution of HTA 12 functions: such a process 700 monitors task execution and reacts if the time exceeds the allocated time budget (worst case execution time).

[0119] This mechanism control and runtime authenticity check verifies the integrity analysis that has been performed on a larger time scale and, on a smaller time scale, promptly executes and executes all safety functions mapped to the HOS tasks.

[0120] To guarantee real-time execution of the code, a maximum duration (time budget) has been assigned to each task during the analysis and design of the system to enable the system to schedule tasks and not violate hard real-time requirements. Verification of these execution times is performed by the system in real-time during task execution and possible violations are detected and may result in corrective and logging actions.

[0121] A periodic task TK (defined between the time it is scheduled to run and its completion / response time) is defined by a set of three parameters C, D, T, where C represents the worst-case execution time (WCET) or resource time budget, i.e., computation time, D is the relative deadline, i.e., deadline time, and T is the period (time period).

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

[0123] A special case of sporadic tasks is a periodic task, for which the period is the exact time separation between the arrival of two consecutive jobs generated by the task.

[0124] The difference is:

[0125] implicit deadline system, in which for each instance, a deadline D corresponds to a period T;

[0126] constrained deadline a system in which, for every instance, the deadline D is less than the period T;

[0127] arbitrary deadline A system in which, for each instance, there is no limit between the deadline D and the period T.

[0128] The processing system 10 is configured to perform a time detection procedure 700, referred to herein as Figure 8 , wherein there is no constraint between the deadline D and the period, but a step 710 is performed to check for violations of the worst-case execution time C of the generic task TK, wherein the value of the worst-case execution time C for a given instance is given by offline time analysis. In step 720, an exception is preferably recorded in the same security log SL.

[0129] From the above description, therefore, the advantages of the described solution are apparent.

[0130] The described system advantageously comprises a security-hardened real-time operating system, wherein security hardening is achieved by performing authenticity checks on the operating system software or application software at runtime, which checks are performed in real time by using high priority in a periodic manner and by utilizing dedicated hardware for encryption and certificate validation.

[0131] In particular, by running the authentication process in a periodic task with the highest priority relative to other host / HTA services, the disclosed system also prevents an attacker or an overly demanding host (demanding a large number of operations from the HTA) from preventing the runtime authenticity check from running and detecting software tampering, while also preventing the time required to verify the entire flash memory from exceeding a predefined value.

[0132] Of course, without prejudice to the principle of the embodiment, the construction and details of the embodiment may vary widely with respect to what is described and illustrated herein purely by way of example, without thereby departing from the scope of the present embodiment, as defined by the following claims.

Claims

1. A processing system configured to perform trusted operations, the processing system comprising: at least one host computing module (11), the host computing module (11) comprising a host processing unit (113) and a host memory device (111, 112); and A hardware-isolated hardware trust anchor (12), the hardware trust anchor (12) comprising a respective security processing unit (123), a hardware processing module (122) dedicated to cryptographic operations, and a secure storage device (121), the hardware trust anchor being configured to store and run a real-time secure operating system (HOS), the secure operating system (HOS) being configured to perform validity verification on software used in the processing system (10), The secure operating system (HOS) is configured to perform a runtime authenticity check (500) to control the integrity of the software code at runtime, the runtime authenticity check (500) comprising at least identifying (505) a signed software block (SSB) and corresponding header (SSBH) and data block (SSDB) present in a program memory (121b) in the hardware trust anchor for execution, and performing the following verification steps (510, 520, 530): The first step (510) is to verify the validity of the certificate (C) associated with the signed software block (SSB), The second step (520) is to verify the validity of the header (SSBH) of the signed software block (SBB), The third step (530) is to verify the validity of the hash of the data (SSBD) of the signed software block (SSB), and If one of said verification steps (510, 520, 530) of the validity verification detects an anomaly, information about the detected anomaly is written to a security log (SL), The secure operating system (HOS) is configured to run the runtime authenticity check (500) in a task with the highest priority (PL) relative to other host computing modules (11) or hardware trust anchor (12) services.

2. The system according to claim 1, wherein: The runtime authenticity check (500) is also applied to signed software blocks (SSBs) present in the host memory device (111) of the host computing module (11).

3. The system according to claim 1 or 2, characterized in that The secure operating system (HOS) is configured to run the runtime authenticity check (500) in a periodic task with the highest priority (PL) relative to other host computing modules (11) or hardware trust anchor (12) services at a given period (T), and the check steps (510, 520, 530) are divided into a plurality of sub-steps of a configurable duration (DH) executed at each period (T).

4. The system according to claim 1, wherein: Said first step (510) of verifying the validity of the certificate (C) associated with said signed software block (SSB) comprises that any new certificate to be stored in the hardware trust anchor (12) is verified as another certificate stored in the hardware trust anchor (12) unless it is a self-signed certificate.

5. The system according to claim 1, wherein: Said second step (520) of verifying the validity of said header (SSBH) of said signed software block (SSB) comprises verifying the header signature field of the current signed software block (SBB).

6. The system according to claim 1, wherein: Said third step (530) of verifying the validity of the hash of the data (SSBD) of said signed software block (SSB) comprises: calculating a hash value on said data block (SSBD) in said hardware processing module (122), through a hash engine (122a), and comparing said hash value with the content of a field in a header (SSBH) storing a hash value defining a qualified digest calculated on the data block.

7. The system according to claim 1, wherein: The operating system is configured to perform a stack overflow detection process (600) on a stack (SS) of a volatile memory (121a) of a hardware trust anchor (12) for task execution, which includes checking the amount of used stack (SS) against static boundaries.

8. The system according to claim 7, characterized in that The hardware trust anchor (12) operating system (HOS) is configured as follows: filling (610) the stack area allocated to the task with the known pattern (SP), During each context switch, for modification, the last part in the valid stack range is verified (620), If a modification on a fill operation is detected, then a stack overflow hook function is called (630).

9. The system according to claim 1, wherein: The operating system is configured to perform a real-time detection process (700), comprising checking (710) for violations of a worst-case execution time (C) of a task, the value of the worst-case execution time (C) being given for a given instance of a given task by offline time analysis, and, if the checking step (710) detects an anomaly, writing information about the detected anomaly into a security log (SL).

10. The system according to claim 1, wherein: The at least one host computing module (11) and the hardware trust anchor (12) are part of a system on a chip.

11. The system according to claim 1, wherein: The at least one host computing module (11) is an ECU operating in a vehicle.

12. The system according to claim 1, wherein: The writing of the information about the detected anomaly into the security log (SL) includes creating a security log SL including the information about the detected anomaly, or writing the anomaly into the security log (SL).

13. A method for performing a trusted operation in a processing system according to any one of claims 1 to 12, the method comprising: Storing and running a real-time safety operating system (HOS) for validating software used in a processing system, the method comprising: A runtime authenticity check (500) is performed to control the integrity of the software code at runtime, said runtime authenticity check (500) comprising identifying (505) signed software blocks (SSBs) and corresponding headers (SSBH) and data blocks (SSDB) present in at least a program memory (121b) of a hardware trust anchor (12) for execution, and performing the following verification steps (510, 520, 530) for each signed software block (SSB): The first step (510) is to verify the validity of the certificate (C) associated with the signed software block (SSB), The second step (520) is to verify the validity of the header (SSBH) of the signed software block (SBB), The third step (530) is to verify the validity of the hash of the data (SSBD) of the signed software block (SSB), and If one of said verification steps (510, 520, 530) of the validity verification detects an anomaly, information about the detected anomaly is written to a security log (SL), The secure operating system is configured to run the runtime authenticity check (500) in a task with the highest priority (PL) relative to other host computing modules (11) or hardware trust anchor (12) services.

14. The method according to claim 13, wherein: The method comprises operating a system according to any one of claims 2 to 12.

Images