Package-based remote firmware updates

Abstract

A method for updating firmware includes receiving, at a device, an updated installation package. The updated installation package includes an updated version of an installation package belonging to a set of installation packages stored on the device for installing firmware on the device. The method further includes updating the set of installation packages by replacing the installation package with the updated installation package. The method further includes installing updated firmware in volatile memory of the device based on the updated set of installation packages. The method further includes storing an image of the updated firmware in non-volatile storage of the device. The method further includes loading the image from the device's non-volatile memory to the device's volatile memory during a boot process to execute the updated firmware from the volatile memory and verifying authenticity of the updated firmware.

Description

[Technical Field]

[0001] Technical Field Various implementations described herein relate to firmware updates, and more particularly to package-based firmware updates in which firmware installation is split into multiple combinable installation packages, and further, the authenticity of the firmware is optionally verifiable. [Background technology]

[0002] background Firmware is a type of software that provides low-level control of a hardware device. Typically, to interact with a hardware device, a software application communicates with the firmware, which then interacts with the hardware device as needed to allow the software application to utilize the hardware device. A device's firmware may need to be updated for a variety of reasons, such as to install new features or fix bugs. Updating a device's firmware can be performed in a variety of ways. For example, updated firmware can be received over a cable, such as a Universal Serial Bus (USB) cable or an Ethernet cable. As another example, for remote firmware updates, firmware can be received wirelessly, such as via Wireless Fidelity (WiFi). Summary of the Invention

[0003] In one embodiment, a method for updating firmware includes receiving an updated installation package at a device. The updated installation package includes an updated version of an installation package belonging to a set of installation packages stored on the device for installing firmware on the device. The method further includes updating the set of installation packages stored on the device by replacing an installation package with the updated installation package. The method further includes installing updated firmware in volatile memory of the device based on the updated set of installation packages including the updated installation package. The method further includes storing an image of the updated firmware in non-volatile storage of the device. The method further includes loading the image of the updated firmware from the non-volatile memory of the device to volatile memory of the device during a boot process, enabling execution of the updated firmware from the volatile memory, and attempting to verify authenticity of the updated firmware.

[0004] In another embodiment, a system includes a server including a processor and a memory. The processor is configured to execute computer-readable instructions, and the memory is configured to store computer-readable instructions that, when executed by the processor, cause the processor to perform operations. The operations include identifying an updated installation package and inserting the updated installation package into a set of installation packages to replace an existing version of the updated installation package. The operations further include installing the set of installation packages including the updated installation package to generate reference firmware. The operations further include generating a signed validation hash based on the reference firmware and remotely providing the updated installation package and the signed validation hash to one or more nodes from the server. The one or more nodes use the updated installation package to update the one or more nodes.

[0005] In yet another embodiment, a method for updating a file system includes receiving an updated installation package at a device. The updated installation package includes an updated version of an installation package, the installation package belonging to a set of installation packages stored on the device for installation of the file system on the device. The method further includes receiving a signed validation hash associated with the file system. The method further includes updating the set of installation packages stored on the device by replacing an installation package with the updated installation package. The method further includes installing the updated file system in volatile memory of the device based on the updated set of installation packages including the updated installation package, and validating the updated file system by comparing a hash of the updated file system with the signed validation hash. The method further includes storing an image of the updated file system in non-volatile storage of the device. The method further includes loading an image of the updated file system from the non-volatile memory of the device onto volatile memory of the device during boot of the device, enabling execution of the updated file system from the volatile memory, and attempting to re-validate the updated file system by comparing the updated hash of the updated file system with the signed validation hash.

[0006] These exemplary aspects and features are mentioned not to limit or define the presently described subject matter, but to provide examples to aid in understanding the concepts described herein. Other aspects, advantages, and features of the presently described subject matter will become apparent after reviewing the entire application. [Brief explanation of the drawings]

[0007] These and other features, aspects, and advantages of the present disclosure will be better understood from the following detailed description when read in conjunction with the accompanying drawings.

[0008] [Figure 1] FIG. 1 is a diagram of an update system for updating firmware installed on one or more nodes, according to some implementations described herein. [Figure 2] FIG. 2 illustrates a method for generating a firmware update package for one or more nodes according to some implementations described herein. [Figure 3] FIG. 3 is a diagram illustrating the communication flow of a provider server when generating a firmware update package according to some implementations described herein. [Figure 4] FIG. 4 illustrates a method for updating firmware at a node according to some embodiments described herein. [Figure 5] FIG. 5 depicts the communication flow of a node when installing firmware based on an updated installation package in a firmware update package, according to some implementations described herein. [Figure 6] FIG. 6 illustrates a diagram of a node, specifically a utility meter, according to some implementations described herein. DETAILED DESCRIPTION OF THE INVENTION

[0009] Detailed explanation Because firmware typically has low-level access to hardware, firmware is an easy target for attackers seeking to exploit a device. A file system, which can be implemented as firmware, controls how data is stored in and retrieved from a storage device. If the file system is authentic and uncorrupted, it can prevent tampering with the entire device. To protect against malicious attacks, file systems are often signed for verification. Typically, a file system image (i.e., an image of the file system) is generated and signed remotely, and the entire signed file system image is wirelessly downloaded to the device for firmware updates. Based on the signature, the device can verify that the file system is authentic and free of defects, and therefore can use the file system as is.

[0010] However, signed images of file systems can be large amounts of data, and therefore, transmitting a signed file system image from a remote server to a device requiring an update can be expensive in terms of time and network utilization. If the network over which the file system image or other firmware is transmitted is lossy or slow, the transmission can be slow or prone to errors. Furthermore, on bandwidth-limited networks, the transmission can utilize too much bandwidth, causing other transmissions on the network to slow down or fail. Thus, it is desirable to reduce the amount of data required to update a file system or other firmware, provide such updates more efficiently, and reduce the bandwidth utilized by such updates.

