Scope of control of authentication key for software updates

Abstract

A technique for updating a client device is provided, the technique including receiving, by the client device, a software update (204) and a certificate (206) associated with the software update (204), verifying, by the client device, the certificate (206) associated with the software update (204) based on a stored public key of the client device (230), extracting an update range value (216-224) from the certificate, comparing the update range value (216-224) with a corresponding attribute of the update, and either applying the software update based on the comparison or rejecting the software update based on the comparison.

Description

[Technical Field]

[0001] Typically, devices capable of connecting to the Internet, referred to herein as connected devices, are acquired by users with a shipped software version pre-installed on the device. Often, after the shipped software is released, software updates to the shipped software may be made, including additional changes to enhance or add various features, fix bugs, address security issues, etc. Software updates enable connected devices to adapt to ever-changing environments by allowing the software running on the connected device to evolve with the environment rather than remaining fixed at the time of release.

[0002] The connected device update process often includes downloading or otherwise obtaining a software update package and authenticating the software update package, such as by verifying a digital signature and certificate associated with the software update package. This digital signature or certificate is verified using the connected device vendor's public key. However, these public keys and certificates may have unlimited scope and may be operational unless the certificate is revoked using a relatively complex revocation mechanism. In some cases, it is desirable to reduce or eliminate the complexity associated with the revocation process to help minimize the amount of memory, network resources, and processing power required to apply the software update. Summary of the Invention

[0003] FIELD OF THE INVENTION This description relates to software updates. More particularly, but not by way of limitation, aspects of the description relate to an approach for updating software by receiving a software update and a certificate by a client device, validating the certificate associated with the software update based on a stored public key of the client device, extracting an update scope value from the certificate, comparing the update scope value with corresponding attributes of the update, and either applying the software update based on the comparison or rejecting the software update based on the comparison.

[0004] Another aspect of the present description relates to a non-transitory program storage device including instructions stored on the device, the instructions configured to cause one or more processors to generate an update range value defining attributes for the software update, generate a digital signature to protect the update range value, generate a certificate including the digital signature and the update range value, and transmit the certificate and the update range value to a client device, wherein the update range value enables the client device to compare the update range value with corresponding attributes of the update.

[0005] Another aspect of the present description relates to a device that includes a memory and one or more processors operably coupled to the memory, the one or more processors configured to execute non-transitory instructions that cause the one or more processors to receive, by the device, a software update and a certificate associated with the software update, validate, by the device, the certificate associated with the software update based on a stored public key of the device, extract a set of update range values from the certificate, compare the update range values to corresponding attributes of the update, and either apply the software update based on the comparison or reject the software update based on the comparison.

[0006] For a detailed description of various examples, reference will now be made to the accompanying drawings. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a block diagram illustrating a chain of digital certificates.

[0008] [Figure 2] 2 is a block diagram illustrating an approach for applying a software update 200 in some examples.

[0009] [Figure 3] 1 illustrates an approach for updating software in some examples.

[0010] [Figure 4] 1 illustrates an approach for updating software in some examples.

[0011] [Figure 5] FIG. 1 is a schematic diagram of an embodiment of a computing system according to some examples.

[0012] [Figure 6] FIG. 1 is a block diagram of an embodiment of a connection device according to some examples. DETAILED DESCRIPTION OF THE INVENTION

[0013] Public key cryptography is often used in conjunction with digital certificates and signatures. In public key cryptography, a pair of keys, a public key and a private key, are mathematically related using a one-way function. The public key and private key are related so that a message encoded with the public key can only be decoded using the private key, and vice versa. Thus, a digital document (e.g., any type of file) can be digitally signed by hashing the bits of the digital document using the private key to encode the hash, and then attaching the encoded hash to the digital document along with the public key. Verification can then be performed by decrypting the hash using the public key and then comparing the decrypted hash to the hash of the digital document. Digital signatures can be used to verify that a particular software update is from a trusted source, such as the vendor of a connected device or system.

