Method and related device for over-the-air upgrade

Abstract

The application provides an over-the-air upgrade method and related equipment, and relates to the fields of network technology and security. The method comprises the following steps: sending a device identifier and a first firmware version number to the cloud; receiving a public key, firmware corresponding to a second firmware version number, encrypted data and signature data sent by the cloud; obtaining a first response according to the first firmware version number based on a physically unclonable function chip; decrypting the encrypted data according to the first response to obtain the second firmware version number to be verified; verifying the signature data according to the public key, the second firmware version number to be verified and the firmware corresponding to the second firmware version number; and performing firmware upgrade according to the firmware corresponding to the second firmware version number in the case of passing the verification. The application does not need to store the public key of the cloud on the device side for a long time, reduces the occupation of storage resources, improves the overall performance of the device side, and does not need to preset the same OTA cloud public key on the device side, thereby reducing the management complexity.

Description

Technical Field

[0001] This disclosure relates to the field of network technology and security, and in particular to an over-the-air upgrade method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] OTA (Over-The-Air) is a method for remotely updating device firmware or software using wireless communication technology. It is widely used in modern Internet of Things (IoT) devices, smartphones, automobiles, embedded systems, and other fields.

[0003] In related technologies, OTA upgrade methods rely on the signature and verification mechanisms of traditional public-key cryptography algorithms. The device needs to pre-install the same OTA cloud public key, which not only increases management complexity but also poses a serious threat to the security of the entire system if the private key is compromised. Furthermore, public keys are difficult to update in a timely manner, making it difficult to cope with constantly evolving security challenges. At the same time, for resource-constrained devices, storing public keys consumes valuable storage space, thus affecting the overall performance of the device.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] This disclosure provides an over-the-air upgrade method and related equipment, which at least to some extent overcomes the problems of high management complexity, difficulty in updating public keys, and resource consumption in related technologies.

[0006] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0007] According to one aspect of this disclosure, an over-the-air (OTA) upgrade method is provided, applied to a device equipped with a physically unclonable function (PCF) chip, comprising: sending a device identifier and a first firmware version number to a cloud, so that the cloud receives a first response based on the device identifier and the first firmware version number, and encrypts a second firmware version number using the first response to obtain encrypted data; obtaining signature data based on a private key, the second firmware version number, and the firmware corresponding to the second firmware version number, wherein the second firmware version number is the version number of the firmware upgraded from the firmware corresponding to the first firmware version number; receiving a public key, the firmware corresponding to the second firmware version number, the encrypted data, and the signature data sent by the cloud; obtaining the first response based on the PCF chip and the first firmware version number; decrypting the encrypted data based on the first response to obtain a second firmware version number to be verified; verifying the signature data based on the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number; and, if the verification is successful, performing a firmware upgrade based on the firmware corresponding to the second firmware version number.

[0008] According to another aspect of this disclosure, an over-the-air (OTA) upgrade method is also provided, applied in the cloud, comprising: receiving a device identifier and a first firmware version number sent by a device; obtaining a first response based on the device identifier and the first firmware version number; encrypting a second firmware version number using the first response to obtain encrypted data, wherein the second firmware version number is the version number of the firmware upgraded to the firmware corresponding to the first firmware version number; obtaining signature data based on a private key, the second firmware version number, and the firmware corresponding to the second firmware version number; sending a public key, the firmware corresponding to the second firmware version number, the encrypted data, and the signature data to the device, so that the device, based on a physically non-cloning function (PTC) chip, obtains the first response based on the first firmware version number, decrypts the encrypted data based on the first response to obtain a second firmware version number to be verified, verifies the signature data based on the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number, and, if the verification is successful, performs a firmware upgrade based on the firmware corresponding to the second firmware version number.

[0009] According to another aspect of this disclosure, an over-the-air (OTA) upgrade device is also provided, applied to a device end, wherein the device end is equipped with a physically unclonable function (PCF) chip, comprising: a first sending module, configured to send a device identifier and a first firmware version number to a cloud, so that the cloud obtains a first response based on the device identifier and the first firmware version number, and uses the first response to encrypt a second firmware version number to obtain encrypted data, and obtains signature data based on a private key, the second firmware version number, and the firmware corresponding to the second firmware version number, wherein the second firmware version number is the version number of the firmware upgraded from the firmware corresponding to the first firmware version number; a first receiving module, configured to receive a public key, the firmware corresponding to the second firmware version number, the encrypted data, and the signature data sent by the cloud; a first determining module, configured to obtain the first response based on the PCF chip and the first firmware version number; a decryption module, configured to decrypt the encrypted data based on the first response to obtain a second firmware version number to be verified; a verification module, configured to verify the signature data based on the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number; and an upgrade module, configured to perform a firmware upgrade based on the firmware corresponding to the second firmware version number if the verification is successful.

[0010] According to another aspect of this disclosure, an over-the-air (OTA) upgrade device is also provided, applied in the cloud, comprising: a second receiving module for receiving a device identifier and a first firmware version number sent by a device; a second determining module for obtaining a first response based on the device identifier and the first firmware version number; an encryption module for encrypting a second firmware version number using the first response to obtain encrypted data, wherein the second firmware version number is the version number of the firmware upgraded to the firmware corresponding to the first firmware version number; a signing module for obtaining signature data based on a private key, the second firmware version number, and the firmware corresponding to the second firmware version number; and a second sending module for sending a public key, the firmware corresponding to the second firmware version number, the encrypted data, and the signature data to the device, so that the device, based on a physically non-cloning function (PTC) chip, obtains the first response based on the first firmware version number, decrypts the encrypted data based on the first response to obtain a second firmware version number to be verified, verifies the signature data based on the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number, and performs a firmware upgrade based on the firmware corresponding to the second firmware version number if the verification is successful.

[0011] According to another aspect of this disclosure, an electronic device is also provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the over-the-air upgrade method described in any of the preceding claims by executing the executable instructions.

[0012] According to another aspect of this disclosure, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the over-the-air upgrade method described in any of the preceding claims.

[0013] According to another aspect of this disclosure, a computer program product is also provided, comprising: a computer program or instructions that, when executed by a processor, implement the over-the-air upgrade method of any of the above.

[0014] In this embodiment, the terminal sends a device identifier and a first firmware version number to the cloud. The cloud receives a first response based on the device identifier and the first firmware version number, and uses the first response to encrypt a second firmware version number to obtain encrypted data. Based on the private key, the second firmware version number, and the firmware corresponding to the second firmware version number, signature data is obtained. The terminal receives the public key, the firmware corresponding to the second firmware version number, the encrypted data, and the signature data sent by the cloud. Based on the physically unclonable function (PUF) chip, it receives a first response based on the first firmware version number; decrypts the encrypted data based on the first response to obtain a second firmware version number to be verified; verifies the signature data based on the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number; and if the verification is successful, performs a firmware upgrade based on the firmware corresponding to the second firmware version number. This disclosure fully utilizes the unclonable characteristics of the physically unclonable function (PUF) chip and the uniqueness of the device, eliminating the need for long-term storage of the cloud public key on the device, reducing storage resource consumption, improving the overall performance of the device, and eliminating the need for pre-installed identical OTA cloud public keys on the device, thereby reducing management complexity. Furthermore, this disclosure does not require updating the public key. It decrypts the encrypted data using the first response obtained from the physically non-clonable function chip, and verifies the signature data based on the decrypted second firmware version number to be verified, the public key, and the firmware corresponding to the second firmware version number, thereby further improving the security of over-the-air upgrades.

