An embedded Linux secure boot method and system based on RK3568

Abstract

This application relates to an embedded Linux secure boot method and system based on RK3568. The method includes: verifying the signature of the SPL firmware using the root key stored in OTP; if the SPL firmware verification passes, verifying the signature information of the Uboot firmware using the OTP key; if the Uboot firmware verification passes, verifying the signature information of the Boot firmware using the OTP key via the OP-TEE system call, and loading the Kernel image, DTB device tree, and Ramdisk file system; triggering SMC instructions through the Ramdisk file system client program to call a trusted application, obtaining key data from the RPMB partition, and decrypting the Rootfs encrypted container using the key data; after the Rootfs encrypted container is decrypted, booting the Linux system, and completing communication isolation between the secure area and the normal area through the OP-TEE system. This application solves the problems of high firmware tampering risk and insufficient file system flexibility in the prior art, which is beneficial to improving system security.

Description

Technical Field

[0001] This application relates to the field of embedded system technology, and in particular to an embedded Linux secure boot method and system based on RK3568. Background Technology

[0002] In embedded Linux systems, the boot process typically includes stages such as bootrom, SPL, U-Boot, kernel, and rootfs. However, existing boot processes contain numerous security vulnerabilities. For example, if the bootrom, as the initial boot code, is tampered with, the device will be unable to complete hardware initialization, causing the boot process to terminate. The SPL is responsible for loading U-Boot; if the image within its partition is replaced, the SPL stage will fail to load U-Boot correctly. Furthermore, if the bootcmd environment variable is tampered with during the U-Boot stage, it may lead to incorrect kernel image loading or the loading of an unauthorized third-party kernel image. These security vulnerabilities can cause system boot anomalies, resulting in economic losses in production environments and even endangering personnel and environmental safety.

[0003] Furthermore, if files within the rootfs filesystem are arbitrarily deleted, modified, or injected with malicious software, it can also pose a security risk. While existing security solutions prevent malicious tampering by formatting the filesystem as read-only, debuggers cannot modify the filesystem normally, and temporary or cached files during system operation require additional independent storage partitions, increasing system complexity. Summary of the Invention

[0004] The purpose of this application is to propose an embedded Linux secure boot method and system based on RK3568, so as to improve the security of the system boot process and prevent firmware tampering.

[0005] To address the aforementioned technical problems, this application provides an embedded Linux secure boot method based on RK3568, comprising:

[0006] The SPL firmware is signed and verified using the root key stored in the OTP.

[0007] If the SPL firmware verification passes, the signature information of the Uboot firmware is verified using the OTP key.

[0008] If the Uboot firmware verification passes, the OTP key is called through the OP-TEE system to verify the signature information of the Boot firmware, and the Kernel image, DTB device tree and Ramdisk file system are loaded.

[0009] The client program of the Ramdisk file system triggers the SMC instruction to call the trusted application, obtains key data from the RPMB partition, and decrypts the Rootfs encrypted container using the key data;

[0010] Once the Rootfs encrypted container is decrypted, the Linux system is started, and the communication isolation between the secure area and the normal area is completed through the OP-TEE system.

[0011] To address the aforementioned technical problems, this application provides an embedded Linux secure boot system based on RK3568. The system implements the embedded Linux secure boot method based on RK3568 described above, including:

[0012] The RK3568 SoC hardware platform is used to run the Linux system;

[0013] The OP-TEE system is used to divide the system into secure areas and normal areas;

[0014] The root key storage and firmware packaging module is used to store the OTP key and package the SPL firmware, the Uboot firmware and the Boot firmware in FIT format.

[0015] The RPMB partition key storage and decryption module is used to store RPMB key information and decrypt the Rootfs encrypted container.

[0016] This invention provides an embedded Linux secure boot method and system based on RK3568. The method includes: verifying the signature of the SPL firmware using the root key stored in OTP; if the SPL firmware verification passes, verifying the signature information of the Uboot firmware using the OTP key; if the Uboot firmware verification passes, verifying the signature information of the Boot firmware using the OTP key via the OP-TEE system, and loading the Kernel image, DTB device tree, and Ramdisk file system; triggering SMC instructions through the client program of the Ramdisk file system to call a trusted application, obtaining key data from the RPMB partition, and decrypting the Rootfs encrypted container using the key data; after the Rootfs encrypted container is decrypted, booting the Linux system, and completing communication isolation between the secure area and the normal area through the OP-TEE system. This invention solves the problems of high firmware tampering risk and insufficient file system flexibility in the prior art by using OTP key to verify firmware signatures step by step, combining the security isolation mechanism of the OP-TEE system, and the key decryption process based on the RPMB partition, thus improving system security. Attached Figure Description

