Controllable range of authentication keys for software updates

CN115516420BActive Publication Date: 2026-10-30TEXAS INSTRUMENTS INC
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202180033676.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2020-05-14
Filing Date
2021-05-13
Publication Date
2026-10-30
Estimated Expiration
2041-05-13

AI Technical Summary

Technical Problem

然而,这些公开密钥及证书可能具有无限范围且可为可操作的,除非证书使用相对复杂的撤销机制来撤销

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115516420B_ABST
    Figure CN115516420B_ABST
Patent Text Reader

Abstract

The invention provides techniques for updating a client device, including receiving, by a 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 scope value (216-224) from the certificate; comparing the update scope value (216-224) to a corresponding attribute of the update; and applying the software update based on the comparison or rejecting the software update based on the comparison.
Need to check novelty before this filing date? Find Prior Art

Description

Background Technology

[0001] Typically, devices capable of connecting to the Internet (referred to herein as connected devices) are obtained by users with a released version of software pre-installed on the device. In many cases, additional modifications to enhance or add features, fix bugs, address security issues, etc., after the release of the released software, may be made as software updates. Software updates allow connected devices to adapt to changing environments by allowing the software running on them to evolve with the environment rather than remaining fixed at the time of release.

[0002] Typically, a connected device update process involves downloading or otherwise obtaining a software update package and authenticating that package, for example, by verifying the digital signature and certificate associated with the update package. This digital signature or certificate is verified using a public key provided by the connected device vendor. However, these public keys and certificates can be virtually unlimited and operational unless the certificate is revoked using a relatively sophisticated 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 for application software updates. Summary of the Invention

[0003] This invention relates to software updates. More specifically, and not by way of limitation, aspects of the invention relate to techniques for updating software by: receiving a software update and a certificate by a client device; verifying, by the client device, the certificate associated with the software update based on a stored public key of the client device; extracting an update range value from the certificate; comparing the update range value with a corresponding attribute of the update; and applying the software update or rejecting the software update based on the comparison.

[0004] Another aspect of the invention relates to a non-transitory program storage device comprising instructions stored thereon that cause one or more processors to: generate an update range value that defines attributes of a software update; generate a digital signature protecting the update range value; generate a certificate containing 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 is configured to allow the client device to compare the update range value with corresponding attributes of the update.

[0005] Another aspect of the invention relates to an apparatus comprising: a memory; and one or more processors operatively coupled to the memory, wherein the one or more processors are configured to execute non-transitory instructions, the non-transitory instructions causing the one or more processors to: receive a software update and a certificate associated with the software update by the apparatus; verify the certificate associated with the software update by the apparatus based on a stored public key of the apparatus; extract a set of update range values ​​from the certificate; compare the update range values ​​with corresponding attributes of the update; and apply the software update or reject the software update based on the comparison. Attached Figure Description

[0006] For a detailed description of each example, please refer to the accompanying drawings, in which:

[0007] Figure 1 This is a diagram illustrating the digital certificate chain.

[0008] Figure 2 This is a block diagram illustrating the techniques used for application software updates 200 in some examples.

[0009] Figure 3 This describes the techniques used to update software in some examples.

[0010] Figure 4 This describes the techniques used to update software in some examples.

[0011] Figure 5 This is a schematic diagram of an embodiment of a computing system in some instances.

[0012] Figure 6 This is a block diagram of an embodiment of a connected device in some instances. Detailed Implementation

[0013] Public-key cryptography is often used in conjunction with digital certificates and signatures. In public-key cryptography, a pair of keys, namely a public key and a private key, are mathematically correlated using a one-way function. The correlation between the public and private keys ensures that a message encoded with the public key can only be decoded using the private key, and vice versa. Therefore, a digital document (such as any kind of file) can be digitally signed by hashing the digital document's bits, encoding the hash using the private key, and then appending the encoded hash to the digital document along with the public key. Verification can then be performed by decoding the hash using the public key and comparing the decoded hash with the hash of the digital document. Digital signatures can be used to verify that a particular software update comes from a trusted source, such as a vendor of a connected device or system.

