Security updating method and device of internet of things equipment, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a kind of security update method, device, electronic equipment and storage medium of Internet of Things equipment, it is related to data encryption technique field, the method comprises: in response to sending OTA request to server, obtain the encrypted update package corresponding to OTA request;Dynamic generation target private key for temporary session key, and the encrypted update package is decrypted using target private key and temporary session key, obtain corresponding firmware fragment;If the integrity of each firmware fragment is all verified, all firmware fragments are recombined, corresponding update firmware is obtained, and the legality of update firmware is verified using the double-track efficacy certificate stored locally, in the case where the legality of update firmware is verified, the update operation corresponding to update firmware is executed, so as to realize zero key storage risk and quantum level security protection, the processing mode of certificate is optimized, the security and reliability of Internet of Things equipment firmware update are improved.

Description

Technical Field

[0001] This invention relates to the field of data encryption technology, and in particular to a secure update method for an Internet of Things (IoT) device, a secure update device for an IoT device, an electronic device, and a computer-readable storage medium. Background Technology

[0002] For IoT devices, regular updates are necessary to provide richer functionality and meet users' actual needs. One method for security updates is OTA (Over-The-Air), a core function of IoT systems. OTA updates allow for remote updates, repairs, or upgrades to device firmware, software, or configurations via a network without physical contact. However, OTA updates for IoT devices present several risks, including static key storage, inflexible certificate updates, and a lack of quantum-safety measures. Summary of the Invention

[0003] This invention provides a secure update method, apparatus, electronic device, and computer-readable storage medium for Internet of Things (IoT) devices, to solve or partially solve the problems of at least static key storage risk, rigid certificate update, and lack of quantum defense in the OTA update process of IoT devices.

[0004] This invention discloses a security update method for Internet of Things (IoT) devices, comprising:

[0005] In response to sending an OTA request to the server, the server obtains an encrypted update package corresponding to the OTA request, wherein the encrypted update package is a data packet encrypted by the server using a temporary session key;

[0006] A target private key for the temporary session key is dynamically generated, and the target private key and the temporary session key are used to decrypt the encrypted update package to obtain the corresponding firmware fragment;

[0007] If the integrity of each firmware fragment is verified, all firmware fragments are reassembled to obtain the corresponding updated firmware. The legality of the updated firmware is verified using a locally stored dual-track validity certificate. If the legality of the updated firmware is verified, the update operation corresponding to the updated firmware is executed.

[0008] In some feasible implementations, the firmware fragment includes several data blocks. If the integrity of each firmware fragment passes verification, all firmware fragments are reassembled to obtain the corresponding updated firmware, including:

[0009] Obtain the firmware mapping header corresponding to the firmware fragment, wherein the firmware mapping header includes a trusted root hash value;

[0010] Obtain the block index corresponding to the data block, and calculate the block hash value corresponding to each data block;

[0011] The target root hash value corresponding to the firmware fragment is obtained by iteratively calculating based on the block hash value and the block index.

[0012] If the target root hash value is the same as the trusted root hash value, then obtain the next firmware fragment of the firmware fragment;

[0013] Return to the process of iteratively calculating the target root hash value corresponding to the firmware fragment based on the block hash value and the block index, until all firmware fragments have completed integrity verification;

[0014] If the integrity of each firmware segment passes verification, then all firmware segments are reassembled to obtain the corresponding updated firmware.

[0015] In some feasible implementations, the step of iteratively calculating the target root hash value corresponding to the firmware fragment based on the block hash value and the block index includes:

[0016] Select any of the data blocks as the current data block;

[0017] Starting with the current data block, the block hash values ​​of adjacent data blocks are concatenated according to the block index to obtain the current block hash value. The process of concatenating the block hash values ​​of adjacent data blocks according to the block index is returned until all the hash values ​​corresponding to the data blocks in the firmware fragment are exhausted, and the target root hash value corresponding to the firmware fragment is obtained.

[0018] In some feasible implementations, the dynamic generation of the target private key for the temporary session key includes:

[0019] Obtain the first private key component corresponding to the IoT device;

[0020] Obtain the second private key component corresponding to the server;

[0021] The first private key component and the second private key component are combined to obtain the target private key for the temporary session key.

[0022] Among some feasible implementation methods are:

[0023] In response to the first startup of the IoT device, a device identifier corresponding to the IoT device is generated by random number generation, and a first private key component corresponding to the device identifier is generated by elliptic curve cryptography.

[0024] Calculate the first public key component corresponding to the first private key component;

[0025] Send the first public key component to the server and receive a dual-track certificate corresponding to the first public key component sent by the server. The dual-track certificate is a certificate issued by the server using the first public key component corresponding to the IoT device, the second public key component corresponding to the server, and the root certificate. The dual-track certificate includes at least a traditional ECC signature and a post-quantum certificate.

[0026] In some feasible implementations, the step of using a locally stored dual-track validity certificate to verify the legitimacy of the updated firmware, and if the legitimacy verification of the updated firmware passes, performing the update operation corresponding to the updated firmware, includes:

[0027] Extract the target manufacturer signature corresponding to the updated firmware;

[0028] Obtain the dual-track efficacy certificate stored locally. If the target vendor signature matches the trusted vendor signature corresponding to the dual-track efficacy certificate, then perform the update operation corresponding to the updated firmware.

[0029] Among some feasible implementation methods are:

[0030] If the dual-track validity certificate expires or a security risk is detected in the IoT device, then the third private key component sent by the server is obtained.

[0031] Obtain the first public key component corresponding to the IoT device;

[0032] Obtain the second public key component corresponding to the server;

[0033] The third public key component is calculated using the third private key component to obtain the third public key component corresponding to the server, and the second public key component is used to update the third public key component. The server then sends a new dual-track validity certificate corresponding to the third public key component.

[0034] Switch to the new dual-track efficacy certificate and set the expiration time for the original dual-track efficacy certificate.

[0035] This invention also discloses a security update method for IoT devices, comprising:

[0036] In response to receiving an OTA request sent by an IoT device, the system obtains the target firmware corresponding to the OTA request and segments the target firmware to obtain several corresponding firmware segments.

[0037] After encrypting each firmware fragment, a corresponding update data packet is constructed.

[0038] A temporary session key is dynamically generated for the update data packet, and the update data packet is encrypted using the temporary session key to obtain the corresponding encrypted data packet;

[0039] The encrypted data packet is sent to the IoT device.

[0040] In some feasible implementations, the step of constructing the corresponding update data packet after encrypting each firmware fragment includes:

[0041] Obtain the fragment size for the firmware fragment, and divide the firmware fragment into several data blocks according to the fragment size;

[0042] Calculate the block hash value corresponding to the data block, and use the block hash value as the leaf node;

[0043] The leaf nodes are grouped in pairs, and two adjacent leaf nodes are concatenated to obtain the corresponding target block hash value, and the target block hash value is used as a new leaf node.

[0044] Return to the process of grouping the leaf nodes in pairs, splicing two adjacent leaf nodes to obtain the corresponding target block hash value, until the root node corresponding to the firmware fragment is generated, and the root node is used as the trusted root hash value.

[0045] Obtain the vendor key corresponding to the target firmware;

[0046] The trusted root hash value is digitally signed using the vendor key to obtain signature data;

[0047] At least the fragment size, the signature data, and the trusted root hash value are integrated to obtain the corresponding update data packet.

[0048] In some feasible implementations, before obtaining the target firmware corresponding to the OTA request in response to receiving an OTA request from an IoT device, the method further includes:

[0049] Obtain the first public key component corresponding to the IoT device;

[0050] Obtain the second private key component corresponding to the server, and calculate the second public key component corresponding to the second private key component;

[0051] Combine the first public key component and the second public key component to obtain the first target public key;

[0052] Obtain the root certificate corresponding to the target firmware, and use the first target public key and the root certificate to sign the dual-track certificate to obtain a dual-track certificate, and issue the dual-track certificate to the IoT device.