[0014] A connected device will only install software updates from trusted sources, as verified by a digital signature. Often, a connected device contains a public key associated with the connected device's vendor. This public key or certificate may be installed on the connected device as part of creating the connected device. When a software update is developed, the software is signed with the vendor's private key, and the signature is attached to the software update package. After the connected device receives the software update package, the connected device verifies the software update by verifying the digital signature with a public key or certificate that was pre-stored on the connected device, for example, during the connected device's manufacture. Once the software update's public key or certificate is verified by the device, the software update is trusted and can be applied.

[0015] FIG. 1 is a block diagram illustrating a digital certificate chain 100. In some cases, a connected device vendor may act as a root certificate authority for connected devices associated with that vendor. The root certificate 102 includes root metadata 104, such as the root certificate authority's name, identifier, and certificate validity date. The root certificate 102's public key is associated with the root certificate authority's private key. The root certificate 102 also includes a root public key 106 and a root signature 108. The root signature 108 can be calculated based on the root metadata and the root public key 106 using the root certificate authority's private key, since the root certificate 102 is self-signed. When the vendor is a root certificate authority, the root public key 106 serves as a root of trust public key (ROTPK).

[0016] If a vendor is a root certificate authority, the vendor may not want to use the root certificate 102 that directly issues certificates to help maintain the security of the root certificate. In such cases, the vendor can create one or more intermediate certificates 110 based on the root certificate 102. Here, the intermediate certificate 110 includes intermediate metadata 112, which may include metadata identifying the intermediate certificate authority, such as who the intermediate certificate 110 is for or what purpose it is intended for. For example, the intermediate metadata 112 may indicate that the intermediate certificate 110 is a firmware authentication key (FWAK) for signing firmware updates and is issued to a specific person or team. Firmware may refer to low-level software that controls the hardware of a connected device. While the term firmware is used, the concepts described herein may also be more broadly applicable to software and devices in general. The intermediate metadata 112 may also identify the root certificate authority, for example, by including the root public key 106 or the name of the root certificate authority. The intermediate metadata 112 may be hashed and signed using the private key of the root certificate authority to create an intermediate signature 114. The intermediate certificate also includes an intermediate public key 116 that is based on the private key of the intermediate certificate authority.

[0017] In some cases, the vendor may not function as a root certificate authority, and the root certificate 102 may be held by a certificate authority, such as a commercial certificate authority. In such cases, the vendor may request and obtain the first intermediate certificate 110 from the certificate authority. The vendor may then generate a second intermediate certificate based on the first intermediate certificate 110 for use as a FWAK. Additional intermediate certificates may also be generated as needed. The second intermediate certificate may identify the intermediate certificate authority, i.e., the organization to which the first intermediate certificate was issued, by including the first intermediate public key 116 and / or the name of the first intermediate certificate authority.

[0018] During the development and / or release portion of a firmware update, a digital signature may be applied to the firmware update. Creating this digital signature may require the use of a private key associated with the intermediate certificate 110 or root certificate 102. In some cases, the security of the private key may potentially be compromised, such as through employee turnover or fraud, and the private key may need to be revoked or otherwise replaced. However, revoking these keys may be difficult for connected devices because these devices may be offline or difficult to update with revocation information.

[0019] FIG. 2 is a block diagram illustrating an approach for applying a software update 200 in some examples. In some cases, an update package 202 includes an update code 204 for updating a connected device 230 along with an update certificate 206. The update certificate 206, along with the update code 204, can be based on a chain of certificates as described in connection with FIG. 1. For example, an organization can act as an intermediate certificate authority and issue certificates to subordinate organizations, such as development or update teams, or even individuals, such as developers. As a more detailed example, a developer can generate a public / private key pair and submit their public key to an intermediate certificate authority to request a certificate. The organization can then issue a certificate based on the developer, for example, including the developer's public key, e.g., subject public key 212, and the organization's digital signature, e.g., issuer signature 210. The issuer signature 210 can be based at least in part on a hash of the subject public key 212 and subject metadata.

