Firmware security updating method suitable for Internet of Things equipment

Abstract

According to the firmware security updating method suitable for the Internet of Things equipment, the integrity and the high efficiency of the updating process are ensured while a user is supported to select a function module combination for customized updating according to needs. According to the method, a chameleon hash chain is adopted at an update management server side to construct a cross-module credible verification mechanism, hash abstracts are generated for functional modules one by one and are linked to form an integrity chain, and verification failure can be caused by any unauthorized tampering or missing, so that the overall credibility of a customized firmware update package is guaranteed. In order to reduce the burden of the resource-constrained device, a workload verification mechanism is introduced, the server completes calculation of the functional module block and generation of verification parameters in advance, and the device end can confirm the validity of the update package only by quickly verifying the hash chain and the verification parameters. Meanwhile, in combination with a cache multiplexing strategy, the generated function module combination update package is stored and multiplexed, and when a result is found preferentially and the result is not matched, the function module combination update package is dynamically generated and added into the cache.

Description

Technical Field

[0001] This invention belongs to the field of firmware update and information security technology for Internet of Things (IoT) devices, specifically a firmware security update method applicable to IoT devices. Background Technology

[0002] With the rapid development of the Internet of Things (IoT), numerous smart IoT devices have connected to the network, bringing convenience to people's lives while also introducing security risks. Firmware updates are a crucial means of ensuring the security of IoT devices, typically improving their security and performance by patching vulnerabilities or adding features. However, traditional firmware update mechanisms primarily focus on signing and verifying single, complete firmware images, lacking support for module-level updates. Modern IoT devices have diverse functions, and different users may only need a portion of them; for example, a smart camera might require motion detection but not cloud-based recognition. Users increasingly desire customized firmware updates, updating only the necessary module functions rather than the entire firmware. However, there is currently a lack of a universally accepted definition and mechanism for customized firmware updates. Drawing inspiration from software customization, we define "customization rights" as: under authorization and with guaranteed integrity, users can selectively update only the IoT firmware function modules they need, without refreshing the entire firmware image each time. This customized update provides controlled flexibility: users can tailor the update content as needed, while the system maintains trusted update boundaries, ensuring that unauthorized modules cannot infiltrate. Existing technologies face the following security and performance challenges in modular customized updates:

[0003] Lack of cross-module integrity guarantees: Traditional solutions typically perform global signing or hashing of the entire firmware package. Once users are allowed to freely combine modules, a single signature is insufficient to cover all combinations. If untrusted functional modules are inserted into the update package or necessary dependent modules are omitted, existing solutions cannot effectively detect this, potentially leading to security vulnerabilities. As user customization increases, the update chain itself becomes a new attack surface. If a trusted integrity link between modules cannot be established, attackers may exploit custom vulnerabilities to tamper with firmware updates.

[0004] Performance bottlenecks in customized updates: The diversity of module combinations presents scalability challenges for update services. For resource-constrained IoT devices, verifying multiple modules and their dependencies simultaneously is costly. Furthermore, large-scale update management servers, which need to rebuild firmware images and perform signature verification for each user-customized request, consume significant computing and storage resources. A small patch in a customized scenario can trigger thousands of firmware combination requests, causing an exponential increase in certificate verification and I / O burden on the update management server. While existing incremental updates and differential patching methods improve transmission efficiency, they still assume a single predefined firmware image from the manufacturer, lacking support for user-customized scenarios. Additionally, traditional solutions often require IoT devices to perform heavy cryptographic calculations (such as multi-signature verification), which is extremely difficult for IoT devices with limited computing power.

[0005] In summary, as IoT firmware updates move towards modularity and personalization, there is an urgent need for an update mechanism that can both ensure the security and reliability of each module and take into account the efficiency of large-scale customization, in order to balance the contradiction between user customization flexibility and firmware update security and performance. Summary of the Invention

[0006] This invention provides a firmware security update method suitable for Internet of Things (IoT) devices, aiming to ensure the security, reliability, efficiency, and scalability of the update chain while supporting user-customized firmware updates.

[0007] The technical solution to achieve the purpose of this invention is: a method for securely updating IoT firmware that supports customization, comprising the following steps:

[0008] Initialization phase:

[0009] Before IoT devices leave the factory or are deployed for the first time, update the management server to complete the initial configuration.

[0010] Customization request stage:

[0011] When an IoT device requires a firmware upgrade, the user or the IoT device sends a customized update request containing the required combination of functional modules to the update management server. After receiving the request, the update management server checks its cache to see if a generated firmware package corresponding to the combination of functional modules already exists.

[0012] If a corresponding combination of functional modules exists, the customized firmware update package and its integrity verification data are directly extracted, and the subsequent operations are performed in the package generation stage.

[0013] If no corresponding functional module combination exists, the process proceeds to the package generation stage, where the server dynamically generates a new customized firmware update package.

[0014] Package generation stage:

[0015] After completing the customization request, the update management server enters the package generation stage, where the update package is verified or dynamically built.

[0016] If the corresponding custom firmware update package exists in the cache, proceed to step A:

[0017] The consistency check, commitment block confirmation, workload verification parameter review, and signature and authorization check are performed sequentially to ensure that the cached results still meet the latest security policy and can be securely distributed.

[0018] If the corresponding update package is not found in the cache, proceed to step B:

[0019] Load template blocks from the template pool, inject functional module code, use chameleon hash trapdoor parameters to complete collision adjustment and version connection proof generation, and finally construct commitment blocks and complete custom firmware update packages;

[0020] Distribution and verification phase:

[0021] The customized firmware update package is sent to the target IoT device, which then performs the following verification steps:

[0022] Verify the digital signature or source certificate of the firmware update package to confirm that the update package comes from a trusted update management server;

[0023] Read the previous version information and collision proof value from the update package, and combine them with the old version verification chain stored in the IoT device to verify the equivalence of the key information of the old version and the current version under the Chameleon hash; if the verification fails, the update package is rejected.

