Embedded Linux safe starting method and system based on RK3568

Abstract

The invention relates to an embedded Linux safe starting method and system based on RK3568. The method comprises the steps that signature verification is conducted on SPL firmware through a root key stored by OTP; if the verification of the SPL firmware is passed, the OTP key is used to verify the signature information of the Uboot firmware; if the verification of the Uboot firmware is passed, calling an OTP secret key through an OP-TEE system to verify the signature information of the Boot firmware, and loading a Kernel mirror image, a DTB device tree and a Ramdisk file system; triggering an SMC instruction through a client program of the Ramdisk file system to call a trusted application program, obtaining key data from the RPMB partition, and decrypting the Rootfs encryption container through the key data; and after decryption of the Rootfs encryption container is completed, starting the Linux system, and completing communication isolation between the security area and the common area through the OP-TEE system. According to the method, the problems of high firmware tampering risk and insufficient file system flexibility in the prior art are solved, and the system security is improved.

Description

Technical Field

[0001] The present 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 Art

[0002] In embedded Linux systems, the boot process typically includes stages such as bootrom, SPL, UBoot, kernel, and rootfs. However, the existing boot process presents numerous security risks. For example, if the bootrom, the initial boot code, is tampered with, the device will be unable to complete hardware initialization, resulting in the termination of the boot process. The SPL is responsible for loading U-Boot. If the image within its partition is replaced, U-Boot cannot be loaded correctly during the SPL stage. Tampering with the bootcmd environment variable during the U-Boot stage can lead to kernel image loading errors or the loading of unauthorized third-party kernel images. These security risks can cause system startup anomalies, resulting in economic losses in production environments and even endangering personnel and environmental safety.

[0003] Furthermore, arbitrarily deleting or modifying files within the rootfs file system, or injecting illegal software into it, can also pose information security risks. While existing security solutions prevent malicious tampering by formatting the file system as read-only, debuggers cannot modify the file system 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 the embodiments of the present application is to propose an embedded Linux secure boot method and system based on RK3568 to improve the security of the system boot process and prevent firmware tampering.

[0005] In order to solve the above technical problems, the embodiment of the present application provides an embedded Linux secure boot method based on RK3568, including:

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

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

[0008] If the Uboot firmware passes the verification, 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] Triggering the SMC instruction to call the trusted application through the client program of the Ramdisk file system, obtaining the key data from the RPMB partition, and decrypting the Rootfs encrypted container through the key data;

[0010] When 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] In order to solve the above technical problems, the embodiments of the present application provide an embedded Linux secure boot system based on RK3568, which is used to implement any of the above-mentioned embedded Linux secure boot methods based on RK3568, including:

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

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

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

[0015] RPMB partition key storage and decryption module, used to store RPMB key information and decrypt Rootfs encrypted containers.

[0016] The embodiment of the present invention provides an embedded Linux secure boot method and system based on RK3568. The method includes: performing signature verification on the SPL firmware through the root key stored in the OTP; if the SPL firmware passes the verification, the signature information of the Uboot firmware is verified using the OTP key; if the Uboot firmware passes the verification, the OTP key is called by 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; the client program of the Ramdisk file system triggers the SMC instruction to call the trusted application, obtains the key data from the RPMB partition, and decrypts the Rootfs encrypted container through the key data; when the Rootfs encrypted container is decrypted, the Linux system is started, and the communication isolation between the secure area and the ordinary area is completed through the OP-TEE system. The embodiment of the present invention solves the problems of high firmware tampering risk and insufficient file system flexibility in the prior art by verifying the firmware signature step by step through 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 conducive to improving system security. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the solutions in this application, a brief introduction will be given below to the drawings required for use in the description of the embodiments of this application. Obviously, the drawings described below are some embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

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

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

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

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

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

[0023] Figure 6 This is a flowchart for implementing another sub-process in the RK3568-based embedded Linux secure boot method provided in an embodiment of the present application;

[0024] Figure 7 Schematic diagram of an embedded Linux secure boot system based on RK3568 provided in an embodiment of the present application;

[0025] Figure 8 This is a block diagram of an implementation of an embedded Linux secure boot system based on RK3568 provided in an embodiment of the present application. DETAILED DESCRIPTION

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meanings as commonly understood by those skilled in the art to which this application belongs. The terms used in the specification of the application are for the purpose of describing specific embodiments only and are not intended to limit this application. The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. The terms "first", "second", etc. in the specification and claims of this application or the above-mentioned drawings are used to distinguish different objects, not to describe a specific order.

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

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

