Method and system for unified signature of product firmware

Abstract

The present invention proposes a method and system for unified signing of product firmware, the method comprising: receiving a signature request sent by a client through a server, and automatically and uniformly signing all firmware to be signed contained in the product according to the product model version and firmware type, and returning the signature result to the client. The automated signature processing of the present invention can not only efficiently and safely sign all firmware to be signed, solving the problems of low efficiency and cumbersome procedures of manual signatures, but also realizes the protection of secret keys and signature tools, which can avoid the risk of leakage, and executing the signing operation of all firmware according to the product model version and firmware type can prevent firmware from being flashed by mistake, thereby ensuring the adaptability and correctness of the product.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and system for uniformly signing product firmware. Background Art

[0002] Firmware such as BIOS, BMC and CPLD are key components to ensure the normal operation of hardware devices. In order to ensure the security and integrity of these firmware, the firmware needs to be signed. The firmware signature can verify the source of the firmware and that it has not been tampered with, thereby protecting the device from malware.

[0003] At present, the implementation of firmware signing usually relies on manual and decentralized operations, that is, professionals use signing tools to sign different types of firmware according to specific processes. Although this method can meet the basic needs of signing to a certain extent, its efficiency and security are challenged when facing diverse and large-scale firmware signing tasks.

[0004] First, the manual and decentralized signing process requires separate configuration and operation for each signature, which leads to a lot of duplication of work and time waste, especially when there are many product models and firmware versions. It is inefficient, time-consuming and error-prone. Secondly, from a security perspective, decentralized signing methods increase the risk of key leakage, because multiple departments and personnel may have access to sensitive signature keys. In addition, the lack of a unified security management strategy may also lead to security vulnerabilities. Furthermore, due to the lack of strict signature management based on product models and firmware types, there is a high risk of mis-flashing. Operators may flash mismatched firmware into the device due to negligence or inaccurate information, resulting in device failure, functional failure or even damage. Summary of the invention

[0005] Based on this, the purpose of the present invention is to propose a method and system for uniformly signing product firmware to solve the above-mentioned problems.

[0006] The method for uniformly signing product firmware proposed in the present invention is applied to a server, and the method includes:

[0007] Receive a signature request sent by a client, wherein the parameters carried in the signature request include the product model version, all firmware to be signed contained in the product, and the firmware type;

[0008] All the firmware to be signed contained in the product are uniformly signed according to the product model version and firmware type, and the signature result is returned to the client.

[0009] Furthermore, before the step of receiving the signature request sent by the client, the step further includes:

[0010] Generate multiple types of keys;

[0011] Separate and store the keys required for different product models and versions;

[0012] Separately store signature configuration information of different types of firmware.

[0013] Furthermore, the step of uniformly signing all the firmware to be signed contained in the product according to the product model version and firmware type includes:

[0014] For each firmware to be signed, create a unique encrypted directory;

[0015] Find and obtain the corresponding key according to the product model version;

[0016] Read the corresponding signature configuration information according to the firmware type;

[0017] Selecting a matching signature tool and script according to the signature configuration information;

[0018] Copy the firmware to be signed, the secret key, the signing tool and the script to the corresponding encrypted directory;

[0019] Perform a signing operation on the firmware to be signed in the encrypted directory to generate a signature file;

[0020] If the signature is successful, the signature output is processed according to the firmware type.

[0021] Furthermore, the step of isolating and storing signature configuration information of different types of firmware includes:

[0022] The signature configuration information corresponding to different types of firmware is stored in different signature configuration files respectively;

[0023] Different signature configuration files are distinguished according to the file name suffix.

[0024] Furthermore, the step of creating a unique encrypted directory includes:

[0025] Generate a unique encrypted directory through the timestamp encryption algorithm.

[0026] Furthermore, the step of generating a unique encrypted directory by using a timestamp encryption algorithm includes:

[0027] Generate a random secret key through a preset function and set it as a random secret key;

[0028] Get the current timestamp and convert it into a number, setting it as the timestamp data;

[0029] Compressing the timestamp data using a preset compression algorithm;

[0030] Encrypting the compressed timestamp data using the random key;

[0031] Convert the encrypted data into a string in a preset format;