[0017] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the implementation of the embedded Linux secure boot method based on RK3568 provided in this application embodiment;

[0019] Figure 2 This is a flowchart illustrating the implementation of the embedded Linux secure boot method based on RK3568 provided in this application embodiment;

[0020] Figure 3 This is a flowchart illustrating the implementation of an embedded Linux secure boot method based on RK3568, provided in another embodiment of this application.

[0021] Figure 4 This is a flowchart illustrating the implementation of a sub-process in the embedded Linux secure boot method based on RK3568 provided in this application embodiment;

[0022] Figure 5 This is a flowchart illustrating the implementation of an embedded Linux secure boot method based on RK3568, provided in another embodiment of this application.

[0023] Figure 6 This is a flowchart illustrating the implementation of another sub-process in the embedded Linux secure boot method based on RK3568 provided in this application embodiment;

[0024] Figure 7 This is a schematic diagram of an embedded Linux secure boot system based on RK3568 provided in an embodiment of this application;

[0025] Figure 8 This is a block diagram of an embedded Linux secure boot system implementation based on RK3568 provided in this application embodiment. Detailed Implementation

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0027] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0029] In existing technologies, the boot process of embedded Linux systems is subject to security risks at multiple stages. If the firmware is tampered with at any stage during the step-by-step boot process from bootrom to kernel, the system will fail to boot. Existing protection methods employ static verification mechanisms, which cannot defend against malicious code injection at intermediate stages. File system security protection typically uses read-only formats, which, while preventing runtime tampering, limits debugging and maintenance flexibility and cannot prevent data theft at the storage media level.

[0030] To address the aforementioned issues, given the observed trust transfer breaks at various stages of system startup, a continuous security verification mechanism is needed. Regarding the insufficient security of key storage, OTP memory was found to possess physical tamper-proof characteristics. It was also noted that the security extension capabilities of the ARM architecture are not fully utilized, and the TEE environment can isolate sensitive operations. In terms of file system encryption, existing solutions rely on fixed key storage, which is vulnerable to physical attacks; therefore, dynamic key management needs to be implemented in conjunction with secure partitioning.

[0031] Therefore, this application proposes an embedded Linux secure boot method based on RK3568, including: verifying the signature of the SPL firmware using the root key stored in OTP; if the SPL firmware verification passes, verifying the signature information of the Uboot firmware using the OTP key; if the Uboot firmware verification passes, verifying the signature information of the Boot firmware using the OTP key via the OP-TEE system call, and loading the Kernel image, DTB device tree, and Ramdisk file system; triggering the SMC instruction to call a trusted application through the client program of the Ramdisk file system, obtaining key data from the RPMB partition, and decrypting the Rootfs encrypted container using the key data; after the Rootfs encrypted container is decrypted, booting the Linux system, and completing the communication isolation between the secure area and the normal area through the OP-TEE system.

[0032] The OTP storage root key refers to the encryption key burned into the chip's one-time programmable storage unit. Specifically, it uses the SHA-256 algorithm to generate key pairs, leveraging the physical tamper-proof characteristics of the OTP memory to ensure key security. The step-by-step verification refers to chain-like verification of the SPL, Uboot, and Boot firmware in the boot order, implemented using the RSA-2048 signature algorithm. This ensures that the next stage of firmware can only be loaded after the previous stage's verification passes. The OP-TEE system refers to a trusted execution environment based on the ARM TrustZone architecture. It specifically restricts key verification operations to the secure world by dividing the world into two hardware isolation domains: a secure world and a normal world. The RPMB partition refers to the eMMC storage chip's replay attack protection security partition. It uses the AES-128-GCM encryption algorithm to store key data, and access control is implemented through the chip controller. The Rootfs encrypted container refers to an encrypted file system container built using dm-crypt technology. It encapsulates the original file system using the LUKS format, and the decryption key is only obtained from the secure environment at runtime.

[0033] Specifically, after the system powers on, it first verifies the integrity of the SPL firmware using an OTP key, establishing an initial trust anchor. Digital signature verification is required before loading each firmware level to ensure no unauthorized code injection. After the U-boot phase, the processor is switched to a secure state via SMC instructions, and the OP-TEE takes over the Boot firmware verification process. After the Ramdisk boots, its client program triggers a trusted application through security monitoring, extracting the encryption key from the physically protected RPMB partition. This key exists only in memory within a secure environment and is used to dynamically decrypt the file system container. A controlled communication channel is established between the secure and ordinary areas, ensuring that sensitive data such as keys are not exposed to the ordinary operating system environment. This application effectively prevents system paralysis caused by firmware tampering during the boot process and ensures the integrity of code execution at each stage. The key management system resists attacks at both the physical and software levels, ensuring the security of the file system decryption process. The trusted execution environment isolates sensitive operations at runtime, avoiding the risk of malicious user-space programs obtaining key data. The dynamic decryption mechanism ensures the file system's tamper-proof capabilities while supporting legitimate system maintenance operations.

