Controlled scope of authentication key for software update

Techniques for updating a client device are provided that include receiving, by a client device, a software update and a certificate associated with the software update, 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 scope value from the certificate, comparing the update scope value against a corresponding attribute of the update, and either applying the software update based on the comparing, or rejecting the software update based on the comparing.

BACKGROUND

Generally, a device capable of being connected to the internet, referred to herein as a connected device, is obtained by a user with a shipped software version pre-installed on the device. In many cases, after the shipped software is released, additional changes to enhance or add features, fix bug, address security issues, etc. may be made as software updates to the shipped software. Software updates allow connected devices to adapt to an ever-changing environment by allowing the software running on the connected device to evolve with the environment rather than remaining fixed at the time of release.

Traditionally, a connected device update process 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 conventionally verified using a public key of the connected device vendor. However, these public keys and certificates typically have an unlimited scope and are operative unless the certificates are revoked using a relatively complex revocation mechanism. In certain cases, it is desirable to reduce or remove complexities associated with the revocation process to help minimize the amount of memory, network resources, and processing power needed to apply software updates.

SUMMARY

This disclosure relates to updating software. More particularly, but not by way of limitation, aspects of the present disclosure relate to techniques for updating software by receiving, by a client device, a software update and a certificate, 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 scope value from the certificate, comparing the update scope value against a corresponding attribute of the update, and either applying the software update based on the comparing, or rejecting the software update based on the comparing.

Another aspect of the present disclosure relates to a non-transitory program storage device comprising instructions stored thereon to cause one or more processors to generate an update scope value, the update scope value defining an attribute for a software update, generate a digital signature protecting update scope value, generate a certificate including the digital signature and the update scope value, and transmit, to a client device, the certificate and the update scope value, wherein update scope value is configured to allow the client device to compare the update scope value against corresponding attribute of the update.

Another aspect of the present disclosure relates to a device including 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 causing the one or more processors to receive, by the device, a software update and a certificate associated with the software update, verify, by the device, the certificate associated with the software update based on a stored public key of the device, extract a set of update scope values from the certificate, compare the update scope value against a corresponding attribute of the update, and either apply the software update based on the comparing, or rejecting the software update based on the comparing.

DETAILED DESCRIPTION

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 one way functions. The public key and private keys are related such that messages encoded using the public key can only be decoded using the private key and vice versa. Thus, a digital document (e.g., file of any kind) can be digitally signed by hashing the bits of the digital document encoding the hash using a private key, and then appending the encoded hash to the digital document along with the public key. Verification then can be performed by decoding the hash using the public key and then comparing the decoded hash against a hash of the digital document. Digital signatures may be used to verify that a particular software update is from a trusted source, such as the vendor of the connected device or system.

Certain connected devices typically only install software updates from a trusted source as verified by the digital signature. Often the connected devices include a public key associated with a vendor of the connected device. This public key or certificate may be installed on the connected device as a part of producing the connected device. 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 the connected device receives the software update package, the connected device verifies the software update by verifying the digital signature with the public key or certificate that was pre-stored on the connected device, for example, during manufacturing of the connected device. Once the public key or certificate of the software update has been verified by the device, the software update is trusted and may be applied.

FIG.1is a block diagram illustrating a chain of digital certificates100. In certain cases, a vendor of connected devices may serve as a root certificate authority for the connected devices associated with the vendor. The root certificate102includes root metadata104, such as the name of the root certificate authority, identifiers, date of validity of the certificate, etc. The public key of root certificate102is associated with a private key of the root certificate authority. The root certificate102also includes a root public key106and a root signature108. The root signature108may be computed based on root metadata and the root public key106, using the private key of the root certificate authority, as the root certificate102is self-signed. When the vendor is the root certificate authority, the root public key106functions as a root of trust public key (ROTPK).

In cases where the vendor is the root certificate authority, the vendor may not want to use the root certificate102directly issue certificates to help maintain the security of the root certificate. In such cases the vendor may create one or more intermediate certificates110based on the root certificate102. Here, the intermediate certificate110includes intermediate metadata112, which may include metadata identifying the intermediate authority, such as to whom, or for what purpose, the intermediate certificate110is for. For example, the intermediate metadata112may indicate that the intermediate certificate110is a firmware authentication key (FWAK) for signing firmware updates and is issued to a particular person or team. Firmware typically refers to low level software that controls hardware of the connected device. It may be understood that while the term firmware is used, the concepts discussed herein may apply more broadly to software and devices in general. The intermediate metadata112may also identify the root certificate authority, for example, by including the root public key106, or name of the root certificate authority. The intermediate metadata112may be hashed and signed using a private key of a root certificate authority to create an intermediate signature114. The intermediate certificate also contains an intermediate public key116based on the private key of the intermediate authority.

