SoC chip multi-stage flow control method and hardware trusted root

Abstract

A SoC chip multi-stage flow control trusted starting method and hardware trusted root, the method takes RomCode, eFuse, hash algorithm module, symmetric cipher algorithm and integrity check module, exception processing special pin and end-to-end special access connection between eFuse and security special module as hardware trusted root, through comprehensive utilization of hardware trusted root and multi-stage flow control strategy solidified in RomCode, realizes trusted chain of chip, ensures safety and trust of chip under normal starting and abnormal restart, debugging and other abnormal starting scenes.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit design, and in particular to a hardware root of trust design, and a chip trust chain startup strategy based on the hardware root of trust using multi-level process control. Background Technology

[0002] In the field of integrated circuits, a System-on-a-Chip (SoC) is a chip-level system formed by combining a series of integrated circuits with specific functions on a single chip. Its hardware part includes microprocessors / microcontrollers, control logic, on-chip memory, specific functional units, external communication interfaces, etc., while the software part includes embedded systems and application software.

[0003] Generally, during the power-on startup process of a SoC chip, the on-chip ROM reads the boot loader from non-volatile memory. The boot loader performs initialization and configuration operations on the processor, peripherals, and various dedicated functional units. After initialization, the boot loader loads the operating system and application programs into the SoC's on-chip RAM for execution. Therefore, if there are security risks during the chip's startup process, and any part, such as the boot loader or application programs, is maliciously tampered with or replaced, the chip's security cannot be guaranteed. Thus, it is necessary to implement comprehensive security and trust protection for SoC chips, ensuring a complete chain of trust to effectively prevent malicious tampering of the chip program during startup and operation. To prevent the chip program from being tampered with and replaced, and from which important algorithms and data can be stolen, a corresponding startup key is usually set for verification. The software image is only run after successful verification.

[0004] For systems requiring high-level security features, it is essential to ensure that all code and corresponding operations are trustworthy throughout the entire process, from the first instruction executed during chip startup to the completion of application software loading. If the chip's own root of trust is tampered with or bypassed, the system itself will not be able to detect it. Therefore, the chip must possess an immutable hardware root of trust for startup and employ a comprehensive set of secure startup strategies to ensure the chip's own startup is trustworthy and secure.

[0005] It should be noted that the information disclosed in the background section above is only for understanding the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The main objective of this invention is to overcome the deficiencies of the aforementioned background technology and provide a trusted startup method for multi-level process control of SoC chips and a trusted root hardware for SoC chips.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] A trusted boot method for multi-level process control of SoC chips uses RomCode, eFuse, hash algorithm module, symmetric cryptography algorithm and integrity verification module, special pin for exception handling, and end-to-end dedicated access connection between eFuse and security module as hardware trust roots. By comprehensively utilizing the hardware trust roots and the multi-level process control strategy embedded in RomCode, a trusted chain is realized for the chip, ensuring the security and trustworthiness of the chip under normal boot and abnormal boot scenarios such as abnormal restart and debugging.

[0009] Furthermore:

[0010] The multi-level process control includes the following steps:

[0011] 1) The chip is powered on;

[0012] 2) Check if the PLL is locked;

[0013] 3) Initialize UART, SPI, CRC, eFuse, symmetric cryptography algorithm and integrity verification module, and hash algorithm module;

[0014] 4) Read the level of the forced upgrade pin to determine whether to execute forced upgrade mode. If not in forced upgrade mode, proceed to step 5); otherwise, jump to step 13.

[0015] 5) Read and determine whether there is normal program data in the non-volatile memory. If there is normal program data, proceed to step 6); otherwise, jump to step 13.

[0016] 6) Close the JTAG channel;

[0017] 7) Enable eFuse and read information such as chip version number and key index number;

[0018] 8) Enable symmetric cryptography algorithms and integrity verification modules;

[0019] 9) Perform the decryption operation on the main program data, and determine whether the decrypted data sequence matches the correct sequence preset before encryption based on the decryption result. If they match, proceed to step 10); otherwise, proceed to step 13.

[0020] 10) Enable hash algorithm module;

[0021] 11) Perform hash calculation on the main program data to obtain digest information, further obtain message verification code, compare the digest and message verification code with the preset correct sequence to determine if they match. If they match, proceed to step 12); if they do not match, jump to step 13.

[0022] 12) Copy the main program image to RAM, and then jump the instruction to RAM to execute the main program;

[0023] 13) Wait for UART or SPI input instructions. If no instructions are input, the software is reset and jumps to step 1). If instructions are input, step 14) is executed.