[0029] Existing technologies present security risks at multiple stages in the embedded Linux system boot process. Tampering with the firmware at any stage during the boot process, from bootrom to kernel, will cause system boot failure. Existing protection methods rely on static verification mechanisms, which are unable to address malicious code injection in intermediate stages. File system security protection typically uses a read-only format. While this prevents runtime tampering, it limits debugging and maintenance flexibility and fails to protect against data theft at the storage media level.

[0030] To address these issues, we observed trust transfer failures at various stages of system startup, necessitating the establishment of a continuous security verification mechanism. To address the issue of insufficient key storage security, we discovered that OTP memory offers physical tamper resistance. We also noted that the security extensions of the ARM architecture are underutilized, and that a TEE environment can isolate sensitive operations. Regarding file system encryption, existing solutions rely on fixed key storage, making them vulnerable to physical attacks. Dynamic key management requires the integration of secure partitions.

[0031] Therefore, this application proposes an embedded Linux secure boot method based on RK3568, including: verifying the signature of the SPL firmware through the root key stored in OTP; if the SPL firmware passes the verification, the OTP key is used to verify the signature information of the Uboot firmware; if the Uboot firmware passes the verification, the OTP key is called by 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; the SMC instruction is triggered by the client program of the Ramdisk file system to call the trusted application, obtain the key data from the RPMB partition, and decrypt the Rootfs encrypted container through the key data; when the Rootfs encrypted container is decrypted, the Linux system is started, and the communication isolation between the secure area and the ordinary area is completed through the OP-TEE system.

[0032] The root key stored in the OTP refers to the encryption key burned into the chip's one-time programmable memory. Specifically, the SHA-256 algorithm is used to generate the key pair, leveraging the physical tamper-resistant nature of the OTP memory to ensure key security. Stage-by-stage verification involves chained verification of the SPL, Uboot, and Boot firmware in the boot sequence, implemented using the RSA-2048 signature algorithm. This ensures that the previous stage of verification passes before the next stage of firmware can be loaded. The OP-TEE system is a trusted execution environment based on the ARM TrustZone architecture. By dividing the secure world and the normal world into two hardware-isolated domains, key verification operations are restricted to the secure world. The RPMB partition is the replay-resistant secure partition of the eMMC storage chip, using the AES-128-GCM encryption algorithm to store key data, with access control implemented by the chip controller. The Rootfs encrypted container is an encrypted file system container built using dm-crypt technology. It uses the LUKS format to encapsulate the original file system, and the decryption key is only retrieved from the secure world at runtime.

[0033] Specifically, after the system is powered on, the integrity of the SPL firmware is first verified using the OTP key, forming the initial trust anchor. Digital signatures must be verified before loading each level of firmware to ensure no unauthorized code injection. After the Uboot stage completes, the processor is switched to a secure state via an SMC instruction, and OP-TEE takes over the Boot firmware verification process. After the Ramdisk is booted, its client program triggers a trusted application through a security monitoring call to extract 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 normal areas, preventing sensitive data such as keys from being exposed to the normal operating system environment. This application effectively prevents system crashes caused by firmware tampering during the boot phase and ensures the integrity of code execution at all stages. The key management system protects against physical and software attacks, ensuring the security of the file system decryption process. The trusted execution environment isolates sensitive operations at runtime, preventing the risk of malicious programs from obtaining key data in user space. The dynamic decryption mechanism ensures the file system's tamper resistance while supporting legitimate system maintenance operations.

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

[0035] See also Figure 1 and Figure 2 , Figure 1 A specific implementation of the embedded Linux secure boot method based on RK3568 is shown. Figure 2 This is a flowchart of the implementation process of the embedded Linux secure boot method based on RK3568 provided in the embodiment of the present application.

[0036] It should be noted that the method of the present invention is not limited to the method of Figure 1 The process sequence shown is limited to the following steps:

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