[0015] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0017] Figure 1 A flowchart of an over-the-air upgrade method in the relevant technology is shown.

[0018] Figure 2 A schematic diagram of an over-the-air upgrade system structure is shown in an embodiment of this disclosure.

[0019] Figure 3 A flowchart of an over-the-air upgrade method according to an embodiment of the present disclosure is shown.

[0020] Figure 4 A flowchart of an over-the-air upgrade method according to another embodiment of this disclosure is shown.

[0021] Figure 5 A schematic diagram of an over-the-air upgrade system according to an embodiment of this disclosure is shown.

[0022] Figure 6 A signaling diagram of the over-the-air upgrade method in an embodiment of this disclosure is shown.

[0023] Figure 7 A flowchart of an over-the-air upgrade method is shown in another embodiment of this disclosure.

[0024] Figure 8 A schematic diagram of an over-the-air upgrade device is shown in one embodiment of this disclosure.

[0025] Figure 9 A schematic diagram of an over-the-air upgrade device is shown in another embodiment of this disclosure.

[0026] Figure 10 A structural block diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0027] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0028] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0029] To facilitate understanding, before introducing the embodiments of this disclosure, several terms involved in the embodiments of this disclosure will be explained as follows.

[0030] PUF (Physical Unclonable Function) is a technology that generates unique identifiers based on the physical characteristics of hardware. It leverages microscopic differences in materials or manufacturing processes to generate unique, unpredictable responses for each device. These differences are naturally formed during production and cannot be precisely copied or cloned, thus providing a high level of security. PUF works through a challenge-response mechanism: a challenge is input, and a unique response determined by the device's physical characteristics is obtained.

[0031] OTA (Over-the-Air) is a technology that uses a wireless network to transmit data or update features on remote devices. It is used for software upgrades, firmware updates, and configuration parameter adjustments, and is particularly prevalent in the Internet of Things (IoT), smartphones, and smart cars. Through OTA technology, manufacturers can perform remote upgrades without manual user intervention or device return to the factory, thereby improving maintenance efficiency, reducing operating costs, and promptly fixing vulnerabilities or adding new features. The core OTA process includes firmware package signing and distribution, device verification and installation, ensuring the security and reliability of the upgrade process.

[0032] RSA (Rivest-Shamir-Adleman, a public-key cryptography algorithm) is used for digital signatures to ensure the integrity and authenticity of data. In digital signatures, the private key is used to sign the data, and the recipient uses the public key to verify the signature.

[0033] ECDSA (Elliptic Curve Digital Signature Algorithm) is used to ensure data integrity, authentication, and non-repudiation. It is an algorithm that uses the mathematical structure of elliptic curves to implement digital signatures.

[0034] In related technologies, such as Figure 1 As shown, the device has a pre-configured cloud public key. The device reports its version number to the cloud, which generates an upgrade package. The cloud then determines whether to upgrade based on the reported version number sent by the device. If no upgrade is needed, no action is taken. If an upgrade is required, an upgrade request is sent to the device. The device receives the upgrade package generated by the cloud, verifies it using the pre-configured cloud public key, and updates the program upon successful verification. In other words, the firmware is upgraded based on the upgrade package.

[0035] The cloud generates the upgrade package using a signing module. For example, the signing module signs the package using S = Sign(sk, Fireware), where S represents the upgrade package (data encrypted with the private key), Sign represents the encryption algorithm, sk represents the private key, and Fireware represents the firmware. The device verifies the upgrade package using a signature verification module. For example, the signature verification module verifies the package using V = Verify(pk, Fireware, S), where V represents the verification result, Verify represents the verification algorithm, pk represents the public key, Fireware represents the firmware, and S represents the upgrade package.

[0036] Over-the-air (OTA) upgrade methods in related technologies rely on traditional public-key encryption algorithms (such as RSA and ECDSA), which are easily cracked in a quantum computing environment and vulnerable to quantum computing attacks, thus posing a serious security threat to the devices. Furthermore, each device is pre-installed with the same static key (cloud public key), which is easily extracted or cracked. Pre-installed static keys are difficult to update and require storing large amounts of keys and certificates, consuming limited storage space on the device.

[0037] To address at least one of the aforementioned problems, this disclosure provides an over-the-air (OTA) update method and related equipment, applicable to scenarios involving device firmware or software upgrades. For example, it can be applied in the smart home field, such as OTA updates for smart door locks, smart cameras, and smart appliances, where these devices have limited resources and high security requirements. For example, it can be applied in the Industrial Internet of Things (IIoT), where numerous sensors, controllers, and other IoT devices require firmware upgrades to optimize performance in industrial production. For example, it can be applied to wearable devices, such as smart bracelets and smartwatches, where firmware upgrades optimize performance, but these devices have very limited storage space and power consumption. The OTA update method provided by this disclosure fully utilizes the non-cloning characteristics of PUF chips and the uniqueness of devices, eliminating the need for long-term storage of cloud public keys on the device side, reducing storage resource consumption, improving overall device performance, and eliminating the need for pre-installed identical OTA cloud public keys on the device side, thereby reducing management complexity. Furthermore, this disclosure does not require updating the public key. It decrypts the encrypted data using the first response obtained from the physically non-clonable function chip, and verifies the signature data based on the decrypted second firmware version number to be verified, the public key, and the firmware corresponding to the second firmware version number, thereby further improving the security of over-the-air upgrades.

[0038] The specific implementation methods of the embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0039] Figure 2 A schematic diagram of an over-the-air upgrade system architecture according to an embodiment of this disclosure is shown. Figure 2 As shown, the system architecture may include a device 201 and a cloud 202. The device 201 and the cloud 202 can be connected via a wireless network.

[0040] Optionally, the aforementioned wireless network may use standard communication technologies and / or protocols. The network is typically the Internet, but can also be any network, including but not limited to any combination of Local Area Networks (LANs), Metropolitan Area Networks (MANs), Wide Area Networks (WANs), mobile networks, private networks, or Virtual Private Networks (VPNs). In some embodiments, technologies and / or formats including Hyper Text Markup Language (HTML), Extensible Markup Language (XML), etc., are used to represent data exchanged over the network. Furthermore, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Networks (VPNs), and Internet Protocol Security (IPsec) may be used to encrypt all or some links. In other embodiments, customized and / or dedicated data communication technologies may be used to replace or supplement the aforementioned data communication technologies.

[0041] Device 201 can be various electronic devices, including but not limited to cameras, webcams, drones, smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, wearable devices, augmented reality devices, virtual reality devices, etc.

