Firmware security updating method and device for Internet of Things equipment
By using segmented downloading and dynamic session keys, the security and efficiency issues in the firmware update process of IoT devices are solved, efficient and secure firmware updates are achieved, and the user experience is improved.
Patent Information
- Application Number
- CN202511158108.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-19
- Publication Date
- 2025-09-16
AI Technical Summary
The firmware update process of existing IoT devices suffers from insufficient security and lacks efficient download capabilities, resulting in a lengthy update process, high resource consumption, and poor user experience. Especially in wireless network environments, unstable network connections lead to frequent network reconstruction and key negotiation, which increases the pressure on the TSM platform, prolongs the update time, and reduces the user experience.
A fragmented download mechanism is adopted, with encrypted caching and fragmented processing performed through a proxy server. Combined with dynamic session keys and IP address rotation, an end-to-end encrypted trust chain and hardware-level protection are implemented to ensure the security and efficiency of firmware updates.
It achieves the security and efficiency of firmware updates, reduces resource consumption, improves user experience, maintains stable data transmission through fragmented downloading and edge caching, and avoids the negative impact of frequent network reconstruction and key negotiation.
Smart Images

Figure CN120653283A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of software technology, and in particular to a method and apparatus for securely updating firmware of an Internet of Things device. Background Art
[0002] In the Internet of Things (IoT), firmware updates are a key means of fixing vulnerabilities, enhancing functionality, and improving device security. However, existing firmware update mechanisms for IoT devices, particularly when it comes to updating security chips with high security requirements, suffer from significant security and efficiency deficiencies. The current, commonly used approach involves pushing encrypted firmware update packages to the device's security chip via a Trusted Service Management (TSM) platform.
[0003] However, IoT devices and their associated local network devices typically rely on wireless networks for connectivity, which is unstable. This makes it difficult to maintain a stable, high-speed, and continuous data transmission channel between the TSM platform and the security chip. Furthermore, network connectivity is prone to unexpected interruptions during firmware updates. Once this occurs, to ensure the security of subsequent data transmission, the TSM platform must re-establish a network connection session with the security chip and re-establish encryption keys based on a new negotiation process before continuing to transmit the firmware update package (or retransmit the entire update package). This frequent network reconnection and key negotiation mechanism has multiple negative consequences, including increased pressure on the TSM platform, prolonged firmware update time, and a degraded user experience.
[0004] Therefore, the current firmware update process of IoT devices, especially in wireless network environments, not only has the hidden danger of insufficient security, but also lacks efficient download capabilities, resulting in a lengthy update process, high resource consumption, and poor user experience, becoming a key bottleneck restricting the security operation and maintenance efficiency of IoT devices. Summary of the Invention
[0005] The present application provides a method and apparatus for securely updating firmware for IoT devices, which can address the current issues of insufficient security and lack of efficient download capabilities during firmware updates for IoT devices, resulting in a lengthy update process, high resource consumption, and poor user experience.
[0006] In order to achieve the above objectives, this application adopts the following technical solutions: In a first aspect, the present application provides a firmware security update method for an Internet of Things device, which is applied to a main controller of the Internet of Things device, and the method includes: sending a firmware update request to a proxy server, the firmware update request is used to obtain a firmware update package for the Internet of Things device; wherein the firmware update request includes an identifier of the Internet of Things device and a version number of the firmware; receiving shard metadata from the proxy server; wherein the shard metadata includes: the total number of shards of the firmware update package, a list of shard hash values, an Internet Protocol IP address of the proxy server, and a dynamic session key, and the dynamic session key is used to encrypt and decrypt firmware update package shards; sending shard requests to the proxy server in sequence, the shard requests are used to obtain a target number of firmware update package shards; receiving a target number of encrypted firmware update package shards from the proxy server, and forwarding the encrypted firmware update package shards to a security chip.
[0007] In one possible implementation, the fragment request includes timestamp information and a random number, and the random number is used to defend against replay attacks; each time after receiving a target number of encrypted firmware update package fragments from a proxy server, the method also includes: receiving an IP address change message from the proxy server, and the IP address change message is used to indicate the changed IP address of the proxy server after sending the target number of encrypted firmware update package fragments; according to the IP address change message, continue to send fragment requests to the proxy server.
[0008] In a possible implementation, the method further includes: forwarding the dynamic session key and the shard hash value list to the security chip.
[0009] In the second aspect, the present application provides a firmware security update method for an Internet of Things device, which is characterized in that it is applied to a security chip of the Internet of Things device, and the method includes: receiving encrypted firmware update package fragments from a main controller; performing security verification on the encrypted firmware update package fragments, and storing the encrypted firmware update package fragments in a secure area if the security verification passes; determining the firmware update package based on all received encrypted firmware update package fragments, and verifying the firmware update package based on the developer public key obtained from the certificate authority CA; and updating the firmware of the Internet of Things device according to the firmware update package if the firmware update package verification passes.
[0010] In one possible implementation, the method also includes: receiving a dynamic session key and a fragment hash value list from a main controller; performing security verification on the encrypted firmware update package fragments, specifically including: calculating the hash value of the encrypted firmware update package fragments and comparing it with the fragment hash value list; determining the firmware update package based on all received encrypted firmware update package fragments, specifically including: decrypting all encrypted firmware update package fragments based on the dynamic session key; splicing the decrypted encrypted firmware update package fragments to determine the firmware update package.
[0011] In a third aspect, the present application provides a firmware security update method for an Internet of Things device, which is characterized in that it is applied to a proxy server, and the method includes: receiving a firmware update package from a certificate authority CA, and caching the firmware update package to an encrypted storage area; sharding the firmware update package to obtain firmware update package shards; receiving a firmware update request from a main controller, the firmware update request is used to obtain the firmware update package of the Internet of Things device; wherein the firmware update request includes an identifier of the Internet of Things device and a version number of the firmware; sending shard metadata to the main controller; wherein the shard metadata includes: the total number of shards of the firmware update package, a list of shard hash values, an Internet Protocol IP address of the proxy server, and a dynamic session key, the dynamic session key is used to encrypt and decrypt firmware update package shards; receiving shard requests sent sequentially from the main controller, the shard requests are used to obtain a target number of firmware update package shards; and sending encrypted firmware update package shards to the main controller.
[0012] In a possible implementation, the method further includes: sending an IP address change message to the main controller, where the IP address change message is used to indicate the changed IP address of the proxy server after sending the target number of encrypted firmware update package fragments.
[0013] In a fourth aspect, the present application provides a firmware update device for an Internet of Things device, characterized in that it is applied to a main controller of the Internet of Things device, and the device includes: a sending unit and a receiving unit; the sending unit is used to send a firmware update request to a proxy server, and the firmware update request is used to obtain a firmware update package for the Internet of Things device; wherein the firmware update request includes an identifier of the Internet of Things device and a version number of the firmware; the receiving unit is used to receive shard metadata from the proxy server; wherein the shard metadata includes: the total number of shards of the firmware update package, a list of shard hash values, an Internet Protocol IP address of the proxy server, and a dynamic session key, and the dynamic session key is used to encrypt and decrypt firmware update package shards; the sending unit is also used to send shard requests to the proxy server in sequence, and the shard requests are used to obtain a target number of firmware update package shards; the receiving unit is also used to receive a target number of encrypted firmware update package shards from the proxy server, and forward the encrypted firmware update package shards to the security chip.
[0014] In one possible implementation, the receiving unit is also used to receive an IP address change message from the proxy server, where the IP address change message is used to indicate the changed IP address of the proxy server after sending a target number of encrypted firmware update package fragments; the sending unit is also used to continue sending fragment requests to the proxy server based on the IP address change message.
[0015] In a possible implementation, the sending unit is further configured to forward the dynamic session key and the shard hash value list to the security chip.
[0016] In a fifth aspect, the present application provides a firmware update device for an Internet of Things device, characterized in that it is applied to a security chip of the Internet of Things device, and the device includes: a receiving unit and a processing unit; the receiving unit is used to receive encrypted firmware update package fragments from a main controller; the processing unit is used to perform security verification on the encrypted firmware update package fragments, and if the security verification passes, the encrypted firmware update package fragments are stored in a secure area; the processing unit is also used to determine the firmware update package based on all the received encrypted firmware update package fragments, and verify the firmware update package based on the developer public key obtained from the certificate authority CA; the processing unit is also used to update the firmware of the Internet of Things device according to the firmware update package if the firmware update package verification passes.
[0017] In one possible implementation, the receiving unit is also used to receive a dynamic session key and a fragment hash value list from the main controller; the processing unit is also used to calculate the hash value of the encrypted firmware update package fragment and compare it with the fragment hash value list; the processing unit is also used to decrypt all encrypted firmware update package fragments based on the dynamic session key; the processing unit is also used to splice the decrypted encrypted firmware update package fragments to determine the firmware update package.
[0018] In a sixth aspect, the present application provides a firmware update device for an Internet of Things device, characterized in that it is applied to a proxy server, and the device includes: a receiving unit, a processing unit and a sending unit; the receiving unit is used to receive a firmware update package from a certificate authority CA and cache the firmware update package to an encrypted storage area; the processing unit is used to fragment the firmware update package to obtain firmware update package fragments; the receiving unit is also used to receive a firmware update request from a main controller, and the firmware update request is used to obtain the firmware update package of the Internet of Things device; wherein the firmware update request includes an identifier of the Internet of Things device and a version number of the firmware; the sending unit is used to send fragment metadata to the main controller; wherein the fragment metadata includes: the total number of fragments of the firmware update package, a list of fragment hash values, an Internet Protocol IP address of the proxy server, and a dynamic session key, and the dynamic session key is used to encrypt and decrypt the firmware update package fragments; the receiving unit is also used to receive fragment requests sent in sequence from the main controller, and the fragment requests are used to obtain a target number of firmware update package fragments; the sending unit is also used to send encrypted firmware update package fragments to the main controller.
[0019] In a possible implementation, the sending unit is further configured to send an IP address change message to the main controller, where the IP address change message is used to indicate the changed IP address of the proxy server after sending a target number of encrypted firmware update package fragments.
[0020] In the seventh aspect, the present application provides a computer-readable storage medium storing one or more programs, wherein the one or more programs include instructions, which, when executed by the electronic device of the present application, enable the electronic device to execute the firmware security update method of the Internet of Things device as described in the first to third aspects and any possible implementation of the first to third aspects.
[0021] In an eighth aspect, the present application provides an electronic device comprising: a processor and a memory; wherein the memory is used to store one or more programs, and the one or more programs include computer-executable instructions. When the electronic device is running, the processor executes the computer-executable instructions stored in the memory to enable the electronic device to execute the firmware security update method of the Internet of Things device as described in the first to third aspects and any possible implementation method of the first to third aspects.
[0022] In the ninth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the electronic device of the present application to execute the firmware security update method for an IoT device as described in the first to third aspects and any possible implementation of the first to third aspects.
[0023] In a tenth aspect, the present application provides a chip system, which is applied to a firmware security update device for an Internet of Things device; the chip system includes one or more interface circuits and one or more processors. The interface circuit and the processor are interconnected via a line; the interface circuit is used to receive a signal from the memory of the firmware security update device of the Internet of Things device and send the signal to the processor, wherein the signal includes a computer instruction stored in the memory. When the processor executes the computer instruction, the firmware security update device of the Internet of Things device performs the firmware security update method for the Internet of Things device as described in the first to third aspects and any possible implementation of the first to third aspects.
[0024] Based on the above technical solution, when performing firmware updates, the embodiment of the present application can implement an end-to-end encrypted trust chain based on the process of developer HSM signature → CA certificate verification → security chip signature verification. It also implements a dynamic defense mechanism by rotating the IP address of the proxy server and the dynamic session key, and implements hardware-level protection through decryption and secure zone storage of the security chip, thereby making the firmware update anti-eavesdropping and anti-tampering throughout the process. While ensuring the security of the firmware update, it maintains efficient download capabilities through fragmented downloading and edge caching, reduces resource consumption for firmware updates, and thus streamlines the firmware security update process, reduces resource consumption, and ultimately improves the user experience. BRIEF DESCRIPTION OF THE DRAWINGS
[0025] Figure 1A schematic diagram of the architecture of a firmware security update system for an IoT device provided in an embodiment of the present application; Figure 2 A flowchart of a firmware security update method for an IoT device provided in an embodiment of the present application; Figure 3 A schematic diagram of the structure of a firmware security update device for an Internet of Things device provided in an embodiment of the present application; Figure 4 A schematic diagram of the structure of another device for securely updating firmware for an IoT device provided in an embodiment of the present application; Figure 5 A schematic diagram of the structure of another device for securely updating firmware for an IoT device provided in an embodiment of the present application; Figure 6 A schematic diagram of the structure of another device for securely updating firmware for an IoT device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0026] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0027] In this document, the character " / " generally indicates an "or" relationship between the preceding and following objects. For example, A / B can be understood as either A or B.
[0028] The terms "first" and "second" in the specification and claims of this application are used to distinguish different objects, rather than to describe a specific order of objects. For example, the terms "first edge service node" and "second edge service node" are used to distinguish different edge service nodes, rather than to describe the characteristic order of edge service nodes.
[0029] Furthermore, the terms "including," "having," and any variations thereof, as used in the description of this application are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or units is not limited to the listed steps or units, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to the process, method, product, or apparatus.
[0030] Additionally, in the embodiments of this application, words such as "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described in this application as "exemplary" or "for example" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplarily" or "for example" is intended to present concepts in a concrete manner.
[0031] Currently, in the Internet of Things (IoT), firmware updates are a key means of fixing vulnerabilities, enhancing functionality, and improving device security. However, existing firmware update mechanisms for IoT devices, especially when it comes to updating security chips with high security requirements, suffer from significant security and efficiency deficiencies.
[0032] The current common approach is to push encrypted firmware update packages to the device's security chip through a Trusted Service Management (TSM) platform. However, this process faces significant challenges: IoT devices and their associated local network devices typically rely on wireless networks for connectivity. This inherently unstable connection, characterized by signal fluctuations, interference, bandwidth limitations, and intermittent connection interruptions, makes it difficult to maintain a stable, high-speed, and continuous data transmission channel between the TSM platform and the security chip.
[0033] This network instability creates a host of issues: During firmware update transmissions, network connections can easily be unexpectedly interrupted. Once this occurs, to ensure the security of subsequent data transmission, the TSM platform must reestablish a network connection session with the security chip and re-establish encryption keys based on a new negotiation process before continuing to transmit the firmware update package (or retransmitting the entire update package). This frequent network reconnection and key negotiation mechanism has multiple negative consequences: (1) Increased pressure on the TSM platform: Handling frequent connection establishment, key negotiation, and session management significantly increases the computing, communication, and resource overhead of the TSM platform.
[0034] (2) Extended update time: Each interruption and reestablishment of the connection / key causes significant delay. For large firmware update packages, multiple interruptions can cause the overall update time to increase exponentially.
[0035] (3) Reduced user experience: Long update times may cause the device to be unavailable for a long time or have limited functions, affecting normal user use and reducing user satisfaction.
[0036] (4) Limiting technical implementation: This model, which relies on a stable, long-term connection, naturally hinders the effective implementation of the segmented download (breakpoint-resume) mechanism. This is because each breakpoint recovery requires not only retransmitting the data, but also reestablishing the security context (connection and key). The overhead is almost equivalent to restarting the entire update process, which makes the advantages of segmented download in efficiency and security disappear.
[0037] Therefore, the current firmware update process of IoT devices, especially in wireless network environments, not only has the hidden danger of insufficient security, but also lacks efficient download capabilities, resulting in a lengthy update process, high resource consumption, and poor user experience, becoming a key bottleneck restricting the security operation and maintenance efficiency of IoT devices.
[0038] In view of this, in order to solve the problems existing in the above-mentioned prior art, the present application proposes a firmware security update method and device for IoT devices, which can solve the problems of insufficient security and lack of efficient download capabilities in the firmware update process of IoT devices at this stage, resulting in a lengthy update process, high resource consumption, and poor user experience.
[0039] The following describes in detail the firmware security update method for IoT devices provided by this application in conjunction with the accompanying drawings: For example, Figure 1 As shown, Figure 1 This application provides an architectural diagram of a firmware security update system for an IoT device. The firmware security update system 100 for the IoT device includes: a developer terminal 101, a certificate authority (CA) 102, a proxy server 103, a main controller 104, and a security chip 105.
[0040] The developer side 101 refers to the entity or system responsible for firmware development, signing, and initial distribution, which is usually a dedicated environment of the manufacturer of the IoT device or the firmware development team.
[0041] Developer 101: When updating firmware for IoT devices, the core responsibilities typically include the following four parts: (1) Firmware development and testing, specifically including code development (writing device firmware, such as embedded code based on FreeRTOS) and security testing (performing static analysis, such as Coverity, and dynamic testing, such as hardware fuzz testing).
[0042] (2) Secure signature, specifically including private key management: using HSM (such as YubiHSM 2) to generate and store ECDSA private keys, which never leave the HSM; implementing multi-factor authentication (such as smart card + biometrics) to access signature permissions; firmware signing, etc.
[0043] (3) Certificate and metadata generation
[0044] A certificate, specifically a developer certificate. For example, apply for an X.509 certificate (including a public key) from a CA for device-side signature verification. The certificate must clearly identify the developer and device type (e.g., using an OID extension field). Metadata generation, such as a JSON file containing the firmware version, dependencies, and hash values, is also required.
[0045] (4) Submit the firmware update package to the CA, including: Secure transmission: upload the signed firmware package to the CA server via SFTP or mutual TLS; metadata association ensures that the CA binds the firmware to the developer certificate and device model whitelist.
[0046] The above describes the functions of the developer client 101. In the embodiment of the present application, after developing the firmware update package, the developer client 101 uses the developer HSM and the developer's private signature key to sign the firmware update package to prevent tampering during transmission. Accordingly, after obtaining the firmware update package, the IoT device uses the developer's public key to verify it. The developer's public key can be transmitted to the IoT device by CA 102.
[0047] CA102, or the Certificate Authority, is the core security framework for IoT device firmware updates. It issues digital certificates to developers, proxy servers, and devices, binding their public keys to their identities (e.g., developer ID, device model).
[0048] For example, in the embodiment of the present application, CA 102 receives the firmware update package submitted by the developer terminal 101 and synchronizes it to the proxy server 103. CA 102 can also be responsible for sending the developer's public key to the IoT device.
[0049] The proxy server 103 is usually deployed in the cloud, close to the CA 102 or the firmware storage server. In this application, the proxy server 103 can receive the firmware update package from the CA 102 and encrypt and cache it in the encrypted storage area.
[0050] In one possible implementation, the proxy server 103 encrypts the firmware update package using the AES-256 encryption algorithm, and caches the encrypted firmware update package in an encrypted storage area using edge node technology.
[0051] It is understandable that when the proxy server 103 needs to send a firmware update package to the IoT device, the proxy server 103 will pull the encrypted firmware update package from the encrypted storage area, decrypt it, and send it to the IoT device.
[0052] For example, in an embodiment of the present application, the proxy server 103 may send the firmware update package to the main controller 104 of the IoT device in a fragmented manner.
[0053] Specifically, the proxy server 103 is configured to receive the firmware update package from the CA 102 and cache the firmware update package in the encrypted storage area. The proxy server 103 is also configured to perform segmentation processing on the firmware update package to obtain the firmware update package segments.
[0054] In one possible implementation, upon receiving the firmware update package, proxy server 103 splits the firmware update package into segments and a list of segment hash values. The size of each segment can be determined based on actual application requirements, such as 128KB, and is not specifically limited in this embodiment.
[0055] The proxy server 103 is configured to receive a firmware update request from the main controller 104, wherein the firmware update request is used to obtain a firmware update package for the IoT device. The firmware update request includes an identifier of the IoT device and a firmware version number.
[0056] The proxy server 103 is further configured to send fragment metadata to the main controller 104. The fragment metadata includes the total number of fragments in the firmware update package, a list of fragment hash values, the Internet Protocol (IP) address of the proxy server 103, and a dynamic session key. The dynamic session key is used to encrypt and decrypt the firmware update package fragments.
[0057] The proxy server 103 is further configured to receive fragmentation requests sent sequentially from the main controller 104 , where the fragmentation requests are used to obtain a target number of firmware update package fragments.
[0058] The proxy server 103 is further configured to send encrypted firmware update package segments to the main controller 104. It is understood that, to ensure security, each firmware update package segment is encrypted, for example, using the AES-256 encryption algorithm.
[0059] In a possible implementation, the proxy server 103 is further configured to send an IP address change message to the main controller, where the IP address change message is used to indicate the changed IP address of the proxy server after sending a target number of encrypted firmware update package fragments.
[0060] The functions of the proxy server 103 are described above. The specific steps in which the proxy server 103 participates in the firmware security update method process can be found in the description of the relevant embodiments below, and will not be repeated here.
[0061] The main controller 104 may be a main processor on the IoT device, such as a microcontroller unit (MCU).
[0062] Illustratively, in an embodiment of the present application, the main controller 104 is configured to send a firmware update request to the proxy server 103 , where the firmware update request is used to obtain a firmware update package.
[0063] The main controller 104 is further configured to receive fragment metadata from the proxy server 103. The fragment metadata includes: the total number of fragments in the firmware update package, a list of fragment hash values, the proxy server's Internet Protocol (IP) address, and a dynamic session key. The dynamic session key is used to encrypt and decrypt the firmware update package fragments.
[0064] The main controller 104 is further configured to send fragment requests to the proxy server 103 in sequence, where the fragment requests are used to obtain a target number of firmware update package fragments.
[0065] The main controller 104 is further configured to receive a target number of encrypted firmware update package fragments from the proxy server 103 , and forward the encrypted firmware update package fragments to the security chip 105 .
[0066] In one possible implementation, each time after receiving a target number of encrypted firmware update package fragments from proxy server 103, main controller 104 is further configured to receive an IP address change message from proxy server 103. The IP address change message indicates the changed IP address of proxy server 103 after sending the target number of encrypted firmware update package fragments. Accordingly, main controller 104 is further configured to continue sending fragment requests to proxy server 103 based on the IP address change message.
[0067] In a possible implementation, the main controller 104 is further configured to forward the dynamic session key and the shard hash value list to the security chip 105 .
[0068] The functions of the main controller 104 are described above. For the specific steps in which the main controller 104 participates in the firmware security update method process, please refer to the description of the relevant embodiments below, which will not be repeated here.
[0069] The security chip 105 is installed in the IoT device and is the core security component during firmware updates. It is responsible for protecting sensitive data, performing key encryption and decryption operations, and ensuring the integrity and authenticity of the firmware.
[0070] Specifically, the security chip 105 is configured to receive encrypted firmware update package fragments from the main controller 104 .
[0071] The security chip 105 is further configured to perform security verification on the encrypted firmware update package fragments, and store the encrypted firmware update package fragments in the secure area if the security verification passes.
[0072] The security chip 105 is further configured to determine a firmware update package based on fragments of all received encrypted firmware update packages.
[0073] The security chip 105 is also used to verify the firmware update package based on the developer public key obtained from the CA 102.
[0074] The security chip 105 is further configured to update the firmware of the IoT device according to the firmware update package when the firmware update package passes verification.
[0075] In one possible implementation, the security chip 105 is further configured to receive a dynamic session key and a fragment hash value list from the main controller 104. Furthermore, the security chip 105 calculates hash values for the encrypted firmware update package fragments and compares them with the fragment hash value list to determine a security verification result. Furthermore, the security chip 105 determines the firmware update package based on all received encrypted firmware update package fragments. This specifically includes decrypting all encrypted firmware update package fragments using the dynamic session key. The decrypted encrypted firmware update package fragments are then concatenated to determine the firmware update package.
[0076] The functions of the security chip 105 are described above. For the specific steps in which the security chip 105 participates in the firmware security update method process, please refer to the description of the relevant embodiments below and will not be repeated here.
[0077] For example, Figure 2 As shown, Figure 2 A flowchart of a firmware security update method for an IoT device provided in this application includes the following steps: S201: The developer submits a firmware update package to the CA, and the CA receives the firmware update package.
[0078] Among them, before submitting the firmware update package to the CA, the developer uses the developer HSM and the developer's signature private key to sign the firmware update package to prevent the firmware update package from being tampered with during transmission. Correspondingly, the developer's public key corresponding to the developer's signature private key will also be sent to the CA, and the IoT device can obtain the public key through the CA. Furthermore, after obtaining the firmware update package, the IoT device uses the developer's public key for verification. For example, in an embodiment of the present application, after the security chip obtains the firmware update package, it will verify the firmware update package based on the developer's public key from the CA.
[0079] S202: The CA sends a firmware update package to the proxy server, and the proxy server receives the firmware update package accordingly.
[0080] Optionally, the CA may also send the developer's public key to the proxy server, so that the proxy server subsequently sends the developer's public key to the IoT device.
[0081] In one possible implementation, after receiving the firmware update package, the proxy server caches the firmware update package in an encrypted storage area. Exemplarily, the proxy server encrypts the firmware update package using the AES-256 encryption algorithm. Furthermore, the proxy server caches the encrypted firmware update package in the encrypted storage area using edge node technology.
[0082] It is understandable that when the proxy server needs to send a firmware update package to the IoT device, the proxy server will pull the encrypted firmware update package from the encrypted storage area and decrypt it before sending it to the IoT device.
[0083] S203: The proxy server generates firmware update package fragments.
[0084] Optionally, the proxy server pulls the encrypted firmware update package from the encrypted storage area and decrypts it. Afterwards, the firmware update package is split to obtain firmware update package fragments and a fragment hash value list. The size of each fragment can be determined based on actual application requirements, for example, 128KB, and this embodiment of the present application does not impose a specific limit. It should be noted that the fragment hash value list can be used by the subsequent security chip to perform security verification on the received firmware update package fragments to ensure that the fragments have not been tampered with.
[0085] It is understood that, to ensure security, each firmware update package fragment is encrypted, for example, using the AES-256 encryption algorithm. Accordingly, the proxy server generates a dynamic session key, which is used to encrypt and decrypt the firmware update package fragments.
[0086] S204: The main controller sends a firmware update request to the proxy server. Correspondingly, the proxy server receives the firmware update request.
[0087] The firmware update request is used to obtain a firmware update package, including the identifier of the IoT device and the firmware version number.
[0088] S205: The proxy server sends the shard metadata to the main controller. Correspondingly, the main controller receives the shard metadata.
[0089] The shard metadata includes the total number of shards in the firmware update package, a list of shard hash values, the IP address of the proxy server, and a dynamic session key. The dynamic session key is used to encrypt and decrypt the firmware update package shards.
[0090] S206: The main controller sends the fragmentation requests to the proxy server in sequence. Correspondingly, the proxy server receives the fragmentation requests in sequence.
[0091] Optionally, after receiving the shard metadata, the main controller may generate shard requests based on the shard metadata and send shard requests to the proxy server in sequence based on the proxy server's IP address. Each request is used to obtain the target number of firmware update package shards. The main controller stops sending shard requests until it has obtained all the firmware update package shards.
[0092] It should be noted that the target number may be determined according to the needs of actual applications, such as 1 to 5, and is not specifically limited in the embodiments of the present application.
[0093] S207: The proxy server sends the encrypted firmware update package fragments to the main controller. Correspondingly, the main controller receives the encrypted firmware update package fragments.
[0094] As described in step S203 above, to ensure security, the firmware update package fragments sent to the main controller are encrypted, for example, using the AES-256 encryption algorithm. Accordingly, the dynamic session key used to decrypt the firmware update package fragments has been sent to the main controller in S205. The main controller can forward this key to the security chip, which then decrypts the encrypted firmware update package fragments.
[0095] S208: The main controller forwards the encrypted firmware update package fragments to the security chip. Correspondingly, the security chip receives the encrypted firmware update package fragments.
[0096] Optionally, before sending the encrypted firmware update package fragments to the security chip, the main control forwards the dynamic session key and the fragment hash value list to the security chip, so that the security chip can perform security verification and decrypt the encrypted firmware update package fragments after receiving the encrypted firmware update package fragments.
[0097] S209: The security chip performs a security check on the encrypted firmware update package fragments. If the security check passes, the encrypted firmware update package fragments are stored in the secure area.
[0098] Optionally, after receiving the fragment hash value list from the main controller, the security chip calculates the hash value of the encrypted firmware update package fragment and compares it with the fragment hash value list to determine the security verification result. Further, if the security verification passes, the encrypted firmware update package fragment is stored in the secure area.
[0099] S210: The proxy server sends an IP address change message to the main controller. Correspondingly, the main controller receives the IP address change message.
[0100] The IP address change message is used to indicate the changed IP address of the proxy server after sending a target number of encrypted firmware update package fragments.
[0101] Optionally, each time the proxy server sends a preset number of shards to the main controller or after a preset duration has elapsed, the proxy server sends an IP address change message to the main controller. For example, after the proxy server sends five shards to the main controller, it assigns a new proxy IP address and sends an IP address change message to the main controller. Alternatively, after 30 seconds have passed, it assigns a new proxy IP address and sends an IP address change message to the main controller. The specific preset number and preset duration can be determined based on actual application needs and are not specifically limited in this application.
[0102] It is understandable that after the main controller receives the IP address change message, it can continue to send fragment requests to the proxy server according to the IP address change message.
[0103] S211. The security chip determines a firmware update package based on all received encrypted firmware update package fragments, and verifies the firmware update package based on the developer public key obtained from the certificate authority CA.
[0104] Optionally, the security chip determines the firmware update package based on all the received encrypted firmware update package fragments, specifically including: decrypting all the encrypted firmware update package fragments according to the dynamic session key; thereafter, the security chip splices the decrypted encrypted firmware update package fragments to determine the firmware update package.
[0105] Optionally, the developer public key is forwarded to the security chip via the proxy server and the main controller. After that, the security chip verifies the firmware update package based on the developer public key obtained from the certificate authority (CA).
[0106] Accordingly, if the firmware update package passes the verification, the subsequent S212 is executed; Accordingly, if the firmware update package fails the verification, the subsequent step S214 is executed.
[0107] S212. The security chip updates the firmware of the IoT device according to the firmware update package.
[0108] It is understandable that the security chip writes the firmware update package to the Flash storage area to complete the firmware update and ensure that only signed firmware can be executed.
[0109] S213: The security chip sends an update success message to the main controller. Correspondingly, the main controller receives the update success message.
[0110] Optionally, after updating the firmware of the IoT device according to the firmware update package, the security chip generates an update success message.
[0111] S214: The security chip sends an alarm log to the main controller, and the main controller receives the alarm log accordingly.
[0112] Optionally, when the firmware update package fails verification, the security chip triggers self-locking and generates an alarm log, and then sends the alarm log to the main controller.
[0113] S215. The main controller sends an update result message to the proxy server.
[0114] Optionally, the main controller generates an update result message based on the update success message or alarm log sent by the security chip, and reports the update result message to the proxy server, so that operation and maintenance personnel can perform operation and maintenance analysis and audit through the proxy server.
[0115] S216. The proxy server synchronizes the update result message to the blockchain.
[0116] In this step, the update result message is synchronized to the blockchain to meet the audit requirements of the General Data Protection Regulation (GDPR).
[0117] Based on the above technical solution, when performing firmware updates, the embodiment of the present application can implement an end-to-end encrypted trust chain based on the process of developer HSM signature → CA certificate verification → security chip signature verification. It also implements a dynamic defense mechanism by rotating the IP address of the proxy server and the dynamic session key, and implements hardware-level protection through decryption and secure zone storage of the security chip, thereby making the firmware update anti-eavesdropping and anti-tampering throughout the process. While ensuring the security of the firmware update, it maintains efficient download capabilities through fragmented downloading and edge caching, reduces resource consumption for firmware updates, and thus streamlines the firmware security update process, reduces resource consumption, and ultimately improves the user experience.
[0118] In the embodiment of the present application, the firmware security update device of the Internet of Things device can be divided into functional modules or functional units according to the above method example. For example, each functional module or functional unit can be divided according to each function, or two or more functions can be integrated into one processing module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of software functional modules or functional units. Among them, the division of modules or units in the embodiment of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation.
[0119] For example, Figure 3FIG2 is a schematic diagram of a possible structure of a firmware security update device for an IoT device according to an embodiment of the present application. The firmware security update device 300 for the IoT device includes: a sending unit 301 and a receiving unit 302.
[0120] The sending unit 301 is configured to send a firmware update request to the proxy server, wherein the firmware update request is used to obtain a firmware update package for the IoT device, wherein the firmware update request includes an identifier of the IoT device and a firmware version number.
[0121] The receiving unit 302 is configured to receive fragment metadata from the proxy server. The fragment metadata includes: the total number of fragments in the firmware update package, a list of fragment hash values, the Internet Protocol (IP) address of the proxy server, and a dynamic session key used to encrypt and decrypt the firmware update package fragments.
[0122] The sending unit 301 is further configured to send fragment requests to the proxy server in sequence, where the fragment requests are used to obtain a target number of firmware update package fragments.
[0123] The receiving unit 302 is further configured to receive a target number of encrypted firmware update package fragments from the proxy server.
[0124] The sending unit 301 is further configured to forward the encrypted firmware update package fragments to the security chip.
[0125] Optionally, the receiving unit 302 is further configured to receive an IP address change message from the proxy server, where the IP address change message is used to indicate the changed IP address of the proxy server after sending a target number of encrypted firmware update package fragments.
[0126] Optionally, the sending unit 301 is further configured to continue sending the fragmentation request to the proxy server according to the IP address change message.
[0127] Optionally, the sending unit 301 is further configured to forward the dynamic session key and the shard hash value list to the security chip.
[0128] Optionally, the firmware security update apparatus 300 of the IoT device may further include a storage unit ( Figure 3 ), the storage unit stores a program or instruction. When the sending unit 301 and the receiving unit 302 execute the program or instruction, the firmware security update device of the Internet of Things device can execute the firmware security update method of the Internet of Things device in the above method embodiment.
[0129] also, Figure 3 The technical effects of the firmware security update device for an Internet of Things device can refer to the technical effects of the firmware security update method for an Internet of Things device in the above embodiment, and will not be repeated here.
[0130] For example, Figure 4 FIG. 4 is a schematic diagram of a possible structure of a firmware security update device for an IoT device according to an embodiment of the present application. The firmware security update device 400 for an IoT device includes: a receiving unit 401 and a processing unit 402.
[0131] The receiving unit 401 is configured to receive encrypted firmware update package fragments from the main controller.
[0132] The processing unit 402 is configured to perform security verification on the encrypted firmware update package fragments, and store the encrypted firmware update package fragments in a secure area if the security verification passes.
[0133] The processing unit 402 is further configured to determine a firmware update package according to all received encrypted firmware update package fragments, and verify the firmware update package according to a developer public key obtained from a certificate authority CA.
[0134] The processing unit 402 is further configured to update the firmware of the IoT device according to the firmware update package if the firmware update package passes verification.
[0135] Optionally, the receiving unit 401 is further configured to receive a dynamic session key and a shard hash value list from the main controller.
[0136] Optionally, the processing unit 402 is further configured to calculate hash values of fragments of the encrypted firmware update package and compare the hash values with the fragment hash value list.
[0137] Optionally, the processing unit 402 is further configured to decrypt all encrypted firmware update package fragments according to the dynamic session key.
[0138] Optionally, the processing unit 402 is further configured to splice the decrypted encrypted firmware update package fragments to determine the firmware update package.
[0139] Optionally, the firmware security update device 400 of the Internet of Things device may further include a storage unit ( Figure 4 ), the storage unit stores a program or instruction. When the receiving unit 401 and the processing unit 402 execute the program or instruction, the firmware security update device of the Internet of Things device can execute the firmware security update method of the Internet of Things device in the above method embodiment.
[0140] also, Figure 4 The technical effects of the firmware security update device for an Internet of Things device can refer to the technical effects of the firmware security update method for an Internet of Things device in the above embodiment, and will not be repeated here.
[0141] For example, Figure 5FIG. 5 is a schematic diagram of a possible structure of a firmware security update device for an IoT device according to an embodiment of the present application. The firmware security update device 500 for an IoT device includes: a receiving unit 501 , a processing unit 502 , and a sending unit 503 .
[0142] The receiving unit 501 is configured to receive a firmware update package from a certificate authority (CA), and cache the firmware update package in an encrypted storage area.
[0143] The processing unit 502 performs fragment processing on the firmware update package to obtain firmware update package fragments.
[0144] The receiving unit 501 is further configured to receive a firmware update request from the main controller, wherein the firmware update request is used to obtain a firmware update package for the IoT device, wherein the firmware update request includes an identifier of the IoT device and a firmware version number.
[0145] The sending unit 503 is configured to send the fragment metadata to the main controller. The fragment metadata includes: the total number of fragments in the firmware update package, a list of fragment hash values, the Internet Protocol (IP) address of the proxy server, and a dynamic session key used to encrypt and decrypt the firmware update package fragments.
[0146] The receiving unit 501 is further configured to receive fragmentation requests sent sequentially from the main controller, where the fragmentation requests are used to obtain a target number of firmware update package fragments.
[0147] The sending unit 503 is further configured to send the encrypted firmware update package fragments to the main controller.
[0148] Optionally, the sending unit 503 is further configured to send an IP address change message to the main controller, where the IP address change message is used to indicate the changed IP address of the proxy server after sending a target number of encrypted firmware update package fragments.
[0149] Optionally, the firmware security update device 500 of the Internet of Things device may further include a storage unit ( Figure 5 ), the storage unit stores a program or instruction. When the receiving unit 501, the processing unit 502 and the sending unit 503 execute the program or instruction, the firmware security update device of the Internet of Things device can execute the firmware security update method of the Internet of Things device described in the above method embodiment.
[0150] also, Figure 5 The technical effects of the firmware security update device for the Internet of Things device can refer to the technical effects of the firmware security update method for the Internet of Things device described in the above embodiment, and will not be repeated here.
[0151] For example, Figure 6FIG. 1 is another possible structural diagram of the firmware security update method for the Internet of Things device involved in the above embodiment. Figure 6 As shown, the firmware security update device 600 of the Internet of Things device includes: a processor 602.
[0152] Among them, the processor 602 is used to control and manage the actions of the firmware security update device 600 of the Internet of Things device, for example, executing the steps performed by the above-mentioned sending unit 301, receiving unit 302, receiving unit 401, processing unit 402, receiving unit 501, processing unit 502 and sending unit 503, and / or other processes for executing the technical solution described in this document.
[0153] The processor 602 may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or other programmable logic device, a transistor logic device, a hardware component, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.
[0154] Optionally, the IoT device firmware security update apparatus 600 may further include a communication interface 603, a memory 601, and a bus 604. The communication interface 603 is used to support communication between the IoT device firmware security update apparatus 600 and other network entities. The memory 601 is used to store program code and data of the IoT device firmware security update apparatus.
[0155] Among them, the memory 601 can be a memory in the firmware security update device of the Internet of Things device, and the memory may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a read-only memory, a flash memory, a hard disk or a solid-state drive; the memory may also include a combination of the above types of memory.
[0156] The bus 604 may be an Extended Industry Standard Architecture (EISA) bus or the like. The bus 604 may be divided into an address bus, a data bus, a control bus, or the like. For ease of representation, Figure 6 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.
[0157] Through the description of the above embodiments, those skilled in the art will clearly understand that for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working processes of the above-described systems, devices, and modules can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0158] An embodiment of the present application provides a computer program product containing instructions. When the computer program product is run on an electronic device of the present application, the computer is caused to execute the firmware security update method for an Internet of Things device described in the above method embodiment.
[0159] An embodiment of the present application also provides a computer-readable storage medium, which stores instructions. When a computer executes the instructions, the electronic device of the present application executes the various steps performed by the firmware security update device of the Internet of Things device in the method flow shown in the above method embodiment.
[0160] The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk. Random Access Memory (RAM), Read-Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM), a register, a hard disk, an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any other form of computer-readable storage medium known in the art, or any combination thereof. An exemplary storage medium is coupled to a processor so that the processor can read information from and write information to the storage medium. Of course, the storage medium may also be an integral part of the processor. The processor and storage medium may be located in an application-specific integrated circuit (ASIC). In the embodiments of the present application, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.
[0161] The above is only a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or replacements within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.
Claims
1. A method for securely updating firmware of an IoT device, characterized in that: The method applied to the main controller of the Internet of Things device includes: Sending a firmware update request to a proxy server, wherein the firmware update request is used to obtain a firmware update package for the IoT device; wherein the firmware update request includes an identifier of the IoT device and a firmware version number; Receiving fragment metadata from the proxy server, wherein the fragment metadata includes: a total number of fragments of the firmware update package, a list of fragment hash values, an Internet Protocol (IP) address of the proxy server, and a dynamic session key, wherein the dynamic session key is used to encrypt and decrypt the firmware update package fragments; Sending fragment requests to the proxy server in sequence, wherein the fragment requests are used to obtain a target number of firmware update package fragments; Receive a target number of encrypted firmware update package fragments from the proxy server, and forward the encrypted firmware update package fragments to the security chip.
2. The method for securely updating firmware of an IoT device according to claim 1, wherein: The fragment request includes timestamp information and a random number, and the random number is used to defend against replay attacks; Each time after receiving a target number of encrypted firmware update package fragments from the proxy server, the method further includes: receiving an IP address change message from the proxy server, the IP address change message being used to indicate a changed IP address of the proxy server after sending the target number of encrypted firmware update packet fragments; According to the IP address change message, continue to send the fragment request to the proxy server.
3. The method for securely updating firmware of an IoT device according to claim 2, wherein: The method further comprises: Forward the dynamic session key and the shard hash value list to the security chip.
4. A method for securely updating firmware of an IoT device, characterized in that: The security chip applied to the IoT device, the method comprising: receiving encrypted firmware update packet fragments from the main controller; Performing a security check on the encrypted firmware update package fragments, and if the security check passes, storing the encrypted firmware update package fragments in a secure area; Determining a firmware update package based on all received encrypted firmware update package fragments, and verifying the firmware update package based on a developer public key obtained from a certificate authority (CA); If the firmware update package passes the verification, the firmware of the IoT device is updated according to the firmware update package.
5. The method for securely updating firmware of an IoT device according to claim 4, wherein: The method further comprises: receiving a dynamic session key and the shard hash value list from a master controller; The performing security verification on the encrypted firmware update package fragments specifically includes: Calculating a hash value of the encrypted firmware update package fragment and comparing it with the fragment hash value list; The step of determining the firmware update package based on all received encrypted firmware update package fragments specifically includes: decrypting all encrypted firmware update packet fragments according to the dynamic session key; The decrypted encrypted firmware update package fragments are spliced together to determine the firmware update package.
6. A method for securely updating firmware of an IoT device, characterized in that: Applied to a proxy server, the method includes: Receiving a firmware update package from a certificate authority (CA), and caching the firmware update package in an encrypted storage area; Slice the firmware update package to obtain firmware update package fragments; Receive a firmware update request from a main controller, the firmware update request being used to obtain a firmware update package for the IoT device; wherein the firmware update request includes an identifier of the IoT device and a firmware version number; Sending shard metadata to the master controller; wherein the shard metadata includes: the total number of shards of the firmware update package, a list of shard hash values, an Internet Protocol (IP) address of the proxy server, and a dynamic session key, wherein the dynamic session key is used to encrypt and decrypt the firmware update package shards; receiving fragment requests sent in sequence from the main controller, the fragment requests being used to obtain a target number of firmware update package fragments; Sending encrypted firmware update package fragments to the master controller.
7. The method for securely updating firmware of an IoT device according to claim 6, wherein: The method further comprises: An IP address change message is sent to the main controller, where the IP address change message is used to indicate the changed IP address of the proxy server after sending the target number of encrypted firmware update packet fragments.
8. A firmware update device for an Internet of Things device, characterized in that: A main controller applied to an Internet of Things device, the device comprising: a sending unit and a receiving unit; The sending unit is configured to send a firmware update request to the proxy server, wherein the firmware update request is used to obtain a firmware update package for the IoT device; wherein the firmware update request includes an identifier of the IoT device and a firmware version number; The receiving unit is configured to receive fragment metadata from the proxy server, wherein the fragment metadata includes: a total number of fragments of the firmware update package, a fragment hash value list, an Internet Protocol (IP) address of the proxy server, and a dynamic session key, wherein the dynamic session key is used to encrypt and decrypt the firmware update package fragments; The sending unit is further configured to send fragment requests to the proxy server in sequence, wherein the fragment requests are used to obtain a target number of firmware update package fragments; The receiving unit is further configured to receive a target number of encrypted firmware update package fragments from the proxy server, and forward the encrypted firmware update package fragments to the security chip.
9. A firmware update device for an Internet of Things device, characterized in that: A security chip applied to an IoT device, the device comprising: a receiving unit and a processing unit; The receiving unit is configured to receive encrypted firmware update packet fragments from the main controller; The processing unit is configured to perform a security check on the encrypted firmware update package fragments, and if the security check passes, store the encrypted firmware update package fragments in a secure area; The processing unit is further configured to determine a firmware update package based on all received encrypted firmware update package fragments, and verify the firmware update package based on a developer public key obtained from a certificate authority (CA); The processing unit is further configured to update the firmware of the IoT device according to the firmware update package if the firmware update package passes verification.
10. A firmware update device for an Internet of Things device, characterized in that: Applied to a proxy server, the device comprises: a receiving unit, a processing unit and a sending unit; The receiving unit is configured to receive a firmware update package from a certificate authority (CA) and cache the firmware update package in an encrypted storage area; The processing unit is configured to perform fragment processing on the firmware update package to obtain firmware update package fragments; The receiving unit is further configured to receive a firmware update request from the main controller, wherein the firmware update request is used to obtain a firmware update package for the IoT device; wherein the firmware update request includes an identifier of the IoT device and a firmware version number; The sending unit is configured to send fragment metadata to the main controller; wherein the fragment metadata includes: a total number of fragments of the firmware update package, a fragment hash value list, an Internet Protocol (IP) address of the proxy server, and a dynamic session key, wherein the dynamic session key is used to encrypt and decrypt the firmware update package fragments; The receiving unit is further configured to receive fragmentation requests sent in sequence from the main controller, wherein the fragmentation requests are used to obtain a target number of firmware update package fragments; The sending unit is further configured to send encrypted firmware update package fragments to the main controller.
Citation Information
Patent Citations
OTA technology firmware upgrading method, device and equipment
CN111538512A
Firmware updating method, device and system of Internet of Things equipment and storage medium
CN112947966A
Firmware updating method, device and system for Internet of Things equipment
CN114329596A
Firmware updating method, terminal equipment and server
CN119806566A
Firmware encryption method and system based on device unique identifier and dynamic key verification
CN120337243A