[0011] One option for addressing this issue is to split the installation files for the file system into a collection of installation packages. Then, when an update is needed, the remote server sends to the device only the installation packages that require updates to enable installation of the updated version of the file system or other firmware. The device can then add these installation packages to the installation packages already stored on the device and use the resulting combination of installation packages to install the updated version of the file system or other firmware. However, this approach has the disadvantage that a signed version of the updated file system image is not provided with each update, thereby eliminating the ability to verify the authenticity of the file system as a whole.

[0012] Another option is to sign each installation package so that it can be verified, resulting in a presumed valid (i.e., authentic and therefore defect-free) file system. However, this technique has a significant drawback for devices that run file systems from volatile memory. For example, the file system may be random access memory (RAM) based. Memory-based file systems (e.g., RAM-based) may be used for a variety of reasons. In some cases, for example, memory-based file systems may be several times faster in terms of read and write performance than file systems based on non-volatile memory. Because volatile memory does not retain data upon power loss, for such devices, rebooting the device results in the file system being erased. This requires re-verification of the installation packages and reinstallation of the file system after each reboot. Installation typically requires unpacking the installation files and copying the data to a predetermined location in volatile memory, which are performed in addition to verifying each installation package before or during the installation itself.

[0013] In some cases, verifying the installation package and reinstalling the file system can take a significant period of time (e.g., several minutes), during which the device is unavailable. For example, consider a device that is a utility meter configured to meter resources for billing purposes. If the utility meter needs to be restarted after service provision or for other reasons, the file system must be reinstalled during the boot process, during which time resource metering is unavailable for several minutes, and the service provider may not be able to accurately bill for usage during that time. As another example, during the boot process, the utility meter's communications relay device may be unable to send or receive data for a span of several minutes, resulting in loss of transmitted data. Therefore, it would be desirable to reduce the boot time of a device (e.g., a utility meter) by avoiding installing a file system during the boot process.

[0014] According to some implementations described in this disclosure, a provider server responsible for updating firmware in one or more nodes maintains a set of installation packages corresponding to a current version of the firmware, such as a file system in the node. To provide a firmware update, the provider server identifies an updated installation package. The updated installation package is an updated version of an older (e.g., obsolete or superseded) installation package currently included in the set of installation packages, also referred to herein as a current installation package. The provider server updates the set of installation packages by replacing the older installation package with the updated installation package, so that the updated set of installation packages corresponds to the updated version of the firmware. The provider server generates a reference firmware. The reference firmware may be an image of the updated version of the firmware. The provider server generates a signed validation hash based on the reference firmware and sends the updated installation package and the signed validation hash to each node to be updated. The node receives the updated installation package and the signed validation hash. In the node's copy of its local set of installation packages, the node replaces the old installation package with the updated installation package and installs the updated version of the firmware based on the updated set of installation packages. The node verifies (i.e., verifies the authenticity of) the firmware by hashing the updated version and comparing the resulting hash with the signed validation hash. The node saves an image of the updated firmware to non-volatile storage, ensuring that the image survives power downs, such as when the node boots or reboots.Furthermore, upon boot (e.g., reboot), rather than reinstalling the updated firmware, the device copies an image of the firmware to the volatile memory where the firmware was installed. Again, the node validates the updated firmware by hashing it and comparing the result with the signed validation hash.

[0015] The implementations described herein have advantages over existing techniques for updating firmware, particularly when updating file systems configured to run from volatile memory. For example, the implementations described herein enable updating firmware as a result of transmitting an updated installation package rather than transmitting an entire file system image. Therefore, remote firmware updates require reduced bandwidth because the updated installation package is likely to be much smaller than the file system image. Furthermore, the implementations described herein enable validating firmware based on a reference image known to be authentic and defect-free, such as a remotely stored reference firmware. As a result, even when firmware runs from volatile memory, firmware does not need to be reinstalled when a node boots because a signed validation hash or other form of validation data is provided based on the reference firmware. Thus, a device can create firmware only once, and when a node boots, it needs to be re-verified but not reinstalled, and firmware verification is typically much faster than reinstallation. Thus, some implementations enable efficient installations that reduce network utilization while keeping boot times relatively low.

[0016] FIG. 1 is a diagram of an update system 100 for updating firmware installed on one or more nodes 105, according to some implementations described herein. As shown in FIG. 1, the update system 100 is integrated with a provider server 110 and further integrated with one or more nodes 105 that are remote from the provider server 110. In some implementations, the provider server 110 communicates with the nodes 105 directly or indirectly, such as via wireless communication such as Wireless Fidelity (WiFi) or Bluetooth, via a wired connection, or via a combination of networks that may include a wired network, a wireless network, or both. For example, the wireless communication may be wireless over a wireless mesh network, in which case one or both of the provider server 110 and the nodes 105 include respective radios. In one implementation, to update firmware on the nodes 105, the provider server 110 provides a firmware update package 120 to a firmware update server 130, which includes a radio connected to the wireless mesh network of which the nodes 105 are a part. Thus, the nodes 105 download the firmware update package 120 from the firmware update server 130 over the wireless mesh network, for example, using wireless communication. However, in another implementation, the nodes 105 download the firmware update package 120 from the firmware update server 130 using some other communication technology, such as WiFi, Bluetooth, or a wired connection. It will be appreciated that the firmware update server 130 may be connected to the nodes 105 and therefore may communicate with the nodes 105 over one or more of a variety of networks, which may be wired, wireless, or a combination of both.

[0017] Each of the provider server 110, the nodes 105, and the firmware update server 130 may be implemented as hardware, software, or a combination of hardware and software. In one implementation, for example, each node 105 is a computing device such as a utility meter, and the provider server 110 is implemented as one or more computing devices remote from the nodes 105 or is a server application running on a computing device remote from the nodes 105. Similarly, the firmware update server 130 may be one or more computing devices or a server application running on one or more computing devices. In some implementations, the provider server 110 and the firmware update server 130 run on a common computing device or set of computing devices and thus need not be separate devices. However, alternatively, the provider server 110 and the firmware update server 130 may be implemented as separate components. For example, the firmware update server 130 may provide a cloud service that receives firmware update packages 120 from one or more provider servers 110 and transmits the firmware update packages 120 to one or more nodes 105.

