A flexible configuration secure boot device and method

Abstract

The application provides a flexible configuration security starting device and method, the device comprises: a firmware signature module, which is used for signing a user-specified partition or signing in an address size manner; a data writing module, which is used for writing OTP data into an ARM processor, wherein writing the OTP data into the ARM processor realizes writing of user-required parsed signature data into an OTP module according to a uboot working mode or a system working mode of the ARM processor; and a chip starting module, which is used for acquiring writing of the OTP data and signature of a firmware program, writing the signed firmware program into the ARM processor, and realizing security starting of the ARM processor during starting. The application can realize efficient and flexible firmware program signature, simple and efficient integration of writing of OTP module data, greatly improve work efficiency, and reduce complexity of use of the OTP function.

Description

Technical Field

[0001] This invention relates to the field of processor technology, and more specifically to a flexibly configurable secure boot device and method. Background Technology

[0002] ARM processors are widely used across various industries, such as in the server field, where they serve as BMCs for monitoring and managing servers. With the widespread adoption of ARM processors, system security requirements have become increasingly stringent, leading to significantly higher demands on the data integrity and security of data running on ARM processors. Modern mainstream Windows systems support Secure Boot, and the development of embedded systems has also introduced this feature, making support and maintenance tools for Secure Boot particularly important.

[0003] Currently, OTP programmers provided by chip manufacturers can only be used for programming in certain system modes (such as MaskROM), and must be programmed using dedicated software. Meanwhile, existing signing tools can only sign fixed partitions and have strict requirements on the data to be signed in the firmware program and the location of the signature. These tools cannot add new partitions for signing, nor can they customize the signature or the location of the signature data in the firmware program, which hinders flexible product configuration and development.

[0004] Therefore, to address this problem, a more optimized and flexibly configurable safety start-up device and method are needed. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide an improved, flexibly configurable safety start device and method.

[0006] Currently, OTP programmers provided by chip manufacturers can only program in certain system modes (such as MaskROM) and require dedicated software. Furthermore, existing signing tools are limited to signing fixed partitions and have strict requirements on the data to be signed and the location of the signature in the firmware program. These tools cannot sign fixed partitions, add new partitions, customize signatures, or specify the location of the signature data in the firmware program, hindering flexible product configuration and development. Therefore, to address these issues, a more efficient and flexible secure boot device and method are needed. This device includes a firmware signing module for signing user-specified partitions or signing them based on address size; a data writing module for writing OTP data to the ARM processor, where the OTP data is written to the OTP module according to the ARM processor's uboot or system operating mode; and a chip boot module for acquiring the OTP data and firmware program signature, writing the signed firmware program to the ARM processor, and enabling secure booting from the ARM processor. This invention overcomes the limitations of OTP signature burning tools, supports direct burning of signature files under uboot and system, and supports signature of generated firmware programs by partition and custom signature location, size and storage location of signature results.

[0007] The advantage of this implementation is that when signing firmware programs, the number, location, and size of signatures can be flexibly increased according to project needs. When writing to OTP, it is not limited by the CPU's operating mode; that is, it can be directly flashed using an OTP writing tool in common u-boot or system operating modes.

[0008] To achieve the above objectives, in one respect, the present invention provides a flexibly configurable safe startup device, the flexibly configurable safe startup device comprising:

[0009] The firmware signing module is used to sign user-specified partitions or to sign them based on address size.

[0010] The data writing module is used to write OTP data to the ARM processor. Specifically, writing OTP data to the ARM processor is implemented by writing the parsed signature data that the user needs to write into the OTP module according to the uboot working mode or system working mode of the ARM processor.

[0011] The chip boot module is used to acquire OTP data and sign the firmware program. The signed firmware program is then written into the ARM processor, enabling secure booting of the ARM processor.

[0012] In some embodiments of the flexible configuration secure boot device according to the present invention, the firmware signing module includes:

[0013] The signing tool configuration unit is used to provide the signing configuration file.

[0014] In some embodiments of the flexible configuration secure boot device according to the present invention, the firmware signing module further includes:

[0015] The signature execution unit obtains the signature configuration file data, parses the configuration file data, and dynamically performs the signing of the partitions that need to be signed.

[0016] Another aspect of the present invention provides a flexible configuration secure boot method, which specifically includes:

[0017] Sign the user-specified partition or sign it according to address size, and perform firmware signing.

[0018] Obtain firmware signature data, and write the data that the user needs to parse and sign into the OTP module according to the uboot working mode or system working mode of the ARM processor;

[0019] The process involves acquiring OTP data and signing the firmware program, then writing the signed firmware program into the ARM processor, enabling secure booting of the ARM processor.

[0020] In some embodiments of the flexible configuration secure boot method according to the present invention, the method of signing the user-specified partition or signing it according to address size to perform firmware signing specifically includes:

[0021] Extract configuration file database;

[0022] Different partition addresses and the corresponding signature positions for each partition can be specified through configuration files. The configuration files contain the starting address, size, and ending address of the signature data.

[0023] The firmware signing tool identifies the file to be signed by parsing the configuration file, as well as its starting position and size in the firmware program. It then calculates the signature data using a signature algorithm and writes it to the location specified in the configuration file, thus completing the signing of the firmware program.

[0024] In some embodiments of the flexible configuration secure boot method according to the present invention, the method further includes: calculating signature data using a signature algorithm based on SHA256 or RSA2048.

[0025] In some embodiments of the flexible configuration secure boot method according to the present invention, the method of writing to the location specified in the configuration file to store signature data to complete the signing of the firmware program specifically includes:

[0026] Parse the configuration file;

[0027] Determine if the configuration file has been signed for all partitions. If it has, end the configuration parsing process; otherwise, proceed to the next step.

[0028] Check if the file exists in the corresponding path. If it exists, proceed to the next step. Otherwise, calculate the signature value based on the StartAddr and MaxSize of the ima file.

[0029] Calculate file size;

[0030] Check if the file size has exceeded the maximum value. If so, report a signing failure and end the signing process. If not, proceed to the next step.

[0031] The hash value of the file is calculated based on the SHA algorithm;

[0032] Sign the hash value using the RASA private key;

[0033] Check if the signature result has been written to the corresponding SignatureStartAddr. If it has, end the signature process. Otherwise, execute the steps above to check if the configuration file has been signed and complete all partitions.

[0034] In some embodiments of the flexible configuration secure boot method according to the present invention, the method of writing the data to be parsed and signed by the user into the OTP module according to the uboot working mode or system working mode of the ARM processor specifically includes:

[0035] Obtain the public key's PEM file, which is a binary file named public.bin;

[0036] Determine if the detection device is online. If yes, proceed to the next step. If not, prompt for writing device wiring and end the writing process.

[0037] Send TCP data packets and wait for a TCP response;

[0038] Parse TCP response data to obtain running status;

[0039] Analyze the running status and determine the running status;

[0040] Obtain the running status result. If it is running in uboot, copy the tfip command or tcp to public.cin into memory.

[0041] Execute the uboot otp write command to complete the writing of OTP data;

[0042] Execute the OTP command to enable the OTP module. A message will indicate that the OTP function has been successfully enabled, and the writing process will end.

[0043] In some embodiments of the flexible configuration secure boot method according to the present invention, the method of writing the data to be parsed and signed by the user into the OTP module according to the uboot working mode or system working mode of the ARM processor further includes:

[0044] Obtain the running status result. If it is running on the system, use the scp or tcp command to copy public.cin to the device.

[0045] Check if the file public.cin exists. If not, indicate that no file was detected and end the writing process.

[0046] If so, the OTP control process is invoked to write the OTP data;

[0047] Send a TCP command to enable the OTP module;

[0048] The OTP control process is invoked to enable the OTP module, indicating that the OTP function has been successfully enabled, and the writing process ends.

[0049] In some embodiments of the flexible configuration secure boot method according to the present invention, the method of acquiring OTP data writing and firmware program signing, writing the signed firmware program into the ARM processor, and enabling secure boot of the ARM processor upon power-on specifically includes:

[0050] After the ARM processor powers on, it performs a secure boot process through a step-by-step verification procedure to ensure that the running program has not been modified. If the verification is successful, the process can proceed step by step. If an error occurs during the process, it will stop at that stage and will not proceed to the next level.

[0051] The present invention has at least the following beneficial technical effects: the present invention can realize efficient and flexible firmware program signing, simple and easy-to-use and efficient integration of OTP module data writing, greatly improve work efficiency and reduce the complexity of using OTP function. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other embodiments can be obtained based on these drawings without creative effort.

[0053] In the diagram:

[0054] Figure 1 A schematic diagram of the structure of the flexible configuration safety start device according to the present invention is shown;

[0055] Figure 2 A schematic diagram of a flexibly configurable firmware signing module according to the present invention is shown.

[0056] Figure 3 A schematic diagram illustrating the implementation flow of the flexible configuration secure boot method according to the present invention is shown;

[0057] Figure 4 This diagram illustrates the implementation flow of the firmware signing method, which involves signing a user-specified partition or signing it based on address size.

[0058] Figure 5 This diagram illustrates the implementation process of writing signature data to the location specified in the configuration file to complete the firmware signing method.

[0059] Figure 6 This diagram illustrates the implementation flow of a method for writing the parsed signature data required by the user into the OTP module, depending on the uboot or system operating mode of the ARM processor.

[0060] Figure 7 A schematic diagram illustrating the implementation flow of the secure boot process of an ARM processor according to the present invention is shown.

[0061] Figure 8 A schematic diagram of the signature tool configuration file in this invention is shown. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to specific examples and the accompanying drawings.

[0063] It should be noted that all uses of "first" and "second" in the embodiments of the present invention are for the purpose of distinguishing two different entities or different parameters with the same name. Therefore, "first" and "second" are merely for convenience of expression and should not be construed as limiting the embodiments of the present invention. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, such as other steps or units inherent in a process, method, system, product, or device that includes a series of steps or units.

[0064] Currently, OTP programmers provided by chip manufacturers can only program in certain system modes (such as MaskROM) and require dedicated software. Furthermore, existing signing tools are limited to signing fixed partitions and have strict requirements on the data to be signed and the location of the signature in the firmware program. These tools cannot sign fixed partitions, add new partitions, customize signatures, or specify the location of the signature data in the firmware program, hindering flexible product configuration and development. Therefore, to address these issues, a more efficient and flexible secure boot device and method are needed. This device includes a firmware signing module for signing user-specified partitions or signing them based on address size; a data writing module for writing OTP data to the ARM processor, where the OTP data is written to the OTP module according to the ARM processor's uboot or system operating mode; and a chip boot module for acquiring the OTP data and firmware program signature, writing the signed firmware program to the ARM processor, and enabling secure booting from the ARM processor. This invention overcomes the limitations of OTP signing tools, supporting direct signing of signature files under both u-boot and system modes. Furthermore, for signing firmware programs, it supports partition-based signing and allows for custom signature locations, sizes, and storage locations for the signing results. The advantage of this implementation is that the number, location, and size of signatures can be flexibly increased according to project needs during firmware signing. When writing to OTP, it is not limited by the CPU's operating mode; it can be directly written using OTP writing tools in common u-boot or system operating modes.

[0065] This invention provides a flexible configuration for a secure startup device, such as... Figure 1 As shown, the flexibly configurable safety start device includes:

[0066] Firmware signing module 100 is used to sign user-specified partitions or to sign them according to address size.

[0067] The data writing module 120 is used to write OTP data to the ARM processor. The OTP data writing to the ARM processor realizes that the user needs to write the parsed signature data into the OTP module according to the uboot working mode or system working mode of the ARM processor.

[0068] The chip boot module 130 is used to acquire the writing of OTP data and the signing of the firmware program. The signed firmware program is written into the ARM processor, and the ARM processor can be safely booted upon power-on.