[0034] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0035] Please see Figure 1 and Figure 2 , Figure 1 This paper illustrates a specific implementation of an embedded Linux secure boot method based on RK3568. Figure 2 This is a flowchart illustrating the implementation of the embedded Linux secure boot method based on RK3568 provided in this application embodiment.

[0036] It should be noted that if substantially the same result is obtained, the method of this invention is not based on... Figure 1 Limited to the order of the processes shown, this method includes the following steps:

[0037] S1: Verify the signature of the SPL firmware using the root key stored in the OTP.

[0038] Specifically, the hardware utilizes the RK3568 SoC solution, providing an OP-TEE trusted execution environment. OP-TEE is an open-source execution environment specifically designed for security, providing both secure and non-secure zones for the system. During the UBoot phase, OP-TEE creates a lightweight operating system, which is the OP-TEE described in this application. Within the secure zone, multiple trusted applications (TAs) can be loaded and run, such as data management and secure payment services. Client programs (CAs) running in the non-secure zone must trigger the SMC (Secure Monitor Call) instruction to switch the OP-TEE system to the secure world in order to communicate with TA programs and invoke TAs to perform sensitive data operations. SMC is a privileged instruction in the ARM architecture, enabling the switching between the secure and insecure states of the ARM core. Trusted applications can only be transmitted and stored in the secure zone, achieving memory isolation between the secure and non-secure zones and ensuring the information security of sensitive data during transmission and storage.

[0039] In this embodiment of the application, when the Linux system needs to be started, the Linux system needs to be powered on, then the hardware needs to be initialized, and the SPL firmware needs to be signed and verified using the root key stored in OTP.

[0040] Further, step S1 includes: after the system is powered on, performing hardware initialization based on the Bootrom firmware and reading the root key stored in the OTP; and performing signature verification on the SPL firmware using the root key stored in the OTP.

[0041] Specifically, the Bootrom is the first piece of firmware code executed upon system power-on. This firmware code resides inside the CPU and typically performs SoC-level hardware initialization, providing a runtime environment for subsequent program loading. The firmware signature information for the next stage, SPL, is verified by reading the OTP key.

[0042] The root key in OTP storage refers to the key data embedded in the chip via a one-time programmable memory. Specifically, a physical fuse mechanism ensures the key cannot be modified after being written, physically preventing tampering or replacement. Hardware initialization refers to the basic configuration of the processor core, memory controller, and peripheral interfaces. This is achieved by executing pre-built initialization code within the Bootrom to set the clock frequency, map memory addresses, and configure security registers, establishing a trusted hardware operating environment for subsequent verification.

[0043] Specifically, after the system powers on, it first runs the Bootrom code embedded in the chip ROM to complete the processor core state settings and memory controller initialization, ensuring that subsequent operations are executed in the correct hardware environment. Then, it accesses the OTP storage area to retrieve the root key that has been written to the circuit breaker. This key is generated using an asymmetric encryption algorithm to produce a public-private key pair; the public key is used to verify the digital signature of the SPL firmware. By calling the cryptographic algorithm engine to perform a signature verification operation on the signature data of the SPL image, if the hash value matches the public key decryption result, the firmware is deemed complete and trustworthy. This process establishes a hardware-level trust chain in the earliest stage of the boot process, effectively preventing the possibility of tampered SPL firmware being loaded and executed.

[0044] Please see Figure 3 , Figure 3 A specific implementation method prior to step S1 is shown below in detail:

[0045] S1A: Package the SPL firmware, the Uboot firmware, and the Boot firmware using the FIT format.

[0046] S1 B: The SPL firmware, the Uboot firmware, and the Boot firmware are signed level by level using the same set of OTP keys.

[0047] The FIT format refers to a firmware image packaging format based on a device tree structure. Specifically, it uses Flattened Image Tree technology to integrate multiple firmware components into a single image file. Its tree-like data structure supports multi-node configuration and integrity verification. This format addresses the difficulty of detecting tampering with individual firmware files in traditional distributed storage through a unified storage structure and verification mechanism. The OTP key refers to the cryptographic root key stored in a one-time programmable memory. Specifically, it can be a key pair generated using an elliptic curve digital signature algorithm, stored immutably through a hardware fuse mechanism. This key serves as the starting point of the trust chain, providing a unified cryptographic foundation for hierarchical signing and avoiding the risk of trust chain breakage caused by multi-key management.

