Firmware updating method and device and storage medium

Abstract

The invention discloses a firmware updating method and device and a storage medium, and relates to the technical field of computers, and the firmware updating method comprises the following steps: performing security verification processing on first firmware according to a firmware updating request to determine whether the first firmware is secure firmware; and performing version verification processing on the first firmware to determine whether the version of the first firmware is abnormal or not. And performing timestamp verification on the first firmware, and determining whether the version of the first firmware is abnormal or not according to the release moment of the first firmware. And performing rollback processing on the first firmware to determine whether the first firmware is abnormal or not. The technical problem of ensuring the security of the firmware to be updated is solved, and the technical effect of improving the firmware updating security is achieved.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and in particular, to a firmware update method, device, and storage medium. Background Art

[0002] Currently, various requirements of users for a server can be met by updating the firmware in the server.

[0003] In the actual application process, when a firmware update is required, the server obtains the firmware to be updated and performs a verification process on the firmware to be updated. When the verification passes, the firmware is updated. In the above process, how to ensure the security of the firmware to be updated is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a firmware update method, device, and storage medium to at least solve the problem of low security in firmware update in related technologies.

[0005] This application provides a firmware update method, including:

[0006] Obtaining a firmware update request, where the firmware update request includes an identifier of a first firmware and a release time corresponding to the first firmware;

[0007] Performing a security verification process and a version verification process on the first firmware according to the identifier of the first firmware to obtain a security type and a version type of the first firmware;

[0008] Performing a timestamp verification process and a rollback verification process on the first firmware according to the firmware update request to obtain a timestamp type and a rollback type of the first firmware;

[0009] Updating the first firmware according to the security type, version type, timestamp type, and rollback type of the first firmware to obtain a target firmware.

[0010] This application also provides a firmware update device, including:

[0011] An obtaining module, configured to obtain a firmware update request, where the firmware update request includes an identifier of a first firmware and a release time corresponding to the first firmware;

[0012] A processing module, configured to perform a security verification process and a version verification process on the first firmware according to the identifier of the first firmware to obtain a security type and a version type of the first firmware;

[0013] The processing module is further configured to perform a timestamp verification process and a rollback verification process on the first firmware according to the firmware update request to obtain a timestamp type and a rollback type of the first firmware;

[0014] An update module, configured to update the first firmware according to the security type, version type, timestamp type, and rollback type of the first firmware to obtain a target firmware.

[0015] This application also provides a firmware update device, including: a memory for storing a computer program; a processor for implementing the steps of any of the above firmware update methods when executing the computer program.

[0016] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program implements the steps of any of the above firmware update methods when executed by a processor.

[0017] This application also provides a computer program product, including a computer program that implements the steps of any of the above firmware update methods when executed by a processor.

[0018] With this application, by using multiple verification methods, it is determined that the first firmware is a firmware that can be updated, avoiding situations such as updating abnormal firmware, being attacked during update, and data leakage during the firmware update process. Therefore, the technical problem of ensuring the security of the firmware to be updated can be solved, achieving the technical effect of improving the security of firmware update. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] To more clearly illustrate the embodiments of this application, the following will briefly introduce the drawings required for the embodiments. Obviously, the drawings in the following description are only some embodiments of this application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0020] Figure 1 Schematic diagram of the application scenario provided by the embodiment of this application;

[0021] Figure 2 Schematic flow chart of firmware update provided by the embodiment of this application Figure 1 ;

[0022] Figure 3 Schematic diagram of the process of obtaining a firmware update request provided by the embodiment of this application;

[0023] Figure 4 Schematic flow chart of firmware update provided by the embodiment of this application Figure 2 ;

[0024] Figure 5 Schematic diagram of the process of firmware update provided by the embodiment of this application;

[0025] Figure 6 Schematic diagram of the structure of the firmware update device provided by the embodiment of this application;

[0026] Figure 7 The structural schematic diagram of the firmware update device provided for this application. Detailed implementation manners

[0027] Next, the technical solutions in the embodiments of this application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of this application.

[0028] It should be noted that in the description of this application, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0029] During the firmware update process, security verification processing is performed on the first firmware to determine whether the first firmware is a secure firmware. Version verification processing is performed on the first firmware to determine whether the version of the first firmware is abnormal. Timestamp verification is performed on the first firmware to determine whether there is an abnormality in the version of the first firmware based on the release time of the first firmware. Rollback processing is performed on the first firmware to determine whether there is an abnormality in the first firmware. Through the above multiple verification methods, it is determined that the first firmware is a firmware that can be updated, avoiding situations such as updating abnormal firmware, being attacked during the update, and data leakage during the firmware update process, and improving the security of the firmware update.

[0030] In order to enable those skilled in the art of this technology to better understand the solution of this application, the following further detailed description of this application will be made in conjunction with the accompanying drawings and specific implementation manners.

[0031] Combined with the specific application environment architecture or specific hardware architecture on which the execution of the firmware update method depends, the specific application environment architecture or specific hardware architecture is described herein. Refer to Figure 1 , Figure 1 which is the schematic diagram of the application scenario provided for the embodiments of this application. As Figure 1As shown, it includes a terminal device 101 and a firmware update device 102. The terminal device 101 can be a mobile phone, a tablet computer, a computer, etc. The firmware update device 102 can be a server. A user can generate a firmware update request through the terminal device 101 and send the firmware update request to the firmware update device 102. The firmware update device 102 determines the first firmware to be updated in the firmware update device 102 according to the firmware update request, and performs an update process on the first firmware to obtain a target firmware.