[0042] Optionally, the client of the application installed on different devices 201 may be the same, or the client of the same type of application based on different operating systems. Depending on the device platform, the specific form of the application client may also be different; for example, the application client may be a mobile client, a PC client, etc.

[0043] Cloud 202 can be an OTA server that provides various services, such as a backend management server that supports the device operated by the user via device 201. The backend management server can analyze and process the received requests and other data, and feed the processing results back to the device.

[0044] Optionally, the server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The cloud-based 202 transmits data or updates functions to the device-based 201 via a wireless network. The device-based 201 is equipped with a PUF chip. The PUF chip on the device-based 201 can generate a unique response for each device; the cloud-based 202 adds a database and a key management module. The cloud-based database can be used to store the mapping relationship of "device identifier - PUF identifier - challenge - response"; the key management module is responsible for generating public-private key pairs. Furthermore, this disclosure can upgrade the signature module and verification module, introducing a quantum-resistant public-key signature algorithm on the basis of traditional public-key cryptography algorithms to further enhance security.

[0045] Under the above system architecture, this disclosure provides an over-the-air upgrade method, which can be executed by any electronic device with computing power.

[0046] In some embodiments, the over-the-air (OTA) upgrade method provided in this disclosure can be executed by the device side of the system architecture described above; in other embodiments, the OTA upgrade method provided in this disclosure can be executed by the cloud in the system architecture described above; in still other embodiments, the OTA upgrade method provided in this disclosure can be implemented by the device side and the cloud in the system architecture described above through interaction.

[0047] Figure 3 A flowchart of an over-the-air upgrade method according to an embodiment of this disclosure is shown, such as Figure 3 As shown, the method is applied to the device side, which is equipped with a physically unclonable function chip. The over-the-air upgrade method provided in this embodiment may include the following steps S301 to S306.

[0048] S301 sends the device identifier and the first firmware version number to the cloud so that the cloud can obtain the first response based on the device identifier and the first firmware version number, and use the first response to encrypt the second firmware version number to obtain encrypted data. Based on the private key, the second firmware version number, and the firmware corresponding to the second firmware version number, the signature data is obtained. The second firmware version number is the version number of the firmware upgraded from the firmware corresponding to the first firmware version number.

[0049] In this embodiment, the device identifier is used to uniquely identify the device. This embodiment does not specifically limit the form in which the device identifier is represented. For example, the device identifier can be represented by one or more combinations of letters, numbers, symbols, and Chinese characters. The first firmware version number is the version number of the firmware to be upgraded on the device.

[0050] S302 receives the public key, firmware corresponding to the second firmware version number, encrypted data, and signature data sent from the cloud.

[0051] S303, a chip based on physically unclonable functions, obtains the first response based on the first firmware version number.

[0052] In this embodiment of the disclosure, the first firmware version number is used as a challenge input to the physically unclonable function chip, and a first response is output.

[0053] S304 decrypts the encrypted data based on the first response to obtain the second firmware version number to be verified.

[0054] In this embodiment, the cloud uses a first response to encrypt the second firmware version number, obtaining encrypted data. The device then uses the first response output by the physically non-cloning function chip to decrypt the encrypted data, obtaining the second firmware version number to be verified. This disclosure eliminates the need to store the cloud key on the device to decrypt the encrypted data. Furthermore, the cloud's encryption of the second firmware version number using the first response enhances the security of the encryption.

[0055] S305 verifies the signature data based on the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number.

[0056] In this embodiment of the disclosure, the signature data is verified by using the decrypted second firmware version number to be verified, the public key, and the second firmware version number together. By utilizing the uniqueness of the device end configured with the PUF chip, it is ensured that when the signature public key, the firmware corresponding to the second firmware version number, and the signature data are tampered with, they can be verified, thus preventing attackers from sending illegal firmware (such as firmware upgrade packages).

[0057] S306, if the verification is successful, will perform a firmware upgrade based on the firmware corresponding to the second firmware version number.

[0058] It should be noted that the firmware will not be upgraded if the verification fails.

[0059] This disclosure fully utilizes the non-cloning nature of the PUF chip and the uniqueness of the device, eliminating the need for long-term storage of the cloud public key on the device, reducing storage resource consumption, improving overall device performance, and eliminating the need for the device to pre-install the same OTA cloud public key, thereby reducing management complexity. Furthermore, this disclosure eliminates the need to update the public key; the encrypted data is decrypted using the first response obtained from the PUF chip, and the signature data is verified based on the decrypted second firmware version number to be verified, the public key, and the firmware corresponding to the second firmware version number, further enhancing the security of over-the-air upgrades.

[0060] The present disclosure will now be described through several exemplary embodiments.

[0061] In an exemplary embodiment, the over-the-air upgrade method provided in this disclosure, which decrypts encrypted data based on a first response to obtain a second firmware version number to be verified, may include: performing an XOR operation on the first response and the encrypted data to obtain the second firmware version number to be verified.

[0062] It should be noted that the cloud performs an XOR operation on the first response and the second firmware version number to obtain the encrypted data. The device performs an XOR operation on the first response and the encrypted data to obtain the second firmware version number to be verified.

[0063] This embodiment of the disclosure uses XOR operations to encrypt data, effectively protecting the second firmware version number between the cloud and the device, ensuring the security and integrity of data exchange. Due to the reversibility of XOR operations, only the device with the correct first response and encrypted data can successfully verify the second firmware version number, reducing the risk of man-in-the-middle attacks. Furthermore, XOR operations have low computational overhead, making them suitable for efficient execution on low-power devices without affecting device performance, and they are simple to implement and have good scalability.

[0064] In another exemplary embodiment, the over-the-air upgrade method provided in this disclosure may include decrypting encrypted data based on a first response to obtain a second firmware version number to be verified, which may include: decrypting encrypted data using a first response based on a symmetric encryption algorithm to obtain a second firmware version number to be verified.

[0065] It should be noted that the cloud uses a symmetric encryption algorithm and the first response to encrypt the second firmware version number, resulting in encrypted data. The first response is the encryption key.

[0066] In this embodiment of the disclosure, no specific limitation is made to the symmetric encryption algorithm. For example, the symmetric encryption algorithm is AES (Advanced Encryption Standard). Another example is DES (Data Encryption Standard).

[0067] The embodiments disclosed herein are based on a symmetric encryption algorithm, using the first response as a key to decrypt encrypted data, which can effectively ensure data security and operate efficiently.

[0068] In yet another exemplary embodiment, before sending the device identifier and the first firmware version number to the cloud, the over-the-air upgrade method provided in this disclosure may further include: sending a registration request to the cloud, the registration request carrying an identifier of a physically unclonable function chip, so that the cloud stores the correspondence between the identifier of the physically unclonable function chip and the device identifier.

[0069] In this embodiment of the disclosure, after receiving a registration request from the device, the cloud can obtain the device identifier of the device. For example, the cloud can directly obtain the device identifier of the sender (device) from the source of the registration request. Alternatively, the registration request may also carry a device identifier, which the cloud can then obtain from the registration request.

