Key revocation for edge devices

RELATED APPLICATIONS

0001This application claims the benefit under 35 U.S.C. § 119(e) of U.S. Provisional Application No. 63/132,992 entitled “KEY REVOCATION FOR EDGE DEVICES,” filed Dec. 31, 2020, under Attorney Docket No. G0766.70338US00, which is incorporated by reference herein in its entirety.

FIELD

0002Embodiments described herein relate to remotely performing key revocation on a device that is limited to communication within a local network of the device.

BACKGROUND

0003A device may use a key to perform cryptographic operations such as encrypting and/or decrypting data. A key used by a device may need to be removed from operation. For example, a device may need to stop using one key for encryption and/or decryption and replace the key with a new key. The device may perform a process of key revocation to revoke use of one key and initiate use of a new key in place of the revoked key.

BRIEF SUMMARY

0004Described herein are techniques of remotely performing key revocation on a device that cannot communicate outside of a local network of the device. The techniques involve including key revocation instructions in software update instructions that are sent to the device. The device may verify the software update instructions using one or more keys to determine whether they are safe for execution on the device. For example, the device may verify that the software update instructions have been sent by a trusted software provider. The device may execute the key revocation instructions included in the software update instruction to revoke use of a key of the key(s), and initiate use of a new key in place of the revoked key.

0005In some embodiments, the device may verify software update instructions using multiple keys, each associated with a different party. For example, one key may be used to verify a signature of a software provider while another key may be used to verify a signature of a user of the device. The device may be configured to execute revocation instructions included in the software update instructions when the software update instructions are verified using both keys. The use of multiple keys provides an additional layer of security against improper key revocation being performed by the device, as an adversary would need to access two separate keys from two different parties in order to initiate a key revocation.

0006According to some embodiments, a method for performing a key revocation on a device limited to communication within a local network of the device is provided. The device stores a first key and a second key. The method comprises: using a processor of the device to perform: receiving, from a host system within the local network of the device, instructions for updating software installed on the device, wherein the instructions include instructions for revocation of the first key; and executing the instructions, wherein execution of the instructions causes the device to: revoke use of the first key; and initiate use of a third key in place of the first key.

0007According to some embodiments, a device forming part of a local network and limited to communication within the local network is provided. The device comprises: a wireless communication circuit; memory configured to store a first key and a second key; and a processor configured to: receive, using the wireless communication circuit from a host system within the local network, instructions for updating software installed on the device, wherein the instructions include instructions for revocation of the first key; and execute the instructions, wherein execution of the instructions causes the device to: revoke use of the first key; and initiate use of a third key in place of the first key.

0008A system for performing key revocation on a device without having connectivity to the device. The device has a first key. The system comprises: a wireless communication circuit; and a processor configured to: transmit, to a host system within a local network of the device, instructions for updating software installed on the device, wherein the instructions, when executed by the device, cause the device to: revoke use of the first key of the device; and initiate use of a second key in place of the first key.

0009A device limited to communication within a local network of the device. The device comprising: a wireless communication circuit; a memory configured to store a first key; and a processor configured to: receive, using the wireless communication circuit from a host system within the local network, instructions for updating software installed on the device, wherein the instructions include instructions for revocation of the first key; verifying the instructions using the first key; and after verifying the instructions using the key, executing the instructions, wherein execution of the instructions causes the device to: revoke use of the first key; and initiate use of a second key in place of the first key.

BRIEF DESCRIPTION OF THE DRAWINGS

0010<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example system in which some embodiments of the technology described herein may be implemented.

0011<figref idref="DRAWINGS">FIG. 2</figref> illustrates an example software architecture of a device, according to some embodiments of the technology described herein.

0012<figref idref="DRAWINGS">FIG. 3</figref> illustrates an example set of software update instructions, according to some embodiments of the technology described herein.

0013<figref idref="DRAWINGS">FIG. 4A</figref> illustrates a software provider system placing a first key on a device, according to some embodiments of the technology described herein.

0014<figref idref="DRAWINGS">FIG. 4B</figref> illustrates a system associated with a user of the device of <figref idref="DRAWINGS">FIG. 2A</figref> placing a second key on the device, according to some embodiments of the technology described herein.

0015<figref idref="DRAWINGS">FIG. 5</figref> illustrates an example process for a device to perform key revocation, according to some embodiments of the technology described herein.

0016<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example process of verifying software update instructions, according to some embodiments of the technology described herein.

0017<figref idref="DRAWINGS">FIG. 7</figref> illustrates an example process for a system to initiate key revocation on a device, according to some embodiments of the technology described herein.

0018<figref idref="DRAWINGS">FIG. 8</figref> illustrates an example computer system which may be used to implement some embodiments of the technology described herein.

DETAILED DESCRIPTION

0019Certain computing devices—sometimes referred to as “edge devices”—are unable to communicate outside of a local network, and thus rely on a host system to communicate outside of the local network. For example, an edge device may rely on a host system that is located proximate the edge device to communicate with a system over the Internet. A system without access to the local network (“external system”) or physical access to the edge device is limited to communicating with the edge device through the host system. As an illustrative example, the edge device may be a battery monitoring device that is sealed inside a battery back. The battery monitoring device may monitor conditions of the battery while the battery is installed and used in a product (e.g., an automobile). While the battery monitoring device is deployed on the product, the battery monitoring device may be unable to communicate over the Internet, and thus a manufacturer's computer system may be limited to communicating with the battery monitoring device (e.g., to retrieve monitoring data) through a host system that is proximate the battery monitoring device.

0020An edge device may store one or more keys for use in performing cryptographic operations. The cryptographic operations may include encrypting data and/or decrypting data. For example, the edge device may use a key to decrypt data of a digital signature to verify the digital signature. As another example, the edge device may use a key to encrypt data as a digital signature of the device. An edge device may also use key(s) to verify software installed on the device. Software installed on the edge device may have been digitally signed using key(s) by one or more external systems such as a software provider's system, a system of a user of the edge device, and/or another external system. The edge device may store key(s) corresponding to the key(s) used to digitally sign the software, and use its stored key(s) to verify that the software is from a trusted source, for example from the software provider. As an illustrative example, a device may store public key(s) corresponding to private key(s) that were used to digitally sign software installed on the device. In this example, the device may use its stored public key(s) to verify digital signature(s) of the software before allowing the software to operate the device.

0021Throughout the lifetime of an edge device, it may be desirable or even necessary to perform key revocation in which usage of a key by the edge device is stopped (“revoked”) and usage of a new key is initiated. For example, if a private key stored on a software provider's computer system is compromised, a corresponding key on a device may need to be revoked in order to protect the device from being susceptible to receiving unauthorized communications from the manufacturer's computer system. For example, an adversarial entity may use the compromised private key to transmit software to the device, and possibly gain unauthorized control of the device. Without revocation of the key corresponding to the private key, the device would be unable to detect that the software provided by the adversarial entity is unauthorized for use. The problem may be further compounded because the edge device may be one of many edge devices that each uses the key to verify software on the device. The key may thus be stored on a fleet of a user's devices. Without revocation of the key from the fleet of devices, an adversarial entity may gain unauthorized control over the entire fleet of devices. As an illustrative example, each of a fleet of vehicle sensors may store a public key corresponding to a private key of a provider of software installed on the sensor, and use the key to verify the software when it is being loaded before allowing it to control the sensor. If an adversary were to gain access to the private key of the software provider, the adversary may be able to transmit its own software to the vehicle sensors signed using the private key. As the vehicle sensors would still be using the key corresponding to the private key, the vehicle sensors would load the adversary's software and allow it to control the sensors.