[0038] Specifically, the RK3568 SoC solution is adopted in hardware to provide the OP-TEE trusted execution environment, wherein OP-TEE is an open source execution environment designed specifically for security, providing the system with secure and normal areas. OP-TEE will create a lightweight operating system in the UBoot phase, which is the OP-TEE in this application. Among them, multiple trusted applications (TAs) can be loaded and run in the secure area, such as data management, secure payment services, etc. The client program (CA) running in the normal area needs to trigger the SMC (Secure Monitor Call) instruction to the OP-TEE system to switch to the secure world in order to communicate with the TA program and call the TA to perform sensitive data operations. Among them, SMC is a privileged instruction in the ARM architecture, which realizes the switching between the secure state and the non-secure state of the ARM core. Trusted applications can only be transmitted and stored in the secure area, realizing the isolation of secure and normal area memories, and ensuring the information security of sensitive data in transmission and storage.

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

[0040] Furthermore, step S1 includes: when 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, BootROM is the first firmware code executed when the system is powered on. This firmware code is located inside the CPU and generally performs SoC-level hardware initialization to provide an operating environment for subsequent loaded programs. The firmware signature information of the next stage, SPL, is verified by reading the OTP key.

[0042] The root key stored in the OTP refers to the key data stored inside the chip through a one-time programmable memory. Specifically, a physical fuse mechanism can be used to ensure that the key cannot be modified after it is written, thereby physically preventing the key from being tampered with or replaced. Hardware initialization refers to the basic configuration of the processor core, memory controller, and peripheral interfaces. Specifically, the clock frequency setting, memory address mapping, and security register configuration can be achieved by executing the initialization code preset in the BootROM, thus establishing a trusted hardware operating environment for subsequent verification.

[0043] Specifically, after the system is powered on, the Bootrom code solidified in the chip ROM is first run to complete the processor core state setting and memory controller initialization, ensuring that subsequent operations are performed in the correct hardware environment. Subsequently, the OTP storage area is accessed to extract the root key that has been written by the fuse. When the key is generated, an asymmetric encryption algorithm is used to generate a public-private key pair. The public key is used to verify the digital signature of the SPL firmware. The signature data of the SPL image is verified by calling the cryptographic algorithm engine. If the hash value matches the public key decryption result, the firmware is determined to be complete and trustworthy. This process builds a hardware-level trust chain at the earliest stage of the boot process, effectively blocking the possibility of tampered SPL firmware being loaded and executed.

[0044] See also Figure 3 , Figure 3 A specific implementation method before step S1 is shown, which is described in detail as follows:

[0045] S1A: The SPL firmware, the Uboot firmware, and the Boot firmware are packaged in a FIT format.

[0046] S1 B: Use the same set of OTP keys to sign the SPL firmware, the Uboot firmware, and the Boot firmware step by step.

[0047] Among them, the FIT format refers to a firmware image packaging format based on the device tree structure. Specifically, the Flattened Image Tree technology can be used to integrate multiple firmware components into a single image file. Its tree data structure supports multi-node configuration and integrity verification. This format solves the problem of difficult detection of tampering of a single firmware in traditional distributed storage through a unified storage structure and verification mechanism. Among them, the OTP key refers to the cryptographic root key stored in a one-time programmable memory. Specifically, a key pair generated by the elliptic curve digital signature algorithm can be used to achieve tamper-proof storage through a hardware fuse mechanism. This key serves as the starting point of the trust chain and provides a unified cryptographic basis for step-by-step signatures, avoiding the risk of trust chain breaks caused by multiple key management.

[0048] Specifically, during the system construction 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 in the image, and the node contains a hash value and signature data field. The OTP key performs a step-by-step signature operation on the firmware content of each node: first, the signature of 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, and finally the Boot firmware and the first two levels of signature data are used together to generate a third-level signature. During the startup process, before each firmware is loaded, it is necessary to verify whether the signature of its corresponding node matches the OTP key, forming a chain verification structure from the bottom layer to the upper layer.

[0049] Traditional embedded systems use independent storage for firmware files and use different key signatures. There are problems such as tampering with a single file is difficult to detect and complex key management leads to security vulnerabilities. This application uses the FIT format to implement centralized management and a unified verification mechanism for firmware. Combined with the cascade signature method of a single OTP key, a strong correlation verification relationship is established between firmware, so that tampering at any level will destroy the overall signature chain, significantly increasing the difficulty for attackers to implement partial tampering. This application implements holistic protection of the firmware storage structure, ensuring the integrity and source authenticity of the firmware at each startup stage; constructs a trust transfer mechanism based on cryptographic root keys, so that the verification of each firmware inherits the trust basis of the previous stage; effectively defends against local attacks on a single firmware or signature mechanism, and solves the security risks caused by loose packaging and multi-key verification.

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

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

