Firmware updating method and device

Abstract

The embodiment of the invention provides a firmware updating method and device. The method is applied to a chip management system, and a software development kit corresponding to the chip management system runs on equipment in a chip application environment. A downloading data script issued by a developer of the chip management system is stored in the software development kit, and the downloading data script comprises downloading command data signed by the developer through a private key; a public key corresponding to the private key is held by the chip management system; the method comprises the following steps: initiating an authorization request for firmware updating to a software development kit; receiving downloading command data signed by the private key and issued by the software development kit after the downloading command data signed by the developer through the private key and obtained by analyzing the downloading data script; performing signature verification on the downloading command data signed by the private key by using the public key; and if the signature verification is passed, executing the downloading command data to download firmware updating data for updating the chip operating system, and updating the chip operating system by using the firmware updating data.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of chip technology, and more particularly to a firmware update method and device. Background Art

[0002] In the field of chip technology, a chip operating system (COS) is an operating system designed for a specific chip or embedded system, which aims to manage hardware resources, provide device control, support application execution and other functions.

[0003] With the development and iteration of chip operating systems, it is often necessary to update the chip operating system through firmware updates. Among them, firmware updates usually need to be completed with the cooperation of the chip management system (CMS) and the corresponding software development kit (SDK). Among them, SDK is an auxiliary software package for chip products. The SDK runs on the main terminal device of the chip application environment (that is, the terminal device with the chip installed, such as a smart card with an NFC chip installed, a smartphone with a mobile phone chip installed, etc.); in addition to providing firmware update data, SDK can also be used by chip users to quickly implement applications in the system where the chip is located.

[0004] Back to the firmware update, the above-mentioned process of cooperation between CMS and SDK can refer to the CMS requesting the SDK to download firmware update data by running the CMS download function, and the SDK sending the firmware update data to the CMS in response to the request. After receiving the firmware update data, the CMS uses the firmware update data to update the COS.

[0005] In related technologies, the CMS and SDK cooperate with each other to perform identity verification during the firmware update process to ensure that the firmware update data issued is the official version, rather than a third-party program such as a malicious program.

[0006] During the implementation of this application, the inventors discovered that traditional identity verification typically uses a group algorithm key-based authentication mechanism. This mechanism requires the SDK and CMS to share a group algorithm key. Both parties use the shared key to encrypt and decrypt a segment of random data, thereby verifying the legitimacy of the other party's identity. However, this introduces a group key management system, which is costly, complex, and relatively insecure, making it less applicable in some chip application environments. Summary of the Invention

[0007] The embodiments of the present application provide a firmware update method and device.

[0008] According to a first aspect of an embodiment of the present application, a firmware update method is provided, which is applied to a chip management system, wherein a software development kit corresponding to the chip management system runs on a device in a chip application environment; the software development kit stores a download data script published by a developer of the chip management system, the download data script including download command data signed by the developer using a private key; a public key corresponding to the private key is held by the chip management system; the method comprises:

[0009] Initiating an authorization request for firmware update to the software development kit;

[0010] Receiving the download command data signed by the private key issued by the developer after the software development kit parses the download data script;

[0011] Use the public key to verify the download command data signed by the private key;

[0012] If the signature verification passes, the download command data is executed to download firmware update data for updating the chip operating system, and the chip operating system is updated using the firmware update data.

[0013] Optionally, the method further includes:

[0014] receiving a digital summary issued by the software development kit and calculated based on the download command data;

[0015] If the signature verification passes, executing the download command data to download firmware update data for updating the chip operating system includes:

[0016] If the signature verification passes, the digital summary is further used to perform an integrity check on the download command data;

[0017] If the integrity check passes, the download command data is executed to download firmware update data for updating the chip operating system.

[0018] Optionally, executing the download command data to download firmware update data for updating a chip operating system includes:

[0019] Executing the download command data to download firmware update data for updating the chip operating system;

[0020] When the firmware update data is ciphertext data, the ciphertext data is decrypted using a key stored in a specific area of the chip to obtain the plaintext firmware update data.

[0021] Optionally, the download command data becomes invalid after execution is completed.

[0022] Optionally, the private key and the corresponding public key are generated using a 256-bit elliptic cryptographic algorithm.

[0023] Optionally, the script format of the download data script includes APUD format.

[0024] According to a second aspect of an embodiment of the present application, a firmware update method is provided, which is applied to a software development kit corresponding to a chip management system, wherein the software development kit runs on a device in a chip application environment; the software development kit stores a download data script published by a developer of the chip management system, wherein the download data script includes download command data signed by the developer using a private key; a public key corresponding to the private key is held by the chip management system; the method comprises:

[0025] Receiving an authorization request for firmware update initiated by the chip management system;

[0026] Parsing the download data script, and sending the download command data signed by the developer using the private key in the parsed download data script to the chip management system;

[0027] In response to the chip management system executing the download command data after successfully verifying the download command data signed by the private key based on the public key, the firmware update data for updating the chip operating system is sent to the chip management system, so that the chip management system uses the firmware update data to update the chip operating system.

[0028] Optionally, a configuration file of the software development kit maintains a policy configuration item of the firmware update policy;

