Https secure firmware upgrading method, device and equipment and storage medium

Abstract

The application relates to the computer technical field, in particular to an HTTPS secure firmware upgrading method and device, equipment and a storage medium, wherein a set of upgrading context parameters is acquired, a target HTTP request message is read according to a breakpoint offset, a TCP transmission channel is established after a firmware URL analysis server network connection information is parsed and an OpenThread instance is locked and protected, a protocol stack resource preemption problem is avoided, and a lock resource is released after a link is established; the HTTP and HTTPS protocols are compatible, HTTPS link encryption transmission and decryption processing are realized through mbedTLS, response data legality is uniformly verified, a breakpoint offset is reserved in an abnormal case, legal segmented firmware data is written into a corresponding DFU partition, a Flash write offset is stored in real time and persistently, integrity verification is finally completed in combination with a total firmware length, and firmware activation or suspension upgrading operation is executed according to a verification result. The application adapts to Thread equipment network characteristics, realizes secure, stable and breakpoint continuation supporting firmware upgrading, and solves the problems of poor security, easy disconnection and inability to continue transmission.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device and storage medium for HTTPS secure firmware upgrade. Background Technology

[0002] Matter over Thread devices typically operate in low-power IPv6 Thread networks, where network capabilities are managed jointly by the Matter and OpenThread protocol stacks. It's important to note that Thread devices are not Wi-Fi devices. While Wi-Fi devices can directly access the internet using operating system sockets, TLS sockets, HTTP clients, or downloader libraries, low-power Thread devices typically only expose OpenThread protocol stack capabilities, and their internet exit relies on a Thread Border Router for IPv6 routing or NAT64 translation. In this type of Matter over Thread device environment, there are no readily available, mature HTTPS firmware download libraries like those for Wi-Fi devices.

[0003] For Matter over Thread devices such as smoke detectors, door sensors, and other sensors, firmware upgrades are essential for long-term product maintenance. Traditional approaches typically rely on Matter standard OTA providers, BLE / SMP DFU, vendor-specific gateway forwarding, or general network download components like Zephyr socket / nRF Downloader. Therefore, existing Matter over Thread low-power devices only possess OpenThread protocol stack capabilities and lack a mature HTTPS firmware download library adapted to this network environment. When using existing traditional firmware upgrade solutions, it's impossible to achieve native HTTPS firmware segmented download upgrades that support breakpoint resumption, partitioned writing, and link verification based on the native OpenThread TCP channel combined with mbedTLS. The upgrade process is prone to defects such as network concurrency preemption of protocol stack resources, lack of encrypted data transmission, loss of breakpoints, failure of firmware write verification, and inability to resume transmission after an upgrade interruption. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this invention provides an HTTPS secure firmware upgrade method, apparatus, device, and storage medium that adapts to the network characteristics of Thread devices and achieves secure, stable firmware upgrades that support breakpoint resumption.

[0005] A first aspect of this application provides a method for upgrading HTTPS secure firmware, the method comprising: Upon receiving the upgrade trigger command, obtain the upgrade context parameter set; Read the breakpoint offset according to the upgrade context parameter set, and generate the target HTTP request message according to the breakpoint offset; The server network connection information is obtained by parsing the firmware URL in the upgrade context parameter set; Obtain an initialized OpenThread instance and apply a Thread mutex lock to the OpenThread instance to obtain a lock-protected OpenThread instance; An OpenThread TCP transmission channel is established based on the locked OpenThread instance and the server network connection information. After the TCP connection is established, the Thread mutex lock of the OpenThread instance is released. The transmission process is performed according to the OpenThread TCP transmission channel and the target HTTP request message; if the firmware URL is HTTPS, a TLS handshake is completed based on mbedTLS and the target HTTP request message is encrypted before being sent; if the firmware URL is HTTP, the target HTTP request message is sent directly. The OpenThread TCP transmission channel receives TCP data sent by the server. Under the HTTPS link, the TCP ciphertext is decrypted to obtain the HTTP plaintext. Under the HTTP link, the plaintext is directly obtained. The HTTP plaintext is uniformly parsed and the legality of the response is verified. If the verification is invalid, the current TCP transmission link is closed, firmware data reception is stopped, and the current breakpoint offset is retained. If the verification is valid, segmented firmware data fragments are output. Based on the image format identifier in the upgrade context parameter set, the segmented firmware data fragments are written to the corresponding DFU partition, the Flash write offset is updated synchronously in real time, and the updated Flash write offset is persistently stored. Based on the updated Flash write offset and the total firmware length in the upgrade context parameter set, a download integrity check is performed, and firmware activation or upgrade suspension is performed based on the check result.

[0006] In an optional implementation, the step of reading the breakpoint offset based on the upgrade context parameter set and generating the target HTTP request message based on the breakpoint offset includes: The image type is distinguished based on the image format identifier in the upgrade context parameter set; the image type includes the original MCUboot image and the Matter OTA packaged image; If it is the original MCUboot image, call the DFU target interface to read the offset of the bytes already written to Flash as the breakpoint offset; if it is the Matter OTA packaged image, read the persistent payload start position, total payload size, and multi-image internal write offset, and calculate the global breakpoint offset in combination with the total firmware length. Determine whether the global breakpoint offset is greater than 0; If the global breakpoint offset is equal to 0, a full-range GET request is generated as the target HTTP request message; if the global breakpoint offset is greater than 0, a fragmented GET request carrying the Content-Range field is generated as the target HTTP request message.

[0007] In an optional implementation, obtaining the server network connection information by resolving the firmware URL from the upgrade context parameter set includes: The firmware URL is parsed to distinguish whether the corresponding transmission protocol is HTTP or HTTPS, and the domain name, port information, and resource access path are extracted, while the Host header is compatible with IPv6 literal format. Perform DNS resolution operations on the extracted domain names, prioritizing the query of the IPv6 AAAA record corresponding to the domain name; If the AAAA record query fails, then query the domain A record and use the Thread border router to obtain the IPv4 mapping address through NAT64 protocol translation; The server network connection information is generated by integrating the transmission protocol, the parsed server IP address, and the extracted port information.

[0008] In an optional implementation, establishing an OpenThread TCP transmission channel based on the locked OpenThread instance and the server network connection information includes: Initialize the TCP endpoint and the circular send buffer based on the locked OpenThread instance; Initiate a TCP connection request based on the server IP address and port information in the server network connection information; Listen for TCP connection ready callbacks. After successfully establishing a TCP connection, release the Thread mutex lock corresponding to the OpenThread instance and obtain a usable OpenThread TCP transmission channel.

[0009] In an optional implementation, the step of sending the target HTTP request message after completing the TLS handshake based on mbedTLS and encrypting it, if the firmware URL is an HTTPS protocol, includes: Initialize the mbedTLS client session, configure the password random number, SNI hostname, and server certificate verification strategy, and adapt the OpenThread TCP send and receive callbacks to the mbedTLS standard BIO read and write interface; Complete the TLS 1.2 handshake process based on the established TCP transport channel; The plaintext of the target HTTP request is sent into mbedTLS for encryption, and the resulting TCP ciphertext data stream is written into the OpenThread TCP loop send buffer and sent outward.

[0010] In an optional implementation, writing the segmented firmware data fragments to the corresponding DFU partition based on the image format identifier in the upgrade context parameter set includes: If the image format identifier corresponds to the original MCUboot image, verify whether the first 32 bytes of the firmware image header are valid. After the image header verification is successful, call the DFU target streaming interface to sequentially write the segmented firmware data fragments into the MCUboot secondary partition. If the image format identifier corresponds to a Matter OTA packaged image, accumulate segmented firmware data fragments and parse the Matter OTA header. After verifying that the payload size recorded in the header matches the total firmware length in the upgrade context parameter set, strip the Matter OTA header and write only the data fragment corresponding to the payload into the DFU multi-image target partition.

[0011] In an optional implementation, the step of performing a download integrity check based on the updated Flash write offset and the total firmware length in the upgrade context parameter set, and performing firmware activation or upgrade suspension processing based on the check result, includes: Compare the updated Flash write offset with the total firmware length in the upgrade context parameter set; If the updated Flash write offset is equal to the total length of the firmware, the MCUboot interface is called to mark the new firmware as pending activation. After the device restarts, the MCUboot will complete the firmware installation. If the updated Flash write offset is not equal to the total length of the firmware, the current upgrade task is paused, and the write offset of persistent storage is retained.