[0032] Takes a string as the name of the encryption directory.

[0033] Furthermore, the step of processing the signature output according to the firmware type includes:

[0034] If the firmware is in .hpm format, the signature output is the corresponding signature file.

[0035] If the firmware is in .ima format or .bin format, an intermediate file is generated, and the signature output includes the corresponding signature file and intermediate file.

[0036] Furthermore, the step of receiving the signature request sent by the client includes:

[0037] Start the background service and perform file transfer through the Flask framework to receive the signature request sent by the client.

[0038] Furthermore, the step of performing a signing operation on the firmware to be signed in the encrypted directory and generating a signature file further includes:

[0039] After the signing is completed, the non-essential files in the encrypted directory are deleted, and the non-essential files include secret keys, signing tools and scripts.

[0040] The present invention also provides a system for uniformly signing product firmware, which is applied to a server and includes:

[0041] The signature request receiving module is used to receive the signature request sent by the client, wherein the parameters carried in the signature request include the product model version, all firmware to be signed contained in the product, and the firmware type;

[0042] Signature processing module: used to perform unified signature processing on all the firmware to be signed contained in the product according to the product model version and firmware type, and return the signature result to the client.

[0043] In summary, the method for unified signing of product firmware of the present invention receives the signature request sent by the client through the server, and automatically and uniformly signs all the firmware to be signed contained in the product according to the product model version and firmware type, and returns the signature result to the client. The automated signature processing can not only efficiently and safely sign all the firmware to be signed, solving the problems of low efficiency and cumbersome process of manual signing, but also realizes the protection of secret keys and tools, and can avoid the risk of leakage. Executing the signing operation of all firmware according to the product model version and firmware type can prevent the firmware from being flashed incorrectly, thereby ensuring the adaptability and correctness of the product.

[0044] Additional aspects and advantages of the present invention will be given in part in the following description and in part will be obvious from the following description or will be learned through embodiments of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The above and / or additional aspects and advantages of the present invention will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which:

[0046] Figure 1 This is a flow chart of a method for uniformly signing product firmware according to a first embodiment of the present invention;

[0047] Figure 2 A flowchart of a specific implementation method of the method for unified signing of product firmware according to the first embodiment of the present invention;

[0048] Figure 3 This is a system block diagram of a system for uniformly signing product firmware according to a second embodiment of the present invention. DETAILED DESCRIPTION

[0049] In order to facilitate the understanding of the present invention, the present invention will be described more fully below with reference to the relevant drawings. Several embodiments of the present invention are given in the drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. On the contrary, the purpose of providing these embodiments is to make the disclosure of the present invention more thorough and comprehensive.

[0050] It should be noted that when an element is referred to as being "fixed to" another element, it may be directly on the other element or there may be a central element. When an element is considered to be "connected to" another element, it may be directly connected to the other element or there may be a central element at the same time. The terms "vertical", "horizontal", "left", "right" and similar expressions used herein are for illustrative purposes only.

[0051] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which the present invention belongs. The terms used herein in the specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. The term "and / or" used herein includes any and all combinations of one or more of the related listed items.

[0052] Example 1

[0053] See also Figure 1 The present invention proposes a method for uniformly signing product firmware, which is applied to a server. The method includes steps S101 to S102:

[0054] S101, receiving a signature request sent by a client, wherein the parameters carried in the signature request include the product model version, all firmware to be signed contained in the product, and the firmware type;.

[0055] It should be noted that the background service is started and the file is transferred through the Flask framework to receive the signature request sent by the client. In this way, the server can accurately obtain the key information sent by the client and prepare for the subsequent signature operation. This web-based service architecture makes the signature processing process more automated and efficient.

[0056] A background service is a program running on the server side that is responsible for handling various requests from clients. Starting a background service usually includes loading the service program, initializing related resources (such as memory, database connection, etc.), setting the listening port, and starting to accept and process external connection requests.

[0057] In this embodiment, file transfer can be performed through the Flask framework. Flask is a Python framework for building Web applications, which provides tools for processing HTTP requests and responses. The client uploads files (here refers to the signature request) to the server through the HTTP protocol, and Flask is responsible for receiving these files. Flask defines routes and view functions to specify the operations that should be performed when a request for a specific URL path is received, thereby implementing the file reception and processing logic.