0022The inventors have recognized that performing remote key revocation on an edge device is difficult because of the limitations in communicating with the edge device. A system (e.g., a software provider system) that needs to initiate a key revocation cannot directly communicate with the edge device to do so. Instead, key revocation on an edge device would be initiated by an intermediary host system that can communicate with the edge device (e.g., over a local network). However, an edge device that receives a key revocation instruction from a host system cannot verify that the key revocation request is valid because the edge device cannot communicate with a third party verification authority to verify the validity of the request. For example, the edge device cannot access an independent third party certification authority through the Internet to verify that a key revocation request was generated by a trusted software provider system. The edge device would be unaware if the host system that transmitted the request has been compromised, or that a key revocation request received from the host system was initiated by an adversarial entity. Conventional techniques do not allow secure performance of remote key revocation on an edge device without a third party verification authority.

0023The inventors have developed techniques to securely perform remote key revocation on an edge device without requiring a third party verification authority. The techniques provide a remote key revocation process that does not rely on a host system to initiate remote key revocation. This prevents a compromised host system or compromised system communicating with the host system from performing unauthorized key revocation on the edge device. The techniques leverage a secure software update process to perform key revocation.

0024Some embodiments of techniques described herein use a secure software update procedure to perform key revocation on a device that is limited to communication within a local network of the device. The techniques embed software instructions for performing key revocation within software update instructions provided to the device. When the device receives the software update instructions, the device may verify and execute the software instructions and, as a result, revoke use of a key and initiate use of a new key in place of the revoked key. The techniques limit initiation of key revocation on the edge device to the secure software update procedure used to update software on the edge device, and thus do not allow the host system to initiate key revocation. In some embodiments, the local network of the device lacks any third party verification authority that the device can use to verify instructions received by the device. Thus, the device may be unable to communicate any such third party verification authority. By embedding key revocation instructions in the software update instructions, some embodiments eliminate the need for the device to participate in communication (e.g., in a challenge response protocol) to request key revocation. This eliminates the opportunity for an adversary to provide its own new key to use in place of a revoked key by intercepting a request to perform key revocation transmitted by the device. Instead, the device verifies software update instructions provided to the device using one or more of its keys. The key revocation is performed if the software update instructions are verified, and otherwise not executed.

0025Some embodiments of techniques described herein perform remote key revocation using a trusted software platform of the edge device. The trusted software platform may allow the device to perform key revocation even if a key of the device is compromised. The trusted software platform of the device uses two keys, each provided by a separate party, to verify software loaded on the device. The trusted software platform includes multiple software layers which are serially loaded. The software layers may include one or more trusted bootloaders that verify the software using the two keys before enabling the software to operate the device.

0026Accordingly, techniques described herein improve the security of an edge device by allowing key revocation to be performed in a secure manner. Due to an edge device's inability to communicate with a third party verification authority, conventional techniques would either require the edge device to execute revocation instructions without verification that the instructions are sent by a trusted source (e.g., a device manufacturer and/or a provider of software installed on the device), or otherwise not include key revocation functionality in the edge device and thus be susceptible to an adversary that gains access to a key corresponding to a key of the device (e.g., an adversary that acquires a private key corresponding to a public key stored on the device). Techniques described herein provide a more secure edge device that includes key revocation functionality for protection against communication from a compromised external system, and the ability to verify that key revocation instructions are from a trusted source.

0027Some embodiments may allow one-time revocation, in which the edge device stores a flag indicating whether a key has been revoked. Some embodiments may allow a predetermined number of key revocations, in which the edge device selects from a set of keys during each revocation. Some embodiments may allow an unlimited number of revocations, where each revocation updates a key. Some embodiments of techniques described herein include a key selection mechanism that indicates to the edge device to stop using one key, and initiate use of another key. The secure key mechanism may use a flag indicating that a key is revoked, and an indication of a new key.

0028<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example system <b>100</b> in which some embodiments of the technology described herein may be implemented. The system <b>100</b> includes a device <b>102</b> and a host system <b>104</b> within a local network <b>110</b>, and a software provider system <b>106</b> in communication with the host system <b>104</b> through a network <b>108</b>. The device <b>102</b> is an edge device. As illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, the device <b>102</b> is limited to communication with devices within the local network <b>110</b> of the device. The device <b>102</b> is unable to communicate with the software provider system <b>106</b> through the network <b>108</b>, or otherwise directly with the software provider system <b>106</b>.

0029The network <b>108</b> may be any suitable communication network through which the software provider system <b>106</b> may communicate with the host system <b>104</b>. In some embodiments, the network <b>108</b> may include one or more vehicle networks. For example, the network <b>108</b> may include a controller area network (CAN) through which the software provider system <b>106</b> may communicate with the host system <b>106</b>. The network <b>108</b> may include an electronic control unit (ECU) that communicates with the host system <b>104</b> and the software provider system <b>106</b> through the CAN. In some embodiments, the network <b>108</b> may include local area network (LAN). In some embodiments, the network <b>108</b> may include a remote network (e.g., the Internet). In some embodiments, the network <b>108</b> may be a local connection between the software provider system <b>106</b> and the host system <b>104</b>.

0030The device <b>102</b> includes various components. As shown in <figref idref="DRAWINGS">FIG. 1</figref>, the device <b>102</b> includes a processor <b>102</b>A, wireless communication circuitry <b>102</b>B, and memory <b>102</b>C. In some embodiments, the device <b>102</b> may include a system on chip (SoC) that includes the processor <b>102</b>A, the wireless communication circuitry <b>102</b>B, and the memory <b>102</b>C.

0031The processor <b>102</b>A comprises electronic circuitry configured to execute software instructions. For example, the processor <b>102</b>A may comprise a microcontroller, a microprocessor, an embedded processor, a digital signal processor (DSP), a graphical processing unit (GPU), a neural processing unit (NPU), and/or another suitable processor.