[0020] The update certificate 206 may also include scope fields, such as a certificate sequence number 214, a firmware version 216, a target firmware component 218, a validity period 220, and a device ID 222. The update certificate 206 may include an additional scope field 224, as needed. In some cases, the scope field may be included as metadata, such as in subject metadata. For example, issuer metadata 208 may include one or more scope fields. The scope field defines the scope of the firmware update and includes additional information identifying the scope of the firmware update. The scope field is signed and protected by a digital signature. For example, the scope field is included as part of the certificate that is hashed and signed by the issuer, and the scope is fixed for the update certificate 206. In some cases, different scopes may be configured for each update certificate, as defined by the value in the scope field. For example, a certificate may include a specific version of the update code 204 for which the updated certificate is valid for each build of FW. In some cases, the value of the scope field may be based on properties of the update code, provided by the subject, or provided by the issuer.

[0021] After the update package 202 is received by the connected device 230, the firmware update 202 may be stored in the memory of the connected device 230. A certificate validation module 236 of the connected device 230 verifies that the firmware update is from a trusted source. For example, the connected device 230 includes current firmware 232 having a current firmware version 234. After the firmware update 202 is received via the update protocol 250, the certificate validation module 236 verifies the update certificate 206 using the issuer's public key 212 and verifies the issuer signature 210. The certificate validation module 236 may access the intermediate certificate 226 from the firmware update 202 to obtain a root public key from the intermediate certificate 226. This obtained root public key is then verified against the ROTPK from the vendor certificate 238 installed during production of the connected device 230. Verifying the intermediate certificate 226 against the ROTPK allows the connected device 230 to verify that the issuer is a trusted source. If the firmware update is from a trusted source, the scope of the update certificate may be verified.

[0022] The certificate's scope defines a set of conditions that must be met to apply the update. The scope of a firmware update 202, as defined by the scope field, is enforced by the connectivity device 230 that receives the firmware update 202. The connectivity device 230's scope validation module 240 may validate the scope defined by the certificate against the update's conditions, for example, based on ownership of the firmware update 202, ownership of the device, how the update is being applied, etc. As an example, the scope of the update may be based on a sequence number associated with the certificate. In this example, the sequence number may be used only once, and the certificate may be generated with a unique, increasing certificate sequence number 214. Thus, each time a new certificate is generated, the new certificate is provided with a different certificate sequence number that is higher than the certificate sequence number associated with the previous certificate. When the connectivity device 230 applies an update, the connectivity device 230 stores the sequence number associated with the update as the current sequence number 242, in this example. When the next update is received, the scope validation module 240 retrieves the certificate sequence number 214 from the update certificate 206 after verifying the certificate's digital signature against the stored ROTPK. The range validation module 240 obtains the current sequence number 242 of the connected device 230 and compares the current sequence number 242 with the certificate sequence number 214 of the firmware update to verify that the certificate sequence number 214 is the same as the current sequence number 242. If the certificate sequence number 214 is greater than the current sequence number 242, the certificate and associated update may be within range. If a given certificate sequence number may be used multiple times, the connected device 230 may include a counter that is incremented and compared against the limit each time a particular sequence number is used.

[0023] As another example, the scope of the update may be based on the firmware version. In this example, the range verification module 240 may obtain the version range 216 from the certificate's range field after the certificate's digital signature is verified against the stored ROTPK. This version range 216 may specify the version or range of versions for which the certificate is valid, as the case may be. The range verification module 240 may also obtain the update version of the updated code 204 as well as the current firmware version 234. The range verification module verifies that the update version is greater than the current firmware version and also verifies that the update version of the update code 204 matches or is within the version range 216. If the update version of the update code 204 cannot be verified against the version range 216, the update code 204 is rejected.