[0058] The client (which may be a web browser, mobile application, or other network client) constructs a signature request and sends it to the server through the network. This signature request carries key parameter information, such as the product model version, all the firmware to be signed contained in the product, and the type of firmware. After the server receives the signature request through the Flask framework, it first needs to parse the parameters contained in the request. The product model version information can be used to find and obtain the secret key corresponding to the product model version in the subsequent signature processing process; the firmware to be signed is the object of the signature operation, such as BMC (baseboard management controller), BIOS (basic input and output system), CPLD (complex programmable logic device), etc.; and the firmware type can be used to determine the corresponding signature configuration information to be read in the subsequent signature processing process. The system can select the appropriate signature tool and script according to the firmware type. After parsing the parameters, the server will prepare for subsequent signature operations based on this information.

[0059] S102, performing unified signature processing on all the firmware to be signed contained in the product according to the product model version and firmware type, and returning the signature result to the client.

[0060] It should be noted that unified signing of all firmware to be signed contained in the product according to the product model version and firmware type is an efficient and automated firmware signing process, which avoids manual operation and prevents the risk of key leakage. It also relies on clear product model version and firmware type information, can process multiple firmware in batches, effectively prevents firmware from being accidentally flashed, and finally returns the signature result to the client, thereby ensuring the security and reliability of the firmware.

[0061] After receiving the signature request, the signature request is parsed and the parameter information it carries (such as product model version, firmware type) is obtained from it. Different product models and versions may require different signature algorithms, keys or security policies. Specifically, the keys required for each model version of the product can be stored securely and isolated in the system in advance. During the signature processing, the keys required for the corresponding product pre-stored in the system can be retrieved according to the product model version. The firmware type can affect the specific technology and process of the signature. For example, BIOS, BMC, and CPLD firmware may require different signature methods. Specifically, the signature configuration information of each type of firmware can be stored securely and isolated in the system in advance. For example, the signature configuration information corresponding to different types of firmware (such as BMC, BIOS, CPLD) can be stored in different configure.ini configuration files. These configuration files will be distinguished according to the file name suffix (such as .hpm, .ima, .bin, etc.), so as to ensure that each firmware type and its signature method has an independent configuration file. During the signature processing, the corresponding pre-stored signature configuration information can be read according to the firmware type, and then the matching signature tool and script can be selected according to the signature configuration information. The tools and files required for the signature obtained according to the product type version and firmware type are copied to the corresponding encrypted directories for independent and encrypted signing to achieve unified signature processing for all firmware, which not only effectively prevents firmware from being flashed by mistake, but also ensures the security of the secret key.

[0062] In the unified signature processing process, all firmware to be signed need to be signed uniformly to process multiple firmwares simultaneously or sequentially, rather than manually processing them one by one, which greatly improves the efficiency of signing. Unified signatures usually involve automated scripts or tools that can automatically perform signing operations according to preset rules and algorithms, reducing the possibility of human error. Through unified signature processing, it can be ensured that all firmware is signed according to the same high-standard security process, thereby enhancing the security and consistency of the firmware.

[0063] After the signing is completed, the system returns the signing result to the client, which is both a completion notification and a way to provide the signed firmware. After the client receives the signing result, it can verify to ensure that the firmware has been signed correctly and then deploy it to the corresponding product. If there is a problem in the signing process, the returned result may also contain error information to help the client understand the problem and handle it accordingly. Through the interaction between the client and the server, the client sends a signing request, the server processes the signing request and returns the signing result, thus forming a complete request and response cycle. This interaction mode ensures the timely delivery and processing of information.

[0064] Based on step S101 to step S102, the signature request sent by the client is received by the server, and all the firmware to be signed contained in the product is automatically and uniformly signed according to the product model version and firmware type, and the signature result is returned to the client. The automated signature processing can not only efficiently and securely sign all the firmware to be signed, but also solve the problems of low efficiency and cumbersome process of manual signing, but also realize the protection of secret keys and tools, and avoid the risk of leakage. Executing the signing operation of all firmware according to the product model version and firmware type can prevent the firmware from being flashed incorrectly, thereby ensuring the adaptability and correctness of the product.