[0048] Specifically, during the system build phase, the SPL firmware, Uboot firmware, and Boot firmware are integrated into a FIT format image structure. Each firmware corresponds to an independent configuration node within the image, containing hash values ​​and signature data fields. The OTP key performs a step-by-step signature operation on the firmware content of each node: first, a signature for the SPL firmware is generated and written to the corresponding node; then, the Uboot firmware and the SPL signature data are hashed together to generate a second-level signature; finally, the Boot firmware and the first two levels of signature data are combined to generate a third-level signature. During the boot process, before each firmware is loaded, it must verify whether the signature of its corresponding node matches the OTP key, forming a chain verification structure from the bottom layer to the top layer.

[0049] Traditional embedded systems use independently stored firmware files and different keys for signing, which presents problems such as difficulty in detecting tampering with individual files and complex key management leading to security vulnerabilities. This application implements a centralized management and unified verification mechanism for firmware through the FIT format. Combined with a cascading signature method using a single OTP key, it establishes a strong correlation verification relationship between firmware files, ensuring that any level of tampering will disrupt the overall signature chain, significantly increasing the difficulty for attackers to perform partial tampering. This application achieves overall protection of the firmware storage structure, ensuring the integrity and authenticity of firmware at each boot stage; it constructs a trust transfer mechanism based on a cryptographic root key, ensuring that the verification of each firmware inherits the trust foundation of the previous stage; it effectively defends against local attacks targeting individual firmware files or signing mechanisms, and solves the security risks caused by loose packaging and multi-key verification.

[0050] S2: If the SPL firmware verification passes, the signature information of the Uboot firmware is verified using the OTP key.

[0051] Specifically, if signature verification fails, an error message is returned for re-verification. If signature verification succeeds, the signature information of the SPL firmware is loaded, and then the signature information of the Uboot firmware is verified using the OTP key. SPL is a secondary bootloader located between the bootrom and Uboot; its firmware code resides in an external eMMC and is responsible for loading the main bootloader, Uboot. The signature information of the next-stage Uboot firmware is verified by reading the OTP key.

[0052] S3: If the Uboot firmware verification passes, the OTP key is called through the OP-TEE system to verify the signature information of the Boot firmware, and the Kernel image, DTB device tree and Ramdisk file system are loaded.

[0053] Specifically, the U-Boot firmware code resides in the external eMMC and is responsible for parsing the DTB device tree, passing boot parameters (bootargs), and loading the Linux kernel image from the storage device into RAM. It uses the OP-TEE system integrated into the U-Boot firmware itself to read the OTP key and verify the signature information of the next-stage Boot firmware. The Boot firmware code, located in the external eMMC, contains the kernel image, DTB device tree binary data, and a Ramdisk file system.

[0054] Please see Figure 4 , Figure 4 A specific implementation of step S3 is shown below:

[0055] S31: If the Uboot firmware verification passes, the ARM core security state is switched via the OP-TEE system based on the SMC instruction.

[0056] S32: The trusted application calls the OTP key in the secure area to verify the signature information of the Boot firmware.

[0057] S33: Load the Kernel image, the DTB device tree, and the Ramdisk file system.

[0058] The OP-TEE system refers to a trusted execution environment built on ARM TrustZone technology. It can be implemented using the open-source OP-TEE framework and is used to isolate code execution and data access between secure and non-secure zones. SMC instructions are security monitoring call instructions for the ARM architecture, which can be triggered by writing assembly instructions to switch the ARM core from a secure state to a secure state. Trusted applications are protected programs running in the secure zone, which can call OTP keys through the TEE's internal API, preventing the keys from being exposed in the non-secure zone. OTP keys are one-time programmable encryption keys, implemented through the OTP storage unit built into the RK3568 chip, ensuring the keys cannot be tampered with. The Kernel image is the binary file of the Linux kernel, which can be loaded using zImage or Image format and used to start the core functions of the operating system. The DTB device tree is a structured data file describing hardware configuration information, which can be parsed by the U-boot firmware and passed to the kernel. The Ramdisk file system is a temporarily mounted initial memory file system, which can be built using cpio format and provides a temporary environment for decrypting the root file system.