[0052] S3: If the Uboot firmware passes the verification, 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 Uboot firmware code, located in the external eMMC, is responsible for parsing the DTB device tree, passing the boot parameters (bootargs), and loading the Linux kernel image from the storage device into RAM. The OP-TEE system, integrated into the Uboot firmware, reads the OTP key to verify the signature of the next-stage boot firmware. The boot firmware code, located in the external eMMC, contains the kernel image, the DTB device tree binary data, and a Ramdisk file system.

[0054] See also Figure 4 , Figure 4 A specific implementation of step S3 is shown, which is described in detail as follows:

[0055] S31: If the Uboot firmware passes the verification, the OP-TEE system switches the ARM core security state 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 is 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 the secure and normal zones. The SMC instruction is a security monitoring call instruction in the ARM architecture. It can be triggered by writing assembly instructions to switch the ARM core from the normal to the secure state. Trusted applications are protected programs running in the secure zone. They can access OTP keys through the TEE's internal API, preventing the keys from being exposed in the normal zone. OTP keys are one-time programmable encryption keys that can be stored using the OTP storage unit built into the RK3568 chip, ensuring they cannot be tampered with. A kernel image is a Linux kernel binary file that can be loaded in zImage or Image format and used to boot the core operating system functions. A DTB device tree is a structured data file describing hardware configuration information that can be parsed and passed to the kernel by the Uboot firmware. A ramdisk file system is a temporarily mounted initial memory file system that can be constructed in cpio format to provide a temporary environment for decrypting the root file system.

[0059] Specifically, after the Uboot phase verification passes, the system triggers an ARM core state switch by executing an SMC instruction, allowing subsequent operations to be executed in the secure area. In the secure area, the trusted application uses the key stored in the OTP to verify the digital signature of the Boot firmware. This verification process is completely isolated from the normal area. After successful verification, the system sequentially loads the verified Kernel image, the DTB device tree that accurately describes the hardware topology, and the Ramdisk file system containing the decryption tools. During this process, the integrity of the Kernel image is guaranteed by the digital signature. The loading of the DTB device tree ensures that the hardware initialization parameters have not been tampered with. The Ramdisk file system provides a controlled execution environment for subsequent root file system decryption operations. The loading order of these three components follows the embedded system's boot dependencies. After the Kernel image is booted, the Ramdisk file system is immediately mounted, forming a complete chain of trust from the hardware abstraction layer to the application layer. This application achieves secure isolation of the Boot firmware verification process, preventing key leakage and bypass attacks on the verification logic. The synergy between the trusted execution environment and the ARM core state switch ensures that critical verification operations are completed in a secure area protected by hardware. At the same time, the integrity check of the kernel image and device tree eliminates malicious code injection from the root. The secure loading of the Ramdisk file system builds a trusted basic environment for subsequent encrypted file system decryption, forming a security protection system covering the entire startup process.

[0060] Furthermore, before step S32, the present application also 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 the RAM memory; and incorporating the Uboot firmware into the OP-TEE system.

[0061] Among them, the DTB device tree refers to a structured data file that describes the hardware resource configuration. It can be implemented in a flat device tree format and is used to define the processor type, peripheral address space, and memory mapping relationship. It ensures the integrity and legitimacy of the hardware configuration by parsing the device tree during the secure boot process. The bootargs parameter refers to the boot configuration information passed to the kernel. It can be implemented in the form of a string parameter. By loading the parameter into the kernel, the resource access rights during kernel initialization can be constrained. RAM memory loading refers to copying the kernel image in the storage medium to the physical memory. It can be implemented by a DMA controller or CPU direct addressing. This operation prevents the runtime image from being tampered with through a physical memory access isolation mechanism. The integration of Uboot firmware into the OP-TEE system refers to the logical integration of the boot loader and the trusted execution environment. It can be implemented by a shared memory area or a security monitoring call interface, so that Uboot can perform key verification and state switching operations in the secure area.

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

[0063] S4: triggering an 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 through the key data.

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

[0065] See also Figure 5 , Figure 5 A specific implementation method before step S4 is shown, which is described in detail as follows:

[0066] S4A: Use preset tools to build an encrypted container based on the device mapping framework of the Linux system.

[0067] S4B: Put the original EXT4 format file system firmware into the encrypted container.

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