[0029] The step of sending the firmware update data for updating the chip operating system to the chip management system includes:

[0030] Loading version information of firmware update data used to update the chip operating system;

[0031] Reading the policy configuration items in the configuration file, and determining an update strategy for the policy configuration items;

[0032] Update the status of the firmware flag bit according to the update strategy and the version information;

[0033] When the state of the firmware flag is the downloading state, the firmware update data for updating the chip operating system is sent to the chip management system.

[0034] Optionally, updating the status of the firmware flag bit according to the update policy and the version information includes at least one of the following:

[0035] If the update policy is a higher version update and the version information is a higher version, the firmware flag is updated to a download state;

[0036] If the update policy is version different update, and the version information is different, then the firmware flag is updated to the download state;

[0037] If the update policy is to always update, the firmware flag is updated to the download state.

[0038] Optionally, the software development kit maintains firmware recovery data corresponding to the current version of the chip operating system, and the method further includes:

[0039] In response to a failure of the chip management system to update the chip operating system, counting the number of downloads of the same firmware update data by the chip management system;

[0040] If the number of downloads reaches a threshold, the firmware recovery data is sent to the chip management system, so that the chip management system uses the firmware recovery data to restore the chip operating system to the version before the update.

[0041] Optionally, the method further includes:

[0042] If the number of downloads does not reach the threshold, the firmware update data for updating the chip operating system is sent to the chip management system again.

[0043] Optionally, the method further includes:

[0044] In response to the chip management system successfully updating the chip operating system, the maintained firmware recovery data is deleted, and the firmware update data is backed up as new firmware recovery data.

[0045] According to a third aspect of an embodiment of the present application, a firmware update device is provided, which is applied to a chip management system. A software development kit corresponding to the chip management system runs on a device in a chip application environment. The software development kit stores a download data script published by a developer of the chip management system, wherein the download data script includes download command data signed by the developer using a private key. A public key corresponding to the private key is held by the chip management system. The device includes:

[0046] a requesting unit, initiating an authorization request for firmware update to the software development kit;

[0047] a receiving unit, receiving the download command data signed by the private key issued by the developer after the software development kit parses the download data script to obtain the download command data;

[0048] A signature verification unit, using the public key to verify the download command data signed by the private key;

[0049] The updating unit executes the download command data to download firmware update data for updating the chip operating system if the signature verification passes, and uses the firmware update data to update the chip operating system.

[0050] According to a fourth aspect of an embodiment of the present application, a firmware update device is provided, which is applied to a software development kit corresponding to a chip management system, wherein the software development kit runs on a device in a chip application environment; the software development kit stores a download data script published by a developer of the chip management system, wherein the download data script includes download command data signed by the developer using a private key; a public key corresponding to the private key is held by the chip management system; the device includes:

[0051] A receiving unit, receiving an authorization request for firmware update initiated by the chip management system;

[0052] A signature unit, which parses the download data script and sends the download command data signed by the developer using a private key in the parsed download data script to the chip management system;

[0053] An update unit, in response to the chip management system executing the download command data after successfully verifying the download command data signed by the private key based on the public key, sends the firmware update data for updating the chip operating system to the chip management system, so that the chip management system uses the firmware update data to update the chip operating system.

[0054] According to a fifth aspect of the embodiments of the present application, there is provided an electronic device, including:

[0055] processor;

[0056] a memory for storing processor-executable instructions;

[0057] The processor is configured to perform any of the above methods.

[0058] An embodiment of the present application provides a firmware update solution that uses public-private key signature verification to implement secure authentication of download command data between the chip management system and the software development kit. Because the chip management system only needs to store the public key locally, and the download data script provided by the developer to the software development kit does not need to be kept confidential, that is, the chip management system and the software development kit do not share the same key, there is no need to introduce a high-cost, high-complexity group key management system. Thus, while ensuring security, the use of public-private key signature verification can reduce the cost and complexity of firmware updates. Furthermore, because the chip management system does not need to deploy a key management system, it is more applicable to various low-performance chips. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 This is a schematic diagram of the chip management system and software development kit provided in an application scenario of this application;

[0060] Figure 2 This is a flowchart of a firmware update method using a chip management system as an execution subject provided by an embodiment of the present application;

[0061] Figure 3 This is a flowchart of a firmware update method using a software development kit as an execution body provided by an embodiment of the present application;

[0062] Figure 4 This is a schematic diagram of the structure of a firmware update device provided by an embodiment of the present application;

[0063] Figure 5 This is a schematic diagram of the structure of a firmware update device provided by an embodiment of the present application;

[0064] Figure 6 It is a structural diagram of a firmware updating device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0065] Exemplary embodiments are described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numbers in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all possible implementations consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of the present invention, as detailed in the appended claims.

[0066] The terms used in the embodiments of the present application are for the purpose of describing specific embodiments only and are not intended to limit the embodiments of the present application. The singular forms "a," "the," and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0067] It should be understood that although the terms first, second, third, etc. may be used to describe various information in the embodiments of the present application, these information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of the embodiments of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0068] The firmware update solution provided by the present invention can be applied to a chip management system (CMS) and / or a software development kit (SDK).