[0024] For each functional module block in the update package, recalculate the chameleon hash digest and verify whether the chameleon hash digest is consistent with the functional module hash digest recorded in the update package; at the same time, verify whether the proof of work for this part meets the predetermined proof of work difficulty requirements; if the hash value of any functional module block does not match or the proof of work fails, the update package is determined to be incomplete or untrustworthy, and the update is rejected.

[0025] Once the hash chain integrity verification and workload verification of all functional module blocks have passed, the update package is accepted, and the installation and update phase begins.

[0026] Installation and update phase:

[0027] The IoT device deploys and updates the verified code of each functional module to the firmware system, and updates the locally stored verification chain information to the hash digest list and commitment value of the current version, which serves as the integrity verification benchmark for the next firmware update; this completes the security update process of a customized firmware.

[0028] Compared with the prior art, the significant advantages of this invention are:

[0029] This invention allows users to select firmware modules for updates as needed, while ensuring the integrity and security of the update process.

[0030] Specifically as follows:

[0031] 1. Security under Customization Constraints: This invention allows users to freely choose functional modules for customized updates while still ensuring the integrity and trustworthiness of the firmware update process through chameleon hashing, commitment chains, and cross-version collision proof mechanisms. Traditional whole-image update schemes cannot provide cross-module security guarantees under customization conditions, while this invention overcomes this limitation and avoids the contradiction between customization freedom and security.

[0032] 2. Lightweight and High-Efficiency: This invention introduces a workload verification mechanism, centralizing complex calculations on the update management server. IoT devices only need to perform rapid hash verification and workload verification, significantly reducing computational and energy consumption. Simultaneously, by combining caching and reuse mechanisms, the overhead of repeatedly generating firmware packages is reduced, shortening firmware update response time and device downtime, achieving a balance between low resource consumption and high efficiency.

[0033] 3. Traceability and Scalability: This invention generates a commitment block and collision proof in each update, forming a verifiable version chain record, ensuring the continuity and traceability of the firmware evolution process, facilitating subsequent security audits and tracking. Furthermore, this solution is suitable for large-scale, multi-architecture heterogeneous IoT device environments, can support massive customized update requests, and possesses excellent scalability and adaptability. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the overall architecture of the IoT firmware security update system described in this invention.

[0035] Figure 2 This is a flowchart illustrating the firmware update method described in this invention. Detailed Implementation

[0036] The present invention will now be described in further detail with reference to the accompanying drawings and examples. The following embodiments are implemented based on the technical solution of the present invention, providing detailed implementation methods and processes; however, the scope of protection of the present invention is not limited to the following embodiments.

[0037] For ease of understanding, the terms used in this specification are defined as follows:

[0038] 1. Functional module: refers to the logical functional unit in firmware, such as communication module, security module, driver module, etc., which is the smallest functional division granularity of firmware.

[0039] 2. Module block: refers to the basic data unit that encapsulates a functional module in an update package or verification chain, including template blocks, functional module blocks, and commitment blocks.

[0040] 3. Functional module combination: refers to a set of functional modules selected in the user's customization request.

[0041] Functional module hash set: refers to an ordered set of hash digest values ​​of each functional module, used to generate commitment values ​​and verification chains.

[0042] A method for secure firmware updates for the Internet of Things (IoT) that supports customization primarily employs the following two technologies:

[0043] ● Chameleon hashing technology, possessing the ability to generate hash collisions while holding a trapdoor key, is used to flexibly replace module content without changing the hash value, denoted as C. hash .

[0044] ● Proof of Work (PoW) mechanism: By calculating random numbers that meet specific difficulty conditions, it increases the cost of module forgery and the credibility of verification.

[0045] This invention provides a method for secure firmware updates in the Internet of Things (IoT) that supports customization, and its system model is as follows: Figure 1 As shown, two core entities are involved: update management servers and IoT devices. The update management server is a trusted computing center with complete functional module management capabilities, cryptographic computing capabilities, and update task scheduling functions; the IoT devices are IoT nodes deployed on terminals, which are diverse in type and heterogeneous in architecture, and generally have characteristics such as limited resources, high customization requirements, and weak security protection capabilities.

[0046] This invention addresses three major challenges in the firmware update process under current IoT scenarios: first, inconsistencies in the update chain caused by customization requirements make unified verification difficult; second, integrity verification mechanisms are resource-intensive and unsuitable for lightweight IoT devices; and third, users lack choice in traditional update strategies, affecting system openness and controllability. To address these challenges, this invention proposes a secure update mechanism with traceability, verifiability, and configurability, and introduces customization rights into the update system, ensuring that the update package content is flexibly customizable while guaranteeing the security requirements of continuous verification and integrity checks.

[0047] This invention combines the chameleon hash function with a work-verification mechanism. It constructs update packages using functional module blocks as basic units, maintains version chain continuity using commitment values, achieves digest consistency after module embedding using trapdoor parameters, and increases the cost of forgery through work-verification. In each update, IoT devices only need to verify modules related to their customized content, and complete version continuity and integrity checks through a local chained verification structure, thereby significantly reducing overhead and improving verification efficiency.

[0048] This invention mainly comprises five stages: initialization, customization request, package generation, distribution verification, and installation / update. Among them:

[0049] ● Initialization phase corresponds to Figure 2 Step 101 represents the system configuration process before the IoT device leaves the factory or is deployed, which mainly completes the generation of the initial verification chain and the writing of cryptographic parameters;

[0050] ●Customization request stage corresponds to Figure 2 Step 102 is responsible for checking whether a matching custom firmware update package already exists in the cache after the device initiates an update request; regardless of whether the cache is hit, the system will proceed to the package generation stage. Figure 2 Steps 103 to 110 are executed in the same way, but the execution path is different: if the corresponding custom firmware update package exists in the cache, steps 103 to 106 are mainly executed to complete the cache package consistency verification, commitment block confirmation and workload verification parameter review, etc.; if the corresponding custom firmware update package does not exist in the cache, steps 107 to 110 are executed to further complete the template block loading, functional module injection, collision parameter calculation and update package encapsulation, thereby generating a complete custom firmware update package.

[0051] ●The corresponding stage of generating packages Figure 2 Steps 103 to 110 cover the two execution paths mentioned above;