In certain cases, a vendor may not be serving as the root certificate authority and the root certificate102is held by a certification authority, such as a commercial certification authority. In such cases, the vendor may request and obtain a first intermediate certificate110from the certification authority. The vendor may also then generate a second intermediate certificate, based on the first intermediate certificate110, to use as a FWAK. Additional intermediate certificates may also be generated as needed. The second intermediate certificate may identify intermediate certification authority, that is the organization the first intermediate certificate was issued to, by including the first intermediate public key116, and/or name of the first intermediate certification authority.

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 certificate110or root certificate102. In certain cases, the security of the private key may potentially be compromised, such as through employee turnover or nefarious actions, and it may be necessary to revoke and otherwise replace the private keys. However, revocation of these keys can be difficult with connected devices as these devices may be offline or difficult to update with revocation information.

FIG.2is a block diagram illustrating a technique for applying a software update200, in accordance with aspects of the present disclosure. In certain cases, an update package202includes update code204for updating a connected device230along with an update certificate206. The update certificate206may be based on a chain of certificates, such as that described in conjunction withFIG.1, along with the update code204. For example, an organization may be acting as an intermediate certification authority and issue certificates to sub-organizations, such as a development or update team, or even individuals, such as developers. As a more detailed example, a developer may generate a public/private key pair and may submit their public key to the intermediate certification authority to request a certificate. The organization may then issue a certificate based for the developer, for example including the public key of the developer, e.g., a subject public key212, and a digital signature of the organization, e.g., the issuer signature210. The issuer signature210may be based at least in part on a hash of the subject public key212and subject metadata.

The update certificate206may also include scope fields such as a certificate sequence number214, version scope216, target firmware component218, validity period220, device id222. The update certificate206may include additional scope fields224as desired. In certain cases, scope fields may be included as metadata, for example, in the subject metadata. For example, the issuer metadata208may include one or more scope fields. The scope fields define the scope of the firmware update and contain additional information identifying the scope of the firmware update. The scope fields are signed and protected by a digital signature. For example, the scope fields are contained in a portion of the certificate which is hashed and then signed by the issuer and the scope is fixed for the update certificate206. In certain cases, a different scope, as defined by the values within the scope fields, may be set for each update certificate. For example the certificate may include a specific version of the update code204for which the certificate is valid against which is updated for each build of the FW. In certain cases, values for the scope fields may be based on properties of the update code, provided by the subject, or provided by the issuer.

After the update package202is received by the connected device230, the firmware updated202may be stored in a memory of the connected device230. A certificate verification module236of the connected device230verifies the firmware update is from a trusted source. For example, the connected device230includes a current firmware232with a current firmware version234. After the firmware update202is received via an update protocol250, the certificate verification module236verifies the update certificate206by using the issuer's public key212to verify the issuer signature210. The certificate verification module236can access the intermediate certificate226from the firmware update202to obtain a root public key from the intermediate certificate226. This obtained root public key is then validated against the ROTPK from the vendor certificate238installed during production of the connected device230. Verifying the intermediate certificate226against the ROTPK allows the connected device230to verify that issuer is a trusted source. If the firmware update is from a trusted source, the scope of the update certificate may be verified.

The scope of the certificate defines a set of conditions that must be satisfied to apply the update. The scope of the firmware update202, as defined by the scope fields, are enforced by the connected device230that receives the firmware update202. The scope verification module240of the connected device230may verify the scope, as defined by the certificate against conditions of the update, for example based on properties of the firmware update202, properties of the device, how the update is being applied, etc. As an example, the scope of an update may be based on a sequence number associated with the certificate. In this example, sequence numbers may only be used once and certificates may be generated with a certificate sequence number214which is a unique, increasing number. Thus, each time a new certificate is generated, the new certificate is provided with a different certificate sequence number which is larger than a certificate sequence number associated with a previous certificate. When the connected device230applies an update, the connected device230stores the sequence number associated with the update, in this example, as the current sequence number242. When the next update is received, the scope verification module240, after verifying the digital signature of the certificate as against the stored ROTPK, obtains a certificate sequence number214from the update certificate206. The scope verification module240obtains a current sequence number242of the connected device230and compares the current sequence number242to the certificate sequence number214of the firmware update to verify that the certificate sequence number214as against the current sequence number242. Where the certificate sequence number214exceeds the current sequence number242, then the certificate, and associated update, may be within scope. In cases where a given certificate sequence number may be used multiple times, the connected device230may include a counter that is incremented each time a particular sequence number is used and compared against a limit.