[0024] 14) Enable and call the symmetric cryptography algorithm and integrity verification module to decrypt and verify the integrity of the input instruction sequence, and determine whether the instruction is legal and valid. If the instruction is correct, proceed to step 15); if the instruction is incorrect, jump to step 13.

[0025] 15) Execute the burning of relevant fields in eFuse and burn the main program to the specified address space in FLASH.

[0026] In various embodiments of the present invention, firstly, by comprehensively utilizing RomCode, eFuse, hash algorithm module, symmetric cryptography algorithm and integrity verification module, special pins for exception handling, and end-to-end dedicated access connections between eFuse and the dedicated modules, a hardware root of trust design is provided to ensure the security and trustworthiness of the bootloader during the chip power-on phase; secondly, by utilizing the end-to-end direct access connection between the security key storage medium controller and the dedicated encryption / decryption algorithm module, during the normal startup phase of the chip power-on, hardware-based access to the security key by the CPU and bus, as well as the snooping on the security data on the CPU core and bus via external communication interfaces, are blocked; thirdly, by comprehensively utilizing the hardware root of trust and multi-level process control, a trust chain for the chip is realized to ensure the security and trustworthiness of the chip under normal startup and abnormal startup scenarios such as abnormal restarts and debugging.

[0027] In some embodiments, the hardware root of trust consists of several hardware functional units and special connections, specifically including: RomCode, eFuse, hash algorithm module, symmetric cryptography algorithm and integrity verification module, dedicated exception handling pins, and end-to-end dedicated access connections between eFuse and dedicated modules. The eFuse storage area is configured as a write-only area, a read-write area, and a read / write status indicator area. Secure data such as the main program's decryption key, digest information, and encrypted communication enable status indication are stored in the write-only area. When the hash algorithm module, symmetric cryptography algorithm module, and integrity verification dedicated module need to use this secure data, the eFuse controller automatically transmits the data to the corresponding entry point of each dedicated module through the dedicated access connection. The CPU and bus cannot access this secure data throughout the process. Status information such as chip ID, version number counter, JTAG lock status indication, and external communication interface enable indication are stored in the read-write area; the read / write status indicator area is used to indicate the read / write attributes of different data segments of the eFuse.

[0028] In some embodiments, the main functions of RomCode include: completing chip power-on initialization, determining the next workflow based on the configuration status information of the eFuse readable and writable area and whether a main program exists in the chip. Specifically, if a main program already exists in the chip, it is guided to start the main program based on the configuration status of the hardware root of trust; if a main program does not yet exist in the chip, it is confirmed through encrypted communication handshake signals, JTAG, SWD, UART, and SPI communication interfaces are enabled, debug mode is entered, and the main program is programmed; if an anomaly occurs due to human error or uncontrollable electromagnetic interference such as single-event reversal, a dedicated anomaly handling pin is used to enter a forced reset state, re-enter debug mode, and program the main program.

[0029] In some embodiments, after the RomCode program completes chip initialization, it closes the JTAG communication interface and performs a series of trusted chain verifications on the main program in the non-volatile memory. Specifically, this includes: the CPU obtaining the main program version number stored in the eFuse and reading the main program stored at the corresponding address in the non-volatile memory; enabling the symmetric cryptography algorithm and integrity verification module, which directly accesses the key stored in the eFuse to decrypt the main program image and simultaneously perform integrity verification of the main program image; and enabling the hash algorithm module, which directly accesses the signature key stored in the eFuse and verifies it against the digest information extracted after decrypting the main program image.

[0030] If the chip does not yet contain a main program, identity verification is required before proceeding to the programming process. Identity verification is confirmed via an encrypted communication sequence. The user inputs the encrypted communication sequence via UART or SPI. The symmetric cryptography module decrypts the sequence, and the hash algorithm module calculates and confirms the digest value of the decrypted sequence. After confirmation, the decrypted sequence is compared with the sequence stored in the eFuse. If they match completely, the user's identity is confirmed. The user can then program the eFuse and write the main program to non-volatile memory. After programming is complete, the chip automatically enters a reset state.

[0031] If an abnormality occurs due to uncontrollable electromagnetic interference or other extreme factors, preventing normal startup, a dedicated exception handling pin can be used to enter a forced reset state. After completing authentication through an encrypted communication sequence, the system can enter debug mode to verify the correctness of the eFuse programming information and reprogram the correct version of the main program.

[0032] A SoC chip hardware root of trust that implements the trusted boot method.

[0033] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the trusted boot method.