[0069] Please refer to the following Figure 1 Schematic diagram of a chip management system and software development kit in an exemplary application scenario. Figure 1 As shown, the chip management system (CMS) and the chip operating system (COS) are both located in the chip product, and the software development kit is located in the host device.

[0070] Chip products are widely used in various electronic devices, and different types of chips have different functions. For example, NFC (Near Field Communication) chips are commonly used in scenarios such as mobile payments, access control systems, and electronic ticketing; Wi-Fi chips provide wireless network connections and are widely used in scenarios such as smartphones, routers, and smart home devices; GPS chips (Global Positioning System) provide positioning services and are widely used in scenarios such as smartphones, in-car navigation, and drones; image processing chips (ISPs) provide image processing and video decoding and are mainly used in scenarios such as cameras, security monitoring, and smartphones; processor chips (CPUs) provide computing and control capabilities and are widely used in computers, mobile phones, and smart home devices. In addition, there may be sensor chips, power management chips, flash memory chips, etc., which are not listed one by one in this invention.

[0071] The host device may refer to a chip application environment, which is usually a terminal device where the chip product is installed, such as the aforementioned smart phone, access control system, car navigation, electronic computer, etc.

[0072] Typically, the chip product and the host device can be connected via a preset communication interface, enabling data exchange based on this connection to implement related functional services. These functional services include the active device implementing functional services related to the chip product based on the SDK, such as the firmware update service for COS.

[0073] In chip products, CMS acts as a bootloader, which can receive firmware update data sent by the host device through the SDK during its operation, and use the firmware update data to complete the firmware update of COS.

[0074] As previously mentioned, in related technologies, the CMS and SDK collaborate to perform identity verification during the firmware update process to ensure that the issued firmware update data is the official version and not a third-party program such as a malicious program. Traditional identity verification typically uses an identity authentication mechanism based on a group algorithm key. This mechanism requires the SDK and CMS to share a group algorithm key. Both parties use the shared key to encrypt and decrypt a piece of random data, thereby verifying the legitimacy of the other party's identity. However, this introduces a group key management system, which is costly, complex, and less secure, making it less applicable in some chip application environments.

[0075] In view of this, an embodiment of the present application aims to provide a firmware update solution that implements secure authentication of download command data between a chip management system and a software development kit by using a public-private key signature verification method. The public-private key is generated by the developer of the chip management system (e.g., a chip designer), and the public key in the public-private key is stored by the chip management system. The developer uses the private key in the public-private key to sign the download data script used to download the firmware update data, and publishes the signed download data script to the software development kit for storage; when the chip management system and the software development kit authenticate each other, the chip management system verifies the signed download data script provided by the software development kit using the public key. Since the chip management system only needs to store the public key locally, and the download data script for the software development kit does not need to be kept confidential, that is, the chip management system and the software development kit do not need to share the same key, there is no need to introduce a high-cost, high-complexity group key management system. In this way, while ensuring security, the use of a public-private key signature verification method can reduce the cost and complexity of firmware updates, and since the chip management system does not need to deploy a key management system, it is more applicable to various low-performance chips.

[0076] Please refer to the following for further reference Figure 2 The firmware update method flow chart shown in the figure can be understood. Figure 2 The method in can be applied to the aforementioned chip management system; Figure 1As shown, the software development kit corresponding to the chip management system can be run on a device in the chip application environment (i.e., the master device in the figure). In addition, the software development kit in the embodiment of the present application stores a download data script released by the developer of the chip management system, and the download data script includes download command data signed by the developer using a private key; the public key corresponding to the private key is held by the chip management system; the method can include the following steps:

[0077] Step 210: Initiate an authorization request for firmware update to the software development kit.

[0078] In an embodiment of the present application, a chip management system (hereinafter referred to as CMS) may initiate a firmware update authorization request to a software development kit (hereinafter referred to as SDK).

[0079] Step 220: Receive the download command data signed by the private key issued by the developer after the software development kit parses the download data script to obtain the download command data signed by the developer using the private key.

[0080] After receiving the authorization request from the CMS, the SDK parses the stored download data script to extract the signed download command data. As previously mentioned, the signed download command data is obtained by signing the original unsigned download command data using the developer's private key. After parsing the signed download command data, the SDK can send the signed download command data to the CMS.

[0081] The download command data may include information related to the firmware update data to be downloaded, such as the length and location of the firmware update data, whether signature verification is enabled, and the like.

[0082] The format of the download command data in any embodiment of the present application can adopt the APDU format. Since the APDU format is defined by international standards and has more mature ecological support such as supporting tools, it is more applicable and can cover a wider range of application scenarios.

[0083] Based on this, the above download command data may be composed of a plurality of APDU commands. Exemplary download command data may be shown in the following table:

[0084]

[0085]

[0086] Among them, the CLA, INS, P1, P2, Lc and other fields are all taken from the 7816 standard specification and are part of the APDU command.

[0087] Step 230: Use the public key to verify the signed download command data.

[0088] After receiving the download command data signed by the developer's private key issued by the SDK, the CMS can use the public key it holds to verify the signature of the download command data signed by the private key.