[0032] Figure 2 The flowchart of the firmware update provided by the embodiment of the present application Figure 1 is as follows Figure 2 As shown, an embodiment of the present application provides a firmware update method, and the method will be described in detail as follows:

[0033] S201: Obtain a firmware update request.

[0034] The execution subject of the embodiment of the present application can be a firmware update device or a data processing device set in the firmware update device. The firmware update device can be implemented by software or by a combination of software and hardware. The firmware update device can be a server.

[0035] The firmware update request includes the identifier of the first firmware and the release time corresponding to the first firmware.

[0036] Firmware is permanent or semi-permanent software embedded in a hardware device, directly controlling the operation of the hardware and acting as a bridge between the hardware and high-level software (such as an operating system). It is usually stored in the ROM, EEPROM or Flash memory of the device and has the characteristics of low latency and high reliability.

[0037] Exemplarily, if the firmware update device is a server, the first firmware can be a Baseboard Management Controller (BMC).

[0038] Exemplarily, the release time corresponding to the first firmware can be the time generated during the version compilation of the first firmware in the server.

[0039] The user can determine the identifier of the first firmware on the page provided by the terminal device. The terminal device determines the release time corresponding to the first firmware in response to the user's input selection operation. And according to the identifier of the first firmware and the release time corresponding to the first firmware, a firmware update request is generated. The terminal device sends the firmware update request to the firmware update device.

[0040] Next, in combination with Figure 3 the process of obtaining the firmware update request will be described. Figure 3Schematic diagram of the process for obtaining a firmware update request provided by an embodiment of this application. Please refer to Figure 3 , including interface 301 to interface 302. Interface 301 to interface 302 can be pages provided by the terminal device. Please refer to interface 301. In the main page provided by the terminal device, the user clicks on the icon corresponding to the firmware update application. In response to the user's input selection operation, the terminal device displays the operation page of the firmware update application. The operation page includes a drop-down selection menu corresponding to the identifiers of multiple firmwares.

[0041] Please refer to interface 302. The user determines that the identifier of the firmware is Firmware A in the drop-down selection menu corresponding to identifier 1, and clicks on the icon corresponding to OK. In response to the user's input selection operation, the terminal device determines the release time corresponding to the first firmware. And based on the identifier of the first firmware and the release time corresponding to the first firmware, a firmware update request is generated. The terminal device sends the firmware update request to the firmware update device. The firmware update request received by the firmware update device includes Firmware A; A year, B month, C day, D hour, E second.

[0042] Optionally, the storage space of the terminal device can store the identifiers of multiple firmwares and the release time corresponding to each firmware identifier. The terminal device can obtain the release time corresponding to the first firmware from the storage space based on the identifier of the first firmware, and generate a firmware update request. Or, the terminal device obtains the release time corresponding to the first firmware from the server based on the identifier of the first firmware, and generates a firmware update request. The server stores the identifiers of multiple firmwares and the release time corresponding to each firmware identifier.

[0043] S202: According to the identifier of the first firmware, perform security verification processing and version verification processing on the first firmware to obtain the security type and version type of the first firmware.

[0044] Exemplarily, the security type can be a normal security type or an abnormal security type. The version type is a normal version type and an abnormal version type.

[0045] The firmware update device can obtain the target hash value generated during the firmware compilation phase according to the identifier of the first firmware. The firmware update device obtains the current update environment data, and determines the security type of the first firmware based on the target similarity between the environment data and the target hash value.

[0046] Exemplarily, the environment data can be noise data collected in a Trusted Execution Environment (TEE). TEE is a hardware-level secure isolation environment created in a general computing device (such as a terminal device, server) to protect sensitive data and code from being damaged or stolen by the main operating system (such as Android, Linux) or other applications.

[0047] In the TEE environment, the firmware or data can be protected from being attacked or leaked during the firmware update process, further enhancing the security of the firmware update.

[0048] For example, as shown in the above example, the identifier of the first firmware is determined to be Firmware A. The firmware update device obtains the target hash value generated during the compilation stage of Firmware A as Hash Value 1. The firmware update device obtains the current updated environmental data and determines the security type of the first firmware as the normal security type based on the target similarity between the environmental data and the target hash value.

[0049] The security verification process is used to determine whether the first firmware is a secure firmware. During the security verification process, since the target hash value is obtained through encryption, it needs to be decrypted first before determining the target similarity. By decrypting and then performing the verification, it can be avoided that the first firmware is an insecure firmware, resulting in insecure situations such as the firmware update device being attacked and data being leaked.

[0050] The version verification process is used to verify the specific content and format of the version of the first firmware to avoid errors during the firmware update.

[0051] For example, as shown in the above example, the identifier of the first firmware is determined to be Firmware A. The firmware update device obtains the version format corresponding to Firmware A and determines that the version format is the correct format. Therefore, the firmware update device determines the version type of the first firmware as the normal version type.

[0052] S203: According to the firmware update request, perform a timestamp verification process and a rollback verification process on the first firmware to obtain the timestamp type and rollback type of the first firmware.

[0053] Exemplarily, the timestamp type can be the normal timestamp type or the abnormal timestamp type. The rollback type can be the normal rollback type, the intermediate rollback type, or the abnormal rollback type.