[0052] • Distribution verification phase Figure 2 Steps 111 to 114 involve processes such as custom firmware update package distribution, version continuity verification, functional module block verification, workload verification, and commitment value confirmation, which are used to ensure the credibility of the update source and the integrity of the content.

[0053] ● Installation and update phase Figure 2 In step 115, the IoT device completes the functional module after passing all verifications.

[0054] The replacement of blocks and the update of version records enable a complete, secure, and controllable firmware update.

[0055] Initialization phase:

[0056] Before IoT devices leave the factory or are deployed for the first time, the management server needs to complete initial configuration to establish a trusted foundation for subsequent customized firmware updates:

[0057] The server generates an initial firmware version, calculates the hash digests of each functional module and aggregates them into an overall commitment value, which is then written into the device to form an initial verification chain as a benchmark for integrity verification.

[0058] The server is configured with a chameleon hash function and its trapdoor parameters to ensure hash consistency during subsequent module replacement; a workload verification difficulty parameter is set to increase the cost of forgery.

[0059] The commitment value, public parameters, and verification rules are then securely written to the device's trusted storage area. Through this stage, IoT devices possess reliable firmware verification capabilities upon first operation. The specific steps are as follows:

[0060] Step 101: Initialization Phase

[0061] This phase mainly includes the following specific measures:

[0062] (1) Generation and implantation of firmware verification chain

[0063] The update management server generates an initial firmware version for each IoT device and calculates a list of hash digest values ​​for each functional module in that version. For example, if an IoT device contains several functional modules M1, M2, and M3, their hash values ​​are calculated separately, and then the hash values ​​of all modules are concatenated in sequence to generate an overall commitment value. This commitment value serves as a trusted identifier for the current firmware version of the IoT device.

[0064] Subsequently, the update management server combines the module hash value list with the commitment value to form an initial verification chain, and writes this information to the secure storage area of ​​the IoT device, such as read-only memory or trusted platform modules, to prevent unauthorized modification. This verification chain will serve as the reference benchmark for integrity verification in subsequent versions.

[0065] (2) Chameleon hash function parameter configuration

[0066] The update management server pre-configures a chameleon hash function for generating custom firmware and generates a set of trapdoor parameters containing trapdoor information for this chameleon hash function. The trapdoor parameters are only retained on the update management server side and are used to ensure that the hash value remains unchanged after the functional module block is embedded when generating the update package, thereby ensuring the traceability of the commitment value and the continuity of the version chain.

[0067] (3) Setting up a workload verification mechanism

[0068] To enhance the anti-counterfeiting capabilities of update packages, the update management server sets workload verification difficulty parameters, including:

[0069] ●Difficulty threshold: When an IoT device is required to verify a certain functional module, the workload verification result must meet the predetermined difficulty requirement;

[0070] ●Random perturbation range: Used to generate the random perturbation factor required for verification calculations;

[0071] ●Verification algorithm format: Clearly define how IoT devices perform workload verification on functional module blocks.

[0072] The introduction of this mechanism can effectively increase the cost of forging update packages and enhance system security.

[0073] (4) Security information burning for IoT devices

[0074] During the manufacturing process of IoT devices, the following initialization information is securely written into the device's storage: the functional modules of the initial version and their hash digests; the corresponding commitment values; the public parameters of the controllable hash function; the firmware version number; and the verification logic and computing resource verification rules. This writing process should be completed in a trusted execution environment or during the isolated boot phase to prevent malicious tampering and ensure that the IoT device has secure firmware verification capabilities upon its first run.

[0075] Customization request stage:

[0076] Step 102: Customize Request Processing

[0077] When an IoT device needs a firmware update, the user or the IoT device sends a customized update request containing a combination of target functional modules to the update management server. Upon receiving the request, the update management server checks its cache to see if a customized firmware update package corresponding to the module combination exists.

[0078] 1. If the corresponding custom firmware update package exists in the cache: directly extract the update package and its integrity verification data, and proceed to the package generation stage to perform subsequent verification and distribution preparation operations;

[0079] 2. If the corresponding custom firmware update package does not exist in the cache: then proceed to the package generation stage, where the update management server dynamically generates a new custom firmware update package.

[0080] This step, through a cache query mechanism, effectively reduces the overhead of repeatedly building firmware packages and improves update response efficiency while meeting user customization needs.

[0081] Package generation stage:

[0082] After completing the customization request, the update management server enters the package generation stage, where the update package is verified or dynamically built.

[0083] If the corresponding custom firmware update package exists in the cache, then the consistency check, commitment block confirmation, workload verification parameter review, and signature and authorization check are performed sequentially to ensure that the cached result still meets the latest security policy and can be securely distributed. The specific implementation steps are as follows:

[0084] Step 103: Cache Packet Consistency Verification

[0085] After completing the initialization phase, when a customized firmware update package corresponding to the target functional module combination exists in the cache, the update management server must first perform a consistency check on the cached package to ensure the trustworthiness and integrity of the update package before distribution. This step mainly includes the following:

[0086] (1) Chameleon hash function confirmed

[0087] The update management server invokes the chameleon hash function configured during initialization to verify the hash digests of each functional module block in the cache package. The chameleon hash function features controlled collisions: the input is the content of the functional module block and a random perturbation factor; collisions cannot be independently constructed externally; and the server can generate verifiable hash collisions between different inputs through trapdoor parameters. This characteristic ensures that even if the cache package undergoes module replacement during generation, its commitment structure and version chain remain continuous. These features allow the update management server to flexibly embed different functional modules during customized updates without disrupting the overall commitment structure, thereby maintaining the continuity of the version chain and the stability of the verification structure.

[0088] (2) Comparison of commitment value with hash set

[0089] The update management server reads the commitment block from the cache package, recalculates the set of hash digests for the functional modules, and compares it with the commitment value of the cache record. If they match, the cache package has not been tampered with, and the verification chain is complete and usable; if they do not match, the cache package is deemed invalid, and steps 107–110 are required to regenerate the update package.

[0090] (3) Safety verification of trapdoor parameters

