Firmware updating method and device for embedded equipment, equipment and storage medium

Abstract

The embodiment of the invention provides a firmware updating method and device for embedded equipment, equipment and a storage medium. The method comprises the following steps: after acquiring a firmware micro-service pack for performing firmware updating on target firmware in embedded equipment, the embedded security element acquires and stores firmware state data of the target firmware, performs firmware updating on the target firmware based on the firmware micro-service pack in response to the storage of the firmware state data, and if the updating fails, performs firmware updating on the target firmware based on the firmware micro-service pack. And performing data recovery on the target firmware based on the firmware state data. The embodiment of the invention is used for realizing atomization updating of the target firmware in the embedded equipment.

Description

Technical Field

[0001] This application relates to the field of embedded technology, and in particular to a firmware update method, apparatus, device and storage medium for embedded devices. Background Technology

[0002] Embedded Universal Integrated Circuit Cards (eUICCs) are core components in modern IoT devices, smartphones, and wearable devices. They not only store user credentials but also run complex operating systems to manage configuration files and ensure communication security. Unlike traditional pluggable SIM (Subscriber Identity Module) cards, eUICCs are directly soldered onto the device's motherboard, which presents significant challenges for firmware maintenance throughout their lifecycle. Like any complex software, eUICC firmware may have security vulnerabilities or require functional upgrades. Currently, firmware updates mainly rely on over-the-air (OTA) technology, which pushes update packages to devices via cellular networks. However, OTA update links are lengthy, involving multiple links such as base stations, core networks, and operator platforms. Interruptions in any link can lead to incomplete eUICC firmware writing. Since eUICC firmware is the foundation of device communication and security, incomplete updates will permanently disable it, rendering embedded devices unusable. Furthermore, OTA updates depend on cellular network connections. For embedded devices that are not yet activated, devices in areas without network coverage, and / or embedded devices that cannot connect to the network due to firmware vulnerabilities, OTA-based firmware updates will be completely ineffective. In addition, the long-link OTA transmission process increases the risk of man-in-the-middle attacks, data hijacking, or malicious injection, and its inherent complexity constitutes a large potential attack surface. How to achieve effective eUICC firmware updates has become an increasingly important focus for both device providers and users. Summary of the Invention

[0003] In view of this, embodiments of this application provide a firmware update method, apparatus, device, and storage medium for embedded devices, used to achieve atomic updates of target firmware.

[0004] To achieve the above objectives, the technical solutions provided in this application are as follows: In a first aspect, embodiments of this application provide a firmware update method for an embedded device, applied to an embedded secure element, the method comprising: Obtain the firmware micro-patch package for updating the target firmware in the embedded device; Obtain and store the firmware status data of the target firmware; In response to the storage of the firmware status data, the target firmware is updated based on the firmware micro-patch package; If the update fails, data recovery is performed on the target firmware based on the firmware status data.

[0005] Secondly, embodiments of this application provide a firmware update apparatus for an embedded device, operating on an embedded secure element, the apparatus comprising: The first acquisition unit is used to acquire firmware micro-patch packages for updating the target firmware in the embedded device. The second acquisition unit is used to acquire and store the firmware status data of the target firmware; A firmware update unit is used to update the target firmware based on the firmware micro-patch package in response to the storage of the firmware status data. The data recovery unit is used to recover data from the target firmware based on the firmware status data when the update fails.

[0006] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor, wherein the memory is used to store a computer program and the processor is used to cause the electronic device to implement the firmware update method of the embedded device described in any of the above embodiments when executing the computer program.

[0007] Fourthly, embodiments of this application provide a computer-readable storage medium that, when executed by a computing device, causes the computing device to implement the firmware update method for an embedded device as described in any of the above embodiments.

[0008] Fifthly, embodiments of this application provide a computer program product that, when run on a computer, enables the computer to implement the firmware update method for embedded devices described in any of the above embodiments.

[0009] The firmware update method for embedded devices provided in this application embodiment updates the target firmware through an embedded secure element. Specifically, after obtaining the firmware micro-patch package for updating the target firmware in the embedded device, the firmware status data of the target firmware is obtained and stored. Then, the firmware is updated based on the firmware micro-patch package. If the update fails, the target firmware is restored based on the firmware status data. Thus, by storing the firmware status data of the target firmware before the firmware update, the target firmware can be restored based on the firmware status data in the event of an update failure, preventing the embedded device from becoming "bricked" after the target firmware update fails, and realizing atomic updates of the target firmware. Attached Figure Description