[0014] Some connected devices only install software updates from trusted sources, such as those verified by digital signatures. Typically, a connected device contains a public key associated with the device's vendor. This public key or certificate may be installed on the connected device as part of its manufacturing process. When a software update is developed, the software is signed using the vendor's private key, and the signature is appended to the software update package. After receiving the software update package, the connected device verifies the software update by verifying the digital signature using, for example, the public key or certificate pre-stored on the connected device during its manufacturing. Once the software update's public key or certificate has been verified by the device, the software update is trusted and can be applied.

[0015] Figure 1 This is a block diagram illustrating the digital certificate chain 100. In some cases, the vendor of the connected device can act as the root certificate authority associated with the vendor's connected device. Root certificate 102 contains root metadata 104, such as the name of the root certificate authority, its identifier, the certificate's expiration date, etc. The public key of root certificate 102 is associated with the private key of the root certificate authority. Root certificate 102 also contains a root public key 106 and a root signature 108. The root signature 108 can be calculated using the root certificate authority's private key based on the root metadata and the root public key 106, because root certificate 102 is self-signed. When the vendor is the root certificate authority, the root public key 106 is used as the Trusted Public Key Root (ROTPK).

[0016] In cases where the vendor is the root certificate authority, the vendor may not want to use root certificate 102 to directly issue certificates to help maintain the security of the root certificate. In such cases, the vendor may create one or more intermediate certificates 110 based on root certificate 102. In this document, intermediate certificate 110 contains intermediate metadata 112, which may contain metadata identifying the intermediate certificate authority (e.g., who or what the intermediate certificate 110 is used for). For example, intermediate metadata 112 may indicate that intermediate certificate 110 is a firmware authentication key (FWAK) used to sign firmware updates and is distributed to a specific person or team. Firmware may refer to low-level software that controls hardware of a connected device. When using the term firmware, the concepts described herein can often be applied more broadly to software and devices. Intermediate metadata 112 may also identify the root certificate authority, for example, by including root public key 106 or the name of the root certificate authority. 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 contains an intermediate public key 116 based on the private key of the intermediate certificate authority.

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

[0018] Digital signatures may be applied to firmware updates during the development and / or release phase. Creating this digital signature may require a private key associated with intermediate certificate 110 or root certificate 102. In some cases, the security of the private key may be potentially compromised, such as through employee turnover or illegal activities, and it may be necessary to revoke and otherwise replace the private key. However, revoking these keys can be difficult for connected devices, as these devices may be offline or difficult to update with revocation information.

[0019] Figure 2 This is a block diagram illustrating the techniques used for application software updates 200 in some instances. In some cases, update package 202 includes update code 204 for updating the connected device 230 and update certificate 206. Update certificate 206 may be based on a certificate chain (e.g., together with...). Figure 1 The described certificate chain and update code 204. For example, an organization can act as an intermediate certificate authority and issue certificates to sub-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 the intermediate certificate authority to request a certificate. The organization can then issue a certificate to the developer, for example, containing the developer's public key (e.g., subject public key 212) and the organization's digital signature (e.g., publisher signature 210). Publisher signature 210 may be a hash based at least in part on subject public key 212 and subject metadata.

[0020] The update certificate 206 may also include scope fields, such as certificate serial number 214, firmware version 216, target firmware component 218, validity period 220, and device ID 222. The update certificate 206 may include additional scope fields 224 as needed. In some cases, scope fields may be included as metadata, for example, in the subject metadata. For example, publisher metadata 208 may include one or more scope fields. Scope fields define the scope of the firmware update and contain additional information identifying the scope of the firmware update. Scope fields are digitally signed and protected by the digital signature. For example, scope fields may be included in a portion of a hashed and subsequently signed certificate, and the scope of the update certificate 206 may be fixed. In some cases, different scopes may be set for each update certificate, as defined by the values ​​within the scope fields. For example, a certificate may contain a specific version of the update code 204 to which the certificate is valid for each build of the firmware update against said specific version. In some cases, the value of the scope field may be based on the nature of the update code provided by the subject or the publisher.

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