[0065] In addition, a method for uniformly signing product firmware according to an embodiment of the present invention is described in detail as follows:

[0066] Further optionally, before step S101, the step of receiving the signature request sent by the client further includes:

[0067] Generate multiple types of keys;

[0068] Separate and store the secret keys of each product model version;

[0069] Separately store signature configuration information of different types of firmware.

[0070] Specifically, before executing the signing operation, the system will perform a series of key preparations. First, multiple types of keys will be generated, which can usually be done through tools such as openssl. The generated key types include private.pem (private key), public.pem (public key), AESIV (AES encryption key) and AESKey (AES initialization vector). These keys play a vital role in the subsequent signing and encryption process. Then, in order to ensure security, the system will store the keys of different product models and versions in different preset directories in a safe and isolated manner, which can effectively prevent the confusion or leakage of the keys. In addition, the corresponding signature configuration information will be isolated and stored according to the type of firmware (such as BMC, BIOS, CPLD, etc.) to ensure that the signature configuration of each firmware is independent and secure. These configuration information will be stored in the configure.ini configuration file with a specific file name suffix (such as .hpm, .ima, .bin, etc.) so that it can be accurately identified and called during the signing process. Through these meticulous preparations, it can be ensured that each firmware type and its signature method have independent configuration files and keys, thus providing a solid foundation for the subsequent unified signature processing.

[0071] Further optionally, in step S102, the step of uniformly signing all the firmware to be signed contained in the product according to the product model version and firmware type includes:

[0072] For each firmware to be signed, create a unique encrypted directory;

[0073] Find and obtain the corresponding key according to the product model version;

[0074] Read the corresponding signature configuration information according to the firmware type;

[0075] Selecting a matching signature tool and script according to the signature configuration information;

[0076] Copy the firmware to be signed, the secret key, the signing tool and the script to the corresponding encrypted directory;

[0077] Perform a signing operation on the firmware to be signed in the encrypted directory to generate a signature file;

[0078] If the signature is successful, the signature output is processed according to the firmware type.

[0079] Specifically, the system will first determine the product model version and firmware type, and create a unique encrypted directory for each firmware to be signed to ensure the independent encryption of the signing environment. Then, according to the product model version, the system will find and obtain the corresponding key from the preset directory. At the same time, according to the firmware type, the system will read the corresponding signature configuration information and select the matching signature tool and script. These necessary files, including the firmware to be signed, the key, the signature tool and the script, will be copied to the previously created encrypted directory to form a black box environment for separate signatures. In this encrypted directory, the system will execute the shell command to sign the firmware to ensure the security of the entire process. If the signature is successful, the system will process the signature output according to the firmware type, generate the corresponding signature file or intermediate file, and provide the download address information to the client. In addition, in order to keep the environment clean and secure, after the signature is completed, the system will delete the relevant tools, scripts and keys, leaving only the signed firmware for users to download. If the signature fails, the system will delete the entire directory and return the failure information to the client. In addition, this signing process also has the functions of decryption and backtracking. When there is a problem with the signed firmware, the administrator of the signing center can decrypt the encrypted directory and obtain information such as the time of the signature to facilitate tracing and solving the problem.

[0080] Further optionally, the step of isolating and storing signature configuration information of different types of firmware includes:

[0081] The signature configuration information corresponding to different types of firmware is stored in different signature configuration files respectively;

[0082] Different signature configuration files are distinguished according to the file name suffix.

[0083] Specifically, it is understandable that the signature configuration information corresponding to different types of firmware (such as BMC, BIOS, CPLD) is stored in their own independent signature configuration files, which ensures that the signature configuration information of each firmware will not interfere or confuse each other. In order to further distinguish and manage these configuration files, the system will identify and classify different signature configuration files according to the file name suffix (such as .hpm, .ima, .bin, etc.), where .hpm represents a firmware package format, .ima represents an image file format, and .bin represents a binary file format. In this way, the configuration files required for each firmware type and its corresponding signature method can be clearly identified and located, thereby ensuring the accuracy and efficiency of signature processing. In short, the signature configuration information of various types of firmware is stored in different configure.ini files, and the file suffix is ​​used to distinguish and manage them, so as to achieve independent and orderly signature configuration management.