[0070] In this embodiment of the disclosure, the correspondence between the chip identifier and the device identifier of the cloud storage physically unclonable function is not specifically limited, and can be displayed in tabular form, for example.

[0071] For example, the correspondence between the identifier of a physically unclonable function chip (PUF ID) and the device identifier is shown in Table 1 below.

[0072] Table 1. Correspondence between Device Identifier and PUF ID

[0073]

[0074] It should be noted that the cloud database also stores the correspondence between PUF IDs and challenge-response pairs, as shown in Table 2 below.

[0075] Table 2. Correspondence between PUF ID and Challenge-Response Pairs

[0076]

[0077] As shown in Table 2 above, the cloud-based database stores challenge-response pairs for the PUF chip. When the cloud receives the device identifier and first firmware version number sent by the device, it can match the first response corresponding to the first firmware version number from the database. It should be noted that the first firmware version number is the challenge corresponding to the first response of the PUF chip.

[0078] It should be noted that during the registration phase before the PUF chip leaves the factory, a certain number of challenge-response pairs of physically unclonable chips are stored in a database.

[0079] For example, the cloud receives the device identifier and first firmware version number (e.g., challenge C2) sent by the device. The cloud queries Table 1 to find the PUF ID (e.g., PUF1) corresponding to the device identifier (e.g., device 1) and Table 2 to find the first response (e.g., response Res2) corresponding to the first firmware version number.

[0080] This embodiment of the disclosure stores the correspondence between the identifier of the physically unclonable function chip and the device identifier, which facilitates the establishment of a correspondence between the identifier of the physically unclonable function chip, the device identifier, and the challenge-response relationship of the PUF chip. This allows a first response to be obtained based on the device identifier and the first firmware version number, preparing for subsequent encryption of the second firmware version number using the first response, thereby improving data security.

[0081] Based on the same inventive concept, this disclosure also provides an over-the-air (OTA) upgrade method, as described in the following embodiments. Since the principle by which this method solves the problem is similar to that of the above-described method embodiments, the implementation of this method can refer to the implementation of the above-described method embodiments, and repeated details will not be elaborated further.

[0082] Figure 4 A flowchart of an over-the-air upgrade method according to another embodiment of this disclosure is shown, such as Figure 4 As shown, when applied to the cloud, the over-the-air upgrade method provided in this embodiment may include the following steps S401 to S405.

[0083] S401, receive the device identifier and first firmware version number sent by the receiving device.

[0084] S402, the first response is obtained based on the device identifier and the first firmware version number.

[0085] For example, the cloud queries the database for the first response corresponding to the device identifier and the first firmware version number.

[0086] S403 uses the first response to encrypt the second firmware version number to obtain encrypted data. The second firmware version number is the version number of the firmware upgraded from the first firmware version number.

[0087] S404: Obtain signature data based on the private key, the second firmware version number, and the firmware corresponding to the second firmware version number.

[0088] This disclosure does not specifically limit how the signature data is obtained based on the private key, the second firmware version number, and the firmware corresponding to the second firmware version number. For example, the signature data is obtained by signing the second firmware version number and the firmware corresponding to the second firmware version number using the private key.

[0089] S405 sends a public key, the firmware corresponding to the second firmware version number, encrypted data, and signature data to the device, so that the device, based on the physically non-clonable function chip, obtains a first response according to the first firmware version number, and decrypts the encrypted data according to the first response to obtain the second firmware version number to be verified. The device then verifies the signature data according to the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number. If the verification is successful, the device performs a firmware upgrade according to the firmware corresponding to the second firmware version number.

[0090] This disclosure fully leverages the non-cloning nature of the PUF chip on the device and the uniqueness of each device, eliminating the need for long-term storage of the cloud public key on the device. This reduces storage resource consumption, improves overall device performance, and eliminates the need for pre-installed identical OTA cloud public keys on the device, thus reducing management complexity. Furthermore, this disclosure eliminates the need to update the public key. Encrypted data is obtained by encrypting the second firmware version number using the first response. Signature data is then obtained based on the private key, the second firmware version number, and the corresponding firmware. This allows the device to verify the encrypted data, signature data, public key, and the first response output by the PUF chip, further enhancing the security of over-the-air (OTA) updates.

[0091] The present disclosure will now be described through several exemplary embodiments.

[0092] In an exemplary embodiment, after receiving the device identifier and the first firmware version number sent by the receiving device, the over-the-air upgrade method may further include: determining whether the firmware corresponding to the first firmware version number needs to be upgraded based on the device identifier, the first firmware version number, and the second firmware version number; if an upgrade is required, executing a first response based on the device identifier and the first firmware version number.

[0093] In this embodiment, the cloud queries the second firmware version number corresponding to the device identifier and determines whether the second firmware version number is the same as the first firmware version number. If they are different, it means that an upgrade is needed. Otherwise, if they are the same, it means that no upgrade is needed.

[0094] In this embodiment of the disclosure, the cloud can make an upgrade decision each time it receives the device identifier and the first firmware version number.

[0095] In this embodiment of the disclosure, the cloud can automatically query and compare firmware version numbers to effectively determine whether a device needs to be upgraded, avoiding unnecessary repetitive operations, saving network and storage resources, and improving system security, stability and user experience.

[0096] In another exemplary embodiment, the over-the-air upgrade method provided in this disclosure, in order to obtain signature data based on the private key, the second firmware version number, and the firmware corresponding to the second firmware version number, may include: generating a private key and a public key in response to the firmware corresponding to the first firmware version number needing to be upgraded; and obtaining signature data based on the post-quantum signature algorithm, according to the private key, the second firmware version number, and the firmware corresponding to the second firmware version number.

[0097] In this embodiment of the disclosure, the OTA cloud needs to generate a private key and a public key each time the device firmware is upgraded. That is to say, the private key and public key disclosed in this disclosure are not immutable and can be changed each time as needed.

[0098] In this embodiment of the disclosure, the post-quantum signature algorithm is a lightweight quantum-resistant signature algorithm. This embodiment does not specifically limit the type of lightweight quantum-resistant signature algorithm used. For example, a lightweight quantum-resistant signature algorithm is SLH-DSA (Stateless Hash-Based Dal Signature Algorithm), which dynamically derives keys using a pseudo-random number generator, eliminating the need for state preservation.

[0099] For example, a signature module is configured in the cloud and a signature verification module is configured on the device. The signature module and the signature verification module can use a lightweight quantum-resistant signature algorithm (such as SLH-DSA) for one-time signatures as an example to resist quantum computing attacks. However, this disclosure does not limit the signature algorithm, and the cloud and the terminal can choose their own algorithms.

[0100] It should be noted that the embodiments disclosed herein utilize the device uniqueness of PUF to ensure that when the public key, firmware, and signature result (signature data) are tampered with, they can be verified, thus preventing attackers from sending illegal firmware (such as firmware upgrade packages).

[0101] The embodiments disclosed herein do not require pre-configured OTA cloud public keys; they are generated dynamically only when needed, thus reducing the storage space occupied on the device.