0032The processor <b>102</b>A may be configured to perform key revocation. The processor <b>102</b>A may perform revocation by executing software instructions stored on the device <b>102</b> (e.g., in memory <b>102</b>C). The processor <b>102</b>A may be configured to perform key revocation by receiving from the host system <b>104</b> within the local network <b>110</b> of the device <b>102</b>, instructions for updating software installed on the device <b>110</b>. The instructions for updating software installed on the device <b>110</b> may include software instructions for an update to software installed on the device. For example, the software instructions may include an updated software image for a software application installed on the device. The instructions may further include instructions for revocation of a key (e.g., stored in memory <b>102</b>C). When the processor <b>102</b>A executes the key revocation instructions, they cause the device <b>102</b> to revoke use of one key and initiate use of another key in place of the revoked key. In some embodiments, the revocation instructions, when executed by the processor <b>102</b>A, may cause the processor <b>102</b>A to access the new key from memory <b>102</b>C of the device <b>102</b>, and configure the device <b>102</b> to use the new key in subsequent operations in place of the first key. For example, the revocation instructions may cause the processor <b>102</b>A to access the new key from flash memory of the device <b>102</b>. In some embodiments, the revocation instructions may include the new key. In such embodiments, the processor <b>102</b>A may copy the new key from the revocation instructions into its memory <b>102</b>C, and use the new key in subsequent operations in place of the first key.

0033As an illustrative example, the device <b>102</b> may be a vehicle controller device having software installed thereon for electronically controlling a vehicle (e.g., climate system control, cruise control, auto-driving, braking, and/or another aspect of the vehicle). The host system <b>104</b> may be a central electronic control unit (ECU) of the vehicle through which the device <b>102</b> receives software updates. In this example, the vehicle controller device may receive an update to its control software which also includes key revocation instructions. For example, the vehicle controller device may receive an update including the key revocation instructions due to a breach of the software provider system <b>106</b> in which an adversary gained access to a private key corresponding to a previous key of the device <b>102</b>. As such the adversary could transmit its own software instructions to the device <b>102</b> signed with the private key. As the vehicle controller device does not have access to a third party verification authority (e.g., through the Internet), the vehicle controller device would be unable to determine that the software instructions were transmitted by an adversary.

0034Returning again to <figref idref="DRAWINGS">FIG. 1</figref>, the wireless communication circuitry <b>102</b>B may comprise a transceiver that allows the device <b>102</b> to communicate with one or more external systems (e.g., host system <b>104</b>) within a range of the device <b>102</b>. For example, the transceiver may be a BLUETOOTH transceiver, an infrared (IR) transceiver, a radio transceiver, or other suitable type of transceiver. The wireless communication circuitry <b>102</b>B may be configured to communicate in a local network (e.g., network <b>110</b>) of the device <b>102</b>. The device <b>102</b> may use the wireless communication circuitry <b>102</b>B to transmit and/or receive data from an external system. For example, the device <b>102</b> may use the wireless communication circuitry <b>102</b>B to transmit and receive data in packets. In some embodiments, the wireless communication circuitry may be limited to communication within the local network <b>110</b> of the device <b>102</b>. The local network <b>110</b> may have a boundary that is within a vicinity of the wireless communication circuitry <b>102</b>B. For example, the wireless communication circuitry <b>102</b>B may be limited to communicating with external systems within a threshold distance of the wireless communication circuitry <b>102</b>B. The threshold distance may be 10 feet, 20 feet, 30 feet, 40 feet, 50 feet, 100 feet, 200 feet, or other suitable distance from the wireless communication circuitry <b>102</b>B. In some embodiments, the local network <b>110</b> may be a wireless local network (WLAN), For example, the WLAN may include a router configured to transmit and receive data over radio frequencies. In some embodiments, the local network <b>110</b> may be a communication network between the wireless communication circuitry <b>102</b>B and one or more external systems.

0035Memory <b>102</b>C may comprise hardware that can be configured to store information. For example, the memory <b>102</b>C may comprise an integrated circuit that is used to store information. The memory <b>102</b>C may include non-volatile memory such as flash memory, one time programmable (OTP) memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), and/or electrically erasable programmable read-only memory (EEPROM). The memory <b>102</b>C may include volatile memory such as static random access memory (SRAM) and/or dynamic random access memory (DRAM).

0036As shown in <figref idref="DRAWINGS">FIG. 1</figref>, the memory <b>102</b>C is configured to store one or more keys. The key(s) may be cryptographic key(s) that are used to perform cryptographic operations including authentication of data, encryption of data, decryption of data, generation and/or verification of a signature, verification of software instructions, and/or other cryptographic operations. In some embodiments, a key may consist of a set of characters. For example, the key may be a randomly generated string of characters. In some embodiments, a key may be generated using a key generation algorithm. For example, a key may be generated using a deterministic random bit generator (DRBG), or a pseudorandom number generator (PRNG) to obtain a random value. In some embodiments, a key may be generated from a random value using a key generation algorithm. In another example, the key may be generated from a random value using a key generation algorithm such as the advanced encryption standard (AES) key generation algorithm, or the Rivest Shamir Adleman (RSA) key generation algorithm. In some embodiments, the key(s) may include asymmetric key(s). The asymmetric key(s) stored in the memory <b>102</b>C may be public key(s) corresponding to private key(s). In some embodiments, the key(s) may include symmetric key(s). The symmetric key(s) stored in the memory <b>102</b>C may be identical to key(s) stored in another system.

0037In some embodiments, the key(s) may include multiple keys generated by multiple external systems. Each of the multiple keys may be generated by a respective external system. In some embodiments, a first key may be generated by a software provider system <b>106</b> and a second key may be generated by a system associated with a user of the device <b>102</b>. A system associated with a user of the device <b>102</b> may also be referred to herein as a “user system”. To illustrate, the software provider system <b>106</b> may be associated with a manufacturer of the device. When the device <b>102</b> is with the manufacturer, the manufacturer may use the software provider system <b>106</b> to generate a key (e.g., a symmetric key, or a public key) that is then stored in the memory <b>102</b>C. A user of the device <b>102</b> (e.g., an entity that purchases the device <b>102</b>) may use a user system to generate a key (e.g., a symmetric key, or a public key) that is stored in the memory <b>102</b>C.

0038In some embodiments, the key(s) may include a single key generated by an external system. In some embodiments, the key may be generated by a software provider system <b>106</b>. For example, the software provider system <b>106</b> may generate the key and store the key in the memory <b>102</b>C while the device <b>102</b> is with the manufacturer. In some embodiments, the key may be generated by a user system. For example, the key may be generated by a user system and stored in the memory <b>102</b>C of the device <b>102</b> prior to deployment of the device <b>102</b>.

0039In some embodiments, the key(s) may include one or more keys to use after revocation. A key that is be used after performing a revocation may also be referred to herein as “revocation key”. For example, the key(s) may include a first key that the device is configured to use for cryptographic operations, and a revocation key that the device is configured to use after revocation of the first key. When revocation is performed by the device, the device may stop use of the first key and initiate use of the revocation key for performing cryptographic operations. In some embodiments, the key(s) may include multiple revocation keys. In such embodiments, each time the device <b>102</b> performs revocation, the device <b>102</b> may revoke use of a previous key and initiate use of one of the multiple revocation keys. For example, the key(s) may include 2, 3, 4, 5, or more revocation keys. In some embodiments, the key(s) may include a single revocation key. In such embodiments, the device <b>102</b> may be limited to performing one revocation. In some embodiments, revocation key(s) may be stored in the memory <b>102</b>C prior to deployment of the device <b>102</b> for use. For example, the revocation key(s) may be stored in the memory <b>102</b>C during manufacturing of the device <b>102</b>. In another example, the revocation key(s) may be stored in the memory <b>102</b>C by a user of the device prior to deploying the device <b>102</b> for use. In some embodiments, the amount of storage space in the memory <b>102</b>C may limit the number of keys that can be stored therein. For example, the amount of storage space in the memory <b>102</b>C may limit the number of keys to 2, 3, 4, or 5 keys.