[0084] Among them, configure.ini is an initialization (INI) format configuration file used to define and save various configuration parameters. In the scenario of firmware signing, configure.ini contains the parameters required in the signing process, such as the selection of signature algorithm, the path of key file, the format of signature output, etc. Each different type of firmware (such as BMC, BIOS, CPLD) has a separate configure.ini file to correctly configure the signing process.

[0085] Further optionally, the step of creating a unique encrypted directory includes:

[0086] Generate a unique encrypted directory through the timestamp encryption algorithm.

[0087] Further optionally, the step of generating a unique encrypted directory by using a timestamp encryption algorithm includes:

[0088] Generate a random secret key through a preset function and set it as a random secret key;

[0089] Get the current timestamp and convert it into a number, setting it as the timestamp data;

[0090] Compressing the timestamp data using a preset compression algorithm;

[0091] Encrypting the compressed timestamp data using the random key;

[0092] Convert the encrypted data into a string in a preset format;

[0093] Takes a string as the name of the encryption directory.

[0094] It can be understood that the steps of generating a unique encrypted directory through the timestamp encryption algorithm are to first generate a random key, then obtain the current timestamp and convert it into digital form, then use the timestamp compression algorithm to reduce the data size, and then use the random key to encrypt the compressed timestamp. The encrypted data is then converted into a string in a specific format, and finally the string is used as the name of the encrypted directory, thereby ensuring that each generated directory name is unique and highly secure.

[0095] Further optionally, after the step of processing the signature output according to the firmware type, the step further includes:

[0096] Build a dictionary containing firmware information and format the return data;

[0097] Provide a download link for the signature file or intermediate file through HTTP service.

[0098] Further optionally, the step of processing the signature output according to the firmware type includes:

[0099] If the firmware is in .hpm format, the signature output is the corresponding signature file.

[0100] If the firmware is in .ima format or .bin format, an intermediate file is generated, and the signature output includes the corresponding signature file and intermediate file.

[0101] Understandably, after processing the firmware signature and generating the corresponding signature file or intermediate file, the system will further process the output according to the specific type of the firmware. For firmware in .hpm format, its signature output directly corresponds to the final signature file. However, for firmware in .ima and .bin formats, an intermediate file will be generated, and its signature output file contains the signature file and the intermediate file (such as encrypted_rom.'+end_with+'_enc). In order to clearly provide this information to the user, the system will build a dictionary containing detailed information about the firmware, such as the firmware type, signature status, and related file names, and format this data for easy understanding by the user. In addition, the system also provides users with download links for signature files or intermediate files through HTTP services to ensure that users can easily obtain the required files. In the returned dictionary, for .ima and .bin firmware, the system will specially mark two fields: output and enc. The output field corresponds to the signature file, and the enc field corresponds to the intermediate encrypted file to distinguish between the signature file and the intermediate encrypted file, thereby providing users with clear file download instructions.

[0102] The purpose of the intermediate file is to achieve the transition from unsigned firmware to signed firmware. When the server originally runs unsigned firmware and needs to be upgraded to signed firmware, since the server with unsigned firmware usually cannot directly refresh the signed firmware file, an intermediate file needs to be refreshed first. This intermediate file acts as a bridge, allowing the server to adapt to the signature mechanism first, and then refresh the final signed firmware.

[0103] Further optionally, the step of performing a signing operation on the firmware to be signed in the encrypted directory and generating a signature file further includes:

[0104] After the signing is completed, the non-essential files in the encrypted directory are deleted, and the non-essential files include secret keys, signing tools and scripts.

[0105] Understandably, during the signing process, after the signing is completed according to the product model and firmware type in the signing request, non-essential files in the encrypted directory can be deleted. This operation specifically includes removing files such as keys, signing tools, and scripts, aiming to reduce potential security risks. By cleaning up these non-essential files, the security and confidentiality of the signing process is ensured, while optimizing the use of storage space.

[0106] like Figure 2 FIG. 1 is a specific implementation operation of an embodiment of the present invention:

[0107] The client sends a POST request: The client sends a POST request to the signature center, which contains the firmware to be signed and related information.