[0034] This invention provides a hardware trusted chain design and a trusted boot method with multi-level process control for a SoC chip. It comprehensively utilizes RomCode, eFuse, hash algorithm modules, symmetric cryptography algorithms and integrity verification modules, dedicated exception handling pins, and end-to-end dedicated access connections between eFuse and dedicated modules to provide a hardware trusted root design. This design ensures the physical and logical security and trustworthiness of each functional module of the bootloader during the chip power-on phase. Based on this, it comprehensively utilizes the functional modules in the hardware trusted root and the multi-level process control in RomCode to achieve trusted and secure boot of the chip, ensuring the chip's security and trustworthiness in normal boot, abnormal restart, debugging, and other abnormal boot scenarios.

[0035] This invention offers excellent scalability. The eFuse can store multiple sets of security keys and other information, and also features version number rollback protection. This ensures the chip has key update capabilities while preventing attacks using expired keys. Furthermore, the eFuse stores the encrypted internal data integrity verification sequence and hash value of the main program under the corresponding version key, ensuring the security and matching of the corresponding verification information after a key update. Attached Figure Description

[0036] Figure 1 This is a diagram of the overall architecture of the hardware trusted root in an embodiment of the present invention.

[0037] Figure 2 This is a schematic diagram of the chip trusted chain startup process for multi-level process control according to an embodiment of the present invention. Detailed Implementation

[0038] The embodiments of the present invention will be described in detail below. It should be emphasized that the following description is merely exemplary and not intended to limit the scope and application of the present invention.

[0039] It should be noted that when a component is referred to as "fixed to" or "set on" another component, it can be directly on or indirectly on that other component. When a component is referred to as "connected to" another component, it can be directly connected to or indirectly connected to that other component. Furthermore, a connection can be used for fixing, coupling, or communication.

[0040] It should be understood that the terms "length", "width", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", and "outer" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing the embodiments of the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the present invention.

[0041] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of the present invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0042] This invention provides a chip trusted chain startup method with multi-level process control. It uses RomCode, eFuse, hash algorithm module, symmetric cryptography algorithm and integrity verification module, special pin for exception handling, and special access connection between eFuse and security module as hardware trust roots. By comprehensively utilizing the hardware trust roots and the multi-level process control strategy embedded in RomCode, a trusted chain is realized for the chip, ensuring the chip's security and trustworthiness in normal startup and abnormal startup scenarios such as abnormal restart and debugging.

[0043] Figure 1 The diagram shown illustrates the overall organizational structure of the SoC chip security design method proposed in this invention. The design comprises the following components:

[0044] RomCode: The bootloader's main tasks include completing chip initialization, disabling the JTAG communication interface, controlling the chip's power-on startup mode selection, flow control, exception handling, and input / output operations during the boot phase, and completing a series of trusted chain verifications of the main program in non-volatile memory.

[0045] eFuse: Both reading and writing tasks in eFuse are controlled and implemented by the eFuse controller. High-level security keys and other data are transmitted end-to-end to the entry points of dedicated security algorithm modules receiving this data via a dedicated read connection, without going through the bus, under the direct control of the eFuse controller. The eFuse storage area is configured as a write-only area, a read-write area, and a read / write status indicator area. The main program's decryption key, digest information, and encrypted communication enable status indicators are stored in the write-only area. Specifically, when the hash algorithm module, symmetric cryptography algorithm module, and integrity verification module need to use this security data, the CPU sends the key's index number. The eFuse controller reads the key data at the corresponding address based on the index number and automatically transmits the key data to the corresponding entry point of each dedicated module controller via a dedicated access connection. The CPU and bus cannot access this key data throughout the entire process.

[0046] Hash Algorithm Module: Receives digest consistency verification instructions sent by the CPU through the hash algorithm module controller, and uses the end-to-end dedicated access connection with eFuse to receive key data transmitted from the eFuse controller, thereby performing digest calculation on the main program data.

[0047] Symmetric cryptography algorithm and integrity verification module: The symmetric cryptography algorithm module controller receives symmetric encryption and decryption instructions sent by the CPU. Utilizing the dedicated end-to-end access connection with eFuse, it receives several key data transmitted from the eFuse controller to perform symmetric decryption calculations on the main program data. Simultaneously, it performs internal integrity verification of the main program data.

[0048] Dedicated pin for exception handling: This pin is mainly set up to prevent the chip from starting normally under abnormal conditions. When the boot program in the ROMCode detects that this dedicated pin is pulled high, it is determined that the chip is in an abnormal state and there is human operation. At this time, it will allow authentication through encrypted communication sequence, enter debug mode, check whether the eFuse burning information is correct, allow rewriting of data in eFuse, and rewrite the main program.