As another example, the scope of an update may be based on a firmware version. In this example, the scope verification module240may, after the digital signature of the certificate is verified as against the stored ROTPK, obtain a version scope216from the scope fields of the certificate. This version scope216, in certain cases, specifies versions, or a range of versions, against which the certificate is valid for. The scope verification module240may also obtain an update version of the updated code204, as well as a current FW version234. The scope verification module verifies that the update version is greater than the current FW version and also verifies that the update version of the update code204matches, or is within the range of, the version scope216. If the update version of the update code204cannot be verified against the version scope216, the update code204is rejected.

As another example, the scope of an update may be based on the components of the connected device230. In certain cases, the firmware of a connected device230may vary, for example, based on a configuration of the connected device. Certain versions of the connected device may support different features, such as different supported networking protocols, available sensors, location specific variances, etc. These different versions of the connected device may have different firmware components based on the supported features. Information regarding the specific current firmware components234may be included in the current firmware232. The scope verification module240, as a part of checking the scope of the firmware update202, may access a target firmware component218scope field and the current firmware components234. The scope verification module240may compare the current firmware components234to determine that the target firmware component218matches the current firmware components234. In certain cases, the scope verification module240may check that the target firmware component218includes at least some of the current firmware components234.

As another example, the scope of an update may be based on a device identifier (ID)244. In certain cases, the connected device230includes a device ID224, which may be installed during production of the connected device230. The scope verification module240may access a list of device IDs222from the firmware update202to verify that the device ID244of the connected device230is in the list of device IDs222.

In certain cases, the scope of the firmware update202may be defined by additional properties, for example, contained in the additional scope fields224, For example, the additional scope field224may indicate that the connected device230may be within scope if the firmware update202is received via a certain update protocol250. This update protocol may define how the update was obtained, for example, the network protocol used to obtain the update or whether the update was directly copied to the device, for example via USB. The update protocol may be identified and stored in a memory246along with the firmware update202. Other properties defining the scope of the firmware update202may also be contained, for example, in the additional scope fields224.

FIG.3illustrates a technique for updating software300, in accordance with aspects of the present disclosure. At step302, 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 the certificate scope fields. In certain cases, the digital certificate may be received separately from the software update. At step304, 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 include a public key of the intermediate authority, which may be used to extract a signature, which may be decoded by a public key of the manufacturer 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 was manufactured. At step306, 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, software version number or range, and update protocol. At step308, the update scope value is compared against a corresponding attribute of the update. Attributes of the update may include, for example, a property of the client device, environmental values, such as a protocol or technique used to obtain an update, metadata associated with the update, 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 larger. Other examples include verifying that the upgrade version number is equal to or within a range of a version number in the scope field. At step310, the software update is either applied based on the comparing or the software update is rejected based on the comparing. For example, if the comparisons succeed, the software update may be applied. In another example, if the comparison fails, such as if the software update version is outside of a range of versions defined in the certificate, then the software update is rejected.

FIG.4illustrates a technique for updating software400, in accordance with aspects of the present disclosure. At step402, an update scope value is generated, the update scope value defining an attribute for an update. As discussed above, attributes of the update may include, for example, a property of the client device, environmental values, such as a protocol or technique used to obtain an update, metadata associated with the update, relationship between the certificate and the update, etc. Multiple attributes may be included in certain cases. At404, a digital signature protecting the update scope value may be generated. For example, scope values may be included in one or more fields of a digital certificate. A digital signature may be generated based on the fields of the the digital certificate, including the scope values. The digital signature then protects the scope values. In certain cases, the digital signature may be the digital signature of the issuer of the certificate. At step406, a certificate is generated including the digital signature and the update scope value. At step408, a software update and the update scope value are transmitted to a connected device, wherein the update scope value is configured to allow the client device to compare the update scope value against corresponding attribute of the update.

FIG.5is a schematic diagram of an embodiment of a computing system500, where embodiments of the present disclosure may operate herein. Computing system500may include connected devices502A-502C (collectively502), an update server504, and network506, such as the internet. In some embodiments, the update server504may not be a single server, but one or more servers accessible via a single network address, such as a uniform resource locator (URL). In some cases, the update server504may be a list of alternative download sources, and may include third party servers. The URL may be utilized by an organization that distributes software updates. Although not specifically illustrated inFIG.5, the update server504may also include one or more datacenters. The datacenters may include a plurality of server instances, where each server instance can be implemented on a physical computing system, such as a single electronic computing device (e.g., a single physical hardware server) or could be in the form a multi-computing device (e.g., multiple physical hardware servers). Server instances may be connected via one or more network devices (e.g., gateway or router) or a combination of devices to route or direct network traffic to an appropriate server. In certain cases, the server may also be located within a local area network (LAN).