[0069] In this embodiment, during operation, the firmware signing module 100 signs the user-specified partition or signs it according to address size. Then, the data writing module 200 writes OTP data to the ARM processor. The OTP data writing to the ARM processor is implemented by writing the parsed and signed data that the user needs to write into the OTP module according to the uboot working mode or system working mode of the ARM processor. Finally, the chip boot module 300 obtains the written OTP data and the signature of the firmware program, writes the signed firmware program into the ARM processor, and enables secure boot of the ARM processor.

[0070] This invention overcomes the limitations of OTP signing tools, supporting direct signing of signature files under both u-boot and system modes. Furthermore, for signing firmware programs, it supports partition-based signing and allows for custom signature locations, sizes, and storage locations for the signing results. The advantage of this implementation is that the number, location, and size of signatures can be flexibly increased according to project needs during firmware signing. When writing to OTP, it is not limited by the CPU's operating mode; it can be directly written using OTP writing tools in common u-boot or system operating modes.

[0071] This invention provides a firmware signing module 100, such as... Figure 2 As shown, the firmware signing module 100 includes:

[0072] The signature tool configuration unit 110 is used to provide a signature configuration file.

[0073] The signature execution unit 120 obtains the signature configuration file data, parses the configuration file data, and dynamically performs the signing of the partition that needs to be signed.

[0074] In this embodiment, the firmware signing tool identifies the file to be signed by parsing the configuration file, as well as its starting position and size in the firmware program. It then calculates the signature data by performing a signature algorithm (such as SHA256 and RSA2048) and writes it to the location specified in the configuration file, thus completing the signing of the firmware program.

[0075] For example, such as Figure 8 The image shows the contents of the signing tool configuration file. The configuration file format includes a SIGNATURE header, the name of each partition (e.g., UBOOT, DTB, KERNEL, ROOTFS, OTHERFS (other used file systems)), a FilePath for each partition, the starting address of the partition, the maximum size of the partition, and the address of the signature data. If a new partition needs to be signed, it can be added under that partition's file. This allows for signing of specified partitions. Additionally, if no file path is specified for OTHERFS, it will sign according to the given StartAddr and MaxSize, enabling signatures with custom positions and sizes.

[0076] This invention also provides a flexible configuration method for secure booting, such as... Figure 3 As shown, the flexible configuration secure boot method specifically includes:

[0077] Step S10: Sign the user-specified partition or sign it according to the address size to perform firmware signing.

[0078] Step S20: Obtain firmware program signature data, and write the data that the user needs to write to parse the signature into the OTP module according to the uboot working mode or system working mode of the ARM processor.

[0079] Step S30: Obtain the OTP data writing and firmware program signature, write the signed firmware program into the ARM processor, and enable secure booting of the ARM processor.

[0080] In this embodiment, the present invention overcomes the limitations of OTP signing tools, supporting direct signing of signature files under u-boot and system modes. Furthermore, for signing firmware programs, it supports partition-based signing and custom signature locations, sizes, and storage locations for the signing results. The advantage of this implementation is that the number, location, and size of signatures can be flexibly increased according to project needs during firmware signing. When writing to OTP, it is not limited by the CPU's operating mode; that is, it can be directly written using an OTP writing tool in common u-boot or system operating modes.

[0081] This invention provides a method for signing a user-specified partition or by address size to perform firmware signing. Figure 4 As shown, the method for signing the firmware program by signing the user-specified partition or by signing it according to address size includes:

[0082] Step S101: Extract the configuration file database;

[0083] Step S102: Specify different partition addresses and the location of the signature corresponding to the partition through the configuration file. The configuration file contains the starting address, size, and ending address of the signature data.

[0084] In step S103, the firmware signing tool identifies the file to be signed by parsing the configuration file, as well as its starting position and size in the firmware program. It then calculates the signature data using a signature algorithm and writes it to the location specified in the configuration file, thus completing the signing of the firmware program.

[0085] In this embodiment, the signature data is calculated using the SHA256 or RSA2048 algorithm.