[0053] The dual-track validity certificate includes at least a traditional ECC signature and a post-quantum certificate.

[0054] Among some feasible implementation methods, it also includes

[0055] If the dual-track validity certificate expires or a security risk is detected in the IoT device, a new second private key component is generated, and the third public key component corresponding to the new second private key component is calculated.

[0056] By combining the third public key component and the first public key component, a second target public key is obtained;

[0057] The second target public key and the root certificate are used to issue a new dual-track certificate, and the new dual-track certificate is then issued to the IoT device.

[0058] This invention also discloses a security update device for IoT devices, comprising:

[0059] The data packet request module is used to respond to sending an OTA request to the server and obtain an encrypted update packet corresponding to the OTA request, wherein the encrypted update packet is a data packet encrypted by the server using a temporary session key;

[0060] The decryption module is used to dynamically generate a target private key for the temporary session key, and use the target private key and the temporary session key to decrypt the encrypted update package to obtain the corresponding firmware fragment;

[0061] The verification module is used to reassemble all the firmware fragments to obtain the corresponding updated firmware if the integrity of each firmware fragment passes the verification, and to verify the legality of the updated firmware using a locally stored dual-track validity certificate. If the legality of the updated firmware passes the verification, the module executes the update operation corresponding to the updated firmware.

[0062] In some feasible implementations, the firmware fragment includes several data blocks, and the verification module is specifically used for:

[0063] Obtain the firmware mapping header corresponding to the firmware fragment, wherein the firmware mapping header includes a trusted root hash value;

[0064] Obtain the block index corresponding to the data block, and calculate the block hash value corresponding to each data block;

[0065] The target root hash value corresponding to the firmware fragment is obtained by iteratively calculating based on the block hash value and the block index.

[0066] If the target root hash value is the same as the trusted root hash value, then obtain the next firmware fragment of the firmware fragment;

[0067] Return to the process of iteratively calculating the target root hash value corresponding to the firmware fragment based on the block hash value and the block index, until all firmware fragments have completed integrity verification;

[0068] If the integrity of each firmware segment passes verification, then all firmware segments are reassembled to obtain the corresponding updated firmware.

[0069] In some feasible implementations, the verification module is specifically used for:

[0070] Select any of the data blocks as the current data block;

[0071] Starting with the current data block, the block hash values ​​of adjacent data blocks are concatenated according to the block index to obtain the current block hash value. The process of concatenating the block hash values ​​of adjacent data blocks according to the block index is returned until all the hash values ​​corresponding to the data blocks in the firmware fragment are exhausted, and the target root hash value corresponding to the firmware fragment is obtained.

[0072] In some feasible implementations, the decryption module is specifically used for:

[0073] Obtain the first private key component corresponding to the IoT device;

[0074] Obtain the second private key component corresponding to the server;

[0075] The first private key component and the second private key component are combined to obtain the target private key for the temporary session key.

[0076] Among some feasible implementation methods are:

[0077] The private key generation module is used to generate a device identifier corresponding to the IoT device by random number in response to the first startup of the IoT device, and to generate a first private key component corresponding to the device identifier by elliptic curve cryptography.

[0078] The public key calculation module is used to calculate the first public key component corresponding to the first private key component;

[0079] The certificate acquisition module is used to send the first public key component to the server and receive a dual-track certificate corresponding to the first public key component sent by the server. The dual-track certificate is a certificate issued by the server using the first public key component corresponding to the IoT device, the second public key component corresponding to the server, and the root certificate. The dual-track certificate includes at least a traditional ECC signature and a post-quantum certificate.

[0080] In some feasible implementations, the verification module is specifically used for:

[0081] Extract the target manufacturer signature corresponding to the updated firmware;

[0082] Obtain the dual-track efficacy certificate stored locally. If the target vendor signature matches the trusted vendor signature corresponding to the dual-track efficacy certificate, then perform the update operation corresponding to the updated firmware.

[0083] Among some feasible implementation methods are:

[0084] The private key acquisition module is used to acquire the third private key component sent by the server if the dual-track validity certificate expires or if a security risk is detected in the IoT device.

[0085] The public key acquisition module is used to acquire the first public key component corresponding to the IoT device and the second public key component corresponding to the server.

[0086] The public key update module is used to calculate using the third private key component to obtain the third public key component corresponding to the server, update the third public key component with the second public key component, and receive a new dual-track validity certificate sent by the server corresponding to the third public key component.

[0087] The certificate switching module is used to switch to the new dual-track function certificate and set the expiration time for the original dual-track function certificate.

[0088] This invention also discloses a security update device for IoT devices, comprising:

[0089] The firmware sharding module is used to respond to an OTA request sent by an IoT device, obtain the target firmware corresponding to the OTA request, and shard the target firmware to obtain a number of corresponding firmware shards.

[0090] The firmware encryption module is used to encrypt each firmware fragment and then construct the corresponding update data packet.

[0091] The data packet encryption module is used to dynamically generate a temporary session key for the updated data packet, and use the temporary session key to encrypt the updated data packet to obtain the corresponding encrypted data packet;

[0092] A data packet sending module is used to send the encrypted data packet to the IoT device.

[0093] In some feasible implementations, the firmware encryption module is specifically used for:

[0094] Obtain the fragment size for the firmware fragment, and divide the firmware fragment into several data blocks according to the fragment size;

[0095] Calculate the block hash value corresponding to the data block, and use the block hash value as the leaf node;

[0096] The leaf nodes are grouped in pairs, and two adjacent leaf nodes are concatenated to obtain the corresponding target block hash value, and the target block hash value is used as a new leaf node.

[0097] Return to the process of grouping the leaf nodes in pairs, splicing two adjacent leaf nodes to obtain the corresponding target block hash value, until the root node corresponding to the firmware fragment is generated, and the root node is used as the trusted root hash value.

[0098] Obtain the vendor key corresponding to the target firmware;

[0099] The trusted root hash value is digitally signed using the vendor key to obtain signature data;

[0100] At least the fragment size, the signature data, and the trusted root hash value are integrated to obtain the corresponding update data packet.

[0101] In some feasible implementations, the apparatus further includes:

[0102] A public key acquisition module is used to acquire the first public key component corresponding to the IoT device;

[0103] The public key calculation module is used to obtain the second private key component corresponding to the server and calculate the second public key component corresponding to the second private key component.

[0104] A public key combination module is used to combine the first public key component and the second public key component to obtain a first target public key;

[0105] The certificate issuance module is used to obtain the root certificate corresponding to the target firmware, and to issue a dual-track certificate by using the first target public key and the root certificate, and to issue the dual-track certificate to the IoT device.

[0106] The dual-track validity certificate includes at least a traditional ECC signature and a post-quantum certificate.

[0107] Among some feasible implementation methods, it also includes

[0108] The public key update module is used to generate a new second private key component and calculate the third public key component corresponding to the new second private key component if the dual-track validity certificate expires or a security risk is detected in the IoT device.

[0109] A public key combination module is used to combine the third public key component and the first public key component to obtain a second target public key;

[0110] The certificate update module is used to sign a new dual-track certificate using the second target public key and the root certificate, and then issue the new dual-track certificate to the IoT device.

[0111] This invention also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0112] The memory is used to store computer programs;

[0113] When the processor executes a program stored in the memory, it implements the method described in the embodiments of the present invention.

[0114] This invention also discloses a computer-readable storage medium storing instructions that, when executed by one or more processors, cause the processors to perform the methods described in this invention.

[0115] The embodiments of the present invention have the following advantages:

[0116] In this embodiment of the invention, when an IoT device needs to perform an OTA update, it can send a corresponding OTA request to the server and obtain an encrypted update package corresponding to the OTA request returned by the server. The encrypted update package is a data packet encrypted by the server using a temporary session key. Then, a target private key for the temporary session key is dynamically generated, and the encrypted update package is decrypted using the target private key and the temporary session key to obtain the corresponding firmware fragment. If the integrity of each firmware fragment is verified, all firmware fragments are reassembled to obtain the corresponding updated firmware. The legality of the updated firmware is verified using a locally stored dual-track certificate. If the legality of the updated firmware is verified, the update operation corresponding to the updated firmware is executed. Thus, during the OTA update process of the device, the updated firmware is protected by dynamically synthesized keys and dual-track certificates, achieving zero key storage risk and quantum-level security protection, optimizing the certificate processing method, and improving the security and reliability of IoT device firmware updates. Attached Figure Description

[0117] Figure 1 This is a flowchart illustrating the steps of a security update method for an Internet of Things (IoT) device provided in an embodiment of the present invention.

[0118] Figure 2 This is a flowchart illustrating the steps of a security update method for an Internet of Things (IoT) device provided in an embodiment of the present invention.

[0119] Figure 3 This is a schematic diagram of the OTA update process provided in an embodiment of the present invention;

[0120] Figure 4 This is a structural block diagram of a security update device for an Internet of Things (IoT) device provided in an embodiment of the present invention;

[0121] Figure 5 This is a structural block diagram of a security update device for an Internet of Things (IoT) device provided in an embodiment of the present invention. Detailed Implementation

[0122] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0123] As an example, at least one of the following problems exists during the OTA update process for IoT devices:

[0124] 1. Risk of static key storage: The device is pre-installed with a complete private key. Attackers can obtain the key through physical extraction or side-channel attacks, leading to system-level security failure.

[0125] 2. Rigid certificate renewal: Certificates have a fixed validity period, and expired equipment needs to be returned to the factory for reprogramming, resulting in high maintenance costs and service interruptions;

[0126] 3. Lack of quantum defense: The algorithm cannot resist quantum computing attacks, upgrades require hardware replacement, and there is a lack of smooth migration path.

[0127] In this invention, when an IoT device needs an OTA update, it can send a corresponding OTA request to the server and obtain an encrypted update package corresponding to the OTA request returned by the server. The encrypted update package is a data packet encrypted by the server using a temporary session key. Then, a target private key for the temporary session key is dynamically generated, and the encrypted update package is decrypted using the target private key and the temporary session key to obtain the corresponding firmware fragment. If the integrity of each firmware fragment is verified, all firmware fragments are reassembled to obtain the corresponding updated firmware. The legality of the updated firmware is verified using a locally stored dual-track certificate. If the legality of the updated firmware is verified, the update operation corresponding to the updated firmware is executed. Thus, during the OTA update process, the updated firmware is protected by dynamically synthesized keys and dual-track certificates, achieving zero key storage risk and quantum-level security protection, optimizing the certificate processing method, and improving the security and reliability of IoT device firmware updates.

[0128] Reference Figure 1 This diagram illustrates a flowchart of a security update method for an IoT device provided in an embodiment of the present invention. The method can be applied to IoT devices and specifically includes the following steps:

[0129] Step 101: In response to sending an OTA request to the server, obtain the encrypted update package corresponding to the OTA request, wherein the encrypted update package is a data packet encrypted by the server using a temporary session key;

[0130] For IoT devices, OTA updates can effectively improve security, extend product lifecycle, and enhance user experience. During an OTA update, IoT devices remotely update, repair, or upgrade their firmware using wireless communication methods such as WiFi (Wireless Fidelity), cellular networks, Bluetooth, and LoRa (Long Range). When an OTA update is triggered, the IoT device sends a corresponding OTA request to the server to obtain the updated firmware for the update.

[0131] In some feasible implementations, when an IoT device is first started, in response to the first startup of the IoT device, a device identifier corresponding to the IoT device can be generated by random number generation, and a first private key component corresponding to the device identifier can be generated using elliptic curve cryptography. The first public key component corresponding to the first private key component is calculated, and then the first public key component is sent to the server. The server sends a dual-track certificate corresponding to the first public key component. The dual-track certificate is a certificate issued by the server using the first public key component corresponding to the IoT device, the second public key component corresponding to the server, and the root certificate. The dual-track certificate includes at least a traditional ECC (Elliptic Curve Cryptography) signature and a post-quantum certificate.

[0132] For the server, it can obtain the first public key component sent by the IoT device, generate a complementary second private key component based on the first public key component, calculate the second public key component corresponding to the second private key component, and then combine the first public key component and the second public key component to obtain the corresponding first target public key. Then, it obtains the root certificate corresponding to the target firmware (i.e., the firmware used for OTA updates of IoT devices), and issues a corresponding dual-track certificate using the first target public key and the root certificate. Then, it sends the dual-track certificate to the corresponding IoT device. The dual-track certificate includes at least a traditional ECC signature and a post-quantum certificate, so that it can be bound to the corresponding firmware through the dual-track certificate, which facilitates the IoT device to verify the legality of the firmware during the OTA update process.

[0133] In the key generation process described above, for IoT devices, a unique device identifier can be generated by random number generation upon initial startup. Different IoT devices generate different device identifiers. Then, based on this device identifier, elliptic curve cryptography is used to generate the corresponding first private key component d1. At the same time, a corresponding cryptographic algorithm is used to derive the corresponding first public key component P1 from the first private key component d1. For example, the cryptographic algorithm can be a function G(x), where x can be a private key component, then P1 = G(d1), etc. After the corresponding first public key component is generated, it can be uploaded to the server through a secure channel (such as TLS) so that the server can generate corresponding key components and issue certificates based on the first public key component.

[0134] Accordingly, after receiving the first public key component P1 sent by the IoT device, the server can perform deterministic calculations within the hardware security module using multi-source data such as the first public key component P1, the device identifier corresponding to the IoT device, the master key seed, and the derived context key, through key derivation functions (such as KDF). After domain adjustment, the server generates the corresponding second private key component d2. Then, it uses the same cryptographic algorithm as the IoT device to derive the corresponding second public key component P2, i.e., P2 = G(d2). The server can then combine the complete first target public key P = P1 + P2 and issue a dual-track certificate using a root CA (Certificate Authority) certificate. This dual-track certificate can include at least traditional ECC signatures and post-quantum signatures. The server then distributes this certificate to the IoT device, ensuring that the IoT device only stores the first private key component d1 and the certificate, while the server only stores the second private key component and the certificate. This ensures that the private key d = d1 + d2 is not completely stored on either device, achieving zero key storage risk.

[0135] In some examples, for IoT devices, a cryptographically secure pseudo-random number generator can be invoked to generate a 16-byte globally unique device identifier (Device ID). This identifier serves as the root seed for the entire key derivation process of the IoT device. Then, an HMAC-based Key Derivation Function (HKDF) is used, coupled with the SHA256 hash algorithm, to perform deterministic derivation processing on the generated device identifier, transforming it into a fixed-length 32-byte private key seed. This ensures the output conforms to the requirements of elliptic curve cryptography, improving the accuracy of the key generation process. The derived private key seed byte sequence can then be interpreted as an integer and loaded as a scalar value onto a specified elliptic curve (e.g., secp256r1) to generate the corresponding first private key component d1. Finally, by performing elliptic curve scalar multiplication, the first private key component d1 generated is multiplied by the preset base point G of the curve to calculate the corresponding first public key component, thereby enabling the IoT device to obtain a cryptographically strong asymmetric key pair bound to its identity.