[0069] EXT4-formatted file system firmware refers to the raw data of a journaled file system, retaining full read and write permissions and metadata processing capabilities, and is used to maintain normal file operations within the encrypted container. Key signatures refer to digital certificates generated using an asymmetric encryption algorithm. Specifically, RSA-2048 can be used to sign encrypted container metadata and verify the legitimacy of encrypted container access. Encrypted firmware generation involves encapsulating the file system and encrypted metadata into a single image using a pre-set toolchain. Specifically, the LUKS standard format can be used to construct the encryption 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 with the physical storage medium at the block device layer. The original EXT4 file system is fully copied into the encrypted container, retaining its standard file read and write interfaces and log management functions. An RSA key pair is then generated using openssl, the encrypted container's metadata header is digitally signed, and the public key information is burned to a secure storage area. Finally, the encrypted container and the signed information are packaged together using the mkimage tool to generate a single firmware image. This image requires key verification before it can be mounted during system startup. During system operation, the encrypted container is transparently accessed through the kernel-level encryption and decryption modules. The EXT4 file system maintains full write capabilities, and temporary files generated during debugging can be written directly into the encrypted container without requiring 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 debugging, avoiding the mandatory isolation of storage partitions required by traditional read-only file systems. The encrypted container maintains a complete file operation interface using the standard EXT4 format, allowing system services to run directly without modifying the write path, reducing the secondary development workload of the storage management component. The key signing mechanism forms a linkage verification with the secure boot process to ensure that the encrypted container can only be decrypted and mounted in an environment that has completely passed the previous level verification, preventing malicious tampering or illegal access during runtime.

[0071] See also Figure 6 , Figure 6 A specific implementation of step S4 is shown, which is described in detail as follows:

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

[0073] S42: Triggering the SMC instruction based on the client program.

[0074] S43: Based on the SMC instruction, the trusted application is called from the secure area, and the key data is obtained from the RPMB partition of the eMMC.

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

[0076] Among them, trusted applications refer to security service programs running in a trusted execution environment (secure area). Specifically, they can be developed through the OP-TEE framework and used to perform key acquisition operations in an isolated environment. Replay-protected memory block partitions refer to storage areas with tamper-proof features in embedded multimedia cards. Specifically, they can be implemented through the hardware characteristics of the eMMC chip and can ensure the integrity and confidentiality of key data. The root file system encrypted container refers to a file system image encapsulated using an encryption algorithm. Specifically, it can be implemented in the LUKS format and must be decrypted with a key before it can be mounted as a read-write partition.

[0077] Specifically, during the boot process, the Ramdisk initialization program is first loaded into memory and the pre-installed client program is executed. This client program switches the processor state to secure mode by calling security monitoring instructions, triggering the execution of the trusted application. The trusted application accesses the replay-protected memory block partition, extracts the pre-stored encryption key, and returns the key to the client program through a secure channel. The client program uses the key to decrypt the root file system encrypted container and convert it into a standard mountable file system format. During this process, key acquisition and decryption operations are completed in a secure environment, and system components in normal mode cannot directly access the key data or interfere with the decryption process.

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

[0079] In an embodiment of the present application, an OP-TEE trusted execution environment is provided, wherein OP-TEE provides a secure and normal area for the system. When executing the client program, communication is performed with the trusted application through the trusted execution environment universal interface, sensitive data operations are performed in the secure area, and the normal area is used as a decrypted non-sensitive interface. Among them, the trusted execution environment universal interface is the / dev / tee0 device node, which is a session communication channel initiated by the client program with the secure area. The / dev / teepriv0 device node is a session communication channel initiated by the TA with the normal area. The client program initiates a call request to the available application in the secure area through the TEE client interface such as TEEC_InvokeCommand, allowing the available application to perform sensitive data processing and complete sending a response to the client program.

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

[0081] Among them, the preset tool is a third-party tool dmsetup. Specifically, in the process of decrypting the Rootfs encrypted container, the trusted application first accesses the RPMB partition in the secure area to obtain the key data, and then transmits the key information to the client program running in the Ramdisk environment through the TEE interface. The client program calls the preset tool to inject the key data into the decryption process, so that the Rootfs encrypted container is decrypted in the memory as a mountable block device. In this process, the reading and transfer operations of the RPMB key are completely performed by the trusted application in the secure area. The ordinary area can only obtain the decrypted block device path through the standardized interface and cannot directly access the original key data. This solution limits key operations to the trusted execution environment and uses preset tools to standardize the decryption process, which not only ensures the security of the key transfer process, but also avoids the coupling of 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, the embodiment of the present application starts the Linux system, and then completes the communication isolation between the secure area and the ordinary area through the OP-TEE system.