[0018] In some implementations, provider server 110 may be configured to generate or otherwise provide firmware update packages 120 corresponding to various versions and types of firmware. Accordingly, it will be understood that the techniques described herein for providing firmware update packages 120 can be performed by provider server 110 for various different firmware 140. However, in one implementation, provider server 110 provides firmware update packages 120 for a particular type of node 105 (e.g., utility meter), for a particular type of firmware 140 (e.g., a file system for use by a particular utility meter), or for firmware 140 from a particular manufacturer. For example, provider server 110 may be owned or managed by a manufacturer or service provider, and thus, firmware update packages 120 generated by provider server 110 may be configured to provide firmware updates from that manufacturer or service provider. Furthermore, in some implementations, firmware update server 130 maintains firmware update packages 120 received from various provider servers 110, and thus, for example, from various manufacturers or service providers. Thus, a provider server 110 may generate a firmware update package 120 for a particular firmware 140, while a firmware update server 130 may distribute such firmware update packages 120 received from various provider servers 110.

[0019] 1 shows only a single node 105. However, it will be understood that a single node 105 is provided for illustrative purposes only, and that multiple nodes 105 may be configured to update their respective firmware 140 through the update system 100. For example, multiple nodes 105 may each be configured to download firmware update packages 120 from a firmware update server 130 or directly from a provider server 110. Furthermore, it will be understood that operations described herein as being performed by a node 105 may be performed by each such node 105, according to some implementations.

[0020] 1 , some implementations of provider server 110 maintain various data related to the current version of firmware 140 installed on node 105 or desired to be installed on node 105. For example, provider server 110 may maintain one or more of package set 150, which is a set of installation packages 155 that can be used together to install firmware 140, reference firmware 145, which is an image of firmware 140, and verification data 160. Specifically, one example of provider server 110 maintains package set 150, reference firmware 145, and verification data 160. Generally, in some implementations, installation packages 155 can be combined to install firmware 140, reference firmware 145 is an image of firmware 140, and verification data 160 can be used to verify the authenticity of firmware 140 or an image of firmware 140, such as reference firmware 145.

[0021] In some implementations, package set 150 includes two or more installation packages 155 that can be combined to install firmware 140. For example, package sets 150 may be combinable to form a single, unified installation package that is executable (e.g., extensible) to install firmware 140. In some implementations, provider server 110 initially gained access to package set 150 by generating package set 150 (e.g., by generating one or more of the individual installation packages 155). However, additionally or alternatively, provider server 110 received package set 150 from a trusted source, such as an administrator. Still additionally or alternatively, provider server 110 received a unified installation package and divided the unified installation package into package sets 150. Techniques for dividing unified installation packages into package sets 150 exist in the art, and one or more of such techniques may be used in some implementations of update system 100.

[0022] In some implementations, reference firmware 145 is an image of firmware 140 maintained as a reference by provider server 110. For example, provider server 110 may use package set 150 to install firmware 140 on provider server 110, thereby generating reference firmware 145. In this manner, reference firmware 145 is presumed to be an authentic version of firmware 140.

[0023] Verification data 160 may be data usable to validate firmware 140, potentially including a firmware image, or to validate package set 150, or both. In some implementations, verification data 160 includes signed hashes, such as a set of hashes where the entire set is signed, or a set of hashes where each hash is individually signed. Each such hash may be the result of a hash of an authentic version of reference firmware 145 or an installation package 155. For example, verification data 160 may include signed validation hashes 165, which may be a signed hash of reference firmware 145, and respective signed package hashes corresponding to each installation package 155, where each such signed package hash is a signed hash of the corresponding installation package 155.

[0024] In some implementations, the provider server 110 utilizes the reference firmware 145 to generate the validation data 160. For example, to generate the signed package hash, the provider server 110 may apply a hash function to the corresponding installation package 155 and then sign the resulting hash. Further, for example, to generate the signed validation hash, the provider server 110 may hash the reference firmware 145, such as by applying a hash function to the reference firmware 145, and sign the resulting hash to generate the signed validation hash.

[0025] Node 105 may maintain its own local copy of various data related to firmware 140, specifically related to the version of firmware 140 installed on node 105. For example, node 105 may maintain one or more (e.g., each) of package set 150 corresponding to firmware 140, firmware image 170, which is a copy of firmware 140 installed on node 105, and validation data 160 usable to validate firmware 140 or package set 150, or both. For example, node 105 may maintain each of package set 150, firmware image 170, and validation data 160 in its non-volatile storage 180 such that these elements are retained in non-volatile storage 180 when node 105 loses power. Non-volatile storage 180, also referred to herein as non-volatile memory, may be a hard disk drive, solid-state drive, NAND flash memory, read-only memory (ROM), or other storage device that retains saved data when power is lost. Generally, package set 150 stored on node 105 corresponds to the version of firmware 140 that node 105 is currently using, such that package set 150 was or could have been used to install that version of firmware 140. As an example, when a manufacturer or service provider installed an initial version of firmware 140 on node 105, the manufacturer or service provider may have stored one or more of package set 150, firmware image 170, and validation data 160 on node 105, specifically in non-volatile storage 180 of node 105. As described herein, whenever firmware 140 is updated, node 105 may update this stored data, such as package set 150, firmware image 170, and validation data 160, to correspond to the updated firmware 140.

[0026] In some implementations, node 105 installs firmware 140 into volatile memory 190 of node 105. Volatile memory 190 can be, for example, random access memory (RAM), such that firmware 140 is RAM-based. In that case, execution of package set 150 causes firmware 140 to be deployed to volatile memory 190, such that one or more of a directory, environment variables, and executable files for firmware 140 are maintained in and accessed from volatile memory 190. In some implementations, firmware 140 is a read-only file system, such as SquashFS, but alternatively, firmware 140 need not be a read-only file system, or even a file system at all. When node 105 is rebooted or otherwise loses power, firmware 140 may be erased from volatile memory 190 due to the inability of volatile memory 190 to retain data when power is lost. However, additionally or alternatively, firmware 140 may be installed in non-volatile storage 180.