The connected devices502may include, but is not limited to, an IoT device, a mobile device, such as a smartphone, tablet, etc., a personal computer, a wearable device, etc. Certain connected devices502, such as connected device502A and502B are coupled to and able to communicate with the update server504via network506. Certain connected devices502C may be coupled to one or more other connected devices502D and able to obtain updates via the one or more other connected devices502D and network506. The network506may include one or more computing networks available today, such as LANs, wide area networks (WAN), the Internet, and/or other remote networks. The network506may contain wired and/or wireless programmable devices that operate in the electrical and/or optical domain. For example, network506may include wired networks, such as ethernet, universal serial bus (USB), fiber optic connections, etc., wireless networks, such as cellular networks (e.g., Global System for Mobile Communications (GSM) based cellular network), wireless fidelity (WiFi® (WIFI is a registered trademark owned by Wi-Fi Alliance Corporation)) networks, and/or other suitable radio based network as would be appreciated by one of ordinary skill in the art upon viewing this disclosure. The network506may also employ any number of network communication protocols, such as Transmission Control Protocol (TCP) and Internet Protocol (IP). Although not explicitly shown inFIG.5, network506may include a variety of network devices, such as servers, routers, network switches, and/or other network hardware devices configured to transport data over networks. In certain cases, the update server504may be directly connected to the connected device502. For example, the update server504may be connected via a direct serial interface, short range radio frequency connection, parallel cable, etc.

As illustrated inFIG.6, connected device600includes a processing element such as processor605that contains one or more hardware processors, where each hardware processor 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 illustrated inFIG.6, the processing elements that make up processor605may also include one or more other types of hardware processing components, such as graphics processing units (GPUs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and/or digital signal processors (DSPs).

FIG.6illustrates that memory610may be operatively and communicatively coupled to processor605. Memory610may be a non-transitory computer readable storage medium configured to store various types of data. For example, memory610may include one or more volatile devices such as random access memory (RAM). Non-volatile storage devices620can 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 memory designed to maintain data for a duration time after a power loss or shut down operation. The non-volatile storage devices620may also be used to store programs that are loaded into the RAM when such programs executed.

Persons of ordinary skill in the art are aware that software programs may be developed, encoded, and compiled in a variety of computing languages for a variety of software platforms and/or operating systems and subsequently loaded and executed by processor605. In one embodiment, the compiling process of the software program may transform program code written in a programming language to another computer language such that the processor605is able to execute the programming code. For example, the compiling process of the software program may generate an executable program that provides encoded instructions (e.g., machine code instructions) for processor605to accomplish specific, non-generic, particular computing functions.

After the compiling process, the encoded instructions may then be loaded as computer executable instructions or process steps to processor605from storage620, from memory610, and/or embedded within processor605(e.g., via a cache or on-board ROM). Processor605may be configured to execute the stored instructions or process steps in order to perform instructions or process steps to transform the computing device into a non-generic, particular, specially programmed machine or apparatus. Stored data, e.g., data stored by a storage device620, may be accessed by processor605during the execution of computer executable instructions or process steps to instruct one or more components within the computing device600. Storage620may be partitioned or split into multiple sections that may be accessed by different software programs. For example, storage620may include a section designated for specific purposes, such as storing program instructions or data for updating software of the computing device600. In one embodiment, the software to be updated includes the ROM, or firmware, of the computing device. In certain cases, the computing device600may include multiple operating systems. For example, the computing device600may include a general-purpose operating system which is utilized for normal operations. The computing device600may also include another operating system, such as a bootloader, for performing specific tasks, such as upgrading and recovering the general-purpose operating system, and allowing access to the computing device600at a level generally not available through the general-purpose operating system. Both the general-purpose operating system and the another operating system may have access to the section of storage620designated for specific purposes.

Computing device600may also include one or more communications interfaces625which may be communicatively coupled to processor605. The one or more communications interfaces may include a radio communications interface for interfacing with one or more radio communications devices. In certain cases, elements coupled to the processor may be included on hardware shared with the processor. For example, the communications interfaces625, storage,620, and memory610may be included, along with other elements such as the digital radio, in a single chip or package, such as in a system on a chip (SOC). Computing device600may also include an input device630. Examples of an input device include sensors, cameras, and human input devices, such as mouse, keyboard, touchscreen, etc. Processed input may be output from the computing device600via the communications interfaces625to one or more other devices. In certain cases, the computing device600may also include an output device, not shown, for providing output, for example, to a user. Examples of the output device include a display screen, tactile or motion generators, speakers, lights, etc.