[0022] A certificate scope definition requires a set of conditions to be met for an update to be applied. For example, the scope of firmware update 202, defined by the scope field, is enforced by the connected device 230 receiving firmware update 202. The scope verification module 240 of the connected device 230 can verify the scope defined by the certificate against the update conditions, for example, based on the nature of the firmware update 202, the nature of the device, the method of applying the update, etc. As an example, the scope of the update can be based on a serial number associated with the certificate. In this example, the serial number can only be used once, and the certificate can be generated together with a unique, continuously incrementing certificate serial number 214. Therefore, whenever a new certificate is generated, a different certificate serial number is provided to the new certificate, which is greater than the certificate serial number associated with the previous certificate. When an update is applied via the connected device 230, the connected device 230 stores the serial number associated with the update, in this example as the current serial number 242. When the next update is received, the scope verification module 240 obtains the certificate serial number 214 from the updated certificate 206 after comparing it with the stored ROTPK verification certificate's digital signature. The range verification module 240 obtains the current serial number 242 via the connection device 230 and compares the current serial number 242 with the certificate serial number 214 of the firmware update to verify the certificate serial number 214 against the current serial number 242. If the certificate serial number 214 exceeds the current serial number 242, the certificate and associated update are within range. If a given certificate serial number can be used multiple times, the connection device 230 may include a counter that increments each time a specific serial number is used and compared to a limit.

[0023] As another example, the update range can be based on the firmware version. In this example, the range verification module 240 can obtain the version range 216 from the range field of the certificate after comparing it with the digital signature of the stored ROTPK verification certificate. This version range 216 may specify a version or version range for which the certificate is valid. The range verification module 240 can also obtain the updated version of the update code 204 and the current firmware version 234. The range verification module verifies that the updated version is greater than the current firmware version and also verifies that the updated version of the update code 204 matches the version range 216 or is within the version range 216. If the updated version of the update code 204 cannot be verified against the version range 216, then 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 differ, for example, based on the configuration of the connected device. Some versions of the connected device may support different features, such as different supported networking protocols, available sensors, location-specific differences, etc. These different versions of the connected device may have different firmware components based on the supported features. Information about a specific current firmware component 234 may be included in the current firmware 232. The scope verification module 240, as part of checking the scope of the firmware update 202, may access the scope field of the target firmware component 218 and the current firmware component 234. The scope verification module 240 may compare the current firmware component 234 to determine if the target firmware component 218 matches the current firmware component 234. In some cases, the scope verification module 240 may check that the target firmware component 218 contains at least some of the current firmware components 234.

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

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

[0027] Figure 3This describes the techniques used for updating software 300 in some instances. In step 302, the 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 contain a digital certificate and a digital signature based on a hash of the certificate's scope field. In some cases, the digital certificate may be received separately from the software update. In step 304, the client device verifies the certificate associated with the software update based on a stored public key on the client device. For example, the certificate may contain a public key of an intermediate issuing authority, which can be used to extract a signature that can be decoded by a manufacturer's public key stored on the connected device to verify that the software update originates from the manufacturer. This public key may, for example, be stored on the device when it is manufactured. In step 306, an update scope value is extracted from the certificate. For example, one or more scope fields may be included in the update certificate. These scope fields define the scope of the firmware update. Examples of scope fields include a certificate serial number, software version number, or scope and update protocol. In step 308, the update scope value is compared with the corresponding attributes of the update. The updated attributes may include, for example, the nature of the client device, environmental values ​​such as the protocol or technology used to obtain the update, metadata associated with the update, and the relationship between the certificate and the update. For instance, the update serial number may be compared with the current serial number already associated with the software on the connected device to verify that the update serial number is greater. Other instances include verifying that the update version number is equal to or within the range of version numbers in the range field. In step 310, the software update is applied or rejected based on the comparison. For example, if the comparison is successful, the software update is applied. In another instance, if the comparison fails, for example, if the software update is outside the version range defined in the certificate, the software update is rejected.