[0091] The update management server checks the trapdoor parameter call path and random perturbation factor used to generate the cache package to ensure they are consistent with the settings during the initialization phase. The trapdoor parameters are always stored only on the server side and are never distributed to IoT devices to prevent attackers from forging update packages.

[0092] The above verification ensures that the customized firmware update package extracted from the cache can directly enter the subsequent verification and distribution process without reconstruction, thereby improving the overall update efficiency.

[0093] Step 104: Confirmation of the commitment block

[0094] After completing the cache package consistency check, the update management server needs to verify the commitment blocks in the cached custom firmware update package to ensure the correctness and stability of the functional module hash set and the overall commitment value. This step mainly includes the following operations:

[0095] (1) Commitment block reading and comparison

[0096] The update management server reads the commitment block from the cached package and obtains the set of hash digests of the functional modules and the overall commitment value C recorded therein. Then, based on the actual functional module blocks contained in the cached package, it recalculates the corresponding hash digest set and regenerates the overall commitment value. If the recalculated result matches the cached record, the commitment block is considered trustworthy; otherwise, the cached package is deemed invalid, and steps 107–110 are required for regeneration.

[0097] (2) Verification of the integrity of the commitment block structure

[0098] As the core node of the verification chain, the commitment block's structure must remain stable despite changes in the functional modules. The update management server must verify that the commitment block's unique identification function for the functional module combination order is working correctly and that it has not been tampered with or is missing.

[0099] Through the above verification, the commitment block can provide cross-module consistency guarantees for the cache package, ensuring that the cached results remain valid in the version chain. If the commitment block verification passes, step 105 can be proceeded to review the workload verification parameters.

[0100] Step 105: Workload Verification Parameter Review

[0101] After confirming the commitment block, the update management server needs to review the workload verification parameters of each functional module block in the cache package to ensure that the difficulty threshold set when the cache was generated remains consistent with the current policy, thereby guaranteeing the security and effectiveness of the cache package. This step mainly includes the following operations:

[0102] (1) Verify workload verification parameters module by module

[0103] The update management server re-executes the workload verification process for each functional module block in the cache package, checking whether the corresponding workload verification parameter values ​​meet the current difficulty requirements (e.g., whether the hash result is less than a predetermined threshold).

[0104] (2) Difficulty strategy consistency check

[0105] Since the difficulty threshold for workload verification may be adjusted over time or with policy upgrades, updating the management server requires confirming that the workload verification parameters used when the cache package was generated are still valid under the current policy. If the difficulty policy is increased and the original workload verification parameters no longer meet the requirements, the cache package is deemed invalid, and steps 107–110 must be performed to regenerate it.

[0106] (3) Exception handling

[0107] If, during the review process, it is found that the workload verification parameters of a certain functional module block are missing or fail to be verified, the entire cache package is deemed invalid and will not be distributed. At this time, the update management server will proceed to steps 107–110 to regenerate the customized firmware update package.

[0108] The above verification ensures that the customized firmware update package extracted when the cache is hit still complies with the latest security policy and will not cause security vulnerabilities due to outdated parameters or reduced difficulty.

[0109] Step 106: Signature and Authorization Verification Before Distribution

[0110] After completing the consistency verification of the cached package, confirmation of the commitment block, and review of the workload verification parameters, the update management server needs to perform a final signature and authorization verification on the customized firmware update package to ensure its credible origin and distribution capability. This step mainly includes the following operations:

[0111] (1) Digital Signature and Certificate Verification

[0112] The update management server uses its private key to digitally sign the commitment value and necessary metadata (such as version number, timestamp, etc.) in the cache packet, along with a trusted certificate. This signature ensures that the cache packet cannot be tampered with during transmission and distribution, and IoT devices can use it to verify its trustworthy origin.

[0113] (2) Access control and authorization checks

[0114] The update management server verifies, based on the target device's registration information and access control list (ACL), that the customized firmware update package is only distributed to devices with legitimate requests. If the target device is found to have insufficient permissions or expired authorization information, the distribution of the update package will be refused.

[0115] (3) Final integrity verification

[0116] Before signing, the update management server performs a quick check on the promised value of the cached package to ensure it matches the previous verification. If a discrepancy is found, the signing process is aborted, and steps 107–110 are performed to regenerate the update package.

[0117] Through the above process, it is ensured that the customized firmware update package directly distributed when the cache is hit meets the requirements in terms of integrity, source credibility, and authorization legality, thus enabling it to safely enter the distribution verification stage.

[0118] Through this phase, the update management server is able to provide IoT devices with reliable and traceable custom firmware packages while ensuring security and continuity.

[0119] If the corresponding update package does not exist in the cache, a template block is loaded from the template pool, the functional module code is injected, the collision adjustment and version integration proof generation are completed using the chameleon hash trapdoor parameter, and finally the commitment block and the complete custom firmware update package are constructed. The specific implementation steps are as follows:

[0120] Step 107: Loading Template Blocks and Loading Old Version Information

[0121] When the update management server confirms a cache miss in steps 102–106, it needs to initialize the update package to generate the required template blocks and load the verification chain information of the previous version from the IoT device to ensure the continuity and integrity of the generation process. This step mainly includes the following processes:

[0122] (1) Template block loading

[0123] The update management server selects template blocks from the module template pool that match the number of functional modules required by the customization request. Each template block contains randomly populated data, an initial hash digest, and work validation parameters that meet the work validation requirements, serving as a structured container for functional module injection.

[0124] (2) Device Identification Resolution and Version Location

[0125] The update management server locates the firmware version metadata of the last successfully updated IoT device from the historical storage system based on the device's unique identifier (such as device ID, registration information, or binding record). To ensure the reliability of the version data, signature verification or other trusted mechanisms (such as blockchain notarization) are required to verify that the historical data has not been tampered with.

[0126] (3) Loading the old version verification chain

[0127] The update management server loads the core verification chain data from the previous version, including the functional module hash digest set (BlockInfo), the overall commitment value (Commitment), and necessary additional metadata (such as timestamps, version numbers, etc.). This data will be used in subsequent steps to calculate collision parameters and complete the version transition.