[0027] As shown in FIG. 1 , provider server 110 identifies updated installation packages 155 that provide updates to firmware 140. For example, in one embodiment, a unified installation package is executable to install an updated version of firmware 140. The unified installation package is divided into updated package sets 150, which are the same as package set 150 (i.e., before the update) except that one or more individual installation packages 155, including updated installation package 155, have been modified. In the example shown in FIG. 1 , the updated installation package is an updated version of an older installation package 155 currently included in package set 150. Thus, by replacing the older installation package 155 with the updated installation package 155, package set 150 is updated and is now executable to install an updated version of firmware 140.

[0028] In this manner, the provider server 110 can install the updated package set 150 to generate an updated reference firmware 145, which is an updated image of the firmware 140. Given the updated reference firmware 145, the provider server 110 may generate an updated version of the verification data 160, such as a signed validation hash 165. The provider server 110 may send the firmware update package 120 to the firmware update server 130 for distribution to one or more nodes 105, the firmware update package 120 including the updated installation package 155 and the verification data 160. In some implementations, the verification data 160 included in the firmware update package 120 includes the signed validation hash 165 for verifying the firmware 140 and a signed package hash corresponding to the provided updated installation package 155. If multiple installation packages 155 are updated and therefore provided with the firmware update package 120, the verification data 160 may include a respective signed package hash for each such updated installation package 155.

[0029] In some implementations, the node 105 downloads the firmware update package 120, which may include the updated installation package 155 and validation data 160, as described above. The node 105 may download the firmware update package 120 from the firmware update server 130 or directly from the provider server 110, such as in implementations where an explicit firmware update server 130 is not used. The node 105 may validate the updated installation package 155 by using the validation data 160. Furthermore, the node 105 may execute the updated package set 150 to install an updated version of the firmware 140, for example, by installing the updated version of the firmware 140 in the volatile memory 190 of the node 105. The node 105 may use the validation data 160 to validate the firmware 140, and in particular, in some implementations, may perform this validation before executing the firmware 140. To update its locally stored package set 150, node 105 may replace an older installation package 155 with an updated installation package 155 in its package set 150 stored locally in non-volatile storage 180. Additionally, in the case of multiple updated installation packages 155, for each updated installation package 155 in firmware update package 120, the node may replace the respective older installation package 155 in package set 150 with the updated installation package 155.

[0030] In some implementations, firmware 140 is installed in volatile memory 190. In that case, node 105 maintains firmware image 170 in non-volatile storage 180, but in some implementations, firmware image 170 is not executable; for example, a reference in firmware image 170 may not necessarily point to the resource that the reference is expected to point to because the reference is not at the installed location in volatile memory 190. When the node reboots, firmware 140 is erased from volatile memory 190. Thus, after rebooting, node 105 may copy firmware image 170 to volatile memory 190, specifically, for example, to the storage location in volatile memory 190 where firmware 140 was installed. Therefore, firmware 140 may again be executable from its installed location. However, node 105 may validate firmware 140 using validation data 160 before executing firmware 140 after a reboot or other power loss.

[0031] While this disclosure repeatedly refers to operations performed by node 105 in the example of a reboot, it will be understood that such operations may additionally or alternatively be performed in the case of a boot that is not a reboot. In other words, when node 105 is powered on after being powered off, such operations described herein may be performed, including, for example, copying firmware image 170 from non-volatile storage 180 to volatile memory 190 and verifying firmware 140.

[0032] FIG. 2 illustrates a method 200 for generating a firmware update package 120 according to some implementations described herein. Specifically, the firmware update package 120 may include an updated installation package 155 and validation data 160. It will be understood that the firmware update package 120 may include multiple updated installation packages 155, each of which may be incorporated into the firmware update package 120 as described herein. In some implementations, this method 200 or a similar method is performed by the provider server 110 to provide the firmware update package 120 to one or more nodes 105 to enable the nodes 105 to update their respective versions of firmware 140. It will be understood that the order of operations shown in FIG. 2 and described herein is for illustrative purposes only, and further, that the blocks of FIG. 2 may be reordered, one or more blocks may be deleted, and additional blocks may be added.

[0033] As shown in FIG. 2 , in block 205, the provider server 110 identifies an updated installation package 155 for updating the firmware 140. In one example, the provider server 110 generates the updated installation package 155 by dividing the integrated installation package for the updated version of the firmware 140 into a package set 150 (i.e., a set of installation packages 155) such that the updated installation package 155 is a member of the set. In this case, the integrated installation package 155 may be generated by the provider server 110 or provided to the provider server 110, such as via upload by an administrator. In another example, the provider server 110 may simply receive the updated installation package 155, such as via upload by an administrator. It will be appreciated that various techniques are available for providing the updated installation package 155 to the provider server 110.

[0034] In block 210, the provider server 110 updates the package set 150 stored on the provider server 110 by replacing the old installation package 155, of which the updated installation package is an updated version, with the updated installation package 155 in the package set 150. In this manner, the package set 150 has been updated to enable installation of the updated version of the firmware 140. In some implementations, whether there is one or more updated installation packages 155, the updated installation packages 155 may constitute a subset (e.g., a proper subset) of the package set 150, such that not every installation package 155 needs to be updated for the firmware update to occur.

[0035] In block 215, provider server 110 installs package set 150, such as by executing installation package 155 to unpackage package set 150 into an updated version of firmware 140. The result of the installation is reference firmware 145, which may be an image of updated firmware 140.

[0036] In block 220, the provider server 110 generates validation data 160 based on at least the reference firmware 145. In some implementations, the validation data 160 includes a collection of hashes signed by the provider server 110. For example, the set of hashes may be concatenated or otherwise combined, and the combined result may be signed, or each hash may be signed individually. Specifically, the validation data 160 may include a hash of the reference firmware 145 that has been signed to form the signed validation hash 165. In this case, to generate the signed validation hash 165, the provider server 110 may input the reference firmware 145 into a hash function and sign the output of the hash function. In one implementation, for example, the signature is performed using the Elliptic Curve Digital Signature Algorithm (ECDSA) with a digital signature issued by a Landys+Gyr Signed Authority (LGSA), although it will be understood that other signature techniques or authorities may be used.