[0028] Figure 4 This describes the techniques used to update software 400 in some instances. In step 402, an update scope value is generated, defining the attributes of the software update. As described above, the update attributes may include, for example, the nature of the client computing device, environmental values ​​such as the protocol or technology used to obtain the update, metadata associated with the update, the relationship between the certificate and the update, etc. In some cases, multiple attributes may be included. In step 404, a digital signature protecting the update scope value is generated. For example, the scope value may be contained in one or more fields of a digital certificate. The digital signature may be generated based on the fields of the digital certificate (including the scope value). The digital signature then protects the scope value. In some cases, the digital signature may be the digital signature of the certificate issuer. In step 406, a certificate containing the digital signature and the update scope value is generated. In step 408, the software update and the update scope value are transmitted to the connected device, wherein the update scope value is configured to allow the client device to compare the update scope value with the corresponding attributes of the update.

[0029] Figure 5 This is a schematic diagram of an embodiment of a computing system 500 in which embodiments of the invention can be operated. The computing system 500 may include connection devices 502A to 502C (collectively referred to as 502), an update server 504, and a network 506 (e.g., the Internet). In some embodiments, the update server 504 may not be a single server, but may be one or more servers accessible via a single network address (e.g., a Uniform Resource Locator (URL)). In some cases, the update server 504 may be a list of alternative download resources and may include third-party servers. The URL may be utilized by an organization distributing software updates. Although in Figure 5 While not explicitly stated, update server 504 may also include one or more data centers. A data center may contain multiple server examples, each of which may be implemented on a physical computing system (e.g., 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). Server examples may be connected via 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 server may also be located within a local area network (LAN).

[0030] Connected devices 502 may include (but are not limited to) IoT devices, mobile devices (e.g., smartphones, tablets, etc.), personal computers, wearable devices, etc. Some connected devices 502 (e.g., connected devices 502A and 502B) are coupled to update server 504 and are capable of communicating with update server 504 via network 506. Some connected devices 502C may be coupled to one or more other connected devices 502D and are capable of receiving updates via one or more other connected devices 502D and network 506. Network 506 may include one or more currently available computing networks, such as LANs, wide area networks (WANs), the Internet, and / or other remote networks. Network 506 may contain wired and / or wireless programmable devices operating in the electrical and / or optical domains. For example, network 506 may include wired networks (e.g., Ethernet, Universal Serial Bus (USB), fiber optic connections, etc.), wireless networks (e.g., cellular networks (e.g., GSM-based cellular networks)), wireless fidelity (Wireless Fiber Optics), and wireless networks (e.g., wireless networks based on Global System for Mobile Communications (GSM)). (WIFI is a registered trademark of the Wi-Fi Alliance, Inc.) Networks and / or other suitable radio-based networks that a person skilled in the art would understand upon viewing this invention. Network 506 may also employ any number of network communication protocols, such as Transmission Control Protocol (TCP) and Internet Protocol (IP). Although in Figure 5While not explicitly shown, network 506 may include various network devices, such as servers, routers, network switches, and / or other network hardware devices configured to transmit data over the network. In some cases, update server 504 may be directly connected to connection device 502. For example, update server 504 may be connected via a direct serial interface, a short-range RF connection, a parallel cable, etc.

[0031] like Figure 6 The description indicates that the connected device 600 includes processing elements, such as a processor 605 containing one or more hardware processors, each of which may have one or more processor cores. Examples of processors include (but are not limited to) a central processing unit (CPU) or a microprocessor. Although Figure 6 Although not specified, the processing element 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] Figure 6 The memory 610 is operatively and communicatively coupled to the processor 605. The memory 610 may be a non-transitory computer-readable storage medium configured to store various types of data. For example, the memory 610 may include one or more volatile devices, such as random access memory (RAM). The 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 duration after a power-off or shutdown operation. The non-volatile storage device 620 may also be used to store such programs that are loaded into RAM during program execution.