[0102] The embodiments disclosed herein employ a "one-time key, one-machine key" mechanism, which is compatible with lightweight quantum-resistant digital signature algorithms that can be used for one-time signatures (i.e., a public-private key pair can only be signed once), such as the hash-based SLH-DSA algorithm standardized by the National Institute of Standards and Technology (NIST).

[0103] In yet another exemplary embodiment, the over-the-air upgrade method provided in this disclosure may include encrypting the second firmware version number using the first response to obtain encrypted data by performing an XOR operation on the first response and the second firmware version number to obtain encrypted data.

[0104] This embodiment of the disclosure uses XOR operations to encrypt data, effectively protecting the second firmware version number between the cloud and the device, ensuring the security and integrity of data exchange. Due to the reversibility of XOR operations, only the device with the correct first response and encrypted data can successfully verify the second firmware version number, reducing the risk of man-in-the-middle attacks. Furthermore, XOR operations have low computational overhead, making them suitable for efficient execution on low-power devices without affecting device performance, and they are simple to implement and have good scalability.

[0105] It should be noted that this publicly available cloud platform can also utilize a symmetric encryption algorithm to encrypt the second firmware version number using the first response as the key. The device then uses the first response output by the PUF chip to decrypt the encrypted data.

[0106] In yet another exemplary embodiment, obtaining a first response based on a device identifier and a first firmware version number in the over-the-air upgrade method provided in this disclosure may include: querying a first response corresponding to a device identifier and a first firmware version number based on a mapping relationship, wherein the mapping relationship is used to indicate the correspondence between the device identifier, the first firmware version number and the first response, and the mapping relationship is stored in a database in the cloud.

[0107] In this embodiment of the disclosure, the cloud searches for a first response corresponding to the device identifier and the first firmware version number through a mapping relationship, and then uses the first response to encrypt the second firmware version number.

[0108] It should be noted that the method for querying the first response corresponding to the device identifier and the first firmware version number has been described in the above embodiments and will not be repeated here. For example, the mapping relationship is represented by a combination of Table 1 and Table 2. Table 1 and Table 2 are used to query the first response corresponding to the device identifier and the first firmware version number.

[0109] Based on the mapping relationship, this embodiment queries the first response corresponding to the device identifier and the first firmware version number, in preparation for subsequent encryption of the second firmware version number using the first response, thereby improving data security.

[0110] Based on the same inventive concept, this disclosure also provides an over-the-air upgrade system, such as... Figure 5 As shown, the over-the-air (OTA) update system comprises a device-side component and an OTA cloud component. The device-side component includes a physically unclonable module, a first XOR module, and a signature verification module. The OTA cloud component includes a database, a second XOR module, a signature module, and a key management module.

[0111] The OTA cloud takes the first firmware version number reported by the device as the first challenge and retrieves the corresponding first response from the database. The second XOR module XORs the first response with the latest firmware version number from the OTA cloud (the second firmware version number) and sends the XOR result (encrypted data) to the device (e.g., the terminal device). Furthermore, the OTA cloud signs the latest firmware (the firmware corresponding to the second firmware version number) and the second firmware version number, and sends the signature result (signature data) to the terminal device. The signing process is defined as S = Sign(sk, Fireware||V2), that is, based on the private key sk, the Sign algorithm is used to sign the concatenation of the firmware Fireware and the latest firmware version number V2 from the OTA cloud.