[0089] In practical applications, different asymmetric encryption algorithms are used to generate public and private key pairs, and corresponding signature verification algorithms are used. For example, the RSA algorithm or the elliptic curve cryptography (ECC) algorithm can be used.

[0090] It should be noted that the ECC algorithm has better security than the RAS algorithm. For example, even with a smaller key, the ECC algorithm can still provide a security level comparable to or even higher than the RAS algorithm. For example, the 256-bit ECC algorithm is more secure than the 2048-bit RSA algorithm.

[0091] Based on this, in any embodiment of the present application, the above-mentioned private key and the corresponding public key can be generated based on the ECC algorithm.

[0092] Regarding the ECC algorithm, with the improvement and optimization of the ECC algorithm, many improved algorithms based on the ECC algorithm have been derived, such as ECDSA (Elliptic Curve Digital Signature Algorithm), ECDH (Elliptic Curve Diffie-Hellman Algorithm), EdDSA (Edwards Elliptic Curve Digital Signature Algorithm), etc.

[0093] Take the Elliptic Curve Digital Signature Algorithm (ECDSA) as an example; the ECDSA algorithm combines public-key cryptography and hash functions to verify message integrity and source authenticity. ECDSA's security is based on the Elliptic Curve Discrete Logarithm Problem (ECDLP), which enables it to achieve the same or higher security levels as traditional public-key cryptosystems (such as RSA) with shorter key lengths.

[0094] Step 240: If the signature verification passes, execute the download command data to download firmware update data for updating the chip operating system, and use the firmware update data to update the chip operating system.

[0095] If the signature verification fails, it means that the identity of the sender of the download command data is illegal. Therefore, there is a security risk in using the download command data, and malicious programs may be downloaded. Therefore, when the signature verification fails, the received authentication data is discarded or deleted, and the aforementioned step 210 is executed again.

[0096] If the signature verification is successful, it indicates that the identity of the sender of the download command data is legal, and thus the download command data can be used to download the firmware update data.

[0097] Exemplarily, the CMS may execute the download command data to download firmware update data for updating the COS from the SDK, and after downloading the firmware update data, use the firmware update data to update the COS.

[0098] Through the above-described embodiment, public-private key signature verification is used to implement secure authentication of download command data between the chip management system and the software development kit. Since the chip management system only needs to store the public key locally, and the download data script for the software development kit does not need to be kept confidential, that is, the chip management system and the software development kit do not share the same key, there is no need to introduce a high-cost and high-complexity group key management system. Thus, while ensuring security, the use of public-private key signature verification can reduce the cost and complexity of firmware updates. Furthermore, since the chip management system does not need to deploy a key management system, it is more applicable to various low-performance chips.

[0099] In traditional firmware update solutions, in addition to identity authentication, data integrity verification is also required, that is, verifying whether the download command data is complete. If it is incomplete, it means that the download command data may be tampered with. In this case, the download command data should not be executed even if the authentication is passed.

[0100] In related technologies, data integrity verification is implemented based on the CRC (Cyclic Redundancy Check) algorithm. Specifically, the authentication data sent by the SDK to the CMS includes a CRC code in addition to the download command data. In addition to authenticating the download command data, the CMS also needs to use the CRC code to verify the download command data to determine whether it is complete. However, CRC codes have a high probability of collision, that is, different data may have the same CRC code, so the accuracy of integrity verification based on the CRC algorithm is difficult to guarantee.

[0101] In view of this, the embodiments of the present application are Figure 1 Based on the embodiments, the following embodiments are further provided:

[0102] In this embodiment, when the SDK sends the signed download command data, it may also send the digital digest calculated based on the download command data.

[0103] It is understandable that the SDK can simultaneously send the signed download command data and the digital summary to the CMS through one data transmission; or it can send the signed download command data and the digital summary to the CMS separately through two data transmissions.

[0104] Accordingly, if the signature verification passes in step 240, executing the download command data to download the firmware update data for updating the chip operating system may further include:

[0105] If the signature verification passes, the digital summary is further used to perform an integrity check on the download command data;

[0106] If the integrity check passes, the download command data is executed to download firmware update data for updating the chip operating system.

[0107] In this embodiment, the digital digest can be a hash value. Specifically, the SDK can perform a hash calculation on the download command data to obtain a unique hash value. The CMS can then use the hash value to perform an integrity check on the download command data. The CMS can also perform a hash calculation on the download command data to obtain a corresponding hash value. If the hash value calculated by the CMS matches the hash value in the authentication data, the download command data in the authentication data is complete. Because the collision probability of a hash algorithm is much lower than that of a CRC algorithm, integrity checks based on hash values are more accurate.

[0108] In an exemplary embodiment, when the above-mentioned step 240 executes the download command data to download firmware update data for updating the chip operating system, the firmware update data can be unencrypted plaintext data or encrypted ciphertext data; when the firmware update data is ciphertext data, the ciphertext data is decrypted using a key stored in a specific area of the chip to obtain plaintext firmware update data.

[0109] In this embodiment, the encrypted data downloaded by the CMS needs to be further decrypted. The decryption key can be stored in a specific area of the chip. Encryption and decryption can use the same symmetric encryption algorithm, such as AES (Advanced Encryption Standard) and DES (Data Encryption Standard).