[0059] Specifically, after the U-Boot stage verification passes, the system triggers an ARM core state switch by executing SMC instructions, allowing subsequent operations to be executed in a secure area. The trusted application in the secure area calls the key stored in the OTP to digitally sign and verify the Boot firmware; this verification process is completely isolated from the ordinary area. After successful verification, the system sequentially loads the verified Kernel image, the DTB device tree accurately describing the hardware topology, and the Ramdisk file system containing decryption tools. During this process, the integrity of the Kernel image is guaranteed by digital signature, the loading of the DTB device tree ensures that hardware initialization parameters have not been tampered with, and the Ramdisk file system provides a controlled execution environment for subsequent root file system decryption operations. The loading order of the three components follows the embedded system startup dependencies; the Ramdisk file system is mounted immediately after the Kernel image starts, forming a complete trusted chain from the hardware abstraction layer to the application layer. This application achieves secure isolation of the Boot firmware verification process, preventing key leakage and side-channel attacks on the verification logic. Through the synergistic effect of the trusted execution environment and the ARM core state switch, it ensures that critical verification operations are completed in a hardware-protected secure area. Meanwhile, the integrity verification of the kernel image and device tree eliminates malicious code injection at the source, and the secure loading of the Ramdisk file system builds a trusted foundation environment for the subsequent decryption of the encrypted file system, forming a security protection system covering the entire boot process.

[0060] Furthermore, prior to step S32, this application further includes: parsing the DTB device tree through the Uboot firmware and loading the DTB device tree and bootargs parameters into the Linux kernel; loading the Linux kernel image from the storage device into RAM memory; and incorporating the Uboot firmware into the OP-TEE system.

[0061] The DTB device tree is a structured data file describing hardware resource configurations, typically implemented in a flat device tree format. It defines processor types, peripheral address spaces, and memory mappings, ensuring the integrity and legitimacy of the hardware configuration during secure boot by parsing the device tree. The bootargs parameters are boot configuration information passed to the kernel, typically implemented as string parameters. Loading these parameters into the kernel constrains resource access permissions during kernel initialization. RAM memory loading involves copying the kernel image from storage media to physical memory, typically using a DMA controller or direct CPU addressing. This operation prevents runtime image tampering through physical memory access isolation mechanisms. Integrating the U-boot firmware into the OP-TEE system logically integrates the boot loader with the trusted execution environment, typically using shared memory regions or security monitoring call interfaces. This allows U-boot to perform key verification and state switching operations within a secure region.

[0062] Specifically, in the secure boot process, the U-boot firmware's parsing of the DTB device tree verifies the digital signature of the hardware configuration description file, preventing address space out-of-bounds errors or peripheral initialization errors caused by malicious tampering of the device tree. The step of loading the bootargs parameters into the kernel restricts the execution permissions of unauthorized code through preset security policy flags in the boot parameters, such as a kernel module loading blacklist or a root filesystem read-only flag. When the kernel image is loaded into RAM, a memory protection unit is used to write-protect the kernel execution area, preventing runtime memory injection attacks from tampering with the kernel code. The integration of the U-boot firmware with the OP-TEE system ensures that the key call operations required for security verification are completed in a trusted execution environment. For example, key decryption services are triggered through security monitoring call instructions, while ARM TrustZone technology isolates the communication paths between the normal and secure areas. This application effectively prevents vulnerabilities that allow bypassing security verification after device tree parameters or the kernel image are tampered with. It ensures the integrity of the kernel runtime code through memory isolation mechanisms and boot parameter constraints, while achieving seamless collaboration between the bootloader and the trusted execution environment at the key management and state switching levels, ensuring trusted linkage between hardware resources and the software environment in the secure boot process.

[0063] S4: The client program of the Ramdisk file system triggers the SMC instruction to call the trusted application, obtains key data from the RPMB partition, and decrypts the Rootfs encrypted container using the key data.

[0064] Specifically, the Ramdisk file system obtains the key data of the RPMB partition through the execution of the client planning program and tee-supplient by the internal initialization program, completes the system decryption operation, and uses switch_root to switch to the rootfs system for standard system boot.

[0065] Please see Figure 5 , Figure 5 A specific implementation method prior to step S4 is shown below in detail:

[0066] S4A: Uses pre-defined tools to build an encrypted container based on the device mapping framework of the Linux system.

[0067] S4B: Place the original EXT4 formatted file system firmware into the encrypted container.

[0068] S4C: Construct the key signature of the encrypted container and generate encrypted firmware to encrypt the Rootfs encrypted container.

[0069] In this context, EXT4 format file system firmware refers to raw data using a journaling file system, retaining full read / write permissions and metadata processing capabilities to maintain normal file operation functionality within the encrypted container. Key signing refers to a digital certificate generated based on an asymmetric encryption algorithm, specifically using RSA-2048 to sign the encrypted container's metadata, used to verify the legitimacy of access to the encrypted container. Encrypted firmware generation refers to encapsulating the file system and encrypted metadata into a single image using a pre-defined toolchain, specifically using the LUKS standard format to construct the encrypted header information and key slot structure.