[0024] As another example, the scope of the update may be based on the components of the connected device 230. In some cases, the firmware of the connected device 230 may vary, for example, based on the configuration of the connected device. Particular versions of connected devices may support different features, such as different supported networking protocols, available sensors, location-specific differences, etc. These different versions of connected devices may have different firmware components based on the supported functionality. Information regarding particular current firmware components 234 may be included in the current firmware 232. The range verification module 240 may access the target firmware component 218 range field and the current firmware component 234 as part of checking the scope of the firmware update 202. The range verification module 240 may compare the current firmware component 234 to determine that the target firmware component 218 matches the current firmware component 234. In some cases, the range verification module 240 may check that the target firmware component 218 includes at least some of the current firmware components 234.

[0025] As another example, the scope of the update may be based on a device identifier (ID) 244. In some cases, the connected device 230 includes a device ID 224 that may be installed during production of the connected device 230. The scope verification module 240 may access the list of device IDs 222 from the firmware update 202 and verify that the device ID 244 of the connected device 230 is in the list of device IDs 222.

[0026] In some cases, the scope of the firmware update 202 may be defined by additional properties, such as those included in the additional scope field 224. For example, the additional scope field 224 may indicate that the connected device 230 may be within range if the firmware update 202 is received via a certain update protocol 250. The update protocol may define how the update was obtained, such as the network protocol used to obtain the update or whether the update was copied directly to the device, such as via USB. The update protocol may be identified and stored in the memory 246 along with the firmware update 202. Other properties that define the scope of the firmware update 202 may also be included, such as those included in the additional scope field 224.

[0027] FIG. 3 illustrates an approach for updating software 300 in some examples. At step 302, a client device receives a software update and a certificate associated with the software update. For example, a connected device may receive a firmware update. The firmware update may include a digital certificate along with a digital signature based on a hash of a certificate scope field. In some cases, the digital certificate may be received separately from the software update. At step 304, the client device verifies the certificate associated with the software update based on a public key stored on the client device. For example, the certificate may include a public key of an intermediate authority, which can be used to extract a signature that can be decrypted with a manufacturer's public key stored on the connected device to verify that the software update originated from the manufacturer. This public key may be stored on the device, for example, when the device is manufactured. At step 306, an update scope value is extracted from the certificate. For example, one or more scope fields may be included with the update certificate. These scope fields define the scope of the firmware update. Examples of scope fields include a certificate sequence number, a software version number or scope, and an update protocol. At step 308, the update range value is compared to corresponding attributes of the update. The attributes of the update may include, for example, properties of the client device, environmental values such as the protocol or method used to obtain the update, metadata associated with the update, the relationship between the certificate and the update, etc. For example, the update sequence number may be compared to a current sequence number associated with the software already on the connected device to verify that the update sequence number is greater. Another example includes verifying that the upgrade version number is equal to or within the range of the version number in the range field. At step 310, the software update is applied based on the comparison, or the software update is rejected based on the comparison. For example, if the comparison is successful, the software update may be applied.In another example, the software update is rejected if the comparison fails, such as if the software update version is outside the range of versions defined in the certificate.

[0028] FIG. 4 illustrates an approach for updating software 400 in some examples. At step 402, an update range value is generated, where the update range value defines attributes for the update. As described above, the attributes of the update may include, for example, properties of the client device, environmental values such as the protocol or method used to obtain the update, metadata associated with the update, a relationship between the certificate and the update, etc. In some cases, multiple attributes may be included. At 404, a digital signature protecting the update range value may be generated. For example, the range value may be included in one or more fields of a digital certificate. The digital signature may be generated based on fields of the digital certificate that include the range value. The digital signature then protects the range value. In some cases, the digital signature may be the digital signature of the certificate issuer. At step 406, a certificate including the digital signature and the update range value is generated. At step 408, the software update and the update range value are sent to the connected device, where the update range value is configured to enable the client device to compare the update range value with the corresponding attributes of the update.