[0054] The timestamp verification process is used to verify whether the release time corresponding to the first firmware is the correct time generated during the version compilation stage. The correct time generated during the version compilation stage is stored in the firmware update device.

[0055] For example, as shown in the above example, the identifier of the first firmware is determined to be Firmware A. The firmware update device obtains the correct time generated during the version compilation stage of Firmware A as A year B month C day D hour E second. The firmware update device obtains the release time corresponding to the first firmware in the firmware update request as A year B month C day D hour E second. Since the correct time generated during the version compilation stage of Firmware A is the same as the release time corresponding to the first firmware. Therefore, the firmware update device determines the timestamp type of the first firmware as the normal timestamp type.

[0056] The timestamp verification process can determine whether the release time of the first firmware is the correct time. In this way, it is possible to avoid the situation where the first firmware is other firmware, resulting in abnormal firmware updates, data being attacked or leaked.

[0057] The rollback verification can determine whether new security issues are generated during the current firmware update. It can also re-verify the security issues generated during updates in historical periods.

[0058] Exemplarily, the rollback verification process can confirm whether the firmware update updates back to a historical version, reducing the possibility of a rollback attack.

[0059] For example, as shown in the above example, it is determined that the identifier of the first firmware is Firmware A. The firmware update device obtains the abnormal data generated during the firmware update of Firmware A in the historical period. And perform a verification process on Firmware A and the abnormal data to obtain that the rollback type of the first firmware is the normal type.

[0060] The rollback verification process can determine whether there are abnormalities when the first firmware is updated. In this way, it is possible to avoid the situation of abnormal firmware updates, data being attacked or leaked, improving the security of firmware updates. And the rollback verification process can verify the abnormalities generated by historical updates, avoiding the same abnormalities in each firmware update, and improving the reliability of firmware updates.

[0061] S204: Update the first firmware according to the security type, version type, timestamp type, and rollback type of the first firmware to obtain the target firmware.

[0062] The first firmware can be updated to obtain the target firmware in the following way according to the security type, version type, timestamp type, and rollback type of the first firmware: If the security type of the first firmware is the normal security type, the version type of the first firmware is the normal version type, the timestamp type of the first firmware is the normal timestamp type, and the rollback type of the first firmware is the normal rollback type, then determine that the verification result is verification passed; If the security type of the first firmware is an abnormal security type, or the version type of the first firmware is an abnormal version type, or the timestamp type of the first firmware is an abnormal timestamp type, or the rollback type of the first firmware is an abnormal rollback type, then determine that the verification result is verification failed; When the verification result is verification passed, update the first firmware to obtain the target firmware.

[0063] For example, as shown in the above example, the specific types of Firmware A can be as shown in Table 1:

[0064] Table 1

[0065]

[0066] As shown in Table 1, it is determined that the security type of the first firmware is the normal security type, the version type of the first firmware is the normal version type, the timestamp type of the first firmware is the normal timestamp type, and the rollback type of the first firmware is the normal rollback type. Therefore, the firmware update device determines that the verification result is verification passed. The firmware update device updates the first firmware to obtain the target firmware.

[0067] The firmware update method provided by the embodiments of the present application determines, through the above multiple verification methods, that the first firmware is a firmware that can be updated, avoiding situations such as updating abnormal firmware, being attacked during the update, and data leakage during the firmware update process, and improving the security of the firmware update.

[0068] Based on any of the above embodiments, below, in combination with Figure 4 , the specific process of the firmware update will be described.

[0069] Figure 4 is a schematic flow of the firmware update provided by the embodiments of the present application Figure 2 , as Figure 4 shown, the embodiments of the present application provide another firmware update method, and the method will be described in detail as follows:

[0070] S401: Obtain a firmware update request.

[0071] Before making a firmware update request, the firmware can be compiled to obtain a target hash value.

[0072] The target hash value can be obtained in the following manner: Obtain initial environment data; process the initial environment data through a first preset algorithm to obtain at least one initial environment field; obtain the first code of the first firmware; process at least one initial environment field and the first code through a second preset algorithm to obtain a first hash value; perform a signature process on the first hash value according to the first private key information to obtain the target hash value.

[0073] Exemplarily, if the first firmware is BMC, when the hardware corresponding to BMC is produced, the cold start characteristic of the memory in the hardware corresponding to BMC is activated through TEE. And the initial noise of the memory at the moment of power-on is collected as the initial environment data.

[0074] The cold start characteristic is the characteristic that the memory still retains data briefly after power-off.

[0075] For example, the memory can be a Static Random-Access Memory (SRAM).

[0076] Optionally, the first preset algorithm and the second preset algorithm can be set in advance and stored in the storage space of the firmware update device. The first preset algorithm can be a hash algorithm, and the second preset algorithm can be a Physical Unclonable Function (PUF).

[0077] For example, the hash algorithm can be the Secure Hash Algorithm 3 (SHA-3) algorithm.

[0078] PUF is a security primitive based on the physical characteristics of hardware. It uses the inevitable microscopic differences in the manufacturing process (such as the process deviation of the chip) to generate a unique and non-replicable "digital fingerprint", which is often used for device authentication, key generation, and anti-counterfeiting.

[0079] Processing the initial environment data through the first preset algorithm to obtain at least one initial environment field, and the length of the at least one initial environment field is a preset length. For example, the preset length can be 256.