[0012] A second aspect of this application provides an HTTPS secure firmware upgrade device, the device comprising: The parameter acquisition module is used to receive and parse the upgrade trigger command and obtain the upgrade context parameter set; The message generation module is used to read the breakpoint offset according to the upgrade context parameter set, and generate the target HTTP request message according to the breakpoint offset; The network parsing module is used to parse the server network connection information based on the firmware URL in the upgrade context parameter set; The thread lock protection module is used to obtain an initialized OpenThread instance and apply a Thread mutex lock to the OpenThread instance to obtain a locked OpenThread instance; The channel establishment module is used to establish an OpenThread TCP transmission channel based on the locked OpenThread instance and the server network connection information, and release the Thread mutex lock of the OpenThread instance after the TCP connection is established. The secure transmission module is used to perform transmission processing based on the OpenThread TCP transmission channel and the target HTTP request message; if the firmware URL is HTTPS, it completes the TLS handshake based on mbedTLS and encrypts the target HTTP request message before sending it; if the firmware URL is HTTP, it directly sends the target HTTP request message. The data receiving and verification module is used to receive TCP data sent by the server through the OpenThread TCP transmission channel. Under the HTTPS link, the TCP ciphertext is decrypted to obtain the HTTP plaintext. Under the HTTP link, the plaintext is directly obtained. The HTTP plaintext is uniformly parsed and the legality of the response is verified. If the verification is invalid, the current TCP transmission link is closed, firmware data reception is stopped, and the current breakpoint offset is retained. If the verification is valid, segmented firmware data fragments are output. The partition writing and breakpoint storage module is used to write the segmented firmware data fragments to the corresponding DFU partition according to the image format identifier in the upgrade context parameter set, synchronously update the Flash write offset in real time, and persistently store the updated Flash write offset. The upgrade processing module is used to perform download integrity verification based on the updated Flash write offset and the total firmware length in the upgrade context parameter set, and to perform firmware activation or upgrade suspension processing based on the verification result.

[0013] A third aspect of this application provides a Matter over Thread device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the HTTPS secure firmware upgrade method.

[0014] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described HTTPS secure firmware upgrade method.

[0015] In summary, the HTTPS secure firmware upgrade method, apparatus, device, and storage medium provided in this application... Firmware upgrade adaptation is entirely based on the device's native OpenThread protocol stack, adapting to the operational characteristics of low-power IPv6 Thread networks. It does not rely on the general socket and download libraries of WiFi devices and perfectly adapts to the network egress forwarding mechanism of Thread devices. Regarding protocol stack resource protection, by applying a Thread mutex lock to the initialized OpenThread instance before establishing the TCP transmission channel, and promptly releasing the lock resources after the connection is established, the problem of multiple tasks preempting OpenThread protocol stack resources in network concurrency scenarios is effectively avoided, ensuring stable and conflict-free network transmission during firmware upgrades. At the secure transmission level, it is compatible with both HTTP and HTTPS protocols. For HTTPS protocol links, it relies on mbedTLS to complete the standard TLS handshake and encrypt the request message transmission. After receiving the encrypted data, it decrypts it to obtain the HTTP plaintext, compensating for the security vulnerabilities of traditional upgrade schemes that lack encryption protection and are susceptible to theft and tampering of firmware transmission data. Simultaneously, it uniformly verifies the legality of the parsed HTTP plaintext response, promptly identifying abnormal transmission data. If the verification fails, it immediately shuts down the transmission link and stops data reception, avoiding the problem of writing erroneous firmware data from the transmission source. Regarding breakpoint resumption and data storage, this application reads, updates, and persistently stores the Flash write breakpoint offset based on the upgrade context parameter set throughout the entire process. In the event of upgrade anomalies, link interruptions, or data verification failures, the current breakpoint position can be completely preserved. After the device restarts or the network recovers, the upgrade request can be resumed based on the breakpoint offset, solving the problems of breakpoint loss and inability to resume transmission after upgrade interruption in traditional solutions. Simultaneously, this application accurately writes segmented firmware data to the corresponding DFU partition according to the image format identifier, achieving orderly segmented firmware writing. Combined with a dual verification mechanism of real-time offset updates and final download integrity, it effectively solves the problems of traditional firmware upgrade write verification failure, incomplete firmware data, and low upgrade success rate. Finally, based on the integrity verification result, it adaptively completes firmware activation or upgrade pause processing, achieving secure, stable, resumable, and highly reliable native HTTPS firmware upgrades for Matter over Thread devices. Attached Figure Description

[0016] Figure 1 This is a schematic diagram illustrating the architecture of an HTTPS secure firmware upgrade system adapted for Matter over Thread devices, as shown in an embodiment of this application. Figure 2 This is a flowchart illustrating an HTTPS secure firmware upgrade method according to an embodiment of this application; Figure 3 This is a schematic diagram illustrating the process of preparing an HTTPS secure firmware upgrade request, as shown in an embodiment of this application. Figure 4 This is a schematic diagram illustrating a process for downloading, writing, and upgrading an application, as shown in an embodiment of this application. Figure 5 This is a timing diagram illustrating an OpenThread TCP carrying HTTPS implementation according to an embodiment of this application; Figure 6 This is a schematic diagram illustrating a process for determining a resume offset and constructing a request, as shown in an embodiment of this application. Figure 7 This is a schematic diagram illustrating a response verification and download recovery process according to an embodiment of this application; Figure 8 This is a flowchart illustrating the writing process for two image formats as shown in an embodiment of this application; Figure 9 This is a functional block diagram of an HTTPS secure firmware upgrade device shown in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a Matter over Thread device shown in an embodiment of this application. Detailed Implementation

[0017] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0018] The following will clearly and completely describe the concept, specific structure, and technical effects of the present invention in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this invention can be combined interactively without contradicting each other.

[0019] Currently, the mainstream firmware upgrade technologies for Matter Thread devices in the industry can include: Option 1: Matter standard OTA Provider upgrade solution.

[0020] The Matter protocol defines a cluster of OTA Software Update Provider and Requestor functionalities. Devices can obtain firmware upgrade packages through OTA Providers within the Matter ecosystem, enabling unified upgrade management for devices within the Matter ecosystem. However, its implementation relies on the collaborative participation of controllers, gateways, or local providers, resulting in a lengthy and complex deployment process for firmware package acquisition, data distribution, and ecosystem configuration. When devices need to directly connect to enterprise private clouds, object storage servers, or intranet HTTPS file servers to obtain firmware, the deployment cost and debugging difficulty of the Matter standard OTA link increase significantly. Furthermore, this solution cannot complete device firmware downloads simply by configuring an HTTPS firmware URL, making it difficult to reuse mature and implemented HTTPS file distribution capabilities. Moreover, device upgrade behavior is entirely dependent on the operational status of the ecosystem controller and provider, exhibiting extremely poor flexibility and failing to adapt to the differentiated upgrade needs of various scenarios such as manufacturer production testing, after-sales maintenance, and batch iterations.

[0021] Option 2: Zephyr socket or general downloader upgrade solution.

[0022] In WiFi or Ethernet devices, a common practice is to establish an HTTPS connection via Zephyr sockets, TLS sockets, or vendor downloader components to write the acquired firmware data to the DFU target partition, with the network stack being uniformly scheduled and managed by the system socket layer. However, this solution has limited applicability, only suitable for high-speed network devices with standard socket interfaces, and cannot address the internet HTTPS firmware download needs of low-power Thread devices. For Matter overThread devices, their OpenThread instances are uniformly held, scheduled, and managed by the Matter protocol stack. Forcibly introducing a general socket download link would lead to problems such as unclear network stack ownership, conflicts in Thread stack lock scheduling logic, and excessive system resource consumption. Especially in the nRF Connect SDK Matter official example architecture, Thread communication capabilities are deeply encapsulated by the Matter protocol stack. Building a separate network download channel decoupled from Matter is highly likely to cause system malfunctions, resulting in insufficient compatibility and stability.

[0023] Option 3: Standard HTTP over Thread upgrade solution.

[0024] This system implements basic HTTP GET requests using the OpenThread TCP protocol stack, downloads firmware data from the business server via the Thread network, and writes it to the MCUboot secondary partition to complete the upgrade. While it eliminates reliance on Matter ecosystem OTA components and boasts a relatively lightweight architecture, it suffers from security vulnerabilities. It natively does not support TLS encrypted transmission, server authentication, SNI extensions, or certificate verification mechanisms. The firmware access URL, data packet transmission, and the entire upgrade process are all susceptible to network eavesdropping and data tampering, failing to meet the security and compliance requirements for device firmware upgrades. Furthermore, current mainstream cloud storage, CDN, and object storage services all provide only HTTPS encrypted download addresses by default; ordinary HTTP transmission solutions are incompatible with existing mainstream file distribution services, resulting in extremely poor business adaptability.

[0025] Option 4: A simple streaming download solution with no interruptions.

[0026] The system employs a one-time complete download logic. After the device initiates a firmware download request, it sequentially writes the received data stream into the device's flash storage until the download is complete. If any abnormalities occur during the process, such as network interruption, device power failure, or fluctuations in the Thread link signal, the upgrade will fail immediately, and subsequent restarts will require downloading the complete firmware package from scratch. Because Thread networks inherently have low bandwidth, are susceptible to environmental interference, and firmware packages are typically large, this mechanism significantly increases upgrade time and power consumption, while also greatly increasing the probability of upgrade failure. Furthermore, this solution generally lacks fine-grained verification mechanisms for HTTP status codes, Content-Length, Content-Range, firmware image headers, and data write offsets, which can easily lead to incomplete firmware fragments remaining in the secondary partition and misaligned data, causing device upgrade failures and startup anomalies.

[0027] It is evident that the existing Matter over Thread device firmware upgrade technology system has shortcomings. First, the devices cannot be adapted to the general HTTPS upgrade link. The existing Matter standard OTA solution relies on proprietary ecosystem components and configuration processes, and cannot directly pull firmware through a regular HTTPS URL. Enterprises' existing HTTPS file distribution resources cannot be reused, resulting in high upgrade and deployment costs and poor flexibility.