0040<figref idref="DRAWINGS">FIG. 2</figref> illustrates an example software architecture <b>200</b> of the device <b>102</b>, according to some embodiments of the technology described herein. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, the software architecture <b>200</b> includes a first bootloader <b>202</b>, a second bootloader <b>204</b>, operational software <b>206</b>, communication software <b>208</b>, and over-the-air (OTA) processing software <b>214</b>. In some embodiments, the first bootloader <b>202</b> may be an immutable hardware bootloader (e.g., in ROM), and the second bootloader <b>204</b> may be an optional subsequent bootloader that performs additional validation. In some embodiments, the second bootloader <b>204</b> may be stored in flash memory.

0041The device <b>102</b> may be configured to use the first bootloader <b>202</b> and the second bootloader <b>204</b> when loading operational software <b>206</b> onto the device <b>102</b>. Each of the bootloaders <b>202</b>, <b>204</b> may comprise a set of instructions stored in memory <b>102</b>C of the device <b>102</b> that are executed to load the operational software <b>206</b> into memory of the device <b>102</b>. For example, the first bootloader <b>202</b> may be stored in read-only memory (ROM) and the second bootloader <b>204</b> may be stored in flash memory. The device <b>102</b> may be configured to use the bootloaders <b>202</b>, <b>204</b> to sequentially load the operational software <b>206</b> in stages. In some embodiments, each of the bootloaders <b>202</b>, <b>204</b> may be configured to use its own respective key to verify the operational software <b>206</b>. For example, the first bootloader <b>202</b> may use a first key to verify a first signature of the operational software <b>206</b>, and the second bootloader <b>204</b> may use a second key to verify a second signature of the operational software <b>206</b>. The first signature may be generated by a software provider system and a second signature may be generated by a user system. In embodiments in which each of the first bootloader <b>202</b> and the second bootloader <b>204</b> is configured to use its own respective key to verify the operational software <b>206</b>, for an adversary to load operational software onto the device <b>102</b>, the adversary would have to transmit software to the device <b>102</b> that includes two separate signatures generated using two separate keys of two different parties (e.g., software provider and user).

0042As illustrated in <figref idref="DRAWINGS">FIG. 2</figref> the operational software <b>206</b> may use communication software <b>208</b> to operate wireless communication circuitry <b>210</b> of the device. The wireless communication circuitry <b>210</b> may be the wireless communication circuitry <b>102</b>B described herein with reference to <figref idref="DRAWINGS">FIG. 1</figref>. The communication software <b>208</b> may allow the device <b>102</b> to transmit and receive data from the host system <b>104</b>. The communication software <b>208</b> may be configured to receive, using the wireless communication circuitry <b>210</b>, software update instructions <b>212</b> from the host system <b>104</b>. The software update instructions may include key revocation instructions. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, the software update instructions processing <b>214</b> is performed by the second bootloader <b>204</b>. The software update instructions processing <b>214</b> is performed by the second bootloader because the software update may include updates to the bootloaders <b>202</b>, <b>204</b>. In some embodiments, the operational software <b>206</b> may be restricted from modifying the bootloaders <b>202</b>, <b>204</b>. Restricting the operational software <b>206</b> from modifying the bootloaders <b>202</b>, <b>204</b> may ensure that the bootloaders <b>202</b>, <b>204</b> are protected from any adversary, and thus can be trusted to update software on the device <b>102</b>. In such embodiments, software updates may not be performed by operational software <b>206</b>.

0043Although the example embodiment of <figref idref="DRAWINGS">FIG. 2</figref> includes two bootloaders, in some embodiments, the software architecture of a device may include one bootloader. The bootloader may be configured to perform the processing of the bootloaders <b>202</b>, <b>204</b> described herein. In some embodiments, the bootloader may be an immutable hardware bootloader. For example, the immutable hardware bootloader may be a ROM bootloader. In some embodiments, the software architecture may include one or more subsequent optional bootloaders that may be configured to perform additional validation. In such embodiments, the optional bootloader(s) may not be required to load operational software onto the device, or to verify software instructions (e.g., including key revocation instructions).

0044The host system <b>104</b> may comprise one or more computing devices within a local network <b>110</b>. The host system <b>104</b> may be located within a vicinity of the device <b>102</b> in which the device <b>102</b> can communicate with the host system (e.g., using wireless communication circuitry <b>102</b>B). The host system <b>104</b> may be configured to communicate through a network <b>108</b> that is outside of the local network <b>110</b> of the device. As shown in <figref idref="DRAWINGS">FIG. 1</figref>, the host system <b>104</b> can communicate with a software provider system <b>106</b> through the network <b>108</b>. For example, the host system <b>104</b> may include wireless communication circuitry that allows the host system <b>104</b> to communicate through the Internet. As an illustrative example, the host system <b>104</b> may be a central electronic control unit (ECU) of a vehicle, while the device <b>102</b> may be a vehicle controller device for a particular component of the vehicle (e.g., climate control, cruise control, auto driving, and/or braking).

0045The software provider system <b>106</b> may comprise one or more computing devices outside of the local network <b>110</b> of the device <b>102</b>. In some embodiments, the software provider system <b>106</b> may be associated with a manufacturer of the device <b>102</b>. The software provider system <b>106</b> may provide software for operation of the device <b>102</b>. For example, the device <b>102</b> may be a vehicle controller device, and the software provider system <b>106</b> may provide a software application for the device <b>102</b> to perform its vehicle control operations. In another example, the device <b>102</b> may be a sensor, and the software provider system <b>106</b> may provide a software application that operates the sensor to collect measurements. In another example, the device <b>102</b> may be a camera and the software provider system <b>106</b> may provide software instructions for performing image processing and enhancement that are used by the camera in capturing images.