[0037] Additionally, verification data 160 may include a signed package hash corresponding to the updated installation package 155, or may include a respective signed package hash corresponding to each installation package 155 in the updated package set 150. In some implementations, signed package hashes for non-updated installation packages 155 are previously generated and stored on or otherwise accessible by provider server 110. To generate a signed package hash for an installation package, such as an updated installation package 155, provider server 110 may hash the installation package 155 and sign the resulting hash, thereby forming the signed package hash corresponding to the installation package 155. Thus, verification data 160 may be used to verify the authenticity of firmware 140 and each installation package 155 in the updated package set 150.

[0038] In block 225, the provider server 110 transmits the firmware update package 120 to the firmware update server 130. However, additionally or alternatively, the provider server 110 may transmit the firmware update package 120 to one or more nodes 105 without using the firmware update server 130 as an intermediary. In either case, such transmission may, but need not, include one or more unicast transmissions. In some implementations, for example, the provider server 110 may specifically direct the firmware update package 120 to the firmware update server 130 or one or more nodes 105, or additionally or alternatively, the provider server 110 may broadcast or multicast the firmware update package 120, thereby allowing the firmware update server 130 or one or more nodes 105 to download the firmware update package 120.

[0039] The firmware update package 120 sent by the provider server 110 may include an updated installation package 155 and verification data 160. In some implementations, the verification data 160 in the firmware update package 120 includes a signed validation hash 165, which may include a signed package hash corresponding to the updated installation package 155; however, the verification data 160 need not include data necessary to verify installation packages 155 other than the updated installation package 155 being provided. For example, if the installation package 155 is not being modified, each node 105 may already have verification data 160 (e.g., a signed package hash) corresponding to the existing installation package 155. Thus, the verification data 160 of the firmware update package 120 may include information for verifying only the items being updated, such as the updated installation package 155 or the firmware 140 itself.

[0040] 3 illustrates the communication flow of the provider server 110 when generating a firmware update package 120 according to some implementations described herein. The following description follows this communication flow from left to right. While the example of FIG. 3 shows two installation packages 155a, 155b being updated and that the firmware 140 being updated is a file system, it will be understood that these details are provided for illustrative purposes only. It will be understood that the firmware 140 need not be a file system, and that one or more installation packages 155 may be updated in a firmware update package 120 configured to update the firmware 140.

[0041] Provider server 110 may maintain a server record 305 that includes current package set 150a and reference file system 310, which may be an image of the file system that corresponds to current package set 150a. Thus, in this example, before incorporating the update, server record 305 includes the current version of current package set 150a and reference file system 310, which is in the process of being updated, as shown in FIG.

[0042] When the updated installation packages 155c and 155d are introduced, the provider server 110 inserts the updated installation packages 155c and 155d into the current package set 150a, replacing the current installation packages 155a and 155b, which are the current versions of the updated installation packages 155c and 155d, respectively. This results in the updated package set 150b. As also shown in FIG. 3, in some implementations, the provider server 110 installs the updated package set 150b as an update and generates a reference file system 310, which may be an image of a file system. Based on the reference file system 310, the provider server 110 may generate a signed validation hash 165, or other information for validating a file system, for inclusion in the verification data 160. The provider server 110 may also generate a signed package hash (not shown) for inclusion in the verification data 160 to enable verification of the updated installation packages 155c and 155d. The provider server 110 may send the firmware update package 120, including the updated installation packages 155c, 155d and the signed validation hash 165, to the firmware update server 130.

[0043] 3, provider server 110 may update its server record 305 based on updated installation packages 155c, 155d and updated validation data 160. That is, updated installation packages 155c, 155d may be retained in server record 305, specifically updated package set 150b, instead of previous installation packages 155a, 155b. Furthermore, validation data 160 in server record 305 may be updated by including signed validation hash 165 and including the respective signed package hashes for each updated installation package 155c, 155d instead of the signed package hashes for each current installation package 155a, 155b.

[0044] 4 illustrates a method 400 for updating firmware 140 on a node 105 according to some implementations described herein. In some implementations, this method 400, or the like, is performed by a node 105 to update firmware 140 running on the node 105. It will be understood that the order of operations shown in FIG. 4 and described herein is for illustrative purposes only, and further, that the blocks in FIG. 4 may be reordered, one or more blocks may be removed, and additional blocks may be added.

[0045] 4, at block 405, the node 105 receives the firmware update package 120. For example, the node 105 may receive the firmware update package 120 by downloading the firmware update package 120 directly from the provider server 110, or the node 105 may receive the firmware update package 120 indirectly from the provider server 110 by downloading the firmware update package 120 from the firmware update server 130. The firmware update package 120 may include an updated installation package 155 (e.g., potentially multiple updated installation packages 155) and verification data 160. The updated installation package 155 may be an updated version of an older installation package 155 included in the package set 150 currently maintained on the node 105. The verification data 160 may include, for example, a signed validation hash 165 to enable verification of the firmware 140 and a signed package hash for verification of the updated installation package 155.

[0046] In one example, the firmware 140 being updated is a file system containing code and applications. The image of the file system itself can be quite large, and therefore, embodiments described herein can reduce network traffic by avoiding the transmission of the entire file system image. Rather, embodiments of a node 105 need only download verification data 160 and one or more updated installation packages 155, which are only part of the data required for installation, to update its firmware 140 as described herein.

[0047] At block 410 of method 400, node 105 updates package set 150 stored on node 105 by replacing old installation packages 155 with updated installation packages 155. In some implementations, old installation packages 155 may be discarded (e.g., deleted). However, alternatively, old installation packages 155 may be saved if node 105 needs to restore its firmware 140 to a previous version or for another reason. In some implementations, whether there is one or multiple updated installation packages 155, the updated installation packages 155 may constitute a subset (e.g., a proper subset) of package set 150, such that not all installation packages 155 need to be updated based on firmware update package 120.