[0086] For example, the signing tool dynamically signs all partitions that need signing by parsing the configuration file. For files without a file path, it signs according to the starting position and the maximum size, thus enabling both specified partition signing and signing of arbitrary sizes based on file size. The signing tool's execution flow is as follows: Figure 5 As shown in the image below, the SignatureImage is the signing tool. xxx.ima is the firmware program. The method of writing the signature data to the location specified in the configuration file to complete the signing of the firmware program specifically includes:

[0087] Step S201: Parse the configuration file;

[0088] Step S202: Determine whether the configuration file has been signed for all partitions. If the configuration file has been signed for all partitions, end the configuration parsing process. Otherwise, proceed to the next step.

[0089] Step S203: Check if the file exists in the corresponding path. If it exists, proceed to the next step. If not, calculate the signature value according to the StartAddr and MaxSize of the ima file.

[0090] Step S204: Calculate the file size;

[0091] Step S205: Check if the file size has exceeded the maximum value. If yes, report signing failure and end the signing process. If no, proceed to the next step.

[0092] Step S206: Calculate the hash value of the file based on the SHA algorithm;

[0093] Step S207: Sign the hash value using the RASA private key;

[0094] Step S208: Determine whether the signature result has been written to the corresponding SignatureStartAddr. If it has, end the signature process. If not, execute the above steps to determine whether the configuration file has been signed and all partitions have been completed.

[0095] For example, the SHA algorithm, or Secure Hash Algorithm, is a family of cryptographic hash functions and a FIPS-certified secure hash algorithm. It is an algorithm that can compute a fixed-length string (also known as a message digest) corresponding to a digital message.

[0096] For example, RSA, or public-key cryptosystem, is a cryptosystem that uses different encryption and decryption keys, and "it is computationally infeasible to derive the decryption key from the known encryption key." The encryption key is simply called the private key, and the decryption tool is simply called the public key.

[0097] This invention provides a method for writing user-defined signature parsing data into an OTP module based on the u-boot or system operating mode of the ARM processor. Figure 6 As shown, the method for writing the parsing signature data that the user needs to write into the OTP module according to the uboot working mode or system working mode of the ARM processor specifically includes:

[0098] Step S301: Obtain the public key's PEM file, wherein the public key's PEM file is a binary file named public.bin;

[0099] Step S302: Determine if the detection device is online; if so, proceed to the next step.

[0100] Step S3021: If not, prompt to write to the device cable management and end the writing process;

[0101] Step S303: Send a TCP data packet and wait for a TCP response;

[0102] Step S304: Parse the TCP response data and obtain the running status;

[0103] Step S304: Analyze the running status and determine the running status;

[0104] Step S3041: Obtain the running status judgment result. If it is running in uboot;

[0105] Step S3042: Copy the tfip command or tcp to public.cin into memory;

[0106] Step S3043: Execute the uboot otp write command;

[0107] Step S3044: Complete the writing of OTP data;

[0108] Step S3045: Execute the OTP command to enable the OTP module;

[0109] Step S306 indicates that the OTP function has been successfully enabled, and the writing process ends.

[0110] In this embodiment, the method of writing the parsing signature data that the user needs to write into the OTP module according to the uboot working mode or system working mode of the ARM processor further includes:

[0111] Step S3051: Obtain the running status judgment result;

[0112] Step S3052: If running on the system, copy public.cin to the device using the scp or tcp command;

[0113] Step S3053: Check if the file public.cin exists. If not, indicate that no file was detected and end the writing process.

[0114] Step S3054: If yes, call the OTP control process to write the OTP data;

[0115] Step S3055: Send a TCP command to enable the OTP module;

[0116] Step S3056: Invoke the OTP control process to enable the OTP module;

[0117] Step S306 indicates that the OTP function has been successfully enabled, and the writing process ends.

[0118] This invention provides a method for acquiring and writing OTP data and signing the firmware program, then writing the signed firmware program into the ARM processor, enabling secure booting of the ARM processor. Figure 7 As shown, the method of acquiring OTP data, writing the firmware program, signing the firmware program, writing the signed firmware program into the ARM processor, and enabling secure booting of the ARM processor is as follows:

[0119] The above steps complete the writing of OTP data and the signing of the firmware program. The signed firmware program is then written to the ARM processor, enabling secure booting of the ARM processor.

[0120] After the ARM processor powers on, it performs a secure boot process through a step-by-step verification procedure to ensure that the running program has not been modified. If the verification is successful, the process can proceed step by step. If an error occurs during the process, it will stop at that stage and will not proceed to the next level.

[0121] In this embodiment, the steps of the ARM processor's secure boot process include:

[0122] Step S401: The ARM processor is powered on;

[0123] In step S402, the chip uses the OTP public key data to parse the hash value of the uboot-spl signature data;

[0124] Step S403: The chip calculates the hash of the uboot-spl part of the stored firmware program.

[0125] Step S404: Determine whether the hash value calculated by the chip is consistent with the hash value parsed by the OTP;

[0126] Step S4010: If not, CPU operation stops at this stage.

[0127] Step S4041: If yes, load and run the uboot-spl program;

[0128] Step S4042, uboot-spl uses the OTP public key data to parse the uboot signature data hash value;

[0129] In step S4043, the uboot-spl program calculates the hash of the stored firmware program uboot part.

[0130] Step S405: Determine whether the hash value calculated by uboot-spl is consistent with the hash value parsed by otp;

[0131] Step S4010: If not, CPU operation stops at this stage.

[0132] Step S4051: If yes, load and run the uboot program;

[0133] In step S4052, U-Boot uses the OTP public key data to parse the kernel and DTB signature data hash values;

[0134] In step S4053, the uboot-spl program calculates the hash of the stored firmware program kernel and DTB signature data.

[0135] Step S406: Determine whether the hash value calculated by uboot is consistent with the hash value parsed by otp.

[0136] Step S4010: If not, CPU operation stops at this stage.

[0137] Step S4061: If yes, load the kernel program and its corresponding device and run it;

[0138] In step S4062, the kernel uses the OTP public key data to parse the rootfs signature data hash value;

[0139] In step S4063, the kernel program calculates the hash of the stored rootfs.

[0140] Step S407: Determine whether the hash value calculated by the kernel program is consistent with the hash value parsed by OTP.

[0141] Step S4010: If not, CPU operation stops at this stage.

[0142] Step S4071: If so, the kernel mounts the rootfs and runs it;

[0143] Step S4072: The rootfs uses the OTP public key data to parse the hash value of the otherfs signature data;

[0144] Step S4073, the otherfs running program calculates the hash of the stored otherfs.

[0145] Step S408: Determine whether the hash value calculated by the rootfs running program is consistent with the hash value parsed by the OTP.

[0146] Step S4010: If not, CPU operation stops at this stage.

[0147] Step S409: The rootfs mounts otherfs and runs, ending the process.

[0148] For example, it's worth noting that OTP (One-Time Programmable) is a type of chip memory, meaning it's programmable only once: once the program is burned into the chip, it cannot be changed or erased. Firmware, in this context, refers to the complete program running on an ARM processor that ensures the system functions correctly, including the BootLoader, Kernel, RootFS, and OtherFS. The BootLoader is the startup program that runs before the Kernel program and is used to boot from it. The BootLoader reads the firmware program from a designated partition of the FLASH memory into memory and then jumps to run the firmware program.

[0149] In this application, secure boot employs a signature authentication method for the system software. Before the device leaves the factory, the image file of the device's operating system is signed and authenticated, and the public key data is written into the chip's one-time programmable module (OTP). When the device boots up, it parses the signature data using the public key data to verify the signature.

[0150] This invention also provides a schematic diagram of a computer device, which includes a display screen, a memory, a processor, and a computer program. The memory stores the computer program, and when executed by the processor, the computer program causes the processor to perform the steps of the flexible configuration secure boot method.

[0151] Sign the user-specified partition or sign it according to address size, and perform firmware signing.

[0152] Obtain firmware signature data, and write the data that the user needs to parse and sign into the OTP module according to the uboot working mode or system working mode of the ARM processor;