[0029] FIG. 5 is a schematic diagram of an embodiment of a computing system 500 in which embodiments of the present description may function. The computing system 500 may include connected devices 502A-502C (collectively 502), an update server 504, and a network 506, such as the Internet. In some embodiments, the update server 504 may not be a single server, but rather one or more servers accessible via a single network address, such as a Uniform Resource Locator (URL). In some cases, the update server 504 may be a list of alternative download sources or may include third-party servers. The URL may be utilized by an organization that sells software updates. Although not specifically shown in FIG. 5, the update server 504 may also include one or more data centers. A data center may include multiple server instances, each of which may be implemented on a physical computing system, such as a single electronic computing device (e.g., a single physical hardware server), or may be in the form of multiple computing devices (e.g., multiple physical hardware servers). The server instances may be connected through one or more network devices (e.g., gateways or routers), or a combination of devices, to route or direct network traffic to the appropriate server. In some cases, the servers may be located within a local area network (LAN).

[0030] The connected devices 502 may include, but are not limited to, IoT devices, mobile devices such as smartphones and tablets, personal computers, wearable devices, etc. Certain connected devices 502, such as connected devices 502A and 502B, may be connected to and communicate with an update server 504 via a network 506. Certain connected devices 502C may be coupled to one or more other connected devices 502D and may obtain updates via the one or more other connected devices 502D and the network 506. The network 506 may include one or more computing networks available today, such as a LAN, a wide area network (WAN), the Internet, and / or other remote networks. The network 506 may include wired and / or wireless programmable devices operating in the electrical and / or optical domains. For example, the network 506 may include a wired network such as an Ethernet, a Universal Serial Bus (USB), a fiber optic connection, a cellular network (e.g., a Global System for Mobile Communications (GSM)-based cellular network), a wireless network such as a Wireless Fidelity (WiFi®) network (WIFI is a registered trademark owned by Wi-Fi Alliance, Inc.), and / or other suitable radio-based networks as would be understood by one of ordinary skill in the art upon reading this specification. The network 506 may also employ any number of network communication protocols, such as Transmission Control Protocol (TCP) and Internet Protocol (IP). Although not explicitly shown in FIG. 5, the network 506 may include various network devices, such as servers, routers, network switches, and / or other network hardware devices configured to transfer data over the network. In some cases, the update server 504 may be directly connected to the connection device 502. For example, the update server 504 may be connected via a direct serial interface, a short-range radio frequency connection, a parallel cable, etc.