[0010] The accompanying drawings, which are incorporated in and form part of the embodiments of this application, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings that need to be called in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic diagram illustrating the implementation environment of a firmware update method for an embedded device provided in one or more embodiments of this application; Figure 2 A flowchart illustrating the steps of a firmware update method for an embedded device provided in this application embodiment; Figure 3 This application provides a flowchart of the firmware update method steps for an embedded device applied to an eUICC update scenario, as shown in the embodiments of this application. Figure 4 This is a schematic diagram of the structure of the firmware update device for an embedded device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] To better understand the above-mentioned objectives, features, and advantages of this application, the solution of this application will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0014] Many specific details are set forth in the following description in order to provide a full understanding of this application, but this application may also be implemented in other ways different from those described herein. Obviously, the embodiments in the specification are only some embodiments of this application, and not all embodiments.

[0015] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner. Furthermore, in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0016] The firmware update method for embedded devices provided in this application is applicable to the implementation environment of firmware update systems for embedded devices. (Refer to...) Figure 1 The implementation environment includes at least: Embedded secure element 101, target firmware 102; The embedded security element 101 and the target firmware 102 are deployed on the same chip (SoC, System on Chip). The chip acts as the main controller and integrates general-purpose computing and storage units such as a processor (CPU, Central Processing Unit), memory (RAM, Random Access Memory), and flash memory (Flash, Flash Memory) to handle the main business logic of the device and communicate with external networks, such as downloading update patches.

[0017] The embedded secure element 101 is an independent, tamper-proof secure microprocessor. It runs a secure operating system and carries critical security applications; it is used to acquire firmware micro-patch packages for updating target firmware in embedded devices, acquire and store firmware status data of the target firmware, update the target firmware based on the firmware micro-patch packages, and if the update fails, restore the target firmware based on the firmware status data. Furthermore, this implementation environment may also include an NFC (Near-Field Communication) controller 103, a communication interface 104, and an authorized external device 105. The authorized external device 105 may be a dedicated terminal or a maintenance terminal. It sends a firmware micro-patch package to the NFC controller 103 via the NFC channel. The NFC controller 103 receives the firmware micro-patch package and sends it to the chip via the on-chip bus. The chip's processor sends the firmware micro-patch package to the embedded secure element 101 via the communication interface 104 to update the target firmware 102. The communication interface 104 may be an SWP (Single Wire Protocol) / ISO7816 (Identification Cards - Integrated Circuit Cards with Contacts) secure interface.

[0018] Reference Figure 2 As shown, the firmware update method for embedded devices provided in this application embodiment can be applied to embedded secure elements, and specifically includes the following steps S201 to S204.

[0019] Step S201: Obtain the firmware micro-patch package for updating the target firmware in the embedded device.

[0020] In this embodiment, firmware updates for the target firmware in the embedded device are achieved through an embedded secure element. The embedded device in this embodiment includes a device that integrates the target firmware and the embedded secure element. The target firmware can be an eUICC, and the embedded secure element can be an eSE (Embedded Secure Element).

[0021] In practice, during the firmware update process of the target firmware in the embedded device, the embedded secure element first obtains the firmware micro-patch package for updating the target firmware in the embedded device.

[0022] In the specific execution process, the embedded device may also include an NFC controller. During the process of obtaining the firmware micro-patch package for updating the target firmware in the embedded device, the firmware micro-patch package for updating the target firmware in the embedded device sent by the NFC controller through the on-chip bus can be obtained. In this way, the firmware micro-patch package can be obtained without the embedded device being connected to the network, thus improving the convenience of obtaining the firmware micro-patch package.

[0023] Specifically, the authorized external device, which can be a dedicated terminal or maintenance terminal, sends a firmware micro-patch package to the NFC controller of the embedded device via the NFC channel. The NFC controller receives the firmware micro-patch package and sends it to the embedded secure element via the on-chip bus. The embedded secure element then obtains the firmware micro-patch package sent by the NFC via the on-chip bus.