[0033] Those skilled in the art will recognize that software programs can be developed, coded, and compiled in various computing languages ​​for use on various software platforms and / or operating systems, and subsequently loaded and executed by processor 605. In one embodiment, the compilation process of a software program can transform program code written in a programming language into another computer language, enabling processor 605 to execute the programming code. For example, the compilation process of a software program can produce an executable program that provides processor 605 with encoded instructions (e.g., machine code instructions) to implement specific, non-general-purpose computational functions.

[0034] Following the compilation process, the encoded instructions are then loaded as computer-executable instructions or process steps from storage device 620, from memory 610, into processor 605, and / or embedded within processor 605 (e.g., via cache or onboard ROM). Processor 605 may be configured to execute the stored instructions or process steps to transform the computing device into a non-general-purpose, specific, specially programmed machine or device. For example, the stored data in storage device 620 may be accessed by processor 605 during the execution of the computer-executable instructions or process steps to instruct one or more components within computing device 600. Storage device 620 may be partitioned or divided into multiple segments accessible by different software programs. For example, storage device 620 may contain segments marked for a specific purpose, such as storing program instructions or data for updating software of computing device 600. In one embodiment, the software to be updated includes ROM or firmware of the computing device. In some cases, computing device 600 may contain multiple operating systems. For example, computing device 600 may include a general-purpose operating system for normal operation. Computing device 600 may also include another operating system for performing specific tasks, such as a bootloader, which may update and restore the general-purpose operating system and allow access to computing device 600 at levels normally unavailable through the general-purpose operating system. Both the general-purpose operating system and the other operating system may access segments of storage device 620 designated for a specific purpose.

[0035] The computing device 600 may also include one or more communication interfaces 625 communicatively coupled to the processor 605. The one or more communication interfaces may include radio communication interfaces for interfacing with one or more radio communication devices. In some cases, the elements coupled to the processor may be included on hardware shared with the processor. For example, the communication interface 625, storage device 620, and memory 610 may be included in a single chip or package, such as in a system-on-a-chip (SoC), along with other elements, such as 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 mice, keyboards, and touchscreens. 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 an output device (not shown) for providing output to a user, for example. Examples of output devices include a display screen, a haptic or motion generator, a speaker, a light, etc.

[0036] The term "coupled" is used throughout this specification. The term may encompass a connection, communication, or signal path that achieves a functional relationship consistent with the description of this invention. For example, if device A generates a signal to control device B to perform an action, then in a first instance, device A is coupled to device B; or in a second instance, if the intermediary component C substantially does not alter the functional relationship between device A and device B, then device A is coupled to device B via the intermediary component C, such that device B is controlled by the control signal generated by device A.

Claims

1. A method for updating a client device, comprising: The client device receives a software update and a certificate associated with the software update, wherein the software update includes update code; The certificate associated with the software update is verified by the client device based on the client device's stored public key; Obtain the version value of the update code for the software update; Obtain the current version number stored on the client device; In the first comparison, the version value of the updated code is compared with the current version number; Extract the version range value from the certificate; In the second comparison, the version value of the updated code is compared with the version range value extracted from the certificate; Access range-based data from the certificate; Access the identifier stored on the client device; In the third comparison, the range-based data from the certificate is verified to match the identifier stored on the client device; and any of the following operations: The software update is applied based on the first comparison, the second comparison, and the third comparison; or The software update is rejected based on the first comparison, the second comparison, and the third comparison.

2. The method of claim 1, wherein the second comparison includes verifying that the version value of the updated code matches the version range value.

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

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

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

6. The method according to claim 1, wherein: Accessing the range-based data from the certificate includes retrieving the certificate serial number from the certificate; Accessing the identifier stored on the client device includes accessing the current serial number stored on the client device; as well as In the third comparison, verifying the range-based data match from the certificate to the identifier stored on the client device includes comparing the certificate serial number with the current serial number.