[0048] At block 415, the node 105 installs the firmware 140 based on the updated package set 150. For example, the node 105 executes (e.g., unpacks or decompresses) the package set 150 to generate executable firmware 140. The node 105 may install the firmware 140 into the volatile memory 190 of the node 105, such that the firmware 140 executes from the volatile memory 190.

[0049] In block 420, the node 105 validates the firmware 140 through the use of the validation data 160. For example, the node hashes the firmware 140 installed on the node 105 and compares the resulting hash to the signed validation hash 165 in the validation data 160. If the hash of the as-installed firmware 140 matches the signed validation hash 165, which is presumed to be valid because it is signed, the node 105 considers the firmware to be valid.

[0050] In some implementations, node 105 utilizes device mapper verity (dm-verity) or other verification tools to verify firmware 140. The verification tool provides transparent verification as part of the boot process to ensure node 105 boots with verified firmware 140. This transparent verification may include hashing firmware 140 and comparing the resulting hash to a signed validation hash 165 in verification data 160. If dm-verity or a similar verification tool is used, node 105 may reboot in response to installing firmware 140, and verification of firmware 140 may occur as part of the boot-up process. However, it will be understood that various verification techniques may be used and that a reboot need not be a requirement for verification to occur.

[0051] At block 425, node 105 updates its local record of firmware 140. More specifically, node 105 may store verification data 160 (e.g., signed package hashes for updated installation packages 155 as well as signed validation hashes) in non-volatile storage 180 of node 105, and node 105 may also store firmware image 170 of newly updated firmware 140 in non-volatile storage 180. Thus, when node 105 reboots or otherwise loses power, the latest versions of verification data 160, including the set of installation packages, information for verifying firmware 140 and optionally package set 150, and firmware image 170 are retained.

[0052] In some implementations, if verification of firmware 140 is performed during the boot process, firmware image 170 may be stored in non-volatile storage 180 before rebooting node 105. In other words, block 425 of method 400 may occur before block 420. In that case, firmware image 170 may be copied back to volatile memory 190 as part of the boot process to enable verification of firmware 140.

[0053] At some point after updating firmware 140 as described above, node 105 may lose power. For example, node 105 may be rebooted for troubleshooting purposes or to enable servicing of node 105. Such reboot of node 105 occurs at block 430 of method 400. At block 435, in response to the reboot, node 105 loads firmware image 170 from non-volatile storage 180 to volatile memory 190 so that firmware 140 can be executed from volatile memory 190. In other words, node 105 may copy firmware image 170 from non-volatile storage 180 to an install location for firmware 140 in volatile memory 190. As described above, if firmware 140 is executed from volatile memory 190, as in this example, firmware 140 was erased when node 105 lost power, and copying firmware image 170 back to volatile memory 190 allows firmware 140 to execute from its installed location. At block 440, and in response to the reboot, node 105 attempts to revalidate firmware 140. For example, as described above, node 105 may hash firmware 140 and compare the resulting hash with validation data 160, specifically, signed validation hash 165 therein.

[0054] It will be understood that blocks 435 and 440 can be executed in the order described above, block 440 can be executed before block 435, or blocks 435 and 440 can be executed in parallel. For example, when block 435 is executed before block 440, such that firmware 140 was copied to volatile memory 190 before verification, node 105 can attempt to verify firmware 140 based on firmware 140 installed in volatile memory 190. For example, node 105 can utilize dm-verity or a similar tool to load firmware 140 and securely boot node 105 based on verification of firmware 140 with verification data 160 during the boot process. However, if block 440 is executed before block 435, such that firmware 140 was not copied to volatile memory 190 before verification, node 105 can attempt to verify firmware 140 based on firmware image 170 stored in non-volatile storage 180. For example, firmware image 170 may be hashed and the resulting hash compared to the validation data, specifically, for example, signed validation hash 165 within the validation data.

[0055] In some implementations, the node 105 stores the package set 150 corresponding to the current version of firmware 140, but the node 105 does not utilize the installation package 155 during a reboot process, more specifically, to reload and verify the firmware 140. Rather, installation of each version of firmware 140 based on the package set 150 only needs to occur once. After a power loss (e.g., during a reboot), the firmware 140 does not need to be reinstalled from the package set 150 because the firmware image 170 was saved in non-volatile storage 180, thereby allowing the node 105 to copy the firmware image 170 back to the volatile memory 190 where the firmware 140 operates. Typically, copying the firmware image 170 and verifying the firmware 140 takes less time than it takes to install the firmware 140 from the package set 150. Thus, the implementations described herein reduce the boot-up time of the node 105.

[0056] 4, in decision block 445 of method 400, node 105 determines whether validation of firmware 140 was successful. If validation was successful (i.e., the firmware was verified as authentic), in block 450, node 105 continues its boot process and firmware 140 executes from volatile memory 190.

[0057] However, if validation fails, method 400 proceeds to block 455. In that case, firmware 140 is determined to be unauthenticated, which may indicate potential corruption or malware, and therefore, in some implementations, node 105 does not execute firmware 140. Although the boot process may be incomplete and firmware 140 may not be executing, in some implementations, node 105 may still have access to a set of services deemed critical or secure. For example, node 105 may be able to reinstall firmware 140 from package set 150 or contact firmware update server 130 using at least one communication device (e.g., radio). Thus, in block 455, node 105 reinstalls firmware 140 based on package set 150 stored in non-volatile storage 180. In decision block 460, node 105 then determines whether the as-freshly installed firmware 140 is valid. If node 105 is able to verify firmware 140, method 400 proceeds to block 450, where node 105 completes the boot process and executes firmware 140. However, if the verification fails again, then at block 465 the node 105 performs further troubleshooting activities.