[0024] To enhance the security of firmware micro-patches during transmission, the firmware micro-patches in this embodiment can be encrypted and signed.

[0025] In practice, after the embedded secure element obtains the firmware micro-patch package for the target firmware, it performs patch package verification on the firmware micro-patch package. In this way, through patch package verification, firmware updates are avoided based on firmware micro-patch packages that are dangerous from the source and / or have been tampered with during transmission.

[0026] The patch package verification in this embodiment may include signature verification and / or packet data integrity verification. In this way, signature verification avoids firmware updates based on firmware micro-patterns from dangerous sources, ensuring the legitimacy of the firmware micro-pattern's source; and packet data integrity verification avoids firmware updates based on firmware micro-patterns that have been tampered with during transmission.

[0027] Specifically, in the process of verifying the signature of the firmware micro-patch package, the encrypted signature data of the firmware micro-patch package can be verified based on a pre-stored trusted public key. In one optional implementation of this embodiment, the firmware micro-patch package is first parsed to obtain the encrypted signature data, then the trusted public key is read, and the encrypted signature data is decrypted based on the trusted public key to obtain a first hash value. The first hash value is then checked to see if it meets the preset access conditions. If it does, the signature verification of the firmware micro-patch package is determined to be successful, or the verification result of the patch package verification of the firmware micro-patch package is determined to be successful. If not, the verification result of the patch package verification of the firmware micro-patch package is determined to be unsuccessful.

[0028] The preset admission criteria may include a preset admission length and / or no syntax errors during decryption.

[0029] For example, the preset admission conditions include a preset admission length of 256 and no syntax errors in decryption. After obtaining the first hash value, if the length of the first hash value is 256 and there are no syntax errors in the decryption process of the ciphertext signature data based on the trusted public key, then the signature verification of the firmware micro-patch package is determined to be successful or the verification result of the patch package verification of the firmware micro-patch package is successful.

[0030] In practical applications, encrypted signature data is usually stored in the packet header. Based on this, in order to improve parsing efficiency, the encrypted signature data can be obtained by parsing the packet header of the firmware micro-patch package during the process of parsing the firmware micro-patch package to obtain encrypted signature data.

[0031] Specifically, during the process of verifying the integrity of firmware micro-pattern packages, hash verification can be performed on the firmware micro-pattern packages. In one optional implementation provided in this embodiment, during the process of verifying the integrity of package data, the encrypted patch data in the firmware micro-pattern package is first obtained, the encrypted patch data is hashed to obtain a second hash value, and it is checked whether the first hash value and the second hash value are consistent. If they are consistent, it is determined that the integrity of the firmware micro-pattern package package has passed or the verification result of the firmware micro-pattern package patch verification is that the verification has passed. If not, it is determined that the verification result of the firmware micro-pattern package patch verification is that the verification has failed.

[0032] The encrypted patch data in this embodiment includes encrypted binary differential data in the firmware micro-patch package.

[0033] The above describes in detail the processes of signature verification and packet data integrity verification. In this embodiment, during the patch package verification process of the firmware micro-patch package, the firmware micro-patch package can be parsed to obtain encrypted signature data, the trusted public key can be read, and the encrypted signature data can be decrypted based on the trusted public key to obtain a first hash value. The first hash value is checked to see if it meets the preset access conditions. If not, the verification result of the patch package verification is determined to be verification failure. If yes, the first hash value meets the preset access conditions, the encrypted patch data in the firmware micro-patch package is obtained, the encrypted patch data is hashed to obtain a second hash value, and the first hash value and the second hash value are checked to see if they are consistent. If yes, the verification result of the patch package verification is determined to be verification success. If not, the verification result of the patch package verification is determined to be verification failure.

[0034] In the specific execution process, if the verification result is successful, the firmware will be updated based on the firmware micro-patch package, that is, subsequent processing will be performed. If the verification result is unsuccessful, no processing will be performed.

[0035] Step S202: Obtain and store the firmware status data of the target firmware.