[0028] Secondly, low-power Thread devices lack mature HTTPS access capabilities. Unlike WiFi devices, Thread devices do not have readily available HTTPS clients or cloud download components. To achieve HTTPS server connectivity, the entire process of OpenThread DNS resolution, TCP connection, NAT64 forwarding at the border, and TLS secure session must be completed independently, which is difficult to develop and costly to implement.

[0029] Third, the general-purpose network download component has poor compatibility with the Matter protocol stack. The OpenThread instance, stack lock scheduling, and event callbacks of Matter over Thread devices are all uniformly managed by the Matter framework. The general-purpose socket download component introduces a duplicate network abstraction layer, causing problems such as system resource conflicts and thread scheduling disorder, resulting in insufficient system integration and stability.

[0030] Fourth, conventional Thread firmware upgrade solutions lack security. Traditional HTTP upgrade methods lack encryption and authentication mechanisms, resulting in serious security vulnerabilities in the firmware transmission process. They cannot meet the security and trust requirements for firmware upgrades in industrial and home-use devices, and are not compatible with mainstream encrypted file distribution services.

[0031] Fifth, the cost of uninterrupted resume mechanism in low-bandwidth Thread scenarios is high. Thread network links have poor stability and limited bandwidth. Upgrade solutions with uninterrupted resume capability will result in full retransmission after abnormal interruption, which will significantly increase upgrade power consumption, time and failure rate, and lead to poor user experience and equipment maintenance efficiency.

[0032] Sixth, the firmware download and DFU writing process lacks a unified and standardized processing mechanism. The data structures of the original MCUboot image file and the Matter OTA package file are significantly different. If the coupling between the download layer and the DFU writing layer is chaotic, problems such as misidentification of the image header, incorrect payload offset, and incomplete writing of multiple images can easily occur, leading to firmware upgrade failure and the inability of the device to start normally.

[0033] Therefore, this embodiment proposes an HTTPS secure firmware upgrade scheme based on Matter over Thread, which reuses the OpenThread TCP stack, to provide low-power Thread devices with an application-layer channel that can access an HTTPS firmware server on the Internet. An HTTPS OTA data channel is directly built on the OpenThread instance managed by Matter. The device resolves the firmware server address via OpenThread DNS, accesses the Internet via Thread Border Router, and establishes a connection via OpenThread TCP. When the URL is HTTPS, mbedTLS is used to complete the TLS handshake and encrypted communication on the TCP stream. The HTTP parsing layer does not care whether the underlying data is plaintext HTTP or HTTPS decrypted plaintext; it only outputs response metadata and body fragments to the OTA layer. The OTA layer then performs breakpoint resumption, format verification, flash writing, completion confirmation, and application upgrade based on the current download offset, image format, total file length, and DFU target status. During the debugging phase, server certificate verification can be disabled for rapid integration testing; during mass production, a trusted CA certificate, fixed certificate fingerprint, or fixed public key can be configured to enable the HTTPS link to have server identity verification capabilities. This security strategy does not change the overall data channel and upgrade process of this invention.

[0034] To facilitate understanding of the inventive concept of this application, the key technical parameters of the HTTPS secure firmware upgrade method based on Matter over Thread and reusing the OpenThread TCP stack are shown in Table 1.

[0035] Table 1:

[0036] It should be noted that the above parameters are recommended settings in this embodiment and can be adjusted according to chip RAM, thread link quality, firmware size and server capabilities, and do not constitute a limitation of this application.

[0037] Reference Figure 1 The diagram shown is an architectural schematic of an HTTPS secure firmware upgrade system adapted to Matter over Thread devices, as illustrated in an embodiment of this application. The HTTPS secure firmware upgrade system includes a Matter over Thread device side, a Thread network side, and an HTTPS server side.

[0038] Among them, the Matter over Thread device side is the core of the upgrade execution, which is implemented by 10 functional modules working in layers to achieve the entire link of triggering, policy control, network transmission, and firmware writing; the Thread network side is responsible for the device's internal network networking and Internet boundary forwarding capabilities, including Thread Mesh network and Thread Border Router; the HTTPS server side provides standardized firmware storage and breakpoint resume response capabilities, and is equipped with firmware service programs and firmware image files that support Range fragmentation requests.

[0039] The Matter over Thread device-side configuration includes an upgrade trigger module, an OTA upgrade strategy module, an HTTP / 1.1 parsing module (i.e., an HTTP parsing module), a breakpoint resume and progress saving module, a DFU writing module, an HTTPS / TLS adaptation module, an OpenThread transmission module, an MCUboot upgrade application module, and a Matter Thread stack management module. The upgrade trigger module can be triggered by Shell commands, Matter commands, timed policies, or cloud policies. Input parameters include at least the firmware URL and the total length of the firmware file, and may also include the image number or image format. The OTA upgrade strategy module manages the upgrade state machine, determines whether to continue downloading from the breakpoint, verifies whether the HTTP response meets expectations, and writes the body data to the DFU target. The HTTP parsing module parses the HTTP / 1.1 status line, response headers, Content-Length, Content-Range, Transfer-Encoding: chunked, and redirection location information. The HTTPS / TLS adaptation module is located between the HTTP parsing module and the OpenThread transmission module. When the URL is https: / / , this module initializes the mbedTLS client session, configures random number generation, SNI, and certificate verification policies, and adapts the OpenThread TCP send / receive functions to mbedTLS BIO callbacks. The OpenThread transport module uses the OpenThread instance provided by the Matter Thread stack management module to perform DNSAAAA resolution, A record / NAT64 resolution, TCP endpoint initialization, TCP connection establishment, send buffering, and receive callbacks. To ensure safe coexistence with the Matter stack, critical operations such as initiating and closing connections are protected by Thread stack locks. The breakpoint resume and progress saving module is used to save the offsets already written to flash. For the original MCUboot image, this offset comes from the DFUtarget; for the Matter OTA package file, this module saves the payload start position, payload size, and multi-image write offset. The DFU write module writes the verified firmware data to the MCUboot secondary slot or multi-image target. After the upgrade is complete, the MCUboot upgrade application module schedules the new firmware, and the Bootloader completes the installation after the device reboots. The Thread network side consists of a Thread Mesh network and a Thread Border Router. If the server has an IPv6 address, the device can access it directly through Thread IPv6 routing; if the server only has an IPv4 address, it can be accessed through A record resolution and NAT64.The server provides HTTPS firmware files and supports HTTP Range responses, allowing the device to resume downloading from where it was interrupted.

[0040] Specifically, the upgrade trigger module receives the upgrade start command and parses the input parameters. A typical command is `http otastart`. <url><file_size>[image_number] or http ota start-matter <url><file_size>The `file_size` parameter is used to initialize the DFU target and perform integrity verification, preventing the device from blindly writing to flash without knowing the total length. The OTA upgrade strategy module is the control center of the upgrade process, responsible for starting, pausing, resuming, canceling, and applying upgrades. This module selects either the original MCUboot write process or the Matter OTA multi-image write process based on the image format; determines whether to construct an HTTP Range request based on the written offset; and performs writing, progress reporting, error handling, and completion confirmation based on HTTP response events and body data events. The HTTP / 1.1 parsing module is responsible for constructing GET and Range requests, supporting host, port, and path parsing for http: / / and https: / / URLs; supporting the Host header format for IPv6 literal addresses; and parsing HTTP status codes, Content-Length, Content-Range, Transfer-Encoding: chunked, Connection: closed, and Location. When body data arrives, this module outputs data fragments as events, without directly participating in flash writing, thus decoupling from the OTA strategy. The HTTPS / TLS adaptation module is enabled when the URL is HTTPS. After the OpenThread TCP connection is established, this module enters the TLS handshake state, using mbedTLS to complete the TLS 1.2 client handshake, SNI hostname setting, random number generation, and certificate verification policy configuration. TCP ciphertext received by OpenThread is first buffered and then read and decrypted by mbedTLS; plaintext output by mbedTLS is sent to the HTTP parsing module. HTTP GET requests are first encrypted by mbedTLS and then sent via OpenThread TCP. The OpenThread transport module directly uses the OpenThreadDNS and TCP APIs, without relying on Zephyr sockets. This module serves as the foundational bridging layer for low-power Thread devices to access the internet, connecting the OpenThread capabilities on the Thread device side with the HTTPS file service on the server side. DNS resolution prioritizes querying AAAA records; if that fails, it attempts to access IPv4 servers using A records and NAT64. The TCP connection uses the OpenThread TCP endpoint and a circular send buffer. The receiving side reads TCP segments using otTcpReceiveByReference() and calls commit to release the buffer after processing.The MatterThread stack management module provides an initialized OpenThread instance for the Matter framework and provides Thread stack locks during operations such as initiating GET requests and closing connections to prevent application upgrade threads and Matter / OpenThread event handling from concurrently accessing the same protocol stack. The breakpoint resume and progress saving module obtains the current written offset through the DFU target for the original MCUboot image; for Matter OTA files, it saves the total file length, payload start point, and payload size through settings and obtains the internal offset of the payload through DFU multi-image. After device reboot, restarting the upgrade with the same URL and file size allows downloading to continue from the saved offset. The DFU write module checks if the first 32 bytes of the image header of the original MCUboot image are indeed the MCUboot image before writing them sequentially to the secondary slot; for Matter OTA files, it parses the Matter OTA header to confirm that the payload size matches the total file size before writing the payload to the multi-image target. Writing uses the DFU target API, supporting the handling of unaligned HTTP fragments by the DFU stream's internal buffer. After the MCUboot upgrade application module completes download and execution confirmation, it calls the upgrade scheduling interface to mark the new firmware as pending installation. After the device restarts, MCUboot installs the new firmware from the secondary slot. Downloading and installation are separated to avoid accidentally triggering an upgrade before the download is complete.