7. The method according to claim 1, wherein: Accessing the range-based data from the certificate includes a list of identifiers from the certificate access device. The identifier stored on the client device includes the device identifier number for accessing the client device; as well as In the third comparison, the range-based data matching from the certificate is verified. The identifier stored on the client device includes the device identifier number of the client device, which is listed in the device identifier list.

8. The method according to claim 1, wherein: Access the target component scope field from the certificate; and In the fourth comparison, the target component scope field is compared with the current component on the client device; and any of the following operations: The software update is applied based on the first comparison, the second comparison, the third comparison, and the fourth comparison; or The software update is rejected based on the first comparison, the second comparison, the third comparison, and the fourth comparison.

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

10. A client device comprising: A memory configured to store the current version number and identifier; as well as One or more processors operatively coupled to the memory, wherein the one or more processors are configured to execute non-transitory instructions that cause the one or more processors to: Receive software updates and certificates associated with the software updates, wherein the software updates contain update code; The certificate associated with the software update is verified using the device's stored public key; Obtain the version value of the update code for the software update; In the first comparison, the version value of the updated code is compared with the current version number; Extract the version range value from the certificate; in the second comparison, compare the version value of the updated code with the version range value extracted from the certificate; Access range-based data from the certificate; In the third comparison, the range-based data from the certificate is verified to match the identifier in the memory; and any of the following operations: The software update is applied based on the first comparison, the second comparison, and the third comparison; or The software update is rejected based on the first comparison, the second comparison, and the third comparison.

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

12. The client device of claim 10, wherein the version range value includes a version number range, and wherein the second comparison includes verifying that the version value of the update code of the software update is within the version number range.

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

14. The client device of claim 10, wherein the stored public key of the device includes the public key of the device manufacturer.

15. The client device according to claim 10, wherein: The identifier in the memory is the current serial number. Accessing the range-based data from the certificate includes the operation of retrieving the certificate serial number from the certificate; as well as In the third comparison, verifying the range-based data match from the certificate and the identifier stored in the memory includes comparing the certificate serial number with the current serial number.

16. The client device according to claim 10, wherein: The identifier in the memory is a device identifier; Accessing the range-based data from the certificate includes operations from the certificate access device identifier list; as well as In the third comparison, verifying the range-based data match from the certificate, the identifier stored in the memory includes the operation of verifying the device identifier number listed in the device identifier list.

17. The client apparatus of claim 10, wherein the non-transitory instruction is configured to be executed by the one or more processors to further cause the one or more processors to verify the digital signature of the software update based on the certificate.

18. A client device comprising: A memory configured to store the current version number, the current serial number, and the device identifier; as well as One or more processors operatively coupled to the memory, wherein the one or more processors are configured to execute non-transitory instructions that cause the one or more processors to: Receive software updates and certificates associated with the software updates, wherein the software updates contain update code; The certificate associated with the software update is verified using the device's stored public key; Obtain the version value of the update code for the software update; In the first comparison, the version value of the updated code is compared with the current version number; Extract the version range value from the certificate; In the second comparison, the version value of the updated code is compared with the version range value extracted from the certificate; Extract the certificate serial number from the certificate; In the third comparison, the certificate serial number is compared with the current serial number; From the certificate access device identifier list; In the fourth comparison, the device identifier is verified to be listed in the device identifier list; and any of the following operations: The software update is applied based on the first comparison, the second comparison, the third comparison, and the fourth comparison; or The software update is rejected based on the first comparison, the second comparison, the third comparison, and the fourth comparison.

19. The client device of claim 18, further comprising a current firmware component, wherein the non-transitory instructions are configured to be executed by the one or more processors to further cause the one or more processors to perform the following steps: Access the target component scope field from the certificate; In the fifth comparison, the target component range field is compared with the current firmware component; and any of the following operations: The software update is applied based on the first comparison, the second comparison, the third comparison, the fourth comparison, and the fifth comparison; or The software update is rejected based on the first comparison, the second comparison, the third comparison, the fourth comparison, and the fifth comparison.

Citation Information

Patent Citations

  • Method for providing a firmware update of a device

    US20190163465A1