[0031] As shown in Figure 6, connectivity device 600 includes processing elements such as processor 605, which includes one or more hardware processors, each of which may have a single or multiple processor cores. Examples of processors include, but are not limited to, a central processing unit (CPU) or a microprocessor. Although not shown in Figure 6, the processing elements of processor 605 may also include one or more other types of hardware processing components, such as a graphics processing unit (GPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and / or a digital signal processor (DSP).

[0032] FIG. 6 illustrates that memory 610 may be operatively and communicatively coupled to processor 605. Memory 610 may be a non-transitory computer-readable storage medium configured to store various types of data. For example, memory 610 may include one or more volatile devices, such as random access memory (RAM). Non-volatile storage device 620 may include one or more disk drives, optical drives, solid-state drives (SSDs), tape drives, flash memory, electrically programmable read-only memory (EEPROM), and / or any other type of memory designed to retain data for a period of time after a power loss or shutdown operation. Non-volatile storage device 620 may also be used to store programs that are loaded into RAM when such programs are executed.

[0033] Those skilled in the art will recognize that software programs can be developed, coded, and compiled in a variety of computing languages for a variety of software platforms and / or operating systems, and then loaded and executed by processor 605. In one embodiment, the software program compilation process can convert program code written in a programming language into another computer language so that processor 605 can execute the programming code. For example, the software program compilation process can generate an executable program that provides coded instructions (e.g., machine code instructions) to enable processor 605 to accomplish a specific, non-general-purpose, specific computing function.

[0034] After the compilation process, the encoded instructions may be loaded as computer-executable instructions or process steps from storage 620, from memory 610, into processor 605, and / or embedded within processor 605 (e.g., via cache or on-board ROM). Processor 605 may be configured to execute the stored instructions or process steps to perform instructions or process steps to transform the computing device into a non-general-purpose, particularly specially programmed, machine or apparatus. Stored data, such as data stored by storage device 620, may be accessed by processor 605 during execution of the computer-executable instructions or process steps to instruct one or more components within computing device 600. Storage 620 may be partitioned or divided into multiple sections that can be accessed by different software programs. For example, storage 620 may include sections designated for specific purposes, such as storing program instructions or data for updating software on computing device 600. In one embodiment, the updated software comprises the ROM or firmware of the computing device. In some cases, computing device 600 may include multiple operating systems. For example, computing device 600 may include a general-purpose operating system that is utilized for normal operation. Computing device 600 may also include another operating system, such as a boot loader, to perform specific tasks, such as upgrading and recovering the general-purpose operating system, and to allow access to computing device 600 at levels not generally available through the general-purpose operating system. Both the general-purpose operating system and the other operating system may have access to sections of storage 620 designated for specific purposes.

[0035] The computing device 600 may also include one or more communication interfaces 625 that may be communicatively coupled to the processor 605. The one or more communication interfaces may include a wireless communication interface for interfacing with one or more wireless communication devices. In some cases, elements coupled to the processor may be included on hardware shared with the processor. For example, the communication interface 625, storage 620, and storage 610 may be included on a single chip or package, such as a system-on-chip (SOC), along with other elements, such as a digital radio. The computing device 600 may also include an input device 630. Examples of input devices include sensors, cameras, and human input devices, such as a mouse, keyboard, or touchscreen. Processed input may be output from the computing device 600 to one or more other devices via the communication interface 625. In some cases, the computing device 600 may also include output devices, not shown, for example, to provide output to a user. Examples of output devices include, for example, a display screen, a haptic or motion generator, a speaker, a light, etc.

[0036] The term "couple" is used throughout this specification. This term may encompass a connection, communication, or signal path that enables a functional relationship consistent with the description herein. For example, in a first example, device A is coupled to device B if device A generates a signal to control device B to perform a certain action, or in a second example, device A is coupled to device B via an intervening component C such that device B is controlled by device A via a control signal generated by device A, where intervening component C does not substantially change the functional relationship between device A and device B.

Claims

1. 1. A method for updating a client device, performed by the client device, comprising: receiving a software update including an update code and a certificate associated with the software update; verifying a certificate associated with the software update based on a stored public key of the client device; obtaining a version value of an update code of the software update; obtaining a current version number stored on the client device; comparing a version value of the update code to the current version number in a first comparison; extracting a version range value from the certificate; comparing a version value of the update code with a version range value extracted from the certificate in a second comparison; accessing metadata from the certificate; accessing an identifier stored on the client device; verifying that the metadata from the certificate matches an identifier stored on the client device in a third comparison; applying the software update based on the first, second, and third comparisons or rejecting the software update based on the first, second, and third comparisons; A method comprising:

2. 10. The method of claim 1, The method, wherein the second comparison includes verifying that a version value of the update code is within the version range value.

3. 10. The method of claim 1, the version range value comprises a range of version numbers; The method, wherein the second comparison includes verifying that a version value of an update code of the software update is within the version number range.

4. 10. The method of claim 1, The method of claim 1, wherein the version range value is protected by a digital signature of the certificate.

5. 10. The method of claim 1, The method, wherein the stored public key of the client device includes a public key of a manufacturer of the client device.

6. 10. The method of claim 1, accessing the metadata from the certificate includes extracting a certificate sequence number from the certificate; accessing an identifier stored on the client device includes accessing a current sequence number stored on the client device; verifying that the metadata from the certificate matches an identifier stored on the client device in the third comparison includes comparing the certificate sequence number to the current sequence number.

7. 10. The method of claim 1, accessing the metadata from the certificate includes accessing a device identification list from the certificate; accessing an identifier stored on the client device includes accessing a device identification number of the client device; The method, wherein verifying that the metadata from the certificate matches an identifier stored on the client device in the third comparison includes verifying that a device identification number of the client device is listed in the device identification list.

8. 10. The method of claim 1, accessing a target component range field from the certificate; comparing the target component range field to current components on the client device in a fourth comparison; applying the software update based on the first, second, third, and fourth comparisons or rejecting the software update based on the first, second, third, and fourth comparisons; The method further comprises:

9. 10. The method of claim 1, The method further includes verifying a digital signature of the software update based on the certificate.

10. A device, a memory configured to store a current version number and an identifier; one or more processors operably coupled to the memory, the one or more processors comprising: receiving a software update including an update code and a certificate associated with the software update; verifying a certificate associated with the software update based on a stored public key of the device; obtaining a version value of an update code of the software update; comparing a version value of the update code to the current version number in a first comparison; extracting a version range value from the certificate; comparing a version value of the update code with a version range value extracted from the certificate in a second comparison; accessing metadata from the certificate; verifying that the metadata from the certificate matches the identifier in the memory in a third comparison; applying the software update based on the first, second, and third comparisons, or rejecting the software update based on the first, second, and third comparisons. the one or more processors configured to execute non-transient instructions; Including, the device.

11. 11. The device of claim 10, The device, wherein the second comparison includes verifying that a version value of the update code is within the version range value.

12. 11. The device of claim 10, the version range value comprises a range of version numbers; The device, wherein the second comparing includes verifying that a version value of an update code of the software update is within the version number range.

13. 11. The device of claim 10, The device, wherein the version range value is protected by a digital signature of the certificate.

14. 11. The device of claim 10, A device, wherein the stored public keys of the device include the public key of the manufacturer of the device.

15. 11. The device of claim 10, the identifier in said memory is the current sequence number; accessing metadata from the certificate includes an act for extracting a certificate sequence number from the certificate; verifying that the metadata from the certificate matches the identifier stored in the memory in the third comparison includes an operation for comparing the certificate sequence number with the current sequence number.

16. 11. The device of claim 10, the identifier in the memory is a device identification number; accessing the metadata from the certificate includes an act for accessing a device identification list from the certificate; The device, wherein verifying that the metadata from the certificate matches the identifier stored in the memory in the third comparison includes an operation for verifying that the device identification number of the device is listed in the device identification list.

17. 11. The device of claim 10, the non-transitory instructions are configured to be executed by the one or more processors to further cause the one or more processors to verify a digital signature of the software update based on the certificate.

18. A device, a memory configured to store a current version number, a current sequence number, and a device identification number; one or more processors operably coupled to the memory, the one or more processors comprising: receiving a software update including an update code and a certificate associated with the software update; verifying a certificate associated with the software update based on a stored public key of the device; obtaining a version value of an update code of the software update; comparing a version value of the update code to the current version number in a first comparison; extracting a version range value from the certificate; comparing a version value of the update code with a version range value extracted from the certificate in a second comparison; extracting a certificate sequence number from the certificate; comparing the certificate sequence number to the current sequence number in a third comparison; accessing a device identification list from the certificate; verifying in a fourth comparison that the device identification number is listed in the device identification list; applying the software update based on the first, second, third, and fourth comparisons, or rejecting the software update based on the first, second, third, and fourth comparisons. the one or more processors configured to execute non-transient instructions; Including, the device.

19. 20. The device of claim 18, further comprising a current firmware component; The non-transitory instructions configured to be executed by the one or more processors further include instructions to the one or more processors: accessing a target component range field from the certificate; comparing the target component range field to the current firmware component in a fifth comparison; The device applies the software update based on the first, second, third, fourth, and fifth comparisons, or rejects the software update based on the first, second, third, fourth, and fifth comparisons.

Images