[0041] The Thread network side serves as the carrier for device intranet networking and internet boundary forwarding, consisting of two parts: the Thread Mesh network and the Thread Border Router. Matter over Thread devices rely on the ThreadMesh network to complete low-power, multi-hop relay communication between multiple nodes, adapting to distributed deployment scenarios of multiple smart home devices. The ThreadBorder Router undertakes cross-network routing and forwarding functions. When the remote HTTPS server deploys an IPv6 network, it directly forwards device access requests through native Thread IPv6 routing. When the server only supports IPv4 networks, it enables the NAT64 protocol to complete IPv6 to IPv4 address translation, and works with the device's DNS resolution results to achieve cross-network segment communication. It is fully compatible with the Thread protocol's low-power sleep and time slot scheduling mechanisms, and will not destroy the original low-power operation characteristics of the device due to service upgrades.

[0042] On the HTTPS server side, the hardware carrier can be public cloud object storage, CDN acceleration nodes, or a private HTTPS file server within the enterprise intranet. The server locally stores two types of firmware image files: the raw native MCUboot image and the standard Matter OTA packaged image. The server has a built-in Range response module that can identify fragmented HTTP requests from the device that carry the Content-Range field, and return a 206 Partial Content fragmented response message and the corresponding firmware data to the device, fully supporting the device's breakpoint resume interaction logic. The server enforces standard HTTPS encryption service, is compatible with SNI extensions and trusted server certificate verification systems, and can directly reuse the enterprise's existing mature HTTPS file distribution and CDN acceleration infrastructure without the need to deploy additional Matter standard OTA Provider components, significantly reducing the upgrade, deployment, and debugging costs for manufacturers in all scenarios of production, testing, and after-sales.

[0043] In practice, maintenance personnel issue the native MCUboot image upgrade command `httpota start https: / / xxx.xxx / firmware-v2.bin 1048576` via the device's local shell. The upgrade trigger module parses the parameters and sends them to the OTA upgrade strategy module. The OTA upgrade strategy module reads the breakpoint resume and progress save module, and after confirming there are no historical upgrade breakpoints, issues a complete firmware download command. The HTTP / 1.1 parsing module generates an HTTPS standard GET request, and the message is encrypted with TLS by the HTTPS / TLS adaptation module and sent to the OpenThread transmission module. The OpenThread transmission module requests stack lock protection from the MatterThread stack management module, calls the OpenThread DNS and TCP interfaces, and accesses the remote HTTPS server via the Thread Mesh network and Thread Border Router. The server Range response module returns a complete response message and firmware fragments. The data is transmitted back to the device via the Thread network, and after being decrypted by the OpenThread transmission module, the HTTPS / TLS adaptation module, and fragmented by the HTTP / 1.1 parsing module, the plaintext firmware fragments are pushed to the OTA upgrade strategy module. The OTA upgrade strategy module schedules the DFU writing module to write the firmware fragments to the MCUboot image segment by segment. The secondary partition is updated and stored in real time by the breakpoint resume and progress saving module. If the thread link is interrupted during operation, the same upgrade command is reissued after the device restarts. The system automatically reads the historical offset to construct a Range fragmentation request and resumes the remaining firmware from the interruption position. After all firmware fragments are written and integrity verification is completed, the MCUboot upgrade application module marks the new firmware as pending activation. When the device is powered on and restarted next time, the Bootloader will complete the new firmware switching and installation.

[0044] This embodiment utilizes an HTTPS secure firmware upgrade system, enabling direct connection to any HTTPS firmware URL without relying on Matter ecosystem OTA providers, thus reusing existing enterprise file distribution resources. Transmission is entirely based on Matter's uniformly managed OpenThread protocol stack, eliminating network stack resource conflicts caused by general Socket components. End-to-end TLS encrypted transmission meets the security and trust requirements for firmware upgrades. In low-bandwidth, high-fluctuation network scenarios, breakpoint resumption reduces retransmission power consumption and failure rate. Independent verification and writing logic is set up for the MCUboot native image and Matter OTA packaged image, resolving image parsing and partition writing errors, balancing upgrade flexibility, transmission security, system stability, and low-power adaptation requirements.

[0045] Reference Figure 2 The diagram illustrates a flowchart of an HTTPS secure firmware upgrade method according to an embodiment of this application. This HTTPS secure firmware upgrade method is applied to Matter over Thread embedded devices, particularly low-power Matter over Thread devices based on nRF Connect SDK, Matter protocol stack, OpenThread protocol stack, mbedTLS, and MCUboot. The Matter over Thread device connects to a Thread Mesh network and accesses an external HTTPS firmware server through a Thread border router. While the Matter over Thread embedded device already possesses Thread IPv6 networking capabilities, it is not a WiFi device and does not inherently possess the common internet HTTPS access libraries, socket downloaders, or cloud file download SDKs found on WiFi devices. Furthermore, it is not suitable to introduce WiFi or BLE DFU processes for upgrades. In other words, the Matter over Thread device, in a non-WiFi Thread device without readily available HTTPS download libraries, combines OpenThreadDNS, OpenThread TCP, Thread Border Router IPv6 routing or NAT64, TLS sessions, and HTTP download processes into a complete internet access link. The HTTPS secure firmware upgrade method includes the following steps.

[0046] To facilitate understanding of the inventive concept of this application, the following embodiment uses a Matter over Thread smoke detector as an example. The device has completed Thread network access and can access the HTTPS firmware file in the enterprise object storage through the Thread Border Router, and upgrade the Matter over Thread smoke detector through the HTTPS object storage.

[0047] S21, Receive the parsing upgrade trigger instruction and obtain the upgrade context parameter set.

[0048] Refer to together Figure 3 In some embodiments, the device can receive upgrade trigger commands locally through four channels: device Shell interactive commands, Matter standard protocol control commands, local scheduled upgrade tasks, and cloud-based remote upgrade strategies. These commands uniformly carry basic parameters. These basic parameters may include, but are not limited to: firmware access URL, total firmware file length (file_size), and extended parameters such as image number (image_number) and image format identifier (image_format). The image format identifier distinguishes between Raw MCUboot native images and Matter OTA packaged images. Upon receiving an upgrade request, the device first initializes the global OTA context and checks for any incomplete historical download tasks. It then integrates the basic parameters, such as URL, file_size, image format identifier, and image number, to generate a standardized upgrade context parameter set.

[0049] S22, read the breakpoint offset according to the upgrade context parameter set, and generate the target HTTP request message according to the breakpoint offset.

[0050] When a device initiates a new upgrade task or resumes an interrupted upgrade task, it relies on the upgrade context parameter set to complete the breakpoint offset reading and request message construction. Specifically, the device first extracts the image format identifier carried in the upgrade context, distinguishes between two types of firmware: the original MCUboot image and the Matter OTA packaged image, and reads the write offset of the corresponding persistent storage area according to the image type as the global breakpoint offset; it performs a validity check on the read global breakpoint offset to ensure that the offset value does not exceed the total firmware length recorded in the upgrade context; then, based on the numerical relationship between the global breakpoint offset and the total firmware length, it constructs an HTTP request message according to the scenario, and outputs a unique target HTTP request message to be sent to the network parsing process.

[0051] In an optional implementation, the step of reading the breakpoint offset based on the upgrade context parameter set and generating the target HTTP request message based on the breakpoint offset includes: The image type is distinguished based on the image format identifier in the upgrade context parameter set; the image type includes the original MCUboot image and the Matter OTA packaged image; If it is the original MCUboot image, call the DFU target interface to read the offset of the bytes already written to Flash as the breakpoint offset; if it is the Matter OTA packaged image, read the persistent payload start position, total payload size, and multi-image internal write offset, and calculate the global breakpoint offset in combination with the total firmware length. Determine whether the global breakpoint offset is greater than 0; If the global breakpoint offset is equal to 0, a full-range GET request is generated as the target HTTP request message; if the global breakpoint offset is greater than 0, a fragmented GET request carrying the Content-Range field is generated as the target HTTP request message.