[0110] In addition, as with the firmware update data type, the download command data can also be encrypted, and the encrypted download command data also needs to be decrypted first. Although both the ciphertext download command data and the plaintext download command data can be composed of several APDU commands, there are differences in the field definitions. Please take the format definition of the ciphertext download command data as an example:

[0111]

[0112] It's important to note that the CMS obtains download permission for firmware updates through successful signature verification of the download command data. This permission expires after the download command data is executed, effectively invalidating the download permission granted to the CMS. This means that each granted download permission only authorizes the execution of one download command data, not all subsequent download command data. This prevents security risks associated with the execution of unidentified download command data.

[0113] After introducing the firmware update embodiment executed by the above CMS, the following describes Figure 2 The flowchart of the firmware update method with SDK as the execution body is shown in FIG. Figure 1 As shown, the SDK can run on devices in the chip application environment (i.e. Figure 1 In addition, the SDK in the embodiment of the present application stores a download data script published by the developer of the CMS, wherein the download data script includes download command data signed by the developer using a private key; the public key corresponding to the private key is held by the CMS; the method may include the following steps:

[0114] Step 310: Receive an authorization request for firmware update initiated by the chip management system.

[0115] This step corresponds to the aforementioned step 210 , where the CMS initiates an authorization request, and the SDK executes steps 320 to 330 after receiving the authorization request.

[0116] In actual applications, in order to implement the execution of subsequent steps, the SDK may also complete the update accuracy in advance before step 310.

[0117] For example, the SDK can set the file path: / system / vendor / hed / libnfc.conf

[0118] Set the path of the firmware update data: / system / vendor / hed / lib_fw.so

[0119] Set the firmware flag to true

[0120] Read policy configuration items in the configuration file, etc.

[0121] Step 320: Parse the download data script, and send the download command data signed by the developer using the private key in the parsed download data script to the chip management system.

[0122] After receiving the authorization request from the CMS, the SDK parses the stored download data script to extract the signed download command data. The signed download command data is obtained by signing the original unsigned download command data using the developer's private key. After extracting the signed download command data, the SDK sends it to the CMS as authentication data.

[0123] The download command data may include information related to the firmware update data to be downloaded, such as the length and location of the firmware update data, whether signature verification is enabled, etc. The format of the download command data in the embodiment of the present application may adopt the extended APDU format.

[0124] This step corresponds to step 220 in the aforementioned embodiment. Please refer to the contents of the aforementioned embodiment and will not be described in detail here.

[0125] Step 330, in response to the chip management system executing the download command data after successfully verifying the download command data signed by the private key based on the public key, the firmware update data for updating the chip operating system is sent to the chip management system, so that the chip management system uses the firmware update data to update the chip operating system.

[0126] This step corresponds to steps 230 and 240 in the aforementioned embodiment. Please refer to the contents of the aforementioned embodiment and will not be described again here.

[0127] Through the above-described embodiment, public-private key signature verification is used to implement secure authentication of download command data between the chip management system and the software development kit. Since the chip management system only needs to store the public key locally, and the download data script for the software development kit does not need to be kept confidential, that is, the chip management system and the software development kit do not share the same key, there is no need to introduce a high-cost and high-complexity group key management system. Thus, while ensuring security, the use of public-private key signature verification can reduce the cost and complexity of firmware updates. Furthermore, since the chip management system does not need to deploy a key management system, it is more applicable to various low-performance chips.

[0128] It is worth mentioning that the firmware update data in the SDK can be provided in the form of a so library. The so library can provide two variables, DlSeq (character array) pointing to the download command data, and DlSeqSz (int integer) pointing to the character array length.

[0129] As described in the previous embodiment, the format of the download command data consists of multiple APDU commands. The following example provides a download command data for reference:

[0130] fwvers ion=xxxx / / two-byte version information

[0131] checkdatalen=xxxx xxxx / / four-byte check data length

[0132] checkdatacrc=xxxx / / two-byte crc

[0133] apdu=BF4C000000000400000000

[0134] apdu=B0700000001040+ciphertext+signature value

[0135] apdu=B0B00000001040+ciphertext+signature value

[0136] In an exemplary embodiment, the configuration file of the software development kit maintains a policy configuration item of the firmware update policy;

[0137] Accordingly, the above step 330 of sending the firmware update data for updating the chip operating system to the chip management system may further include:

[0138] Loading version information of firmware update data used to update the chip operating system;

[0139] Reading the policy configuration items in the configuration file, and determining an update strategy for the policy configuration items;

[0140] Update the status of the firmware flag bit according to the update strategy and the version information;

[0141] When the state of the firmware flag is the downloading state, the firmware update data for updating the chip operating system is sent to the chip management system.

[0142] In this embodiment, the above-mentioned policy configuration item can be taken as an example of "HED_FLASH_CONFIG" in the configuration file. "HED_FLASH_CONFIG" can have a value of 1, 2, or 3, where 1 indicates a higher version update, 2 indicates a different version update, and 3 indicates always updating. The SDK obtains the version information of the firmware in the NFCC by resetting the NFCC core (i.e., sending cmd_reset_nci:0x20,0x00,0x01,0x01).

[0143] Furthermore, the updating of the status of the firmware flag bit according to the update strategy and the version information may include at least one of the following:

[0144] (1) If the update strategy is a higher version update and the version information is a higher version, the firmware flag is updated to a download state.

[0145] For example, when "HED_FLASH_CONFIG" = 1 and the version information is a higher version, the firmware flag is set to the download state true. Otherwise, if the version information is not a higher version, the firmware flag is set to false.

[0146] (2) If the update policy is to update the versions differently, and the version information is different, the firmware flag is updated to the download state.

[0147] For example, when "HED_FLASH_CONFIG" = 2 and the version information is a different version, the firmware flag is set to download state true. Otherwise, if the version information is not a different version, the firmware flag is set to false.

[0148] (3) If the update policy is to always update, the firmware flag is updated to the download state.

[0149] For example, when "HED_FLASH_CONFIG" = 3, the firmware flag is directly set to the download state true. Otherwise, if the version information is neither 1 nor 2 nor 3, the firmware flag is directly set to false.

[0150] When the firmware flag is true, the firmware update process is terminated. When the firmware flag is true, the "HED_NFCC_MODE" item in the configuration file is set to 1, enabling download mode (chip power off, pull LDMode High, chip power on); loading the firmware update data as the download source; and sending the firmware update data used to update the chip operating system to the chip management system.

[0151] Through the above embodiment, the version control strategy of the firmware update is improved from being implemented on the traditional CMS side to being instantiated on the SDK side, thereby saving CMS side storage space and simplifying the design complexity of the CMS side.

[0152] In actual applications, when the CMS downloads firmware update data, it will update while downloading, that is, it will perform a partial update based on the partially downloaded firmware update data. At this time, if the chip is abnormally powered off, the CMS will not be able to download the complete firmware update data. At this time, you need to consider how to restore to the old version of the firmware.

[0153] To address the aforementioned issues, the CMS typically provides an A / B backup mechanism. If downloading new firmware A fails, the old firmware B can be rolled back to restore it. If downloading new firmware A succeeds, the new firmware A is used as a backup of the old firmware B, replacing the original old firmware A. This approach requires a lot of CMS storage space and is difficult to apply to low-cost chip products.

[0154] In view of this, based on any of the above embodiments, the following embodiments are further provided:

[0155] In this embodiment, the SDK maintains firmware recovery data corresponding to the current version of the chip operating system, and after the above step 330, the following steps may be further included:

[0156] In response to a failure of the chip management system to update the chip operating system, counting the number of downloads of the same firmware update data by the chip management system;

[0157] If the number of downloads reaches a threshold, the firmware recovery data is sent to the chip management system, so that the chip management system uses the firmware recovery data to restore the chip operating system to the version before the update.

[0158] If the number of downloads does not reach the threshold, the firmware update data for updating the chip operating system will be sent to the chip management system again.

[0159] Through the above embodiment, by improving the A / B backup mechanism in the traditional CMS into the SDK, since the CMS adopts pure overwrite download, the CMS end can restore to the old version of the firmware without providing additional storage space and complex design, so it can be applied to more low-cost chip products.

[0160] In an exemplary embodiment, the method further includes:

[0161] In response to the chip management system successfully updating the chip operating system, the maintained firmware recovery data is deleted, and the firmware update data is backed up as new firmware recovery data.

[0162] In this embodiment, if the CMS firmware is successfully updated, the SDK needs to update the maintained firmware recovery data to serve as an A / B backup for subsequent firmware updates of new versions.

[0163] For example, after the CMS firmware is successfully updated, the SDK can back up the firmware update data in the firmware update data path: / system / vendor / hed / lib_fw.so set in the aforementioned step 310 to the firmware recovery data path: system / vendor / hed / lib_fw_platform.so; thereby completing the A / B backup.

[0164] It should be noted that, since the firmware update embodiment provided in this application involves cooperation between CMS and SDK, the steps in the above-mentioned embodiment with CMS as the execution body and the embodiment with SDK as the execution body can refer to each other or be implemented in combination.

[0165] Corresponding to the aforementioned firmware update method embodiment, the present application also provides an embodiment of a firmware update device. The device embodiment can be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of the device in which it is located reading the corresponding computer program in the non-volatile memory into the memory and running it. From the hardware level, such as Figure 4 FIG. 1 is a schematic diagram of a structure of a device where the firmware update device in the embodiment of the present application is located, except Figure 4 In addition to the processor, network interface, memory and non-volatile memory shown, the device in which the apparatus in the embodiment is located may also include other hardware according to the actual communication function, which will not be described in detail.

[0166] See Figure 5 , is a structural diagram of a firmware update device provided in an embodiment of the present application, the device corresponds to Figure 2 The embodiment shown is applied to a chip management system, wherein a software development kit corresponding to the chip management system runs on a device in a chip application environment; the software development kit stores a download data script published by the developer of the chip management system, wherein the download data script includes download command data signed by the developer using a private key; the public key corresponding to the private key is held by the chip management system; the apparatus includes:

[0167] The request unit 510 initiates an authorization request for firmware update to the software development kit;

[0168] The receiving unit 520 receives the download command data signed by the private key issued by the developer after the software development kit parses the download data script to obtain the download command data signed by the developer using the private key;

[0169] The signature verification unit 530 uses the public key to verify the download command data signed by the private key;

[0170] The updating unit 540 executes the download command data to download firmware update data for updating the chip operating system if the signature verification passes, and uses the firmware update data to update the chip operating system.

[0171] Optionally, the receiving unit 520 further includes receiving a digital summary calculated based on the download command data and issued by the software development kit;

[0172] The updating unit 540 includes:

[0173] The verification subunit further uses the digital summary to perform integrity verification on the download command data if the signature verification passes;

[0174] The download subunit executes the download command data to download firmware update data for updating the chip operating system if the integrity check passes.

[0175] Optionally, the updating unit 540 includes:

[0176] A download subunit, executing the download command data to download firmware update data for updating the chip operating system;

[0177] The decryption subunit uses a key stored in a specific area of the chip to decrypt the ciphertext data to obtain the plaintext firmware update data when the firmware update data is ciphertext data.

[0178] Optionally, the download command data becomes invalid after execution is completed.

[0179] Optionally, the private key and the corresponding public key are generated using a 256-bit elliptic cryptographic algorithm.

[0180] Optionally, the script format of the download data script includes APUD format.

[0181] See Figure 6 , is a structural diagram of a firmware update device provided in an embodiment of the present application, the device corresponds to Figure 3The illustrated embodiment is applied to a software development kit corresponding to a chip management system, the software development kit running on a device in a chip application environment; the software development kit stores a download data script published by the developer of the chip management system, the download data script including download command data signed by the developer using a private key; the public key corresponding to the private key is held by the chip management system; the apparatus includes:

[0182] The receiving unit 610 receives an authorization request for firmware update initiated by the chip management system;

[0183] The signature unit 620 parses the download data script and sends the download command data signed by the developer using the private key in the parsed download data script to the chip management system;

[0184] The update unit 630, in response to the chip management system executing the download command data after successfully verifying the download command data signed by the private key based on the public key, sends the firmware update data for updating the chip operating system to the chip management system, so that the chip management system uses the firmware update data to update the chip operating system.

[0185] Optionally, a configuration file of the software development kit maintains a policy configuration item of the firmware update policy;

[0186] The updating unit 630 includes:

[0187] The version control subunit loads the version information of the firmware update data used to update the chip operating system; reads the policy configuration item in the configuration file and determines the update policy of the policy configuration item; updates the status of the firmware flag bit according to the update policy and the version information; and when the status of the firmware flag bit is a downloading state, sends the firmware update data used to update the chip operating system to the chip management system.

[0188] Optionally, updating the status of the firmware flag bit according to the update policy and the version information includes at least one of the following:

[0189] If the update policy is a higher version update and the version information is a higher version, the firmware flag is updated to a download state;

[0190] If the update policy is version different update, and the version information is different, then the firmware flag is updated to the download state;

[0191] If the update policy is to always update, the firmware flag is updated to the download state.

[0192] Optionally, the software development kit maintains firmware recovery data corresponding to the current version of the chip operating system, and the device further includes:

[0193] A recovery unit, in response to the chip management system failing to update the chip operating system, counts the number of times the chip management system downloads the same firmware update data; if the number of downloads reaches a threshold, sends the firmware recovery data to the chip management system; so that the chip management system uses the firmware recovery data to restore the chip operating system to the version before the update.

[0194] Optionally, the device further includes:

[0195] The retransmission unit sends the firmware update data for updating the chip operating system to the chip management system again if the number of downloads does not reach the threshold.

[0196] Optionally, the device further includes:

[0197] The backup unit deletes the maintained firmware recovery data in response to the chip management system successfully updating the chip operating system, and backs up the firmware update data as new firmware recovery data.

[0198] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

[0199] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0200] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present application scheme. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0201] above Figure 5 or Figure 6The internal functional modules and structural schematic of the firmware update device are described. The actual execution subject can be an electronic device, including:

[0202] processor;

[0203] a memory for storing processor-executable instructions;

[0204] The processor is configured to execute any one of the above firmware update method embodiments.

[0205] In the embodiment of the above-mentioned electronic device, it should be understood that the processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or any conventional processor, etc., and the aforementioned memory can be a read-only memory (ROM), a random access memory (RAM), a flash memory, a hard disk, or a solid-state drive. The steps of the method disclosed in the embodiment of the present invention can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor.

[0206] The various embodiments in this application are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences from other embodiments. In particular, the electronic device embodiment is generally similar to the method embodiment, so the description is relatively simple. For relevant parts, refer to the partial description of the method embodiment.

[0207] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0208] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A firmware update method, characterized in that: Applied to a chip management system, a software development kit corresponding to the chip management system runs on a device in a chip application environment; the software development kit stores a download data script published by the developer of the chip management system, and the download data script includes download command data signed by the developer using a private key; The public key corresponding to the private key is held by the chip management system; the method includes: Initiating an authorization request for firmware update to the software development kit; Receiving the download command data signed by the private key issued by the developer after the software development kit parses the download data script; Use the public key to verify the download command data signed by the private key; If the signature verification passes, the download command data is executed to download firmware update data for updating the chip operating system, and the chip operating system is updated using the firmware update data.

