A certificate-based authorization method and system for firmware startup
Patent Information
- Application Number
- CN202310393590.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-04-13
- Publication Date
- 2026-10-09
- Estimated Expiration
- 2043-04-13
AI Technical Summary
此方法有以下技术缺陷:一是需要在编译时获取到设备的唯一标识,根据唯一标识进行定制化编译,给授权方带来巨大的维护与管理压力;二是生成证书的授权种子与软件携带的授权种子相同,可以通过读取软件二进制文件撞库破解授权种子后使用读取到的设备唯一标识进行自行授权,存在巨大的安全隐患
[0067] (1) The firmware boot method based on certificate authorization provided by this invention stores the certificate file in flash memory after successful authorization. Each time, the certificate file in flash memory is reread to determine whether authorization was successful. This eliminates the need for a TCM security card and security module on the hardware, making it suitable for motherboards without built-in security chips. Furthermore, the solution provided by this invention uses private and public keys for encrypting and decrypting the certificate file respectively. Only the public key is released when the firmware is published. Therefore, even if the public key used to import the firmware is cracked by a user through memory reading, the user cannot generate a private key to independently authorize and crack the firmware, greatly improving the security of firmware authorization.
Smart Images

Figure CN116611034B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of embedded system technology, specifically to a firmware boot method and system based on certificate authorization. Background Technology
[0002] Firmware is a crucial piece of foundational software in a computer system, typically stored permanently in Flash Memory. Motherboards, graphics cards, network cards, and hard drives all contain firmware; although their functions differ, they all essentially use and drive the hardware. The most important firmware in a computer is called the BIOS (Basic Input / Output System), which initializes the motherboard hardware, manages hardware resources, and boots the operating system. It acts as a bridge connecting the computer's basic hardware and system software.
[0003] Firmware plays a vital role in computer functionality, performance, and security, just like core computer components such as the CPU (Central Processing Unit) and operating system. The characteristics of firmware dictate that it boots before the operating system, can access and manipulate hardware, can read and write files, and can read and write information invisible to the operating system. It also has advantages in authorization and authentication, as well as a suitable operating environment.
[0004] Currently, firmware authorization boot methods fall into two categories: those requiring hardware support and those without. One method requiring hardware support is the PIN-based firmware boot method and process (Technical No.: 18144063). This method relies on the TCM (Trusted Computing Platform) security chip integrated into the motherboard, using the security chip to store and verify the PIN code. While this method is relatively secure, it has high hardware requirements and is not suitable for motherboards without a built-in security chip.
[0005] The licensing and authentication methods, electronic devices, and processes for embedded software without hardware support (Technical No.: 26519916) first obtain the device's unique identifier, then generate an authorization certificate using an authorization seed and the unique identifier, and compile it into the embedded software. During software execution, the authorization certificate is parsed using the authorization seed carried by the software and the unique identifier obtained from the device to determine whether authorization was successful. This method has the following technical drawbacks: First, it requires obtaining the device's unique identifier during compilation and performing customized compilation based on the unique identifier, placing a huge maintenance and management burden on the licensor; second, the authorization seed used to generate the certificate is the same as the authorization seed carried by the software, which can be cracked by reading the software binary file and then using the read device's unique identifier to perform unauthorized authorization, posing a significant security risk. Summary of the Invention
[0006] To overcome the shortcomings of the prior art, the present invention provides a firmware boot method and system based on certificate authorization to solve at least one of the above-mentioned technical problems.
[0007] Based on one aspect of this invention, a certificate-based firmware boot method is provided, comprising the following steps:
[0008] S1: Run firmware on the machine, obtain a unique code in the machine, and generate a first unique machine identifier from the unique code.
[0009] A unique code within a machine is a code used to distinguish one machine from another. This code is unique; one machine can only correspond to one code, and one code can only correspond to one machine. A common example is the WWWM (Worldwide Unique Number) on a hard drive, which is burned into each hard drive during manufacturing and will not be repeated with other hard drives. Using this unique code to generate a unique machine identifier ensures that each machine has its own unique identifier for encryption.
[0010] S2: Read the reserved certificate storage space on the flash memory, and determine whether the first certificate file is stored in the certificate storage space. If yes, proceed to step S3; otherwise, proceed to step S4.
[0011] S3: Determine whether the length of the first certificate file meets the expectation (i.e., whether the length of the first certificate file is the same as the length of the standard certificate file). If not, proceed to step S4. If yes, decrypt the first certificate file based on the public key stored in the firmware to obtain the second machine unique identifier. Determine whether the second machine unique identifier is the same as the first machine unique identifier. If yes, the firmware starts normally. If not, proceed to step S4.
[0012] S4: Send the unique identifier of the first machine to the authorized party and perform the following steps:
[0013] S401: Determine whether the authorized party has generated a certificate file for the received first machine unique identifier. If yes, send the certificate file as the second certificate file to the firmware user and proceed to step S5. If no, proceed to step S402.
[0014] S402: Encrypt the unique identifier of the first machine and the customized information of the authorized party based on the private key to obtain the third certificate file, and return the third certificate file to the firmware user;
[0015] S5: Decrypt the second certificate file based on the public key stored in the firmware to obtain the unique identifier of the third machine, and determine whether the unique identifier of the third machine is the same as the unique identifier of the first machine. If yes, the firmware starts; otherwise, proceed to step S402.
[0016] S6: Decrypt the third certificate file based on the public key stored in the firmware to obtain the unique identifier of the fourth machine, and determine whether the unique identifier of the fourth machine is the same as the unique identifier of the first machine. If so, the firmware starts.
[0017] In the above technical solution, the certificate file is stored in flash memory after successful authorization. Each time, the certificate file in flash memory is reread to determine if authorization was successful. This eliminates the need for a hardware-based TCM security card and security module, making it suitable for motherboards without built-in security chips. Furthermore, the solution provided by this invention uses private and public keys for encrypting and decrypting the certificate file respectively. Only the public key is released when firmware is published. Therefore, even if the public key used to import the firmware is cracked by a user through memory reading, the user cannot generate a private key to independently authorize and crack the firmware, greatly improving the security of firmware authorization.
[0018] The second certificate file may be incorrect or expired. Therefore, firmware authorization based on the second certificate file may fail to boot. In this case, a new certificate file (i.e., the third certificate file) needs to be regenerated based on the unique identifier of the first machine. Under normal circumstances, the new certificate file (i.e., the third certificate file) can complete the firmware authorization boot.
[0019] Furthermore, the following steps are included before step S1:
[0020] The public and private keys are obtained using the RSA algorithm module in the system tool OpenSSL. The public key is imported into the firmware, and the private key is stored in the authorized party's local management software.
[0021] Reserve space in the flash memory to store the certificate;
[0022] Compile the firmware and deliver the compiled firmware to the firmware user.
[0023] The RSA algorithm is used to generate both public and private keys simultaneously, but only the public key is released during distribution. Because RSA is an asymmetric encryption algorithm, it has the property that the private key can be used to derive the public key, but the public key can never be used to derive the private key. Therefore, even if a user cracks the public key imported into the firmware by reading its memory, the user cannot generate the private key to independently authorize and crack the firmware, greatly improving the security of firmware authorization.
[0024] Furthermore, the unique encoding includes CPU serial number, hard disk globally unique serial number, or network card MAC address.
[0025] Furthermore, in step S1, a hash algorithm is used to encrypt the code that has unique properties.
[0026] A hash algorithm maps a binary value of arbitrary length to a shorter, fixed-length binary value, called a hash value. A hash value is a unique and extremely compact numerical representation of a piece of data. If you hash a piece of plaintext and change even a single letter, the subsequent hash will produce a different value. Finding two different inputs that hash to the same value is computationally impossible, so the hash value of data can be used to verify data integrity. Hash algorithms have advantages such as ease of calculation, easy reduction, collision resistance, one-way hashing, and high sensitivity.
[0027] Further, in step S5, if the unique identifier of the third machine is the same as the unique identifier of the first machine, the second certificate file is stored in the reserved certificate storage space on the flash memory; if the certificate storage space contains the first certificate file, the first certificate file is deleted. In step S6, if the unique identifier of the fourth machine is the same as the unique identifier of the first machine, the third certificate file is stored in the reserved certificate storage space on the flash memory; if the certificate storage space contains the first certificate file, the first certificate file is deleted.
[0028] If the certificate file is not stored in the reserved certificate storage space on the flash memory, or if the stored certificate file (i.e., the first certificate file) fails to verify (i.e., the first certificate file becomes invalid), the successfully verified second or third certificate file received from the licensor will be stored in the reserved certificate storage space on the flash memory, and the invalid first certificate file stored in the certificate storage space will be deleted. Upon the next firmware boot, the certificate file will be read directly from the certificate storage space for authorization, eliminating the need to request the licensor to generate a certificate file every time the firmware boots, thus reducing the workload of the licensor (developer).
[0029] Furthermore, in step S402, the customized information of the licensor includes at least the certificate release time, certificate validity period, vendor number, and firmware version number.
[0030] The certificate's expiration date can be calculated by using the certificate's issuance date and validity period, and then the certificate's expiration date can be determined based on the current time.
[0031] Furthermore, in step S3, if the determination result is yes, the following steps are also included:
[0032] S301: Decrypt the first certificate file to obtain the first certificate release time, first certificate validity period, first vendor number and first firmware version number;
[0033] S302: Get the current time, read the firmware version number, and read the manufacturer number;
[0034] S303: The expiration time of the first certificate is calculated based on the issuance time and the limited term of the first certificate;
[0035] S304: Perform the following three checks:
[0036] Determine whether the current time in S302 is less than the expiration time of the first certificate;
[0037] Determine whether the first vendor number matches the vendor number in S302;
[0038] Determine whether the firmware version number in the first firmware version is consistent with the firmware version number in S302;
[0039] If all three judgments are true, the firmware will start; otherwise, proceed to step S4.
[0040] By checking whether the certificate file has expired (the certificate file expires when the current time in S302 is greater than or equal to the first certificate expiration time), whether the vendor number is consistent, and whether the firmware version number is consistent, the verification conditions during authorization are increased, thereby enhancing the security of verification.
[0041] Furthermore, in step S5, if the determination result is yes, the following steps are also included:
[0042] S501: Decrypt the second certificate file to obtain the second certificate release time, second certificate validity period, second vendor number, and second firmware version number;
[0043] S502: Get the current time, read the firmware version number, and read the manufacturer number;
[0044] S503: The expiration time of the second certificate is calculated based on the issuance time and limited validity period of the second certificate;
[0045] S503: Perform the following three checks:
[0046] Determine whether the second vendor number matches the vendor number in S502;
[0047] Determine whether the second firmware version number is consistent with the firmware version number in S502;
[0048] Determine whether the current time in S502 is less than the expiration time of the second certificate;
[0049] If the results of the three judgment processes are all yes, then the firmware will start; otherwise, proceed to step S402.
[0050] If the second certificate file fails to meet the above three conditions, it means that the second certificate file stored in the authorizing party cannot enable firmware authorization to start. In this case, the authorizing party needs to regenerate a certificate file and perform authorization verification according to the regenerated certificate file.
[0051] According to another aspect of this invention, a certificate-based firmware boot system is provided, comprising:
[0052] Machine Unique Identifier Generation Module: Used to generate the first machine unique identifier;
[0053] Certificate generation module: used to encrypt the unique identifier of the first machine and the customized information of the authorizing party based on the private key to obtain the third certificate file;
[0054] Certificate acquisition module: used to read certificate files from the certificate storage space reserved on flash memory and to receive second and third certificate files sent by the authorized party;
[0055] Certificate decryption module: used to decrypt the first certificate file, the second certificate file, and the third certificate file based on the public key;
[0056] Judgment module: Used to determine whether the length of the first certificate file meets the expectation. Judgment module is also used to determine whether the second, third and fourth machine unique identifiers are the same as the first machine unique identifier.
[0057] In the above technical solution, the machine unique identifier generation module uses a hash algorithm to encrypt the machine's unique code to generate a first machine unique identifier, and obtains a first certificate file through the certificate acquisition module. If the first certificate file is not obtained, or if the first certificate file fails to be decrypted by the certificate decryption module and verified by the judgment module, the authorized party obtains the first machine unique identifier and generates a third certificate file based on the certificate generation module or retrieves the second certificate file. Then, the certificate acquisition module obtains the second or third certificate file, and finally, the certificate decryption module decrypts the second and / or third certificate files, and the judgment module verifies the decrypted content. If the verification is successful, the firmware starts normally.
[0058] Furthermore, the judgment module is also used to perform the following judgments:
[0059] Determine whether the second vendor number matches the vendor number in S502;
[0060] Determine whether the second firmware version number is consistent with the firmware version number in S502;
[0061] Determine whether the current time in S502 is less than the expiration time of the second certificate;
[0062] Determine whether the current time in S302 is less than the expiration time of the first certificate;
[0063] Determine whether the first vendor number matches the vendor number in S302;
[0064] Determine whether the firmware version number in the first firmware is consistent with the firmware version number in S302.
[0065] The judgment module performs the above judgments, adding verification conditions to the certificate file and thus enhancing the verification security of the certificate file. The judgment module is also used to complete other judgment processes in this invention.
[0066] Compared with the prior art, the beneficial effects of the present invention are as follows:
[0067] (1) The firmware boot method based on certificate authorization provided by this invention stores the certificate file in flash memory after successful authorization. Each time, the certificate file in flash memory is reread to determine whether authorization was successful. This eliminates the need for a TCM security card and security module on the hardware, making it suitable for motherboards without built-in security chips. Furthermore, the solution provided by this invention uses private and public keys for encrypting and decrypting the certificate file respectively. Only the public key is released when the firmware is published. Therefore, even if the public key used to import the firmware is cracked by a user through memory reading, the user cannot generate a private key to independently authorize and crack the firmware, greatly improving the security of firmware authorization.
[0068] (2) The firmware boot method based on certificate authorization provided by the present invention does not rely on the underlying design and security module support, is universally applicable to various firmware boot scenarios, and does not occupy too much space.
[0069] (3) The firmware boot method based on certificate authorization provided by this invention uses an asymmetric encryption algorithm to obtain a public key and a private key. The public key and private key are stored separately to ensure the absolute security of the private key even when the firmware binary is published. The certificate is reread and verified each time the device boots, preventing users from bypassing the authorization process by modifying the flash memory through the driver.
[0070] (4) The firmware boot method based on certificate authorization provided by this invention has the possibility of server-auto-authorization, which can reduce the workload of developers. Different machines can use the same firmware to boot. If unauthorized or expired authorization is found, the machine's unique identifier is sent to the server. After the server obtains the unique identifier, it generates a new certificate and returns it. Based on this idea, batch authorization and management can be realized without developers needing to customize firmware for each machine.
[0071] (5) The present invention provides a firmware boot system based on certificate authorization. The machine unique identifier generation module uses a hash algorithm to encrypt the code with unique properties of the machine to generate a first machine unique identifier, and obtains a first certificate file through the certificate acquisition module. If the first certificate file is not obtained or the first certificate file fails to be verified after being decrypted by the certificate decryption module and verified by the judgment module, the authorizing party obtains the first machine unique identifier and generates a third certificate file based on the certificate generation module or retrieves the second certificate file. Then the certificate acquisition module obtains the second certificate file or the third certificate file. Finally, the second certificate file and / or the third certificate file are decrypted by the certificate decryption module, and the judgment module verifies the decrypted content. If the verification is successful, the firmware boots normally. Attached Figure Description
[0072] Figure 1 This is a flowchart of a firmware boot method according to an embodiment of the present invention;
[0073] Figure 2 This is a schematic diagram of the firmware boot system structure according to an embodiment of the present invention. Detailed Implementation
[0074] The technical solutions of various embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0075] like Figure 1 As shown, this embodiment provides a firmware boot method based on certificate authorization, including the following steps:
[0076] The public and private keys are obtained using the RSA algorithm module in the system tool OpenSSL. The public key is imported into the firmware, and the private key is stored in the local management software of the authorized party. The local management software of the authorized party also stores the generated certificate file.
[0077] Reserve space in the flash memory to store the certificate;
[0078] Compile the firmware and deliver the compiled firmware to the firmware user.
[0079] The RSA algorithm is used to generate both public and private keys simultaneously, but only the public key is released during distribution. Because RSA is an asymmetric encryption algorithm, it has the property that the private key can be used to derive the public key, but the public key can never be used to derive the private key. Therefore, even if a user cracks the public key imported into the firmware by reading its memory, the user cannot generate the private key to independently authorize and crack the firmware, greatly improving the security of firmware authorization.
[0080] S1: Run firmware on the machine, obtain a unique code in the machine, and generate a first machine unique identifier from the unique encryption.
[0081] A unique code within a machine is a code used to distinguish one machine from another. This code is unique; one machine can only correspond to one code, and one code can only correspond to one machine. A common example is the WWWM (Worldwide Unique Number) on a hard drive, which is burned into each hard drive during manufacturing and will not be repeated with other hard drives. Using this unique code to generate a unique machine identifier ensures that each machine has its own unique identifier for encryption.
[0082] Specifically, in this embodiment, the unique codes of the machine include CPU serial number, hard disk globally unique serial number, or network card MAC address, etc.
[0083] As a preferred implementation, this embodiment uses a hash algorithm to encrypt the machine-unique code to generate a first machine-unique identifier.
[0084] S2: Read the reserved certificate storage space on the flash memory, and determine whether the first certificate file is stored in the certificate storage space. If yes, proceed to step S3; otherwise, proceed to step S4.
[0085] S3: Determine whether the length of the first certificate file meets the expectation. If not, proceed to step S4. If yes, decrypt the first certificate file based on the public key stored in the firmware to obtain the second machine unique identifier. Determine whether the second machine unique identifier is the same as the first machine unique identifier. If yes, the firmware starts normally. If not, proceed to step S4.
[0086] In a preferred embodiment, if the determination result of whether the second machine unique identifier is the same as the first machine unique identifier is yes in step S3, then the following steps are further performed:
[0087] S301: Decrypt the first certificate file to obtain the first certificate release time, first certificate validity period, first vendor number and first firmware version number;
[0088] S302: Obtain the current time, read the firmware version number, and read the vendor number; in this embodiment, the current time is obtained from the machine clock, the firmware version number is read from the flash memory, and the vendor number is read from the CPLD;
[0089] S303: The expiration time of the first certificate is calculated based on the issuance time and the limited term of the first certificate;
[0090] S304: Perform the following three checks:
[0091] Determine whether the current time in S302 is less than the expiration time of the first certificate;
[0092] Determine whether the first vendor number matches the vendor number in S302;
[0093] Determine whether the firmware version number in the first firmware version is consistent with the firmware version number in S302;
[0094] If all three judgments are true, the firmware will start; otherwise, proceed to step S4.
[0095] S4: Send the unique identifier of the first machine to the authorized party and perform the following steps:
[0096] S401: Determine whether the authorized party has generated a certificate file for the received first machine unique identifier. If yes, send the certificate file as the second certificate file to the firmware user and proceed to step S5. If no, proceed to step S402.
[0097] S402: Encrypt the unique identifier of the first machine and the customized information of the authorized party based on the private key to obtain the third certificate file, and return the second certificate file to the firmware user, proceed to step S6, and store the newly generated third certificate file in the local management software of the authorized party.
[0098] Specifically, the customized information provided by the licensor includes at least the certificate release date, certificate validity period, vendor number, and firmware version number.
[0099] S5: Decrypt the second certificate file based on the public key stored in the firmware to obtain the unique identifier of the third machine, and determine whether the unique identifier of the third machine is the same as the unique identifier of the first machine. If yes, the firmware starts; otherwise, proceed to step S402.
[0100] In a preferred embodiment, if the determination result of whether the unique identifier of the third machine is the same as the unique identifier of the first machine is yes in step S5, then the following steps are also required:
[0101] S501: Decrypt the second certificate file to obtain the second certificate release time, second certificate validity period, second vendor number, and second firmware version number;
[0102] S502: Get the current time, read the firmware version number, and read the manufacturer number;
[0103] S503: The expiration time of the second certificate is calculated based on the issuance time and limited validity period of the second certificate;
[0104] S503: Perform the following three checks:
[0105] Determine whether the second vendor number matches the vendor number in S502;
[0106] Determine whether the second firmware version number is consistent with the firmware version number in S502;
[0107] Determine whether the current time in S502 is less than the expiration time of the second certificate;
[0108] If the results of the three judgment processes are all yes, then the firmware will start; otherwise, proceed to step S402.
[0109] S6: Decrypt the third certificate file based on the public key stored in the firmware to obtain the unique identifier of the fourth machine, and determine whether the unique identifier of the fourth machine is the same as the unique identifier of the first machine. If so, the firmware starts.
[0110] In a preferred embodiment, if the determination result of whether the unique identifier of the fourth machine is the same as the unique identifier of the first machine is yes in step S6, then the following steps are also required:
[0111] S601: Decrypt the third certificate file to obtain the third certificate release date, third certificate validity period, third vendor number and third firmware version number;
[0112] S602: Get the current time, read the firmware version number, and read the manufacturer number;
[0113] S603: The expiration time of the third certificate is calculated based on the issuance time and limited duration of the third certificate;
[0114] S603: Perform the following three checks:
[0115] Determine whether the third vendor number matches the vendor number in S602;
[0116] Determine whether the firmware version number of the third firmware is consistent with the firmware version number in S602;
[0117] Determine whether the current time in S602 is less than the expiration time of the third certificate;
[0118] If all three judgments are true, then the firmware will start.
[0119] Further, in step S5, if the unique identifier of the third machine is the same as the unique identifier of the first machine, the second certificate file is stored in the reserved certificate storage space on the flash memory; if the certificate storage space contains the first certificate file, the first certificate file is deleted. In step S6, if the unique identifier of the fourth machine is the same as the unique identifier of the first machine, the third certificate file is stored in the reserved certificate storage space on the flash memory; if the certificate storage space contains the first certificate file, the first certificate file is deleted.
[0120] In a preferred implementation, when the second, third, or fourth machine unique identifier is different from the first unique identifier, the number of certificate decryption attempts is recorded. When the number of certificate decryption attempts exceeds a threshold, the firmware is suspended, preventing the user from importing the certificate again.
[0121] Compared to embedded software licensing and authentication methods and electronic devices and processes that use the AES encryption algorithm and include a license seed in the software for both encryption and decryption, this invention uses the RSA algorithm to generate both a public and private key, distributing only the public key upon release. Because RSA is an asymmetric encryption algorithm, it possesses the property that the private key can derive the public key, but the public key can never derive the private key. Therefore, even if a user cracks the public key imported into the firmware by reading memory, the user cannot generate the private key to independently authorize and crack the firmware, greatly improving the security of firmware licensing.
[0122] Unlike PIN-based firmware boot methods and processes, this invention does not store the certificate file in the flash memory after successful authorization. Instead, it stores the certificate file in the flash memory and re-reads it each time to determine if authorization was successful. This is because, unlike PIN-based firmware boot methods and processes, this invention does not rely on a hardware-based TCM security card and security module, which carries the risk of users skipping subsequent authorization authentication by directly modifying the flags in the flash memory. Therefore, it is necessary to save the certificate file and re-determine authorization success each time. This method also allows for better determination of certificate expiration time.
[0123] This embodiment also provides a certificate-based firmware boot system to implement the steps of the certificate-based firmware boot method described in this embodiment, including:
[0124] Machine Unique Identifier Generation Module: Used to generate the first machine unique identifier;
[0125] Certificate generation module: used to encrypt the unique identifier of the first machine and the customized information of the authorizing party based on the private key to obtain the third certificate file;
[0126] Certificate acquisition module: used to read certificate files from the certificate storage space reserved on flash memory and to receive second and third certificate files sent by the authorized party;
[0127] Certificate decryption module: used to decrypt the first certificate file, the second certificate file, and the third certificate file based on the public key;
[0128] Judgment module: Used to determine whether the length of the first certificate file meets the expectation. Judgment module is also used to determine whether the second, third and fourth machine unique identifiers are the same as the first machine unique identifier.
[0129] Furthermore, the judgment module is also used to perform the following judgments:
[0130] Determine whether the second vendor number matches the vendor number in S502;
[0131] Determine whether the second firmware version number is consistent with the firmware version number in S502;
[0132] Determine whether the current time in S502 is less than the expiration time of the second certificate;
[0133] Determine whether the current time in S302 is less than the expiration time of the first certificate;
[0134] Determine whether the first vendor number matches the vendor number in S302;
[0135] Determine whether the firmware version number in the first firmware is consistent with the firmware version number in S302.
[0136] The judgment module is also used to complete other judgment processes in the steps of a certificate-based firmware boot method.
[0137] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the technical solutions of the embodiments of the present invention.
Claims
1. A firmware boot method based on certificate authorization, characterized in that, Includes the following steps: S1: Run firmware on the machine, obtain a unique code in the machine, and encrypt the unique code to generate a first unique machine identifier; S2: Read the reserved certificate storage space on the flash memory, and determine whether the first certificate file is stored in the certificate storage space. If yes, proceed to step S3; otherwise, proceed to step S4. S3: Determine whether the length of the first certificate file meets the expectation. If not, proceed to step S4. If yes, decrypt the first certificate file based on the public key stored in the firmware to obtain the second machine unique identifier. Determine whether the second machine unique identifier is the same as the first machine unique identifier. If yes, the firmware starts normally. If not, proceed to step S4. S4: Send the unique identifier of the first machine to the authorized party and perform the following steps: S401: Determine whether the authorized party has generated a certificate file for the received first machine unique identifier. If yes, send the certificate file as the second certificate file to the firmware user and proceed to step S5. If no, proceed to step S402. S402: Encrypt the unique identifier of the first machine and the customized information of the authorized party based on the private key to obtain the third certificate file, and return the third certificate file to the firmware user, and proceed to step S6; S5: Decrypt the second certificate file based on the public key stored in the firmware to obtain the unique identifier of the third machine, and determine whether the unique identifier of the third machine is the same as the unique identifier of the first machine. If yes, the firmware starts; otherwise, proceed to step S402. S6: Decrypt the third certificate file based on the public key stored in the firmware to obtain the unique identifier of the fourth machine, and determine whether the unique identifier of the fourth machine is the same as the unique identifier of the first machine. If so, the firmware starts.
2. The firmware boot method based on certificate authorization according to claim 1, characterized in that, The following steps are included before step S1: The public and private keys are obtained using the RSA algorithm module in the system tool OpenSSL. The public key is imported into the firmware, and the private key is stored in the authorized party's local management software. Reserve space in the flash memory to store the certificate; Compile the firmware and deliver the compiled firmware to the firmware user.
3. The firmware boot method based on certificate authorization according to claim 1, characterized in that, The unique encoding includes CPU serial number, hard disk globally unique serial number, or network card MAC address.
4. The firmware boot method based on certificate authorization according to claim 1, characterized in that, In step S1, a hash algorithm is used to encrypt the code that has unique properties.
5. The firmware boot method based on certificate authorization according to claim 1, characterized in that, In step S5, if the unique identifier of the third machine is the same as the unique identifier of the first machine, the second certificate file is stored in the reserved certificate storage space on the flash memory; if the certificate storage space contains the first certificate file, the first certificate file is deleted. In step S6, if the unique identifier of the fourth machine is the same as the unique identifier of the first machine, the third certificate file is stored in the reserved certificate storage space on the flash memory; if the certificate storage space contains the first certificate file, the first certificate file is deleted.
6. The firmware boot method based on certificate authorization according to claim 1, characterized in that, In step S402, the customized information of the licensor includes at least the certificate release time, certificate validity period, vendor number, and firmware version number.
7. The firmware boot method based on certificate authorization according to claim 6, characterized in that, In step S3, if the determination result is yes, the following steps are also included: S301: Decrypt the first certificate file to obtain the first certificate release time, first certificate validity period, first vendor number and first firmware version number; S302: Get the current time, read the firmware version number, and read the manufacturer number; S303: The expiration time of the first certificate is calculated based on the issuance time and the limited term of the first certificate; S304: Perform the following three checks: Determine whether the current time in S302 is less than the expiration time of the first certificate; Determine whether the first vendor number matches the vendor number in S302; Determine whether the firmware version number in the first firmware version is consistent with the firmware version number in S302; If all three judgments are true, the firmware will start; otherwise, proceed to step S4.
8. The firmware boot method based on certificate authorization according to claim 6, characterized in that, In step S5, if the determination result is yes, the following steps are also included: S501: Decrypt the second certificate file to obtain the second certificate release time, second certificate validity period, second vendor number, and second firmware version number; S502: Get the current time, read the firmware version number, and read the manufacturer number; S503: The expiration time of the second certificate is calculated based on the issuance time and limited validity period of the second certificate; S503: Perform the following three checks: Determine whether the second vendor number matches the vendor number in S502; Determine whether the second firmware version number is consistent with the firmware version number in S502; Determine whether the current time in S502 is less than the expiration time of the second certificate; If the results of the three judgment processes are all yes, then the firmware will start; otherwise, proceed to step S402.
9. A certificate-based firmware boot system, used to implement the steps of a certificate-based firmware boot method as described in any one of claims 1-8, characterized in that, include: Machine Unique Identifier Generation Module: Used to generate the first machine unique identifier; Certificate generation module: used to encrypt the unique identifier of the first machine and the customized information of the authorizing party based on the private key to obtain the third certificate file; Certificate acquisition module: used to read certificate files from the certificate storage space reserved on flash memory and to receive second and third certificate files sent by the authorized party; Certificate decryption module: used to decrypt the first certificate file, the second certificate file, and the third certificate file based on the public key; Judgment module: Used to determine whether the length of the first certificate file meets the expectation. Judgment module is also used to determine whether the second, third and fourth machine unique identifiers are the same as the first machine unique identifier.
10. A certificate-based firmware boot system according to claim 9, characterized in that, The judgment module is also used to perform the following judgments: Determine whether the second vendor number matches the vendor number in S502; Determine whether the second firmware version number is consistent with the firmware version number in S502; Determine whether the current time in S502 is less than the expiration time of the second certificate; Determine whether the current time in S302 is less than the expiration time of the first certificate; Determine whether the first vendor number matches the vendor number in S302; Determine whether the firmware version number in the first firmware is consistent with the firmware version number in S302.
Citation Information
Patent Citations
Code protection method for chip
CN111475815A
Operating system booting method, firmware, security certificate and computer
CN112395621A