0046The software provider system <b>106</b> may be configured to remotely perform key revocation on the device <b>102</b>. The software provider system <b>106</b> may be configured to remotely revoke a key on the device <b>102</b> by generating software update instructions that include key revocation instructions. The software provider system <b>106</b> may transmit the software update instructions to the host system <b>104</b> through the network <b>108</b> for transmission to the device <b>102</b>. In some embodiments, the software provider system <b>106</b> may be configured to: (1) generate the software update instructions to include an update to software installed on the device <b>102</b> and key revocation instructions; and (2) and include authentication information with the generated set of software instructions. In some embodiments, the authentication information may be a digital signature. In some embodiments, the authentication information may be an authentication code generated using a symmetric algorithm. In some embodiments, the authentication information may be an encrypted hash of the software update instructions encrypted by the software provider system <b>106</b>. An update to software installed on the device <b>102</b> may be a software image, and the key revocation instructions may include software instructions that, when executed by a processor of the device <b>102</b>, cause the device to stop use of a key and initiate use of a new key for cryptographic operations in place of the revoked key. A key that is presently used by the device <b>102</b> to verify information and instructions sent by the software provider system <b>106</b> may be used to verify the software update instructions. For example, the software provider system <b>106</b> may digitally sign the software update instructions using a private key corresponding to a public key stored by the device <b>102</b>. In another example, the software provider system <b>106</b> may digitally sign the software update instructions using a symmetric key that is also stored by the device <b>102</b>. In some embodiments, the software provider system <b>106</b> may be configured to sign a software update using a new key (e.g., a new private key) such that the device <b>102</b> can verify the software update using a corresponding new key (e.g., new public key) that is to be used as a result of executing the revocation instructions. The device <b>102</b> may be configured to use its new key to verify the updated software (e.g., when loading the software onto the device <b>102</b>).

0047<figref idref="DRAWINGS">FIG. 3</figref> illustrates an example set of software update instructions <b>300</b>, according to some embodiments of the technology described herein. The software update instructions <b>300</b> may be generated by the software provider system <b>106</b> of <figref idref="DRAWINGS">FIG. 1</figref>.

0048The software update instructions <b>300</b> include a set of key revocation instructions <b>302</b>. The key revocation instructions <b>302</b> may be executable by a processor of the device <b>102</b>. When executed, the key revocation instructions <b>302</b> may cause the device <b>102</b> to stop use of a first key for cryptographic operations and initiate use of new key for subsequent cryptographic operations. For example, the key revocation instructions <b>302</b> may cause the processor to update a flag associated with the first key stored in memory indicating that the first key is no longer to be used and/or update a flag associated with new key in memory indicating that the new key is to be used. In another example, the key revocation instructions <b>302</b> may cause the device <b>102</b> to remove the first key from the memory <b>102</b>C of the device. In another example, the key revocation instructions <b>302</b> may identify a location in memory of the device <b>102</b> storing the new key from which the device <b>102</b> is to obtain a key for use in cryptographic operations. In another example, the revocation instructions <b>302</b> may modify a variable in memory <b>102</b>C of the device <b>102</b> that causes the device <b>102</b> to use the new key in place of the first key. The software update instructions <b>300</b> include a software image <b>304</b>. The software image <b>304</b> may be an updated software image for software installed on the device. For example, the software image <b>304</b> may update operations performed by the device <b>102</b>, resolve bugs in software of the device <b>102</b>, or otherwise modify the software of the device <b>102</b>.

0049The software update instructions <b>300</b> of <figref idref="DRAWINGS">FIG. 3</figref> are signed with two signatures: a first signature <b>300</b>A generated by the software provider system <b>106</b> using a first key, and a second signature <b>300</b>B generated by a user system using a second key. The device <b>102</b> may be configured to verify the software update instructions <b>300</b> using both signatures (e.g., as performed in process <b>600</b> described herein with reference to <figref idref="DRAWINGS">FIG. 6</figref>). In this embodiment, for an adversary to be able to transmit a software image and/or key revocation instructions to the device <b>102</b>, the adversary would have to access both the first key and the second key in order to generate the two signatures. As indicated by the dotted line around the signature <b>300</b>B generated using the second key, in some embodiments, the software update instructions <b>300</b> may only be signed with the signature <b>300</b>A generated using the first key. In such embodiments, the software update instructions <b>300</b> may be signed by the software provider system <b>106</b> but not a user system.

0050As illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, the software image <b>302</b> is signed with a signature <b>304</b>A generated using the new key that is to be used after the device <b>102</b> executes the key revocation instructions <b>302</b>. The device <b>102</b> may verify the new software image <b>304</b> using the new key. For example, the device <b>102</b> may verify the new software image <b>304</b> using the new key when loading the software after power up. The software image <b>304</b> is also signed with a signature <b>304</b>B generated using the second key (e.g., of a user system). The device <b>102</b> may use the signature <b>304</b>B to verify the software image <b>304</b> in addition to the signature <b>304</b>A generated using the new key. In some instances, the new software image <b>304</b> may be functionally identical to the to a software image that is presently on the device. In such instances, the new software image <b>304</b> may be provided to provide the new key and/or the signature <b>304</b>B. Thus, the software update instructions <b>300</b> may be used to perform key revocation without updating functionality of the software.

0051As indicated by the dotted lines of the signature <b>304</b>B, in some embodiments, the software image <b>304</b> may be signed with the signature <b>304</b>A without the signature <b>304</b>B. For example, the user system may not sign the software image <b>304</b>. In another example, the user system may sign the software update instructions <b>300</b>, but the software provider system may not. In some embodiments the software update instructions <b>100</b> are signed by one entity (e.g., a software provider system or a user system), and delivered (e.g., to a host system) by another entity (e.g., the user system or the software provider system) that does not sign the software update instructions <b>100</b>. For example, the software provider system may sign the software instructions <b>300</b>, and the user system may deliver the software update instructions <b>300</b> to the host system. In such embodiments, an adversary would still need to access two separate systems (i.e., the signing system and the delivery system) to gain access to be able to provide key revocation instructions to a device.

0052<figref idref="DRAWINGS">FIG. 4A</figref> illustrates a software provider system <b>400</b> placing a first key on a device <b>410</b>, according to some embodiments of the technology described herein. In some embodiments, the software provider system <b>400</b> may be software provider <b>106</b> of <figref idref="DRAWINGS">FIG. 1</figref> and the device <b>410</b> may be device <b>102</b> of <figref idref="DRAWINGS">FIG. 1</figref>.

0053The software provider system <b>400</b> performs key generation <b>402</b>. In the example of <figref idref="DRAWINGS">FIG. 4A</figref>, the software provider system <b>400</b> performs private/public keypair generation in which the software provider system <b>400</b> generates a keypair consisting of a private key <b>402</b>A and a corresponding public key <b>402</b>B. The private key <b>402</b>A may not be shared outside of the software provider system <b>400</b>, while the corresponding public key <b>402</b>B may be distributed outside of the software provider system <b>400</b>. In some embodiments, the software provider system <b>400</b> may be configured to use key generation <b>402</b> to generate an asymmetric key pair for a signature algorithm. For example, the software provider system <b>400</b> may generate an asymmetric key pair for a Rivest-Shamir Adleman (RSA), Elliptic Curve Digital Signature Algorithm (ECDSA), digital signature algorithm (DSA), or other digital signature scheme. In another example, the software provider system <b>400</b> may perform key generation <b>402</b> to generate a symmetric key.