[0136] Upon receiving the first public key component P1 and device identifier from the IoT device, the server can initiate a secure and deterministic key derivation process to generate a matching second public key component. Specifically, the server can combine P1 sent by the IoT device, the device ID, a pre-configured master key seed, and a derivation context string indicating the purpose of this derivation (e.g., "iot_device_d2_derivation_v1"). These data collectively ensure the uniqueness and determinism of each derivation—that is, the same input will always produce the same output, but different devices or different contexts will produce completely unrelated keys. Next, the aggregated data can be fed into a key derivation function (KDF, such as an HMAC-based KDF) deployed within the Hardware Security Module (HSM). This ensures, through the HSM's protection, that the master key seed is never exposed in plaintext in the server's general memory, and that the entire computation process is executed in a physically tamper-proof secure environment. Accordingly, the output of KDF is a raw key material, which is then normalized through field adjustment (e.g., treating it as the order n of the large integer modulo elliptic curve) into a standard second private key component d2 within the valid private key range of the elliptic curve. Based on the generated second private key component d2, the server can use an elliptic curve cryptography algorithm identical to that of the IoT device (e.g., the same secp256r1 curve and base point G) to derive the corresponding second public key component P2. At this point, the server possesses the first public key component P1 corresponding to the IoT device and its own generated second public key component P2. It can then further utilize the commutative homomorphic property of elliptic curve point addition to add these two points together to synthesize the complete first target public key P = P1 + P2. From a cryptographic perspective, the complete private key d corresponding to the first target public key P is composed of the first private key component d1 of the IoT device and the second private key component d2 of the server, generated in a corresponding manner (such as d = (d1 + d2) mod n). However, the complete d does not exist in either the IoT device or the server at any given time, which greatly enhances security.

[0137] Finally, the Certification Authority (CA) can use this synthesized public key P as the public key for the certificate body to issue a corresponding dual-signature certificate. This certificate contains both signatures:

[0138] Traditional ECC signing: The certificate content is signed using the CA's own traditional ECC private key (such as RSA or ecdsa), ensuring full compatibility with existing Internet PKI (Public Key Infrastructure) infrastructure and TLS (Transport Layer Security) stack.

[0139] Post-quantum (PQ) signature: At the same time, the CA uses its quantum-resistant private key (such as the lattice-based, hash-based Dilithium or SPHINCS+ algorithm) to generate a post-quantum signature for the same content and embeds it in the extended field of the certificate.

[0140] In the above process, the IoT device stores the corresponding first private key component and dual-track certificate locally, while the server stores the corresponding second private key component and dual-track certificate. When the IoT device initiates an OTA request, the server can obtain the target firmware corresponding to the OTA request, fragment the target firmware to obtain several corresponding firmware fragments, encrypt each firmware fragment, construct the corresponding update data packet, dynamically generate a temporary session key for the update data packet, and use the temporary session key to encrypt the update data packet to obtain the corresponding encrypted data packet. The encrypted data packet is then sent to the IoT device so that after receiving the corresponding encrypted data packet, the IoT device can decrypt it based on the stored first private key component to obtain the corresponding update data packet, and then perform legality verification based on the dual-track certificate to confirm the integrity and legality of the firmware, thereby improving the security and reliability of IoT device firmware updates.

[0141] In some feasible implementations, after obtaining the update firmware corresponding to the OTA request, the server can obtain the fragment size for the firmware fragment, divide the firmware fragment into several data blocks according to the fragment size, calculate the block hash value corresponding to the data block, use the block hash value as a leaf node, then group the leaf nodes pairwise, concatenate two adjacent leaf nodes to obtain the corresponding target block hash value, and use the target block hash value as a new leaf node. This process of grouping leaf nodes pairwise and concatenating two adjacent leaf nodes to obtain the corresponding target block hash value continues until the root node corresponding to the firmware fragment is generated. The root node is used as the trusted root hash value, and then the vendor key corresponding to the target firmware is obtained and... The trusted root hash value is digitally signed using the vendor key to obtain signature data. Finally, at least the fragment size, signature data, and trusted root hash value are integrated to obtain the corresponding update data packet. By constructing the corresponding Merkle tree (i.e., generating a unique "fingerprint" representing the firmware fragment—the trusted root hash value) and signing the "fingerprint" using the vendor key, it is effectively proven that the update packet comes from a legitimate vendor and has not been tampered with, ensuring the integrity and authenticity of the data. At the same time, the fragmentation method supports streaming transmission and block-by-block verification, improving memory efficiency and fault tolerance. In addition, the size of the data block can be flexibly adjusted to adapt to different network environments and device capabilities, improving the adaptability of the scenario.

[0142] Optionally, after obtaining the corresponding updated firmware, the server can fragment it according to actual needs, obtaining several firmware fragments. Then, it can further obtain the corresponding fragment size, and divide each firmware fragment into several data blocks according to the fragment size. After that, it can construct the corresponding Merkle hash tree, so that each fragment is associated with a corresponding Merkle Proof. The specific process can be as follows:

[0143] First, the firmware binary file to be upgraded is divided into multiple data blocks of a fixed size (e.g., 4KB): B0, B1, B2, ..., Bn-1. The size of each block can be flexibly adjusted based on network efficiency and device memory usage, and this invention does not impose any limitations on this.