[0052] Refer to together Figure 3 and Figure 6 In some embodiments, the device reads the image format identifier from the upgrade context parameter set to distinguish between two branches: hardware initialization and breakpoint read. If the identifier is a Raw MCUboot native image, the device initializes the MCUboot DFU target partition, configures the Flash write buffer, and directly reads the bytes already written in the DFU partition as the global download offset downloaded. If the identifier is a Matter OTA packaged image, the device initializes the DFU multi-image module, registers the image writer, reads the persistently saved payload start position, total payload size, and internal payload write offset from the device's non-volatile settings storage, and calculates the global download offset downloaded by combining it with the total firmware length in the context, i.e., the breakpoint resume offset resume_offset (also known as the global breakpoint offset). The device determines whether the global download offset downloaded is greater than 0. If downloaded is greater than 0, it means there is an incomplete historical upgrade progress, and a Range resume GET request carrying the Range: bytes=downloaded-fragment field is constructed as the target HTTP request message. If downloaded is equal to 0, it means a brand new download task, and a normal complete GET request without the fragment field is constructed as the target HTTP request message.

[0053] If the global breakpoint offset read is greater than the total firmware length, the offset data is determined to be abnormal. The device terminates the current upgrade process and reports an offset parameter error, retains the original persistent transmission information, and waits for the user to reissue a valid upgrade command.

[0054] S23, obtain server network connection information by parsing the firmware URL in the upgrade context parameter set.

[0055] S24. Obtain the initialized OpenThread instance and apply a Thread mutex lock to the OpenThread instance to obtain a locked OpenThread instance.

[0056] The device sequentially completes URL resolution, DNS domain name resolution, and OpenThread instance locking operations, outputting server network connection information carrying the protocol, IP, and port, along with the locked OpenThread instance.

[0057] In an optional implementation, obtaining the server network connection information by resolving the firmware URL from the upgrade context parameter set includes: The firmware URL is parsed to distinguish whether the corresponding transmission protocol is HTTP or HTTPS, and the domain name, port information, and resource access path are extracted, while the Host header is compatible with IPv6 literal format. Perform DNS resolution operations on the extracted domain names, prioritizing the query of the IPv6 AAAA record corresponding to the domain name; If the AAAA record query fails, then query the domain A record and use the Thread border router to obtain the IPv4 mapping address through NAT64 protocol translation; The server network connection information is generated by integrating the transmission protocol, the parsed server IP address, and the extracted port information.

[0058] Refer to together Figure 3 In some embodiments, the device extracts the firmware URL from the upgrade context parameter set, performs complete URL parsing, distinguishes between HTTP plaintext protocol (HTTP) and HTTPS encrypted protocol (HTTPS), and simultaneously extracts the domain name, port information, and resource access path. The parsing logic is compatible with the IPv6 literal Host header writing format. The device calls its own OpenThread protocol stack instance, which has already completed power-on initialization, and applies a global Thread mutex lock to this instance to obtain a locked and protected OpenThread instance. Further, based on this locked instance, the device calls the OpenThread native DNS interface to perform domain name resolution. The resolution strategy follows the IPv6 priority principle, prioritizing the query of the domain name AAAA record to obtain the IPv6 server address. If the AAAA record query fails, the device queries the domain name A record to obtain the IPv4 address, and uses the Thread border router NAT64 protocol to complete the IPv6 / IPv4 address mapping conversion to obtain an IPv6 mapping address that OpenThread can recognize. The device integrates the parsed transport protocol, server IP address, and port information to generate server network connection information.

[0059] S25, establish an OpenThread TCP transmission channel based on the locked OpenThread instance and the server network connection information, and release the Thread mutex lock of the OpenThread instance after the TCP connection is established.

[0060] Once the locked OpenThread instance and server network connection information are obtained, the device uses the locked OpenThread instance to create a TCP link, initiates a TCP connection based on the server network connection information, and releases the protocol stack mutex lock after the link is ready, generating a TCP transmission channel that can be used to send and receive data.

[0061] In an optional implementation, establishing an OpenThread TCP transmission channel based on the locked OpenThread instance and the server network connection information includes: Initialize the TCP endpoint and the circular send buffer based on the locked OpenThread instance; Initiate a TCP connection request based on the server IP address and port information in the server network connection information; Listen for TCP connection ready callbacks. After successfully establishing a TCP connection, release the Thread mutex lock corresponding to the OpenThread instance and obtain a usable OpenThread TCP transmission channel.

[0062] Refer to together Figure 3 In some embodiments, the device initializes the TCP endpoint and circular send buffer based on a lock-protected OpenThread instance, reads the server IP address and port information from the server network connection information, and initiates a long TCP connection by calling the OpenThread native TCP interface. The device continuously listens for TCP established ready callback events. When it hears a callback signal indicating that the TCP connection has been successfully established, it releases the Thread global mutex lock previously applied to the OpenThread instance, thus obtaining a usable OpenThread TCP transmission channel. The request sending processing flow is then initiated by outputting the TCP transmission channel and the corresponding circular send / receive buffer.

[0063] S26, perform transmission processing according to the OpenThread TCP transmission channel and the target HTTP request message; if the firmware URL is HTTPS, complete the TLS handshake based on mbedTLS and encrypt the target HTTP request message before sending; if the firmware URL is HTTP, send the target HTTP request message directly.

[0064] HTTPS does not establish a separate network stack; instead, it uses the OpenThreadTCP connection already managed by Matter as the underlying TLS transport. The mbedTLS send callback writes the TLS ciphertext to the OpenThread TCP circularsend buffer; the OpenThread TCP receive callback puts the ciphertext returned by the server into the TLS ciphertext buffer, and then drives mbedTLS to read it. The HTTP plaintext obtained from TLS decryption continues into the same HTTP parsing module. Therefore, HTTP and HTTPS maintain consistency in response parsing, range continuation, and OTA write strategies.

[0065] Refer to together Figure 4 and Figure 5 In some embodiments, after the OTA policy module initiates a download request to the HTTP client, the HTTP client calls the OpenThread DNS / TCP component to complete domain name resolution and TCP connection creation. Once the TCP link is ready, the OpenThread instance lock is not released. If the target address is an HTTPS protocol, the mbedTLS client session is initialized, and the OpenThread TCP send / receive callbacks are adapted to the mbedTLS standard BIO read / write interface. A TLS handshake interaction, including SNI, random number generation, and certificate verification, is completed using the existing TCP channel. During the data transmission phase, the device sends the target HTTP plaintext to mbedTLS for encryption to generate ciphertext. This ciphertext is then written to the OpenThread TCP circular send buffer via the BIO send interface and sent to the HTTPS server via the established TCP channel. During the data reception phase, the OpenThread TCP receive callback captures the ciphertext sent by the server, stores it in the TLS ciphertext cache, and then calls the mbedTLS BIO recv interface to read and decrypt the ciphertext. After stripping the TLS encapsulation, the original HTTP plaintext is output. After plaintext output, it is directly sent to a unified HTTP parsing module for processing. It shares the same set of response parsing, range continuation, and firmware fragmentation writing logic as the pure HTTP plaintext link. Only the underlying transmission distinguishes between encrypted and plaintext links, while the upper-layer OTA business processing logic is completely reused. If the firmware URL is an HTTP protocol, the entire process of mbedTLS initialization, handshake, encryption, and decryption is skipped, and the HTTP plaintext is directly sent through the OpenThread TCP channel.

[0066] In some embodiments, mbedTLS and OpenThread TCP adopt a non-blocking callback linkage design, reusing the same TCP link throughout the handshake and encrypted transmission and reception process, without the need to allocate additional independent sockets and transmission buffers, thus reducing the memory overhead of low-power Thread devices; HTTP and HTTPS share the same set of upper-layer OTA business logic, eliminating the need to develop two separate sets of message parsing, breakpoint resumption, and DFU writing handlers, simplifying code maintenance and firmware integration.

[0067] To facilitate understanding of the inventive concept, the following embodiments provide a specific example of a mass production security configuration. During the R&D and debugging phase, HTTPS certificate verification can be temporarily disabled to quickly confirm the Thread TCP, TLS handshake, and firmware download links. During mass production, a trusted CA certificate, server certificate fingerprint, or server public key fingerprint should be configured in the firmware, and certificate verification should be enabled. Specifically, the server hostname is set during TLS initialization for SNI and certificate hostname matching. The server certificate chain or fixed public key is verified during the TLS handshake phase. An HTTP GET request is sent only after successful verification. If verification fails, a TLS error is reported, and the HTTP parsing and DFU write process is not initiated. It is evident that debugging convenience and mass production security can be switched through configuration; after mass production, it can prevent the device from connecting to a fake server or downloading tampered firmware files.

[0068] S27. Receive TCP data sent by the server through the OpenThread TCP transmission channel. Under the HTTPS link, decrypt the TCP ciphertext to obtain HTTP plaintext. Under the HTTP link, directly obtain the plaintext. Perform unified message parsing on the HTTP plaintext and verify the legality of the response. If the verification is invalid, close the current TCP transmission link, stop firmware data reception, and retain the current breakpoint offset. If the verification is valid, output segmented firmware data fragments.

[0069] Refer to together Figure 4 and Figure 7 In some embodiments, the device continuously pulls the TCP data stream within the channel through the OpenThread zero-copy read interface. If the current transmission link is HTTPS encrypted, the received ciphertext data stream is sent to the initialized mbedTLS session for decryption, and the original HTTP plaintext is output after stripping the TLS encapsulation. If the transmission link is HTTP plaintext, no decryption is required, and the TCP payload is directly extracted as the HTTP plaintext message. The device performs standardized parsing on the decrypted / directly obtained HTTP plaintext, extracts key fields in the message header, including the HTTP response status code, Content-Length, Content-Range, Transfer-Encoding chunk identifier, and redirection location address, distinguishes whether the current request type is a normal complete GET request or a fragmented Range continuation request, and enters the corresponding validity verification branch.