[0080] In the firmware compilation stage, the PUF SDK can be integrated through the development environment, the PUF function can be called, and the first code can be combined with at least one initial environment field to generate a first hash value.

[0081] The first key information can be generated during the hardware production stage corresponding to the firmware and stored in the memory of the hardware. The first key information includes the first public key information and the first private key information.

[0082] After performing a signature process on the first hash value according to the first private key information to obtain the target hash value, the target hash value can be stored in the memory of the hardware.

[0083] Generating the target hash value through the hash algorithm and PUF can improve the security in the subsequent verification process.

[0084] S402: Perform a security verification process on the first firmware according to the identifier of the first firmware to obtain the security type of the first firmware.

[0085] The security verification process of the first firmware can be performed according to the identifier of the first firmware in the following manner to obtain the security type of the first firmware: Obtain the target hash value of the first firmware according to the identifier of the first firmware; perform parsing processing on the target hash value according to the target hash value to obtain the initial environment data; obtain the currently updated environment data; obtain the target similarity between the environment data and the initial environment data; if the target similarity is greater than or equal to the preset similarity, determine that the security type of the first firmware is the normal security type; if the target similarity is less than the preset similarity, determine that the security type of the first firmware is the abnormal security type.

[0086] Exemplarily, after obtaining the target hash value, the firmware update device can perform parsing processing on the target hash value according to the first public key information to obtain the initial noise data.

[0087] Exemplarily, the target similarity between the environment data and the target hash value can be obtained through a similarity algorithm.

[0088] Optionally, the preset similarity can be set in advance and stored in the preset storage space of the firmware update device. The preset similarity can be 0.97.

[0089] For example, assume that the identifier of the first firmware is Firmware B, and the initial environment data is the initial noise of the memory in the hardware corresponding to Firmware B when powering on. During the security verification process, the target hash value of Firmware B is obtained as Hash Value 2. The firmware update device performs parsing processing on Hash Value 2 to obtain the initial environment data as Noise Data 1. The firmware update device obtains the currently updated environment data of Firmware B, which is Noise Data 2. The firmware update device obtains the target similarity between Noise Data 2 and Noise Data 1 through a similarity algorithm, which is 0.98. The firmware update device obtains the preset similarity as 0.97. Since the target similarity is greater than the preset similarity, the firmware update device determines that the security type of Firmware B is the normal security type.

[0090] Optionally, before performing the security verification process, the firmware signature can be verified whether it is a secure signature through a secure boot chain.

[0091] Exemplarily, if the security type of the first firmware is the abnormal security type, a first response message is generated. The first response message is used to indicate that the security verification fails, and the security type of the first firmware is the abnormal security type. The firmware update device can store the first response message and send the first response message to the terminal device.

[0092] Optionally, if the security type of the first firmware is the abnormal security type, it can be determined whether to perform subsequent verification processing according to the first indication information. The first indication information can be pre-configured or can be set by the user in real time according to the first response message.

[0093] If the first indication information indicates not to perform subsequent verification processing, the firmware update device does not perform subsequent verification processing and does not update the first firmware.

[0094] If the first indication information indicates to perform subsequent verification processing, the firmware update device may default to perform version verification processing, timestamp verification processing, and rollback verification processing. Further, the first indication information may indicate to perform at least one of version verification processing, timestamp verification processing, and rollback verification processing, so that the firmware update device performs corresponding verification processing.

[0095] For example, the first indication information indicates to perform subsequent verification processing and indicates to perform version verification processing, timestamp verification processing, and rollback verification processing. Then the firmware update device performs version verification processing, timestamp verification processing, and rollback verification processing on the first firmware according to the indication information.

[0096] S403: Perform version verification processing on the first firmware according to the identifier of the first firmware to obtain the version type of the first firmware.

[0097] The version verification processing of the first firmware can be performed according to the identifier of the first firmware in the following manner to obtain the version type of the first firmware: According to the identifier of the first firmware, obtain at least one version field and the second public key information of the first firmware; according to the second public key information, perform parsing processing on at least one version field to obtain the version identifier of the first firmware; perform matching processing on the format of the version identifier and at least one preset format to obtain a matching result. If the matching result is a pass, determine that the version type of the first firmware is a normal version type; if the matching result is a fail, determine that the version type of the first firmware is an abnormal version type.

[0098] Exemplarily, the version identifier of the first firmware may be a semantic version number. The semantic version number includes a major version number.minor version number.patch number.build number.

[0099] For example, the version identifier of the first firmware may be (such as 24.12.01.2048).

[0100] Convert the version identifier of the first firmware into a 128-bit integer. Generate second key information through an elliptic curve obfuscation algorithm. The second key information includes second public key information and second private key information. Generate a 256-bit random number through a quantum random number generator to obtain at least one version field. The at least one version field includes the version identifier of the first firmware and the random number. Write it into the version identifier area of the firmware header. Store the at least one version field and the second key information in the memory of the hardware corresponding to the first firmware.

[0101] For example, the elliptic curve obfuscation algorithm can be the NIST P-384 curve.

[0102] When performing version verification processing, the firmware update device obtains at least one version field and second public key information from the memory. And according to the second public key information, it performs parsing processing on at least one version field to obtain the version identifier of the first firmware, that is, it parses to obtain a semantic version number.

[0103] Optionally, after obtaining at least one version field, the firmware update device can also verify the randomness of at least one version field through the NIST SP 800-90B test to prevent replay attacks.