[0144] Next, for each data block B i Calculate cryptographic hash values ​​(such as SHA-256), each hash value H i =Hash(B i These form the leaf nodes of the Merkle tree.

[0145] Then, the leaf nodes are grouped in pairs, adjacent hash values ​​are concatenated, their hash values ​​are calculated, and a parent node (intermediate node) is generated. This process is executed recursively until a unique root node (MerkleRootHash) is generated. During the recursion, if the number of leaf nodes is odd, the last node is copied and paired with itself (or paired with an empty value).

[0146] Finally, the generated MerkleRootHash(R) can be digitally signed using the vendor's private key. The signed data (Sig) is then combined with metadata such as firmware version and fragment size to form the firmware header. The trusted root hash value is integrated to obtain the corresponding update data packet. By constructing the corresponding Merkle tree (i.e., generating a unique "fingerprint" representing the firmware fragment—the trusted root hash value), and signing the "fingerprint" with the vendor's key, it is effectively proven that the update packet comes from a legitimate vendor and has not been tampered with, ensuring the integrity and authenticity of the data. At the same time, the fragmentation method supports streaming transmission and block-by-block verification, improving memory efficiency and fault tolerance. In addition, the size of the data block can be flexibly adjusted to adapt to different network environments and device capabilities, improving the adaptability of the scenario.

[0147] Furthermore, after receiving the update data packet, to ensure data transmission security, the server can generate a corresponding temporary session key and encrypt the update data packet based on this temporary session key to obtain the corresponding encrypted data packet. This encrypted data packet is then transmitted to the IoT device, thus ensuring data transmission security. The temporary session key can be a symmetric encryption key, which is dynamically generated by the server during the session with the IoT device. The server uses this temporary session key to encrypt the update data packet, while the IoT device uses the same temporary session key to decrypt the encrypted data packet.

[0148] Step 102: Dynamically generate a target private key for the temporary session key, and use the target private key and the temporary session key to decrypt the encrypted update package to obtain the corresponding firmware fragment;

[0149] After receiving an encrypted data packet from the server, the IoT device can dynamically generate a target private key for the temporary session key, and use this target private key to decrypt the temporary session key to obtain the corresponding update data packet. It can then extract the corresponding firmware fragment from this update data packet. This data transmission process based on the temporary session key effectively ensures data transmission security. In particular, during OTA updates, fragmented transmission can improve data transmission efficiency.

[0150] In some feasible implementations, IoT devices can obtain the second private key component corresponding to the server, and synthesize it with the first private key component generated by themselves to obtain the target private key for the temporary session key. Then, they can use the target private key to decrypt the temporary session key to obtain the corresponding update data packet, and extract the corresponding firmware fragment from the update data packet for further integrity verification of the firmware fragment.

[0151] In some examples, in conjunction with the foregoing embodiments, the data encryption and transmission process corresponding to the server may include the following implementation process:

[0152] 1. Prepare for update: The server prepares the firmware update data package F.

[0153] 2. Generate session key: The server randomly generates a temporary session key K_session (e.g., an AES-256 key).

[0154] 3. Encrypting data packets: The server uses K_session and a symmetric encryption algorithm (such as AES-GCM) to encrypt F, resulting in an encrypted data packet Enc(F).

[0155] Enc(F)=AES_Encrypt(K_session,F)

[0156] 4. Perform key exchange:

[0157] In one possible implementation, the server randomly generates a one-time temporary private key d_s_temp and calculates the corresponding temporary public key P_s_temp = d_s_temp * G. Then, using the complete public key P = P1 + P2 and its own second private key component d2, a shared secret S is generated through a series of calculations (possibly involving homomorphic operations), and a key encryption key K_enc is derived from the shared secret S. Finally, K_enc is used to encrypt the session key K_session, resulting in the encrypted session key Enc(K_session).

[0158] In another possible implementation, the server can directly calculate P_d_temp = d_s_temp * P (where P is the device's complete public key), and the x-coordinate of this P_d_temp is the shared secret S.

[0159] Finally, the server sends Enc(F), Enc(K_session), and its temporary public key P_s_temp to the device.

[0160] Furthermore, after receiving the encrypted data packet, the corresponding decryption process for the IoT device includes:

[0161] 1. Data reception: The device receives Enc(F), Enc(K_session) and P_s_temp.

[0162] 2. Enter TEE (Trusted Execution Environment): The device transfers sensitive operations to the TEE (Trusted Execution Environment) for execution.

[0163] 3. Dynamically synthesizing a complete private key: In the TEE, the device combines its own d1 with some information sent by the server (or combines the shared knowledge of d1 and d2 stored locally) to dynamically synthesize a one-time complete private key d. For example, d = (d1 + d2) mod n (assuming it is synthesized by addition).

[0164] During this process, d exists only in the TEE memory and is used only for this calculation. It is destroyed immediately after the calculation is completed and is never persisted anywhere in its complete form, which greatly improves security.

[0165] 4. Calculate the shared secret: In the TEE, the device uses the synthesized complete private key d and the temporary public key P_s_temp sent by the server to calculate the same shared secret S. Where S = d * P_s_temp (according to ECC principles, d * P_s_temp = d * (d_s_temp * G) = d_s_temp * (d * G) = d_s_temp * P, which is the same as the result calculated by the server).

[0166] 5. Derivation of decryption key: The device uses the same algorithm as the server to derive the encryption key K_enc from the shared secret S.

[0167] 6. Decrypt the session key: The device decrypts Enc(K_session) with K_enc to obtain the plaintext temporary session key K_session.

[0168] K_session=AES_Decrypt(K_enc, Enc(K_session))

[0169] 7. Decrypt the data packet: The device finally uses K_session to decrypt Enc(F) to obtain the original firmware data packet F, such as F = AES_Decrypt(K_session, Enc(F)).

[0170] After the IoT device leaves the TEE, the digital signature of the decrypted firmware F is verified using a dual-track validity certificate in a normal environment to confirm its integrity and legitimacy.

[0171] Step 103: If the integrity of each firmware segment passes verification, all firmware segments are reassembled to obtain the corresponding updated firmware. The legality of the updated firmware is verified using the locally stored dual-track validity certificate. If the legality of the updated firmware passes verification, the update operation corresponding to the updated firmware is executed.

[0172] After decrypting the corresponding firmware fragments through the above process, the IoT device can verify the integrity of the firmware fragments. Once the integrity verification of any firmware fragment is successful, the IoT device can use that firmware fragment or continue to download the next firmware fragment. After the integrity verification of all firmware fragments is successful, all firmware fragments are reassembled to obtain the corresponding updated firmware. Then, the legality of the updated firmware is verified using a locally stored dual-track certificate. If the legality verification of the updated firmware is successful, the update operation corresponding to the updated firmware is executed. Thus, during the OTA update process, the updated firmware is protected by dynamically synthesized keys and dual-track certificates, achieving zero key storage risk and quantum-level security protection, optimizing the certificate processing method, and improving the security and reliability of IoT device firmware updates.

[0173] In some feasible implementations, the server divides each firmware fragment into several data blocks. During the integrity verification of the firmware fragments, the IoT device can first obtain the firmware mapping header corresponding to the firmware fragment. The firmware mapping header includes the trusted root hash value and the block index corresponding to the data block. Then, iterative calculation is performed based on the block hash value and the block index to obtain the target root hash value corresponding to the firmware fragment. If the target root hash value is the same as the trusted root hash value, the next firmware fragment is obtained, and the process of iterative calculation based on the block hash value and the block index to obtain the target root hash value corresponding to the firmware fragment is returned until all firmware fragments have completed integrity verification. If the integrity of each firmware fragment passes the verification, all firmware fragments are reassembled to obtain the corresponding updated firmware. Thus, in the OTA update process, by performing integrity verification on each firmware fragment one by one, efficient streaming verification and memory optimization are achieved. At the same time, the Merkle tree can effectively guarantee data integrity and real-time error detection, and the trusted root hash value can effectively verify the integrity of potentially very large firmware fragments, minimizing trust overhead.

[0174] In a concrete implementation, for the above iterative calculation process, the IoT device can select any data block as the current data block. Then, starting from the current data block, it concatenates the block hash values ​​of adjacent data blocks according to the block index to obtain the current block hash value. This process of concatenating the block hash values ​​of adjacent data blocks according to the block index is repeated until all the hash values ​​corresponding to all data blocks in the firmware fragment are exhausted, thus obtaining the target root hash value corresponding to the firmware fragment. For example, the corresponding integrity verification process may include:

[0175] IoT devices can calculate the corresponding hash value (e.g., SHA-256) for each data block in the decrypted firmware fragment, obtaining H_i = Hash(data_chunk, data block), and perform iterative calculations starting from the calculated hash value. During the iterative calculation process, the IoT device can sequentially retrieve each provided adjacent hash value from the MerkleProof array and determine the concatenation order for each step based on the chunk_index of the current fragment. If the current node's position is even (left), it is concatenated as Hash(H_current||Proof_Node)(current hash value|proof node); if the current node's position is odd (right), it is concatenated as Hash(Proof_Node||H_current)(proof node|current hash value), and then the calculation result is used as the new H_current (current hash value), and the same operation is continued with the next hash value in MerkleProof until all leaf nodes in the MerkleProof array are exhausted. After the above iterative calculation, a final calculation result Calculated_Root (i.e., the target root hash) is obtained. Then, this Calculated_Root (target root hash) can be compared with the trusted_Root (trusted root hash) decrypted from the signed firmware header. If Calculated_Root == Trusted_Root: this proves that the current fragment is complete, tamper-proof, and part of the original firmware, and the IoT device can apply the fragment or continue downloading the next fragment; if Calculated_Root ! = Trusted_Root: this proves that verification failed, and the IoT device can immediately abort the OTA process and report a verification failure error to the server. A verification failure could mean that the fragment data was corrupted during transmission or suffered a man-in-the-middle attack.

[0176] After the integrity of the firmware fragments is fully verified through the above process, if all firmware fragments pass the verification, the IoT device can assemble all firmware fragments to obtain the corresponding updated firmware, and use the locally stored dual-track validity certificate to verify the legality of the updated firmware. If the legality verification of the updated firmware passes, the update operation corresponding to the updated firmware is executed.

[0177] In some feasible implementations, IoT devices can first extract the target vendor signature corresponding to the updated firmware, and then compare the target vendor signature with the vendor signature contained in the dual-track validity certificate. If the target vendor signature matches the trusted vendor signature corresponding to the dual-track validity certificate, the update operation corresponding to the updated firmware is executed. Thus, during the OTA update process, the updated firmware is protected by dynamically synthesized keys and dual-track validity certificates, achieving zero key storage risk and quantum-level security protection, optimizing the certificate processing method, and improving the security and reliability of IoT device firmware updates.

[0178] Furthermore, if the dual-track validity certificate expires or a security risk is detected in the IoT device, the system obtains the third private key component sent by the server, the first public key component corresponding to the IoT device, and the second public key component corresponding to the server. Then, it calculates the third public key component corresponding to the server using the third private key component, updates the third public key component with the second public key component, and receives a new dual-track validity certificate corresponding to the third public key component sent by the server. Finally, it switches to the new dual-track validity certificate, sets an expiration time for the original dual-track validity certificate, and proactively issues a new public key component by monitoring the status certificate. This allows the IoT device to recalculate the new public key component through a secure channel and synchronously update the certificate chain, achieving seamless certificate updates and ensuring forward security.

[0179] It should be noted that the embodiments of the present invention include, but are not limited to, the examples described above. It is understood that those skilled in the art can make further settings according to actual needs under the guidance of the ideas in the embodiments of the present invention, and the present invention does not limit such settings.

[0180] In this embodiment of the invention, when an IoT device needs to perform an OTA update, it can send a corresponding OTA request to the server and obtain an encrypted update package corresponding to the OTA request returned by the server. The encrypted update package is a data packet encrypted by the server using a temporary session key. Then, a target private key for the temporary session key is dynamically generated, and the encrypted update package is decrypted using the target private key and the temporary session key to obtain the corresponding firmware fragment. If the integrity of each firmware fragment is verified, all firmware fragments are reassembled to obtain the corresponding updated firmware. The legality of the updated firmware is verified using a locally stored dual-track certificate. If the legality of the updated firmware is verified, the update operation corresponding to the updated firmware is executed. Thus, during the OTA update process of the device, the updated firmware is protected by dynamically synthesized keys and dual-track certificates, achieving zero key storage risk and quantum-level security protection, optimizing the certificate processing method, and improving the security and reliability of IoT device firmware updates.

[0181] Reference Figure 2 This diagram illustrates a flowchart of a security update method for an Internet of Things (IoT) device provided in an embodiment of the present invention. This method can be applied to a server and specifically includes the following steps:

[0182] Step 201: In response to receiving an OTA request sent by an IoT device, obtain the target firmware corresponding to the OTA request, and segment the target firmware to obtain a number of corresponding firmware segments.

[0183] Step 202: After encrypting each firmware fragment, construct the corresponding update data packet;

[0184] Step 203: Dynamically generate a temporary session key for the update data packet, and use the temporary session key to encrypt the update data packet to obtain the corresponding encrypted data packet;

[0185] Step 204: Send the encrypted data packet to the IoT device.

[0186] In some feasible implementations, the step of constructing the corresponding update data packet after encrypting each firmware fragment includes:

[0187] Obtain the fragment size for the firmware fragment, and divide the firmware fragment into several data blocks according to the fragment size;

[0188] Calculate the block hash value corresponding to the data block, and use the block hash value as the leaf node;

[0189] The leaf nodes are grouped in pairs, and two adjacent leaf nodes are concatenated to obtain the corresponding target block hash value, and the target block hash value is used as a new leaf node.

[0190] Return to the process of grouping the leaf nodes in pairs, splicing two adjacent leaf nodes to obtain the corresponding target block hash value, until the root node corresponding to the firmware fragment is generated, and the root node is used as the trusted root hash value.

[0191] Obtain the vendor key corresponding to the target firmware;

[0192] The trusted root hash value is digitally signed using the vendor key to obtain signature data;

[0193] At least the fragment size, the signature data, and the trusted root hash value are integrated to obtain the corresponding update data packet.

[0194] In some feasible implementations, before obtaining the target firmware corresponding to the OTA request in response to receiving an OTA request from an IoT device, the method further includes:

[0195] Obtain the first public key component corresponding to the IoT device;

[0196] Obtain the second private key component corresponding to the server, and calculate the second public key component corresponding to the second private key component;

[0197] Combine the first public key component and the second public key component to obtain the first target public key;

[0198] Obtain the root certificate corresponding to the target firmware, and use the first target public key and the root certificate to sign the dual-track certificate to obtain a dual-track certificate, and issue the dual-track certificate to the IoT device.

[0199] The dual-track validity certificate includes at least a traditional ECC signature and a post-quantum certificate.

[0200] Among some feasible implementation methods, it also includes

[0201] If the dual-track validity certificate expires or a security risk is detected in the IoT device, a new second private key component is generated, and the third public key component corresponding to the new second private key component is calculated.

[0202] By combining the third public key component and the first public key component, a second target public key is obtained;

[0203] The second target public key and the root certificate are used to issue a new dual-track certificate, and the new dual-track certificate is then issued to the IoT device.

[0204] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the following examples are provided for illustrative purposes:

[0205] As an example, refer to Figure 3 The diagram illustrates an OTA update process provided in an embodiment of the present invention, which may include:

[0206] 1. Device-side key component generation (initialization phase)

[0207] When the device is first started, a unique device identifier is generated using a random number, and a private key component d1 is generated based on this identifier using elliptic curve cryptography (ECC). The corresponding public key component P1 = G(d1) is calculated and uploaded to the cloud via a secure channel (such as TLS).

[0208] 2. Cloud-based key component generation and certificate issuance

[0209] A complementary private key component d2 is generated in the cloud, and the public key component P2 = G(d2) is calculated. The complete public key P = P2 + P2 is combined, and a dual-track validity certificate (including traditional ECC signature + post-quantum signature) is issued using the root CA certificate. The certificate is distributed to the device, which only stores d1 and the certificate, while the cloud stores d2, ensuring that the private key d = d1 + d2 is never stored incompletely.

[0210] 3. OTA firmware signing and fragment encryption

[0211] The cloud performs a hash calculation (SHA-256) on the firmware and signs it using the manufacturer's private key to generate firmware metadata (version number, signature, etc.). The firmware is then fragmented, and a Merkle hash tree is constructed, with each fragment accompanied by a corresponding MerkleProof. When the device initiates an OTA request, the cloud dynamically generates a temporary session key K through ECDH key exchange to encrypt and transmit the firmware fragments.

[0212] 4. Device firmware verification and decryption

[0213] After receiving the encrypted firmware fragments, the device dynamically synthesizes a private key d = d1 + d2 within the TEE secure environment, which is used to decrypt the session key K. After decrypting the firmware fragments, MerkleProof is used to verify their integrity piece by piece, ensuring they have not been tampered with. Once all fragments have passed verification, the complete firmware is reassembled, and a dual-track certificate is used to verify the vendor signature, confirming the firmware's legitimacy.

[0214] 5. Seamless certificate update (dynamic key rotation)

[0215] When a certificate is about to expire or a security risk is detected (such as a private key leak), a new private key component d2' is generated in the cloud and encrypted before being pushed to the device. The device calculates the new public key P' = P1 + P2', the cloud issues and distributes a new certificate, and the device seamlessly switches to the new certificate. The old certificate is added to a short-term CRL (expiring within 5 minutes). The old private key component d2 is immediately destroyed to ensure forward security.

[0216] Through the above process, during the OTA update of the device, the updated firmware is protected by dynamically synthesized keys and dual-track power certificates, achieving zero key storage risk and quantum-level security protection, optimizing the certificate processing method, and improving the security and reliability of firmware updates for IoT devices.

[0217] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0218] Reference Figure 4 The diagram illustrates a structural block diagram of a security update device for an Internet of Things (IoT) device provided in an embodiment of the present invention, which may specifically include the following modules:

[0219] The data packet request module 401 is used to respond to sending an OTA request to the server and obtain an encrypted update packet corresponding to the OTA request, wherein the encrypted update packet is a data packet encrypted by the server using a temporary session key;

[0220] The decryption module 402 is used to dynamically generate a target private key for the temporary session key, and use the target private key and the temporary session key to decrypt the encrypted update package to obtain the corresponding firmware fragment;

[0221] The verification module 403 is used to reassemble all the firmware fragments to obtain the corresponding updated firmware if the integrity of each firmware fragment passes the verification, and to verify the legality of the updated firmware using a locally stored dual-track validity certificate. If the legality of the updated firmware passes the verification, the module executes the update operation corresponding to the updated firmware.

[0222] In some feasible implementations, the firmware fragment includes several data blocks, and the verification module 403 is specifically used for:

[0223] Obtain the firmware mapping header corresponding to the firmware fragment, wherein the firmware mapping header includes a trusted root hash value;

[0224] Obtain the block index corresponding to the data block, and calculate the block hash value corresponding to each data block;

[0225] The target root hash value corresponding to the firmware fragment is obtained by iteratively calculating based on the block hash value and the block index.

[0226] If the target root hash value is the same as the trusted root hash value, then obtain the next firmware fragment of the firmware fragment;

[0227] Return to the process of iteratively calculating the target root hash value corresponding to the firmware fragment based on the block hash value and the block index, until all firmware fragments have completed integrity verification;

[0228] If the integrity of each firmware segment passes verification, then all firmware segments are reassembled to obtain the corresponding updated firmware.

[0229] In some feasible implementations, the verification module 403 is specifically used for:

[0230] Select any of the data blocks as the current data block;

[0231] Starting with the current data block, the block hash values ​​of adjacent data blocks are concatenated according to the block index to obtain the current block hash value. The process of concatenating the block hash values ​​of adjacent data blocks according to the block index is returned until all the hash values ​​corresponding to the data blocks in the firmware fragment are exhausted, and the target root hash value corresponding to the firmware fragment is obtained.

[0232] In some feasible implementations, the decryption module 402 is specifically used for:

[0233] Obtain the first private key component corresponding to the IoT device;

[0234] Obtain the second private key component corresponding to the server;

[0235] The first private key component and the second private key component are combined to obtain the target private key for the temporary session key.

[0236] Among some feasible implementation methods are:

[0237] The private key generation module is used to generate a device identifier corresponding to the IoT device by random number in response to the first startup of the IoT device, and to generate a first private key component corresponding to the device identifier by elliptic curve cryptography.

[0238] The public key calculation module is used to calculate the first public key component corresponding to the first private key component;

[0239] The certificate acquisition module is used to send the first public key component to the server and receive a dual-track certificate corresponding to the first public key component sent by the server. The dual-track certificate is a certificate issued by the server using the first public key component corresponding to the IoT device, the second public key component corresponding to the server, and the root certificate. The dual-track certificate includes at least a traditional ECC signature and a post-quantum certificate.

[0240] In some feasible implementations, the verification module 403 is specifically used for:

[0241] Extract the target manufacturer signature corresponding to the updated firmware;

[0242] Obtain the dual-track efficacy certificate stored locally. If the target vendor signature matches the trusted vendor signature corresponding to the dual-track efficacy certificate, then perform the update operation corresponding to the updated firmware.

[0243] Among some feasible implementation methods are:

[0244] The private key acquisition module is used to acquire the third private key component sent by the server if the dual-track validity certificate expires or if a security risk is detected in the IoT device.

[0245] The public key acquisition module is used to acquire the first public key component corresponding to the IoT device and the second public key component corresponding to the server.

[0246] The public key update module is used to calculate using the third private key component to obtain the third public key component corresponding to the server, update the third public key component with the second public key component, and receive a new dual-track validity certificate sent by the server corresponding to the third public key component.

[0247] The certificate switching module is used to switch to the new dual-track function certificate and set the expiration time for the original dual-track function certificate.

[0248] Reference Figure 5 The diagram illustrates a structural block diagram of a security update device for an Internet of Things (IoT) device provided in an embodiment of the present invention, which may specifically include the following modules:

[0249] Firmware sharding module 501 is used to respond to receiving an OTA request sent by an IoT device, obtain the target firmware corresponding to the OTA request, and shard the target firmware to obtain a number of corresponding firmware shards.

[0250] Firmware encryption module 502 is used to encrypt each firmware fragment and then construct the corresponding update data packet.

[0251] The data packet encryption module 503 is used to dynamically generate a temporary session key for the updated data packet, and use the temporary session key to encrypt the updated data packet to obtain the corresponding encrypted data packet;

[0252] A data packet sending module is used to send the encrypted data packet to the IoT device.

[0253] In some feasible implementations, the firmware encryption module 502 is specifically used for:

[0254] Obtain the fragment size for the firmware fragment, and divide the firmware fragment into several data blocks according to the fragment size;

[0255] Calculate the block hash value corresponding to the data block, and use the block hash value as the leaf node;

[0256] The leaf nodes are grouped in pairs, and two adjacent leaf nodes are concatenated to obtain the corresponding target block hash value, and the target block hash value is used as a new leaf node.

[0257] Return to the process of grouping the leaf nodes in pairs, splicing two adjacent leaf nodes to obtain the corresponding target block hash value, until the root node corresponding to the firmware fragment is generated, and the root node is used as the trusted root hash value.

[0258] Obtain the vendor key corresponding to the target firmware;

[0259] The trusted root hash value is digitally signed using the vendor key to obtain signature data;

[0260] At least the fragment size, the signature data, and the trusted root hash value are integrated to obtain the corresponding update data packet.

[0261] In some feasible implementations, the apparatus further includes:

[0262] A public key acquisition module is used to acquire the first public key component corresponding to the IoT device;

[0263] The public key calculation module is used to obtain the second private key component corresponding to the server and calculate the second public key component corresponding to the second private key component.

[0264] A public key combination module is used to combine the first public key component and the second public key component to obtain a first target public key;

[0265] The certificate issuance module is used to obtain the root certificate corresponding to the target firmware, and to issue a dual-track certificate by using the first target public key and the root certificate, and to issue the dual-track certificate to the IoT device.

[0266] The dual-track validity certificate includes at least a traditional ECC signature and a post-quantum certificate.

[0267] Among some feasible implementation methods, it also includes

[0268] The public key update module is used to generate a new second private key component and calculate the third public key component corresponding to the new second private key component if the dual-track validity certificate expires or a security risk is detected in the IoT device.

[0269] A public key combination module is used to combine the third public key component and the first public key component to obtain a second target public key;

[0270] The certificate update module is used to sign a new dual-track certificate using the second target public key and the root certificate, and then issue the new dual-track certificate to the IoT device.

[0271] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0272] In addition, this invention also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described IoT device security update method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0273] This invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the above-described security update method embodiments for IoT devices, achieving the same technical effects. To avoid repetition, these details are not repeated here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0274] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0275] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, EEPROM, Flash, and eMMC, etc.) containing computer-usable program code.