[0049] The end-to-end dedicated access connection between eFuse and dedicated modules: The end-to-end dedicated connection between eFuse and the hash algorithm module and the symmetric cryptography algorithm and integrity verification module, the enable signal of this connection is controlled by the eFuse controller.

[0050] Figure 2 The multi-level process control strategy proposed in this invention is shown below, and the main control flow is as follows:

[0051] 1) The chip is powered on;

[0052] 2) Check if the PLL is locked;

[0053] 3) Initialize UART, SPI, CRC, eFuse, symmetric cryptography algorithm and integrity verification module, and hash algorithm module;

[0054] 4) Read the level of the forced upgrade pin to determine whether to execute forced upgrade mode. If not in forced upgrade mode, proceed to step 5); otherwise, jump to step 13.

[0055] 5) Read and determine whether there is normal program data in the non-volatile memory. If there is normal program data, proceed to step 6); otherwise, jump to step 13.

[0056] 6) Close the JTAG channel;

[0057] 7) Enable eFuse and read information such as chip version number and key index number;

[0058] 8) Enable symmetric cryptography algorithms and integrity verification modules;

[0059] 9) Perform the decryption operation on the main program data, and determine whether the decrypted data sequence matches the correct sequence preset before encryption based on the decryption result. If they match, proceed to step 10); otherwise, proceed to step 13.

[0060] 10) Enable hash algorithm module;

[0061] 11) Perform hash calculation on the main program data to obtain digest information, further obtain message verification code, compare the digest and message verification code with the preset correct sequence to determine if they match. If they match, proceed to step 12); if they do not match, jump to step 13.

[0062] 12) Copy the main program image to RAM, and then jump the instruction to RAM to execute the main program;

[0063] 13) Wait for UART or SPI input instructions. If no instructions are input, the software is reset and jumps to step 1). If instructions are input, step 14) is executed.

[0064] 14) Enable and call the symmetric cryptography algorithm and integrity verification module to decrypt and verify the integrity of the input instruction sequence, and determine whether the instruction is legal and valid. If the instruction is correct, proceed to step 15); if the instruction is incorrect, jump to step 13.

[0065] 15) Execute the burning of relevant fields in eFuse and burn the main program to the specified address space in FLASH.

[0066] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment or an embodiment combining software and hardware aspects.

[0067] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0068] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0069] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0070] The background section of this invention may include background information about the problems or environment in which the invention is being developed, and is not necessarily a description of prior art. Therefore, the content included in the background section does not constitute an admission of prior art by the applicant.

[0071] The above description provides a further detailed explanation of the present invention in conjunction with specific / preferred embodiments, and it should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various substitutions or modifications can be made to these described embodiments without departing from the concept of the present invention, and all such substitutions or modifications should be considered within the scope of protection of the present invention. In the description of this specification, the reference to terms such as "an embodiment," "some embodiments," "preferred embodiment," "example," "specific example," or "some examples," etc., indicates that the specific features, structures, materials, or characteristics described in connection with that embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples. Although the embodiments of the present invention and their advantages have been described in detail, it should be understood that various changes, substitutions, and modifications can be made herein without departing from the scope of protection of the patent application.

Claims

1. A trusted boot method for multi-level process control of a SoC chip, characterized in that, RomCode, eFuse, hash algorithm module, symmetric cryptography algorithm and integrity verification module, special pin for exception handling, and end-to-end dedicated access connection between eFuse and security module are used as hardware trusted roots. By comprehensively utilizing the hardware trusted root and the multi-level flow control strategy embedded in RomCode, a trusted chain is realized for the chip, ensuring the chip's security and trustworthiness under normal startup and abnormal startup scenarios, including abnormal restart and debugging. The multi-level process control includes the following steps: 1) The chip is powered on; 2) Check if the PLL is locked; 3) Initialize UART, SPI, CRC, eFuse, symmetric cryptography algorithm and integrity verification module, and hash algorithm module; 4) Read the forced upgrade pin level to determine whether to execute forced upgrade mode. If not in forced upgrade mode, proceed to step 5); otherwise, jump to step 13. 5) Read and determine whether there is normal program data in the non-volatile memory. If there is normal program data, proceed to step 6); otherwise, jump to step 13. 6) Close the JTAG channel; 7) Enable eFuse and read the chip version number and key index number; 8) Enable symmetric cryptography algorithms and integrity verification modules; 9) Perform the decryption operation on the main program data, and determine whether the decrypted data sequence matches the preset correct sequence before encryption based on the decryption result. If they match, proceed to step 10); otherwise, jump to step 13. 10) Enable the hash algorithm module; 11) Perform hash calculation on the main program data to obtain digest information, further obtain message verification code, compare the digest and message verification code with the preset correct sequence to determine if they match. If they match, proceed to step 12); if they do not match, jump to step 13. 12) Copy the main program image into RAM, and then jump the instruction to RAM to execute the main program; 13) Wait for UART or SPI input instructions. If no instructions are input, perform a software reset and jump to step 1). If instructions are input, jump to step 14). 14) Enable and call the symmetric cryptography algorithm and integrity verification module to decrypt and verify the integrity of the input instruction sequence, and determine whether the instruction is valid. If the instruction is correct, proceed to step 15); if the instruction is incorrect, jump to step 13. 15) Execute the burning of relevant fields in eFuse and burn the main program to the specified address space in FLASH.