[0104] The format of the version identifier can be matched with at least one preset format in the following way to obtain a matching result: If there is a preset format in at least one preset format that matches the format of the version identifier, it is determined that the matching result is a pass; If there is no preset format in at least one preset format that matches the format of the version identifier, it is determined that the matching result is a fail.

[0105] Exemplarily, at least one preset format can be set in advance and stored in the preset storage space of the firmware update device. The preset format can be a time format, a semantic format, a version operator format, etc.

[0106] Exemplarily, if the preset format is the same as the format of the version identifier, or the similarity between the preset format and the format of the version identifier is greater than or equal to a first preset value, it can be determined that the preset format matches the format of the version identifier. If the preset format is different from the format of the version identifier, or the similarity between the preset format and the format of the version identifier is less than the first preset value, it can be determined that the preset format does not match the format of the version identifier.

[0107] For example, assume that the preset format includes: time format (year / month / day); semantic format (major version, minor version, patch version); version operator format (major version, vendor representative, patch version). The version format of Firmware B is time format A year B month C day. If there is a preset format (year / month / day) in at least one preset format of the firmware update device that matches the format of the version identifier, it is determined that the matching result is a pass. Therefore, the firmware update device determines that the version type of the first firmware is a normal version type.

[0108] Exemplarily, if the version type of the first firmware is an abnormal version type, a second response message is generated. The second response message is used to indicate that the version verification fails and the version type of the first firmware is an abnormal version type. The firmware update device can store the second response message and send the second response message to the terminal device.

[0109] Optionally, if the version type of the first firmware is an abnormal version type, it is possible to determine whether to perform subsequent verification processing according to the second indication information. The second indication information can be pre-configured or can be set by the user in real time according to the second response information.

[0110] It should be noted that the relevant description of the second indication information can refer to the first indication information and will not be elaborated here.

[0111] S404: Perform a timestamp verification process on the first firmware according to the firmware update request to obtain the timestamp type of the first firmware.

[0112] The timestamp verification process on the first firmware can be performed according to the firmware update request in the following way to obtain the timestamp type of the first firmware: obtain the preset moment corresponding to the first firmware; if the release moment matches the preset moment, determine that the timestamp type of the first firmware is the normal timestamp type; if the release moment does not match the preset moment, determine that the timestamp type of the first firmware is the abnormal timestamp type.

[0113] Exemplarily, it is possible to set in advance the identifier of at least one firmware and the preset moment corresponding to the identifier of each firmware, and store the identifier of at least one firmware and the preset moment corresponding to the identifier of each firmware in the preset storage space of the firmware update device. The preset moment corresponding to the identifier of each firmware can be the moment generated during the compilation stage of the firmware.

[0114] Exemplarily, if the release moment is the same as the preset moment, or the time difference between the release moment and the preset moment is less than or equal to the second preset value, it can be determined that the release moment matches the preset moment. If the release moment is different from the preset moment, or the time difference between the release moment and the preset moment is greater than the second preset value, it can be determined that the release moment does not match the preset moment.

[0115] For example, as shown in the above example, it is determined that the identifier of the first firmware is Firmware B. The firmware update device obtains the preset moment corresponding to Firmware B as A year B month C day D hour E second. The firmware update device determines according to the release moment corresponding to the first firmware in the firmware update request as A year B month C day D hour E second. Since the release moment of Firmware B is the same as the preset moment, it can be determined that the release moment matches the preset moment. Therefore, the firmware update device determines that the timestamp type of the first firmware is the normal timestamp type.

[0116] Exemplarily, if the version type of the first firmware is the abnormal timestamp type, a third response information is generated. The third response information is used to indicate that the timestamp verification fails, and the timestamp type of the first firmware is the abnormal timestamp type. The firmware update device can store the third response information and send the third response information to the terminal device.

[0117] Optionally, if the version type of the first firmware is an abnormal timestamp type, it is possible to determine whether to perform subsequent verification processing according to the third indication information. The third indication information can be pre-configured or can be set by the user in real time according to the third response information.

[0118] It should be noted that the relevant description of the third indication information can refer to the first indication information and will not be elaborated here.

[0119] S405: Perform a rollback verification process on the first firmware according to the firmware update request to obtain the rollback type of the first firmware.

[0120] If the rollback type is a normal rollback type, it indicates that there are no security issues with the first firmware and firmware update can be performed. If the rollback type is an abnormal rollback type, it indicates that there are very serious security issues with the first firmware and firmware update cannot be performed. If the rollback type is an intermediate rollback type, it indicates that there are certain security issues and it is possible to determine whether to perform firmware update according to user needs.

[0121] Optionally, if the rollback type is an abnormal rollback type, a fourth response information can also be generated. The fourth response information is used to indicate that the rollback verification fails and the rollback type of the first firmware is an abnormal rollback type. The firmware update device can store the fourth response information and send the fourth response information to the terminal device.

[0122] If the rollback type is an intermediate rollback type, determine the prompt information according to the identifier of the first firmware and the data generated by the rollback verification. The prompt information includes the identifier of the first firmware, the version identifier of the first firmware, the abnormal data corresponding to the rollback verification, and the abnormal level corresponding to the abnormal data; store the prompt information, or send the prompt information to a preset device.