[0070] Specifically, during the system build phase, an encrypted container is first created using the third-party tool dmsetup based on the Linux feature DeviceMapper. This container establishes a mapping relationship between the block device layer and the physical storage medium. The original EXT4 file system is completely copied into the encrypted container, retaining its standard file read / write interface and log management functions. Then, an RSA key pair is generated using openssl, the metadata header of the encrypted container is digitally signed, and the public key information is burned to a secure storage area. Finally, the mkimage tool packages the encrypted container and the signature information into a single firmware image. This image requires key verification during system startup to complete the mounting operation. When the system is running, the encrypted container achieves transparent access through the kernel-level encryption / decryption module, and the EXT4 file system maintains full write capability. Temporary files generated during the debugging phase can be directly written into the encrypted container without additional storage partitions. This application implements dynamic encryption protection for the Rootfs file system, allowing temporary files to be written into the encrypted container during the debugging phase, avoiding the mandatory isolation requirements of traditional read-only file systems for storage partitions. The encrypted container maintains a complete file operation interface through the standard EXT4 format, and system services can run directly without modifying the write path, reducing the workload of secondary development of storage management components. The key signature mechanism and the secure boot process work together to ensure that the encrypted container can only be decrypted and mounted after it has passed the pre-level verification, thus preventing malicious tampering or unauthorized access during runtime.

[0071] Please see Figure 6 , Figure 6 A specific implementation of step S4 is shown below:

[0072] S41: Start the Ramdisk file system initialization program and execute the client program in the Ramdisk file system.

[0073] S42: The SMC instruction is triggered based on the client program.

[0074] S43: Based on the SMC instruction, the trusted application is invoked from the secure zone to obtain the key data from the RPMB partition of the eMMC.

[0075] S44: Decrypt the Rootfs encrypted container using the key data.

[0076] Trusted applications refer to secure service programs running in a trusted execution environment (secure zone). These can be developed using the OP-TEE framework and are used to perform key acquisition operations in an isolated environment. Replay-protected memory block partitions refer to tamper-proof storage areas in embedded multimedia cards, implemented using the hardware features of eMMC chips, ensuring the integrity and confidentiality of key data. Root file system encrypted containers refer to file system images encapsulated using encryption algorithms, specifically implemented in LUKS format. They require decryption with a key before being mounted as read-write partitions.

[0077] Specifically, during startup, the Ramdisk initializer is first loaded into memory and executes a pre-installed client program. This client program switches the processor state to secure mode by invoking a security monitoring instruction, triggering the execution of a trusted application. The trusted application accesses the replay-protected memory block partition, extracts a pre-stored encryption key, and returns the key to the client program via a secure channel. The client program uses the key to decrypt the root file system encrypted container, converting it into a mountable standard file system format. Throughout this process, key acquisition and decryption are performed in a secure environment; system components in normal mode cannot directly access the key data or interfere with the decryption process.

[0078] Furthermore, after step S41, this application also includes: communicating with the trusted application through a trusted execution environment general interface when executing the client program, performing sensitive data operations in the secure area, and using the general area as a decrypted non-sensitive interface.

[0079] In this embodiment, an OP-TEE trusted execution environment is provided, where OP-TEE provides secure and normal zones for the system. When the client program is executed, it communicates with the trusted application through a general interface of the trusted execution environment. Sensitive data operations are performed in the secure zone, and the normal zone is used as a decrypted, non-sensitive interface. The general interface of the trusted execution environment is the / dev / tee0 device node, which is a session communication channel initiated by the client program with the secure zone. The / dev / teepriv0 device node is a session communication channel initiated by the TA with the normal zone. The client program initiates a call request to an available application in the secure zone through a TEE client interface such as TEEC_InvokeCommand, allowing the available application to perform sensitive data processing and send a response back to the client program.

[0080] Further, step S44 includes: returning the RPMB key information in the key data to the client program through the TEE interface via the trusted application; and decrypting the Rootfs encrypted container using a preset tool based on the key data according to the Ramdisk file system initialization program.

[0081] The default tool is the third-party tool dmsetup. Specifically, during the decryption of the Rootfs encrypted container, the trusted application first accesses the RPMB partition within the secure zone to obtain key data, and then transmits the key information to the client program running in the Ramdisk environment via the TEE interface. The client program calls the default tool to inject the key data into the decryption process, causing the Rootfs encrypted container to be decrypted into a mountable block device in memory. During this process, the reading and transmission of the RPMB key are entirely performed by the trusted application within the secure zone; the ordinary zone can only obtain the path to the decrypted block device through a standardized interface and cannot directly access the original key data. This solution, by confining key operations within a trusted execution environment and standardizing the decryption process using a default tool, ensures the security of the key transmission process while avoiding coupling between the decryption logic and business code.