[0276] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0277] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0278] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0279] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0280] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0281] The present invention has provided a detailed description of a security update method and a security update device for an Internet of Things (IoT) device. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for securely updating an Internet of Things (IoT) device, characterized in that, include: In response to sending an OTA request to the server, the system obtains an encrypted update package, an encrypted session key, and a temporary public key corresponding to the OTA request, wherein the encrypted update package is a data packet encrypted by the server using the temporary session key; A target private key for the temporary session key is dynamically generated, and the target private key and the temporary session key are used to decrypt the encrypted update package to obtain the corresponding firmware fragment; If the integrity of each firmware fragment is verified, all firmware fragments are reassembled to obtain the corresponding updated firmware. The legality of the updated firmware is verified using a locally stored dual-track validity certificate. If the legality of the updated firmware is verified, the update operation corresponding to the updated firmware is executed. The dual-track validity certificate is a certificate issued by the server using the first public key component corresponding to the IoT device, the second public key component corresponding to the server, and the root certificate. The dual-track validity certificate includes at least a traditional ECC signature and a post-quantum certificate. The step of dynamically generating a target private key for the temporary session key, and using the target private key and the temporary session key to decrypt the encrypted update package, includes: Obtain the first private key component corresponding to the IoT device; Obtain the second private key component corresponding to the server; The first private key component and the second private key component are combined to obtain the target private key for the temporary session key; A shared secret is generated based on the target private key and the temporary public key; Generate a key for encryption based on the shared secret; Decrypt the encrypted session key into the temporary session key based on the encrypted key; The encrypted update package is decrypted using the temporary session key.