[0128] (4) Consistency verification and data preprocessing

[0129] After loading the old version of the data, the update management server needs to confirm the consistency between the old commitment value and the module hash digest set, and standardize the data format to prevent data anomalies from causing subsequent collision calculation failures.

[0130] Step 108: Functional Module Injection

[0131] After loading the template blocks and the old version verification chain information, the update management server needs to embed the user-requested functional module code one by one into the template blocks to form the main structure of the customized firmware update package. This step mainly includes the following processes:

[0132] (1) Template and functional module mapping

[0133] The update management server selects the corresponding template blocks from the template block set according to the functional module combination in the customization request, and establishes a one-to-one mapping relationship. Each template block retains the original structure fields (module identifier, random disturbance factor, workload verification parameters, etc.), and only replaces its pseudo-fill content with the actual functional module code.

[0134] (2) Function code embedding

[0135] The actual code of the target functional module is written into the corresponding template block, replacing the original randomized filler string. At this point, the core fields of each functional module block include: module identifier, actual functional module code, initial hash digest (to be corrected), and the original workload verification parameters.

[0136] (3) Keep the structure fields unchanged

[0137] To ensure the continuity of the verification chain and the validity of the work verification, the identifier, work verification parameters, and hash structure fields of the module block are not modified during functional module injection. These fields will be corrected in the next step using chameleon hash collision adjustment to ensure that the hash digest remains consistent with the original value after replacement.

[0138] (4) Data temporary storage after injection

[0139] The update management server stores the module blocks with the actual functional code populated into a temporary cache structure and marks them as "pending adjustment" to provide data input for subsequent collision calculations and commitment chain generation.

[0140] Step 109: Chameleon Hash Collision Adjustment and Version Integral Proof Generation

[0141] After injecting the functional module, the update management server needs to use the trapdoor parameter of the chameleon hash function to perform collision adjustment on the functional module block, ensuring that it maintains a consistent hash digest with the template block after content replacement. Simultaneously, it combines the verification chain information from the previous version to generate a cross-version connection proof to ensure the continuity of the version chain. This step mainly includes the following processes:

[0142] (1) Module-by-module collision adjustment

[0143] Since the initial hash digest of the template block is generated based on randomly padded data, directly calculating it after replacing it with the actual functional module code will cause the hash digest to change. To solve this problem, the update management server uses trapdoor parameters to calculate a new perturbation factor r′, such that:

[0144] C hash (functional module code, r') = h

[0145] Where h is the original hash digest of the template block. This process ensures that the hash digest of the functional module block remains consistent with the original template after the code is replaced, thereby maintaining the stability of the commitment chain structure.

[0146] (2) Maintain the validity of workload verification parameters

[0147] Since collision adjustment ensures that the hash digest remains unchanged, the workload verification parameters calculated by the functional module block in the template stage remain valid and do not need to be recalculated. This avoids repeatedly performing high-overhead PoW calculations during the update process, thus improving overall efficiency.

[0148] (3) New version commitment value generation

[0149] After completing collision adjustments for all functional modules, the update management server concatenates the hash digests of these modules in a fixed order to form a new BlockInfo, and calculates the overall commitment value C:

[0150] C = C hash (H1||H2||...||H L )

[0151] Where H i This represents the hash digest of the i-th functional module block. This commitment value will serve as the integrity identifier for the new firmware version.

[0152] (4) Generation of version compatibility proof

[0153] To ensure the continuity of version iterations, the update management server utilizes the controllable collision property of the chameleon hash function to construct an equivalence proof between the commitment values ​​of the old and new versions. Specifically, the server generates a set of collision parameters that ensures the old version's key data and the new version's key data maintain an equivalent mapping under the chameleon hash. This collision proof is attached to the update package as evidence of cross-version continuity.

[0154] Through the above steps, the update management server not only ensures hash consistency after the functional module is replaced, but also establishes a verifiable version chain for the firmware update process, thereby achieving a balance between functional customization and security.

[0155] Step 110: Commitment Block Construction and Update Package Encapsulation

[0156] After completing the chameleon hash collision adjustment of the functional module block in step 109, and obtaining the functional module hash digest set (BlockInfo), the new overall commitment value C, and the version integration proof, the management server updates the commitment block construction and final encapsulation of the customized firmware. This step mainly includes:

[0157] (1) Construction of commitment block

[0158] Based on the new set of functional module hash digests obtained in step 109 and the commitment value C, a commitment block is generated according to a predetermined normalization order (such as ascending order by module identifier or a preset topological order). The commitment block contains at least:

[0159] Functional module hash digest set BlockInfo = {H1, H2, ..., H L};

[0160] ● Overall commitment value C;

[0161] ●Version identifier and timestamp (used to track when the commitment was generated);

[0162] ● Algorithm and strategy identifiers (Chameleon hash algorithm identifier, work verification strategy version number, etc.);

[0163] ●Optional: Previous version commitment value identifier (PrevC) or its digest, used to quickly build link indexes.

[0164] The commitment block, as the core node of the verification chain, is independent of specific functional code and uniquely determines the combination and its order in this customized project.

[0165] (2) Update package metadata and generate manifest

[0166] Generate a list for distribution and device verification, which should include at least: target device / model constraints, target firmware version number, algorithm and parameter identifiers used (including PoW difficulty threshold), dependency / conflict constraints (such as minimum bootloader version), publisher identifier and validity period, packet size and fragmentation strategy (such as fragment size and order description when using fragmented transmission), etc. This list is used for pre-verification of "adaptability and policy consistency" on the device side.

[0167] (3) Update package assembly and consistency verification

[0168] The functional module block set, commitment block, version transition certificate, Manifest, digital signature, and certificate information are assembled into a custom firmware update package according to a fixed container format. Overall consistency verification (structural verification, field verification, checksum verification) is performed, and a unique package identifier (PackageID) and external reference digest are generated to ensure the verifiability of the package during storage / transmission.

[0169] (4) Cache registration and index creation

[0170] Using "Functional Module Combination → PackageID" as the primary key, the update package information and data location are registered in the server cache and index, recording its strategy version (including PoW difficulty version), algorithm identifier and validity period, which facilitates rapid reuse and consistency traceability of subsequent similar requests.

[0171] The above process generates a complete customized firmware update package, providing a unified, traceable, and verifiable packaging result for the distribution and verification phase. If any inconsistency or verification failure occurs in any sub-step, the update management server should revert to steps 107–109 to regenerate the relevant data before repackaging.

[0172] Distribution and verification phase:

[0173] The customized firmware update package is sent to the target IoT device, which then performs the following verification steps:

[0174] Verify the digital signature or source certificate of the update package to confirm that the update package comes from a trusted update management server;

[0175] Read the previous version information and collision proof value from the update package, and combine them with the old version verification chain stored in the IoT device to verify the equivalence of the key information of the old version and the current version under the Chameleon hash; if the verification fails, the update package is rejected.

[0176] For each functional module block in the update package, recalculate the chameleon hash digest and verify whether the chameleon hash digest is consistent with the functional module hash digest recorded in the update package; at the same time, verify whether the proof of work for this part meets the predetermined proof of work difficulty requirements; if the hash value of any functional module block does not match or the proof of work fails, the update package is determined to be incomplete or untrustworthy, and the update is rejected.

[0177] Once the hash chain integrity verification and workload verification of all functional module blocks have passed, the update package is accepted, and the installation and update phase begins.

[0178] Step 111: Firmware update complete

[0179] This step marks the official start of the update process for IoT devices. After the update management server completes firmware packaging and transmission, the IoT device receives and prepares to verify the integrity and legitimacy of the update package. This stage is the entry point for IoT devices to receive the customized firmware update package issued by the update management server, mainly involving data arrival, preliminary parsing, and state switching preparation.

[0180] (1) Firmware package reception

[0181] IoT devices receive the complete update package from the update management server via a secure communication channel (such as TLS, VPN, SSH, etc.). The update package includes:

[0182] ●L updated functional module blocks (including module code, perturbation parameters, module hash digest, and workload verification parameters);

[0183] ● One commitment block (containing BlockInfo and root hash commitment value C);

[0184] ● Proof of hash collision with the old version promise P (if it is not the first update);

[0185] ● Update authentication data such as management server signatures or root certificates.

[0186] (2) Packet integrity verification (transmission level)

[0187] Before the IoT devices formally verify each functional module, a transmission integrity check is first performed on the received update packets to ensure that the content has not been tampered with or truncated. This stage typically includes:

[0188] ● Check if the transmitted data is complete (byte checksum / file hash);

[0189] ●Verify the validity of the signature and the trustworthiness of the certificate;

[0190] ● Determine whether the firmware structure conforms to the preset format (whether it contains functional module blocks, commitment blocks, workload verification parameters, etc.).

[0191] If a formatting error, invalid signature, or missing data is detected, the IoT device immediately discards the update package and records the reason for the failure or reports it to the update management server.

[0192] (3) State transition preparation

[0193] If the firmware package passes the initial verification, the IoT device will temporarily store it in the update buffer and switch its internal state to "pending update" mode: the currently running firmware remains unchanged to ensure normal operation is not interfered with; a soft interrupt or timer task is set to trigger the subsequent commitment verification process (step 111 and thereafter). If the IoT device is in a critical task cycle (such as camera recording or control command processing), it can postpone entering the verification process and perform the update after the task is completed.

[0194] (4) Version comparison preparation (moving to the next stage)

[0195] After the update package arrives, the IoT device will extract the version information (such as version number, timestamp, module serial number) from the commitment block, which will be used in step 111 version confirmation to determine whether the update is a duplicate or a legitimate continuation version.

[0196] Step 112: Version Confirmation

[0197] This step aims to ensure that the update packages currently received by IoT devices are the result of legitimate version continuation, with the correct commitment chain connection, preventing attackers from forging intermediate firmware versions or rolling back historical states, thereby ensuring the integrity and security of firmware evolution.

[0198] (1) Load local old version information

[0199] IoT devices read the currently running firmware version record from a secure storage area, which mainly includes:

[0200] ●The hash digest collection of the previous version's functional modules (OldBlockInfo);

[0201] ● The root commitment value of the previous version (OldCommitment) old );

[0202] ● Generate metadata such as timestamps, version numbers, and verification status locally.

[0203] (2) Extract the update package version verification content

[0204] The IoT device parses the commitment block and collision proof in the newly arrived update packet to obtain the following key fields:

[0205] ● New module set hash (NewBlockInfo);

[0206] • New Commitment;

[0207] Collision proof P (generated by the update management server based on the chameleon hash trapdoor);

[0208] • Hash function configuration parameters (e.g., hash algorithm, collision mode, etc.).

[0209] Step 113: Module Verification

[0210] After confirming the version of the update package, IoT devices officially enter the integrity verification phase. This step aims to ensure that the firmware package has not been tampered with and that it maintains continuity with the previously running versions of the IoT device, thereby guaranteeing the trusted evolution of the update chain. This phase mainly consists of two parts: module hash consistency verification and commitment continuity verification.

[0211] (1) Module hash consistency verification:

[0212] IoT devices sequentially extract the actual code blocks of each functional module in the update package and their corresponding hash value list (H = {h1, h2, ..., h...}). L}), recalculate the hash digest h for each module block using the built-in chameleon hash function. i ′=Chash(PStr i ′,r i ). Among them: PStr i ' is the actual functional code of the module block in the update package; r i To update the perturbation factor pre-calculated by the management server, used to offset hash changes caused by code replacement. IoT devices compare h one by one. i ′ and h provided in the package i If all module hash values ​​match, the modules are considered to have not been tampered with and the integrity verification is passed; if any module hash is inconsistent, the data integrity is considered to be compromised, and the IoT device should stop the update process and report the anomaly.

[0213] (2) Commitment Transition Verification:

[0214] The IoT device then verifies whether the version compatibility of the update package holds, i.e., whether a trusted hash chain exists between the old and new versions. This process is based on a collision proof P provided by the update management server, comparing the hash set of the old version stored by the IoT device with the promised value:

[0215] Calculate the summary of old version commitments:

[0216] C old =C hash (OldBlockInfo, OldCommitment)

[0217] Compute the new digest using the new version of the hash set and collision proof:

[0218] C new =C hash (NewBlockInfo, P)

[0219] Compare C old With C new If the results are equal, it indicates that the current update has indeed legitimately evolved from the old version by the trusted update management server, and the continuity of the commitment chain is established; otherwise, it indicates that there may be a risk of a forked version or intermediate tampering, and the IoT device should reject the update package and enter an alarm state. Through this double verification step, the IoT device ensures that the content of the update package has not been illegally tampered with during transmission and generation, while maintaining the integrity of the hash chain from the original version to the current version, thereby preventing version forgery and rollback attacks.

[0220] Step 114: Proof of Work

[0221] The IoT device verifies the proof-of-work attached to each functional module in the update package. It extracts the module's perturbation content and corresponding proof-of-work parameters, calculates the hash value, and determines whether it meets preset difficulty requirements (e.g., leading zeros). If all module proofs of work pass verification, the update is considered valid; otherwise, the update is rejected, and the firmware package is discarded.

[0222] Step 115: Confirmation of Commitment

[0223] After completing module hash verification and proof-of-work verification, the IoT device enters the commitment confirmation phase. At this point, the IoT device will re-execute the commitment value calculation operation based on the verified module hash set. If the calculated commitment value is completely consistent with the value recorded in the commitment block in the update package, it is determined that the update management server has fulfilled its commitment, the firmware content is complete and trustworthy, and the IoT device accepts the firmware and continues the subsequent process; otherwise, if the commitment value is inconsistent, it is determined that there is a risk of tampering or forgery in the update process, and the IoT device immediately stops the update and discards the firmware package.

[0224] Installation and update phase:

[0225] Step 116: Firmware Update

[0226] After the commitment confirmation is completed, the IoT device officially enters the firmware installation phase. In this step, the IoT device loads the verified functional module code into local storage or writes it to the firmware area according to the order of the functional modules in the update package, replacing the original old module content. The installation process strictly adheres to module boundaries and metadata configuration to ensure that the system's functional structure is not compromised. After all modules are loaded, the IoT device updates its local version record, providing a new integrity verification benchmark for subsequent verification.

[0227] In summary, this invention proposes a secure firmware update method for IoT devices that supports customization. By combining modular encapsulation, a commitment block mechanism, and chameleon hash collision technology, it achieves a balance between the flexibility of firmware customization and strong security for integrity verification. During the update process, the update management server significantly improves encapsulation efficiency through template block generation and workload verification mechanisms, while supporting cache reuse to further reduce computational overhead. IoT devices undergo a multi-verification process (hash digest verification, commitment chain verification, workload verification, and version continuity verification) to ensure the firmware source is trustworthy, the content is complete, and the link is continuous, comprehensively improving the update security and adaptability of IoT devices. This method is applicable to diverse IoT scenarios, and has significant potential for widespread adoption, especially in the management of large-scale heterogeneous IoT devices. Experimental results show that this method can significantly reduce the frequency of server re-builds and device downtime in large-scale customized update scenarios, achieving flexible, efficient, and scalable firmware updates while maintaining strong security.

Claims

1. A method for secure firmware updates for the Internet of Things (IoT) that supports customization, characterized in that, Includes the following steps: Initialization phase: Before IoT devices leave the factory or are deployed for the first time, update the management server to complete the initial configuration. Customization request stage: When an IoT device requires a firmware upgrade, the user or the IoT device sends a customized update request containing the required combination of functional modules to the update management server. After receiving the request, the update management server checks its cache to see if a generated firmware package corresponding to the combination of functional modules already exists. If a corresponding combination of functional modules exists, the customized firmware update package and its integrity verification data are directly extracted, and the subsequent operations are performed in the package generation stage. If no corresponding functional module combination exists, the process proceeds to the package generation stage, where the server dynamically generates a new customized firmware update package. Package generation stage: After completing the customization request, the update management server enters the package generation stage, where the update package is verified or dynamically built. If the corresponding custom firmware update package exists in the cache, proceed to step A: The consistency check, commitment block confirmation, workload verification parameter review, and signature and authorization check are performed sequentially to ensure that the cached results still meet the latest security policy and can be securely distributed. If the corresponding update package is not found in the cache, proceed to step B: Load template blocks from the template pool, inject functional module code, use chameleon hash trapdoor parameters to complete collision adjustment and version connection proof generation, and finally construct commitment blocks and complete custom firmware update packages; Distribution and verification phase: The customized firmware update package is sent to the target IoT device, which then performs the following verification steps: Verify the digital signature or source certificate of the firmware update package to confirm that the update package comes from a trusted update management server; Read the previous version information and collision proof value from the update package, and combine them with the old version verification chain stored in the IoT device to verify the equivalence of the key information of the old version and the current version under the Chameleon hash. If the verification fails, the update package will be rejected. For each functional module block in the update package, recalculate the chameleon hash digest and verify whether the chameleon hash digest is consistent with the functional module hash digest recorded in the update package; at the same time, verify whether the proof of work for this part meets the predetermined proof of work difficulty requirements; if the hash value of any functional module block does not match or the proof of work fails, the update package is determined to be incomplete or untrustworthy, and the update is rejected. Once the hash chain integrity verification and workload verification of all functional module blocks have passed, the update package is accepted, and the installation and update phase begins. Installation and update phase: The IoT device will deploy and update the verified code of each functional module to the firmware system, and update the locally stored verification chain information to the hash digest list and commitment value of the current version, as a basis for integrity verification during the next firmware update. This completes the security update process for a custom firmware.

2. The IoT firmware security update method supporting customization rights according to claim 1, characterized in that, Before IoT devices leave the factory or are deployed for the first time, updating the management server to complete the initial configuration specifically includes: The management server is updated to generate the initial firmware version, the hash digests of each functional module are calculated and aggregated into an overall commitment value, and the overall commitment value is written into the device to form an initial verification chain; Update the management server configuration for the Chameleon hash function and its trapdoor parameters; Update the workload verification difficulty parameters in the management server settings; Securely write IoT device security information into the trusted storage area of ​​the IoT device.