[0036] In practice, to avoid update failures or anomalies during firmware updates based on firmware micro-patches that could render the target firmware or even the embedded device unusable, the firmware state data of the target firmware is acquired and stored after obtaining the firmware micro-patches. This means acquiring and storing a firmware snapshot of the target firmware. This allows for data recovery of the target firmware based on the firmware state data in the event of an update failure or an anomaly, ensuring that the target firmware can continue to be used even if it reverts to a previous state after an update failure or an anomaly.

[0037] The firmware status data in this embodiment includes target firmware-related data stored in the target firmware's internal memory. Optionally, the firmware status data includes firmware version number, firmware configuration information, and / or firmware description summary. In one optional implementation of this embodiment, after the embedded secure element verifies the patch package of the firmware micro-patch package, it reads the firmware status data of the target firmware, then encrypts the firmware status data to obtain encrypted firmware data, and stores the encrypted firmware data in a non-volatile secure storage area. Thus, by encrypting and storing the firmware status data in the non-volatile secure storage area of ​​the embedded secure element, effective storage of the firmware status data is achieved, preventing its loss or leakage.

[0038] Specifically, if the encrypted firmware data is successfully stored in the non-volatile secure storage area, subsequent processing can be performed; if storage fails, no processing is required.

[0039] In practice, before reading the firmware status data of the target firmware, the embedded secure element can also send a predefined update reminder command to the target firmware to remind it that a firmware update is about to be performed.

[0040] Step S203: In response to the storage of firmware status data, update the target firmware based on the firmware micro-patch package.

[0041] In practice, after acquiring and storing the firmware status data, the target firmware is updated based on the firmware micro-patch package in response to the storage of the firmware status data.

[0042] The following section provides a detailed explanation of the firmware update process for the target firmware based on firmware micro-patches.

[0043] Step S203-1: Write the firmware micro-patch package to the target firmware.

[0044] In the process of updating the target firmware based on the firmware micro-patch package, the firmware micro-patch package is first written to the target firmware.

[0045] In practice, to improve the security, stability, and controllability of the update process and avoid interference and risks, the target firmware can be switched to firmware update mode before writing the firmware micro-patch package to the target firmware. The firmware update mode in this embodiment is a minimized, isolated security instruction loader mode. In firmware update mode, the target firmware does not load the main operating system and only responds to low-level read / write commands sent from the embedded security element via the on-chip bus, thereby avoiding interference and risks caused by the execution of the main operating system. In an optional implementation of this embodiment, during the process of writing the firmware micro-patch package to the target firmware, the target firmware is first switched to firmware update mode based on the physical connection with the target firmware, and then the firmware micro-patch package is written to the target firmware in firmware update mode.

[0046] Specifically, during the process of switching the target firmware to firmware update mode based on the physical connection with the target firmware, the embedded secure element can force the target firmware to restart through a dedicated hardware control circuit. During the target firmware restart process, the embedded secure element sends an indication signal to the target firmware to instruct the target firmware to enter firmware update mode, thereby switching the target firmware to firmware update mode.

[0047] Since the firmware micro-patch package is in encrypted form, in one optional implementation of this embodiment, during the process of writing the firmware micro-patch package to the target firmware or to the target firmware in firmware update mode, the firmware micro-patch package is first decrypted to obtain the differential data to be written and the address to be written. Then, the differential data to be written is divided into at least one data block, and at least one data block is written to the target firmware based on the address to be written.

[0048] The differential data to be written in this embodiment includes binary differential data.

[0049] During the actual execution process, the embedded security element decrypts the firmware micro-patch package, obtains the differential data to be written and the address to be written, and then writes the data blocks to the location corresponding to the address to be written in the memory of the target firmware via the on-chip bus, in units of data blocks.

[0050] To promptly detect write failures, one optional implementation of this embodiment involves writing at least one data block to the target firmware based on the address to be written. First, a first data block is written to the target firmware based on the address to be written. After the first data block is detected as successfully written, the written data corresponding to the address to be written is read, and the written data is compared with the written data block. If they match, a second data block is written to the target firmware based on the address to be written; otherwise, the update of the target firmware is determined to have failed. In this way, each time the embedded security element successfully writes a data block, it immediately reads the data back from the address to be written and compares it bit-by-bit with the written data block, improving the effectiveness of the data written to the target firmware.