[0123] During the historical period, the version identifier of the firmware version corresponding to the normal rollback type, as well as the prompt information generated by the intermediate rollback type, can be stored in the preset storage space of the firmware update device. When performing the rollback verification this time, check whether there is abnormal data in the prompt information generated by the historical intermediate rollback type and update the stored prompt information.

[0124] Exemplarily, the severity level can include level 0, level 1, level 2, level 3, and level 4.

[0125] Exemplarily, the preset device can be a device set by the user. For example, the preset device can be the terminal device used by the user.

[0126] After the firmware update device sends a prompt message to a preset device, if a feedback message corresponding to the prompt message is received within a preset duration, it determines whether to perform a firmware update according to the feedback message. If a feedback message corresponding to the prompt message is not received within the preset duration, the firmware update is not performed. The preset duration can be 5 minutes.

[0127] For example, the firmware update device determines that the rollback type is an intermediate rollback type and generates a prompt message. The prompt message may include Firmware B, version A year B month C day, abnormal data, and severity level 0. The firmware update device sends the prompt message to the terminal device and receives the feedback message sent by the terminal device within 5 minutes. If the firmware update device determines that the feedback message indicates to perform a firmware update, it updates Firmware B to obtain the target firmware.

[0128] S406: Update the first firmware according to the security type, version type, timestamp type, and rollback type of the first firmware to obtain the target firmware.

[0129] After the firmware update is completed, store the firmware version information, timestamp, format, etc. of each successful update in the preset storage space of the firmware update device. When subsequent verification of the firmware update can be performed, it is determined whether the firmware of this version already exists in the internal verification and is consistent with the currently received information. This method can further prevent rollback attacks, and the security permission firmware update record ensures that the firmware version cannot be rolled back.

[0130] The firmware update method provided by the embodiments of the present application, through the above multiple verification methods, if it is determined that the first firmware is abnormal, it is updated according to the user feedback, or not updated. If it is determined that the first firmware is normal, the first firmware is updated. In this way, situations such as updating abnormal firmware, being attacked during the update, and data leakage during the firmware update process can be avoided, improving the security and reliability of the firmware update.

[0131] Based on any one of the above embodiments, below, in combination with Figure 5 , an example of the firmware update process is given.

[0132] Figure 5 It is a schematic diagram of the firmware update process provided by the embodiments of the present application. As Figure 5 shown, it includes a terminal device 501 and a firmware update device 502. At the factory stage of the firmware update device 502, the firmware update device 502 generates first key information, and the first key information includes first private key information and first public key information.

[0133] During the firmware compilation stage, the firmware update device 502 can obtain initial environment data and process the initial environment data through a hashing algorithm to obtain at least one initial environment field. The firmware update device 502 obtains the first code of the first firmware and processes at least one initial environment field and the first code through the PUF to obtain a first hash value. According to the first private key information, the first hash value is signed to obtain a target hash value. The firmware update device 502 stores the target hash value and the first key information in a preset storage space.

[0134] During the compilation stage, the firmware update device 502 generates a version identifier for the first firmware and converts the version identifier of the first firmware into a 128-bit integer. Through an elliptic curve obfuscation algorithm, second key information is generated, where the second key information includes second public key information and second private key information. A 256-bit random number is generated through a quantum random number generator to obtain at least one version field. The at least one version field includes the version identifier of the first firmware and the random number. The version identifier is written to the version identifier area of the firmware header. The at least one version field and the second key information are stored in a preset storage space.

[0135] The user can determine that the identifier of the first firmware is Firmware C on the page provided by the application of the terminal device 501. In response to the user's input selection operation, the terminal device 501 determines that the release time corresponding to the first firmware is Time 1. The terminal device 501 generates a firmware update request according to the identifier of the first firmware and the release time corresponding to the first firmware. The terminal device 501 sends the firmware update request to the firmware update device 502, and the firmware update request includes Firmware C and Time 1.

[0136] The firmware update device 502 obtains the target hash value of the first firmware according to the identifier of the first firmware. According to the target hash value, parsing processing is performed on the target hash value to obtain initial environment data. The firmware update device 502 obtains that the target similarity between the environment data and the initial environment data is 0.97. The firmware update device 502 obtains a preset similarity of 0.97 and determines that the target similarity is equal to the preset similarity. Therefore, the firmware update device 502 determines that the security type of the first firmware is a normal security type.

[0137] The firmware update device 502 obtains at least one version field and second public key information of the first firmware, and according to the second public key information, parsing processing is performed on the at least one version field to obtain that the version identifier of the first firmware is 24.12.01.2048, and the format of the version identifier is a semantic format. The firmware update device 502 performs a matching process on the format of the version identifier and at least one preset format, and the obtained matching result is a pass. Therefore, the firmware update device 502 determines that the version type of the first firmware is a normal version type.

[0138] The firmware update device 502 obtains that the preset time corresponding to the first firmware is time 1, and determines that the release time matches the preset time. Therefore, the firmware update device 502 determines that the timestamp type of the first firmware is the normal timestamp type. The firmware update device 502 performs a rollback verification process on the first firmware and obtains that the rollback type of the first firmware is the abnormal rollback type. Therefore, the firmware update device 502 does not update the first firmware and generates a fourth response message, where the fourth response information is used to indicate that the rollback verification fails and the rollback type of the first firmware is the abnormal rollback type. The firmware update device 502 sends the fourth response information to the terminal device 501.