0054The software provider system <b>400</b> transmits the public key <b>402</b>B and signature to the device <b>410</b>. As shown in <figref idref="DRAWINGS">FIG. 4A</figref>, the software provider system <b>400</b> transmits the public key <b>402</b>B and/or signature to the device <b>410</b> for storage in memory <b>440</b> of the device <b>410</b>. In some embodiments, the software provider system <b>400</b> may transmit the public key <b>402</b>B to the device <b>410</b> through a physical connection. For example, the software provider system <b>400</b> may be connected to the device <b>410</b> using a Joint Test Action Group (JTAG) connection, serial peripheral interface (SPI), an I2C connection, a low pint count (LPC) interface, a universal serial bus (USB) connection, an ethernet connection, a firewire connection, a serial port connection, or other suitable physical connection. In some embodiments, the software provider system <b>400</b> may transmit the public key <b>402</b>B to the device <b>410</b> through a wireless connection. For example, the software provider system <b>400</b> may be connected to the device <b>410</b> using BLUETOOTH, infrared, Wi-Fi, or other suitable wireless connection. In some embodiments, the software provider system <b>400</b> may be configured to transmit the public key <b>402</b>B to the device <b>410</b> during manufacturing. The software provider system <b>400</b> may be associated with a manufacturer of the device <b>410</b>. Prior to sending the device <b>410</b> to a user, the software provider system <b>400</b> may transmit the public key <b>402</b>B to the device <b>410</b>.

0055As shown in <figref idref="DRAWINGS">FIG. 4A</figref>, the software provider system <b>400</b> further performs signature generation <b>408</b> using the private key <b>402</b>A to generate a signature. The software provider system <b>400</b> transmits a generated signature to the device <b>410</b> for storage in memory <b>440</b>. The public key <b>402</b>B corresponding to the private key <b>402</b>A used to generate the signature may subsequently be used by a user system to verify that the signature loaded in the memory <b>440</b> of the device <b>410</b> is a valid signature of a software provider. In some embodiments, the software provider system <b>400</b> may be configured to generate the signature by encrypting data using the private key <b>402</b>A to obtain encrypted data. The public key <b>402</b>B stored in the memory <b>440</b> of the device <b>410</b> may be used by a user system to verify that the signature stored in the device <b>410</b> is valid (e.g., using an RSA, ECDSA, or other suitable digital signature scheme).

0056Although in the example of <figref idref="DRAWINGS">FIG. 4A</figref>, the software provider system <b>400</b> generates a private/public keypair, in some embodiments, the software provider system <b>400</b> may be configured to generate a symmetric key. In such embodiments, the system <b>400</b> may generate a single key that is transmitted to the device <b>410</b> to store in memory <b>440</b>. The software provider system <b>400</b> may use the same key to encrypt a message authentication tag. The user system may use the key verify that the message authentication tag has not changed.

0057<figref idref="DRAWINGS">FIG. 4B</figref> illustrates a user system <b>430</b> associated with a user of the device <b>410</b> of <figref idref="DRAWINGS">FIG. 2A</figref> placing a second key on the device <b>410</b>, according to some embodiments of the technology described herein. In the example of <figref idref="DRAWINGS">FIG. 4B</figref>, the user system <b>430</b> performs private/public keypair generation <b>432</b> in which the user system <b>430</b> generates a keypair consisting of a private key <b>432</b>A and a corresponding public key <b>432</b>B. The private key <b>432</b>A may not be shared outside of the user system <b>430</b>, while the corresponding public key <b>432</b>B may be distributed outside of the user system <b>430</b>. In some embodiments, the user system <b>430</b> may be configured to perform key generation <b>432</b> to obtain an asymmetric key pair for a signature algorithm. Example algorithms are described herein with reference to <figref idref="DRAWINGS">FIG. 4A</figref>. In some embodiments, the user system <b>430</b> may be configured to perform key generation <b>432</b> to generate a symmetric key.

0058As shown in <figref idref="DRAWINGS">FIG. 4A</figref>, the user system <b>430</b> transmits the public key <b>432</b>B to the device <b>410</b> for storage in memory <b>440</b> of the device <b>410</b>. In some embodiments, the user system <b>430</b> may be configured to transmit the public key <b>402</b>B to the device <b>410</b> through a physical connection. For example, the user system <b>430</b> may transmit the public key <b>432</b>B to the device <b>410</b> through a universal serial bus (USB) connection, an ethernet connection, a firewire connection, a serial port connection, or other suitable physical connection. In some embodiments, the user system <b>430</b> may be configured to transmit the public key <b>402</b>B to the device <b>410</b> through a wireless connection. For example, the user system <b>430</b> may transmit the public key <b>432</b>B to the device <b>410</b> using a BLUETOOTH connection, infrared connection, Wi-Fi connection, or other suitable wireless connection. In some embodiments, the user system <b>430</b> may be configured to transmit the public key <b>432</b>B to the device <b>410</b> prior to deployment. For example, the device <b>410</b> may be obtained from a manufacturer. The user system <b>430</b> may transmit the public key <b>432</b>B to the device <b>410</b> after the device <b>410</b> is obtained from the manufacturer. The user system <b>430</b> may further be configured to verify a public of a software provider system stored in the memory <b>440</b> of the device <b>410</b> as described herein with reference to <figref idref="DRAWINGS">FIG. 4A</figref>.

0059Although in the example of <figref idref="DRAWINGS">FIG. 4B</figref>, the user system <b>430</b> generates a private/public keypair, in some embodiments, the user system <b>430</b> may be configured to generate a symmetric key. In such embodiments, the system <b>430</b> may be configured to generate a single key that is transmitted to the device <b>410</b> to store in memory <b>440</b>.

0060<figref idref="DRAWINGS">FIG. 5</figref> illustrates an example process <b>500</b> for a device to perform key revocation, according to some embodiments of the technology described herein. The process <b>500</b> may be performed by device <b>102</b> described herein with reference to <figref idref="DRAWINGS">FIG. 2</figref>. In some embodiments, the process <b>500</b> may allow the device to perform key revocation without having to request key revocation from another system. For example, the process <b>500</b> may be performed without the device communicating a request to perform key revocation to a system.

0061Process <b>500</b> begins at block <b>502</b>, where the device receives, from a host system (e.g., host system <b>104</b> described herein with reference to <figref idref="DRAWINGS">FIG. 1</figref>), instructions for updating software installed on the device. An example set of instructions are described herein with reference to <figref idref="DRAWINGS">FIG. 3</figref>. The instructions may have been provided to the host system from a software provider system (e.g., software provider system <b>106</b>). The device may be configured to receive the instructions for updating the software through a connection with the host system within a local network of the device. In some embodiments, the device may receive the instructions for updating software installed on the device through a physical connection with the host system. For example, the device may be embedded in a vehicle and the host system may be an ECU of the vehicle that is connected to the device through a wired connection. In some embodiments, the device may receive the instructions for updating software installed on the device through a wireless connection. For example, the device may be able to communicate wirelessly with the host system in a local network of the device.