[0051] In this embodiment, data blocks can be divided according to flash pages, and the data blocks can be sequentially written. The first data block is any unwritten data block among at least one data block, and the second data block is the next data block or the next unwritten data block among at least one data block.

[0052] In practice, if the target firmware update fails, the encrypted firmware data can be read from the storage area, decrypted to obtain firmware status data, and then the target firmware can be restored based on the firmware status data.

[0053] Step S203-2: If writing is detected to be complete, obtain the target firmware data of the target firmware and generate an update check code based on the target firmware data.

[0054] In practice, after writing the firmware micro-patch package to the target firmware, the target firmware data is obtained, and an update check code is generated based on the target firmware data.

[0055] In this embodiment, to further improve the accuracy of the target firmware data written to the target firmware, a comprehensive verification of the target firmware data is performed after the writing process is completed. During this comprehensive verification, the target firmware data is first obtained, and then an update verification code is generated based on the target firmware data.

[0056] In the process of acquiring the target firmware data, to avoid data omission, the embedded secure element can read the data from the start address to the end address of the target firmware in physical storage order to obtain the target firmware data. In this embodiment, the target firmware data includes binary data.

[0057] To improve the effectiveness of the generated update verification code, in one optional implementation of this embodiment, during the process of generating the update verification code based on the target firmware data, the target firmware data can be input into the verification code generation algorithm to generate the verification code and obtain the update verification code.

[0058] For example, the verification code generation algorithm is a CRC (Cyclic Redundancy Check) operation circuit. The target firmware data is input into the CRC operation circuit for cyclic redundancy calculation, and the fixed-length updated verification code output by the CRC operation circuit is obtained. In the process of inputting the target firmware data into the CRC operation circuit, the target firmware data can be input into the CRC operation circuit in bytes or words.

[0059] For example, the verification code generation algorithm is a hash algorithm. The target firmware data is input into the hash algorithm to perform hash calculation and obtain a fixed-length update verification code.

[0060] The fixed length can be 256.

[0061] In addition, the update verification code can also be a hash message authentication code of the target firmware data; in another optional implementation provided in this embodiment, in the process of generating the update verification code based on the target firmware data, a preset key is first read, mixed data is generated based on the preset key and the target firmware data, hash calculation is performed on the mixed data to obtain a third hash value, and the update verification code is generated based on the preset key and the third key.

[0062] In the specific execution process, during the generation of the update verification code based on the preset key and the third hash value, secondary mixed data can be generated based on the preset key and the third hash value. The secondary mixed data is then hashed to obtain the fourth hash value as the update verification code.

[0063] For example, the preset key and the target firmware data are XORed using the HMAC (Hash-based Message Authentication Code) standard algorithm to obtain mixed data. Then, the mixed data is hashed using SHA-256 (Secure Hash Algorithm 256-bit) to obtain a third hash value. The preset key and the third hash value are then XORed using the HMAC standard algorithm to obtain a second mixed data. Finally, the second mixed data is hashed using SHA-256 to obtain the update verification code.

[0064] It should be noted that the update verification code in this embodiment can be one or more of the above-mentioned methods, and this embodiment does not limit it here.

[0065] Step S203-3: Compare the update check code with the preset check code in the firmware micro-patch package, and determine the update failure if the comparison is inconsistent.

[0066] After calculating and obtaining the update check code, if the update check code matches the preset check code in the firmware micro-patch package, the update is considered successful; otherwise, the update is considered to have failed.

[0067] During the execution process, if the update is successful, the embedded secure element can write an update success result to the target firmware to indicate that the update was successful. To make the target firmware usable after a successful update, the embedded secure element can restart the target firmware via hardware control circuitry, causing it to exit firmware update mode and enter base mode. In base mode, the target firmware loads the main operating system.

[0068] In addition, if the update is successful, the embedded security component can also write the firmware information of the updated target firmware, such as the firmware version number and / or firmware identifier, into the non-volatile secure storage area of ​​the embedded security component.

[0069] Step S204: If the update fails, perform data recovery on the target firmware based on the firmware status data.

[0070] In practice, if the update fails, data recovery is performed on the target firmware based on the firmware status data to achieve atomic data recovery of the target firmware.