[0139] In the firmware update process provided by the embodiments of the present application, through the above multiple verification methods, if it is determined that the first firmware is abnormal, an update is performed according to user feedback, or no update is performed. If it is determined that the first firmware is normal, the first firmware is updated. In this way, situations such as updating abnormal firmware, being attacked during the update, and data leakage during the firmware update process can be avoided, improving the security and reliability of the firmware update.

[0140] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method.

[0141] Figure 6 It is a schematic structural diagram of the firmware update device provided by the embodiments of the present application. As Figure 6 shown, the embodiments of the present application also provide a firmware update device 600, including:

[0142] An obtaining module 601, configured to obtain a firmware update request, where the firmware update request includes an identifier of the first firmware and a release time corresponding to the first firmware;

[0143] A processing module 602, configured to perform a security verification process and a version verification process on the first firmware according to the identifier of the first firmware, and obtain a security type and a version type of the first firmware;

[0144] The processing module 602 is further configured to perform a timestamp verification process and a rollback verification process on the first firmware according to the firmware update request, and obtain a timestamp type and a rollback type of the first firmware;

[0145] An update module 603, configured to update the first firmware according to the security type, version type, timestamp type, and rollback type of the first firmware to obtain a target firmware.

[0146] In a possible implementation manner, the update module 603 is configured to:

[0147] If the security type of the first firmware is a normal security type, the version type of the first firmware is a normal version type, the timestamp type of the first firmware is a normal timestamp type, and the rollback type of the first firmware is a normal rollback type, then it is determined that the verification result is verification passed;

[0148] If the security type of the first firmware is an abnormal security type, or the version type of the first firmware is an abnormal version type, or the timestamp type of the first firmware is an abnormal timestamp type, or the rollback type of the first firmware is an abnormal rollback type, then it is determined that the verification result is verification failed;

[0149] When the verification result is verification passed, update the first firmware to obtain the target firmware.

[0150] In a possible implementation manner, the processing module 602 is configured to:

[0151] According to the identifier of the first firmware, obtain the target hash value of the first firmware;

[0152] Perform parsing processing on the target hash value to obtain the initial environment data;

[0153] Obtain the currently updated environment data;

[0154] Obtain the target similarity between the environment data and the initial environment data;

[0155] If the target similarity is greater than or equal to the preset similarity, then determine that the security type of the first firmware is a normal security type;

[0156] If the target similarity is less than the preset similarity, then determine that the security type of the first firmware is an abnormal security type.

[0157] In a possible implementation manner, the processing module 602 is configured to:

[0158] According to the identifier of the first firmware, obtain at least one version field and the second public key information of the first firmware;

[0159] According to the second public key information, perform parsing processing on at least one version field to obtain the version identifier of the first firmware;

[0160] Perform matching processing on the format of the version identifier and at least one preset format to obtain a matching result;

[0161] If the matching result is matching passed, then determine that the version type of the first firmware is a normal version type;

[0162] If the matching result is matching failed, then determine that the version type of the first firmware is an abnormal version type.

[0163] In a possible implementation, the processing module 602 is configured to:

[0164] If there is a match between a preset format and the format of the version identifier in at least one preset format, determine that the match result is a pass;

[0165] If there is no match between a preset format and the format of the version identifier in at least one preset format, determine that the match result is a fail.

[0166] In a possible implementation, the processing module 602 is configured to:

[0167] Obtain a preset moment corresponding to the first firmware;

[0168] If the release moment matches the preset moment, determine that the timestamp type of the first firmware is a normal timestamp type;

[0169] If the release moment does not match the preset moment, determine that the timestamp type of the first firmware is an abnormal timestamp type.

[0170] In a possible implementation, the processing module 602 is further configured to:

[0171] If the rollback type is an intermediate rollback type, determine a prompt message according to the identifier of the first firmware and the data generated by the rollback verification. The prompt message includes the identifier of the first firmware, the version identifier of the first firmware, the abnormal data corresponding to the rollback verification, and the abnormal level corresponding to the abnormal data;

[0172] Store the prompt message, or send the prompt message to a preset device.

[0173] In a possible implementation, the processing module 602 is further configured to:

[0174] Obtain initial environment data;

[0175] Process the initial environment data through a first preset algorithm to obtain at least one initial environment field;

[0176] Obtain the first code of the first firmware;

[0177] Process at least one initial environment field and the first code through a second preset algorithm to obtain a first hash value;

[0178] Perform a signature process on the first hash value according to the first private key information to obtain a target hash value.

[0179] For the description of the features in the embodiments corresponding to the firmware update device, reference may be made to the relevant descriptions in the embodiments corresponding to the firmware update method, which will not be elaborated here one by one.

[0180] Figure 7This is a schematic structural diagram of the firmware update device provided by the present application. As Figure 7 shown, the firmware update device 700 provided in this embodiment includes: at least one processor 701 and a memory 702. Optionally, the firmware update device 70 also includes a communication component 703. Among them, the processor 701, the memory 702, and the communication component 703 are connected by a bus.

[0181] In a specific implementation process, at least one processor 701 executes the computer-executable instructions stored in the memory 702, so that at least one processor 701 executes the above-mentioned firmware update method embodiment.

[0182] For the specific implementation process of the processor 701, reference can be made to the above method embodiment, and its implementation principle and technical effect are similar, so they will not be elaborated here in this embodiment.