[0070] If the current request is a Range fragmented download request, check if the server returns a 206 PartialContent status code. If not, the response is considered invalid. If a 206 status code is returned, further verify that the total length recorded in Content-Range matches the total length of the firmware within the upgrade context. If the current request is a normal GET full download request, check if the server returns a 200 OK or 206 Partial Content status code. If the status code does not meet the requirements, the response is considered invalid. If valid, verify that the Content-Length value matches the total length of the firmware. If the response is deemed invalid, the device immediately closes the current TCP and TLS transmission links, stops receiving all subsequent firmware data, and does not erase the persistent breakpoint offset and Matter OTA resume parameters stored in non-volatile storage. It directly enters the PAUSED / ERROR state, waiting for the user to issue a recovery command.

[0071] If both the status code and file length verifications pass, the device continuously receives the HTTP body payload from the server, segments it according to TCP fragmentation to generate firmware data fragments, and outputs them segment by segment to the subsequent DFU partition write process. Throughout the segmented reception and writing process, the device continuously monitors for transmission and Flash write anomalies. If any anomalies occur, such as network disconnection or Flash write failure, the transmission link is immediately shut down, preserving all stored download progress. When the device restarts to resume the upgrade, it can read the saved breakpoint offset and initiate a Range resume request from the interrupted position, without needing to re-download the entire firmware package. The device determines that the firmware has been fully received only when the cumulative downloaded bytes are exactly equal to the total firmware length, and then clears all resume information.

[0072] By using a unified plaintext parsing module compatible with both HTTP and HTTPS transmission links, and relying on a strict dual verification mechanism of HTTP status codes and file length, it prevents issues such as server-returned incorrect fragments or mismatched firmware sizes that could lead to partition image corruption. In abnormal scenarios, it permanently retains breakpoint offsets, adapts to working environments with low Thread bandwidth and easily disconnected wireless links, and enables secure and recoverable fragment firmware distribution.

[0073] pass Figure 6 The device uses the persistent write offset in the DFU target as a trusted source of progress (independent of application-layer variables). For Matter OTA files, it also reads the payload start point and payload size, and calculates the overall file download offset using payload_start + payload_offset; based on this, it decides whether to complete directly, send a Range request, or send a regular GET request. Figure 7 It strictly verifies the 206 status code, the total length of Content-Range, and the remaining length of Content-Length. If the verification fails, it will refuse to write. If a download or write error occurs, it will close the connection and retain the progress. When resuming, it will continue from the latest offset.

[0074] Even if the device loses power after parsing the header, it can still locate the correct HTTP Range starting point upon the next startup. If a network disconnection, TLS error, HTTP error, length mismatch, or DFU write error occurs during the upgrade process, the device enters a paused or error state, but the written progress is not cleared.

[0075] S28. Based on the image format identifier in the upgrade context parameter set, the segmented firmware data fragment is written to the corresponding DFU partition, the Flash write offset is updated synchronously in real time, and the updated Flash write offset is persistently stored.

[0076] When a segmented firmware data fragment is obtained, the device reads the image format identifier in the upgrade context parameter set, distinguishes between the two firmware images, performs differential verification and partition writing operations, and after each firmware segment is written, it accumulates and updates the global Flash write offset in real time, and stores the updated offset value and Matter OTA exclusive payload positioning information into the device's non-volatile storage medium for persistent storage.

[0077] In an optional implementation, writing the segmented firmware data fragments to the corresponding DFU partition based on the image format identifier in the upgrade context parameter set includes: If the image format identifier corresponds to the original MCUboot image, verify whether the first 32 bytes of the firmware image header are valid. After the image header verification is successful, call the DFU target streaming interface to sequentially write the segmented firmware data fragments into the MCUboot secondary partition. If the image format identifier corresponds to a Matter OTA packaged image, accumulate segmented firmware data fragments and parse the Matter OTA header. After verifying that the payload size recorded in the header matches the total firmware length in the upgrade context parameter set, strip the Matter OTA header and write only the data fragment corresponding to the payload into the DFU multi-image target partition.

[0078] Refer to together Figure 4 and Figure 8 In some embodiments, the device reads the image format identifier within the upgrade context and performs differentiated partitioning write operations on the segmented firmware data fragments. Specifically, if the image format identifier corresponds to the original MCUboot image, the device first determines whether the image header verification is complete. If not, it caches the first 32 bytes of firmware data in the current segment and calls the image type identification interface to verify the image header's validity. If the identification determines that it is not a valid MCUboot image, it reports an IMAGE_TYPE error and terminates all write operations. If the image header verification passes, it calls the DFU target streaming interface to sequentially write all segmented firmware data fragments, including the image header, to the MCUboot secondary spare partition. If the image format identifier corresponds to a Matter OTA packaged image, the device first determines whether Matter OTA header parsing is complete. If the header is not parsed, it continuously accumulates segmented firmware data fragments until the Matter OTA header is completely parsed and the payload_size is extracted. It verifies whether the sum of the payload start position and payload_size recorded in the header is equal to the total length of the firmware in the upgrade context parameter set. If they do not match, it reports a SIZE error and stops writing. After the size verification matches, it saves the two types of Matter continuation information, payload_start and payload_size, to non-volatile storage and strips the Matter. For redundant data in the OTA header, only the data fragments corresponding to the valid payload are written to the DFU multi-image target partition using the dfu_multi_image_write interface; if header parsing has been completed previously, the header parsing process is skipped, and only the payload fragment data is written.

[0079] By differentiating the two upgrade file formats, the original MCUboot image is directly written to the MCUbootsecondary slot, but the first 32 bytes of the image header must be verified first to prevent non-firmware files from being written to the upgrade partition. The MatterOT file contains a Matter OTA header, and the payload part is what actually needs to be written to the MCUboot or multi-image target. Therefore, the device first parses the header to confirm that the payload size is consistent with the total file size, and then writes the payload fragment to the multi-image target.

[0080] S29, perform download integrity verification based on the updated Flash write offset and the total firmware length in the upgrade context parameter set, and perform firmware activation or upgrade suspension processing based on the verification result.

[0081] After the device completes the single-segment firmware fragment writing and Flash write offset update persistence, it reads the persisted download progress and compares it with the total firmware length for integrity. Based on the comparison result, it performs either firmware activation mark-up or pauses upgrade to preserve progress.

[0082] In an optional implementation, the step of performing a download integrity check based on the updated Flash write offset and the total firmware length in the upgrade context parameter set, and performing firmware activation or upgrade suspension processing based on the check result, includes: Compare the updated Flash write offset with the total firmware length in the upgrade context parameter set; If the updated Flash write offset is equal to the total length of the firmware, the MCUboot interface is called to mark the new firmware as pending activation. After the device restarts, the MCUboot will complete the firmware installation. If the updated Flash write offset is not equal to the total length of the firmware, the current upgrade task is paused, and the write offset of persistent storage is retained.

[0083] Refer to together Figure 4 In some embodiments, the device reads the Flash write offset from persistent storage and the total firmware length `file_size` in the upgrade context parameter set, and performs a numerical comparison verification: if the Flash write offset is exactly equal to `file_size`, it is determined that the firmware download is complete. The device clears all resume progress information in non-volatile storage, calls the MCUboot upgrade scheduling interface, and marks the new firmware in the secondary partition / multi-image partition as pending activation. The device maintains the currently running firmware and does not actively trigger a restart. When the device is subsequently powered on and restarted actively / passively, the underlying MCUboot Bootloader recognizes the pending activation mark and automatically completes the switching between the old and new firmware partitions and the installation of the new firmware. If the Flash write offset is less than `file_size`, it is determined that the firmware has not been completely downloaded. The device puts the current upgrade task into a paused state, retaining all persistent storage write offsets and resume parameters. After the device restarts, when the user issues an upgrade command with the same URL and the same `file_size`, the historical breakpoint offset can be directly read, and a Range fragment request can be automatically constructed to resume the remaining firmware from the interrupted position, without having to download the complete firmware package again.

[0084] pass Figure 3 and Figure 4 Starting with the upgrade request, the process involves OTA context initialization, image format branching, DFU offset reading, Range / GET request construction, and URL parsing, followed by the network transmission phase. After network transmission, the process includes HTTP response verification, writing to flash according to the image format, download integrity determination, DFU completion confirmation, and MCUboot upgrade scheduling. Specifically, before initiating the network connection, the local DFU offset is read to determine whether to use a Range; before writing to flash, the HTTP response and image format are verified; and DFU completion confirmation and upgrade scheduling are only executed after the number of downloaded bytes equals the expected file_size.

[0085] If the device is in a resumeable download state, the server must return a 206 Partial Content response. If the server ignores the Range request and returns a 200 OK response, the device stops downloading to avoid writing the complete file from a non-zero offset, which could cause firmware misalignment.