3. The IoT firmware security update method supporting customization rights according to claim 2, characterized in that, IoT device security information includes The initial version's functional modules and their hash digests; the corresponding commitment values; the public parameters of the controllable hash function; the firmware version number; and the verification logic and computational resource verification rules.

4. The IoT firmware security update method supporting customization rights according to claim 1, characterized in that, The specific process of performing consistency checks, commitment block confirmations, workload verification parameter reviews, and signature and authorization checks in sequence to ensure that the cached results still meet the latest security policies and can be securely distributed is as follows: When a custom firmware update package corresponding to the target functional module combination exists in the cache, the update management server first performs a consistency check on the cached package, specifically: The update management server calls the Chameleon hash function configured during the initialization phase to verify the hash digest of each functional module block in the cache package. If the verification passes, it means that the functional module block is complete and usable. If the verification fails, the cached package is deemed invalid, the distribution is terminated, and the process proceeds to step B to regenerate the update package. The update management server reads the commitment block in the cache package, recalculates the set of hash digests of the functional modules, and compares it with the commitment value of the cache record. If the two are consistent, it means that the cache package has not been tampered with and the verification chain is complete and usable; if they are inconsistent, the cache package is determined to be invalid and proceed to step B. The update management server checks the trapdoor parameter call path and random perturbation factor used to generate the cache package to ensure that they are consistent with the settings during the initialization phase. The update management server verifies the commitment blocks in the cached custom firmware update package, specifically including: The update management server reads the commitment block in the cache package and obtains the set of hash digests of the functional modules and the overall commitment value recorded therein; Based on the actual functional module blocks contained in the cache package, the corresponding hash digest set is recalculated, and the overall commitment value is generated again. If the recalculated result matches the cached record, the promised block is trustworthy; otherwise, the cached package is deemed invalid, and step B is executed. The update management server verifies the workload validation parameters of each functional module block in the cache package, specifically including: The update management server re-executes the workload verification process for each functional module block in the cache package, checking whether the corresponding workload verification parameter value meets the current difficulty requirement. If it does, the functional module block meets the integrity requirement, and the next module block is verified until all functional module blocks are verified. If it does not meet the requirement, the functional module block is determined to be invalid, the entire cache package is invalidated, and the process proceeds to step B. Updating the management server requires confirming that the workload verification parameters when the cache package was generated are still valid under the current policy. If the difficulty policy is increased and the original workload verification parameters no longer meet the requirements, the cache package is deemed invalid, and step B is performed. If, during the review process, it is found that the workload verification parameters of a certain functional module block are missing or fail to be verified, the entire cache package is determined to be invalid and will not be distributed; at this time, the update management server proceeds to step B. Updating the management server requires performing a final signature and authorization verification on the customized firmware update package, specifically including: The update management server uses a private key to digitally sign the commitment value and necessary metadata in the cached package, and attaches a trusted certificate; The update management server confirms, based on the target device's registration information and access control list, that the customized firmware update package is only distributed to devices that have made legitimate requests. If the target device is found to have insufficient permissions or expired authorization information, the update package will be refused to be distributed. Before signing, the update management server quickly verifies the commitment value of the cached package again to ensure that it is consistent with the previous verification. If a difference is found, the signing process is stopped and proceeds to step B.

5. The IoT firmware security update method supporting customization rights according to claim 1, characterized in that, The specific method for loading template blocks from the template pool, injecting functional module code, using chameleon hash trapdoor parameters to complete collision adjustment and version compatibility proof generation, and finally constructing the commitment block and the complete custom firmware update package is as follows: The initialization update package generates the required template blocks and loads the verification chain information of the previous version on the IoT device, specifically including: The update management server selects template blocks from the module template pool that match the number of functional modules required by the customization request; each template block contains randomly populated data, an initial hash digest, and workload verification parameters that meet the workload verification requirements, and is used as a structured container for functional module injection; The update management server locates the firmware version metadata of the last successfully updated device from the historical storage system based on the unique identifier of the IoT device. Update the management server to load the core verification chain data from the previous version; The management server is updated to confirm the consistency between the old commitment value and the module hash digest set, and the data format is standardized. The update management server embeds the user-requested functional module code one by one into template blocks to form the main structure of the customized firmware update package, specifically including: The update management server selects the corresponding template blocks from the template block set in turn according to the combination of functional modules in the customization request, and establishes a one-to-one mapping relationship. Write the actual code of the target functional module into the corresponding template block, replacing the original randomly filled string; The update management server stores the module blocks with the actual functional code populated into a temporary cache structure and marks them as "pending adjustment" status; Updating the management server requires using the trapdoor parameter of the chameleon hash function to perform collision adjustment on the functional module blocks, ensuring that the functional module blocks maintain a consistent hash digest with the template block after content replacement; simultaneously, it combines the verification chain information from the previous version to generate a cross-version connection proof, specifically including: The updated management server uses the trapdoor parameter to calculate a new perturbation factor r′, such that: C hash (functional module code, r') = h Where h is the original hash digest of the template block; The update management server concatenates the hash digests of the functional modules in a fixed order to form a new set of hash digests for the functional modules, and calculates the overall commitment value C: C = Chash(H1||H2||...||HL) Where H i This represents the hash digest of the i-th functional module block, and the commitment value serves as the integrity identifier for the new firmware version; The update management server utilizes the controllable collision property of the chameleon hash function to construct an equivalence proof between the old and new version commitment values; The update management server performs commitment block construction and final encapsulation for the custom firmware.

6. The IoT firmware security update method supporting customization rights according to claim 5, characterized in that, The specific method for the update management server to construct the commitment block and finally encapsulate the custom firmware is as follows: Based on the new functional module hash digest set and commitment value, commitment blocks are generated in a predetermined normalized order; Generate a list for distribution and device verification; The functional module block set, commitment block, version transition proof, list, digital signature and certificate information are assembled into a custom firmware update package in a fixed container format.

Images