[0082] S5: After the Rootfs encrypted container is decrypted, the Linux system is started, and the communication isolation between the secure area and the normal area is completed through the OP-TEE system.

[0083] Specifically, after the Rootfs encrypted container is decrypted, this embodiment of the application starts the Linux system, and then completes the communication isolation between the secure area and the normal area through the OP-TEE system.

[0084] In this embodiment, the SPL firmware is signed and verified using the root key stored in the OTP. If the SPL firmware verification passes, the signature information of the Uboot firmware is verified using the OTP key. If the Uboot firmware verification passes, the signature information of the Boot firmware is verified using the OTP key via the OP-TEE system, and the Kernel image, DTB device tree, and Ramdisk file system are loaded. The client program of the Ramdisk file system triggers the SMC instruction to call a trusted application, obtains key data from the RPMB partition, and decrypts the Rootfs encrypted container using the key data. After the Rootfs encrypted container is decrypted, the Linux system is started, and communication isolation between the secure area and the normal area is completed through the OP-TEE system. This embodiment of the invention solves the problems of high firmware tampering risk and insufficient file system flexibility in the prior art by verifying firmware signatures step by step using the OTP key, combining the security isolation mechanism of the OP-TEE system, and the key decryption process based on the RPMB partition, which is beneficial to improving system security.

[0085] Please refer to Figure 7 and Figure 8 This application provides an embodiment of an embedded Linux secure boot system based on RK3568, which is used to implement... Figure 1 The method embodiment shown.

[0086] like Figure 8 As shown, the embedded Linux secure boot system based on RK3568 in this embodiment includes: an RK3568 SoC hardware platform 61, an OP-TEE system 62, a root key storage and firmware packaging module 63, an RPMB partition key storage and decryption module 64, wherein:

[0087] The RK3568 SoC hardware platform 61 is used to run the Linux system; the OP-TEE system 62 is used to divide the system into secure and normal areas; the root key storage and firmware packaging module 63 is used to store the OTP key and package the SPL firmware, the Uboot firmware and the Boot firmware in FIT format; the RPMB partition key storage and decryption module 64 is used to store RPMB key information and decrypt the Rootfs encrypted container.

[0088] Specifically, a Linux system is implemented on the RK3568 SoC to achieve secure boot. The RK3568 SoC provides an OP-TEE trusted execution environment, dividing the system into secure and normal zones. Within the secure zone, ATF (Arm TrustedFirmware) is EL3-level firmware code running on the ARM architecture. It acts as the secure monitor of the OP-TEE system, using the underlying SMC instruction set to isolate and facilitate communication between the secure and normal zones. OP-TEE provides a hardware-level isolated secure execution environment for sensitive data operations, providing the execution environment and data storage for TA programs. Within the normal zone (client application trusted application), the / dev / tee0 device node is a communication channel initiated by the CA (Client Application Trusted) with the secure zone, while the / dev / teepriv0 device node is a communication channel initiated by the TA (Client Application Trusted) with the normal zone. The CA program initiates a call request to the TA program in the secure zone through TEE client interfaces such as TEEC_InvokeCommand, instructing the TA program to perform sensitive data processing and then send a response back to the CA program. Among them, tee-suppl icant is a daemon process running in the normal zone, responsible for handling RPC (Remote Procedure Call) requests from the secure zone and acting as a proxy for the secure zone to process file system resources in the normal zone.

[0089] The RK3568 SoC hardware platform refers to an embedded chipset equipped with an ARM architecture processor and security extension modules. Specifically, it can be implemented using the Rockchip RK3568 chip and its built-in cryptographic coprocessor. This platform provides a hardware-level root of trust and an isolated execution environment for secure boot. The OP-TEE system refers to a trusted execution environment framework based on ARM TrustZone technology. Specifically, it achieves memory isolation by dividing the secure world state from the normal world state, ensuring that key verification operations are performed within a physically protected area. In the OTP storage root key and FIT format firmware packaging module, OTP refers to a one-time programmable memory unit, specifically using an internal fuse array to achieve irreversible key writing; FIT format refers to a flattened mirror tree format, specifically integrating SPL, Uboot, and Boot firmware through a device tree descriptor to generate a hierarchical signature chain. In the RPMB partition key storage and decryption module, RPMB refers to a replay protected memory block partition, specifically utilizing the physical tamper-proof characteristics of the eMMC storage chip and the HMAC-SHA256 authentication protocol to achieve secure key access.