[0153] The process involves acquiring OTP data and signing the firmware program, then writing the signed firmware program into the ARM processor, enabling secure booting of the ARM processor.

[0154] It is understood that, in the preferred embodiments provided by the present invention, the computer device may also be a laptop computer, a personal digital assistant (PDA), a mobile phone, or other devices capable of communication.

[0155] This invention also provides a readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the flexibly configurable secure boot method:

[0156] Sign the user-specified partition or sign it according to address size, and perform firmware signing.

[0157] Obtain firmware signature data, and write the data that the user needs to parse and sign into the OTP module according to the uboot working mode or system working mode of the ARM processor;

[0158] The process involves acquiring OTP data and signing the firmware program, then writing the signed firmware program into the ARM processor, enabling secure booting of the ARM processor.

[0159] It is understood that, in the preferred embodiments provided by the present invention, the computer device may also be a laptop computer, a personal digital assistant (PDA), a mobile phone, or other devices capable of communication.

[0160] For example, a computer program can be divided into one or more modules, one or more of which are stored in memory and executed by a processor to perform the present invention. One or more modules can be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in a terminal device. For example, the aforementioned computer program can be divided into units or modules of the berth status display system provided in the various system embodiments described above.

[0161] Those skilled in the art will understand that the above description of the terminal device is merely an example and does not constitute a limitation on the terminal device. It may include more or fewer components than described above, or combine certain components, or different components, such as input / output devices, network access devices, buses, etc.

[0162] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. This processor is the control center of the terminal device, connecting various parts of the user terminal via various interfaces and lines.

[0163] The aforementioned memory can be used to store computer programs and / or modules. The aforementioned processor implements various functions of the aforementioned terminal device by running or executing the computer programs and / or modules stored in the memory, and by calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as information collection template display function, product information publishing function, etc.). In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0164] This invention overcomes the limitations of OTP signing tools, supporting direct signing of signature files under both u-boot and system modes. Furthermore, for signing firmware programs, it supports partition-based signing and allows for custom signature locations, sizes, and storage locations for the signing results. The advantage of this implementation is that the number, location, and size of signatures can be flexibly increased according to project needs during firmware signing. When writing to OTP, it is not limited by the CPU's operating mode; it can be directly written using OTP writing tools in common u-boot or system operating modes.

[0165] The above are exemplary embodiments disclosed in this invention. However, it should be noted that various changes and modifications can be made without departing from the scope of the embodiments of this invention as defined by the claims. The functions, steps, and / or actions of the methods according to the disclosed embodiments described herein do not need to be performed in any particular order. Furthermore, although the elements disclosed in the embodiments of this invention may be described or claimed individually, they may be understood as multiple unless explicitly limited to a singular number.

[0166] It should be understood that, as used herein, the singular form "a" is intended to include the plural form as well, unless the context clearly supports an exception. It should also be understood that, as used herein, "and / or" refers to any and all possible combinations of one or more of the associatedly listed items. The embodiment numbers disclosed above are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0167] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of the invention (including the claims) is limited to these examples. Within the framework of the invention, technical features of the above embodiments or different embodiments can be combined, and many other variations of different aspects of the invention exist, which are not provided in the details for the sake of brevity. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the protection scope of the invention.

Claims

1. A flexibly configurable safety start device, characterized in that, The flexibly configurable safety start device includes: The firmware signing module is used to sign user-specified partitions or to sign them based on address size. The data writing module is used to write OTP data to the ARM processor. Specifically, writing OTP data to the ARM processor is implemented by writing the parsed signature data that the user needs to write into the OTP module according to the uboot working mode or system working mode of the ARM processor. The chip boot module is used to acquire OTP data and sign the firmware program, and write the signed firmware program into the ARM processor, enabling secure booting of the ARM processor. The firmware signing module is further used to: extract the configuration file database; specify different partition addresses and the corresponding signature positions of the partitions through the configuration file, wherein the configuration file contains the starting address, size, and ending address of the signature data; the firmware signing tool identifies the file to be signed, as well as its starting position and size in the firmware program by parsing the configuration file, calculates the signature data by performing a signature algorithm, and writes it to the location specified in the configuration file to complete the signing of the firmware program. The data writing module is further used for: obtaining the public key's PEM file, wherein the public key's PEM file is a binary file named public.bin; determining whether the detection device is online, and if so, proceeding to the next step; if not, prompting the device to reconnect and ending the writing process; sending TCP data packets and waiting for a TCP response; parsing the TCP response data to obtain the running status; parsing the running status and judging the running status; obtaining the running status judgment result, and if running in U-Boot; copying the tfip command or TCP to public.cin into memory; executing the U-Boot OTP write command; completing the writing of OTP data; executing the OTP command to enable the OTP module; prompting that the OTP function has been successfully enabled and ending the writing process.