[0108] Determine the product model: The signature center first analyzes the data in the request to determine the product model. This is to select the correct signature configuration and key later.

[0109] Determine the firmware type: Next, the signature center will determine the type of firmware (such as .ima, .hpm, .bin, etc.).

[0110] Create an encrypted directory: The Signature Center will create a unique encrypted directory. This directory will be used to store all files and tools required for the signing process, forming an isolated and secure working environment.

[0111] Prepare the signing environment: The signing center copies the unsigned firmware, signing tools, secret keys, and necessary scripts to the created encrypted directory. In this way, all signing operations are performed in this closed "black box" environment, ensuring the security and integrity of the data.

[0112] Execute the signing operation: In the encrypted directory, the signature center executes a shell command to start the signing tool to sign the firmware. This process is automated to ensure the consistency and efficiency of the signature.

[0113] Processing signature output: If the signature is successful, the signature center will process the signature output according to the firmware type. For some firmware types (such as .hpm), the signature file is the final output. For other types (such as .ima, .bin), an encrypted intermediate file (such as encrypted_rom.xxx_enc) will also be generated. The signature output will contain the signature file and the intermediate file.

[0114] Clean up unnecessary files: After signing is completed, for security reasons, the Signature Center will delete unnecessary files in the encrypted directory, including signing tools, scripts, and keys, to reduce potential security risks and free up storage space.

[0115] Return results to the client: If the signature is successful, the signature center will return the success status information to the client, as well as the download address of the signature file and / or encrypted intermediate file. If the signature fails, the signature center will delete the entire encrypted directory and return the failure information to the client.

[0116] The method for unified signing of product firmware in the embodiment of the present invention significantly improves the signing efficiency and reduces manual intervention through automated unified signature processing, and is particularly suitable for situations where there are many product models and firmware types. Secondly, the method enhances security by centrally managing secret keys and signature tools without exposing them to the outside, effectively preventing key leakage and illegal signatures. In addition, it can also prevent mis-flashing and ensure the correctness and adaptability of the firmware. At the same time, it supports multiple firmware signatures, which improves the flexibility and versatility of the signature.

[0117] Example 2

[0118] See also Figure 3 The present invention also proposes a system for uniformly signing product firmware, which is applied to a server and includes:

[0119] The signature request receiving module is used to receive the signature request sent by the client, wherein the parameters carried in the signature request include the product model version, all firmware to be signed contained in the product, and the firmware type;

[0120] Signature processing module: used to perform unified signature processing on all the firmware to be signed contained in the product according to the product model version and firmware type, and return the signature result to the client.

[0121] Further optionally, the signature request receiving module is further used for:

[0122] Generate multiple types of keys;

[0123] Separate and store the keys required for different product models and versions;

[0124] Separately store signature configuration information of different types of firmware.

[0125] Further optionally, the signature processing module is further used for:

[0126] For each firmware to be signed, create a unique encrypted directory;

[0127] Find and obtain the corresponding key according to the product model version;

[0128] Read the corresponding signature configuration information according to the firmware type;

[0129] Selecting a matching signature tool and script according to the signature configuration information;

[0130] Copy the firmware to be signed, the secret key, the signing tool and the script to the corresponding encrypted directory;

[0131] Perform a signing operation on the firmware to be signed in the encrypted directory to generate a signature file;

[0132] If the signature is successful, the signature output is processed according to the firmware type.

[0133] Further optionally, the signature request receiving module is further used for:

[0134] The signature configuration information corresponding to different types of firmware is stored in different signature configuration files respectively;

[0135] Different signature configuration files are distinguished according to the file name suffix.

[0136] Further optionally, the signature processing module is further used for:

[0137] Generate a unique encrypted directory through the timestamp encryption algorithm.

[0138] Further optionally, the signature processing module is further used for:

[0139] Generate a random secret key through a preset function and set it as a random secret key;

[0140] Get the current timestamp and convert it into a number, setting it as the timestamp data;

[0141] Compressing the timestamp data using a preset compression algorithm;

[0142] Encrypting the compressed timestamp data using the random key;

[0143] Convert the encrypted data into a string in a preset format;

[0144] Takes a string as the name of the encryption directory.

[0145] Further optionally, the signature processing module is further used for:

[0146] If the firmware is in .hpm format, the signature output is the corresponding signature file.

[0147] If the firmware is in .ima format or .bin format, an intermediate file is generated, and the signature output includes the corresponding signature file and intermediate file.

[0148] This ensures that different types of firmware signature outputs can be processed correctly and returned to the requester through a unified interface.

[0149] Further optionally, the signature request receiving module is further used for:

[0150] Start the background service and perform file transfer through the Flask framework to receive the signature request sent by the client.

[0151] Further optionally, the signature processing module is further used for:

[0152] After the signing is completed, the non-essential files in the encrypted directory are deleted, and the non-essential files include secret keys, signing tools and scripts.

[0153] The above-mentioned embodiments only express several implementation methods of the present invention, and the description thereof is relatively specific and detailed, but it cannot be understood as limiting the scope of the patent of the present invention. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be subject to the attached claims.

Claims

1. A method for uniformly signing product firmware, characterized in that: Applied to a server, the method comprises: Receive a signature request sent by a client, wherein the parameters carried in the signature request include the product model version, all firmware to be signed contained in the product, and the firmware type; Performing unified signing processing on all the firmware to be signed contained in the product according to the product model version and firmware type, and returning the signing result to the client; The step of uniformly signing all the firmware to be signed contained in the product according to the product model version and firmware type comprises: For each firmware to be signed, create a unique encrypted directory; Find and obtain the corresponding key according to the product model version; Read the corresponding signature configuration information according to the firmware type; Selecting a matching signature tool and script according to the signature configuration information; Copy the firmware to be signed, the secret key, the signing tool and the script to the corresponding encrypted directory; Perform a signing operation on the firmware to be signed in the encrypted directory to generate a signature file; If the signature is successful, the signature output is processed according to the firmware type.

2. The method for uniformly signing product firmware according to claim 1, characterized in that: The step of receiving the signature request sent by the client also includes: Generate multiple types of keys; Separate and store the keys required for different product models and versions; Separately store signature configuration information of different types of firmware.

3. The method for uniformly signing product firmware according to claim 2, characterized in that: The step of isolating and storing signature configuration information of different types of firmware includes: The signature configuration information corresponding to different types of firmware is stored in different signature configuration files respectively; Different signature configuration files are distinguished according to the file name suffix.

4. The method for uniformly signing product firmware according to claim 1, characterized in that: The steps of creating a unique encrypted directory include: Generate a unique encrypted directory through the timestamp encryption algorithm.

5. The method for uniformly signing product firmware according to claim 4, characterized in that: The step of generating a unique encrypted directory by using a timestamp encryption algorithm includes: Generate a random secret key through a preset function and set it as a random secret key; Get the current timestamp and convert it into a number, setting it as the timestamp data; Compressing the timestamp data using a preset compression algorithm; Encrypting the compressed timestamp data using the random key; Convert the encrypted data into a string in a preset format; Takes a string as the name of the encryption directory.

6. The method for uniformly signing product firmware according to claim 1, characterized in that: The step of processing the signature output according to the firmware type comprises: If the firmware is in .hpm format, the signature output is the corresponding signature file; If the firmware is in .ima format or .bin format, an intermediate file is generated, and the signature output includes the corresponding signature file and intermediate file.

7. The method for uniformly signing product firmware according to claim 1, characterized in that: The step of receiving the signature request sent by the client comprises: Start the background service and perform file transfer through the Flask framework to receive the signature request sent by the client.

8. The method for uniformly signing product firmware according to claim 1, characterized in that: After the step of performing a signing operation on the firmware to be signed in the encrypted directory and generating a signature file, the following steps are further included: After the signing is completed, the non-essential files in the encrypted directory are deleted, and the non-essential files include secret keys, signing tools and scripts.

9. A system for the method of uniformly signing product firmware as described in any one of claims 1 to 8, characterized in that: Applicable to servers, including: The signature request receiving module is used to receive the signature request sent by the client, wherein the parameters carried in the signature request include the product model version, all firmware to be signed contained in the product, and the firmware type; Signature processing module: used to perform unified signature processing on all the firmware to be signed contained in the product according to the product model version and firmware type, and return the signature result to the client.

Images