2. The method according to claim 1, characterized in that The method further comprises: receiving a digital summary issued by the software development kit and calculated based on the download command data; If the signature verification passes, executing the download command data to download firmware update data for updating the chip operating system includes: If the signature verification passes, the digital summary is further used to perform an integrity check on the download command data; If the integrity check passes, the download command data is executed to download firmware update data for updating the chip operating system.

3. The method according to claim 1 or 2, wherein executing the download command data to download firmware update data for updating a chip operating system comprises: Executing the download command data to download firmware update data for updating the chip operating system; When the firmware update data is ciphertext data, the ciphertext data is decrypted using a key stored in a specific area of the chip to obtain the plaintext firmware update data.

4. The method according to claim 1 or 2, characterized in that The download command data becomes invalid after execution is completed.

5. The method according to claim 1 or 2, characterized in that The private key and the corresponding public key are generated using a 256-bit elliptic cryptographic algorithm.

6. The method according to claim 1 or 2, characterized in that The script format of the download data script includes APUD format.

7. A firmware update method, characterized in that: Applicable to a software development kit corresponding to a chip management system, the software development kit running on a device in a chip application environment; the software development kit storing a download data script published by the developer of the chip management system, the download data script including download command data signed by the developer using a private key; The public key corresponding to the private key is held by the chip management system; the method includes: Receiving an authorization request for firmware update initiated by the chip management system; Parsing the download data script, and sending the download command data signed by the developer using the private key in the parsed download data script to the chip management system; In response to the chip management system executing the download command data after successfully verifying the download command data signed by the private key based on the public key, the firmware update data for updating the chip operating system is sent to the chip management system, so that the chip management system uses the firmware update data to update the chip operating system.