0062Next, process <b>500</b> proceeds to block <b>504</b>, where the device verifies the instructions received at block <b>502</b> using one or more keys. The device may be configured to use a key to verify that the instructions have been received from a trusted source. For example, the device may use the key to verify that the instructions are instructions generated by a software provider system (e.g., of a manufacturer of the device). In some embodiments, the device may be configured to use the key to verify the instructions. For example, the device may use the key to verify a digital signature included in the instructions using a digital signature scheme (e.g., RSA, ECDSA, or other digital signature scheme). In this example, the verification may involve: (1) performing an operation using the key; and (2) verifying the digital signature based on the result of the operation. The device may verify the digital signature based on the result of the operation by determining whether the result matches an expected result. In another example, the device may verify a message authentication tag using the key (e.g., where the key is a symmetric key).

0063In some embodiments, the device may be configured to verify the instructions using multiple keys. The multiple keys may have been stored on the device prior to deployment of the device for use. For example, the device may verify the instructions using a key stored on the device by a software provider (e.g., a device manufacturer) and a key stored on the device by a user of the device. The keys may have been stored on the device as described herein with reference to <figref idref="DRAWINGS">FIGS. 4A-4B</figref>. Process <b>600</b> describes an example process that the device may perform to verify the instruction using multiple keys.

0064Next, process <b>500</b> proceeds to block <b>506</b>, where the device executes the instructions. A processor of the device may be configured to execute the instructions. In some embodiments, the device may be configured to execute the instructions using bootloader(s) of the device. For example, the device may execute the instructions using bootloader(s) as described with respect to reference <b>214</b> of <figref idref="DRAWINGS">FIG. 2</figref>.

0065Next, process <b>500</b> proceeds to block <b>508</b>, where the device revokes use of a first key and initiates use of a new key in place of the first key. The device may perform the steps of block <b>508</b> as a result of executing the instructions at block <b>506</b>. The instructions cause the device to perform revocation. In some embodiments, the device may set a flag that causes the device to revoke use of the first key and initiate use of the new key stored in memory of the device. For example, the flag may activate a software function that, when executed, causes the device to revoke use of the first key and initiate use of the new key. In some embodiments, the instructions may include the new key and the device may replace the first key with the new key included in the instructions. In some embodiments, the device may read the new key from the device's memory, and replace the first key with the new key. In some embodiments, the device may modify a flag associated with the first key to indicate that the first key is no longer to be used (e.g., in performing verification, encryption, and/or other processes). In some embodiments, the device may update an index whose value indicates a respective one of a plurality of keys stored in memory of the device. The updated index may indicate the new key in place of the first key. For example, the device may update the index by incrementing the index. In another example, the device may update the index by randomly setting the index to a value different from its current value.

0066In some embodiments, the device may revoke use of data associated with the first key as part of revoking the first key. The data may be used by the device in conjunction with the first key to perform verification. In some embodiments, the data may be a hashing of a set of data that is used to verify a digital signature. For example, the device may compare a decryption of a digital signature obtained using the first key to the data (e.g., the hashing of the set of data) to verify the digital signature. The device may revoke use of the of the data associated with the first key, and initiate use of new data associated with the new key. The device may replace the data associated with the first key with the new data associated with the new key, or otherwise update an indication (e.g., an index or flag) that causes the device to subsequently use the new data with the new key.

0067<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example process <b>600</b> of verifying software update instructions, according to some embodiments of the technology described herein. Process <b>600</b> may be performed by device <b>102</b> described herein with reference to <figref idref="DRAWINGS">FIG. 1</figref>. In some embodiments, process <b>600</b> may be performed as part of block <b>508</b> of process <b>500</b> described herein with reference to <figref idref="DRAWINGS">FIG. 5</figref>. In some embodiments, process <b>600</b> may also be performed by a device at every boot up to verify software installed prior to loading the software.

0068The device performing process <b>600</b> may be configured with a multi-bootloader software architecture (e.g., as described herein with reference to <figref idref="DRAWINGS">FIG. 2</figref>). The device may have a first bootloader and a second bootloader. The first and second bootloaders may also be referred to herein respectively as a primary bootloader and a secondary bootloader. Each of the bootloaders may be configured to use a respective key in performing a verification. The first bootloader may be configured to use a first key (e.g., a key provided by the software provider), and the second bootloader may be configured to use a second key (e.g., a key provided by a user of the device). In some embodiments, each of the first and second bootloaders may be configured to use both the first and second key. The software instructions may be encrypted using two keys corresponding to the first key and the second key. In some embodiments, the instructions may be digitally signed using two keys. For example, the first and second keys may be public keys and the software instructions may be digitally signed using first and second private keys corresponding to the first and second public keys. A software provider system may sign the instructions using the first private key and a user system may sign the instructions using the second private key.

0069Process <b>600</b> begins at block <b>602</b>, where the device uses the first bootloader to verify the instructions using the first key. The device may load the first bootloader from memory of the device (e.g., ROM or flash). The first bootloader may be configured to verify the instructions using a first key (e.g., a first public key, or a first symmetric key). The first bootloader may be configured to use the first key to verify a first digital signature included in the instructions. In this example, the first bootloader may use the key to verify the first digital signature by: (1) decrypting encrypted data of the first digital signature using the first key to obtain a decryption of the encrypted data; and (2) verifying the first digital signature based on the decryption. The first bootloader may verify the first digital signature based on the decryption by determining whether the decryption matches an expected output of the decryption. For example, the encrypted data may be an encryption of a hashing of a set of data. In this example, the first bootloader may determine whether the decryption of the encrypted data matches the hashing of the set of data to verify the digital signature. If the decryption matches the hashing of the set of data, then the first bootloader may determine that the first digital signature as valid. If the decryption does not match the hashing of the set of data, then the first bootloader may determine that the first digital signature is invalid.

0070Next, process <b>600</b> proceeds to block <b>604</b>, where the device determines whether the instructions were verified at block <b>602</b>. If verification of the instructions failed at block <b>602</b>, then process <b>600</b> proceeds to block <b>612</b>, where the device prevents execution of the instructions. At block <b>612</b>, the device may stop execution of the instructions. Thus, the device may not perform any key revocation or software update. The device may continue with a previous version of the software and continue using a current key for verification.

0071If the device verified the instructions at block <b>602</b> (e.g., by determining that a first digital signature is valid), then process <b>600</b> proceeds to block <b>606</b>, where the device uses a second bootloader to verify the instructions using the second key. The device may load the second bootloader from memory of the device (e.g., ROM or flash). The second bootloader may be configured to verify the instructions using a second key (e.g., a second public key, or a second symmetric key). The second bootloader may be configured to use the second key to verify a second digital signature included in the instructions. In this example, the second bootloader may use the key to verify the second digital signature by: (1) decrypting encrypted data of the second digital signature using the second key to obtain a decryption of the encrypted data; and (2) verifying the second digital signature based on the decryption. The second bootloader may verify the second digital signature based on the decryption by determining whether the decryption matches an expected output of the decryption. For example, the encrypted data may be an encryption of a hashing of a set of data. In this example, the second bootloader may determine whether the decryption of the encrypted data matches the hashing of the set of data to verify the digital signature. If the decryption matches the hashing of the set of data, then the second bootloader may determine that the second digital signature as valid. If the decryption does not match the hashing of the set of data, then the second bootloader may determine that the second digital signature is invalid.