2. The trusted boot method as described in claim 1, characterized in that, By utilizing the end-to-end direct access connection between the secure key storage medium controller and the dedicated encryption / decryption algorithm module, during the normal startup phase of the chip power-on, the CPU and bus are prevented from accessing the secure key, as well as from spying on the secure data on the CPU core and bus via external communication interfaces.

3. The trusted boot method as described in claim 1, characterized in that, The eFuse storage area is divided into a write-only area, a read-write area, and a read / write status indicator area. Secure data, including the main program's decryption key, digest information, and encrypted communication enable status indicators, is stored in the write-only area. When the hash algorithm module, symmetric cryptography module, and integrity verification module need to use this secure data, the eFuse controller automatically transmits the data to the corresponding entry point of each dedicated module via a dedicated access line. The CPU and bus cannot access this secure data throughout the process. Status information, including chip ID, version counter, JTAG lock status indicator, and external communication interface enable indicator, is stored in the read-write area. The read / write status indicator area is used to indicate the read / write attributes of different data segments in the eFuse.

4. The trusted boot method as described in claim 1, characterized in that, The main functions of ROMCode include: completing chip power-on initialization; determining the next workflow based on the configuration status information of the eFuse readable and writable area and whether a main program exists in the chip; if a main program already exists in the chip, guiding the main program to start based on the configuration status of the hardware root of trust; if a main program does not yet exist in the chip, confirming through encrypted communication handshake signals, enabling JTAG, SWD, UART, and SPI communication interfaces, entering debug mode, and programming the main program; if an anomaly occurs due to extreme circumstances, including human error or uncontrollable electromagnetic interference, using a dedicated anomaly handling pin to enter a forced reset state, re-enter debug mode, and program the main program.

5. The trusted boot method as described in claim 1, characterized in that, After the ROMCode program completes chip initialization, it closes the JTAG communication interface and performs a series of trusted chain verifications on the main program in the non-volatile memory. Specifically, this includes: the CPU obtaining the main program version number stored in the eFuse and reading the main program stored at the corresponding address in the non-volatile memory; enabling the symmetric cryptography algorithm and integrity verification module, which directly accesses the key stored in the eFuse to decrypt the main program image and simultaneously perform integrity verification of the main program image; and enabling the hash algorithm module, which directly accesses the signature key stored in the eFuse and verifies it against the digest information extracted after decrypting the main program image.

6. The trusted boot method as described in claim 1, characterized in that, If the main program is not yet present in the chip, identity verification must be performed before the program can be written. Identity verification is confirmed through an encrypted communication sequence. The user inputs the encrypted communication sequence via UART or SPI. The symmetric cryptography algorithm module decrypts the encrypted sequence, and the hash algorithm module calculates and confirms the digest value of the decrypted sequence. After confirmation, the decrypted sequence is compared with the sequence stored in the eFuse. If they are completely identical, the user's legitimate identity is confirmed. The user can then perform operations including writing to the eFuse and writing the main program to non-volatile memory. After writing is completed, the chip automatically enters a reset state.

7. The trusted boot method as described in claim 1, characterized in that, In the event of an anomaly caused by extreme factors, including uncontrollable electromagnetic interference, which prevents normal startup, a dedicated anomaly handling pin is used to enter a forced reset state. After authentication is completed through an encrypted communication sequence, the system enters debug mode to verify the correctness of the eFuse programming information and reprograms the correct version of the main program.

8. A SoC chip hardware root of trust that implements the trusted boot method as claimed in any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the trusted boot method as described in any one of claims 1 to 7.

Images