[0071] Corresponding to the encrypted firmware data stored above, in an optional implementation of this embodiment, during the process of data recovery of the target firmware based on firmware status data, the encrypted firmware data is first read from the non-volatile secure storage area, then the encrypted firmware data is decrypted to obtain firmware status data, and the target firmware is recovered based on the firmware status data.

[0072] After data recovery, temporary data generated during the update process can be deleted to save storage space.

[0073] It should be noted that, based on the stored firmware status data, this embodiment can determine that the update has failed if the patch package verification fails, there is a write verification error, communication is interrupted, or the comparison is inconsistent. In other words, data recovery of the target firmware can be performed based on the firmware status data.

[0074] In summary, the firmware update method for embedded devices provided in this embodiment ensures that the firmware update process is either completely successful or completely restored to the initial state before the update after any failure in any environment. This avoids partial updates or damage that renders the device unusable, achieving atomicity in firmware updates for embedded devices, improving the convenience and effectiveness of firmware updates, and also enhancing the security of embedded devices.

[0075] The following uses the application of the firmware update method for an embedded device provided in this embodiment in an eUICC update scenario as an example to further illustrate the firmware update method for an embedded device provided in this embodiment. Figure 3 As shown, the firmware update method for embedded devices applied to eUICC update scenarios includes the following steps.

[0076] Step S301: Receive the firmware micro-patch package for firmware update of eUICC in the embedded device via NFC.

[0077] Step S302: Verify the firmware micro-pattern package.

[0078] If the verification fails, no action needs to be taken.

[0079] Step S303: If the verification is successful, obtain and store the firmware status data of eUICC.

[0080] Step S304: Control eUICC to switch to firmware update mode.

[0081] Step S305: Obtain at least one data block corresponding to the firmware micro-patch package, write the data blocks one by one to eUICC and perform write verification.

[0082] If the verification fails, proceed to step S310.

[0083] Step S306: If the verification passes, obtain the target firmware data of eUICC after all data blocks have been written.

[0084] Step S307: Generate an update verification code based on the target firmware data.

[0085] Step S308: Compare whether the update check code and the preset check code in the firmware micro-patch package are consistent; If so, proceed to step S309; If not, proceed to step S310.

[0086] Step S309: Write the firmware information of the eUICC into the non-volatile secure storage area.

[0087] Step S310: Perform data recovery on eUICC based on firmware status data.

[0088] It should be noted that any one or more steps from S301 to S310 can be combined with any one or more steps from S201 to S204 to form a new implementation method according to the needs of implementation and deployment. In addition, any one or more technical features can be selected in steps S301 to S310 and combined with any one or more technical features provided in steps S201 to S204 to form a new implementation method according to the actual deployment needs. Alternatively, any one or more technical features in steps S301 to S310 can be replaced with any one or more technical features provided in steps S201 to S204 to form a new implementation method according to the actual deployment needs. These will not be elaborated on here.

[0089] Based on the same inventive concept, as an implementation of the above method, this application also provides a firmware update device for an embedded device. This embodiment corresponds to the aforementioned method embodiment. For ease of reading, this application will not repeat the details of the aforementioned method embodiment one by one, but it should be clear that the firmware update device for an embedded device in this application can correspondingly implement all the contents of the aforementioned method embodiment.

[0090] This application provides a firmware update device for an embedded device. Figure 4 This is a schematic diagram of the firmware update device for the embedded device, as shown below. Figure 4 As shown, the firmware update device for the embedded device includes: The first acquisition unit 401 is used to acquire a firmware micro-patch package for updating the target firmware in the embedded device. The second acquisition unit 402 is used to acquire and store the firmware status data of the target firmware; Firmware update unit 403 is used to update the target firmware based on the firmware micro-patch package in response to the storage of the firmware status data. The data recovery unit 404 is used to recover data from the target firmware based on the firmware status data when the update fails.

[0091] Optionally, the second acquisition unit 402 is configured to: read the firmware status data of the target firmware; the firmware status data includes firmware version number, firmware configuration information and / or firmware description summary; encrypt the firmware status data to obtain encrypted firmware data, and store the encrypted firmware data in a non-volatile secure storage area.

[0092] Optionally, the data recovery unit 404 is configured to: read the encrypted firmware data from the non-volatile secure storage area; decrypt the encrypted firmware data to obtain the firmware status data; and perform data recovery on the target firmware based on the firmware status data.