0072Next, process <b>600</b> proceeds to block <b>608</b>, where the device determines whether the instructions were verified at block <b>606</b>. If verification of the instructions failed at block <b>606</b>, then process <b>600</b> proceeds to block <b>612</b>, where the device prevents execution of the instructions as described above. If the instructions are verified at block <b>606</b>, then process <b>600</b> proceeds to block <b>610</b>, where the device permits execution of the instructions. For example, the instructions may be executed by the second bootloader or by operational software of the device. The instructions may be executed as described at blocks <b>506</b> and <b>508</b> of process <b>500</b> described herein with reference to <figref idref="DRAWINGS">FIG. 5</figref>.

0073<figref idref="DRAWINGS">FIG. 7</figref> illustrates an example process <b>700</b> for a system to perform key revocation on a device, according to some embodiments of the technology described herein. In some embodiments, process <b>700</b> may be performed by software provider system <b>106</b> to revoke a key on device <b>102</b> as described herein with reference to <figref idref="DRAWINGS">FIG. 1</figref>.

0074Process <b>700</b> begins at block <b>702</b>, where the system obtains generates key revocation instructions. The key revocation instructions, when executed by the device, may cause the device to revoke use of a first key and replace it with a new key as described at blocks <b>506</b>-<b>508</b> of process <b>500</b> described herein with reference to <figref idref="DRAWINGS">FIG. 5</figref>. For example, the system may generate a file including code encoding the key revocation instructions.

0075Next, process <b>700</b> proceeds to block <b>704</b>, where the system obtains a software update. The system update may be an updated software image for software installed on the device. In some embodiments, the system may be configured to obtain the software image by compiling source code into an executable software image. For example, the system may compile source code into a binary file that can be loaded and executed by the device. In some embodiments, the system may be configured to obtain the software image by receiving the software image from another system. For example, the software image may have been generated by compiling source code on another system and then transmitted to the system performing process <b>700</b>.

0076Next, process <b>700</b> proceeds to block <b>706</b>, where the system digitally signs the software update using a new key. The new key may correspond to a new key for use by the device in place of the first key after revocation is performed. In some embodiments, the new key may be a new private key corresponding to a new public key to be used on the device. In some embodiments, the new key may be a new symmetric key which is also to be used on the device. The system may be configured to digitally sign the software update by generating a digital signature to be included with the software update. The system may be configured to generate the digital signature by: (1) obtaining a set of data; and (2) encrypting the set of data using the new key to obtain an encrypted set of data as the digital signature. In some embodiments, the system may be configured to obtain the set of data by hashing data (e.g., textual data) to obtain the set of data. The system may encrypt the hashed set of data using the new key. By digitally signing the software update using the new key, the software update may be verified by the device using a corresponding new key of the device after execution of the revocation instructions.

0077Next, process <b>700</b> proceeds to block <b>708</b>, where the system generates software update instructions that include the revocation instructions and the software update. In some embodiments, the system may be configured to generate one or more files including the software update and the revocation instructions. For example, the system may generate a file including the software update (e.g., a software image), and a file including the revocation instructions. The system may store the two files in a single data package as the software update instructions. An example set of software update instructions that may be generated by the system is described herein with reference to <figref idref="DRAWINGS">FIG. 3</figref>.

0078Next, process <b>700</b> proceeds to block <b>710</b>, where the system digitally signs the software update instructions using a first key that corresponds to a key that the device is currently configured to use for verification. The system may digitally sign the software update instructions by generating a digital signature that is included with the software update instructions. Techniques of generating a digital signature using a key are described herein. The device may be configured to verify the software update instructions using the key corresponding to the first key. For example, the device may verify the software update instructions using a public key corresponding to the first key. In another example, the first key may be a symmetric key, and the device may verify the software update instructions using the first symmetric key.

0079Next, process <b>700</b> proceeds to block <b>712</b>, where the system transmits the software update instructions. In some embodiments, the system may be configured to transmit the software update instructions to a user system. The user system may digitally sign the software update instructions. In some embodiments, the user system may verify a digital signature of the system performing process <b>700</b> and, if the user system determines that the digital signature is valid, the user system may digitally sign the software update instructions by generating its own digital signature. The user system may then transmit the software update instructions to a host system (e.g., host system <b>104</b>) for transmission to the device. In some embodiments, the user system may transmit the software update instructions to a host system without digitally signing the software update instructions. In such embodiments, the software update instructions may be signed by a single entity (e.g., the system performing process <b>700</b>). The device may verify the software update instructions by verifying both digital signatures included in the software update instructions. In some embodiments, the system performing process <b>700</b> may be configured to transmit the software update instructions to the host system without transmitting them to a user system. The device may verify the software update instructions by verifying the digital signature of the system included in the software update instructions. Transmission of the software update instructions to the device may cause the device to perform process <b>500</b> described herein with reference to <figref idref="DRAWINGS">FIG. 5</figref>. The device may revoke use of a key and initiate use of another key in place of the revoked key.

0080In some embodiments, the system may be configured to transmit the software update instructions including the key revocation instructions without receiving any request generated by the device. For example, the system may transmit the software update instructions without participating in any communication protocol with the device. As described herein with reference to <figref idref="DRAWINGS">FIG. 4</figref>, the device may receive the instructions (e.g., through a host system) without requesting the instructions. This may eliminate the opportunity for an adversary to intercept any such request and/or send its own key to the device.

0081<figref idref="DRAWINGS">FIG. 8</figref> shows a block diagram of an example computer system <b>800</b> that may be used to implement embodiments of the technology described herein. The computing device <b>800</b> may include one or more computer hardware processors <b>802</b> and non-transitory computer-readable storage media (e.g., memory <b>804</b> and one or more non-volatile storage devices <b>806</b>). The processor(s) <b>802</b> may control writing data to and reading data from (1) the memory <b>804</b>; and (2) the non-volatile storage device(s) <b>806</b>. To perform any of the functionality described herein, the processor(s) <b>802</b> may execute one or more processor-executable instructions stored in one or more non-transitory computer-readable storage media (e.g., the memory <b>804</b>), which may serve as non-transitory computer-readable storage media storing processor-executable instructions for execution by the processor(s) <b>802</b>.

0082The terms “program” or “software” are used herein in a generic sense to refer to any type of computer code or set of processor-executable instructions that can be employed to program a computer or other processor (physical or virtual) to implement various aspects of embodiments as discussed above. Additionally, according to one aspect, one or more computer programs that when executed perform methods of the disclosure provided herein need not reside on a single computer or processor, but may be distributed in a modular fashion among different computers or processors to implement various aspects of the disclosure provided herein.

0083Processor-executable instructions may be in many forms, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform tasks or implement abstract data types. Typically, the functionality of the program modules may be combined or distributed.