[0058] For example, the node may validate the various installation packages 155 in the package set 150 to attempt to determine whether the problem lies with the installation package 155. If the validation is successful (i.e., all installation packages are deemed authentic), the node 105 may send an error notification. In that case, the installation packages 155 appear authentic, but the firmware 140 is invalid in some way, and the node 105 may not be able to fix the firmware 140 issue with a new installation that has already been attempted. However, if validation of an installation package 155 fails, the node 105 may request one or more replacement installation packages 155 based on the determination that the problem lies with the installation package 155. For example, the node 105 may request a replacement for each installation package 155 for which validation failed from the firmware update server 130 or the provider server 110, and the firmware update server 130 or the provider server 110 may send such a replacement in response to the request. If validation of an installation package 155 fails even after a replacement from the firmware update server 130, the node may send a notification of the error.

[0059] FIG. 5 illustrates the communication flow of a node 105 when installing firmware 140 based on an updated installation package 155 according to some implementations described herein. The following description follows this communication flow from left to right. While the example of FIG. 5 shows two installation packages 155c and 155d being updated and the updated firmware 140 being a file system 510, it will be understood that these details are provided for illustrative purposes only. It will be understood that the firmware 140 need not be a file system 510, and that one or more installation packages 155 may be updated in a firmware update package 120 configured to update the firmware 140.

[0060] 5, in some implementations, the node 105 maintains in its non-volatile storage 180 a node record 505 that includes a current package set 150a that corresponds to the current version of the file system 510 running from the node 105's volatile memory 190. In this example, the node 105 downloads from the firmware update server 130 a firmware update package 120 that includes updated installation packages 155c, 155d and verification data 160, such as signed validation hashes 165 and respective signed package hashes, for verifying each of the updated installation packages 155c, 155d. The node 105 updates the current package set 150a stored in the node record 505 by inserting the updated installation packages 155c, 155d into the current package set 150a in place of the current installation packages 155a, 155b, which are the current (i.e., updated) versions of the updated installation packages 155c, 155d, respectively. The node 105 installs the updated file system 510 based on the updated package set 150b including the updated installation packages 155c and 155d, and verifies the updated file system 510 with the verification data 160.

[0061] In this example, node 105 initially stores in its node record 505 in non-volatile storage 180 the current (i.e., updated) version of file system image 515 copied from the file system 510 installed before the update, the current package set 150a corresponding to the file system 510 installed before the update, and validation data 160 that is configured to install the file system 510 as installed before the update and validates the current version of the file system 510 before the update. In light of the fact that file system 510 has been updated, node 105 may update this record 505 accordingly. Thus, to update record 505, node 105 may replace the existing signed validation hash 165 in the record with the signed validation hash 165 received in firmware update package 120, and may replace the existing file system image 515 in record 505 with the updated file system image 515 copied from the newly installed and thus newly updated file system 510. As mentioned above, in some implementations, the signed validation hash 165 and file system image 515 are maintained for use in re-establishing the file system 510 in volatile memory 190 after the node 105 loses power, and the updated package set 150b is maintained for use during future updates to the file system 510 or for reinstalling the file system 510 for troubleshooting or other purposes.

[0062] 6 illustrates a diagram of a node 105, specifically a utility meter 600, in accordance with some implementations described herein. For example, the utility meter 600 may be a water meter, a gas meter, or other type of meter that measures consumption of a resource 610. The utility meter 600 as shown may function as a node 105 configured to install and utilize firmware 140 as described herein. More specifically, for example, the firmware 140 may be the file system 510 of the utility meter 600. While this disclosure refers to the implementations described herein being embodied in the utility meter 600, it will be understood by those skilled in the art that the implementations are not limited to the utility meter 600. Rather, for example, the node 105 may be a collector, gateway, or other computing device other than the utility meter 600.

[0063] 6 , the exemplary utility meter 600 measures consumption of a resource 610 occurring within a building premises 620. To this end, the utility meter 600 may include a metering engine 605 that detects signals indicative of resource 610 usage and determines, based on the signals, usage of the resource 610 within the building premises 620. The utility meter 600 may further include a processing unit 630, volatile memory 190, non-volatile storage 180, and a communication device, such as a radio 660. For example, the utility meter 600 may use the radio 660 to download a firmware update package 120 from a firmware update server 130 or from a provider server 110 as described herein. The processing unit 630, the volatile memory 190, the non-volatile storage 180, and the radio 660 may be in communication with each other and with the metering engine 605 via a system bus 670. While the processing unit 630, volatile memory 190, and non-volatile storage 180 are shown and described herein as being separate components, it will be understood that this distinction is for purposes of illustration only and is not intended to limit the scope of the present disclosure. For example, the processing unit 630, volatile memory 190, and non-volatile storage 180 may be integrated together on a single chip, such as a microcontroller unit.

[0064] In some implementations, the operations of the node 105 described herein, such as installing the firmware 140, verifying the firmware 140, and executing the firmware 140, are embodied as program instructions stored on a computer-readable medium, such as the non-volatile storage 180 or the volatile memory 190 of the utility meter 600. In some implementations, the computer-readable medium is a non-transitory computer-readable medium. The processing unit 630 may execute the program instructions to perform the operations as described herein.

[0065] Numerous specific details are described herein to provide a thorough understanding of the claimed subject matter. However, those skilled in the art will understand that the claimed subject matter may be practiced without these specific details. In other instances, methods, apparatuses, or systems that would be known by those skilled in the art have not been described in detail so as not to obscure the claimed subject matter.