[0084] In an embodiment of the present application, the SPL firmware is signed and verified by the root key stored in the OTP; if the SPL firmware passes the verification, the signature information of the Uboot firmware is verified using the OTP key; if the Uboot firmware passes the verification, the OTP key is called by 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; the SMC instruction is triggered by the client program of the Ramdisk file system to call the trusted application, obtain the key data from the RPMB partition, and decrypt the Rootfs encrypted container through the key data; when the Rootfs encrypted container is decrypted, the Linux system is started, and the communication isolation between the secure area and the ordinary area is completed through the OP-TEE system. The embodiment of the present invention verifies the firmware signature step by step through the OTP key, combines the security isolation mechanism of the OP-TEE system and the key decryption process based on the RPMB partition, solves the problems of high firmware tampering risk and insufficient file system flexibility in the prior art, and is conducive 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 of this embodiment includes: RK3568 SoC hardware platform 61, OP-TEE system 62, root key storage and firmware packaging module 63, RPMB partition key storage and decryption module 64 and RPMB partition key storage and decryption module 64, wherein:

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

[0088] Specifically, a Linux system is installed on the RK3568 SoC to achieve secure boot. The RK3568 SoC provides an OP-TEE trusted execution environment (TEE) that divides the system into secure and normal zones. Within the secure zone, ATF (Arm Trusted Firmware) is firmware code running at the ARM architecture's EL3 level. It serves as the OP-TEE system's secure monitor, implementing isolation and communication between the secure and normal zones through low-level SMC instructions. OP-TEE provides a hardware-isolated secure execution environment for sensitive data operations, providing an execution environment and data storage for the client application (TA). Within the normal zone (client application trusted application), the / dev / tee0 device node is a communication channel initiated by the CA (CA) with the secure zone, and the / dev / teepriv0 device node is a communication channel initiated by the TA (TA) 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, allowing the TA program to perform sensitive data processing and then send a response to the CA program. Among them, tee-suppl icant is a daemon process running in the common area, responsible for processing RPC (Remote Procedure Call) requests in the secure area and acting as a proxy for the secure area to process file system resources in the common area.

[0089] The RK3568 SoC hardware platform refers to an embedded chipset equipped with an ARM architecture processor and a security extension module. 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 isolated execution environment for secure boot. The OP-TEE system is a trusted execution environment framework based on ARM TrustZone technology. Specifically, it achieves memory isolation by partitioning the secure world state from the normal world state, ensuring that key verification operations are performed within a physically protected area. In the OTP root key storage and FIT format firmware packaging module, OTP refers to a one-time programmable memory unit (OTP), which uses the chip's internal fuse array to enable irreversible key writes. The FIT format refers to a flattened image tree format that integrates SPL, Uboot, and Boot firmware through device tree descriptors and generates a hierarchical signature chain. In the RPMB partition key storage and decryption module, RPMB refers to a replay-protected memory block partition, which leverages the physical tamper-proof properties of the eMMC storage chip and the HMAC-SHA256 authentication protocol to ensure secure key access.

[0090] Specifically, the hardware platform provides the trusted computing foundation for the system. The OP-TEE system isolates sensitive operations through the secure world state. The OTP module secures the root key to prevent key leakage, and the FIT package establishes a hierarchical verification relationship between firmware. During the boot process, the SPL firmware is authenticated by the OTP key, and the integrity of the Uboot and Boot firmware is subsequently verified using hierarchical signatures in the FIT format. During the loading phase, the OP-TEE system takes over the security verification process, utilizing the key handling mechanism within the secure zone to load kernel components. During the file system decryption phase, the RPMB module extracts the key through a physical tamper-proof channel and cooperates with the Ramdisk client program to dynamically decrypt the encrypted container, avoiding the storage path redirection issues associated with read-only file systems. 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 not only ensures the integrity and confidentiality of the root file system but also avoids the complexity of path redirection during debugging. The collaborative work of the hardware security module and the trusted execution environment ensures that key storage, firmware verification, and file decryption are performed in a physically isolated environment, addressing the technical shortcomings of traditional solutions that are prone to key leakage and verification processes being vulnerable to side-channel attacks.