[0183] In the above embodiment, it should be understood that the processor may be a central processing unit (Central Processing Unit, abbreviated as: CPU), or other general-purpose processors, digital signal processors (Digital Signal Processor, abbreviated as: DSP), application specific integrated circuits (Application Specific Integrated Circuit, abbreviated as: ASIC), etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in combination with the application can be directly embodied as being executed by a hardware processor, or executed by a combination of hardware and software modules in the processor.

[0184] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (Non-volatile Memory, NVM), such as at least one disk memory.

[0185] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

[0186] Embodiments of the present application further provide a computer-readable storage medium storing a computer program, where the computer program is configured to execute the steps in any of the above-described firmware update method embodiments when running.

[0187] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs such as USB flash drives, read-only memories (ROM for short), random access memories (RAM for short), mobile hard disks, magnetic disks, or optical discs.

[0188] Embodiments of the present application further provide a computer program product, where the computer program product includes a computer program, and the computer program implements the steps in any of the above-described firmware update method embodiments when executed by a processor.

[0189] Embodiments of the present application further provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, and the computer program implements the steps in any of the above-described firmware update method embodiments when executed by a processor.

[0190] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Skilled professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0191] The above has introduced in detail a firmware update method, device, and storage medium provided by the present application. Specific examples are used herein to elaborate on the principle and implementation manner of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A firmware update method, characterized in that, Including: Obtain a firmware update request, where the firmware update request includes an identifier of a first firmware and a release time corresponding to the first firmware; Perform a security verification process and a version verification process on the first firmware according to the identifier of the first firmware to obtain a security type and a version type of the first firmware; Perform a timestamp verification process and a rollback verification process on the first firmware according to the firmware update request to obtain a timestamp type and a rollback type of the first firmware; Update the first firmware according to the security type, version type, timestamp type, and rollback type of the first firmware to obtain a target firmware.

2. The firmware update method according to claim 1, wherein Updating the first firmware according to the security type, version type, timestamp type, and rollback type of the first firmware to obtain a target firmware includes: If the security type of the first firmware is a normal security type, the version type of the first firmware is a normal version type, the timestamp type of the first firmware is a normal timestamp type, and the rollback type of the first firmware is a normal rollback type, then determine that the verification result is verification passed; If the security type of the first firmware is an abnormal security type, or the version type of the first firmware is an abnormal version type, or the timestamp type of the first firmware is an abnormal timestamp type, or the rollback type of the first firmware is an abnormal rollback type, then determine that the verification result is verification failed; When the verification result is verification passed, update the first firmware to obtain the target firmware.

3. The firmware update method according to claim 2, wherein Performing a security verification process on the first firmware according to the identifier of the first firmware to obtain the security type of the first firmware includes: Obtain a target hash value of the first firmware according to the identifier of the first firmware; Perform a parsing process on the target hash value to obtain initial environment data; Obtain the environment data of the current update; Obtain a target similarity between the environment data and the initial environment data; If the target similarity is greater than or equal to a preset similarity, then determine that the security type of the first firmware is the normal security type; If the target similarity is less than the preset similarity, then determine that the security type of the first firmware is the abnormal security type.

4. The firmware update method according to claim 2, wherein Performing a version verification process on the first firmware according to the identifier of the first firmware to obtain the version type of the first firmware includes: Obtain at least one version field and second public key information of the first firmware according to the identifier of the first firmware; Perform a parsing process on the at least one version field according to the second public key information to obtain a version identifier of the first firmware; Perform a matching process on the format of the version identifier with at least one preset format to obtain a matching result; If the matching result is matching passed, then determine that the version type of the first firmware is the normal version type; If the matching result is matching failed, then determine that the version type of the first firmware is the abnormal version type.

5. The firmware update method according to claim 4, characterized in that, Performing a matching process on the format of the version identifier with at least one preset format to obtain a matching result includes: If there is a preset format in the at least one preset format that matches the format of the version identifier, determine that the matching result is a pass; If there is no preset format in the at least one preset format that matches the format of the version identifier, determine that the matching result is a fail.

6. The firmware update method according to claim 2, wherein According to the firmware update request, perform a timestamp verification process on the first firmware to obtain the timestamp type of the first firmware, including: Obtain a preset moment corresponding to the first firmware; If the release moment matches the preset moment, determine that the timestamp type of the first firmware is the normal timestamp type; If the release moment does not match the preset moment, determine that the timestamp type of the first firmware is the abnormal timestamp type.

7. The firmware update method according to any one of claims 1-6, characterized in that, The method further includes: If the rollback type is the intermediate rollback type, determine a prompt message according to the identifier of the first firmware and the data generated by the rollback verification. The prompt message includes the identifier of the first firmware, the version identifier of the first firmware, the abnormal data corresponding to the rollback verification, and the abnormal level corresponding to the abnormal data; Store the prompt message, or send the prompt message to a preset device.

8. The firmware update method according to any one of claims 1-6, characterized in that The method further includes: Obtain initial environment data; Process the initial environment data through a first preset algorithm to obtain at least one initial environment field; Obtain the first code of the first firmware; Process the at least one initial environment field and the first code through a second preset algorithm to obtain a first hash value; Perform a signature process on the first hash value according to the first private key information to obtain a target hash value.

9. A firmware update device, characterized in that, including: A memory for storing a computer program; A processor for implementing the steps of the firmware update method according to any one of claims 1 to 8 when executing the computer program.

10. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein the computer program implements the steps of the firmware update method according to any one of claims 1 to 8 when executed by a processor.

Images