[0090] Specifically, the hardware platform provides the foundation for trusted computing for the system. The OP-TEE system isolates sensitive operations through a secure world state, the OTP module embeds the root key to prevent key leakage, and FIT packaging forms a hierarchical verification relationship between firmware components. During the boot process, the SPL firmware is verified by the OTP key, and then the integrity of the Uboot and Boot firmware is verified sequentially through hierarchical signatures in FIT format. During the loading phase, the OP-TEE system takes over the security verification process and uses the key processing mechanism within the secure area to complete the loading of kernel components. During the file system decryption phase, the RPMB module extracts the key through a physical tamper-proof channel and works with the Ramdisk client program to dynamically decrypt the encrypted container, avoiding the storage path redirection problem caused by using a read-only file system. This application effectively prevents system anomalies caused by firmware tampering during the boot phase. By replacing the read-only file system with an encrypted container, it ensures the integrity and confidentiality of the root file system and avoids the complexity of path redirection during debugging. The collaborative work of the hardware security module and the trusted execution environment ensures that critical operations such as key storage, firmware verification, and file decryption are completed in a physically isolated environment, solving the technical defects of traditional solutions such as easy key leakage and vulnerability of the verification process to side-channel attacks.

[0091] Obviously, the embodiments described above are merely some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the scope of this application. This application can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of protection of this application.

Claims

1. A secure boot method for embedded Linux based on RK3568, characterized in that, include: After the system is powered on, hardware initialization is performed based on the Bootrom firmware, and the root key stored in the OTP is read. The SPL firmware is signed and verified using the root key stored in the OTP. If the SPL firmware verification passes, the signature information of the Uboot firmware is verified using the OTP key. If the Uboot firmware verification passes, the ARM core security state is switched via the OP-TEE system based on SMC instructions. The signature information of the Boot firmware is verified by calling the OTP key in a secure area through a trusted application. Load the kernel image, DTB device tree, and Ramdisk file system; Start the Ramdisk file system initialization program and execute the client program in the Ramdisk file system; The SMC instruction is triggered based on the client program; Based on the SMC instructions, a trusted application is invoked from the secure zone to obtain key data from the RPMB partition of the eMMC; The trusted application returns the RPMB key information in the key data to the client program via the TEE interface. The Ramdisk file system initialization program uses a preset tool to decrypt the Rootfs encrypted container based on the key data. Once the Rootfs encrypted container is decrypted, the Linux system is started, and the communication isolation between the secure area and the normal area is completed through the OP-TEE system.

2. The embedded Linux secure boot method based on RK3568 according to claim 1, characterized in that, Before performing signature verification on the SPL firmware using the root key stored in the OTP, the method further includes: The SPL firmware, the Uboot firmware, and the Boot firmware are packaged using the FIT format; The same set of OTP keys is used to sign the SPL firmware, the Uboot firmware, and the Boot firmware level by level.

3. The embedded Linux secure boot method based on RK3568 according to claim 1, characterized in that, Before the trusted application invokes the OTP key in the secure area to verify the signature information of the Boot firmware, the method further includes: The DTB device tree is parsed through the Uboot firmware, and the DTB device tree and bootargs parameters are loaded into the Linux kernel; Load the Linux kernel image from the storage device into RAM memory; The Uboot firmware is incorporated into the OP-TEE system.

4. The embedded Linux secure boot method based on RK3568 according to claim 1, characterized in that, Before the client program of the Ramdisk file system triggers the SMC instruction to call the trusted application, obtains key data from the RPMB partition, and decrypts the Rootfs encrypted container using the key data, the method further includes: An encrypted container is constructed using a pre-defined tool based on the device mapping framework of the Linux system. Place the original EXT4 formatted file system firmware into the encrypted container; Construct a key signature for the encrypted container and generate encrypted firmware to encrypt the Rootfs encrypted container.

5. The embedded Linux secure boot method based on RK3568 according to claim 1, characterized in that, After starting the Ramdisk file system initialization program and executing the client program in the Ramdisk file system, the method further includes: When the client program is executed, it communicates with the trusted application through the Trusted Execution Environment General Interface, performs sensitive data operations in the secure area, and uses the ordinary area as a decrypted non-sensitive interface.

6. An embedded Linux secure boot system based on RK3568, the system being used to implement the embedded Linux secure boot method based on RK3568 as described in any one of claims 1 to 5, characterized in that, include: The RK3568 SoC hardware platform is used to run the Linux system; The OP-TEE system is used to divide the system into secure areas and normal areas; The root key storage and firmware packaging module is used to store the OTP key and package the SPL firmware, the Uboot firmware and the Boot firmware in FIT format. The RPMB partition key storage and decryption module is used to store RPMB key information and decrypt the Rootfs encrypted container.

Images