2. The method according to claim 1, characterized in that, The firmware fragment comprises several data blocks. If the integrity of each firmware fragment passes verification, all firmware fragments are reassembled to obtain the corresponding updated firmware, including: Obtain the firmware mapping header corresponding to the firmware fragment, wherein the firmware mapping header includes a trusted root hash value; Obtain the block index corresponding to the data block, and calculate the block hash value corresponding to each data block; The target root hash value corresponding to the firmware fragment is obtained by iteratively calculating based on the block hash value and the block index. If the target root hash value is the same as the trusted root hash value, then obtain the next firmware fragment of the firmware fragment; Return to the process of iteratively calculating the target root hash value corresponding to the firmware fragment based on the block hash value and the block index, until all firmware fragments have completed integrity verification; If the integrity of each firmware segment passes verification, then all firmware segments are reassembled to obtain the corresponding updated firmware.

3. The method according to claim 2, characterized in that, The step of iteratively calculating the target root hash value corresponding to the firmware fragment based on the block hash value and the block index includes: Select any of the data blocks as the current data block; Starting with the current data block, the block hash values ​​of adjacent data blocks are concatenated according to the block index to obtain the current block hash value. The process of concatenating the block hash values ​​of adjacent data blocks according to the block index is returned until all the hash values ​​corresponding to the data blocks in the firmware fragment are exhausted, and the target root hash value corresponding to the firmware fragment is obtained.