8. The method according to claim 7, characterized in that The configuration file of the software development kit maintains a policy configuration item of the firmware update policy; The step of sending the firmware update data for updating the chip operating system to the chip management system includes: Loading version information of firmware update data used to update the chip operating system; Reading the policy configuration items in the configuration file, and determining an update strategy for the policy configuration items; Update the status of the firmware flag bit according to the update strategy and the version information; When the state of the firmware flag is the downloading state, the firmware update data for updating the chip operating system is sent to the chip management system.

9. The method according to claim 8, characterized in that Updating the status of the firmware flag bit according to the update strategy and the version information includes at least one of the following: If the update policy is a higher version update and the version information is a higher version, the firmware flag is updated to a download state; If the update policy is version different update, and the version information is different, then the firmware flag is updated to the download state; If the update policy is to always update, the firmware flag is updated to the download state.

10. The method according to any one of claims 7 to 9, characterized in that: The software development kit maintains firmware recovery data corresponding to the current version of the chip operating system, and the method further includes: In response to a failure of the chip management system to update the chip operating system, counting the number of downloads of the same firmware update data by the chip management system; If the number of downloads reaches a threshold, the firmware recovery data is sent to the chip management system, so that the chip management system uses the firmware recovery data to restore the chip operating system to the version before the update.

11. The method according to claim 10, characterized in that The method further comprises: If the number of downloads does not reach the threshold, the firmware update data for updating the chip operating system is sent to the chip management system again.

12. The method according to claim 10, characterized in that The method further comprises: In response to the chip management system successfully updating the chip operating system, the maintained firmware recovery data is deleted, and the firmware update data is backed up as new firmware recovery data.

13. A firmware update device, characterized in that: Applied to a chip management system, a software development kit corresponding to the chip management system runs on a device in a chip application environment; the software development kit stores a download data script published by the developer of the chip management system, and the download data script includes download command data signed by the developer using a private key; The public key corresponding to the private key is held by the chip management system; the device includes: a requesting unit, initiating an authorization request for firmware update to the software development kit; a receiving unit, receiving the download command data signed by the private key issued by the developer after the software development kit parses the download data script to obtain the download command data; A signature verification unit, using the public key to verify the download command data signed by the private key; The updating unit executes the download command data to download firmware update data for updating the chip operating system if the signature verification passes, and uses the firmware update data to update the chip operating system.

14. A firmware update device, characterized in that: Applicable to a software development kit corresponding to a chip management system, the software development kit running on a device in a chip application environment; the software development kit storing a download data script published by the developer of the chip management system, the download data script including download command data signed by the developer using a private key; The public key corresponding to the private key is held by the chip management system; the device includes: A receiving unit, receiving an authorization request for firmware update initiated by the chip management system; a signature unit, which parses the download data script and sends the download command data signed by the developer using the private key in the parsed download data script to the chip management system; An update unit, in response to the chip management system executing the download command data after successfully verifying the download command data signed by the private key based on the public key, sends the firmware update data for updating the chip operating system to the chip management system, so that the chip management system uses the firmware update data to update the chip operating system.

15. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to execute the method according to any one of claims 1 to 12.

Images