[0093] Optionally, the first acquisition unit 401 is further configured to: perform patch package verification on the firmware micro-patch package; if the verification is successful, perform the operation of acquiring and storing the firmware status data of the target firmware.

[0094] Optionally, the first acquisition unit 401 is specifically used to: parse the firmware micro-pattern package to obtain encrypted signature data; read the trusted public key, and decrypt the encrypted signature data based on the trusted public key to obtain a first hash value; verify whether the first hash value meets the preset access conditions; if so, determine that the verification result of the patch package verification is verified as successful.

[0095] Optionally, the first acquisition unit 401 is further configured to: if the first hash value satisfies the preset access condition, acquire the encrypted patch data in the firmware micro-pattern; perform a hash operation on the encrypted patch data to obtain a second hash value, and detect whether the first hash value and the second hash value are consistent; if so, determine that the verification result of the patch package verification is successful.

[0096] Optionally, the firmware update unit 403 is configured to: write the firmware micro-patch package to the target firmware; if the writing is detected to be complete, obtain the target firmware data of the target firmware and generate an update check code based on the target firmware data; compare the update check code with the preset check code in the firmware micro-patch package, and determine that the update has failed if the comparison is inconsistent.

[0097] Optionally, when writing the firmware micro-patch package to the target firmware, the firmware update unit 403 is specifically used to: switch the target firmware to firmware update mode based on the physical connection with the target firmware, and write the firmware micro-patch package to the target firmware in firmware update mode; wherein the target firmware in firmware update mode does not load the main operating system.

[0098] Optionally, when writing the firmware micro-patch package to the target firmware, the firmware update unit 403 is specifically used to: decrypt the firmware micro-patch package to obtain the differential data to be written and the address to be written; divide the differential data to be written into at least one data block, and write the at least one data block to the target firmware based on the address to be written.

[0099] Optionally, when the firmware update unit 403 writes the at least one data block to the target firmware based on the address to be written, it specifically performs the following steps: writes a first data block to the target firmware based on the address to be written; the first data block is any unwritten data block among the at least one data blocks; after detecting that the first data block has been written, reads the written data corresponding to the address to be written; compares whether the written data is consistent with the written data block; if yes, writes a second data block to the target firmware based on the address to be written; the second data block is the next unwritten data block of the first data block among the at least one data blocks; if no, determines that the update of the target firmware has failed.

[0100] Optionally, when generating an update verification code based on the target firmware data, the firmware update unit 403 is specifically configured to: input the target firmware data into a verification code generation algorithm to generate a verification code and obtain the update verification code; and / or, read a preset key and generate mixed data based on the preset key and the target firmware data; perform hash calculation on the mixed data to obtain a third hash value; and generate the update verification code based on the preset key and the third hash value.

[0101] The firmware update apparatus for embedded devices provided in this application can execute the firmware update method for embedded devices provided in any of the above embodiments. Its implementation principle and technical effect are similar, and will not be described again here.

[0102] Based on the same inventive concept, embodiments of this application also provide an electronic device. Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application, such as... Figure 5As shown, the electronic device provided in this application embodiment includes: a memory 501 and a processor 502. The memory 501 is used to store a computer program, and the processor 502 is used to execute the firmware update method of the embedded device provided in the above embodiment when executing the computer program.

[0103] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the computing device to implement the firmware update method for the embedded device provided in the above embodiments.

[0104] Based on the same inventive concept, this application also provides a computer program product that, when run on a computer, enables the computing device to implement the firmware update method for embedded devices provided in the above embodiments.

[0105] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code.

[0106] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0107] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0108] Computer-readable media include both permanent and non-permanent, removable and non-removable storage media. Storage media can store information using any method or technology; the information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0109] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some or all of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A firmware update method for an embedded device, characterized in that, Applied to embedded security elements, the method includes: Obtain the firmware micro-patch package for updating the target firmware in the embedded device; Obtain and store the firmware status data of the target firmware; In response to the storage of the firmware status data, the target firmware is updated based on the firmware micro-patch package; If the update fails, data recovery is performed on the target firmware based on the firmware status data.