[0112] The terminal device uses the current firmware version number (first firmware version number) as a challenge, calculates the first response using the PUF chip, and XORs the first response with the encrypted data to recover the second firmware version number. Subsequently, the terminal device verifies the signature data sent from the OTA cloud using a signature verification process, defined as V=Verify (pk, Fireware||V2', S), which verifies the validity of the signature data S based on the public key pk, where V2' is the recovered second firmware version number, and Fireware is the firmware corresponding to the second firmware version number.

[0113] Compared with related technologies, this disclosure has significant differences and innovations. Related technologies suffer from problems such as the need for pre-installed identical OTA cloud public keys on the device side, difficulties in updating public keys, and resource consumption limited by device space. In contrast, this disclosure fully utilizes the non-cloning nature of PUF and the uniqueness of each device to dynamically generate unique signature information (signature data) for each device. Furthermore, it eliminates the need for long-term storage of cloud public keys on the device side, dynamically generating them only when needed, thus reducing storage resource consumption.

[0114] Furthermore, this disclosure adopts a "one-time key, one-machine key" mechanism, which is compatible with a lightweight quantum-resistant digital signature algorithm that can be used for one-time signatures (i.e., a public-private key pair can only be signed once).

[0115] It should be noted that each time an upgrade package is released, the OTA cloud selects the first response corresponding to the first firmware version number, the latest firmware version number, and the new private key to ensure the uniqueness of this firmware signature. Even if a malicious device cannot reuse the upgrade package to launch attacks on other devices.

[0116] It should be noted that the OTA cloud public key does not need to be pre-installed on the device; it is generated each time it is used.

[0117] It should be noted that the signature S = Sign(sk, Fireware||V2) means that, based on the private key sk, the signature algorithm Sign is used to sign the concatenation of the firmware Fireware and the latest firmware version number V2 in the OTA cloud. The verification V = Verify(pk, Fireware||V2', S) means that, based on the public key pk, the verification algorithm Verify and the signature data S are used to verify the concatenation of the firmware Fireware and the latest version number V2' in the OTA cloud calculated based on the PUF chip and the XOR module.

[0118] In an exemplary embodiment, such as Figure 6 As shown, an over-the-air upgrade method provided in this disclosure may include the following steps S601 to S609.

[0119] S601: The device sends the device identifier and the first firmware version number to the cloud.

[0120] S602: The cloud obtains the first response based on the device identifier and the first firmware version number, and uses the first response to encrypt the second firmware version number to obtain encrypted data.

[0121] For S603, in response to the firmware version number corresponding to the first firmware version needing to be upgraded, a private key and a public key are generated in the cloud.

[0122] S604: The cloud obtains signature data based on the private key, the second firmware version number, and the firmware corresponding to the second firmware version number.

[0123] S605 sends the public key, the firmware corresponding to the second firmware version number, encrypted data, and signature data from the cloud to the device.

[0124] The S606, based on a physically unclonable function chip, receives the first response according to the first firmware version number.

[0125] S607 decrypts the encrypted data based on the first response to obtain the second firmware version number to be verified.

[0126] S608 verifies the signature data based on the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number.

[0127] S609, if the verification is successful, will perform a firmware upgrade based on the firmware corresponding to the second firmware version number.

[0128] This disclosure fully utilizes the non-clonable nature of the PUF chip and the uniqueness of the device, eliminating the need for long-term storage of the cloud public key on the device, reducing storage resource consumption, improving overall device performance, and eliminating the need for pre-installed identical OTA cloud public keys on the device, thereby reducing management complexity. Furthermore, this disclosure eliminates the need to update the public key; the encrypted data is decrypted using the first response obtained from the physically non-clonable function chip, and the signature data is verified based on the decrypted second firmware version number to be verified, the public key, and the firmware corresponding to the second firmware version number, further enhancing the security of over-the-air upgrades.

[0129] The present disclosure will be further illustrated below through two specific embodiments.

[0130] In one embodiment, the SLH-DSA algorithm standardized by the National Institute of Standards and Technology (NIST) is used as an example. Examples of lightweight, quantum-resistant signature verification modules are shown in Table 3 below.

[0131] Table 3 Examples of Lightweight Quantum-Resistant Signature Verification Modules

[0132]

[0133] An over-the-air upgrade method provided in this disclosure may include the following steps A1 to A10.

[0134] Step A1: The device reports its device identifier and first firmware version number (the device's firmware version number V1) to the OTA cloud.

[0135] Step A2: Create the firmware (the latest firmware upgrade package Fireware) corresponding to the second firmware version number in the cloud.

[0136] Step A3: The cloud selects the first response (ResX) corresponding to the first firmware version number from the database based on the device identifier and the first firmware version number.

[0137] Step A4: XOR the first response with the second firmware version number (the latest firmware version number V2 in the cloud) to obtain encrypted data (XOR result).

[0138] Step A5: The cloud calls slh_keygen() to generate a private key (sk) and a public key (pk).

[0139] Step A6: The cloud calls slh_sign() to generate signature data S = slh_sign(sk, Fireware||V2). It should be noted that the firmware corresponding to the second firmware version number and the concatenation of the second firmware version number are used as a message. This message and the private key are input into the signature module, which then outputs the signature data.

[0140] Step A7: The cloud sends encrypted data, public key, firmware corresponding to the second firmware version number, and signature data to the device.

[0141] Step A8: The device uses the PUF chip to calculate the first response corresponding to the first firmware version number.

[0142] In step A9, the device performs an XOR operation between the first response and the encrypted data to calculate the second firmware version number to be verified.

[0143] In step A10, the device calls `slh_verify()` to verify the signature data. It should be noted that the second firmware version number to be verified and the corresponding firmware are used as the message. The message, public key, and signature data are input into the signature verification module, and the verification result is output. If the verification result is successful, the firmware is upgraded. If the verification result fails, the upgrade is abandoned.

[0144] It should be noted that the lightweight quantum-resistant signature verification module may include a signature module, a verification module, and a key management module.

[0145] The PUF technology in related technologies is mainly used in the field of terminal identity authentication. This disclosure utilizes the non-cloning and device-specific uniqueness of PUF to generate a unique firmware upgrade package signature for each device, avoiding the risk of signature copying and tampering. Furthermore, this disclosure eliminates the need to pre-install identical cloud public keys on the device, solving the problem of difficulty in updating stolen private keys. Simultaneously, since the firmware verification key does not need to be stored and is dynamically generated only when needed, it significantly reduces the storage space occupied by resource-constrained IoT devices, improving the security and efficiency of firmware upgrades.

[0146] In another embodiment, such as Figure 7 As shown, the over-the-air upgrade method provided in this disclosure may include the following S701 to S717.

[0147] S701 stores the challenge-response pairs of the PUF chip in a database in the cloud.

[0148] S702, the device is equipped with a PUF chip and the PUF identifier is registered to the cloud. The cloud stores the correspondence between the device identifier and the identifier of the physically unclonable function chip.

[0149] S703, create the firmware corresponding to the second firmware version number (the latest firmware upgrade package Fireware) in the cloud.

[0150] S704: The device sends the device identifier and the first firmware version number to the cloud.

[0151] S705 determines whether an upgrade is needed based on the device identifier and the first firmware version number. If an upgrade is needed, proceed to S706; otherwise, the process ends.

[0152] S706: Based on the device identifier, the cloud uses the first firmware version number as the first challenge and selects the corresponding first response from the database.

[0153] In the S707, the cloud performs an XOR operation between the first response and the second firmware version number to calculate the encrypted data.

[0154] S708 uses the cloud-based key management module to generate public and private keys.

[0155] S709, the cloud calls the signature module to generate signature data. For example, this disclosure generates signature data based on the private key, the second firmware version number, and the firmware corresponding to the second firmware version number.

[0156] S710, the cloud initiates an upgrade request to the device.

[0157] The S711 sends encrypted data, public key, firmware corresponding to the second firmware version number, and signature data from the cloud to the device.

[0158] The S712 device receives encrypted data, public key, firmware corresponding to the second firmware version number, and signature data through a communication protocol.

[0159] S713: The device uses the PUF chip to calculate the first response corresponding to the first firmware version number.

[0160] S714 XORs the first response with the encrypted data to calculate the second firmware version number to be verified.

[0161] S715, the device verifies the signature data. For example, this disclosure verifies the signature data based on the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number.

[0162] S716 checks if the verification passed. If the verification passed, proceed to S717. If the verification failed, the process ends.

[0163] S717, firmware upgrade on the device side. Execute S704.

[0164] Related technologies suffer from problems such as the need for devices to pre-install identical OTA cloud public keys, difficulties in updating public keys, and the space consumption of resource-constrained devices. This disclosure fully utilizes the non-cloning nature of PUFs and the uniqueness of each device to dynamically generate immutable signature information for each device. Furthermore, it eliminates the need for long-term storage of cloud public keys on the device, generating them dynamically only when needed, thus reducing storage resource consumption. In addition, this disclosure is compatible with lightweight quantum-resistant digital signature algorithms that support one-time signatures (i.e., a public-private key pair can only be used for one signature).

[0165] It should be noted that the acquisition, storage, use, and processing of data in this disclosed technical solution comply with the relevant provisions of national laws and regulations. The various types of data, such as personal identity data, operational data, and behavioral data related to individuals, customers, and groups, obtained in the embodiments of this disclosure have all been authorized.

[0166] Based on the same inventive concept, this disclosure also provides an over-the-air upgrade device, as described in the following embodiments. Since the principle by which this device embodiment solves the problem is similar to that of the above-described method embodiments, the implementation of this device embodiment can refer to the implementation of the above-described method embodiments, and repeated details will not be elaborated further.

[0167] Figure 8 This diagram illustrates an over-the-air upgrade device according to an embodiment of the present disclosure, such as... Figure 8 As shown, the device is applied to the device side, which is equipped with a physically unclonable function chip. The device includes: a first sending module 81, a first receiving module 82, a first determining module 83, a decryption module 84, a verification module 85, and an upgrade module 86. The first sending module 81 can be used to send a device identifier and a first firmware version number to the cloud, so that the cloud can obtain a first response based on the device identifier and the first firmware version number, and use the first response to encrypt the second firmware version number to obtain encrypted data. Based on the private key, the second firmware version number, and the firmware corresponding to the second firmware version number, signature data is obtained. The second firmware version number is the version number of the firmware upgraded from the firmware corresponding to the first firmware version number. The first receiving module 82 can be used to receive the public key, the firmware corresponding to the second firmware version number, the encrypted data, and the signature data sent by the cloud. The first determining module 83 can be used to obtain a first response based on the first firmware version number based on the physically unclonable function chip. The decryption module 84 can be used to decrypt the encrypted data based on the first response to obtain the second firmware version number to be verified. The verification module 85 can be used to verify the signature data based on the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number. The upgrade module 86 can be used to upgrade the firmware based on the firmware corresponding to the second firmware version number if the verification is successful.

[0168] In one embodiment, the decryption module 84 can also perform an XOR operation on the first response and the encrypted data to obtain the second firmware version number to be verified.

[0169] In one embodiment, before sending the device identifier and the first firmware version number to the cloud, the first sending module 81 can also be used to send a registration request to the cloud, the registration request carrying the identifier of the physically unclonable function chip, so that the cloud stores the correspondence between the identifier of the physically unclonable function chip and the device identifier.

[0170] The over-the-air (OTA) upgrade device disclosed in this embodiment fully utilizes the non-clonable nature of the PUF chip and the uniqueness of the device itself. It eliminates the need for long-term storage of the cloud public key on the device, reducing storage resource consumption and improving overall device performance. Furthermore, it eliminates the need for pre-installed identical OTA cloud public keys on the device, thus reducing management complexity. In addition, this disclosure eliminates the need to update the public key. The encrypted data is decrypted using the first response obtained from the physically non-clonable function chip, and the signature data is verified based on the decrypted second firmware version number to be verified, the public key, and the firmware corresponding to the second firmware version number, further enhancing the security of OTA upgrades.

[0171] Figure 9 This diagram illustrates an over-the-air upgrade device according to an embodiment of the present disclosure, such as... Figure 9 As shown, this device, applied in the cloud, includes: a second receiving module 91, a second determining module 92, an encryption module 93, a signing module 94, and a second sending module 95. The second receiving module 91 receives a device identifier and a first firmware version number sent by the device. The second determining module 92 obtains a first response based on the device identifier and the first firmware version number. The encryption module 93 encrypts the second firmware version number using the first response to obtain encrypted data, where the second firmware version number is the version number of the upgraded firmware corresponding to the first firmware version number. The signing module 94 obtains signature data based on a private key, the second firmware version number, and the corresponding firmware. The second sending module 95 sends a public key, the firmware corresponding to the second firmware version number, the encrypted data, and the signature data to the device. This allows the device to obtain the first response based on the first firmware version number using a physically non-cloning function chip, and decrypt the encrypted data based on the first response to obtain the second firmware version number to be verified. The device then verifies the signature data using the public key, the second firmware version number to be verified, and the corresponding firmware. If the verification is successful, the device performs a firmware upgrade based on the firmware corresponding to the second firmware version number.

[0172] In one embodiment, after receiving the device identifier and the first firmware version number sent by the receiving device, the second receiving module 91 can also be used to determine whether the firmware corresponding to the first firmware version number needs to be upgraded based on the device identifier, the first firmware version number and the second firmware version number; if an upgrade is required, execute to obtain a first response based on the device identifier and the first firmware version number.

[0173] In one embodiment, the signature module 94 can also be used to generate a private key and a public key in response to the firmware corresponding to the first firmware version number needing to be upgraded; and to obtain signature data based on the post-quantum signature algorithm, according to the private key, the second firmware version number, and the firmware corresponding to the second firmware version number.

[0174] In one embodiment, the encryption module 93 can also be used to perform an XOR operation on the first response and the second firmware version number to obtain encrypted data.

[0175] In one embodiment, the second determining module 92 can also be used to query the first response corresponding to the device identifier and the first firmware version number based on the mapping relationship. The mapping relationship is used to indicate the correspondence between the device identifier, the first firmware version number and the first response. The mapping relationship is stored in a database in the cloud.

[0176] The over-the-air (OTA) upgrade device disclosed in this embodiment fully utilizes the non-clonable nature of the PUF chip and the uniqueness of the device itself. It eliminates the need for long-term storage of the cloud public key on the device, reducing storage resource consumption and improving overall device performance. Furthermore, it eliminates the need for pre-installed identical OTA cloud public keys on the device, thus reducing management complexity. In addition, this disclosure eliminates the need to update the public key. The encrypted data is decrypted using the first response obtained from the physically non-clonable function chip, and the signature data is verified based on the decrypted second firmware version number to be verified, the public key, and the firmware corresponding to the second firmware version number, further enhancing the security of OTA upgrades.

[0177] It should be noted that the examples and application scenarios implemented by the modules in the above device embodiments and the corresponding steps in the method embodiments are the same, but are not limited to the content disclosed in the above method embodiments. It should also be noted that the above modules, as part of the device, can be executed in a computer system such as a set of computer-executable instructions.

[0178] Those skilled in the art will understand that various aspects of this disclosure can be implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, which can be collectively referred to herein as a "circuit", "module" or "system".

[0179] Based on the same inventive concept, this disclosure also provides an electronic device, which includes: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the control upgrade method described above by executing the executable instructions. Since the principle by which this electronic device solves the problem is similar to that of the above method embodiments, the implementation of this electronic device embodiment can refer to the implementation of the above method embodiments, and repeated details will not be described again.

[0180] The following reference Figure 10 To describe an electronic device 1000 according to such an embodiment of the present disclosure. Figure 10 The electronic device 1000 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0181] like Figure 10 As shown, the electronic device 1000 is manifested in the form of a general-purpose computing device. The components of the electronic device 1000 may include, but are not limited to: at least one processing unit 1010, at least one storage unit 1020, and a bus 1030 connecting different system components (including storage unit 1020 and processing unit 1010).

[0182] The storage unit stores program code that can be executed by the processing unit 1010, causing the processing unit 1010 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. For example, the processing unit 1010 can perform the following steps of the above method embodiment: sending a device identifier and a first firmware version number to the cloud, so that the cloud receives a first response based on the device identifier and the first firmware version number, and encrypting a second firmware version number using the first response to obtain encrypted data; obtaining signature data based on a private key, the second firmware version number, and the firmware corresponding to the second firmware version number, wherein the second firmware version number is the version number of the firmware upgraded from the firmware corresponding to the first firmware version number; receiving a public key, the firmware corresponding to the second firmware version number, the encrypted data, and the signature data sent by the cloud; obtaining a first response based on the first firmware version number using a physically non-cloning function chip; decrypting the encrypted data based on the first response to obtain a second firmware version number to be verified; verifying the signature data based on the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number; and, if the verification is successful, upgrading the firmware based on the firmware corresponding to the second firmware version number.

[0183] Storage unit 1020 may include readable media in the form of volatile storage units, such as random access memory (RAM) 10201 and / or cache memory 10202, and may further include read-only memory (ROM) 10203.

[0184] Storage unit 1020 may also include a program / utility 10204 having a set (at least one) program module 10205, such program module 10205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0185] Bus 1030 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.

[0186] Electronic device 1000 can also communicate with one or more external devices 1040 (e.g., keyboard, pointing device, Bluetooth device, etc.), one or more devices that enable a user to interact with electronic device 1000, and / or any device that enables electronic device 1000 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 1050. Furthermore, electronic device 1000 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 1060. As shown, network adapter 1060 communicates with other modules of electronic device 1000 via bus 1030. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 1000, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0187] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0188] Based on the same inventive concept, in the disclosed exemplary embodiments, a computer-readable storage medium is also provided, which may be a readable signal medium or a readable storage medium. The computer-readable storage medium stores a program product capable of implementing the methods described above.