[0066] The features discussed herein are not limited to any particular hardware architecture or configuration. A computing device can include any suitable arrangement of components that provides a result conditioned on one or more inputs. Suitable computing devices include general-purpose microprocessor-based computer systems that access stored software (i.e., computer-readable instructions stored on the computer system's memory) that programs or configures the computing system from a general-purpose computing device to a specialized computing device that implements one or more aspects of the present subject matter. Any suitable programming, scripting, or other type of language or combination of languages ​​can be used to implement the teachings contained herein in software used in programming or configuring a computing device.

[0067] Aspects of the methods disclosed herein may be performed in operation of such a computing device. The order of the blocks presented in the above examples may be changed; for example, the blocks may be reordered, combined, and / or divided into sub-blocks. Certain blocks or processes may be performed in parallel.

[0068] The use of "adapted to" or "configured to" herein is intended as open and inclusive language that does not preclude devices adapted or configured to perform additional tasks or steps. Furthermore, the use of "based on" is intended to be open and inclusive in the sense that when a process, step, calculation, or other operation is "based on" one or more recited conditions or values, it may in fact be based on additional conditions or values ​​beyond those recited. Headings, lists, and numbering contained herein are for ease of description only and are not intended to be limiting.

[0069] While the present subject matter has been described in detail with respect to aspects of its embodiments, it will be understood that those skilled in the art, once armed with the foregoing understanding, will be able to readily make modifications, variations, and equivalents to such embodiments. Accordingly, it will be understood that the present disclosure has been presented for purposes of illustration and not limitation, and is not intended to exclude the inclusion of modifications, variations, and / or additions to the present subject matter as would be readily apparent to one skilled in the art.

Claims

1. 1. A method for updating firmware, comprising: receiving, at the device, an updated installation package including an updated version of an installation package belonging to a set of installation packages stored on the device for installing firmware on the device; updating the set of installation packages stored on the device by replacing the installation package with the updated installation package; installing updated firmware into a volatile memory of the device based on the set of updated installation packages including the updated installation package; receiving, at the device, a signed validation hash of an authentic version of the updated firmware installed on the device; generating a hash of the updated firmware installed on the device; verifying that the hash matches the signed validation hash of an authentic version of the updated firmware; storing an image of the updated firmware in non-volatile storage of the device; and During boot of the device: loading the image of the updated firmware from the non-volatile storage of the device into the volatile memory of the device so as to execute the updated firmware from the volatile memory; hashing the updated firmware to generate a current hash; and attempting to verify the authenticity of the updated firmware by verifying whether the current hash of the updated firmware matches the signed validation hash of an authentic version of the updated firmware; A method including:

2. the set of installation packages includes a plurality of installation packages; The step of updating the set of installation packages comprises: replacing an appropriate subset of said set of installation packages with updated versions; The method of claim 1.

3. the updated firmware is a file system; The method according to claim 1 or claim 2.

4. the device is a utility meter; The updated installation package is received over a wireless network. The method according to claim 1 or claim 2.

5. A system including a server, a server processor configured to execute computer-readable instructions; When executed by the server processor, Identifying an updated installation package; updating the set of installation packages to the updated set of installation packages by inserting the updated installation package into the set of installation packages to replace an existing version of the updated installation package; installing the updated set of installation packages, including the updated installation package, to generate reference firmware; generating a signed validation hash based on the installed reference firmware; providing the updated installation package and the signed validation hash remotely from the server to one or more nodes, and the one or more nodes updating the one or more nodes using the updated installation package; a server memory configured to store computer-readable instructions for execution by the server processor; the server includes moreover, the node includes a node processor configured to execute computer-readable instructions to perform the operations of the node; The operation of the node is as follows: storing an image of the updated firmware in non-volatile storage of the node; and During boot of said node, loading the image of the firmware from the non-volatile storage of the node into a volatile memory of the node so that the firmware can be executed from the volatile memory; hashing the updated firmware to generate a current hash; and attempting to re-verify the authenticity of the firmware by verifying whether the current hash of the updated firmware matches the signed validation hash of an authentic version of the updated firmware; Including, the system.

6. moreover, The operation of the node is as follows: receiving the updated installation package and the signed validation hash; updating the local set of installation packages by replacing an existing version of the updated installation package with the updated installation package in the local set of installation packages stored on the node; installing the firmware into the volatile memory of the node based on the local set of installation packages including the updated installation package, and enabling the firmware to be executed from the volatile memory; verifying the authenticity of the firmware by comparing a hash of the firmware with the signed validation hash; Including, The system of claim 5.

7. The step of attempting to re-verify the authenticity of the firmware comprises: detecting that the current hash of the firmware is not equal to the signed validation hash; moreover, The operation of the node is as follows: requesting from the server a replacement of one or more installation packages in the local set of installation packages based on the current hash of the firmware not being equal to the signed validation hash; The system of claim 6.

8. the local set of installation packages includes a plurality of installation packages; updating the local set of installation packages, replacing an appropriate subset of the local set of installation packages with updated versions; 8. The system according to claim 6 or claim 7.

9. the node is a utility meter; 7. The system according to claim 5 or claim 6.

10. The system of claim 9 , wherein the firmware is a file system for the utility meter.

11. 1. A method for updating a file system, comprising: receiving, at the device, an updated installation package that includes an updated version of an installation package belonging to a set of installation packages stored on the device for installation on a file system of the device; updating the set of installation packages stored on the device by replacing the installation package with the updated installation package; installing an updated file system in a volatile memory of the device based on the set of updated installation packages, including the updated installation package; receiving, at the device, a signed validation hash of an authentic version of the updated file system installed on the device; generating a hash of the updated file system installed on the device; validating the updated file system by comparing a hash of the updated file system with the signed validation hash; storing an image of the updated file system in non-volatile storage of the device; and During boot of said device, loading the image of the updated file system from the non-volatile storage of the device into the volatile memory of the device so as to execute the updated file system from the volatile memory; hashing the updated file system to generate an updated hash; and attempting to revalidate the updated file system by comparing an updated hash of the updated file system with the signed validation hash of an authentic version of the updated file system; A method comprising:

12. The step of attempting to revalidate the updated file system includes: generating the updated hash by hashing the updated file system stored in the volatile memory of the device after loading the image of the updated file system from the non-volatile storage of the device into the volatile memory of the device; The method of claim 11.

13. The step of attempting to revalidate the updated file system includes: generating the updated hash by hashing the image of the updated file system before loading the image of the updated file system from the non-volatile storage of the device into the volatile memory of the device; The method of claim 11.

14. receiving the updated installation package includes downloading the updated installation package over a wireless mesh network; 14. The method according to any one of claims 11 to 13.

Images