2. The method according to claim 1, characterized in that, The step of acquiring and storing the firmware status data of the target firmware includes: Read the firmware status data of the target firmware; the firmware status data includes firmware version number, firmware configuration information and / or firmware description summary; The firmware status data is encrypted to obtain encrypted firmware data, and the encrypted firmware data is stored in a non-volatile secure storage area.

3. The method according to claim 2, characterized in that, The data recovery of the target firmware based on the firmware status data includes: Read the encrypted firmware data from the non-volatile secure storage area; The encrypted firmware data is decrypted to obtain the firmware status data, and the target firmware is recovered based on the firmware status data.

4. The method according to claim 1, characterized in that, After the operation of obtaining the firmware micro-patch package for firmware update of the target firmware in the embedded device is executed, the method further includes: The firmware micro-pattern package is verified. If the verification is successful, perform the operation of obtaining and storing the firmware status data of the target firmware.

5. The method according to claim 4, characterized in that, The step of verifying the firmware micro-pattern package includes: Parse the firmware micro-patch package to obtain encrypted signature data; Read the trusted public key, and decrypt the ciphertext signature data based on the trusted public key to obtain the first hash value; Verify whether the first hash value meets the preset admission conditions; If so, the verification result of the patch package verification is determined to be successful.

6. The method according to claim 5, characterized in that, The step of verifying the firmware micro-pattern package also includes: If the first hash value satisfies the preset admission condition, the encrypted patch data in the firmware micro-patch package is obtained; Perform a hash operation on the encrypted patch data to obtain a second hash value, and check whether the first hash value and the second hash value are consistent; If so, the verification result of the patch package verification is determined to be successful.

7. The method according to claim 1, characterized in that, The firmware update based on the firmware micro-patch package for the target firmware includes: Write the firmware micro-patch package to the target firmware; If the write operation is detected as complete, the target firmware data of the target firmware is obtained, and an update check code is generated based on the target firmware data. The update check code is compared with the preset check code in the firmware micro-patch package, and the update fails if the comparison is inconsistent.

8. The method according to claim 7, characterized in that, The step of writing the firmware micro-patch package to the target firmware includes: Based on the physical connection with the target firmware, the target firmware is switched to firmware update mode, and the firmware micro-patch package is written to the target firmware in firmware update mode; In the firmware update mode, the target firmware is not loaded with the main operating system.

9. The method according to claim 7, characterized in that, The step of writing the firmware micro-patch package to the target firmware includes: The firmware micro-patch package is decrypted to obtain the differential data to be written and the address to be written. The differential data to be written is divided into at least one data block, and the at least one data block is written to the target firmware based on the address to be written.

10. The method according to claim 9, characterized in that, The step of writing at least one data block to the target firmware based on the address to be written includes: A first data block is written to the target firmware based on the address to be written; the first data block is any unwritten data block among the at least one data block. After the first data block has been written, read the data already written to the address to be written. Compare whether the written data is consistent with the written data block; If so, a second data block is written to the target firmware based on the address to be written; the second data block is the next unwritten data block of the first data block among the at least one data block; If not, the update of the target firmware is determined to have failed.

11. The method according to claim 7, characterized in that, The step of generating an update verification code based on the target firmware data includes: The target firmware data is input into a verification code generation algorithm to generate a verification code, thereby obtaining the update verification code. And / or, Read the preset key and generate mixed data based on the preset key and the target firmware data; Perform a hash calculation on the mixed data to obtain a third hash value; The updated verification code is generated based on the preset key and the third hash value.

12. A firmware update device for an embedded device, characterized in that, Operating on an embedded secure element, the device includes: The first acquisition unit is used to acquire firmware micro-patch packages for updating the target firmware in the embedded device. The second acquisition unit is used to acquire and store the firmware status data of the target firmware; A firmware update unit is used to update the target firmware based on the firmware micro-patch package in response to the storage of the firmware status data. A data recovery unit is used to recover data from the target firmware based on the firmware status data when an update fails.

13. An electronic device, characterized in that, include: A memory and a processor, the memory being used to store a computer program; the processor being used to cause the electronic device to implement the firmware update method for the embedded device according to any one of claims 1-11 when executing the computer program.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a computing device, causes the computing device to implement the firmware update method for an embedded device according to any one of claims 1-11.

Images