[0189] More specific examples of computer-readable storage media in this disclosure may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0190] In this disclosure, a computer-readable storage medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting a program for use by or in connection with an instruction execution system, apparatus, or device.

[0191] Optionally, the program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0192] In practical implementation, program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0193] Based on the same inventive concept, this disclosure also provides a computer program product, including a computer program or instructions, which, when executed by a processor, implements the over-the-air update method of any one of the above method embodiments. Since the principle by which this computer program product embodiment solves the problem is similar to that of the above method embodiments, the implementation of this computer program product embodiment can refer to the implementation of the above method embodiments, and repeated details will not be elaborated further.

[0194] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0195] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0196] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0197] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

Claims

1. An over-the-air upgrade method, characterized in that, Applied to the device side, the device side is equipped with a physically unclonable function chip, including: Send a device identifier and a first firmware version number to the cloud so that the cloud receives a first response based on the device identifier and the first firmware version number, and uses the first response to encrypt the second firmware version number to obtain encrypted data. Based on the private key, the second firmware version number and the firmware corresponding to the second firmware version number, obtain signature data. The second firmware version number is the version number of the firmware upgraded from the firmware corresponding to the first firmware version number. Receive the public key sent by the cloud, the firmware corresponding to the second firmware version number, the encrypted data, and the signature data; Based on the physically unclonable function chip, the first response is obtained according to the first firmware version number; The encrypted data is decrypted based on the first response to obtain the second firmware version number to be verified; The signature data is verified based on the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number; If the verification is successful, the firmware will be upgraded according to the firmware corresponding to the second firmware version number.