[0086] To facilitate understanding of the inventive concept, the following embodiment provides a specific example of resuming a download after an upgrade interruption. Assume that when the device downloads firmware to 40%, the TCP connection is lost due to attenuation of the Thread wireless signal. After the transmission link abnormality, the HTTP client reports a transmission error, and the OTA upgrade status switches to a paused or error state. The device does not clear the persistently stored DFU download progress. When the user issues a resume upgrade command (resume) again, or reissues an upgrade start command carrying the same firmware URL and the same total firmware length (file_size), the OTA module calls the DFU offset read interface, identifies the firmware data already written in the secondary partition, reads the global breakpoint offset, and constructs a data structure carrying Range: bytes= <offset>- The fragment GET request for the field is sent to the server. After receiving the server's response, the device performs a validity check. If the server returns a 206 Partial Content status code, and the total file length marked with Content-Range matches the preset file_size, then the remaining missing firmware fragments are written. If the server returns a 200 status code, or the message length does not match the total firmware length, then the Flash write operation is directly rejected to avoid image corruption caused by offset misalignment. Through the above breakpoint resumption mechanism, temporary interruptions in the Thread network do not require re-downloading the complete firmware package, effectively shortening upgrade time and reducing wireless transmission power consumption. At the same time, relying on the dual verification mechanism of 206 status code and message length, the risk of firmware write errors caused by abnormal resumption is avoided.

[0087] This document also provides a specific example of payload parsing and multi-image writing for Matter OTA files. The firmware file downloaded by the device is not a raw MCUboot image, but a Matter OTA format file. This file contains a Matter OTA header at the beginning, and the actual firmware data to be written to the DFU target is the payload at the end. Specifically, the OTA module initiates the Matter format upgrade process, initializes the DFU multi-image, and registers an image writer. After the HTTP body arrives, the Matter OTA header parser accumulates and parses the header. Upon successful parsing, the payload size is obtained, and the payload start offset is calculated. The device verifies whether payload_start + payload_size equals the passed file_size. If the verification passes, the Matter resume information is saved, and subsequent payload fragments are written to the multi-image target. If the device loses power during payload writing, the payload location information is read from settings upon the next startup, and the resume position is calculated using the multi-image offset. It is evident that the same HTTPS download link can handle both Raw MCUboot images and Matter OTA encapsulated files; the Matter OTA header will not be incorrectly written to the DFU payload target, and the correct offset is maintained during resume.

[0088] This application proposes an HTTPS OTA Secure Firmware Upgrade Architecture (HOSFUA) based on the Matter over Thread native protocol stack. It relies on the OpenThread, mbedTLS, and MCUboot components natively integrated into the device to build an end-to-end external network firmware download link. It eliminates the need for additional independent transmission components, dedicated upgrade gateways, or auxiliary wireless communication channels, and forms a complete closed-loop solution for industry pain points such as the lack of native HTTPS download libraries, limited network bandwidth, easy link interruption, difficulty in compatibility of multiple firmware formats, and the risk of image corruption during upgrades in low-power Thread devices.Compared to existing technologies, this architecture enables low-power Thread devices without a supporting HTTPS download library to establish a complete external network access link comprised of OpenThread DNS, OpenThread TCP, Thread border router IPv6 routing and NAT64 translation, and the mbedTLS TLS adaptation layer. This allows devices to directly connect to an internet HTTPS firmware server for upgrades without the need for additional Matter OTA Provider deployment or auxiliary communication channels such as WiFi or BLE; firmware fetching can be completed solely through the Thread Mesh network. It fully reuses the native DNS and TCP interfaces of the OpenThread protocol stack, which is uniformly managed by Matter, eliminating the need for third-party general-purpose socket download components. A global mutex lock in Thread ensures safe collaboration between the protocol stack and Matter business threads, effectively reducing device memory resource consumption and software integration complexity. Simultaneously, it innovatively builds an mbedTLS BIO adaptation layer, fully carrying out TLS encrypted sessions within OpenThread. On top of the TCP transport stream, this solution enables low-power Thread devices to securely connect to public cloud object storage, CDN, and enterprise intranet HTTPS file services. It also ensures that HTTP plaintext transmission and HTTPS encrypted transmission share the same set of message parsing, Range breakpoint resumption, length verification, firmware fragment distribution, and DFU partition writing business logic, eliminating code redundancy and inconsistent business behavior caused by dual transmission protocols. For use cases with low Thread network bandwidth, frequent wireless connection drops, and the risk of unexpected device power loss, it combines DFU partition write offset, Matter OTA payload offset persistent storage mechanism, and HTTP Range fragmentation requests to achieve efficient breakpoint resumption. After network interruption or device power loss recovery, only missing firmware fragments are incrementally downloaded, significantly shortening upgrade time and reducing wireless transmission power consumption. The entire solution incorporates a multi-level security verification mechanism, sequentially verifying the HTTP response status code, Content-Length, Content-Range, total firmware length, Raw MCUboot image header, Matter... The OTA payload size is jointly verified. If the server does not respond to the fragmentation request in compliance with regulations, the Flash write operation is terminated directly, avoiding the problem of device bricking caused by misaligned data and illegal image writing to the storage partition from the source. In addition, the architecture can be compatible with two mainstream firmware formats: native MCUboot bare image and standard Matter OTA packaged file. Different verification and partition writing logic are designed for the two types of images, which can adapt to the diverse firmware packaging and release processes of manufacturers and take into account the controllable upgrade scheduling needs of all scenarios such as R&D debugging, mass production and remote after-sales.In addition, it supports status operations such as start, pause, resume, abort, apply, and status, which can be used for R&D debugging or encapsulated into mass production upgrade processes by the product application layer or Matter commands.

[0089] Reference Figure 9 The diagram shown is a functional block diagram of an HTTPS secure firmware upgrade device according to an embodiment of this application.

[0090] In some embodiments, the HTTPS secure firmware upgrade device 90 may include multiple functional modules composed of computer program segments. The computer programs of each program segment of the HTTPS secure firmware upgrade device 90 may be stored in the memory of the Matter over Thread device and executed by at least one processor to perform the HTTPS secure firmware upgrade function. Based on the functions they perform, they can be divided into multiple functional modules. The functional modules may include: a parameter acquisition module 901, a message generation module 902, a network parsing module 903, a thread lock protection module 904, a channel establishment module 905, a secure transmission module 906, a data reception and verification module 907, a partition writing and breakpoint storage module 908, and an upgrade processing module 909. The term "module" in this application refers to a series of computer program segments that can be executed by at least one processor and perform a fixed function, stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0091] The parameter acquisition module 901 is used to receive and parse the upgrade trigger instruction and obtain the upgrade context parameter set.

[0092] The message generation module 902 is used to read the breakpoint offset according to the upgrade context parameter set and generate the target HTTP request message according to the breakpoint offset.

[0093] The network parsing module 903 is used to parse the server network connection information based on the firmware URL in the upgrade context parameter set.

[0094] The thread lock protection module 904 is used to obtain an initialized OpenThread instance and apply a Thread mutex lock to the OpenThread instance to obtain a locked and protected OpenThread instance.

[0095] The channel establishment module 905 is used to establish an OpenThread TCP transmission channel based on the locked OpenThread instance and the server network connection information, and release the Thread mutex lock of the OpenThread instance after the TCP connection is established.

[0096] The secure transmission module 906 is used to perform transmission processing based on the OpenThread TCP transmission channel and the target HTTP request message; if the firmware URL is HTTPS, it completes the TLS handshake based on mbedTLS and encrypts the target HTTP request message before sending it; if the firmware URL is HTTP, it directly sends the target HTTP request message.

[0097] The data receiving and verification module 907 is used to receive TCP data sent by the server through the OpenThread TCP transmission channel. Under the HTTPS link, the TCP ciphertext is decrypted to obtain the HTTP plaintext. Under the HTTP link, the plaintext is directly obtained. The HTTP plaintext is uniformly parsed and the legality of the response is verified. If the verification is invalid, the current TCP transmission link is closed, the firmware data reception is stopped, and the current breakpoint offset is retained. If the verification is valid, the segmented firmware data fragments are output.

[0098] The partition writing and breakpoint storage module 908 is used to write the segmented firmware data fragments to the corresponding DFU partition according to the image format identifier in the upgrade context parameter set, synchronously update the Flash write offset in real time, and persistently store the updated Flash write offset.

[0099] The upgrade processing module 909 is used to perform a download integrity check based on the updated Flash write offset and the total firmware length in the upgrade context parameter set, and to perform firmware activation or pause upgrade processing based on the check result.

[0100] It should be understood that the various variations and specific embodiments of the HTTPS secure firmware upgrade method provided in the above embodiments are also applicable to the HTTPS secure firmware upgrade device of this embodiment. Through the foregoing detailed description of the HTTPS secure firmware upgrade method, those skilled in the art can clearly understand the implementation method of the HTTPS secure firmware upgrade device in this embodiment. For the sake of brevity, it will not be described in detail here.

[0101] See Figure 10 The diagram shown is a schematic representation of the Matter over Thread device according to an embodiment of this application. In a preferred embodiment of this application, the Matter over Thread device 10 includes a memory 101, at least one processor 102, and at least one communication bus 103.