4. The method according to claim 1, characterized in that, Also includes: In response to the first startup of the IoT device, a device identifier corresponding to the IoT device is generated by random number generation, and a first private key component corresponding to the device identifier is generated by elliptic curve cryptography. Calculate the first public key component corresponding to the first private key component; Send the first public key component to the server and receive the dual-track validity certificate corresponding to the first public key component sent by the server.

5. The method according to claim 1 or 4, characterized in that, The method involves using a locally stored dual-track validity certificate to verify the legitimacy of the updated firmware. If the verification of the updated firmware's legitimacy is successful, the corresponding update operation is performed, including: Extract the target manufacturer signature corresponding to the updated firmware; Obtain the dual-track efficacy certificate stored locally. If the target vendor signature matches the trusted vendor signature corresponding to the dual-track efficacy certificate, then perform the update operation corresponding to the updated firmware.

6. The method according to claim 5, characterized in that, Also includes: If the dual-track validity certificate expires or a security risk is detected in the IoT device, then the third private key component sent by the server is obtained. Obtain the first public key component corresponding to the IoT device; Obtain the second public key component corresponding to the server; The third public key component is calculated using the third private key component to obtain the third public key component corresponding to the server, and the second public key component is used to update the third public key component. The server then sends a new dual-track validity certificate corresponding to the third public key component. Switch to the new dual-track efficacy certificate and set the expiration time for the original dual-track efficacy certificate.

7. A method for securely updating an Internet of Things (IoT) device, characterized in that, include: In response to receiving an OTA request sent by an IoT device, the system obtains the target firmware corresponding to the OTA request and segments the target firmware to obtain several corresponding firmware segments. After encrypting each firmware fragment, a corresponding update data packet is constructed. Obtain the first public key component corresponding to the IoT device; Obtain the second private key component corresponding to the server, and calculate the second public key component corresponding to the second private key component; Combine the first public key component and the second public key component to obtain the first target public key; Obtain the root certificate corresponding to the target firmware, and use the first target public key and the root certificate to sign a dual-track certificate, and issue the dual-track certificate to the IoT device; wherein, the dual-track certificate includes at least a traditional ECC signature and a post-quantum certificate; A temporary session key is dynamically generated for the update data packet, and the update data packet is encrypted using the temporary session key to obtain the corresponding encrypted data packet; Randomly generate a temporary private key and a corresponding temporary public key; A shared secret is generated based on the temporary private key and the first target public key; Generate a key for encryption based on the shared secret; The temporary session key is encrypted using the encryption key to obtain the encrypted session key; Send the encrypted data packet, encrypted session key, and temporary public key to the IoT device.

8. The method according to claim 7, characterized in that, After encrypting each firmware fragment, the corresponding update data packet is constructed, including: Obtain the fragment size for the firmware fragment, and divide the firmware fragment into several data blocks according to the fragment size; Calculate the block hash value corresponding to the data block, and use the block hash value as the leaf node; The leaf nodes are grouped in pairs, and two adjacent leaf nodes are concatenated to obtain the corresponding target block hash value, and the target block hash value is used as a new leaf node. Return to the process of grouping the leaf nodes in pairs, splicing two adjacent leaf nodes to obtain the corresponding target block hash value, until the root node corresponding to the firmware fragment is generated, and the root node is used as the trusted root hash value. Obtain the vendor key corresponding to the target firmware; The trusted root hash value is digitally signed using the vendor key to obtain signature data; At least the fragment size, the signature data, and the trusted root hash value are integrated to obtain the corresponding update data packet.

9. The method according to claim 8, characterized in that, Also includes If the dual-track validity certificate expires or a security risk is detected in the IoT device, a new second private key component is generated, and the third public key component corresponding to the new second private key component is calculated. By combining the third public key component and the first public key component, a second target public key is obtained; The second target public key and the root certificate are used to issue a new dual-track certificate, and the new dual-track certificate is then issued to the IoT device.

10. A security update device for an Internet of Things (IoT) device, characterized in that, include: The data packet request module is used to respond to sending an OTA request to the server and obtain the encrypted update packet, encrypted session key and temporary public key corresponding to the OTA request. The encrypted update packet is a data packet encrypted by the server using the temporary session key. The decryption module is used to dynamically generate a target private key for the temporary session key, and use the target private key and the temporary session key to decrypt the encrypted update package to obtain the corresponding firmware fragment; The verification module is used to reassemble all the firmware fragments to obtain the corresponding updated firmware if the integrity of each firmware fragment passes the verification, and to verify the legality of the updated firmware using a locally stored dual-track validity certificate. If the legality of the updated firmware passes the verification, the module executes the update operation corresponding to the updated firmware. The dual-track validity certificate is a certificate issued by the server using the first public key component corresponding to the IoT device, the second public key component corresponding to the server, and the root certificate. The dual-track validity certificate includes at least a traditional ECC signature and a post-quantum certificate. Specifically, the decryption module is used to: obtain a first private key component corresponding to the IoT device; obtain a second private key component corresponding to the server; synthesize the first private key component and the second private key component to obtain a target private key for the temporary session key; generate a shared secret based on the target private key and the temporary public key; generate a key encryption key based on the shared secret; decrypt the encrypted session key to the temporary session key based on the key encryption key; and decrypt the encrypted update package based on the temporary session key.

11. A security update device for an Internet of Things (IoT) device, characterized in that, include: The firmware sharding module is used to respond to an OTA request sent by an IoT device, obtain the target firmware corresponding to the OTA request, and shard the target firmware to obtain a number of corresponding firmware shards. The firmware encryption module is used to encrypt each firmware fragment and then construct the corresponding update data packet. A public key acquisition module is used to acquire the first public key component corresponding to the IoT device; The public key calculation module is used to obtain the second private key component corresponding to the server and calculate the second public key component corresponding to the second private key component. A public key combination module is used to combine the first public key component and the second public key component to obtain a first target public key; The certificate issuance module is used to obtain the root certificate corresponding to the target firmware, and to issue a dual-track certificate by using the first target public key and the root certificate, and to issue the dual-track certificate to the IoT device; wherein, the dual-track certificate includes at least a traditional ECC signature and a post-quantum certificate; A data packet encryption module is used to dynamically generate a temporary session key for the updated data packet, and encrypt the updated data packet using the temporary session key to obtain a corresponding encrypted data packet; randomly generate a temporary private key and generate a corresponding temporary public key; generate a shared secret based on the temporary private key and the first target public key; generate a key encryption key based on the shared secret; and encrypt the temporary session key using the key encryption key to obtain an encrypted session key. The data packet sending module is used to send the encrypted data packet, the encrypted session key, and the temporary public key to the IoT device.

12. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method as described in any one of claims 1-9.

13. A computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1-9.

Images