2. The over-the-air upgrade method according to claim 1, characterized in that, The step of decrypting the encrypted data based on the first response to obtain the second firmware version number to be verified includes: Perform an XOR operation on the first response and the encrypted data to obtain the second firmware version number to be verified.

3. The over-the-air upgrade method according to claim 1, characterized in that, Before sending the device identifier and first firmware version number to the cloud, the method further includes: A registration request is sent to the cloud, the registration request carrying the identifier of the physically unclonable function chip, so that the cloud stores the correspondence between the identifier of the physically unclonable function chip and the device identifier.

4. An over-the-air upgrade method, characterized in that, Applied to the cloud, including: The receiving device sends the device identifier and the first firmware version number; A first response is obtained based on the device identifier and the first firmware version number; The first response is used to encrypt the second firmware version number to obtain encrypted data. The second firmware version number is the version number of the firmware upgraded from the first firmware version number. The signature data is obtained based on the private key, the second firmware version number, and the firmware corresponding to the second firmware version number; The device sends a public key, the firmware corresponding to the second firmware version number, the encrypted data, and the signature data to the device, so that the device, based on a physically non-clonable function chip, obtains the first response according to the first firmware version number, and decrypts the encrypted data according to the first response to obtain the second firmware version number to be verified. The device then verifies the signature data according to the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number. If the verification is successful, the device performs a firmware upgrade according to the firmware corresponding to the second firmware version number.

5. The over-the-air upgrade method according to claim 4, characterized in that, After the device identifier and first firmware version number sent by the receiving device, the method further includes: Based on the device identifier, the first firmware version number, and the second firmware version number, determine whether the firmware corresponding to the first firmware version number needs to be upgraded; If an upgrade is required, the process of obtaining a first response based on the device identifier and the first firmware version number is executed.

6. The over-the-air upgrade method according to claim 5, characterized in that, The step of obtaining signature data based on the private key, the second firmware version number, and the firmware corresponding to the second firmware version number includes: In response to the firmware version number corresponding to the first firmware version number requiring an upgrade, a private key and a public key are generated. Based on the post-quantum signature algorithm, the signature data is obtained according to the private key, the second firmware version number, and the firmware corresponding to the second firmware version number.

7. The over-the-air upgrade method according to claim 4, characterized in that, The step of encrypting the second firmware version number using the first response to obtain encrypted data includes: The encrypted data is obtained by performing an XOR operation on the first response and the second firmware version number.

8. The over-the-air upgrade method according to claim 4, characterized in that, The step of obtaining the first response based on the device identifier and the first firmware version number includes: Based on the mapping relationship, a first response corresponding to the device identifier and the first firmware version number is queried. The mapping relationship is used to indicate the correspondence between the device identifier, the first firmware version number and the first response. The mapping relationship is stored in the database in the cloud.

9. An over-the-air upgrade device, characterized in that, Applied to the device side, the device side is equipped with a physically unclonable function chip, including: The first sending module is used to send a device identifier and a first firmware version number to the cloud so that the cloud can obtain a first response based on the device identifier and the first firmware version number, and use the first response to encrypt the second firmware version number to obtain encrypted data. Based on the private key, the second firmware version number and the firmware corresponding to the second firmware version number, signature data is obtained. The second firmware version number is the version number of the firmware upgraded from the firmware corresponding to the first firmware version number. The first receiving module is used to receive the public key sent by the cloud, the firmware corresponding to the second firmware version number, the encrypted data, and the signature data. The first determining module is used to obtain the first response based on the physically unclonable function chip and the first firmware version number; The decryption module is used to decrypt the encrypted data according to the first response to obtain the second firmware version number to be verified; The verification module is used to verify the signature data based on the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number; The upgrade module is used to upgrade the firmware according to the firmware corresponding to the second firmware version number if the verification is successful.

10. An over-the-air upgrade device, characterized in that, Applied to the cloud, including: The second receiving module is used to receive the device identifier and the first firmware version number sent by the device. The second determining module is used to obtain a first response based on the device identifier and the first firmware version number; An encryption module is used to encrypt the second firmware version number using the first response to obtain encrypted data, wherein the second firmware version number is the version number of the firmware upgraded from the first firmware version number. The signature module is used to obtain signature data based on the private key, the second firmware version number, and the firmware corresponding to the second firmware version number; The second sending module is used to send a public key, the firmware corresponding to the second firmware version number, the encrypted data, and the signature data to the device, so that the device, based on a physically non-cloning function chip, obtains the first response according to the first firmware version number, decrypts the encrypted data according to the first response to obtain the second firmware version number to be verified, verifies the signature data according to the public key, the second firmware version number to be verified, and the firmware corresponding to the second firmware version number, and performs a firmware upgrade according to the firmware corresponding to the second firmware version number if the verification is successful.

11. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the over-the-air upgrade method according to any one of claims 1 to 8 by executing the executable instructions.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the over-the-air upgrade method according to any one of claims 1 to 8.

13. A computer program product comprising: A computer program or instruction, characterized in that, when executed by a processor, the computer program or instruction implements the over-the-air upgrade method according to any one of claims 1 to 8.

Images