[0102] Those skilled in the art should understand that Figure 10 The structure of the Matter over Thread device shown does not constitute a limitation of the embodiments of this application. It can be a bus structure or a star structure. The Matter over Thread device 3 may also include more or fewer other hardware or software than shown, or different component arrangements.

[0103] In some embodiments, the Matter over Thread device 3 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), digital processors, and embedded devices. The Matter over Thread device 3 may also include user equipment, including, but not limited to, any electronic product capable of human-computer interaction with a user via a keyboard, mouse, remote control, touchpad, or voice control device, such as a personal computer, tablet computer, smartphone, or digital camera.

[0104] In the embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, computer-readable storage media, and Matter over Thread devices can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple components or modules may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between devices, components, or modules, and may be electrical, mechanical, or other forms.

[0105] The components described as separate parts may or may not be physically separate. The components shown as components may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the components can be selected to achieve the purpose of this embodiment according to actual needs.

[0106] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each component can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0107] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drive, portable hard drive, read-only memory (ROM). Various media that can store program code, such as only memory, random access memory (RAM), magnetic disks or optical disks.

[0108] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to 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 and modules involved are not necessarily essential to the present invention.

[0109] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0110] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.< / offset> < / url> < / url>

Claims

1. A method for upgrading HTTPS secure firmware, characterized in that, The method includes: Upon receiving the upgrade trigger command, obtain the upgrade context parameter set; Read the breakpoint offset according to the upgrade context parameter set, and generate the target HTTP request message according to the breakpoint offset; The server network connection information is obtained by parsing the firmware URL in the upgrade context parameter set; Obtain an initialized OpenThread instance and apply a Thread mutex lock to the OpenThread instance to obtain a lock-protected OpenThread instance; An OpenThreadTCP transmission channel is established based on the locked OpenThread instance and the server network connection information. After the TCP connection is established, the Thread mutex lock of the OpenThread instance is released. The transmission process is performed according to the OpenThread TCP transmission channel and the target HTTP request message; if the firmware URL is HTTPS, a TLS handshake is completed based on mbedTLS and the target HTTP request message is encrypted before being sent; if the firmware URL is HTTP, the target HTTP request message is sent directly. The OpenThread TCP transmission channel receives TCP data sent by the server. Under the HTTPS link, the TCP ciphertext is decrypted to obtain the HTTP plaintext. Under the HTTP link, the plaintext is directly obtained. The HTTP plaintext is uniformly parsed and the legality of the response is verified. If the verification is invalid, the current TCP transmission link is closed, firmware data reception is stopped, and the current breakpoint offset is retained. If the verification is valid, segmented firmware data fragments are output. Based on the image format identifier in the upgrade context parameter set, the segmented firmware data fragments are written to the corresponding DFU partition, the Flash write offset is updated synchronously in real time, and the updated Flash write offset is persistently stored. Based on the updated Flash write offset and the total firmware length in the upgrade context parameter set, a download integrity check is performed, and firmware activation or upgrade suspension is performed based on the check result.

2. The HTTPS secure firmware upgrade method according to claim 1, characterized in that, The step of reading the breakpoint offset based on the upgrade context parameter set and generating the target HTTP request message based on the breakpoint offset includes: The image type is distinguished based on the image format identifier in the upgrade context parameter set; the image type includes the original MCUboot image and the Matter OTA packaged image; If it is the original MCUboot image, call the DFU target interface to read the offset of the bytes already written to Flash as the breakpoint offset; if it is the Matter OTA packaged image, read the persistent payload start position, total payload size, and multi-image internal write offset, and calculate the global breakpoint offset in combination with the total firmware length. Determine whether the global breakpoint offset is greater than 0; If the global breakpoint offset is equal to 0, a full-range GET request is generated as the target HTTP request message; if the global breakpoint offset is greater than 0, a fragmented GET request carrying the Content-Range field is generated as the target HTTP request message.

3. The HTTPS secure firmware upgrade method according to claim 1, characterized in that, The step of resolving the server network connection information based on the firmware URL in the upgrade context parameter set includes: The firmware URL is parsed to distinguish whether the corresponding transmission protocol is HTTP or HTTPS, and the domain name, port information, and resource access path are extracted, while the Host header is compatible with IPv6 literal format. Perform DNS resolution operations on the extracted domain names, prioritizing the query of the IPv6 AAAA record corresponding to the domain name; If the AAAA record query fails, then query the domain A record and use the Thread border router to obtain the IPv4 mapping address through NAT64 protocol translation; The server network connection information is generated by integrating the transmission protocol, the parsed server IP address, and the extracted port information.

4. The HTTPS secure firmware upgrade method according to claim 1, characterized in that, The step of establishing an OpenThread TCP transmission channel based on the locked OpenThread instance and the server network connection information includes: Initialize the TCP endpoint and the circular send buffer based on the locked OpenThread instance; Initiate a TCP connection request based on the server IP address and port information in the server network connection information; Listen for TCP connection ready callbacks. After successfully establishing a TCP connection, release the Thread mutex lock corresponding to the OpenThread instance and obtain a usable OpenThread TCP transmission channel.

5. The HTTPS secure firmware upgrade method according to claim 1, characterized in that, If the firmware URL is an HTTPS protocol, after completing the TLS handshake based on mbedTLS and encrypting the target HTTP request message, the following is sent: Initialize the mbedTLS client session, configure the password random number, SNI hostname, and server certificate verification strategy, and adapt the OpenThread TCP send and receive callbacks to the mbedTLS standard BIO read and write interface; Complete the TLS 1.2 handshake process based on the established TCP transport channel; The plaintext of the target HTTP request is sent into mbedTLS for encryption, and the resulting TCP ciphertext data stream is written into the OpenThreadTCP loop send buffer and sent outward.

6. The HTTPS secure firmware upgrade method according to claim 1, characterized in that, The step of writing the segmented firmware data fragments to the corresponding DFU partition according to the image format identifier in the upgrade context parameter set includes: If the image format identifier corresponds to the original MCUboot image, verify whether the first 32 bytes of the firmware image header are valid. After the image header verification is successful, call the DFU target streaming interface to sequentially write the segmented firmware data fragments into the MCUbootsecondary partition. If the image format identifier corresponds to a Matter OTA packaged image, accumulate segmented firmware data fragments and parse the Matter OTA header. After verifying that the payload size recorded in the header matches the total firmware length in the upgrade context parameter set, strip the Matter OTA header and write only the data fragment corresponding to the payload into the DFU multi-image target partition.

7. The HTTPS secure firmware upgrade method according to claim 1, characterized in that, The step of performing a download integrity check based on the updated Flash write offset and the total firmware length in the upgrade context parameter set, and then performing firmware activation or upgrade suspension processing based on the check result, includes: Compare the updated Flash write offset with the total firmware length in the upgrade context parameter set; If the updated Flash write offset is equal to the total length of the firmware, the MCUboot interface is called to mark the new firmware as pending activation. After the device restarts, the MCUboot will complete the firmware installation. If the updated Flash write offset is not equal to the total length of the firmware, the current upgrade task is paused, and the write offset of persistent storage is retained.

8. An HTTPS secure firmware upgrade device, characterized in that, The device includes: The parameter acquisition module is used to receive and parse the upgrade trigger command and obtain the upgrade context parameter set; The message generation module is used to read the breakpoint offset according to the upgrade context parameter set, and generate the target HTTP request message according to the breakpoint offset; The network parsing module is used to parse the server network connection information based on the firmware URL in the upgrade context parameter set; The thread lock protection module is used to obtain an initialized OpenThread instance and apply a Thread mutex lock to the OpenThread instance to obtain a locked OpenThread instance; The channel establishment module is used to establish an OpenThread TCP transmission channel based on the locked OpenThread instance and the server network connection information, and release the Thread mutex lock of the OpenThread instance after the TCP connection is established. The secure transmission module is used to perform transmission processing based on the OpenThread TCP transmission channel and the target HTTP request message; if the firmware URL is HTTPS, it completes the TLS handshake based on mbedTLS and encrypts the target HTTP request message before sending it; if the firmware URL is HTTP, it directly sends the target HTTP request message. The data receiving and verification module is used to receive TCP data sent by the server through the OpenThread TCP transmission channel. Under the HTTPS link, the TCP ciphertext is decrypted to obtain the HTTP plaintext. Under the HTTP link, the plaintext is directly obtained. The HTTP plaintext is uniformly parsed and the legality of the response is verified. If the verification is invalid, the current TCP transmission link is closed, firmware data reception is stopped, and the current breakpoint offset is retained. If the verification is valid, segmented firmware data fragments are output. The partition writing and breakpoint storage module is used to write the segmented firmware data fragments to the corresponding DFU partition according to the image format identifier in the upgrade context parameter set, synchronously update the Flash write offset in real time, and persistently store the updated Flash write offset. The upgrade processing module is used to perform download integrity verification based on the updated Flash write offset and the total firmware length in the upgrade context parameter set, and to perform firmware activation or upgrade suspension processing based on the verification result.

9. A Matter over Thread device, characterized in that, The method includes a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the HTTPS secure firmware upgrade method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the HTTPS secure firmware upgrade method according to any one of claims 1 to 7.

Images