2. The apparatus according to claim 1, characterized in that, The firmware signing module includes: The signing tool configuration unit is used to provide the signing configuration file.

3. The apparatus according to claim 2, characterized in that, The firmware signing module also includes: The signature execution unit obtains the signature configuration file data, parses the configuration file data, and dynamically performs the signing of the partitions that need to be signed.

4. A flexible configuration safety start method based on the flexible configuration safety start device according to any one of claims 1-3, characterized in that, The flexible configuration of the secure boot method specifically includes: Sign the user-specified partition or sign it according to address size, and perform firmware signing. Obtain firmware signature data, and write the data that the user needs to parse and sign into the OTP module according to the uboot working mode or system working mode of the ARM processor; The process involves acquiring OTP data and signing the firmware program, then writing the signed firmware program into the ARM processor, enabling secure booting of the ARM processor.

5. The method according to claim 4, characterized in that, The method for signing the user-specified partition or signing it according to address size to perform firmware signing specifically includes: Extract configuration file database; Different partition addresses and the corresponding signature positions for each partition can be specified through configuration files. The configuration files contain the starting address, size, and ending address of the signature data. The firmware signing tool identifies the file to be signed, as well as its starting position and size in the firmware program, by parsing the configuration file. It then calculates the signature data using a signature algorithm and writes it to the location specified in the configuration file, thus completing the signing of the firmware program.

6. The method according to claim 5, characterized in that, The method further includes: calculating signature data using a signature algorithm based on SHA256 or RSA2048.

7. The method according to claim 6, characterized in that, The method of writing the signature data to the location specified in the configuration file to complete the signing of the firmware program specifically includes: Parse the configuration file; Determine if the configuration file has been signed for all partitions. If it has, end the configuration parsing process; otherwise, proceed to the next step. Check if the file exists in the corresponding path. If it exists, proceed to the next step. Otherwise, calculate the signature value based on the StartAddr and MaxSize of the ima file. Calculate file size; Check if the file size has exceeded the maximum value. If so, report a signing failure and end the signing process. If not, proceed to the next step. The hash value of the file is calculated based on the SHA algorithm; Sign the hash value using the RASA private key; Check if the signature result has been written to the corresponding SignatureStartAddr. If it has, end the signature process. Otherwise, execute the steps above to check if the configuration file has been signed and complete all partitions.

8. The method according to claim 4, characterized in that, The method for writing the parsing and signature data required by the user into the OTP module according to the uboot working mode or system working mode of the ARM processor specifically includes: Obtain the running status result. If it is running in the system, use the scp or tcp command to copy public.cin to the device. Check if the file public.cin exists. If not, indicate that no file was detected and end the writing process. If so, the OTP control process is invoked to write the OTP data; Send a TCP command to enable the OTP module; The OTP control process is invoked to enable the OTP module, indicating that the OTP function has been successfully enabled, and the writing process ends.

9. The method according to claim 4, characterized in that, The method for acquiring and writing OTP data and signing the firmware program, then writing the signed firmware program into the ARM processor to enable secure booting of the ARM processor, specifically includes: After the ARM processor is powered on, it performs a safe boot process by following a step-by-step verification process to ensure that the running program has not been modified. If the verification is successful, it can start up step by step. If an error occurs during the process, it will stop at this stage and will not proceed to the next stage.

Images