[0091] Obviously, the embodiments described above are only some of the embodiments of the present application, rather than all of the embodiments. The preferred embodiments of the present application are given in the accompanying drawings, but they do not limit the scope of the present application. The present application can be implemented in many different forms. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present application more thorough and comprehensive. Although the present application has been described in detail with reference to the aforementioned embodiments, for those skilled in the art, it is still possible to modify the technical solutions described in the aforementioned specific embodiments, or to make equivalent replacements for some of the technical features therein. Any equivalent structure made using the contents of the present application specification and the accompanying drawings, directly or indirectly used in other related technical fields, is also within the scope of protection of the present application.

Claims

1. A secure boot method for embedded Linux based on RK3568, characterized in that: include: The SPL firmware is signed and verified using the root key stored in the OTP. If the SPL firmware passes the verification, the signature information of the Uboot firmware is verified using the OTP key; If the Uboot firmware passes the verification, the OTP key is called by 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; Triggering the SMC instruction to call the trusted application through the client program of the Ramdisk file system, obtaining the key data from the RPMB partition, and decrypting the Rootfs encrypted container through the key data; When 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: The signature verification of the SPL firmware using the root key stored in the OTP includes: When the system is powered on, the hardware is initialized 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.

3. 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 in FIT format; The SPL firmware, the Uboot firmware, and the Boot firmware are signed step by step using the same set of OTP keys.

4. The embedded Linux secure boot method based on RK3568 according to claim 1, characterized in that: If the Uboot firmware passes the verification, the OTP key is called by 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, including: If the Uboot firmware passes the verification, the OP-TEE system switches the ARM core security state based on the SMC instruction; Verify the signature information of the Boot firmware by calling the OTP key in the secure area through the trusted application; The kernel image, the DTB device tree and the Ramdisk file system are loaded.

5. The RK3568-based embedded Linux secure boot method according to claim 4, characterized in that: Before the trusted application program calls the OTP key in the secure area to verify the signature information of the Boot firmware, the method further includes: Parsing the DTB device tree through the Uboot firmware, and loading the DTB device tree and bootargs parameters into the Linux kernel; Load the Linux kernel image from the storage device into RAM memory; Incorporate the Uboot firmware into the OP-TEE system.

6. The RK3568-based embedded Linux secure boot method according to claim 1, wherein: The client program of the Ramdisk file system triggers an SMC instruction to call a trusted application, obtains key data from the RPMB partition, and before decrypting the Rootfs encrypted container using the key data, the method further includes: Using a preset tool to build an encrypted container according to the device mapping framework of the Linux system; Put the original EXT4 format file system firmware into the encrypted container; A key signature of the encrypted container is constructed, and encryption firmware is generated to encrypt the Rootfs encrypted container.

7. The RK3568-based embedded Linux secure boot method according to any one of claims 1 to 6, characterized in that: The client program of the Ramdisk file system triggers the SMC instruction to call the trusted application, obtains the key data from the RPMB partition, and decrypts the Rootfs encrypted container by using the key data, including: Starting the Ramdisk file system initialization program and executing the client program in the Ramdisk file system; Triggering the SMC instruction based on the client program; Calling the trusted application from the secure area based on the SMC instruction, and obtaining the key data from the RPMB partition of the eMMC; The Rootfs encrypted container is decrypted using the key data.

8. The RK3568-based embedded Linux secure boot method according to claim 7, 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 executing the client program, the client program communicates with the trusted application through the trusted execution environment universal interface, performs sensitive data operations in the secure area, and uses the common area as a decrypted non-sensitive interface.

9. The RK3568-based embedded Linux secure boot method according to claim 7, characterized in that: Decrypting the Rootfs encrypted container using the key data includes: Returning the RPMB key information in the key data to the client program through the TEE interface by the trusted application; Decrypt the Rootfs encrypted container according to the key data using a preset tool according to the Ramdisk file system initialization program.

10. 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 claimed in any one of claims 1 to 9, characterized in that: include: RK3568 SoC hardware platform, used to run the Linux system; OP-TEE system, used to divide the system into secure and normal areas; A root key storage and firmware packaging module, used to store the OTP key and package the SPL firmware, the Uboot firmware and the Boot firmware in FIT format; RPMB partition key storage and decryption module, used to store RPMB key information and decrypt Rootfs encrypted containers.

Images